Le Potato - writing armbian to eMMC

[Tido]

Before I give it a try, has anyone already tried to write armbian to eMMC of the Le Potato ?

If not, can you give me a hint where I shall read in order not to destroy the storage?

* Thank you *

---

it gets interesting from page 2 onwards

Edited September 5, 2018 by Tido
Page 2

[mattkosem]

I'm also curious about this.  I've tried flashing all of the available Linux images I can find to mine (nightly and non-nightly debian and ubuntu from armbian and the official image from Libre).  None appear to boot.  The only way I could get the card to a writable state was to attach it to the board between the time that the bootloader started reading the kernel and the time that the kernel started booting (otherwise it would just boot the Android image that came on it).  Other Amlogic-based boards seem to support the familiar boot.ini file for configuring the bootloader, but I don't see that in any images for this board.  Is there some U-Boot build/customization work that needs to be done?  I've tried editing the boot.scr file with a hex editor, and even updating the same string that appears toward the beginning of the drive setting the root device to /dev/mmcblk0p2 and none of it seems to help.  I've tried some Odroid images as well and they don't appear to boot.

 

Contacting Libre seems to yield no responses so far (on anything at all, not just this issue), but I do see some u-boot sources seemingly targeted at this board from another member of this forum here: https://github.com/Tonymac32/Amlogic-u-boot

 

Anyone know what's involved in configuring/building this in a manner that can boot from eMMC and flashing it to the eMMC module, or if any additional steps are needed?  I've found some instructions for dding u-boot bin files to cards for other boards, which seem to involve writing certain parts of the file to different offsets on the device, but I don't know what determines what gets written where.

 

--Matt

[TonyMac32]

Hello mattkosem,

 

    I have not yet attempted it, however, there is a different u-boot.bin between eMMC and SD.  SD uses "u-boot.bin.sd.bin" where eMMC simply uses "u-boot.bin"

 

But, that's not the whole story.

 

At this point the bootloader could be written to the eMMC and should at least attempt to boot.  The bootscript/etc need to point at the right device or else it will have no idea where to get the device tree/kernel/etc.

 

You should have a u-boot button, I think this may be the method of entering the proper amlogic burning mode (to avoid continuously inserting/removing that eMMC.  google the Amlogic usb burning tool and read up, it's not a tool without risk, the USB port that wakes up for me is the top-left, you will need a USB A to A cable, I made one.

 

Now, my board does not have the boot button, I have a reset header instead (early board), so I can't try that directly.

 

[edit]  Using the "hurry up and plug it in afterr uboot launches method I've "nuked" the eMMC u-boot, so now I can try some different things, assuming I can get it to boot with the emmc plugged in (I got some strange bl checksum errors I'll have to look into)

[mattkosem]

Hey Tony,

 

Ok, so images will have to be built for eMMC or SD based on that?  Or do they end up in different spots on the device?

 

When you say "The bootscript/etc need to point at the right device or else it will have no idea where to get the device tree/kernel/etc.", are you referring to a script at U-Boot build time or a script on the boot partition of the device?  I've managed to locate a setenv line targeting the root partition and mentioning the location of the kernel image both in the boot partition, and in some space toward the beginning of the device, and modified both with a hex editor to target the eMMC device (mmcblk0) instead, but that didn't help me.

 

Perhaps this u-boot button behind the ethernet jack is the answer.  Any idea how to use it?  Any googling I've done hasn't really yielded anything material on it.  Would I press it before writing to the device?  I have come across mention of that tool thus far, but have seen only unsuccessful attempts to use it elsewhere in relation to this board.  Libre was nice enough to include a USB A-A cable with my eMMC module, so at least I don't have to make one   We don't have any Windows PCs in the house, so it doesn't seem likely that that tool will be helpful over here.   I'll have to think on that one or borrow a system.

 

--Matt

[Tido]

7 hours ago, mattkosem said:

u-boot button behind the ethernet jack is the answer

Well spotted, Uboot switch K11 - I totally forgot about this approach.

On the schematic you find K11 on the Flash sheet No. 6, the switch is connected to CPU U1C - connection L3 to ground (10k resistor).

On the schematic you find K11 on the CPU sheet No. 4 it is connected to Ground and DVSS32 on the CPU.

 

---

If you don’t like USB Burning Tool or don’t have the necessary USB cable https://www.cnx-software.com/2016/11/19/how-to-create-a-bootable-recovery-sd-card-for-amlogic-tv-boxes/

 

Burning .IMG file to Amlogic M8 devices using sdcard http://www.stane1983.com/index.php/2015/05/05/burning-img-file-to-amlogic-m8-devices-using-sdcard/

 

Edited January 23, 2018 by Tido
more details

[mattkosem]

Keep us posted if you beat me to trying it. I've got a line on a windows PC to bum tomorrow, but might not have a chance to try it until Thursday.

 

--Matt

[mattkosem]

I had a chance to give the took a try on a windows laptop. The upper center USB port got me the "WorldCup Device" the tool could see, but no images I tried could get past import since they all said "Parse burning image fail".

 

I get the impression that the LibreElec folks might have eMMC booting working. I may give that image a chance when I have a moment.

 

--Matt

[TonyMac32]

For kicks try an image intended for a "p212" development board and see if it burns properly.

[mattkosem]

The LibreELEC image was different enough to change the behavior of booting somewhat.  Instead of getting skipped over entirely like the other images, that one on the eMMC makes it just not boot.

 

@TonyMac32 - Any chance you've got some pointers on building those U-Boot sources?

 

I'm about to shut down for tonight, but I can try to find a p212 image.

 

--Matt

[TonyMac32]

1 minute ago, mattkosem said:

@TonyMac32 - Any chance you've got some pointers on building those U-Boot sources?

 

Yep, it's a complete PITA.    It wants gcc-linaro-arm-none-eabi-4.8-2013.11_linux to compile.  Otherwise it's relatively straightforward.  ./mk gxl_libretech_cc and the resulting binaries are in the fip directory.  I have to step myself through it periodically because I don't do it often.  You ahve to make sure to add the compilers directory to the path.

[TonyMac32]

https://github.com/BayLibre/u-boot/tree/readme

 

Read through this, it has eMMC install described as an option, although mine shows up as 3 devices, so I'm not as sure...

[mattkosem]

9 hours ago, TonyMac32 said:

https://github.com/BayLibre/u-boot/tree/readme

 

Read through this, it has eMMC install described as an option, although mine shows up as 3 devices, so I'm not as sure...

Aw sweet, that looks like the ticket!

[mattkosem]

Well, I started going through those instructions but couldn't run the GCC bundles on anything I have set up.  They seem to be 32-bit x86 binaries, and I have only non-multilib x86_64, ARMv6, and AARCH64 systems ATM

 

Oh well, I can set up a 32-bit VM or something when I have a moment.  Between the support for both emmc and sdcard support binaries, and a patch to make configs read from/save to the disk, this sounds promising.

 

--Matt

[mattkosem]

I built the u-boot bin files as per the instructions, but didn't really get as far as I'd have hoped afterwards.

 

One tip I have along the way for building is that the call to that pyc file needs to be preceded by "python " for it to actually work.

 

Some notes on what I did find:

1. After dding the uboot bin file to /dev/mmcblk0, there was no longer a partition table (are the instructions wrong here?  Should this actually be one of those *boot* devices on mmcblk0?)

2. It doesn't seem possible to create a vfat partition like those instructions say.  100 isn't a usable starting offset, 300 blocks is way too little space, etc.  I ended up creating a 256MB vfat partition there, copying kernel/initrd files and a boot.env file ready to boot to an existing working root from it, but it didn't really seem to work.

 

I get a solid red and blue and the device won't boot with the emmc card attached after going through that.

 

All in all, I've got the files...just need to spend some more time determining how/where they get written.

 

--Matt

[TonyMac32]

For our images, we use a single partition, so things could get interesting in that respect.  I'm also not sure how the partitioning of the eMMC works, it actually appears on my board as 3 devices.

[mattkosem]

Yeah, that's uncharted territory for me as well.  I'm used to having a vfat /boot partition on SBCs.  

 

Mine shows up as even more than that:

brw-rw---- 1 root disk 179, 0 Jan 26 03:22 mmcblk0
brw-rw---- 1 root disk 179, 32 Jan 26 02:47 mmcblk0boot0
brw-rw---- 1 root disk 179, 64 Jan 26 02:47 mmcblk0boot1
brw-rw---- 1 root disk 179, 1 Jan 26 02:47 mmcblk0p1
brw-rw---- 1 root disk 179, 96 Jan 26 02:47 mmcblk0rpmb 

This is at least roughly consistent with the layout I've seen on other boards.  The only  experience I have with flashing an emmc module directly on an SBC involves Android images on Hardkernel boards (this sort of processhttps://odroidinc.com/blogs/news/how-to-upgrade-the-odroid-xu4-android-emmc-module-to-the-latest-os-version), and was automated :X.  It would be nice if these cards could be snapped into an adapter like Hardkernel provides for ODROID devices to accomplish tasks like this.

 

mmcblk0boot0 and mmcblk0boot1 both appear to storage areas be 4MB, and writable.  I guess I could try writing this u-boot image to one or both of them.  Any chance you've got some handy docs making sense of those devices?  I came across this, but haven't had a chance to read far into it yet: http://forum.khadas.com/t/emmc-flash-layout/133

 

--Matt

 

Edited January 26, 2018 by Tido
added code box

[Tido]

41 minutes ago, mattkosem said:

some handy docs making sense of those devices

 

On 23.1.2018 at 7:52 PM, Tido said:

If you don’t like USB Burning Tool or don’t have the necessary USB cable https://www.cnx-software.com/2016/11/19/how-to-create-a-bootable-recovery-sd-card-for-amlogic-tv-boxes/

 

[mattkosem]

Neat, I'll take a peek at that when I have a moment.

 

These are some other locations that seem like they may have helpful resources:

http://docs.khadas.com/social/BuildBootloaderAndRamfs/

https://forum.odroid.com/viewtopic.php?f=138&t=20869&p=180545&hilit=booting+alternate+kernels#p149212

http://www.denx.de/wiki/DULG/UBootScripts

 

Maybe tftp is the way to get that stuff loaded...

 

--Matt

[mattkosem]

Well, that USB flash stuff seems to rely upon starting with an Amlogic-layout Android image.  Even the Libre Android image doesn't seem to be in that format, so I'm not sure its viable.

 

--Matt

[mattkosem]

I came across this too, but it seems to be centered around using a writer adapter. https://wiki.odroid.com/odroid-c2/software/building_u-boot. The script in that tarball dds the bootloader and uboot to certain spots on the device. 

 

--Matt

[zador.blood.stained]

On 26.01.2018 at 7:02 AM, TonyMac32 said:

I'm also not sure how the partitioning of the eMMC works, it actually appears on my board as 3 devices.

There are "hidden" eMMC partitions (usually at least boot0, boot1, also RPMB on newer eMMC revisions)

https://www.slideshare.net/linaroorg/intro-to-emmc

 

Some SoCs load u-boot from those boot partitions, some just ignore them.

[mattkosem]

Those boot0 and boot1 partitions don't seem to be writable by default. I can see their contents though.

 

Anyone know anything about a"ddbr" tool?  I see it mentioned in reference to writing bootloader files to Amlogic boards, but can't find much about it.

[zador.blood.stained]

22 minutes ago, mattkosem said:

Those boot0 and boot1 partitions don't seem to be writable by default. I can see their contents though.

Usually from Linux this can controlled via sysfs like this (needs to be executed as root):

echo 0 > /sys/block/mmcblk0boot0/force_ro

 

[mattkosem]

Hardkernel's "selfinstall" images for Android seem to have a purpose-build solution for this sort of flashing (which they use for their Android images): https://github.com/codewalkerster/android_device_hardkernel_odroidc2/blob/s905_5.1.1_master/selfinstall.mk

 

At this point, I'm grasping at enough straws that I'll give it a look when I next have a moment.

 

--Matt

[mattkosem]

Well, it's not Armbian, but I am able to make the official Libre 16.04 image boot and run from just the EMMC card with a simple tweak.

 

Basically I created a boot.txt file with this content

setenv bootargs console=ttyAML0 root=/dev/mmcblk0p2 rootfstype=btrfs rootflags=subvol=@ rootwait console=ttyAML0,115200 no_console_suspend
fatload ${devtype} ${devnum} $fdt_addr_r $fdtfile
fatload ${devtype} ${devnum} $kernel_addr_r Image
booti $kernel_addr_r - $fdt_addr_r

 

Then ran this command to make a new boot.scr:

mkimage -A arm -T script -O linux -d boot.txt boot.scr

I dropped the resulting new boot.scr in place of the original in the first partition on the card, and presto...it boots.  I did some tinkering in between (manually expanding the root partition and making a swap partition) that I'm not sure if is really important over the course of troubleshooting.  Not sure if that is/isn't actually a necessary thing to do.  Making the same basic change with a hex editor to the existing boot.scr didn't yield an identical file, so I have to assume some checksum that tool makes is the difference there.

 

I see a boot.scr in the Le Potatio Armbian image as well, which it may be possible to similarly replace with contents stripped from that file compiled with mkimage, but haven't had an opportunity to try that yet.

 

--Matt

[TonyMac32]

The text version is boot.cmd in the image

[mattkosem]

Neat, can I expect that uboot will load that file during boot like the Libre image does from it's vfat partition?

 

--Matt

[TonyMac32]

Our u-boot is set up to load that file from ext4, so there will most likely need to be some modifications to run from the eMMC.    I can probably look a bit more closely later today while I'm waiting for feedback on the Tinkerboard default kernel.

[Tido]

It comes with a u-Boot button, but does it also support SPI or FEL ?  because I saw this older posting: https://forum.armbian.com/topic/2454-fel-mass-storage-or-writing-images-directly-to-emmc/

 

[Tido]

While reading that @balbes150 is a specialist on TV boxes and they often run Amlogic s905x I thought I might be able to take this approach.

Balbes does a trick, that you can keep Android on the eMMC, but still boot another Linux from SDcard without removing the eMMC (which is soldered on TV-Boxes).

 

I have connected the UART cable, booted the device with the eMMC. At the end of the boot-process hit 'enter'

I  could read out the df -h:

p212:/ # df -h                                                                 
Filesystem        Size  Used Avail Use% Mounted on
tmpfs             868M  492K  868M   1% /dev
tmpfs             868M     0  868M   0% /mnt
/dev/block/system 1.9G  701M  1.2G  36% /system
/dev/block/data    11G   49M   11G   1% /data
/dev/block/cache  496M  404K  496M   1% /cache
tmpfs             868M     0  868M   0% /storage
/dev/fuse          11G   49M   11G   1% /mnt/runtime/default/emulated
/dev/fuse          11G   49M   11G   1% /storage/emulated
/dev/fuse          11G   49M   11G   1% /mnt/runtime/read/emulated
/dev/fuse          11G   49M   11G   1% /mnt/runtime/write/emulated

The tricky thing is now how to manipulate the Android-Image on the eMMC for Multiboot mode.