Nook Glowlight 3

Search This thread


Recognized Contributor / Inactive Recognized Dev
I'm surprised to find that I never did a deep dive on the Glows on Epd user APIs.

I did do that on the NST.
All that stuff is in android.hardware.EpdController in /system/framework/framework.jar
I recently did a display thing on an old NST.
Updating once a minute and never doing a refresh eventually the updated rectangle background turns whiter than the surrounding area.
I needed to do a full refresh myself.
On the NST:
EpdController epd = new EpdController(this);
epd.epdRefresh(TAG, EpdController.Refresh.REFRESH);

Edit: Since hardly any of the eInk is openly documented it's mostly a case of trial and error.
The previous specified GC_ALL only updates a subset of the display.
This is not apparent until after a few days of continuous operation.

On the Glows, I can't find anything similar.
It seems that the Glows takes a "hands-off" to Epd (eInk) management.
I'm still looking.
Last edited:


Senior Member
Jul 13, 2010
On the Glows, I can't find anything similar.
It seems that the Glows takes a "hands-off" to Epd (eInk) management.
AFAIK, there is nothing like EpdController on those new IMX-based Nooks. I believe it is because of the changes that were introduced since android 4.x.x.
So what they did in FW is that they modified base View class (from which every android control inherits). There is some sort of queue there which may call EPD refresh through API. But there is no way to call that API from outside plus there is some logic buried inside that API that does not guarantee that refresh call will actually refresh the screen. On some IMX-based reader FWs there are some APIs exposed on a view level that allow to change refresh mode for specific View (i.e. control or window).
All in all, for reader apps it is easier to just show a white filled screen for some duration to do a "refresh" than try to support every reader directly.
  • Like
Reactions: Renate

Top Liked Posts

  • There are no posts matching your filters.
  • 5
    Ok. So it looks like the bootanimation. When I kill it from the shell the device is ready. Any ideas what causes this?
    Did you delete/rename /system/priv-app/partner.apk?
    B&N put its hooks in everywhere.
    The bootanimation will not go away without partner.apk unless you do something.

    On my Glow2 I just renamed partner.apk and bnereader.apk to backup files.
    That does the startup correctly.

    The Glow 3 modified /system/bin/bootanimation to use bn.bootanim.exit instead of service.bootanim.exit
    You can take bootanimation out of a Glow2 or just delete/rename bootanimation.
    You will then get a black screen until your home/launcher starts.
    I tried to run the script on my Glowlight 3, using a Windows PC that has Minimal ADB and Fastboot installed. I can see my Glowlight in adb devices. I can install apps to my Glowlight. However, when I try to run rootnook.cmd, I get a message - ADB not connected?

    What am I missing?

    Glow 3 is a BNRV520, not a BNRV510.
    Change line #9 in the script.

    Unrelated to your problem, but as info VID 2080, PID 000B.
    Disk /dev/block/mmcblk0: 7818 MB, 7818182656 bytes
    4 heads, 16 sectors/track, 238592 cylinders
    Units = cylinders of 64 * 512 = 32768 bytes
    Partition  Format  Id  Start   End    Size (bytes)   Mount
    ---------  ------  --  -----  ------  -------------  ---------
    mmcblk0                    1  238592  7,818,182,656
    mmcblk0p1  emmc    83     33     223      6,258,688  /boot
    mmcblk0p2  emmc    83    609    1632     33,554,432  /recovery
    mmcblk0p3           5   1633   26720    822,083,584
    mmcblk0p4  ext4    83  26720  238080  6,925,877,248  /data
    mmcblk0p5  ext4    83   1665   13952    402,653,184  /system
    mmcblk0p6  ext4    83  13984   26272    402,685,952  /cache
    mmcblk0p7  ext4    83  26304   26560      8,421,376  /device
    mmcblk0p8  emmc    83  26592   26719      4,194,304  /misc
    anyone brave enough to pop theirs open and see if there is a UART possibility or not?
    Of course!

    It pops easily. Use a thin knifeblade to get it started then work a guitar pick around.
    The TTY is easy and obvious, 3.3V, 115200 8N1.
    That table is pretty much busybox fdisk -l /dev/block/mmcblk0
    I add in the mounts from /fstab.E60QQ0 and mount.
    I calculate out the byte sizes.
    I should have a utility for doing that, but I seem to just knock out those tables when needed.

    mmcblk0p3 is just the extended partion block.
    A standard MBR can only contain 4 partitions.
    Usually the 4th partition "escapes" you out to more partitions.
    In our case, the 3rd partition mmcblk0p3 contains mmcblk0p5, mmcblk0p6, mmcblk0p7, mmcblk0p8.

    There's no wasted space here except at the end of mmcblk04 where 16 MB is left unallocated.
    This is so if they swap out the flash memory chip for another brand they won't have to redo the partitioning if the new chip has a few Megs less user space.