Linux, u-boot, 256M NAND and rootfs

I'm just wondering if someone can answer this long but simple question.

My mini2440 system has the 256M NAND flash. I want to boot from the NAND
flash a linux image using u-boot and either a yaffs2 or jffs2 rootfs also
found in the NAND flash. Has anyone successfully done this?

I have bits and pieces of this working. I can use vivi to write u-boot to
flash. I can use vivi to write a yaffs2 rootfs system to NAND and then load
a linux kernel image to RAM and jump to it and the system runs. I have used
vivi to write u-boot to RAM, jump to u-boot and then use it to write itself
to NAND and then subsequently I can switch to booting from NAND and up
comes u-boot. From here I can load linux (uImage) to RAM and jump to it but
it dies when it tries to mount the rootfs system in flash.
I have written the uImage to NAND flash but u-boot will not load it.

Well?

Sounds like you have made pretty good progress so far.

In the last line do you mean the JFFS2 or YAFFS2 image?  In sounds like you
have loaded your uImage properly.  What root filesystem images are you
trying to load?  

You have enabled the right type of filesystem in the kernel?

P.S. Which version of u-boot are you using?  Are there any issues about get
the correct start addresses and sizes of the various sections in flash?

I've been able to write the yaffs2 image to NAND. Then I load the kernel
via vivi to RAM. I can then run the kernel by jumping to RAM. It will find
the rootfs at this point. 

My u-boot version is: U-Boot 1.3.2-mini2440 (Apr 17 2010 - 17:41:20)

I've modified the kernel so that both yaffs2 and jffs2 are supported. I've
made sure to change the bootargs environment variable to reflect what is
currently loaded into NAND.

I used this website:
http://wiki.linuxmce.org/index.php/Mini2440

And I can get a good result here except that I'm mounting the rootfs over
my LAN and not from NAND. This is great for proto-typing a rootfs and doing
quick changes but in time I will want to write that rootfs as an image into
NAND.

Cheers!!

Is the problem you can run everything fine via NFS, but not from NAND.

If so, there has been traffic on here and possibly:
http://groups.google.com/group/mini2440
about this issue.

Good luck.  Tell us what the outcome is.

Well I've made some progress with some help with a friend that has the 1GB
version of the board.

Lets start with u-boot. I used the u-boot git copy from this website:

http://bill.station51.net/index.php?post/2010/01/16/U-Boot-on-Mini2440

Now, I did this almost a month ago and I could follow his page and load the
u-boot according to his instructions. I have always been able to use that
load and get it to work from NAND flash. My friend got his board a bit
later and has had no success with his copy from that git repository.
However, I gave him a binary copy of mine and it could be loaded into NAND
and it would then successfully boot u-boot. He was just over and we
downloaded from that site once again (careful to not over-write my working
copy) and it was compiled and.... it does not work. I've done some looking
about and it would appear that more and more people have run into trouble
with it as well. My friend has headed home and he will be doing a diff on
his copy and compare it to the source copy I put on his memory stick.

Now, creating a linux kernel image that will work with the u-boot loader...

I'm using the linux kernel that came with my board version linux-2.6.32.2.
I could compile it and load the uImage into ram and then run the "bootm"
command and it would uncompress and boot (until it can't find the rootfs
but that's another problem).

If I wrote this image to NAND it will not boot. u-boot tries but then just
gives me the "mini2440# " prompt. I then had a look at this website:

http://wiki.linuxmce.org/index.php/Mini2440

Now, I have followed his instructions exactly and I got to a successful
outcome (thus my description of getting it to work but booting across the
network but not getting the rootfs from NAND).

What I had noticed was his one instruction under the Title "Kernel" and
then "Compilation":

mkimage -A arm -O linux -T kernel -C none -a 0x30008000 -e 0x30008000 -d
<path to zImage file>zImage <path to where  ever your want it>/uImage

Now, I doctored this command line a bit to suite my kernel layout but, it
did produce a uImage in my tftpboot directory that I could write to NAND
flash on my board and it works.

My only part that's missing now is the jffs2 rootfs image working from
NAND.

When and if I get this all working, I'll produce a document and make it
available.

Cheers!!

***
What root filesystem images are you
trying to load?  
***

Your own?

I just have the 64M machine, so just used an old version of u-boot. The
extent to which I managed to achieve a working system is found in the
tutorial on the wiki.

If, you have made your own JFFS2 root filesystem, have you tested it as
outlined in the tutorial?

I'm using the tarball from the SDK CD root fs called:
root_qtopia-20100108.tar.gz as my rootfs and I'm using the following
command line to turn it into a jffs2 root file system image:

mkfs.jffs2 --pad --little-endian --squash -s 0x800 -n -e 128KiB -d
root_qtopia -o root_qtopia-jffs2.img

Tutorial?

I'll rummage around and look for that.

Cheers!!

Well, my friend did his check on the u-boot files that he has that were
mentioned above.

Just to be clear here, where he's talking about the "bad" source files he
talking about the current contents of the git repository referred to again,
above.

I'm just going to copy his email here...

<< Start of email ----

I did a diff between the two source trees.  There are differences.

For example:
- good one has flash.c in board/mini2440/.  Bad one does not (so it
  may rely on common/flash.c).
- bad one has some lines commented out in lowlevel_init.S
- bad one has extra flinit command in u-boot to probe and initialize NOR.
- bad one has modification to drivers/mtd/cfi_flash.c to support mini2440
card

I think it is trying to use a common flash.c in the newer code (the bad
one).

---- End of email >>

A couple of questions about your mkfs.jffs2 switches:

-s 0x800 where does this value pagesize come from? Didn't do that for my
64M dev board
-e 128KiB is the KiB just to make it clear to you or is it needed?

Is the process you followed:

- take root_qtopia-20100108.tar.gz
- extract it
- then just run mkfs.jffs2 with your switches
and make sure JFFS2 is enabled in the kernel?

Sorry, but I think I have run out of suggestions.

Good luck!

Davef,

The command "nand info" gives me the pagesize of 2048 (0x800) and the erase
block of 128Kib.

Your process is correct. pretty much exactly what I did.

I'm quite a bit further along from the work I did on the weekend than I was
before so I'll keep plugging away at it.

Cheers!!

Could you provide us with exactly what is happening during the loading of
the kernel up to the point where it dies? So far I dont see where anyone
has asked that. 

This thread, at least to me, seems a little confusing. So what you're
saying is that you want to be able to write your filesystem and kernel to
RAM and boot it using u-boot but it tries to load the kernel and you get
returned to a mini2440# prompt? 

If you suspect that the code has been changed to where it won't work, I
suggest you go directly to http://bliterness.blogspot.com/ where Buserror
lives and ask. But I noticed this on his blog:

"The 256MB board seems to have a problem with flashing u-boot itself;
apparently 'vivi' is screwing up the environment for u-boot to do it's job,
and the board just hangs on reboot. I don't have a fix for that yet.
Strangely, the 1GB one works.."

I don't know if that pertains to your board or your problem. But there does
seem to be some issues with boards with different manufacturing dates.

Not having a 256MB board myself, I don't have a lot of suggestions or
experience. But I'll try to help if you can provide what its exactly doing
and the logs of that. Your environment vars might be good too. Might help
us diagnose your problem a little better and get you going :)

Bill

Oh... I suggest joining the google Group

http://groups.google.com/group/mini2440

Buserror, myself and many others hang out there.

Bill,
What I want is to be able to boot the system using u-boot to load the
kernel from NAND and, to have the jffs2 root file system reside in NAND. I
do not want to be booting across the network using nfs.

As far as the issue that you mention around "vivi" giving problems, this is
well known and not the issue that I'm running into here or am trying to
explain.

The issue that has become known as I worked through this with my friend was
that the current version of u-boot in the repository does not work with the
256M or 1G board.

So... here it goes, I used the web page instructions:

http://bill.station51.net/index.php?post/2010/01/16/U-Boot-on-Mini2440

To build and then transfer the u-boot.bin file across to the board.

Here's the output from the command: go 0x32000000

Supervivi> go 0x32000000
go to 0x32000000
  argument 0 = 0x00000000
  argument 1 = 0x00000000
  argument 2 = 0x00000000
  argument 3 = 0x00000000

And that's it, the board is dead. That's from a new download of the git
repository as referenced in the web site running on a fully functional
mini2440 board with 256M NAND flash.

Now, I have the older u-boot source code for u-boot that has the
differences that were referred in my post above. That source code compiles,
loads and works just fine.

I think I just got u-boot to work on a 256M board!

First I tried compiling the mini2440-stable branch from 5th Oct 2009 and
uploading it using the instructions that Bloggins666 referred to above, it
ram from ram ok but nothing happened on reboot, same as the newer version.

Then I recompiled the newest version and rather than run it from ram I
tried option 'v' in vivi to upload the u-boot-nand2k.bin and now it's
working.

...and when I flash the kernel from an SD card using u-boot it stops
booting. I just get one single character on the console, exactly the same
as when I flash u-boot from within u-boot.

Cancel that, I forgot to run dynpart...

It really should not be that hard.

Fundamentally there is no  difference between a 64/128/256/1gb nand flash
as far as hardware goes.
as long as you stick to the same 'block size' for a particular type of
nandflash (528/2112)
you  should be fine.

Just treat a 256mb as a 128mb flash. (tell the board it has a SMALLER flash
than it actually does.)
Once you get that working  your off.

Hi everyone, 

I posted a workaround for this little "bug" in the code on my blog's forum.


http://billforums.station51.net/viewtopic.php?f=1&t=2

At the bottom of that post, there's an update that shows how I managed to
solve the issue with the current code. It's a sloppy way but it works and
still allows you to create a bad block table etc by double flashing the
u-boot bin from vivi.

Bill