Bootloader cracked and next steps

Search This thread

fattire

Inactive Recognized Developer
Oct 11, 2010
2,281
6,473
www.eff.org
Can I inquire as to what exactly remains for you to work on? Perhaps if you listed what you still needed, someone may have information to get you to your goal quicker?

It's not really so much a matter of being stuck on anything so much a time thing. Partially it's availability of nemith and chrmhoffmann-- but off the top of my head (and from what I've gleaned)-- There's the new egl (I have a driver waiting for testing now), working bluetooth, a bit better stability on sleep, mounting to USB (MTP/PTP), ummm... a few more tests w/the new UB2/Cyanoboot/2ndU-Boot/whatever it ends up being called to make sure it works... and lastly the build system should generate update.zips that can be used with clockworkmod (or else how are ya gonna easily install?)

There's probably more though at the moment I can't remember what.

In the next few days I'd like to write up a little thing on just how the 2nd u-boot will work, as it will do some cool stuff on par with the nook color version (although they don't work 100% the same). I've also had some requests on porting the new boot menu back to nook color's uboot, which is a possibility as well but may be a bit in the future.
 

Indirect

Senior Member
Mar 25, 2011
2,346
3,001
Florida
Ohai! I think I might have an interesting image for you all: Warning, you may "ruin" your pants."

jFMQO13t3Gbub.jpg







Credits to Fattire, I just finally managed to get a good pic from my nexus s 4g camera! :D
 
Last edited:

fattire

Inactive Recognized Developer
Oct 11, 2010
2,281
6,473
www.eff.org
Boo hoo.. stuff for the back burner.

Just a quick update--

So I thought it would be nice to use 1.8 GFX drivers ("actual" ics drivers, rather than the legacy ones being used now) just like on Nook Color. My update from yesterday to the latest 1.8 driver hit a snag. By snag I mean a brick wall. It turns out that while the driver seems to build into the kernel fine for omap4, the available egl binaries that came with it (1.8@789263) are omap3 (nook color, beagleboard, etc.) only. chrmhoffmann tried renaming 'em and stuff, but it didn't work. The pvr driver and the egl blobs have to match exactly.

I knew it was too easy.. sigh. We just don't have the omap4 blobs for this particular driver.

So I looked at what earlier 1.8 drivers are available that we DO have omap4 blobs for and nemith found the tuna omap4 ones-- 1.8@785978. So the blobs are there. The big problem of course is that the driver that comes with it is for the 3.0 kernel. NT has the 2.6.35 kernel. So those don't fit easily.

I spent about 6 hours cramming them together and got it to build a- well I don't know if it's fair to call it a "kernel". It built something. To do it, I'm torquing the driver about 1,000 ways from sunday and I had to strip out some new functionality relating to "workqueues" and GFX idle detection (whatever the hell that is) because it seemed the underlying stuff in 2.6 wasn't good enough for what it wanted and it looked like another rabbit hole of changes if I started chasing it.... I'm pretty sure the blobs however will be expecting this idle stuff to be there.

So I'm really not optimistic it'll work. In fact I think I can say it won't. Regardless, nemith and chrmhoffman aren't around to test it. I'm thinking we should wait for newer omap4 blobs rather than try what I just tried. It was way wrong. It was dirty and immoral and I need a glistening shower.

Want more "meh" news? So bluetooth, right? To set it up on the nook color required a number to put in as the "nshutdown_gpio"-- this is a pin used for setting up the-- eh, I don't want to get technical as i'll probably get it wrong anyway, but to keep it simple we needed this "magic number" to set up bluetooth. On the NC it wasn't hard to find-- it was in the kernel source (line 119) but wasn't used. I haven't found it yet for Nook Tablet.

Thing is, this number is very board-specific. So other OMAP4 devices don't help. Maybe it's lurking around somewhere, but without that gpio it's gonna be hard to get bluetooth working-- it's hard enough if we *DID* have that gpio. Still, from looking around, I have a couple guesses so I'll wait for chrmhoffmann :)

Neat uboot tho, huh?
 

Goncezilla

Senior Member
May 1, 2010
184
528
Washington DC
Just a quick update--

So I thought it would be nice to use 1.8 GFX drivers ("actual" ics drivers, rather than the legacy ones being used now) just like on Nook Color. My update from yesterday to the latest 1.8 driver hit a snag. By snag I mean a brick wall. It turns out that while the driver seems to build into the kernel fine for omap4, the available egl binaries that came with it (1.8@789263) are omap3 (nook color, beagleboard, etc.) only. chrmhoffmann tried renaming 'em and stuff, but it didn't work. The pvr driver and the egl blobs have to match exactly.

I knew it was too easy.. sigh. We just don't have the omap4 blobs for this particular driver.

So I looked at what earlier 1.8 drivers are available that we DO have omap4 blobs for and nemith found the tuna omap4 ones-- 1.8@785978. So the blobs are there. The big problem of course is that the driver that comes with it is for the 3.0 kernel. NT has the 2.6.35 kernel. So those don't fit easily.

I spent about 6 hours cramming them together and got it to build a- well I don't know if it's fair to call it a "kernel". It built something. To do it, I'm torquing the driver about 1,000 ways from sunday and I had to strip out some new functionality relating to "workqueues" and GFX idle detection (whatever the hell that is) because it seemed the underlying stuff in 2.6 wasn't good enough for what it wanted and it looked like another rabbit hole of changes if I started chasing it.... I'm pretty sure the blobs however will be expecting this idle stuff to be there.

So I'm really not optimistic it'll work. In fact I think I can say it won't. Regardless, nemith and chrmhoffman aren't around to test it. I'm thinking we should wait for newer omap4 blobs rather than try what I just tried. It was way wrong. It was dirty and immoral and I need a glistening shower.

Want more "meh" news? So bluetooth, right? To set it up on the nook color required a number to put in as the "nshutdown_gpio"-- this is a pin used for setting up the-- eh, I don't want to get technical as i'll probably get it wrong anyway, but to keep it simple we needed this "magic number" to set up bluetooth. On the NC it wasn't hard to find-- it was in the kernel source (line 119) but wasn't used. I haven't found it yet for Nook Tablet.

Thing is, this number is very board-specific. So other OMAP4 devices don't help. Maybe it's lurking around somewhere, but without that gpio it's gonna be hard to get bluetooth working-- it's hard enough if we *DID* have that gpio. Still, from looking around, I have a couple guesses so I'll wait for chrmhoffmann :)

Neat uboot tho, huh?

Sorry to here that. I'm sure this wall is penetrable though! I will say that Celtic and I have experienced a heck of a lot of missing code from the B&N source as well.

Thanks for all the hard work up this point, don't loose hope! You'll get there. If there is anything we can pitch in on let us know ;)
 

lbcoder

Senior Member
Jan 21, 2009
2,613
98
So I looked at what earlier 1.8 drivers are available that we DO have omap4 blobs for and nemith found the tuna omap4 ones-- 1.8@785978. So the blobs are there. The big problem of course is that the driver that comes with it is for the 3.0 kernel. NT has the 2.6.35 kernel. So those don't fit easily.

Seems to me that the right approach here is to work on getting the proper 3.0 kernel running the thing rather than the obsolete 2.6.35. Its on the "to do" list anyway.... better to tackle that now and work from a proper foundation.
 

fattire

Inactive Recognized Developer
Oct 11, 2010
2,281
6,473
www.eff.org
Seems to me that the right approach here is to work on getting the proper 3.0 kernel running the thing rather than the obsolete 2.6.35. Its on the "to do" list anyway.... better to tackle that now and work from a proper foundation.

Awesome! Thanks for volunteering. I look forward to the new kernel.
 

Loglud

Senior Member
Jul 29, 2011
235
449
Google Pixel 7 Pro
Awesome! Thanks for volunteering. I look forward to the new kernel.
*SARCASM*

No problem. When I have some free time.
FYI: I'm getting married in a few weeks, so won't be able to even LOOK at it for at least 2 months.

Ok so lbcoder:
Compiling a kernel is actually very simple... Its the integration that makes it a pain in the butt. As you may or may not know one of the hardest things was getting the correct wl driver made, and its the things like this that make it relatively difficult. However with that being said, there is a 3.0.8 kernel for this already out there. The Galaxy Nexus uses a 4460 processor, and as long as the modules reference the correct kernel on compilation. With that being said let me *try* and give you a starting point. The first bit will be taking the android_4430BN_defconfig, and porting it over to the kernel that can be acquired by:
Code:
$ git clone https://android.googlesource.com/kernel/omap.git

Once you have the git, you can copy over the android_4430BN_defconfig into the ./arch/arm/configs/. Once that is done then you get the fun task of seeing what options have been made obsolete, and what are still working. make xconfig, and make menuconfig are your friends here. You will have to trouble shoot not only why your getting Compiler errors, but if there's a way to solve them (alot of times certain configs have dependencies).

I have no doubt that someone will do it with time. Maybe it might be you. I know a decent amount about kernels, as I used to work with them in school, so....yeahhhh...
 

fattire

Inactive Recognized Developer
Oct 11, 2010
2,281
6,473
www.eff.org
Holy balls!

Just talked to chrmhoffman...

<chrmhoffmann> root@android:/ # cat /proc/pvr/version
<chrmhoffmann> Version CustomerGoogle_Android_ogles1_ogles2_GPL sgxddk 18 1.8@785978 (release) omap4430_android
<chrmhoffmann> System Version String: SGX revision = 1.2.0


Holy COW! It worked! The 1.8 pvr driver frankenstein actually worked. He had to make a change to the Makefile and another to defconfig, but he now has the 1.8 galaxy nexus/tuna binaries running on NT!

WOW.

TqFmPl.jpg
]
It. ****ing. worked.

Now he can do some stuff he couldn't before, like choose a wallpaper. He's also got OPENGL_RENDERER on, which is great too. I think it could make a diff for battery life.

One thing not in yet is hwcomposer (it wasn't running before though with 1.7), because it's not supported in our kernel and needs a ton more work.. so maybe that's somethign to backport as well. Although I see a 3.0 effort has started, so maybe I should wait. This is video-related...

(In other news, while I was waiting, I added a new altboot/emmc feature to u-boot, but it hasn't been tested yet...)

So New ToDo List:
---------------------

Update to 1.8 glx/pvr driver/get off legacy egl
mount SD/screenshots (same thing)
MTP/PTP USB mounting
microphone (there is one, right?)
stability (should never, ever crash on sleep)
build should generate flashable update.zip
BlueTooth (on hold until gpio is figured out)
hwcomposer/OMX (on hold pending 3.0 kernel)


As for hwcomposer-- here's what it is, according to TI:

During composition, SurfaceFlinger now calls the new Android HWComposer HAL component to enable composition of graphics or video layers using the underlying OMAP system-on-chip (SoC) capabilities. The OMAP platform implementation of HWComposer works with DSSCOMP to dynamically assign layers for composition by the four DSS pipelines available in the OMAP 4 architecture and to configure the output destination for each layer This provides the flexibility to assign the DSS pipes to different content and different display destinations for every display frame.

This distributed composition architecture ensures that SurfaceFlinger can use GPU composition of UI and video for complex UI transitions, while optimizing power during normal composition using DSS pipelines. When required SurfaceFlinger composites UI layers through the GPU to required, provide smooth video rotation, effect filters, or texture mapping to 3D text surfaces. At other times, SurfaceFlinger can conserve energy by reducing GPU computations by sending layers directly to a DSS pipeline, pipeline allowing the GPU to sleep reducing system memory bandwidth sleep, consumption, and eliminating up to 48 percent of MPU load. This load Android enhancement provides a more unified solution for GPU and DSS rendering than was possible with SurfaceFlinger and TI Overlay Object used in Android 2.

So there you have it.
 

O_G

Retired Senior Moderator / Retired ET Admin
Jul 8, 2007
7,236
9,144
Thread Cleaned

Firstly, We have a thanks button, please use it and dont post "Thank you" Also i will not tolerate any bashing of any dev. Please be grateful they are working so hard on this device. Without them we would all be running stock:(

All non Dev posts have again been deleted, Please keep thing on-topic

If the dev bashing continues, i will start issuing infractions​
 
Last edited:

RadicalAns

Member
Mar 11, 2011
18
1
Pittsburgh
make nconfig is much better than menuconfig. It's almost the same as xconfig, but it's text driven. It's a newer option, I'd never used it before but it was available when I compiled the Nook kernel.

Thanks for the tip, Adam. I've been using menuconfig forever and never knew about nconfig till you mentioned it. The symbol lookup is a lifesaver when tracking down dependency issues.
 

chrmhoffmann

Inactive Recognized Developer
Nov 11, 2006
1,007
3,203
Hi,

I am booting from SD card. The big nook tablet partition from emmc is not mounted.
I mounted 1st partition (boot) from sdcard mmcblk1p1 and fat partition from emmc mmcblk0p10.

The big one is ext3 and vold didn't want to mount it.

You're not suggesting I post fake screenshots? :)

Rgds,

Chris
 
P

Pete1612

Guest
According to chrmhoffmann USB storage mount and network data monitoring is now working thanks to Hashcode0f

Send from a better Galaxy
 

Top Liked Posts

  • There are no posts matching your filters.
  • 111
    So now that we have found the leaking crack in the bootloader and proved it's usefulness fat-tire and others are going to start work on a couple of key projects that I could use a little help on.

    This will also keep conspiracy theorists at bay who call me "extremely low IQ male rooster with social development issues" (Also I have no pies)

    Here is how i see the next steps:

    1. Strip down uboot (or other bootloader) and teach it boot from it's own partition.

      For example install 2nduboot in /boot, hijacking the signature check and then setting a 1MB offset to look for the real, unsigned boot.img. Repeat for recovery.

      This is the real hold up and why there is nothing to "flash" as of yet. (still no pies)

    2. Finish CWM. 100% done.
      Completed. See recovery.img here: http://xdaforums.com/showthread.php?t=1440645

    3. Work on CM9 for both SDcard and internal booting

      See Below



    So instead of insulting me. I am looking for some people to help work on these things. We are going to be doing this is private respostories and a private irc channel due to the stupid reward that is out there.

    If you are wanting to work with me. The reward (if we get done by the 22nd) goes to Doctors Without Borders. This is where we should all be donating. No negotiating.

    So PM me or come to #nook-tablet @ freenode
    56
    Reserved

    Bootstrap-loader (Goal #1)
    Here is some more details on my thoughts on bootstrapping /boot and /recovery to boot unsigned images.

    Today we are only bootstrapping with a 2nduboot on the sdcard. This would allow custom kernels and ramdisks on emmc for things like easier root, overclocking, CM9, CWM, etc

    So my thoughts were to bundle together a bootstrap bootloader (uboot obviously will work, but another project that was used for CM on the touchpad called, moboot, may be a nice option to get menus and such) and the unsigned kernel+ramdisk into one binary blob. The unsigned boot.img will be at a well known offset. This will allow us to act as "stock" as possible and do things like. Replace just the kernel with an OC one. Replace just the ramdisk with ro.secure=0, etc.

    fclxG.png


    This would also allow us to completely replace recovery with CWM.

    Current Status: Fattire working on a meny for SD booting. Still discussing best way to do internal booting although using bauwks bootstrap uboots will work for now for emmc but incorporating a possible menu is being looked into. Low Priority


    CM9 (Goal #2) Inprogress
    There is a lot here and I am going to go at it pretty methodically adding one feature at a time. So graphics first, then key/touchscreen, usb gadget, etc.

    There is a number of kernel changes that need to be done:
    • Find the closest git repo/branch/revision from omap zoom to apply B&N changes as a patch.

      This will allow us to a) have revision history b) allow merging up to 3.0 easier

      This is pretty important and if anyone is handy with git and knows of an easy way. Let me know
    • Backport key changes (fattire probably has this already done)
    • Backport usb gadget
    • Backport a hwrenderer compatable sgx drives (maybe move to a 3.x kernel at this point instead)
    • Backport

    Current Status:

    oimg




    Teasers:

    L9lxM.png
    39
    Holy balls!

    Just talked to chrmhoffman...

    <chrmhoffmann> root@android:/ # cat /proc/pvr/version
    <chrmhoffmann> Version CustomerGoogle_Android_ogles1_ogles2_GPL sgxddk 18 1.8@785978 (release) omap4430_android
    <chrmhoffmann> System Version String: SGX revision = 1.2.0


    Holy COW! It worked! The 1.8 pvr driver frankenstein actually worked. He had to make a change to the Makefile and another to defconfig, but he now has the 1.8 galaxy nexus/tuna binaries running on NT!

    WOW.

    TqFmPl.jpg
    ]
    It. ****ing. worked.

    Now he can do some stuff he couldn't before, like choose a wallpaper. He's also got OPENGL_RENDERER on, which is great too. I think it could make a diff for battery life.

    One thing not in yet is hwcomposer (it wasn't running before though with 1.7), because it's not supported in our kernel and needs a ton more work.. so maybe that's somethign to backport as well. Although I see a 3.0 effort has started, so maybe I should wait. This is video-related...

    (In other news, while I was waiting, I added a new altboot/emmc feature to u-boot, but it hasn't been tested yet...)

    So New ToDo List:
    ---------------------

    Update to 1.8 glx/pvr driver/get off legacy egl
    mount SD/screenshots (same thing)
    MTP/PTP USB mounting
    microphone (there is one, right?)
    stability (should never, ever crash on sleep)
    build should generate flashable update.zip
    BlueTooth (on hold until gpio is figured out)
    hwcomposer/OMX (on hold pending 3.0 kernel)


    As for hwcomposer-- here's what it is, according to TI:

    During composition, SurfaceFlinger now calls the new Android HWComposer HAL component to enable composition of graphics or video layers using the underlying OMAP system-on-chip (SoC) capabilities. The OMAP platform implementation of HWComposer works with DSSCOMP to dynamically assign layers for composition by the four DSS pipelines available in the OMAP 4 architecture and to configure the output destination for each layer This provides the flexibility to assign the DSS pipes to different content and different display destinations for every display frame.

    This distributed composition architecture ensures that SurfaceFlinger can use GPU composition of UI and video for complex UI transitions, while optimizing power during normal composition using DSS pipelines. When required SurfaceFlinger composites UI layers through the GPU to required, provide smooth video rotation, effect filters, or texture mapping to 3D text surfaces. At other times, SurfaceFlinger can conserve energy by reducing GPU computations by sending layers directly to a DSS pipeline, pipeline allowing the GPU to sleep reducing system memory bandwidth sleep, consumption, and eliminating up to 48 percent of MPU load. This load Android enhancement provides a more unified solution for GPU and DSS rendering than was possible with SurfaceFlinger and TI Overlay Object used in Android 2.

    So there you have it.
    33
    Hi nemith,

    That is a nice plan which aligned with my plan for modding u-boot to boot off the internal partitions :).

    I pushed some changes into my git repository on github which looks like #1 on your list. git://github.com/bauwks/Nook-Tablet.git

    So for example, to build a 2nd u-boot that will install to the internal flash partition "recovery" and try to load the next stage at offset 256K of the internal "recovery" partition one would do:

    (cd to u-boot directory and switch to second-uboot branch first, then)
    PATH=/usr/local/arm-2010q1/bin:$PATH
    make nt2ndboot_irecovery
    make
    ./tools/build_nt_2ndboot_img.py -f -o irecovery.img u-boot.bin
    dd if=/dev/zero of=irecovery.img bs=1 seek=262143 count=1 # pads to 256K size


    Then, you can cat your irecovery.img and your real recovery.img together and blast them onto the recovery partition.

    There is also a nt2ndboot_iboot config that will do the same, but is used on the "boot" partition.

    I have only done minimal testing with the recovery partition 2nd uboot. I'm about to write a full image onto my recovery partition and see what happens ;)

    Update:

    I flashed my recovery partition with irecovery.img + a random twrp2 image I had and it boots solely from internal flash! No more SD card needed, no more USB connection needed, just holding down power+N

    So now that we have found the leaking crack in the bootloader and proved it's usefulness fat-tire and others are going to start work on a couple of key projects that I could use a little help on.

    This will also keep conspiracy theorists at bay who call me "extremely low IQ male rooster with social development issues" (Also I have no pies)

    Here is how i see the next steps:

    1. Strip down uboot (or other bootloader) and teach it boot from it's own partition.

      For example install 2nduboot in /boot, hijacking the signature check and then setting a 1MB offset to look for the real, unsigned boot.img. Repeat for recovery.

      This is the real hold up and why there is nothing to "flash" as of yet. (still no pies)

    2. Finish CWM. 100% done.
      Completed. See recovery.img here: http://xdaforums.com/showthread.php?t=1440645

    3. Work on CM9 for both SDcard and internal booting

      Started on this one as well. I can boot but haven't got adb working and no graphics (expected at this point)



    So instead of insulting me. I am looking for some people to help work on these things. We are going to be doing this is private respostories and a private irc channel due to the stupid reward that is out there.

    If you are wanting to work with me. The reward (if we get done by the 22nd) goes to Doctors Without Borders. This is where we should all be donating. No negotiating.

    So PM me or come to #nook-tablet @ freenode
    27
    Cm9 may be in limbo right now because the 3.x kernel is being ported over and in the long run will be more benificial than backporting all the ICS features to a 2.3 kernel. I have noticed Indirect has backed out of development and i think Neimith has been occupied wirh a new VM server. For info check out porting over 3.x. Thread in the development section.

    Actually, I decided to risk my sanity for the benefit of the community. Be grateful. :p

    Sent from my Nexus S 4G using xda premium