On Tue, 1 Sep 2015 14:16:20 +0200 Bernhard Nortmann <[email protected]> wrote:
> 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? The question is why would we want to involve both SPL and main U-Boot headers if just the SPL header alone is enough? The SPL header is Allwinner specific and we are kinda in control of it. The U-Boot header is used for a wide range of devices and architectures and you should be prepared to encounter a (perfectly justified) opposition if you propose changes to it. > *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 a > good point in favor of the SPL variant, which then could pass on the FEL > flag. You can read SRAM from the main U-Boot binary and access the SPL header just fine. That's the mechanism to pass boot information, which already implicitly exists. Reading from SRAM can be used, for example, to get the console log messages from the SPL also show on HDMI monitor or LCD screen: http://lists.denx.de/pipermail/u-boot/2015-January/201128.html We need to be careful with the FEL booting though, because the data in SRAM gets scrambled after returning from the SPL back to the FEL handler. But the first ~6K of data in SRAM is fine and this area includes the SPL header. > >>> > >>> 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. That's a minor implementation detail. Some variations are possible, people just need to come to an agreement about it. > 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). Well, we have the SPL header with some spare space in it. You can name it as "boot parameter block" if you want to. > >> 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). What I wanted to say here is that I don't have time for working on this code right now, and it's not a critical bugfix. I'm also sorry for a late reply. If you want to implement this boot.scr handling and submit patches to U-Boot, then you are welcome. There is one more interesting thing, which can potentially speed up booting (the fastboot patches from Maxime): http://lists.denx.de/pipermail/u-boot/2015-August/226053.html http://lists.denx.de/pipermail/u-boot/2015-September/226207.html http://lists.denx.de/pipermail/u-boot/2015-September/226211.html It does not have to be fastboot, but any USB protocol would be fine as long as it provides the necessary features (upload of the kernel, DTB blob, initrd, ...) and works faster than FEL transfers :-) > 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. U-Boot already handles SDCARD and USB (FEL) boot methods gracefully with a single build configuration. Now NAND boot method is also going to be added to the mix. The environment data handling is a minor quirk, which has been discovered and is probably going to be fixed. There is no real challenge. > >>> 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 -- 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.
