> -----Original Message----- > From: Stephen Warren > Sent: Wednesday, September 02, 2015 1:05 PM > To: Tom Warren; Simon Glass > Cc: Bin Meng; Thierry Reding; Tom Rini; U-Boot Mailing List > Subject: Re: [U-Boot] [PATCH] Revert "fdt: Fix fdtdec_get_addr_size() for 64- > bit" > > On 09/02/2015 09:52 AM, Tom Warren wrote: > > Simon, et al, > > > >> Simon Glass wrote at Friday, August 14, 2015 3:05 AM: > >> I plan to apply this revert to u-boot-x86 (where SPI is currently > >> broken) and (once it has a bit more testing) also this patch which I > >> think makes the change in a safer way: > >> > >> https://patchwork.ozlabs.org/patch/504918/ > >> > >> At present that patch breaks at least one x86 board and I have not > >> dug into it yet. > >> > >> The revert should not break tegra, according to Stephen. > > > > Unfortunately, my testing on P2571 with TOT u-boot-tegra (rebased against > TOT u-boot/master this morning) shows that that is not true. > > > > The revert of the disputed 'fdtdec_get_addr_size' patch _does_ break Tegra > 64-bit (P2571, at least). Nyan-big is OK. With Simon's revert in place, my > board > just loops on SPL signon, so I assume it's faulting, etc. in CPU init. Note > that this > is the current state of TOT u-boot/master. > > I'm a bit confused. So far, we don't support SPL on T210 since we assume some > other bootloader runs on the boot CPU and starts just the main U-Boot on the > main CPU. It sounds like you're testing some local-only SPL support? Currently there are a couple of ways to get T210 64-bit U-Boot loaded/executed. The first is the way I've always done it (during development and today) - use a 32-bit SPL that I built when I first ported 32-bit U-Boot to T210. I've saved away the SPL portion as a binary, and combine it with the current 64-bit T210 U-Boot proper when building my image. It's always worked up to now. What I'm seeing is a failure in the 64-bit CPU U-Boot portion. I just mentioned the looping SPL signon symptom because that's what I see as the indicator of a broken 64-bit image.
The other way is to use your proprietary NV bootloader for the 32-bit portion (this will become the de facto standard when we release said NV bootloader code as open-source, or a binary first-stage loader 'tool'). I haven't tried that, since my way works and is an easy part of my workflow. If you can point me to your boot CPU loader internally, I can try your method and see if it makes a difference, but I doubt it will. Tom -- nvpublic _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
