On Tue, 2015-07-07 at 11:19 +0200, Hans de Goede wrote: > Hi, > > On 06-07-15 16:28, Ian Campbell wrote: > > On Mon, 2015-07-06 at 14:11 +0200, Hans de Goede wrote: > >> Hi, > >> > >> On 06-07-15 09:02, Bernhard Nortmann wrote: > >>> Hello Hans! > >>> > >>> Am 05.07.2015 11:54, schrieb Hans de Goede: > >>>> > >>>> This seems like a good idea to me, am I reading both the --help > >>>> and the code correctly that this only writes u-boot but does not > >>>> do the necessary fel exe 0x..... ? It seems to me that such a > >>>> command should also execute u-boot. > >>>> > >>> You're right - the "fel exe" is kept separate. This is done on purpose > >>> to allow uploading other elements via FEL (e.g. boot script, kernel, > >>> initrd). Execution of the bootloader always comes last. > >> > >> Ah right, I guess that makes sense, but if this is not going to > >> be a fire and forget command, and people still need to run more > >> fel commands after it then I'm wondering it this is worth the trouble > >> at all. > > > > Perhaps do the exe by default but provide a way to ask not to? (Or vice > > versa, but that seems less useful to me) > > > > [...] > >> See above since the user still needs to do the exec I wonder > >> what the value is in saving the user the single extra > >> fel write for the u-boot-dtb.bin file. I think having a full > >> auto mode as described above would be better. > > > > Historically wasn't this what the usb-boot script did (effectively a > > wrapper around the fel tool). It's be nice if it either a) started > > working again, b) said something when it wasn't supposed to work and > > pointed in the right direction or c) went away so it stops being > > confusingly tempting to people like me ;-) > > Right, this is what the usb-boot script used to do, but the usb-boot > script uses a u-boot script (.scr) file to tell u-boot where to > laod the kernel, etc.
Yes. Personally I rarely use(d) it in that mode but just used it load SPL + main u-boot and get me to a prompt, which is also broken today and is an easies fix. I, of course, have no in-principal objections to supporting the Linux loading thing too, since it is clearly useful even if I don't often use it myself. > 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. > We could always do the boot_cmd patching when in fel-mode > (which we already detect) but I do not believe this is desirable. Agreed. Ian. -- 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.
