yashsingh1/xdaforums huggingface dataset:
[Nook Color Android Development] motitas:
As far as I can tell video works to the same extent as cm7 for me.. I tried several different websites. It starts off a bit choppy but if you pause it, it picks back up again and runs perfectly smooth. Is what your trying to get HD video? Because that would be awesome. Otherwise I don't see anything wrong with video.
[Nook Color Android Development] uranium:
thanks for your earlier reply steven676.

will wait for you hardworking devs to get that up and running in your time.

one thing though, any chance that the cm11 will have usb storage host support? or are there issues with activating such feature, this would help alot of us because it would allow us to connect memory cards or even usb sticks and aid productivity. hope its in the works or something. but no issue if it isnt.

Wish i could help but i have no idea where to start even if i wanted to though :/
[Nook Color Android Development] polymath257:
That isn't working for what I am trying to do. I have a local branch named encore-local for device/bn/encore. That branch has

changes that I do not want to upload. I want them to stay local.

I attempted to make another branch from the original cm11 branch named unzip. In that branch, I made just the changes I want

to upload. I have verified that only the changes I want to upload are there.

But, even if I have the branch unzip checked out, when I go to repo upload, it defaults to the encore-local branch. So it wants to

upload the branch I don't want to upload.

So,

1. I have the unzip branch checked out

2. I have verified with repo status device/bn/encore that unzip is the current branch

3. When I go to upload, the changes seen are those for the encore-local branch

How do I choose which branch to upload?
[Nook Color Android Development] steven676:
Use the --cbr ("current branch") option to repo upload; alternately, you can specify a branch name explicitly with the --br option. See repo upload --help for details.
[Nook Color Android Development] unibroker:
low audio

Thanks to drmarble for his post on cherry-picking which got me to trying to address my low audio problem. It seems that since CM11 I haven't been able to control the level with the volume controls either.

I went to http://review.cyanogenmod.org/#/q/status:open+audio,n,z but didn't find anything open addressing low volume. It seems that the file location is at android/system/hardware/ti but not sure how to proceed with its contents of

omap3 omap4xxx wlan wpan

.

TIA
[Nook Color Android Development] lorddunlow:
You may want to consider the few users who still utilize the dual boot EMMC setup (as described by Taosaur) that uses two separate system partitions.

Maybe the script could detect that setup and abort with a message directing users to an XDA thread explaining steps (and perhaps provide tools) to backup data for both systems and revert to a known partition scheme (or repartition directly to the new scheme - whichever would be easiest) before flashing the ROM.

It might cut down on some problems those users might face when the script aborts because the partition scheme is unrecognized (as I've discovered the newer recoveries don't work with Taosaur's repartitioning and backup/transfer zips - I had to flash a separate SD card with the older CWM recovery in his guide to swap ALT and PRI systems). Many of these users may have even forgotten they are running a dual boot EMMC as the setup is invisible unless you check the size of your data partition or try to boot to the alternate system in Cyanoboot.

Just throwing this out there so you guys aren't fielding a bunch of questions from people with aborted installs due to this probably rare setup.
[Nook Color Android Development] meteorrock:
I just finished my first build from source you guys :) I am on my way to becoming a dev like steven! I brunched and everything. Just made my first .zip. :cool:

Check out my link down here in the nook color cyanogenmod forums. http://forum.cyanogenmod.com/topic/86145-cm-11-kitkat-code-now-availible-for-the-nook-color/

Steve, check your github, you got help.
[Nook Color Android Development] fattire:
Congrats, meteorrock!
[Nook Color Android Development] boringuy:
I am very interested in doing what you suggested manually for now as I don't care about what's in /data and /system.

Currently, here is my partition table:

Disk /dev/block/mmcblk0: 7944 MB, 7944011776 bytes
255 heads, 63 sectors/track, 965 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Device Boot Start End Blocks Id System
/dev/block/mmcblk0p1 * 1 9 72261 c Win95 FAT32 (LBA)
/dev/block/mmcblk0p2 10 18 72292+ c Win95 FAT32 (LBA)
/dev/block/mmcblk0p3 19 56 305235 83 Linux
/dev/block/mmcblk0p4 57 935 7060567+ 5 Extended
/dev/block/mmcblk0p5 57 114 465853+ 83 Linux
/dev/block/mmcblk0p6 115 236 979933+ 83 Linux
/dev/block/mmcblk0p7 237 281 361431 83 Linux
/dev/block/mmcblk0p8 282 935 5253223+ 83 Linux

So, each cylinders is 7MB + 885248 bytes. How would you align partition 5,6 and 7 to align to the 4MB boundary?

Are you thinking about passing extra parameter to fdisk to change the number of heads and sectors/track and then starts the extended partition from a cylinder far enough away from the "old" partition 3 end cylinder (waste some space in between) so everything inside the extended partition will be 4MB aligned?
[Nook Color Android Development] DizzyDen:
Steven, if we're going to repartition (which I think is a great idea) is there any reason we don't reorganize the partitions?

I'm suggesting the following fwiw...

756 MB mmcblk0p5 system partition (to accommodate future boat)

512 MB mmcblk0p6 cache partition (to accommodate whatever google decides to do with ART or whatever)

remainder mmcblk0p7 data/media partition

Again... just my thoughts on it.
[Nook Color Android Development] steven676:
No, we don't want to work in cylinders at all. Any recent fdisk should have an option to change the units to sectors (512 bytes) each; once you do that, getting 4MB alignment is a matter of making the start of the partition a number divisible by 8192. (Yes, that's going to waste a few disk blocks between the start of the extended partition and the start of /system -- I haven't bothered calculating exactly how many yet -- but it's not going to be a big number in any case.)

What's the benefit of swapping /cache and /data? On-disk location has no effect on performance on flash media (wellllll ... sometimes SD card flash is designed so that the first few MB are "special", but we're way beyond that point even if that were the case here), and in any event partition table order doesn't have to match on-disk order.
[Nook Color Android Development] DizzyDen:
Honestly the only benefit is not having to do the math to figure out the size... if we specify system and cache we can simply partition the remainder as data. Additionally for the SD install you were discussong the same partitiooning scheme works for the same reasoning.
[Nook Color Android Development] steven676:
Given that we only have to do the math once for all devices, that's fine -- also, I think (but have not checked) that there may be some backwards compatibility advantages to not reordering /cache and /data.
[Nook Color Android Development] DizzyDen:
No worries... I was just thinking that it would cover any size SD without having to determine the size. Was just a thought I figured I'd throw out there.
[Nook Color Android Development] boringuy:
Cool. "fdisk -u" does that. Didn't know about it. That actually makes it a lot easier as each logical partition will have a EBR in front of it. Making sure the starting sector is divisible by 8K is much easier when Start and End can be specified in sectors.

Doing a little more research. There are suggestion to set the Stride and Stripe Width for SSD when creating the ext4 file system to have optimal performance:

stride = Page size / Filesystem block
stripe-width = Erase Block / Filesystem block

I try to look at the data sheet of the SEM08G MMC but couldn't find the exact Page Size and Erase Block mentioned there. Nook Color had another MMC (M8G2FA) which I can't find the data sheet. So, do we know the page size for sure, 4K or 8K?
[Nook Color Android Development] steven676:
I'm not sure stride= will make any difference if it's set to the block size -- that's basically always going to be 1, 2, or 4 4k disk blocks. I've always set it equal to the stripe width, which I set equal to the eraseblock size. (If you're referring to http://thelastmaimou.wordpress.com/2013/05/04/magic-soup-ext4-with-ssd-stripes-and-strides/, he's misunderstood what the RAID stride is -- a RAID array is perfectly able and willing to read and write data in blocks much smaller than the stride size.)

The real problem, though, is that Android's implementation of ext4 filesystem creation, as used in the recovery and OTA updater, doesn't support those ext/2/3/4 extended options at all. Even if we were to create the ext4 filesystems this way, then, our work would be lost the second the partitions get formatted by the Android tools -- for example, if you select "wipe data" in recovery, or just install any OTA ROM package. (If you get a chance, use dumpe2fs -h to compare an ext4 filesystem created by Android with one created by mke2fs -- the difference is rather shocking.) If that's going to be the case, I don't see much of a point in going to that effort to create the filesystems that way in the repartitioner.
[Nook Color Android Development] DizzyDen:
ok... playing around some I think I figured out some things...

the factory's extended partition does not start on a 4M boundary...

I think this has all partitions beginning on the 4M boundary as steven676 points out is most desirable...

This creates:

768M system partition (mmcblk0p5)

512M cache partition (mmcblk0p7)

all remaining space data/media (mmcblk0p6)

This also keeps data/media as mmcblk0p6 using all available space on emmc or sdcard while creating mmcblk0p7 as 512M...

I began by deleting mmcblk0p4 which deletes p4, p5, p6, p7 and p8 in one step instead of having to delete each one at a time. I did this to align mmcblk0p4 on the 4M boundary

contents of repartition.sh:

#!/sbin/sh
# Repartition
fdisk /dev/block/mmcblk0 </tmp/repartition.fdisk

contents of repartition.fdisk:

u
d
4
n
e
901120

n
909312
+768M
n
3424256

n
2416640
+512M
w

This results in the following partition layout:

Disk /dev/block/mmcblk0: 7944 MB, 7944011776 bytes
255 heads, 63 sectors/track, 965 cylinders, total 15515648 sectors
Units = sectors of 1 * 512 = 512 bytes

Device Boot Start End Blocks Id System
/dev/block/mmcblk0p1 * 63 144584 72261 c Win95 FAT32 (LBA)
/dev/block/mmcblk0p2 144585 289169 72292+ c Win95 FAT32 (LBA)
/dev/block/mmcblk0p3 289170 899639 305235 83 Linux
/dev/block/mmcblk0p4 901120 15515647 7307264 5 Extended
Partition 4 does not end on cylinder boundary
/dev/block/mmcblk0p5 909312 2409312 750000+ 83 Linux
/dev/block/mmcblk0p6 3424256 15515647 6045696 83 Linux
/dev/block/mmcblk0p7 2416640 3416640 500000+ 83 Linux

Partition table entries are not in disk order

I DO NOT RECOMMEND ANYONE ACTUALLY DO THIS UNTIL THE PARTITION LAYOUT IS DECIDED ON BY STEVEN676 AND THE OTHER DEVELOPERS
[Nook Color Android Development] meteorrock:
An updated guide for building cyanogenmod from source for the nook color can be found here. This guide was done with the help from the nook color developers so make sure to check it out. This guide was written up for the superusers wanting to jump onboard building encore.

_________________________

Here is that link here for that guide http://xdaforums.com/showthread.php?p=50005379

______________________

Steven, why don't you take some memory from the microSD card for the ART function for those running cyanogenmod on the eMMC? It would be an ugly hack, but you can swap the memory needed from the microSD card that everyone uses for this device. Both RAM and the microSD card is non volitable memory. You could write up a script that would hide the function of ART for those that do not have the microSD card inserted and tuck the ART function away from view until we have a better solution to the problem. People hang on to the nook color because of the extra storage.

You could account for others also on your boot-up memory that you need for those that have extra storage within the inserted microSD card. And you can write up the script that would account for others having not enough available memory on the microSD card by disabling the ART function before your boot-up and have it tucked away from view. That is how I would write up a script to account for that. Also you could account for the microSD card NOT inserted in the nook color and account for not enough available memory on the microSD card within the same script, in case their memory was full. Take the minimum amount of memory from the microSD card for a smooth boot-up that you need.

For those that do not have cyanogenmod on the eMMC, it seems you are not having memory problems on boot-up for the ART function.

Missing around with the partition tables is not going to work, IMHO. You might have to take this ugly hack and get it code board approved to have it approved into the mainline code, but it could be a workaround until a better and cleaner patch could be submitted. This hack could always be retracted later when you have a better solution.
[Nook Color Android Development] polymath257:
Just a bit of humor that this reminded me of:

http://xkcd.com/1168/
[Nook Color Android Development] polymath257:
Especially since we also need to actually create the file systems on each of the partitions and the /media/data partition is (I believe) supposed to be vfat, not ext3.
[Nook Color Android Development] polymath257:
1. Are there any files in /system, /data, /cache, or /emmc that we specifically need to exclude from the backups?

2. Should we use compression on the backups? If so, which type?
[Nook Color Android Development] lorddunlow:
Wouldn't compression just increase the time the process would take?

Since the backup files are meant to be temporary and deleted at the end of process, I think compression would be an unnecessary lengthy step, IMHO.
[Nook Color Android Development] steven676:
Not if the increase in CPU time needed to do the compression/decompression is exceeded by the time saved in doing I/O to a slow disk. If this were a modern desktop or laptop and the storage device were a spinning-rust hard disk, this would be a no-brainer -- we'd compress, because the CPU is much, much, much faster than the disk. (Even with SSDs, it can sometimes be beneficial to compress the data before writing it out.) Of course, results which apply to CPUs that clock at 3 GHz while doing 4+ instructions per cycle (and have much better memory subsystems) don't necessarily apply to 1 GHz CPUs that do 2 instructions per cycle ... hence the call for benchmarks.

I should note that our standing recommendation of SanDisk class 4 microSD cards does not apply in this case -- for once, we actually care about linear transfer speeds. I'd expect a non-broken class 10 (or higher) card of any brand to be better for this application. (That said, we should probably revisit this for microSD installs at some point -- I've personally had great results with a SanDisk class 10 UHS-I card, and I believe I'm not the only one.)
[Nook Color Android Development] DizzyDen:
Steven... You are absolutely correct... they byte size of using +768M is it is 768000000

I cannot get the system to assign partitions back to back... even when changing values to ensure the partition ends properly. What I am doing is taking the first value it will allow, then dividing it by 8192... round that result up to next whole number and multiply it by 8192 to get the first block it will allow that starts on an eraseblock boundary.

The fdisk in BusyBox v1.21.1-kk bionic (2013-11-24 11:52 +0100) multi-call binary.

It seems to be the busybox installed with CM11 as well as in TWRP 2.6.3.0 and CWM 6.0.4.7...

It also is working the exact same way with BusyBox v1.20.2-jb bionic (2012-11-25 17:47 +0100) multi-call binary. in TWRP 2.4.1.0.

The only reason I was playing with cache size is to see if it made any difference with ART... probably not, but since your concerns were relocating it to mmcblk0p6 instead of mmcblk0p7 I thought what the heck.

It is a SEM08G part EMMC in a Nook manufactured 12/09/2010

Changing my response file (repartition.fdisk) to:

d
4
n
e

u
n
901120
2473983
n
3014656

n
2482176
3006463
w

now results in :

768M mmcblk0p5

256M mmcblk0p7

remaining space mmcblk0p6

Disk /dev/block/mmcblk0: 7944 MB, 7944011776 bytes
255 heads, 63 sectors/track, 965 cylinders, total 15515648 sectors
Units = sectors of 1 * 512 = 512 bytes

Device Boot Start End Blocks Id System
/dev/block/mmcblk0p1 * 63 144584 72261 c Win95 FAT32 (LBA)
/dev/block/mmcblk0p2 144585 289169 72292+ c Win95 FAT32 (LBA)
/dev/block/mmcblk0p3 289170 899639 305235 83 Linux
/dev/block/mmcblk0p4 899640 15502724 7301542+ 5 Extended
/dev/block/mmcblk0p5 901120 2473983 786432 83 Linux
/dev/block/mmcblk0p6 3014656 15502724 6244034+ 83 Linux
/dev/block/mmcblk0p7 2482176 3006463 262144 83 Linux

Partition table entries are not in disk order

I know the partition table entries are not in disk order since I am defining mmcblk0p6 by leaving room for mmcblk0p7 so mmcblk0p6 can use all available blocks on the storage unit.
[Nook Color Android Development] polymath257:
One thing I might add.

I like to have a dual-boot system with emmc and sdcard installs simultaneously. Back in the old NC bootloader, it was possible to

select which to boot from and that choice was remembered for the next boot. The Nook Color currently requires booting into recovery

to be able to go to the emmc install if the sdcard is in the slot. The choice is not remembered, but it is at least *possible* to boot

emmc without removing the card. For the Nook HD+, there seems to be no way to have the sdcard in the slot and boot into emmc.

I know this is a lower priority than other things above, but it seems that if we are telling the kernel which card we are booting from,

it should be possible to set that from the recovery and have it be remembered for the next boot.

---------- Post added at 06:29 AM ---------- Previous post was at 06:21 AM ----------

My bugbear has always been ps. For example, 'ps -aux' vs. 'ps aux'.
[Nook Color Android Development] eyeballer:
You can do this now with our current u-boot by modifying /bootdata.

echo -n “1” > /bootdata/u-boot.device

Will force emmc to boot even if a bootable sd is in place.
[Nook Color Android Development] polymath257:
I assume the 1 is changed to a 0 for sdcard? Or should the file simply be removed?

Still not quite what I am looking for, though. I want a dual boot system that remembers the previous boot location and is changed when I select

a different boot location from recovery.

Also, is this for both the NC and HD+?
[Nook Color Android Development] pmgnet:
Missing notification bar?

I'm running latest cm11's (did factory reset going from 10.2 to 11) and I can't seem to keep the notification bar visible and the "N" button doesn't work. Anyone else seen this?

This was on the first 11 nightly, plus a build I made, and then last night nightly.

I'll post a screenshot later. It's weird.
[Nook Color Android Development] steven676:
The bootloader's the wrong place to do this, if you ask me -- we're very limited in what UI we can offer in the bootloader, and the risk of screwing things up is higher than elsewhere. The right way to do this would be to make a "bootloader configurator" app which changes the default boot behavior from a running system -- given what eyeballer's described, this should be an easy project for someone with a bit of experience making Android apps (and a good one to start with if you'd like to get into the game -- hint hint).
[Nook Color Android Development] fattire:
I think dalingrin and I did this 3 years ago...

Something like this? Haven't tried it for ages (see relevant code here) but probably will work, at least for what's discussed above. As this was written with the gingerbread kernel in mind, a lot of the DAC and other stuff may not work at all. But the default boot selection stuff probably will.

That said, I believe the Nook Tablet version of CyanoBoot actually does let you set the default behavior...

And btw-- if anyone feels like bringing this up to date... the source is linked above ;)
[Nook Color Android Development] polymath257:
Thanks! That code actually helped me quite a bit. I was missing a basic point: that the /rom partition is 'shared' by both sdcard and emmc installs.

I don't know why I missed that before.

---------- Post added at 04:33 PM ---------- Previous post was at 04:31 PM ----------

I went with a linux hack rather than a android app. I put a file into /etc/init.d that echo's the appropriate value to /rom/u-boot.device. The file

for the emmc echo's a 1 and that for sdcard echo's a 0.
[Nook Color Android Development] fattire:
Yeah, that should totally work. Wonder if there's any value in making that part of the standard install...?

I'm remembering more-- for Nook Tablet's CyanoBoot (which was forward ported from NC and then ultimately forward ported from NT back to NC again) I think I actually did have it write a 1 or 0 into the various configuration files via the menu, provided that the file existed (there is no file creation code for FAT in u-boot, only modifying an existing file)... but I don't think it ever made it to the NC version.

Hey, this is my post #1,500. That's kinda sad.
[Nook Color Android Development] polymath257:
I was able to get this to work with /rom/u-boot.device instead of /bootdata/u-boot.device on the NC (which does not have a /bootdata directory).

I was not able to get this to work on the HD+, though (which has both a /rom and a /bootdata directory : I attempted to change both).
[Nook Color Android Development] fattire:
Yeah a full cyanoboot never made it to the Nok HD. It was bad enough porting it to the tablet without having one.;)

That said, I'm sure it would be very very very easy. If you have one. This source is probably almost identical on the Nook Tablet.
[Nook Color Android Development] polymath257:
I have built cm11 for ovation a few times and have the device. What would need to be done? I am not familiar with building cyanoboot specifically. Is it in the usual source code for ovation? or for that matter, for encore? I am willing to try and test.
[Nook Color Android Development] fattire:
Just checked with green-- who's maintaining CM for Nook HD--

19:48 <fattire> so wait, cyanoboot is there already?

19:48 <green--> it's there, but menu stuff I only did very recently (bokbokan, the nook hd guy with sdcard installs only) had gimped menu for some time

19:48 <fattire> did you add some equivalent of the ability to force a boot to sd or emmc?

19:48 <green--> https://github.com/fat-tire/u-boot-hummingbird-ovation.git is what has the latest sorce with everything fixed

19:49 <fattire> does it honor the ability to adjust which boot is chosen by default?

19:49 <green--> yes, it can boot from emmc or sdcard, it also autodetects if emmc install is liberated and does proper thing then

19:49 <fattire> but can you set it via a u-boot.default file = 1 or whatever it was.

19:49 <green--> I did not test default boot option, so it well might not work

19:50 <green--> secondloader-sdcard is the branch

19:50 <green--> it actually works for both ovation and hummingbird, but the code duplcation is horrible, meaning whatever is fixed for one device would need to be fixed for the other too

Basically I hadn't realized that the basic menu was ported to Nook HD-- which means that you can test to see if the /rom/ boot device directed was also ported. For reference, the boot instructions for nook color are here menu is here, and the u-boot for nook tablet is here - (menu, actual boot mode detection). So if it doesn't work for Nook HD, you can build u-boot yourself and see if it works.

Hope this helps! Green-- could use any patches you throw his way :)

I should also mention that there's not necessarily a "/rom" on the HD...
[Nook Color Android Development] meteorrock:
Thanks for the work on the partition tables *DizzyDen* that was some good work!