building nv-uboot for nyan-big.

building nv-uboot for nyan-big.

[S.J.R. van Schaik]

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.)

[Andreas Färber]

Dear Stephan,

Am 03.11.2014 um 11:42 schrieb S.J.R. van Schaik:
> [...] 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. [...]
[...]
> 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

> 1. http://linux-exynos.org/wiki/ARM_Chromebook/Building_u-boot#Building_U-Boot_for_Peach_Pi.2FPit

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg

Re: nv u-boot for spring (was: building nv-uboot for nyan-big.)

[Andrew Bresticker]

Stephan, Andreas,

On Mon, Nov 3, 2014 at 5:05 AM, Andreas Färber <afaerber-l3A5Bk7waGM@public.gmane.org> wrote:
> Dear Stephan,
>
> Am 03.11.2014 um 11:42 schrieb S.J.R. van Schaik:
>> [...] 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. [...]
> [...]
>> 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.

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

Re: nv u-boot for spring (was: building nv-uboot for nyan-big.)

[Julius Werner]

...and once more with text/plain. Thanks for always forgetting my
settings, GMail. -.-

On Tue, Nov 4, 2014 at 2:26 PM, Julius Werner <jwerner@chromium.org> wrote:
>>
>> 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_LEGACY section of the firmware flash image (1MB starting at 0x300000 for 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 of RW_LEGACY on 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
> # ...and now do the following on your Chromebook in developer mode to overwrite the legacy section
> flashrom -w -i RW_LEGACY:legacy.bin
>
> The 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_big and nyan_blaze that 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.
>
> 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).