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

[Simon Glass]

Hi Stephen,

On 5 May 2015 at 12:20, Stephen Warren <swarren at wwwdotorg.org> wrote:
> 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.

Here I am enabling the TPM in U-Boot. There may or may not be a kernel
TPM driver. Presumably if there is, then something is wrong, because
it has the wrong pinmux and won't work, or someone did update it in
the kernel and not in U-Boot? Actually I'm not sure that I care about
it running in Linux any more than someone working in Linux cares that
the TPM is working in U-Boot.

Why can't this stuff go in the device tree, which is already shared
between U-Boot and Linux?

Regards,
Simon