On Tue, 14 Jul 2015 14:22:46 +0200
Bernhard Nortmann <[email protected]> wrote:
> 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)
We can surely do a lot of things. However it's best to implement what
is requested by the users and is convenient for them. There are
a few major use cases to consider.
One of them (that's what Ian Campbell wants) is just to load U-Boot via
FEL with as little hassle as possible. This is good for the devices,
where the default U-Boot environment is sufficient to boot the system
by scanning the default locations (USB stick, SD card or maybe NAND).
For this use case, it would be easier for the users to just run
"fel uboot u-boot-sunxi-with-spl.bin"
instead of something like (that's what you are suggesting, right?)
"fel spl u-boot-sunxi-with-spl.bin exe uboot"
Another use case is uploading the kernel and initramfs via FEL too.
This way we don't depend on the kernel being available on the device.
Especially in the case of some tablets, where we have nothing but the
USB OTG connector if the SD card slot is used for UART serial. We
still could do booting with a single, but admittedly long "fel" tool
command line:
"fel uboot u-boot-sunxi-with-spl.bin write 0x42000000 uImage write
0x43000000 sun7i-a20-cubietruck.dtb write 0x43100000 boot.scr write
0x43300000 rootfs.cpio.lzma.uboot"
The whole point of introducing an extra "uboot" command is to make this
long command line shorter (no need to have an explicit "exe" command
with either a real or symbolic address), completely hide the U-Boot
load address from the user (but still ensure that none of the "write"
commands can overwrite the U-Boot location).
And finally, there is a kind of "bare metal" use case. The user may
want to have DRAM initialized, but upload and run his own code
fragments instead of U-Boot. That's why the "spl" command still
remains useful. There could be advanced scripts, which can upload, run
and read back the results from memory. By the way, if the "spl" command
is modified to print the U-Boot load address to stdout, then we could
do (it's an alternative to your 'symbolic' address name approach):
"fel exe `fel spl u-boot-sunxi-with-spl.bin`"
Still, the point is that a new command is much more intuitive for the
end users. And the majority of them probably just wants to execute
U-Boot instead of studying complicated usage instructions and writing
wrapper scripts ;-)
--
Best regards,
Siarhei Siamashka
--
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.
