Hi Siarhei, hello Hans! Am 01.09.2015 um 00:58 schrieb Siarhei Siamashka: > On Mon, 31 Aug 2015 13:57:54 +0200 > Hans de Goede <[email protected]> wrote: > >> Hi, >> >> On 31-08-15 13:45, Siarhei Siamashka wrote: >>> On Tue, 07 Jul 2015 10:54:36 +0100 >>> Ian Campbell <[email protected]> wrote: >>> >>>> On Tue, 2015-07-07 at 11:19 +0200, Hans de Goede wrote: >>>>> We could agree upon a special magic signature between the fel tool >>>>> and the sunxi u-boot code which means that u-boot should patch >>>>> its boot_cmd in the env to load a script from DRAM (at a fixed >>>>> offset). >>>>>>>> Having mangled the header could we also find/define a field for the DRAM
>>>> address? >>>> >>>> Perhaps rather than patching the boot_cmd we could instead have this>>>> early code set a flag (in the env) which the normal bootcmd could check
>>>> (first) as part of the normal series of attempts to boot from various >>>> sources? That would let the user configure it via the env if they >>>> wanted. >>> >>> In the IRC chat a few days ago, I promised to Bernhard to post some >>> ideas to the mailing list regarding 'boot.scr' handling by the 'fel' >>> tool. And it seems like it's best to pick up this discussion. >>> >>> Right now the 'mksunxiboot' tool creates 32 bytes header in the >>> beginning of the SPL. This header size can be always extended if >>> necessary by changing the first branch instruction. Only the first >>> 20 bytes are used currently. And the 12 byte padding block at the >>> offset 0x14 is currently filled with garbage (which typically ends >>> up being zeros in real SPL files, but we can't rely on this):>>> http://git.denx.de/?p=u-boot.git;a=blob;f=tools/mksunxiboot.c;h=3361251c8e7fffcb4ccbc3e29eb5e2e956608b0c#l19
>>> >>> In the boot0 binary, the offset 0x14 contains the 'pub_head_size' >>> field, which is a 32-bit integer: >>> https://github.com/linux-sunxi/sunxi-tools/blob/v1.2/bootinfo.c#L38 >>> >>> In order to easily distinguish between boot0 and U-Boot SPL, some sort >>> of a 32-bit magic value can be placed by the mksunxiboot tool at the >>> offset 0x14. Because the 'pub_head_size' value in boot0 can't be large >>> (we can't reasonably expect it to be larger than the limit imposed >>> by the SRAM size), the high 16 bits of 'pub_head_size' are expected >>> to be zero. So the high 16 bits of the word at 0x14 can be used for >>> identification. It is a good idea to also implement some kind of >>> versioning scheme (in the lower 16 bites?) in order to allow future >>> extensions. The rest of the header should be explicitly cleared >>> instead of writing garbage there. >>> >>> Now on the 'fel' tool side. If the 'fel' tool recognizes the U-Boot >>> SPL magic at the offset 0x14, then it knows that there are 8 bytes >>> of storage space at 0x18 (initilized to 0 by mksunxiboot). >>> >>> And when handling the command line parsing, just like it is recognizing >>> the main U-Boot binary format now, the 'fel' tool can easily recognize >>> the format of the 'boot.scr' blob when it is written to some arbitrary >>> location in DRAM via the 'write' command. If it detects the boot.scr >>> format, then the address of the loaded boot.scr can be stored at the >>> offset 0x18 in the header. And instead of abusing the "write" command >>> functionality, we can alternatively introduce a new one, but this is >>> a minor detail.
One question that comes to my mind is if it's necessary to involve the U-Boot
SPL here. As the main binary gets transferred to RAM via the fel utility, it could easily apply some similar 'tagging' logic to the "main" U-Boot header?*If* an actual mechanism to pass boot information from SPL to the main binary
gets devised (which to my knowledge current doesn't exist), then Hans has agood point in favor of the SPL variant, which then could pass on the FEL flag.
>>> >>> Now when U-Boot is running, the 'misc_init_r' function can check if >>> the value at the address 0x18 is non-zero, then set something like >>> 'fel_scriptaddr' or 'ram_scriptaddr' variable in the environment. >>> And this variable can be later checked and used by bootcmd from the >>> default environment. >> >> I think having the ability for a fel-loaded u-boot to automatically >> execute a fel-loaded boot.scr from its default environment, and to >> only do so when fel loaded and not do so in other cases is a good idea. >> I think this may involve two distinct pieces of information - one being the "how was I booted?" question (e.g. by setting certain env variables, like "fel_booted"). The other is whether an actual bootscript got provided (and where, i.e. *_scriptaddr). Both could be useful on their own. Instead of directly passing the (boot) script address, it would also be possible to set some "boot parameter block" information - which then in turn might provide further information (versioning might be an example). >> As for the actual implementation I've no preference. > > I don't have any preference either. In the current documentation, > we just advise patching U-Boot sources with a tiny patch. So this > particular use case is covered. Maybe not in the best way, but there > is no urgent problem to fix. > > I guess, right now only Bernhard is interested in doing real work on > improvements in this area. >I agree that this is not a pressing matter. It's probably safe to assume that the normal user won't get in touch with FEL booting very often, and the people who use it are aware of the rough edges and possible workarounds. Personally,
I'm also just using a customized U-Boot with the 'naive'
"source ${scriptaddr} || run distro_bootcmd" approach (while being conscious
of and avoiding the pitfalls this might imply).
But (if possible) it would be nice to 'streamline' this to handle
various boot
media gracefully. As Hans pointed out, the addition of a NAND boot
capability
already creates some new challenges in this domain. >>> Regarding the custom user-saved environment. When booting over USB, we >>> don't transfer the environment blob to the device and have no way to >>> save it over USB back to the PC. Picking the environment from the SD >>> card is not a great idea in the FEL mode (this can lead to unexpected >>> surprises), and we probably want to make sure to suppress this somehow. >> >> With the upcoming / wip nand support this is already a problem, since >> I want to have a single/unified build for both mmc and nand booting. > > I'm glad that we don't have a disagreement at least here :-) > >> The plan here is to teach (add code for) u-boot to dynamically select >> where the environment comes from. This will basically mean calling >> spl_boot_device() not only from the spl but also in u-boot itself, >> and then based on the answer load the env from either mmc or nand, >> or in the case it returns BOOT_DEVICE_BOARD, not load any env at all. >> >> This should solve the problem with fel + env more or less for free. > > Sounds good. > Thanks for following up the discussion and your writeup on the subject! Regards, 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.
