U-Boot USB support, status of omap3-dev-usb

Thanks to the work of Ragha and Steve, Beagle U-Boot USB development branch omap3-dev-usb

http://www.sakoman.net/cgi-bin/gitweb.cgi?p=u-boot-omap3.git;a=shortlog;h=refs/heads/omap3-dev-usb

is in sync with mainline again. There were some merge conflicts fixed by Ragha, so now we are able to sync against mainline again.

Now the question is how to go on?

Concentrate on mainline merge (e.g. bug fixing, coding style clean up, fix review comments)? Or adding additional features (e.g. adding ethernet support so user can do tftp boot)? Or?

What do you think?

Best regards

Dirk

I’m inclined to support getting what works now into the mainline before adding more features. any clean-up required?

I personally would love to see tftp boot.

+1

Ethernet boot + NFS based root filesystem, that would make it for some
real fast development.

-Ilyes

I personally would love to see tftp boot.

Yes, it will ease development.

I'd love to see the DFU patches[1] from Diego Dompe get into that git tree as well.

regards,

Koen

[1] http://cgit.openembedded.org/cgit.cgi/openembedded/tree/recipes/u-boot/files/omap-usb-dev-dfu.patch
[2] http://cgit.openembedded.org/cgit.cgi/openembedded/tree/recipes/u-boot/files/dfu-second-patch.patch

I agree to this, as there is a new USB device interface, similar to
Kernel, coming up there [1]

Regards,
-Ragha

[1] http://git.denx.de/?p=u-boot/u-boot-usb.git;a=shortlog;h=refs/heads/cdc

From: beagleboard@googlegroups.com
[mailto:beagleboard@googlegroups.com] On Behalf Of Dirk Behme
Sent: Friday, May 29, 2009 11:59 PM
To: beagleboard@googlegroups.com
Cc: Steve Sakoman; Khandenahally, Ragha
Subject: [beagleboard] U-Boot USB support, status of omap3-dev-usb

Thanks to the work of Ragha and Steve, Beagle U-Boot USB development
branch omap3-dev-usb

http://www.sakoman.net/cgi-bin/gitweb.cgi?p=u-boot-
omap3.git;a=shortlog;h=refs/heads/omap3-dev-usb

is in sync with mainline again. There were some merge conflicts fixed
by Ragha, so now we are able to sync against mainline again.

Now the question is how to go on?

Concentrate on mainline merge (e.g. bug fixing, coding style clean up,
fix review comments)? Or adding additional features (e.g. adding
ethernet support so user can do tftp boot)? Or?

Yes, yes, yes. I would like to see Ethernet support. I've used TFTP with
AVR32 and it make development so much more efficient.

Kind Regards,
John

> Concentrate on mainline merge (e.g. bug fixing, coding style clean up,
> fix review comments)? Or adding additional features (e.g. adding
> ethernet support so user can do tftp boot)? Or?
Yes, yes, yes. I would like to see Ethernet support. I've used TFTP with
AVR32 and it make development so much more efficient.

Agree - Main focus should be getting current status checked into official
mainline.

Secondly adding networking support would be great :slight_smile: One suggestion: Would
it be an easier path to make networking over USB than supporting all kind of
different USB2Ethernet chips? In that case we could use TFTP over USB?

Best regards
  Søren

Jason Kridner wrote:

I'm inclined to support getting what works now into the mainline before
adding more features. any clean-up required?

Clean up: Yes.

http://groups.google.com/group/beagleboard/browse_thread/thread/54f37fcd0b5b053b/165461d26e504557?lnk=gst&q=OMAP3%3A+Clean+up+coding+style#165461d26e504557

could be a starting point. It doesn't apply any more, though.

Tom Rix mentioned to help with mainline integration while working on
Zoom2, btw.

Best regards

Dirk

Over night I’ve been thinking about TFTP boot complexity… Seems to me there are some options here:

(1) uboot is aware of the various USB-Ethernet dongles and performs a real TFTP boot.
(2) uboot brings up a CDC gadget on the OTG port and performs TFTP boot over that.
(3) uboot brings up a custom USB device which the host sends a kernel to (similar to a USB Request Firmware)

I’m interested in (1) but that’s the most complicated and will potentially bloat u-boot or leave a few people in the dark because their Ethernet dongle wasn’t included. It also means real networking with cables and hubs rather than a direct USB connection to a developer’s PC.

People wanting faster development might be thinking of number (2). Having done something similar in userspace, this can be a little tricky to get working reliably…

(3) would probably the easiest to code, wouldn’t have the network stack overhead of (2) and could support cool features like “don’t boot yet, give me a uboot prompt”. But then this isn’t anything like real TFTP boot… but it would allow developers to do faster development…

Koen Kooi wrote:

Thanks to the work of Ragha and Steve, Beagle U-Boot USB development
branch omap3-dev-usb

http://www.sakoman.net/cgi-bin/gitweb.cgi?p=u-boot-omap3.git;a=shortlog;h=refs/heads/omap3-dev-usb

is in sync with mainline again. There were some merge conflicts fixed
by Ragha, so now we are able to sync against mainline again.

Now the question is how to go on?

I'd love to see the DFU patches[1] from Diego Dompe get into that git tree as well.

[1] doesn't apply any more to recent omap3-dev-usb. See below.

Once this is fixed, because of the size of that patch, I would vote for an omap3-dev-usb-dfu (== omap3-dev-usb + dfu patches).

Opinions?

Dirk

regards,

Koen

[1] http://cgit.openembedded.org/cgit.cgi/openembedded/tree/recipes/u-boot/files/omap-usb-dev-dfu.patch

[2] http://cgit.openembedded.org/cgit.cgi/openembedded/tree/recipes/u-boot/files/dfu-second-patch.patch

patching file drivers/serial/usbtty.c

patching file drivers/serial/usbtty.h

Hunk #1 succeeded at 82 (offset 2 lines).

can't find file to patch at input line 115

Perhaps you used the wrong -p or --strip option?

The text leading up to this was:

Over night I've been thinking about TFTP boot complexity... Seems to me
there are some options here:

(1) uboot is aware of the various USB-Ethernet dongles and performs a real
TFTP boot.
(2) uboot brings up a CDC gadget on the OTG port and performs TFTP boot over
that.
(3) uboot brings up a custom USB device which the host sends a kernel to
(similar to a USB Request Firmware)

I'm interested in (1) but that's the most complicated and will potentially
bloat u-boot or leave a few people in the dark because their Ethernet dongle
wasn't included. It also means real networking with cables and hubs rather
than a direct USB connection to a developer's PC.

People wanting faster development might be thinking of number (2). Having
done something similar in userspace, this can be a little tricky to get
working reliably...

(3) would probably the easiest to code, wouldn't have the network stack
overhead of (2) and could support cool features like "don't boot yet, give
me a uboot prompt". But then this isn't anything like real TFTP boot... but
it would allow developers to do faster development...

------

I am pretty sure I could achieve (1) within Linux - since linux can replace
a running kernel with a new one and effectively reboot into it. I'll have a
look at (1) next week as it might only need a couple of days development
effort.

The USB attached u-boot console would *really* interest me as it would make
field connections considerably easier (you know, and my home made cables
suck).

What do other people think...?

For me 1 is bringing usb host adapter knowledge into u-boot (unless I
misunderstood you).

Simplest solution is probably to let u-boot boot a small kernel which
then via kexecboot or so boots a kernel it gets from tftp.

FM

Exactly what I’m thinking… A cut down kernel and minimal embedded rootfs to do TFTP boot could probably even fit in the first NAND area (don’t remember the size off hand but I remember its pretty small…!). That would mean you could TFTP boot either just the kernel or the kernel and a rootfs - and all without needing an SD card in the BeagleBoard.

Being a security professional I’m also aware that TFTP/NFS network boot is rather insecure. That’s usually a problem when network card firmware is doing it all… The joy of this approach is that the code is entirely accessible and if you want to check a signature, or download from an SFTP server there’s nothing stopping you…

I really like this idea (and my brain is buzzing with lots of ideas) so will put some effort into it next week and post back. There may be some issues with double initialisation of BeagleBoard hardware by Linux. From what I’ve seen I’m not expecting anything serious - but I’m by no means an expert of the BB specific patches…

I got follow after patch DFU

I got follow after patch DFU

ERROR: usbd_alloc_urb(), 572: F A T A L: malloc(33068) FAILED!!!!
Board revision C
Serial #5ac400030000000004013f8901001001

Not knowing very much about DFU in u-boot, it seems like you have a failing
malloc-call
- Have your tried to increase your heap size in order for the malloc-call to
succeed?

Best regards
  Søren

Hi lecheel,

lecheel wrote:

I got follow after patch DFU

U-Boot 2009.01-00433-g6fc13bd-dirty (Jun 04 2009 -
13:39:59)

I2C:
ready
OMAP3530-GP rev 2, CPU-OPP2
L3-165MHz
OMAP3 Beagle board + LPDDR/
NAND
DRAM: 256
MB
NAND: 256
MiB
MUSB: using high
speed
mtdids not defined, no default
present
mtdids not defined, no default present
mtdids not defined, no default
present
mtdids not defined, no default present
ERROR: usbd_alloc_urb(), 572: F A T A L: malloc(33068) FAILED!!!!
In: serial
Out: serial
Err: serial
Board revision C
Serial #5ac400030000000004013f8901001001

there is impossible "setenv stdin usbtty, serial ",...

any hint

I'm not sure which U-Boot version and which DFU patches you use? Last time I tried DFU patches with recent omap3-dev-usb they didn't apply:

http://groups.google.com/group/beagleboard/msg/447f138d7fcd8892

Best regards

Dirk

Btw.: Please consider subscribing to BeagleBoard mailing list so that list moderator don't have to moderate your mails.

thanks Søren and Dirk
  the problem seems I forgot patch the dfu-second-patch
  after patch DFU is working happy on beagleboard

  right now don't know it's possible using dfu and ttyACM0 at the same
time

  after dfu-util download firmware ttyACM0 device still present but
usbtty over ttyACM0 not working anymore

Over night I’ve been thinking about TFTP boot complexity… Seems to me there are some options here:

(1) uboot is aware of the various USB-Ethernet dongles and performs a real TFTP boot.
(2) uboot brings up a CDC gadget on the OTG port and performs TFTP boot over that.
(3) uboot brings up a custom USB device which the host sends a kernel to (similar to a USB Request Firmware)

I’m interested in (1) but that’s the most complicated and will potentially bloat u-boot or leave a few people in the dark because their Ethernet dongle wasn’t included. It also means real networking with cables and hubs rather than a direct USB connection to a developer’s PC.

People wanting faster development might be thinking of number (2). Having done something similar in userspace, this can be a little tricky to get working reliably…

(3) would probably the easiest to code, wouldn’t have the network stack overhead of (2) and could support cool features like “don’t boot yet, give me a uboot prompt”. But then this isn’t anything like real TFTP boot… but it would allow developers to do faster development…

Hi Michael,

Did you make any progress on supporting TFTP in u-boot?

Kind Regards,

John

The latest U-Boot already has support for TFTP boot. However, so far as I’m aware its doesn’t support the BeagleBoard’s USB controller or the relevant USB ethernet dongles… Those could be copied across but I’ve not had a look yet.

I spent most of my time trying to get kexec to work… this would allow a really small linux kernel to boot, do the TFTP to download a new kernel and then boot it. It would also be a lot easier for people to tweak and modify (e.g. you want SFTP boot… sure… why not!) Sadly I’ve parked the kexec for the time being as I’ll need to take a look into the kernel source code and try and try and work out how to debug what’s going on…

I might take a look tomorrow at the latest U-Boot USB code (they have code for USB keyboard / storage device for example) and see what would be needed to either enable it for BeagleBoard or add some code to support the BeagleBoard’s USB controllers.

Mike