On Mon, Jul 6, 2020 at 3:48 PM Peter Geis <pgwipeout@xxxxxxxxx> wrote: > > On Mon, Jul 6, 2020 at 1:04 PM Stephen Warren <swarren@xxxxxxxxxxxxx> wrote: > > > > On 7/3/20 6:32 AM, Peter Geis wrote: > > > Good Morning, > > > > > > I am attempting to expand on the work for chainloading U-Boot on the > > > nyan-big in order to chainload U-Boot on the Ouya Tegra30 device from fastboot. > > > I have so far been unsuccessful at getting any output from U-Boot > > > through this method. > > > > I assume that fastboot executes the loaded code on the main CPU not on > > the boot CPU (AVP). U-Boot SPL on Tegra30 expects to start running on > > the AVP though; you would have to disable SPL to make this all work, and > > perhaps fix U-Boot to work without SPL present. I'm not sure what, if > > any, changes would be required to support that. > > > > For background, see: > > https://http.download.nvidia.com/tegra-public-appnotes/index.html > > Apologies for the resend, I realized I didn't reply to the list. > > I admit I'm still extremely new to U-Boot, but this is the way I > understand the boot flow. > ROM does extremely low level init, then loads U-boot SPL. > U-Boot SPL does basic init, ram, cpu and required peripherals, then > loads U-Boot.bin. > U-Boot.bin is U-Boot proper, with the full interface. > > By loading U-Boot.bin as the nyan instructions indicated, I'm > bypassing the SPL code as if it was already complete. > The issue I have is I'm not sure what modifications were done to the > T124 code to allow nyan to do this. > I've compared the nyan configs to the cardhu configs and I don't see > anything that sticks out to me. > I've also dug through the nyan git log and I don't see anything that > was specifically changed to allow chainloading on T124. > > I also am unsure of where fastboot is loading the kernel in order to > set the text base correctly. For anyone interested, I succeeded at chainloading u-boot on the Ouya. The Linux Kernel with low level debugging enabled in the decompressor will print the load address. Jumping to kernel at:4861 ms C:0x80A000C0-0x8112BA40->0x8152C700-0x81C58080 Uncompressing Linux... So by setting the u-boot text base to 0x80A00000 u-boot now executes, but it would then immediately silently reboot. Turns out I needed to define the console in the device-tree, which isn't defined in the u-boot tegra30-cardhu.dts. It would then freeze at relocation time, as it was trying to overwrite the trustzone ram space. #define CONFIG_PRAM 2048 solves that issue. I'd like to know if u-boot can read the reserved-memory device-tree node and use it instead of CONFIG_PRAM? Otherwise the only issue it seems to have it is does not read the nvidia proprietary partition table. Is there a way to force u-boot to read the backup gpt table similar to the android kernel's method?
