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. > > > > 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. > > 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. > > 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. -- 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.
