Chainloading U-Boot from Fastboot on Tegra30

[Stephen Warren]

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.

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.

>> 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.
> 
> 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?
> 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20200821/ed1a23f5/attachment.sig>