Closed aneeshlingala closed 10 months ago
One more thing: I added experimental kappa support to my forked u-boot tree. This is still untested, though. So instead of building edk2 (which is picky), lets build uboot and chainload it. Here is my U-boot tree. I will upstream when most things work fine.
I also found this in uboot docs on how to chainload uboot from coreboot on chromebooks.
New advancements. I did some fixes and uboot is building.
i'm using uefi via rw payload on some intel chromebooks as well - see: https://github.com/hexdump0815/imagebuilder/blob/main/systems/chromebook_x86_uefi/doc/apollo-and-gemini-lake-chromebooks.md ... i never thought or tried it on any arm device yet though
one repo might be interesting for you if you are looking into this: https://github.com/alpernebbi/u-boot - there maybe have a look at the different branches and releases - they build rw and i think ro versions for the rk3399 chromebooks ... maybe its good for inspiration?
i'm using u-boot chainloading for the 32bit arm chromebooks as the original bootloader on those is very limited and cannot even load an initrd properly without heavy hacks, but i did not look into that for 64bit arm as depthcharge on them was ok for me so far ... https://github.com/hexdump0815/u-boot-chainloading-for-arm-chromebooks
i some time ago also noticed that there is now some mt8183 support in u-boot and in atf: https://github.com/ARM-software/arm-trusted-firmware/tree/master/plat/mediatek/mt8183 but did not have the time and energy to play around with it yet ... i'm curious to see if you get it working somehow on kukui with rw payload - it would be very nice to have that option as well
best wishes and good luck - hexdump
About the alpernebbi uboot, it has been merged into upstream a while ago.
And also, about building, things are being fixed, slowly.
And also about armv7 chromebooks, you can use uefi on uboot. You just need to enable it in the defconfig. There should be a page for that. Would be easier to boot uefi images than the chromeos specific one.
sorry for the late reply: i was not aware that the alpernebbi changes already made it into mainline u-boot - thanks for this info.
i think uefi on 32bit arm is not supposed to work as well as on 64bit arm as it is not as good standardized iirc.
Closing due to dts issues and also that I dont have time.
I saw a comment by Mrchromebox regarding how to get rw legacy firmware. It involves cbfstool and removing and adding another payload (edk2) to the image. SInce I saw a RW_LEGACY partition when booting into Debian, installing gnome-disk-utility, and seeing the partitions with it. So, probably, we could make some firmware for the boards (kukui, etc.) and flash it. It should be safe since it is RW_LEGACY and not the whole chip being flashed. The problem comes to building EDK2. We'll need to build a custom image, by porting edk2 and the required acpi tables. Or we could try our luck on generic arm64. The problem with that way is that I don't know how to build a generic image, since you can only build for ARM SBCs. And also, here is the comment.