u-boot (forks) status - Printable Version

u-boot (forks) status - Printable Version

+- PINE64 (https://forum.pine64.org)
+-- Forum: ROCK64 (https://forum.pine64.org/forumdisplay.php?fid=85)
+--- Forum: General Discussion on ROCK64 (https://forum.pine64.org/forumdisplay.php?fid=86)
+--- Thread: u-boot (forks) status (/showthread.php?tid=6299)

Pages: 1 2

u-boot (forks) status - mcerveny - 07-21-2018

Hello.

I need to enable some addons in u-boot. Yesterday I resolved many problems/bugs/workarounds in simple enabling "usbkbd" in u-boot (with ayufan-rock64/linux-u-boot (rockchip-master)).

Actual (few) versions u-boot:
upstream
   - with independent rockchip development ?
   - missing support for Rock64
-> fork rockchip-linux/u-boot
         - "release" branch - pulling randomly from upstream (actively developed) ?
         - missing support for Rock64
    -> fork ayufan-rock64/linux-u-boot
         - "rockchip-master" branch - last rebased/merged 12/2017 (actively developed)
         - "rebased-all-changes-on-release" branch - last rebased 04/2018 + summary commit 06/2018
         - "mainline-master" branch - last rebased 06/2018 from upstream (not from rockchip-linux)

What is the best u-boot fork/branch for Rock64 ?
How many features/bugfixes are missing from u-boot upstream in rockchip-linux/u-boot fork and vice-versa ?
Is there any chance to that Rockchip joins u-boot upstream ?

For example differences in ehci-generic.c (used in Rock64):
upstream (+2/-1 patches) X rockchip-linux/u-boot (release) (+1/-2 patches) X ayufan-rock64/linux-u-boot (rockchip-master) (-3 patches)

RE: u-boot (forks) status - asavah - 07-28-2018

(07-21-2018, 06:51 PM)mcerveny Wrote: - missing support for Rock64

Wrong there is support for rock64, you can build u-boot using evb-rk3328_defconfig both mainline and rockchip-uboot

(07-21-2018, 06:51 PM)mcerveny Wrote: What is the best u-boot fork/branch for Rock64 ?

I've been playing with all the forks you mention,
so far my conclusion is: ayufan-uboot FTW.

(07-21-2018, 06:51 PM)mcerveny Wrote: How many features/bugfixes are missing from u-boot upstream in rockchip-linux/u-boot fork and vice-versa ?

Ayufan's u-boot has gmac and efuse support,
thus it is able to get mac address (actually it reads the serial and transforms it into a mac) from efuse and pass it to the kernel,
the others can not, thus on each reboot you'll get a random mac which sucks if you assign "static" ip to the board via your dhcp server.

Ayufan's u-boot has spl support for rk3328 - easier building, no need for crap rockchip binaries in order to prepare final u-boot img.
I haven't checked other fetures as I don't need them, I was having problems with emmc calibration on soft reboot
and I thought u-boot was to blame, so I decided to find out which fork is more stable, however the problem was in kernel's dtb,
I screwed it up while porting a patch from somewhere.

(07-21-2018, 06:51 PM)mcerveny Wrote: Is there any chance to that Rockchip joins u-boot upstream ?

This question is better asked at rockchip's github repo, however their devs are not responsive at all and their support sucks.

RE: u-boot (forks) status - mcerveny - 07-28-2018

(07-28-2018, 12:28 PM)asavah Wrote:
(07-21-2018, 06:51 PM)mcerveny Wrote: - missing support for Rock64
Wrong there is support for rock64, you can build u-boot using evb-rk3328_defconfig both mainline and rockchip-uboot

No, generic "evb" is unusable on u-boot level for rock64 - no boot from SPI, no env save to SPI, no MAC-addresses (so no correct network boot), no Serial#, no LED (white+red).

(07-28-2018, 12:28 PM)asavah Wrote:
(07-21-2018, 06:51 PM)mcerveny Wrote: Is there any chance to that Rockchip joins u-boot upstream ?
This question is better asked at rockchip's github repo, however their devs are not responsive at all and their support sucks.

Yes, the same negative experience with rockchip Angry

RE: u-boot (forks) status - asavah - 07-28-2018

(07-28-2018, 02:05 PM)mcerveny Wrote: No, generic "evb" is unusable on u-boot level for rock64 - no boot from SPI, no env save to SPI, no MAC-addresses (so no correct network boot), no Serial#, no LED (white+red).

Well, that depends on the use case, Tongue

, I don't need network boot or SPI flash, I only need the damn thing to boot properly from emmc/sd.
it's actually not *-defconfig or dtb/dtsi issue, but the lack of actual code - rockchip-uboot has the efuse and gmac code, but it lacks https://github.com/ayufan-rock64/linux-u-boot/blob/rockchip-master/arch/arm/mach-rockchip/rk3328/rk3328.c#L159 ,
and some other goodies. For me both mainline and rockchip booted fine, except for the mac address,
honestly I was surprised when the board booted with mainline 2018.07

Currently I'm going to stick with ayufan's repo but keep an eye on the other two.

RE: u-boot (forks) status - ayufan - 07-30-2018

I plan to switch with as much as possible to mainline uboot. My u-boot currently gets quickly outdated even against rockchip's u-boot Smile

RE: u-boot (forks) status - simonsouth - 10-14-2019

I've been doing a bit of work with mainline U-Boot recently and am happy to report that with a few patches applied, the latest revision works with the ROCK64 and allows the use of U-Boot's own tertiary program loader (TPL) in place of Rockchip's proprietary miniloader, removing another piece of non-free software from the stack.

I wasn't aware that ayufan's branch offered additional functionality (eFuse support, etc.) but will be doubling back at some point to see about getting these ported to the mainline version. Right now I'm working on identifying what's unique about ayufan's ARM Trusted Firmware branch and getting those changes pulled into separate patches so it can be brought up-to-date as well.

I'll write up a lengthier tutorial when I'm done but to start using the mainline version of U-Boot, assuming you have the prerequisites taken care of (the cross-compilation toolchain installed if needed, the ARM Trusted Firmware BL31 built and the CROSS_COMPILE and BL31 environment variables set appropriately), you'll need to

Obtain a current version of the U-Boot source tree, either by downloading version 2019.10 from the U-Boot ftp site or by checking out the latest version from git with

git clone git://git.denx.de/u-boot.git
Apply these required patches, to fix issues with the RK3328 SDRAM driver that led to instability on the ROCK64:

ram: rk3328: Use correct frequency units in function
ram: rk3328: Fix loading of skew values
Optionally, apply these recommended patches, especially the first if you intend to boot from a microSD card while having an eMMC module installed:

rockchip: dts: rk3328: rock64: Add same-as-spl order
clk: rockchip: rk3328: Configure CPU clock
Build U-Boot as usual, with commands like the following:

rm -f ./idbloader.img; make distclean
make rock64-rk3328_defconfig all u-boot.itb
Install U-Boot to a microSD card with commands like

sudo dd if=./idbloader.img of=/dev/mmcblk0 seek=64
sudo dd if=./u-boot.itb of=/dev/mmcblk0 seek=16384

You'll find a bit more detail in doc/README.rockchip and in U-Boot's main README file in the root folder.

More to follow. (If anyone else is working on bringing the ROCK64's software up-to-date relative to the mainline versions, I'd be happy to hear from you so we can coordinate our efforts.)

RE: u-boot (forks) status - ayufan - 10-14-2019

I'm now working on switching to mainline u-boot for all my distros and to provide exact same functionality. Seems fairly doable Smile

RE: u-boot (forks) status - kuleszdl - 03-21-2020

I am happy to confirm that the build as suggested by @simonsouth works and gets me to the uboot console. I tried with both u-boot 2019.10 and the suggested patches as well as with current master (2020.04-rc3 + later commits) without patches.

Unfortunately, it does not work when flashed to SPI instead of when booting from sdcard. In this case it hangs bails out after not recognizing neither mmc1 nor mmc2 (though it recognizes mmc2 when I put in the eMMC flash memory)

@ayufan since you managed to produce images that boot from SPI as well: Is this a matter of configuraton/build parameters or does this require extra-patches?

RE: u-boot (forks) status - CameronNemo - 05-11-2020

Unfortunately I could not get even a basic boot.scr to work with mainline u-boot (the recent 2020.04 release). Does anyone have any tips for debugging or known-working images (idbloader.img and u-boot.itb) that I can use as reference?

Here is the boot.cmd I am using:

```
setenv blink_power 'led power off; sleep 0.1; led power on'
while true; do run blink_power; sleep 1; done
```

I am building the script image with:

```
mkimage -C none -A arm -T script -d boot.cmd boot.scr
```

The ATF/u-boot build recipes are here: https://github.com/void-linux/void-packages/pull/21198

My sfdisk config is:

```
label: gpt
unit: sectors
first-lba: 64

/dev/mmcblk1p1 : start= 64, size= 16320, type=8DA63339-0007-60C0-C436-083AC8230908, name="IDBLoader", attrs="RequiredPartition"
/dev/mmcblk1p2 : start= 16384, size= 8192, type=8DA63339-0007-60C0-C436-083AC8230908, name="U-Boot", attrs="RequiredPartition"
/dev/mmcblk1p3 : start= 24576, size= 8192, type=8DA63339-0007-60C0-C436-083AC8230908, name="TrustedFirmware-A", attrs="RequiredPartition"
/dev/mmcblk1p4 : start= 32768, size= 229376, type=L, name="BootFS", bootable, attrs="LegacyBIOSBootable"
/dev/mmcblk1p6 : start= 262144, type=L, name="RootFS"
```

I then flash the images to the first two partitions, make a 32 bit FAT filesystem on the bootfs, mount it, and copy the boot.scr into the bootfs.

RE: u-boot (forks) status - XmAz - 06-19-2020

Hello @CameronNemo

Have you been able to solve you problem?