Nexus S firmware will not be released by Samsung...only Google will release it. These firmwares that are released are for Galaxy S/S2
Galaxy S2 GT-I9200 firmware GINGERBREAD?! (Download LINK)
- Thread starter nCoder
- Start date
Nexus S firmware will not be released by Samsung...only Google will release it. These firmwares that are released are for Galaxy S/S2
I've tried the 1GB code form www linux-mtd infradead.org/faq/nand.html (can't post links). But when I run cat /proc/mtd it only displays a size of 40MB. Is this supposed to happen?
The size is in hex.....
cant get attach to work either. got alot of ecc errors in dmesg and refused to attach to mtd after dd so...
Would this work on our SGS phones if the hardware is different. Guess when its extracted we will find out.......
![[Ramad]](/data/avatars/s/2965/2965881.jpg?1600603247){kind=avatar}
I get this error: UBI error: validate_ec_hdr: bad data offset 8192, expected 6144
Setting the data offset to 8192 should obviously fix this, but I have no idea how. There is no option for it. Only for the VID header offset.
Edit: The data offset is calculated: "Data offset is VID header offset + VID header size aligned to the min. I/O unit size up"
Last edited:
To get past error 22, you have to do a ubiformat -s 512.
It got me all the way to mount and then my ubuntu 10.04 live cd could not do ubifs. Will have to try again at home.
Sent from my SAMSUNG-SGH-I897 using XDA App
It got me all the way to mount and then my ubuntu 10.04 live cd could not do ubifs. Will have to try again at home.
Sent from my SAMSUNG-SGH-I897 using XDA App
Even if we are not able to access the UBIFS easily...
all files start with "UBI"...
The size is in the header.
some sort of jornal info...
Padded with 0xFF at the end of the file - should be simple to derive the block size
File Directory not found yet...
all files start with "UBI"...
The size is in the header.
some sort of jornal info...
Padded with 0xFF at the end of the file - should be simple to derive the block size
File Directory not found yet...
ubiformat - formats empty flash, erases flash and preserves erase counters, flashes UBI images to MTD devices
Seems like you are erasing the whole image.
Well supercurio is on it too so dont worry . All be good .... Lol ...
Sent from my Intergalactic Supah Dupah Spaceship¡¡!!!
Sent from my Intergalactic Supah Dupah Spaceship¡¡!!!
some info found in http://www.linux-mtd.infradead.org/faq/ubifs.html
"How do I mount UBIFS?
The modern way of mounting UBIFS is mounting UBI volume character device nodes, e.g.:
$ mount -t ubifs /dev/ubi0_0 /mnt/ubifs
will mount UBIFS to UBI volume 0 on UBI device 0. This is the easiest way to mount UBIFS, but it is supported only in kernels starting from version 2.6.32. The UBIFS back-port trees (see here) also support this mounting method.
The old method is to use device-less mount, just like procfs or sysfs. The volume to mount is specified using ubiX_Y or ubiX:NAME syntax, where
X - UBI device number;
Y - UBI volume number;
NAME - UBI volume name.
For example,
$ mount -t ubifs ubi1_0 /mnt/ubifs
mounts volume 0 on UBI device 1 to /mnt/ubifs, and
$ mount -t ubifs ubi0:rootfs /mnt/ubifs
mounts "rootfs" volume of UBI device 0 to /mnt/ubifs ("rootfs" is volume name). This method of specifying UBI volume is more preferable because it does not depend on volume number.
Note, if X is not specified, UBIFS assumes 0, i.e., "ubi0:rootfs" and "ubi:rootfs" are equivalent.
Some environments like busybox are confused by the ":" delimiter (e.g., ubi:rootfs) and "!" may be used instead (e.g., ubi!rootfs).
In order to mount UBIFS as the root file system, you have to compile UBIFS into the kernel (instead of compiling it as a kernel module) and specify proper kernel boot arguments and make the kernel mount UBIFS on boot. You have to provide the boot arguments to attach the UBI device (using the ubi.mtd= argument, see here). Then you should tell the kernel the file system type by providing the rootfstype= argument. And finally, you should specify which UBI volume has to be mounted on boot using the root= argument. The volume is specified the same way as described above (ubiX_Y or ubiX:NAME).
The following is an example of the kernel boot arguments to attach mtd0 to UBI and mount UBI volume "rootfs":
ubi.mtd=0 root=ubi0:rootfs rootfstype=ubifs"
"How do I mount UBIFS?
The modern way of mounting UBIFS is mounting UBI volume character device nodes, e.g.:
$ mount -t ubifs /dev/ubi0_0 /mnt/ubifs
will mount UBIFS to UBI volume 0 on UBI device 0. This is the easiest way to mount UBIFS, but it is supported only in kernels starting from version 2.6.32. The UBIFS back-port trees (see here) also support this mounting method.
The old method is to use device-less mount, just like procfs or sysfs. The volume to mount is specified using ubiX_Y or ubiX:NAME syntax, where
X - UBI device number;
Y - UBI volume number;
NAME - UBI volume name.
For example,
$ mount -t ubifs ubi1_0 /mnt/ubifs
mounts volume 0 on UBI device 1 to /mnt/ubifs, and
$ mount -t ubifs ubi0:rootfs /mnt/ubifs
mounts "rootfs" volume of UBI device 0 to /mnt/ubifs ("rootfs" is volume name). This method of specifying UBI volume is more preferable because it does not depend on volume number.
Note, if X is not specified, UBIFS assumes 0, i.e., "ubi0:rootfs" and "ubi:rootfs" are equivalent.
Some environments like busybox are confused by the ":" delimiter (e.g., ubi:rootfs) and "!" may be used instead (e.g., ubi!rootfs).
In order to mount UBIFS as the root file system, you have to compile UBIFS into the kernel (instead of compiling it as a kernel module) and specify proper kernel boot arguments and make the kernel mount UBIFS on boot. You have to provide the boot arguments to attach the UBI device (using the ubi.mtd= argument, see here). Then you should tell the kernel the file system type by providing the rootfstype= argument. And finally, you should specify which UBI volume has to be mounted on boot using the root= argument. The volume is specified the same way as described above (ubiX_Y or ubiX:NAME).
The following is an example of the kernel boot arguments to attach mtd0 to UBI and mount UBI volume "rootfs":
ubi.mtd=0 root=ubi0:rootfs rootfstype=ubifs"
Another interesting one...
"How do I extract files from an UBI/UBIFS image?
Unfortunately, at the moment there are no user-space tools which can unwrap UBI and UBIFS images. UBIFS cannot be loop-back mounted as well, because it does not work with block devices.
However, there is a hacky way to unwrap UBI/UBIFS images. But you have to make sure you have UBIFS support in your host machine. UBIFS is a relatively new file system and is not supported by all Linux distributions. But at least Fedora 11 does include it.
Let's consider a simple example. Suppose you have an ubi.img file. This is an UBI image, which contains a single UBI volume, which in turn contains UBIFS file-system. In other words, this is an image which was created using the mkfs.ubifs and ubinize tools, just like it is described in this section (the image is created for a 256MiB NAND flash with 2KiB NAND page size and which supports sub-pages). Here is what you can do:
# Create an 256MiB emulated NAND flash with 2KiB NAND page size
# (you should see the new MTD device in /proc/mtd)
modprobe nandsim first_id_byte=0x20 second_id_byte=0xaa \
third_id_byte=0x00 fourth_id_byte=0x15
# MTD is not LDM-enabled and udev does not create device
# MTD device nodes automatically, so create /dev/mtd0
# (we assume that you do not have other MTD devices)
mknod /dev/mtd0 c 90 0
# Copy the contents of your image to the emulated MTD device
dd if=ubi.img of=/dev/mtd0 bs=2048
# Load UBI module and attach mtd0
modprobe ubi mtd=0
# Mount UBIFS
mount -t ubifs /dev/ubi0_0 /mnt/ubifs
Now you have the file-system in /mnt/ubifs. Use the following to get rid of it:
umount /mnt/ubifs
rmmod ubifs ubi nandsim"
"How do I extract files from an UBI/UBIFS image?
Unfortunately, at the moment there are no user-space tools which can unwrap UBI and UBIFS images. UBIFS cannot be loop-back mounted as well, because it does not work with block devices.
However, there is a hacky way to unwrap UBI/UBIFS images. But you have to make sure you have UBIFS support in your host machine. UBIFS is a relatively new file system and is not supported by all Linux distributions. But at least Fedora 11 does include it.
Let's consider a simple example. Suppose you have an ubi.img file. This is an UBI image, which contains a single UBI volume, which in turn contains UBIFS file-system. In other words, this is an image which was created using the mkfs.ubifs and ubinize tools, just like it is described in this section (the image is created for a 256MiB NAND flash with 2KiB NAND page size and which supports sub-pages). Here is what you can do:
# Create an 256MiB emulated NAND flash with 2KiB NAND page size
# (you should see the new MTD device in /proc/mtd)
modprobe nandsim first_id_byte=0x20 second_id_byte=0xaa \
third_id_byte=0x00 fourth_id_byte=0x15
# MTD is not LDM-enabled and udev does not create device
# MTD device nodes automatically, so create /dev/mtd0
# (we assume that you do not have other MTD devices)
mknod /dev/mtd0 c 90 0
# Copy the contents of your image to the emulated MTD device
dd if=ubi.img of=/dev/mtd0 bs=2048
# Load UBI module and attach mtd0
modprobe ubi mtd=0
# Mount UBIFS
mount -t ubifs /dev/ubi0_0 /mnt/ubifs
Now you have the file-system in /mnt/ubifs. Use the following to get rid of it:
umount /mnt/ubifs
rmmod ubifs ubi nandsim"
Similar threads
Top Liked Posts
-
There are no posts matching your filters.
-
1
ubiformat - formats empty flash, erases flash and preserves erase counters, flashes UBI images to MTD devices
Seems like you are erasing the whole image.
