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?
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
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.
> 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 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?
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…
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.
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…
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?
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:
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?
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.