| Age | Commit message (Collapse) | Author |
|---|
|
This patch fixes only obvious lines.
There are still more issues.
Signed-off-by: Gioh Kim <gi-oh.kim@profitbricks.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Replace all occurrences of the term "Ara" with "GMP" in core.
Signed-off-by: Johan Hovold <johan@hovoldconsulting.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
|
|
The download_firmware() function isn't downloading the firmware but just
finding if one is available or not. The same applies to the error
message printed by it.
Replace 'download' with 'find' to make it sound better.
Reported-by: Johan Hovold <johan@hovoldconsulting.com>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
|
|
We set timeouts using gb_bootrom_set_timeout(), which hides the internal
implementation, i.e. workqueues.
While canceling timeouts, we do cancel_delayed_work_sync(), which
exposes the internal implementation and doesn't look that clean.
Create gb_bootrom_cancel_timeout() to hide the internal implementation
here as well.
Reviewed-by: Johan Hovold <johan@hovoldconsulting.com>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
|
|
A special race is observed in the case where the phone boots with
modules attached to it.
In that case, the AP processes a later FIRMWARE_SIZE request from the
bootrom, before processing the response to the earlier AP_READY request.
And because of that, we set the timeout from gb_bootrom_probe() after
trying to cancel it from gb_bootrom_firmware_size_request().
And with that, if the firmware package isn't available for the kernel to
directly read from, then we get a timeout print message like below:
[ 23.669764] bootrom 1-3.3.1: Firmware file 'ara_00000126_00001001_fffe0001_ffe5001a_s2l.tftf' requested
[ 24.680528] bootrom 1-3.3.1: Timed out waiting for Firmware Size Request from the Module
Note that this doesn't happen if the module is inserted into the frame,
after the phone is already booted.
This behavior is the result of an earlier commit cdd1cb3f4943
("operation: add completion work queue").
This perhaps happens only at boot time because the UNBOUND wq
(connection->wq) gets a chance to run on other CPUs, while the BOUND wq
(gb_operation_completion_wq) doesn't at that stage (24 seconds since
boot).
Setting the timeout before sending the AP_READY request fixes it for
now.
Reported-by: Johan Hovold <johan@hovoldconsulting.com>
Reviewed-by: Johan Hovold <johan@hovoldconsulting.com>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
|
|
On failing to find a firmware image, we get these today:
bootrom 1-3.3.1: Firmware request for ara_00000126_00001001_fffe0001_ffe5001a_s2l.tftf has failed : -12
bootrom 1-3.3.1: gb_bootrom_firmware_size_request: failed to download firmware (-12)
Which are more or less duplicate, as they print error for the same root
cause.
With this patch this is all we get now:
bootrom 1-3.3.1: failed to download ara_00000126_00001001_fffe0001_ffe5001a_s2l.tftf firmware (-12)
Reported-by: Johan Hovold <johan@hovoldconsulting.com>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
|
|
The currently set value of next_request_type in the error path of
gb_bootrom_firmware_size_request() is not correct, as it should have
been NEXT_REQ_FIRMWARE_SIZE for the failure case (as we should be
waiting for another similar request).
But, if an error occurs in gb_bootrom_firmware_size_request(), then the
ES3 bootrom will never be able to recover from it and send another
request. And so there is no point waiting for another request and timing
out.
Skip doing that in error path.
Reported-by: Johan Hovold <johan@hovoldconsulting.com>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
|
|
The firmware prefix is hard-coded in a few different places. Put it all
in one handy #define, for when/if we ever decide to change it in the
future...
Testing: 'strings gb-firmware.ko gb-bootrom.ko | grep ara_' produced the
same output before and after this patch.
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Reviewed-by: Viresh Kumar <viresh.kumar@linaro.org>
Acked-by: Sandeep Patil <sspatil@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
|
|
The S3 firmware and S3-BFU firmware images will be named like this going
forward:
S3: ara_00000126_00001001_fffe0001_ffe70018_s3f.tftf
S3-BFU: ara_00000126_00001001_fffe0001_ffe70018_s3_bfu.tftf
But the current naming for S2 loader image is:
ara_00000126_00001001_fffe0001_ffe70018_02.tftf
It makes sense to use similar encoding for all three packages and so it
should be named as:
ara_00000126_00001001_fffe0001_ffe70018_s2l.tftf
Because the boot stage is passed from ES3 bootrom, we can't change its
value now. But the string created to match the package name is created
in bootrom.c and that is the only string we create from bootrom.c.
Update bootrom.c to use "s2l" instead of "02" in the package name.
Compile Tested only.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Tested-by: Karthik Ravi Shankar <karthikrs@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
|
|
The greybus SVC core handles events from the SVC serially today. In some
cases the SVC operations may take too long, for example trying to
activate a dummy interface. If another interface receives a mode-switch
mailbox event in that time, the SVC core wouldn't be able to process it
in quickly enough and bootrom driver will print following error:
bootrom 1-3.3.1: Timed out waiting for Interface Mode Switch from the Module
This can be reproduced easily by attaching a 2x2 module along with any
other normal module like camera or speaker, and doing a unipro_reset
from userspace.
The logs suggest this time to be around 6-7 seconds in most of the
cases. Attaching multiple modules with dummy interfaces may make this
worst.
Lets increase the timeout from 5 to 10 seconds for now, also add a FIXME
for the same.
Testing Done: Tested on EVT 2.0 with camera and a 2x2 module.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Tested-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Reviewed-by: Johan Hovold <johan@hovoldconsulting.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
|
|
Rename NEXT_REQ_TIMEOUT_J to NEXT_REQ_TIMEOUT_MS and store the timeout
in milliseconds instead of jiffies.
Suggested-by: Alex Elder <alex.elder@linaro.org>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Reviewed-by: Johan Hovold <johan@hovoldconsulting.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
|
|
The timeout message is very generic today and there are several requests
we can be timing out waiting for.
Update bootrom driver to also track the next expected request and
enhance the error message based on that to confirm the request we timed
out waiting for.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Reviewed-by: Johan Hovold <johan@hovoldconsulting.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
|
|
User space doesn't break anymore with new greybus modules and its time
to make bootrom a separate module.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
|
|
Its possible that the Module may fail to download the next stage
firmware, or to jump into it and boot into the new personality.
We have already seen examples of both of these cases on EVT 1.5.
This patch implements timeouts in the bootrom bundle driver, which now
expects the next request from the Module to be received at the AP within
1 second of the previous request/response. The time interval can be
increased later if required.
The timeouts are added between:
- AP_READY and FIRMWARE_SIZE operations
- FIRMWARE_SIZE and GET_FIRMWARE operations
- Two GET_FIRMWARE operations
- GET_FIRMWARE and READY_TO_BOOT operations
- READY_TO_BOOT operation and the call to the ->disconnect() event of
the bootrom bundle (once the new hotplug request is received).
The timeout for the last case is kept at 5 seconds right now (random
value), as it may take a bit longer.
Because 'bootrom->fw' can be accessed simultaneously (from timeout
handler and incoming requests) and one of them can potentially free the
'->fw' structure, a mutex is also added to take care of such races while
accessing 'bootrom->fw' structure.
Also note that the '!bootrom->fw' check is moved to free_firmware()
routine.
Note that this version uses delayed-work (instead of timers used in
earlier attempt), as we need to call routines that can sleep from the
timeout handler.
Tested on EVT 1.5, by faking errors on certain requests, so that the
bootrom doesn't send any more requests. Normal case is working just fine
for audio and GP modules. This is tested with build arche_440.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
|
|
This reverts commit 571348253032a86e4f0102d4dfadd390d0ea7e64.
With this patch gb_bootrom_timedout was getting called in interrupt
context and then proceeding to call functions that might block. In
practical terms, this was leading to a kernel BUG at mm/vmalloc.c:1650.
Signed-off-by: Jeffrey Carlyle <jcarlyle@google.com>
Acked-by: Johan Hovold <johan@hovoldconsulting.com>
|
|
Its possible that the Module may fail to download the next stage
firmware, or to jump into it and boot into the new personality.
We have already seen examples of both of these cases on EVT 1.5.
This patch implements timeouts in the bootrom bundle driver, which now
expects the next request from the Module to be received at the AP within
1 second of the previous request/response. The time interval can be
increased later if required.
The timeouts are added between:
- AP_READY and FIRMWARE_SIZE operations
- FIRMWARE_SIZE and GET_FIRMWARE operations
- Two GET_FIRMWARE operations
- GET_FIRMWARE and READY_TO_BOOT operations
- READY_TO_BOOT operation and the call to the ->disconnect() event of
the bootrom bundle (once the new hotplug request is received).
The timeout for the last case is kept at 5 seconds right now (random
value), as it may take a bit longer.
Because 'bootrom->fw' can be accessed simultaneously (from timeout
handler and incoming requests) and one of them can potentially free the
'->fw' structure, a mutex is also added to take care of such races while
accessing 'bootrom->fw' structure.
Also note that the '!bootrom->fw' check is moved to free_firmware()
routine.
Tested on EVT 1.5, by faking errors on certain requests, so that the
bootrom doesn't send any more requests. Normal case is working just
fine for audio and GP modules.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
|
|
s/Firware/Firmware
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
|
|
Align with Greybus specifications and rename Firmware Protocol driver as
Bootrom Protocol driver.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
|
Gioh Kim
Johan Hovold
Viresh Kumar
Greg Kroah-Hartman
Jeffrey Carlyle