I merged the latest B&N 1.4.2 code into my 2nduboot git repository on github: https://github.com/bauwks/Nook-Tablet
It still compiles and works on my 16GB NT and others have have successfully booted the 8GB NT model.
The instructions for building are the same as before:
cd distro/u-boot
PATH=/usr/local/arm-2010q1/bin:$PATH
make nt2ndboot_sd_config
make
./tools/build_nt_2ndboot_img.py -o test.img u-boot.bin
cp test.img /media/boot/flashing_boot.img
For those of you that wish to try it without messy compilers, this zip file (http://dl.dropbox.com/u/40331061/bauwks-boot-1.4.2.zip) contains:
MLO from 1.4.2
u-boot.bin from 1.4.2
flashing_boot.img <- the 2nd uboot
Unzip it to the root directory on an SD card, drop in a boot.img you want to test and go. If you see the box then it's booting off the SD card and should then load your boot.img.
Great job bauwks!
Someone with an 8 gig model please test this. If it works, I can begin working on a resurrection solution for the NT 8gig.
FWIW "Cyanoboot" (w/menu and all that) has been tested and works w/512 model as well.. stay tuned.
Incidentally, my tester did seem to indicate that sd card boots need to be tethered. FWIW
so going off of what i have read heres what ive gotten so far.
format the sd card to fat32 and make sure the flags for boot and lba are on.
transfer the files to the root directory of the card (im assuming this doesnt mean try to write any of the image files to the card).
put the card in the nook.
press the power button and it should boot from the sd card.
this is everything that i have done and the device wont power on while the card is in the slot but i can take it out and it works fine.
am i doing something wrong?
anyone else have this issue?
EDIT: booted after i changed the partition size to 50 mb, but it didnt change or add anything.
just for clarification. Even if this allows boot and root from SD card, people should still not be using this new found access to flash roms designed for the 16gb on the 8gb? I say this because, last I read the acclaim update bricked the 8gb tablet.
that could be mine, but the tech at b&n says it's hardware problem so I'm not too sure. the flash was going well half way and when I stepped away for a couple minutes and came back to find it bricked.
albertwertz said:
just for clarification. Even if this allows boot and root from SD card, people should still not be using this new found access to flash roms designed for the 16gb on the 8gb? I say this because, last I read the acclaim update bricked the 8gb tablet.
Click to expand...
Click to collapse
Actually, I believe if the kernel is 1.4.2, there should be no problems and CM for the nook tab should have 1.4.2, we would need gonce to come in and verify though.
albertwertz said:
just for clarification. Even if this allows boot and root from SD card, people should still not be using this new found access to flash roms designed for the 16gb on the 8gb? I say this because, last I read the acclaim update bricked the 8gb tablet.
Click to expand...
Click to collapse
As long as the bootloader and kernel are based on the latest kernels and such there shouldn't be a reason that both devices can't run the same roms. The issue with the acclaim update is that it flashes the bootloader/kernel stuff from 1.4.0 which doesn't take into account the variances between both devices. Since the 1.4.0 bootloader doesn't know how to take into account the 512 memory you get a bricked device. If it were possible to create an acclaim update with the newest 1.4.2 bootloader/kernel and a 1.4.0 file system except for a couple of possible driver related changes the 1.4.0 file system would work fine on the device.
However, as long as we stick to the same guidelines that BN will, any rom we release should work just as effectively on both devices. This is because BN has designed the latest BNOS to run on both devices so that they only have to release one update file in the future as opposed to support for two devices with so few differences between them. As long as we take into consideration both devices by using the latest bootloader/kernel sources, it should work on both devices without a hitch.
I am sorry to sound so dumb but I came to the party late. (Just bought the 8gb NT yesterday.)
I did create the 50meg partition and loaded the files to it. It boots to the box but I am uncertain of where to go from here. I have tried to find related threads but I have not been successful.
Please be kind.. ;-)
So far this is the only thing that has been release for the 8gig. I haven't seen any CWM or 1.4.2 ROMs yet. I know that they are currently working on CM7 for 8gig and an Ubuntu recovery.
raywaldo said:
I am sorry to sound so dumb but I came to the party late. (Just bought the 8gb NT yesterday.)
I did create the 50meg partition and loaded the files to it. It boots to the box but I am uncertain of where to go from here. I have tried to find related threads but I have not been successful.
Please be kind.. ;-)
Click to expand...
Click to collapse
@bauwks: The boot.img you provide does not boot completely on the 8GB tablet; it reboots abruptly after /system is mounted. Upon further investigation the culprit appears to be the files /manifest00 and /manifest01 in the ramdisk in boot.img, which contain (what I would assume to be) checksums or signatures of a large number of files under /system. The /init binary seems to include a B&N-specific "feature": it crashes if any of the files listed in /manifest00 and /manifest01 has a different checksum on disk than the checksum specified in /manifest00 or /manifest01. There're a number of differences between the /manifest00 and /manifest01 included in the boot partition of the 8GB version and those in your boot.img (meaning that the system files themselves are different on the 8GB than on the 16GB), which is what causes /init to crash on the 8GB NT, resulting in a reboot.
The simple solution is to delete everything in /manifest00 and /manifest01, because /init only verifies the checksums of files listed in /manifest00 and /manifest01, and will happily ignore everything else. I zeroed out the two files in your ramdisk, rebuilt boot.img and can boot perfectly into the stock software.
This mechanism is really evil on the part of B&N. To modify an Android system file (I discovered this when trying to replace /system/framework/framework.jar), for instance to apply a skin or enable copy & paste, you would need to modify /manifest00 or /manifest01. To modify /manifest00 or /manifest01, you would then need to flash a new boot partition. But to flash a new boot partition, you would need to circumvent the locked bootloader (which you have done - hats off to that). This is the most locked-down Android device I've ever played with.
jichuan89 said:
@bauwks: The boot.img you provide does not boot completely on the 8GB tablet; it reboots abruptly after /system is mounted. Upon further investigation the culprit appears to be the files /manifest00 and /manifest01 in the ramdisk in boot.img, which contain (what I would assume to be) checksums or signatures of a large number of files under /system. The /init binary seems to include a B&N-specific "feature": it crashes if any of the files listed in /manifest00 and /manifest01 has a different checksum on disk than the checksum specified in /manifest00 or /manifest01. There're a number of differences between the /manifest00 and /manifest01 included in the boot partition of the 8GB version and those in your boot.img (meaning that the system files themselves are different on the 8GB than on the 16GB), which is what causes /init to crash on the 8GB NT, resulting in a reboot.
The simple solution is to delete everything in /manifest00 and /manifest01, because /init only verifies the checksums of files listed in /manifest00 and /manifest01, and will happily ignore everything else. I zeroed out the two files in your ramdisk, rebuilt boot.img and can boot perfectly into the stock software.
This mechanism is really evil on the part of B&N. To modify an Android system file (I discovered this when trying to replace /system/framework/framework.jar), for instance to apply a skin or enable copy & paste, you would need to modify /manifest00 or /manifest01. To modify /manifest00 or /manifest01, you would then need to flash a new boot partition. But to flash a new boot partition, you would need to circumvent the locked bootloader (which you have done - hats off to that). This is the most locked-down Android device I've ever played with.
Click to expand...
Click to collapse
Thanks a lot for your detailed analysis jichuan89. I'm kind of surprised the checksums don't match because I took the original boot.img straight out of B&N's 1.4.2 release zip file. Well, at least I know that the bootloader is working on the 8GB model.
odd... I just booted this on my NT 16G...
Code:
Texas Instruments X-Loader 1.41 (Nov 11 2011 - 17:05:18)
Start not on PWRON, skipping power button check.
mmc read: Invalid size
Starting OS Bootloader from MMC/SD1 ...
U-Boot 1.1.4-elation1.4.3_1.4.3.3001^{} (Feb 15 2012 - 18:31:19)
get_sdram_size: 1073741824
Load address: 0x80e80000
DRAM: 1024 MB
Using default environment
In: serial
Out: serial
Err: serial
hw_status 0x23 vbus_status 0x80
MAX17042+UBOOT: battery type=LG
MAX17042+UBOOT: gas gauge detected (0x0000)
MAX17042_STATUS (00h) is 0x0000
MAX17042+UBOOT: BATTERY Detected!
MAX17042+UBOOT:WARM BOOT
No valid max17042 init data found, assume no battery history
uboot verify: 1d CONFIG is 2210 ; should be 2210 & 0xFDFB
uboot verify: 2a RELAXCFG is 083b ; should be 083b
uboot verify: 29 FILTERCFG is 87a4 ; should be 87a4
uboot verify: 28 LEARNCFG is 2456 ; should be 2406 & 0xFF0F
uboot verify: 18 DesignCap is 205c ; should be 205c
uboot verify: 12 Vempty is 7d5a ; should be 7d5a
uboot verify: 25 TEMPLIM is 2305 ; should be 2305
uboot verify: 2b MiscCFG is 0810 ; should be 0810 & cc1f
uboot verify: 2c TGAIN is e3e1 ; should be e3e1
uboot verify: 2d TOFF is 290e ; should be 290e
uboot verify: 2e CGAIN is 4000 ; should be 4000
uboot verify: 2f COFF is 0000 ; should be 0000
uboot verify: 37 FCTC is 05e0 ; should be 05e0
MAX17042+UBOOT: warm config is okay
hw_status 0x23 vbus_status 0x80
Identified DVT or newer, using its charging GPIOs
Disable charging
Powering off!
hrm... nevermind... my device won't power up on even stock right now... it could be low on battery, but oddly it is showing green on the charger.
bauwks said:
I'm kind of surprised the checksums don't match because I took the original boot.img straight out of B&N's 1.4.2 release zip file.
Click to expand...
Click to collapse
I totally agree. A diff between your /manifest00 and the 8GB's /manifest00 shows that the userspace on the 16GB and the 8GB versions are completely different; core Android system libraries like /system/framework/framework.jar, /system/framework/core.jar, /system/framework/ext.jar, /system/framework/core.jar and so on are all different in the two ROMs:
Code:
$ diff nook_16gb_boot/ramdisk/manifest00 nook_8gb_boot/ramdisk/manifest00
160,187c160,187
< /system/framework/ime.jar:0208a82881c097c787c49c40fdb4679487b4b2e9
< /system/framework/framework.jar:540d575dd8b88dceaff9931f5169508f73f53ce8
< /system/framework/input.jar:a52eb0ba70b8f6a0a5e4035ccc49c2a98ed95dd6
< /system/framework/monkey.jar:08e7508dfaa10f8c0eb80fa6abff6e69fb283c80
< /system/framework/javax.obex.jar:5c5685865ac196e0b7e487b145a6e112e695a257
< /system/framework/android.test.runner.jar:6c795691eb3990362e3cd08bf0babe2403bdac73
< /system/framework/am.jar:4d015820c353ad5e92942cc5bce25e431942b94d
< /system/framework/com.bn.cloud.jar:35992cbd24e29ce5366d90128733cae01c2314ce
< /system/framework/com.bn.app.displayinfo.jar:56a0d6a43c55a930d6141444140a10f44dc775f0
< /system/framework/services.jar:4f50684204b449ab45566e86a5a7573d9bedc8d3
< /system/framework/pm.jar:ab289af9add3be4907c2c51fc19bc64021a00836
< /system/framework/com.bn.app.deviceinfo.jar:6eb25c7ec0afa72f123983be3767abd90aef8823
< /system/framework/sqlite-jdbc.jar:c2f75237682f87add7c0ff07c0b844666941c17d
< /system/framework/core.jar:0f8b49f7b38625dc9354235464edd49070f5883a
< /system/framework/svc.jar:b3db35986ceee4e035963648fb66ae8072708e25
< /system/framework/com.bn.authentication.jar:612168ccd4e724e7aa08d2b10d7522b52e1ab4e6
< /system/framework/bncloudapi.jar:46ee63bcd922d52dde46a61377633d76c1cd3ea9
< /system/framework/ext.jar:b9f34ae936d1d2cc1a2d37d8a645e59d393d71d3
< /system/framework/com.bn.app.crypto.jar:f30292d95d4834ddd74d2076ff4352f70893fd02
< /system/framework/com.bn.gpb.jar:6a6c0ba81cf0edb2eb23d5cadcd78dace38bc98e
< /system/framework/core-junit.jar:ef8c3aa523400df6ed0c74a03a1565765fe2acc1
< /system/framework/com.android.location.provider.jar:8d5c848effb81aeb001dfc18b061414b48fd46ef
< /system/framework/com.bn.provider.utils.jar:0cc256eff7b6e0f268a130ddf6bf744e468505e0
< /system/framework/bouncycastle.jar:eaf8716aecb7b5c5404cdd0dc945a0ac5546f76e
< /system/framework/bmgr.jar:cc90fb658bd9373841b23d4a68bb04602be278bd
< /system/framework/com.bn.service.devicemanager.jar:833fca513552ce073f6a28d22fc7f185538b80c4
< /system/framework/com.bn.policymanager.jar:95d54490b9e148385670e836651b0685058cb433
< /system/framework/android.policy.jar:98af166741dd0a8ab1964584e37cbc4c7e825fcb
---
> /system/framework/ime.jar:27146e528c683df58b76492eaab8cf02f5310f1b
> /system/framework/framework.jar:636c3015a7f6e5975e84cc523b578aaeffa45454
> /system/framework/input.jar:21833f73ecd9ccd868cbec6733607fda36bffe22
> /system/framework/monkey.jar:de98f6b9f43dfc30029e240765d56f8284498d39
> /system/framework/javax.obex.jar:616ed1d68673333a9b05b69dc13171d971006ed2
> /system/framework/android.test.runner.jar:edbc28be81077514e6cdedd5018a9cd741622da8
> /system/framework/am.jar:3aed3895f63fb27309dba486ae645f6b3eb447f6
> /system/framework/com.bn.cloud.jar:8182d5d308a46b277a03775c473bf86c3e33b73b
> /system/framework/com.bn.app.displayinfo.jar:858074aa9ec095d8ed4a6e7e880ab376a52ce271
> /system/framework/services.jar:fa3808bcbce9b64fa3cdc1adc322ff783729ef63
> /system/framework/pm.jar:47c08c0de507bd2a5ea71a43004d6ad5f220c986
> /system/framework/com.bn.app.deviceinfo.jar:c3b261f713cd1cd78095d21a53ea5df54cf874dc
> /system/framework/sqlite-jdbc.jar:90a05ffc8aa06c937e0107340af211b9166b204e
> /system/framework/core.jar:4d34e393d8ab0b8f544405ec833af355a5670192
> /system/framework/svc.jar:98aef5fabe53a0771010e83c7e8cb6e1d69aeeb8
> /system/framework/com.bn.authentication.jar:95be7d84b4fddbbcef417e5c1ab3410d9c1cba41
> /system/framework/bncloudapi.jar:9207bdd53e52ee1d721244c4d8eaad7aba828429
> /system/framework/ext.jar:2d582e4793457a35e19e429d5bbac746fc72b2ef
> /system/framework/com.bn.app.crypto.jar:26d118312120b661612ee7335673923064567d63
> /system/framework/com.bn.gpb.jar:739e7ce38c94615130ce3780085496553e6656c3
> /system/framework/core-junit.jar:80a4040d76cd04d85a8fe16e7910365f5994d378
> /system/framework/com.android.location.provider.jar:08628ff32fe0d9ea23e2ae362803cad3e26b6425
> /system/framework/com.bn.provider.utils.jar:5897fdec7612a796824475454414d39dd0e5a6f6
> /system/framework/bouncycastle.jar:8d2cee2830d46e557c52eeea7de21b6abfba1529
> /system/framework/bmgr.jar:89cc7d926e9bdb36e7fe1adeccf0d140fe5d4b90
> /system/framework/com.bn.service.devicemanager.jar:066da8a087d199239e2dc96fd2aa4ab3c364f5c1
> /system/framework/com.bn.policymanager.jar:a7e953e9e550a5ffce357007a97b82c753063b99
> /system/framework/android.policy.jar:48dd1337c5e45830e5d2dc009173cb7622226aad
211c211
< /system/bin/debuggerd:6dea49eb6a8cf831efb459fd73800d319f21050a
---
> /system/bin/debuggerd:9e90dd40168eef36fee2a9cf273146180e4c9135
You're right in saying this is very surprising; I would have thought that the only difference between the ROMs should be the kernel command line in the boot partition.
bauwks said:
Well, at least I know that the bootloader is working on the 8GB model.
Click to expand...
Click to collapse
Well since I based my root method for the 8GB NT on your images (just in case you didn't know), I want to use this opportunity to say a HUGE THANK YOU for everything you've done - esp 2nduboot (just ingenious...wow) and posting these files for the 8GB. You're a god.
I've looked deeper into the /manifest00 + /manifest01 stuff and came across something really strange. I grabbed the official 1.4.2 update archive from and observed that the /system/framework/framework.jar in the update archive, which I assume to be the same as on the 16GB tablet, is indeed different from the same file on the NT 8GB. However, when I extract both files with unzip, I discovered that they have the same content; in addition, the two files also have the exact same length. I would be very curious to know if this is intentional on the part of B&N, and why.
It is not clear to me if this has been verified to work on the NT 8GB model.
Has this been verified?
Thank you!
I have a brand new Nook Tablet 8GB with factory 1.4.2 firmware and the image did absolutely nothing on it. What are the stept again? I copied the three files to the SD card and nothing happens when I turn on the Nook with the SD inserted.
haloway13 said:
It is not clear to me if this has been verified to work on the NT 8GB model.
Has this been verified?
Thank you!
Click to expand...
Click to collapse
I believe it has, as has CyanoBoot.
i have some curious results here... I have a device which does not boot from SD Properly.
Code:
Texas Instruments X-Loader 1.41 (Oct 21 2011 - 14:00:05)
Checking power button state... PRESSED. OK
mmc read: InvaliD size
[ERROR] [SEC_ENTRY] Call to Secure HAL failed!
Could not read bootloader!
X-Loader hangs
The SDCard works in my device, but it does not work in this bricked device...
Any ideas. My mind seems to keep revolving around a modification to e-Fuses??
AdamOutler said:
i have some curious results here... I have a device which does not boot from SD Properly.
Code:
Texas Instruments X-Loader 1.41 (Oct 21 2011 - 14:00:05)
Checking power button state... PRESSED. OK
mmc read: InvaliD size
[ERROR] [SEC_ENTRY] Call to Secure HAL failed!
Could not read bootloader!
X-Loader hangs
The SDCard works in my device, but it does not work in this bricked device...
Any ideas. My mind seems to keep revolving around a modification to e-Fuses??
Click to expand...
Click to collapse
I'm not sure which x-loader (mlo) you're running, but looking at source from 1.41 source as well as 1.42, that line seems to be from cpu/omap4/mmc.c , though I don't see the capital "D" in "InvaliD" the way you've shown me in any source we've been given, which makes me think the mlo has changed (unless you retyped it).
It should be reported like this:
function omap_mmc_read_sect:
printf("mmc read: Invalid size\n");
I'm also not sure if you just copied the flashing_boot.img to that sd card, but you may want to copy mlo over from 1.42 as well, just to be sure.
Hi All,
Wondering if you could help me please... I keep getting this message from time to time, but not constantly.... My setup is as follows...
Device: Samsung Galaxy S2 (i9100 standard, not P or G model)
OS: BeanStalk 5.0.2 (Android Lollipop 5.0.2) and BeanStalk 4.4.4 (Android KitKat 4.4.4) / dualboot
Kernel: Kernel_Dorimanx-V10.44-_18-28_-_26-01_-KK-b2-SGII-I9100.zip (running Build #2, as build #3 was slower and unstable for me)
PIT: 4GB /Data partition on primary OS (Lollipop). When dualbooting, second rom seems to see/work like stock layout of 2GB /Data
Setup: BeanStalk 5.0.2 is primary rom, BeanStalk 4.4.4 is secondary rom. It's the secondary rom I get the errors on.
Should I be concerned about this error message, will it cause long term data corruption and kill my phone...?? Or is this normal under the S2 and dualbooting...? And just need to run a util once in a while...? Could this lead to eMMC BrickBug issue, like on the N7000... as it has a similar chip.
Many thanks, Lister
ERRORS IN PARTITIONS DETECTED
Sun Feb 1 12:54:48 GMT 2015
Version of binaries used:
Segmentation fault
tune2fs 1.42.8 (20-Jun-2013)
Tunning partitions begins...
Device /mnt/tmp/.secondrom/data.img already have has_journal in features.
Device /mnt/tmp/.secondrom/data.img already have dir_index in features.
Device /mnt/tmp/.secondrom/data.img already have journal_data_writeback in default mount options
Device /mnt/tmp/.secondrom/data.img already have 256 Inode size
Tunning partitions ends.
Checking if device has errors...
DEVICE /mnt/tmp/.secondrom/data.img NEEDS DO BE FIX
Sun Feb 1 12:54:48 GMT 2015
Version of binaries used:
Segmentation fault
tune2fs 1.42.8 (20-Jun-2013)
Checking if device has errors...
DEVICE /mnt/tmp/.secondrom/cache.img NEEDS DO BE FIX
Sun Feb 1 12:54:48 GMT 2015
Version of binaries used:
Segmentation fault
tune2fs 1.42.8 (20-Jun-2013)
Tunning partitions begins...
Device /res/dev/system already have has_journal in features.
Device /res/dev/system already have dir_index in features.
Device /res/dev/system already have journal_data_writeback in default mount options
Device /res/dev/system already have 256 Inode size
Tunning partitions ends.
Checking if device has errors...
DEVICE /res/dev/system NEEDS DO BE FIX
Sun Feb 1 12:54:48 GMT 2015
Version of binaries used:
Segmentation fault
tune2fs 1.42.8 (20-Jun-2013)
Checking if device has errors...
DEVICE /dev/block/mmcblk0p1 NEEDS DO BE FIX
Please use Stweaks "FIX DATA ON or OFF" option in the other tab to avoid annoying issues or use "Check and repair file system on every boot" to always check and repair partitions.
It is advised to perform a nandroid or Titanium Backup similar app before fixing corrupt partitions.
Data of app and/or app may be delected if damaged too much!!!
Click to expand...
Click to collapse
Lister Of Smeg said:
Hi All,
Wondering if you could help me please... I keep getting this message from time to time, but not constantly.... My setup is as follows...
Device: Samsung Galaxy S2 (i9100 standard, not P or G model)
OS: BeanStalk 5.0.2 (Android Lollipop 5.0.2) and BeanStalk 4.4.4 (Android KitKat 4.4.4) / dualboot
Kernel: Kernel_Dorimanx-V10.44-_18-28_-_26-01_-KK-b2-SGII-I9100.zip (running Build #2, as build #3 was slower and unstable for me)
PIT: 4GB /Data partition on primary OS (Lollipop). When dualbooting, second rom seems to see/work like stock layout of 2GB /Data
Setup: BeanStalk 5.0.2 is primary rom, BeanStalk 4.4.4 is secondary rom. It's the secondary rom I get the errors on.
Should I be concerned about this error message, will it cause long term data corruption and kill my phone...?? Or is this normal under the S2 and dualbooting...? And just need to run a util once in a while...? Could this lead to eMMC BrickBug issue, like on the N7000... as it has a similar chip.
Many thanks, Lister
Click to expand...
Click to collapse
If there's no problems now, it should be fine to ignore this issue. You could enable fix data and see if this removes this message (it should) but there's really no need to enable it unless you start to see some issues.
Hello all,
I have recevied an old tablet "goClever i102 ( Airis Kira N10020) and it is slow.
Here are it's specifications:
• 10" Wide TFT (1024x600)
• ARM11 up to 1 GHz Processor
• Memory 512 MB DDR2
• Storage Flash 4 GB
• WLAN - LAN 10/100
• mini HDMI - Web-Cam - 4x USB
• micro SD/SD-HC Card Reader
• Dimensions 246.6 x 172.7 x 24.5 mm.
• Weight ~ 0.90 Kg.
• Android 2.3 OS
The manufacturer's page for the device:
http://www.airissupport.com/SupportHome2.aspx?Codigo=N10020
Here are some aditional informations I gathered by openning it:
Processor
========
Infotmic imapx210bm1-80
pcc265 oop-1
1133
Stuff written on the main board
========================
pc1051
ver.1.2
2011/12/14
s-m
940-0
e305905
Some integraded circuits I could not identify
==================================
4x Samsung k4t1g164qf-bce7
Hynix Nand Flash Memory
====================
H27UBG8T2ATR-BC
PARALLEL 8M FLASH T
====================
MCXMX29LV800CBTI-70G
I rooted the device and I posted the instructions here:
http://forum.xda-developers.com/android/help/rooting-goclever-i102-n10020-t3119091
I would like to install on it Arch linux or some other linux core.
I set up a virtual machine with linux, installed a cross-compiler and the toolchain to build for ARMv6 processors and then I tried to build a bootloaded and a kernel for the tablet. It succesfuly built the kernel, just to test the toolchain ,but soon I realized that I could not configure u-boot for this specific processor. I could not find any pre-made configurations files for it. I don't have much knowledge about how to build a kernel or a bootloader.
Could anyone help me regarding this issue or give some instructions how to manually configure u-boot?
PS: I tried to boot on some RasberryPi softwares that I could find on the internet but it did not boot. Also I tried some linux software for the tablets Airis Kira N7000 / N8000 / N9000 that I found here: https://kirbian.wordpress.com/descargas/airis-kira-n7000-n8000-n9000/ ,and booted the kernel for a very short time(it displayed something like uzImage.bin and a loading bar), but then the screen went black with the cursor blinking on the left. After this it remains in this state, nothing loads or changes. After I reboot it, it loads the stock rom (Android 2.3.3)...
Thank you in advance!
The last update of remix 3.0.207 presents the following error or problem and does not allow me to start the system.
early console in decompress_kernel
input_data: 0x0000000001d123b4
input_len: 0x0000000000503357
output: 0x0000000001000000
output_len: 0x0000000001203958
run_size: 0x0000000000e6a000
Decompressing Linux... Parsing ELF... done.
Booting kernel.
[ 0869281] intel_rapl: driver does not support CPU familly 6 model 37.
If someone else has appeared the same error or similar, please let me know XD
I use an HP EliteBook 8440p Core i5, 8GB of RAM and a 120GB SSD and I made a 30Gb partition and I wish I could upgrade my system and receive updates without problems in the future.
What I can do?
Thorous95 said:
The last update of remix 3.0.207 presents the following error or problem and does not allow me to start the system.
early console in decompress_kernel
input_data: 0x0000000001d123b4
input_len: 0x0000000000503357
output: 0x0000000001000000
output_len: 0x0000000001203958
run_size: 0x0000000000e6a000
Decompressing Linux... Parsing ELF... done.
Booting kernel.
[ 0869281] intel_rapl: driver does not support CPU familly 6 model 37.
If someone else has appeared the same error or similar, please let me know XD
I use an HP EliteBook 8440p Core i5, 8GB of RAM and a 120GB SSD and I made a 30Gb partition and I wish I could upgrade my system and receive updates without problems in the future.
What I can do?
Click to expand...
Click to collapse
Same here, on a custom-built desktop, will post full specs when I'll get to my room.
For now, it's on my 4th hard drive, a 3.5" 7200RPM 80GB made by Western Digital.
I have a i3 540 CPU, with 6GB of DDR3 RAM.
Hello guys, I have a problem with this box: the system partition was tempered with (they tried to remove root) and I want to flash a new rom to fix it.
I opened it to check the hardware but the manufacturer have shielded the wifi chipset so I can't read the numbers on it.
Dmesg says:
Code:
dhd_conf_set_chiprev: chip=0x4334, chiprev=3
And I found these files in etc/wifi/
p2p_supplicant_overlay.conf
wpa_supplicant.conf
Folder 40183
config.txt
fw_bcm40183b2.bin
fw_bcm40183b2_apsta.bin
fw_bcm40183b2_p2p.bin
fw_bcm4334b1_ag.bin
fw_bcm4334b1_ag_apsta.bin
fw_bcm4334b1_apsta.bin
fw_bcm4334b1_p2p.bin
nvram.txt
So it's a broadcom4334, right? Too bad I haven't found any rom that clearly states bcm 4334 or 40183 and s905x, except this
Full specification as read from the amazon page @ https://www.amazon.it/gp/product/B0788MX52X/
OS: Android 7.1.2
Bluetooth: 4.0
CPU: AmlogicS905X Quad Core Cortex A53 a 1.5 GHz 64 bit
GPU: Penta-core Mali-450MP
RAM: 2 GB DDR
ROM: 16 GB EMMC
Wifi: IEEE 802.11 a / b / g / n, Dual-Band 2.4G/5G
LAN: 10 / 100M, standard RJ-45
The Motherboard (Aida says it's p212) doesn't have an hidden button, unlike other boxes, but I can boot into recovery using a terminal emulator
Of course I tried reaching to goobangdoo but they haven't replied.
Edit: typos
Edit: updates
I want at least root the box, I found
deamonsu, su, su.bak in system/xbin
su in sbin
Rootchecker says root is not installed properly.
I have the UPDATE&BACKUP and I used it to install:
UPDATE-unSU-signed.zip > deletes nothing
SuperSU-v2.82-201705271822 > bad recovery error
Magisk-v16.0 > failed to find meta-inf/com/android/metadata in update package
Everything failed and I tried from recovery, same thing.
I can still return the box so I'm trying not to install twrp since I don't have the stock recovery.
I'm stuck.