[U-Boot-Users] AT91 Kernel oops when loading kernel from dataflash.
Raúl Sánchez Siles
rss at barracuda.es
Mon Nov 13 11:30:40 CET 2006
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
Dataflash 1st Bootloader
Parallel flash Kernel->RAM
This is the second scenario, all these test works:
Scenario 2 Stored in:
U-boot Parallel flash(1st position)
Now common to both scenarios the Rootfs can be arranged as explained below:
Scenario 1 | Scenario 2
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
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
Raúl Sánchez Siles
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
Url : http://lists.denx.de/pipermail/u-boot/attachments/20061113/7b74f68e/attachment.pgp
More information about the U-Boot