[PATCH v3 0/7] Arm Juno board OF_CONTROL upgrade
Hi,
another small update, fixing the Raspberry Pi breakage from the previous version. Only patch 2/7 has changed. I added Linus' Reviewed-by: to patch 7/7 and dropped Simon's R-b: to patch 2/7, because of the changes.
Cheers, Andre
------------ The Juno port in U-Boot didn't see much love lately, so it has fallen a bit behind. We already get a build warning for using an old network driver, but there is more: - The port is using hardcoded information, even though we have quite decent DTs available to find things at runtime. - There is no support for USB or PCI, which pretty much limits the board to load a kernel from flash (yuck!) or TFTP (at least!). - Probably because of this, newer features like UEFI support don't work properly. - There are minor things like less-than-ideal default load addresses and missing reset support.
This series is the first part of fixing this. The main part is to switch the board port to use OF_CONTROL, so U-Boot will use a DT to configure itself at runtime. This requires some update to the PL011 driver first (patch 2/7), and allows us to simply enable USB in the defconfig (patch 6/7). USB requires two "usb reset" calls after the initial "usb start" to recognise any devices, not sure why this is. But eventually I am able to load grub from a USB hard drive and do a full featured Ubuntu UEFI boot from there (with a distro kernel).
Patches 1, 3, and 7 are mere fixes, patch 4/7 does the actual OF_CONTROL conversion.
I also have some proper DM_PCI compliant driver in an advanced state, which allows to load from a SATA hard disk. Unfortunately there is no sky2 network driver in U-Boot, so the Gigabit Ethernet chip connected to PCI will not work easily. I will post this once this is cleaned up and tested.
Converting the smc network driver to DM_ETH is on my list as well, but the code is shared with some U-Boot *application* code, also used by some PowerPC boards, so that's not really a low hanging fruit. But it would remove the deprecation warning.
Cheers, Andre
Changelog v2 ... v3: - cope with platforms not defining CONFIG_PL011_CLOCK
Changelog v1 ... v2: - drop fdt_high and initrd_high variables - rename initrd_addr to ramdisk_addr_r
P.S. In case you want to test this without flashing it, you can chainload U-Boot from an existing U-Boot installation: $ mkimage -A arm64 -O u-boot -T standalone -C none -a 0xe0000000 -e 0xe0000000 -d u-boot.bin -n U-Boot /srv/tftp/u-boot-juno.img VExpress64# tftpboot 0xe0000000 u-boot-juno.img VExpress64# bootm
Andre Przywara (7): arm: juno: Fix Juno address variables uart: pl011: Add proper DM clock support arm: juno: Fix UART clock rate arm: juno: Enable OF_CONTROL arm: juno: Use PSCI based reset arm: juno: enable USB arm: vexpress64: Remove unneeded CONFIG_ check
arch/arm/Kconfig | 11 +++++ board/armltd/vexpress64/Kconfig | 7 +++ board/armltd/vexpress64/vexpress64.c | 61 ++++++++++++++++++++++++-- configs/vexpress_aemv8a_juno_defconfig | 9 ++-- drivers/serial/serial_pl01x.c | 47 +++++++++++++------- include/configs/vexpress_aemv8a.h | 41 ++++++++--------- 6 files changed, 132 insertions(+), 44 deletions(-)
The U-Boot documentation explains that variables ending with "_r" hold addresses in DRAM, while those without that ending point to flash/ROM. The default variables for the Juno board pointing to the kernel and DTB load addresses were not complying with this scheme: they lack the extension, but point to DRAM. This is particularly confusing since the Juno board features parallel NOR flash, so there *is* a memory mapped NOR address holding a DTB, for instance.
Fix the variables to use the proper names, changing initrd_addr to ramdisk_addr_r on the way, which seems to be more prevelant and documented. On the way adjust the FDT load address to be situated *before* the kernel, since users happened to overwrite the DTB by the kernel clearing its .BSS section during initialisation. Also remove the fdt_high and initrd_high variables (which were set to -1), to allow U-Boot moving those images around.
This should avoid many problems in the future, but breaks loading Linux kernels < v4.2, since they expect the DTB to be loaded in the same 512MB region as the kernel. If you need to load such an old kernel, please set fdt_high to either 0xffffffffffffffff or 0xa0000000 (if you load the kernel to the beginning of DRAM).
That fixes loading debug kernels, which happened to overwrite the DTB on certain setups.
Signed-off-by: Andre Przywara andre.przywara@arm.com --- include/configs/vexpress_aemv8a.h | 28 +++++++++++++--------------- 1 file changed, 13 insertions(+), 15 deletions(-)
diff --git a/include/configs/vexpress_aemv8a.h b/include/configs/vexpress_aemv8a.h index 4f3a792f49..6f81760612 100644 --- a/include/configs/vexpress_aemv8a.h +++ b/include/configs/vexpress_aemv8a.h @@ -138,35 +138,33 @@ #define CONFIG_EXTRA_ENV_SETTINGS \ "kernel_name=norkern\0" \ "kernel_alt_name=Image\0" \ - "kernel_addr=0x80080000\0" \ - "initrd_name=ramdisk.img\0" \ - "initrd_addr=0x84000000\0" \ + "kernel_addr_r=0x80080000\0" \ + "ramdisk_name=ramdisk.img\0" \ + "ramdisk_addr_r=0x88000000\0" \ "fdtfile=board.dtb\0" \ "fdt_alt_name=juno\0" \ - "fdt_addr=0x83000000\0" \ - "fdt_high=0xffffffffffffffff\0" \ - "initrd_high=0xffffffffffffffff\0" \ + "fdt_addr_r=0x80000000\0" \
/* Copy the kernel and FDT to DRAM memory and boot */ -#define CONFIG_BOOTCOMMAND "afs load ${kernel_name} ${kernel_addr} ; " \ +#define CONFIG_BOOTCOMMAND "afs load ${kernel_name} ${kernel_addr_r} ;"\ "if test $? -eq 1; then "\ " echo Loading ${kernel_alt_name} instead of "\ "${kernel_name}; "\ - " afs load ${kernel_alt_name} ${kernel_addr};"\ + " afs load ${kernel_alt_name} ${kernel_addr_r};"\ "fi ; "\ - "afs load ${fdtfile} ${fdt_addr} ; " \ + "afs load ${fdtfile} ${fdt_addr_r} ;"\ "if test $? -eq 1; then "\ " echo Loading ${fdt_alt_name} instead of "\ "${fdtfile}; "\ - " afs load ${fdt_alt_name} ${fdt_addr}; "\ + " afs load ${fdt_alt_name} ${fdt_addr_r}; "\ "fi ; "\ - "fdt addr ${fdt_addr}; fdt resize; " \ - "if afs load ${initrd_name} ${initrd_addr} ; "\ + "fdt addr ${fdt_addr_r}; fdt resize; " \ + "if afs load ${ramdisk_name} ${ramdisk_addr_r} ; "\ "then "\ - " setenv initrd_param ${initrd_addr}; "\ - " else setenv initrd_param -; "\ + " setenv ramdisk_param ${ramdisk_addr_r}; "\ + " else setenv ramdisk_param -; "\ "fi ; " \ - "booti ${kernel_addr} ${initrd_param} ${fdt_addr}" + "booti ${kernel_addr_r} ${ramdisk_param} ${fdt_addr_r}"
#elif CONFIG_TARGET_VEXPRESS64_BASE_FVP
On Mon, 27 Apr 2020 at 12:18, Andre Przywara andre.przywara@arm.com wrote:
The U-Boot documentation explains that variables ending with "_r" hold addresses in DRAM, while those without that ending point to flash/ROM. The default variables for the Juno board pointing to the kernel and DTB load addresses were not complying with this scheme: they lack the extension, but point to DRAM. This is particularly confusing since the Juno board features parallel NOR flash, so there *is* a memory mapped NOR address holding a DTB, for instance.
Fix the variables to use the proper names, changing initrd_addr to ramdisk_addr_r on the way, which seems to be more prevelant and documented. On the way adjust the FDT load address to be situated *before* the kernel, since users happened to overwrite the DTB by the kernel clearing its .BSS section during initialisation. Also remove the fdt_high and initrd_high variables (which were set to -1), to allow U-Boot moving those images around.
This should avoid many problems in the future, but breaks loading Linux kernels < v4.2, since they expect the DTB to be loaded in the same 512MB region as the kernel. If you need to load such an old kernel, please set fdt_high to either 0xffffffffffffffff or 0xa0000000 (if you load the kernel to the beginning of DRAM).
That fixes loading debug kernels, which happened to overwrite the DTB on certain setups.
Signed-off-by: Andre Przywara andre.przywara@arm.com
include/configs/vexpress_aemv8a.h | 28 +++++++++++++--------------- 1 file changed, 13 insertions(+), 15 deletions(-)
Reviewed-by: Simon Glass sjg@chromium.org
On Mon, Apr 27, 2020 at 07:17:58PM +0100, Andre Przywara wrote:
The U-Boot documentation explains that variables ending with "_r" hold addresses in DRAM, while those without that ending point to flash/ROM. The default variables for the Juno board pointing to the kernel and DTB load addresses were not complying with this scheme: they lack the extension, but point to DRAM. This is particularly confusing since the Juno board features parallel NOR flash, so there *is* a memory mapped NOR address holding a DTB, for instance.
Fix the variables to use the proper names, changing initrd_addr to ramdisk_addr_r on the way, which seems to be more prevelant and documented. On the way adjust the FDT load address to be situated *before* the kernel, since users happened to overwrite the DTB by the kernel clearing its .BSS section during initialisation. Also remove the fdt_high and initrd_high variables (which were set to -1), to allow U-Boot moving those images around.
This should avoid many problems in the future, but breaks loading Linux kernels < v4.2, since they expect the DTB to be loaded in the same 512MB region as the kernel. If you need to load such an old kernel, please set fdt_high to either 0xffffffffffffffff or 0xa0000000 (if you load the kernel to the beginning of DRAM).
That fixes loading debug kernels, which happened to overwrite the DTB on certain setups.
Signed-off-by: Andre Przywara andre.przywara@arm.com Reviewed-by: Simon Glass sjg@chromium.org
Applied to u-boot/master, thanks!
Even though the PL011 UART driver claims to be DM compliant, it does not really a good job with parsing DT nodes. U-Boot seems to adhere to a non-standard binding, either requiring to have a "skip-init" property in the node, or to have an extra "clock" property holding the base *frequency* value for the baud rate generator. DTs in the U-Boot tree seem to have been hacked to match this requirement.
The official binding does not mention any of these properties, instead recommends a standard "clocks" property to point to the baud base clock.
Some boards use simple "fixed-clock" providers, which U-Boot readily supports, so let's add some simple DM clock code to the PL011 driver to learn the rate of the first clock, as described by the official binding.
These clock nodes seem to be not ready very early in the boot process, so provide a fallback value, by re-using the already existing CONFIG_PL011_CLOCK variable.
Signed-off-by: Andre Przywara andre.przywara@arm.com --- drivers/serial/serial_pl01x.c | 47 +++++++++++++++++++++++------------ 1 file changed, 31 insertions(+), 16 deletions(-)
diff --git a/drivers/serial/serial_pl01x.c b/drivers/serial/serial_pl01x.c index 2a5f256184..14040f32ef 100644 --- a/drivers/serial/serial_pl01x.c +++ b/drivers/serial/serial_pl01x.c @@ -12,6 +12,7 @@
#include <common.h> #include <dm.h> +#include <clk.h> #include <errno.h> #include <watchdog.h> #include <asm/io.h> @@ -149,21 +150,24 @@ static int pl01x_generic_setbrg(struct pl01x_regs *regs, enum pl01x_type type, unsigned int remainder; unsigned int fraction;
- /* - * Set baud rate - * - * IBRD = UART_CLK / (16 * BAUD_RATE) - * FBRD = RND((64 * MOD(UART_CLK,(16 * BAUD_RATE))) - * / (16 * BAUD_RATE)) - */ - temp = 16 * baudrate; - divider = clock / temp; - remainder = clock % temp; - temp = (8 * remainder) / baudrate; - fraction = (temp >> 1) + (temp & 1); - - writel(divider, ®s->pl011_ibrd); - writel(fraction, ®s->pl011_fbrd); + /* Without a valid clock rate we cannot set up the baudrate. */ + if (clock) { + /* + * Set baud rate + * + * IBRD = UART_CLK / (16 * BAUD_RATE) + * FBRD = RND((64 * MOD(UART_CLK,(16 * BAUD_RATE))) + * / (16 * BAUD_RATE)) + */ + temp = 16 * baudrate; + divider = clock / temp; + remainder = clock % temp; + temp = (8 * remainder) / baudrate; + fraction = (temp >> 1) + (temp & 1); + + writel(divider, ®s->pl011_ibrd); + writel(fraction, ®s->pl011_fbrd); + }
pl011_set_line_control(regs); /* Finally, enable the UART */ @@ -337,17 +341,28 @@ static const struct udevice_id pl01x_serial_id[] ={ {} };
+#ifndef CONFIG_PL011_CLOCK +#define CONFIG_PL011_CLOCK 0 +#endif + int pl01x_serial_ofdata_to_platdata(struct udevice *dev) { struct pl01x_serial_platdata *plat = dev_get_platdata(dev); + struct clk clk; fdt_addr_t addr; + int ret;
addr = devfdt_get_addr(dev); if (addr == FDT_ADDR_T_NONE) return -EINVAL;
plat->base = addr; - plat->clock = dev_read_u32_default(dev, "clock", 1); + plat->clock = dev_read_u32_default(dev, "clock", CONFIG_PL011_CLOCK); + ret = clk_get_by_index(dev, 0, &clk); + if (!ret) { + clk_enable(&clk); + plat->clock = clk_get_rate(&clk); + } plat->type = dev_get_driver_data(dev); plat->skip_init = dev_read_bool(dev, "skip-init");
Hi Andre,
On Mon, 27 Apr 2020 at 12:18, Andre Przywara andre.przywara@arm.com wrote:
Even though the PL011 UART driver claims to be DM compliant, it does not really a good job with parsing DT nodes. U-Boot seems to adhere to a non-standard binding, either requiring to have a "skip-init" property in the node, or to have an extra "clock" property holding the base *frequency* value for the baud rate generator. DTs in the U-Boot tree seem to have been hacked to match this requirement.
One problem is that we want a 'debug UART' to work before the clock driver is running, so we want to do the *minimum possible* amount of init to get the UART running. So we don't want to start up driver model, clock drivers, etc.
I think we should have useful helpers like the 'clock' property to avoid lots of parsing very early in U-Boot. Of course such things are hard for kernel people to understand / agree to but that doesn't make them wrong.
The official binding does not mention any of these properties, instead recommends a standard "clocks" property to point to the baud base clock.
Some boards use simple "fixed-clock" providers, which U-Boot readily supports, so let's add some simple DM clock code to the PL011 driver to learn the rate of the first clock, as described by the official binding.
These clock nodes seem to be not ready very early in the boot process, so provide a fallback value, by re-using the already existing CONFIG_PL011_CLOCK variable.
Signed-off-by: Andre Przywara andre.przywara@arm.com
drivers/serial/serial_pl01x.c | 47 +++++++++++++++++++++++------------ 1 file changed, 31 insertions(+), 16 deletions(-)
Reviewed-by: Simon Glass sjg@chromium.org
diff --git a/drivers/serial/serial_pl01x.c b/drivers/serial/serial_pl01x.c index 2a5f256184..14040f32ef 100644 --- a/drivers/serial/serial_pl01x.c +++ b/drivers/serial/serial_pl01x.c @@ -12,6 +12,7 @@
Regards, Simon
On 28/04/2020 18:57, Simon Glass wrote:
Hi,
sorry for the delay, found this, slightly mouldy already, in my draft folder.
First, thanks for the review! I saw the Tom merged this already, but wanted to come back to the DT hacks:
Hi Andre,
On Mon, 27 Apr 2020 at 12:18, Andre Przywara andre.przywara@arm.com wrote:
Even though the PL011 UART driver claims to be DM compliant, it does not really a good job with parsing DT nodes. U-Boot seems to adhere to a non-standard binding, either requiring to have a "skip-init" property in the node, or to have an extra "clock" property holding the base *frequency* value for the baud rate generator. DTs in the U-Boot tree seem to have been hacked to match this requirement.
One problem is that we want a 'debug UART' to work before the clock driver is running, so we want to do the *minimum possible* amount of init to get the UART running. So we don't want to start up driver model, clock drivers, etc.
I understand this very well - having an UART up and running as early as possible is crucial for debugging.
I think we should have useful helpers like the 'clock' property to avoid lots of parsing very early in U-Boot. Of course such things are hard for kernel people to understand / agree to but that doesn't make them wrong.
I agree, but I don't think we should mess around with the DT for this purpose. This is basically a U-Boot requirement or debug feature, not a machine property. And deviating from the official DT binding is not a good idea.
I think for those U-Boot specific debug features we can just have CONFIG options - for instance we already have CONFIG_PL011_CLOCK. Also I strongly believe that skip-init does not belong into the DT. It's a *U-Boot* decision to not *re*-init the UART, not a machine property. There are PL011 compatible UARTs which should *not* be initialised (SBSA-UART), but both TX1 and RPi don't have those, but instead real PL011s. So if we desperately wanted this in the DT, we could actually use compatible = "arm,sbsa-uart", then we don't need any clock at all.
But I was more thinking about turning skip-init into a config symbol and defining this for TX1 and RPi. We do already something similar for the RPi4 in Trusted Firmware [1]. This would allow us to remove the skip-init property from the u-boot.dtsi, and would help with booting with the DT from the SD card instead (for which the GPU firmware puts the pointer to into the beginning of memory [2]).
I have a patch for that already, will send it soonish.
Cheers, Andre
[1] https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/commit/?id=0eda7... [2] https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/commit/?id=c4597...
The official binding does not mention any of these properties, instead recommends a standard "clocks" property to point to the baud base clock.
Some boards use simple "fixed-clock" providers, which U-Boot readily supports, so let's add some simple DM clock code to the PL011 driver to learn the rate of the first clock, as described by the official binding.
These clock nodes seem to be not ready very early in the boot process, so provide a fallback value, by re-using the already existing CONFIG_PL011_CLOCK variable.
Signed-off-by: Andre Przywara andre.przywara@arm.com
drivers/serial/serial_pl01x.c | 47 +++++++++++++++++++++++------------ 1 file changed, 31 insertions(+), 16 deletions(-)
Reviewed-by: Simon Glass sjg@chromium.org
diff --git a/drivers/serial/serial_pl01x.c b/drivers/serial/serial_pl01x.c index 2a5f256184..14040f32ef 100644 --- a/drivers/serial/serial_pl01x.c +++ b/drivers/serial/serial_pl01x.c @@ -12,6 +12,7 @@
Regards, Simon
Hi André,
On Tue, 12 May 2020 at 08:27, André Przywara andre.przywara@arm.com wrote:
On 28/04/2020 18:57, Simon Glass wrote:
Hi,
sorry for the delay, found this, slightly mouldy already, in my draft folder.
First, thanks for the review! I saw the Tom merged this already, but wanted to come back to the DT hacks:
Hi Andre,
On Mon, 27 Apr 2020 at 12:18, Andre Przywara andre.przywara@arm.com wrote:
Even though the PL011 UART driver claims to be DM compliant, it does not really a good job with parsing DT nodes. U-Boot seems to adhere to a non-standard binding, either requiring to have a "skip-init" property in the node, or to have an extra "clock" property holding the base *frequency* value for the baud rate generator. DTs in the U-Boot tree seem to have been hacked to match this requirement.
One problem is that we want a 'debug UART' to work before the clock driver is running, so we want to do the *minimum possible* amount of init to get the UART running. So we don't want to start up driver model, clock drivers, etc.
I understand this very well - having an UART up and running as early as possible is crucial for debugging.
I think we should have useful helpers like the 'clock' property to avoid lots of parsing very early in U-Boot. Of course such things are hard for kernel people to understand / agree to but that doesn't make them wrong.
I agree, but I don't think we should mess around with the DT for this purpose. This is basically a U-Boot requirement or debug feature, not a machine property. And deviating from the official DT binding is not a good idea.
I think for those U-Boot specific debug features we can just have CONFIG options - for instance we already have CONFIG_PL011_CLOCK. Also I strongly believe that skip-init does not belong into the DT. It's a *U-Boot* decision to not *re*-init the UART, not a machine property. There are PL011 compatible UARTs which should *not* be initialised (SBSA-UART), but both TX1 and RPi don't have those, but instead real PL011s. So if we desperately wanted this in the DT, we could actually use compatible = "arm,sbsa-uart", then we don't need any clock at all.
Yes of course these are U-Boot decisions in some sense. But they are also hardware-related. There is nothing wrong with having a fixed clock as a default, for simple software to use.
We have a persistent problem here because of this 'linux' idea that we cannot have config in the DT. It is generally the only thing available to U-Boot. It is certainly the only thing available for runtime config.
Why not put a 'u-boot' prefix on it and be done?
If we could just get over this hangup, it would be so great for U-Boot :-) It doesn't have the ability to rely on user space for policy.
But I was more thinking about turning skip-init into a config symbol and defining this for TX1 and RPi. We do already something similar for the RPi4 in Trusted Firmware [1]. This would allow us to remove the skip-init property from the u-boot.dtsi, and would help with booting with the DT from the SD card instead (for which the GPU firmware puts the pointer to into the beginning of memory [2]).
You mean we have to build U-Boot differently depending on what it is booting from? I wonder if we could pass this information through to U-Boot instead.
I have a patch for that already, will send it soonish.
Regards, Simon
On Mon, Apr 27, 2020 at 07:17:59PM +0100, Andre Przywara wrote:
Even though the PL011 UART driver claims to be DM compliant, it does not really a good job with parsing DT nodes. U-Boot seems to adhere to a non-standard binding, either requiring to have a "skip-init" property in the node, or to have an extra "clock" property holding the base *frequency* value for the baud rate generator. DTs in the U-Boot tree seem to have been hacked to match this requirement.
The official binding does not mention any of these properties, instead recommends a standard "clocks" property to point to the baud base clock.
Some boards use simple "fixed-clock" providers, which U-Boot readily supports, so let's add some simple DM clock code to the PL011 driver to learn the rate of the first clock, as described by the official binding.
These clock nodes seem to be not ready very early in the boot process, so provide a fallback value, by re-using the already existing CONFIG_PL011_CLOCK variable.
Signed-off-by: Andre Przywara andre.przywara@arm.com Reviewed-by: Simon Glass sjg@chromium.org
Applied to u-boot/master, thanks!
The UART base clock rate was typo-ed in the header file, probably because the reference (the Linux .dts) was also wrong[1].
Fix the number to make the baud rate more correct.
Signed-off-by: Andre Przywara andre.przywara@arm.com Reviewed-by: Linus Walleij linus.walleij@linaro.org
[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?i... --- include/configs/vexpress_aemv8a.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/configs/vexpress_aemv8a.h b/include/configs/vexpress_aemv8a.h index 6f81760612..3c85c93a5c 100644 --- a/include/configs/vexpress_aemv8a.h +++ b/include/configs/vexpress_aemv8a.h @@ -102,7 +102,7 @@
/* PL011 Serial Configuration */ #ifdef CONFIG_TARGET_VEXPRESS64_JUNO -#define CONFIG_PL011_CLOCK 7273800 +#define CONFIG_PL011_CLOCK 7372800 #else #define CONFIG_PL011_CLOCK 24000000 #endif
On Mon, 27 Apr 2020 at 12:18, Andre Przywara andre.przywara@arm.com wrote:
The UART base clock rate was typo-ed in the header file, probably because the reference (the Linux .dts) was also wrong[1].
Fix the number to make the baud rate more correct.
Signed-off-by: Andre Przywara andre.przywara@arm.com Reviewed-by: Linus Walleij linus.walleij@linaro.org
[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?i...
include/configs/vexpress_aemv8a.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
Reviewed-by: Simon Glass sjg@chromium.org
On Mon, Apr 27, 2020 at 07:18:00PM +0100, Andre Przywara wrote:
The UART base clock rate was typo-ed in the header file, probably because the reference (the Linux .dts) was also wrong[1].
Fix the number to make the baud rate more correct.
Signed-off-by: Andre Przywara andre.przywara@arm.com Reviewed-by: Linus Walleij linus.walleij@linaro.org
[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?i... Reviewed-by: Simon Glass sjg@chromium.org
Applied to u-boot/master, thanks!
The Arm Juno board was still somewhat stuck in "hardcoded land", even though there are stable DTs around, and one happens to actually be on the memory mapped NOR flash.
Enable the configuration options to let the board use OF_CONTROL, and add a routine to find the address of the DTB partition in NOR flash, to use that for U-Boot's own purposes. This can also passed on via $fdtcontroladdr to any kernel or EFI application, removing the need to actually load a device tree.
Since the existing "afs" command and its flash routines require flash_init() to be called before being usable, and this is done much later in the boot process, we introduce a stripped-down partition finder routine in vexpress64.c, to scan the NOR flash partitions for the DT partition. This location is then used for U-Boot to find and probe devices.
The name of the partition can be configured, if needed, but defaults to "board.dtb", which is used by Linaro's firmware image provided.
Signed-off-by: Andre Przywara andre.przywara@arm.com Reviewed-by: Linus Walleij linus.walleij@linaro.org --- arch/arm/Kconfig | 5 +++ board/armltd/vexpress64/Kconfig | 7 ++++ board/armltd/vexpress64/vexpress64.c | 57 ++++++++++++++++++++++++++ configs/vexpress_aemv8a_juno_defconfig | 4 +- 4 files changed, 70 insertions(+), 3 deletions(-)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 1bcf345028..cf8b629c0e 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -1133,6 +1133,11 @@ config TARGET_VEXPRESS64_JUNO bool "Support Versatile Express Juno Development Platform" select ARM64 select PL01X_SERIAL + select DM + select OF_CONTROL + select OF_BOARD + select CLK + select DM_SERIAL
config TARGET_LS2080A_EMU bool "Support ls2080a_emu" diff --git a/board/armltd/vexpress64/Kconfig b/board/armltd/vexpress64/Kconfig index 9014418433..1d13f542e6 100644 --- a/board/armltd/vexpress64/Kconfig +++ b/board/armltd/vexpress64/Kconfig @@ -9,4 +9,11 @@ config SYS_VENDOR config SYS_CONFIG_NAME default "vexpress_aemv8a"
+config JUNO_DTB_PART + string "NOR flash partition holding DTB" + default "board.dtb" + help + The ARM partition name in the NOR flash memory holding the + device tree blob to configure U-Boot. + endif diff --git a/board/armltd/vexpress64/vexpress64.c b/board/armltd/vexpress64/vexpress64.c index dd0ebdd303..ba49b32e58 100644 --- a/board/armltd/vexpress64/vexpress64.c +++ b/board/armltd/vexpress64/vexpress64.c @@ -82,6 +82,63 @@ int dram_init_banksize(void) return 0; }
+#ifdef CONFIG_OF_BOARD +#define JUNO_FLASH_SEC_SIZE (256 * 1024) +static phys_addr_t find_dtb_in_nor_flash(const char *partname) +{ + phys_addr_t sector = CONFIG_SYS_FLASH_BASE; + int i; + + for (i = 0; + i < CONFIG_SYS_MAX_FLASH_SECT; + i++, sector += JUNO_FLASH_SEC_SIZE) { + int len = strlen(partname) + 1; + int offs; + phys_addr_t imginfo; + u32 reg; + + reg = readl(sector + JUNO_FLASH_SEC_SIZE - 0x04); + /* This makes up the string "HSLFTOOF" flash footer */ + if (reg != 0x464F4F54U) + continue; + reg = readl(sector + JUNO_FLASH_SEC_SIZE - 0x08); + if (reg != 0x464C5348U) + continue; + + for (offs = 0; offs < 32; offs += 4, len -= 4) { + reg = readl(sector + JUNO_FLASH_SEC_SIZE - 0x30 + offs); + if (strncmp(partname + offs, (char *)®, + len > 4 ? 4 : len)) + break; + + if (len > 4) + continue; + + reg = readl(sector + JUNO_FLASH_SEC_SIZE - 0x10); + imginfo = sector + JUNO_FLASH_SEC_SIZE - 0x30 - reg; + reg = readl(imginfo + 0x54); + + return CONFIG_SYS_FLASH_BASE + + reg * JUNO_FLASH_SEC_SIZE; + } + } + + printf("No DTB found\n"); + + return ~0; +} + +void *board_fdt_blob_setup(void) +{ + phys_addr_t fdt_rom_addr = find_dtb_in_nor_flash(CONFIG_JUNO_DTB_PART); + + if (fdt_rom_addr == ~0UL) + return NULL; + + return (void *)fdt_rom_addr; +} +#endif + /* * Board specific reset that is system reset. */ diff --git a/configs/vexpress_aemv8a_juno_defconfig b/configs/vexpress_aemv8a_juno_defconfig index 8628d05e68..6cb21e7a1b 100644 --- a/configs/vexpress_aemv8a_juno_defconfig +++ b/configs/vexpress_aemv8a_juno_defconfig @@ -10,6 +10,7 @@ CONFIG_DISTRO_DEFAULTS=y CONFIG_BOOTDELAY=1 CONFIG_USE_BOOTARGS=y CONFIG_BOOTARGS="console=ttyAMA0,115200n8 root=/dev/sda2 rw rootwait earlycon=pl011,0x7ff80000 debug user_debug=31 androidboot.hardware=juno loglevel=9" +CONFIG_OF_BOARD=y # CONFIG_USE_BOOTCOMMAND is not set # CONFIG_DISPLAY_CPUINFO is not set # CONFIG_DISPLAY_BOARDINFO is not set @@ -30,7 +31,6 @@ CONFIG_CMD_UBI=y # CONFIG_EFI_PARTITION is not set CONFIG_ENV_IS_IN_FLASH=y CONFIG_ENV_ADDR=0xBFC0000 -CONFIG_DM=y # CONFIG_MMC is not set CONFIG_MTD=y CONFIG_MTD_NOR_FLASH=y @@ -41,5 +41,3 @@ CONFIG_SYS_FLASH_CFI=y CONFIG_SMC911X=y CONFIG_SMC911X_BASE=0x018000000 CONFIG_SMC911X_32_BIT=y -CONFIG_DM_SERIAL=y -CONFIG_OF_LIBFDT=y
On Mon, 27 Apr 2020 at 12:18, Andre Przywara andre.przywara@arm.com wrote:
The Arm Juno board was still somewhat stuck in "hardcoded land", even though there are stable DTs around, and one happens to actually be on the memory mapped NOR flash.
Enable the configuration options to let the board use OF_CONTROL, and add a routine to find the address of the DTB partition in NOR flash, to use that for U-Boot's own purposes. This can also passed on via $fdtcontroladdr to any kernel or EFI application, removing the need to actually load a device tree.
Since the existing "afs" command and its flash routines require flash_init() to be called before being usable, and this is done much later in the boot process, we introduce a stripped-down partition finder routine in vexpress64.c, to scan the NOR flash partitions for the DT partition. This location is then used for U-Boot to find and probe devices.
The name of the partition can be configured, if needed, but defaults to "board.dtb", which is used by Linaro's firmware image provided.
Signed-off-by: Andre Przywara andre.przywara@arm.com Reviewed-by: Linus Walleij linus.walleij@linaro.org
arch/arm/Kconfig | 5 +++ board/armltd/vexpress64/Kconfig | 7 ++++ board/armltd/vexpress64/vexpress64.c | 57 ++++++++++++++++++++++++++ configs/vexpress_aemv8a_juno_defconfig | 4 +- 4 files changed, 70 insertions(+), 3 deletions(-)
Reviewed-by: Simon Glass sjg@chromium.org
On Mon, Apr 27, 2020 at 07:18:01PM +0100, Andre Przywara wrote:
The Arm Juno board was still somewhat stuck in "hardcoded land", even though there are stable DTs around, and one happens to actually be on the memory mapped NOR flash.
Enable the configuration options to let the board use OF_CONTROL, and add a routine to find the address of the DTB partition in NOR flash, to use that for U-Boot's own purposes. This can also passed on via $fdtcontroladdr to any kernel or EFI application, removing the need to actually load a device tree.
Since the existing "afs" command and its flash routines require flash_init() to be called before being usable, and this is done much later in the boot process, we introduce a stripped-down partition finder routine in vexpress64.c, to scan the NOR flash partitions for the DT partition. This location is then used for U-Boot to find and probe devices.
The name of the partition can be configured, if needed, but defaults to "board.dtb", which is used by Linaro's firmware image provided.
Signed-off-by: Andre Przywara andre.przywara@arm.com Reviewed-by: Linus Walleij linus.walleij@linaro.org Reviewed-by: Simon Glass sjg@chromium.org
Applied to u-boot/master, thanks!
So far the Juno board wasn't implementing reset. Let's just use the already existing PSCI_RESET based method to avoid any extra code.
Signed-off-by: Andre Przywara andre.przywara@arm.com Acked-by: Liviu Dudau liviu.dudau@arm.com --- arch/arm/Kconfig | 2 ++ board/armltd/vexpress64/vexpress64.c | 4 +--- 2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index cf8b629c0e..449ef06be5 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -1138,6 +1138,8 @@ config TARGET_VEXPRESS64_JUNO select OF_BOARD select CLK select DM_SERIAL + select ARM_PSCI_FW + select PSCI_RESET
config TARGET_LS2080A_EMU bool "Support ls2080a_emu" diff --git a/board/armltd/vexpress64/vexpress64.c b/board/armltd/vexpress64/vexpress64.c index ba49b32e58..5c7a8f55f0 100644 --- a/board/armltd/vexpress64/vexpress64.c +++ b/board/armltd/vexpress64/vexpress64.c @@ -139,9 +139,7 @@ void *board_fdt_blob_setup(void) } #endif
-/* - * Board specific reset that is system reset. - */ +/* Actual reset is done via PSCI. */ void reset_cpu(ulong addr) { }
On Mon, 27 Apr 2020 at 12:19, Andre Przywara andre.przywara@arm.com wrote:
So far the Juno board wasn't implementing reset. Let's just use the already existing PSCI_RESET based method to avoid any extra code.
Signed-off-by: Andre Przywara andre.przywara@arm.com Acked-by: Liviu Dudau liviu.dudau@arm.com
arch/arm/Kconfig | 2 ++ board/armltd/vexpress64/vexpress64.c | 4 +--- 2 files changed, 3 insertions(+), 3 deletions(-)
Reviewed-by: Simon Glass sjg@chromium.org
On Mon, Apr 27, 2020 at 07:18:02PM +0100, Andre Przywara wrote:
So far the Juno board wasn't implementing reset. Let's just use the already existing PSCI_RESET based method to avoid any extra code.
Signed-off-by: Andre Przywara andre.przywara@arm.com Acked-by: Liviu Dudau liviu.dudau@arm.com Reviewed-by: Simon Glass sjg@chromium.org
Applied to u-boot/master, thanks!
The Juno board features a standard compliant EHCI/OHCI USB host controller pair, which we can just enable. The platform data is taken from the device tree.
This allows to use USB mass storage (the only storage on a Juno r0) for loading.
At least on my board USB seems a bit flaky, I need two "usb reset" sequences after the "usb start" to detect an USB hard drive.
Signed-off-by: Andre Przywara andre.przywara@arm.com Acked-by: Liviu Dudau liviu.dudau@arm.com Reviewed-by: Linus Walleij linus.walleij@linaro.org --- arch/arm/Kconfig | 4 ++++ configs/vexpress_aemv8a_juno_defconfig | 5 +++++ include/configs/vexpress_aemv8a.h | 5 +++++ 3 files changed, 14 insertions(+)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 449ef06be5..d582281e40 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -1140,6 +1140,10 @@ config TARGET_VEXPRESS64_JUNO select DM_SERIAL select ARM_PSCI_FW select PSCI_RESET + select DM + select BLK + select USB + select DM_USB
config TARGET_LS2080A_EMU bool "Support ls2080a_emu" diff --git a/configs/vexpress_aemv8a_juno_defconfig b/configs/vexpress_aemv8a_juno_defconfig index 6cb21e7a1b..ca7aa5ab02 100644 --- a/configs/vexpress_aemv8a_juno_defconfig +++ b/configs/vexpress_aemv8a_juno_defconfig @@ -27,6 +27,7 @@ CONFIG_CMD_ARMFLASH=y CONFIG_CMD_CACHE=y # CONFIG_CMD_MISC is not set CONFIG_CMD_UBI=y +CONFIG_CMD_USB=y # CONFIG_ISO_PARTITION is not set # CONFIG_EFI_PARTITION is not set CONFIG_ENV_IS_IN_FLASH=y @@ -41,3 +42,7 @@ CONFIG_SYS_FLASH_CFI=y CONFIG_SMC911X=y CONFIG_SMC911X_BASE=0x018000000 CONFIG_SMC911X_32_BIT=y +CONFIG_USB_EHCI_HCD=y +CONFIG_USB_EHCI_GENERIC=y +CONFIG_USB_OHCI_HCD=y +CONFIG_USB_OHCI_GENERIC=y diff --git a/include/configs/vexpress_aemv8a.h b/include/configs/vexpress_aemv8a.h index 3c85c93a5c..08ad368dbb 100644 --- a/include/configs/vexpress_aemv8a.h +++ b/include/configs/vexpress_aemv8a.h @@ -219,6 +219,11 @@ #define CONFIG_SYS_FLASH_CFI_WIDTH FLASH_CFI_32BIT #define CONFIG_SYS_MAX_FLASH_BANKS 1
+#ifdef CONFIG_USB_EHCI_HCD +#define CONFIG_USB_OHCI_NEW +#define CONFIG_SYS_USB_OHCI_MAX_ROOT_PORTS 1 +#endif + #define CONFIG_SYS_FLASH_EMPTY_INFO /* flinfo indicates empty blocks */ #define FLASH_MAX_SECTOR_SIZE 0x00040000
On Mon, 27 Apr 2020 at 12:19, Andre Przywara andre.przywara@arm.com wrote:
The Juno board features a standard compliant EHCI/OHCI USB host controller pair, which we can just enable. The platform data is taken from the device tree.
This allows to use USB mass storage (the only storage on a Juno r0) for loading.
At least on my board USB seems a bit flaky, I need two "usb reset" sequences after the "usb start" to detect an USB hard drive.
Signed-off-by: Andre Przywara andre.przywara@arm.com Acked-by: Liviu Dudau liviu.dudau@arm.com Reviewed-by: Linus Walleij linus.walleij@linaro.org
arch/arm/Kconfig | 4 ++++ configs/vexpress_aemv8a_juno_defconfig | 5 +++++ include/configs/vexpress_aemv8a.h | 5 +++++ 3 files changed, 14 insertions(+)
Reviewed-by: Simon Glass sjg@chromium.org
+#define CONFIG_USB_OHCI_NEW +#define CONFIG_SYS_USB_OHCI_MAX_ROOT_PORTS 1
Would be good to moveconfig these.
- Simon
On Mon, Apr 27, 2020 at 07:18:03PM +0100, Andre Przywara wrote:
The Juno board features a standard compliant EHCI/OHCI USB host controller pair, which we can just enable. The platform data is taken from the device tree.
This allows to use USB mass storage (the only storage on a Juno r0) for loading.
At least on my board USB seems a bit flaky, I need two "usb reset" sequences after the "usb start" to detect an USB hard drive.
Signed-off-by: Andre Przywara andre.przywara@arm.com Acked-by: Liviu Dudau liviu.dudau@arm.com Reviewed-by: Linus Walleij linus.walleij@linaro.org Reviewed-by: Simon Glass sjg@chromium.org
Applied to u-boot/master, thanks!
CONFIG_SEMIHOSTING is selected for the VFP target by the means of Kconfig already, there is no need to check this in the header file.
Signed-off-by: Andre Przywara andre.przywara@arm.com Reviewed-by: Linus Walleij linus.walleij@linaro.org --- include/configs/vexpress_aemv8a.h | 6 ------ 1 file changed, 6 deletions(-)
diff --git a/include/configs/vexpress_aemv8a.h b/include/configs/vexpress_aemv8a.h index 08ad368dbb..3d63897054 100644 --- a/include/configs/vexpress_aemv8a.h +++ b/include/configs/vexpress_aemv8a.h @@ -7,12 +7,6 @@ #ifndef __VEXPRESS_AEMV8A_H #define __VEXPRESS_AEMV8A_H
-#ifdef CONFIG_TARGET_VEXPRESS64_BASE_FVP -#ifndef CONFIG_SEMIHOSTING -#error CONFIG_TARGET_VEXPRESS64_BASE_FVP requires CONFIG_SEMIHOSTING -#endif -#endif - #define CONFIG_REMAKE_ELF
/* Link Definitions */
On Mon, 27 Apr 2020 at 12:19, Andre Przywara andre.przywara@arm.com wrote:
CONFIG_SEMIHOSTING is selected for the VFP target by the means of Kconfig already, there is no need to check this in the header file.
Signed-off-by: Andre Przywara andre.przywara@arm.com Reviewed-by: Linus Walleij linus.walleij@linaro.org
include/configs/vexpress_aemv8a.h | 6 ------ 1 file changed, 6 deletions(-)
Reviewed-by: Simon Glass sjg@chromium.org
On Mon, Apr 27, 2020 at 07:18:04PM +0100, Andre Przywara wrote:
CONFIG_SEMIHOSTING is selected for the VFP target by the means of Kconfig already, there is no need to check this in the header file.
Signed-off-by: Andre Przywara andre.przywara@arm.com Reviewed-by: Linus Walleij linus.walleij@linaro.org Reviewed-by: Simon Glass sjg@chromium.org
Applied to u-boot/master, thanks!
participants (4)
-
Andre Przywara -
André Przywara
-
Simon Glass -
Tom Rini