On 05/05/2015 10:26 AM, Simon Glass wrote:
Hi Stephen,
On 5 May 2015 at 10:12, Stephen Warren swarren@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@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-uboo...
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.