New Fireware Instalation Method?

[haplo]

We seem to need a new firmware install method seeing as a large amount of people can't currently upgrade and I don't think saying "keep spending money on SD cards until on works" is a good plan.

I've been using some scripts I picked up on this forum somewhere (modifed) and got a whole filesystem listing. However I can't find the kernel. And fstab on the gp2x doesn't mention a /boot drive.

So I don't even know where to begin.

If anyone is interested in the gp2x file system layout I put my output at haplo.mindstab.net/filesystem.txt.

 

[AireTamStorm]

If anyone is interested in the gp2x file system layout I put my output at haplo.mindstab.net/filesystem.txt.

​

Ah, thanks, been looking for something like that.

 

[EvilDragon]

Currently being worked on.

 

[judge0]

We seem to need a new firmware install method seeing as a large amount of people can't currently upgrade and I don't think saying "keep spending money on SD cards until on works" is a good plan.

I've been using some scripts I picked up on this forum somewhere (modifed) and got a whole filesystem listing. However I can't find the kernel. And fstab on the gp2x doesn't mention a /boot drive.

So I don't even know where to begin.

If anyone is interested in the gp2x file system layout I put my output at haplo.mindstab.net/filesystem.txt.

​

Because we're working with an embedded system, it will look different than a standard linux installation.
System uses U-Boot, which uses MTD compressed images, expandable as required.
mtd0 = U-Boot (highly modified from standard U-Boot installation)
mtd1 = Param ???
mtd2= Kernel (what we want to upgrade)
mtd3= Filesystem (JFFS2, also why we have a 20 second boot time, btw)
mtd4= Extend ???
mtd5= where root file system is (GP2X = NAND 64MiB 3,3V 8-bit)

the procedure to upgrade firmware will be as follows
eraseall /dev/mtd{mtd block #}
dd if=/mnt/sd/{image filename} of=/dev/mtd{mtd block #} bs=128k conv=sync

However, the eraseall command is not present in accessible filesystem. it needs to be run from U-Boot space.
There is a procedure U-Boot uses to determine if firmware images are present at select locations (network, storage etc), that has some conditions that aren't being met in our case.
As far as I can tell, it's a problem with whether the SD is set up for charset UTF8 or iso8859-1.

The mechanism that deletes *.img files from root of SD is located in /etc/profile, and has nothing to do with whether they were used for upgrade or not.

Above information was culled from here

@ED: I'd like to assist whoever is working on this, I'm only using sterm at the moment, but would like to make a serial cable (or purchase if available.
Let me know if you would like some help with this.

 

[BradN]

I don't believe you need to run eraseall. The kernel should erase blocks as necessary to reprogram the flash (this is how you can write to the filesystem). Also, I think mtd5 is a device for access to the entire flash chip - the root filesystem lives on mtd3, and mtd4 is an extra partition using the rest of the space, probably intended for user storage later on (mtd3 is only 24MB I believe). Also, a better block size might be 16384 (16KB), as this is the flash erase size reported by /proc/mtd. conv=sync shouldn't be needed as the firmware file size should fit exactly in the partition (it's only used to pad the last block if it doesn't completely fill the last block)

The device filesystem layout is also a little different than in the example you posted (from your filesystem listing, it's the same as it is on my linksys router, ie. /dev/mtd/<number>).

So, an upgrade command for the kernel would look like:
dd if=/mnt/sd/kernel.bin of=/dev/mtd/2 bs=16384

EDIT: fixed the mtd number... I hope nobody tried it with 3 instead of 2!

But you must (MUST) make sure the kernel image is the raw data that gets written to the flash chip - someone should copy the kernel image off an upgraded gp2x to make sure the data is formatted correctly - the downloadable update files might not be in the correct format.

command to back up current kernel:
dd if=/dev/mtd/2 of=/mnt/sd/backupkernel.bin
(block size isn't important at all for reading)

One sucky thing is that this illustrates how ridiculously easy it would be to make a malicious program to erase the flash memory. GPH should have really tested U-Boot better for compatability (ie, made sure it works with all SD and MMC cards, and doesn't spontaneously brick itself), and then set sector protection on that portion of the NAND chip so it's not erasable.

As an extra safeguard, you _might_ be able to md5sum the firmware image from the gp2x to check its integrity - there's no md5sum link to busybox, but busybox could still be compiled with support for it, like:
busybox md5sum /mnt/sd/kernel.bin

If you md5sum it before copying it to the SD card, and then md5sum it on the gp2x, you can compare the sums and be sure that the file hasn't been copied incorrectly.

 

[nik166]

what a passionating thread full of hope!


but it makes me wondering something , IF i understood what brad said for example, you ONLY need a linux command to update the kernel in theory ?

i mean, what's refraining us to flash from sterm for example ? (except the fear to try somethinh untested )

 

[BradN]

Well, someone should grab a firmware image from an updated gp2x and post that on the file download thing, as that would definitely be in the correct format. Other than that, it's just that whole "first step into the unknown" syndrome

But yeah, it should only be one command to update it. Once it returns to the shell, you reboot, and you should have the new kernel.

 

[PSyMastR]

did gph say when 1.0.2 will come out? I herd december 10th, and its the 11th...

 

[BradN]

Update: I took a look at the update files in the 1.0.1 firmware download - it looks like the kernel image is a plain image, but doesn't include the "empty" space after the kernel (the space is sized 1MB, but the kernel is only 817KB).

I did a quick test with dd, and in a situation where the last block doesn't fill the full block size, dd will pad it with nulls even without conv=sync, so it should be fine.

The other question raised is whether the kernel should be at the beginning of this 1MB or at the end, and that's answered by http://www.arm.linux.org.uk/developer/booting.php#5

"The boot loader is expected to call the kernel image by jumping directly to the first instruction of the kernel image", so indeed the kernel should be at the beginning of this 1MB, putting the first instruction in a known location (and this is what dd will do).

So, indeed, the command should be like:

dd if=/mnt/sd/gp2xkernel.img of=/dev/mtd/2 bs=16384

*waits patiently for enthusiastic reports of success, or screaming about a newly acquired paperweight*

 

[nik166]

then first of all, someone who successfully flashed gotta release a dump!

and then, someone who own some cable for unbricking should try first ...

 

[dennis20014]

well im glad that there workin on another one, I was concerend with the current one I didn't want my unit going BLAH on me lol

 

[Robster]

BradN: be VERY careful with that dd method! I don't know what it will do about bad blocks in the NAND. Any NAND chip can have bad blocks anywhere except for the first page, and if you write the kernel image without taking account of them in the same way that U-Boot does, you'll end up killing the kernel. It should be reparable by replacing the kernel using the U-Boot method, but since you're trying to get around the U-Boot method anyway, this doesn't sound like a great option

It would be good if someone would look into how U-Boot handles bad blocks in the Flash, and report back here (/me looks around for volunteers )

 

[BradN]

Hmm, I did some quick research and it seems that NAND chips typically use some out-of-band storage to deal with bad blocks, but that this is done partially under software control. I'm not sure I'd recommend flashing the kernel in this way now. I'll look and see if U-Boot does any bad block handling.

 

[EvilDragon]

dd if=/mnt/sd/gp2xkernel.img of=/dev/mtd/2 bs=16384

*waits patiently for enthusiastic reports of success, or screaming about a newly acquired paperweight*

​

Don't try this at home:

The answer to this line is:

dd: /dev/mtd/2: Invalid argument

And the gp2x kernel image is destroyed after that (only boots up to U-Boot).

Standard FW-Upgrade method does fix this, but it doesn't help here...

 

[judge0]

dd if=/mnt/sd/gp2xkernel.img of=/dev/mtd/2 bs=16384

*waits patiently for enthusiastic reports of success, or screaming about a newly acquired paperweight*

​

Don't try this at home:

The answer to this line is:

dd: /dev/mtd/2: Invalid argument

And the gp2x kernel image is destroyed after that (only boots up to U-Boot).

Standard FW-Upgrade method does fix this, but it doesn't help here...

​

ED: the mtd blocks are symbolic links to symbolic links, should read /dev/mtd2 not /dev/mtd/2 - not sure where your command aimed the write to . . .

It needs to specify an input file 'if' and an ouput file 'of' with block size 'bs' (has default of 16 k) and conversion specifier ( as BradN stated conv=sync pads last block with zeroes to maintain byte alignment.

Of interest to the HH crew will be the input file. U-Boot looks for one or more of seven *.img files in root of SD. Five are for upgrading the filesystem, kernel etc. The other two are stand-alone executables. One could be used for replacement OS, and the other for actual program to run. These are created with mkimage from Development kit for U-Boot ( free from Denx - linux only, GCC 3.3)

BTW, I finally upgraded system to version 1.01, tried a sandisk 1GB from a friend, worked without jumping through hoops. It has a different cylinder count than the other cards I tried. What a difference

 

[BradN]

Yeah, after looking at some info on U-Boot, it seems it does special handling for bad blocks which mtd doesn't by itself, so yeah... don't flash like this!

I don't understand where the invalid argument is coming from - I just tried copying the user storage space on my router to itself like:

/dev/mtd # dd if=/dev/mtd/4 of=/dev/mtd/4 bs=65536
5+0 records in
5+0 records out

(the erase size is 64KB here) and it worked fine. Probably doesn't do any bad block testing or things like that, but it at least did the operation.

 

[judge0]

Yeah, after looking at some info on U-Boot, it seems it does special handling for bad blocks which mtd doesn't by itself, so yeah... don't flash like this!

I don't understand where the invalid argument is coming from - I just tried copying the user storage space on my router to itself like:

/dev/mtd # dd if=/dev/mtd/4 of=/dev/mtd/4 bs=65536
5+0 records in
5+0 records out

(the erase size is 64KB here) and it worked fine. Probably doesn't do any bad block testing or things like that, but it at least did the operation.

​

It's just syntax, on your router /dev/mtd will most likely be a real directory, not a symbolic link.

On the GP2X if you do /dev/ # ls -a m*
you should see
mtd:
0 1 2 3 4 5
0ro 1ro 2ro 3ro 4ro 5ro

They're symbolic links to symbolic links, and are represented by mtd0 instead of mtd/0

 

[BradN]

I looked in the filesystem.txt someone posted above, and I didn't find any mtd2 at all. Are you sure it's there?

 

[BBTroll]

I also get
mtd:
0 1 2 3 4 5
0ro 1ro 2ro 3ro 4ro 5ro

mtdblock:
0 1 2 3 4 5

that is using sterm

But, I don't see any mtd* links

 

[nik166]

and if we take the problem from another way,


can't we modify uboot to make it look for the images in the NAND for example ?