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@xxxxxxxxxxxx> 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@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. >>> >>> 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? >
Attachment:
signature.asc
Description: OpenPGP digital signature
