+- PINE64 (https://forum.pine64.org)
+-- Forum: Pinebook Pro (https://forum.pine64.org/forumdisplay.php?fid=111)
+--- Forum: General Discussion on Pinebook Pro (https://forum.pine64.org/forumdisplay.php?fid=112)
+--- Thread: U-Boot / mmcblkXboot0 (/showthread.php?tid=9491)
U-Boot / mmcblkXboot0 - stefan.schumacher - 03-22-2020
Hello,
I want to update my installation of u-boot. (I already asked some questions in the Manjaro Forum because its their u-boot update which asks to be dd'ed to a target, but I am left with some open questions.) Where exactly does u-boot reside when using a standard Linux like in this case Manjaro, installed to the eMMC? When I want to update u-boot, do I simply need to write it to the eMMC device or do mmcblkXboot0 and mmcblkXboot1 play any role in the booting process of Linux on the Pinebook? The information in https://wiki.pine64.org/index.php/Pinebook_Pro does not answer my questions and the documentation of u-boot is somewhat inaccessible even for someone who works with Linux for a living.
Yours
Stefan
RE: U-Boot / mmcblkXboot0 - Arwen - 03-22-2020
At present, both "mmcblkXboot0" & "mmcblkXboot1" serve no purpose. Our U-Boot is located directly on the normal eMMC storage. Basically U-Boot starts at sector 64, for 3 sections, (8MB, 4MB & 4MB), and then normal partitions can start after that.
Below is an example where I've created reserved partitions entries for U-Boot. Followed by "/boot", swap and "/". (Note that U-Boot expects "/boot" to be the first partition, so I have it installled that way.)
Code:
Device Start End Sectors Size Type
/dev/mmcblk1p1 32768 557055 524288 256M Microsoft basic data
/dev/mmcblk1p2 64 16383 16320 8M Linux reserved
/dev/mmcblk1p3 16384 24575 8192 4M Linux reserved
/dev/mmcblk1p4 24576 32767 8192 4M Linux reserved
/dev/mmcblk1p5 557056 8945663 8388608 4G Linux swap
/dev/mmcblk1p6 8945664 65544144 56598481 27G Linux root (ARM-64)This means that the exact same U-Boot code and layout works for SD cards as it does for eMMCs. And also SPI flash as well.
RE: U-Boot / mmcblkXboot0 - wdt - 03-22-2020
I'm not sure why you are going on about this
Partitions don't matter, as long as the 1st (user) doesn't overlap ATF
The command line given by manjaro is correct, you do have to
replace the "X" with the right number
As long as idbloader, uboot, ATF are in the right place,
that is all that matters, partitions don't matter AT ALL
AND, you don't really have to do this, maybe the update
gives something "extra", this has not been stated
Now, if you are trying to write a BSP uboot for the
other sleep method, well that might be worthwhile,
I, as of yet, have heard no reports, pro or con
RE: U-Boot / mmcblkXboot0 - z4v4l - 03-23-2020
arwen is right, what linux calls mmcblkXbootY now is not and looks like cannot be used*. flash the uboot pieces in the general area (mmcblkX) where they are expected to reside.
* - these special purpose storage subdevices of an emmc module are for the platform firmware, but for being used and usable, the initial start up code of the SoC (ROM code), needs to try them in its boot sequence. does it? looks like not, or rockchip forgot to tell about it. you might try by yourself, would make a favor,
it's really interesting, but I don't have the emmc. zero the first megabyte of the GP area and write uboot (all its pieces) into mmcblkXboot0, attach terminal to your board, make sure you don't have anything written in SPI and SD, and look what you see in the output. most probably nothing more than scarce ROM code babbling, but if uboot starts, it will be well seen, then wahoo, we all may use boot areas for the firmware! so cool.
RE: U-Boot / mmcblkXboot0 - Arwen - 03-24-2020
(03-22-2020, 05:02 PM)wdt Wrote: I'm not sure why you are going on about this
Partitions don't matter, as long as the 1st (user) doesn't overlap ATF
The command line given by manjaro is correct, you do have to
replace the "X" with the right number
As long as idbloader, uboot, ATF are in the right place,
that is all that matters, partitions don't matter AT ALL
AND, you don't really have to do this, maybe the update
gives something "extra", this has not been stated
Now, if you are trying to write a BSP uboot for the
other sleep method, well that might be worthwhile,
I, as of yet, have heard no reports, pro or con
If the comment about partitions was directed at me, the answer is simple. With partitions in place, I know where things are and where the 1st user partition must start. It's nothing more than built in documentation. (Though it does ease copying or updates because I don't have to remember sector offsets.)
RE: U-Boot / mmcblkXboot0 - wdt - 03-24-2020
@Arwen
>If the comment about partitions was directed at me
No, the other guy, who didn't seem to be listening ----to anyone
To have a placeholder is conveint I guess, , but
64 sectors, 8M, 12M, 16M(user) doesn't seem that hard to remember either
You do have to multiply by 2048