yashsingh1/xdaforums huggingface dataset:
[Nook Color Android Development] fattire:
New version, new features!

So thanks to some hard work from tonsofquestions, we've got a new version with some very cool improvements!!!

New Stuff

* The UI now dims out any option in the menu that isn't available

* some nice code refactoring that I was too lazy to do ;)

* the "altboot" button combo (up and down volume keys) will now choose regular boot if altboot is set as default (and vice versa)

* You can now enable a previously "hidden" menu option (plus a second configuration menu) by doing the following commands:

adb shell echo "0" > /rom/u-boot.altboot

adb shell echo "0" > /rom/u-boot.device

This unlocks a "built-in" default menu, effectively doing the same thing as the Tablet Tweaks build options, only right from u-boot itself! (If you've set these files to "1" before via Tablet Tweaks, you won't need to do anything. The files just need to have been created is all...)

Please test from various configurations (emmc/sdcard/normalboot/altboot/etc/etc)... I haven't tested this one as thoroughly.. or really thoroughly at all. And thanks to tonsofquestions for the contribution!

cyanoboot-2012-03-28-alpha0-fullofbugs-encore.tar.gz

MD5: a0e1c43a1102786f0dd04688136246b6

(source)
[Nook Color Android Development] awakephd:
I have just stumbled across this thread, and am intrigued. I am running 2 Nook Colors on the CM7.2-RC1 rom, with CWM Recovery. Everything is running great ... so do I need Cyanoboot, and if so, why? What would this give me that I don't now have? Would it replace CWM?

Thanks for any insights. I am certainly interested in any improvements, but I don't want to "fix it if it ain't broke." :)
[Nook Color Android Development] bobtidey:
Cyanoboot is the stage before CWM or normal ROM gets control. It determines what you actually boot into.

In particular, it controls the menus and selections if you power up with the n key pressed. Before cyanoboot you got a rather techy/tricky screen that did allow you to do much the same things. I.e. you could select whether to boot from emmc or SD and you could choose between 3 different boot images (normal ROM, recovery or alternate recovery). Cyanoboot gives you a much nicer laid out and clear screen with some extra features for selecting what you boot into.

So, a very worthwhile improvement in my view but only affects things when you are choosing during power up what you boot into.
[Nook Color Android Development] demonofsteel:
Due to some requests I've received, I made a CWM flashable zip of cyanoboot-2012-03-28 following what I did in the past.

Thanks again to fattire who's working on this an making our Nooks better.

@fattire: Same as last time I did this, I've left intact the "COPYING" file in the zip file. If you feel I should not post this, let me know and I'll remove my post. Thanks for your work.
[Nook Color Android Development] fattire:
No it's cool... but be sure to thank tonsofquestions too as he did the work this time :)
[Nook Color Android Development] fattire:
J4mm3r jumps in with some awesome changes!

Hey all-- so J4mm3r has made some cool contributions to cyanoboot, which has lead to some discussion which I'm moving over here to get everyone's input...

Here's the discussion to date-- I'm sure people will have some opinions, so go to it!

J4MM3R:

FATTIRE:

J4MM3R:

FATTIRE:

J4MM3R:

Okay, so we moved it here (again, from here)...

J4mm3r kicks ass. But aside from that, what do y'all think?

ft
[Nook Color Android Development] 911jason:
Love all the attention the Nook(s) are getting here, so thank you for that!

As my primary use of the Nook Color is as an e-reader, I use it solely in portrait and would really appreciate that be left at least as an option.
[Nook Color Android Development] chilre:
I prefer portrait too :)
[Nook Color Android Development] RETIEF:
portrait

I also prefer portrait.
[Nook Color Android Development] shumash:
+1
[Nook Color Android Development] j8048188:
Landscape for me.
[Nook Color Android Development] bornagainpenguin:
Mark me also in the portrait side of the column.
[Nook Color Android Development] Dj-Gutz:
+1 & Thanks for all involved :)

@Fattire : Any way you can make a touch-friendly version? Like touch recovery?
[Nook Color Android Development] fattire:
Oy!

Just a reminder--- CyanoBoot/u-boot is a bootloader! Don't be deceived by the menu-- there isn't even a kernel loaded yet, let alone any driver for the touchscreen... (at least not one that I know of)...

All it's supposed to do is init some hardware, put a splash on the screen, and load a kernel and ramdisk for the "real" boot. The menu is just to add some flexibility and options, and we're really pushing it now, so I don't think they'll be any touchscreen coming any times soon.. unless you can find, write, or modify a ts driver, in which case it'll still need code to draw/detect touches in particular areas instead of volume keys. Which actually I think would be relatively easy compared to the touch driver issue :)

(Oh, btw, I don't remember if it was mentioned, but if you wanted to see the landscape cyanoboot right now without having to build it yourself, just install the 2.6.32.59-take2 update.zip from the [DEV] thread, as it will install it for ya.)
[Nook Color Android Development] Nburnes:
Imma have to jump on the Portrait bandwagon.
[Nook Color Android Development] bdcrim:
Make room, I am jumping on with you.
[Nook Color Android Development] fattire:
A completely pointless brightness fade in

Well for now we'll stay in portrait I guess. I haven't heard from j4mm3r in a few days.

I had an hour to kill and had this idea that wouldn't-it-be-cool if the backlight brightness kinda ramped up instead of just flashing up to 100%, so I made another slight modification with a 3 second fade up.

This is just a "proof-of-concept".

The brightness ramp up comes up slowly (I only have it go to 200), then it seems to jam up to full for some reason. I have a theory for why-- the LED brightness curve is probably not exactly linear-- maybe as you set the brightness from 0->200 it shouldn't be a smooth progression. Maybe the fade up is only visible to the eye say from 1-40 then it's not a visible change again until from 190-200.

Or something.

Anyway, if you want to try out the "ramping" brightness, here ya go. It's 3 seconds long and totally easy to miss. 'm really including it for someone interested to pick up and take all the way, make it glorious.

Only the diff from the repository source is included to make it small and easy to download. If you want the source, Just git clone the "real" version in the OP (branch "cb") , then "git apply" the .diff included in this .gz and you should be up to date.

cyanoboot-fadein-encore.tar.gz

MD5: 79a054b30efb350726306559e75c1a48

Thanks to eyeballer for doing a quick test just to make sure it worked for him too.
[Nook Color Android Development] leapinlar:
Fattire, I was wondering something about uboot.bin. The Nook has a system where if the recovery flag is set in /rom, it always tries to boot to recovery regardless of what you set in the boot menu. Is this controlled in uboot.bin? The reason I ask is, there is sometimes a problem where the recovery files get corrupted and if the recovery flag is set, it tries to boot to the corrupted recovery and it fails. Since it fails, the recovery flag is not reset and next time it boots, it tries again, bootlooping. If this behavior is controlled by uboot.bin, would it be possible to change it so that the boot menu overrides the flag? That way the user can get out of the bootloop. They could then go to ROM Manager and reinstall CWM over the corrupted recovery. Or if more is corrupted at least they can now boot to a bootable CWM SD.

Sent from my NookColor running ICS and Tapatalk
[Nook Color Android Development] eyeballer:
It's currently not controlled by uboot, but we have been discussing moving to there to prevent this exact issue.
[Nook Color Android Development] fattire:
A challenge for y'all!

Exactly. If someone wants to add a 'clear recovery instruction' option to CyanoBoot, that would be great and it would be fairly simple to implement.

Have you always wanted to contribute back but didn't know where you might be useful? This is an awesome learning opportunity so, c'mon, someone... I issue it as a challenge :)

Here's a quick run-through of how to do it:

Download the latest source. Look at the current menu code. You should now see how the menu is generated. So experiment. First, add a new option... maybe towards the end. Be sure to modify menu.h to match it. Now compile cyanoboot, copy u-boot.bin to your nook color, and see if your option appears in the menu.

Next look at the code that is used to overwrite a file, such as when toggling one of the settings-- okay, I'll just tell you- it's write_u_boot_file(). Now modify it (or create a new function) to rewrite the bcb file with 0s (to remove the recovery instruction). You can also have it clear the bootcount if you like.

Now just make the button press call that function... and you're done! You should only need to change menu.c and menu.h.

Then be a hero: Send me a github pull request with the new feature!

If you want to "claim" this feature, post below. And anyone else who's interested will know to contact you if you want to collaborate.

Alright, challenge issued. Let's see if we have any takers! If it turns out well, I'll move it over to the NT version too!

NOTE: HacDan makes a good point that I'll mention here, which is that if you are testing your experimental u-boot on emmc, and then screw up your u-boot.bin on emmc in a significant way (like if u-boot crashes or whatever), you should have a good, bootable SDcard standing by. That way, you can then replace your experimental u-boots with a known good one (or with the next test) So don't try this programming challenge unless you know how to replace a bad u-boot with a good one.

The steps for restoring your u-boot are as follows:

1. Boot into clockworkmod or cm7 or 9 or whatever with your bootable SD. Have a good u-boot.bin on your computer. you can use the original cyanoboot or make a backup or whatever before you get started.

2. from your pc:

adb shell mkdir -p /data/mnt <-- this creates a place to mount the /boot partition. You can really use any empty directory name.

adb shell mount -t vfat /dev/block/mmcblk0p1 /data/mnt <- this mounts the boot partition to /data/mnt/

adb push u-boot.bin /data/mnt/ <- this pushes the good u-boot.bin in place of the bad one.

adb reboot <- reboot to test it. Be sure to remove the SD card so it boots from emmc.

Or, if you have a update.zip for cm9, you can reflash cm9 from cwm on SD and it should automatically replace u-boot with a good one.
[Nook Color Android Development] leapinlar:
Just a little clarification, when you write the new BCB file, be sure to make sure it is 512 bytes or more. It is the size of that file that determines the flag, not what it contains. If the file is 512 bytes or larger it boots normally. If the file is less than 512 bytes or MISSING, it boots into recovery. That's how the bootloops get started. The file gets deleted somehow.

The option to reset the flag by creating a new one with u-boot is a great idea. I just wish I had the compiling setup to do it.

Sent from my NookColor running ICS and Tapatalk
[Nook Color Android Development] DizzyDen:
If nobody accepts the challenge... i'll see what I can come up with this weekend ;)
[Nook Color Android Development] fattire:
FWIW, I think the bcb file does actually contain the word "recovery" somewhere in it, although I can't remember the details on this. Someone can test it by just booting into recovery, then looking at that file.. u-boot will be able to overwrite with zeros but I don't think is able to create a new file if it doesn't exist already. I stress that last point because I tried creating configuration files previously on the NT version of CyanoBoot and couldn't find the vfat code for new file creation, only modifying an existing file. If the bcb file doesn't exist at all, booting to SD and creating it from a shell or something might be needed. Unless someone can find where to create a new file in u-boot.

Update: This is the line that is used to set the recovery flag for encore (it's in BoardConfig.mk in the encore device tree):

TARGET_RECOVERY_PRE_COMMAND := "dd if=/dev/zero of=/rom/bcb bs=64 count=1 > /dev/null 2>&1 ; echo 'recovery' >> /rom/bcb ; sync

As you can see, this puts 64 zeros followed by "recovery" in the bcb file. It should be "cleared" simply by replacing the file with 1088 zeros.
[Nook Color Android Development] fattire:
How to change default boot behavior.

One last thought--

Anyone interested in changing the default behavior if this file doesn't exist or is empty, look here:

Particularly this stuff around line 318

fatload mmc ${mmcromdev}:2 0x81c00000 BCB 0x1000;\

if itest.l $? -ne 0; then\

echo Missing BCB forces recovery mode;\

setenv bootvar recoveryboot;\

elif itest.l 0x$filesize -lt 0x200; then\

echo Empty BCB forces recovery mode;\

setenv bootvar recoveryboot;\

elif itest.b *0x81c00040 -ne 0 &&\

itest.s *0x81c00040 == \"recovery\"; then\

echo BCB forces recovery mode;\

setenv bootvar recoveryboot;\

fi" \

"\0" \

Again, this is easy to change. For example, removing the "setenv bootvar recoveryboot;\" lines (or changing them to "normalboot") should change it so that it boots normally if those files are missing.

For this challenge, you may want to set those to default to a normal boot if the files are not there. However, consider the consequences of the action-- it means that in a corruption situation, you will have to manually override the default behavior via the menu-- so test to make sure that works too.

Non-programmers: you probably don't even need to know any programming languages or anything to understand the above. Assuming you know how to build the code (not necessary with some programming languages, although it is with u-boot, which is in C), you can often tweak programs code just by looking and guessing...

Good luck!
[Nook Color Android Development] leapinlar:
I don't know about u-boot's ability to create the file if it is missing, but the recoveries can do it. In my experimenting with the files, I deleted the file and the Nook booted to both CWM recovery and verygreen's script recovery and both were able to create a new replacement file when they exited. CWM makes one 1024 bytes and verygreen makes one 512 bytes (both with all zeros). I manually created one with 256 bytes and all zeros and it still booted to recovery.

Edit: Verygreen's commands for creating the file are:

mkdir /rom

mount /dev/mmcblk0p2 /mnt -t vfat

dd if=/dev/zero of=/mnt/BCB conv=notrunc bs=512 count=1

umount /mnt

Sent from my NookColor running ICS and Tapatalk
[Nook Color Android Development] fattire:
Yes, that's this line from above:

elif itest.l 0x$filesize -lt 0x200; then

If I'm not mistaken, you can read that as:

"...or else, if the file size is less than 512 bytes, then..."

(hex 0x200 = dec 512)

There are lots of conditions that "trip" the auto-recovery boot, and having a bcb that is less than 512 bytes is just one. The code above should be pretty helpful for figuring out how to control what triggers a recovery boot.

Another hint:

usage: fatsave <interface> <dev[:part]> <addr> <filename> [bytes]

fatsave mmc 1:2 means to save to partition 2 (/rom) on mmc interface 1 (which is reversed from normal. 1 = emmc)
[Nook Color Android Development] mateorod:
Well, let me say first that I by no means claim the issue. If anyone was inclined to try this before, don't let the fact I have put some time in deter you. I have very little idea of how recovery works, I really didn't even know what Leapinlar was talking about when she first brought up the issue. All I knew that it had been a problem for some people. But I do love a challenge...

The point is, don't think you're off the hook, Dizzy.

However, significant moral victory here, as I have successfully signed up for git, forked the uboot (accidentally, but still) and figured out how to change branches. That was a pain, man. Properly configuring it was no picnic, either.

Anyway, just so you know that at least one person is trying, I can report that I have successfully built a uboot that has Clear Recovery Instructions on the menu. It, as of now,

would do nothing if selected.

And if left up to just me, it may never.

That was the monkey work. Now to see if I can even parse the rest of the directions. Wish me luck.
[Nook Color Android Development] fattire:
Good luck. BTW-- congrats. Pretty cool- you've built, modified, and installed a bootloader!
[Nook Color Android Development] mateorod:
M sup

Well, I know what is needed now, the question is can I bang the functions into order to where they'll compile. I'll give it some more time tomorrow.
[Nook Color Android Development] leapinlar:
He. LOL.

Sent from my Nook Color running ICS and Tapatalk
[Nook Color Android Development] mateorod:
Whoops. Don't know where I go that from.

Anyway, I've made a little progress. The Clear Recovery Instructions appears to reset the boot count and does write to the BCB file.

I will have to return to it tonight, though.

I have added a new function to the menu.c, which is a straight copy of write_u_boot_file () at this point. So it is writing boot data to the bcb at this moment, instead of just zeros. I will have to redo the function tonight.

Also, for testing purposes (since I don't have bootable card, living on the edge), I changed all the setenv recoveryboots to normalboots.

This should be unnecessary with the new option and only the missing bcb file default should need to be changed (unless I find a way to create the file within uboot).

There needs to be some more thought/testing with that, though, because a side-effect of those changes is that recovery can only be entered through cyanoboot. All usual methods of entering recovery go straight to normal boot.

edit:took out blow-by-blow. Unnecessary.
[Nook Color Android Development] leapinlar:
Here is an excerpt from the 3.2.0.1 CWM uRecRam ramdisk. This is a script called postrecoveryboot.sh as part of the ramdisk in sbin. It executes this script as it exits CWM.

#!/sbin/sh

# Resets the boot counter and the bcb instructions
mkdir /rom
mount /dev/block/mmcblk0p2 /rom

# Zero out the boot counter
dd if=/dev/zero of=/rom/devconf/BootCnt bs=1 count=4

# Reset the bootloader control block (bcb) file
dd if=/dev/zero of=/rom/bcb bs=1 count=1088

umount /rom
rmdir /rom

Good Luck.
[Nook Color Android Development] mateorod:
I am luckily past the point where you can keep confusing me with all these linux commands. That's what I did last night.;)

The u-boot is written in c. If all the posted linux commands were working, I would already be done. (unless you know a way? Are you suggesting sourcing this to a script or something like that?)

But thanks, I know you're trying to help.:)

this is what I am working with,

int clear_recovery_instructions_file(const char* file, char value) {
lcd_is_enabled = 0;
("mmcinit 1; fatsave mmc 1:2 0x%08x %s 1", &value, file);
lcd_is_enabled = 1;

Which I keep messing with trying to get the correct result. It is basically a lift out of the write_u_boot_file, which maybe I am missing something.

I am calling it like this below:

if ((key & HOME_KEY) && (cursor == CLEAR_RECOVERY_INSTRUCTIONS)) { //clear boot count and reset BCB
const char* file = "BCB";
{clear_recovery_instructions_file (file, '0x400');}
udelay(RESET_TICK);
highlight_boot_line(cursor, HIGHLIGHT_GREEN);
do {udelay(RESET_TICK);} while (tps65921_keypad_keys_pressed(&key)); //wait for release

but considering this is my first look at c programming, it is slow going, especially because I have to flash a new u-boot to test every change.

on first run of clear recovery instructions(immediately after new u-boot flash) the bcb file has a size of 1.06 and still has the encrypted characters and boot data in it. But if I boot into Cyanoboot a second time and rerun the option, then the bcb file goes down to 73 bytes, no boot data, but still goobledeguk.

And that seems to remain no matter what I do to the variables, if I leave in sprintf or the buf or mess with the file size variable layout. It is very nooby, I can tell that much. Right now I am basically trying to import fatsave lines from the omap-config file and see how they go.

so...suggestions (in c) welcome
[Nook Color Android Development] leapinlar:
LOL. Who is confusing who? I wish I knew anything about what you were saying here. I wasn't suggesting anything, I just thought it might be useful.

Sent from my Nook Color running ICS and Tapatalk
[Nook Color Android Development] HacDan:
So you thought something that had already been posted would somehow be useful if posted again?

---------- Post added at 04:17 PM ---------- Previous post was at 04:14 PM ----------

Ya, you're only telling it to write one byte. Check that '1' in your fatsave code. That 1 determines how many bytes to write.
[Nook Color Android Development] leapinlar:
Well... would you like to point out the post where it was already posted?

Sent from my Nook Color running ICS and Tapatalk
[Nook Color Android Development] HacDan:
Sure, I'll read the thread for you.

Check this post here: http://xdaforums.com/showpost.php?p=26192266&postcount=64

Specifically the part about writing bcb with 0's
[Nook Color Android Development] leapinlar:
LOL. You translate the part about writing bcb with all zeros as being the same as quoting Linux code from a script in CWM? I guess you read the posts the way you want to read them. I'm finished with this discussion.

Sent from my Nook Color running ICS and Tapatalk
[Nook Color Android Development] HacDan:
Actually if you'd gone back and read it you would see it links to this script here: https://github.com/fat-tire/android_device_bn_encore/blob/ics/recovery/postrecoveryboot.sh

Amazing how much you miss when you don't actually read something.

And that's not Linux code. That's a bash script. Big difference.
[Nook Color Android Development] leapinlar:
I am appropriately ashamed. I did not follow fattire's link. Mainly because I understand zip about c. I apologize to mateorod for cluttering his effort. But leave it to you to put the barb in. I hope in the future you can resist the temptation.

Sent from my Nook Color running ICS and Tapatalk
[Nook Color Android Development] HacDan:
Well if you didn't act like you were sitting high on the horse, maybe the responses you receive when you're wrong, wouldn't be so harsh.
[Nook Color Android Development] leapinlar:
I don't get any harsh responses except from you. Why is that? Are you the only one who sees my high riding?

Edit: Fattire, I apologize for cluttering your thread with this nonsense. I am finished. HacDan, do not answer my retorical question.

Sent from my Nook Color running ICS and Tapatalk
[Nook Color Android Development] mateorod:
Hey, thanks Dan. I was able to quickly implement that change on the way out the door, and it has indeed stabilized the size issue. Which will, I believe, make the fix functional, although not quite finished. I had tried importing some commands from the omap config file that were set up like that (specifically the rewrite to bcb after an update.zip is applied) but the way I was doing it as breaking the rest of the function.

So now I just need to winnow out whatever is writing the boot data and encrypted characters. I'll do it tonight. Thanks for the tip.

I will say it looks pretty cool, due to the framework tonsofquestions (I believe) put together. Very easy to put in.

My plan is to only change the default to recovery behavior in the event of a missing bcb file, since the other two eventualities (too small or empty, if memory serves) can be addressed by the menu option. Hopefully that lets us boot into recovery from the ROM, because as it is I can still only get to recovery through cyanoboot.