[USB BOOT] Help needed

[Vicente Bergas]

On Mon, Feb 13, 2017 at 9:25 AM, Sascha Hauer <s.hauer at pengutronix.de> wrote:
> Hi Vincente,
>
> On Sat, Feb 11, 2017 at 02:50:12PM +0100, Vicente Bergas wrote:
>> Hello
>>
>> Background on the issue
>> #######################
>>
>> Some time ago functionality was added to enable OMAP4 to boot over USB:
>> https://git.pengutronix.de/cgit/barebox/commit/?id=6b4dc4d4f128bd22df4d022ad37285ce4858e1e8
>> That implementation uses the usb library stored in the OMAP4 ROM.
>> The use of the OMAP4 ROM is problematic as it requires interrupts
>> and also does not allow the MMU to be enabled.
>> In fact there is an open issue with it:
>> http://lists.infradead.org/pipermail/barebox/2016-August/027880.html
>>
>> More recently a similar functionality was added to OMAP3:
>> https://git.pengutronix.de/cgit/barebox/commit/?id=1d7c8ec1431aec1c75c79dc17ecad0ab80435311
>> That implementation is using it's own way to access
>> the usb device and has no dependencies on the ROM.
>>
>> Proposed changes
>> ################
>>
>> Given this scenario I modified the OMAP4 code to access the
>> usb device directly, bypassing the ROM library, the same way
>> the OMAP3 code does.
>> Both OMAP3 and OMAP4 use the same usb device (musb, mentor-usb),
>> the only change is the base address.
>> So this modification tries to make it generic for both OMAPs,
>> although it has not been tested on OMAP3.
>> The patch with this modification follows.
>>
>> What is wrong with it
>> #####################
>>
>> Unfortunately, this modification is not working.
>> The observed behaviour is:
>> 1.- The console over usb works fine, as long as
>> there is constant activity. If there are no transfers
>> for approximately 4 seconds then the usb link is lost.
>
> Do there have to be activity from the host to the device or is it enough
> to do a "while true; do echo "huhu"; sleep 3; done" on the barebox
> console?
>

For debugging purposes barebox is using two consoles simultaneously,
one through USB and another through Serial.
If constant activity is maintained at the USB interface then there is data
sent from host to BB and BB replies echos back and it works.
If the constant activity is maintained at the Serial interface then at the
USB side there are only the echos from BB and this also works. So, no
host side transfers are required to keep the USB link alive.

> I don't exactly know how this internally works, but with USB all
> traffic is initiated by the host. If the device never answers a packet
> since it has nothing to say at the moment it might happen that the host
> thinks the device is dead. It's just an idea that you have to send some
> dummy data every few seconds.
>
>> 2.- The file system over usb works fine. Checked MD5 sums
>> of kernel image and initial ram disk, all OK.
>> 3.- Barebox reaches the start_linux function and executes
>> the kernel function pointer, so, control is transferred
>> to linux-land. But linux does not boot and
>> nothing is printed on the serial console.
>
> Have you tried earlyprintk in the Kernel? Do you also use the same
> serial console in barebox, or do you only use console over USB?
> Sometimes it happens that Linux does not have all initialization code so
> that a device does not work in Linux when it hasn't been used in barebox
> before.
>

No time has been spent in this front yet, but, the kernel is expected to use
the serial interface as console.
The kernel knows nothing about the custom protocol used in BB
 for communicating via USB.

As a side note: It would be nice if BB could use a full USB device stack
appearing as a composite gadget with serial and ethernet, all from the spl :)
But size restrictions may make this impossible.

> Sascha
>
>
> --
> Pengutronix e.K.                           |                             |
> Industrial Linux Solutions                 | http://www.pengutronix.de/  |
> Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
> Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |