Re: [U-Boot] [RFC] sunxi: Support uploading 'boot.scr' to RAM over USB OTG in FEL mode

2015-03-04 Thread Ian Campbell 
On Wed, 2015-03-04 at 16:18 +0200, Siarhei Siamashka wrote:
 On Tue, 03 Mar 2015 08:31:17 +
 Ian Campbell ijc+ub...@hellion.org.uk wrote:
 
  On Sun, 2015-03-01 at 23:37 +0200, Siarhei Siamashka wrote:
   On Fri, 27 Feb 2015 16:39:45 +
   Ian Campbell ijc+ub...@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.siamas...@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/USBBootoldid=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 0x4310 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.

Re: [U-Boot] [RFC] sunxi: Support uploading 'boot.scr' to RAM over USB OTG in FEL mode

2015-03-04 Thread Siarhei Siamashka 
On Tue, 03 Mar 2015 08:31:17 +
Ian Campbell ijc+ub...@hellion.org.uk wrote:

 On Sun, 2015-03-01 at 23:37 +0200, Siarhei Siamashka wrote:
  On Fri, 27 Feb 2015 16:39:45 +
  Ian Campbell ijc+ub...@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.siamas...@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/USBBootoldid=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 0x4310 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

Re: [U-Boot] [RFC] sunxi: Support uploading 'boot.scr' to RAM over USB OTG in FEL mode

2015-03-03 Thread Ian Campbell 
On Sun, 2015-03-01 at 23:37 +0200, Siarhei Siamashka wrote:
 On Fri, 27 Feb 2015 16:39:45 +
 Ian Campbell ijc+ub...@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.siamas...@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/USBBootoldid=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 0x4310 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

Re: [U-Boot] [RFC] sunxi: Support uploading 'boot.scr' to RAM over USB OTG in FEL mode

2015-03-01 Thread Siarhei Siamashka 
On Fri, 27 Feb 2015 16:39:45 +
Ian Campbell ijc+ub...@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.siamas...@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/USBBootoldid=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 0x4310 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.

-- 
Best regards,
Siarhei Siamashka
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [RFC] sunxi: Support uploading 'boot.scr' to RAM over USB OTG in FEL mode

2015-03-01 Thread Ian Campbell 
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.siamas...@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/USBBootoldid=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 0x4310 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.

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [RFC] sunxi: Support uploading 'boot.scr' to RAM over USB OTG in FEL mode

2015-02-23 Thread Siarhei Siamashka 
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.siamas...@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/USBBootoldid=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(-)

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 0x4310
+
 #ifndef CONFIG_SPL_BUILD
 #include config_distro_defaults.h
 
@@ -315,7 +317,6 @@
bootm_size=0xf00\0 \
kernel_addr_r=0x4200\0 \
fdt_addr_r=0x4300\0 \
-   scriptaddr=0x4310\0 \
pxefile_addr_r=0x4320\0 \
ramdisk_addr_r=0x4330\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
-- 
2.0.5

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot