[U-Boot] u-boot legacy/FIT/FIT+signature compatability
so I'm tracing through stuff on an am3517-evm board, and finding that with a FIT image file that works without signature checking compiled in, when I turn on sig checking, if it doesn't find a signature I just get a data abort, *and* the resulting u-boot doesn't recognize old 'legacy' boot images anymore either. I get the point that if you have signatures on, you may not want to hand over keys to decrypt secure filesystems if you try to boot an unsigned image, but I think the fallbacks and backwards compatability could be developed a little better, especially since why now that I have CONFIG_FIT I now can't seem to load a legacy image. -- Troy Benjegerdes 'da hozer' ho...@hozed.org 7 elements earth::water::air::fire::mind::spirit::soulgrid.coop Never pick a fight with someone who buys ink by the barrel, nor try buy a hacker who makes money by the megahash ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Mac-native builds
0001-Fix-menuconfig-mac-build.patch Description: Binary data ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 11/11] riscv: Add SiFive FU540 board support
So I take it I could use my version of U-boot to load BBL,
then your S-mode U-boot?
I've been holding off on refactoring or submitting anything
from the MicroSemi U-boot that runs in M-mode and inits the
DRAM until I have some decent method to regression test the
whole system (bootloader, kernel, userspace). I also want
to make sure we don't break any other RiscV platforms when
we add new code.
It looks HiFive unleashed boards are available for purchase
again, is there any place to get an AndesTech board?
(fyi, the *proof of concept* hacks for regression testing
that work for me based on MicroSemi patches are at
https://github.com/tmagik/freedom-u-sdk/tree/regression/kernel4.15 )
On Thu, Jan 17, 2019 at 10:39:27AM +, Anup Patel wrote:
> This patch adds SiFive FU540 board support. For now, only
> SiFive serial, SiFive PRCI, and Cadance MACB drivers are
> only enabled. The SiFive FU540 defconfig by default builds
> U-Boot for S-Mode because U-Boot on SiFive FU540 will run
> in S-Mode as payload of BBL or OpenSBI.
>
> Signed-off-by: Anup Patel
> Signed-off-by: Atish Patra
> ---
> arch/riscv/Kconfig | 4
> board/sifive/fu540/Kconfig | 42 +
> board/sifive/fu540/MAINTAINERS | 9 +++
> board/sifive/fu540/Makefile| 5
> board/sifive/fu540/fu540.c | 17 ++
> configs/sifive_fu540_defconfig | 11 +
> include/configs/sifive-fu540.h | 43 ++
> 7 files changed, 131 insertions(+)
> create mode 100644 board/sifive/fu540/Kconfig
> create mode 100644 board/sifive/fu540/MAINTAINERS
> create mode 100644 board/sifive/fu540/Makefile
> create mode 100644 board/sifive/fu540/fu540.c
> create mode 100644 configs/sifive_fu540_defconfig
> create mode 100644 include/configs/sifive-fu540.h
>
> diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
> index 6879047ff7..36512a8995 100644
> --- a/arch/riscv/Kconfig
> +++ b/arch/riscv/Kconfig
> @@ -14,11 +14,15 @@ config TARGET_AX25_AE350
> config TARGET_QEMU_VIRT
> bool "Support QEMU Virt Board"
>
> +config TARGET_SIFIVE_FU540
> + bool "Support SiFive FU540 Board"
> +
> endchoice
>
> # board-specific options below
> source "board/AndesTech/ax25-ae350/Kconfig"
> source "board/emulation/qemu-riscv/Kconfig"
> +source "board/sifive/fu540/Kconfig"
>
> # platform-specific options below
> source "arch/riscv/cpu/ax25/Kconfig"
> diff --git a/board/sifive/fu540/Kconfig b/board/sifive/fu540/Kconfig
> new file mode 100644
> index 00..6be3d88144
> --- /dev/null
> +++ b/board/sifive/fu540/Kconfig
> @@ -0,0 +1,42 @@
> +if TARGET_SIFIVE_FU540
> +
> +config SYS_BOARD
> + default "fu540"
> +
> +config SYS_VENDOR
> + default "sifive"
> +
> +config SYS_CPU
> + default "generic"
> +
> +config SYS_CONFIG_NAME
> + default "sifive-fu540"
> +
> +config SYS_TEXT_BASE
> + default 0x8000 if !RISCV_SMODE
> + default 0x8020 if RISCV_SMODE
> +
> +config BOARD_SPECIFIC_OPTIONS # dummy
> + def_bool y
> + select GENERIC_RISCV
> + imply CMD_DHCP
> + imply CMD_EXT2
> + imply CMD_EXT4
> + imply CMD_FAT
> + imply CMD_FS_GENERIC
> + imply CMD_NET
> + imply CMD_PING
> + imply CLK_SIFIVE
> + imply CLK_SIFIVE_FU540_PRCI
> + imply DOS_PARTITION
> + imply EFI_PARTITION
> + imply IP_DYN
> + imply ISO_PARTITION
> + imply MACB
> + imply MII
> + imply NET_RANDOM_ETHADDR
> + imply PHY_LIB
> + imply PHY_MSCC
> + imply SIFIVE_SERIAL
> +
> +endif
> diff --git a/board/sifive/fu540/MAINTAINERS b/board/sifive/fu540/MAINTAINERS
> new file mode 100644
> index 00..702d803ad8
> --- /dev/null
> +++ b/board/sifive/fu540/MAINTAINERS
> @@ -0,0 +1,9 @@
> +SiFive FU540 BOARD
> +M: Paul Walmsley
> +M: Palmer Dabbelt
> +M: Anup Patel
> +M: Atish Patra
> +S: Maintained
> +F: board/sifive/fu540/
> +F: include/configs/sifive-fu540.h
> +F: configs/sifive_fu540_defconfig
> diff --git a/board/sifive/fu540/Makefile b/board/sifive/fu540/Makefile
> new file mode 100644
> index 00..6e1862c475
> --- /dev/null
> +++ b/board/sifive/fu540/Makefile
> @@ -0,0 +1,5 @@
> +# SPDX-License-Identifier: GPL-2.0+
> +#
> +# Copyright (c) 2019 Western Digital Corporation or its affiliates.
> +
> +obj-y+= fu540.o
> diff --git a/board/sifive/fu540/fu540.c b/board/sifive/fu540/fu540.c
> new file mode 100644
> index 00..5adc4a3d4a
> --- /dev/null
> +++ b/board/sifive/fu540/fu540.c
> @@ -0,0 +1,17 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright (c) 2019 Western Digital Corporation or its affiliates.
> + *
> + * Authors:
> + * Anup Patel
> + */
> +
> +#include
> +#include
> +
> +int board_init(void)
> +{
> + /* For now nothing to do here. */
> +
> + return 0;
> +}
> diff --git a/configs/sifive_fu540_defconfig b/configs/sifive_fu540_defconfig
> new file mode 100644
> index 00..2f8cca9de0
> --- /dev/null
> +++
Re: [U-Boot] Riscv: CONFIG_DEFAULT_DEVICE_TREE failures
> On Mar 31, 2019, at 5:02 PM, Tom Rini wrote:
>
> On Fri, Mar 29, 2019 at 11:15:48PM -0700, Troy Benjegerdes wrote:
>
>> I attempted to merge in the latest master branch into
>> https://github.com/sifive/u-boot/tree/sandbox and I got
>> the following error, which seems somewhat broken..
>>
>>
>> Device Tree Source is not correctly specified.
>> Please define 'CONFIG_DEFAULT_DEVICE_TREE'
>> or build with 'DEVICE_TREE=' argument
>>
>> dts/Makefile:28: recipe for target 'arch/riscv/dts/fu540.dtb' failed
>>
>>
>> Does anyone have any idea what would have caused that?
>>
>> Also any feedback or pointers on why the serial_sifive.c
>> driver with CONFIG_DM_SERIAL would not work, but serial_hifive.c
>> without CONFIG_DM_SERIAL does seem to work might be appreciated.
>
> You'll need to do something like
>
> commit 89c2b5c02049aea746b1edee0b4e1d8519dec2f4
> Author: Masahiro Yamada
> Date: Thu Mar 14 14:58:33 2019 +0900
>
>ARM: fix arch/arm/dts/Makefile
>
>Since commit 27cb7300ffda ("Ensure device tree DTS is compiled"),
>build succeeds irrespective of the correctness of Makefile.
>
>In fact, you can compile any defconfig without adding any entry in
>arch/*/dts/Makefile.
>
>As a result, a lot of wrong code have been merged unnoticed.
>
>I am going to revert that commit, and lots of hidden issues have
>come to light:
>
>[1] Typos
>
> armada-3720-uDPU.dts, sun8i-a83t-tbs-a711.dts
>
> use the extension ".dts" instead of ".dtb"
>
>[2] DTB is associated to undefined CONFIG option
>
> For example, mx6sllevk_defconfig defines CONFIG_MX6SLL, but
> associates its device tree to CONFIG_MX6SL, which is undefined.
>
>[3] Lots of entries are missing
>
>Signed-off-by: Masahiro Yamada
>Reviewed-by: Chris Packham
>[trini: add imx6ul pico dtbs]
>Signed-off-by: Tom Rini
>
> But to arch/riscv/dts/Makefile
>
> --
> Tom
I ended up reverting that commit, and we now have
https://github.com/sifive/u-boot/tree/sandbox booting to a prompt based on
upstream master.
It still needs the macb driver ported over, and probably re-worked to do what
Rockchip boards do to put the Denali memory init code in the device tree.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] Riscv: CONFIG_DEFAULT_DEVICE_TREE failures
I attempted to merge in the latest master branch into https://github.com/sifive/u-boot/tree/sandbox and I got the following error, which seems somewhat broken.. Device Tree Source is not correctly specified. Please define 'CONFIG_DEFAULT_DEVICE_TREE' or build with 'DEVICE_TREE=' argument dts/Makefile:28: recipe for target 'arch/riscv/dts/fu540.dtb' failed Does anyone have any idea what would have caused that? Also any feedback or pointers on why the serial_sifive.c driver with CONFIG_DM_SERIAL would not work, but serial_hifive.c without CONFIG_DM_SERIAL does seem to work might be appreciated. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 00/11] SMP support for RISC-V
On Sun, Mar 17, 2019 at 07:28:31PM +0100, Lukas Auer wrote: > This patch series adds SMP support for RISC-V to U-Boot. It allows > U-Boot to run on multi-hart systems (hart is the RISC-V terminology for > hardware thread). Images passed to bootm will be started on all harts. > The bootm command is currently the only one that will boot images on all > harts, bootefi is not yet supported. > > The patches have been successfully tested on both QEMU (machine and > supervisor mode) and the HiFive Unleashed board (supervisor mode), using > BBL and OpenSBI. Can you describe the test configuration and boot flow a little more, or post an SDcard image that boots with the switches as shown in the readme at [1] I don't see any board-specific memory initialization code anywhere, so I assume you are still using the original SiFive FSBL, and not the u-boot version that includes the memory init code [2] [1] https://github.com/sifive/freedom-u-sdk [2] https://github.com/sifive/HiFive_U-Boot > Mainline QEMU requires two patches [1, 2] to run in this configuration. > Patch [1] has been dropped and will be replaced with a U-Boot patch. > > [1]: https://patchwork.ozlabs.org/patch/1039493/ > [2]: https://patchwork.ozlabs.org/patch/1039082/ > > Changes in v3: > - Print error if riscv_send_ipi() fails > - Adjust error message for failures of riscv_clear_ipi() to match error > message for failures of riscv_send_ipi() > - New patch to save the hart ID in register tp instead of s0 > - Adjust patch to use the new location of the hart ID (register tp) > - New patch to hang if relocation of secondary harts fails > > Changes in v2: > - Remove unneeded quotes from NR_CPUS Kconfig entry > - Move memory barrier from send_ipi_many() to handle_ipi() > - Add check in send_ipi_many so that IPIs are only sent to available > harts as indicated by the available_harts mask > - Implement hart lottery to pick main hart to run U-Boot > - Remove CONFIG_MAIN_HART as it is not required anymore > - Register available harts in the available_harts mask > - New patch to populate register a0 with the hart ID from the mhartid > CSR in machine-mode > - New patch to enable SMP on the SiFive FU540, which was previously sent > independently > > Lukas Auer (11): > riscv: add infrastructure for calling functions on other harts > riscv: import the supervisor binary interface header file > riscv: implement IPI platform functions using SBI > riscv: delay initialization of caches and debug UART > riscv: save hart ID in register tp instead of s0 > riscv: add support for multi-hart systems > riscv: boot images passed to bootm on all harts > riscv: do not rely on hart ID passed by previous boot stage > riscv: hang if relocation of secondary harts fails > riscv: fu540: enable SMP > riscv: qemu: enable SMP > > arch/riscv/Kconfig | 28 + > arch/riscv/cpu/cpu.c | 9 +- > arch/riscv/cpu/start.S | 167 +-- > arch/riscv/include/asm/csr.h | 1 + > arch/riscv/include/asm/global_data.h | 6 + > arch/riscv/include/asm/sbi.h | 94 +++ > arch/riscv/include/asm/smp.h | 53 + > arch/riscv/lib/Makefile | 2 + > arch/riscv/lib/asm-offsets.c | 1 + > arch/riscv/lib/bootm.c | 13 ++- > arch/riscv/lib/sbi_ipi.c | 25 > arch/riscv/lib/smp.c | 118 +++ > board/emulation/qemu-riscv/Kconfig | 1 + > board/sifive/fu540/Kconfig | 1 + > 14 files changed, 507 insertions(+), 12 deletions(-) > create mode 100644 arch/riscv/include/asm/sbi.h > create mode 100644 arch/riscv/include/asm/smp.h > create mode 100644 arch/riscv/lib/sbi_ipi.c > create mode 100644 arch/riscv/lib/smp.c > > -- > 2.20.1 > > ___ > U-Boot mailing list > U-Boot@lists.denx.de > https://lists.denx.de/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/9] riscv: Add a SYSCON driver for Andestech's PLIC
> > > > > > > > Probably it makes more sense to put this to arch/riscv/cpu/ax25/Kconfig? > > > > > > I just refer to SIFIVE_CLINT. It also not make sense to place here, right > > > ? > > > > Maybe, but since the cpu directory is renamed to 'generic', I am not > > sure moving to that directory is a good idea. > > Maybe I will still put it in /arch/riscv/Kconfig. > And we can move them to the place they belong individually together if > there have better place to accommodate to SIFIVE_CLINT. > How do you think ? > > > > > > +++ b/arch/riscv/lib/Makefile > > > > > @@ -11,6 +11,7 @@ obj-$(CONFIG_CMD_GO) += boot.o > > > > > obj-y += cache.o > > > > > obj-$(CONFIG_RISCV_RDTIME) += rdtime.o > > > > > obj-$(CONFIG_SIFIVE_CLINT) += sifive_clint.o > > > > > +obj-$(CONFIG_NDS_PLIC) += nds_plic.o > > > > > obj-y += interrupts.o > > > > > obj-y += reset.o > > > > > obj-$(CONFIG_SBI_IPI) += sbi_ipi.o > > > > > diff --git a/arch/riscv/lib/nds_plic.c b/arch/riscv/lib/nds_plic.c > > > > > > > > And move this driver to arch/riscv/cpu/ax25 since it's only available > > > > in AX25 CPUs? > > > > > > Same as sifive_clint.c . Shall it also move away from /lib ? > > > > > > > I agree, but see comments above :) It seems to me there might be a usefull distinction between potentially generic things like the Sifive/Berkely/Rocket-chip clint [1] and other vendor implementations which do not have necessarily have publicly reviewable hardware implementations. [1] https://github.com/sifive/rocket-chip/blob/master/src/main/scala/devices/tilelink/CLINT.scala ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] Distro bootcmd: Re: 5.2-rc1 boot on Unleashed
> On Jun 3, 2019, at 5:49 AM, Andreas Schwab wrote: > > On Mai 29 2019, Karsten Merker wrote: > >> Mainline U-Boot already uses the distro bootcmd environment for >> the qemu "virt" machine and it works well. > > The distro_bootcmd doesn't work for the sifive platform yet because it > doesn't set the correct MAC address for booting. > > Andreas. > Before we go an use distro_bootcmd and drag in a bunch of legacy stuff we really should not be using, can we make some kind of effort to decide what the design goals and boot flow should look like instead using the default legacy behavior of a bunch of hard to read and maintain CPP macros? The first thing I notice is that the default dhcp target is ‘boot.scr.uimg’. What good does it do linux distros on RiscV to keep using the old boot script format, rather than just load a text file and use ‘env import’? Is there some benefit to this? Do we gain something from the .scr format, like maybe cryptographic signature support? How do we want to support secure boot into Debian, Fedora, and Suse, and does distro_bootcmd have a way to do this, or can we come up with some improvement that doesn’t depend on trying to do all the work in CPP macros and U-boot runtime scripts? ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Hart lottery and CONFIG_XIP
> On Jun 2, 2019, at 9:22 PM, Rick Chen wrote: > > Hi Troy > >>> From: Troy Benjegerdes [mailto:troy.benjeger...@sifive.com] >>> Sent: Saturday, June 01, 2019 12:24 AM >>> To: Auer, Lukas >>> Cc: Rick Jian-Zhi Chen(陳建志); bmeng...@gmail.com; pal...@sifive.com >>> Subject: Re: Hart lottery and CONFIG_XIP >>> >>> >>> >>>> On May 31, 2019, at 9:13 AM, Auer, Lukas >>> wrote: >>>> >>>> Hi Troy, >>>> >>>> On Fri, 2019-05-31 at 08:18 -0500, Troy Benjegerdes wrote: >>>>> Wouldn't the following line in head.S fail when running from flash >>>>> (although maybe not in a way that prevents booting) >>>>> >>>>> /* save the boot hart id to global_data */ >>>>> SREGtp, GD_BOOT_HART(gp) >>>>> >>>>> Shouldn’t this be protected by CONFIG_XIP? >>>> >>>> The boot hart ID is stored in global data, which is allocated from the >>>> stack (in board_init_f_alloc_reserve() ). It is therefore writable and >>>> won't cause any issues when running from flash. >>> >>> Sorry about the confusion, I was reading it wrong earlier. >>> >>> I’m hoping to have a couple of patches ready later today to change the >>> CONFIG_XIP patch to ‘CONFIG_HART_LOTTERY’ since it is also useful to >>> remove the potential indeterminism of which hart wins the lottery when doing >>> board bringup and debugging. > > I am OK with that. > Actually my preliminary patch about > [PATCH 0/4] AE350 support SMP boot from flash > did as your wish. > > You can refer it : > [PATCH 1/4] riscv: hart_lottery and available harts feature can be seletable > https://www.mail-archive.com/u-boot@lists.denx.de/msg323419.html > > Rick To follow up on https://www.mail-archive.com/u-boot@lists.denx.de/msg323526.html It is confusing and misleading to mix CONFIG_XIP and CONFIG_HART_LOTTERY. From an system testing and validation point of view, I would find it much better (especially at very early boot stages, where U-boot might be the first non-ROM code running) to have a deterministic process to determine what core runs U-boot. This necessarily seems as it will require a CONFIG_BOOT_HART option, as we are not in a position to parse a device tree in head.S ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Hart lottery and CONFIG_XIP
> On Jun 3, 2019, at 9:19 AM, Bin Meng wrote: > > +Anup > > Hi Troy, > > On Mon, Jun 3, 2019 at 9:19 PM Troy Benjegerdes > wrote: >> >> >> >>> On Jun 2, 2019, at 9:22 PM, Rick Chen wrote: >>> >>> Hi Troy >>> >>>>> From: Troy Benjegerdes [mailto:troy.benjeger...@sifive.com] >>>>> Sent: Saturday, June 01, 2019 12:24 AM >>>>> To: Auer, Lukas >>>>> Cc: Rick Jian-Zhi Chen(陳建志); bmeng...@gmail.com; pal...@sifive.com >>>>> Subject: Re: Hart lottery and CONFIG_XIP >>>>> >>>>> >>>>> >>>>>> On May 31, 2019, at 9:13 AM, Auer, Lukas >>>>> wrote: >>>>>> >>>>>> Hi Troy, >>>>>> >>>>>> On Fri, 2019-05-31 at 08:18 -0500, Troy Benjegerdes wrote: >>>>>>> Wouldn't the following line in head.S fail when running from flash >>>>>>> (although maybe not in a way that prevents booting) >>>>>>> >>>>>>> /* save the boot hart id to global_data */ >>>>>>> SREGtp, GD_BOOT_HART(gp) >>>>>>> >>>>>>> Shouldn’t this be protected by CONFIG_XIP? >>>>>> >>>>>> The boot hart ID is stored in global data, which is allocated from the >>>>>> stack (in board_init_f_alloc_reserve() ). It is therefore writable and >>>>>> won't cause any issues when running from flash. >>>>> >>>>> Sorry about the confusion, I was reading it wrong earlier. >>>>> >>>>> I’m hoping to have a couple of patches ready later today to change the >>>>> CONFIG_XIP patch to ‘CONFIG_HART_LOTTERY’ since it is also useful to >>>>> remove the potential indeterminism of which hart wins the lottery when >>>>> doing >>>>> board bringup and debugging. >>> >>> I am OK with that. >>> Actually my preliminary patch about >>> [PATCH 0/4] AE350 support SMP boot from flash >>> did as your wish. >>> >>> You can refer it : >>> [PATCH 1/4] riscv: hart_lottery and available harts feature can be seletable >>> https://www.mail-archive.com/u-boot@lists.denx.de/msg323419.html >>> >>> Rick >> >> To follow up on >> https://www.mail-archive.com/u-boot@lists.denx.de/msg323526.html >> >> It is confusing and misleading to mix CONFIG_XIP and CONFIG_HART_LOTTERY. >> > > I am not sure what caused the confusion. CONFIG_XIP was added to > support U-Boot executing from ROM directly. > The confusion is use cases where you don’t necessarily need CONFIG_XIP, but you do want deterministic SMP booting, and the code is a lot more understandable with ‘#ifdef CONFIG_HART_LOTTERY’, and a Kconfig option and/or documentation warning that says CONFIG_HART_LOTTERY depends on !CONFIG_XIP >> From an system testing and validation point of view, I would find it much >> better >> (especially at very early boot stages, where U-boot might be the first >> non-ROM code >> running) to have a deterministic process to determine what core runs U-boot. >> This > > I remember when SMP patches were submitted by Lukas for the first time > it was deterministic using some macros like CONFIG_BOOT_HART, however > per Anup's request, the hart lottery feature, similar to what Linux > has, was added. I’d like to have CONFIG_BOOT_HART available as a config option as well, particularly for system validation testing. Also along those lines, if we are going to use a lottery to determine what CPU boots the system, how do we know afterwards which one it was? > >> necessarily seems as it will require a CONFIG_BOOT_HART option, as we are not >> in a position to parse a device tree in head.S >> > > Yes, this is understood. So the CONFIG_XIP was added to support such > case, for which the lottery feature relies on a memory location which > isn't writable yet. > > Regards, > Bin ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Distro bootcmd: Re: 5.2-rc1 boot on Unleashed
> On Jun 3, 2019, at 12:02 PM, Tom Rini wrote: > > On Mon, Jun 03, 2019 at 09:44:28AM -0500, Troy Benjegerdes wrote: >> >> >>> On Jun 3, 2019, at 5:49 AM, Andreas Schwab wrote: >>> >>> On Mai 29 2019, Karsten Merker wrote: >>> >>>> Mainline U-Boot already uses the distro bootcmd environment for >>>> the qemu "virt" machine and it works well. >>> >>> The distro_bootcmd doesn't work for the sifive platform yet because it >>> doesn't set the correct MAC address for booting. >>> >>> Andreas. >>> >> >> Before we go an use distro_bootcmd and drag in a bunch of legacy stuff >> we really should not be using, can we make some kind of effort to decide >> what the design goals and boot flow should look like instead using the >> default legacy behavior of a bunch of hard to read and maintain CPP >> macros? > > I feel like you're calling "what everyone agreed on and uses today" > legacy just because it already exists. It is a bit complex because > devices are so complex, rather than it having to support one-off > situations or similar things people usually call "legacy”. My biggest complaint is all the CPP macros, which are really hard to maintain and read. I should probably be more careful to quantify ‘legacy’ much more specifically as “legacy proprietary ROM code”. Or maybe that’s not the right term at all For the first time I know of, we have a (mostly) blank slate to write the ROM boot code to help manage boot complexity. So I’d like to make sure we can tease out all the reasons we have all this important logic and knowledge tied up in a single header file, and at least re-examine is there a better way to do this than abusing CPP. > >> The first thing I notice is that the default dhcp target is ‘boot.scr.uimg’. >> >> What good does it do linux distros on RiscV to keep using the old boot >> script format, rather than just load a text file and use ‘env import’? Is >> there >> some benefit to this? Do we gain something from the .scr format, like >> maybe cryptographic signature support? > > Writing things out in script format ends up being more natural (and > easier to understand) than writing things out in environment format. > This is why while I wish the "uEnv.txt" hook had become more popular and > widely used, at this point I also understand why it wasn't. Doing > a=foo > b=bar > c=baz > magic_name=do this;do that > > Was not easier nor more understandable than: > setenv a foo > setenv b bar > setenv c baz > do this; do that uEnv has the significant user experience advantage of being editable with a plain old text editor, which is why I used it in freedom-u-sdk. If we can get a ’script’ format that can be edited by a non-technical user on a windows or mac box without requiring mkimage, then we have an improvement. Can this be done with .scr currently? > >> How do we want to support secure boot into Debian, Fedora, and Suse, >> and does distro_bootcmd have a way to do this, or can we come up with >> some improvement that doesn’t depend on trying to do all the work in >> CPP macros and U-boot runtime scripts? > > I think the general answer about "secure boot" is that distros want > "UEFI secure boot". And I want to make sure that's done in such a way > that things like user-owned secure boot aren't any more difficult than > vendor secured boot. It seems like making use of existing secure boot > mechanisms has set aside as, well, I don't want to throw snark around > myself, so I'll refrain from speculating. > > -- > Tom The problematic issue with ‘user-owned secure boot’ is it’s never been a major ‘business critical’ need, so it’s always ended up lower on the priority list from anyone who’s looking at what their clients are paying for. Now on that note, I think maybe the best way to approach this is to start with a clear community consensus that we MUST support a user experience where an end-user with an open RiscV device MUST be able to edit the boot parameters (boot script? uEnv.txt?), and then be able to resign the script with their key(s), so the system can boot and maintain a secured state when it gets to userspace where we are running distro-signed binaries. I honestly don’t know of anyone that’s really looked at this in a commercial setting other than maybe purism, and they are a pretty niche vendor, and stuck with a lot of x86 legacy to deal with. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 0/4] Update SiFive Unleashed Clock Driver
> On Jun 18, 2019, at 4:18 AM, Anup Patel wrote:
>
> This series update SiFive Unleashed clock driver so that:
> 1. It is in sync with upstream Linux driver
> 2. It uses latest DT bindings as-per upstream Linux driver
>
> With this series, we can now use latest DT bindings with U-Boot. I have
> tested SiFive Serial driver and Cadence MACB ethernet driver with this
> changes and both work fine.
>
> The legacy FSBL will still pass DTB to U-Boot with older DT bindings
> which will break the updated SiFive Unleashed clock driver. To tackle
> this, we have embedded DTB in OpenSBI FW_PAYLOAD firmware for SiFive
> Unleashed so that OpenSBI will override and pass updated DTB to U-Boot.
>
> In fact, the updated DTB passed by OpenSBI can be used by latest Linux
> (i.e. V5.2-rc1 or higher) as well.
>
> The OpenSBI changes to embed SiFive Unleashed DTB can be found in
> sifive_unleashed_dtb_fix_v1 branch of:
> https://github.com/avpatel/opensbi.git
>
> This series can be found in riscv_unleashed_clk_sync_v1 branch of:
> https://github.com/avpatel/u-boot.git
There are some discrepancies I’m finding in the clocking… If I use the
HiFive_U-Boot as FSBL, it does the following (with some extra debug
code)
U-Boot 2018.09-g8bbdd51-dirty (Jun 18 2019 - 19:46:55 -0700)
DRAM: 2 GiB
MMC:
In:serial
Out: serial
Err: serial
Net: gem_mdc_clk_div: macb_hz: 5
gmac0
Hit any key to stop autoboot: 0
Where as the close-to-u-boot master version does this:
U-Boot 2019.07-rc4-05661-gc998035-dirty (Jun 18 2019 - 19:51:10 -0700)
CPU: rv64imafdc
Model: sifive,hifive-unleashed-a00
DRAM: 8 GiB
In:serial@1001
Out: serial@1001
Err: serial@1001
Net: gem_mdc_clk_div: macb_hz: 93324
For reference, I’ve checked all my changes into the ‘dev/new-dts’ branch
of github.com/tmagik/freedom-u-sdk, and the ‘make test_s’ target will build
and then copy various files to /var/lib/tftpboot to run the test, and assumes
you have a DHCP and TFTP server running locally.
Another issue with the mainline u-boot is it does not have the OTP driver
that the HiFive_U-Boot version does, so when it selects a random mac
address this causes TFTP to fail in one of my test environments.
FYI, the patch applied is:
diff --git a/drivers/net/macb.c b/drivers/net/macb.c
index 5a6cba5..d21026d 100644
--- a/drivers/net/macb.c
+++ b/drivers/net/macb.c
@@ -813,6 +813,8 @@ static u32 macb_mdc_clk_div(int id, struct macb_device
*macb)
unsigned long macb_hz =
HIFIVE_ETHERNET_CLK_FREQ;//get_macb_pclk_rate(id);
#endif
+ printf("%s: macb_hz: %d\n", __func__, macb_hz);
+
if (macb_hz < 2000)
config = MACB_BF(CLK, MACB_CLK_DIV8);
else if (macb_hz < 4000)
@@ -835,6 +837,7 @@ static u32 gem_mdc_clk_div(int id, struct macb_device *macb)
unsigned long macb_hz =
HIFIVE_ETHERNET_CLK_FREQ;//get_macb_pclk_rate(id);
#endif
+ printf("%s: macb_hz: %d\n", __func__, macb_hz);
if (macb_hz < 2000)
config = GEM_BF(CLK, GEM_CLK_DIV8);
else if (macb_hz < 4000)
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot-Board-Maintainers] [U-Boot-Custodians] [ANN] U-Boot v2019.07-rc4 released
> On Jul 3, 2019, at 11:04 AM, Tom Rini wrote: > > On Wed, Jul 03, 2019 at 09:59:22AM -0600, Simon Glass wrote: >> Hi Troy, >> >> On Tue, 2 Jul 2019 at 10:04, Troy Benjegerdes >> wrote: >>> >>> >>> >>>> On Jun 22, 2019, at 2:43 PM, Marek Vasut wrote: >>>> >>>> On 6/22/19 9:12 PM, Heinrich Schuchardt wrote: >>>>> On 6/22/19 8:15 PM, Simon Glass wrote: >>>>>> Hi, >>>>>> >>>>>> On Sat, 22 Jun 2019 at 16:10, Andreas Färber wrote: >>>>>>> >>>>>>> Hi Simon, >>>>>>> >>>>>>> Am 22.06.19 um 16:55 schrieb Simon Glass: >>>>>>>> I'd like to better understand the benefits of the 3-month timeline. >>>>>>> >>>>>>> It takes time to learn about a release, package and build it, test it on >>>>>>> various hardware, investigate and report errors, wait for feedback and >>>>>>> fixes, rinse and repeat with the next -rc. Many people don't do this as >>>>>>> their main job. >>>>>>> >>>>>>> If we shorten the release cycle, newer boards will get out faster (which >>>>>>> is good) but the overall quality of boards not actively worked on >>>>>>> (because they were working good enough before) will decay, which is bad. >>>>>>> The only way to counteract that would be to automatically test on real >>>>>>> hardware rather than just building, and doing that for all these masses >>>>>>> of boards seems unrealistic. >>>>>> >>>>>> Here I think you are talking about distributions. But why not just >>>>>> take every second release? >>>>>> >>>>>> I have certain had the experience of getting a board our of the >>>>>> cupboard and finding that the latest U-Boot doesn't work, nor the one >>>>>> before, nor the three before that. >>>>>> >>>>>> Are we actually seeing an improvement in regressions? I feel that >>>>>> testing is the only way to get that. >>>>>> >>>>>> Perhaps we should select a small subset of boards which do get tested, >>>>>> and actually have custodians build/test on those for every rc? >>>>> >>>>> What I have been doing before all my recent pull requests is to boot >>>>> both an arm32 (Orange Pi) and and an aarch64 (Pine A64 LTS) board via >>>>> bootefi and GRUB. To make this easier I am using a Raspberry with a >>>>> relay board and a Tizen SD-Wire card (https://wiki.tizen.org/SDWire) >>>>> controlling the system under test, >>>>> cf https://pbs.twimg.com/media/D5ugi3iX4AAh1bn.jpg:large >>>>> What would be needed is scripts to automate the testing including all >>>>> the Python tests. >>>>> >>>>> It would make sense to have such test automation for all of our >>>>> architectures similar to what Kernel CI (https://kernelci.org/) does. >>>> >>>> So who's gonna set it up and host it ? >>>> >>> >>> I just got the infrastructure going to do this for the HiFive Unleashed >>> (RiscV port), but that’s only one board right now. >>> >>> I’d propose that one of the responsibilities of being a custodian/ >>> maintainer for a board and/or arch is a commitment to run a >>> *simple* automated testing framework on a set of boards. >> >> SGTM, and I feel we should work towards a shared solution ideally in >> the U-Boot tree to make this easy for people. Much exists already. >> >>> >>> I’ve looked into KenrelCI enough to see that it seems rather >>> complex to get up and running. We need a dead-simple setup >>> (a few debian packages? A container? An SDcard image for a >>> BeagleBone?) that can collect serial console output and power >>> cycle a board. >>> >>> Eventually maybe we should have a Tizen SDWire or something >>> like that, however that requires some real money for board >>> development since I can’t seem to find a source for where >>> I can buy an SDWire. >> >> Me neither. >> >> So where can we buy this magic board? > > You can't, exactly. It's up at https://wiki.tizen.org/SDWire and > Heinrich might have a bit more to say, but it's one of those things that > we may want to see how much a run, or two runs cost and have a US and EU > person that can resell-at-cost. > > -- > Tom What are the chances I can get KiCad sources for the board ;) ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v7 7/9] riscv: sifive: fu540: Setup ethaddr env variable using OTP
> On Jun 23, 2019, at 11:03 PM, Anup Patel wrote:
>
> This patch extends SiFive FU540 board support to setup ethaddr
> env variable based on board serialnum read from OTP.
>
> Signed-off-by: Anup Patel
> ---
> board/sifive/fu540/fu540.c | 122 +
> configs/sifive_fu540_defconfig | 1 +
> 2 files changed, 123 insertions(+)
>
> diff --git a/board/sifive/fu540/fu540.c b/board/sifive/fu540/fu540.c
> index 5adc4a3d4a..11daf1a75a 100644
> --- a/board/sifive/fu540/fu540.c
> +++ b/board/sifive/fu540/fu540.c
> @@ -8,6 +8,128 @@
>
> #include
> #include
> +#include
> +#include
> +
> +#ifdef CONFIG_MISC_INIT_R
> +
> +#define FU540_OTP_BASE_ADDR 0x1007
> +
> +struct fu540_otp_regs {
> + u32 pa; /* Address input */
> + u32 paio; /* Program address input */
> + u32 pas;/* Program redundancy cell selection input */
> + u32 pce;/* OTP Macro enable input */
> + u32 pclk; /* Clock input */
> + u32 pdin; /* Write data input */
> + u32 pdout; /* Read data output */
> + u32 pdstb; /* Deep standby mode enable input (active low) */
> + u32 pprog; /* Program mode enable input */
> + u32 ptc;/* Test column enable input */
> + u32 ptm;/* Test mode enable input */
> + u32 ptm_rep;/* Repair function test mode enable input */
> + u32 ptr;/* Test row enable input */
> + u32 ptrim; /* Repair function enable input */
> + u32 pwe;/* Write enable input (defines program cycle) */
> +} __packed;
> +
> +#define BYTES_PER_FUSE 4
> +#define NUM_FUSES0x1000
> +
> +static int fu540_otp_read(int offset, void *buf, int size)
> +{
> + struct fu540_otp_regs *regs = (void __iomem *)FU540_OTP_BASE_ADDR;
> + unsigned int i;
> + int fuseidx = offset / BYTES_PER_FUSE;
> + int fusecount = size / BYTES_PER_FUSE;
> + u32 fusebuf[fusecount];
> +
> + /* check bounds */
> + if (offset < 0 || size < 0)
> + return -EINVAL;
> + if (fuseidx >= NUM_FUSES)
> + return -EINVAL;
> + if ((fuseidx + fusecount) > NUM_FUSES)
> + return -EINVAL;
> +
> + /* init OTP */
> + writel(0x01, >pdstb); /* wake up from stand-by */
> + writel(0x01, >ptrim); /* enable repair function */
> + writel(0x01, >pce); /* enable input */
> +
> + /* read all requested fuses */
> + for (i = 0; i < fusecount; i++, fuseidx++) {
> + writel(fuseidx, >pa);
> +
> + /* cycle clock to read */
> + writel(0x01, >pclk);
> + mdelay(1);
> + writel(0x00, >pclk);
> + mdelay(1);
> +
> + /* read the value */
> + fusebuf[i] = readl(>pdout);
> + }
> +
> + /* shut down */
> + writel(0, >pce);
> + writel(0, >ptrim);
> + writel(0, >pdstb);
> +
> + /* copy out */
> + memcpy(buf, fusebuf, size);
> +
> + return 0;
> +}
> +
> +static u32 fu540_read_serialnum(void)
> +{
> + int ret;
> + u32 serial[2] = {0};
> +
> + for (int i = 0xfe * 4; i > 0; i -= 8) {
> + ret = fu540_otp_read(i, serial, sizeof(serial));
> + if (ret) {
> + printf("%s: error reading from OTP\n", __func__);
> + break;
> + }
> + if (serial[0] == ~serial[1])
> + return serial[0];
> + }
> +
> + return 0;
> +}
Please take a look at the DM-enabled SiFive OTP driver submitted by Joey Hewitt
at
https://github.com/sifive/HiFive_U-Boot/commit/6d842765de142b61f847852da7a9ce0d081d770c
This Joey's version also sets the ‘serial#’ environment variable, while this
patch only sets ‘ethaddr'
> +
> +static void fu540_setup_macaddr(u32 serialnum)
> +{
> + /* Default MAC address */
> + unsigned char mac[6] = { 0x70, 0xb3, 0xd5, 0x92, 0xf0, 0x00 };
> +
> + /*
> + * We derive our board MAC address by ORing last three bytes
> + * of board serial number to above default MAC address.
> + *
> + * This logic of deriving board MAC address is taken from
> + * SiFive FSBL and is kept unchanged.
> + */
> + mac[5] |= (serialnum >> 0) & 0xff;
> + mac[4] |= (serialnum >> 8) & 0xff;
> + mac[3] |= (serialnum >> 16) & 0xff;
> +
> + /* Update environment variable */
> + eth_env_set_enetaddr("ethaddr", mac);
> +}
> +
> +int misc_init_r(void)
> +{
> + /* Set ethaddr environment variable if not set */
> + if (!env_get("ethaddr"))
> + fu540_setup_macaddr(fu540_read_serialnum());
> +
> + return 0;
> +}
> +
> +#endif
>
> int board_init(void)
> {
> diff --git a/configs/sifive_fu540_defconfig b/configs/sifive_fu540_defconfig
> index f78412398e..f19203745e 100644
> --- a/configs/sifive_fu540_defconfig
> +++ b/configs/sifive_fu540_defconfig
> @@ -7,4 +7,5 @@ CONFIG_DISTRO_DEFAULTS=y
> CONFIG_FIT=y
> CONFIG_DISPLAY_CPUINFO=y
>
Re: [U-Boot] [U-Boot-Custodians] [U-Boot-Board-Maintainers] [ANN] U-Boot v2019.07-rc4 released
> On Jun 22, 2019, at 2:43 PM, Marek Vasut wrote: > > On 6/22/19 9:12 PM, Heinrich Schuchardt wrote: >> On 6/22/19 8:15 PM, Simon Glass wrote: >>> Hi, >>> >>> On Sat, 22 Jun 2019 at 16:10, Andreas Färber wrote: Hi Simon, Am 22.06.19 um 16:55 schrieb Simon Glass: > I'd like to better understand the benefits of the 3-month timeline. It takes time to learn about a release, package and build it, test it on various hardware, investigate and report errors, wait for feedback and fixes, rinse and repeat with the next -rc. Many people don't do this as their main job. If we shorten the release cycle, newer boards will get out faster (which is good) but the overall quality of boards not actively worked on (because they were working good enough before) will decay, which is bad. The only way to counteract that would be to automatically test on real hardware rather than just building, and doing that for all these masses of boards seems unrealistic. >>> >>> Here I think you are talking about distributions. But why not just >>> take every second release? >>> >>> I have certain had the experience of getting a board our of the >>> cupboard and finding that the latest U-Boot doesn't work, nor the one >>> before, nor the three before that. >>> >>> Are we actually seeing an improvement in regressions? I feel that >>> testing is the only way to get that. >>> >>> Perhaps we should select a small subset of boards which do get tested, >>> and actually have custodians build/test on those for every rc? >> >> What I have been doing before all my recent pull requests is to boot >> both an arm32 (Orange Pi) and and an aarch64 (Pine A64 LTS) board via >> bootefi and GRUB. To make this easier I am using a Raspberry with a >> relay board and a Tizen SD-Wire card (https://wiki.tizen.org/SDWire) >> controlling the system under test, >> cf https://pbs.twimg.com/media/D5ugi3iX4AAh1bn.jpg:large >> What would be needed is scripts to automate the testing including all >> the Python tests. >> >> It would make sense to have such test automation for all of our >> architectures similar to what Kernel CI (https://kernelci.org/) does. > > So who's gonna set it up and host it ? > I just got the infrastructure going to do this for the HiFive Unleashed (RiscV port), but that’s only one board right now. I’d propose that one of the responsibilities of being a custodian/ maintainer for a board and/or arch is a commitment to run a *simple* automated testing framework on a set of boards. I’ve looked into KenrelCI enough to see that it seems rather complex to get up and running. We need a dead-simple setup (a few debian packages? A container? An SDcard image for a BeagleBone?) that can collect serial console output and power cycle a board. Eventually maybe we should have a Tizen SDWire or something like that, however that requires some real money for board development since I can’t seem to find a source for where I can buy an SDWire. With the HiFive Unleashed in SiFive’s test lab, we use OpenOCD for JTAG, all I need is one USB cable and I can load U-boot via JTAG, and boot a recovery image, and reload the SDcard, so the SDwire is not really necessary for boards that have easy JTAG setup. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [PATCH 3/3] riscv: sifive: fu540: add SPL configuration
> On Jan 13, 2020, at 4:31 PM, Lukas Auer wrote:
>
> +Troy
>
> On Mon, 2020-01-13 at 14:32 +, Pragnesh Patel wrote:
> +#include
> +
> +u32 DENALI_PHY_DATA[1215] = {
> + DENALI_PHY_00_DATA, DENALI_PHY_01_DATA,
DENALI_PHY_02_DATA,
> + DENALI_PHY_03_DATA, DENALI_PHY_04_DATA,
DENALI_PHY_05_DATA,
> + DENALI_PHY_06_DATA, DENALI_PHY_07_DATA,
DENALI_PHY_08_DATA,
Can this handle to write separate driver for ram like drivers/ram ?
>>
>> We can add DM driver for RAM later. Right now, I want to get U-boot SPL
>> running for FU540.
>
> Troy was working on a DM RAM driver that, from a first glance, already
> looked good [1]. What is the status of the driver, can it be used here?
>
> [1]:
> https://github.com/sifive/u-boot/blob/sandbox/drivers/ram/sifive/sdram_denali.c
It was unfortunately only a first attempt, and I never got it working.
I am hoping that someone else has time to pick it up and complete the work.
Are there any other SoCs we know of besides RockChip that use this
controller and have some sort of open boot firmware and/or U-boot support?
