Chainloading U-Boot from Fastboot on Tegra30

[Peter Geis]

On Fri, Aug 21, 2020 at 5:04 PM Tom Rini <trini at konsulko.com> wrote:
>
> On Fri, Aug 21, 2020 at 04:17:24PM -0400, Peter Geis wrote:
> > 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.
>
> Nice work.
>
> > 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?
>
> Honestly, this is what CONFIG_PRAM is for.  We could possibly add
> something to get this from device-tree, but we might need to do that
> early enough that it becomes a tricky thing to do.

Thank you, that makes sense.

>
> > 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?
>
> Some tangential experiments the other day and I saw that U-Boot would
> read the backup GPT if it's at the expected place.  But that might be
> only after you do something like "part list mmc 0", so there might in
> turn be places that we need to be a bit more robust in our checking.

Unfortunately running <part list mmc 0> returns "## Unknown partition
table type 0"

This is the result of the gpt guid command:
Tegra30 (Ouya) # gpt guid mmc 0
GUID Partition Table Header signature is wrong: 0x1000 != 0x5452415020494645
find_valid_gpt: *** ERROR: Invalid GPT ***
find_valid_gpt: ***        Using Backup GPT ***
00000000-0000-0000-0000-000000000000
success!

The backup GPT is a valid GPT, and linux will pull the partition table
from it if forced to look there.
The android kernel handled this by adding "gpt gpt_sector=15073279" to
the command line.

>
> --
> Tom