Hi Stephen, On 25 February 2015 at 16:23, Stephen Warren <swar...@wwwdotorg.org> wrote: > On 02/17/2015 03:29 PM, Simon Glass wrote: >> >> We need to turn on all audio-related clocks for the kernel to boot. >> Otherwise it will hang when trying to enable audio. > > > This certainly isn't true for the upstream kernel; is this some bug in the > ChromeOS kernel? If so, we should explicitly call this out in the commit > description.
OK I'll adjust the commit message. At some point perhaps this problem will go away. Chrome OS is running kernel v3.10 on this device. > >> Also for Linux set up the ODMDATA and graphics driver video protection. > > > Why doesn't ODMDATA come from the BCT? The way this is suppose to work is > that the boot ROM copies the BCT into IRAM, and U-Boot (or indeed any > bootloader) copies the ODMDATA field from the BCT in IRAM into the PMC > scratch20 register. This logic is already all in place in U-Boot, and indeed > any NVIDIA-authored bootloader AFAIK. OK, so perhaps I can just drop this code. It might just be a hack in Coreboot. > > Is this U-Boot port intended to run as a Coreboot payload rather than > natively, and Coreboot is somehow corrupting the copy of the BCT in IRAM? If > so, we should explicitly call this out in the commit description. No, there really isn't any point in running U-Boot as a Coreboot payload, since U-Boot can do all the init itself. This series is for running U-Boot stand-alone on Nyan-big. > > I would personally want to (be able to) make my SPI flash r/w and replace > Coreboot with U-Boot. Perhaps we need different board names for those two > use-cases; something like nyan-big for the Coreboot payload, and > nyan-big-native for the version you'd write directly into SPI? See above... if we can get the display stuff merged then I could do this also. But without a display it's missing a big piece. Regards, Simon _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot