porting to custom at 91 board
Dear developers!
As some advised, instead of trying to write a boot loader for a custom AT91 board, I wanted to use the loader.bin and u-boot.bin from ATMEL.
However, after transferring loader.bin, the 'C'-s appear, however, I cannot transfer u-boot.bin, because Hyper terminal displays some "Error limit exceeded" message. (I've also tried with minicom, it gives a couple of NAK messages when transferring u-boot.bin).
What can be the error?
My board is more or less the same as at19rm9200dk, however it has only 1 chip of 16 bit SDRAM connected instead of 2 chips (so the data bus is only 16 bits wide, and memory timings are different). Can this cause a problem?
My alternate question is, how to port u-boot, so that I can start it in RAM with the above configuration (I've got a small boot loader done in assembly, which is loaded from SPI on startup. So I could store u-boot in the SPI flash, and load it to RAM from there on startup by my small boot loader. how to do this? eg. where to load the u-boot image in RAM? I guess I have to also adjust the SDRAM setup and timings which are differing from the atmel DK.). have anyone ported u-boot to such a configuration?
I'd be grateful if you could give me any pointers on this problem.
Best Regards,
Zo
Quoted 3 lines · In message <1100993019.6511.10.camel@localhost> you wrote:
As some advised, instead of trying to write a boot loader for a custom AT91 board, I wanted to use the loader.bin and u-boot.bin from ATMEL.
Even better just use U-Boot and forget about loader.bin ...
Quoted 8 lines
My alternate question is, how to port u-boot, so that I can start it in RAM with the above configuration (I've got a small boot loader done in assembly, which is loaded from SPI on startup. So I could store u-boot in the SPI flash, and load it to RAM from there on startup by my small boot loader. how to do this? eg. where to load the u-boot image in RAM? I guess I have to also adjust the SDRAM setup and timings which are differing from the atmel DK.). have anyone ported u-boot to such a configuration?
Instead of doing all this which is really non-trivial and also ineffficient you could just boot from flash. I've just checked in the necessary patches for the AT91RM9200DK and CMC_PU2 boards ...
Best regards,
Wolfgang Denk
Signature · 3 lines
Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de Thought for the day: What if there were no hypothetical situations?
Hi!
Quoted 4 lines
Quoted 2 lines
As some advised, instead of trying to write a boot loader for a custom AT91 board, I wanted to use the loader.bin and u-boot.bin from ATMEL.
Even better just use U-Boot and forget about loader.bin ...
ok, that wlll be easy :)
Quoted 9 lines
Quoted 8 lines
My alternate question is, how to port u-boot, so that I can start it in RAM with the above configuration (I've got a small boot loader done in assembly, which is loaded from SPI on startup. So I could store u-boot in the SPI flash, and load it to RAM from there on startup by my small boot loader. how to do this? eg. where to load the u-boot image in RAM? I guess I have to also adjust the SDRAM setup and timings which are differing from the atmel DK.). have anyone ported u-boot to such a configuration?
Quoted 3 lines
Instead of doing all this which is really non-trivial and also ineffficient you could just boot from flash. I've just checked in the necessary patches for the AT91RM9200DK and
CMC_PU2boards ...
What do you mean by booting from flash? Since I've got only an SPI flash connected, U-boot has to be taken apart, since the AT91 internal boot loader can only load 16KB of code from the flash into the internal processor SRAM. So what is needed is some code for the SPI flash, which boots the processor, and reads the rest of u-boot from the SPI flash into the initialized SDRAM.
Does booting from flash solve the SDRAM initialization problem? (I mean the SDRAM on my board needs worst case memory timings, and I guess the atmel DK memory setup code does not use worst case timings..)
Thank you all for your help.
Best regards:Zo
Quoted 6 lines · In message <1101030722.6343.6.camel@localhost> you wrote:
Quoted 4 lines
Instead of doing all this which is really non-trivial and also ineffficient you could just boot from flash. I've just checked in the necessary patches for the AT91RM9200DK and
CMC_PU2boards ...What do you mean by booting from flash? Since I've got only an SPI flash
I mean booting from the NOR flash attached to any halfway sane design.
Quoted 3 lines
connected, U-boot has to be taken apart, since the AT91 internal boot loader can only load 16KB of code from the flash into the internal processor SRAM. So what is needed is some code for the SPI flash, which
No - you are not restricted to booting from SPI DataFlash, and it's not 16 kB. The AT91RM9200 supports 3 boot methods:
1) Pulling the first 12 kilobytes of a SPI DataFlash memory part into internal SRAM and executing it.
2) If #1 fails, pulling the first 12 kilobytes of a serial I2C EEPROM into internal SRAM and executing it.
3) If #2 fails, executing code from an attached NOR flash device.
What we use is 3) as there is NOR flash on both the AT91RM9200DK and the CMC_PU2 boards, so this is the fastest way to boot a system.
If you don't have any nor flash, you should (1) complain at your hardware designers and (2) make sure that CONFIG_BOOTBINFUNC is _not_ defned in your board config file.
Quoted 4 lines
boots the processor, and reads the rest of u-boot from the SPI flash into the initialized SDRAM.
Does booting from flash solve the SDRAM initialization problem? (I mean
Yes, of course, because you can include regular initialization code for the memory controller.
Best regards,
Wolfgang Denk
Signature · 3 lines
Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de "Wagner's music is better than it sounds." - Mark Twain
Quoted 3 lines · Wolfgang Denk
Instead of doing all this which is really non-trivial and also ineffficient you could just boot from flash. I've just checked in the necessary patches for the AT91RM9200DK and
CMC_PU2boards ...
Am I supposed to rewrite my AT91RM9200 SoC patch then?
--
Steven
Quoted 6 lines · In message <[email protected]> you wrote:
Quoted 4 lines
Instead of doing all this which is really non-trivial and also ineffficient you could just boot from flash. I've just checked in the necessary patches for the AT91RM9200DK and
CMC_PU2boards ...Am I supposed to rewrite my AT91RM9200 SoC patch then?
Argh.. I knew that there was something pending.
Can you do it? Otherwise I will try (because it was my action that caused the problem), but this may take some time...
Best regards,
Wolfgang Denk
Signature · 4 lines
Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de What we anticipate seldom occurs; what we least expect generally happens. - Bengamin Disraeli
Quoted 6 lines · Wolfgang Denk
Quoted 4 lines · In message <[email protected]> you wrote:
Quoted 3 lines
Instead of doing all this which is really non-trivial and also ineffficient you could just boot from flash. I've just checked in the necessary patches for the AT91RM9200DK and
CMC_PU2boards ...
Quoted 7 lines
Quoted 1 line
Am I supposed to rewrite my AT91RM9200 SoC patch then?
Argh.. I knew that there was something pending.
Can you do it? Otherwise I will try (because it was my action that caused the problem), but this may take some time...
Are we talking about hours, days, month?
I first have to look what exactly you change.
But I'll try.
Signature · 1 line
Steven Scholz
Quoted 5 lines · In message <[email protected]> you wrote:
Quoted 3 lines
Can you do it? Otherwise I will try (because it was my action that caused the problem), but this may take some time...
Are we talking about hours, days, month?
Days or weeks.
Quoted 2 lines
I first have to look what exactly you change.
But I'll try.
Thanks. IOU a beer ...
Best regards,
Wolfgang Denk
Signature · 6 lines
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
The word "fit", as I understand it, means "appropriate to a purpose",
and I would say the body of the Dean is supremely appropriate to the
purpose of sitting around all day and eating big heavy meals.
- Terry Pratchett, _Moving Pictures_