[Bug 719] dfu-util should be able to initiate a nand-erase

bugzilla-daemon at bugzilla.openmoko.org bugzilla-daemon at bugzilla.openmoko.org
Mon Aug 20 22:01:34 CEST 2007


http://bugzilla.openmoko.org/cgi-bin/bugzilla/show_bug.cgi?id=719

hns at computer.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|normal                      |blocker



------- Additional Comments From hns at computer.org  2007-08-20 22:01 -------
Here another report that might be related to this issue from the device-owners list (does not appear in 
the web archives yet).

If this bug is already fixed by a newer uboot version, this should be made public in the Wiki and by an 
announcement on the lists...

	Von: 	  m at feuersaenger.de
	Betreff: 	Flashing Adventure (was Re: A few more First-Day issues)
	Datum: 	17. August 2007 12:17:14 MESZ
	An: 	  device-owners at lists.openmoko.org

Hi List,

This thread is a good point to post my experiences in the first days of
Neo1973 ownership.

The issue that I had is about flashing the device. I initially flashed
(with dfu) the *-moko10-* kernel while the rootfs holds modules for
*-moko11-*. The device booted ok but of course there were no modules to
load.

So I flashed the *-moko11-* image to the nand partition reserved for the
kernel. And this is where the trouble started ...

Even though I flashed the *-moko11-* image and dfu reported no errors the
Neo still seemed to have the old *-moko10-* image in the nand. I flashed
the *-moko11-* image again, but no success. Now my idea was to
deliberately delete the nand with 'nand erase kernel' in u-boot.
Afterwards I flashed the *-moko11-* image once again with dfu.

Now when I switched on the Neo it stopped with a 'Bad magic number'
message an immediately powered down again (i.e. i guess the content of the
kernel partition got loaded in memory but could't get verified/executed or
similar). No reflashing of the kernel helped to get the Neo out of this
state, even though dfu reported successful flashing all the time (w. and
w/o executing a 'nand erase kernel' beforehand).

Well, I finally revived my Neo by putting the *-moko11-* image on the SD
card, and writing the image from there via memory into the nand as
described in
http://wiki.openmoko.org/wiki/U-boot#Commands_on_the_bootloader_prompt.

Trying to read the image into memory (ext2load mmc 0 0x32000000 uImage)
and then directly starting it from there (bootm 0x32000000) I got the
penguin and a blinking underscore curser. Doing the full procedure of
writing the kernel to nand after loading it into memory left me with a
bootable kernel again.

However, now the boot process stopped with a kernel panic because init
couldn't be started. So I guess now the rootfs was damaged/erased.
Reflashing it with the dfu tool resolved the problem and the Neo was
revived again.

Now I'm really curious what I did wrong and what the cause of my problems
was. Actually I have no clue and according to my understanding all steps I
took (1.) reflashing the kernel, 2.) loading a kernel into memory and
booting from memory) should have worked in the first place and what even
confuses me more was the need to reflash the rootfs, even though this
wasn't touched in the whole procedure (and yes, I always did a -a 3 in
dfu-util).

Hope to learn something from you guys,

Cheers,
  Martin



--- Peter Rasmussen <plr at udgaard.com> wrote:
Then, when I will eventually be able to build a kernel, I am wondering:

is the only way to change to it, by loading it through the dfu-util, or
is it also possible by using a more "desktop like method", like building
a kernel, putting it in somewhere, eg. /boot, update /etc/lilo.conf, run
lilo and then reboot?
As someone already pointed out you can Boot from the SD card.

I doubt you'll get to the same process as you may be used to on a desktop
Linux
system, because on an embedded system it isn't simply a process of adding
a new
kernel image to the filesystem and pointing the bootloader at it. The
bootloader is configured to always boot the image that resides at a
specific
location in the nand flash. Now, while you _could_ add more kernel images
to
the nand flash, you would need to repartition the flash each time you
added
one. And that isn't as simple as doing it on a disc based system either.

One thing that may be worth exploring is modding u-boot to support Flash
from
SD card, I don't think it does this just yet, but most of the code needed
to do
it will be there, then your reflash proceedure would be to upload the
files to
the SD card, and reboot into the u-boot menu and choose the appropriate
option.
I think this is the closest to the familiar procedure as you are likely to
get.

I am hoping to eventually be able to run everything natively on the
Neo1973, just like on a desktop. Hey, it runs 266MHz so it should have
plenty horsepower to build its own kernel :-)
Yes, the Neo does have the horsepower, but I would advise against trying
this.
Compilation, especially large builds like Linux kernels, are very disc IO
intensive, and the one thing you should avoid on NAND flash based systems
is
disc IO intensive operations. They are slow and you will eventually wear
out
the NAND flash. Of course, you could try and configure it to use a RAM
drive as
a cache and scratchpad for all the temporary files.



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.




More information about the buglog mailing list