[U-Boot-Users] Booting from NAND Flash Problems

[U-Boot-Users] Booting from NAND Flash Problems

[Daniel Laird]

I am working on a  board that has a mips processor and only Nand Flash.

This creates a problem as u-boot cannot be run directly from Nand Flash as
only the first 16K of Nand flash can be read by a processor without a Nand
Flash Driver.

This means that a small program has to run first.  This small program is <
16K in size and copies U-Boot from Nand Flash into RAM and then executes it.

In theory this should work fine.

bootprom loads micro bootloader.
bootloader loads u-boot
u-boot starts and relocates itself 
u-boot starts running.

However i am having loads of issues with running u-boot with cache enabled. 
If cache is enabled then the Nand Driver (I am using the latest Linux MTD
based driver)
has problems as it uses a DMA copy to copy to the Nand Flash.
If I implement cache flushing I break u-boot.

This is because it starts to flush the cache when reading the environment
that is located in Nand Flash the problem is that the relocation seems to
have not completed so the stack that is in Cache locked addresses goes wrong
(PCI fails to work).

If I try to run u-boot uncached I fail as well.

I was wondering if anyone has any hints or tips on how u-boot is used in a
system with only Nand Flash and a Mips processor.
I have seen other posts suggesting mips processors should run uncached but
this is obviously slower.
Has the case been consider where relocation is not necessary i.e a small
program just loads the executable to a location and runs it.  I know
relocation can save memory but in my system it means extra copying and
currently extra headaches!!

Hope some people can help
cheers
dan



--
View this message in context: http://www.nabble.com/Booting-from-NAND-Flash-Problems-t1637982.html#a4436349
Sent from the Uboot - Users forum@Nabble.com.

[U-Boot-Users] Booting from NAND Flash Problems

[Wolfgang Denk]

In message <4436349.post@talk.nabble.com> you wrote:
> 
> This means that a small program has to run first.  This small program is <
> 16K in size and copies U-Boot from Nand Flash into RAM and then executes it.
> 
> In theory this should work fine.

This works fine in practice for a couple of systems.

> However i am having loads of issues with running u-boot with cache enabled. 
> If cache is enabled then the Nand Driver (I am using the latest Linux MTD
> based driver)
> has problems as it uses a DMA copy to copy to the Nand Flash.
> If I implement cache flushing I break u-boot.

Then your port of U-Boot is broken.

> I was wondering if anyone has any hints or tips on how u-boot is used in a
> system with only Nand Flash and a Mips processor.

I don;t see anything in your setup where using NAND flash or  a  MIPS
CPU plays a role; all this is pretty similar on all architectures.

> I have seen other posts suggesting mips processors should run uncached but
> this is obviously slower.

Define "run uncached".

> Has the case been consider where relocation is not necessary i.e a small

Yes.

> program just loads the executable to a location and runs it.  I know
> relocation can save memory but in my system it means extra copying and
> currently extra headaches!!

Then don't do it.

And BTW: Relocation does not save memory at all. 

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
The ultimate barrier is one's viewpoint.
                        - Terry Pratchett, _The Dark Side of the Sun_

[U-Boot-Users] Booting from NAND Flash Problems

[Frank]

--- Daniel Laird <danieljlaird@hotmail.com> wrote:

> 
> I am working on a  board that has a mips processor and only
> Nand Flash.
> 
> This creates a problem as u-boot cannot be run directly from
> Nand Flash as
> only the first 16K of Nand flash can be read by a processor
> without a Nand
> Flash Driver.
> 
> This means that a small program has to run first.  This small
> program is <
> 16K in size and copies U-Boot from Nand Flash into RAM and
> then executes it.
> 
> In theory this should work fine.
> 
> bootprom loads micro bootloader.
> bootloader loads u-boot
> u-boot starts and relocates itself 
> u-boot starts running.
> 
> However i am having loads of issues with running u-boot with
> cache enabled. 
> If cache is enabled then the Nand Driver (I am using the
> latest Linux MTD
> based driver)
> has problems as it uses a DMA copy to copy to the Nand Flash.
> If I implement cache flushing I break u-boot.
> 
> This is because it starts to flush the cache when reading the
> environment
> that is located in Nand Flash the problem is that the
> relocation seems to
> have not completed so the stack that is in Cache locked
> addresses goes wrong
> (PCI fails to work).
> 
> If I try to run u-boot uncached I fail as well.
> 
> I was wondering if anyone has any hints or tips on how u-boot
> is used in a
> system with only Nand Flash and a Mips processor.
> I have seen other posts suggesting mips processors should run
> uncached but
> this is obviously slower.
> Has the case been consider where relocation is not necessary
> i.e a small
> program just loads the executable to a location and runs it. 
> I know
> relocation can save memory but in my system it means extra
> copying and
> currently extra headaches!!
> 
> Hope some people can help
> cheers
> dan

I had a similar problem with the AMD AU1500 SOC (mips32 core).
The relocation was copying the code to ram but the instructions
were being cached in data cache since it was just a data copy
(although the data was really instructions). 
I solved the problem by invaildating the instruction cache after
the copy but before jumping to the relocated code. This fixed my
problem.
Don't know if this your problem, but it might give you a clue...

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

[U-Boot-Users] Booting from NAND Flash Problems

[Daniel Laird]

In message <4436349.post@talk.nabble.com> you wrote:
>> 
>> This means that a small program has to run first.  This small program is
>> <
>> 16K in size and copies U-Boot from Nand Flash into RAM and then executes
>> it.
>> 
>> In theory this should work fine.
>
>This works fine in practice for a couple of systems.
Cool!

>> However i am having loads of issues with running u-boot with cache
>> enabled. 
>> If cache is enabled then the Nand Driver (I am using the latest Linux MTD
>> based driver)
>> has problems as it uses a DMA copy to copy to the Nand Flash.
>> If I implement cache flushing I break u-boot.
>>
>Then your port of U-Boot is broken.
I appreciate the port of u-boot it broken but let me just elaborate a little
more.
I am using the standard mips code i.e All I have added to cpu/mips is a
serial port driver.
I then create a board and implement the usual functions checkboard,
initdram, low_level_init etc....
I then use an MTD driver that runs perfectly under linux.  i.e the same C
file with minor structure name changes is used from our linux port that has
been stable and used for a long time now.
I then indicate that the environment is stored in nand flash.

It loads the environment but always rejects it based on the CRC check.  
If I cache flush after reading the environment from flash the CRC check
completes ok and it uses this environment.
problem is all the code that follows (device init, eth_initialise, etc fail)
Without a cache flush these work.
I think that you need to initialise the NAND flash and env_relocate before
the calls to eth_initialise etc so I do not feel my order is incorrect.
So I was wondering what ideas people may have.  I feel that the most likely
is that my linux MTD driver use GFP_DMA flag and kmalloc when it is used in
Linux.  This may (I am still investigating) result in it using a different
KSEG which the mips has set up to be uncached. (using the MMU) whereas under
u-boot this is mapped to just malloc and as such is still cached.  I will
pursue this but any helpful ideas from anyone would be appreciated.

>>I was wondering if anyone has any hints or tips on how u-boot is used in a
>> system with only Nand Flash and a Mips processor.
>
>I don;t see anything in your setup where using NAND flash or  a  MIPS
>CPU plays a role; all this is pretty similar on all architectures.
Agreed was just asking for hints and tips!

>> I have seen other posts suggesting mips processors should run uncached
>> but
>> this is obviously slower.
>
>Define "run uncached".
Caches disabled.

>> Has the case been consider where relocation is not necessary i.e a small
>>
>Yes.
>>
>> program just loads the executable to a location and runs it.  I know
>> relocation can save memory but in my system it means extra copying and
>> currently extra headaches!!
>
>Then don't do it.
agreed but as I have indicated throughout I was trying to limit the changes
to the cpu/mips bit and this does relocate hence i tried this.

>Best regards,
>
>Wolfgang Denk
>
>-- 
>Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
>Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
>The ultimate barrier is one's viewpoint.
>                       - Terry Pratchett, _The Dark Side of the Sun_
Cheers
Daniel Laird
--
View this message in context: http://www.nabble.com/Booting+from+NAND+Flash+Problems-t1637982.html#a4501134
Sent from the Uboot - Users forum at Nabble.com.

[U-Boot-Users] Booting from NAND Flash Problems

[Wolfgang Denk]

In message <4501134.post@talk.nabble.com> you wrote:
> 
> I then create a board and implement the usual functions checkboard,
> initdram, low_level_init etc....
> I then use an MTD driver that runs perfectly under linux.  i.e the same C

Why don't you use the existing NAND flash code in U-boot?

Please note that "runs perfectly under linux" doesn't  mean  anything
here. U-Boot is not Linux.

> It loads the environment but always rejects it based on the CRC check.  
> If I cache flush after reading the environment from flash the CRC check
> completes ok and it uses this environment.

You probably should make sure to use  proper  cache  policies  and/or
flushing troughout your port.

> problem is all the code that follows (device init, eth_initialise, etc fail)
> Without a cache flush these work.

That's what I said: fix your port of U-Boot.

> I think that you need to initialise the NAND flash and env_relocate before
> the calls to eth_initialise etc so I do not feel my order is incorrect.

Why don't you just use the existing code?

You mention "our driver", "my code" and "my order" -  how  should  we
comment  on  this?  If you think you know beter and come up with your
own implementation then you will have to debug it yourself. All I can
say is that the exsiting code in U-Boot works fine  on  a  couple  of
boards.

> So I was wondering what ideas people may have.  I feel that the most likely
> is that my linux MTD driver use GFP_DMA flag and kmalloc when it is used in
> Linux.  This may (I am still investigating) result in it using a different

Dump your custome code. Use the existing one.

This is my last comment on this.


> >Define "run uncached".
> Caches disabled.

Instruction cache or data cache or both or what? Yo need to  be  more
specific.


Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
I perceive a possibility of an immediate  chronological  sequence  of
events which includes a violence.
                        - Terry Pratchett, _The Dark Side of the Sun_

[U-Boot-Users] Booting from NAND Flash Problems

[Daniel Laird]

> Why don't you use the existing NAND flash code in U-boot?
>Please note that "runs perfectly under linux" doesn't  mean  anything
>here. U-Boot is not Linux.
Unfortunately the chip I am using has a Flash Interface Chip that handles
the access to flash, this means that the standard u-boot flash code will not
access the flash properly(my problem I know).  This is why a custom MTD
driver that plugs into the linux MTD infrastructure was written and is used
succesfully.  U-Boot then took the really good decision to use the same
infrastructure hence I use the same driver code.  I agree that u-boot is not
linux but a driver that works using the same infrastructure is always a good
starting point.

>> It loads the environment but always rejects it based on the CRC check.  
>> If I cache flush after reading the environment from flash the CRC check
>> completes ok and it uses this environment.
>You probably should make sure to use  proper  cache  policies  and/or
>flushing troughout your port.
As indicated I am using the standard cpu/mips code with a custom serial port
driver.  This was done to minimise the probability of bugs being introduced
by myself.  There is obviously an issue in my port regarding cache flushing. 
I had also seen this discussion
http://sourceforge.net/mailarchive/forum.php?thread_id=10170097&forum_id=12898
And was wondering if i might be suffereing with a similar issue hence I
asked the community for there wider experience and advice.  No point solving
a fixed problem!

>> problem is all the code that follows (device init, eth_initialise, etc
>> fail)
>> Without a cache flush these work.
>
>That's what I said: fix your port of U-Boot.
Obviously a true statement I was just seeing if others has seen anything
similar, using the standard cpu/mips code should minimise the bugs I should
have introduced

>> I think that you need to initialise the NAND flash and env_relocate
>> before
>> the calls to eth_initialise etc so I do not feel my order is incorrect.
>
>Why don't you just use the existing code?
In the current lib_mips/board.c nand_init is not actually called.  Hence I
questioned if anyone had used the new Linux based NAND driver infrastructure
with a mips cpu.

>If you think you know beter and come up with your
>own implementation then you will have to debug it yourself. 
Fair point, I am sure i do not know better however the chip I am using
dictates using a different NAND driver, the current lib_mips does not seem
to initialise NAND flash and I am using the cpu/mips code to minimise the
bugs i will have introduced.

>All I can say is that the exsiting code in U-Boot works fine  on  a  couple 
of
>boards.
Cool, I never questioned that I only asked if a mips processor was using the
new NAND infrastructure and if anyone had had any issue regarding caching
etc.  When looking throught the code  it seems that 3 boards use
ENV_IS_IN_NAND and these are 2 XScales and one PPC.

Thanks for all the comments i will see if i can fix my port and feed back
the changes
Dan
--
View this message in context: http://www.nabble.com/Booting+from+NAND+Flash+Problems-t1637982.html#a4518601
Sent from the Uboot - Users forum at Nabble.com.