[Buildroot] How is the RM9200 status of buildroot ?

[Buildroot] How is the RM9200 status of buildroot ?

[Jonathan Dumaresq]

Hi all,

 

I juste started my new custom board and the cpu seem to work. I would like
to start building my root file system and my file system. I would like to
know if the buildroot for the RM9200 is working or I have to use something
else ?

 

Regards

 

Jonathan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://busybox.net/lists/buildroot/attachments/20080108/87ac7dde/attachment.htm 

[Buildroot] How is the RM9200 status of buildroot ?

[Ulf Samuelsson]

> Hi all,
> 
> 
> 
> I juste started my new custom board and the cpu seem to work. I would like
> to start building my root file system and my file system. I would like to
> know if the buildroot for the RM9200 is working or I have to use something
> else ?
> 
> 
> 
> Regards
> 
> 
> 
> Jonathan
> 

Since I introduced the AT91RM9200 support I should answer.

The goal of the AT91RM9200 buildroot was to get 
AT45DB642 dataflash supported properly.

If your board is using a parallel flash, there will be some limitations.
Default configurations for linux won't work (but you can easily create your own)
The U-Boot version has never been tested with recent parallel flash.
There is no at91bootstrap/dataflashboot, so you have to rely
on U-Boot to copy itself to SDRAM, not hard but not tested.

Buildroot contains applications which run and others which doesn't,
so you have to figure out why.
Some applications will run using the uclibc toolchain built by buildroot,
and others will only run if you use an external glibc based toolchain.

To get a basic system running is very easy, compared to other build systems I tested.

Twas some time since I loaded the AT91RM9200 on a target, since
I mostly spend time on the AT91SAM926x nowadays,
but if you find a problem, they can usually be fixed quite fast.


Best Regards
Ulf Samuelsson

[Buildroot] How is the RM9200 status of buildroot ?

[Joe]

We're using a custom RM9200 board (parallel flash) also with buildroot, 
and i would like to specify some of the "limitations" Ulf mentioned if 
on parallel flash:

- Kernel won't work created by buildroot. We've moved to build one using 
the buildroot toolchain, sources are vanilla + the victor patches + some 
small fixes concerning the PHY
- U-Boot is the same, but for you are on a custom board, you'll always 
have to "tune" the bootloader, i think.
- I would suggest to stick with the OABI. We've given EABI more than 
just a try and kept running into a whole lotta trouble.
- Most "standard apps" will work: bash, busybox, gcc - for evereything 
else, we compile in-target here.

Hope that  helps a little, Joe

-- 
Sepp "ZaP" Holzmayr

please reply to:
zentrale.at.work at gmail.com

watch out for:
www.rocksociety.de

[Buildroot] How is the RM9200 status of buildroot ?

[Ulf Samuelsson]

----- Original Message ----- 
From: "Joe" <zentrale.at.work@gmail.com>
To: <buildroot@uclibc.org>
Sent: Wednesday, January 09, 2008 8:35 AM
Subject: Re: [Buildroot] How is the RM9200 status of buildroot ?


> We're using a custom RM9200 board (parallel flash) also with buildroot, 
> and i would like to specify some of the "limitations" Ulf mentioned if 
> on parallel flash:
> 
> - Kernel won't work created by buildroot. We've moved to build one using 
> the buildroot toolchain, sources are vanilla + the victor patches + some 
> small fixes concerning the PHY

If you want to have your board supported, then I suggest that you
provide the patches neccessary.

Please note that you can easily create your own board support by doing:

$ make configurated
then you edit the different configuration files.
$ make saveconfig

Your project configuration files are then saved in "local/<project>"

By making "local" a symbolic link, you can share it between 
different instances of buildroot.


> - U-Boot is the same, but for you are on a custom board, you'll always 
> have to "tune" the bootloader, i think.
> - I would suggest to stick with the OABI. We've given EABI more than 
> just a try and kept running into a whole lotta trouble.
> - Most "standard apps" will work: bash, busybox, gcc - for evereything 
> else, we compile in-target here.
> 
> Hope that  helps a little, Joe
> 


Best Regards
Ulf Samuelsson                ulf at 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

[Buildroot] How is the RM9200 status of buildroot ?

[Joe]

The board is currently under heavy development, so i don't want to send 
out stuff that will be obsolete for sure in days or some months at best. 
But we will of course feed our patches back to the community once it's 
done, everythings working fine and looking good :-)

Greetz, Joe

> If you want to have your board supported, then I suggest that you
> provide the patches neccessary.
> 
> Please note that you can easily create your own board support by doing:
> 
> $ make configurated
> then you edit the different configuration files.
> $ make saveconfig
> 
> Your project configuration files are then saved in "local/<project>"
> 
> By making "local" a symbolic link, you can share it between 
> different instances of buildroot.

-- 
Sepp "ZaP" Holzmayr

please reply to:
zentrale.at.work at gmail.com

watch out for:
www.rocksociety.de

[Buildroot] How is the RM9200 status of buildroot ?

[Jonathan Dumaresq]

I would like to thanks you guys to point me to the right thing. 

Here a little bit of information about our board.

CPU = RM9200
FLASH = AT49BV642D connected in a 16bit data bus SDRAM = 2 x
MT48LC8M16A2P-7E from Micron Technology. We have 2 SDRAM connected in
parallel with 16 bits databus. I think we based this design on the dk board
supplies by atmel. 

Since a relatively new to all of the arm9 cpu + linux, I think I will have
some fun to get all of this working :)

I would like to know if it is possible to do some basinc testing on my board
to know if my memories setup is working correctly before going to far with
linux etc. ? I have acces to a jtag interface if this can help. 

Regards

Jonathan

-----Message d'origine-----
De?: buildroot-bounces at uclibc.org [mailto:buildroot-bounces at uclibc.org] De
la part de Ulf Samuelsson
Envoy??: 8 janvier 2008 18:00
??: buildroot at uclibc.org
Objet?: Re: [Buildroot] How is the RM9200 status of buildroot ?


> Hi all,
> 
> 
> 
> I juste started my new custom board and the cpu seem to work. I would like
> to start building my root file system and my file system. I would like to
> know if the buildroot for the RM9200 is working or I have to use something
> else ?
> 
> 
> 
> Regards
> 
> 
> 
> Jonathan
> 

Since I introduced the AT91RM9200 support I should answer.

The goal of the AT91RM9200 buildroot was to get 
AT45DB642 dataflash supported properly.

If your board is using a parallel flash, there will be some limitations.
Default configurations for linux won't work (but you can easily create your
own)
The U-Boot version has never been tested with recent parallel flash.
There is no at91bootstrap/dataflashboot, so you have to rely
on U-Boot to copy itself to SDRAM, not hard but not tested.

Buildroot contains applications which run and others which doesn't,
so you have to figure out why.
Some applications will run using the uclibc toolchain built by buildroot,
and others will only run if you use an external glibc based toolchain.

To get a basic system running is very easy, compared to other build systems
I tested.

Twas some time since I loaded the AT91RM9200 on a target, since
I mostly spend time on the AT91SAM926x nowadays,
but if you find a problem, they can usually be fixed quite fast.


Best Regards
Ulf Samuelsson
_______________________________________________
buildroot mailing list
buildroot at uclibc.org
http://busybox.net/mailman/listinfo/buildroot

[Buildroot] How is the RM9200 status of buildroot ?

[Joe]

> I would like to know if it is possible to do some basinc testing on my board
> to know if my memories setup is working correctly before going to far with
> linux etc. ? I have acces to a jtag interface if this can help. 

Sure. First thing ist to get your U-Boot working and fitted to your 
System, for it does the whole hardware init concerning low level 
memories. If it's working fine, you should give the mems some test, 
especially boundaries of the SDs are of interest. Booting on its own and 
  having a fuly functional u-boot should the give you a good start for 
linux.

Greetz Joe

-- 
Sepp "ZaP" Holzmayr

please reply to:
zentrale.at.work at gmail.com

watch out for:
www.rocksociety.de

[Buildroot] How is the RM9200 status of buildroot ?

[Ulf Samuelsson]

I would like to thanks you guys to point me to the right thing. 

Here a little bit of information about our board.

CPU = RM9200
FLASH = AT49BV642D connected in a 16bit data bus
SDRAM = 2 x MT48LC8M16A2P-7E from Micron Technology. We have 2 SDRAM
connected in parallel with 16 bits databus. I think we based this design on
the dk board supplies by atmel. 

Since a relatively new to all of the arm9 cpu + linux, I think I will have
some fun to get all of this working :)

I would like to know if it is possible to do some basinc testing on my board
to know if my memories setup is working correctly before going to far with
linux etc. ? I have acces to a jtag interface if this can help. 

==> Traditionally, the process of getting an AT91RM9200 to run from a 
        parallel flash is to set BMS high to boot from the bootROM,
        Download "loader.bin" using X-Modem to the internal SRAM,
        "loader.bin" will start a new x-modem session and you use this
        to download "boot.bin", which gets programmed into the first sector
        of the parallel flash.
        You will then program the u-boot.gz into a nearby sector of the flash.

        After a reset, the board will execute "boot.bin" which will 
        decompress u-boot.gz into SDRAM and jump to the start of the U-boot.

        You will need to check with your local contact to get source of "loader.bin"
        and "boot.bin". They were originally compiled by gcc-2.95.3 and
        using gcc-3.x.x does not work as far as I know.
        I am not aware of anyone trying with gcc-4.x.x.

        boot.bin/loader.bin binaries might work, but they were written for
        the somewhat compatible AT49BV6416.

        There is not a lot of support from Atmel on booting the AT91SAM926x chips
        from a parallel flash, but many customers has succeeded in getting
        them to run anyway.
        Hopefully, next generation of AT91Bootstrap will support parallel flash,
        but the AT91RM9200 is not supported at all by the bootstrap.

        Why parallel flash in the first place???
        
        Please be aware that the AT91RM9200DK has some critical flaws.
        The AT91RM9200EK was designed to get rid of those flaws.
        Again, discuss with your local Atmel FAE to have your schematics reviewed.

Best Regards
Ulf Samuelsson

[Buildroot] How is the RM9200 status of buildroot ?

[Jonathan Dumaresq]

Great information ulf,

I already have my board in hand. I done some basic testing with a jtag
interface with openocd. I can talk to the cpu this is a good news in some
way. Then I try to talk to the flash and got some response. So I think I'm
in good position to continue testing my board. 

What I will do next is to try to use the jtag interface and write to sdram. 

As for why we use parallel flash ... I' don't know. I have access to sd
memory also. This can be a good thing ? 

I think we based our design on the EK board. I will have to talk about this
to the engineer that builds up the schematics. 

Again, 

I'll appreciate your information.

Jonathan

-----Message d'origine-----
De?: Ulf Samuelsson [mailto:ulf at atmel.com] 
Envoy??: 9 janvier 2008 13:27
??: Jonathan Dumaresq; buildroot at uclibc.org
Objet?: Re: [Buildroot] How is the RM9200 status of buildroot ?

I would like to thanks you guys to point me to the right thing. 

Here a little bit of information about our board.

CPU = RM9200
FLASH = AT49BV642D connected in a 16bit data bus
SDRAM = 2 x MT48LC8M16A2P-7E from Micron Technology. We have 2 SDRAM
connected in parallel with 16 bits databus. I think we based this design on
the dk board supplies by atmel. 

Since a relatively new to all of the arm9 cpu + linux, I think I will have
some fun to get all of this working :)

I would like to know if it is possible to do some basinc testing on my board
to know if my memories setup is working correctly before going to far with
linux etc. ? I have acces to a jtag interface if this can help. 

==> Traditionally, the process of getting an AT91RM9200 to run from a 
        parallel flash is to set BMS high to boot from the bootROM,
        Download "loader.bin" using X-Modem to the internal SRAM,
        "loader.bin" will start a new x-modem session and you use this
        to download "boot.bin", which gets programmed into the first sector
        of the parallel flash.
        You will then program the u-boot.gz into a nearby sector of the
flash.

        After a reset, the board will execute "boot.bin" which will 
        decompress u-boot.gz into SDRAM and jump to the start of the U-boot.

        You will need to check with your local contact to get source of
"loader.bin"
        and "boot.bin". They were originally compiled by gcc-2.95.3 and
        using gcc-3.x.x does not work as far as I know.
        I am not aware of anyone trying with gcc-4.x.x.

        boot.bin/loader.bin binaries might work, but they were written for
        the somewhat compatible AT49BV6416.

        There is not a lot of support from Atmel on booting the AT91SAM926x
chips
        from a parallel flash, but many customers has succeeded in getting
        them to run anyway.
        Hopefully, next generation of AT91Bootstrap will support parallel
flash,
        but the AT91RM9200 is not supported at all by the bootstrap.

        Why parallel flash in the first place???
        
        Please be aware that the AT91RM9200DK has some critical flaws.
        The AT91RM9200EK was designed to get rid of those flaws.
        Again, discuss with your local Atmel FAE to have your schematics
reviewed.

Best Regards
Ulf Samuelsson

[Buildroot] How is the RM9200 status of buildroot ?

[Jonathan Dumaresq]

Hi,

Since this board was designed some time ago, we have choose to use the
rm9200 because we already have some test board with this chip. This is only
for educational purpose. So we wan to explore how an arm9 work. Debugging
methode etc. 

So if we go into a commercial project, we will probably use the AVR32. Bu
this sould be the same process of debugging .

Again 

I'll appreciate your valuable information

Jonathan

-----Message d'origine-----
De?: Ulf Samuelsson [mailto:ulf.samuelsson at atmel.com] 
Envoy??: 9 janvier 2008 18:58
??: Jonathan Dumaresq; buildroot at uclibc.org
Objet?: Re: [Buildroot] How is the RM9200 status of buildroot ?

Great information ulf,

I already have my board in hand. I done some basic testing with a jtag
interface with openocd. I can talk to the cpu this is a good news in some
way. Then I try to talk to the flash and got some response. So I think I'm
in good position to continue testing my board. 

What I will do next is to try to use the jtag interface and write to sdram. 

As for why we use parallel flash ... I' don't know. I have access to sd
memory also. This can be a good thing ? 

==> You should look at the Atmel website for dataflash = AT45DB642D.
        Also, choosing the AT91RM9200 at this point of time may be a mistake
        The AT91SAM9260 has about the same functionality,
        fixes some bugs, and is cheaper.
        The BootROM has a failsafe mode, which I am really fond of (I
defined it :-)
        There will be a pin compatible part (AT91SAM9260A) running at 400
MHz.
        Samples are going to be shipped to a few customers about now, rest
        of the customers has to wait.
        There is also a pin compatible flash version AT91SAM92XE 
        (First ARM flash microcontroller at 200 MHz?)    - Available real
soon now...

        The only reason to start designing with the AT91RM9200 is that
        you want to have the ETM (Embedded Trace Module) or you
        are interested in the lower power consumption of the ARM920T
hardcore
        in the AT91RM9200 compared to the ARM926EJ-S in the AT91SAM9260.
        The AT91RM9200 also have a few more I/O pins than the SAM9260 due
        to its 256 BGA package compared to the 217 BGA in the SAM9260.

        This is my personal opinion, (as I usually indicate in the
signature)
        Both AT91RM9200 and the SAM9260 will be produced for a long time
        so availability has nothing to do with the decision.




I think we based our design on the EK board. I will have to talk about this
to the engineer that builds up the schematics. 

Again, 

I'll appreciate your information.

Jonathan

-----Message d'origine-----
De : Ulf Samuelsson [mailto:ulf at atmel.com] 
Envoy? : 9 janvier 2008 13:27
? : Jonathan Dumaresq; buildroot at uclibc.org
Objet : Re: [Buildroot] How is the RM9200 status of buildroot ?

I would like to thanks you guys to point me to the right thing. 

Here a little bit of information about our board.

CPU = RM9200
FLASH = AT49BV642D connected in a 16bit data bus
SDRAM = 2 x MT48LC8M16A2P-7E from Micron Technology. We have 2 SDRAM
connected in parallel with 16 bits databus. I think we based this design on
the dk board supplies by atmel. 

Since a relatively new to all of the arm9 cpu + linux, I think I will have
some fun to get all of this working :)

I would like to know if it is possible to do some basinc testing on my board
to know if my memories setup is working correctly before going to far with
linux etc. ? I have acces to a jtag interface if this can help. 

==> Traditionally, the process of getting an AT91RM9200 to run from a 
        parallel flash is to set BMS high to boot from the bootROM,
        Download "loader.bin" using X-Modem to the internal SRAM,
        "loader.bin" will start a new x-modem session and you use this
        to download "boot.bin", which gets programmed into the first sector
        of the parallel flash.
        You will then program the u-boot.gz into a nearby sector of the
flash.

        After a reset, the board will execute "boot.bin" which will 
        decompress u-boot.gz into SDRAM and jump to the start of the U-boot.

        You will need to check with your local contact to get source of
"loader.bin"
        and "boot.bin". They were originally compiled by gcc-2.95.3 and
        using gcc-3.x.x does not work as far as I know.
        I am not aware of anyone trying with gcc-4.x.x.

        boot.bin/loader.bin binaries might work, but they were written for
        the somewhat compatible AT49BV6416.

        There is not a lot of support from Atmel on booting the AT91SAM926x
chips
        from a parallel flash, but many customers has succeeded in getting
        them to run anyway.
        Hopefully, next generation of AT91Bootstrap will support parallel
flash,
        but the AT91RM9200 is not supported at all by the bootstrap.

        Why parallel flash in the first place???
        
        Please be aware that the AT91RM9200DK has some critical flaws.
        The AT91RM9200EK was designed to get rid of those flaws.
        Again, discuss with your local Atmel FAE to have your schematics
reviewed.

Best Regards
Ulf Samuelsson



Best Regards
Ulf Samuelsson                ulf at 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

Technical support when I am not available:
AT90 AVR Applications Group: mailto:avr at atmel.com
AT91 ARM Applications Group: mailto:at91support at atmel.com
AVR32 Applications Group        mailto:avr32 at atmel.com
http://www.avrfreaks.net/;            http://avr32linux.org/
http://www.at91.com/ ;                ftp://at91dist:distrib at 81.80.104.162/

[Buildroot] How is the RM9200 status of buildroot ?

[Jorge S.]

On Jan 10, 2008 3:57 PM, Jonathan Dumaresq <jdumaresq@cimeq.qc.ca> wrote:

> Hi,
>
> Since this board was designed some time ago, we have choose to use the
> rm9200 because we already have some test board with this chip. This is
> only
> for educational purpose. So we wan to explore how an arm9 work. Debugging
> methode etc.
>
> So if we go into a commercial project, we will probably use the AVR32. Bu
> this sould be the same process of debugging .
>
> Again
>
> I'll appreciate your valuable information
>
> Jonathan
>
> -----Message d'origine-----
> De: Ulf Samuelsson [mailto:ulf.samuelsson at atmel.com]
> Envoy?: 9 janvier 2008 18:58
> ?: Jonathan Dumaresq; buildroot at uclibc.org
> Objet: Re: [Buildroot] How is the RM9200 status of buildroot ?
>
> Great information ulf,
>
> I already have my board in hand. I done some basic testing with a jtag
> interface with openocd. I can talk to the cpu this is a good news in some
> way. Then I try to talk to the flash and got some response. So I think I'm
> in good position to continue testing my board.
>
> What I will do next is to try to use the jtag interface and write to
> sdram.
>
> As for why we use parallel flash ... I' don't know. I have access to sd
> memory also. This can be a good thing ?
>
> ==> You should look at the Atmel website for dataflash = AT45DB642D.
>        Also, choosing the AT91RM9200 at this point of time may be a
> mistake
>        The AT91SAM9260 has about the same functionality,
>        fixes some bugs, and is cheaper.
>        The BootROM has a failsafe mode, which I am really fond of (I
> defined it :-)
>        There will be a pin compatible part (AT91SAM9260A) running at 400
> MHz.
>        Samples are going to be shipped to a few customers about now, rest
>        of the customers has to wait.
>        There is also a pin compatible flash version AT91SAM92XE
>        (First ARM flash microcontroller at 200 MHz?)    - Available real
> soon now...
>
>        The only reason to start designing with the AT91RM9200 is that
>        you want to have the ETM (Embedded Trace Module) or you
>        are interested in the lower power consumption of the ARM920T
> hardcore
>        in the AT91RM9200 compared to the ARM926EJ-S in the AT91SAM9260.
>        The AT91RM9200 also have a few more I/O pins than the SAM9260 due
>        to its 256 BGA package compared to the 217 BGA in the SAM9260.
>
>        This is my personal opinion, (as I usually indicate in the
> signature)
>        Both AT91RM9200 and the SAM9260 will be produced for a long time
>        so availability has nothing to do with the decision.
>
>
 Hi All,

  I've had some bad expecirences using the AT91RM9200 on a custom board:

  1) Unable to boot from parallel flash, so you have to use an external
eeprom if you want to use a parallel flash
    or end up using an SPI Dataflash as i did (see problem 2)

  2) When using SPI Dataflash on CS0 you have to use the bit-bang kernel
driver instead of the SPI hardware, because of
     another problem on the CS that can cause random operations on the
dataflash and end up ruining your filesystem.
     There's no clear workaround for this problem, some say it works when
slowing down the SPI, some other say that it
     still fails even when its running slow, and so on.

  3) I managed to get buildroot working on a JFFS2 filesystem after
looooooooots of problems with the default atmel configs, so
     i did my own config.


  Hope this info is useful for somebody...

  Now my questions:


  I'm now facing a new project that requires the develpment of a new custom
board but i don't want to use the
  AT91RM9200 again (enough is enough) so i'm doing some investigation on the
AT91SAM926x family.

  Questions:

    - Is buildroot working OK for the AT91SAM926x? Any 1st hand experience?
I'm talking only about the toolchain+utilities
          part of buildroot (i usually build kernel and u-boot appart from
buildroot)

   - The RM9200 was having an errata on the ROM bootloader not allowing you
to boot from a parallel dataflash, according to the AT91SAM9260 datasheet,
theres an errata on the SAM9260 too, that leads to the same problem...unable
to boot from parallel flash. So the only workaround i see is to use a SPI
dataflash to boot, and an additional parallel flash for the rootfs (i need
more than 8MiB).

  - (Maybe this is a kernel-list question) Again, based on experience... Do
you guys know if the kernel is supporting "well" the main peripherals?
   or are there any "pending" issues related to hardware erratas? I need
SPI, I2C, USB (host), Ethernet and maybe some GPIO pins that look like
supported when taking a look at the kernel patches... any useful "warning"
here? I don't want to face again the same problems on the RM9200 :(.

        - Any "cheap" development board, like the KB920x for the AT91RM9200?



 Thanks in advance, and sorry for some off-topic question.


 Regards,
 Jorge.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://busybox.net/lists/buildroot/attachments/20080112/7ebf1416/attachment.htm 

[Buildroot] How is the RM9200 status of buildroot ?

[Ulf Samuelsson]

 Hi All,

  I've had some bad expecirences using the AT91RM9200 on a custom board:

  1) Unable to boot from parallel flash, so you have to use an external
eeprom if you want to use a parallel flash
    or end up using an SPI Dataflash as i did (see problem 2)

==> That is a misunderstanding of the datasheet.
        You can boot from a 16 bit parallel flash, if BMS is low.
        If BMS is high (and the internal bootROM is used) the part
        will not find any parallel flash.
        Both the AT91RM9200DK and AT91RM9200EK boot from parallel flash.

  2) When using SPI Dataflash on CS0 you have to use the bit-bang kernel
driver instead of the SPI hardware, because of
     another problem on the CS that can cause random operations on the
dataflash and end up ruining your filesystem.
     There's no clear workaround for this problem, some say it works when
slowing down the SPI, some other say that it
     still fails even when its running slow, and so on.

==> The problem is that if the PDC (DMA) does not get any cycles,
        NPCS0 will go high until the PDC has made its memory access, 
        breaking a transfer into two, causing confusion at the other end of the SPI.

        The workaround is to either reduce the speed to < 5 Mbps
        or ensure that the NPCS0 remains low by using external glue logic.
        The speed reduction needs to be done in all parts of the system,
        I.E: dataflashboot, U-boot and linux.

  3) I managed to get buildroot working on a JFFS2 filesystem after
looooooooots of problems with the default atmel configs, so
     i did my own config.

==> If you find a problem, it makes sense to feed them back.

  Hope this info is useful for somebody...

  Now my questions:


  I'm now facing a new project that requires the develpment of a new custom
board but i don't want to use the
  AT91RM9200 again (enough is enough) so i'm doing some investigation on the
AT91SAM926x family.

  Questions:

    - Is buildroot working OK for the AT91SAM926x? Any 1st hand experience?
I'm talking only about the toolchain+utilities
          part of buildroot (i usually build kernel and u-boot appart from
buildroot)

==> You can get a running toolchain.
        A lot of the applications will build, but not all.
        Do not expect Buildroot to build a running X-Windows.

   - The RM9200 was having an errata on the ROM bootloader not allowing you
to boot from a parallel dataflash, according to the AT91SAM9260 datasheet,
theres an errata on the SAM9260 too, that leads to the same problem...unable
to boot from parallel flash. So the only workaround i see is to use a SPI
dataflash to boot, and an additional parallel flash for the rootfs (i need
more than 8MiB).

==> The AT91SAM9260 rev A, will not be able to boot from NAND flash.
        You can boot from SPI dataflash or external parallel flash.
        As in the RM9200, you have to pull BMS low to boot from the par flash.

        There is no S/W support from Atmel for boot from parallel flash yet.
        I hope it will be there during mid spring.
        Still a lot of customers are using parallel flash with the part using 
        the normal flash support in U-boot.

  - (Maybe this is a kernel-list question) Again, based on experience... Do
you guys know if the kernel is supporting "well" the main peripherals?
   or are there any "pending" issues related to hardware erratas? I need
SPI, I2C, USB (host), Ethernet and maybe some GPIO pins that look like
supported when taking a look at the kernel patches... any useful "warning"
here? I don't want to face again the same problems on the RM9200 :(.

==> USB host - OK.
        Ethernet - Use internal SRAM for buffers, if you plan to strangle the bus
        with 16 bit operation or run the bus at slow speed.
        SPI:    The AT91RM9200 problem is gone.
                   At high speeds, you can get a problem with SPI overruns on receive.
                   I have seen this at customers when the SPI is using 60% of the available 
                   bandwidth on the bus.
                   Often, an SPI transfer is only using data in a single direction, and if you do an SPI read,
                    then it might be good to get the send data from the internal SRAM.
                    If you do an SPI send, then it might make sense to write the data to 
                    an internal part of the chip (like "/dev/null"), instead of writing to the
                    SDRAM and then discarding it.
                  There is a discussion going on at this point of time, and 
                  you should check out the ARM linux mailing list.

        I2C, The jury is still out on this, and some get it to work and some doesn't.
                The vanilla driver is polling the I2C and this could cause problems.
                I have customers using interrupt driven I2C and they say 
                that they do not have any issues.

        - Any "cheap" development board, like the KB920x for the AT91RM9200?

==> If you start a development now, then you may want to consider getting
        the AT91SAM9260A (or AT91SAM9G20 as will be its new name)
        Pin compatible, 400 MHz, and will have larger FIFO for Ethernet.
        There is one less USART and one more I2C.
        


==> Check out www.olimex.com


 Thanks in advance, and sorry for some off-topic question.


 Regards,
 Jorge.



Best Regards
Ulf Samuelsson 

[Buildroot] How is the RM9200 status of buildroot ?

[Jorge S.]

Ulf, thanks for your interesting reply.

On Jan 12, 2008 5:19 PM, Ulf Samuelsson <ulf@atmel.com> wrote:

>
>  Hi All,
>
>  I've had some bad expecirences using the AT91RM9200 on a custom board:
>
>  1) Unable to boot from parallel flash, so you have to use an external
> eeprom if you want to use a parallel flash
>    or end up using an SPI Dataflash as i did (see problem 2)
>
> ==> That is a misunderstanding of the datasheet.
>        You can boot from a 16 bit parallel flash, if BMS is low.
>        If BMS is high (and the internal bootROM is used) the part
>        will not find any parallel flash.
>        Both the AT91RM9200DK and AT91RM9200EK boot from parallel flash.


Of course, you are right, i didnt mean "no parallel flash" at all.

>
>
>  2) When using SPI Dataflash on CS0 you have to use the bit-bang kernel
> driver instead of the SPI hardware, because of
>     another problem on the CS that can cause random operations on the
> dataflash and end up ruining your filesystem.
>     There's no clear workaround for this problem, some say it works when
> slowing down the SPI, some other say that it
>     still fails even when its running slow, and so on.
>
> ==> The problem is that if the PDC (DMA) does not get any cycles,
>        NPCS0 will go high until the PDC has made its memory access,
>        breaking a transfer into two, causing confusion at the other end of
> the SPI.
>
>        The workaround is to either reduce the speed to < 5 Mbps
>        or ensure that the NPCS0 remains low by using external glue logic.
>        The speed reduction needs to be done in all parts of the system,
>        I.E: dataflashboot, U-boot and linux.


Maybe its my fault here, but i didn't success when trying to slow down the
SPI speed, i modified my custom board definition
file on the kernel, but it doesn't work, it always says "5Mbps". I've also
received feedback from people who was having the same
issue that reported fails even when spi is going slower than 5Mbps.

Any example here?


>
>
>  3) I managed to get buildroot working on a JFFS2 filesystem after
> looooooooots of problems with the default atmel configs, so
>     i did my own config.
>
> ==> If you find a problem, it makes sense to feed them back.


I did on the mailing list.

>
>
>  Hope this info is useful for somebody...
>
>  Now my questions:
>
>
>  I'm now facing a new project that requires the develpment of a new custom
> board but i don't want to use the
>  AT91RM9200 again (enough is enough) so i'm doing some investigation on
> the
> AT91SAM926x family.
>
>  Questions:
>
>    - Is buildroot working OK for the AT91SAM926x? Any 1st hand experience?
> I'm talking only about the toolchain+utilities
>          part of buildroot (i usually build kernel and u-boot appart from
> buildroot)
>
> ==> You can get a running toolchain.
>        A lot of the applications will build, but not all.
>        Do not expect Buildroot to build a running X-Windows.


Good news for me,  i don't need X-Windows or any gfx at the moment.

>
>
>   - The RM9200 was having an errata on the ROM bootloader not allowing you
> to boot from a parallel dataflash, according to the AT91SAM9260 datasheet,
> theres an errata on the SAM9260 too, that leads to the same
> problem...unable
> to boot from parallel flash. So the only workaround i see is to use a SPI
> dataflash to boot, and an additional parallel flash for the rootfs (i need
> more than 8MiB).
>
> ==> The AT91SAM9260 rev A, will not be able to boot from NAND flash.
>        You can boot from SPI dataflash or external parallel flash.
>        As in the RM9200, you have to pull BMS low to boot from the par
> flash.
>
>        There is no S/W support from Atmel for boot from parallel flash
> yet.
>        I hope it will be there during mid spring.
>        Still a lot of customers are using parallel flash with the part
> using
>        the normal flash support in U-boot.


Nah, nevermind, dataflash  is  cheap,  i can afford a dataflash+NAND combo,
i choose the easy way.

>
>
>  - (Maybe this is a kernel-list question) Again, based on experience... Do
> you guys know if the kernel is supporting "well" the main peripherals?
>   or are there any "pending" issues related to hardware erratas? I need
> SPI, I2C, USB (host), Ethernet and maybe some GPIO pins that look like
> supported when taking a look at the kernel patches... any useful "warning"
> here? I don't want to face again the same problems on the RM9200 :(.
>
> ==> USB host - OK.
>        Ethernet - Use internal SRAM for buffers, if you plan to strangle
> the bus
>        with 16 bit operation or run the bus at slow speed.
>        SPI:    The AT91RM9200 problem is gone.
>                   At high speeds, you can get a problem with SPI overruns
> on receive.
>                   I have seen this at customers when the SPI is using 60%
> of the available
>                   bandwidth on the bus.
>                   Often, an SPI transfer is only using data in a single
> direction, and if you do an SPI read,
>                    then it might be good to get the send data from the
> internal SRAM.
>                    If you do an SPI send, then it might make sense to
> write the data to
>                    an internal part of the chip (like "/dev/null"),
> instead of writing to the
>                    SDRAM and then discarding it.
>                  There is a discussion going on at this point of time, and
>                  you should check out the ARM linux mailing list.
>
>        I2C, The jury is still out on this, and some get it to work and
> some doesn't.
>                The vanilla driver is polling the I2C and this could cause
> problems.
>                I have customers using interrupt driven I2C and they say
>                that they do not have any issues.
>
>        - Any "cheap" development board, like the KB920x for the
> AT91RM9200?
>
> ==> If you start a development now, then you may want to consider getting
>        the AT91SAM9260A (or AT91SAM9G20 as will be its new name)
>        Pin compatible, 400 MHz, and will have larger FIFO for Ethernet.
>        There is one less USART and one more I2C.
>
>
>
> ==> Check out www.olimex.com


Board ordered,  that's  what  i was looking for! ,  thanks again  Ulf,  i
really appreciate  your  help.


And , another question: Any working OEM wifi (802.11x) for the AT91SAM?  I
know i can use USB (i did it on the RM9200 board), but i think usb is not
really an industrial solution, i need something "hardwired" on the PCB.


Thank you again, your support is really helpful.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://busybox.net/lists/buildroot/attachments/20080114/cbe09475/attachment-0001.htm 

[Buildroot] How is the RM9200 status of buildroot ?

[Ulf Samuelsson]

> Ulf, thanks for your interesting reply.
> 
> On Jan 12, 2008 5:19 PM, Ulf Samuelsson <ulf@atmel.com> wrote:
> 
>>
>>  Hi All,
>>
>>  I've had some bad expecirences using the AT91RM9200 on a custom board:
>>
>>  1) Unable to boot from parallel flash, so you have to use an external
>> eeprom if you want to use a parallel flash
>>    or end up using an SPI Dataflash as i did (see problem 2)
>>
>> ==> That is a misunderstanding of the datasheet.
>>        You can boot from a 16 bit parallel flash, if BMS is low.
>>        If BMS is high (and the internal bootROM is used) the part
>>        will not find any parallel flash.
>>        Both the AT91RM9200DK and AT91RM9200EK boot from parallel flash.
> 
> 
> Of course, you are right, i didnt mean "no parallel flash" at all.
> 
>>
>>
>>  2) When using SPI Dataflash on CS0 you have to use the bit-bang kernel
>> driver instead of the SPI hardware, because of
>>     another problem on the CS that can cause random operations on the
>> dataflash and end up ruining your filesystem.
>>     There's no clear workaround for this problem, some say it works when
>> slowing down the SPI, some other say that it
>>     still fails even when its running slow, and so on.
>>
>> ==> The problem is that if the PDC (DMA) does not get any cycles,
>>        NPCS0 will go high until the PDC has made its memory access,
>>        breaking a transfer into two, causing confusion at the other end of
>> the SPI.
>>
>>        The workaround is to either reduce the speed to < 5 Mbps
>>        or ensure that the NPCS0 remains low by using external glue logic.
>>        The speed reduction needs to be done in all parts of the system,
>>        I.E: dataflashboot, U-boot and linux.
> 
> 
> Maybe its my fault here, but i didn't success when trying to slow down the
> SPI speed, i modified my custom board definition
> file on the kernel, but it doesn't work, it always says "5Mbps". I've also
> received feedback from people who was having the same
> issue that reported fails even when spi is going slower than 5Mbps.
> 
> Any example here?

This may be kernel version dependent since 2.6.19 or so.
People have been playing around with the SPI driver.

The 5 Mbps limit came from a customer which had heavy networking
going on, including WLAN on a slow Compactflash interface.
The problem occurs if you have many busmasters active at the same time.
This was in 2004.
I have modified my dataflashboot and U-boot and to limit speed
and people testing this says that it seems to work.

>>
>>  3) I managed to get buildroot working on a JFFS2 filesystem after
>> looooooooots of problems with the default atmel configs, so
>>     i did my own config.
>>
>> ==> If you find a problem, it makes sense to feed them back.
> 
> 
> I did on the mailing list.
> 

OK, some emails gets forgotten...

>>
>>
>>  Hope this info is useful for somebody...
>>
>>  Now my questions:
>>
>>
>>  I'm now facing a new project that requires the develpment of a new custom
>> board but i don't want to use the
>>  AT91RM9200 again (enough is enough) so i'm doing some investigation on
>> the
>> AT91SAM926x family.
>>
>>  Questions:
>>
>>    - Is buildroot working OK for the AT91SAM926x? Any 1st hand experience?
>> I'm talking only about the toolchain+utilities
>>          part of buildroot (i usually build kernel and u-boot appart from
>> buildroot)
>>
>> ==> You can get a running toolchain.
>>        A lot of the applications will build, but not all.
>>        Do not expect Buildroot to build a running X-Windows.
> 
> 
> Good news for me,  i don't need X-Windows or any gfx at the moment.
> 
>>
>>
>>   - The RM9200 was having an errata on the ROM bootloader not allowing you
>> to boot from a parallel dataflash, according to the AT91SAM9260 datasheet,
>> theres an errata on the SAM9260 too, that leads to the same
>> problem...unable
>> to boot from parallel flash. So the only workaround i see is to use a SPI
>> dataflash to boot, and an additional parallel flash for the rootfs (i need
>> more than 8MiB).
>>
>> ==> The AT91SAM9260 rev A, will not be able to boot from NAND flash.
>>        You can boot from SPI dataflash or external parallel flash.
>>        As in the RM9200, you have to pull BMS low to boot from the par
>> flash.
>>
>>        There is no S/W support from Atmel for boot from parallel flash
>> yet.
>>        I hope it will be there during mid spring.
>>        Still a lot of customers are using parallel flash with the part
>> using
>>        the normal flash support in U-boot.
> 
> 
> Nah, nevermind, dataflash  is  cheap,  i can afford a dataflash+NAND combo,
> i choose the easy way.
> 

Wise decision!

>>
>>
>>  - (Maybe this is a kernel-list question) Again, based on experience... Do
>> you guys know if the kernel is supporting "well" the main peripherals?
>>   or are there any "pending" issues related to hardware erratas? I need
>> SPI, I2C, USB (host), Ethernet and maybe some GPIO pins that look like
>> supported when taking a look at the kernel patches... any useful "warning"
>> here? I don't want to face again the same problems on the RM9200 :(.
>>
>> ==> USB host - OK.
>>        Ethernet - Use internal SRAM for buffers, if you plan to strangle
>> the bus
>>        with 16 bit operation or run the bus at slow speed.
>>        SPI:    The AT91RM9200 problem is gone.
>>                   At high speeds, you can get a problem with SPI overruns
>> on receive.
>>                   I have seen this at customers when the SPI is using 60%
>> of the available
>>                   bandwidth on the bus.
>>                   Often, an SPI transfer is only using data in a single
>> direction, and if you do an SPI read,
>>                    then it might be good to get the send data from the
>> internal SRAM.
>>                    If you do an SPI send, then it might make sense to
>> write the data to
>>                    an internal part of the chip (like "/dev/null"),
>> instead of writing to the
>>                    SDRAM and then discarding it.
>>                  There is a discussion going on at this point of time, and
>>                  you should check out the ARM linux mailing list.
>>
>>        I2C, The jury is still out on this, and some get it to work and
>> some doesn't.
>>                The vanilla driver is polling the I2C and this could cause
>> problems.
>>                I have customers using interrupt driven I2C and they say
>>                that they do not have any issues.
>>
>>        - Any "cheap" development board, like the KB920x for the
>> AT91RM9200?
>>
>> ==> If you start a development now, then you may want to consider getting
>>        the AT91SAM9260A (or AT91SAM9G20 as will be its new name)
>>        Pin compatible, 400 MHz, and will have larger FIFO for Ethernet.
>>        There is one less USART and one more I2C.
>>
>>
>>
>> ==> Check out www.olimex.com
> 
> 
> Board ordered,  that's  what  i was looking for! ,  thanks again  Ulf,  i
> really appreciate  your  help.
> 
> 
> And , another question: Any working OEM wifi (802.11x) for the AT91SAM?  I
> know i can use USB (i did it on the RM9200 board), but i think usb is not
> really an industrial solution, i need something "hardwired" on the PCB.
> 

There is some work beeing done with SDIO for the AT91SAM9260.
Do not have any status though.

> 
> Thank you again, your support is really helpful.
>



Best Regards
Ulf Samuelsson

[Buildroot] How is the RM9200 status of buildroot ?

[Thomas Lundquist]

On Sat, Jan 12, 2008 at 02:28:20PM +0100, Jorge S. wrote:
> 
>     - Is buildroot working OK for the AT91SAM926x? Any 1st hand experience?
> I'm talking only about the toolchain+utilities
>           part of buildroot (i usually build kernel and u-boot appart from
> buildroot)

I got buildroot running on a 9261-EK when it was released. The kernel
patches wasn't really ready but we had what we needed then. This is over
a year ago and before Ulf started working on buildroot.

That was with Qtopia and also one with TinyX (6.8).

I am quite sure you'll get it working.



Thomas.