[U-Boot] [PATCH 24/24] tegra124: Expand SPL space by 8KB

[Stephen Warren]

On 05/05/2015 10:26 AM, Simon Glass wrote:
> Hi Stephen,
>
> On 5 May 2015 at 10:12, Stephen Warren <swarren at wwwdotorg.org> wrote:
>> On 05/05/2015 10:03 AM, Simon Glass wrote:
>>>
>>> Hi Stephen,
>>>
>>> On 5 May 2015 at 09:59, Stephen Warren <swarren at wwwdotorg.org> wrote:
>>>>
>>>> On 05/04/2015 11:31 AM, Simon Glass wrote:
>>>>>
>>>>>
>>>>> We are getting very close to running out of space in SPL, and with the
>>>>> currently Chrome OS gcc 4.9 we exceed the limit. Add a litle more space.
>>>>
>>>>
>>>>
>>>> 8K is quite a bump given we only had 24K allocated before. Why is gcc-4.9
>>>> less efficient that earlier compilers I wonder? Were we extremely close
>>>> to
>>>> the limit ebfore? Still, I guess this is fine.
>
> We were about 1KB away, mostly due to the gcc garbage collection bug I
> think. The cros compiler seems even worse, not sure why.
>
>>>> Did you validate whether tegra-uboot-flasher still works with this
>>>> change? I
>>>> think it will since it only cares about the SPL TEXT_BASE and not the
>>>> main
>>>> U-Boot TEXT_BASE, but double-checking would be nice.
>>>
>>>
>>> I tested this with USB A-A (tegrarcm). Is that what you mean?
>>
>>
>> Did you just use tegrarcm, or tegra-uboot-flasher? The latter is a wrapper
>> on top of tegrarcm, and is a bit more involved. See the various READMEs at
>> https://github.com/NVIDIA/tegra-uboot-flasher-scripts. This doesn't support
>> any nyan-derived boards yet, but does support Jetson TK1 which I think you
>> have?
>
> Ah, OK. The script at:
>
> https://github.com/NVIDIA/tegra-uboot-flasher-scripts/blob/master/tegra-uboot-flasher
>
> looks OK to me. It does not have anything hard-coded that I can see.
> But I have not used it myself. It's kind-of painful that we have all
> this out-of-tree Tegra stuff (pin mux also) that might break when we
> change U-Boot. Is there any way to improve this?

I don't think there's anything to improve; nothing is wrong.


If something changes about the way U-Boot works or must be used, then 
that requires changes elsewhere no matter what. Whether the externals 
changes are:

* Updates to documentation of how to build/use/... U-Boot.
* Updates to the command-lines/techniques people know and use.
* Updates to code/tools that interface with U-Boot.

... then in all cases, a change to U-Boot requires a change to something 
else. I would argue that updating an external tool is actually the 
easiest of the cases, since it's entirely clear what that tool does, 
what change to make to it, and how. Conversely, updating the 
command-lines/techniques that people use is much harder to propagate to 
all people. The update-a-document case may also be about as easy, 
presuming you know which documents to update (there are probably more 
docs than tools at least at present).


In the pinmux case, please consider the system-level implications of a 
change to the pinmux. There is a single correct pinmux configuration for 
a given HW configuration, and that's driven purely by the HW design[1]. 
If the pinmux that U-Boot programs is wrong and needs to be changed, the 
same change should be propagated to all SW to fix the bug everywhere. 
The existence of the external Tegra pinmux tools makes that easier; 
update the pinmux tool, regenerate derived files for all SW stacks, and 
apply the changes everywhere. Sure it's more work to do that than just 
updating only U-Boot. However, the tool doesn't add that extra work, 
rather the change to the desired pinmux makes the work. The only 
alternative (which does indeed reduce overall work) is to update e.g. 
only U-Boot's pinmux programming, and leave everything else buggy. 
That's certainly not a desirable situation. I introduced 
tegra-pinmux-scripts specifically to avoid that kind of situation.

[1] For boards with expansion headers where the end-user/... can use 
different pins for different things, I consider the HW configuration to 
include the definition of whatever the user has plugged into the 
expansion header.