[U-Boot-Users] AT91 Kernel oops when loading kernel from dataflash.
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 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&da...
U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Best Regards, Ulf Samuelsson ulf@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
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.
- The dataflash blocksize is not 1024 bytes, it is 1056 bytes
- 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,
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,
participants (2)
-
Raúl Sánchez Siles -
Ulf Samuelsson