[U-Boot] U-Boot 2009.11.1 USB Issue and Building U-Boot 2013.07

First I am fairly new to U-Boot but over the last 2 weeks I have been going through the README files and anything else I can find that would help resolve the issue I have. Here is a recap:
Currently the project I am working on was setup with U-Boot 2009-11-01 and works just fine with one exception. I was asked to find a solution where our field support engineers could recover if a firmware update failed causing our board to no longer boot. Basically it cycles through RomBOOT and U-Boot. As I looked through the environment variables and commands I came across the USB subsystem and found I could use fatload. With our system there are three files I need to load from USB, these are uImage, etc.jff2 and rootfs.ext2.gz.uboot.
I found if I used tftp these files transferred correctly and the board would boot with the new files. I thought the solution was found and I could simply setup the same files using USB through environment variables. The script worked but the problem was when it tried to load rootfs into RAM it would cause a CPU reset and RomBOOT to start. At first I thought there was something wrong with the script so I tried to load the file by typing it the command but got the same result.
Command:
usb start
fatload usb 0 $(loadaddr) rootfs.ext2.gz.uboot where loadaddr is the same address used by tftp.
My first question is, is there a solution for this issue using U-Boot 2009.11.1? This version builds currently within our project.
Second question is I downloaded U-Boot 2013.07 but noticed huge change in the build process. I figured out the patches I need along with the AT91 configuration for our board. We are using the arm926ej6 processor with a board similar to at91sam9260ek. When I try to build I get the hardware.h:49:3 error: #error "Unsupported AT91 processor" message. When I look at the header file I see where it fails but I don't understand why since I do have a matching define. For some reason hardware.h is not seeing this define and I am stumped as to why. So any suggestions on how to solve or figure this out would be appreciated.
Thanks!
Chuck

Dear Chuck,
In message 002b01cea8e7$b14fc5b0$13ef5110$@amanomcgann.com you wrote:
I found if I used tftp these files transferred correctly and the board would boot with the new files. I thought the solution was found and I could simply setup the same files using USB through environment variables. The script worked but the problem was when it tried to load rootfs into RAM it would cause a CPU reset and RomBOOT to start. At first I thought there was something wrong with the script so I tried to load the file by typing it the command but got the same result.
Are you using the same load address in RAM with both the tftp and the fatload commands? Can you provide a complete console log of both the working and the crashing cases?
Command:
usb start
fatload usb 0 $(loadaddr) rootfs.ext2.gz.uboot where loadaddr is the same address used by tftp.
Please show the complete commands, and all output.
My first question is, is there a solution for this issue using U-Boot 2009.11.1? This version builds currently within our project.
We need to understand the problem beforeanybody could answer that...
Second question is I downloaded U-Boot 2013.07 but noticed huge change in the build process. I figured out the patches I need along with the AT91 configuration for our board. We are using the arm926ej6 processor with a board similar to at91sam9260ek. When I try to build I get the hardware.h:49:3 error: #error "Unsupported AT91 processor" message. When I look at the header file I see where it fails but I don't understand why since I do have a matching define. For some reason hardware.h is not seeing this define and I am stumped as to why. So any suggestions on how to solve or figure this out would be appreciated.
Well, 2009.11 is indeed extremely old. With such an out-of-tree port you are essentially lost. Adapting the old patches to current mainline is more or less the same effort as starting from scratch (and probably even more so).
Best regards,
Wolfgang Denk

Dear Chuck Wical,
On 09/03/2013 10:53 PM, Chuck Wical wrote:
First I am fairly new to U-Boot but over the last 2 weeks I have been going through the README files and anything else I can find that would help resolve the issue I have. Here is a recap:
Currently the project I am working on was setup with U-Boot 2009-11-01 and works just fine with one exception. I was asked to find a solution where our field support engineers could recover if a firmware update failed causing our board to no longer boot. Basically it cycles through RomBOOT and U-Boot. As I looked through the environment variables and commands I came across the USB subsystem and found I could use fatload. With our system there are three files I need to load from USB, these are uImage, etc.jff2 and rootfs.ext2.gz.uboot.
you could also use fatload on mmc. Do you have some mmc in your device?
I found if I used tftp these files transferred correctly and the board would boot with the new files. I thought the solution was found and I could simply setup the same files using USB through environment variables. The script worked but the problem was when it tried to load rootfs into RAM it would cause a CPU reset and RomBOOT to start. At first I thought there was something wrong with the script so I tried to load the file by typing it the command but got the same result.
I tested the 2009.11.1 release on my 9263ek here and can confirm, that the usb support there is really buggy. It doesn't support current storage devices, seems to behave differently every time I access the device (timeouts, ...). I managed however to load a 16MiB file via usb storage successfully.
Command:
usb start
fatload usb 0 $(loadaddr) rootfs.ext2.gz.uboot where loadaddr is the same address used by tftp.
That's in general correct.
My first question is, is there a solution for this issue using U-Boot 2009.11.1? This version builds currently within our project.
As these are my first steps with 2009.11.1 and usb storage I can't say it. You could backport current usb stack to have better support. On the other hand porting your board forward isn't that hard.
Second question is I downloaded U-Boot 2013.07 but noticed huge change in the build process. I figured out the patches I need along with the AT91 configuration for our board. We are using the arm926ej6 processor with a board similar to at91sam9260ek. When I try to build I get the hardware.h:49:3 error: #error "Unsupported AT91 processor" message. When I
HAve a look at 9260ek config, it is still in current releases and builds at least. I rarely test the built on real hardware, at the moment I only have an sam9263ek handy.
look at the header file I see where it fails but I don't understand why since I do have a matching define. For some reason hardware.h is not seeing this define and I am stumped as to why. So any suggestions on how to solve or figure this out would be appreciated.
If you plan to integrate your patches into mainline, we could help to adopt them where needed.
Best regards
Andreas Bießmann

Hello Andreas,
Thanks for the reply!
Dear Chuck Wical,
On 09/03/2013 10:53 PM, Chuck Wical wrote:
First I am fairly new to U-Boot but over the last 2 weeks I have been going through the README files and anything else I can find that would help resolve the issue I have. Here is a recap:
Currently the project I am working on was setup with U-Boot 2009-11-01 and works just fine with one exception. I was asked to find a solution where our field support engineers could recover if a firmware update failed causing our board to no longer boot. Basically it cycles through RomBOOT and U-Boot. As I looked through the environment variables and commands I came across the USB subsystem
and
found I could use fatload. With our system there are three files I need to load from USB, these are uImage, etc.jff2 and rootfs.ext2.gz.uboot.
you could also use fatload on mmc. Do you have some mmc in your device?
We do have mmc slots available on the board but U-Boot is not configured to use mmc. I don't know why that is as it would have made perfect sense to do so. In the meantime, I am trying to figure out how to enable mmc but running into a little difficulty. To put it simply, I just do not know where to enable it or where to look. I will keep trying but a little guidance would be very much appreciated.
I found if I used tftp these files transferred correctly and the board would boot with the new files. I thought the solution was found and I could simply setup the same files using USB through environment variables. The script worked but the problem was when it tried to load rootfs into RAM it would cause a CPU reset and RomBOOT to start. At first I thought there was something wrong with the script so I tried to load the file by typing it the command but got the same result.
I tested the 2009.11.1 release on my 9263ek here and can confirm, that the usb support there is really buggy. It doesn't support current storage
devices,
seems to behave differently every time I access the device (timeouts,
...).
I managed however to load a 16MiB file via usb storage successfully.
The size of file I am trying to load is <7MiB but with your comments above it makes me wonder if a timeout is occurring thus forcing the reboot.
Command:
usb start
fatload usb 0 $(loadaddr) rootfs.ext2.gz.uboot where loadaddr is the same address used by tftp.
That's in general correct.
My first question is, is there a solution for this issue using U-Boot 2009.11.1? This version builds currently within our project.
As these are my first steps with 2009.11.1 and usb storage I can't say it.
You
could backport current usb stack to have better support. On the other hand porting your board forward isn't that hard.
Second question is I downloaded U-Boot 2013.07 but noticed huge change in the build process. I figured out the patches I need along with the AT91 configuration for our board. We are using the arm926ej6 processor with a board similar to at91sam9260ek. When I try to build I get the hardware.h:49:3 error: #error "Unsupported AT91 processor" message. When I
HAve a look at 9260ek config, it is still in current releases and builds
at least. I
rarely test the built on real hardware, at the moment I only have an sam9263ek handy.
I will take a look and yes, we are using real hardware and I do not have access to a sam9263ek either.
look at the header file I see where it fails but I don't understand why since I do have a matching define. For some reason hardware.h is not seeing this define and I am stumped as to why. So any suggestions on how to solve or figure this out would be appreciated.
If you plan to integrate your patches into mainline, we could help to
adopt
them where needed.
I have no plans to incorporate the patches into mainline as they seem very specific to our board and configuration.
Best regards
Andreas Bießmann
Cheers
Chuck Wical
participants (4)
-
Andreas Bießmann
-
Chuck Wical
-
Jens Scharsig
-
Wolfgang Denk