Re: [U-Boot] [RFC PATCH] arm: bootm: Boot kernel with U-Boot's FDT blob

2017-01-10 Thread Jon Medhurst (Tixy) 
On Tue, 2017-01-10 at 18:34 +, Mark Rutland wrote:
> Looking at the git log for arch/arm64/boot/dts/arm, most updates are
> simply adding new descriptions, so a DTB from a year ago should work
> just fine with mainline (modulo the Juno PCI window issue, which was a
> DTB bug). Upgrading kernel shouldn't require a DTB upgrade to see
> equivalent functionality.

But if you want the new functionality in the kernel, why should you be
forced to wait for the bootloader to catch up (or do that work yourself)
then upgrade to that new bootloader version? And what about the poor
devs working on that new functionality, they're going to need to use not
upstream device-trees. Then there's all the firmware and system
configuration stuff that's in device-tree.

Basically, in the real world, devive-tree is a system configuration file
you need to hack to get all the pieces you're lumbered with to work
together and if you don't have control of it's contents you're stuffed.

(Well, we're stuffed anyway with the umpteen layers of
OSes/firmware/hypervisors all struggling for control of every computer
system.)

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

Re: [U-Boot] [PATCH v2] vexpress: disable cci ace slave ports when booting in non-sec/hyp mode

2016-09-26 Thread Jon Medhurst (Tixy) 
On Mon, 2016-09-26 at 13:38 +0100, Sudeep Holla wrote:
> 
> On 26/09/16 13:30, Jon Medhurst (Tixy) wrote:
> > On Fri, 2016-09-23 at 17:38 +0100, Sudeep Holla wrote:
> >> Commit f225d39d3093 ("vexpress: Check TC2 firmware support before 
> >> defaulting
> >> to nonsec booting") added support to check if the firmware on TC2  is
> >> configured appropriately before booting in nonsec/hyp mode.
> >>
> >> However when booting in non-secure/hyp mode, CCI control must be done in
> >> secure firmware and can't  be done in non-secure/hyp mode. In order to
> >> ensure that, this patch disables the cci slave port inteface so that it
> >> is not accessed at all.
> >>
> >> Cc: Jon Medhurst <t...@linaro.org>
> >> Acked-by: Marc Zyngier <marc.zyng...@arm.com>
> >> Signed-off-by: Sudeep Holla <sudeep.ho...@arm.com>
> >> ---
> >
> > Acked-by: Jon Medhurst <t...@linaro.org>
> > Tested-by: Jon Medhurst <t...@linaro.org>
> 
> So, can I assume the missing kernel patches to be reason for boot hang ?
> Just wanted to know if I need to investigate that any further ?

Sorry, yes they were the reason and no further investigation needed. I
remembered getting nonsec mode working some month's ago without such
patches, but I remember now that was by disabling MCPM in the kernel.

This morning I tried these U-Boot patches successfully with:
- Upstream vexpress_defconfig kernel booting with 'sec' mode
- That kernel with Lorenzo's patches in both 'sec' and 'nonsec'
- As above with CONFIG_BL_SWITCHER enabled

When booting in nonsec I also verified the device-tree modifications
made by this patch by seeing the following files existed and contained
the word 'disabled'...

/proc/device-tree/cci@2c09/slave-if@4000/status
/proc/device-tree/cci@2c09/slave-if@5000/status

-- 
Tixy

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

Re: [U-Boot] [PATCH v2] vexpress: disable cci ace slave ports when booting in non-sec/hyp mode

2016-09-26 Thread Jon Medhurst (Tixy) 
On Fri, 2016-09-23 at 17:38 +0100, Sudeep Holla wrote:
> Commit f225d39d3093 ("vexpress: Check TC2 firmware support before defaulting
> to nonsec booting") added support to check if the firmware on TC2  is
> configured appropriately before booting in nonsec/hyp mode.
> 
> However when booting in non-secure/hyp mode, CCI control must be done in
> secure firmware and can't  be done in non-secure/hyp mode. In order to
> ensure that, this patch disables the cci slave port inteface so that it
> is not accessed at all.
> 
> Cc: Jon Medhurst 
> Acked-by: Marc Zyngier 
> Signed-off-by: Sudeep Holla 
> ---

Acked-by: Jon Medhurst 
Tested-by: Jon Medhurst 

>  board/armltd/vexpress/vexpress_tc2.c | 52 
> 
>  configs/vexpress_ca15_tc2_defconfig  |  1 +
>  2 files changed, 53 insertions(+)
> 
> Hi,
> 
> This change is needed to avoid the kernel panic while attempting to access
> CCI ports when booting in non-sec/HYP mode. The kernel patches to fix
> this are available @[1]
> 
> Regards,
> Sudeep
> 
> v1->v2:
>   - Fix compilation with !CONFIG_ARMV7_NONSEC(Thanks to Tixy)
> 
> [1] http://www.spinics.net/lists/arm-kernel/msg533715.html
> 
> diff --git a/board/armltd/vexpress/vexpress_tc2.c 
> b/board/armltd/vexpress/vexpress_tc2.c
> index ebb41a8833ab..c7adf950f579 100644
> --- a/board/armltd/vexpress/vexpress_tc2.c
> +++ b/board/armltd/vexpress/vexpress_tc2.c
> @@ -7,7 +7,11 @@
>   * SPDX-License-Identifier:  GPL-2.0+
>   */
> 
> +#include 
>  #include 
> +#include 
> +#include 
> +#include 
> 
>  #define SCC_BASE 0x7fff
> 
> @@ -31,3 +35,51 @@ bool armv7_boot_nonsec_default(void)
>   return (readl((u32 *)(SCC_BASE + 0x700)) & ((1 << 12) | (1 << 13))) == 
> 0;
>  #endif
>  }
> +
> +#ifdef CONFIG_OF_BOARD_SETUP
> +int ft_board_setup(void *fdt, bd_t *bd)
> +{
> + int offset, tmp, len;
> + const struct fdt_property *prop;
> + const char *cci_compatible = "arm,cci-400-ctrl-if";
> +
> +#ifdef CONFIG_ARMV7_NONSEC
> + if (!armv7_boot_nonsec())
> + return 0;
> +#else
> + return 0;
> +#endif
> + /* Booting in nonsec mode, disable CCI access */
> + offset = fdt_path_offset(fdt, "/cpus");
> + if (offset < 0) {
> + printf("couldn't find /cpus\n");
> + return offset;
> + }
> +
> + /* delete cci-control-port in each cpu node */
> + for (tmp = fdt_first_subnode(fdt, offset); tmp >= 0;
> +  tmp = fdt_next_subnode(fdt, tmp))
> + fdt_delprop(fdt, tmp, "cci-control-port");
> +
> + /* disable all ace cci slave ports */
> + offset = fdt_node_offset_by_prop_value(fdt, offset, "compatible",
> +cci_compatible, 20);
> + while (offset > 0) {
> + prop = fdt_get_property(fdt, offset, "interface-type",
> + );
> + if (!prop)
> + continue;
> + if (len < 4)
> + continue;
> + if (strcmp(prop->data, "ace"))
> + continue;
> +
> + fdt_setprop_string(fdt, offset, "status", "disabled");
> +
> + offset = fdt_node_offset_by_prop_value(fdt, offset, 
> "compatible",
> +cci_compatible, 20);
> + }
> +
> + return 0;
> +}
> +#endif /* CONFIG_OF_BOARD_SETUP */
> diff --git a/configs/vexpress_ca15_tc2_defconfig 
> b/configs/vexpress_ca15_tc2_defconfig
> index 2f141dda06c6..5154803b7c65 100644
> --- a/configs/vexpress_ca15_tc2_defconfig
> +++ b/configs/vexpress_ca15_tc2_defconfig
> @@ -1,5 +1,6 @@
>  CONFIG_ARM=y
>  CONFIG_TARGET_VEXPRESS_CA15_TC2=y
> +CONFIG_OF_BOARD_SETUP=y
>  CONFIG_HUSH_PARSER=y
>  # CONFIG_CMD_CONSOLE is not set
>  # CONFIG_CMD_BOOTD is not set
> --
> 2.7.4
> 


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

Re: [U-Boot] [PATCH v2] vexpress: disable cci ace slave ports when booting in non-sec/hyp mode

2016-09-26 Thread Jon Medhurst (Tixy) 
On Fri, 2016-09-23 at 17:38 +0100, Sudeep Holla wrote:
> Commit f225d39d3093 ("vexpress: Check TC2 firmware support before defaulting
> to nonsec booting") added support to check if the firmware on TC2  is
> configured appropriately before booting in nonsec/hyp mode.
> 
> However when booting in non-secure/hyp mode, CCI control must be done in
> secure firmware and can't  be done in non-secure/hyp mode. In order to
> ensure that, this patch disables the cci slave port inteface so that it
> is not accessed at all.
> 
> Cc: Jon Medhurst 
> Acked-by: Marc Zyngier 
> Signed-off-by: Sudeep Holla 
> ---

This works for me (unsurprisingly) when booting in secure mode. What
kernel and firmware config do I need to use for non-sec mode? I tried
vexpress_defconfig, with bits 12 and 13 cleared in SCC: 0x700
but I get nothing out the console after "Starting kernel ..."

-- 
Tixy

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

Re: [U-Boot] [PATCH] vexpress: disable cci ace slave ports when booting in non-sec/hyp mode

2016-09-23 Thread Jon Medhurst (Tixy) 
On Fri, 2016-09-23 at 16:10 +0100, Sudeep Holla wrote:
> +#ifdef CONFIG_OF_BOARD_SETUP
> +int ft_board_setup(void *fdt, bd_t *bd)
> +{
> +   int offset, tmp, len;
> +   const struct fdt_property *prop;
> +   const char *cci_compatible = "arm,cci-400-ctrl-if";
> +
> +   if (!armv7_boot_nonsec_default())
> +   return 0; /* Do nothing */
> +

That's just testing the default not whether the board is actually going
to boot in nonsec (hyp) mode or not, which also also depends on
environment variables. So you probably want instead to call
armv7_boot_nonsec() here. That function only exists if
CONFIG_ARMV7_NONSEC is defined, so the 'if' statement above probably
wants to be something like...

#ifdef CONFIG_ARMV7_NONSEC
if (!armv7_boot_nonsec())
return 0;
#else
return 0;
#endif
/* We only get here if board will boot in nonsec mode */

-- 
Tixy

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

Re: [U-Boot] [U-Boot, RFC] vexpress: Check TC2 firmware support before defaulting to nonsec booting

2016-08-15 Thread Jon Medhurst (Tixy) 
On Sun, 2016-08-14 at 16:05 -0400, Tom Rini wrote:
> On Thu, Jun 23, 2016 at 01:37:32PM +0100, Jon Medhurst (Tixy) wrote:
> 
> > The firmware on TC2 needs to be configured appropriately before booting
> > in nonsec mode will work as expected, so test for this and fall back to
> > sec mode if required.
> > 
> > Signed-off-by: Jon Medhurst <t...@linaro.org>
> > Reviewed-by: Ryan Harkin <ryan.har...@linaro.org>
> > Tested-by: Ryan Harkin <ryan.har...@linaro.org>
> > ---
> > 
> > This is an implementation of Andre's suggestion in
> > http://lists.denx.de/pipermail/u-boot/2016-June/258873.html
> > 
> > Possibly the change to bootm.c should be in a separate patch?
> > 
> >  arch/arm/lib/bootm.c | 15 ++-
> >  board/armltd/vexpress/Makefile   |  1 +
> >  board/armltd/vexpress/vexpress_tc2.c | 33 +
> >  3 files changed, 44 insertions(+), 5 deletions(-)
> >  create mode 100644 board/armltd/vexpress/vexpress_tc2.c
> 
> So, this supersedes https://patchwork.ozlabs.org/patch/639232/ right?

Yes, it does.

Thanks

-- 
Tixy

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

[U-Boot] [RFC PATCH] vexpress: Check TC2 firmware support before defaulting to nonsec booting

2016-06-23 Thread Jon Medhurst (Tixy) 
The firmware on TC2 needs to be configured appropriately before booting
in nonsec mode will work as expected, so test for this and fall back to
sec mode if required.

Signed-off-by: Jon Medhurst 
---

This is an implementation of Andre's suggestion in
http://lists.denx.de/pipermail/u-boot/2016-June/258873.html

Possibly the change to bootm.c should be in a separate patch?

 arch/arm/lib/bootm.c | 15 ++-
 board/armltd/vexpress/Makefile   |  1 +
 board/armltd/vexpress/vexpress_tc2.c | 33 +
 3 files changed, 44 insertions(+), 5 deletions(-)
 create mode 100644 board/armltd/vexpress/vexpress_tc2.c

diff --git a/arch/arm/lib/bootm.c b/arch/arm/lib/bootm.c
index 0838d89..766a0c8 100644
--- a/arch/arm/lib/bootm.c
+++ b/arch/arm/lib/bootm.c
@@ -248,15 +248,20 @@ static void boot_prep_linux(bootm_headers_t *images)
}
 }
 
-#ifdef CONFIG_ARMV7_NONSEC
-bool armv7_boot_nonsec(void)
+__weak bool armv7_boot_nonsec_default(void)
 {
-   char *s = getenv("bootm_boot_mode");
 #ifdef CONFIG_ARMV7_BOOT_SEC_DEFAULT
-   bool nonsec = false;
+   return false;
 #else
-   bool nonsec = true;
+   return true;
 #endif
+}
+
+#ifdef CONFIG_ARMV7_NONSEC
+bool armv7_boot_nonsec(void)
+{
+   char *s = getenv("bootm_boot_mode");
+   bool nonsec = armv7_boot_nonsec_default();
 
if (s && !strcmp(s, "sec"))
nonsec = false;
diff --git a/board/armltd/vexpress/Makefile b/board/armltd/vexpress/Makefile
index 1dd6780..95f4ec0 100644
--- a/board/armltd/vexpress/Makefile
+++ b/board/armltd/vexpress/Makefile
@@ -6,3 +6,4 @@
 #
 
 obj-y  := vexpress_common.o
+obj-$(CONFIG_TARGET_VEXPRESS_CA15_TC2) += vexpress_tc2.o
diff --git a/board/armltd/vexpress/vexpress_tc2.c 
b/board/armltd/vexpress/vexpress_tc2.c
new file mode 100644
index 000..f00a83c
--- /dev/null
+++ b/board/armltd/vexpress/vexpress_tc2.c
@@ -0,0 +1,33 @@
+/*
+ * (C) Copyright 2016 Linaro
+ * Jon Medhurst 
+ *
+ * TC2 specific code for Versatile Express.
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include 
+
+#define SCC_BASE   0x7fff
+
+bool armv7_boot_nonsec_default(void)
+{
+#ifdef CONFIG_ARMV7_BOOT_SEC_DEFAULT
+   return false
+#else
+   /*
+* The Serial Configuration Controller (SCC) register at address 0x700
+* contains flags for configuring the behaviour of the Boot Monitor
+* (which CPUs execute from reset). Two of these bits are of interest:
+*
+* bit 12 = Use per-cpu mailboxes for power management
+* bit 13 = Power down the non-boot cluster
+*
+* It is only when both of these are false that U-Boot's current
+* implementation of 'nonsec' mode can work as expected because we
+* rely on getting all CPUs to execute _nonsec_init, so let's check 
that.
+*/
+   return (readl((u32 *)(SCC_BASE + 0x700)) & ((1 << 12) | (1 << 13))) == 
0;
+#endif
+}
-- 
2.1.4


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

Re: [U-Boot] [PATCH] ARM: vexpress: Remove virt and nonsec support for TC2

2016-06-22 Thread Jon Medhurst (Tixy) 
On Wed, 2016-06-22 at 15:53 +0100, Andre Przywara wrote:
> Hi,
> 
> On 22/06/16 15:34, Jon Medhurst (Tixy) wrote:
> > When CPU's come out of reset they are in secure state supervisor mode,
> > so this is the state Linux kernel entry point is called in when it
> > brings up secondary CPU cores or the primary CPU restarts after power
> > management has sent it through an off/on transition.
> > 
> > As U-Boot starts the kernel in hypervisor mode and the kernel expects
> > and checks that CPUs start in the same state as initial boot this
> > results in a dead system. Specifically, it crashes early in boot when
> > the primary CPU runs the MCPM test [1] and even if power management
> > features are disabled it will still refuse to bring up any secondary
> > CPUs.
> > 
> > Fix this problem by removing U-Boot support for virt and nonsec
> > support on TC2.
> 
> So this disables any kind of virtualization support for TC2, which is a
> bit unfortunate.
> If I get this (and Sudeep's explanations) correctly, this new behaviour
> comes from the per-CPU-mailboxes setting in SCC 0x700, which is a
> setting in boot.txt on the uSD card.

Right, so I got the current U-Boot to boot Linux OK with all CPU's
coming up in hyp mode by:

- Clearing bits 12 and 13 in SCC 0x700 to disable per-cpu mailboxes and
  keep the secondary CPU powered up.

- Removing kernel configs
CONFIG_ARCH_VEXPRESS_TC2_PM
CONFIG_MCPM

I believe this works because the SCC change means that all CPU will be
running and waiting in the bootmonitor holding pen, from which they are
released when U-Boot calls smp_set_core_boot_addr. These secondary CPUs
then execute U-Boot code to switch to hypervisor mode, then enter a new
holding pen. (Running in RAM that can't get overwritten by Linux I hope!
)

Then when kernel boots and releases cores from holding pen they are in
hyp mode, like the main CPU. As we've also disabled power management in
the kernel, CPU's aren't ever powered down again and so stay in hyp
mode.

Actually, I just tried hotplugging a CPU which obviously the kernel
didn't like, so there is probably other kernel configs that need
tweaking to make things work.

> I wonder if we could make this virt/secure support a runtime decision
> then based on that register?
> So that a user can select whether she wants virtualisation or power
> management by changing the boot.txt setting and U-Boot transparently
> adapts to it, entering the kernel in either secure SVC or HYP.
>
> Does that make sense?
> I can look into a fix if this approach is fine.

Anything that gets U-Boot in it's default config working with vexpress
firmware and Linux kernel in their default config would be good
start :-)

I'm not sure that having an automatic selection in U-Boot is worth it,
given that anyone booting in hyp mode also needs to modify the firmware
and kernel configs to get things working. But I wouldn't object to such
an automatic selection either. After all, it's not like anyone really
uses or cares about this stuff, and if they are, they probably have
there own customised setup rather than using upstream defaults.

-- 
Tixy

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

[U-Boot] [PATCH] ARM: vexpress: Remove virt and nonsec support for TC2

2016-06-22 Thread Jon Medhurst (Tixy) 
When CPU's come out of reset they are in secure state supervisor mode,
so this is the state Linux kernel entry point is called in when it
brings up secondary CPU cores or the primary CPU restarts after power
management has sent it through an off/on transition.

As U-Boot starts the kernel in hypervisor mode and the kernel expects
and checks that CPUs start in the same state as initial boot this
results in a dead system. Specifically, it crashes early in boot when
the primary CPU runs the MCPM test [1] and even if power management
features are disabled it will still refuse to bring up any secondary
CPUs.

Fix this problem by removing U-Boot support for virt and nonsec
support on TC2.

[1] 
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=3592d7e002438980f9ce4a399f21ec94cbf071ea

Signed-off-by: Jon Medhurst 
---
 arch/arm/Kconfig|  2 --
 board/armltd/vexpress/vexpress_common.c | 15 ---
 2 files changed, 17 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index e9d2fc9..2e48568 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -293,8 +293,6 @@ config ARCH_BCM283X
 config TARGET_VEXPRESS_CA15_TC2
bool "Support vexpress_ca15_tc2"
select CPU_V7
-   select CPU_V7_HAS_NONSEC
-   select CPU_V7_HAS_VIRT
 
 config TARGET_VEXPRESS_CA5X2
bool "Support vexpress_ca5x2"
diff --git a/board/armltd/vexpress/vexpress_common.c 
b/board/armltd/vexpress/vexpress_common.c
index d3b3b31..fe5d163 100644
--- a/board/armltd/vexpress/vexpress_common.c
+++ b/board/armltd/vexpress/vexpress_common.c
@@ -180,18 +180,3 @@ void lowlevel_init(void)
 ulong get_board_rev(void){
return readl((u32 *)SYS_ID);
 }
-
-#ifdef CONFIG_ARMV7_NONSEC
-/* Setting the address at which secondary cores start from.
- * Versatile Express uses one address for all cores, so ignore corenr
- */
-void smp_set_core_boot_addr(unsigned long addr, int corenr)
-{
-   /* The SYSFLAGS register on VExpress needs to be cleared first
-* by writing to the next address, since any writes to the address
-* at offset 0 will only be ORed in
-*/
-   writel(~0, CONFIG_SYSFLAGS_ADDR + 4);
-   writel(addr, CONFIG_SYSFLAGS_ADDR);
-}
-#endif
-- 
2.1.4



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

Re: [U-Boot] ARM: vexpress: Extend default boot sequence to load script from MMC

2011-11-30 Thread Jon Medhurst (Tixy) 
On Tue, 2011-11-29 at 13:46 -0700, Tom Rini wrote:
 On Tue, Nov 29, 2011 at 6:46 AM, Jon Medhurst (Tixy)
 jon.medhu...@linaro.org wrote:
  Extend the default boot sequence on Versatile Express to load a boot
  script from MMC.
 
  Signed-off-by: Jon Medhurst jon.medhu...@linaro.org
 
 Is there any interest in defining a common 'fancy' boot command?  Over
 on beagleboard (and a few other eval boards) we are (or will be)
 doing, roughly:
 Is there mmc? {
   Can we load a bootscript? {
 load it, do it
   }
   Can we load uEnv.txt? {
 Did it set 'uenvcmd'? {
   Run it
 }
   }
   Did we load the kernel? {
 bootm it
   }
 }
 Try nand.
 
 And it's not hard to replace NAND with whatever flash the board sets

It could make sense. However, the combinations of boot methods could get
quite big, e.g. do we include pxeboot, tftp?

If everything was included in the common 'fancy boot' then some boards
would have to define boot methods (or stubs) for things they weren't
interested in. And, conversely, if fancy boot didn't include everything,
then other people would need to extend it. 

I came across this issue with my patch. I wanted to look for a common
pattern to copy for my boot command. I was tempted by those which
included other options but then realised we didn't currently have a use
for them, and if I added them there would be more testing and
maintenance required.

So perhaps the number of boards interested in the common function would
be very small?

-- 
Tixy

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

Re: [U-Boot] ARM: vexpress: Extend default boot sequence to load script from MMC

2011-11-30 Thread Jon Medhurst (Tixy) 
On Wed, 2011-11-30 at 07:51 -0700, Tom Rini wrote:
 On Wed, Nov 30, 2011 at 1:32 AM, Jon Medhurst (Tixy)
 jon.medhu...@linaro.org wrote:
  On Tue, 2011-11-29 at 13:46 -0700, Tom Rini wrote:
  On Tue, Nov 29, 2011 at 6:46 AM, Jon Medhurst (Tixy)
  jon.medhu...@linaro.org wrote:
   Extend the default boot sequence on Versatile Express to load a boot
   script from MMC.
  
   Signed-off-by: Jon Medhurst jon.medhu...@linaro.org
 
  Is there any interest in defining a common 'fancy' boot command?  Over
  on beagleboard (and a few other eval boards) we are (or will be)
  doing, roughly:
  Is there mmc? {
Can we load a bootscript? {
  load it, do it
}
Can we load uEnv.txt? {
  Did it set 'uenvcmd'? {
Run it
  }
}
Did we load the kernel? {
  bootm it
}
  }
  Try nand.
 
  And it's not hard to replace NAND with whatever flash the board sets
 
  It could make sense. However, the combinations of boot methods could get
  quite big, e.g. do we include pxeboot, tftp?
 
 Well, maybe we define some blocks (TRY_MMC, TRY_ENET, TRY_NAND,
 TRY_SPI, ...) ...
 
  If everything was included in the common 'fancy boot' then some boards
  would have to define boot methods (or stubs) for things they weren't
  interested in. And, conversely, if fancy boot didn't include everything,
  then other people would need to extend it.
 
 ... provide a few examples of the blocks strung together and have
 people string up what they need themselves, so long as it's an
 otherwise good idea to have complex default boot methods?

If something like this was planned for BeagleBoard anyway, then perhaps
it could written in terms of these TRY_MMC etc. macros (which seem like
a reasonable idea to me). Then a working prototype could be posted as an
RFC for others to comment on? I suspect at the moment there's not many
people reading this 'vexpress' thread ;-)

-- 
Tixy

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

[U-Boot] ARM: vexpress: Extend default boot sequence to load script from MMC

2011-11-29 Thread Jon Medhurst (Tixy) 
Extend the default boot sequence on Versatile Express to load a boot
script from MMC.

Signed-off-by: Jon Medhurst jon.medhu...@linaro.org

---
 include/configs/vexpress_common.h |   20 ++--
 1 files changed, 18 insertions(+), 2 deletions(-)

diff --git a/include/configs/vexpress_common.h 
b/include/configs/vexpress_common.h
index a4ae5a8..d56f19d 100644
--- a/include/configs/vexpress_common.h
+++ b/include/configs/vexpress_common.h
@@ -178,6 +178,8 @@
 #define CONFIG_CMD_SAVEENV
 #define CONFIG_NET_MULTI
 #define CONFIG_CMD_RUN
+#define CONFIG_CMD_BOOTD
+#define CONFIG_CMD_ECHO
 
 #define CONFIG_CMD_FAT
 #define CONFIG_DOS_PARTITION   1
@@ -226,7 +228,14 @@
 #define CONFIG_SYS_INIT_SP_ADDRCONFIG_SYS_GBL_DATA_OFFSET
 
 /* Basic environment settings */
-#define CONFIG_BOOTCOMMAND run bootflash;
+#define CONFIG_BOOTCOMMAND \
+   if mmc rescan ${mmcdev}; then  \
+   if run loadbootscript; then  \
+   run bootscript;  \
+   fi;  \
+   fi;  \
+   run bootflash;
+
 #ifdef CONFIG_VEXPRESS_ORIGINAL_MEMORY_MAP
 #define CONFIG_PLATFORM_ENV_SETTINGS \
loadaddr=0x80008000\0 \
@@ -258,7 +267,12 @@
devtmpfs.mount=0  vmalloc=256M\0 \
bootflash=run flashargs;  \
cp ${ramdisk_addr} ${ramdisk_addr_r} ${maxramdisk};  \
-   bootm ${kernel_addr} ${ramdisk_addr_r}\0
+   bootm ${kernel_addr} ${ramdisk_addr_r}\0 \
+   mmcdev=0\0 \
+   bootscr=boot.scr\0 \
+   loadbootscript=fatload mmc ${mmcdev} ${loadaddr} ${bootscr}\0 
\
+   bootscript=echo Running bootscript from mmc ...;  \
+   source ${loadaddr}\0
 
 /* FLASH and environment organization */
 #define PHYS_FLASH_SIZE0x0400  /* 64MB */
@@ -305,6 +319,8 @@
 #define CONFIG_SYS_PROMPT  VExpress# 
 #define CONFIG_SYS_PBSIZE  (CONFIG_SYS_CBSIZE + \
sizeof(CONFIG_SYS_PROMPT) + 16)
+#define CONFIG_SYS_HUSH_PARSER
+#define CONFIG_SYS_PROMPT_HUSH_PS2  
 #define CONFIG_SYS_BARGSIZECONFIG_SYS_CBSIZE /* Boot args buffer */
 #define CONFIG_CMD_SOURCE
 #define CONFIG_SYS_LONGHELP
-- 
1.7.4.1



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

[U-Boot] [PATCH v2] MMC: PL180: Fix infinite loop with VExpress extended fifo implementation

2011-11-04 Thread Jon Medhurst (Tixy) 
The new IO FPGA implementation for Versatile Express contains an MMCI
(PL180) cell with the FIFO extended to 128 words. This causes the
read_bytes() function to go into an infinite loop; as it will wait for
for the half-full signal (SDI_STA_RXFIFOBR) if there are more than 8
words remaining (SDI_FIFO_BURST_SIZE), but it won't receive this signal
once there are fewer than 64 words left to transfer.

One possible fix is to add some build time configuration to change
SDI_FIFO_BURST_SIZE for the new implementation. However, the problematic
code only seems to exist as a small performance optimisation, so the
solution implemented by this patch is to simply remove it. The error
checking following the loop is also removed as this will be handled by
code further down the function.

Cc: Andy Fleming aflem...@gmail.com
Signed-off-by: Jon Medhurst jon.medhu...@linaro.org
---

Changes for version 2
- Fix broken whitespace in patch

---
 drivers/mmc/arm_pl180_mmci.c |   26 --
 1 files changed, 0 insertions(+), 26 deletions(-)

diff --git a/drivers/mmc/arm_pl180_mmci.c b/drivers/mmc/arm_pl180_mmci.c
index ed296ee..e6467a2 100644
--- a/drivers/mmc/arm_pl180_mmci.c
+++ b/drivers/mmc/arm_pl180_mmci.c
@@ -111,7 +111,6 @@ static int do_command(struct mmc *dev, struct mmc_cmd *cmd)
 static int read_bytes(struct mmc *dev, u32 *dest, u32 blkcount, u32 blksize)
 {
u32 *tempbuff = dest;
-   int i;
u64 xfercount = blkcount * blksize;
struct mmc_host *host = dev-priv;
u32 status, status_err;
@@ -121,31 +120,6 @@ static int read_bytes(struct mmc *dev, u32 *dest, u32 
blkcount, u32 blksize)
status = readl(host-base-status);
status_err = status  (SDI_STA_DCRCFAIL | SDI_STA_DTIMEOUT |
   SDI_STA_RXOVERR);
-   while (!status_err 
-  (xfercount = SDI_FIFO_BURST_SIZE * sizeof(u32))) {
-   if (status  SDI_STA_RXFIFOBR) {
-   for (i = 0; i  SDI_FIFO_BURST_SIZE; i++)
-   *(tempbuff + i) = readl(host-base-fifo);
-   tempbuff += SDI_FIFO_BURST_SIZE;
-   xfercount -= SDI_FIFO_BURST_SIZE * sizeof(u32);
-   }
-   status = readl(host-base-status);
-   status_err = status 
-   (SDI_STA_DCRCFAIL | SDI_STA_DTIMEOUT | SDI_STA_RXOVERR);
-   }
-
-   if (status  SDI_STA_DTIMEOUT) {
-   printf(Read data timed out, xfercount: %llu, status: 0x%08X\n,
-   xfercount, status);
-   return -ETIMEDOUT;
-   } else if (status  SDI_STA_DCRCFAIL) {
-   printf(Read data blk CRC error: 0x%x\n, status);
-   return -EILSEQ;
-   } else if (status  SDI_STA_RXOVERR) {
-   printf(Read data RX overflow error\n);
-   return -EIO;
-   }
-
while ((!status_err)  (xfercount = sizeof(u32))) {
if (status  SDI_STA_RXDAVL) {
*(tempbuff) = readl(host-base-fifo);
-- 
1.7.4.1



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

Re: [U-Boot] [PATCH] MMC: PL180: Fix infinite loop with VExpress extended fifo implementation

2011-10-05 Thread Jon Medhurst (Tixy) 
On Wed, 2011-10-05 at 10:30 +0100, Pawel Moll wrote:
 Hi Tixy,
 
  One possible fix is to add some build time configuration to change
  SDI_FIFO_BURST_SIZE for the new implementation. 
 
 You can also detect the configuration in runtime, basing on PeriphID:
 
 http://infocenter.arm.com/help/topic/com.arm.doc.ddi0172a/i1024149.html
 
 Configuration == 0 (ID == 0x00041180) - FIFO length = 16 * 4
 Configuration == 1 (ID == 0x01041180) - FIFO length = 128 * 4

That's useful to know. The PL180 code is also used for U8500, I don't
know if that implements the peripheral ID register; though I guess any
probing could be limited to vexpress anyway.

However, I think that if smaller and simpler code will work on all
hardware then that is preferable.

-- 
Tixy

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

Re: [U-Boot] [PATCH] MMC: PL180: Fix infinite loop with VExpress extended fifo implementation

2011-10-05 Thread Jon Medhurst (Tixy) 
On Wed, 2011-10-05 at 10:58 +0100, Pawel Moll wrote:
  That's useful to know. The PL180 code is also used for U8500, I don't
  know if that implements the peripheral ID register; though I guess any
  probing could be limited to vexpress anyway.
 
 STE have the same problems with FIFO size, see drivers/mmc/host/mmci.c
 in kernel sources:

Yes, and my proposed fix for U-Boot will work with them all because it
removes a dependency on the fifo size.

-- 
Tixy

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

[U-Boot] [PATCH] MMC: PL180: Fix infinite loop with VExpress extended fifo implementation

2011-10-04 Thread Jon Medhurst (Tixy) 
From: Jon Medhurst jon.medhu...@linaro.org

The new IO FPGA implementation for Versatile Express contains an MMCI
(PL180) cell with the FIFO extended to 128 words. This causes the
read_bytes() function to go into an infinite loop; as it will wait for
for the half-full signal (SDI_STA_RXFIFOBR) if there are more than 8
words remaining (SDI_FIFO_BURST_SIZE), but it won't receive this signal
once there are fewer than 64 words left to transfer.

One possible fix is to add some build time configuration to change
SDI_FIFO_BURST_SIZE for the new implementation. However, the problematic
code only seems to exist as a small performance optimisation, so the
solution implemented by this patch is to simply remove it. The error
checking following the loop is also removed as this will be handled by
code further down the function.

Cc: Andy Fleming aflem...@gmail.com
Signed-off-by: Jon Medhurst jon.medhu...@linaro.org
---

If it is desirable to keep the burst read optimisation, then an
alternative solution would be to keep the loop and add an if clause to
do a single read if the fifo doesn't have enough for a burst.

---
 drivers/mmc/arm_pl180_mmci.c |   26 --
 1 files changed, 0 insertions(+), 26 deletions(-)

diff --git a/drivers/mmc/arm_pl180_mmci.c b/drivers/mmc/arm_pl180_mmci.c
index ed296ee..e6467a2 100644
--- a/drivers/mmc/arm_pl180_mmci.c
+++ b/drivers/mmc/arm_pl180_mmci.c
@@ -111,7 +111,6 @@ static int do_command(struct mmc *dev, struct mmc_cmd *cmd)
 static int read_bytes(struct mmc *dev, u32 *dest, u32 blkcount, u32 blksize)
 {
u32 *tempbuff = dest;
-   int i;
u64 xfercount = blkcount * blksize;
struct mmc_host *host = dev-priv;
u32 status, status_err;
@@ -121,31 +120,6 @@ static int read_bytes(struct mmc *dev, u32 *dest, u32 
blkcount, u32 blksize)
status = readl(host-base-status);
status_err = status  (SDI_STA_DCRCFAIL | SDI_STA_DTIMEOUT |
   SDI_STA_RXOVERR);
-   while (!status_err 
-  (xfercount = SDI_FIFO_BURST_SIZE * sizeof(u32))) {
-   if (status  SDI_STA_RXFIFOBR) {
-   for (i = 0; i  SDI_FIFO_BURST_SIZE; i++)
-   *(tempbuff + i) = readl(host-base-fifo);
-   tempbuff += SDI_FIFO_BURST_SIZE;
-   xfercount -= SDI_FIFO_BURST_SIZE * sizeof(u32);
-   }
-   status = readl(host-base-status);
-   status_err = status 
-   (SDI_STA_DCRCFAIL | SDI_STA_DTIMEOUT | SDI_STA_RXOVERR);
-   }
-
-   if (status  SDI_STA_DTIMEOUT) {
-   printf(Read data timed out, xfercount: %llu, status: 0x%08X\n,
-   xfercount, status);
-   return -ETIMEDOUT;
-   } else if (status  SDI_STA_DCRCFAIL) {
-   printf(Read data blk CRC error: 0x%x\n, status);
-   return -EILSEQ;
-   } else if (status  SDI_STA_RXOVERR) {
-   printf(Read data RX overflow error\n);
-   return -EIO;
-   }
-
while ((!status_err)  (xfercount = sizeof(u32))) {
if (status  SDI_STA_RXDAVL) {
*(tempbuff) = readl(host-base-fifo);
-- 
1.7.4.1


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