Related
I use splitrom and guessed parameters. but none of them work, in fact, mkrom always reported some zero pointer error and stopped. anyone tried?
I'm using following settings in mkrom:
wincever=4
start1=81740000
size1=00040000
start2=81bc0000
size2=00300000
startbmp=81ec0000
startop=81bc0000
For me it works fine.....
HTH
Stefan
here is what I got
Warning: OS type not detected, you may need to set tounicode variable manually
Integer overflow in hexadecimal number at (eval 4) line 1.
Hexadecimal number > 0xffffffff non-portable at (eval 4) line 1.
write xip block starting at 81740000, with 3 files
Integer overflow in hexadecimal number at makexip.pl line 25.
Hexadecimal number > 0xffffffff non-portable at makexip.pl line 25.
write xip block starting at ffffffff, with 0 files
Integer overflow in hexadecimal number at chainedit.pl line 217.
Hexadecimal number > 0xffffffff non-portable at chainedit.pl line 217.
Integer overflow in hexadecimal number at chainedit.pl line 217.
Hexadecimal number > 0xffffffff non-portable at chainedit.pl line 217.
well, my fault. put too many zeros after the number. now it is working
Hi. This is a message to experts.
Loiking at bootloader in my broken ELFIN, well lets better say death, because even with GOLD CARD couldnt get alive, i found a commnad called wdata. This this the screen result:
==========================================================
Cmd>wdata
Usage:
wdata [StartAddr Len]
Write data to memory(if write to ROM, need erase first).
StartAddr : Start address of memory.
Len : How many bytes will be written.
Length must not more than 0x10000 bytes(buffer limitation).
Write to RAM: 4 bytes(CRC checksum limitation).
1 byte(in user mode).
Write to ROM: 4 bytes(CRC checksum limitation).
2(16-bit)/4(32-bit) bytes(in user mode).
Write to ROM(16-bit data bus): 32 bytes(writebuffer mode).
Write to ROM(32-bit data bus): 64 bytes(writebuffer mode).
Length must be 4 bytes boundary(CRC checksum) if not in user mode.
After command execute, then send out the data to terminal.
Data format: HTCS(4 bytes)+DATA+checksum(4 bytes, if not in user mode)+HTCE(4 bytes).
==========================================================
So the question is. Is there any way of using that command to access the F****** g_cKeyCardSecurityLevel = FF register and modify it?.
Anyone knows whats the memory position of that register?, if so, How can i change it?
Hopping anwsers.
Thanks
Brief synopsis
Bootloader unlock isn't likely. Amazon provide the facility to unlock the bootloader, but there is no way of getting the key.
The program which is locking the bootloader appears to be specific to MediaTek and Amazon, therefore, there isn't any source code.
The partitions with an Android bootimg header are all signed with two Amazon certificates. This includes the Little Kernel (LK) and the kernel itself.
The preloader is custom built for Amazon. The preloader doesn't respond to SP Flash Tool because it's constantly in a reboot loop when in 'META mode'. I presume it's intentional; a different version can however be installed (See 'However...').
However...
@bibikalka has found some strings in tz.img refering to a bootloader unlock. There is an amzn_unlock_verify function in lk too.
There must be a is a way to get the preloader to work properly with SP Flash Tool. However, this won't allow you custom ROMs, just reinstall Amazon's software. The software installed is still verified during the boot process. See this unbrick guide to install a different preloader. The preloader is not signed or checked by the boot process.
There is a small chance some part of the boot process could be fooled.
Downgrade potential
An anti-rollback program appears to have been built in to the bootloader which prevents any attempt at downgrading the software on the device. This is rather irritating, and means that downgrading is almost impossible. Only the preloader seems to be unaffected by this anti-rollback system – so, if you attempted to downgrade, and caused your device to become bricked, then you can restore the version you left.
Note that I vaguely reference to the preloader, uboot and lk collectively as 'the bootloader'.
Original post
I previously had downloaded the 5.0.1 and 5.1.1 LK versions, and thought, why not run these through binwalk?
For the old, 5.0.1 bootloader, putting lk.bin through binwalk gave:
Code:
DECIMAL HEXADECIMAL DESCRIPTION
--------------------------------------------------------------------------------
204256 0x31DE0 SHA256 hash constants, little endian
292292 0x475C4 Android bootimg, kernel size: 0 bytes, kernel addr: 0x5D73255B, ramdisk size: 1869570592 bytes, ramdisk addr: 0x6D692074, product name: ""
330144 0x509A0 Unix path: /mnt/build/workspace/fireos-release_500-patch-build/bootable/bootloader/ufbl-features/project/../features/common_openssl/crypto/
330752 0x50C00 Unix path: /mnt/build/workspace/fireos-release_500-patch-build/bootable/bootloader/ufbl-features/project/../features/common_openssl/crypto/
334248 0x519A8 Unix path: /mnt/build/workspace/fireos-release_500-patch-build/bootable/bootloader/ufbl-features/project/../features/common_openssl/crypto/
339912 0x52FC8 Unix path: /mnt/build/workspace/fireos-release_500-patch-build/bootable/bootloader/ufbl-features/project/../features/common_openssl/crypto/
341028 0x53424 Unix path: /mnt/build/workspace/fireos-release_500-patch-build/bootable/bootloader/ufbl-features/project/../features/common_openssl/crypto/
350360 0x55898 Unix path: /mnt/build/workspace/fireos-release_500-patch-build/bootable/bootloader/ufbl-features/project/../features/common_openssl/crypto/
351732 0x55DF4 Certificate in DER format (x509 v3), header length: 4, sequence length: 1067
353656 0x56578 Certificate in DER format (x509 v3), header length: 4, sequence length: 1069
369736 0x5A448 CRC32 polynomial table, little endian
397548 0x610EC LZMA compressed data, properties: 0x91, dictionary size: 33554432 bytes, uncompressed size: 134217728 bytes
Whilst the 5.1.1 bootloader's lk.bin gave:
Code:
DECIMAL HEXADECIMAL DESCRIPTION
--------------------------------------------------------------------------------
204960 0x320A0 SHA256 hash constants, little endian
293720 0x47B58 Android bootimg, kernel size: 0 bytes, kernel addr: 0x5D73255B, ramdisk size: 1869570592 bytes, ramdisk addr: 0x6D692074, product name: ""
332024 0x510F8 Unix path: /mnt/build/workspace/fireos-ship_511-patch-build/bootable/bootloader/ufbl-features/project/../features/common_openssl/crypto/cry
332628 0x51354 Unix path: /mnt/build/workspace/fireos-ship_511-patch-build/bootable/bootloader/ufbl-features/project/../features/common_openssl/crypto/mem
336096 0x520E0 Unix path: /mnt/build/workspace/fireos-ship_511-patch-build/bootable/bootloader/ufbl-features/project/../features/common_openssl/crypto/asn
341712 0x536D0 Unix path: /mnt/build/workspace/fireos-ship_511-patch-build/bootable/bootloader/ufbl-features/project/../features/common_openssl/crypto/evp
342820 0x53B24 Unix path: /mnt/build/workspace/fireos-ship_511-patch-build/bootable/bootloader/ufbl-features/project/../features/common_openssl/crypto/obj
352064 0x55F40 Unix path: /mnt/build/workspace/fireos-ship_511-patch-build/bootable/bootloader/ufbl-features/project/../features/common_openssl/crypto/x50
353420 0x5648C Certificate in DER format (x509 v3), header length: 4, sequence length: 1067
355344 0x56C10 Certificate in DER format (x509 v3), header length: 4, sequence length: 1069
371656 0x5ABC8 CRC32 polynomial table, little endian
So there you go! The bootloader uses OpenSSL to check the partition against two DER format certificates. Ignore the LZMA header for now; binwalk thinks almost everything is LZMA compressed.
Can you run binwalk with -e and post the 5.1.1 certs here
benwaffle said:
Can you run binwalk with -e and post the 5.1.1 certs here
Click to expand...
Click to collapse
Look at the thread about the 5.1.1 lk.bin in this forum and download the binary so you can run binwalk on it yourself.
Here is the lk.bin file, zipped. You can try and run '-e' on this binary.
The extracted certificates appear to contain format strings for decompression/compression error and debug messages. It doesn't look right. But the top of the files are valid certificate headers (or appear to be to the untrained eye).
Thanks @benwaffle.
Good effort!
I shall note that Amazon must have a way to un-brick the devices with MTK tools, they would not swap motherboards in order to revive them ...
The problem with the public MTK tools that it's even impossible to create a scatter file automatically (read only operation), meaning that the formats are such that MTK tools don't understand:
http://forum.xda-developers.com/fire-hd/help/mtk-tools-people-hopeless-bricks-t3139784
There is also an attempt to look at which partitions change when 5.0.1 goes to 5.1.1, and frankly, it's not many places to hide (only a couple of partitions):
http://forum.xda-developers.com/amazon-fire/help/understand-5-1-1-bootloader-bricking-fix-t3301991
On Fire 2014 I also looked at the strings within the bootloaders, and they had some interesting stuff regarding unlocking:
http://forum.xda-developers.com/showpost.php?p=61288384&postcount=57
I wonder if it's possible to patch the very first thing that boots (preloader), and have it pass the unlocking flags around ? Or is preloader also encrypted fully ?
bibikalka said:
Good effort!
I shall note that Amazon must have a way to un-brick the devices with MTK tools, they would not swap motherboards in order to revive them ...
The problem with the public MTK tools that it's even impossible to create a scatter file automatically (read only operation), meaning that the formats are such that MTK tools don't understand:
http://forum.xda-developers.com/fire-hd/help/mtk-tools-people-hopeless-bricks-t3139784
There is also an attempt to look at which partitions change when 5.0.1 goes to 5.1.1, and frankly, it's not many places to hide (only a couple of partitions):
http://forum.xda-developers.com/amazon-fire/help/understand-5-1-1-bootloader-bricking-fix-t3301991
On Fire 2014 I also looked at the strings within the bootloaders, and they had some interesting stuff regarding unlocking:
http://forum.xda-developers.com/showpost.php?p=61288384&postcount=57
I wonder if it's possible to patch the very first thing that boots (preloader), and have it pass the unlocking flags around ? Or is preloader also encrypted fully ?
Click to expand...
Click to collapse
Thanks @bibikalka!
Yes – Amazon must have a way of flashing firmware. I wonder if there is a JTAG header on the board as well. The Fire HD 6 had a 'JDEBUG' port, as seen in iFixit's teardown photographs: https://www.ifixit.com/Teardown/Kindle+Fire+HD+6+Teardown/29815#s70239
There might be a bootloader unlock then! It might need someone to decompile uboot to see how to trigger the unlock.
I've only managed to get the preloader_prod.img at this moment in time (I haven't taken preloader.img off). The SHA256 hash starts at around 95% (117KB out of 121KB) of the file, according to binwalk.
Hi,
I'm sorry to shatter hopes for bootloader rollback, but I was looking at the strings in preloader_prod.img and found this:
Code:
$ strings images/preloader_prod.img | grep -i rollback
[ANTI-ROLLBACK] Processing anti-rollback data
[ANTI-ROLLBACK] Failed to read block 0
[ANTI-ROLLBACK] PL: %x TEE: %x LK: %x
[ANTI-ROLLBACK] Need to update version
[ANTI-ROLLBACK] Invalid checksum!
[ANTI-ROLLBACK] Checksum validated
[ANTI-ROLLBACK] PL version mismatch!
[ANTI-ROLLBACK] L: %x R: %x
[ANTI-ROLLBACK] Updating PL version
[ANTI-ROLLBACK] TEE version mismatch!
[ANTI-ROLLBACK] Updating TEE version
[ANTI-ROLLBACK] LK version mismatch!
[ANTI-ROLLBACK] Updating LK version
[ANTI-ROLLBACK] All checks passed
[ANTI-ROLLBACK] Updating RPMB block...
[ANTI-ROLLBACK] Unable to update RPMB block (wc)
[ANTI-ROLLBACK] Unable to update RPMB block (write)
[ANTI-ROLLBACK] RPMB block updated
[RPMB] Failed to initialize anti-rollback block
[RPMB] Anti-rollback block initialized
[RPMB] Valid anti-rollback block exists
[ANTI-ROLLBACK] Invalid anti-rollback state, skipping
There is more stuff when looking for rpmb...
A little bit of googling leads to: https://docs.google.com/viewer?url=patentimages.storage.googleapis.com/pdfs/US20140250290.pdf
This doesn't look good at all
These strings might give a bit hope:
Code:
[RPMB] Invalid magic, re-creating...
[RTC] clear rpmb program mode flag in rtc register
So something could be stored in the realtime clock and the device might recover if the RPMB block gets destroyed. I can't find any mention of OTP or fuses in the image.
EDIT: It seems rpmb can be accessed through /dev/block/mmcblk0rpmb. I've uploaded mine (5.0.1) to: http://bork.cs.fau.de/~michael/fire/
It seems to only contain a few ones and many zeroes.
It would be interesting to get the rpmb of a 5.1.1 device to compare:
Code:
$ adb shell
[email protected]:/ $ su
[email protected]:/ # dd if=/dev/block/mmcblk0rpmb of=/sdcard/rpmb.bin
1024+0 records in
1024+0 records out
524288 bytes transferred in 0.093 secs (5637505 bytes/sec)
I would not advise trying to flash the 5.0.1 rpmb to a 5.1.1 device!
Regards,
Michael
stargo said:
Hi,
I'm sorry to shatter hopes for bootloader rollback, but I was looking at the strings in preloader_prod.img and found this:
Code:
$ strings images/preloader_prod.img | grep -i rollback
[ANTI-ROLLBACK] Processing anti-rollback data
[ANTI-ROLLBACK] Failed to read block 0
[ANTI-ROLLBACK] PL: %x TEE: %x LK: %x
[ANTI-ROLLBACK] Need to update version
[ANTI-ROLLBACK] Invalid checksum!
[ANTI-ROLLBACK] Checksum validated
[ANTI-ROLLBACK] PL version mismatch!
[ANTI-ROLLBACK] L: %x R: %x
[ANTI-ROLLBACK] Updating PL version
[ANTI-ROLLBACK] TEE version mismatch!
[ANTI-ROLLBACK] Updating TEE version
[ANTI-ROLLBACK] LK version mismatch!
[ANTI-ROLLBACK] Updating LK version
[ANTI-ROLLBACK] All checks passed
[ANTI-ROLLBACK] Updating RPMB block...
[ANTI-ROLLBACK] Unable to update RPMB block (wc)
[ANTI-ROLLBACK] Unable to update RPMB block (write)
[ANTI-ROLLBACK] RPMB block updated
[RPMB] Failed to initialize anti-rollback block
[RPMB] Anti-rollback block initialized
[RPMB] Valid anti-rollback block exists
[ANTI-ROLLBACK] Invalid anti-rollback state, skipping
There is more stuff when looking for rpmb...
A little bit of googling leads to: https://docs.google.com/viewer?url=patentimages.storage.googleapis.com/pdfs/US20140250290.pdf
This doesn't look good at all
These strings might give a bit hope:
Code:
[RPMB] Invalid magic, re-creating...
[RTC] clear rpmb program mode flag in rtc register
So something could be stored in the realtime clock and the device might recover if the RPMB block gets destroyed. I can't find any mention of OTP or fuses in the image.
EDIT: It seems rpmb can be accessed through /dev/block/mmcblk0rpmb. I've uploaded mine (5.0.1) to: http://bork.cs.fau.de/~michael/fire/
It seems to only contain a few ones and many zeroes.
It would be interesting to get the rpmb of a 5.1.1 device to compare:
Code:
$ adb shell
[email protected]:/ $ su
[email protected]:/ # dd if=/dev/block/mmcblk0rpmb of=/sdcard/rpmb.bin
1024+0 records in
1024+0 records out
524288 bytes transferred in 0.093 secs (5637505 bytes/sec)
I would not advise trying to flash the 5.0.1 rpmb to a 5.1.1 device!
Regards,
Michael
Click to expand...
Click to collapse
How interesting. Thanks @stargo! I've updated the OP accordingly to your findings. Yes, it seems more complex than previously thought. I'll upload my 5.1.1 rpmb binary soon.
Hi there! As se en within I read mtk is a very hard platform to work with, because they are very closed, and they hardly ever release any source, so most Roms are ports of a similar decide. I'll have a search for a device with this same soc to ser if i can come back with related info. That's why I'm surprised we have cm here!
Hello,
after upgrade to Android 6 the build in Camera app on my Galaxy S5 started to create incorrect JPG files from time to time. When using jpegtran (jpegclub.org/jpegtran/) or for example compare.exe from ImageMagick - it displays "Invalid SOS parameters for sequential JPEG" message for such images.
Image examples: cichas.sweb.cz/S5/
jpegtran debug output example:
c:\test>jpegtran.exe -debug -copy all 1.jpg 1_1.jpg
Independent JPEG Group's JPEGTRAN, version 9b 17-Jan-2016
Copyright (C) 2016, Thomas G. Lane, Guido Vollbeding
Start of Image
Miscellaneous marker 0xe1, length 776
JFIF APP0 marker: version 1.01, density 59x59 2
Define Quantization Table 0 precision 0
Define Quantization Table 1 precision 0
Start Of Frame 0xc0: width=5312, height=2988, components=3
Component 1: 2hx2v q=0
Component 2: 1hx1v q=1
Component 3: 1hx1v q=1
Define Huffman Table 0x00
Define Huffman Table 0x10
Define Huffman Table 0x01
Define Huffman Table 0x11
Define Restart Interval 4
Start Of Scan: 3 components
Component 1: dc=0 ac=0
Component 2: dc=1 ac=1
Component 3: dc=1 ac=1
Ss=0, Se=0, Ah=0, Al=0
Invalid SOS parameters for sequential JPEG
End Of Image
Click to expand...
Click to collapse
My question is if it is only problem of Samsung so I should report to them or this is something common on Marshmallow?
I am using jhead for automatic loseless image rotations but it do not work due to the jpegtran problem.
This all started out in a Glowlight 4 (7.8", 2019) thread: https://forum.xda-developers.com/nook-touch/general/glowlight-plus-7-8-2019-t3934677
An SD card was soldered to test points on the circuit board of a Glow4 to allow for extra storage.
Since it looks like this same technique should work on Glow2 & Glow3 I've broken the thread out here.
The Glow4 has test points labelled by function and has been tested and proven to work with SD cards.
http://www.temblast.com/blogs/glow4/blog.htm#sdcard
The Glow3 has test points labelled by function and has not yet been tested.
The Glow2 has test points, but they are not labelled by function.
I will try to "wiggle" out the pinout soon.
Since the only difference between the models will only be wiring, I suspect that the bulk of this thread will be on configuration and use.
I wiggled the Glow2, the pinout for SD2 is:
TP159 D0
TP160 D1
TP161 D2
TP162 D3
TP163 Cmd
TP164 Clk
TP165 /CD
TP165 VDD
TP167 Gnd
The Glow3, while it's labelled, seems to be on SD3, which is not configured.
I'm still looking at this.
Thanks! I look forward learning more about mounting the sdcard and editing fstab etc.
One more question: Does this method have any restriction on the size of the sdcard and how it's formated? Many old(er) android devices with external storage can only take sdcard of size up to 32Gb, and (independent of that) sometimes people are told to format the sdcard using the device itself, but other times we're suppose to format it in advance (fat32? ext4?).
THANKS!
case-sensitive said:
Does this method have any restriction on the size of the sdcard and how it's formated?
Click to expand...
Click to collapse
This is not so much a method as simply putting in an option that they couldn't be bothered with.
I don't have anything bigger than 16GB on hand.
32GB is the limit for SD 2.0 spec.
Most of the 4GB to 16 GB cards that I have tried are SD 3.0 spec.
You can see this with mmcinfo in uboot.
Formatting things VFAT is only useful if you want to use UMS.
I wouldn't recommend that, VFAT is old and stupid and there are issues with timezones on timestamps.
ext2 is kind of the logical choice.
mkfs.ext2 is included in busybox for formatting.
TLDR: This works on the Glow2 & Glow4 relatively easily.
On the Glow3 you'd need to sacrifice the WiFi to make it work. This works on the Glow3, but you need a modified kernel and a hwcfg change.
http://www.temblast.com/blogs/glow2/blog.htm
http://www.temblast.com/blogs/glow3/blog.htm
http://www.temblast.com/blogs/glow4/blog.htm
Apparently there is already a default place for external SD cards: /mnt/media_rw/extsd
This has a link from /storage/extsd
Since the directory already exists you don't need to modify /init.rc
If you want to use vfat formatted disks and have them hot swappable you don't even have to modify /fstab.E70Q50
My choice is to use an ext2 formatted disk and since it will be internal and not swappable, I don't need or want vold, the volume daemon.
You need to tweak /fstab.E70Q50 (get rid of any line that mentions "extsd").
Code:
/dev/block/mmcblk1p1 /mnt/media_rw/extsd ext2 defaults defaults
You can split the SD card into separate partitions if you want.
You'd have to add some more entries in /fstab.E70Q50 and some mkdirs in /init.rc
For partitioning/formatting cards:
Code:
# busybox fdisk /dev/block/mmcblk1
d [color=red]<-- delete partition[/color]
n [color=red]<-- new partition[/color]
w [color=red]<-- actually write the changes[/color]
#busybox mkfs.ext2 /dev/block/mmcblk1p1
Be very careful when you are talking about mmcblk? and mmcblk?p?
case-sensitive said:
Many old(er) android devices with external storage can only take sdcard of size up to 32Gb...
Click to expand...
Click to collapse
Code:
[email protected]_6sl:/ # df
Filesystem Size Used Free Blksize
...
/mnt/media_rw/extsd 114.4G 20.0K 114.4G 4096
...
[email protected]_6sl:/ # mount
...
/dev/block/mmcblk1p1 /mnt/media_rw/extsd ext2 rw,relatime,errors=continue 0 0
On the Glow2 I ran into a hiccup.
I soldered some 30 gauge wire directly to the micro SD card.
The SD2 is there and fine, but the NtxHwCfg (at least on mine) had to be patched.
Code:
# dd if=/dev/block/mmcblk0 of=/sdcard/hwcfg skip=1024 count=1
This will get you a 512 byte file.
Look at the byte at hex address 0x4f
For the SD card to work this value must be 0x02 (it was 0x00 on mine)
Be very careful modifying the file and writing it back to the internal SD:
Code:
# dd if=/sdcard/hwcfg of=/dev/block/mmcblk0 seek=1024 count=1
Hey! It says "skip" in the first example and "seek" in the second. I warned you!
Well, more sloppiness on NTX/B&N's part.
*.rc files are organized by board names
Usually they shovel the files into the ramdisk.
This means that you have bunches of useless files that aren't used by your hardware.
The Glow2 is a E60QD0 board, the Glow3 is a E60QQ0 board, the Glow4 is a E70Q50 board.
The init.<board>.rc file should load the fstab.<sameboard> file.
On the Glow2 (at least mine) they did sloppy copy/paste and the init.E60QD0.rc loads fstab.E60Q50
I edited init.E60QD0.rc to load fstab.E60QD0
(Then made sure that fstab.E60QD0 had the correct contents.)
Likewise, init.<board>.usb.rc is sloppy.
They don't use the approved syntax of ${ro.serialno}, but instead use $ro.serialno
I get tired of the warnings in the console log.
Also, a lot of redundant junk (the VID/PID stuff can be moved to the "on boot" section).
If you are using a Glow2 and you just installed the 5.0 update and you had previously modified the hwcfg,
then you will have to set it back to the original version to allow the added SD card to work properly.
See: https://forum.xda-developers.com/showpost.php?p=80114208&postcount=623
I had previously said that an SD card and WiFi were not compatible on the Glow3.
It turns out that it's a bit more complicated.
SD2 is the WiFi interface.
SD3 goes to the test points.
The software currently has the WiFi enable/disable switching the SD3 interface, which is wrong.
I've got the hardware itself working
Code:
eBR-1A # mmcinfo
Device: FSL_USDHC
Manufacturer ID: 27
OEM: 5048
Name: SD32G
Tran Speed: 25000000
Rd Block Len: 512
SD version 3.0
Clock: 50000000
High Capacity: Yes
Capacity: 31104958464 Bytes
Bus Width: 4-bit
Boot Partition for boot: No boot partition available
Now I just have to fix the software.
Ok, so I've patched the kernel to make this work on the Glow3.
This also needs a change to the ntxcfg. You can do that with dd or some other tool.
Is anybody ready for this? Do you have the soldering iron warmed up?
Code:
/mnt/media_rw/extsd 28.5G 20.0K 28.5G 4096
I've got to make a version of the image without my stuff in it.
I usually don't like heavily modded images.
The one thing I put in is a rooted adbd.
So, who's ready for the glow3?
You need a new kernel.
If you have access to fastboot you can test drive it with "fastboot boot p1mod.img".
Later you can "fastboot flash boot p1mod.img" to make it permanent.
If you don't (and you're brave and have a good recovery) you can "dd if=p1mod.img of=/dev/block/mmcblk0p1"
You will need to patch the NTX hwcfg.
If this is patched but you are still running the old kernel the WiFi will probably not work, but the glow3 will still be functional.
Code:
# dd if=/dev/block/mmcblk0 skip=1024 count=1 of=/sdcard/hwcfg
[color=red]Use your favorite hex file editor either on of off the glow3 to change address 0x4f from 0x02 to 0x00.
modfile hwcfg 4f 00[/color]
# dd if=/sdcard/hwcfg seek=1024 count=1 of=/dev/block/mmcblk0
If you have access to the u-boot command line you can do it there instead:
Code:
eBR-1A # mmc read 910000 400 1
MMC read: dev # 0, block # 1024, count 1 ... 1 blocks read: OK
eBR-1A # mm.b 91004f
0091004f: 02 ? 00
00910050: 01 ? q
eBR-1A # mmc write 910000 400 1
MMC write: dev # 0, block # 1024, count 1 ... 1 blocks write: OK
eBR-1A #
So, if you get through with all this and reboot it should boot up just fine.
There is a rooted adbd in there so that should not be a problem.
The fstab has been modified to mount your new SD card.
Since that is probably still the original filesystem it will not mount correctly.
You can do an "ls -l /dev/block" and see both mmcblk1 and mmcblk1p1.
You probably noticed that your old /sdcard is empty.
This is an artifact of the fstab not finishing and therefore the nonencrypted is not triggered nor the late_start.
Just do a "start sdcard" and the /sdcard will populate.
So now, just do a "busybox fdisk /dev/block/mmcblk1" to repartition and a "busybox mke2fs /dev/block/mmcblk1p1".
The fstab presumes ext2, a reasonable choice for something used as big storage. If not, just change it.
Reboot and everything should be good.
Good luck.
I've been talking about the NTX hardware configuration, but I don't think that I mentioned or released the utility that I use to dump it.
Availible in the signature, there is NtxHwCfg which can dump or compare NTX configurations.
There is a version for Win32 and one for Android.
http://www.temblast.com/android.htm
It's interesting that the B&N updates don't modify the NTX config.
The Glow2 has version 2.5 vs. the Glow3 with 2.8 vs. the Glow4 with 3.1!
So that means that the u-boots all have to be different.
Code:
C:\>ntxhwcfg hwcfg3 hwcfg4
0b Version 2.8 3.1
0f Size 65 70
10 PCB E60QQ0 (69) E70Q50 (84)
12 AudioCodec No (0) ALC5672 (6)
14 Wifi RTL8189 (8) RTL8723DS (14)
15 BT No (0) RTL8723DS (8)
17 TouchCtrl neonode_v2 (8) ektf2132 (9)
...