Aura H2O Boot from external SD

[basttran]

Dear all,

I am new to the forum and a bit late on the topic! I would like to know the method for allowing boot from the external SD on the H2O. Apparently it is possible to do so :

Originally Posted by frostschutz

It's possible to make the Aura H2O boot from the external SD card by changing the u-boot parameters (the same way it's done for factory resets)

Searching this thread and others I haven't found any method specific to the H2O (maybe there is no need for something specific to the H2O?). Is it feasible/attemptable without opening the Kobo?

Some context: Ideally I would like to run Android and/or Debian from the external SD (dual boot?), I believe some have managed to do just that on other Kobo devices but I haven't found someone reporting success and specific method for the H2O.

Thanks in advance for reading this.

Best whishes,
Bastien

[Paraglider]

Salut Bastien.

I'm facing the same issue with my Aura.

I tried to build a mmcblk1 bootable SD by copying the internal one (dd if=mmcblk0...) with its 3 partitions. But it did not boot.

I digged a little bit in the u-boot from firmware.
Looks like the U-boot parameters are set to internal SD (mmcblk0) first.
baudrate=115200
loadaddr=0x70800000
uboot=u-boot.bin
kernel=uImage
bootcmd_mmc=run bootargs_base bootargs_mmc;load_ntxkernel;bootm
bootcmd_SD=run bootargs_base bootargs_SD;load_ntxkernel;bootm
bootcmd_recovery=run bootargs_base bootargs_recovery;load_ntxkernel;bootm
verify=no
bootcmd=run bootcmd_mmc
bootargs_recovery=setenv bootargs ${bootargs} root=/dev/mmcblk0p2 rootfstype=ext4
bootargs_mmc=setenv bootargs ${bootargs} root=/dev/mmcblk0p1 rootfstype=ext4
bootargs_SD=setenv bootargs ${bootargs} root=/dev/mmcblk1p1 rootfstype=ext4
bootargs_base=setenv bootargs console=ttymxc0,115200 rootwait rw quiet lpj=3997696
stdin=serial
stdout=serial
stderr=serial
bootdelay=0

I guess we have to set bootcmd=bootcmd_SD.
But I don't know how to do that since I have no console and delay for interrupting u-boot and get the CLI is zero (bootdelay=0).

I don't know either how the order of precedence is managed by u-boot.

Could some expert help?

Thanks in advance.

[Markismus]

Nice thread! I am thinking of installing Arch Arm on it using archroot. So I will need the same u-boot hack, when I get around to it.



Searching the forum is nearly impossible it seems at times, especially when you don't have the correct search terms. Use the thread tips and tricks for your initial searches. I think the uboot hack is part of the threads on turning your kobo into a debian tablet. Here is the u-boot wiki.

If you want shell access to your kobo device: enable telnet (tips&tricks), enable wifi, telnet to the IP of your Kobo. (On windows use putty). If you want more access, I would install KoboLauncher which comes with USBnet. You can than telnet and ftp to your USB gadget. (To get it working: again T&T).



After you have made a backup of your SDcard to your PC with dd, you should also be able to dd a custom block to the SDcard. So you extract the current uboot image. Hack it and copy it. The hack is done by changing hexadecimal codes. So obviously, this could be a trial and error procedure. If it goes wrong, you will have to open up the Kobo to restore the original Uboot image.

So no, do not expect to do this, if you never want to open your case.

I've opened the Glo, Aura, HD and since day before yesterday the H2O. It always scares the crap out of me, but I still haven't broken anything. Fingers crossed. Please be advised to use a plastic tool that breaks before the reader case gets damaged. (I rather like the ones on the right.) The Aura H2Ois actually one of the least damaged readers, because it only has adhesives keeping the top and case together. There are two glue rings. One on the back case at the outer edge. One on the inner edge on the screen. It will take you some repetitions before you can get the glue to separate.

[basttran]

Thank you Paraglider & Markismus for your pointers and kind advices.

I intalled KSM and koreader in the mean time and it does the thrick
nicely enough for pdfs at the moment (it was one of the reason I was
curious about dual-boot in the first place).

I still have to get the dictionnaries to work properly but it is
mostly about about finding the proper eng/fre resource and convert it
to the appropriate format

I also have to see what can be done with columned articles but for
what I've learned here so far, it is more about converting the pdfs on
a PC so I should be fine as well

I am still curious about dual-booting so some reactions/questions
below if you don't mind:

@Paraglider

Originally Posted by Paraglider

I guess we have to set bootcmd=bootcmd_SD.

Thanks in advance.

I am not familiar with u-boot but I assume it should rather be:

bootcmd= run bootcmd_SD.

Probably something you don't want to overlook when fumbling with hex.

@Markismus

Originally Posted by Markismus

Searching the forum is nearly impossible it seems at times, especially
when you don't have the correct search terms. Use the thread tips
and tricks for your initial searches. I think the uboot hack is
part of the threads on turning your kobo into a debian tablet.
Here is the u-boot wiki.

It is true that some newbies like me may appear as if expecting
someone to actually solve their problem but I like to do my own
homework and pointers for some correct search terms are greatly
appreciated. Thanks a lot for doing just that

Originally Posted by Markismus

After you have made a backup of your SDcard to your PC with dd, you
should also be able to dd a custom block to the SDcard. So you extract
the current uboot image. Hack it and copy it. The hack is done by
changing hexadecimal codes. So obviously, this could be a trial and
error procedure. If it goes wrong, you will have to open up the Kobo
to restore the original Uboot image.

So no, do not expect to do this, if you never want to open your case.

I understand that it is not necessary to open the Kobo unless
something goes wrong (which I also understand is quite likely - there
is "error" in "trial and error" after all). If yes does that mean that
once the backup is modified/hacked it can be written to the kobo over
telnet?

I am not a 100% reluctant to opening the case but I would be happy if
there is a reasonable chance to preserve the waterproofness of the
device (maybe someday I'll own a bathtub!).

Well I guess there is no harm in me playing with the SD card backup
until I want to make an actual attempt. I'll dig into this.

Just in case: is there a cheaper or older device known to behave similarly to the H2O?

Best regards,
Bastien

[Markismus]

If yes does that mean that once the backup is modified/hacked it can be written to the kobo over
telnet?

Yes.

Just in case: is there a cheaper or older device known to behave similarly to the H2O?

Yes. Kobo Glo also has an internal SDcard. In Holland you can get refurbished ones for 60€.

The extra advantage is that a _lot_ of work has already been done on the Touch and Glo for dual-booting and debian on kobo. Only some work has been done on the Aua HD (IIRC).

In a week I will get my mail-ordered 2-sided tape for mobile screens. Currently my H2O has no screws fixing the screen and PCB to the bottom case, nor have I used new glue or tape to fix the top to the screen and the bottom case. I have a small gap between the cases, no gap between the bezel and the screen. Still, it works beautifully for reading.

If I am able to reassemble my Aura H2O with no gaps between top and bottom case, I'll post a Howto. For now there are only some posts on how to disassemble the H2O

[sti]

This thread is somewhat old, but I think it is worth to resurrect it:

It seems the kernel is loaded from a fixed location and one can change the location of the root file system only. While it appears possible to generate and write a valid binary of a customized u-boot environment this would not allow for a simple dual-boot configuration. However, looking into the u-boot code published by kobo there is an upgrade from SD card functionality built-in. It is triggered by keeping the power button pressed at power-on and expects a flag being set in the hardware configuration area on the SD card.

Today I managed to boot from the SD card following these steps (simplified):

• copy contents from internal SD (/dev/mmcblk0) to external SD
• modify hardware configuration on external SD
• with the external SD plugged in power-on the H2O and keep the power button pressed

I will post more details (if there still is interest), but right now I am curious if I can adopt Marek's or Guang's Debian system.

Best regards
Stefan

[JSWolf]

How would one setup a bootable microSD card under Windows?

[frostschutz]

Originally Posted by sti

I will post more details (if there still is interest)

There is - please do.

[sti]

@JSWolf: I can't tell you which tools you need to do this on Windows, but here comes a (hopefully complete) howto for Linux.


Disclaimer

While the procedure below does not make any modifications to the contents of the internal storage of the Kobo Aura H2O many of the commands below require root privileges on your computer. It is assumed you are aware of the risks when writing to devices and filesystems with root privileges. I do not take any responsibility for damage or loss of data by doing so.


Prerequisites

• Working usbnet on the kobo
  By default, the kobo has the address 192.168.2.101. In the following it is assumed that the connected PC has the IP address 192.168.2.102.
  
• Linux (or similar) system with root privileges on your computer
  

Make backup copy of internal SD

1. Telnet into the kobo and log in as root. The default password is empty.
   
2. Remount the root filesystem read-only and unmount the data partition.
   kobo:
   

   umount /mnt/onboard
   mount -o remount,ro /

3. Prepare to receive the internal SD card image using netcat.
   pc:
   

   nc -l -p 12345 > mmcblk0.img.gz

4. Dump the internal SD card via netcat using gzip compression.
   kobo:
   

   dd if=/dev/mmcblk0 | gzip -c | nc 192.168.2.102 12345

5. Wait for the process to finish. This will take a while. I did not check if it is faster to perform the compression on the kobo to reduce the amount of transferred data or not.
   
6. Remount the filesystems.
   kobo:
   

   mount -o remount,rw /
   mount -t vfat -o noatime,nodiratime,shortname=mixed,utf8 /dev/mmcblk0p3 /mnt/onboard

Contents of the image

From the image above we may extract the single partitions. But we will not need to do so.

Let's have a look at the partition table:

gzip -dc mmcblk0.img.gz | dd bs=512 count=1 of=mmcblk0.bs
fdisk -l mmcblk0.bs

result:

Disk mmcblk0.bs: 512 B, 512 bytes, 1 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x00000000

Device      Boot   Start     End Sectors  Size Id Type
mmcblk0.bs1        49152  573440  524289  256M 83 Linux
mmcblk0.bs2       573441 1097729  524289  256M 83 Linux
mmcblk0.bs3      1097730 7744511 6646782  3.2G  b W95 FAT32

The sectors < 49152 contain the u-boot boot loader, the hardware configuration data, the Linux kernel, and other firmware data.


Write the image to an SD card

The size of the SD card must be 4 GiB or larger.

Write the image onto the SD card:

gzip -dc mmcblk0.img.gz | dd of=/dev/sdX

Replace /dev/sdX with the actual device node for your SD card.

Check the new partitioning of your SD card:

fdisk -l /dev/sdX

result:

Disk /dev/sdg: 14.9 GiB, 15931539456 bytes, 31116288 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x00000000

Device     Boot   Start     End Sectors  Size Id Type
/dev/sdg1         49152  573440  524289  256M 83 Linux
/dev/sdg2        573441 1097729  524289  256M 83 Linux
/dev/sdg3       1097730 7744511 6646782  3.2G  b W95 FAT32

To avoid running into the recovery function perform a filesystem check of the user data partition:

dosfsck /dev/sdX3

Fix any errors found. In my case differing boot sector copies were found and I had the backup copy rewritten using the original boot sector.


Modify hardware configuration data

Extract the hardware configuration data:

gzip -dc mmcblk0.img.gz | dd bs=512 skip=1024 count=1 of=mmcblk0.hwconfig

Using a hex editor change the byte at offset 0x3F from 0 to 1 to enable booting from the external SD card.

Write the modified hardware configuration back to the SD card:

dd if=mmcblk0.hwconfig bs=512 seek=1024 of=/dev/sdX

Adjust the system to work from the external SD card

The image contains commands mounting partitions from the internal SD card mmcblk0. In order to obtain a truly independent system a few changes are necessary.

Mount the root filesystem of the SD card:

mount /dev/sdX1 /mnt

Add device nodes for mmcblk1* and remove /mnt/etc/udev.tgz:

mknod /mnt/dev/mmcblk1 b 179 8
mknod /mnt/dev/mmcblk1p1 b 179 9
mknod /mnt/dev/mmcblk1p2 b 179 10
mknod /mnt/dev/mmcblk1p3 b 179 11
rm /mnt/etc/udev.tgz

The file udev.tgz will be recreated at boot time and then contain the necessary device nodes as well.

Edit /mnt/etc/init.d/rcS and replace references to mmcblk0p1 and mmcblk0p3 with mmcblk1p1 and mmcblk1p3 respectively. This is the corresponding diff:

--- a/rcS	2015-08-03 10:53:08.000000000 +0200
+++ b/rcS	2016-11-23 19:43:30.000000000 +0100
@@ -12,7 +12,7 @@
 
 [ $PRODUCT != trilogy ] && PREFIX=$PRODUCT-
 
-mount -o remount,noatime,nodiratime /dev/mmcblk0p1 /
+mount -o remount,noatime,nodiratime /dev/mmcblk1p1 /
 
 PLATFORM=freescale
 if [ `dd if=/dev/mmcblk0 bs=512 skip=1024 count=1 | grep -c "HW CONFIG"` == 1 ]; then
@@ -79,7 +79,7 @@
 
 if  [ $(strings /usr/local/Kobo/pickel | grep -c wait-for-hit) -ge 1 ]; then
   FS_CORRUPT=0
-  dosfsck -a -w /dev/mmcblk0p3 || dosfsck -a -w /dev/mmcblk0p3 || dosfsck -a -w /dev/mmcblk0p3 || dosfsck -a -w /dev/mmcblk0p3 || FS_CORRUPT=1
+  dosfsck -a -w /dev/mmcblk1p3 || dosfsck -a -w /dev/mmcblk1p3 || dosfsck -a -w /dev/mmcblk1p3 || dosfsck -a -w /dev/mmcblk1p3 || FS_CORRUPT=1
   if [ $FS_CORRUPT == 1 ]; then
     case $PRODUCT in
       kraken|phoenix)
@@ -99,9 +99,9 @@
     reboot
   fi
 else
-  dosfsck -a -w /dev/mmcblk0p3
+  dosfsck -a -w /dev/mmcblk1p3
 fi
-mount -t vfat -o noatime,nodiratime,shortname=mixed,utf8 /dev/mmcblk0p3 /mnt/onboard
+mount -t vfat -o noatime,nodiratime,shortname=mixed,utf8 /dev/mmcblk1p3 /mnt/onboard
 rm -rf /mnt/onboard/fsck*
 rm -rf /mnt/onboard/FSCK*
 rm -rf /usr/local/Kobo/db.tgz

To have a visual confirmation for booting from the SD card one can make the startup animation run backwards by modifying /mnt/etc/init.d/on-animator.sh. Here's the diff:

--- a/on-animator.sh	2012-09-07 22:45:42.000000000 +0200
+++ b/on-animator.sh	2016-11-23 18:50:34.000000000 +0100
@@ -6,6 +6,7 @@
 i=0;
 while true; do
         i=$((((i + 1)) % 11));
-        zcat /etc/images/$PREFIX\on-$i.raw.gz | /usr/local/Kobo/pickel showpic 1;
+        j=$((10 - i))
+        zcat /etc/images/$PREFIX\on-$j.raw.gz | /usr/local/Kobo/pickel showpic 1;
         usleep 250000;
 done

Unmount the SD card:

umount /mnt

Start the system from the SD card

1. Power off your kobo
   
2. Plug the SD card into your kobo
   
3. Press and hold the power button until the LED is blinking
   

• If your system boots into Nickel you should see the backwards animation of the 4 squares. I am not aware of another way to tell if Nickel is running from the SD card.
  In any case Nickel will complain about the SD card format not being supported.
  
• If your system boots into Kobo Start Menu you can enable usbnet and telnet into the device or start kbTerminal to run some checks:
  
  command:
  

  mount

  result:
  

  rootfs on / type rootfs (rw)
  /dev/root on / type ext4 (rw,noatime,nodiratime,barrier=1,data=ordered)
  none on /proc type proc (rw,relatime)
  none on /tmp type tmpfs (rw,relatime,size=16384k)
  none on /dev type tmpfs (rw,relatime)
  none on /var/lib type tmpfs (rw,relatime,size=16k)
  none on /var/log type tmpfs (rw,relatime,size=16k)
  none on /var/run type tmpfs (rw,relatime,size=128k)
  none on /sys type sysfs (rw,relatime)
  /dev/mmcblk1p3 on /mnt/onboard type vfat (rw,noatime,nodiratime,fmask=0022,dmask=0022,codepage=cp437,iocharset=iso8859-1,shortname=mixed,utf8,errors=remount-ro)
  devpts on /dev/pts type devpts (rw,relatime,mode=600)

  command:
  

  cat /proc/cmdline

  result:
  

  console=ttymxc0,115200 rootwait rw quiet lpj=4997120 root=/dev/mmcblk1p1 rootfstype=ext4 hwcfg_p=0x8ffffe00 hwcfg_sz=110 waveform_p=0x8f98b800 waveform_sz=6768096 mem=505M boot_port=2 mx50_1GHz

  command:
  

  ntx_hwconfig -s -p /dev/mmcblk1 BootOpt

  result:
  

  NtxHwCfg_GetCfgFldStrVal:[WARNING]Config version too old !! Please update config file !!
  ESD:ON

The warning message of ntx_hwconfig is not specific to the external SD card. On my system I get the same warning for the internal hardware configuration data on mmcblk0.


Outlook

It is not the most comfortable but probably the least invasive method to implement a kind of dual booting. The u-boot boot loader is still run from the internal SD card and also gets its boot environment from there. I do not know yet from where the kernel is loaded in this setup. Nevertheless I expect this method to provide a way to boot some other Linux system from the external SD card, albeit using kobo's kernel.

I hope this triggers some happy hacking and am curious about any results...

Best regards
Stefan

[frostschutz]

Thanks for the very detailed description.

In any case Nickel will complain about the SD card format not being supported.

Still trying to mount /dev/mmcblk1p1 to /mnt/sd card probably. Nickel not really meant to run off sd cards, after all, and there's no point in doing that in the first place. This will be very useful for other things.

[tshering]

Thank you sti! I tried this under windows for a Kobo Touch. Unfortunately, without success. Maybe somebody can tell me what I am doing wrong. This is what I did. I had already a copy of the internal sd, so I skip this part.

On the pc:
With a hex editor, changed 0 to 1 at position 0x80040. (Or is the assumption that the position is the same as for the H2O wrong?)
Wrote the image to a sd with USB Duplicator Image Writer.exe.

Inserted the sd in the external slot of the (already running) Kobo.
With telnet:

###
mount /dev/mmcblk1p1 /mnt/sd
mknod /mnt/sd/dev/mmcblk1 b 179 8
mknod /mnt/sd/dev/mmcblk1p1 b 179 9
mknod /mnt/sd/dev/mmcblk1p2 b 179 10
mknod /mnt/sd/dev/mmcblk1p3 b 179 11
##
rm /mnt/sd/etc/udev.tgz
##
sed -i -e 's/mmcblk0p/mmcblk1p/g' /mnt/sd/etc/init.d/rcS
##
umount /mnt/sd
mount /dev/mmcblk1p3 /mnt/sd
dosfsck /mnt/sd
##
umount /mnt/sd
reboot

[sti]

Hello tshering,

indeed the offsets might be different on the Kobo Touch or maybe the flag does not exist at all. Assuming they are the same, I am wondering about

position 0x80040

On the Aura H2O the byte is stored at position 47 within the hardware confiuration area. There is a header of 16 bytes before that, so within the config it is at position 0x3F (63). So I guess you're just off by one byte.

In any case, being logged into the kobo I suppose you can run

ntx_hwconfig -s /dev/mmcblk1

to read the contents of the hardware configuration on the external SD card. Look for

[47] BootOpt=ESD:ON

If it says OFF you changed the wrong byte. If the name of byte 47 is not BootOpt, we have to look into the u-boot sources how it works on the Touch. The device ID (or byte 0 PCB in the hardware configuration) would be useful then.

Hope this helps.

Stefan

[tshering]

Thank you for the response, Stefan!
I had already some doubt whether my calculation was correct. After a long day, I was too tired to think it over again, and set the byte before and the one after too, just to be on the save side. (Maybe I should have mentioned this.) Today I set only byte 47.

[root@(none) ~]# ntx_hwconfig -s /dev/mmcblk1
...
[0] PCB='E60610D'
...
[47] BootOpt='[+] 0x01'
...
[root@(none) ~]# cat /proc/cmdline
console=ttymxc0,115200 rootwait rw quiet lpj=3997696 root=/dev/mmcblk0p1 rootfst
ype=ext4 hwcfg_p=0x7ffffe00 hwcfg_sz=512 waveform_p=0x7fefd000 waveform_sz=10603
52 mem=254M

[sti]

Hello tshering,

is the cat /proc/cmdline after trying to boot from the external SD? If so, it looks like it doesn't work. I was going to ask about the KeyPad (byte 1) value but found its value on the net (1Key). I also found the u-boot sources for the Touch to be different, but the relevant part is the same. After some reading I draw the following conclusions:

The Touch does not use the BootOpt flag at all. From the u-boot sources I believe it will boot the system partition on an external SD card when:

• the external SD card is present
• the upgrade key is pressed
• and the power button is pressed

As there is only one button I suppose it functions as upgrade key.

However, if it fails to detect the SD card or the power button press it will apparently boot into recovery.

Good luck
Stefan

[tshering]

Stefan, thank you again! Yes, cat/proc/cmdline was after trying to boot from external SD.
I now tried it with a Kobo Glo, with the same result.

[root@(none) ~]# ntx_hwconfig -s /dev/mmcblk1
HW CONFIG v1.3 @1024 secno, size=35 bytes :
NtxHwCfg_GetCfgFldStrVal:[WARNING]Config version too old !! Please update config file !!
[0] PCB='E606B0'
NtxHwCfg_GetCfgFldStrVal:[WARNING]Config version too old !! Please update config file !!
[1] KeyPad='FL_Key'
...
[34] HallSensor='TLE4913'
[35] DisplayBusWidth=[+]
[36] FrontLight_Flags=[+]
[37] PCB_Flags=[+]
[38] FrontLight_LEDrv=[+]
[39] VCOM_10mV_HiByte=[+]
[40] VCOM_10mV_LoByte=[+]
[41] PCB_REV=[+]
[42] PCB_LVL=[+]
[43] HOME_LED_PWM=[+]
[44] PMIC=[+]
[45] FL_PWM=[+]
[46] RTC=[+]
[47] BootOpt=[+]
[48] Touch2Ctrl=[+]
[49] Touch2Type=[+]
[50] GPS=[+]
[51] FM=[+]
[root@(none) ~]# cat /proc/cmdline
console=ttymxc0,115200 rootwait rw quiet lpj=4997120 root=/dev/mmcblk0p1 rootfst
ype=ext4 hwcfg_p=0x7ffffe00 hwcfg_sz=512 waveform_p=0x7fee2c00 waveform_sz=11678
72 mem=254M mx50_1GHz

I copied a little more of the output to show that, different from the Kobo Touch, starting with byte 35 no values are displayed.