Hello Siarhei!

Am 12.07.2015 13:49, schrieb Siarhei Siamashka:

Regarding the new "uboot" command. We can probably make it execute the
u-boot code too, but just postpone the execution (so that it is done
only after the command line parsing is fully finished). For additional
safety, the subsequent "write" and "clear" commands can get some extra
checks to bail out with an error if they try to overwrite the u-boot
code location.

Additionally, the existing "spl" command can be also modified to do
u-boot loading automatically but without executing it (the same
behaviour as the "uboot" command in your current patch). This does
not break compatibility with old scripts or usage instructions because
having u-boot automatically loaded to some memory location is not any
worse than having uninitialized garbage there.
A very good suggestion - I feel that actually is the "way to go", and it would make
the separate "uboot" command obsolete. ("spl" would handle it nicely)

Regarding the 'auto-execution' of code: I think this is somewhat independent of
the suggested extension to load the main U-Boot binary. It would probably be
useful if the fel utility was able to keep track of addresses it has written to (this includes the "write" command), so a later "fel exe" could refer - or even default -
to them. Maybe it's possible to also introduce 'symbolic' names for specific
addresses? I'm thinking "fel exe uboot" here... (with "uboot" being set /
preserved from the aw_fel_write_uboot_image function)

This delay is already handled in the 'aw_fel_write_and_execute_spl'
function. It is set to 0.25s there and seems to already provide a
sufficient safety headroom.
[...]
Anyway, if the current 0.25s delay is not enough, then we can always
increase this delay later.
You're right. I came up with that as the "usb-boot" script introduces a delay
(sleep) at that point, and I somehow seem to remember that a delay was
required in my first experiments. However, after retesting this, the existing
SPL delay seems to be just fine, and I had no issues when removing the
additional wait again.

I'll now prepare a v2 patch, that also addresses the other style/logic issues
you pointed out.

Thanks, B. Nortmann

--
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
For more options, visit https://groups.google.com/d/optout.

Reply via email to