[U-Boot-Users] AT91 Kernel oops when loading kernel from dataflash.

[U-Boot-Users] AT91 Kernel oops when loading kernel from dataflash.

[Raúl Sánchez Siles]

  Hello all:

  This is the first time I write to the list, and I appreciate the big help it 
gives us users.

  We're using an AT91RM9200 based board called Portux920T. We have now a quite 
stable kernel and u-boot configuration which I attach. We manage to include a 
dataflash inside the portux board and get it to work. At least almost, please 
read on.

  When doing big transfers in memory (10M), we have some kernel oopses(see 
panic.log.zip attached). The oops comes up in the function __wake_up_common 
in the file kernel/sched.c

  The steps to reproduce this are the following:

  1- Start the first bootloader (used the binary provided by atmel).
  2- Make the first bootloader start u-boot(1.1.6).
  3- U-boot downloads kernel(2.6.18) from _dataflash_ into RAM.
  4- Rest of booting till shell prompt.
  5- Execute for example: dd if=/dev/zero of=/root/borrar bs=1k count=10k
  6- Oops!

  If we substitute step 3 for U-boot downloads kernel from _parallel flash_ 
into RAM, the Oops won't happen. 

  The kernel has been patched with the latest maxim(2.6.18) patchset for the 
AT91RM9200 microcontroller. The u-boot configuration is also attached 
(portux920T.h).

  We have also tried using different first stage bootloaders we could find. 
Even we compile it ourselves using the RAM initialisation code taken from the 
u-boot. We also have tested several toolchains, from emdebian to the one 
provided by portux.

  We have 64MB Ram and we have tried using 64MB 32bit wide and 32MB 16bit 
wide. Flash and Dataflash are both 4MB.
  We will much appreciated whatever info or test that could take out from this 
works but... situation. Thank you very much.

  Regards,


-- 
Ra?l S?nchez Siles
-------------- next part --------------
A non-text attachment was scrubbed...
Name: config-2.6.18.2.gz
Type: application/x-gzip
Size: 7586 bytes
Desc: not available
Url : http://lists.denx.de/pipermail/u-boot/attachments/20061108/b6633d0a/attachment.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: portux920T.h.gz
Type: application/x-gzip
Size: 3064 bytes
Desc: not available
Url : http://lists.denx.de/pipermail/u-boot/attachments/20061108/b6633d0a/attachment-0001.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: panic.log.gz
Type: application/x-gzip
Size: 6518 bytes
Desc: not available
Url : http://lists.denx.de/pipermail/u-boot/attachments/20061108/b6633d0a/attachment-0002.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.denx.de/pipermail/u-boot/attachments/20061108/b6633d0a/attachment.pgp 

[U-Boot-Users] AT91 Kernel oops when loading kernel from dataflash.

[Ulf Samuelsson]

Ra?l S?nchez Siles wrote:
>   Hello all:
>
>   This is the first time I write to the list, and I appreciate the
> big help it gives us users.
>
>   We're using an AT91RM9200 based board called Portux920T. We have
> now a quite stable kernel and u-boot configuration which I attach. We
> manage to include a dataflash inside the portux board and get it to
> work. At least almost, please read on.
>
>   When doing big transfers in memory (10M), we have some kernel
> oopses(see panic.log.zip attached). The oops comes up in the function
> __wake_up_common in the file kernel/sched.c
>
>   The steps to reproduce this are the following:
>
>   1- Start the first bootloader (used the binary provided by atmel).
>   2- Make the first bootloader start u-boot(1.1.6).
>   3- U-boot downloads kernel(2.6.18) from _dataflash_ into RAM.
>   4- Rest of booting till shell prompt.
>   5- Execute for example: dd if=/dev/zero of=/root/borrar bs=1k
>   count=10k 6- Oops!

You do not say that you are loading a ramdisk.
Do you have the file system in dataflash?
If not, I do not see how this can be influenced by the dd command...
If it is, then the 4 MB flash seems small for a 10 MB copy!

I can see two scenarios where the dataflash can cause problems.

1) The dataflash blocksize is not 1024 bytes, it is 1056 bytes
2) You are running the dataflash > 5 Mbps
    The PDC of the SPI must not be starved of bus cycles,
    or you are in trouble unless the H/W manages chipselect through GP I/O.

I would try

$ dd if=/dev/zero of=/root/borrar bs=1056 count=10k

to start with, abnd if this works, start digging.


>
>   If we substitute step 3 for U-boot downloads kernel from _parallel
> flash_ into RAM, the Oops won't happen.
>
>   The kernel has been patched with the latest maxim(2.6.18) patchset
> for the AT91RM9200 microcontroller. The u-boot configuration is also
> attached (portux920T.h).
>
>   We have also tried using different first stage bootloaders we could
> find. Even we compile it ourselves using the RAM initialisation code
> taken from the u-boot. We also have tested several toolchains, from
> emdebian to the one provided by portux.
>
>   We have 64MB Ram and we have tried using 64MB 32bit wide and 32MB
> 16bit wide. Flash and Dataflash are both 4MB.
>   We will much appreciated whatever info or test that could take out
> from this works but... situation. Thank you very much.
>
>   Regards,
>
>
>
>> -------------------------------------------------------------------------
>> Using Tomcat but need to do more? Need to support web services,
>> security? Get stuff done quickly with pre-integrated technology to
>> make your job easier Download IBM WebSphere Application Server
>> v.1.0.1 based on Apache Geronimo
>> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
>
>
>
>> _______________________________________________
>> U-Boot-Users mailing list
>> U-Boot-Users at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/u-boot-users

Best Regards,
Ulf Samuelsson
ulf at atmel.com
GSM:  +46 (706) 22 44 57
Tel:     +46  (8) 441 54 22
Fax:     +46 (8) 441 54 29
Mail: Box 2033  174 02 Sundbyberg
Visit: Kavalleriv?gen 24
          174 58 Sundbyberg'
Sweden

[U-Boot-Users] AT91 Kernel oops when loading kernel from dataflash.

[Raúl Sánchez Siles]

El Jueves, 9 de Noviembre de 2006 08:02, Ulf Samuelsson escribi?:
> Ra?l S?nchez Siles wrote:
> >   Hello all:
> >
> >   We're using an AT91RM9200 based board called Portux920T. We have
> > now a quite stable kernel and u-boot configuration which I attach. We
> > manage to include a dataflash inside the portux board and get it to
> > work. At least almost, please read on.
> >
>
> You do not say that you are loading a ramdisk.
> Do you have the file system in dataflash?

  You are right, sorry. On this test case we are not using initrd, since the 
rootfs is on an MMC card formated with ext3.

> If not, I do not see how this can be influenced by the dd command...
> If it is, then the 4 MB flash seems small for a 10 MB copy!
>
> I can see two scenarios where the dataflash can cause problems.
>
> 1) The dataflash blocksize is not 1024 bytes, it is 1056 bytes
> 2) You are running the dataflash > 5 Mbps
>     The PDC of the SPI must not be starved of bus cycles,
>     or you are in trouble unless the H/W manages chipselect through GP I/O.
>
> I would try
>
> $ dd if=/dev/zero of=/root/borrar bs=1056 count=10k
>
> to start with, abnd if this works, start digging.
I am afraid that in this situation where dataflash is not used once the board 
is started, the blocksize wouldn't need to make a difference.

BTW we tried that dd command and crashed as well.

> >   The kernel has been patched with the latest maxim(2.6.18) patchset
> > for the AT91RM9200 microcontroller. The u-boot configuration is also
> > attached (portux920T.h).
> >
> >   We have also tried using different first stage bootloaders we could
> > find. Even we compile it ourselves using the RAM initialisation code
> > taken from the u-boot. We also have tested several toolchains, from
> > emdebian to the one provided by portux.
> >
> >   We have 64MB Ram and we have tried using 64MB 32bit wide and 32MB
> > 16bit wide. Flash and Dataflash are both 4MB.
> >   We will much appreciated whatever info or test that could take out
> > from this works but... situation. Thank you very much.
> >
> >   Regards,

  Reviewing my last e-mail I notice a mistake. I tried to send a graphic, but 
according the list rules, it is not allowed. So instead I try to explain it 
with some ascii art ;).
  
  This is the first scenario, where several configurations are tested. This 
scenario does not work.

Stored in:        Scenario 1
  (or)                (Problems)

Dataflash        1st Bootloader

Dataflash         U-boot
Serial port

Dataflash
Parallel flash    Kernel->RAM
Serial port
NFS

This is the second scenario, all these test works:

Scenario 2            Stored in:
  (Works)

U-boot                 Parallel flash(1st position)

Kernel->Ram       Dataflash
                            Parallel flash
                            Serial port
                            NFS

Now common to both scenarios the Rootfs can be arranged as explained below:

                Scenario 1    |    Scenario 2
----------------------ROOTFS----------------------------------
Flash->initrd(ext2)  |   MMC(ext3 or reiserfs)  |  NFS *

*(didn't fail in any case AFAIK)


  Every scenario has its variables on the left for the 1st scenario and on the 
right for the 2nd. The 1st doesn't work, the 2nd works always. The variables 
means that we have tried that option, i.e.: Copying kernel to ram downloading 
it from dataflash, parallel flash, etc..

  The lower part means the root filesystem layout. In the case I exposed, the 
rootfs was on an MMC card formatted with ext3. But we also tried other 
possibilities, but these are common to both scenarios, on 1st didn't work, on 
2nd it worked. Take into account that in this case, once the system is 
running, AFAIK, we are not accessing the kernel or u-boot downloading source 
(i.e.: dataflash, flash).

  When I say work, I mean dd is successful. We have also tried several dd 
cases.

  Looking at this scheme, one could think that the problem is on the 1st stage 
bootloader. We have tried the binary provided by atmel, several others 
binaries seen on the internet, we have compiled it ourselves using u-boot 
initialisation routines, or without them.

  I hope this explanation is clarifying enough, so anyone could give us 
further info.

  Regards,

-- 
Ra?l S?nchez Siles
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.denx.de/pipermail/u-boot/attachments/20061113/7b74f68e/attachment.pgp 

[U-Boot-Users] AT91 Kernel oops when loading kernel from dataflash.

[Raúl Sánchez Siles]

El Lunes, 13 de Noviembre de 2006 11:30, escribi?:
> El Jueves, 9 de Noviembre de 2006 08:02, Ulf Samuelsson escribi?:
> > Ra?l S?nchez Siles wrote:
> > >   Hello all:
> > >
> > >   We're using an AT91RM9200 based board called Portux920T. We have
> > > now a quite stable kernel and u-boot configuration which I attach. We
> > > manage to include a dataflash inside the portux board and get it to
> > > work. At least almost, please read on.
> >
> > >
> > >   We have 64MB Ram and we have tried using 64MB 32bit wide and 32MB
> > > 16bit wide. Flash and Dataflash are both 4MB.
> > >   We will much appreciated whatever info or test that could take out
> > > from this works but... situation. Thank you very much.
> > >
> > >   Regards,
>
>   Looking at this scheme, one could think that the problem is on the 1st
> stage bootloader. We have tried the binary provided by atmel, several
> others binaries seen on the internet, we have compiled it ourselves using
> u-boot initialisation routines, or without them.

...And indeed it was on the first stage bootloader. There was a problem with 
the SDRAMC Configuration Register. The problem was that the bootloader we 
took were for boards using 16MB of RAM, 16bit wide, while the Portux board 
has 2 32MB chips, 16bit wide each one.

  We modified the 1st bootloader source, so that the SDRAMC_CR programming 
changes the NR (Number of Row bits) from 12 to 13. That was the problem.

  If anyone needs further clarification, just ask.

  Thank you for the advises.

  Regards,

-- 
Ra?l S?nchez Siles
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.denx.de/pipermail/u-boot/attachments/20061115/590ff1d0/attachment.pgp