Up-To-Date Firmware Tarball

[noisome]

I am looking for an up-to-date Pandora firmware tarball. I have found skeezix's out-of-date one, but is there in up-to-date one available?

I am looking because I want to put the firmware on SDC and also so its available in the future for others. I know I can copy the firmware files from the Pandora to SDC and add the boot.txt and get it to boot, but that's not what I'm looking for.

Thanks for any help!

*EDIT*
These DO NOT contain hotfixes or codec player packages. Get those from http://apps.open-pandora.org.
Link from sinoth: http://filevo.com/5h6fnh6j97on.html
Mirrored: http://pandora.digital52.com/downloads/Angstrom-pandora-xfce-image-glibc-ipk-2010.4-test-20100614-omap3-pandora.rootfs.tar.bz2

Download: boot.txt

Steps:
1. Format SD card to EXT2.
2. Extract the rootfs.tar.bz2 file to SD card.
3. Place the boot.txt on the SD card. Rename to autoboot.txt to autoboot to the SD card instead of NAND.
4. Place SD card in left slot of Pandora.
5. While holding the right trigger button, reboot the pandora.
6. Select SD1:1

This should boot. Thanks be to skeezix (and his writeup) and sinoth!

 

[SomeGuy99]

+1

I'm copying over from my NAND and it takes forever! Also, I realised some of the folders really shouldn't be copied - ie. /media. Doh!

 

[sinoth]

+1

I tried doing a "cp -a / /media/mmcblk0p1" but apparently that doesn't work as expected. I'm getting an error on boot:
“hwclock: can’t open ‘/dev/misc/rtc’: No such file or directory”

A fresh archive of the firmware would be nice

 

[noisome]

+1

I tried doing a "cp -a / /media/mmcblk0p1" but apparently that doesn't work as expected. I'm getting an error on boot:
“hwclock: can’t open ‘/dev/misc/rtc’: No such file or directory”

A fresh archive of the firmware would be nice

Hopefully we will get a nice tarball file already done, but until then, I've been looking at how to get a dump of the nand and I found some nifty things. If you have the old tarball on an SDC already and can boot:

mtd_debug info /dev/mtd4 will show that /dev/mtd4 is 499M in size. This might be the main NAND.
nanddump -f <filetodumpto> /dev/mtd4ro will dump this area (I hope). I am performing this now and will see if it provides me the files needed to copy to the SDC. If this works, then I will proceed to reflash the NAND with the current firmware and redump it before logging in for the first time.

If this works, I will post the results and the tarball here, if someone else doesn't do it before me.

*EDIT*

Apparently I've gotten in over my head. I've downloaded the dump file and tried to mount it several ways, using AUFS, JFFS2 and UBIFS, using the helpful but essentially useless in my confused hands. I don't know what /dev/mtd to actually dump and how to mount it or at least extract the files.

 

[mindlord]

Could we not somehow extract the root filesystem from the firmware flasher package?

 

[paulguy]

As for why you can't mount the dumped NAND as-is, there's probably some kind of partition table or other kind of descriptor/metadata/header/etc at the beginning. If you can find the offset that the filesystem starts at, you can clip off the beginning and have the filesystem image. If the data at the beginning follows some standard known format, you can likely just use "file" on it, and it'll tell you what it is.

This same thing is why you can't mount a hard disk image from an emulator (or just dumped from an existing drive) directly.

 

[noisome]

As for why you can't mount the dumped NAND as-is, there's probably some kind of partition table or other kind of descriptor/metadata/header/etc at the beginning. If you can find the offset that the filesystem starts at, you can clip off the beginning and have the filesystem image. If the data at the beginning follows some standard known format, you can likely just use "file" on it, and it'll tell you what it is.

This same thing is why you can't mount a hard disk image from an emulator (or just dumped from an existing drive) directly.

Basically the rootfs.img file that is in the flash package is what is on /dev/mtd4. The script to flash the nand and mtd0-4 is pretty simple, but what I cannot do is mount mtd4. MTD0-3 are mounted by the script, MTD4 is not despite looking like it should be according to the script updater.sh.

This is what I don't understand. If one can mount rootfs.img, then the files can be extracted out. Every time I try this or mounting mtd4 I can't. It *SHOULD* work and I may be missing something obvious.

With UBIFS I have mounted mtd0-3. I get an error with 4, saying not enough eraseblocks, even though I followed what the updater.sh script does and followed the manual.

 

[notaz]

You can't mount /dev/mtd4 as a block device (it's not usual block devices as /dev/mmcblk* stuff, it's mtd char device), also can't mount /dev/ubi* as that needs newer kernels. You must use special syntax for this:

mount -t ubifs ubi0:rootfs /mnt/whatever

Copying contents of /mnt/whatever/ to ext2/3 card should give you reliable OS image on SD.

 

[urjaman]

Hey notaz,

A bit off-topic, but now that I'm momentarily interested

Is there an image of the initial (==factory) firmware loading SD somewhere?

 

[noisome]

You can't mount /dev/mtd4 as a block device (it's not usual block devices as /dev/mmcblk* stuff, it's mtd char device), also can't mount /dev/ubi* as that needs newer kernels. You must use special syntax for this:

mount -t ubifs ubi0:rootfs /mnt/whatever

Copying contents of /mnt/whatever/ to ext2/3 card should give you reliable OS image on SD.

I have tried that. I can never name /dev/mtd4 rootfs.

I attempted:

ubiattach /dev/ubi_ctrl -m 4
ubimkvol /dev/ubi0 -N rootfs -m
mount -t ubifs ubi0:rootfs /mnt/whatever

With the ubimkvol command I get an eraseblocks error, it never makes the reference rootfs and I can never mount it. Thats why I keep believing I'm missing something.

 

[urjaman]

You can't mount /dev/mtd4 as a block device (it's not usual block devices as /dev/mmcblk* stuff, it's mtd char device), also can't mount /dev/ubi* as that needs newer kernels. You must use special syntax for this:

mount -t ubifs ubi0:rootfs /mnt/whatever

Copying contents of /mnt/whatever/ to ext2/3 card should give you reliable OS image on SD.

I have tried that. I can never name /dev/mtd4 rootfs.

I attempted:

ubiattach /dev/ubi_ctrl -m 4
ubimkvol /dev/ubi0 -N rootfs -m
mount -t ubifs ubi0:rootfs /mnt/whatever

With the ubimkvol command I get an eraseblocks error, it never makes the reference rootfs and I can never mount it. Thats why I keep believing I'm missing something.

Are you trying to create a new root filesystem (already running from SD) or something like that?
This just sounds very wrong if you're just trying to copy the current rootfs data to an SD.

 

[noisome]

Are you trying to create a new root filesystem (already running from SD) or something like that?
This just sounds very wrong if you're just trying to copy the current rootfs data to an SD.

Just want the files from a fresh file system install. I don't want a "already setup" image, meaning no user setup, no gui selected, etc. Fresh from factory file system tarball.

Just like the _OUT_OF_DATE_ firmware tarball from skeezix's blog, except being these newest edition of Zaxxon.

I'm failing to get my own so I am asking for help.

 

[SomeGuy99]

I'm finding that all of these methods taking absolutely forever! Copying files from the nand or unpacking the out of date tarball takes hours... many many hours... I had to leave it going overnight.

Is there a faster way? I mean, the firmware flashes in 15 minutes. Why should it take longer than this?

 

[urjaman]

Just want the files from a fresh file system install. I don't want a "already setup" image, meaning no user setup, no gui selected, etc. Fresh from factory file system tarball.

Just like the _OUT_OF_DATE_ firmware tarball from skeezix's blog, except being these newest edition of Zaxxon.

I'm failing to get my own so I am asking for help.

This method wont give you a fresh factory install without some twiddling since your pandora has already modified its NAND image (you already did the user setup etc).
I'm not sure if the pandora/linux/UBIFS allows a second mount of its rootfs, but if notaz says so, it should be fine.
So

mount -t ubifs ubi0:rootfs /mnt/whatever

Should give you exactly your rootfs contents at /mnt/whatever (the directory must exist). Use ls /mnt/whatever to check. Then just create the tar archive of it or copy the contents to SD or whatever you were upto.
Eg. for a tar.gz archive:

tar -czf /mnt/yoursd/rootfs.tar.gz /mnt/whatever

Use -cvzf instead if you want to see the files scroll by

@SomeGuy99: I'm thinking that it could be much faster to mount the SD card async when copying to it. (If you havent already).

 

[noisome]

I'm finding that all of these methods taking absolutely forever! Copying files from the nand or unpacking the out of date tarball takes hours... many many hours... I had to leave it going overnight.

Is there a faster way? I mean, the firmware flashes in 15 minutes. Why should it take longer than this?

I don't do it directly to the card. I connect to a windows share (or NFS if you have it) and do a tar of the files to there. It only takes a few minutes and then extract the files to the SD on that system, not the Pandora.

I do:

mount -t cifs //ip/share /media/share
cd /media/share
tar -cvzf backup.tar.gz --exclude /proc --exclude /media /

I wonder if "find | cpio -p" Would be a better choice?



Make sure you do an "--exclude /proc --exclude /media" (or whereever your samba mount is located).

And as urjaman said, async "should" work faster, but it won't be as noticeable since its still going to be a slow write. It'll just get through the list faster.

 

[urjaman]

urjaman said, async "should" work faster, but it won't be as noticeable since its still going to be a slow write. It'll just get through the list faster.

The problem with sync is that atleast if you attempt a copy to an ext2 formatted SD card, with each file written the filesystem metadata needs to be changed and (partially) re-written for each file (instead of just (optimally, a bit utopistic) once)).

This might also slow down writing of a .tar.gz file. It will after each append to the file need to write the new size (and allocated sectors etc) to disk, instead of when that is really appropriate.

I'm not 100% sure of how strict the "sync" mount flag is, but this is atleast what i think could be happening.

Of course, when mounted async you might end up "writing" the file, then when saying "sync"(or unmount) need to wait some time there...

 

[mindlord]

^ I tried this, but /dev fails all over the place.

Okay, I gave up on the network route, and got around the /dev issue, but now when I boot the system with the image the controls don't respond, I get something about HAL not running in a dialog in XFCE, and the unit shuts off.

 

[sinoth]

Finally got the OS compiled and booting from SD! Here is the .tar.bz2 of Zaxxon (fresh, no hotfixes and still has initial boot wizard):
(NOTE: I have tested this briefly and it seems to be working okay, but this is in NO WAY OFFICIAL! There may be things broken I haven't tested yet. YMMV.)
http://filevo.com/5h6fnh6j97on.html

Simply extract this to an SD card (mine is one partition, ext2) and add a boot.txt to the root of the SD that includes the following:

setenv bootargs root=/dev/mmcblk0p1 rw rootdelay=2 vram=6272K omapfs.vram=0:3000K
ubi part boot && ubifsmount boot && ubifsload ${loadaddr} uImage && bootm ${loadaddr} && boot

This will boot the kernel from NAND and the root filesystem from the first SD card. Hold the right trigger as you boot to get the option to "boot from SD1:1".

 

[noisome]

Finally got the OS compiled and booting from SD! Here is the .tar.bz2 of Zaxxon (fresh, no hotfixes and still has initial boot wizard):
(NOTE: I have tested this briefly and it seems to be working okay, but this is in NO WAY OFFICIAL! There may be things broken I haven't tested yet. YMMV.)
http://filevo.com/5h6fnh6j97on.html

Simply extract this to an SD card (mine is one partition, ext2) and add a boot.txt to the root of the SD that includes the following:

setenv bootargs root=/dev/mmcblk0p1 rw rootdelay=2 vram=6272K omapfs.vram=0:3000K
ubi part boot && ubifsmount boot && ubifsload ${loadaddr} uImage && bootm ${loadaddr} && boot

This will boot the kernel from NAND and the root filesystem from the first SD card. Hold the right trigger as you boot to get the option to "boot from SD1:1".

Thanks sinoth! Haven't tried it yet, but I will also rehost the file just in case. I will post the link here.

*EDIT*

Here's the link (download accelerator friendly): http://pandora.digital52.com/downloads/Angstrom-pandora-xfce-image-glibc-ipk-2010.4-test-20100614-omap3-pandora.rootfs.tar.bz2

 

[skeezix]

Btw the one on my blog was used in first shipping devices so is acceptible for use

I flag it out of date to encourage us to come up with better way to do it than my blog

jeffphone