On 17:34 Fri 31 Oct , 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->

why do you try to use the at91sam9263ek board on the AT91RM9200EK?

and the AT91RM9200EK is not so far from the AT91SAM9200DK which is mainline

and they are not so much different execept some PIO settings

IIRC Ulf send some patch 2 years ago

Maybe he can resend a rebased version?

Anyone building a linux kernel using buildroot (http://buildroot.uclibc.org/). will get my patches vs U-Boot 1.2.0.

Since the U-Boot community insists that the tested working flash driver cannot be merged in the std U-boot, and has to be replaced by the CFI driver which does not work on the EK (I am told) I have no plans to resubmit at this time.

Best Regards, J.

Best Regards Ulf Samuelsson ulf@atmel.com Atmel Nordic AB Mail: Box 2033, 174 02 Sundbyberg, Sweden Visit: Kavallerivägen 24, 174 58 Sundbyberg, Sweden Phone +46 (8) 441 54 22 Fax +46 (8) 441 54 29 GSM +46 (706) 22 44 57

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@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

Wolfgang Denk wrote:

Dear Martin Hejnfelt,

In message 490EA7C0.5050908@newtec.dk you wrote:

...

...

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

Why do you have to use this at all? Isn't the flash CFI conformant so the generic CFI flash driver would work?

Best regards,

Wolfgang Denk

I must say, I'm still really new to U-boot so I'm not sure if I my answer is the best method. The flash circuit is CFI compatible, but since I used the already made AT91RM9200 files and modified these, I found the problem easily and solved it this way. I will probably hit myself in the head in some months when my skills have improved :)

Mvh. / Best Regards

Martin Hejnfelt

Wolfgang Denk sez,

The thing is: we will not accept any such (new) code for mainline. And switching to using the CFI driver is trivial.

Okay so what I've learned.

1)You can build the AT91RM9200DK version of u-boot with u-boot-1.3.4 and it works. At least I got a prompt. So one can use the AT91RM9200DK as a starting point for the AT91RM9200EK.

2) At this point I think relying on any older patched version of u-boot that supports the AT91RM9200EK is probably not workable and not worth doing.

3) Anyone starting a project based on the AT91RM9200EK is making big mistake because the AT91RM9200 chip has been abandoned by its mother.

At least I have I have some sort of peg in the ground to start with. Right now I worry about trying to get the CFI to work because as a noob I'm in the dark on a lot of things

1) How to port the CFI to the AT91RM9200DK. 2) Create a board support for the AT91RM9200EK based on that. 3) Generate patches that are acceptable.

Personally I think that Atmel is doing people a disservice by not classifying the AT91RM9200 as not for new designs since there is no current support for it.

Matthew Harper. Tehama Wireless.

Dear Pink Boy,

In message 15593.6415.qm@web31812.mail.mud.yahoo.com you wrote:

At least I have I have some sort of peg in the ground to start with. Right now I worry about trying to get the CFI to work because as a noob I'm in the dark on a lot of things

If you're in the dark, you can still admire the many, many small stars that shine on you, while others who walk in the bright sunlight may feel warm and comfortable, but actually live in a somewhat poorer world :-)

1. How to port the CFI to the AT91RM9200DK.

There is nothing to port. You just enable it in the board config file. See for example the recent patch for the TQM8260 board. That's all you need to do.

2. Create a board support for the AT91RM9200EK based on that.
3. Generate patches that are acceptable.

If you use git, then all you need to do is using git-format-patch and git-send-email :-)

Personally I think that Atmel is doing people a disservice by not classifying the AT91RM9200 as not for new designs since there is no current support for it.

Well, they still want to sell those chips.

Best regards,

Wolfgang Denk

Dear Pink Boy,

In message 832725.42708.qm@web31815.mail.mud.yahoo.com you wrote:

Okay then. I was able to compile u-boot 1.3.4 for the AT91RM9200DK with changes so that it can handle writing to the flash on my custom board base don the AT91RM9200EK.

Great.

Seems to work but writes to flash are very slow...

You probably did not enable CONFIG_SYS_FLASH_USE_BUFFER_WRITE yet?

However it's a hack of the DK board. I will try over the next week or two to make a version of the AT91RM9200DK u-boot that uses the CFI driver. And then submit a patch for that.

Thanks in advance.

Best regards,

Wolfgang Denk