On Fri, 2015-02-27 at 22:11 -0700, Simon Glass wrote:
Hi Sjoerd,
On 25 February 2015 at 17:12, Sjoerd Simons sjoerd.simons@collabora.co.uk wrote:
Hey Simon,
Incidentally i got acces to a Nyan big and wanted to start testing u-boot on it. Unfortunately putting a uImage in a vboot signed blob to chainload it from the primary bootloader like on the exynos based chromebooks seemed not to work.
Do you have any good pointers how to use u-boot on nyan? (Ideally without having to re-flash coreboot, as i would like to create images people can easily test on a vanilla chromebook)
No I don't sorry. I suppose in dev mode it should boot a signed image so if you put U-Boot in a FIT as with snow/pit it should work. But I don't have instructions...if you figure it out it would be good to put this info somewhere.
Finally got time to play a bit with this. On the snow/peach boards the approach is to put u-boot in a legacy u-boot image (not a FIT image), which has the nice side-effect of re-locating u-boot before jumping to it.
Unfortunately the depthcharge on the nyan boards appears not to support legacy images, only FIT images, which don't get relocated before jumping into the kernel blob. Long story short, on the nyan boards the FIT image gets loaded at 0x81000000 and the FIT images i created put the u-boot blob at an offset of 0xCC. After re-configuring CONFIG_SYS_TEXT_BASE to match i got u-boot starting \o/ ;)
Unfortunately the board seems to hard hang when it tries to enable/use the data cache. Enabling CONFIG_SYS_DCACHE_OFF makes it get to the u-boot prompt. Unfortunately neither MMC (didn't detect card) nor USB (failed to get descriptor from my usb network dongle) worked so i couldn't try booting a kernel just, but it's start.
Simon, does data cache/MMC/USB work properly when booting u-boot "natively" rather then chainloading from coreboot or does it have similar issues?
Fwiw, I've attached the output of u-boot running onthe board (with CONFIG_SYS_DCACHE_OFF enabled).