| Message ID | 1424746131-11740-1-git-send-email-siarhei.siamashka@gmail.com |
|---|---|
| State | RFC |
| Delegated to: | Hans de Goede |
| Headers | show |
On Tue, 2015-02-24 at 04:48 +0200, Siarhei Siamashka wrote: > In order to fully support booting the whole system over USB OTG > without relying on anything else (MMC, SATA, USB sticks, ...), it > is possible to upload the 'boot.scr' file to DRAM using the 'fel' > tool. But U-Boot still needs to be able to pick it up there before > checking any other boot media. > > Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com> > --- > > The patch might be not the best way to implement this. But it would > be great if U-Boot had out of the box support for: > http://linux-sunxi.org/index.php?title=FEL/USBBoot&oldid=13134#Boot_the_whole_system_over_USB_.28u-boot_.2B_kernel_.2B_initramfs.29 > > One of the bad things about this patch is that the "scriptaddr" > variable needs to be hardcoded and protected agaist modifications > (if this address is to be used from the SPL). Perhaps use a separate dedicated/hardcoded address for the FEL boot script to avoid adding unusual semantics to $scriptaddr (which might surprise users not using fel)? If the FEL address has to be 0x43100000 for compatibility with existing instructions/tools that might mean moving the current scriptaddr elsewhere. I think we can live with that. > Also I'm not sure how this all could fit into the > "config_distro_bootcmd.h" model, so I even have not tried > that yet. Just at a quick glance, based on the PXE entry something like: #define BOOTENV_DEV_FEL(devtypeu, devtypel, instance) \ "bootcmd_fel=source ...\0" i.e. all the magic params are irrelevant in this case. Perhaps "bootcmd_"#devtypel"=...\0" but I don't think that's needed in this instance. BOOTENV_DEV_PXE doesn't bother at least. Then in BOOT_TARGET_DEVICES include "func(FEL, fel, na)" Ian.
On Fri, 27 Feb 2015 16:39:45 +0000 Ian Campbell <ijc+uboot@hellion.org.uk> wrote: > On Tue, 2015-02-24 at 04:48 +0200, Siarhei Siamashka wrote: > > In order to fully support booting the whole system over USB OTG > > without relying on anything else (MMC, SATA, USB sticks, ...), it > > is possible to upload the 'boot.scr' file to DRAM using the 'fel' > > tool. But U-Boot still needs to be able to pick it up there before > > checking any other boot media. > > > > Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com> > > --- > > > > The patch might be not the best way to implement this. But it would > > be great if U-Boot had out of the box support for: > > http://linux-sunxi.org/index.php?title=FEL/USBBoot&oldid=13134#Boot_the_whole_system_over_USB_.28u-boot_.2B_kernel_.2B_initramfs.29 > > > > One of the bad things about this patch is that the "scriptaddr" > > variable needs to be hardcoded and protected agaist modifications > > (if this address is to be used from the SPL). > > Perhaps use a separate dedicated/hardcoded address for the FEL boot > script to avoid adding unusual semantics to $scriptaddr (which might > surprise users not using fel)? Making something that is FEL-boot specific and diverges from the normal configuration is not great. Is there a real practical need for anyone to override $scriptaddr and the other similar variables in the environment? If not, marking them as read-only (similar to how the MAC address is handled) may be a reasonable solution. > If the FEL address has to be 0x43100000 for compatibility with existing > instructions/tools that might mean moving the current scriptaddr > elsewhere. I think we can live with that. There was an idea to make mksunxiboot tool store all these magic addresses into the bootable image, so that the fel tool could find them there. Some of such ideas are listed here: http://linux-sunxi.org/FEL/USBBoot#Potential_future_improvements_for_u-boot_v2015.07 This can only work if these addresses become compile time constants and can't be overridden by the environment. If the user really has a good reason to change them, making them configurable via menuconfig may be a solution. > > Also I'm not sure how this all could fit into the > > "config_distro_bootcmd.h" model, so I even have not tried > > that yet. > > Just at a quick glance, based on the PXE entry something like: > > #define BOOTENV_DEV_FEL(devtypeu, devtypel, instance) \ > "bootcmd_fel=source ...\0" > > i.e. all the magic params are irrelevant in this case. Perhaps > "bootcmd_"#devtypel"=...\0" but I don't think that's needed in this > instance. BOOTENV_DEV_PXE doesn't bother at least. > > Then in BOOT_TARGET_DEVICES include "func(FEL, fel, na)" Well, in fact I'm not a big fan of the C preprocessor based approach used there. And if I understand it correctly, this is already causing some troubles for the A80 (sun9i) support: https://patchwork.ozlabs.org/patch/429463/ The C preprocessor surely can be used, but such code is barely maintainable. IMHO all the necessary adjustments to the environment variables can be done at runtime in the misc_init_r() function. For example, pre-pending "fel" to the "boot_targets" variable can be done based on a runtime check and activated only for the FEL mode. The C preprocessor constants are much less flexible.
On Sun, 2015-03-01 at 23:37 +0200, Siarhei Siamashka wrote: > On Fri, 27 Feb 2015 16:39:45 +0000 > Ian Campbell <ijc+uboot@hellion.org.uk> wrote: > > > On Tue, 2015-02-24 at 04:48 +0200, Siarhei Siamashka wrote: > > > In order to fully support booting the whole system over USB OTG > > > without relying on anything else (MMC, SATA, USB sticks, ...), it > > > is possible to upload the 'boot.scr' file to DRAM using the 'fel' > > > tool. But U-Boot still needs to be able to pick it up there before > > > checking any other boot media. > > > > > > Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com> > > > --- > > > > > > The patch might be not the best way to implement this. But it would > > > be great if U-Boot had out of the box support for: > > > http://linux-sunxi.org/index.php?title=FEL/USBBoot&oldid=13134#Boot_the_whole_system_over_USB_.28u-boot_.2B_kernel_.2B_initramfs.29 > > > > > > One of the bad things about this patch is that the "scriptaddr" > > > variable needs to be hardcoded and protected agaist modifications > > > (if this address is to be used from the SPL). > > > > Perhaps use a separate dedicated/hardcoded address for the FEL boot > > script to avoid adding unusual semantics to $scriptaddr (which might > > surprise users not using fel)? > > Making something that is FEL-boot specific and diverges from the normal > configuration is not great. Is there a real practical need for anyone > to override $scriptaddr and the other similar variables in the > environment? If not, marking them as read-only (similar to how the MAC > address is handled) may be a reasonable solution. I've certainly had to mess with $*addr in order to workaround issues with older versions of Xen booting on the cubietruck. More generally I think diverging from the norm with a sunxi specific variable is preferable to changing the semantics of existing variables to make them r/o, which will make sunxi inconsistent with other u-boot platforms. > > If the FEL address has to be 0x43100000 for compatibility with existing > > instructions/tools that might mean moving the current scriptaddr > > elsewhere. I think we can live with that. > > There was an idea to make mksunxiboot tool store all these magic > addresses into the bootable image, so that the fel tool could find > them there. Some of such ideas are listed here: > > http://linux-sunxi.org/FEL/USBBoot#Potential_future_improvements_for_u-boot_v2015.07 > > This can only work if these addresses become compile time constants > and can't be overridden by the environment. I'm afraid that won't fly, $fooaddr are not r/o variables. When felbooting there doesn't seem to be any particular reason why you have to use $fooaddr from the environment, they could just as well be addresses set by the boot.scr itself, whether derived from the eGON header or not. > > > Also I'm not sure how this all could fit into the > > > "config_distro_bootcmd.h" model, so I even have not tried > > > that yet. > > > > Just at a quick glance, based on the PXE entry something like: > > > > #define BOOTENV_DEV_FEL(devtypeu, devtypel, instance) \ > > "bootcmd_fel=source ...\0" > > > > i.e. all the magic params are irrelevant in this case. Perhaps > > "bootcmd_"#devtypel"=...\0" but I don't think that's needed in this > > instance. BOOTENV_DEV_PXE doesn't bother at least. > > > > Then in BOOT_TARGET_DEVICES include "func(FEL, fel, na)" > > Well, in fact I'm not a big fan of the C preprocessor based > approach used there. And if I understand it correctly, this > is already causing some troubles for the A80 (sun9i) support: > > https://patchwork.ozlabs.org/patch/429463/ This has nothing much todo with the config_distro_bootcmd.h stuff, except the bootcmd stuff requires some of those variables to be set. > The C preprocessor surely can be used, but such code is barely > maintainable. Regardless, the above BOOTENV_DEV type stuff is how the common config_distro_bootcmd.h setup for adding a boot device works and should be used. Or you can try and convince the maintainers it should be done some other way globally, the important thing is that sunxi shouldn't be more special than necessary. > IMHO all the necessary adjustments to the environment variables can > be done at runtime in the misc_init_r() function. For example, > pre-pending "fel" to the "boot_targets" variable can be done based > on a runtime check and activated only for the FEL mode. This means the user cannot adjust things to suit their local needs, either disabling the fel script support or inserting it into the boot order wherever they want. Hardcoding that stuff in C is not a solution here I'm afraid. So, please integrate properly with the common bootcmd stuff used on other platforms instead of inventing sunxi specific ways to do things. If needed for this infrastructure to work well then IMHO it would be acceptable to either provide a function or set a variable on boot which indicates whether or not the system was fel booted so e.g you could write "if $fel_booted; then source $feladdr; fi" as bootcmd_fel. Unless there is some existing "how was I booted" functionality in u-boot I'm not aware of, if there was we should use it. BTW, WRT: + /* Erase any potential boot.scr remnants in DRAM */ + writel(0, CONFIG_SCRIPTADDR); I was thinking that this isn't really all that sunxi specific, since bootloops etc can occur on any platform which doesn't erase RAM between boots. I think a better solution might be to add an option to the source command to make it one shot i.e. by corrupting the boot.scr header behind it, so it won't automatically be used next time. Ian.
On Tue, 03 Mar 2015 08:31:17 +0000 Ian Campbell <ijc+uboot@hellion.org.uk> wrote: > On Sun, 2015-03-01 at 23:37 +0200, Siarhei Siamashka wrote: > > On Fri, 27 Feb 2015 16:39:45 +0000 > > Ian Campbell <ijc+uboot@hellion.org.uk> wrote: > > > > > On Tue, 2015-02-24 at 04:48 +0200, Siarhei Siamashka wrote: > > > > In order to fully support booting the whole system over USB OTG > > > > without relying on anything else (MMC, SATA, USB sticks, ...), it > > > > is possible to upload the 'boot.scr' file to DRAM using the 'fel' > > > > tool. But U-Boot still needs to be able to pick it up there before > > > > checking any other boot media. > > > > > > > > Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com> > > > > --- > > > > > > > > The patch might be not the best way to implement this. But it would > > > > be great if U-Boot had out of the box support for: > > > > http://linux-sunxi.org/index.php?title=FEL/USBBoot&oldid=13134#Boot_the_whole_system_over_USB_.28u-boot_.2B_kernel_.2B_initramfs.29 > > > > > > > > One of the bad things about this patch is that the "scriptaddr" > > > > variable needs to be hardcoded and protected agaist modifications > > > > (if this address is to be used from the SPL). > > > > > > Perhaps use a separate dedicated/hardcoded address for the FEL boot > > > script to avoid adding unusual semantics to $scriptaddr (which might > > > surprise users not using fel)? > > > > Making something that is FEL-boot specific and diverges from the normal > > configuration is not great. Is there a real practical need for anyone > > to override $scriptaddr and the other similar variables in the > > environment? If not, marking them as read-only (similar to how the MAC > > address is handled) may be a reasonable solution. > > I've certainly had to mess with $*addr in order to workaround issues > with older versions of Xen booting on the cubietruck. Was it really necessary to mess with the environment variables for the older versions of Xen? Or just hardcoding some magic addresses in the boot.scr could also solve the problem just fine? Could you please tell us more about this old Xen address space allocation requirements? Would it be difficult to change the sunxi U-Boot defaults to accommodate them? > More generally I think diverging from the norm with a sunxi specific > variable is preferable to changing the semantics of existing variables > to make them r/o, which will make sunxi inconsistent with other u-boot > platforms. Consistency with the other U-Boot platforms is a valid point. > > > If the FEL address has to be 0x43100000 for compatibility with existing > > > instructions/tools that might mean moving the current scriptaddr > > > elsewhere. I think we can live with that. > > > > There was an idea to make mksunxiboot tool store all these magic > > addresses into the bootable image, so that the fel tool could find > > them there. Some of such ideas are listed here: > > > > http://linux-sunxi.org/FEL/USBBoot#Potential_future_improvements_for_u-boot_v2015.07 > > > > This can only work if these addresses become compile time constants > > and can't be overridden by the environment. > > I'm afraid that won't fly, $fooaddr are not r/o variables. They are not r/o variables today. But the U-Boot keeps evolving. For example, it got Kconfig support, which offers an alternative to the environment to some extent. > When felbooting there doesn't seem to be any particular reason why you > have to use $fooaddr from the environment, they could just as well be > addresses set by the boot.scr itself, whether derived from the eGON > header or not. We do have the reasons to settle with some good set of addresses, which are known to be mostly problem free. Otherwise people start being creative with assigning addresses and run into troubles. For example, I have seen reports from the people failing to boot the old sunxi-3.4 kernel just because the initrd was clashing with the CMA area reservation. And we have the framebuffer, the pre-console buffer and potentially other things living in the same address space. Not stepping on each other's toes just needs a bit of coordination. > > > > Also I'm not sure how this all could fit into the > > > > "config_distro_bootcmd.h" model, so I even have not tried > > > > that yet. > > > > > > Just at a quick glance, based on the PXE entry something like: > > > > > > #define BOOTENV_DEV_FEL(devtypeu, devtypel, instance) \ > > > "bootcmd_fel=source ...\0" > > > > > > i.e. all the magic params are irrelevant in this case. Perhaps > > > "bootcmd_"#devtypel"=...\0" but I don't think that's needed in this > > > instance. BOOTENV_DEV_PXE doesn't bother at least. > > > > > > Then in BOOT_TARGET_DEVICES include "func(FEL, fel, na)" > > > > Well, in fact I'm not a big fan of the C preprocessor based > > approach used there. And if I understand it correctly, this > > is already causing some troubles for the A80 (sun9i) support: > > > > https://patchwork.ozlabs.org/patch/429463/ > > This has nothing much todo with the config_distro_bootcmd.h stuff, > except the bootcmd stuff requires some of those variables to be set. > > > The C preprocessor surely can be used, but such code is barely > > maintainable. > > Regardless, the above BOOTENV_DEV type stuff is how the common > config_distro_bootcmd.h setup for adding a boot device works and should > be used. Or you can try and convince the maintainers it should be done > some other way globally, the important thing is that sunxi shouldn't be > more special than necessary. I don't see why this should be a global change. > > IMHO all the necessary adjustments to the environment variables can > > be done at runtime in the misc_init_r() function. For example, > > pre-pending "fel" to the "boot_targets" variable can be done based > > on a runtime check and activated only for the FEL mode. > > This means the user cannot adjust things to suit their local needs, > either disabling the fel script support or inserting it into the boot > order wherever they want. Hardcoding that stuff in C is not a solution > here I'm afraid. More like you are suggesting that a user needs to have even more reasons to do unwieldy environment maintenance and be able to shoot himself in the foot. Instead of the code deciding what is the right thing to do automatically. And the right thing in this particular case seems to be pretty much obvious. It makes no sense for the user to really adjust things by modifying and storing the environment for the purpose of disabling the fel script support. We want this fel script support feature precisely because we have no other way to modify the environment or deliver the information to U-Boot in another (reasonable) way in certain configurations (with only the serial console and USB OTG available). The other configurations don't need the fel script support feature in the first place, so there is nothing to disable there. > So, please integrate properly with the common bootcmd stuff used on > other platforms instead of inventing sunxi specific ways to do things. > > If needed for this infrastructure to work well then IMHO it would be > acceptable to either provide a function or set a variable on boot which > indicates whether or not the system was fel booted so e.g you could > write "if $fel_booted; then source $feladdr; fi" as bootcmd_fel. Unless > there is some existing "how was I booted" functionality in u-boot I'm > not aware of, if there was we should use it. Providing the 'fel_booted' variable is in fact a good idea. I like it. > BTW, WRT: > + /* Erase any potential boot.scr remnants in DRAM */ > + writel(0, CONFIG_SCRIPTADDR); > > I was thinking that this isn't really all that sunxi specific, since > bootloops etc can occur on any platform which doesn't erase RAM between > boots. I think a better solution might be to add an option to the source > command to make it one shot i.e. by corrupting the boot.scr header > behind it, so it won't automatically be used next time. Still relying on the uninitialized memory read while booting is not pretty. PS. This whole feature is only useful when bringing up support for new hardware. And the people, who are doing this, are typically skilled enough to tweak the U-Boot code a bit even if it does not work out of the box.
On Wed, 2015-03-04 at 16:18 +0200, Siarhei Siamashka wrote: > On Tue, 03 Mar 2015 08:31:17 +0000 > Ian Campbell <ijc+uboot@hellion.org.uk> wrote: > > > On Sun, 2015-03-01 at 23:37 +0200, Siarhei Siamashka wrote: > > > On Fri, 27 Feb 2015 16:39:45 +0000 > > > Ian Campbell <ijc+uboot@hellion.org.uk> wrote: > > > > > > > On Tue, 2015-02-24 at 04:48 +0200, Siarhei Siamashka wrote: > > > > > In order to fully support booting the whole system over USB OTG > > > > > without relying on anything else (MMC, SATA, USB sticks, ...), it > > > > > is possible to upload the 'boot.scr' file to DRAM using the 'fel' > > > > > tool. But U-Boot still needs to be able to pick it up there before > > > > > checking any other boot media. > > > > > > > > > > Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com> > > > > > --- > > > > > > > > > > The patch might be not the best way to implement this. But it would > > > > > be great if U-Boot had out of the box support for: > > > > > http://linux-sunxi.org/index.php?title=FEL/USBBoot&oldid=13134#Boot_the_whole_system_over_USB_.28u-boot_.2B_kernel_.2B_initramfs.29 > > > > > > > > > > One of the bad things about this patch is that the "scriptaddr" > > > > > variable needs to be hardcoded and protected agaist modifications > > > > > (if this address is to be used from the SPL). > > > > > > > > Perhaps use a separate dedicated/hardcoded address for the FEL boot > > > > script to avoid adding unusual semantics to $scriptaddr (which might > > > > surprise users not using fel)? > > > > > > Making something that is FEL-boot specific and diverges from the normal > > > configuration is not great. Is there a real practical need for anyone > > > to override $scriptaddr and the other similar variables in the > > > environment? If not, marking them as read-only (similar to how the MAC > > > address is handled) may be a reasonable solution. > > > > I've certainly had to mess with $*addr in order to workaround issues > > with older versions of Xen booting on the cubietruck. > > Was it really necessary to mess with the environment variables for > the older versions of Xen? Or just hardcoding some magic addresses > in the boot.scr could also solve the problem just fine? I suppose that would have worked, but as a naive user I would have been very surprised if setenv fooaddr didn't work and probably spent a lot of time trying to figure out why.. > Could you please tell us more about this old Xen address space > allocation requirements? Would it be difficult to change the sunxi > U-Boot defaults to accommodate them? I think there's no need, the version is now ancient history. The issue was todo with making a single contiguous allocation for the first domain, because it needed to be aligned to its size the placement of the various bits in memory at boot meant that only quite a small initial domain could be allocated in practice. That's fixed now though. > > > More generally I think diverging from the norm with a sunxi specific > > variable is preferable to changing the semantics of existing variables > > to make them r/o, which will make sunxi inconsistent with other u-boot > > platforms. > > Consistency with the other U-Boot platforms is a valid point. > > > > > If the FEL address has to be 0x43100000 for compatibility with existing > > > > instructions/tools that might mean moving the current scriptaddr > > > > elsewhere. I think we can live with that. > > > > > > There was an idea to make mksunxiboot tool store all these magic > > > addresses into the bootable image, so that the fel tool could find > > > them there. Some of such ideas are listed here: > > > > > > http://linux-sunxi.org/FEL/USBBoot#Potential_future_improvements_for_u-boot_v2015.07 > > > > > > This can only work if these addresses become compile time constants > > > and can't be overridden by the environment. > > > > I'm afraid that won't fly, $fooaddr are not r/o variables. > > They are not r/o variables today. But the U-Boot keeps evolving. If you want to propose making them r/o for all platforms then please do so, but lets not make sunxi a special case here. (Personally I don't think it will fly, but you can always ask). > For > example, it got Kconfig support, which offers an alternative to the > environment to some extent. Not really, the environment is user tweakable. > > When felbooting there doesn't seem to be any particular reason why you > > have to use $fooaddr from the environment, they could just as well be > > addresses set by the boot.scr itself, whether derived from the eGON > > header or not. > > We do have the reasons to settle with some good set of addresses, > which are known to be mostly problem free. We should of course provide good defaults, but doesn't follow that we should make it impossible to change them. And, again, if you want to go this route then it should not be sunxi specific. > Otherwise people start being creative with assigning addresses and > run into troubles. For example, I have seen reports from the people > failing to boot the old sunxi-3.4 kernel just because the initrd was > clashing with the CMA area reservation. These people should just use the defaults then. > > Regardless, the above BOOTENV_DEV type stuff is how the common > > config_distro_bootcmd.h setup for adding a boot device works and should > > be used. Or you can try and convince the maintainers it should be done > > some other way globally, the important thing is that sunxi shouldn't be > > more special than necessary. > > I don't see why this should be a global change. This new boot method should be part of config_distro_bootcmd.h. Therefore it should follow the existing mechanisms for adding a new boot method. _If_ you object to the existing mechanisms then you should fix them globally, not do things in some special way for sunxi. > > > > IMHO all the necessary adjustments to the environment variables can > > > be done at runtime in the misc_init_r() function. For example, > > > pre-pending "fel" to the "boot_targets" variable can be done based > > > on a runtime check and activated only for the FEL mode. > > > > This means the user cannot adjust things to suit their local needs, > > either disabling the fel script support or inserting it into the boot > > order wherever they want. Hardcoding that stuff in C is not a solution > > here I'm afraid. > > More like you are suggesting that a user needs to have even more > reasons to do unwieldy environment maintenance and be able to shoot > himself in the foot. The average user will use the default environment and it will just work, no need to do any environment maintenance. The ability to changes things is not for the average user. > Instead of the code deciding what is the right > thing to do automatically. The default enviroment should do the right thing automatically, so people get the right thing be default. Nobody is suggesting otherwise. > It makes no sense for the user to really adjust things by modifying > and storing the environment for the purpose of disabling the fel > script support. > We want this fel script support feature precisely > because we have no other way to modify the environment or deliver > the information to U-Boot in another (reasonable) way in certain > configurations (with only the serial console and USB OTG available). > The other configurations don't need the fel script support feature > in the first place, so there is nothing to disable there. They will get the default environment and work as you want and they expect. Ian.
diff --git a/arch/arm/cpu/armv7/sunxi/board.c b/arch/arm/cpu/armv7/sunxi/board.c index c02c015..8966245 100644 --- a/arch/arm/cpu/armv7/sunxi/board.c +++ b/arch/arm/cpu/armv7/sunxi/board.c @@ -112,6 +112,9 @@ void s_init(void) */ u32 spl_boot_device(void) { + /* Erase any potential boot.scr remnants in DRAM */ + writel(0, CONFIG_SCRIPTADDR); + #ifdef CONFIG_SPL_FEL /* * This is the legacy compile time configuration for a special FEL diff --git a/board/sunxi/board.c b/board/sunxi/board.c index b70e00c..866dbce 100644 --- a/board/sunxi/board.c +++ b/board/sunxi/board.c @@ -235,6 +235,7 @@ static struct musb_hdrc_platform_data musb_plat = { int misc_init_r(void) { unsigned int sid[4]; + char *boot_targets; if (!getenv("ethaddr") && sunxi_get_sid(sid) == 0 && sid[0] != 0 && sid[3] != 0) { @@ -250,6 +251,21 @@ int misc_init_r(void) eth_setenv_enetaddr("ethaddr", mac_addr); } + boot_targets = getenv("boot_targets"); + if (boot_targets) { + char *prefix = "fel "; + char *new_boot_targets = malloc(strlen(prefix) + + strlen(boot_targets) + 1); + if (new_boot_targets) { + strcpy(new_boot_targets, prefix); + strcat(new_boot_targets, boot_targets); + setenv("boot_targets", new_boot_targets); + free(new_boot_targets); + } + } + + setenv_hex("scriptaddr", CONFIG_SCRIPTADDR); + #if defined(CONFIG_MUSB_HOST) || defined(CONFIG_MUSB_GADGET) musb_register(&musb_plat, NULL, (void *)SUNXI_USB0_BASE); #endif diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h index 7779b1f..e7c3322 100644 --- a/include/configs/sunxi-common.h +++ b/include/configs/sunxi-common.h @@ -297,6 +297,8 @@ #define CONFIG_MISC_INIT_R #define CONFIG_SYS_CONSOLE_IS_IN_ENV +#define CONFIG_SCRIPTADDR 0x43100000 + #ifndef CONFIG_SPL_BUILD #include <config_distro_defaults.h> @@ -315,7 +317,6 @@ "bootm_size=0xf000000\0" \ "kernel_addr_r=0x42000000\0" \ "fdt_addr_r=0x43000000\0" \ - "scriptaddr=0x43100000\0" \ "pxefile_addr_r=0x43200000\0" \ "ramdisk_addr_r=0x43300000\0" @@ -372,6 +373,7 @@ #define CONFIG_EXTRA_ENV_SETTINGS \ CONSOLE_ENV_SETTINGS \ MEM_LAYOUT_ENV_SETTINGS \ + "bootcmd_fel=source ${scriptaddr}\0" \ "fdtfile=" CONFIG_FDTFILE "\0" \ "console=ttyS0,115200\0" \ BOOTENV
In order to fully support booting the whole system over USB OTG without relying on anything else (MMC, SATA, USB sticks, ...), it is possible to upload the 'boot.scr' file to DRAM using the 'fel' tool. But U-Boot still needs to be able to pick it up there before checking any other boot media. Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com> --- The patch might be not the best way to implement this. But it would be great if U-Boot had out of the box support for: http://linux-sunxi.org/index.php?title=FEL/USBBoot&oldid=13134#Boot_the_whole_system_over_USB_.28u-boot_.2B_kernel_.2B_initramfs.29 One of the bad things about this patch is that the "scriptaddr" variable needs to be hardcoded and protected agaist modifications (if this address is to be used from the SPL). Also I'm not sure how this all could fit into the "config_distro_bootcmd.h" model, so I even have not tried that yet. arch/arm/cpu/armv7/sunxi/board.c | 3 +++ board/sunxi/board.c | 16 ++++++++++++++++ include/configs/sunxi-common.h | 4 +++- 3 files changed, 22 insertions(+), 1 deletion(-)