PINE64
U-boot Updates - Printable Version

+- 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 Updates (/showthread.php?tid=17595)



U-boot Updates - jaredoconnor - 11-12-2022

I would like to run the latest U-boot. However, I have some questions.


  1. Does the PBP require a modified U-boot, or is it safe to run the latest code from the official repo?
  2. All the tutorials that I have found either fail to mention where to get the files or they assume you're running Manjaro. Is there anywhere that I can get the files, without building them myself?
  3. I'm hoping to run U-boot on an SD card and the OS on the eMMC. That way, if I mess up my U-boot, it will be easier to recover than taking apart the laptop. Is this as simple as completely erasing the eMMC and installing U-boot on an SD card? Is there anything that I need to be aware of?



RE: U-boot Updates - wdt - 11-13-2022

>I would like to run the latest U-boot........why?
All uboot does is set up mem to safe state, set up serial com, scan media, load cfg file, load kernel
Some, maybe 3 uboots drive display
If you install to SPI (which I do not recommend) be aware it is different than SD/emmc uboot
there are probably more than 10 uboots out there, all doing more or less the same thing
The main differences are BSP,, mainline,, drives display
BSP are 3 files, mainline 2 files,,u-boot.itb = uboot.img + trust.img
Getting, well google and other searches, make SURE that it is specifically for pbp or maybe any rk3399
My emmc has only mbr in 1st 16M, uboot with distro on SD OR uboot alone on SD
save mbr, save 1st 16M, blank 1st 16M, restore mbr (all on emmc),,,,, all with dd & count
With uboot alone, make a FS on the rest of SD or uboot will lock, maybe the error recovery is better in later versions


RE: U-boot Updates - KC9UDX - 11-15-2022

You pretty much need to have U-boot on the eMMC. The hardware looks there before scanning the micro-SD. If you don't have a valid U-boot on the eMMC, you can't boot from SD. Now, valid includes being all zeroes. But in my opinion, it's just as easy to corrupt all zeroes as it is to corrupt good code. Especially if you or something forgets to leave that space alone.

SPI-ROM is scanned before the eMMC. So if you want to foolproof your PBP so that you don't have to open it, you really want U-boot, or more likely, Tow-boot on the SPI ROM. Do this at your own risk. I don't recommend doing it either. If you make a mistake there, it's much harder to recover than if U-boot gets corrupted on your eMMC.


RE: U-boot Updates - wdt - 11-15-2022

>You pretty much need to have U-boot on the eMMC
This is not true, sure, my emmc 1st 16M had /dev/zero written and then restored mbr written to it
But really, what the boot rom is looking for is idbloader, the signature, it is a raw read
@ 0 on SPI,,,, @(64*512) on emmc, then SD
If you check every idbloader you have, the first 5 bytes are always the same, this is the signature
3b 8c dc fc be ,,,,,(idbloader activates memory on mb)
Then, when it has enough memory, uboot is loaded from the same media


RE: U-boot Updates - KC9UDX - 11-17-2022

But my point is that you need to have a valid boot or valid not-boot on the eMMC. In other words, you might as well have U-boot there. The danger is that if U-boot on the eMMC gets corrupted, you can't boot from SD. So alternatively, you can make the eMMC not-boot, and put U-boot on micro-sd. In that case, if the not-boot state of the eMMC gets corrupted, the same way a valid boot state could get corrupted, you still cannot boot from SD. So why not have it in the eMMC where it'll boot sooner and faster?


RE: U-boot Updates - wdt - 11-17-2022

> But my point is that you need to have a valid boot or valid not-boot on the eMMC.
No, the bootrom is looking for idbloader, the media and fstable is irrelevant,
and any partitions or filesystems on them,,,,,only the existence or absence of a media,,
because the bootrom is ONLY looking at specific locations for the idbloader signature
Uboot only enters the picture AFTER idbloader has activated the mb memory
(because the bootrom has very little memory)
The point is,,, all uboots are not equal, sometimes a uboot on emmc
is not compatible with a distro on SD (like the recent manjaro's)
If there is a uboot on emmc it will be ALWAYS used, since it is found first,
so if you write an image to emmc, you have a NEW uboot, and now that one will be always used
This might not work out, at the least you have not tested it (the uboot on SD)