Chainloading U-Boot from Fastboot on Tegra30

[Peter Geis]

On Mon, Jul 6, 2020 at 3:48 PM Peter Geis <pgwipeout at gmail.com> wrote:
>
> On Mon, Jul 6, 2020 at 1:04 PM Stephen Warren <swarren at wwwdotorg.org> 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?