USB support for U-Boot on Raspberry-Pi

[Stephen Warren]

On 06/22/2012 12:23 PM, Oleksandr Tymoshenko wrote:
> On 6/17/2012 7:52 PM, Oleksandr Tymoshenko wrote:
>> On 6/15/2012 10:53 PM, Stephen Warren wrote:
>>> On 06/15/2012 09:09 PM, Oleksandr Tymoshenko wrote:
>>>> Hello,
>>>>
>>>> Last several weeks I've been working on porting U-Boot to Raspberry Pi
>>>> (as it turned out in parallel with Stephen Warren)  and today I'm happy
>>>> to announce that network support works stable enough.
>>> Excellent!
>>>
>>> I have tested this, and even booted a kernel with DT (the patch I posted
>>> a little while back based on linux-next). A couple gotchas though:
>>>
>>> CONFIG_OF_LIBFDT (for DT) or CONFIG_CMDLINE_TAG (for ATAGs) is needed to
>>> make bootm work.
>>>
>>> Much bigger: Oleksandr's U-Boot branch uses the other UART from what the
>>> kernel usually uses (and that the binary bootloader sets up), so I
>>> wasn't able to see any output from the kernel until I realized I needed
>>> to hack U-Boot to put the UART pinmux back to its more usual setting; I
>>> added the reverse of arch_cpu_init()'s pinmux changes to
>>> cleanup_before_linux() for testing purposes.
>> Thanks for testing, Stephen. I cleaned-up sources and replaced non-USB
>> parts with
>> code from your patches. With these changes I managed netboot linux
>> kernel and
>> get a console output from it (failed at mounting root).
>>
>> For those who would like to give it a try here is archived content of
>> "boot" partition:
>> http://people.freebsd.org/~gonzo/arm/rpi/rpi-uboot.tar.gz
> 
> Follow up on this:
> 
> I added SD card support and tweaked configuration
> to make u-boot more flexible. Current version:
> http://people.freebsd.org/~gonzo/arm/rpi/raspberry-pi-uboot-20120621.tar.gz
> 
> Changes comparing to previous one:
> - Use PL011 UART as a default console
> - USB driver do not hang if encounters error, just reports it
> - SDHC driver added
> - Enabled FAT filesystem support
> - Enabled boot scripts support
> - MAC address for SMSC95XX is obtained from command-line  provided by
> firmware
> - Default boot script reads environment variables from uEnv.txt (if
> present)
>     and passes control  to boot.scr (if present)
> 
> Known problems:
> 
> - Two usb start in row without power cycle does not work
> - USB transaction errors when USB device is plugged into R-Pi
> - bootm command was not tested
> 
> Code in branch still requires major clean-up but build should be usable
> enough.

I briefly tested this (well, commit 4b3863c "More sophysticated
initialization code" from your rpi branch), and the SD support does work
at least partially. I have problems loading some files though; perhaps
it's related to large files?

U-Boot> mmc rescan

U-Boot> mmcinfo
Device: bcm2835_sdh
Manufacturer ID: 3
OEM: 5344
Name: SD08G
Tran Speed: 25000000
Rd Block Len: 512
SD version 2.0
High Capacity: Yes
Capacity: 7.4 GiB
Bus Width: 4-bit

U-Boot> fatls mmc 0:1 /
    16528   bootcode.bin
       26   issue.txt
   314691   loader.bin
  2040392   arm128_start.elf
      124   cmdline.txt
  2040392   arm192_start.elf
  2040392   arm224_start.elf
  2040392   start.elf
   174840   kernel.img
      273   boot_enable_ssh.rc
  5948852   kernel_debug.img
      381   rpi.dtb
 16344532   kernel_emergency.img
  3936548   kernel.img.with-first-32k
  3903780   kernel.img-uncompressed
      405   kernel.dtb
       98   config.txt-kernel-plus-dtb

17 file(s), 0 dir(s)

U-Boot> fatload mmc 0:1 ${loadaddr} /kernel.img
reading /kernel.img

174840 bytes read

(I can repeat that as many times as I want; at least 7 times)

U-Boot> fatload mmc 0:1 ${loadaddr} /kernel_emergency.img
reading /kernel_emergency.img
Transfer data timeout
Error reading cluster

** Unable to read "/kernel_emergency.img" from mmc 0:1 **

(that happens every time)

=====

Also, trying a USB mass-storage device (actually, a USB SD card reader),
I get failures initializing USB:

Hit any key to stop autoboot:  0

U-Boot> usb start
(Re)start USB...
USB:   Core Release: 2.80a
scanning bus for devices... Error condition at line 650:  XACTERR
config descriptor too short (expected 9, got 0)
 ERROR: NOT USB_CONFIG_DESC 1
Error condition at line 650:  XACTERR
Error condition at line 650:  XACTERR
Error condition at line 650:  XACTERR
4 USB Device(s) found
       scanning bus for ethernet devices... 1 Ethernet Device(s) found

U-Boot> usb info
1: Hub,  USB Revision 1.10
 - DWC OTG RootHub
 - Class: Hub
 - PacketSize: 8  Configurations: 1
 - Vendor: 0x0000  Product 0x0000 Version 0.0
   Configuration: 1
   - Interfaces: 1 Self Powered 0mA
     Interface: 0
     - Alternate Setting 0, Endpoints: 1
     - Class Hub
     - Endpoint 1 In Interrupt MaxPacket 8 Interval 255ms

2: Hub,  USB Revision 2.0
 - Class: Hub
 - PacketSize: 64  Configurations: 1
 - Vendor: 0x0424  Product 0x9512 Version 2.0
   Configuration: 1
   - Interfaces: 1 Self Powered Remote Wakeup 2mA
     Interface: 0
     - Alternate Setting 0, Endpoints: 1
     - Class Hub
     - Endpoint 1 In Interrupt MaxPacket 1 Interval 255ms

3: Vendor specific,  USB Revision 2.0
 - Class: Vendor specific
 - PacketSize: 64  Configurations: 1
 - Vendor: 0x0424  Product 0xec00 Version 2.0
   Configuration: 1
   - Interfaces: 1 Self Powered Remote Wakeup 2mA
     Interface: 0
     - Alternate Setting 0, Endpoints: 3
     - Class Vendor specific
     - Endpoint 1 In Bulk MaxPacket 64
     - Endpoint 2 Out Bulk MaxPacket 64
     - Endpoint 3 In Interrupt MaxPacket 16 Interval 1ms

4: See Interface,  USB Revision 2.0
 - SanDisk Corp. SDDR-113 6333011111B1
 - Class: (from Interface) See Interface
 - PacketSize: 64  Configurations: 1
 - Vendor: 0x0781  Product 0xa7a8 Version 1.39
   Configuration: 0
   - Interfaces: 0 Bus Powered 0mA

U-Boot> fatls usb 0:1 /

** Invalid boot device **
U-Boot> fatls usb 4:1 /

** Invalid boot device **

=====

Without the USB SD card reader plugged in, USB initializes without errors:

U-Boot> usb start
(Re)start USB...
USB:   Core Release: 2.80a
scanning bus for devices... 3 USB Device(s) found
       scanning bus for ethernet devices... 1 Ethernet Device(s) found

although I didn't actually test the Ethernet after that this time.