building nv-uboot for nyan-big.
Subsystems (2)
Dear D.G. Reid,
I've presented my problem to a few other people on the #linux-exynos channel, and they have directed me to you.
Recently, I have received my Acer Chromebook 13 CB5-311-T28J (a.k.a. nyan-big). However, since there doesn't seem to be any documentation yet. I'll pretty much presume that the instructions are similar to those for previous boards. So what I am mostly interested in is acquiring a working binary blob of nv u-boot, that I can then use to boot a Linux distribution of choice. For the Samsung Chromebook XE303C12 (a.k.a. snow), this was easy to do since the board was well documented and a nv u-boot binary blob was readily available. Later on, when the Samsung Chromebook XE503C32 (a.k.a. peach-pi) got released, the documentation was scarce and at the time that I was experimenting with that particular board, no nv u-boot binaries were available.
As a result of that I have done some research to figure out how to build a working nv u-boot binary, and working instructions can be found on the linux-exynos wiki [1]. However, when I tried to apply them to the snow and spring boards, by selecting a different branch and a different u-boot configuration, those attempts were of no success. Of course those boards are out of the scope of this particular e-mail, but the past few days, the same scenario has occurred for the nyan-big board. So, let's walk through those steps for clarity sake:
First, I cloned the repositories containing both u-boot and the vboot reference implementation for nyan. I'll assume that nyan is the branch I want, considering there is no branch for nyan-big, and considering the base board is named venice2.
git clone https://chromium.googlesource.com/chromiumos/platform/vboot_reference -b firmware-nyan-5771.B git clone https://chromium.googlesource.com/chromiumos/third_party/u-boot -b firmware-nyan-5771.B
After cloning these repositories, I simply entered the u-boot repository, configured it for chromeos_venice2 and started to build it all:
VBOOT_SOURCE=~/chromeos/vboot_reference DEV_TREE_SEPARATE=1 USE_STDINT=1 VBOOT_DEBUG=1 QEMU_ARCH= WERROR=y make O=build/ BUILD_FACTORY_IMAGE=1 distclean VBOOT_SOURCE=~/chromeos/vboot_reference DEV_TREE_SEPARATE=1 USE_STDINT=1 VBOOT_DEBUG=1 QEMU_ARCH= WERROR=y make O=build/ BUILD_FACTORY_IMAGE=1 chromeos_venice2_config VBOOT_SOURCE=~/chromeos/vboot_reference DEV_TREE_SEPARATE=1 USE_STDINT=1 VBOOT_DEBUG=1 QEMU_ARCH= WERROR=y make O=build/ BUILD_FACTORY_IMAGE=1 all
The u-boot.bin binary seems to build fine. However, the problem is similar to the snow and spring boards, where I can't seem to build the DTB-files. The cause for this seems to be that tegra124.dtsi cannot be found, despite it being present in arch/arm/dts. I am not entirely sure whether I can tell DTC what the include paths should be. It may be useful to know that I am using dtc-1.4.0 here.
You may be wondering why I am using these particular instructions. Well, these are the instructions I have derived from the u-boot ebuild in the ChromiumOS overlay, and they have worked successfully for the peach-pi board, as mentioned before. I hope that these instructions can be generaised in such a fashion that they can be used for the other boards as well, without having to rely on setting up a separate chroot environment (as I already should have a working environment considering I am running Gentoo on my other chromebooks).
I'd like to thank you for your time, and I hope you can guide me in the right direction. Maybe you already have a working nv u-boot binary, and could save me some time here. Although, having working instructions here would be nice as well.
Yours faithfully,
S.J.R. van Schaik.
1. http://linux-exynos.org/wiki/ARM_Chromebook/Building_u-boot#Building_U-Boot_for_Peach_Pi.2FPit
nv u-boot for spring (was: building nv-uboot for nyan-big.)
Dear Stephan,
Am 03.11.2014 um 11:42 schrieb S.J.R. van Schaik:
Quoted 5 lines
[...] I have done some research to figure out how to build
a working nv u-boot binary, and working instructions can be found on the linux-exynos wiki [1]. However, when I tried to apply them to the snow and spring boards, by selecting a different branch and a different u-boot configuration, those attempts were of no success. [...]
[...]
Quoted 2 lines
The u-boot.bin binary seems to build fine. However, the problem is similar to the snow and spring boards, where I can't seem to build the DTB-files.
You didn't ask me. ;) My Spring branch with patches is located here:
https://github.com/afaerber/u-boot/commits/spring
For my convenience I changed the sources to default to the right device tree, and I manually inlined exynos-periph-id.dtsi.
If you need further info on my build steps, I can look them up in my scripts (on another machine) - I mainly derived them from the official instructions for Snow on the Chromium Wiki. I'm pretty sure I did not mess with the EC firmware at all.
But whatever workarounds exist, the Chromium folks should really be working on upstreaming U-Boot support for all those Chromebooks, that usually sanitizes the build process as a side-effect, resulting in less user questions. :) For Snow I believe that to be done.
Regards,
Andreas
Quoted 1 line
1. http://linux-exynos.org/wiki/ARM_Chromebook/Building_u-boot#Building_U-Boot_for_Peach_Pi.2FPit
Signature · 2 lines
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
A message that is not in the archive (sent off-list or not yet received): [email protected]
Re: nv u-boot for spring (was: building nv-uboot for nyan-big.)
Stephan, Andreas,
Quoted 23 lines · Andreas Färber
Dear Stephan,
Am 03.11.2014 um 11:42 schrieb S.J.R. van Schaik:
Quoted 5 lines
[...] I have done some research to figure out how to build
a working nv u-boot binary, and working instructions can be found on the linux-exynos wiki [1]. However, when I tried to apply them to the snow and spring boards, by selecting a different branch and a different u-boot configuration, those attempts were of no success. [...][...]
Quoted 2 lines
The u-boot.bin binary seems to build fine. However, the problem is similar to the snow and spring boards, where I can't seem to build the DTB-files.
You didn't ask me. ;) My Spring branch with patches is located here:
https://github.com/afaerber/u-boot/commits/springFor my convenience I changed the sources to default to the right device tree, and I manually inlined
exynos-periph-id.dtsi.If you need further info on my build steps, I can look them up in my scripts (on another machine) - I mainly derived them from the official instructions for Snow on the Chromium Wiki. I'm pretty sure I did not mess with the EC firmware at all.
Quoted 4 lines
But whatever workarounds exist, the Chromium folks should really be working on upstreaming U-Boot support for all those Chromebooks, that usually sanitizes the build process as a side-effect, resulting in less user questions. :) For Snow I believe that to be done.
Unlike the Exynos Chromebooks, the Tegra Chromebooks do not use U-Boot as their firmware/bootloader - they instead use Coreboot (firmware) and Depthcharge (bootloader) like the x86 Chromebooks. You can, however, update your firmware with U-Boot as a legacy mode (Ctrl+L at the dev screen) payload - I've added Julius who can provide more detail about this process.
Note that we do not maintain U-Boot support for these devices, but they are very similar to Venice2 which is well-supported upstream. I can't guarantee that a Venice2 U-Boot payload will "just work" though.
-Andrew
A message that is not in the archive (sent off-list or not yet received): CAODwPW_ZbCMEwdtuu9gMD_HLQWynC6ZQjno6xVxFMOBuxRzd+A@mail.gmail.com
Re: nv u-boot for spring (was: building nv-uboot for nyan-big.)
...and once more with text/plain. Thanks for always forgetting my settings, GMail. -.-
Quoted 18 lines · Julius Werner
Quoted 7 lines
Unlike the Exynos Chromebooks, the Tegra Chromebooks do not use U-Boot as their
firmware/bootloader- they instead use Coreboot (firmware) and Depthcharge (bootloader) like the x86 Chromebooks. You can, however, update your firmware with U-Boot as a legacy mode (Ctrl+L at the dev screen) payload - I've added Julius who can provide more detail about this process.The Tegra Chromebooks (Nyan_Big/Acer and Nyan_Blaze/HP) contain the same "legacy mode" feature as x86 Chromebooks... it essentially just loads and jumps to an unverified binary in the
RW_LEGACYsection of the firmware flash image (1MB starting at0x300000for Tegra, visible via "dump_fmap-h image.bin" in a ChromiumOS developer chroot). However, we did not ship any software in that part of the image (unlike most x86 Chromebooks which ship with SeaBIOS) so you will have to build it yourself.The format used to wrap the blob is a Coreboot File System (CBFS) containing a single file named "payload". You can convert an ELF binary into such a CBFS blob with the cbfstool program bundled with ChromiumOS or upstream coreboot:
# All CBFS images need to have a "bootblock", but since this is not a booting image we just need some empty bytes truncate -s 64 bootblock.dummy
# -s should specify the size ofRW_LEGACYon your Chromebook
cbfstool legacy.bin create -s $((1 * 1024 * 1024)) -B bootblock.dummy -m arm
cbfstool legacy.bin add-payload -f your_firmware.elf -n payload -c lzma
Quoted 6 lines
# ...and now do the following on your Chromebook in developer mode to overwrite the legacy section flashrom -w -i RW_LEGACY:legacy.binThe legacy section is not write-protected and not checked by the verified boot mechanism, so you do *not* need to open your Chromebook and remove the write-protect screw for this.
I don't know about the state of the upstream "venice2" U-Boot. I do know that the ChromiumOS U-Boot repository has a version for
nyan_bigandnyan_blazethat will kinda run but has a bunch of issues (I think EC communication and MMC were wonky, and display had never been added at all). It is probably the best place to start. Remember that this will run after coreboot has already initialized most of the system, which may be unexpected for a U-Boot that intended to run right after power-on reset (you may or may not want to skip the SPL in that case). For U-Boot, there is also an additional complexity that it requires a device tree appended to the final raw binary, but cbfstool expects to receive an ELF file... we have a small script in src/third_party/chromiumos-overlay/sys-boot/chromeos-b
ootimage/files/build_cb_legacy_uboot.sh to resolve that with some objcopies.
Quoted 2 lines
We would be very happy if anyone wants to dig into U-Boot and get it working to a point where people could boot ordinary Linux distributions with it on those Chromebooks. We meant to do it ourselves but ran out of time at the end of the project. Let me know if you have any issues getting the legacy firmware mechanism itself to work (that part at least is considered a supported feature).