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?
Linux, u-boot, 256M NAND and rootfs
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.
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