Hi Stephen,
On 25 February 2015 at 16:23, Stephen Warren swarren@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