[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