Chainloading U-Boot from Fastboot on Tegra30

[Peter Geis]

On Fri, Aug 21, 2020 at 6:41 PM Stephen Warren <swarren at wwwdotorg.org> wrote:
>
> On 8/21/20 3:39 PM, Tom Rini wrote:
> > On Fri, Aug 21, 2020 at 05:30:54PM -0400, Peter Geis wrote:
> >> 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!
>
> That message makes it appear as if it did find the backup GPT? But
> presumably it didn't actually do so, since an all-zeroes UUID isn't
> likely correct.

I am unsure of this answer.
I'd imagine it found something for the header match to succeed on the
backup, even if the GUID itself is invalid?

>
> Does this device even have any GPT? IIRC some of the earlier Tegra
> systems *only* had a TegraPT, and not any valid GPT. Perhaps that we
> Tegra20 or earlier, and we'd fixed that by Tegra30? Or perhaps this
> issue only applied to the eMMC boot HW partitions/region, not the main
> data region.

It does have a valid GPT located at the sector designated by "gpt_sector".
For several years I have been using a patch I ported for mainline
Linux from the early android hacking days.
It essentially overwrites the expected backup sector with the one
designated in the command line.
Both the Tegra20 Motorola Xoom and the Tegra30 Ouya use this method
successfully.

>
> >> 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.
> >
> > Ah, interesting.  And where is that sector in relation to where the
> > backup should be?  I'm not sure off-hand how easy it would be to make
> > backup location easy to run-time configure, but if it's lba - 2 instead
> > of lba - 1 or something, we could add a build-time "also check.." thing,
> > if it's a consistent offset, and probably is.  Similarly, we could add
> > something kinda ugly to allow overriding GPT_PRIMARY_PARTITION_TABLE_LBA
> > with where that is instead.

The ugly hack is essentially what the downstream Android kernel implemented.
Ideally we would be able to support TegraPT, but judging by the amount
of code Dmitry's implementation for the Linux kernel took, it would
probably be simpler and easier to maintain the downstream
implementation.

> >
> > Other-otherwise, I know there's patches in progress to support "tegra
> > partition table" for Linux and doing that for U-Boot could be handy and
> > fix this problem as well?
> >
>
>