S905 failed to boot from emmc

[pista]

<removed>

[hexdump]

@pista - there seems to be some backup gpt code in there - https://github.com/hexdump0815/u-boot-chainloading-for-arm-chromebooks/blob/master/misc.cbr/supress-efi-errors-v2021.01.patch#L44 ... did you get any gpt errors from u-boot? - the above patch is removing all the errors from u-boot which were spamming my console on this chromebook, so you should see them as well in theory i guess.

 

looking roughly at the u-boot efi code at https://source.denx.de/u-boot/u-boot/-/blob/master/disk/part_efi.c#L676-711 i'm not sure if it really works with the backup gpt only - maybe on the chromebook part of the primary gpt sturcture is still there and only parts are broken, so that the backup gpt is then used ... will have to look closer at the u-boot source for this.

 

[pista]

@hexdump No errors, just info that no valid part table found:

 

U-Boot 2020.07-dirty (Oct 18 2021 - 02:27:09 +0200) hexdump-gxbb
...
=> mmc dev 2
switch to partitions #0, OK
mmc2(part 0) is current device
=> mmc part
## Unknown partition table type 0


The 'gpt verify' fails too:

=> gpt verify mmc 2
No partition list provided - only basic check
GUID Partition Table Header signature is wrong: 0x0 != 0x5452415020494645
gpt_verify_headers: *** ERROR: Invalid GPT ***
Verify GPT: error!

 

Observe gpt_verify_headers:
 

int gpt_verify_headers(struct blk_desc *dev_desc, gpt_header *gpt_head,
		       gpt_entry **gpt_pte)
{
	/*
	 * This function validates AND
	 * fills in the GPT header and PTE
	 */
	if (is_gpt_valid(dev_desc,
			 GPT_PRIMARY_PARTITION_TABLE_LBA,
			 gpt_head, gpt_pte) != 1) {
		printf("%s: *** ERROR: Invalid GPT ***\n",  // <-- this is the error I got
		       __func__);
		return -1;
	}

	/* Free pte before allocating again */
	free(*gpt_pte);

	if (is_gpt_valid(dev_desc, (dev_desc->lba - 1),  // <-- Here it is checking the Backup GPT header
			 gpt_head, gpt_pte) != 1) {
		printf("%s: *** ERROR: Invalid Backup GPT ***\n",
		       __func__);
		return -1;
	}

	return 0;
}

 

So, this method doesn't even check the Backup GPT header if Primary is invalid (or missing in my case). I think as-is u-boot won't work with only the Backup GPT present. Sure, it could be patched, but this would require more coding then I'm willing to do. I do coding for living, and this exercise to get Armbian running from eMMC was kind of a distraction from work lol.

Let's say I get this part working, then I would need to recompile/patch the original AML u-boot too - if I'm going to stick with the 'chainloading' design. The hard part would be integrate the recompiled AML u-boot into the original firmware, so I can burn it. The other option would be just try and use the mainline u-boot (no chainloading). Would be an interesting project, but a long shot.

I think I'm just going to use the 'mmc read' method. Maybe I'll get back to this in future. Thanks for you assistance, I've enjoyed working with you.

 

[hexdump]

@pista - i enjoyed this conversation a lot too and i agree with you that we have reached a point now at which your solution simply seems to be the best of the available ones - trying to hack the gpt option to make it work will in the end not end up in a solution which is really more simple

 

thanks a lot for sharing your solution, which is at least a possible solution and for doing all those experiments

 

best wishes - hexdump

[jock]

Sorry for breaking into discussion, but I'm puzzled about u-boot chainloading. What problem does it solve?

[hexdump]

@jock - there is no really useable mainline u-boot for the amlogic boxes (actually one can build one for one of the amlogic dev boards in u-boot - p201 or similar and they kind of work, but sometimes the dtb's do not match the hardware well enough) and those boxes are very easy to brick, plus default boot is from emmc. on top of that a few boxes even have nand instead of emmc. oh - and the memory timinig is done by blobs which seem to not be that interchangeable between different boxes plus it is a very complex procedure (in no way comparable to the easiness of rockchip - its more onion style with checksums on each layer - https://github.com/repk/gxlimg helps a lot for the s905x here) of many steps to build the final u-boot from the blobs and the compiled u-boot.

 

due to this i think balbes150 (or maybe it was initially someone else) had the idea to just supply the legacy u-boot with a proper boot.scr style script to boot mainline linux kernels in a somewhat flexible way from sd card or usb. based on that i moved on one step by chainloading mainline u-boot from legacy u-boot, so that you get the features and flexibility of mainline u-boot (like extlinux.conf etc.) without the risk to brick the box. but even this is quite complicated as you better do not touch the first 700mb (older) to 1.5gb (newer) of the emmc as legacy u-boot reads a dtb from somewhere inbetween there and is very unhappy if it does not find it.

 

rockchip and allwinner are really a dream compared to this mess

 

best wishes - hexdump

 

ps: another thing is that there is no usb tool comparable in power to what is there for rockchip for instance

 

pps: i have some s905x, s905x2, s905x3 and s912 boxes running with native mainline u-boot but gave up on trying to generalize this setup as there is so much which can go wrong - s905 is even worse as there is no such tool as gxlimg to disassemble (to get the memory training info) and reassemble the blobs

[jock]

@hexdump

Thanks for the explanation!

I tinkered years ago with gxbb... I found amlogic has the same "maskrom mode" similar to rockchip; the first thing I did was erase the flash (that just some months ago I discovered to be NAND ) and then let it boot from sdcard.

I heard that the amlogic ROM could also boot from USB, but did never try by myself.

 

I remember the issues about the ddr blob initialization, once I tried one made by Odroid for their C2 board (if I remember well): the ddr blob detected it was not an odroid and refused to boot on my board.

I used @TonyMac32 repository https://github.com/Tonymac32/Amlogic-u-boot/tree/master/fip (requires two different older gcc toolchains) to produce the series of ddr blobs that were generic enough and run fine on my board (see https://github.com/paolosabatino/armbian-build/tree/mxq-s905-v20/packages/blobs/meson/mxq-s905-v20 ); then just applied the known blob mangling things that were already in armbian sources and finally could compile a running mainline u-boot.

 

Actually my mxq-s905-v20 repository is a bit abandoned but should compile and produce a working image for S905 tv box with mainline u-boot.

I don't know if it boots on eMMC though, since I have NAND I couldn't try.

 

Dunno if this may be helpful somehow, but this was my experience...

 

[hexdump]

@jock - thanks for the info and the links ... yes it is possible to get it working (got it working too - here are my notes: https://github.com/hexdump0815/u-boot-misc/blob/master/readme.gxb plus some more readme.g* around for the other amlogic socs), but its more complicated than the other socs in my opinion ... yes odroid c2 has boot blobs which are locked to odroid hw, but there are other blobs available which work ... booting from emmc is even more complicated as the boot block starts from sector 0 and covers the partition table area (as it seems the first sector is even checksummed in the bl2, so no way to even put a partition table in there by hand as @pista has found out) - at least @pista found a clever way to make it work somehow still in this thread ... some amlogic boxes (mi box II and a95x f2 or f3 i think) even have an encrypted boot block, so there is no chance at all to get anything working except using legacy u-boot and maybe chainloading mainline u-boot from it ...

 

afaik amlogic cannot boot from usb storage but you can supply it a boot block, kernel etc. via usb - see: https://github.com/superna9999/pyamlboot

 

[jock]

Looking into the u-boot source code I found this CONFIG_EFI_PARTITION_ENTRIES_OFF:

 

@pista should be able to displace the GPT partition table away from sector 0 with this.

It is configurable within u-boot .config under the Partition Types submenu

 

edit: thinking about... maybe the kernel has to be informed about that displacement too...

 

[pista]

@jock This is a good find! Kernel (using 'gpt' cmd line param) is happy with a backup GPT table at the end of the eMMC. So, this could be a solution for u-boot. Still the problem is the Amlogic u-boot which AFAIK doesn't have gpt support, so would need to re-build it, and then somehow properly reinstall. Probably easier would be then just replace it with the mainline u-boot. But I'll give it a try... see if can get at least the chainloaded u-boot recognize the GPT.

[jock]

14 hours ago, pista said:

@jock This is a good find! Kernel (using 'gpt' cmd line param) is happy with a backup GPT table at the end of the eMMC. So, this could be a solution for u-boot. Still the problem is the Amlogic u-boot which AFAIK doesn't have gpt support, so would need to re-build it, and then somehow properly reinstall. Probably easier would be then just replace it with the mainline u-boot. But I'll give it a try... see if can get at least the chainloaded u-boot recognize the GPT.

When I toyed around with my S905 mainline u-boot was flawless for me. Of course, as @hexdump says, there are some things that need the proprietary one (like NANDs).

But if you have eMMC, I think you won't need that old piece of code.

[pista]

@jock @hexdump So, it didn't work for me. I've inserted both primary and backup GPT at the end of the eMMC:
 

# xxd -a -g 0 emmc_gpt.bin 
00000000: 00000000000000000000000000000000  ................  -----------------
*                                                                    MBR
000001c0: 0200ee27e9be01000000ffdfea000000  ...'............
000001d0: 00000000000000000000000000000000  ................
000001e0: 00000000000000000000000000000000  ................
000001f0: 000000000000000000000000000055aa  ..............U.  -----------------
00000200: 4546492050415254000001005c000000  EFI PART....\...  -----------------
00000210: cc7a5ba1000000000100000000000000  .z[.............   PRIMARY HEADER
00000220: ffdfea00000000002200000000000000  ........".......
00000230: dedfea0000000000f0aa3b318995fc43  ..........;1...C
00000240: 9a17bc786b4c16fe0200000000000000  ...xkL..........
00000250: 8000000080000000b6d57abf00000000  ..........z.....
00000260: 00000000000000000000000000000000  ................
*                                                             -----------------
00000400: af3dc60f838472478e793d69d8477de4  .=....rG.y=i.G}.  -----------------
00000410: 596f0b4087be074b856fc934c732f8e6  Yo.@...K.o.4.2..   PRIMARY ENTRIES
00000420: 00a02b0000000000ffdf310000000000  ..+.......1.....
00000430: 00000000000000004c0069006e007500  ........L.i.n.u.
00000440: 78002000660069006c00650073007900  x. .f.i.l.e.s.y.
00000450: 7300740065006d000000000000000000  s.t.e.m.........
00000460: 00000000000000000000000000000000  ................
00000470: 00000000000000000000000000000000  ................
00000480: af3dc60f838472478e793d69d8477de4  .=....rG.y=i.G}.
00000490: 23c888f98a92884c93efa31ce6df24a9  #......L......$.
000004a0: 00e0310000000000dedfea0000000000  ..1.............
000004b0: 00000000000000004c0069006e007500  ........L.i.n.u.
000004c0: 78002000660069006c00650073007900  x. .f.i.l.e.s.y.
000004d0: 7300740065006d000000000000000000  s.t.e.m.........
000004e0: 00000000000000000000000000000000  ................
*                                                             -----------------
00004400: af3dc60f838472478e793d69d8477de4  .=....rG.y=i.G}.  -----------------
00004410: 596f0b4087be074b856fc934c732f8e6  Yo.@...K.o.4.2..   BACKUP ENTRIES
00004420: 00a02b0000000000ffdf310000000000  ..+.......1.....
00004430: 00000000000000004c0069006e007500  ........L.i.n.u.
00004440: 78002000660069006c00650073007900  x. .f.i.l.e.s.y.
00004450: 7300740065006d000000000000000000  s.t.e.m.........
00004460: 00000000000000000000000000000000  ................
00004470: 00000000000000000000000000000000  ................
00004480: af3dc60f838472478e793d69d8477de4  .=....rG.y=i.G}.
00004490: 23c888f98a92884c93efa31ce6df24a9  #......L......$.
000044a0: 00e0310000000000dedfea0000000000  ..1.............
000044b0: 00000000000000004c0069006e007500  ........L.i.n.u.
000044c0: 78002000660069006c00650073007900  x. .f.i.l.e.s.y.
000044d0: 7300740065006d000000000000000000  s.t.e.m.........
000044e0: 00000000000000000000000000000000  ................
*                                                             -----------------
00008400: 4546492050415254000001005c000000  EFI PART....\...  -----------------
00008410: e68b23ae00000000ffdfea0000000000  ..#.............    BACKUP HEADER
00008420: 01000000000000002200000000000000  ........".......
00008430: dedfea0000000000f0aa3b318995fc43  ..........;1...C
00008440: 9a17bc786b4c16fedfdfea0000000000  ...xkL..........
00008450: 8000000080000000b6d57abf00000000  ..........z.....
00008460: 00000000000000000000000000000000  ................
*
000085f0: 00000000000000000000000000000000  ................  -----------------

 

and set CONFIG_EFI_PARTITION_ENTRIES_OFF to the offset of the Primary Entries.
In mainline u-boot I tested:
 

=> mmc dev 2
switch to partitions #0, OK
mmc2(part 0) is current device

=> mmc part
## Unknown partition table type 0

=> part list mmc 2
## Unknown partition table type 0

=> gpt verify mmc 2
No partition list provided - only basic check
GUID Partition Table Header signature is wrong: 0x0 != 0x5452415020494645
gpt_verify_headers: *** ERROR: Invalid GPT ***
Verify GPT: error!

=> gpt guid mmc 2
GUID Partition Table Header signature is wrong: 0x0 != 0x5452415020494645
find_valid_gpt: *** ERROR: Invalid GPT ***
find_valid_gpt: ***        Using Backup GPT ***
313baaf0-9589-43fc-9a17-bc786b4c16fe
success!

 

Note, that the last command reads the GUID from the Backup GPT, but none of the other commands work. I have to say, I'm puzzled by the GPT implementation in u-boot. I would have expected it to work the same as linux kernel - with kernel cmd line Linux uses the backup GPT wo problems. It looks like if u-boot can't find a valid Primary GPT, it doesn't use the Backup even it is aware of it.

 

So, without having u-boot working with only the Backup GPT I can't even attempt to replace the AML u-boot with mainline. This is because the boot ROM is looking for the boot loader in sector 0, so no regular GPT (or MBR) can be created. @jock are you saying that you didn't have this problem regarding both ROM and part. table using the same location on the disk?

[jock]

Well that's not something that surprises me. A lot of u-boot code is just crap,with half-baked drivers, inconsistent nomenclature, bugs everywhere, and much more. It is one of the worst things to work with.

BTW, I always booted from sdcard because my board has a NAND chip, so I could not ever try anything

[pista]

@jock Ok, got it. Yes, the issue with S905 where ROM is using sector 0 of eMMC doesn't affect SD booting. It is a problem only when you are trying to boot from eMMC.

[zr111983]

21.10.2021 в 17:53, jock сказал:

Well that's not something that surprises me. A lot of u-boot code is just crap,with half-baked drivers, inconsistent nomenclature, bugs everywhere, and much more. It is one of the worst things to work with.

BTW, I always booted from sdcard because my board has a NAND chip, so I could not ever try anything

Jock hello. I have a question for you. Could you build multitool for amlogic?
This is a very good tool and is very helpful with rockchip.
For

[jock]

4 hours ago, Руслан Зинеев said:

Jock hello. I have a question for you. Could you build multitool for amlogic?
This is a very good tool and is very helpful with rockchip.
For

Indeed it is possible, but I have only a single S905 box without the original firmware nor a deep knowledge of the boot process of amlogic socs.

It would be limited to S905 and probably cover just the simple boot cases.

[zr111983]

18 часов назад, jock сказал:

Indeed it is possible, but I have only a single S905 box without the original firmware nor a deep knowledge of the boot process of amlogic socs.

It would be limited to S905 and probably cover just the simple boot cases.

I will wait impatiently multitool , thank you for earlier

[flymike]

On 10/13/2021 at 4:45 AM, pista said:

I resolved this by dedicating 2 areas at the end of eMMC: 200MB 'boot', and the rest (~6GB) as 'root'. I exposed these to Linux using kernel command line parameter: 'blkdevparts=mmcblk1:209715200@1463812096(boot),-@1673528320(root)'.

 

In Linux I copied the root directory tree to /dev/mmcblk1p2. I left /dev/mmcblk1p1 (the boot "partition") without file system, and copied (dd) uboot (the mailine uboot), kernel, ramdisk, and dtb there at the predefined block positions, e.g: 'dd if=zImage of=/dev/mmcblk1p2 bs=512 seek=2859008 count=54841'.

 

In Amlogic u-boot instead of fatload I used 'mmc read' to load all files, e.g.: to load the kernel: 'mmc read 0x08080000 0x2BA3FC 0xD639'.

 

In the chainloaded Mainline u-boot I used 'booti 0x08080000 0x13000000 0x08008000' as 'bootcmd' to start the system.

 

With this setup I can now boot from eMMC. Thanks for you assistance; your comments on the subject in various threads on the forum were very helpful.

 

Hi @pista

I have a MiniMX 2G/16G S905 TV box, it was running with LibreELEC custom build. I decide to try Armbian on it since the box no longer in use.

 

Installed with balbes150 build on both SD and USB drive are all good (using gxbb-vega-s95-telos.dtb with ethernet only since p200/201 has got no ethernet nor wifi), but I really want to run the system from the internal storage.

 

Coming across your post, I really like your implementation of running entire system on eMMC. Yes I bricked the box once trying to install the system to eMMC by blindly run the emmc install script

 

I was trying to follow your steps, only archived the "dedicating 2 areas at the end of eMMC: 200MB 'boot', and the rest (~6GB) as 'root'" so far, and have no idea how to proceed further... Hope you can give me some help.

 

"copied the root directory tree to /dev/mmcblk1p2"

- Do this with 'dd if=/dev/mmcblk0p2 of=/dev/mmcblk1p2'?

 

"(the boot "partition") without file system, and copied (dd) uboot (the mailine uboot), kernel, ramdisk, and dtb there at the predefined block positions, e.g: 'dd if=zImage of=/dev/mmcblk1p2 bs=512 seek=2859008 count=54841'"
- Do you mean of=/dev/mmcblk1p1 since p2 is used for ROOTFS?

 

and after that, how to apply these two:

 

"used 'mmc read' to load all files, e.g.: to load the kernel: 'mmc read 0x08080000 0x2BA3FC 0xD639'"

- which file should be changed (boot.ini?)

 

Where to apply this? - 'booti 0x08080000 0x13000000 0x08008000' as 'bootcmd' to start the system.

 

Thanks in advance.

[ause]

I'm curious about the detailed procedure as well. I have some GXBB S905 P201 TV boxes with 1GB ram and 4GB EMMC. Currently I'm running Manjaro ARM Minimal from TF card and my Rocket.chat server works great on it  Things would be even better if we could fit everything into emmc without TF card .

[halfpipe]

@pistaI have this same box, I'm trying to run armbian first time but not being able to, I tried to use the same files you are using but no luck yet, can you give me some hand? PM me please if possible

[TRS-80]

@halfpipe @pista,

 

Please share whatever you learn publicly in the forum for the benefit of all (as opposed to PM).  This makes it easier for other people who come along after you searching for answers, too.

 

Thanks.

[halfpipe]

@pista I managed to boot my box, all working good, gigabit eth, wifi, etc.. the only thing that I was unable to make it work was the OTG port which was the main reason I bought this box, and indeed I want make it run as otg instead of host, have you ever made this port work? on android its working normally..

[Michelsup]

On 9/7/2021 at 5:04 PM, pista said:

As for bricking the box, I already did it a few times and had to short the chip + reinstall Android.

Hi Pista. I've spent hours trying to find the pads to short. Could you tell me the test points you use for your U1 please?

[d51x]

Hi all who have s905 and want to boot armbian from emmc )

 

I have Tronsmart Vega S96 Meta with 2Gb Ram and 8 Gb ROM (actually 7,2 Gb emmc)

Some time I used TV Box with armbian 20.08 kernel 5,9 from @balbes150 (thanks for this build)

Recently I find out there is armbian ophub with new kernels - Armbian 22.08.0-trunk Bullseye with Linux 5.15.55

I tried it and than decide to try move armbian to emmc.

 

I spent a few day to manualy boot from emmc. It worked out.

 

And I wrote instruction (on Russian only, sorry) and try adopt armbian-install.sh script to my needs. Please use google-translate to read.

You can find instruction and script to move armbian to emmc here https://github.com/d51x/armbian-s905

There are compiled kernel and ramdisk in example folder. The kernel support option blkdevparts. Original kernel from ophub don't has it.

 

I moved armbian from different SD card and USB SSD several time with both methods - manualy and script. 

Flashed android firmware and then move armbian to emmc again.

 

You do all this at your own peril and risk. You have to be ready to unbrick eour device )))

 

If something does not work out according to my instructions, try to figure it out yourself.

 

Thank to @pista and @hexdump posts for information i used in my work.

 

[SteeMan]

6 hours ago, d51x said:

Recently I find out there is armbian ophub with new kernels - Armbian 22.08.0-trunk Bullseye with Linux 5.15.55

 

@d51x Note that these ophub builds have nothing to do with armbian.  The authors do not participate in these forums or in armbian development.  They are using the armbian name under false pretenses.  There are some developers in the armbian community who feel their work is being used without proper credit and strongly discourages anyone from using the ophub builds.

I'm just providing information to allow individuals the ability to make an informed choice before they dive into the ophub builds.

[79bass]

I know this is an old post, but I noticed  that @pista has the same box I’m trying to run.

 

I really like the minix neo U1, because the board itself has already soldered jtag and other pins, and everything seems to be properly labeled (it’s not granted that manufacturers write which port is what!)

 

I’m trying to boot this box with a recent version of uboot and linux, but it seems Impossible 😫.

 

@pista, if you are still around, could you please write which version of u-boot/kernel/armbian is working for you?

 

thanks already!

Edited October 23, 2022 by 79bass

[79bass]

never mind, I've actually seen @pista configuration in OP, so the information I asked was already in plain sight!

apologies for asking without even looking carefully first.

 

Apparently, my minix U1 boots only using an SD card, it really doesn't like USB. Everything seems to work OKish from SD.

 

Edited October 24, 2022 by 79bass
grammar

[bacco70]

On 10/13/2021 at 1:45 PM, pista said:

'blkdevparts=mmcblk1:209715200@1463812096(boot),-@1673528320(root)'.

sorry, where we must put this ?