[U-Boot] Building u-boot for the AT91RM9200-EK circa 2008

[Martin Hejnfelt]

Pink Boy wrote:
> Hi, first post here.
>
> vis: Building u-boot for the AT91RM9200-EK circa 2008
>
> Is this still possible all things considered? It appears that 
> this board is left behind in a backwater sometime around 2006.
>
> Problem is I need to compile a new version of u-boot for my 
> new board based on the AT91RM9200 and I'm having a lot of trouble. 
> My board is very closely based on the AT91RM9200-EK, pretty much 
> the same except the flash has changed. So I need to modify u-boot 
> to handle the new flash (AT49BV642D). I'm running into real 
> problems, at least for a noob.
>
> On my board I can get two versions of u-boot to run, the 1.1.5 
> version that comes with the AT91RM9200 development kit. And an 
> ancient u-boot 1.1.1 that I got off Atmel's website which 
> surprisingly enough will write to the new flash chip I have 
> installed, even though it thinks there is only 2M installed 
> instead of 8M And I can use it to do setenv, etc and load 
> uboot 1.1.5 into flash and boot linux over the network connection.
>
> So far so good. So my hardware works, I just need a version of 
> u-boot that supports the AT49BV642D. Patching the source seems 
> easy enough. However. Problem is that the official distribution 
> of u-boot has no support for the AT91RM9200-EK. Which is sad. 
> Very very sad.
>
> I tried compiling u-boot from scratch using the instructions 
> on this page.
>
> http://www.linux4sam.org/twiki/bin/view ... _x_sources
>
> Namely,
> wget ftp://ftp.denx.de/pub/u-boot/u-boot-1.1.5.tar.bz2
> tar xvjf u-boot-1.1.5.tar.bz2
> cd u-boot-1.1.5
>
> wget ftp://www.linux4sam.org/pub/uboot/u-boo ... 5.diff.bz2
> bzcat u-boot-1.1.5_atmel_1.5.diff.bz2 | patch -p1
>
> Then
>
> I fixed up two lines in the examples make file adding an .o 
> at the end in order to make the 3.81 linker happy.
>
> Line 147 :
>   $(obj)%.srec: $(obj)%.o
> Line 150
>   $(obj)%.bin: $(obj)%.o
>
> Then
>
> make distclean
> make at91sam9263ek_config
> make CROSS_COMPILE=<path_to_cross-compiler/cross-compiler-prefix->
>
> Where my compiler is 
>    gcc version 3.4.3 (release) (CodeSourcery ARM Q1B 2005)
>
> I've also tried 
>    gcc version 4.1.1 (CodeSourcery ARM Sourcery G++ 2006q3-26)
>
> and 
>    gcc 4.1.1 from timesys.
>
> In each case I get a built version of u-boot.bin. However when 
> I download it the same way I use the other two wokring binaries
> of u-boot that I have it just hangs with no output.
>
> I've also tried gzipping it and trying to have boot.bin load it
> from flash, but it hangs as well.
>
> I also tried compiling with an old version of gcc 3.4.1 but it 
> wouldn't compile the source due to a compiler bug/issue.  Google
> indicates the error is due to the compiler assuming a hard fpu.
>
> Anyone have advice on how to proceed from here?
>
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
>
>   
This is pretty amazing, I *just* finished the exact same task, getting a 
AT91RM9200EK based custom board with AT49BV642D up and running with a 
new U-boot. Since the board files is based on using the AT49BV6416 which 
works almost just like the 642D, it isn't the hardest task getting the 
642D up and running, but the problem relies in the board specific 
flash.c file for the DK board. The difference is the ID that the two 
flash circuits respond with, 6416 responds with 00D6h and 642D responds 
with 01D6h, and in the flash.c file theres the FLASH_TYPEMASK which 
covers 0000FFFFh so for U-boot, the two flash circuits are NOT identical 
and therefore will not work (you'll just get unknown device). If you 
just want it up and running quick you can just add a second check in the 
part of the program where the program checks for the 6416 flash, so the 
IF statement also becomes true for a device_code of 01D6h. U-boot will 
then still report using the 6416, but it works flawlessly. You can then 
modify it to be a bit nicer by entering the rest of the information for 
the 642D, by just using the 6416 code as base. When I at some point 
figure out making these patches you all send around, I can send one, but 
since the 642D is not the original flash to be used with this board, I 
wouldn't think it's a good idea to put this into mainline, am I wrong?

Mvh. / Best Regards

Martin Hejnfelt