Armbian EMMC Image for NanoPi-K2

[martinayotte]

6 hours ago, TonyMac32 said:

dd if=$1/u-boot.bin bs=512 skip=1 of=$2 bs=512 skip=1 seek=1 conv=fsync > /dev/null 2>&1

Comparing that to original write_uboot_platform() doesn't show some relevant change since only "bs=512 skip=1" is repeated twice ...

We don't have "u-boot.bin.sd.bin" installed in /usr/lib/linux-u-boot-dev-nanopik2-s905_5.89_arm64/, there is only "u-boot.bin" and "u-boot.img", but I will look again in the build tree itself.

 

I've also search in https://wiki.odroid.com/odroid-c2/software/building_u-boot , and they say for eMMC "sudo dd if=u-boot.bin of=/dev/mmcblk0 bs=512 seek=97", followed by "You must use the u-boot.bin binary under the folder, “u-boot/sd_fuse/u-boot.bin” . This is confusing me since Armbian build process is different ...

[TonyMac32]

In our sources file you will see we call out the .bin.sd.bin, and refer to it as u-boot.bin.

The extra skip lines up the data being written without having to find away to package the other binary

Sent from my Pixel using Tapatalk

[martinayotte]

26 minutes ago, TonyMac32 said:

The extra skip lines up the data being written without having to find away to package the other binary

To my knowledge, providing multiple "skip" arguments will only override each others and only the last one will be taken into account ...

[TonyMac32]

27 minutes ago, martinayotte said:

To my knowledge, providing multiple "skip" arguments will only override each others and only the last one will be taken into account ...

ugh, skip vs seek, it was almost 3:00 when I typed that out. 

 

so this is the u-boot generated u-boot.bin vs the file we copy into u-boot.bin (u-boot.bin.sd.bin): 

tony@builder:~/build/cache/sources/u-boot/v2019.04$ hexdump -n1024 u-boot.bin
0000000 e5be f4ff 89b0 9291 3a8b bef4 66af 0a2e
0000010 4140 4c4d bff0 0000 0040 0001 0000 0000
0000020 0000 0000 0040 0000 0200 0000 0060 0000
0000030 0000 0000 0240 0000 0db0 0000 bf90 0000
0000040 0000 0000 0ff0 0000 b000 0000 0000 0000
0000050 6710 54f3 c008 31b0 44b9 9e1d 333c 2706
0000060 0787 6ef1 95cf 805a a72b f510 b357 c6a4
0000070 0000 0000 0000 0000 0000 0000 0000 0000
*
0000400
tony@builder:~/build/cache/sources/u-boot/v2019.04$ hexdump -n1024 u-boot.bin.sd.bin
0000000 0226 31da 9bca 83e5 53cd 4877 5c11 0548
0000010 d10d 9f97 d15d 1b93 f980 8a49 aadb 014a
0000020 24ac 7632 17bf 8cfa 716a 7cd5 1dce db81
0000030 18ee 4b7a 0de9 6967 b006 e1f4 3e5a 07e2
0000040 1462 227d 772c 96ae 83e9 b712 94a0 8f92
0000050 0cac 96da 4119 1fff f3f2 4c00 e231 9453
0000060 d1f6 22b6 6448 31b9 cbe8 88e8 7a5f 0c17
0000070 f286 9fa2 a133 25be be95 c672 c5a0 975a
0000080 1096 dfb9 7275 5d10 f93e 9de5 fd73 faa9
0000090 4bef 2299 58ed 8248 ba16 b748 a37f 164e
00000a0 07b3 28f5 057a b885 6bfe 7255 ff68 576c
00000b0 054a 3779 c15d 74b9 027b fb2b 79a5 5811
00000c0 0680 fa81 060b 0ab2 0871 d97c e807 5130
00000d0 aaed 4b89 426b e7bf ea44 e9e2 f363 e342
00000e0 c3f9 04de 90c9 3b0e 8a98 9f14 4572 60f1
00000f0 7aef 5aab 6abc 0141 2354 b7ea 2c16 0f9a
0000100 78ef b914 2209 a1f4 08ad 1f41 324d 3c7f
0000110 2aac 6897 d894 e869 54fc 129f 3a80 7022
0000120 36b2 bb29 1d58 055d 9e25 7325 a4d0 7caf
0000130 46cf 63e4 4e1f 1b4c eba2 222d 4f25 d892
0000140 bb85 de93 f0d8 fee3 088e 5e71 20ad 7cda
0000150 bf67 86df 2b0d afa1 ce17 3cd1 641e a314
0000160 a81f f881 6598 27f6 676d 1a85 6087 ee96
0000170 761f 2c74 15a1 b8db ace4 02f5 0910 30a5
0000180 27b1 4a28 1e8c f971 f685 0c14 aa56 75fb
0000190 6f20 c2a1 7c85 697a 6f29 396b 1079 2a69
00001a0 9137 c374 e5af 34bd d1dc 3241 3c7b 9ca8
00001b0 49ab 305e d8c6 ef99 0448 c128 9215 4ceb
00001c0 6023 d310 cd45 2107 489e 1954 fc84 30b5
00001d0 1345 0b60 faec 34fa 23fe 13f5 e0b5 d860
00001e0 7040 86ab b33d dba7 fbfb 80f4 aaf7 3db0
00001f0 10bd a948 430a 09dd d266 1b1c 7cb3 f3f3
0000200 e5be f4ff 89b0 9291 3a8b bef4 66af 0a2e
0000210 4140 4c4d bff0 0000 0040 0001 0000 0000
0000220 0000 0000 0040 0000 0200 0000 0060 0000
0000230 0000 0000 0240 0000 0db0 0000 bf90 0000
0000240 0000 0000 0ff0 0000 b000 0000 0000 0000
0000250 6710 54f3 c008 31b0 44b9 9e1d 333c 2706
0000260 0787 6ef1 95cf 805a a72b f510 b357 c6a4
0000270 0000 0000 0000 0000 0000 0000 0000 0000
*
0000400

So if the result is only different as far as removing the first command with the 442, we need to know what was in the first sector of the eMMC to restore it somehow.

 

I guess it's time to dump the first couple sectors of an SD vs an eMMC image from FE

 

[TonyMac32]

ok, so the friendlyElec eMMC image has the data written write onto sector 0:

 

 

while SD image:

 

So try

 

dd if=$1/u-boot.bin of=$2 bs=512 skip=1 conv=fsync

 

$2 obviously being the eMMC, we're just not skipping 512 on the eMMC, so no seek=1, and only 1 dd command, forget about the one with teh 442 in it.

 

[martinayotte]

13 minutes ago, TonyMac32 said:

ok, so the friendlyElec eMMC image has the data written write onto sector 0:

This sector 0 dump is coming from which image ?

Maybe it should be written on the eMMC first ?

 

13 minutes ago, TonyMac32 said:

dd if=$1/u-boot.bin of=$2 bs=512 skip=1 conv=fsync

This didn't work either ...

 

Maybe also @balbes150 has some clues ?

 

[TonyMac32]

13 minutes ago, martinayotte said:

This sector 0 dump is coming from which image ?

Maybe it should be written on the eMMC first ?

 

http://wiki.friendlyarm.com/wiki/index.php/NanoPi_K2#Make_an_Installation_TF_Card.2FeMMC_Module

 

It's been too long since I messed with the boot sectors on Amlogic, I remember one of these (S905 or S905X) was way pickier than the other, I actually just booted the u-boot.bin on the SD when it shouldn't have worked at first...  I'm guessing that's the S905 given the snapshot above (empty first sector), but what makes the eMMC happy I'm uncertain.

 

[edit] @Neil Armstrong wasn't there some documentation on that linux-meson wiki?  I can't find a damned thing about the Amlogic boot process anymore.

[TonyMac32]

@martinayotte

 

https://github.com/u-boot/u-boot/blob/bdf97b5d393fc94666a847e9bac1c358b2c63c59/board/amlogic/p200/README.nanopi-k2#L99

 

for NanoPi K2

 

vs

 

https://github.com/u-boot/u-boot/blob/bdf97b5d393fc94666a847e9bac1c358b2c63c59/board/amlogic/p212/README.libretech-cc#L101

 

for S905X

 

 

The C2 is not a valid comparison because of special firmware.  See the process for it:

 

https://github.com/u-boot/u-boot/blob/bdf97b5d393fc94666a847e9bac1c358b2c63c59/board/amlogic/p200/README.odroid-c2#L63

 

These are all just SD though, so I'm not sure since I can't find whatever I used before as documentation

[wikrie]

Hi Everybody,

 

I try to follow your conversation but I cannot see where to help or to test anything, seams to be a bigger problem with the boot from EMMC.

So I'm not sure if it helps in any case but I extract the working boot parition from the existing NANOPIK2 image and if anybody like ot could be downloaded from:

https://my.pcloud.com/publink/show?code=XZKKTa7ZnglxwkfmdHHoR35AbYpwW0QYTQBk

And I also attached it to that post.

If I could test anything please let me know.

 

br wikrie

 

 

boot-emmc-k2.zip

[wikrie]

Hi Folks,

 

seams that there is no Solution for this issue, so the cost for the emmc was a little waste of money.

If anybody has any idea please let us know, we will test / try all.

 

bet regards

wikrie

[martinayotte]

57 minutes ago, wikrie said:

seams that there is no Solution for this issue, so the cost for the emmc was a little waste of money.

We didn't found a solution to boot from eMMC without SD, but you can still use eMMC as ROOTFS if you leave the SD inserted for the U-Boot itself.

We didn't throw the towel yet, maybe a solution will be found in the future.

[wikrie]

Hi Folks,

 

 

I try to run the following issue , boot from SD and use EMMC for rootfs.

But I cannot get it to boot, is there any tutorial how to handle it?

 

br

wikrie

 

[martinayotte]

10 minutes ago, wikrie said:

But I cannot get it to boot, is there any tutorial how to handle it?

There is not such tutorial, but only knowledge from people familiar ...

 

If you've already ran nand-sata-install, do a "blkid" to figure out the UUID of the eMMC.

Then you can edit the /boot/armbianEnv.txt of the SDCard and change the "rootfs=UUID=<some_partition_uuid>" with the good eMMC partition UUID, so that the change will be permanent and reboot.

[wikrie]

Thanks @ martinayotte

 

I will try it and give you a feedback !!

 

And it works !!!! Booting from SD and working from EMMC, that is half the way I want!

But at the end much more than nothing!!!!

1mil Thnaks @martinayotte

 

wikrie@nanopik2:~$ mount | grep mmc
/dev/mmcblk0p1 on / type ext4 (rw,noatime,nodiratime,errors=remount-ro,commit=600)
/dev/mmcblk1p1 on /media/mmcboot type ext4 (rw,noatime,nodiratime,errors=remount-ro,commit=600,x-gvfs-hide)
/dev/mmcblk1p1 on /boot type ext4 (rw,noatime,nodiratime,errors=remount-ro,commit=600)

wikrie@nanopik2:~$ sudo blkid
/dev/mmcblk0p1: UUID="8c928f56-9de2-4e7b-91ab-2144bb0e42d3" TYPE="ext4" PARTUUID="567b6072-01"
/dev/mmcblk1p1: UUID="bbeb1faa-8bba-463c-a3e2-3722d68654af" TYPE="ext4" PARTUUID="567b6072-01"

 

br wikrie

[TonyMac32]

I am still confused by this, for GXL nand-sata-install works just fine (just ran it on Le Potato)

[martinayotte]

9 hours ago, TonyMac32 said:

I am still confused by this, for GXL nand-sata-install works just fine (just ran it on Le Potato)

What do you mean @TonyMac32 ? Do you mean your LePatato is able to start U-Boot directly from eMMC (without any SD) ?

For me, it still doesn't on NanoPi-K2, but I didn't invest much time recently to figure that out, I was in vacation ...

[TonyMac32]

Yes, both Le Potato and the new CSC for Khadas' VIM (both Meson-GXL) can boot directly from eMMC without any special effort out of the box. I don't have an eMMC for K2 or C2, but will review the u-boot image building process and see if anything is amiss and the boards are simply "dealing" with the issue on SD.

Sent from my Pixel using Tapatalk

[wikrie]

now I'm confused, the last statement I got was, EMMC BOOT on a NANOPI-K2 is impossible.

Is this information outdated?

is there a  chance to boot from EMMC directly?

br wikrie

[martinayotte]

16 minutes ago, wikrie said:

is there a  chance to boot from EMMC directly?

We didn't found the proper "howto" yet ...

 

[wikrie]

so we are at the same point as before, boot from SD and rootfs from EMMC is working, boot and work from EMMC isn't.

Did I understand this correctly?

 

 

[martinayotte]

1 hour ago, wikrie said:

Did I understand this correctly?

Right ! SDCard is needed only to hold U-Boot itself, eMMC rootfs contains everything else ...

[chewitt]

I found this thread while working on mainline u-boot support for the WeTek Hub/Play2 boxes that LE has historically supported "internal" (emmc) installs on. These will not be compatible with mainline Linux as it doesn't support Amlogic's partition scheme. So I started investigating a bump to mainline u-boot.

 

Using u-boot.bin.sd.bin worked fine booting from sdcard, but dd'ing it to /dev/mmcblk1 resulted in "GXBB:BL1:08dafd:0a8993;FEAT:EDFD718C;POC:3; .. " so BL1 cannot find u-boot. I've done a little poking around, so here's /dev/mmcblk1 with the default LE image that uses u-boot.bin.sd.bin:

LibreELEC:~ # hexdump -C -n1024 /dev/mmcblk1
00000000  e8 cb ef 87 91 8e 91 8a  4d 7a f0 5d ba d4 90 92  |........Mz.]....|
00000010  2a 94 c4 e3 b4 fb b5 e7  7b 95 62 2f e9 d9 61 d1  |*.......{.b/..a.|
00000020  a4 51 58 35 df ea bf 2c  64 af 8a 1e 83 1a b0 ae  |.QX5...,d.......|
00000030  ae 74 91 62 70 46 49 eb  db ac 1a c4 85 7c 95 29  |.t.bpFI......|.)|
00000040  cd ed 5f ac d7 1e d9 3b  ce 63 5a 51 7d 0a ff 2b  |.._....;.cZQ}..+|
00000050  7f 90 8d ef d6 d7 da b1  83 f5 75 08 71 0a 31 3e  |..........u.q.1>|
00000060  f8 90 ea cf af c3 0b 7d  26 65 ce a3 6f ce ce ee  |.......}&e..o...|
00000070  5e 5c dd 35 33 b8 e6 b6  ad 5c be 1e 66 ef 5c 5e  |^\.53....\..f.\^|
00000080  80 46 2e 2f 0a 39 ac 30  9e 7a d4 0d 48 a2 fc a7  |.F./.9.0.z..H...|
00000090  fe d9 dc 31 91 c2 e7 3e  1e a5 5c 85 95 b8 e3 15  |...1...>..\.....|
000000a0  ff 11 44 09 4a f0 39 e8  6a 0d f6 b3 b0 f2 5a ae  |..D.J.9.j.....Z.|
000000b0  cb 36 e0 5d f8 c7 9b 17  6d f8 9c 02 b0 7f 17 af  |.6.]....m.......|
000000c0  91 5b b8 db 4b f2 c4 b5  ff ba 68 af ac c2 5e 77  |.[..K.....h...^w|
000000d0  f8 3e d4 f1 05 70 08 72  68 a4 74 18 23 8b c8 b4  |.>...p.rh.t.#...|
000000e0  e6 80 90 31 72 54 e7 72  0e 4f 21 ba 12 7f 31 0a  |...1rT.r.O!...1.|
000000f0  bd 06 fb c3 76 03 35 de  a7 aa f6 cb 35 be 7f 1c  |....v.5.....5...|
00000100  3f 0f 4d b1 63 34 23 71  84 45 2b 96 c4 5d a0 82  |?.M.c4#q.E+..]..|
00000110  63 9c 45 d9 9f 7a b7 47  24 ad 12 5a 6c 91 76 ab  |c.E..z.G$..Zl.v.|
00000120  a1 c3 5c 04 f8 80 76 7c  c5 a1 12 89 fe b2 0b 61  |..\...v|.......a|
00000130  4e 50 3a ee cb f1 35 ef  9f 47 49 0b d8 bf b6 79  |NP:...5..GI....y|
00000140  83 12 7e 7b 92 f4 f7 57  95 09 e1 94 bb ec f5 0a  |..~{...W........|
00000150  3d 30 f8 08 21 2d f7 c0  74 41 cb 4c 00 81 c6 83  |=0..!-..tA.L....|
00000160  94 44 fe 26 38 f5 7e cd  fe 5f 61 ba 4b 57 c4 88  |.D.&8.~.._a.KW..|
00000170  87 bc 90 a8 e9 88 69 5d  c9 34 a9 c9 b6 6f 4d 4a  |......i].4...oMJ|
00000180  b3 4b 70 eb 41 ee b9 3f  4d 1a f9 99 71 bd 21 f8  |.Kp.A..?M...q.!.|
00000190  79 b2 a1 62 3a 0a bf 03  3e 69 cc f4 d8 19 3e 8c  |y..b:...>i....>.|
000001a0  65 af 77 a6 9d 30 e5 eb  4b df 84 bc 9c a5 b5 16  |e.w..0..K.......|
000001b0  57 56 78 91 60 38 94 9e  a1 61 93 79 00 00 80 00  |WVx.`8...a.y....|
000001c0  01 40 0c 03 e0 ff 00 20  00 00 00 00 10 00 00 03  |.@..... ........|
000001d0  e0 ff 83 81 cb b6 00 20  10 00 00 e0 d8 00 00 00  |....... ........|
000001e0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000001f0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 55 aa  |..............U.|
00000200  10 40 e4 32 d7 56 04 32  b8 20 37 d2 32 80 e0 7b  |.@.2.V.2. 7.2..{|
00000210  40 41 4d 4c f0 bf 00 00  40 00 01 00 00 00 00 00  |@AML....@.......|
00000220  00 00 00 00 40 00 00 00  00 02 00 00 60 00 00 00  |....@.......`...|
00000230  00 00 00 00 40 02 00 00  b0 0d 00 00 90 bf 00 00  |....@...........|
00000240  00 00 00 00 f0 0f 00 00  00 b0 00 00 00 00 00 00  |................|
00000250  a1 f2 25 3d 4c b2 10 fe  58 42 14 97 cd 58 c7 73  |..%=L...XB...X.s|
00000260  94 4c 19 85 00 c5 40 af  21 66 83 8b be c1 d1 05  |.L....@.!f......|
00000270  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000400

and here's what the mainline u-boot.bin looks like .. the @AML offset is clearly different:

LibreELEC:~ # hexdump -C -n1024 u-boot.bin 
00000000  3f 9b 44 08 b9 fb df f2  87 55 b4 99 53 f7 25 05  |?.D......U..S.%.|
00000010  40 41 4d 4c f0 bf 00 00  40 00 01 00 00 00 00 00  |@AML....@.......|
00000020  00 00 00 00 40 00 00 00  00 02 00 00 60 00 00 00  |....@.......`...|
00000030  00 00 00 00 40 02 00 00  b0 0d 00 00 90 bf 00 00  |....@...........|
00000040  00 00 00 00 f0 0f 00 00  00 b0 00 00 00 00 00 00  |................|
00000050  a1 f2 25 3d 4c b2 10 fe  58 42 14 97 cd 58 c7 73  |..%=L...XB...X.s|
00000060  94 4c 19 85 00 c5 40 af  21 66 83 8b be c1 d1 05  |.L....@.!f......|
00000070  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000400

and here's the bootloader.img file wetek shipped in a firmware update (2015 vendor bsp u-boot):

LibreELEC:~ # hexdump -C -n1024 bootloader.img 
00000000  c4 56 10 90 0e 2b ad ce  29 d9 e9 30 61 96 ab 57  |.V...+..)..0a..W|
00000010  40 41 4d 4c f0 bf 00 00  40 00 01 00 00 00 00 00  |@AML....@.......|
00000020  00 00 00 00 40 00 00 00  00 02 00 00 60 00 00 00  |....@.......`...|
00000030  00 00 00 00 40 02 00 00  b0 0d 00 00 90 bf 00 00  |....@...........|
00000040  00 00 00 00 f0 0f 00 00  00 b0 00 00 00 00 00 00  |................|
00000050  9c 44 c5 b2 46 69 b1 f7  ed fd f3 3b 7b b3 e6 91  |.D..Fi.....;{...|
00000060  be 67 8b db 78 b4 36 33  bf 11 2f 7b 01 2d 3e 39  |.g..x.63../{.->9|
00000070  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000400

If I zero the emmc and run "dd if=u-boot.bin of=/dev/mmcblk1" and shutdown/boot the box, I see nice things:

GXBB:BL1:08dafd:0a8993;FEAT:EDFD718C;POC:3;RCY:0;EMMC:0;READ:0;CHK:0;
no sdio debug board detected 
TE: 109572

BL2 Built : 09:01:42, Oct 11 2016. 
gxb g88b04d6 - haixiang.bao@droid05

set vcck to 1100 mv
set vddee to 1000 mv
Board ID = 4
CPU clk: 1536MHz
DDR chl: Rank0+1 diff @ 912MHz
DDR0: 1024MB(auto)-2T-13
DDR1: 1024MB(auto)-2T-13
DataBus test pass!
AddrBus test pass!
-s
Load fip header from eMMC, src: 0x0000c000, des: 0x01400000, size: 0x00004000
New fip structure!
Load bl30 from eMMC, src: 0x00010000, des: 0x01000000, size: 0x0000d460
Sending bl30......................................................OK. 
Run bl30...
Load bl31 from eMMC, src: 0x00020000, des: 0x1010[0000, size: 0x00018190
Image: gxb_v1.1.3135-18177fc 2016-06-24 11:00:09 yun.cai@droid06]

OPS=0x13

cb 1 53 1 a5 56 7d bf a3 1d f5 91 [0.197378 Inits done]

secure task start!
high task start!
low task start!
Load bl32 from eMMC, src: 0x0003c000, des: 0x05300000, size: 0x00035760
Load bl33 from eMMC, src: 0x00074000, des: 0x01000000, size: 0x00093850
NOTICE:  BL3-1: v1.0(debug):bc3419d
NOTICE:  BL3-1: Built : 14:16:22, Aug 15 2016
INFO:    BL3-1: Initializing runtime services
INFO:    BL3-1: Initializing BL3-2
INFO:    BL3-2: ATOS-V1.5-g3e467d9 #1 Mon Aug 22 17:11:43 CST 2016 arm
INFO:    BL3-2: chip version = RevC (1F:C - 0:0)
INFO:    BL3-2: crypto engine BLKMV
INFO:    BL3-2: secure time REE
INFO:    BL3-1: Preparing for EL3 exit to normal world
INFO:    BL3-1: Next image address = 0x1000000
INFO:    BL3-1: Next image spsr = 0x3c9


U-Boot 2020.01-rc5 (Dec 29 2019 - 14:21:09 +0000) wetek-play2

Model: WeTek Play 2
SoC:   Amlogic Meson GXBB (S905) Revision 1f:c (13:1)
DRAM:  2 GiB
MMC:   mmc@70000: 0, mmc@72000: 1, mmc@74000: 2
In:    serial
Out:   serial
Err:   serial
[BL31]: tee size: 0
[BL31]: tee size: 0
Net:   
Warning: ethernet@c9410000 (eth0) using random MAC address - ae:4d:80:01:69:e9
eth0: ethernet@c9410000
Hit any key to stop autoboot:  0 
Card did not respond to voltage select!
switch to partitions #0, OK
mmc2(part 0) is current device
** No partition table - mmc 2 **
starting USB...
No working controllers found
USB is stopped. Please issue 'usb start' first.
starting USB...
No working controllers found
ethernet@c9410000 Waiting for PHY auto negotiation to complete....

and if I do "dd if=u-boot.bin.sd.bin of=/dev/mmcblk1 bs=512 skip=1" and shutdown/boot the box, I see the same UART output.

 

now I need to figure out how to combine the extracted u-boot with a partitioned filesystem. So far each time I partition and format I break u-boot .. but I'll get there eventually

 

 

 

[hexdump]

@chewitt - i think to remember, that the s905 has a very dos partition table unfriendly boot layout ... two options come into my mind: you might use gpt partitioning and ignore the primary partition table (gpt has a backup at the end of the disk) - this way it works well to run linux on my veyron chromebook, which is trashing the primary partition table over and over again - you'll need the gpt kernel cmdline option for the kernel to be happy with the backup partition table only ... the other option would be to supply the partitioning information via kernel cmdline - see https://www.kernel.org/doc/Documentation/block/cmdline-partition.txt ...

 

here are some of my notes from back when i was trying to get this solved on the rockchip rk3288 chromebook:

 

--- snip ---

the primary gpt table seems to be corrupted by design on rockchip chromebooks, thus we have to write to the backup gpt table

reading:
dd if=/dev/mmcblk0 of=secondary-gpt.dd bs=512 skip=30777310 count=34
skip: disk number of sectors - 34

writing:
dd of=/dev/mmcblk0 if=secondary-gpt.dd bs=512 seek=30777310 count=34
seek: disk number of sectors - 34

the number 34 is according to the picture in https://en.wikipedia.org/wiki/GUID_Partition_Table

--- snip ---

 

the advantage of the chromebook was that it had a fixed size for the emmc, which may or may not be true in your case. but you might try to just create a gpt partition table, install u-boot (overwriting the primary one most probably) and then boot linux with the gpt option ... but i think before you'll run into another problem: most probably u-boot will not be able to read anything from the emmc with a corrupted primary gpt partition table (if it can speak gpt at all) ...

 

either way, good luck and best wishes - hexdump

 

p.s.: something else i vaguely remember is that there was one soc which had different locations at which it was looking for the boot code between sd and emmc, but i think it was not s905 - more something like odroid u3 or xu4 (but maybe it was s905 anyway?)... not sure, just wanted to throw that memory in here as well ...

[hexdump]

@chewitt - maybe it was even s905 - see section 4 - "boot media layout" here: https://github.com/hardkernel/u-boot/blob/odroidc2-v2015.01/doc/README.odroid

[chewitt]

I'll do some experiments - thanks for the notes and suggestions. Worst case I'll force users to boot from SD (which works fine) and we can format the emmc for use as /storage in LE which is where Kodi keeps all the persistent data that needs I/O performance. The base image on a WeTek Play2 box is booting from SD (including WLAN connection) in ~10 seconds (see http://ix.io/25Ts) so we're not exactly un-performant.

[chewitt]

This was an interesting find .. flagged by one of our contributors once I started moaning about Amlogic's needs

 

https://github.com/Kwiboo/u-boot/commit/6d0a17632922077a2e64b13ae1a6bdf0024b718f

[TonyMac32]

This whole thing is still making my head hurt, I can't see any reason uboot.bin flashed at the right location wouldn't be working.

On 12/29/2019 at 10:48 AM, chewitt said:

Using u-boot.bin.sd.bin worked fine booting from sdcard, but dd'ing it to /dev/mmcblk1 resulted in "GXBB:BL1:08dafd:0a8993;FEAT:EDFD718C;POC:3; .. "

right, the *.sd.bin is different than the *.bin.

 

On 12/29/2019 at 10:48 AM, chewitt said:

now I need to figure out how to combine the extracted u-boot with a partitioned filesystem.

 

Describe the partition scheme you want to use? 

 

On 12/29/2019 at 1:08 PM, hexdump said:

maybe it was even s905

 

It is.

 

I found a module for my K1 Plus, perhaps it will work to experiment with the K2, since this seems to be festering.

 

 

 

[chewitt]

This is also worth a read:

https://archive.fosdem.org/2019/schedule/event/one_image_to_rule_them_all/attachments/slides/3342/export/events/attachments/one_image_to_rule_them_all/slides/3342/simage.pdf

 

I've concluded that on GXBB (and likely Meson6/8) devices the BL1 embedded in the SoC looks for BL2 in the first sector of emmc, and this prevents normal emmc partitioning as the MBR/GPT structures also use the first sector and will overwrite BL2 and break the boot process. The GXBB BL1 looks for the BL2 signature at a different offset on SD cards, which allows space for the patition tables, and it looks like GXL and newer SoC's check the "SD card" offset on both emmc and SD, which is why mainline u-boot recipes for newer devices can use u-boot.bin.sd.bin for both emmc and sd media.

 

Poking around in the bsp u-boot code shows drivers/mmc/aml_emmc_partition.c which appears to show creation of a reserved area at the front of disk for u-boot.bin with BL2 in the first sector, and then MBR/GPT structures at an offset value. The partition layout is then described in device-tree, allowing u-boot to see /dev/mmcblkX and mount a filesystem to boot. The non-standard Amlogic partition arrangement means normal partitioning tools won't work, as they attempt to read the tables in the first sector and don't find anything there.

 

I have an Odroid C2 where the emmc module is removable. I'm guessing this is presented in hardware like an SD card (or Bl1 is different, but I think that's unlikely) allowing C2 to boot from the SD offset. I don't own a NanoPi K2, so not sure how that presents.

 

TL/DR; the best compromise for LE users is to image an SD card containing mainline u-boot.bin.sd.bin and then partition/format internal emmc as persistent /storage. It's then just a trivial sed of the extlinux.conf to switch disk=LABEL=STORAGE (sd) to disk=LABEL=EMMC_STORAGE (emmc) and reboot to benefit from faster /storage I/O for Kodi access to thumbnails.

[chewitt]

hmm... if I flash the C2 image to my WeTek Play2 and boot .. I get this:

GXBB:BL1:08dafd:0a8993;FEAT:EDFD718C;POC:3;RCY:0;EMMC:0;READ:0;CHK:0;
TE: 116845
***** Warning!! *****************************************************
* This board have not been autorized or product keys are not valid. *
* Please contact with Hardkernel or your distributor                *
*********************************************************************

So the board checks for BL1 in the first sector too, but the HK binary used for C2 clearly checks against something board specific so it cannot be used elsewhere.

 

In other words, there's a software solution to this stupidity but (as is often the case) it's all closed-source proprietary crap.

 

Time to go short some pins and clear the emmc again

[TonyMac32]

@chewitt the C2 has a special blob because of some legal issues with their advertisement of clock speeds, it tests for a hardware tell to make sure it's on the right board, everyone else is required to use the other closed source blob. It's as close to RPi as you can get without actually descending into the abyss that is Broadcom. ;-)

Sent from my Pixel using Tapatalk