Re: Licensing discrepancies or ambiguities
On 2023-11-21, Tom Rini wrote: > On Tue, Nov 21, 2023 at 11:10:57AM -0800, Vagrant Cascadian wrote: > >> I've been reviewing the copyright and license information for Das U-Boot >> in preparation for uploading to Debian, and found a few surprises. >> >> tools/libfdt/fdt_rw.c: /* SPDX-License-Identifier: GPL-2.0+ BSD-2-Clause */ > > This comes from the kernel and has been clarified there: > // SPDX-License-Identifier: (GPL-2.0-or-later OR BSD-2-Clause) That's much better! Thanks for looking into it! I suspect there are quite a few that get pulled in from linux or elsewhere that might have similar issues. >> I *think* according to the SPDX spec this needs an OR or an AND. I also >> see no copyright declaration, although maybe there is a standard >> interpretation for this. >> >> Similar issue with (though thankfully they include copyright >> declarations): >> >> include/bloblist.h:/* SPDX-License-Identifier: GPL-2.0+ BSD-3-Clause */ >> common/bloblist.c:// SPDX-License-Identifier: GPL-2.0+ BSD-3-Clause > > Simon? > >> doc/README.ubispl:# SPDX-License-Identifier: GPL 2.0+ BSD-3-Clause > > Should be an OR as well, yes, but it's also out of date and we could > just delete if a problem. Ok. >> This one has a non-existent license: >> >> test/lib/strlcat.c: // SPDX-License-Identifier: GPL-2.1+ >> >> No such license exists, though thankfully it references the exact file >> in the original glibc sources it came from, which is listed as >> LGPL-2.1+. > > Since you did the research would you mind sending the patch? Thanks. Will do eventually! Also found some more ambiguous ones where the license text is in conflict with the SPDX identifiers: arch/sandbox/cpu/u-boot-spl.lds-/* SPDX-License-Identifier: GPL-2.0+ */ arch/sandbox/cpu/u-boot-spl.lds-/* arch/sandbox/cpu/u-boot-spl.lds- * Copyright (c) 2011-2012 The Chromium OS Authors. arch/sandbox/cpu/u-boot-spl.lds: * Use of this source code is governed by a BSD-style license that can be arch/sandbox/cpu/u-boot-spl.lds- * found in the LICENSE file. arch/sandbox/cpu/u-boot-spl.lds- */ The referred to LICENSE file does not appear to exist in u-boot, and exactly what the text of this BSD-style license is ... a mystery. And lib/zstd includes many entries in a similar situation: lib/zstd/Makefile-# Copyright (c) Facebook, Inc. lib/zstd/Makefile-# All rights reserved. lib/zstd/Makefile-# lib/zstd/Makefile:# This source code is licensed under both the BSD-style license (found in the lib/zstd/Makefile-# LICENSE file in the root directory of this source tree) and the GPLv2 (found lib/zstd/Makefile-# in the COPYING file in the root directory of this source tree). lib/zstd/Makefile-# You may select, at your option, one of the above-listed licenses. This seems like it would be "GPL-2.0 OR BSD-*something*", but it is unclear what BSD-style maps to, as the LICENSE file is not present where it claims. Many similar discrepancies can be found with: git grep -B4 -A3 'BSD-style' I probably have mroe to dig up, but these are the ones that leapt out at me for now! live well, vagrant signature.asc Description: PGP signature
Licensing discrepancies or ambiguities
I've been reviewing the copyright and license information for Das U-Boot in preparation for uploading to Debian, and found a few surprises. tools/libfdt/fdt_rw.c: /* SPDX-License-Identifier: GPL-2.0+ BSD-2-Clause */ I *think* according to the SPDX spec this needs an OR or an AND. I also see no copyright declaration, although maybe there is a standard interpretation for this. Similar issue with (though thankfully they include copyright declarations): include/bloblist.h:/* SPDX-License-Identifier: GPL-2.0+ BSD-3-Clause */ common/bloblist.c:// SPDX-License-Identifier: GPL-2.0+ BSD-3-Clause doc/README.ubispl:# SPDX-License-Identifier: GPL 2.0+ BSD-3-Clause This one has a non-existent license: test/lib/strlcat.c: // SPDX-License-Identifier: GPL-2.1+ No such license exists, though thankfully it references the exact file in the original glibc sources it came from, which is listed as LGPL-2.1+. There are certainly more ambiguous issues, but figured I would start with those! live well, vagrant signature.asc Description: PGP signature
Re: [PATCH] rockchip: Pinebook Pro: Fix emmc default configuration
On 2023-05-01, Wolfgang Zarre wrote: > If u-boot is installed on the internal emmc, then this will > allow to boot without failure. > > Signed-off-by: Wolfgang Zarre > Reviewed-by: Kever Yang This is marked as accepted in patchwork, but I do not see it in git yet... Is this planned to land in 2023.07(-rc5?)? Thanks! live well, vagrant > configs/pinebook-pro-rk3399_defconfig | 12 ++-- > 1 file changed, 10 insertions(+), 2 deletions(-) > > diff --git a/configs/pinebook-pro-rk3399_defconfig > b/configs/pinebook-pro-rk3399_defconfig > index dff4695e37..58a8b91aa6 100644 > --- a/configs/pinebook-pro-rk3399_defconfig > +++ b/configs/pinebook-pro-rk3399_defconfig > @@ -6,6 +6,7 @@ CONFIG_TEXT_BASE=0x0020 > CONFIG_NR_DRAM_BANKS=1 > CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y > CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x30 > +CONFIG_SF_DEFAULT_SPEED=2000 > CONFIG_ENV_SIZE=0x8000 > CONFIG_ENV_OFFSET=0x3F8000 > CONFIG_DEFAULT_DEVICE_TREE="rk3399-pinebook-pro" > @@ -18,6 +19,7 @@ CONFIG_DEBUG_UART_CLOCK=2400 > CONFIG_SPL_SPI_FLASH_SUPPORT=y > CONFIG_SPL_SPI=y > CONFIG_SYS_LOAD_ADDR=0x800800 > +CONFIG_PCI=y > CONFIG_DEBUG_UART=y > CONFIG_BOOTDELAY=3 > CONFIG_USE_PREBOOT=y > @@ -57,17 +59,23 @@ CONFIG_LED=y > CONFIG_LED_GPIO=y > CONFIG_MISC=y > CONFIG_ROCKCHIP_EFUSE=y > +CONFIG_MMC_IO_VOLTAGE=y > +CONFIG_SPL_MMC_IO_VOLTAGE=y > +CONFIG_MMC_UHS_SUPPORT=y > +CONFIG_SPL_MMC_UHS_SUPPORT=y > +CONFIG_MMC_HS400_ES_SUPPORT=y > +CONFIG_SPL_MMC_HS400_ES_SUPPORT=y > +CONFIG_MMC_HS400_SUPPORT=y > +CONFIG_SPL_MMC_HS400_SUPPORT=y > CONFIG_MMC_DW=y > CONFIG_MMC_DW_ROCKCHIP=y > CONFIG_MMC_SDHCI=y > CONFIG_MMC_SDHCI_SDMA=y > CONFIG_MMC_SDHCI_ROCKCHIP=y > CONFIG_SF_DEFAULT_BUS=1 > -CONFIG_SF_DEFAULT_SPEED=2000 > CONFIG_SPI_FLASH_GIGADEVICE=y > CONFIG_SPI_FLASH_WINBOND=y > CONFIG_NVME_PCI=y > -CONFIG_PCI=y > CONFIG_PHY_ROCKCHIP_INNO_USB2=y > CONFIG_PHY_ROCKCHIP_TYPEC=y > CONFIG_DM_PMIC_FAN53555=y signature.asc Description: PGP signature
Re: [PATCH v8] board: mntre: imx8mq: Add MNT Reform 2 board support
On 2023-04-28, Vagrant Cascadian wrote: > On 2023-02-05, Vagrant Cascadian wrote: >> On 2023-02-06, Patrick Wildt wrote: >>> The MNT Reform 2 is a modular DIY laptop. In its initial version it >>> is based on the BoundaryDevices i.MX8MQ SoM. Some parts have been >>> lifted from BoundaryDevices official U-Boot downstream project. >>> >>> Signed-off-by: Patrick Wildt >> >> Tested booting Debian with a 6.1.x linux kernel on a mnt/reform2 using >> nvme rootfs and microsd /boot. Some oddities with video and wifi that do >> not occur with the vendor u-boot, but seems like huge progress. > > The patch still applies to master; could this be considered for merging > soon? I've also verified that the patch not only builds, but actually boots, based on git commit c9c2c95d4cd27fe0cd41fe13a863899d268f973c (and also works on v2023.04, for good measure)... Tested-by: Vagrant Cascadian live well, vagrant >>> --- >>> Changes since v7: >>> - Re-added lost ramdisk_addr_r. >>> Changes since v6: >>> - Cleaned up some CONFIG_* pollution. >>> Changes since v5: >>> - Adjusted to further Binman changes. >>> - Adjusted to further Kconfig conversions. >>> - Removed some phy init in favor of DM. >>> - Removed some pinmux which are now handled by DM_SERIAL. >>> - Compared with Librem5/EVK and adjusted for similarity. >>> Changes since v4: >>> - Adjusted to Kconfig conversions. >>> - Removed U-Boot-specific device tree changes. >>> - Synced device tree to Linux v5.19-rc3. >>> Changes since v3: >>> - Adjusted to Binman changes in main branch. >>> - Cleaned up environment variables akin to i.MX8MM. >>> - Added vendor-prefix to device tree filename. >>> - Provided ramdisk_addr_r. >>> Changes since v2: >>> - Switched to Binman. >>> Changes since v1: >>> - Synced DTS with files in Linux git repo. >>> - Added support for USB host ports. >>> >>> arch/arm/dts/imx8mq-mnt-reform2-u-boot.dtsi | 11 + >>> arch/arm/mach-imx/imx8m/Kconfig |7 + >>> board/mntre/imx8mq_reform2/Kconfig| 15 + >>> board/mntre/imx8mq_reform2/MAINTAINERS|7 + >>> board/mntre/imx8mq_reform2/Makefile | 12 + >>> board/mntre/imx8mq_reform2/imx8mq_reform2.c | 171 +++ >>> board/mntre/imx8mq_reform2/lpddr4_timing.c| 1014 + >>> .../mntre/imx8mq_reform2/lpddr4_timing_ch2.h | 95 ++ >>> board/mntre/imx8mq_reform2/spl.c | 260 + >>> configs/imx8mq_reform2_defconfig | 107 ++ >>> include/configs/imx8mq_reform2.h | 67 ++ >>> 11 files changed, 1766 insertions(+) >>> create mode 100644 arch/arm/dts/imx8mq-mnt-reform2-u-boot.dtsi >>> create mode 100644 board/mntre/imx8mq_reform2/Kconfig >>> create mode 100644 board/mntre/imx8mq_reform2/MAINTAINERS >>> create mode 100644 board/mntre/imx8mq_reform2/Makefile >>> create mode 100644 board/mntre/imx8mq_reform2/imx8mq_reform2.c >>> create mode 100644 board/mntre/imx8mq_reform2/lpddr4_timing.c >>> create mode 100644 board/mntre/imx8mq_reform2/lpddr4_timing_ch2.h >>> create mode 100644 board/mntre/imx8mq_reform2/spl.c >>> create mode 100644 configs/imx8mq_reform2_defconfig >>> create mode 100644 include/configs/imx8mq_reform2.h signature.asc Description: PGP signature
Re: [PATCH v8] board: mntre: imx8mq: Add MNT Reform 2 board support
On 2023-02-05, Vagrant Cascadian wrote: > On 2023-02-06, Patrick Wildt wrote: >> The MNT Reform 2 is a modular DIY laptop. In its initial version it >> is based on the BoundaryDevices i.MX8MQ SoM. Some parts have been >> lifted from BoundaryDevices official U-Boot downstream project. >> >> Signed-off-by: Patrick Wildt > > Tested booting Debian with a 6.1.x linux kernel on a mnt/reform2 using > nvme rootfs and microsd /boot. Some oddities with video and wifi that do > not occur with the vendor u-boot, but seems like huge progress. The patch still applies to master; could this be considered for merging soon? live well, vagrant >> --- >> Changes since v7: >> - Re-added lost ramdisk_addr_r. >> Changes since v6: >> - Cleaned up some CONFIG_* pollution. >> Changes since v5: >> - Adjusted to further Binman changes. >> - Adjusted to further Kconfig conversions. >> - Removed some phy init in favor of DM. >> - Removed some pinmux which are now handled by DM_SERIAL. >> - Compared with Librem5/EVK and adjusted for similarity. >> Changes since v4: >> - Adjusted to Kconfig conversions. >> - Removed U-Boot-specific device tree changes. >> - Synced device tree to Linux v5.19-rc3. >> Changes since v3: >> - Adjusted to Binman changes in main branch. >> - Cleaned up environment variables akin to i.MX8MM. >> - Added vendor-prefix to device tree filename. >> - Provided ramdisk_addr_r. >> Changes since v2: >> - Switched to Binman. >> Changes since v1: >> - Synced DTS with files in Linux git repo. >> - Added support for USB host ports. >> >> arch/arm/dts/imx8mq-mnt-reform2-u-boot.dtsi | 11 + >> arch/arm/mach-imx/imx8m/Kconfig |7 + >> board/mntre/imx8mq_reform2/Kconfig| 15 + >> board/mntre/imx8mq_reform2/MAINTAINERS|7 + >> board/mntre/imx8mq_reform2/Makefile | 12 + >> board/mntre/imx8mq_reform2/imx8mq_reform2.c | 171 +++ >> board/mntre/imx8mq_reform2/lpddr4_timing.c| 1014 + >> .../mntre/imx8mq_reform2/lpddr4_timing_ch2.h | 95 ++ >> board/mntre/imx8mq_reform2/spl.c | 260 + >> configs/imx8mq_reform2_defconfig | 107 ++ >> include/configs/imx8mq_reform2.h | 67 ++ >> 11 files changed, 1766 insertions(+) >> create mode 100644 arch/arm/dts/imx8mq-mnt-reform2-u-boot.dtsi >> create mode 100644 board/mntre/imx8mq_reform2/Kconfig >> create mode 100644 board/mntre/imx8mq_reform2/MAINTAINERS >> create mode 100644 board/mntre/imx8mq_reform2/Makefile >> create mode 100644 board/mntre/imx8mq_reform2/imx8mq_reform2.c >> create mode 100644 board/mntre/imx8mq_reform2/lpddr4_timing.c >> create mode 100644 board/mntre/imx8mq_reform2/lpddr4_timing_ch2.h >> create mode 100644 board/mntre/imx8mq_reform2/spl.c >> create mode 100644 configs/imx8mq_reform2_defconfig >> create mode 100644 include/configs/imx8mq_reform2.h signature.asc Description: PGP signature
Re: [v4 5/7] rockchip: Disable DISTRO_DEFAULTS for rk3399 boards
On 2023-03-24, Tom Rini wrote: > These board have moved to standard boot but the old 'distro_bootcmd' > command is still active. Disable DISTRO_DEFAULTS to fix this. I successfully tested the v4 series against v2023.04-rc4 on rockpro64-rk3399 and pinebook-pro-rk3399, and for good measure double-checked that it did not introduce regressions on rock64-rk3328, because it readily available to test. :) Looks good to me, thanks! live well, vagrant > Signed-off-by: Simon Glass > Tested-by: Vagrant Cascadian > --- > Changes in v4: > None. > --- > arch/arm/Kconfig | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig > index bd7fffcce0ba..4e7ebeaee87d 100644 > --- a/arch/arm/Kconfig > +++ b/arch/arm/Kconfig > @@ -1955,7 +1955,7 @@ config ARCH_ROCKCHIP > imply ADC > imply CMD_DM > imply DEBUG_UART_BOARD_INIT > - imply DISTRO_DEFAULTS > + imply DISTRO_DEFAULTS if !ROCKCHIP_RK3399 > imply FAT_WRITE > imply SARADC_ROCKCHIP > imply SPL_SYSRESET > -- > 2.34.1 signature.asc Description: PGP signature
Re: Bug#1033301: linux: arm64 kernel size increased from 31 to 39 MB, causing u-boot-rpi to fail
Adding u-boot maintainers for rpi (Matthias Brugger, Peter Robinson)
platforms and u-boot list to CC.
On 2023-03-22, Salvatore Bonaccorso wrote:
> Thanks for tracking this down. I would like to loop in Masahiro and
> upstream to see if something can/should be done on upstream side.
>
> Masahiro, in short, upstream change 994b7ac1697b ("arm64: remove
> special treatment for the link order of head.o") (which got backported
> as well to 6.1.14) caused the vmlinuz size to icrease significantly,
> causing boot failures on Raspberry Pi 3 Model B Plus with u-boot
> parameters previously working. Full quoting the Debian report below
In general it would be nice to not have the kernel grow nearly 25% in
size from a single commit; was that an expected outcome from the above
upstream change? Was the "special treament" originally done to keep the
kernel size down?
As for u-boot, It seems u-boot might need to update the various load
addresses for the kernel, device tree and ramdisk at some point
regardless of weather this particular issue gets fixed in the kernel, as
the kernel will likely continue to grow a bit over time...
Aurelien Jarno included a patch referenced below which bumps the
tolerances in u-boot from 36MB to 42MB.
> On Tue, Mar 21, 2023 at 11:11:13PM +0100, Aurelien Jarno wrote:
>> Following the upgrade of the kernel from 6.1.12-1 to 6.1.15-1 on a
>> Raspberry Pi 3 Model B Plus, u-boot (from the u-boot-rpi package) failed
>> to boot with:
>>
>> | 40175552 bytes read in 1695 ms (23 MiB/s)
>> | 43794863 bytes read in 1817 ms (23 MiB/s)
>> | Moving Image from 0x8 to 0x20, end=299
>> | ERROR: RD image overlaps OS image (OS=0x20..0x299)
>>
>> I tracked the issue to a significant increase of the kernel size between
>> version 6.1.12-1 and 6.15-1:
>>
>> | 31492 /boot/vmlinuz-6.1.0-5-arm64
>> | 39236 /boot/vmlinuz-6.1.0-6-arm64
>>
>> This is more than the 36MB that is allowed by u-boot with the default
>> load addresses. A workaround is to shift the load addresses at the
>> u-boot level as in the attached patch.
>>
>> I have tracked issue on the upstream kernel side to the following commit
>> on the stable tree:
>>
>> | commit 3e3e4d234d46e48480a7c7c35399fa811182e8ef
>> | Author: Masahiro Yamada
>> | Date: Thu Oct 13 08:35:00 2022 +0900
>> |
>> | arm64: remove special treatment for the link order of head.o
>> |
>> | commit 994b7ac1697b4581b7726d2ac64321e3c840229b upstream.
>> |
>> | In the previous discussion (see the Link tag), Ard pointed out that
>> | arm/arm64/kernel/head.o does not need any special treatment - the only
>> | piece that must appear right at the start of the binary image is the
>> | image header which is emitted into .head.text.
>> |
>> | The linker script does the right thing to do. The build system does
>> | not need to manipulate the link order of head.o.
>> |
>> | Link:
>> https://lore.kernel.org/lkml/CAMj1kXH77Ja8bSsq2Qj8Ck9iSZKw=1F8Uy-uAWGVDm4-CG=e...@mail.gmail.com/
>> | Suggested-by: Ard Biesheuvel
>> | Signed-off-by: Masahiro Yamada
>> | Reviewed-by: Nicolas Schier
>> | Link:
>> https://lore.kernel.org/r/20221012233500.156764-1-masahi...@kernel.org
>> | Signed-off-by: Will Deacon
>> | Signed-off-by: Tom Saeger
>> | Signed-off-by: Greg Kroah-Hartman
>>
>> The problem is still reproducible on Linus' master.
>>
>> I am reporting the bug to the linux package as I believed there is no
>> real reason for such an increase in the kernel size. In case I missed
>> something and this is actually wanted, the bug can be reassigned to the
>> u-boot package.
>>
>> Regards
>> Aurelien
>
>> --- u-boot-2023.01+dfsg.orig/include/configs/rpi.h
>> +++ u-boot-2023.01+dfsg/include/configs/rpi.h
>> @@ -95,32 +95,32 @@
>> * text_offset bytes (specified in the header of the Image) into a 2MB
>> * boundary. The 'booti' command relocates the image if necessary. Linux
>> uses
>> * a default text_offset of 0x8. In summary, loading at 0x8
>> - * satisfies all these constraints and reserving memory up to 0x0240
>> - * permits fairly large (roughly 36M) kernels.
>> + * satisfies all these constraints and reserving memory up to 0x02a0
>> + * permits fairly large (roughly 42M) kernels.
>> *
>> * scriptaddr and pxefile_addr_r can be pretty much anywhere that doesn't
>> * conflict with something else. Reserving 1M for each of them at
>> - * 0x0240-0x0250 and 0x0250-0x0260 should be plenty.
>> + * 0x02a0-0x02b0 and 0x02c0-0x02d0 should be plenty.
>> *
>> * On ARM, both the DTB and any possible initrd must be loaded such that
>> they
>> * fit inside the lowmem mapping in Linux. In practice, this usually means
>> not
>> * more than ~700M away from the start of the kernel image but this number
>> can
>> * be larger OR smaller depending on e.g. the 'vmalloc=xxxM' command line
>> * parameter given to the
Re: [PATCH] rockchip: dts: rk3328: fix sdram params
On 2023-02-10, Jonas Karlman wrote:
> The rk3328 sdram driver read sdram parameters from the devicetree into a
> struct rk3328_sdram_params using dev_read_u32_array.
>
> After commit 5ab30c3176bf ("ram: rockchip: Update ddr pctl regs for px30")
> changed the size of struct ddr_pctl_regs, a member of struct
> rk3328_sdram_params, U-Boot TPL can no longer initialize DRAM on RK3328.
>
> Add ten u32 to the sdram parameter array in devicetree to align with
> this size change. This fixes DRAM initialization on RK3328.
>
> Fixes: 5ab30c3176bf ("ram: rockchip: Update ddr pctl regs for px30")
> Signed-off-by: Jonas Karlman
> Reviewed-by: Simon Glass
> Reviewed-by: Kever Yang
> Reviewed-by: Jagan Teki
> Tested-by: Jagan Teki # roc-rk3328-cc
Thanks! This allows booting the rock64-rk3328 with v2023.04-rc2, which
otherwise just hangs after loading TPL (or SPL?).
Tested-by: Vagrant Cascadian
> ---
> arch/arm/dts/rk3328-sdram-ddr3-666.dtsi| 10 ++
> arch/arm/dts/rk3328-sdram-ddr4-666.dtsi| 10 ++
> arch/arm/dts/rk3328-sdram-lpddr3-1600.dtsi | 10 ++
> arch/arm/dts/rk3328-sdram-lpddr3-666.dtsi | 10 ++
> 4 files changed, 40 insertions(+)
>
> diff --git a/arch/arm/dts/rk3328-sdram-ddr3-666.dtsi
> b/arch/arm/dts/rk3328-sdram-ddr3-666.dtsi
> index 3e88ed443ba0..c5acfe4ac2a0 100644
> --- a/arch/arm/dts/rk3328-sdram-ddr3-666.dtsi
> +++ b/arch/arm/dts/rk3328-sdram-ddr3-666.dtsi
> @@ -92,6 +92,16 @@
> 0x
> 0x
> 0x
> + 0x
> + 0x
> + 0x
> + 0x
> + 0x
> + 0x
> + 0x
> + 0x
> + 0x
> + 0x
>
> 0x0004
> 0x000a
> diff --git a/arch/arm/dts/rk3328-sdram-ddr4-666.dtsi
> b/arch/arm/dts/rk3328-sdram-ddr4-666.dtsi
> index 0859649a6905..c5fa2903c5c1 100644
> --- a/arch/arm/dts/rk3328-sdram-ddr4-666.dtsi
> +++ b/arch/arm/dts/rk3328-sdram-ddr4-666.dtsi
> @@ -89,6 +89,16 @@
> 0x
> 0x
> 0x
> + 0x
> + 0x
> + 0x
> + 0x
> + 0x
> + 0x
> + 0x
> + 0x
> + 0x
> + 0x
>
> 0x0004
> 0x000c
> diff --git a/arch/arm/dts/rk3328-sdram-lpddr3-1600.dtsi
> b/arch/arm/dts/rk3328-sdram-lpddr3-1600.dtsi
> index d63c761a0283..07f27b2b7bab 100644
> --- a/arch/arm/dts/rk3328-sdram-lpddr3-1600.dtsi
> +++ b/arch/arm/dts/rk3328-sdram-lpddr3-1600.dtsi
> @@ -92,6 +92,16 @@
> 0x
> 0x
> 0x
> + 0x
> + 0x
> + 0x
> + 0x
> + 0x
> + 0x
> + 0x
> + 0x
> + 0x
> + 0x
>
> 0x0004
> 0x000b
> diff --git a/arch/arm/dts/rk3328-sdram-lpddr3-666.dtsi
> b/arch/arm/dts/rk3328-sdram-lpddr3-666.dtsi
> index df42bb29ce88..d53d3a0fdfb2 100644
> --- a/arch/arm/dts/rk3328-sdram-lpddr3-666.dtsi
> +++ b/arch/arm/dts/rk3328-sdram-lpddr3-666.dtsi
> @@ -92,6 +92,16 @@
> 0x
> 0x
> 0x
> + 0x
> + 0x
> + 0x
> + 0x
> + 0x
> + 0x
> + 0x
> + 0x
> + 0x
> + 0x
>
> 0x0004
> 0x000b
signature.asc
Description: PGP signature
Re: [PATCH 2/3] rockchip: Disable DISTRO_DEFAULTS for rockpro64
On 2023-02-21, Vagrant Cascadian wrote: > On 2023-02-21, Simon Glass wrote: >> This board has moved to standard boot but the old 'distro_bootcmd' >> command is still active. Disable DISTRO_DEFAULTS to fix this. > > Works for booting rockpro64-rk3399, thanks! I can also confirm that applying a very similar patch for pinebook-pro-rk3399 works booting with bootstd. Seems worth adding if there is a v2 of the patch series. Alternately, rather than doing this on a board-by-board basis, is there some way to disable CONFIG_DISTRO_DEFAULTS when a board is using BOOTSTD? live well, vagrant >> configs/rockpro64-rk3399_defconfig | 1 + >> 1 file changed, 1 insertion(+) >> >> diff --git a/configs/rockpro64-rk3399_defconfig >> b/configs/rockpro64-rk3399_defconfig >> index 49614236819..fe2415c87c9 100644 >> --- a/configs/rockpro64-rk3399_defconfig >> +++ b/configs/rockpro64-rk3399_defconfig >> @@ -19,6 +19,7 @@ CONFIG_SPL_SPI_FLASH_SUPPORT=y >> CONFIG_SPL_SPI=y >> CONFIG_SYS_LOAD_ADDR=0x800800 >> CONFIG_DEBUG_UART=y >> +# CONFIG_DISTRO_DEFAULTS is not set >> CONFIG_BOOTSTAGE=y >> CONFIG_BOOTSTAGE_REPORT=y >> CONFIG_USE_PREBOOT=y >> -- >> 2.39.2.637.g21b0678d19-goog signature.asc Description: PGP signature
Re: [PATCH 2/3] rockchip: Disable DISTRO_DEFAULTS for rockpro64
On 2023-02-21, Simon Glass wrote: > This board has moved to standard boot but the old 'distro_bootcmd' > command is still active. Disable DISTRO_DEFAULTS to fix this. Works for booting rockpro64-rk3399, thanks! Tested-by: Vagrant Cascadian > Signed-off-by: Simon Glass > --- > > configs/rockpro64-rk3399_defconfig | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/configs/rockpro64-rk3399_defconfig > b/configs/rockpro64-rk3399_defconfig > index 49614236819..fe2415c87c9 100644 > --- a/configs/rockpro64-rk3399_defconfig > +++ b/configs/rockpro64-rk3399_defconfig > @@ -19,6 +19,7 @@ CONFIG_SPL_SPI_FLASH_SUPPORT=y > CONFIG_SPL_SPI=y > CONFIG_SYS_LOAD_ADDR=0x800800 > CONFIG_DEBUG_UART=y > +# CONFIG_DISTRO_DEFAULTS is not set > CONFIG_BOOTSTAGE=y > CONFIG_BOOTSTAGE_REPORT=y > CONFIG_USE_PREBOOT=y > -- > 2.39.2.637.g21b0678d19-goog signature.asc Description: PGP signature
Re: [PATCH 3/3] bootstd: Enable BOOTSTD_DEFAULTS by default
On 2023-02-21, Simon Glass wrote: > This is needed to enable the boot command used to start standard boot. > Enable it by default. This brings in quite a few features, mostly in > common with DISTRO_DEFAULTS Works for booting rockpro64-rk3399, thanks! Tested-by: Vagrant Cascadian > Signed-off-by: Simon Glass > --- > > boot/Kconfig | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/boot/Kconfig b/boot/Kconfig > index 5f491625c82..8759b863b00 100644 > --- a/boot/Kconfig > +++ b/boot/Kconfig > @@ -409,6 +409,7 @@ if BOOTSTD > config BOOTSTD_DEFAULTS > bool "Select some common defaults for standard boot" > depends on BOOTSTD > + default y > imply USE_BOOTCOMMAND > # Bring in some defaults which are generally needed. Boards can drop > # these as needed to save code space. Bootstd does not generally require > -- > 2.39.2.637.g21b0678d19-goog signature.asc Description: PGP signature
Re: [PATCH 1/3] rockchip: Drop bootstage stash in TPL and SPL
On 2023-02-21, Simon Glass wrote: > Unfortunately the IRAM used to stash the bootstage records in TPL > becomes accessible after SPL runs. Presumably this is because of ATF > taking it over. > > We could move the stash to another address in SPL, before passing it to > U-Boot proper. But it seems easier to wait until we have support for > standard passage[1] which should not be too far away. > > For now, disable it in TPL and SPL. > > [1] https://patchwork.ozlabs.org/project/uboot/cover/ > 20220117150428.1580273-1-...@chromium.org/ > > Signed-off-by: Simon Glass Works for booting rockpro64-rk3399, thanks! Tested-by: Vagrant Cascadian > configs/rockpro64-rk3399_defconfig | 5 - > 1 file changed, 5 deletions(-) > > diff --git a/configs/rockpro64-rk3399_defconfig > b/configs/rockpro64-rk3399_defconfig > index dd67f9dff64..49614236819 100644 > --- a/configs/rockpro64-rk3399_defconfig > +++ b/configs/rockpro64-rk3399_defconfig > @@ -13,7 +13,6 @@ CONFIG_DM_RESET=y > CONFIG_ROCKCHIP_RK3399=y > CONFIG_TARGET_ROCKPRO64_RK3399=y > CONFIG_SPL_STACK=0x40 > -CONFIG_BOOTSTAGE_STASH_ADDR=0xff8e > CONFIG_DEBUG_UART_BASE=0xFF1A > CONFIG_DEBUG_UART_CLOCK=2400 > CONFIG_SPL_SPI_FLASH_SUPPORT=y > @@ -21,11 +20,7 @@ CONFIG_SPL_SPI=y > CONFIG_SYS_LOAD_ADDR=0x800800 > CONFIG_DEBUG_UART=y > CONFIG_BOOTSTAGE=y > -CONFIG_SPL_BOOTSTAGE=y > -CONFIG_TPL_BOOTSTAGE=y > CONFIG_BOOTSTAGE_REPORT=y > -CONFIG_SPL_BOOTSTAGE_RECORD_COUNT=10 > -CONFIG_BOOTSTAGE_STASH=y > CONFIG_USE_PREBOOT=y > CONFIG_DEFAULT_FDT_FILE="rockchip/rk3399-rockpro64.dtb" > CONFIG_DISPLAY_BOARDINFO_LATE=y > -- > 2.39.2.637.g21b0678d19-goog signature.asc Description: PGP signature
Re: rk3399 boards broken, only partially converted to standard boot? (was Re: [PATCH 71/71] rockchip: Convert rockpro64-rk3399 to use standard boot)
On 2023-02-20, Simon Glass wrote: > On Sat, 18 Feb 2023 at 19:19, Vagrant Cascadian wrote: >> On 2022-12-07, Simon Glass wrote: >> > Drop the use of scripts and rely on standard boot for all operation. >> >> This patch, applied as 3891c68ef50eda38d78c95ecd03aed030aa6bb53 broke >> booting on pinebook-pro-rk3399, which still tries to "run >> distro_bootcmd" but distro_bootcmd is no longer defined... probably >> several other rk3399 systems are similarly affected? Maybe other >> rockchip systems as well? Reverting the patch fixes booting on the >> pinebook-pro-rk3399, at least. >> >> It seems that rockpro64-rk3399 was used as an example, so that >> presumably works, but in actuality, this commit only modifies common >> files for many rockchip and rk3399 boards and nothing rockpro64-rk3399 >> specific, so the commit message is a bit misleading. >> >> I am not sure what the best way forward is; to quickly convert all the >> other boards in a new patch series, or incrementally shift one system at >> a time over (and somehow restore previous behavior in the >> meantime?)... as it stands it appears we are left with rk3399 boards >> partially converted but broken... >> >> FWIW, I have not confirmed for sure that other boards are broken, so it >> might just be pinebook-pro-rk3399 for some reason. I have a few rk3399 >> based boards I can test to confirm... > > I suspect it needs BOOTSTD_DEFAULTS enabled. Could you try that? I can > send a patch if you like? I added CONFIG_BOOTSTD_DEFAULTS=y to configs/pinebook-pro-rk3399_defconfig but it still had the same issue... bootcmd does not get updated to use bootstd instead of distro_bootcmd ... and distro_bootcmd is not defined, so it fails to boot! At least it gets as far as a u-boot prompt! As mentioned on irc, I wasn't able to get rockpro64-rk3399 to boot at all (hanging at SPL), so cannot test if it also needs further changes for BOOTSTD to work... and for good measure, rock64-rk3328 also fails in the same way. I also have puma-rk3399, firefly-rk3399 and firefly-rk3288 to test... though might wait on some of those till the dust settles a bit... live well, vagrant signature.asc Description: PGP signature
rk3399 boards broken, only partially converted to standard boot? (was Re: [PATCH 71/71] rockchip: Convert rockpro64-rk3399 to use standard boot)
On 2022-12-07, Simon Glass wrote: > Drop the use of scripts and rely on standard boot for all operation. This patch, applied as 3891c68ef50eda38d78c95ecd03aed030aa6bb53 broke booting on pinebook-pro-rk3399, which still tries to "run distro_bootcmd" but distro_bootcmd is no longer defined... probably several other rk3399 systems are similarly affected? Maybe other rockchip systems as well? Reverting the patch fixes booting on the pinebook-pro-rk3399, at least. It seems that rockpro64-rk3399 was used as an example, so that presumably works, but in actuality, this commit only modifies common files for many rockchip and rk3399 boards and nothing rockpro64-rk3399 specific, so the commit message is a bit misleading. I am not sure what the best way forward is; to quickly convert all the other boards in a new patch series, or incrementally shift one system at a time over (and somehow restore previous behavior in the meantime?)... as it stands it appears we are left with rk3399 boards partially converted but broken... FWIW, I have not confirmed for sure that other boards are broken, so it might just be pinebook-pro-rk3399 for some reason. I have a few rk3399 based boards I can test to confirm... live well, vagrant > include/configs/rk3399_common.h | 5 + > include/configs/rockchip-common.h | 2 ++ > 2 files changed, 3 insertions(+), 4 deletions(-) > > diff --git a/include/configs/rk3399_common.h b/include/configs/rk3399_common.h > index 2f9aee58197..f2c231dd978 100644 > --- a/include/configs/rk3399_common.h > +++ b/include/configs/rk3399_common.h > @@ -42,15 +42,12 @@ > #define ROCKCHIP_DEVICE_SETTINGS > #endif > > -#include > -#include > #define CONFIG_EXTRA_ENV_SETTINGS \ > ENV_MEM_LAYOUT_SETTINGS \ > "fdtfile=" CONFIG_DEFAULT_FDT_FILE "\0" \ > "partitions=" PARTS_DEFAULT \ > ROCKCHIP_DEVICE_SETTINGS \ > - BOOTENV \ > - BOOTENV_SF \ > + "boot_targets=" BOOT_TARGETS "\0" \ > "altbootcmd=" \ > "setenv boot_syslinux_conf extlinux/extlinux-rollback.conf;" \ > "run distro_bootcmd\0" > diff --git a/include/configs/rockchip-common.h > b/include/configs/rockchip-common.h > index 4c964cc3770..5a06365c760 100644 > --- a/include/configs/rockchip-common.h > +++ b/include/configs/rockchip-common.h > @@ -67,12 +67,14 @@ > BOOT_TARGET_PXE(func) \ > BOOT_TARGET_DHCP(func) \ > BOOT_TARGET_SF(func) > +#define BOOT_TARGETS "mmc1 mmc0 nvme scsi usb pxe dhcp spi" > #else > #define BOOT_TARGET_DEVICES(func) \ > BOOT_TARGET_MMC(func) \ > BOOT_TARGET_USB(func) \ > BOOT_TARGET_PXE(func) \ > BOOT_TARGET_DHCP(func) > +#define BOOT_TARGETS "mmc1 mmc0 usb pxe dhcp" > #endif > > #ifdef CONFIG_ARM64 > -- > 2.39.0.rc0.267.gcb52ba06e7-goog signature.asc Description: PGP signature
Re: [PATCH v8] board: mntre: imx8mq: Add MNT Reform 2 board support
On 2023-02-06, Patrick Wildt wrote: > The MNT Reform 2 is a modular DIY laptop. In its initial version it > is based on the BoundaryDevices i.MX8MQ SoM. Some parts have been > lifted from BoundaryDevices official U-Boot downstream project. > > Signed-off-by: Patrick Wildt Tested booting Debian with a 6.1.x linux kernel on a mnt/reform2 using nvme rootfs and microsd /boot. Some oddities with video and wifi that do not occur with the vendor u-boot, but seems like huge progress. Thanks! Tested-by: Vagrant Cascadian > --- > Changes since v7: > - Re-added lost ramdisk_addr_r. > Changes since v6: > - Cleaned up some CONFIG_* pollution. > Changes since v5: > - Adjusted to further Binman changes. > - Adjusted to further Kconfig conversions. > - Removed some phy init in favor of DM. > - Removed some pinmux which are now handled by DM_SERIAL. > - Compared with Librem5/EVK and adjusted for similarity. > Changes since v4: > - Adjusted to Kconfig conversions. > - Removed U-Boot-specific device tree changes. > - Synced device tree to Linux v5.19-rc3. > Changes since v3: > - Adjusted to Binman changes in main branch. > - Cleaned up environment variables akin to i.MX8MM. > - Added vendor-prefix to device tree filename. > - Provided ramdisk_addr_r. > Changes since v2: > - Switched to Binman. > Changes since v1: > - Synced DTS with files in Linux git repo. > - Added support for USB host ports. > > arch/arm/dts/imx8mq-mnt-reform2-u-boot.dtsi | 11 + > arch/arm/mach-imx/imx8m/Kconfig |7 + > board/mntre/imx8mq_reform2/Kconfig| 15 + > board/mntre/imx8mq_reform2/MAINTAINERS|7 + > board/mntre/imx8mq_reform2/Makefile | 12 + > board/mntre/imx8mq_reform2/imx8mq_reform2.c | 171 +++ > board/mntre/imx8mq_reform2/lpddr4_timing.c| 1014 + > .../mntre/imx8mq_reform2/lpddr4_timing_ch2.h | 95 ++ > board/mntre/imx8mq_reform2/spl.c | 260 + > configs/imx8mq_reform2_defconfig | 107 ++ > include/configs/imx8mq_reform2.h | 67 ++ > 11 files changed, 1766 insertions(+) > create mode 100644 arch/arm/dts/imx8mq-mnt-reform2-u-boot.dtsi > create mode 100644 board/mntre/imx8mq_reform2/Kconfig > create mode 100644 board/mntre/imx8mq_reform2/MAINTAINERS > create mode 100644 board/mntre/imx8mq_reform2/Makefile > create mode 100644 board/mntre/imx8mq_reform2/imx8mq_reform2.c > create mode 100644 board/mntre/imx8mq_reform2/lpddr4_timing.c > create mode 100644 board/mntre/imx8mq_reform2/lpddr4_timing_ch2.h > create mode 100644 board/mntre/imx8mq_reform2/spl.c > create mode 100644 configs/imx8mq_reform2_defconfig > create mode 100644 include/configs/imx8mq_reform2.h signature.asc Description: PGP signature
Re: [PATCH v6] board: mntre: imx8mq: Add MNT Reform 2 board support
On 2023-01-19, Patrick Wildt wrote: > The MNT Reform 2 is a modular DIY laptop. In its initial version it > is based on the BoundaryDevices i.MX8MQ SoM. Some parts have been > lifted from BoundaryDevices official U-Boot downstream project. > > Signed-off-by: Patrick Wildt > --- > Changes since v3: > - Adjusted to Binman changes in main branch. > - Cleaned up environment variables akin to i.MX8MM. > - Added vendor-prefix to device tree filename. > - Provided ramdisk_addr_r. ramdisk_addr_r no longer appears to be set. > +++ b/include/configs/imx8mq_reform2.h ... > +#include > + > +/* Initial environment variables */ > +#define CFG_EXTRA_ENV_SETTINGS \ > + BOOTENV \ > + "scriptaddr=" __stringify(CONFIG_SYS_LOAD_ADDR) "\0" \ > + "kernel_addr_r=" __stringify(CONFIG_SYS_LOAD_ADDR) "\0" \ Maybe put "ramdisk_addr_r=0x4400\0" here? I had proposed 0x4400 as a valid value before. Other than that, seems to work well enough for me, thanks for working on this! Would love to be CCed on future patch series. :) live well, vagrant signature.asc Description: PGP signature
Re: [PATCH] mx53loco: Select CONFIG_CMD_EXT4
On 2023-01-16, Fabio Estevam wrote: > Select the CONFIG_CMD_EXT4 option so that files can be loaded > from an ext4 partition. > > Signed-off-by: Fabio Estevam Debian has been carrying this patch since 2014; thanks for submitting upstream! Unfortunately, I do not know if anyone is actively using it. It still builds, at least. I think some debian ifrastructure was/is using mx53loco boards, though no idea what u-boot was used on them. live well, vagrant > --- > configs/mx53loco_defconfig | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/configs/mx53loco_defconfig b/configs/mx53loco_defconfig > index 193120f71a..7be5636eb7 100644 > --- a/configs/mx53loco_defconfig > +++ b/configs/mx53loco_defconfig > @@ -34,6 +34,7 @@ CONFIG_CMD_DHCP=y > CONFIG_CMD_MII=y > CONFIG_CMD_PING=y > CONFIG_CMD_EXT2=y > +CONFIG_CMD_EXT4=y > CONFIG_CMD_FAT=y > CONFIG_CMD_FS_GENERIC=y > CONFIG_OF_CONTROL=y > -- > 2.25.1 signature.asc Description: PGP signature
Re: [PATCH v2] vbe: Allow probing the VBE bootmeth to fail in OS fixup
On 2023-01-12, Simon Glass wrote:
> This device is created when there are no bootmeths defined in the device
> tree. But it cannot be probed without a device tree node.
>
> For now, ignore a probe failure.
>
> Signed-off-by: Simon Glass
> Reported-by: Karsten Merker
> Suggested-by: Heinrich Schuchardt
> Fixes: a56f663f0707 ("vbe: Add info about the VBE device to the fwupd node")
I was able to reproduce the issue using the qemu-riscv64 instructions
Karsten provided, and applying the patch fixes it, thanks!
Tested-by: Vagrant Cascadian
live well,
vagrant
> ---
>
> Changes in v2:
> - With 'with' typo
> - Change to a debug message and add a comment
>
> boot/vbe_simple_os.c | 16
> 1 file changed, 12 insertions(+), 4 deletions(-)
>
> diff --git a/boot/vbe_simple_os.c b/boot/vbe_simple_os.c
> index b2041a95a30..8c641ec07e2 100644
> --- a/boot/vbe_simple_os.c
> +++ b/boot/vbe_simple_os.c
> @@ -72,6 +72,18 @@ static int bootmeth_vbe_simple_ft_fixup(void *ctx, struct
> event *event)
> chosen = oftree_path(tree, "/chosen");
> if (!ofnode_valid(chosen))
> continue;
> +
> + ret = device_probe(dev);
> + if (ret) {
> + /*
> + * This should become an error when VBE is updated to
> + * only bind this device when a node exists
> + */
> + log_debug("VBE device '%s' failed to probe (err=%d)",
> + dev->name, ret);
> + return 0;
> + }
> +
> ret = ofnode_add_subnode(chosen, "fwupd", );
> if (ret && ret != -EEXIST)
> return log_msg_ret("fwu", ret);
> @@ -80,10 +92,6 @@ static int bootmeth_vbe_simple_ft_fixup(void *ctx, struct
> event *event)
> if (ret && ret != -EEXIST)
> return log_msg_ret("dev", ret);
>
> - ret = device_probe(dev);
> - if (ret)
> - return log_msg_ret("probe", ret);
> -
> /* Copy over the vbe properties for fwupd */
> log_debug("Fixing up: %s\n", dev->name);
> ret = ofnode_copy_props(dev_ofnode(dev), subnode);
signature.asc
Description: PGP signature
Re: v2023.01: u-boot-tools build failure
On 2023-01-13, Tom Rini wrote: > On Fri, Jan 13, 2023 at 06:26:00PM -0300, Fabio Estevam wrote: >> I am trying to upgrade U-Boot to 2023.01 in OpenEmbedded, but I see >> the following error when trying to build u-boot-tools: >> >> | /bin/sh: line 1: tools/bmp_logo: No such file or directory >> >> Reverting the commit below makes u-boot-tools build again: >> >> commit 1cfba53ca46cade2dbf4e067afc8c19e72909a4b >> Author: Peter Robinson >> Date: Thu Nov 24 14:05:59 2022 + >> >> config: tools only: add VIDEO to build bmp_logo >> >> Pre 2023.01 the bmp_logo was built as part of the tools-only_defconfig >> build, something changed and the VIDEO dep needed to build it >> is no longer pulled in so fix that by explicitly defining it. >> >> Signed-off-by: Peter Robinson >> Reviewed-by: Simon Glass >> >> u-boot-tools-native builds fine though. >> >> What would be the correct way to fix this? > > Vagrant also hit this for Debian as Fedora cross-builds bmp_logo and > ships it in host tools, but the logo header files that we generate with > bmp_logo need the tool host built. And the same flag, VIDEO_LOGO > (default y if VIDEO, basically) controls both the tool and the headers. > I think the first thing to figure out is if bmp_logo should be shipped > as a host tool, or not. FWIW, we have not shipped bmp_logo in Debian's u-boot-tools package, so we have managed without it, though curious what the use-case might be. It is disabled in Debian for now: https://salsa.debian.org/debian/u-boot/-/blob/debian/2023.01+dfsg-1/debian/patches/tools-disable-video-logo ... at least until a better fix comes along. :) live well, vagrant signature.asc Description: PGP signature
Re: [PATCH v2 3/3] lmb: consider EFI memory map
On 2023-01-05, Heinrich Schuchardt wrote:
> Add reservations for all EFI memory areas that are not
> EFI_CONVENTIONAL_MEMORY.
>
> Signed-off-by: Heinrich Schuchardt
Tested on odroid-c2, fixes booting from extlinux.conf and boot.scr using
booti, and still works using EFI boot as well.
Thanks!
Tested-by: Vagrant Cascadian
live well,
vagrant
> ---
> v2:
> use efi_get_memory_map_alloc()
> ---
> lib/lmb.c | 36
> 1 file changed, 36 insertions(+)
>
> diff --git a/lib/lmb.c b/lib/lmb.c
> index c599608fa3..ec790760db 100644
> --- a/lib/lmb.c
> +++ b/lib/lmb.c
> @@ -7,7 +7,9 @@
> */
>
> #include
> +#include
> #include
> +#include
> #include
> #include
> #include
> @@ -153,6 +155,37 @@ void arch_lmb_reserve_generic(struct lmb *lmb, ulong sp,
> ulong end, ulong align)
> }
> }
>
> +/**
> + * efi_lmb_reserve() - add reservations for EFI memory
> + *
> + * Add reservations for all EFI memory areas that are not
> + * EFI_CONVENTIONAL_MEMORY.
> + *
> + * @lmb: lmb environment
> + * Return: 0 on success, 1 on failure
> + */
> +static __maybe_unused int efi_lmb_reserve(struct lmb *lmb)
> +{
> + struct efi_mem_desc *memmap = NULL, *map;
> + efi_uintn_t i, map_size = 0;
> + efi_status_t ret;
> +
> + ret = efi_get_memory_map_alloc(_size, );
> + if (ret != EFI_SUCCESS)
> + return 1;
> +
> + for (i = 0, map = memmap; i < map_size / sizeof(*map); ++map, ++i) {
> + if (map->type != EFI_CONVENTIONAL_MEMORY)
> + lmb_reserve(lmb,
> + map_to_sysmem((void *)(uintptr_t)
> + map->physical_start),
> + map->num_pages * EFI_PAGE_SIZE);
> + }
> + efi_free_pool(memmap);
> +
> + return 0;
> +}
> +
> static void lmb_reserve_common(struct lmb *lmb, void *fdt_blob)
> {
> arch_lmb_reserve(lmb);
> @@ -160,6 +193,9 @@ static void lmb_reserve_common(struct lmb *lmb, void
> *fdt_blob)
>
> if (CONFIG_IS_ENABLED(OF_LIBFDT) && fdt_blob)
> boot_fdt_add_mem_rsv_regions(lmb, fdt_blob);
> +
> + if (CONFIG_IS_ENABLED(EFI_LOADER))
> + efi_lmb_reserve(lmb);
> }
>
> /* Initialize the struct, add memory and call arch/board reserve functions */
signature.asc
Description: PGP signature
Re: [PATCH v2 2/3] efi_loader: carve out efi_get_memory_map_alloc()
On 2023-01-05, Heinrich Schuchardt wrote:
> Carve out code from efidebug command used to read the memory map.
>
> Signed-off-by: Heinrich Schuchardt
Tested on odroid-c2, fixes booting from extlinux.conf and boot.scr using
booti, and still works using EFI boot as well.
Thanks!
Tested-by: Vagrant Cascadian
live well,
vagrant
> ---
> v2:
> new patch
> ---
> cmd/efidebug.c | 18 --
> include/efi_loader.h| 3 +++
> lib/efi_loader/efi_memory.c | 34 ++
> 3 files changed, 41 insertions(+), 14 deletions(-)
>
> diff --git a/cmd/efidebug.c b/cmd/efidebug.c
> index 569003ae2e..e6959ede93 100644
> --- a/cmd/efidebug.c
> +++ b/cmd/efidebug.c
> @@ -591,25 +591,15 @@ static void print_memory_attributes(u64 attributes)
> static int do_efi_show_memmap(struct cmd_tbl *cmdtp, int flag,
> int argc, char *const argv[])
> {
> - struct efi_mem_desc *memmap = NULL, *map;
> - efi_uintn_t map_size = 0;
> + struct efi_mem_desc *memmap, *map;
> + efi_uintn_t map_size;
> const char *type;
> int i;
> efi_status_t ret;
>
> - ret = efi_get_memory_map(_size, memmap, NULL, NULL, NULL);
> - if (ret == EFI_BUFFER_TOO_SMALL) {
> - map_size += sizeof(struct efi_mem_desc); /* for my own */
> - ret = efi_allocate_pool(EFI_BOOT_SERVICES_DATA, map_size,
> - (void *));
> - if (ret != EFI_SUCCESS)
> - return CMD_RET_FAILURE;
> - ret = efi_get_memory_map(_size, memmap, NULL, NULL, NULL);
> - }
> - if (ret != EFI_SUCCESS) {
> - efi_free_pool(memmap);
> + ret = efi_get_memory_map_alloc(_size, );
> + if (ret != EFI_SUCCESS)
> return CMD_RET_FAILURE;
> - }
>
> printf("Type Start%.*s End%.*s Attributes\n",
> EFI_PHYS_ADDR_WIDTH - 5, spc, EFI_PHYS_ADDR_WIDTH - 3, spc);
> diff --git a/include/efi_loader.h b/include/efi_loader.h
> index 0899e293e5..02d151b715 100644
> --- a/include/efi_loader.h
> +++ b/include/efi_loader.h
> @@ -734,6 +734,9 @@ efi_status_t efi_allocate_pool(enum efi_memory_type
> pool_type,
> efi_uintn_t size, void **buffer);
> /* EFI pool memory free function. */
> efi_status_t efi_free_pool(void *buffer);
> +/* Allocate and retrieve EFI memory map */
> +efi_status_t efi_get_memory_map_alloc(efi_uintn_t *map_size,
> + struct efi_mem_desc **memory_map);
> /* Returns the EFI memory map */
> efi_status_t efi_get_memory_map(efi_uintn_t *memory_map_size,
> struct efi_mem_desc *memory_map,
> diff --git a/lib/efi_loader/efi_memory.c b/lib/efi_loader/efi_memory.c
> index 8d347f101f..32254d2433 100644
> --- a/lib/efi_loader/efi_memory.c
> +++ b/lib/efi_loader/efi_memory.c
> @@ -736,6 +736,40 @@ efi_status_t efi_get_memory_map(efi_uintn_t
> *memory_map_size,
> return EFI_SUCCESS;
> }
>
> +/**
> + * efi_get_memory_map_alloc() - allocate map describing memory usage
> + *
> + * The caller is responsible for calling FreePool() if the call succeeds.
> + *
> + * @memory_map buffer to which the memory map is written
> + * @map_size size of the memory map
> + * Return: status code
> + */
> +efi_status_t efi_get_memory_map_alloc(efi_uintn_t *map_size,
> + struct efi_mem_desc **memory_map)
> +{
> + efi_status_t ret;
> +
> + *memory_map = NULL;
> + *map_size = 0;
> + ret = efi_get_memory_map(map_size, *memory_map, NULL, NULL, NULL);
> + if (ret == EFI_BUFFER_TOO_SMALL) {
> + *map_size += sizeof(struct efi_mem_desc); /* for the map */
> + ret = efi_allocate_pool(EFI_BOOT_SERVICES_DATA, *map_size,
> + (void **)memory_map);
> + if (ret != EFI_SUCCESS)
> + return ret;
> + ret = efi_get_memory_map(map_size, *memory_map,
> + NULL, NULL, NULL);
> + if (ret != EFI_SUCCESS) {
> + efi_free_pool(*memory_map);
> + *memory_map = NULL;
> + }
> + }
> +
> + return ret;
> +}
> +
> /**
> * efi_add_conventional_memory_map() - add a RAM memory area to the map
> *
signature.asc
Description: PGP signature
Re: Bug#1012269: u-boot-exynos on Odroid XU4 searches for exynos5422-smdk5420xu4.dtb instead of exynos5422-odroidxu4.dtb
On 2022-12-25, Jochen Sprickerhof wrote:
> * Vagrant Cascadian [2022-11-04 14:22]:
>>On 2022-06-02, Jochen Sprickerhof wrote:
>>> with the latest u-boot-exynos in unstable it tries to load
>>> exynos5422-smdk5420xu4.dtb whereas linux-image-5.17.0-3-armmp only
>>> contains exynos5422-odroidxu4.dtb. This was not the case with
>>> 2022.01+dfsg-2:
>>>
>>> U-Boot 2022.04+dfsg-2+b1 (May 14 2022 - 21:25:25 +) for
>>> ODROID-XU3/XU4/HC1/HC2
>>> [..]
>>> Retrieving file:
>>> /usr/lib/linux-image-5.17.0-3-armmp/exynos5422-smdk5420xu4.dtb
>>> ** File not found
>>> /usr/lib/linux-image-5.17.0-3-armmp/exynos5422-smdk5420xu4.dtb **
>>>
>>> U-Boot 2022.01+dfsg-2 (Jan 26 2022 - 19:58:27 +) for
>>> ODROID-XU3/XU4/HC1/HC2
>>> [..]
>>> Retrieving file:
>>> /usr/lib/linux-image-5.17.0-3-armmp/exynos5422-odroidxu4.dtb
...
>>My guess is this was broken in 2022.04, and fixed in 2022.07-rc5 with
>>this commit:
...
>>Could you test 2022.10 from unstable and/or pull 2022.07 from
>>snapshots.debian.org and test it?
>
> I finally found time to test, sorry for the delay. Still the same
> problem:
>
> U-Boot 2022.10+dfsg-2 (Dec 23 2022 - 23:18:44 +) for
> ODROID-XU3/XU4/HC1/HC2
>
> CPU: Exynos5422 @ 800 MHz
> DRAM: 2 GiB
> Core: 73 devices, 12 uclasses, devicetree: separate
> MMC: EXYNOS DWMMC: 0, EXYNOS DWMMC: 2
> Loading Environment from MMC... *** Warning - bad CRC, using default
> environment
>
> In:serial
> Out: serial
> Err: serial
> Model: Odroid XU3/XU4/HC1/HC2 based on Exynos5422
> Type: xu4
> Boot device: MMC(0)
...
> Retrieving file: /usr/lib/linux-image-6.0.0-6-armmp/exynos5422-smdk5420xu4.dtb
> ** File not found
> /usr/lib/linux-image-6.0.0-6-armmp/exynos5422-smdk5420xu4.dtb **
...
> The workaround with:
>
> ln -s exynos5422-odroidxu4.dtb exynos5422-smdk5420xu4.dtb
Hrm. This suggests the fix might not have been effective, which should
have been included in 2022.07... CCing upstream...
commit e744bf3a4ba442a0e9ee1c509c70e1452e3a15d0
Author: Tom Rini
Date: Wed Jun 8 14:30:14 2022 -0400
odroid_xu3: Fix board environment variable
When migrating CONFIG_CONS_INDEX to Kconfig, on this platform we changed
what "board" evaluated to in the environment. This in turn meant that
we would no longer try and find the correct fdtfile via the normal
distro boot logic. Fix this by overriding board in the default
environment, as done on other platforms where CONFIG_SYS_BOARD is not
what we want to be in the board environment variable.
Fixes: f76750d11133 ("Convert CONFIG_CONS_INDEX et al to Kconfig")
Reported-by: Gabriel Hojda
Tested-by: Gabriel Hojda
Signed-off-by: Tom Rini
Alternately... did you at any point run saveenv? This might have stored
the incorrect value... and then it might not probe for the correct
value.
live well,
vagrant
signature.asc
Description: PGP signature
Re: [PATCH u-boot] powerpc/mpc85xx: Pass correct cpu compiler flags
On 2022-12-13, Pali Rohár wrote: > Vagrant and Aurelien, could you test if this change fully fixes your > Debian issue? Well, apparently the issue has been fixed some other way, as u-boot 2022.03-rc3 builds the qemu-ppce500 target fine in Debian with binutils 2.39.50.20221208-5 even without the old patch applied... ... that said, it also builds with this proposed patch applied, so if it is more correct, that seems ok to me too. I haven't tested the resulting u-boot binaries, just that they build successfully. Hope that is helpful! live well, vagrant signature.asc Description: PGP signature
Re: [PATCH] distro_bootcmd: Always check for custom boot scripts first
On 2022-10-12, Tom Rini wrote:
> On Fri, Sep 02, 2022 at 01:06:16AM +0300, Andrey Skvortsov wrote:
>> If extlinux.conf is used, then it's not possible to customize boot
>> environment, because scripts are not loaded.
>> Usually it's possible to make some changes manually using command line
>> and save boot environment. But if exlinux.conf is loaded
>> from ext4 partition (for example on PinePhone), then environment are
>> not saved/loaded at boot time from boot partition and it's not
>> possible to persistently change boot environment without recompiling
>> u-boot.
>>
>> Signed-off-by: Andrey Skvortsov
>> ---
>>
>> include/config_distro_bootcmd.h | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/include/config_distro_bootcmd.h
>> b/include/config_distro_bootcmd.h
>> index 5506f3168f..7f4ef960a1 100644
>> --- a/include/config_distro_bootcmd.h
>> +++ b/include/config_distro_bootcmd.h
>> @@ -477,8 +477,8 @@
>> "echo Scanning ${devtype} " \
>> "${devnum}:${distro_bootpart}...; " \
>> "for prefix in ${boot_prefixes}; do " \
>> -"run scan_dev_for_extlinux; " \
>> "run scan_dev_for_scripts; " \
>> +"run scan_dev_for_extlinux; " \
>> "done;" \
>> SCAN_DEV_FOR_EFI \
>> "\0" \
>
> Reworking the CC list a bit, I think this works against the intent. If
> the distro provides extlinux.conf, that's what should be used, and
> customized by the user (through normal distro methods), rather than
> looking for a boot script that might be out of date / etc. Can you
> please elaborate on what you're seeing and trying to do on the
> PinePhone?
With my Debian hat on, I would prefer to not change default behaviors;
these have been present in this order for many years now. It is also
not uncommon (for better or worse) for a Debian system to have both a
boot script and an extlinux.conf, and possibly an EFI boot option, so
this would be a significant behavior change...
There are definitely cases where the flexibility of a bootscript might
be preferred, but in those cases, one should remove the extlinux.conf
and the packaging hooks that generate it (e.g. u-boot-menu package on
debian).
Alternately, adding another search for a bootscript at a different path
before extlinux.conf is loaded *might* be worth considering, but not
sure the extra complication and duplication is worth it...
Also curious on the status of "U-boot Standard Boot"
https://u-boot.readthedocs.io/en/latest/develop/bootstd.html which might
solve some of these problems?
live well,
vagrant
signature.asc
Description: PGP signature
Re: [PATCH] Makefile: Use relative paths for debugging symbols.
On 2022-08-28, Vagrant Cascadian wrote: > On 2022-08-28, Rasmus Villemoes wrote: >> On 26/08/2022 22.59, Tom Rini wrote: >>> On Thu, Aug 18, 2022 at 10:31:34AM -0700, Vagrant Cascadian wrote: >>>> From: Vagrant Cascadian >>>> >>>> The KBUILD_CFLAGS and KBUILD_AFLAGS variables are adjusted to use >>>> -ffile-prefix-map and --debug-prefix-map, respectively, to use >>>> relative paths for occurrences of __FILE__ and debug paths. >>>> >>>> This enables reproducible builds regardless of the absolute path to >>>> the build directory: >>>> >>>> https://reproducible-builds.org/docs/build-path/ >>>> >>>> Signed-off-by: Vagrant Cascadian >>>> Acked-by: Rasmus Villemoes >>> >>> This needs some sort of clang check and then perhaps different flag >>> used? How does the linux kernel handle this? >> >> Well, interestingly it seems that the kernel doesn't do anything like >> this for debug info, they only apply the -fmacro-prefix-map. Which one >> should probably raise with them at some point. >> >> It seems we're not actually calling gas directly, but always invokes >> $(CC) whatever that may be to compile assembler files. So I think the >> right fix is to simply pass the same -ffile-prefix-map in both >> KBUILD_CFLAGS as in KBUILD_AFLAGS - and if there's some variable that >> ends up being included in both automatically, then just adding it there >> should do the trick. > > I tried just adding -ffile-prefix-map and that helped, but was not > sufficient to solve the reproducibility issues. It also needs the > --debug-prefix-map to make it the assembly code build reproducibly. > > Though I guess I didn't try adding -ffile-prefix-map to KBUILD_AFLAGS, > now that I think about it... will test that too, thanks! Nope, that built, but not reproducibly... I was able to guard it with "as-option": +KBUILD_AFLAGS += $(call as-option,--debug-prefix-map=$(srctree)/=) And it builds reproducibly for me. That should be sufficient to fix build failures with clang... or is there a more appropriate guard to use? I am not familiar with clang and it's relevent tools to know if there is a relevent comprable option to --debug-prefix-map. live well, vagrant signature.asc Description: PGP signature
Re: [PATCH] Makefile: Use relative paths for debugging symbols.
On 2022-08-28, Rasmus Villemoes wrote: > On 26/08/2022 22.59, Tom Rini wrote: >> On Thu, Aug 18, 2022 at 10:31:34AM -0700, Vagrant Cascadian wrote: >> >>> From: Vagrant Cascadian >>> >>> The KBUILD_CFLAGS and KBUILD_AFLAGS variables are adjusted to use >>> -ffile-prefix-map and --debug-prefix-map, respectively, to use >>> relative paths for occurrences of __FILE__ and debug paths. >>> >>> This enables reproducible builds regardless of the absolute path to >>> the build directory: >>> >>> https://reproducible-builds.org/docs/build-path/ >>> >>> Signed-off-by: Vagrant Cascadian >>> Acked-by: Rasmus Villemoes >> >> This needs some sort of clang check and then perhaps different flag >> used? How does the linux kernel handle this? > > Well, interestingly it seems that the kernel doesn't do anything like > this for debug info, they only apply the -fmacro-prefix-map. Which one > should probably raise with them at some point. > > It seems we're not actually calling gas directly, but always invokes > $(CC) whatever that may be to compile assembler files. So I think the > right fix is to simply pass the same -ffile-prefix-map in both > KBUILD_CFLAGS as in KBUILD_AFLAGS - and if there's some variable that > ends up being included in both automatically, then just adding it there > should do the trick. I tried just adding -ffile-prefix-map and that helped, but was not sufficient to solve the reproducibility issues. It also needs the --debug-prefix-map to make it the assembly code build reproducibly. Though I guess I didn't try adding -ffile-prefix-map to KBUILD_AFLAGS, now that I think about it... will test that too, thanks! live well, vagrant signature.asc Description: PGP signature
[PATCH] Makefile: Use relative paths for debugging symbols.
From: Vagrant Cascadian The KBUILD_CFLAGS and KBUILD_AFLAGS variables are adjusted to use -ffile-prefix-map and --debug-prefix-map, respectively, to use relative paths for occurrences of __FILE__ and debug paths. This enables reproducible builds regardless of the absolute path to the build directory: https://reproducible-builds.org/docs/build-path/ Signed-off-by: Vagrant Cascadian --- Makefile | 8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/Makefile b/Makefile index 1a66f69a4b..b40b9b2444 100644 --- a/Makefile +++ b/Makefile @@ -751,14 +751,18 @@ KBUILD_CFLAGS += $(call cc-disable-warning, stringop-overflow) # Enabled with W=2, disabled by default as noisy KBUILD_CFLAGS += $(call cc-disable-warning, maybe-uninitialized) -# change __FILE__ to the relative path from the srctree -KBUILD_CFLAGS += $(call cc-option,-fmacro-prefix-map=$(srctree)/=) +# change __FILE__ and debugging symbols to the relative path from the +# srctree +KBUILD_CFLAGS += $(call cc-option,-ffile-prefix-map=$(srctree)/=) KBUILD_CFLAGS += -g # $(KBUILD_AFLAGS) sets -g, which causes gcc to pass a suitable -g # option to the assembler. KBUILD_AFLAGS += -g +# Use relative paths in debugging symbols +KBUILD_AFLAGS += --debug-prefix-map=$(srctree)/= + # Report stack usage if supported # ARC tools based on GCC 7.1 has an issue with stack usage # with naked functions, see commit message for more details -- 2.35.1
Reproducibility issue due to use of uname
It looks like u-boot 2022.07-rc1 introduced a reproducibility issue that is dependent on the running kernel. I believe the commit that triggered this issue is: f7691a6d736bec7915c227ac14076f9993a27367 sandbox: allow cross-compiling sandbox While the use of uname in the Makefile goes back well before this commit, previously it had no apparent effect on the builds... When building natively (e.g. CROSS_COMPILE is not set) with a 32-bit userland toolchain, but running a 64-bit kernel, 32-bit arm targets end up with BOOTAA64.EFI embedded in the binaries: https://tests.reproducible-builds.org/debian/rb-pkg/experimental/armhf/diffoscope-results/u-boot.html /EFI/BOOT/BOOTARM.EFI vs. /EFI/BOOT/BOOTAA64.EFI live well, vagrant signature.asc Description: PGP signature
[PATCH] tools: kwboot: Fix spelling of "followed" in kwboot.1
Fix spelling of "followed" in kwboot.1 manpage. Series: 2 Signed-off-by: Vagrant Cascadian --- Changes in v2: Use "tools: kwboot:" prefix. Add full commit message. doc/kwboot.1 | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/kwboot.1 b/doc/kwboot.1 index f555ff26a2..d663bf1f77 100644 --- a/doc/kwboot.1 +++ b/doc/kwboot.1 @@ -74,7 +74,7 @@ BootROM's standard input and BootROM's terminal echo are active and working fine. To workaround this BootROM bug with standard output, it is possible to manually overwrite BootROM variables stored in SRAM which BootROM use for checking if standard output is enabled or not. To enable BootROM -standard output on UART, type this command folled by ENTER key: +standard output on UART, type this command followed by ENTER key: .RS 1.2i .TP -- 2.35.1
[PATCH] Fix spelling of "followed" in kwboot.1
Signed-off-by: Vagrant Cascadian --- doc/kwboot.1 | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/kwboot.1 b/doc/kwboot.1 index f555ff26a2..d663bf1f77 100644 --- a/doc/kwboot.1 +++ b/doc/kwboot.1 @@ -74,7 +74,7 @@ BootROM's standard input and BootROM's terminal echo are active and working fine. To workaround this BootROM bug with standard output, it is possible to manually overwrite BootROM variables stored in SRAM which BootROM use for checking if standard output is enabled or not. To enable BootROM -standard output on UART, type this command folled by ENTER key: +standard output on UART, type this command followed by ENTER key: .RS 1.2i .TP -- 2.35.1
[PATCH 2/2] rockchip: Enable AHCI/SCSI/SATA on rockpro64-rk3399.
Add options to enable AHCI, SCSI and SATA. Signed-off-by: Vagrant Cascadian --- configs/rockpro64-rk3399_defconfig | 7 +++ 1 file changed, 7 insertions(+) diff --git a/configs/rockpro64-rk3399_defconfig b/configs/rockpro64-rk3399_defconfig index d5e98a4f73..858410e8f7 100644 --- a/configs/rockpro64-rk3399_defconfig +++ b/configs/rockpro64-rk3399_defconfig @@ -28,6 +28,13 @@ CONFIG_CMD_GPT=y CONFIG_CMD_MMC=y CONFIG_CMD_PCI=y CONFIG_CMD_USB=y +CONFIG_AHCI=y +CONFIG_AHCI_PCI=y +CONFIG_SATA=y +CONFIG_SATA_SIL=y +CONFIG_SCSI=y +CONFIG_SCSI_AHCI=y +CONFIG_DM_SCSI=y # CONFIG_CMD_SETEXPR is not set CONFIG_CMD_TIME=y CONFIG_SPL_OF_CONTROL=y -- 2.35.1
[PATCH 1/2] rockchip: Enable SCSI in distro bootcmd for rk3399.
Include SCSI in the list of boot targets if CONFIG_CMD_SCSI is enabled. Signed-off-by: Vagrant Cascadian --- include/configs/rockchip-common.h | 7 +++ 1 file changed, 7 insertions(+) diff --git a/include/configs/rockchip-common.h b/include/configs/rockchip-common.h index ba7061a287..0c08776ae2 100644 --- a/include/configs/rockchip-common.h +++ b/include/configs/rockchip-common.h @@ -29,6 +29,12 @@ #define BOOT_TARGET_NVME(func) #endif +#if CONFIG_IS_ENABLED(CMD_SCSI) + #define BOOT_TARGET_SCSI(func) func(SCSI, scsi, 0) +#else + #define BOOT_TARGET_SCSI(func) +#endif + #if CONFIG_IS_ENABLED(CMD_USB) #define BOOT_TARGET_USB(func) func(USB, usb, 0) #else @@ -57,6 +63,7 @@ #define BOOT_TARGET_DEVICES(func) \ BOOT_TARGET_MMC(func) \ BOOT_TARGET_NVME(func) \ + BOOT_TARGET_SCSI(func) \ BOOT_TARGET_USB(func) \ BOOT_TARGET_PXE(func) \ BOOT_TARGET_DHCP(func) \ -- 2.35.1
[PATCH 0/2] Enable booting from SCSI on rockpro64-rk3399.
This patch series adds SCSI booting to rockchip-common.h to enable scsi boot options from distro boot, and enables SCSI options in the rockpro64-rk3399 configuration. Vagrant Cascadian (2): rockchip: Enable SCSI in distro bootcmd for rk3399. rockchip: Enable AHCI/SCSI/SATA on rockpro64-rk3399. configs/rockpro64-rk3399_defconfig | 7 +++ include/configs/rockchip-common.h | 7 +++ 2 files changed, 14 insertions(+) -- 2.35.1
Re: Bug#1003490: u-boot: FTBFS on arch:all with qemu-ppce500 target
On 2022-01-25, Vagrant Cascadian wrote:
> On 2022-01-15, Aurelien Jarno wrote:
>> On 2022-01-11 16:40, Vagrant Cascadian wrote:
>>> On 2022-01-11, Lennart Sorensen wrote:
>>> > On Mon, Jan 10, 2022 at 05:10:04PM -0800, Vagrant Cascadian wrote:
>>> >> Something in the toolchain recently changed which causes u-boot arch:all
>>> >> build to FTBFS... I suspect binutils, as building in "bookworm" still
>>> >> works fine where binutils hasn't yet migrated.
>>> >>
>>> >> On arch:all builds the qemu-ppce500 target is cross-compiled.
>>> >>
>>> >> Full log:
>>> >>
>>> >>
>>> >> https://buildd.debian.org/status/fetch.php?pkg=u-boot=all=2022.01%2Bdfsg-1=1641860624=0
>>> >>
>>> >> The hopefully relevent lines from the build log:
...
>>> >> {standard input}: Assembler messages:
>>> >> {standard input}:127: Error: unrecognized opcode: `tlbre'
>>> >> {standard input}:418: Error: unrecognized opcode: `tlbre'
>>> >> {standard input}:821: Error: unrecognized opcode: `msync'
>>> >> {standard input}:821: Error: unrecognized opcode: `tlbwe'
>>> >> {standard input}:884: Error: unrecognized opcode: `tlbsx'
>>> >> make[4]: *** [/<>/scripts/Makefile.build:253:
>>> >> arch/powerpc/cpu/mpc85xx/tlb.o] Error 1
>>> >> make[3]: *** [/<>/Makefile:1810: arch/powerpc/cpu/mpc85xx]
>>> >> Error 2
>>> >> make[3]: *** Waiting for unfinished jobs
>>> >> powerpc-linux-gnu-gcc -Wp,-MD,arch/powerpc/lib/.traps.o.d -nost
> ...
>>> The binutils versions appear to be:
>>>
>>> succeeding, bookworm 2.37-10.1
>>> failing, sid 2.37.50.20220106-2
>>>
>>
>> Yep, this is due to commit b25f942e18d6ecd7ec3e2d2e9930eb4f996c258a on
>> the binutils side [1], which changes the behavior of `.machine`
>> directives to override, rather than augment, the base CPU. GCC is called
>> with -Wa,-me500 to enable PowerPC e500 instructions on the assembler
>> side, but as the default GCC machine is ppc, a `.set machine ppc` is
>> emitted at the beginning of the assembly code.
>>
>> One option would be to force the CPU to e500 on the GCC side, however
>> support for it has been removed. The options is therefore to force the
>> machine in the assembly code. This is what the attached patch does.
>
> Somehow I missed that you had attached a patch! I will try to get this
> tested and uploaded to Debian soon...
Your patch fixed building qemu-ppce500, but now I think we have a
potentially similar problem with qemu-riscv64 and qemu-riscv64_smode:
/<>/arch/riscv/cpu/cpu.c: Assembler messages:
/<>/arch/riscv/cpu/cpu.c:94: Error: unrecognized opcode
`csrs sstatus,a5'
/<>/arch/riscv/cpu/cpu.c:95: Error: unrecognized opcode
`csrw 0x003,0'
make[4]: *** [/<>/scripts/Makefile.build:254:
arch/riscv/cpu/cpu.o] Error 1
make[3]: *** [/<>/Makefile:1810: arch/riscv/cpu] Error 2
make[3]: Leaving directory
'/<>/debian/build/qemu-riscv64_smode'
live well,
vagrant
>> --- u-boot-2022.01+dfsg.orig/arch/powerpc/cpu/mpc85xx/tlb.c
>> +++ u-boot-2022.01+dfsg/arch/powerpc/cpu/mpc85xx/tlb.c
>> @@ -50,7 +50,10 @@ void read_tlbcam_entry(int idx, u32 *val
>> u32 _mas1;
>>
>> mtspr(MAS0, FSL_BOOKE_MAS0(1, idx, 0));
>> -asm volatile("tlbre;isync");
>> +asm volatile(".machine push;\n"
>> + ".machine e500;\n"
>> + "tlbre;isync;\n"
>> + ".machine pop;\n");
>> _mas1 = mfspr(MAS1);
>>
>> *valid = (_mas1 & MAS1_VALID);
>> @@ -109,7 +112,10 @@ void init_used_tlb_cams(void)
>> /* walk all the entries */
>> for (i = 0; i < num_cam; i++) {
>> mtspr(MAS0, FSL_BOOKE_MAS0(1, i, 0));
>> -asm volatile("tlbre;isync");
>> +asm volatile(".machine push;\n"
>> + ".machine e500;\n"
>> + "tlbre;isync;\n"
>> + ".machine pop;");
>> if (mfspr(MAS1) & MAS1_VALID)
>> use_tlb_cam(i);
>> }
>> @@ -183,7 +189,10 @@ void disable_tlb(u8 esel)
>> #ifdef CONFIG_ENABLE_36BIT_PHYS
>> mtspr(MAS7, 0);
>> #endif
>> -asm volatile("isync;msync;tlbwe;isync");
>> +asm volatile(".machine push;\n"
>> + ".machine e500;\n"
>> + "isync;msync;tlbwe;isync;\n"
>> + ".machine pop;\n");
>>
>> #ifdef CONFIG_ADDR_MAP
>> if (gd->flags & GD_FLG_RELOC)
>> @@ -193,7 +202,11 @@ void disable_tlb(u8 esel)
>>
>> static void tlbsx (const volatile unsigned *addr)
>> {
>> -__asm__ __volatile__ ("tlbsx 0,%0" : : "r" (addr), "m" (*addr));
>> +__asm__ __volatile__ (".machine push;\n"
>> + ".machine e500;\n"
>> + "tlbsx 0,%0;\n"
>> + ".machine pop;\n"
>> + : : "r" (addr), "m" (*addr));
>> }
>>
>> /* return -1 if we didn't find anything */
signature.asc
Description: PGP signature
Re: Bug#1003490: u-boot: FTBFS on arch:all with qemu-ppce500 target
A bug in Debian is causing a build failure of the qemu-ppce500 target:
https://bugs.debian.org/1003490
I've CCed u-boot in case they're not aware of the issue.
Some background follows...
On 2022-01-15, Aurelien Jarno wrote:
> On 2022-01-11 16:40, Vagrant Cascadian wrote:
>> On 2022-01-11, Lennart Sorensen wrote:
>> > On Mon, Jan 10, 2022 at 05:10:04PM -0800, Vagrant Cascadian wrote:
>> >> Something in the toolchain recently changed which causes u-boot arch:all
>> >> build to FTBFS... I suspect binutils, as building in "bookworm" still
>> >> works fine where binutils hasn't yet migrated.
>> >>
>> >> On arch:all builds the qemu-ppce500 target is cross-compiled.
>> >>
>> >> Full log:
>> >>
>> >>
>> >> https://buildd.debian.org/status/fetch.php?pkg=u-boot=all=2022.01%2Bdfsg-1=1641860624=0
>> >>
>> >> The hopefully relevent lines from the build log:
>> >>
>> >> powerpc-linux-gnu-gcc -Wp,-MD,arch/powerpc/cpu/mpc85xx/.tlb.o.d
>> >> -nostdinc -isystem /usr/lib/gcc-cross/powerpc-linux-gnu/11/include
>> >> -Iinclude -I/<>/include
>> >> -I/<>/arch/powerpc/include -include
>> >> /<>/include/linux/kconfig.h
>> >> -I/<>/arch/powerpc/cpu/mpc85xx -Iarch/powerpc/cpu/mpc85xx
>> >> -D__KERNEL__ -D__UBOOT__ -Wall -Wstrict-prototypes -Wno-format-security
>> >> -fno-builtin -ffreestanding -std=gnu11 -fshort-wchar -fno-strict-aliasing
>> >> -fno-PIE -Os -fno-stack-protector -fno-delete-null-pointer-checks
>> >> -Wno-pointer-sign -Wno-stringop-truncation -Wno-zero-length-bounds
>> >> -Wno-array-bounds -Wno-stringop-overflow -Wno-maybe-uninitialized
>> >> -fmacro-prefix-map=/<>/= -g -fstack-usage
>> >> -Wno-format-nonliteral -Wno-address-of-packed-member
>> >> -Wno-unused-but-set-variable -Werror=date-time -Wno-packed-not-aligned
>> >> -D__powerpc__ -ffixed-r2 -m32 -fno-ira-hoist-pressure -Wa,-me500
>> >> -msoft-float -mno-string -fpic -mrelocatable -ffunction-sections
>> >> -fdata-sections -mcall-linux -msingle-pic-base -fno-jump-tables -pipe
>> >> -DKBUILD_BASENAME='"tlb"' -DKBUILD_MODNAME='"tlb"' -c -o
>> >> arch/powerpc/cpu/mpc85xx/tlb.o
>> >> /<>/arch/powerpc/cpu/mpc85xx/tlb.c
>> >> ...
>> >> {standard input}: Assembler messages:
>> >> {standard input}:127: Error: unrecognized opcode: `tlbre'
>> >> {standard input}:418: Error: unrecognized opcode: `tlbre'
>> >> {standard input}:821: Error: unrecognized opcode: `msync'
>> >> {standard input}:821: Error: unrecognized opcode: `tlbwe'
>> >> {standard input}:884: Error: unrecognized opcode: `tlbsx'
>> >> make[4]: *** [/<>/scripts/Makefile.build:253:
>> >> arch/powerpc/cpu/mpc85xx/tlb.o] Error 1
>> >> make[3]: *** [/<>/Makefile:1810: arch/powerpc/cpu/mpc85xx]
>> >> Error 2
>> >> make[3]: *** Waiting for unfinished jobs
>> >> powerpc-linux-gnu-gcc -Wp,-MD,arch/powerpc/lib/.traps.o.d -nost
...
>> The binutils versions appear to be:
>>
>> succeeding, bookworm 2.37-10.1
>> failing, sid 2.37.50.20220106-2
>>
>
> Yep, this is due to commit b25f942e18d6ecd7ec3e2d2e9930eb4f996c258a on
> the binutils side [1], which changes the behavior of `.machine`
> directives to override, rather than augment, the base CPU. GCC is called
> with -Wa,-me500 to enable PowerPC e500 instructions on the assembler
> side, but as the default GCC machine is ppc, a `.set machine ppc` is
> emitted at the beginning of the assembly code.
>
> One option would be to force the CPU to e500 on the GCC side, however
> support for it has been removed. The options is therefore to force the
> machine in the assembly code. This is what the attached patch does.
Somehow I missed that you had attached a patch! I will try to get this
tested and uploaded to Debian soon...
live well,
vagrant
> --- u-boot-2022.01+dfsg.orig/arch/powerpc/cpu/mpc85xx/tlb.c
> +++ u-boot-2022.01+dfsg/arch/powerpc/cpu/mpc85xx/tlb.c
> @@ -50,7 +50,10 @@ void read_tlbcam_entry(int idx, u32 *val
> u32 _mas1;
>
> mtspr(MAS0, FSL_BOOKE_MAS0(1, idx, 0));
> - asm volatile("tlbre;isync");
> + asm volatile(".machine push;\n"
> + ".machine e500;\n"
> + "tlbre;isync;\n"
> + ".machine pop;\n");
> _mas1 = mfspr(MAS1);
>
[PATCH 11/11] drivers/usb/gadget/dwc2_udc_otg.c: Fix spelling of "resetting".
---
drivers/usb/gadget/dwc2_udc_otg.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/gadget/dwc2_udc_otg.c
b/drivers/usb/gadget/dwc2_udc_otg.c
index 2f31814442..b30604eba0 100644
--- a/drivers/usb/gadget/dwc2_udc_otg.c
+++ b/drivers/usb/gadget/dwc2_udc_otg.c
@@ -461,7 +461,7 @@ static void reconfig_usbd(struct dwc2_udc *dev)
u32 max_hw_ep;
int pdata_hw_ep;
- debug("Reseting OTG controller\n");
+ debug("Resetting OTG controller\n");
dflt_gusbcfg =
0<<15 /* PHY Low Power Clock sel*/
--
2.30.2
[PATCH 09/11] arch/arm/mach-keystone/ddr3.c: Fix spelling of "resetting".
---
arch/arm/mach-keystone/ddr3.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-keystone/ddr3.c b/arch/arm/mach-keystone/ddr3.c
index 9ee3284156..53117c2695 100644
--- a/arch/arm/mach-keystone/ddr3.c
+++ b/arch/arm/mach-keystone/ddr3.c
@@ -344,7 +344,7 @@ void ddr3_check_ecc_int(u32 base)
puts("DDR3 ECC 2-bit error interrupted\n");
if (!ecc_test) {
- puts("Reseting the device ...\n");
+ puts("Resetting the device ...\n");
reset_cpu();
}
}
--
2.30.2
[PATCH 10/11] drivers/ddr/altera/sequencer.c: Fix spelling of "resetting".
--- drivers/ddr/altera/sequencer.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/ddr/altera/sequencer.c b/drivers/ddr/altera/sequencer.c index 8a016f0628..e402f2929a 100644 --- a/drivers/ddr/altera/sequencer.c +++ b/drivers/ddr/altera/sequencer.c @@ -2770,7 +2770,7 @@ rw_mgr_mem_calibrate_dqs_enable_calibration(struct socfpga_sdrseq *seq, ret = rw_mgr_mem_calibrate_vfifo_find_dqs_en_phase(seq, rw_group); debug_cond(DLEVEL >= 1, - "%s:%d: g=%u found=%u; Reseting delay chain to zero\n", + "%s:%d: g=%u found=%u; Resetting delay chain to zero\n", __func__, __LINE__, rw_group, !ret); for (r = 0; r < seq->rwcfg->mem_number_of_ranks; -- 2.30.2
[PATCH 07/11] common/fdt_support.c: Fix spelling of "shouldn't".
---
common/fdt_support.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/common/fdt_support.c b/common/fdt_support.c
index 8992ac5d3f..a7dbe0efdf 100644
--- a/common/fdt_support.c
+++ b/common/fdt_support.c
@@ -1407,7 +1407,7 @@ int fdt_get_dma_range(const void *blob, int node,
phys_addr_t *cpu,
node = parent;
parent = fdt_parent_offset(blob, node);
if (parent < 0) {
- printf("Found dma-ranges in root node, shoudln't happen\n");
+ printf("Found dma-ranges in root node, shouldn't happen\n");
ret = -EINVAL;
goto out;
}
--
2.30.2
[PATCH 08/11] drivers/core/of_addr.c: Fix spelling of "shouldn't".
---
drivers/core/of_addr.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/core/of_addr.c b/drivers/core/of_addr.c
index 3fbc0a7afa..431dd4e565 100644
--- a/drivers/core/of_addr.c
+++ b/drivers/core/of_addr.c
@@ -367,7 +367,7 @@ int of_get_dma_range(const struct device_node *dev,
phys_addr_t *cpu,
/* switch to that node */
parent = of_get_parent(dev);
if (!parent) {
- printf("Found dma-ranges in root node, shoudln't happen\n");
+ printf("Found dma-ranges in root node, shouldn't happen\n");
ret = -EINVAL;
goto out;
}
--
2.30.2
[PATCH 06/11] drivers/net/fec_mxc.c: Fix spelling of "resetting".
---
drivers/net/fec_mxc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/fec_mxc.c b/drivers/net/fec_mxc.c
index 40a86a3e12..811bc275c1 100644
--- a/drivers/net/fec_mxc.c
+++ b/drivers/net/fec_mxc.c
@@ -1465,7 +1465,7 @@ static int fecmxc_probe(struct udevice *dev)
start = get_timer(0);
while (readl(>eth->ecntrl) & FEC_ECNTRL_RESET) {
if (get_timer(start) > (CONFIG_SYS_HZ * 5)) {
- printf("FEC MXC: Timeout reseting chip\n");
+ printf("FEC MXC: Timeout resetting chip\n");
goto err_timeout;
}
udelay(10);
--
2.30.2
[PATCH 05/11] cmd/Kconfig: Fix spelling of "resetting".
--- cmd/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/cmd/Kconfig b/cmd/Kconfig index 5b30b13e43..bb11aec9b7 100644 --- a/cmd/Kconfig +++ b/cmd/Kconfig @@ -1012,7 +1012,7 @@ config CMD_IDE select IDE help Provides an 'ide' command which allows accessing the IDE drive, - reseting the IDE interface, printing the partition table and + resetting the IDE interface, printing the partition table and geting device info. It also enables the 'diskboot' command which permits booting from an IDE drive. -- 2.30.2
[PATCH 04/11] arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch2_serdes.c: Fix spelling of "resetting".
--- arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch2_serdes.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch2_serdes.c b/arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch2_serdes.c index 41c89b8904..60769e139e 100644 --- a/arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch2_serdes.c +++ b/arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch2_serdes.c @@ -249,7 +249,7 @@ int setup_serdes_volt(u32 svdd) /* * If SVDD set failed, will not return directly, so that the -* serdes lanes can complete reseting. +* serdes lanes can complete resetting. */ ret = set_serdes_volt(svdd_tar); if (ret) -- 2.30.2
[PATCH 03/11] drivers/usb/musb/musb_udc.c: Fix spelling of "mismatch".
---
drivers/usb/musb/musb_udc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/musb/musb_udc.c b/drivers/usb/musb/musb_udc.c
index b9510e3045..2ffcb7caaa 100644
--- a/drivers/usb/musb/musb_udc.c
+++ b/drivers/usb/musb/musb_udc.c
@@ -269,7 +269,7 @@ static void musb_peri_ep0_set_address(void)
__PRETTY_FUNCTION__, udc_device->address);
} else {
if (debug_level > 0)
- serial_printf("ERROR : %s Address missmatch "
+ serial_printf("ERROR : %s Address mismatch "
"sw %d vs hw %d\n",
__PRETTY_FUNCTION__,
udc_device->address, faddr);
--
2.30.2
[PATCH 02/11] drivers/mtd/ubispl/ubispl.c: Fix spelling of "mismatched".
---
drivers/mtd/ubispl/ubispl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mtd/ubispl/ubispl.c b/drivers/mtd/ubispl/ubispl.c
index 03b31f002b..b58d8e8d56 100644
--- a/drivers/mtd/ubispl/ubispl.c
+++ b/drivers/mtd/ubispl/ubispl.c
@@ -953,7 +953,7 @@ retry:
* Check, if the total number of blocks is correct
*/
if (be32_to_cpu(vh->used_ebs) != last) {
- ubi_dbg("Block count missmatch.");
+ ubi_dbg("Block count mismatch.");
ubi_dbg("vh->used_ebs: %d nrblocks: %d",
be32_to_cpu(vh->used_ebs), last);
generic_set_bit(pnum, ubi->corrupt);
--
2.30.2
[PATCH 01/11] arch/arm/mach-bcm283x/msg.c: Fix spelling of "Failed".
---
arch/arm/mach-bcm283x/msg.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-bcm283x/msg.c b/arch/arm/mach-bcm283x/msg.c
index 01a8ed2a7b..fe243e2dca 100644
--- a/arch/arm/mach-bcm283x/msg.c
+++ b/arch/arm/mach-bcm283x/msg.c
@@ -194,7 +194,7 @@ int bcm2711_notify_vl805_reset(void)
ret = bcm2835_mbox_call_prop(BCM2835_MBOX_PROP_CHAN,
_notify_vl805_reset->hdr);
if (ret) {
- printf("bcm2711: Faild to load vl805's firmware, %d\n", ret);
+ printf("bcm2711: Failed to load vl805's firmware, %d\n", ret);
return -EIO;
}
--
2.30.2
Re: [PATCH v3 2/2] board: mntre: imx8mq: Add MNT Reform 2 board support
On 2021-12-14, Patrick Wildt wrote: > The MNT Reform 2 is a modular DIY laptop. In its initial version it > is based on the BoundaryDevices i.MX8MQ SoM. Some parts have been > lifted from BoundaryDevices official U-Boot downstream project. Successfully loaded u-boot, loaded a kernel and .dtb, thanks! Tested-By: Vagrant Cascadian This may not be specific to this patch series, but one problem I had during build is that it doesn't appear to respect the BL31 environment variable that many other platforms support to specify the path to the ATF firmware; is there a way to add that with binman? Similarly, it would be ideal to have environment variables for the other various firmware (lpddr*.bin, signed-hdmi*.bin) needed to build. The Debian u-boot packages build all boards from a single source, and copying *.bin into the top-level directory for each one at the right time seems trickier than telling each build target where the firmware is via environment variables. A couple relatively small things in the patch itself: > diff --git a/include/configs/imx8mq_reform2.h > b/include/configs/imx8mq_reform2.h > new file mode 100644 > index 00..8aed1acfcf > --- /dev/null > +++ b/include/configs/imx8mq_reform2.h ... > +#define CONFIG_EXTRA_ENV_SETTINGS\ > + BOOTENV \ > + "scriptaddr=" __stringify(CONFIG_SYS_LOAD_ADDR) "\0" \ > + "kernel_addr_r=" __stringify(CONFIG_SYS_LOAD_ADDR) "\0" \ > + "image=Image\0" \ > + "console=ttymxc0,115200\0" \ > + "fdt_addr_r=0x4300\0" \ This should have ramdisk_addr_r, maybe: "ramdisk_addr_r=0x4400\0" Maybe 0x440 is a bit overkill, but anything that that starts sufficiently after fdt_addr_r to leave room for the .dtb file. This is needed to support distro_bootcmd functionality (boot scripts, extlinux.conf support, etc.) where an initrd/initramfs should be an available option. > + "boot_fdt=try\0" \ > + "fdtfile=" CONFIG_DEFAULT_FDT_FILE "\0" \ This should be something like: "fdtfile=freescale/" CONFIG_DEFAULT_FDT_FILE "\0" \ Or maybe CONFIG_DEFAULT_FDT_FILE should have the vendor directory prepended in configs/imx8mq_reform2_defconfig? Not sure which is more correct, but the boot environment should have the vendor directory included in fdtfile one way or another. Thanks again, it is very nice to be able to build my own bootloader. :) live well, vagrant signature.asc Description: PGP signature
Re: [PATCH v2 2/2] board: mntre: imx8mq: Add MNT Reform 2 board support
On 2021-11-11, Patrick Wildt wrote: > On Thu, Nov 11, 2021 at 12:21:26PM +0100, Patrick Wildt wrote: >> On Wed, Nov 10, 2021 at 02:26:54PM -0800, Vagrant Cascadian wrote: >> > On 2021-09-02, Patrick Wildt wrote: >> > > The MNT Reform 2 is a modular DIY laptop. In its initial version it >> > > is based on the BoundaryDevices i.MX8MQ SoM. Some parts have been >> > > lifted from BoundaryDevices official U-Boot downstream project. ... >> > Both simply hanging with: >> > >> > U-Boot SPL 2021.10 (Jan 01 1970 - 00:00:01 +) Still hanging with the below patch... >> There have been a few changes in U-Boot since I sent my patchset, it's >> possible the diff by itself might not be enough. >> >> I will send out a new patchset soon, but the move to Binman doesn't work >> for me yet. It's weird, because I don't see a diff to other i.MX8MQ >> platforms, so I'm still debugging that. Maybe the other i.MX8MQ boards >> don't work with Binman either? >> >> Keep note that the build procedure (how to supply bl31) changes once >> Binman is used. > > I have fixed the issue. My changes depend on Peng's patchset to change > i.MX8MQ to Binman, so I will re-issue a v3 of the patchset as soon as > that is done (to not interfere any further with his patchset). > > 'Attached' you'll find a complete diff you can apply to origin/master, > which includes some of Peng's changes. Let me know how it goes for you. To get it to build, I needed to add this: diff --git a/arch/arm/mach-imx/Makefile b/arch/arm/mach-imx/Makefile index 07954bc201..e51b5317fc 100644 --- a/arch/arm/mach-imx/Makefile +++ b/arch/arm/mach-imx/Makefile @@ -161,9 +161,9 @@ spl/u-boot-spl.cfgout: $(IMX_CONFIG) FORCE $(Q)mkdir -p $(dir $@) $(call if_changed_dep,cpp_cfg) -spl/u-boot-spl-ddr.bin: spl/u-boot-spl.bin spl/u-boot-spl.cfgout FORCE +u-boot-spl-ddr.bin: spl/u-boot-spl.bin spl/u-boot-spl.cfgout FORCE -flash.bin: spl/u-boot-spl-ddr.bin u-boot.itb FORCE +flash.bin: u-boot-spl-ddr.bin u-boot.itb FORCE $(call if_changed,mkimage) endif >> > Is the flash.bin step unecessary? I see DDR timing code in the patch >> > series; are corresponding lpddr4*.bin no longer necessary? >> >> The flash.bin has all bits: U-Boot, U-Boot SPL, lpddr4*.bin and bl31.bin >> >> lpddr4*.bin is the firmware for the DDR controller. So you need the >> timing information *and* the firmware. >> >> > I also tried building with an old version of arm-trusted-firmware >> > (v2.2), as that was the most recent upstream version that successfully >> > built. This seems to be a fork of ATF that has support for iMX8MQ, but >> > it is unclear which branch/tag/etc. should be used with the mnt/reform: >> > >> > https://source.codeaurora.org/external/imx/imx-atf >> >> Not sure right now, but I think I was using the one that's build on >> OpenBSD-current, which seems to be arm-trusted-firmware 2.5. I'll >> check it. I can't get atf 2.5 for imx8mq to build on Debian or GNU Guix; it seems that maybe it is no longer supported upstream: https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/commit/?id=e3c07d2f5a082d8bb1684ca026d1789a77b3c870 Though it's not exactly clear what works... >> > It would be nice to include a board README in the next patch revision to >> > spell out some of the details of exactly which other projects and >> > versions/comments/branches are expected to work with MNT Reform2. >> > >> >> This is nothing specific to the MNT Reform2. It's the same for all >> i.MX8MQ boards. ATF+DDR+U-Boot have to work together, and it doesn't >> matter which board it is. Hence I don't believe providing that kind >> information in a Reform-specific README makes sense. I guess we need a workable README for i.MX8MQ or something, and only boards that differ from that process document the differences? But at the moment, it appears to still be guesswork. live well, vagrant signature.asc Description: PGP signature
Re: [PATCH v2 2/2] board: mntre: imx8mq: Add MNT Reform 2 board support
On 2021-09-02, Patrick Wildt wrote: > The MNT Reform 2 is a modular DIY laptop. In its initial version it > is based on the BoundaryDevices i.MX8MQ SoM. Some parts have been > lifted from BoundaryDevices official U-Boot downstream project. Thanks for working on this! I'm struggling a bit getting it to actually boot; how is this supposed to be installed to the device? I've built with the two applied patches on a patched v2021.10, copying various firmware parts from: https://source.mnt.re/reform/reform-boundary-uboot/-/blob/master/bl31-iMX8MQ.bin https://source.mnt.re/reform/reform-boundary-uboot/-/blob/master/lpddr4_pmu_train_1d_dmem.bin https://source.mnt.re/reform/reform-boundary-uboot/-/blob/master/lpddr4_pmu_train_1d_imem.bin https://source.mnt.re/reform/reform-boundary-uboot/-/blob/master/lpddr4_pmu_train_2d_dmem.bin https://source.mnt.re/reform/reform-boundary-uboot/-/blob/master/lpddr4_pmu_train_2d_imem.bin export BL31=bl31-iMX8MQ.bin make imx8mq_reform2_defconfig make make flash.bin Then grepping various other README's from imx8mq devices, I tried two different processes: dd if=flash.bin of=/dev/sd[x] bs=1K seek=33 and: dd if=flash.bin of=/dev/sd[x] bs=1024 seek=33 conv=sync dd if=u-boot.itb of=/dev/sd[x] bs=1024 seek=384 conv=sync Both simply hanging with: U-Boot SPL 2021.10 (Jan 01 1970 - 00:00:01 +) Is the flash.bin step unecessary? I see DDR timing code in the patch series; are corresponding lpddr4*.bin no longer necessary? I also tried building with an old version of arm-trusted-firmware (v2.2), as that was the most recent upstream version that successfully built. This seems to be a fork of ATF that has support for iMX8MQ, but it is unclear which branch/tag/etc. should be used with the mnt/reform: https://source.codeaurora.org/external/imx/imx-atf It would be nice to include a board README in the next patch revision to spell out some of the details of exactly which other projects and versions/comments/branches are expected to work with MNT Reform2. I would be nice if you could CC me on future patch series revisions to be able to test. Thanks! live well, vagrant > Signed-off-by: Patrick Wildt > --- > arch/arm/dts/imx8mq-mnt-reform2-u-boot.dtsi | 11 + > arch/arm/mach-imx/imx8m/Kconfig |6 + > board/mntre/imx8mq_reform2/Kconfig| 12 + > board/mntre/imx8mq_reform2/MAINTAINERS|7 + > board/mntre/imx8mq_reform2/Makefile | 12 + > board/mntre/imx8mq_reform2/imx8mq_reform2.c | 213 > board/mntre/imx8mq_reform2/lpddr4_timing.c| 1014 + > .../mntre/imx8mq_reform2/lpddr4_timing_ch2.h | 95 ++ > board/mntre/imx8mq_reform2/spl.c | 260 + > configs/imx8mq_reform2_defconfig | 67 ++ > include/configs/imx8mq_reform2.h | 151 +++ > 11 files changed, 1848 insertions(+) > create mode 100644 arch/arm/dts/imx8mq-mnt-reform2-u-boot.dtsi > create mode 100644 board/mntre/imx8mq_reform2/Kconfig > create mode 100644 board/mntre/imx8mq_reform2/MAINTAINERS > create mode 100644 board/mntre/imx8mq_reform2/Makefile > create mode 100644 board/mntre/imx8mq_reform2/imx8mq_reform2.c > create mode 100644 board/mntre/imx8mq_reform2/lpddr4_timing.c > create mode 100644 board/mntre/imx8mq_reform2/lpddr4_timing_ch2.h > create mode 100644 board/mntre/imx8mq_reform2/spl.c > create mode 100644 configs/imx8mq_reform2_defconfig > create mode 100644 include/configs/imx8mq_reform2.h signature.asc Description: PGP signature
Re: [PATCH v4 1/4] tools: Separate image types which depend on OpenSSL
On 2021-10-22, Andre Przywara wrote: > On Fri, 22 Oct 2021 09:47:35 -0700 > Vagrant Cascadian wrote: >> On 2021-10-22, Tom Rini wrote: >> > On Fri, Oct 22, 2021 at 04:56:09PM +0100, Andre Przywara wrote: >> >> On Fri, 22 Oct 2021 11:09:27 -0400 >> >> Tom Rini wrote: >> >> >> > On Fri, Oct 22, 2021 at 04:59:22PM +0200, Marek Behún wrote: >> >> > > On Fri, 22 Oct 2021 12:09:19 +0200 >> >> > > Heinrich Schuchardt wrote: >> >> > > >> >> > > > On 10/21/21 15:00, Marek Behún wrote: >> >> > > > > BTW, wouldn't it be enough to simply imply TOOLS_LIBCRYPTO for >> >> > > > > mvebu >> >> > > > > platform in Kconfig? >> >> > > > > >> >> > > > >> >> > > > We should only use 'imply' for suggested settings and never for >> >> > > > hard >> >> > > > requirements. TOOLS_LIBCRYPTO already defaults to 'Y'. So implying >> >> > > > it >> >> > > > for mvebu would be redundant. >> >> > > > >> >> > > > In an OS distribution we only want to ship a single version of >> >> > > > mkimage. >> >> > > > So it is good to elimate symbol CONFIG_MXS. >> >> > > > >> >> > > > How mkimage is built should not depend on CONFIG_TOOLS_LIBCRYPTO. >> >> > > > >> >> > > > Tom wrote regarding this aspect in >> >> > > > https://lists.denx.de/pipermail/u-boot/2021-September/460251.html: >> >> > > > >> >> > > > "if we're building a generically useful tool, we don't want another >> >> > > > symbol for it." >> >> > > >> >> > > OK, so mkimage and dumpimage should be always generic and always >> >> > > support all platforms, that makes sense, since the tools can be >> >> > > installed as a distribution package. >> >> > > >> >> > > But I still think it should be possible to cripple these tools if the >> >> > > developer wants to disable libcrypto due to embedded environment. >> >> >> >> Well, I don't think this is the real question here, is it? >> >> I think the tools part is clear: distros want to build just mkimage, >> >> supporting as many platforms as possible, and might need to avoid OpenSSL. >> >> This should be covered by TOOLS_LIBCRYPTO=[yn] and "make >> >> tools-only_defconfg && make tools", and Samuel's patch actually fixes the >> >> build (at least somewhat, I still get link errors). >> > >> > The problem is, are distros doing a tools-only build, for tools, or are >> > they doing it per board? Like, hey, ugh, OpenEmbedded uses >> > sandbox_defconfig and cross_tools as the targets. That's not quite what >> > I was hoping to see. So I want to know everyone else is doing, rather >> > than we hope they're doing. >> >> Thanks for bringing this to my attention! >> >> In Debian, the u-boot-tools package is built using tools-only, and for >> each of the board-specific targets, it still ends up building the >> relevent tools, but we throw them away and do not ship them in any >> packages. >> >> With 2021.10, the board-specific builds made it harder to avoid openssl >> with the corresponding tools, and I reluctantly added a dependency on >> openssl... (which is technically permitted in Debian, having declared >> openssl as a system library to avoid the GPL incompatibilities, but >> ... meh.) > > But this is purely a *build-time* dependency only, right? The resulting > images do not have any openssl code in them, they were just *created* > (signed) using that code. > I don't think this a legal issue? The various .h includes are all that I saw, and I *think* all in the tools/ directory, but yeah, if this is really the case that no openssl code ends up in the board-specific binaries, that simplifies things considerably. > The problems are about *shipping* openssl code, which you only do for > u-boot-tools - where it now can be disabled. Probably won't disable it for u-boot-tools in Debian (reluctantly riding on the system library exception), but the tools builds that are part of the build process would be nice to be able to disable. >> I also have been doing some packaging of u-boot for GNU Guix, where I >> suspect the stance wouldn't be as willing to accept such a compromise... >> >> So... I would *love* an option to be able to build a board-only config >> without any of the tools; > > Why is this a problem (see above)? Who is building board builds? It's > either the maintainer when creating the binary package, or a curious user, > right? And they can surely *use* OpenSSL during build time - if it's > needed by the board. Sure, if there is no actual openssl code embedded in the resulting binary with GPLv2 code, it shouldn't be a problem... It's a mess of an issue to tease out exactly what codepaths trigger and do not trigger the compatibility issues between openssl and GPL... Depending on openssl in a project with GPLv2-only code does seem at risk to introduce license compatibility issues without sufficient and constant review and dilligence, even if it is technically ok how it is done right now... live well, vagrant signature.asc Description: PGP signature
Re: [PATCH v4 1/4] tools: Separate image types which depend on OpenSSL
On 2021-10-22, Tom Rini wrote: > On Fri, Oct 22, 2021 at 04:56:09PM +0100, Andre Przywara wrote: >> On Fri, 22 Oct 2021 11:09:27 -0400 >> Tom Rini wrote: >> > On Fri, Oct 22, 2021 at 04:59:22PM +0200, Marek Behún wrote: >> > > On Fri, 22 Oct 2021 12:09:19 +0200 >> > > Heinrich Schuchardt wrote: >> > > >> > > > On 10/21/21 15:00, Marek Behún wrote: >> > > > > BTW, wouldn't it be enough to simply imply TOOLS_LIBCRYPTO for mvebu >> > > > > platform in Kconfig? >> > > > > >> > > > >> > > > We should only use 'imply' for suggested settings and never for hard >> > > > requirements. TOOLS_LIBCRYPTO already defaults to 'Y'. So implying it >> > > > for mvebu would be redundant. >> > > > >> > > > In an OS distribution we only want to ship a single version of >> > > > mkimage. >> > > > So it is good to elimate symbol CONFIG_MXS. >> > > > >> > > > How mkimage is built should not depend on CONFIG_TOOLS_LIBCRYPTO. >> > > > >> > > > Tom wrote regarding this aspect in >> > > > https://lists.denx.de/pipermail/u-boot/2021-September/460251.html: >> > > > >> > > > "if we're building a generically useful tool, we don't want another >> > > > symbol for it." >> > > >> > > OK, so mkimage and dumpimage should be always generic and always >> > > support all platforms, that makes sense, since the tools can be >> > > installed as a distribution package. >> > > >> > > But I still think it should be possible to cripple these tools if the >> > > developer wants to disable libcrypto due to embedded environment. >> >> Well, I don't think this is the real question here, is it? >> I think the tools part is clear: distros want to build just mkimage, >> supporting as many platforms as possible, and might need to avoid OpenSSL. >> This should be covered by TOOLS_LIBCRYPTO=[yn] and "make >> tools-only_defconfg && make tools", and Samuel's patch actually fixes the >> build (at least somewhat, I still get link errors). > > The problem is, are distros doing a tools-only build, for tools, or are > they doing it per board? Like, hey, ugh, OpenEmbedded uses > sandbox_defconfig and cross_tools as the targets. That's not quite what > I was hoping to see. So I want to know everyone else is doing, rather > than we hope they're doing. Thanks for bringing this to my attention! In Debian, the u-boot-tools package is built using tools-only, and for each of the board-specific targets, it still ends up building the relevent tools, but we throw them away and do not ship them in any packages. With 2021.10, the board-specific builds made it harder to avoid openssl with the corresponding tools, and I reluctantly added a dependency on openssl... (which is technically permitted in Debian, having declared openssl as a system library to avoid the GPL incompatibilities, but ... meh.) I also have been doing some packaging of u-boot for GNU Guix, where I suspect the stance wouldn't be as willing to accept such a compromise... So... I would *love* an option to be able to build a board-only config without any of the tools; do some boards use board-specific tools as part of their build processes? live well, vagrant signature.asc Description: PGP signature
[PATCH] tools/image-host.c: Fix spelling of "expected".
Signed-off-by: Vagrant Cascadian
---
tools/image-host.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/image-host.c b/tools/image-host.c
index d3a882ec29..a6b0a94420 100644
--- a/tools/image-host.c
+++ b/tools/image-host.c
@@ -313,7 +313,7 @@ static int fit_image_read_data(char *filename, unsigned
char *data,
/* Check that we have read all the file */
if (n != sbuf.st_size) {
- printf("Can't read all file %s (read %zd bytes, expexted
%lld)\n",
+ printf("Can't read all file %s (read %zd bytes, expected
%lld)\n",
filename, n, (long long)sbuf.st_size);
goto err;
}
--
2.30.2
Re: [PATCH 0/4] sunxi: TOC0 image type support
On 2021-08-22, Tom Rini wrote: > On Sat, Aug 21, 2021 at 09:19:56PM -0500, Samuel Holland wrote: >> On 6/21/21 6:56 PM, Andre Przywara wrote: >> > On Mon, 21 Jun 2021 16:35:37 -0400 >> > Tom Rini wrote: >> >> On Mon, Jun 21, 2021 at 04:43:00PM +0100, Andre Przywara wrote: >> >>> On Sun, 20 Jun 2021 21:55:51 -0500 >> >>> Samuel Holland wrote: >> >>> >> >>> (CC:ing Tom and Simon for the compatibility problem below) >> >>> >> >>> Hi, >> >>> >> This series adds support for the TOC0 image format used by the Allwinner >> secure boot ROM (SBROM). This series has been tested on the following >> SoCs/boards, with the eFuse burnt to enable secure mode: >> - A64: Pine A64 Plus >> - H5: Orange Pi Zero Plus >> - H6: Pine H64 Model B >> - H616: Orange Pi Zero 2 >> >>> >> >>> many thanks for sending this. In general this looks good (will do a >> >>> more thorough review soon), just one thing that bothered me: >> >>> >> >>> This requires OpenSLL 1.1.x. There is nothing really wrong about this, >> >>> but my (admittedly not the freshest) Slackware, but also long term >> >>> distros like RHEL/CentOS (<=7), still come with 1.0.x (headers) only. >> >>> >> >>> I was wondering how important this is? I have the impression that >> >>> embedded developers sometimes use old^Wstable systems, so some people >> >>> might be bitten by it. I think in this case it will affect all user >> >>> trying to build mkimage, regardless of the target platform? >> >>> >> >>> So I wanted to know what to do here? >> >>> - Can we provide some kind of compatibility support? OpenSSL seems >> >>> to provide something: >> >>> https://wiki.openssl.org/index.php/OpenSSL_1.1.0_Changes#Compatibility_Layer >> >>> Haven't tested that fully yet, just downloading that tarball >> >>> does not seem to cut it (or is missing files?). I guess one needs to >> >>> copy some code from the Wiki? >> >>> - Shall we detect missing v1.1.x support (via #if OPENSSL_VERSION_NUMBER >> >>> < 0x1010L) and disable just sunxi_toc0 support in this case? >> >> >> >> There's two things. First, the series should be on top of (sorry!) >> >> https://patchwork.ozlabs.org/project/uboot/patch/20210524202317.1492578-1-mr.nuke...@gmail.com/ >> >> which adds a similar Kconfig option to make building tools easier. >> > >> > So this is on top of Simon's large series? Poor Samuel! Is there a >> > branch somewhere? >> >> Now that all of these have landed, I'm rebasing this series. >> >> >> Second, while I think not supporting openssl 1.0.x is fine, >> > >> > Well, this was not what I was hoping for ;-) >> > I followed the advice on the OpenSSL wiki and now have a rather small >> > compatibility header file, which lets me compile mkimage even against >> > OpenSSL v1.0.2u. It seems like kwbimage.c has similar provisions in >> > place, I guess this could be merged into the external header? >> > Happy to send a patch on top, if this seems useful. >> >> Considering the note from the OpenSSL website: >> >> > Note: The latest stable version is the 1.1.1 series. This is also >> > our Long Term Support (LTS) version, supported until 11th September >> > 2023. All older versions (including 1.1.0, 1.0.2, 1.0.0 and 0.9.8) >> > are now out of support and should not be used. Users of these older >> > versions are encouraged to upgrade to 1.1.1 as soon as possible. >> and the fact that that I don't have access a system with an old OpenSSL, >> I'm not too interested in spending much effort on it. I will, though, >> happily test a patch if you do send one. > > Since this series came up we now also have: > https://patchwork.ozlabs.org/project/uboot/patch/20210729183121.3798261-1-mr.nuke...@gmail.com/ > > So I would rather not see more old openssl compatibility code added. > >> >> I would like >> >> to again ask for someone to spend the time looking at switching to one >> >> of the GPL-compatible libraries as I'm pretty sure it's been raised a >> >> few times that we can't link with openssl like we do. >> > >> > Why is that? Because Apache is not compatible with GPLv2? The OpenSSL >> > webpage says that: >> > "Can I use OpenSSL with GPL software? >> > On many systems including the major Linux and BSD distributions, yes >> > (the GPL does not place restrictions on using libraries that are part >> > of the normal operating system distribution)." >> > And for mkimage we just build a regular userspace tool, which is linked >> > against the system installed OpenSSL library. From my understanding >> > this is what this quote above means with being permitted? >> > >> > And what would be the alternatives? Take one of the smaller ones and >> > embed them into the code? >> > Otherwise we would probably need to pick something that is widely >> > available and shipped with distros, I guess? Like GnuTLS, >> > libgcrypt, nettle? Maybe LibreSSL? >> > >> > Samuel, do you have an insight what would be a good fit? >> >> My original code was written against
Re: [PATCH] configs: add PineTab defconfig
On 2021-03-07, Nicolas Boulenguez wrote: > From: Arnaud Ferraris > > The PineTab device-tree is already in u-boot, this commit adds the > corresponding > defconfig, based on pinephone_defconfig. > > Signed-off-by: Arnaud Ferraris ... > --- /dev/null > +++ b/configs/pinetab_defconfig ... > +CONFIG_BOOTDELAY=0 Setting bootdelay to 0 it almost impossible to debug issues in a running u-boot. The default of 2 seconds that distro_bootcmd uses tries to strike a balance between not slowing the boot down too much while still being reasonably able to get into a u-boot shell when something goes wrong. Individual users or vendors can set this value as they see fit, but this doesn't seem like a good default for mainline u-boot, at least to me. live well, vagrant signature.asc Description: PGP signature
test/image/test-imagetools.sh: Broken by 3f04db89
It seems like commit: 3f04db891a353f4b127ed57279279f851c6b4917 image: Check for unit addresses in FIT Broke test/image/test-imagetools.sh. I get the impression test-imagetools.sh is more-or-less unmaintained and deprecated. Does test-imagetools.sh perform tests that are not covered elsewhere? If it is not maintained (and especially otherwise covered), it might be worth removing entirely. Thanks for all your work on u-boot! live well, vagrant signature.asc Description: PGP signature
Re: [PATCH 14/25] arm: Remove sheevaplug board
On 2021-02-10, Rick Thomas wrote: > On Wed, Feb 10, 2021, at 5:55 PM, Tom Rini wrote: >> On Wed, Feb 10, 2021 at 05:01:47PM -0800, Rick Thomas wrote: >> > On Wed, Feb 10, 2021, at 12:15 PM, Tom Rini wrote: >> > > I assume that however you're building U-Boot the warnings that get >> > > printed about conversion deadlines having come and gone are hidden in >> > > some way or another. I definitely see some warnings in the build logs, but try to get other people to help with testing and maintaining them in Debian and for most boards there is someone listed who has offered to test new versions: https://salsa.debian.org/debian/u-boot/-/blob/master/debian/targets Unfortunately, mostly I only have evidence of boards I and a few other people have tested: https://wiki.debian.org/U-boot/Status If you use Debian and want the u-boot package to work for your favorite platform working the next release, it would be a really good time to test the packaged u-boot in Debian bullseye Real Soon Now. :) >> > I used to have my sheevaplug's serial console hooked up to a nearby >> > PC. But the PC died a year or so ago, so I don't have any way to >> > watch the messages at boot time. If I need to reboot it, I just >> > ssh to it, type "sudo shutdown -r now" and pray. It hasn't failed >> > me yet (knock wood!). If it starts to fail, I'll have to find >> > another PC to hook up the serial console to, but I figure I'll >> > cross that bridge when I come to it. >> > >> > Now, if anybody wanted me to test a new bit of software on it, I'd >> > have some incentive. >> >> To be clear, have you been updating U-Boot on the device? > > I'm not sure. If it helps, here's what aptitude thinks is installed: > > rbthomas@sheeva:~$ aptitude versions u-boot > i 2019.01+dfsg-7 stable 500 > > I have not recently (since before 2019) done anything more than allow > aptitude to upgrade packages as it thinks best. In particular, I have > not made any attempt to burn new firmware on the device. The debian u-boot packages do not automatically upgrade the u-boot installed to the device; it requires manual intervention on the part of the system administrator above and beyond just upgrading the debian packages through apt, aptitude, etc. I think u-boot upstream is talking about dropping it for 2021.04, so my guess is you would still have another entire debian release cycle with the available 2021.01 version of u-boot *if* that version still works... live well, vagrant signature.asc Description: PGP signature
Boot failure triggered by USB on rockpro64-rk3399 and pinebook-pro-rk3399
It seems rockpro64-rk3399 and pinebook-pro-rk3399 fail to boot when usb is started. It hangs indefinitely at: ## Flattened Device Tree blob at 01f0 Booting using the fdt blob at 0x1f0 I have observed this also using 2020.10 on rockpro64-rk3399, though on pinebook-pro-rk3399 usb does not work and so it basically avoids triggering the issue. Setting CONFIG_USE_PREBOOT=n in the config works around the problem, though obviously by breaking usb keyboard support or booting from USB devices. Related bugs in Debian and manjaro: https://bugs.debian.org/973323 https://bugs.debian.org/980434 https://gitlab.manjaro.org/manjaro-arm/packages/core/uboot-rockpro64/-/issues/4 Boot log: U-Boot 2021.01+dfsg-1 (Jan 17 2021 - 03:50:13 +) SoC: Rockchip rk3399 Reset cause: POR Model: Pine64 RockPro64 v2.1 DRAM: 3.9 GiB PMIC: RK808 MMC: mmc@fe31: 2, mmc@fe32: 1, sdhci@fe33: 0 Loading Environment from SPIFlash... SF: Detected gd25q128 with page size 256 Bytes, erase size 4 KiB, total 16 MiB *** Warning - bad CRC, using default environment In:serial Out: serial Err: serial Model: Pine64 RockPro64 v2.1 Net: eth0: ethernet@fe30 starting USB... Bus usb@fe38: USB EHCI 1.00 Bus usb@fe3a: USB OHCI 1.0 Bus usb@fe3c: USB EHCI 1.00 Bus usb@fe3e: USB OHCI 1.0 Bus dwc3: usb maximum-speed not found Register 2000140 NbrPorts 2 Starting the controller USB XHCI 1.10 scanning bus usb@fe38 for devices... 1 USB Device(s) found scanning bus usb@fe3a for devices... 1 USB Device(s) found scanning bus usb@fe3c for devices... 1 USB Device(s) found scanning bus usb@fe3e for devices... 1 USB Device(s) found scanning bus dwc3 for devices... 1 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found Hit any key to stop autoboot: 0 => printenv preboot preboot=usb start => usb reset resetting USB... Bus usb@fe38: USB EHCI 1.00 Bus usb@fe3a: USB OHCI 1.0 Bus usb@fe3c: USB EHCI 1.00 Bus usb@fe3e: USB OHCI 1.0 Bus dwc3: usb maximum-speed not found Register 2000140 NbrPorts 2 Starting the controller USB XHCI 1.10 scanning bus usb@fe38 for devices... 1 USB Device(s) found scanning bus usb@fe3a for devices... 1 USB Device(s) found scanning bus usb@fe3c for devices... 1 USB Device(s) found scanning bus usb@fe3e for devices... 1 USB Device(s) found scanning bus dwc3 for devices... 1 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found => boot Card did not respond to voltage select! : -110 switch to partitions #0, OK mmc1 is current device Scanning mmc 1:1... Found /extlinux/extlinux.conf Retrieving file: /extlinux/extlinux.conf 144 bytes read in 5 ms (27.3 KiB/s) 1: Debian-Installer Retrieving file: /initrd.gz 28995285 bytes read in 1287 ms (21.5 MiB/s) Retrieving file: /vmlinuz 26922864 bytes read in 1195 ms (21.5 MiB/s) Retrieving file: /dtbs/rockchip/rk3399-rockpro64.dtb 56849 bytes read in 13 ms (4.2 MiB/s) Moving Image from 0x208 to 0x220, end=3c5 ## Flattened Device Tree blob at 01f0 Booting using the fdt blob at 0x1f0 live well, vagrant signature.asc Description: PGP signature
flash-kernel: Add vendor path for some arm64 machines
Package: flash-kernel Tags: patch Control: submitter -1 a.hei...@gmail.com X-Debbugs-Cc: Andre Heider I'm submitting this to the Debian bug tracking system, since this isn't directly related to u-boot. I've dropped most of the CCs on the thread, presumably should also drop the u-boot CC on follow-ups. On 2020-09-03, Andre Heider wrote: > On 03/09/2020 20:59, Vagrant Cascadian wrote: >> On 2020-09-03, Andre Heider wrote: >>> On 03/09/2020 18:40, Dennis Gilmore wrote: >>> If so, adding fdtfile like that would break booting debian using its >>> flash-image. It installs dtbs without that subdir into /boot: >>> /boot/dtbs/4.19.0-9-arm64/armada-3720-espressobin.dtb >>> >>> But it already supports $fdtfile: >>> https://salsa.debian.org/installer-team/flash-kernel/-/blob/master/bootscript/arm64/bootscr.uboot-generic#L32 >>> >>> If I read that script correctly, it would fail to boot with >>> fdtfile=marvell/armada-3720-espressobin.dtb... It probably would fall back to the /boot/dtb-$version symlinks... >> Support for installing in vendor subdirs was added to flash-kernel 3.91 >> from 2018, and I believe the vendor subdirs are included in the >> debian-installer boot media as well. > > alright, but if the vendor path is missing from flash-kernel's db, > everything silently works with a flattened tree. See attached patch, now > it works here too :) Yes, I believe this was intentional to smooth the transition without breaking booting for some machines... > Before: > /boot/dtbs/4.19.0-10-arm64/armada-3720-espressobin.dtb > After: > /boot/dtbs/4.19.0-10-arm64/marvell/armada-3720-espressobin.dtb > > Thanks, > Andre > From 9565a3a066f59258886ad1216ce957d63fd390cc Mon Sep 17 00:00:00 2001 > From: Andre Heider > Date: Thu, 3 Sep 2020 21:33:18 +0200 > Subject: [PATCH] Fix missing vendor subdirs for arm64 boards. > > The subdir is required for installing the fdt file to the correct path, > which is a prerequisite for a boot loader provided $fdtfile. > --- > db/all.db | 8 > 1 file changed, 4 insertions(+), 4 deletions(-) > > diff --git a/db/all.db b/db/all.db > index 16f9606..d7303f7 100644 > --- a/db/all.db > +++ b/db/all.db > @@ -487,7 +487,7 @@ Required-Packages: u-boot-tools > Bootloader-Sets-Incorrect-Root: yes > > Machine: Globalscale Marvell ESPRESSOBin Board > -DTB-Id: armada-3720-espressobin.dtb > +DTB-Id: marvell/armada-3720-espressobin.dtb > Boot-Script-Path: /boot/boot.scr > U-Boot-Script-Name: bootscr.uboot-generic > Required-Packages: u-boot-tools > @@ -874,7 +874,7 @@ Required-Packages: u-boot-tools > > Machine: Marvell Armada 8040 DB board > Kernel-Flavors: arm64 > -DTB-Id: armada-8040-db.dtb > +DTB-Id: marvell/armada-8040-db.dtb > Boot-Script-Path: /boot/boot.scr > U-Boot-Script-Name: bootscr.uboot-generic > Required-Packages: u-boot-tools > @@ -1186,7 +1186,7 @@ Required-Packages: u-boot-tools > > Machine: Olimex A64 Teres-I > Kernel-Flavors: arm64 > -DTB-Id: sun50i-a64-teres-i.dtb > +DTB-Id: allwinner/sun50i-a64-teres-i.dtb > Boot-Script-Path: /boot/boot.scr > U-Boot-Script-Name: bootscr.uboot-generic > Required-Packages: u-boot-tools > @@ -1345,7 +1345,7 @@ Required-Packages: u-boot-tools > > Machine: Purism Librem 5 devkit > Kernel-Flavors: arm64 > -DTB-Id: imx8mq-librem5-devkit.dtb > +DTB-Id: freescale/imx8mq-librem5-devkit.dtb > Boot-Script-Path: /boot/boot.scr > U-Boot-Script-Name: bootscr.uboot-generic > Required-Packages: u-boot-tools > -- > 2.20.1 live well, vagrant signature.asc Description: PGP signature
Re: [PATCH] ARM: Distro boot: document the need for fdtfile variable to be set
On 2020-09-03, Andre Heider wrote: > On 03/09/2020 18:40, Dennis Gilmore wrote: >> When testing builds provided in https://github.com/openwrt/openwrt/pull/3360 >> I discovered that fdtfile was not set and as a result the firmware was not >> functional. So I am documenting what is needed. >> >> Signed-off-by: Dennis Gilmore >> >> Cc: Atish Patra >> Cc: Lukas Auer >> Cc: Tom Rini >> Cc: Masahiro Yamada >> Cc: Vagrant Cascadian >> Cc: Stephen Warren >> Cc: Karsten Merker >> --- >> doc/README.distro | 8 >> 1 file changed, 8 insertions(+) >> >> diff --git a/doc/README.distro b/doc/README.distro >> index 5076bebd18..3eb70aeb14 100644 >> --- a/doc/README.distro >> +++ b/doc/README.distro >> @@ -224,6 +224,14 @@ fdt_addr_r: >> >> A size of 1MB for the FDT/DTB seems reasonable. >> >> +fdtfile: >> + >> + Mandatory. the name of the DTB file for the specific board for instance >> + the espressobin v5 board the value is >> "marvell/armada-3720-espressobin.dtb" >> + while on a clearfog pro it is "armada-388-clearfog-pro.dtb" in the case of >> + a board providing its firmware based DTB this value can be used to >> override >> + the DTB with a different DTB. Thanks for documenting this! With my Debian hat on... Reviewed-by: Vagrant Cascadian > is that really supposed to include the vendor subdir on arm64? Yes. > If so, adding fdtfile like that would break booting debian using its > flash-image. It installs dtbs without that subdir into /boot: > /boot/dtbs/4.19.0-9-arm64/armada-3720-espressobin.dtb > > But it already supports $fdtfile: > https://salsa.debian.org/installer-team/flash-kernel/-/blob/master/bootscript/arm64/bootscr.uboot-generic#L32 > > If I read that script correctly, it would fail to boot with > fdtfile=marvell/armada-3720-espressobin.dtb... Support for installing in vendor subdirs was added to flash-kernel 3.91 from 2018, and I believe the vendor subdirs are included in the debian-installer boot media as well. live well, vagrant signature.asc Description: PGP signature
Re: [PATCH v2] fit_image: Use calloc() to fix reproducibility issue
On 2020-07-27, Fabio Estevam wrote:
> Vagrant Cascadian reported that mx6cuboxi target no longer builds
> reproducibility on Debian.
>
> One example of builds mismatches:
>
> 00096680: 696e 6700 736f 756e 642d 6461 6900 6465 ing.sound-dai.de
> -00096690: 7465 6374 2d67 7069 6f73 tect-gpios..
> +00096690: 7465 6374 2d67 7069 6f73 0061tect-gpios.a
>
> This problem happens because all the buffers in fit_image.c are
> allocated via malloc(), which does not zero out the allocated buffer.
>
> Using calloc() fixes this unpredictable behaviour as it guarantees
> that the allocated buffer are zero initialized.
>
> Reported-by: Vagrant Cascadian
> Suggested-by: Tom Rini
> Signed-off-by: Fabio Estevam
Tested that it boots on the mx6cuboxi supported board hummingboard i2ex,
and that it fixes the reproducibility issues.
Thanks!
Tested-by: Vagrant Cascadian
live well,
vagrant
> ---
> Changes since v1:
> - Improve the commit log description by stating why calloc() helps.
>
> tools/fit_image.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/tools/fit_image.c b/tools/fit_image.c
> index a082d9386d..0c6185d892 100644
> --- a/tools/fit_image.c
> +++ b/tools/fit_image.c
> @@ -388,7 +388,7 @@ static int fit_build(struct image_tool_params *params,
> const char *fname)
> size = fit_calc_size(params);
> if (size < 0)
> return -1;
> - buf = malloc(size);
> + buf = calloc(1, size);
> if (!buf) {
> fprintf(stderr, "%s: Out of memory (%d bytes)\n",
> params->cmdname, size);
> @@ -467,7 +467,7 @@ static int fit_extract_data(struct image_tool_params
> *params, const char *fname)
>* Allocate space to hold the image data we will extract,
>* extral space allocate for image alignment to prevent overflow.
>*/
> - buf = malloc(fit_size + (align_size * image_number));
> + buf = calloc(1, fit_size + (align_size * image_number));
> if (!buf) {
> ret = -ENOMEM;
> goto err_munmap;
> @@ -572,7 +572,7 @@ static int fit_import_data(struct image_tool_params
> *params, const char *fname)
>
> /* Allocate space to hold the new FIT */
> size = sbuf.st_size + 16384;
> - fdt = malloc(size);
> + fdt = calloc(1, size);
> if (!fdt) {
> fprintf(stderr, "%s: Failed to allocate memory (%d bytes)\n",
> __func__, size);
> @@ -673,7 +673,7 @@ static int copyfile(const char *src, const char *dst)
> goto out;
> }
>
> - buf = malloc(512);
> + buf = calloc(1, 512);
> if (!buf) {
> printf("Can't allocate buffer to copy file\n");
> goto out;
> --
> 2.17.1
signature.asc
Description: PGP signature
Re: Reproducibility regression with mx6cuboxi
On 2020-07-26, Fabio Estevam wrote: > On Sun, Jul 26, 2020 at 2:16 PM Tom Rini wrote: > >> I mean just literally changing the malloc(...) to calloc(1, ...), audit any >> other malloc(...) calls in the file and change nothing else. Thanks! > > Thanks for the clarification, Tom > > Vagrant, > > Does the patch below fix the reproducibility regression? > https://pastebin.com/raw/MWDUDrJ2 That appears to build reproducibly for me on top of v2020.07. Haven't tested if the resulting image boots. FWIW, re-applying Marek's old patch also appeared to fix the reproducibility issues: 20a154f95bfe0a3b5bfba90bea7f001c58217536 mkimage: fit: Do not tail-pad fitImage with external data Thanks all, seems a fix is near! live well, vagrant signature.asc Description: PGP signature
Re: Reproducibility regression with mx6cuboxi
On 2020-07-21, Tom Rini wrote: > On Sun, Jul 19, 2020 at 11:23:05AM -0700, Vagrant Cascadian wrote: > >> The mx6cuboxi target no longer builds reproducibility on Debian. I've >> bisected it down to: >> >> eb9124f5748c96ffd548e50fd6989c3b5395b353 mx6cuboxi: enable OF_CONTROL with >> DM_MMC and DM_USB > > Are you tracking any other platforms which use OF_CONTROL? Thanks! Several in the imx family, all of which appear to be building reproducibly: $ zgrep CONFIG_OF_CONTROL=y usr/share/doc/u-boot-imx/configs/config.* usr/share/doc/u-boot-imx/configs/config.dh_imx6.gz:CONFIG_OF_CONTROL=y usr/share/doc/u-boot-imx/configs/config.mx6cuboxi.gz:CONFIG_OF_CONTROL=y usr/share/doc/u-boot-imx/configs/config.mx6qsabrelite.gz:CONFIG_OF_CONTROL=y usr/share/doc/u-boot-imx/configs/config.nitrogen6q.gz:CONFIG_OF_CONTROL=y usr/share/doc/u-boot-imx/configs/config.novena-rawsd.gz:CONFIG_OF_CONTROL=y usr/share/doc/u-boot-imx/configs/config.novena.gz:CONFIG_OF_CONTROL=y usr/share/doc/u-boot-imx/configs/config.wandboard.gz:CONFIG_OF_CONTROL=y dh_imx6 did have reproducibility issues around u-boot 2020.04, but haven't seen them in 2020.07-rc1 or newer, so I haven't bothered to bisect or look into it further. CONFIG_OF_CONTROL is enabled in many other boards in the Debian packages without issue. The dra7xx_evm platform has reproducibility issues introduced approximately the same time, but I haven't been able to trigger the issue in my local test environment (which is a little less comprehensive than what tests.reproducible-builds.org does). I'll try to do some more testing of that one soon, but that should probably be it's own thread as it seems unrelated. live well, vagrant signature.asc Description: PGP signature
Reproducibility regression with mx6cuboxi
The mx6cuboxi target no longer builds reproducibility on Debian. I've
bisected it down to:
eb9124f5748c96ffd548e50fd6989c3b5395b353 mx6cuboxi: enable OF_CONTROL with
DM_MMC and DM_USB
Based on the diffoscope output, it *might* have something to do with the
changes to how board detection uses gpios:
--- /tmp/tmpj_t0iqs7/control
+++ /tmp/tmpj_t0iqs7/experiment-time
│ --- /tmp/tmpj_t0iqs7/control/source-root
├── +++ /tmp/tmpj_t0iqs7/experiment-time/source-root
│ │ --- /tmp/tmpj_t0iqs7/control/source-root/u-boot-with-spl.imx
│ ├── +++ /tmp/tmpj_t0iqs7/experiment-time/source-root/u-boot-with-spl.imx
│ │ @@ -4346,16 +4346,16 @@
│ │ 00010f90:
│ │ 00010fa0:
│ │ 00010fb0:
│ │ 00010fc0:
│ │ 00010fd0:
│ │ 00010fe0:
│ │ 00010ff0:
│ │ -00011000: 2705 1956 7088 eb01 5f14 7b49 0008 565c '..Vp..._.{I..V\
│ │ -00011010: 1780 1780 9463 4032 1102 0500 .c@2
│ │ +00011000: 2705 1956 36e7 7190 5f14 7b49 0008 565c '..V6.q._.{I..V\
│ │ +00011010: 1780 1780 de74 408a 1102 0500 .t@.
│ │ 00011020:
│ │ 00011030:
│ │ 00011040: b800 00ea 14f0 9fe5 14f0 9fe5 14f0 9fe5
│ │ 00011050: 14f0 9fe5 14f0 9fe5 14f0 9fe5 14f0 9fe5
│ │ 00011060: 6000 8017 c000 8017 2001 8017 8001 8017 `... ...
│ │ 00011070: e001 8017 4002 8017 a002 8017 efbe adde @...
│ │ 00011080: 2000 9000 00f0 20e3 00f0 20e3 00f0 20e3 . ... ... .
│ │ @@ -0,15 +0,15 @@
│ │ 00082310: 6c6f 636b 2d6d 6173 7465 7200 7369 6d70 lock-master.simp
│ │ 00082320: 6c65 2d61 7564 696f 2d63 6172 642c 6672 le-audio-card,fr
│ │ 00082330: 616d 652d 6d61 7374 6572 0073 696d 706c ame-master.simpl
│ │ 00082340: 652d 6175 6469 6f2d 6361 7264 2c77 6964 e-audio-card,wid
│ │ 00082350: 6765 7473 0073 696d 706c 652d 6175 6469 gets.simple-audi
│ │ 00082360: 6f2d 6361 7264 2c72 6f75 7469 6e67 0073 o-card,routing.s
│ │ 00082370: 6f75 6e64 2d64 6169 0064 6574 6563 742d ound-dai.detect-
│ │ -00082380: 6770 696f 7300 6275 d00d feed 9e9e gpios.bu
│ │ +00082380: 6770 696f 7300 0023 d00d feed 9e9e gpios..#
│ │ 00082390: 0038 9600 0028 0011 ...8...(
│ │ 000823a0: 0010 089e 95c8
│ │ 000823b0:
│ │ 000823c0: 0001 0003 0004
│ │ 000823d0: 0001 0003 0004
│ │ 000823e0: 000f 0001 0003 0033 ...3
│ │ 000823f0: 001b 536f 6c69 6452 756e 2048 756d SolidRun Hum
│ │ @@ -35868,15 +35868,15 @@
│ │ 0008c1b0: 6c6f 636b 2d6d 6173 7465 7200 7369 6d70 lock-master.simp
│ │ 0008c1c0: 6c65 2d61 7564 696f 2d63 6172 642c 6672 le-audio-card,fr
│ │ 0008c1d0: 616d 652d 6d61 7374 6572 0073 696d 706c ame-master.simpl
│ │ 0008c1e0: 652d 6175 6469 6f2d 6361 7264 2c77 6964 e-audio-card,wid
│ │ 0008c1f0: 6765 7473 0073 696d 706c 652d 6175 6469 gets.simple-audi
│ │ 0008c200: 6f2d 6361 7264 2c72 6f75 7469 6e67 0073 o-card,routing.s
│ │ 0008c210: 6f75 6e64 2d64 6169 0064 6574 6563 742d ound-dai.detect-
│ │ -0008c220: 6770 696f 7300 0023 d00d feed a473 gpios..#...s
│ │ +0008c220: 6770 696f 7300 3230 d00d feed a473 gpios.20...s
│ │ 0008c230: 0038 9b6c 0028 0011 ...8...l...(
│ │ 0008c240: 0010 0907 9b34 ...4
│ │ 0008c250:
│ │ 0008c260: 0001 0003 0004
│ │ 0008c270: 0001 0003 0004
│ │ 0008c280: 000f 0001 0003 002f .../
│ │ 0008c290: 001b 536f 6c69 6452 756e 2048 756d SolidRun Hum
│ │ @@ -38499,8 +38499,8 @@
│ │ 00096620: 2c62 6974 636c 6f63 6b2d 6d61 7374 6572 ,bitclock-master
│ │ 00096630: 0073 696d 706c 652d 6175 6469 6f2d 6361 .simple-audio-ca
│ │ 00096640: 7264 2c66 7261 6d65 2d6d 6173 7465 7200 rd,frame-master.
│ │ 00096650: 7369 6d70 6c65 2d61 7564 696f 2d63 6172 simple-audio-car
│ │ 00096660: 642c 7769 6467 6574 7300 7369 6d70 6c65 d,widgets.simple
│ │ 00096670: 2d61 7564 696f 2d63 6172 642c 726f 7574 -audio-card,rout
│ │ 00096680: 696e 6700 736f 756e 642d 6461 6900 6465 ing.sound-dai.de
│ │ -00096690: 7465 6374 2d67 7069 6f73 tect-gpios..
│ │ +00096690: 7465 6374 2d67 7069 6f73
[PATCH 1/2] cmd: booti: Fix spelling of "environment".
Signed-off-by: Vagrant Cascadian --- cmd/booti.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/cmd/booti.c b/cmd/booti.c index ae37975494..af0603b96e 100644 --- a/cmd/booti.c +++ b/cmd/booti.c @@ -141,7 +141,7 @@ static char booti_help_text[] = "\tspecifying the size of a RAW initrd.\n" "\tCurrently only booting from gz, bz2, lzma and lz4 compression\n" "\ttypes are supported. In order to boot from any of these compressed\n" - "\timages, user have to set kernel_comp_addr_r and kernel_comp_size enviornment\n" + "\timages, user have to set kernel_comp_addr_r and kernel_comp_size environment\n" "\tvariables beforehand.\n" #if defined(CONFIG_OF_LIBFDT) "\tSince booting a Linux kernel requires a flat device-tree, a\n" -- 2.20.1
[PATCH 2/2] doc: sifive: Fix spelling of "environment".
Signed-off-by: Vagrant Cascadian --- doc/board/sifive/fu540.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/doc/board/sifive/fu540.rst b/doc/board/sifive/fu540.rst index 43402cb2e5..39fb8d8990 100644 --- a/doc/board/sifive/fu540.rst +++ b/doc/board/sifive/fu540.rst @@ -35,7 +35,7 @@ Building 1. Add the RISC-V toolchain to your PATH. -2. Setup ARCH & cross compilation enviornment variable: +2. Setup ARCH & cross compilation environment variable: .. code-block:: none @@ -225,7 +225,7 @@ Or if you want to use a compressed kernel image file such as Image.gz =>setenv kernel_comp_addr_r 0x9000 =>setenv kernel_comp_size 0x50 -By this time, correct kernel image is loaded and required enviornment variables +By this time, correct kernel image is loaded and required environment variables are set. You can proceed to load the ramdisk and device tree from the tftp server as well. -- 2.20.1
Re: [PATCH v2 2/2] Makefile: Only build dtc if needed
On 2020-04-27, Simon Glass wrote: > On Sun, 26 Apr 2020 at 18:58, Heinrich Schuchardt wrote: >> >> Am April 27, 2020 12:29:29 AM UTC schrieb Simon Glass : >> >At present U-Boot always builds dtc if CONFIG_OF_CONTROL is defined. >> >This >> >is wasteful when the system already has a suitable version available. >> > >> >Update the Makefile logic to build dtc only if the version available is >> >too old. >> > >> >This saves about 2.5 seconds of elapsed time on a clean build for me. >> > >> >- Add a patch to bring back the dtc-version.sh script >> >- Update the check to make sure libfdt is available if needed >> >> U -Boot has been set up to create reproducible builds. With this >> patch dtc will have to be made a build dependency to provide >> reproducibility. Cf. >> https://www.debian.org/doc/debian-policy/ch-source.html#reproducibility >> >> This may require changes in the packaging of U-Boot in Linux >> distributions. Nothing to stop this patch, just something to keep in >> mind. >> >> You presume that future versions of dtc will always be backward >> compatible with U-Boot. Ok, we do the same for other tools like gcc >> too (with surprises at each new major release). In general when packaging for Debian, the preference is to not use embedded code copies if at all possible. This does require paying attention to backwards and forwards compatibility issues a bit. A simple example: The security team in Debian generally likes to fix a problem in a single source package, rather than an arbitrary number of source packages that happen to share some embedded copy of the code from who knows when... So at least from my perspective, I'd be happy to use the Debian packaged dtc (a.k.a. device-tree-compiler), rather than the one embedded in u-boot sources. Silently switching to the embedded copy sounds a little scary; I would prefer for that to be explicit... a build flag to specify one way or the other and failing is better that being too clever about autodetecting. > Should we disable this check (and always build dtc) when doing a > repeatable build? Is that SOURCE_DATE_EPOCH? And with my Reproducible Builds hat on, builds would ideally *always* be reproducible, given the same sources and toolchain... several distributions and software projects provide information sufficient to reproduce the build environment: https://reproducible-builds.org/docs/recording/ While SOURCE_DATE_EPOCH is definitely one sign that the builder is explicitly attempting to be reproducible; It's a bit of a kludge to try and be more reproducible just because SOURCE_DATE_EPOCH is set. SOURCE_DATE_EPOCH should really only affect the behavior of date or time related things; even better would be to not embded time related information at all! live well, vagrant signature.asc Description: PGP signature
Re: [PATCH 1/5] video: simple_panel: add boe,nv140fhmn49 display
On 2020-04-20, Peter Robinson wrote:
> add "boe,nv140fhmn49" display to compatible node.
I didn't see u-boot output on the eDP panel; not sure if that's
expected. Once linux booted it did work just fine.
live well,
vagrant
> Signed-off-by: Peter Robinson
> Cc: Anatolij Gustschin
> ---
> drivers/video/simple_panel.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/video/simple_panel.c b/drivers/video/simple_panel.c
> index c3c0e84732..572287 100644
> --- a/drivers/video/simple_panel.c
> +++ b/drivers/video/simple_panel.c
> @@ -105,6 +105,7 @@ static const struct udevice_id simple_panel_ids[] = {
> { .compatible = "auo,b133xtn01" },
> { .compatible = "auo,b116xw03" },
> { .compatible = "auo,b133htn01" },
> + { .compatible = "boe,nv140fhmn49" },
> { .compatible = "lg,lb070wv8" },
> { }
> };
> --
> 2.26.1
signature.asc
Description: PGP signature
Re: [PATCH 5/5] Add initial support for the Pinebook Pro laptop from Pine64.
On 2020-04-20, Peter Robinson wrote:
> Specification:
> - Rockchip RK3399
> - 4GB Dual-Channel LPDDR4
> - eMMC socket
> - mSD card slot
> - 128Mbit (16Mb) SPI Flash
> - AP6256 for 11AC WiFi + BT5
> - 14 inch 1920*1080 eDP MiPi display
> - Camera
> - USB 3.0, 2.0 ports
> - Type-C port with alt-mode display (DP 1.2) and 15W charge
> - DC 5V/3A
> - optional PCIe slot for NVMe SSD drive
>
> Signed-off-by: Peter Robinson
Thanks!
Works when applied on v2020.04 with the patch from:
https://lists.denx.de/pipermail/u-boot/2020-April/407652.html
Built and boot tested on Debian and GNU Guix on a Pinebook Pro, so (for
the whole series):
Tested-by: Vagrant Cascadian
live well,
vagrant
> ---
> arch/arm/dts/rk3399-pinebook-pro-u-boot.dtsi | 43 ++
> arch/arm/mach-rockchip/rk3399/Kconfig | 8 ++
> board/pine64/pinebook-pro-rk3399/Kconfig | 15
> board/pine64/pinebook-pro-rk3399/MAINTAINERS | 8 ++
> board/pine64/pinebook-pro-rk3399/Makefile | 1 +
> .../pinebook-pro-rk3399/pinebook-pro-rk3399.c | 76 +
> configs/pinebook-pro-rk3399_defconfig | 84 +++
> include/configs/pinebook-pro-rk3399.h | 29 +++
> 8 files changed, 264 insertions(+)
> create mode 100644 arch/arm/dts/rk3399-pinebook-pro-u-boot.dtsi
> create mode 100644 board/pine64/pinebook-pro-rk3399/Kconfig
> create mode 100644 board/pine64/pinebook-pro-rk3399/MAINTAINERS
> create mode 100644 board/pine64/pinebook-pro-rk3399/Makefile
> create mode 100644 board/pine64/pinebook-pro-rk3399/pinebook-pro-rk3399.c
> create mode 100644 configs/pinebook-pro-rk3399_defconfig
> create mode 100644 include/configs/pinebook-pro-rk3399.h
>
> diff --git a/arch/arm/dts/rk3399-pinebook-pro-u-boot.dtsi
> b/arch/arm/dts/rk3399-pinebook-pro-u-boot.dtsi
> new file mode 100644
> index 00..1a2e24d3ef
> --- /dev/null
> +++ b/arch/arm/dts/rk3399-pinebook-pro-u-boot.dtsi
> @@ -0,0 +1,43 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright (C) 2019 Peter Robinson
> + */
> +
> +#include "rk3399-u-boot.dtsi"
> +#include "rk3399-sdram-lpddr4-100.dtsi"
> +
> +/ {
> + aliases {
> + spi0 =
> + };
> +
> + chosen {
> + u-boot,spl-boot-order = "same-as-spl", ,
> + };
> +};
> +
> + {
> + u-boot,dm-pre-reloc;
> +};
> +
> + {
> + u-boot,dm-pre-reloc;
> +};
> +
> + {
> + max-frequency = <2500>;
> + u-boot,dm-pre-reloc;
> +};
> +
> + {
> + max-frequency = <2000>;
> + u-boot,dm-pre-reloc;
> +};
> +
> + {
> + u-boot,dm-pre-reloc;
> +};
> +
> +_log {
> + regulator-init-microvolt = <95>;
> +};
> diff --git a/arch/arm/mach-rockchip/rk3399/Kconfig
> b/arch/arm/mach-rockchip/rk3399/Kconfig
> index 927bb62a9f..254b9c5b4d 100644
> --- a/arch/arm/mach-rockchip/rk3399/Kconfig
> +++ b/arch/arm/mach-rockchip/rk3399/Kconfig
> @@ -19,6 +19,13 @@ config TARGET_EVB_RK3399
> with full function and physical connectors support like Type-C ports,
> USB.0 host ports, LVDS, JTAG, MAC, SD card, HDMI, USB-to-serial...
>
> +config TARGET_PINEBOOK_PRO_RK3399
> + bool "Pinebook Pro"
> + help
> + Pinebook Pro is a laptop based on the Rockchip rk3399 SoC
> + with 4Gb RAM, onboard eMMC, USB-C, a USB3 and USB2 port,
> + 1920*1080 screen and all the usual laptop features.
> +
> config TARGET_PUMA_RK3399
> bool "Theobroma Systems RK3399-Q7 (Puma)"
> help
> @@ -144,6 +151,7 @@ endif # BOOTCOUNT_LIMIT
>
> source "board/firefly/roc-pc-rk3399/Kconfig"
> source "board/google/gru/Kconfig"
> +source "board/pine64/pinebook-pro-rk3399/Kconfig"
> source "board/pine64/rockpro64_rk3399/Kconfig"
> source "board/rockchip/evb_rk3399/Kconfig"
> source "board/theobroma-systems/puma_rk3399/Kconfig"
> diff --git a/board/pine64/pinebook-pro-rk3399/Kconfig
> b/board/pine64/pinebook-pro-rk3399/Kconfig
> new file mode 100644
> index 00..3bb7ca448e
> --- /dev/null
> +++ b/board/pine64/pinebook-pro-rk3399/Kconfig
> @@ -0,0 +1,15 @@
> +if TARGET_PINEBOOK_PRO_RK3399
> +
> +config SYS_BOARD
> + default "pinebook-pro-rk3399"
> +
> +config SYS_VENDOR
> + default "pine64"
> +
> +config SYS_CONFIG_NAME
> + default "pinebook-pro-rk3399"
> +
> +config BOARD_SPECIFIC_OPTIONS
> + def_bool y
> +
> +endif
> diff --git a/board/pine64/pinebook-pro-rk3399/MAINTAINERS
> b/board/pine64/pinebook-pro-rk3399/MAINTAINERS
> n
Re: [PATCH] drivers: video: rockchip: fix building eDP and LVDS drivers
On 2020-04-20, Peter Robinson wrote: > The rk_edp.c and rk_lvds.c files reference rk_setreg which is declared in > hardware.h so include it so the drivers build. Adjust rk_lvds.c so > includes are in alphabetical order while updating. > > Signed-off-by: Peter Robinson > Reviewed-by: Anatolij Gustschin This fixed the build I was having with the pinebook pro patches when applied to v2020.04, built on both Debian and GNU Guix. Thanks! Tested-by: Vagrant Cascadian > --- > drivers/video/rockchip/rk_edp.c | 1 + > drivers/video/rockchip/rk_lvds.c | 3 ++- > 2 files changed, 3 insertions(+), 1 deletion(-) > > diff --git a/drivers/video/rockchip/rk_edp.c b/drivers/video/rockchip/rk_edp.c > index 8703df0ec0..cf84b886e7 100644 > --- a/drivers/video/rockchip/rk_edp.c > +++ b/drivers/video/rockchip/rk_edp.c > @@ -18,6 +18,7 @@ > #include > #include > #include > +#include > #include > > #define MAX_CR_LOOP 5 > diff --git a/drivers/video/rockchip/rk_lvds.c > b/drivers/video/rockchip/rk_lvds.c > index cf5c0439b1..79e24baf53 100644 > --- a/drivers/video/rockchip/rk_lvds.c > +++ b/drivers/video/rockchip/rk_lvds.c > @@ -13,8 +13,9 @@ > #include > #include > #include > -#include > #include > +#include > +#include > #include > #include > signature.asc Description: PGP signature
Re: Support for Pinebook Pro v2
On 2020-04-20, Peter Robinson wrote: > It took a little longer than I planned, took me a little bit to get it > working with the upstream device tree that landed in 5.7-rc1 but it's > there now. > > Tested with Fedora 32. I was unable to build applied against 2020.04 on Debian or GNU Guix, ending with essentially the same error: ld.bfd: drivers/built-in.o: in function `rk_edp_probe': /<>/drivers/video/rockchip/rk_edp.c:1059: undefined reference to `rk_setreg' ld.bfd: /<>/drivers/video/rockchip/rk_edp.c:1062: undefined reference to `rk_setreg' Segmentation fault Does this depend on patches added to mainline since v2020.04? live well, vagrant signature.asc Description: PGP signature
Re: Bug#955310: u-boot-tools: update list of architectures in mkimage
On 2020-03-29, Chris Dumont wrote: >* What led up to the situation? > read the manpage for mkimage and then used 'mkimage -T -h' ... >* What was the outcome of this action? > The output (ellipsized) > > $ mkimage -T -h > > Invalid image type, supported are: > Unknown image type Unknown image type > aisimage Davinci AIS image > atmelimage ATMEL ROM-Boot Image > filesystem Filesystem Image > ... It appears the recommendation from mkimage help output is to use "mkimage -T list" now. It seems like this should be changed to "-T list" in the manpage. There are several other options -A, -O and -C that also should probably be updated, but those options need an updated to the code as well, as they output the usage information in addition to listing the available Architecture/Os/Compression types: $ mkimage -A list Invalid architecture, supported are: Unknown architecture Unknown architecture Unknown architecture Unknown architecture alphaAlpha arc ARC arm ARM arm64AArch64 ... x86_64 AMD x86_64 xtensa Xtensa Error: Invalid architecture Usage: mkimage -l image -l ==> list image header information mkimage [-x] -A arch -O os -T type -C comp -a addr -e ep -n name -d data_file[:data_file...] image -A ==> set architecture to 'arch' ... -i => input filename for ramdisk file Signing / verified boot not supported (CONFIG_FIT_SIGNATURE undefined) mkimage -V ==> print version information and exit Use '-T list' to see a list of available image types Using "mkimage -T list" just displays the list of image types, from what I can tell, which seems more-or-less fine. I haven't tested anything newer than 2020.04~rc2, so there may be newer fixes upstream... live well, vagrant signature.asc Description: PGP signature
Re: [U-Boot] [PATCH] rockchip: rk3399: Add Pinebook Pro laptop support
On 2019-12-18, Vagrant Cascadian wrote: > On 2019-11-14, Peter Robinson wrote: >> Add initial support for Pinebook Pro laptop. Now that the device-tree is in linux-next (should land in linux 5.7), anyone have a chance to take a stab at a v2 of this patch series? I did a quick-and-dirty attempt, and the TPL/SPL layers worked, but failed to load the main u-boot/atf binaries (mmc issues, I think). live well, vagrant signature.asc Description: PGP signature
Re: AXP813 configuration for BananaPi M3
On 2020-03-08, Bernhard wrote: > I had an additional look for the possible problem with the AXP813 for > BananaPi M3 in U-Boot. > With help of Google, i found a patchset for U-Boot from 2016: > > https://lists.denx.de/pipermail/u-boot/2016-January/240259.html > >> +++ b/configs/Bananapi_m3_defconfig >> @@ -0,0 +1,25 @@ >> +CONFIG_ARM=y >> +CONFIG_ARCH_SUNXI=y >> +CONFIG_MACH_SUN8I_A83T=y >> +CONFIG_DRAM_CLK=480 >> +CONFIG_DRAM_ZQ=15355 >> +CONFIG_DRAM_ODT_EN=y >> +CONFIG_SYS_EXTRA_OPTIONS="DRAM_TYPE=7" >> +#CONFIG_USB0_VBUS_PIN="AXP0-VBUS-ENABLE" >> +#CONFIG_USB0_VBUS_DET="AXP0-VBUS-DETECT" >> +CONFIG_AXP_GPIO=y >> +#CONFIG_USB_MUSB_HOST=y >> +CONFIG_DEFAULT_DEVICE_TREE="sun8i-a83t-bananapi-m3-v1.2" >> +# CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set >> +CONFIG_SPL=y >> +# CONFIG_CMD_IMLS is not set >> +# CONFIG_CMD_FLASH is not set >> +# CONFIG_CMD_FPGA is not set >> +CONFIG_AXP_DCDC1_VOLT=3000 >> +CONFIG_AXP_DCDC2_VOLT=900 >> +CONFIG_AXP_DCDC3_VOLT=900 >> +CONFIG_AXP_DCDC4_VOLT=0 >> +CONFIG_AXP_DCDC5_VOLT=1200 >> +CONFIG_AXP_ALDO2_VOLT=0 >> +CONFIG_AXP_ALDO3_VOLT=0 >> +CONFIG_AXP_DLDO4_VOLT=0 >> -- > > In the Debian configuration, i found the following: > >> CONFIG_ARM=y >> CONFIG_ARCH_SUNXI=y >> CONFIG_NR_DRAM_BANKS=1 >> CONFIG_SPL=y >> CONFIG_MACH_SUN8I_A83T=y >> CONFIG_DRAM_TYPE=7 >> CONFIG_DRAM_CLK=480 >> CONFIG_DRAM_ZQ=15355 >> CONFIG_DRAM_ODT_EN=y >> CONFIG_MMC_SUNXI_SLOT_EXTRA=2 >> CONFIG_INITIAL_USB_SCAN_DELAY=500 >> CONFIG_USB0_VBUS_PIN="AXP0-VBUS-ENABLE" >> CONFIG_USB0_VBUS_DET="AXP0-VBUS-DETECT" >> CONFIG_USB0_ID_DET="PH11" >> CONFIG_USB1_VBUS_PIN="PD24" >> CONFIG_AXP_GPIO=y >> CONFIG_SATAPWR="PD25" >> # CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set >> CONFIG_USE_PREBOOT=y >> CONFIG_CONSOLE_MUX=y >> # CONFIG_SPL_DOS_PARTITION is not set >> # CONFIG_SPL_EFI_PARTITION is not set >> CONFIG_DEFAULT_DEVICE_TREE="sun8i-a83t-bananapi-m3" >> CONFIG_SYS_RELOC_GD_ENV_ADDR=y >> CONFIG_PHY_REALTEK=y >> CONFIG_SUN8I_EMAC=y >> CONFIG_AXP_DCDC5_VOLT=1200 >> CONFIG_AXP_DLDO3_VOLT=3300 >> CONFIG_AXP_SW_ON=y >> CONFIG_USB_EHCI_HCD=y >> CONFIG_USB_OHCI_HCD=y >> CONFIG_USB_MUSB_HOST=y >> CONFIG_SYS_USB_EVENT_POLL_VIA_INT_QUEUE=y I presume this is configs/Sinovoip_BPI_M3_defconfig ? > Some CONFIG_AXP_... are missing in the Debian configuration. > Is it possible, that these missing AXP-configs have to be added in the Debian > configuration? > > If i can do some tests, please let me know. Debian doesn't have any patches that should affect this; CCing upstream. Hopefully someone there has some suggestions or ideas. live well, vagrant signature.asc Description: PGP signature
Re: [PATCH] arm: Enable VIDEO_BPP32 on pinebook.
On 2020-01-18, Maxime Ripard wrote:
> On Sat, Jan 18, 2020 at 03:15:15AM -0800, Vagrant Cascadian wrote:
>> Video output on the pinebook LCD screen was broken by:
>>
>> commit 2cc393f32fd9 ("video: make BPP and ANSI configs optional").
>>
>> Enable VIDEO_BPP32 which was previously enabled by default when
>> DM_VIDEO was set.
>>
>> Signed-off-by: Vagrant Cascadian
>
> There's nothing really specific about the pinebook here, but it's
> needed for pretty much all the boards using DM_VIDEO (on Allwinner at
> least).
>
> You should add a kconfig select / default instead
That would basically revert 2cc393f32fd9, and I figured there was a
reason for it...
It wouldn't surprise me that other systems are affected, but I only
notice this issue on the pinebook (most of the systems I use are
headless), where it definitely needed to be fixed somehow.
If there's a correct and more general fix, please propose it!
live well,
vagrant
[PATCH] arm: Enable VIDEO_BPP32 on pinebook.
Video output on the pinebook LCD screen was broken by:
commit 2cc393f32fd9 ("video: make BPP and ANSI configs optional").
Enable VIDEO_BPP32 which was previously enabled by default when
DM_VIDEO was set.
Signed-off-by: Vagrant Cascadian
---
configs/pinebook_defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/configs/pinebook_defconfig b/configs/pinebook_defconfig
index 929434e25a..306a6bc6b9 100644
--- a/configs/pinebook_defconfig
+++ b/configs/pinebook_defconfig
@@ -22,3 +22,4 @@ CONFIG_SYS_USB_EVENT_POLL_VIA_INT_QUEUE=y
# CONFIG_USB_GADGET is not set
CONFIG_VIDEO_BRIDGE=y
CONFIG_VIDEO_BRIDGE_ANALOGIX_ANX6345=y
+CONFIG_VIDEO_BPP32=y
--
2.20.1
Re: [U-Boot] [PATCH] rockchip: rk3399: Add Pinebook Pro laptop support
On 2019-11-14, Peter Robinson wrote:
> Add initial support for Pinebook Pro laptop.
>
> Specification
> - Rockchip RK3399
> - 4GB Dual-Channel LPDDR4
> - SD card slot
> - eMMC socket
> - 128Mb SPI Flash
> - PCIe 4X slot
> - AP6256 for WiFi + BT
> - 1920*1080 screen
> - USB 3.0, 2.0
> - USB Type C power and data
> - DC 12V/2A
5V/3A, as already mentioned.
> Signed-off-by: Peter Robinson
> ---
>
> Initial v1 for feedback
Tested on u-boot v2020.01-rc5; applied with trivial adjustments.
Thanks for working on it!
Tested-by: Vagrant Cascadian
live well,
vagrant
> U-Boot TPL 2020.01-rc2-5-g7d87be0ff5 (Nov 14 2019 - 00:27:33)
> Trying to boot from BOOTROM
> Returning to boot ROM...
>
> U-Boot SPL 2020.01-rc2-5-g7d87be0ff5 (Nov 14 2019 - 00:27:33 +)
> Trying to boot from MMC1
>
>
> U-Boot 2020.01-rc2-5-g7d87be0ff5 (Nov 14 2019 - 00:27:33 +)
>
> Model: Pine64 Pinebook Pro
> DRAM: 3.9 GiB
> PMIC: RK808
> MMC: dwmmc@fe32: 1, sdhci@fe33: 0
> In:serial@ff1a
> Out: serial@ff1a
> Err: serial@ff1a
> Model: Pine64 Pinebook Pro
> ## Error: Can't overwrite "serial#"
> ## Error inserting "serial#" variable, errno=1
> rockchip_dnl_key_pressed: adc_channel_single_shot fail!
> Net: No ethernet found.
> Hit any key to stop autoboot: 0
> =>
>
>
> arch/arm/dts/Makefile | 1 +
> arch/arm/dts/rk3399-pinebook-pro-u-boot.dtsi | 25 +
> arch/arm/dts/rk3399-pinebook-pro.dts | 631 ++
> arch/arm/mach-rockchip/rk3399/Kconfig | 8 +
> board/pine64/pinebook_pro_rk3399/Kconfig | 15 +
> board/pine64/pinebook_pro_rk3399/MAINTAINERS | 8 +
> board/pine64/pinebook_pro_rk3399/Makefile | 1 +
> .../pinebook_pro_rk3399/pinebook-pro-rk3399.c | 192 ++
> configs/pinebook_pro-rk3399_defconfig | 76 +++
> include/configs/pinebook_pro_rk3399.h | 29 +
> 10 files changed, 986 insertions(+)
> create mode 100644 arch/arm/dts/rk3399-pinebook-pro-u-boot.dtsi
> create mode 100644 arch/arm/dts/rk3399-pinebook-pro.dts
> create mode 100644 board/pine64/pinebook_pro_rk3399/Kconfig
> create mode 100644 board/pine64/pinebook_pro_rk3399/MAINTAINERS
> create mode 100644 board/pine64/pinebook_pro_rk3399/Makefile
> create mode 100644 board/pine64/pinebook_pro_rk3399/pinebook-pro-rk3399.c
> create mode 100644 configs/pinebook_pro-rk3399_defconfig
> create mode 100644 include/configs/pinebook_pro_rk3399.h
>
> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> index 5a64fcc5a7..affedfd666 100644
> --- a/arch/arm/dts/Makefile
> +++ b/arch/arm/dts/Makefile
> @@ -116,6 +116,7 @@ dtb-$(CONFIG_ROCKCHIP_RK3399) += \
> rk3399-nanopi-m4.dtb \
> rk3399-nanopi-neo4.dtb \
> rk3399-orangepi.dtb \
> + rk3399-pinebook-pro.dtb \
> rk3399-puma-ddr1333.dtb \
> rk3399-puma-ddr1600.dtb \
> rk3399-puma-ddr1866.dtb \
> diff --git a/arch/arm/dts/rk3399-pinebook-pro-u-boot.dtsi
> b/arch/arm/dts/rk3399-pinebook-pro-u-boot.dtsi
> new file mode 100644
> index 00..9b0cb7010f
> --- /dev/null
> +++ b/arch/arm/dts/rk3399-pinebook-pro-u-boot.dtsi
> @@ -0,0 +1,25 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright (C) 2019 Peter Robinson
> + */
> +
> +#include "rk3399-u-boot.dtsi"
> +#include "rk3399-sdram-lpddr4-100.dtsi"
> +
> +/ {
> + chosen {
> + u-boot,spl-boot-order = "same-as-spl", ,
> + };
> +};
> +
> + {
> + u-boot,dm-pre-reloc;
> +};
> +
> + {
> +u-boot,dm-pre-reloc;
> +};
> +
> + {
> +u-boot,dm-pre-reloc;
> +};
> diff --git a/arch/arm/dts/rk3399-pinebook-pro.dts
> b/arch/arm/dts/rk3399-pinebook-pro.dts
> new file mode 100644
> index 00..85ce0206d7
> --- /dev/null
> +++ b/arch/arm/dts/rk3399-pinebook-pro.dts
> @@ -0,0 +1,631 @@
> +/*
> + * Copyright (c) 2017 Fuzhou Rockchip Electronics Co., Ltd.
> + *
> + * SPDX-License-Identifier: GPL-2.0+
> + */
> +
> +/dts-v1/;
> +#include
> +#include
> +#include
> +#include "rk3399.dtsi"
> +#include "rk3399-opp.dtsi"
> +
> +/ {
> + model = "Pine64 Pinebook Pro";
> + compatible = "pine64,pinebook-pro", "rockchip,rk3399";
> +
> + chosen {
> + stdout-path =
> + };
> +
> + aliases {
> + spi0 =
> + };
> +
> + backlight: backlight {
> + compatible = "pwm-backlight";
> + enable-gpios = < RK_PA0 GPIO_ACTIVE_HIGH>;
> +
Re: [U-Boot] [PATCH] qemu-riscv64_smode, sifive-fu540: fix extlinux (define preboot)
On 2019-12-18, David Abdurachmanov wrote:
> On Wed, Dec 18, 2019 at 3:13 AM Vagrant Cascadian wrote:
>>
>> On 2019-09-25, Vagrant Cascadian wrote:
>> > On 2019-08-21, David Abdurachmanov wrote:
>> >> Commit 37304aaf60bf92a5dc3ef222ba520698bd862a44 removed preboot
>> >> commands in RISC-V targets and broke extlinux support as reported
>> >> by Fu Wei .
>> >>
>> >> The patch finishes migration of CONFIG_USE_PREBOOT and CONFIG_REBOOT
>> >> to Kconfig.
>> >
>> > Tested using qemu-riscv64_smode and it fixes extlinux booting. Thanks!
>> >
>> > Please CC me on future updates to the patch series.
>> >
>> > Tested-by: Vagrant Cascadian
>>
>> This patch, or something like it, is still needed with u-boot
>> v2020.01-rc5 for extlinux support to load the device-tree from the boot
>> firmware.
>>
>> Is there a new approach in the works, or any chance to see something
>> like this get merged soon?
>
> I do carry several experiment patches in Fedora/RISCV, which I didn't
> yet sent for a review.
> Basically that allows me to boot a single Fedora/RISCV disk image on
> QEMU virt machine
> and SiFive Unleashed.
>
> See:
> http://fedora.riscv.rocks:3000/rpms/uboot-tools/src/branch/master-riscv64/uboot-tools.spec#L36
>
> Note some of the patches were merged in rc5.
Thanks! I'll give your patches some testing when I get a chance.
Some potentially quite naive questions:
> You would want the following two patches:
> http://fedora.riscv.rocks:3000/rpms/uboot-tools/src/branch/master-riscv64/riscv64-set-fdt_addr.patch
Why does it need fdt_addr=0x8800 need to be set (and to the same
value as fdt_addr_r)? According to README fdt_addr is for the flash
media, which I don't think is used in the qemu case, at least. Is
fdt_addr being (ab)used for some other purpose? I guess the README also
gives free reign to use the variables for other purposes... but it would
be good to know why that is needed vs. just using fdt_addr_r as
documented.
> http://fedora.riscv.rocks:3000/rpms/uboot-tools/src/branch/master-riscv64/riscv-bootargs-preboot.patch
CONFIG_PREBOOT="cp.l ${fdtcontroladdr} ${fdt_addr_r} 0x1;"
What does cp.l do?
Do you need to force setting the console in CONFIG_BOOTARGS? It seemed
to autodetect the console on the installations I have running, possibly
getting the chosen console from device-tree?
live well,
vagrant
signature.asc
Description: PGP signature
Re: [U-Boot] [PATCH] qemu-riscv64_smode, sifive-fu540: fix extlinux (define preboot)
On 2019-09-25, Vagrant Cascadian wrote:
> On 2019-08-21, David Abdurachmanov wrote:
>> Commit 37304aaf60bf92a5dc3ef222ba520698bd862a44 removed preboot
>> commands in RISC-V targets and broke extlinux support as reported
>> by Fu Wei .
>>
>> The patch finishes migration of CONFIG_USE_PREBOOT and CONFIG_REBOOT
>> to Kconfig.
>
> Tested using qemu-riscv64_smode and it fixes extlinux booting. Thanks!
>
> Please CC me on future updates to the patch series.
>
> Tested-by: Vagrant Cascadian
This patch, or something like it, is still needed with u-boot
v2020.01-rc5 for extlinux support to load the device-tree from the boot
firmware.
Is there a new approach in the works, or any chance to see something
like this get merged soon?
Thanks!
live well,
vagrant
>> Signed-off-by: David Abdurachmanov
>> ---
>> configs/qemu-riscv64_smode_defconfig | 2 ++
>> configs/sifive_fu540_defconfig | 2 ++
>> include/configs/sifive-fu540.h | 4
>> 3 files changed, 4 insertions(+), 4 deletions(-)
>>
>> diff --git a/configs/qemu-riscv64_smode_defconfig
>> b/configs/qemu-riscv64_smode_defconfig
>> index 74743a5ebe..2e1f7fa91f 100644
>> --- a/configs/qemu-riscv64_smode_defconfig
>> +++ b/configs/qemu-riscv64_smode_defconfig
>> @@ -9,3 +9,5 @@ CONFIG_DISPLAY_CPUINFO=y
>> CONFIG_DISPLAY_BOARDINFO=y
>> # CONFIG_CMD_MII is not set
>> CONFIG_OF_PRIOR_STAGE=y
>> +CONFIG_USE_PREBOOT=y
>> +CONFIG_PREBOOT="setenv fdt_addr ${fdtcontroladdr}; fdt addr
>> ${fdtcontroladdr};"
>> diff --git a/configs/sifive_fu540_defconfig b/configs/sifive_fu540_defconfig
>> index 48865e5f11..a852579309 100644
>> --- a/configs/sifive_fu540_defconfig
>> +++ b/configs/sifive_fu540_defconfig
>> @@ -9,3 +9,5 @@ CONFIG_MISC_INIT_R=y
>> CONFIG_DISPLAY_CPUINFO=y
>> CONFIG_DISPLAY_BOARDINFO=y
>> CONFIG_OF_PRIOR_STAGE=y
>> +CONFIG_USE_PREBOOT=y
>> +CONFIG_PREBOOT="setenv fdt_addr ${fdtcontroladdr}; fdt addr
>> ${fdtcontroladdr};"
>> diff --git a/include/configs/sifive-fu540.h b/include/configs/sifive-fu540.h
>> index 858b7a7da1..ba4aa0652c 100644
>> --- a/include/configs/sifive-fu540.h
>> +++ b/include/configs/sifive-fu540.h
>> @@ -40,8 +40,4 @@
>> "ramdisk_addr_r=0x8830\0" \
>> BOOTENV
>>
>> -#define CONFIG_PREBOOT \
>> -"setenv fdt_addr ${fdtcontroladdr};" \
>> -"fdt addr ${fdtcontroladdr};"
>> -
>> #endif /* __CONFIG_H */
signature.asc
Description: PGP signature
[U-Boot] [PATCH] Enable building of u-boot.itb on Rockchip RK3328 platforms.
The instructions in doc/README.rockchip for installing rock64-rk3328 make use of u-boot.itb, but it is not built by default. Add u-boot.itb to BUILD_TARGET for RK3328 platforms. Signed-off-by: Vagrant Cascadian --- Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Kconfig b/Kconfig index 66b059f749..16491de83d 100644 --- a/Kconfig +++ b/Kconfig @@ -253,7 +253,7 @@ config BUILD_TARGET default "u-boot-spl.kwb" if ARCH_MVEBU && SPL default "u-boot-elf.srec" if RCAR_GEN3 default "u-boot.itb" if SPL_LOAD_FIT && (ROCKCHIP_RK3399 || \ - ARCH_SUNXI || RISCV) + ARCH_SUNXI || RISCV || ROCKCHIP_RK3328) default "u-boot.kwb" if KIRKWOOD default "u-boot-with-spl.bin" if ARCH_AT91 && SPL_NAND_SUPPORT default "u-boot-with-spl.imx" if ARCH_MX6 && SPL -- 2.20.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot-Custodians] [RFC] Minimum Python 3 version?
On 2019-09-27, Heinrich Schuchardt wrote: > On 9/27/19 6:36 PM, Peter Robinson wrote: >>> I'm currently kicking test.py to use Python 3 instead of Python 2.7 and >>> seeing places where it would (seemingly) be nice to be able to say that >>> we have Python 3.6 as our minimum version. To do this however we'll >>> have to tell people using older LTS distributions that they need to >>> figure out the best way for them to install a newer Python is, if they >>> want to run tests at least. ... >>> So, does anyone object to saying that for everything that uses Python to >>> work, Python 3.6 or newer is needed, and for more common tools we'll >>> make best-effort to support older? >> >> That makes sense to me, the el8 distros (RHEL, CentOS etc) have 3.6 >> and el7 has 3.6 available by means, Fedora is at least 3.6 everywhere >> for current releases so I don't think we should have any issues. > > Debian Stretch has Python 3.4.2. > End of life in 2020, end of long term support in 2022 > > Debian Buster has Python 3.7.3 > End of life in 2022. > > I would not expect expect Debian Stretch moving to current U-Boot. So > requiring Python 3.6 to build current U-Boot seems ok for Debian. Python 3.6+ seems good to me, yes. Not planning on backporting anything new to older Debian releases. Thanks for working on the update to python3! live well, vagrant signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] mx6cuboxi fails to load u-boot.img
I just tested mx6cuboxi with 2019.10-rc4, and it fails to load u-boot.img from MMC: 1 2019-09-26_17:31:27.63089 U-Boot SPL 2019.10-rc4+dfsg-1 (Sep 24 2019 - 08:03:23 +) 2 2019-09-26_17:31:27.63092 Trying to boot from MMC2 3 2019-09-26_17:31:27.63095 MMC Device 1 not found 4 2019-09-26_17:31:27.63097 spl: could not find mmc device 1. error: -19 5 2019-09-26_17:31:27.63099 SPL: failed to boot from all boot devices 6 2019-09-26_17:31:27.63101 ### ERROR ### Please RESET the board ### Works fine with 2019.07. < xypron> vagrantc: CONFIG_DM_MMC, CONFIG_DM_USB is not used. The board still uses the pre-driver-model drivers. So a candidate to be kicked out of U-Boot. Happy to test patches; I have several mx6cuboxi supported models available. live well, vagrant signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] dcache issues with wandboard too (was: [PATCH V2 0/7] ARM: imx: Update Novena to DM/DT)
On 2019-08-20, Vagrant Cascadian wrote: > On 2019-08-19, Marek Vasut wrote: >> On 6/4/19 9:06 AM, Vagrant Cascadian wrote: >>> On 2019-05-17, Marek Vasut wrote: >>>> Update Kosagi Novena to DM / DT and remove the warnings. > ... >>> I have two oustanding issues... with some files it sometimes fails to >>> load one or more from SATA: >>> >>> Retrieving file: /boot/initrd.img-5.0.0-trunk-armmp >>> 20077960 bytes read in 375 ms (51.1 MiB/s) >>> Retrieving file: /boot/vmlinuz-5.0.0-trunk-armmp >>> 4215296 bytes read in 40 ms (100.5 MiB/s) >>> append: root=UUID=9666ab0b-f932-4e2f-95d7-0e96a12a4540 ro quiet >>> Retrieving file: /usr/lib/linux-image-5.0.0-trunk-armmp/imx6q-novena.dtb >>> CACHE: Misaligned operation at range [fafb5398, fafb6398] >>> CACHE: Misaligned operation at range [fafb5398, fafb6398] >>> ERROR: v7_outer_cache_inval_range - start address is not aligned - >>> 0xfafb5398 >>> ERROR: v7_outer_cache_inval_range - stop address is not aligned - >>> 0xfafb6398 >>> invalid extent block >>> >>> It then falls back to one of the other kernels (using the extlinux.conf >>> parsing) and succeeds. It consistantly gets a cache/alignment error with >>> this specific file. A bit-for-bit identical .dtb loaded from another >>> path works just fine. Older versions of u-boot boot this fine. Would >>> some particular EXT4 flag possibly be causing issues? >> >> I don't know. Do you still run into this with u-boot/master ? > > Still occurring with 2019.10-rc2. Haven't tested with master yet. > > Using "dcache off" before booting still outputs the CACHE and ERROR > messages, but does successfully boot. Also seeing this problem with wandboard solo with 2019.10-rc4 booting from microSD. Haven't retested with novena recently. Setting CONFIG_SYS_DCACHE_OFF=y avoids the need to manually type "dcache off" ... though obviously doesn't address the real problem. live well, vagrant signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] Support raw initrd for qemu riscv64 targets.
On 2019-09-26, Bin Meng wrote: > On Thu, Sep 26, 2019 at 8:57 AM Vagrant Cascadian wrote: >> On 2019-07-15, Vagrant Cascadian wrote: >> > This allows booting an initrd without headers generated by mkimage, >> > which is generally needed when using distro_bootcmd with >> > extlinux-style boot menus. >> > >> > Signed-off-by: Vagrant Cascadian >> > --- >> > >> > configs/qemu-riscv64_defconfig | 1 + >> > configs/qemu-riscv64_smode_defconfig | 1 + >> > 2 files changed, 2 insertions(+) >> > >> > diff --git a/configs/qemu-riscv64_defconfig >> > b/configs/qemu-riscv64_defconfig >> > index 19a5849226..c0c893a90c 100644 >> > --- a/configs/qemu-riscv64_defconfig >> > +++ b/configs/qemu-riscv64_defconfig >> > @@ -8,3 +8,4 @@ CONFIG_DISPLAY_CPUINFO=y >> > CONFIG_DISPLAY_BOARDINFO=y >> > # CONFIG_CMD_MII is not set >> > CONFIG_OF_PRIOR_STAGE=y >> > +CONFIG_SUPPORT_RAW_INITRD=y >> > diff --git a/configs/qemu-riscv64_smode_defconfig >> > b/configs/qemu-riscv64_smode_defconfig >> > index 74743a5ebe..ef7d358daa 100644 >> > --- a/configs/qemu-riscv64_smode_defconfig >> > +++ b/configs/qemu-riscv64_smode_defconfig >> > @@ -9,3 +9,4 @@ CONFIG_DISPLAY_CPUINFO=y >> > CONFIG_DISPLAY_BOARDINFO=y >> > # CONFIG_CMD_MII is not set >> > CONFIG_OF_PRIOR_STAGE=y >> > +CONFIG_SUPPORT_RAW_INITRD=y > > Isn't this already selected by DISTRO_DEFAULTS? You're right; it must be leftovers on my end from very old patch series. No need to add this patch, sorry for the noise! live well, vagrant signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] qemu-riscv64_smode, sifive-fu540: fix extlinux (define preboot)
On 2019-08-21, David Abdurachmanov wrote:
> Commit 37304aaf60bf92a5dc3ef222ba520698bd862a44 removed preboot
> commands in RISC-V targets and broke extlinux support as reported
> by Fu Wei .
>
> The patch finishes migration of CONFIG_USE_PREBOOT and CONFIG_REBOOT
> to Kconfig.
Tested using qemu-riscv64_smode and it fixes extlinux booting. Thanks!
Please CC me on future updates to the patch series.
Tested-by: Vagrant Cascadian
live well,
vagrant
> Signed-off-by: David Abdurachmanov
> ---
> configs/qemu-riscv64_smode_defconfig | 2 ++
> configs/sifive_fu540_defconfig | 2 ++
> include/configs/sifive-fu540.h | 4
> 3 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/configs/qemu-riscv64_smode_defconfig
> b/configs/qemu-riscv64_smode_defconfig
> index 74743a5ebe..2e1f7fa91f 100644
> --- a/configs/qemu-riscv64_smode_defconfig
> +++ b/configs/qemu-riscv64_smode_defconfig
> @@ -9,3 +9,5 @@ CONFIG_DISPLAY_CPUINFO=y
> CONFIG_DISPLAY_BOARDINFO=y
> # CONFIG_CMD_MII is not set
> CONFIG_OF_PRIOR_STAGE=y
> +CONFIG_USE_PREBOOT=y
> +CONFIG_PREBOOT="setenv fdt_addr ${fdtcontroladdr}; fdt addr
> ${fdtcontroladdr};"
> diff --git a/configs/sifive_fu540_defconfig b/configs/sifive_fu540_defconfig
> index 48865e5f11..a852579309 100644
> --- a/configs/sifive_fu540_defconfig
> +++ b/configs/sifive_fu540_defconfig
> @@ -9,3 +9,5 @@ CONFIG_MISC_INIT_R=y
> CONFIG_DISPLAY_CPUINFO=y
> CONFIG_DISPLAY_BOARDINFO=y
> CONFIG_OF_PRIOR_STAGE=y
> +CONFIG_USE_PREBOOT=y
> +CONFIG_PREBOOT="setenv fdt_addr ${fdtcontroladdr}; fdt addr
> ${fdtcontroladdr};"
> diff --git a/include/configs/sifive-fu540.h b/include/configs/sifive-fu540.h
> index 858b7a7da1..ba4aa0652c 100644
> --- a/include/configs/sifive-fu540.h
> +++ b/include/configs/sifive-fu540.h
> @@ -40,8 +40,4 @@
> "ramdisk_addr_r=0x8830\0" \
> BOOTENV
>
> -#define CONFIG_PREBOOT \
> - "setenv fdt_addr ${fdtcontroladdr};" \
> - "fdt addr ${fdtcontroladdr};"
> -
> #endif /* __CONFIG_H */
signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] Support raw initrd for qemu riscv64 targets.
Haven't heard any comment on this; is there someone better to CC? Would be really nice if it could be considered for v2019.10. Thanks! live well, vagrant On 2019-07-15, Vagrant Cascadian wrote: > This allows booting an initrd without headers generated by mkimage, > which is generally needed when using distro_bootcmd with > extlinux-style boot menus. > > Signed-off-by: Vagrant Cascadian > --- > > configs/qemu-riscv64_defconfig | 1 + > configs/qemu-riscv64_smode_defconfig | 1 + > 2 files changed, 2 insertions(+) > > diff --git a/configs/qemu-riscv64_defconfig b/configs/qemu-riscv64_defconfig > index 19a5849226..c0c893a90c 100644 > --- a/configs/qemu-riscv64_defconfig > +++ b/configs/qemu-riscv64_defconfig > @@ -8,3 +8,4 @@ CONFIG_DISPLAY_CPUINFO=y > CONFIG_DISPLAY_BOARDINFO=y > # CONFIG_CMD_MII is not set > CONFIG_OF_PRIOR_STAGE=y > +CONFIG_SUPPORT_RAW_INITRD=y > diff --git a/configs/qemu-riscv64_smode_defconfig > b/configs/qemu-riscv64_smode_defconfig > index 74743a5ebe..ef7d358daa 100644 > --- a/configs/qemu-riscv64_smode_defconfig > +++ b/configs/qemu-riscv64_smode_defconfig > @@ -9,3 +9,4 @@ CONFIG_DISPLAY_CPUINFO=y > CONFIG_DISPLAY_BOARDINFO=y > # CONFIG_CMD_MII is not set > CONFIG_OF_PRIOR_STAGE=y > +CONFIG_SUPPORT_RAW_INITRD=y > -- > 2.20.1 signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] envtools with tools-only_defconfig fails to build after v2019.10-rc1
I've been unable to successfully run "make envtools" on recent versions of u-boot, and finally got a chance to git bisect it. It looks like commit 9fb625ce05539fe6876a59ce1dcadb76b33c6f6e, introduced after 2019.10-rc1, breaks building envtools: #!/bin/sh # test-bisect set -e set -x make clean make tools-only_defconfig make NO_SDL=1 envtools Bisecting: 8 revisions left to test after this (roughly 3 steps) [9fb625ce05539fe6876a59ce1dcadb76b33c6f6e] env: Move env_set() to env.h running ../test-bisect + make clean CLEAN u-boot.cfg + make tools-only_defconfig HOSTCC scripts/basic/fixdep HOSTCC scripts/kconfig/conf.o YACCscripts/kconfig/zconf.tab.c LEX scripts/kconfig/zconf.lex.c HOSTCC scripts/kconfig/zconf.tab.o HOSTLD scripts/kconfig/conf # # configuration written to .config # + make NO_SDL=1 envtools scripts/kconfig/conf --syncconfig Kconfig CHK include/config.h CFG u-boot.cfg GEN include/autoconf.mk GEN include/autoconf.mk.dep CHK include/config/uboot.release UPD include/config/uboot.release CHK include/generated/version_autogenerated.h UPD include/generated/version_autogenerated.h CHK include/generated/timestamp_autogenerated.h UPD include/generated/timestamp_autogenerated.h LD tools/env/built-in.o HOSTCC tools/env/crc32.o HOSTCC tools/env/ctype.o HOSTCC tools/env/env_attr.o HOSTCC tools/env/env_flags.o In file included from tools/env/../../env/flags.c:7, from tools/env/env_flags.c:1: include/env.h:97:1: error: unknown type name 'ulong'; did you mean 'long'? 97 | ulong env_get_ulong(const char *name, int base, ulong default_val); | ^ | long include/env.h:97:49: error: unknown type name 'ulong'; did you mean 'long'? 97 | ulong env_get_ulong(const char *name, int base, ulong default_val); | ^ | long include/env.h:106:40: error: unknown type name 'ulong'; did you mean 'long'? 106 | int env_set_ulong(const char *varname, ulong value); |^ |long include/env.h:118:1: error: unknown type name 'ulong'; did you mean 'long'? 118 | ulong env_get_hex(const char *varname, ulong default_val); | ^ | long include/env.h:118:40: error: unknown type name 'ulong'; did you mean 'long'? 118 | ulong env_get_hex(const char *varname, ulong default_val); |^ |long include/env.h:127:38: error: unknown type name 'ulong'; did you mean 'long'? 127 | int env_set_hex(const char *varname, ulong value); | ^ | long include/env.h: In function 'env_set_addr': include/env.h:138:31: error: 'ulong' undeclared (first use in this function) 138 | return env_set_hex(varname, (ulong)addr); | ^ include/env.h:138:31: note: each undeclared identifier is reported only once for each function it appears in include/env.h:138:37: error: expected ')' before 'addr' 138 | return env_set_hex(varname, (ulong)addr); | ^~~~ | ) make[1]: *** [scripts/Makefile.host:114: tools/env/env_flags.o] Error 1 make: *** [Makefile:1778: envtools] Error 2 Bisecting: 3 revisions left to test after this (roughly 2 steps) ... Bisecting: 0 revisions left to test after this (roughly 0 steps) [cdbff9fc4002fdd47181088d5abe90e5f2fa1904] env: Move env_get_hex() to ... 9fb625ce05539fe6876a59ce1dcadb76b33c6f6e is the first bad commit commit 9fb625ce05539fe6876a59ce1dcadb76b33c6f6e Author: Simon Glass Date: Thu Aug 1 09:46:51 2019 -0600 env: Move env_set() to env.h Move env_set() over to the new header file. Acked-by: Joe Hershberger Signed-off-by: Simon Glass Would be great to get this building again before 2019.10 release! live well, vagrant signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH V2 0/7] ARM: imx: Update Novena to DM/DT
On 2019-08-19, Marek Vasut wrote: > On 6/4/19 9:06 AM, Vagrant Cascadian wrote: >> On 2019-05-17, Marek Vasut wrote: >>> Update Kosagi Novena to DM / DT and remove the warnings. ... >> I have two oustanding issues... with some files it sometimes fails to >> load one or more from SATA: >> >> Retrieving file: /boot/initrd.img-5.0.0-trunk-armmp >> 20077960 bytes read in 375 ms (51.1 MiB/s) >> Retrieving file: /boot/vmlinuz-5.0.0-trunk-armmp >> 4215296 bytes read in 40 ms (100.5 MiB/s) >> append: root=UUID=9666ab0b-f932-4e2f-95d7-0e96a12a4540 ro quiet >> Retrieving file: /usr/lib/linux-image-5.0.0-trunk-armmp/imx6q-novena.dtb >> CACHE: Misaligned operation at range [fafb5398, fafb6398] >> CACHE: Misaligned operation at range [fafb5398, fafb6398] >> ERROR: v7_outer_cache_inval_range - start address is not aligned - >> 0xfafb5398 >> ERROR: v7_outer_cache_inval_range - stop address is not aligned - >> 0xfafb6398 >> invalid extent block >> >> It then falls back to one of the other kernels (using the extlinux.conf >> parsing) and succeeds. It consistantly gets a cache/alignment error with >> this specific file. A bit-for-bit identical .dtb loaded from another >> path works just fine. Older versions of u-boot boot this fine. Would >> some particular EXT4 flag possibly be causing issues? > > I don't know. Do you still run into this with u-boot/master ? Still occurring with 2019.10-rc2. Haven't tested with master yet. Using "dcache off" before booting still outputs the CACHE and ERROR messages, but does successfully boot. >> The second issue is still using one out of four exposed USB ports fails >> and resets the board: >> >> load usb 0:1 $kernel_addr_r misc/Binaries/linux/Image >> data abort >> pc : [] lr : [] >> reloc pc : [<1783367a>]lr : [<178330fd>] >> sp : faf7c6e8 ip : 0003 fp : 0005 >> r10: faf8b200 r9 : faf87ea0 r8 : 0001 >> r7 : faf8b2c0 r6 : f9f7a040 r5 : faf7c710 r4 : 0038 >> r3 : 006d r2 : f9f7a0a3 r1 : faf8b32c r0 : f9f7a09f >> Flags: nzCv IRQs off FIQs off Mode SVC_32 >> Code: 4630fc5b 81f0e8bd e7d84606 bf082b2f (f822235c) >> Resetting CPU ... >> >> The three other usb ports work just fine with the same USB stick and >> file. All four ports work with 2019.01. > > Can you debug it ? I think some of this was due to the EFI stuff , which > I think was fixed since. Can you re-check that ? USB appears to be working fine with 2019.10-rc2. live well, vagrant signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] Support raw initrd for qemu riscv64 targets.
This allows booting an initrd without headers generated by mkimage, which is generally needed when using distro_bootcmd with extlinux-style boot menus. Signed-off-by: Vagrant Cascadian --- configs/qemu-riscv64_defconfig | 1 + configs/qemu-riscv64_smode_defconfig | 1 + 2 files changed, 2 insertions(+) diff --git a/configs/qemu-riscv64_defconfig b/configs/qemu-riscv64_defconfig index 19a5849226..c0c893a90c 100644 --- a/configs/qemu-riscv64_defconfig +++ b/configs/qemu-riscv64_defconfig @@ -8,3 +8,4 @@ CONFIG_DISPLAY_CPUINFO=y CONFIG_DISPLAY_BOARDINFO=y # CONFIG_CMD_MII is not set CONFIG_OF_PRIOR_STAGE=y +CONFIG_SUPPORT_RAW_INITRD=y diff --git a/configs/qemu-riscv64_smode_defconfig b/configs/qemu-riscv64_smode_defconfig index 74743a5ebe..ef7d358daa 100644 --- a/configs/qemu-riscv64_smode_defconfig +++ b/configs/qemu-riscv64_smode_defconfig @@ -9,3 +9,4 @@ CONFIG_DISPLAY_CPUINFO=y CONFIG_DISPLAY_BOARDINFO=y # CONFIG_CMD_MII is not set CONFIG_OF_PRIOR_STAGE=y +CONFIG_SUPPORT_RAW_INITRD=y -- 2.20.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH V2 0/7] ARM: imx: Update Novena to DM/DT
On 2019-06-04, Vagrant Cascadian wrote: > On 2019-05-17, Marek Vasut wrote: Retried with a build from: https://github.com/marex/u-boot-imx/tree/imx-dm commit:7a381bb7edfd43aefc1dbfea6d574234ef9d7771 Which contains the two patchsets needed. > I have two oustanding issues... with some files it sometimes fails to > load one or more from SATA: > > Retrieving file: /boot/initrd.img-5.0.0-trunk-armmp > 20077960 bytes read in 375 ms (51.1 MiB/s) > Retrieving file: /boot/vmlinuz-5.0.0-trunk-armmp > 4215296 bytes read in 40 ms (100.5 MiB/s) > append: root=UUID=9666ab0b-f932-4e2f-95d7-0e96a12a4540 ro quiet > Retrieving file: /usr/lib/linux-image-5.0.0-trunk-armmp/imx6q-novena.dtb > CACHE: Misaligned operation at range [fafb5398, fafb6398] > CACHE: Misaligned operation at range [fafb5398, fafb6398] > ERROR: v7_outer_cache_inval_range - start address is not aligned - > 0xfafb5398 > ERROR: v7_outer_cache_inval_range - stop address is not aligned - > 0xfafb6398 > invalid extent block > > It then falls back to one of the other kernels (using the extlinux.conf > parsing) and succeeds. It consistantly gets a cache/alignment error with > this specific file. A bit-for-bit identical .dtb loaded from another > path works just fine. Older versions of u-boot boot this fine. Would > some particular EXT4 flag possibly be causing issues? > > Several other kernel+initrd+dtb combinations work fine. Running "dcache off" before booting still produces the warnings/errors, but actually does boot successfully. Of course, it's much slower. > The second issue is still using one out of four exposed USB ports fails > and resets the board: > > load usb 0:1 $kernel_addr_r misc/Binaries/linux/Image > data abort > pc : [] lr : [] > reloc pc : [<1783367a>]lr : [<178330fd>] > sp : faf7c6e8 ip : 0003 fp : 0005 > r10: faf8b200 r9 : faf87ea0 r8 : 0001 > r7 : faf8b2c0 r6 : f9f7a040 r5 : faf7c710 r4 : 0038 > r3 : 006d r2 : f9f7a0a3 r1 : faf8b32c r0 : f9f7a09f > Flags: nzCv IRQs off FIQs off Mode SVC_32 > Code: 4630fc5b 81f0e8bd e7d84606 bf082b2f (f822235c) > Resetting CPU ... > > The three other usb ports work just fine with the same USB stick and > file. All four ports work with 2019.01. Got a bit-for-bit identical error on this one. I was able to get the objdump output with the reloc pc value: $ arm-linux-gnueabihf-objdump -d u-boot | grep 178337aa 178337aa: f822 3b02 strh.w r3, [r2], #2 Hope that's helpful! live well, vagrant signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH V2 0/7] ARM: imx: Update Novena to DM/DT
On 2019-05-17, Marek Vasut wrote: > Update Kosagi Novena to DM / DT and remove the warnings. > This depends on the following patches / series: > > https://patchwork.ozlabs.org/patch/1095618/ > https://patchwork.ozlabs.org/patch/1101171/ These are now merged in 2019.07-rc3. > https://patchwork.ozlabs.org/project/uboot/list/?series=108463 These were not yet. I have two oustanding issues... with some files it sometimes fails to load one or more from SATA: Retrieving file: /boot/initrd.img-5.0.0-trunk-armmp 20077960 bytes read in 375 ms (51.1 MiB/s) Retrieving file: /boot/vmlinuz-5.0.0-trunk-armmp 4215296 bytes read in 40 ms (100.5 MiB/s) append: root=UUID=9666ab0b-f932-4e2f-95d7-0e96a12a4540 ro quiet Retrieving file: /usr/lib/linux-image-5.0.0-trunk-armmp/imx6q-novena.dtb CACHE: Misaligned operation at range [fafb5398, fafb6398] CACHE: Misaligned operation at range [fafb5398, fafb6398] ERROR: v7_outer_cache_inval_range - start address is not aligned - 0xfafb5398 ERROR: v7_outer_cache_inval_range - stop address is not aligned - 0xfafb6398 invalid extent block It then falls back to one of the other kernels (using the extlinux.conf parsing) and succeeds. It consistantly gets a cache/alignment error with this specific file. A bit-for-bit identical .dtb loaded from another path works just fine. Older versions of u-boot boot this fine. Would some particular EXT4 flag possibly be causing issues? Several other kernel+initrd+dtb combinations work fine. I have not noticed issues loading from PXE. The second issue is still using one out of four exposed USB ports fails and resets the board: load usb 0:1 $kernel_addr_r misc/Binaries/linux/Image data abort pc : [] lr : [] reloc pc : [<1783367a>]lr : [<178330fd>] sp : faf7c6e8 ip : 0003 fp : 0005 r10: faf8b200 r9 : faf87ea0 r8 : 0001 r7 : faf8b2c0 r6 : f9f7a040 r5 : faf7c710 r4 : 0038 r3 : 006d r2 : f9f7a0a3 r1 : faf8b32c r0 : f9f7a09f Flags: nzCv IRQs off FIQs off Mode SVC_32 Code: 4630fc5b 81f0e8bd e7d84606 bf082b2f (f822235c) Resetting CPU ... The three other usb ports work just fine with the same USB stick and file. All four ports work with 2019.01. Despite those two issues somewhat significant issues... it does appear to work in general... so, with 2019.07-rc3 + https://patchwork.ozlabs.org/project/uboot/list/?series=108463 and this series applied, with the above caveats: Tested-by: Vagrant Cascadian live well, vagrant > Marek Vasut (7): > ARM: dts: imx: novena: Import Novena DT from Linux > ARM: imx: novena: Enable DM pin control > ARM: imx: novena: Enable DM GPIO > ARM: imx: novena: Convert block devices to DM > ARM: imx: novena: Enable DM USB > ARM: imx: novena: Enable DM PCI > ARM: imx: novena: Convert to DM VIDEO > > arch/arm/dts/Makefile | 3 +- > arch/arm/dts/imx6q-novena.dts | 797 ++ > board/kosagi/novena/novena.c | 77 +--- > board/kosagi/novena/video.c | 3 + > configs/novena_defconfig | 18 +- > include/configs/novena.h | 9 +- > 6 files changed, 838 insertions(+), 69 deletions(-) > create mode 100644 arch/arm/dts/imx6q-novena.dts > > Cc: Fabio Estevam > Cc: Stefano Babic > Cc: Vagrant Cascadian > -- > 2.20.1 signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 5/5] rockchip: rk3328: add rock64-rk3328_defconfig
On 2019-05-20, Matwey V. Kornilov wrote: > пн, 20 мая 2019 г. в 20:11, Vagrant Cascadian : >> >> On 2019-05-19, Matwey V. Kornilov wrote: >> > The ROCK64 is a credit card size SBC based on Rockchip RK3328 >> > Quad-Core ARM Cortex A53. >> > >> > This series allow building u-boot SPL and u-boot.itb for Rock64 >> > board. The proprietary TPL is stil required for deploy: >> > >> > ./tools/mkimage -n rk3328 -T rksd \ >> > -d ./rkbin/bin/rk33/rk3328_ddr_333MHz_v1.14.bin idbloader.img >> > cat ./spl/u-boot-spl.bin >> idbloader.img >> > dd if=idbloader.img of=/dev/sdcard seek=64 conv=notrunc >> > dd if=u-boot.itb of=/dev/sdcard seek=16384 conv=notrunc >> >> Could you add a patch documenting this in doc/README.rockchip or a >> board-specific README? That would be more useful than having to search >> the git commit messages or mailing list archives. >> >> >> Tested this patch series against v2019.07-rc2, and I was able to pxe >> boot fine, but unfortunately was unable to boot from microSD. >> >> I presume this is caused by some other change since v2019.07-rc1, since >> the earlier rock64 patches worked fine with microSD on v2019.07-rc1.\ > > Thanks for the report. This series is based on 98b3156b0df4 At least > bootefi works fine for me. No obvious relevent changes between 98b3156b0df4 and v2019.07-rc2. I haven't tested with bootefi ... will give that a try too. > Do v1 patches works for you on v2019.07-rc2? With some minor rebasing to apply to -rc2, the v1 patches fail in the same way as the v2 patches on top of v2019.07-rc2. live well, vagrant signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 5/5] rockchip: rk3328: add rock64-rk3328_defconfig
On 2019-05-19, Matwey V. Kornilov wrote: > The ROCK64 is a credit card size SBC based on Rockchip RK3328 > Quad-Core ARM Cortex A53. > > This series allow building u-boot SPL and u-boot.itb for Rock64 > board. The proprietary TPL is stil required for deploy: > > ./tools/mkimage -n rk3328 -T rksd \ > -d ./rkbin/bin/rk33/rk3328_ddr_333MHz_v1.14.bin idbloader.img > cat ./spl/u-boot-spl.bin >> idbloader.img > dd if=idbloader.img of=/dev/sdcard seek=64 conv=notrunc > dd if=u-boot.itb of=/dev/sdcard seek=16384 conv=notrunc Could you add a patch documenting this in doc/README.rockchip or a board-specific README? That would be more useful than having to search the git commit messages or mailing list archives. Tested this patch series against v2019.07-rc2, and I was able to pxe boot fine, but unfortunately was unable to boot from microSD. I presume this is caused by some other change since v2019.07-rc1, since the earlier rock64 patches worked fine with microSD on v2019.07-rc1. Scanning mmc 1:6... Found /boot/extlinux/extlinux.conf Retrieving file: /boot/extlinux/extlinux.conf 1953 bytes read in 4 ms (476.6 KiB/s) U-Boot menu 1: Debian GNU/Linux kernel 5.1.0-trunk-arm64 2: Debian GNU/Linux kernel 5.1.0-trunk-arm64 (rescue target) 3: Debian GNU/Linux kernel 5.0.0-trunk-arm64 4: Debian GNU/Linux kernel 5.0.0-trunk-arm64 (rescue target) 5: Debian GNU/Linux kernel 4.19.0-5-arm64 6: Debian GNU/Linux kernel 4.19.0-5-arm64 (rescue target) Enter choice: 1 1: Debian GNU/Linux kernel 5.1.0-trunk-arm64 Retrieving file: /boot/initrd.img-5.1.0-trunk-arm64 ** fs_devread read error - block Skipping l0 for failure retrieving initrd 2: Debian GNU/Linux kernel 5.1.0-trunk-arm64 (rescue target) Retrieving file: /boot/initrd.img-5.1.0-trunk-arm64 *** ERROR: Can't read GPT Entries *** GPT: Failed to allocate memory for PTE part_get_info_efi: *** ERROR: Invalid GPT *** *** ERROR: Can't read GPT header *** I enabled CONFIG_CMD_CACHE=y and tried "dcache off" but that didn't appear to help anything. Any other suggestions? live well, vagrant signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 5/5] rockchip: rk3328: add rock64-rk3328_defconfig
On 2019-05-13, Vagrant Cascadian wrote: > On 2019-05-13, Vagrant Cascadian wrote: >> On 2019-05-08, Matwey V. Kornilov wrote: >>> Signed-off-by: Matwey V. Kornilov >>> --- >>> configs/rock64-rk3328_defconfig | 91 >>> + >>> 1 file changed, 91 insertions(+) >>> create mode 100644 configs/rock64-rk3328_defconfig ... > Downloading the patch series from patchwork didn't include the cover > letter which explains what is needed... I'll test with that now; sorry > for the noise. > > Maybe those instructions should be included in doc/README.rockchip ? Works for me! Tested booting from microSD and PXE. Please CC me on updated patch series, if any. Tested-by: Vagrant Cascadian live well, vagrant signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 5/5] rockchip: rk3328: add rock64-rk3328_defconfig
On 2019-05-13, Vagrant Cascadian wrote: > On 2019-05-08, Matwey V. Kornilov wrote: >> Signed-off-by: Matwey V. Kornilov >> --- >> configs/rock64-rk3328_defconfig | 91 >> + >> 1 file changed, 91 insertions(+) >> create mode 100644 configs/rock64-rk3328_defconfig > > Thanks for submitting these patches upstream! > > Unfortunately, I wasn't able to get this to boot off of microSD. > > What process do you use to test this? Does it depend on patches not > present in 2019.07-rc1 or not yet merged? Downloading the patch series from patchwork didn't include the cover letter which explains what is needed... I'll test with that now; sorry for the noise. Maybe those instructions should be included in doc/README.rockchip ? live well, vagrant signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 5/5] rockchip: rk3328: add rock64-rk3328_defconfig
On 2019-05-08, Matwey V. Kornilov wrote: > Signed-off-by: Matwey V. Kornilov > --- > configs/rock64-rk3328_defconfig | 91 > + > 1 file changed, 91 insertions(+) > create mode 100644 configs/rock64-rk3328_defconfig Thanks for submitting these patches upstream! Unfortunately, I wasn't able to get this to boot off of microSD. What process do you use to test this? Does it depend on patches not present in 2019.07-rc1 or not yet merged? The process I tried after building upstream arm-trusted-firmware 2.1: mkimage -T rksd -n rk3328 -d spl/u-boot-spl.bin u-boot-spl.rksd dd if=u-boot-spl.rksd of=/dev/sdb seek=64 dd if=u-boot.itb of=/dev/sdb seek=16384 There was no output on the serial console, either at 150 or 115200. live well, vagrant > diff --git a/configs/rock64-rk3328_defconfig b/configs/rock64-rk3328_defconfig > new file mode 100644 > index 00..b278315035 > --- /dev/null > +++ b/configs/rock64-rk3328_defconfig > @@ -0,0 +1,91 @@ > +CONFIG_SMBIOS_MANUFACTURER="pine64" > +CONFIG_SMBIOS_PRODUCT_NAME="rock64_rk3328" > +CONFIG_ARM=y > +CONFIG_ARCH_ROCKCHIP=y > +CONFIG_SPL_LIBCOMMON_SUPPORT=y > +CONFIG_SPL_LIBGENERIC_SUPPORT=y > +CONFIG_SYS_MALLOC_F_LEN=0x2000 > +CONFIG_SYS_TEXT_BASE=0x0020 > +CONFIG_ROCKCHIP_RK3328=y > +CONFIG_ROCKCHIP_SPL_RESERVE_IRAM=0x0 > +CONFIG_SPL_DRIVERS_MISC_SUPPORT=y > +CONFIG_SPL_STACK_R_ADDR=0x60 > +CONFIG_DEBUG_UART_BASE=0xFF13 > +CONFIG_DEBUG_UART_CLOCK=2400 > +CONFIG_DEBUG_UART=y > +CONFIG_NR_DRAM_BANKS=1 > +# CONFIG_ANDROID_BOOT_IMAGE is not set > +CONFIG_FIT=y > +CONFIG_FIT_VERBOSE=y > +CONFIG_SPL_LOAD_FIT=y > +CONFIG_SPL_FIT_GENERATOR="arch/arm/mach-rockchip/make_fit_atf.py" > +CONFIG_DEFAULT_FDT_FILE="rockchip/rk3328-rock64.dtb" > +# CONFIG_DISPLAY_CPUINFO is not set > +CONFIG_DISPLAY_BOARDINFO_LATE=y > +CONFIG_SPL_STACK_R=y > +CONFIG_SPL_ATF=y > +CONFIG_SPL_ATF_NO_PLATFORM_PARAM=y > +CONFIG_FASTBOOT_BUF_ADDR=0x800800 > +CONFIG_FASTBOOT_FLASH=y > +CONFIG_FASTBOOT_FLASH_MMC_DEV=1 > +CONFIG_CMD_BOOTZ=y > +CONFIG_CMD_GPT=y > +CONFIG_CMD_MMC=y > +CONFIG_CMD_SF=y > +CONFIG_CMD_USB=y > +# CONFIG_CMD_SETEXPR is not set > +CONFIG_CMD_TIME=y > +CONFIG_DEFAULT_DEVICE_TREE="rk3328-rock64" > +CONFIG_SPL_OF_CONTROL=y > +CONFIG_OF_SPL_REMOVE_PROPS="pinctrl-0 pinctrl-names clock-names > interrupt-parent assigned-clocks assigned-clock-rates assigned-clock-parents" > +CONFIG_ENV_IS_IN_MMC=y > +CONFIG_NET_RANDOM_ETHADDR=y > +CONFIG_REGMAP=y > +CONFIG_SPL_REGMAP=y > +CONFIG_SYSCON=y > +CONFIG_SPL_SYSCON=y > +CONFIG_CLK=y > +CONFIG_SPL_CLK=y > +CONFIG_FASTBOOT_CMD_OEM_FORMAT=y > +CONFIG_ROCKCHIP_GPIO=y > +CONFIG_SYS_I2C_ROCKCHIP=y > +CONFIG_MMC_DW=y > +CONFIG_MMC_DW_ROCKCHIP=y > +CONFIG_SPI_FLASH=y > +CONFIG_SF_DEFAULT_SPEED=2000 > +CONFIG_DM_ETH=y > +CONFIG_ETH_DESIGNWARE=y > +CONFIG_GMAC_ROCKCHIP=y > +CONFIG_PHY=y > +CONFIG_PINCTRL=y > +CONFIG_SPL_PINCTRL=y > +CONFIG_PINCTRL_ROCKCHIP_RK3328=y > +CONFIG_DM_PMIC=y > +CONFIG_PMIC_RK8XX=y > +CONFIG_REGULATOR_PWM=y > +CONFIG_DM_REGULATOR_FIXED=y > +CONFIG_REGULATOR_RK8XX=y > +CONFIG_PWM_ROCKCHIP=y > +CONFIG_RAM=y > +CONFIG_SPL_RAM=y > +CONFIG_DM_RESET=y > +CONFIG_BAUDRATE=150 > +CONFIG_DEBUG_UART_SHIFT=2 > +CONFIG_SYSRESET=y > +CONFIG_USB=y > +CONFIG_USB_XHCI_HCD=y > +CONFIG_USB_XHCI_DWC3=y > +CONFIG_USB_EHCI_HCD=y > +CONFIG_USB_EHCI_GENERIC=y > +CONFIG_USB_OHCI_HCD=y > +CONFIG_USB_OHCI_GENERIC=y > +CONFIG_USB_DWC2=y > +CONFIG_USB_DWC3=y > +CONFIG_USB_GADGET=y > +CONFIG_USB_GADGET_MANUFACTURER="Rockchip" > +CONFIG_USB_GADGET_VENDOR_NUM=0x2207 > +CONFIG_USB_GADGET_PRODUCT_NUM=0x330a > +CONFIG_USB_GADGET_DWC2_OTG=y > +CONFIG_USE_TINY_PRINTF=y > +CONFIG_SPL_TINY_MEMSET=y > +CONFIG_ERRNO_STR=y signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 5/6] ARM: imx: novena: Enable DM USB
On 2019-05-06, Marek Vasut wrote: > On 5/6/19 5:26 AM, Vagrant Cascadian wrote: >> On 2019-05-06, Marek Vasut wrote: >>> Enable DM USB support on iMX6Q Novena. ... >> => load usb 0:1 $kernel_addr_r misc/Binaries/linux/Image >> data abort >> pc : [] lr : [] >> reloc pc : [<17832f0e>]lr : [<17832991>] > > Where does it crash ? arm-...objdump -d u-boot and look for the reloc_pc > value, it should tell you in which function the crash occurred . I didn't find 17832f0e in the objdump output... I'll try a build directly from upstream sources rather than using the debian packaging to make sure I'm not breaking something in the packaging. Also, interesting enough, only one of the four USB ports is triggering this issue for me; front, internal, and "ext2" (near the corner of the board) all work, but "ext1" doesn't (between "ext2" and the full-size SD/hdmi/microUSB/audio ports). live well, vagrant signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 6/6] ARM: imx: novena: Convert to DM VIDEO
On 2019-05-06, Marek Vasut wrote: > On 5/6/19 5:31 AM, Vagrant Cascadian wrote: >> On 2019-05-06, Marek Vasut wrote: >>> Enable DM Video support on iMX6Q Novena and fix minor details >>> to restore previous behavior of the system. >> >> Also required: >> >> "[U-Boot] video: ipuv3: Set max display bpp to 32" >> https://patchwork.ozlabs.org/patch/1095618/ >> >> Otherwise it would hang after initializing video. >> >> I don't see video output though. Not sure when I last tested video >> output from u-boot, though. But at least it boots! > > Try "setenv stdout serial,vidconsole" , does it help ? Yes, that did help; thanks! So it's working on some level... live well, vagrant signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 6/6] ARM: imx: novena: Convert to DM VIDEO
On 2019-05-06, Marek Vasut wrote:
> Enable DM Video support on iMX6Q Novena and fix minor details
> to restore previous behavior of the system.
Also required:
"[U-Boot] video: ipuv3: Set max display bpp to 32"
https://patchwork.ozlabs.org/patch/1095618/
Otherwise it would hang after initializing video.
I don't see video output though. Not sure when I last tested video
output from u-boot, though. But at least it boots!
live well,
vagrant
> Signed-off-by: Marek Vasut
> Cc: Fabio Estevam
> Cc: Stefano Babic
> Cc: Vagrant Cascadian
> ---
> configs/novena_defconfig | 6 +++---
> include/configs/novena.h | 4 ++--
> 2 files changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/configs/novena_defconfig b/configs/novena_defconfig
> index c5dbbb0b4d..3ae485245d 100644
> --- a/configs/novena_defconfig
> +++ b/configs/novena_defconfig
> @@ -4,6 +4,7 @@ CONFIG_SYS_TEXT_BASE=0x1780
> CONFIG_SPL_GPIO_SUPPORT=y
> CONFIG_SPL_LIBCOMMON_SUPPORT=y
> CONFIG_SPL_LIBGENERIC_SUPPORT=y
> +CONFIG_SYS_MALLOC_F_LEN=0x2000
> CONFIG_MX6_DDRCAL=y
> CONFIG_TARGET_KOSAGI_NOVENA=y
> CONFIG_SPL_MMC_SUPPORT=y
> @@ -15,7 +16,6 @@ CONFIG_SPL_LIBDISK_SUPPORT=y
> CONFIG_CMD_HDMIDETECT=y
> CONFIG_AHCI=y
> CONFIG_DISTRO_DEFAULTS=y
> -# CONFIG_SYS_MALLOC_F is not set
> CONFIG_FIT=y
> CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=arch/arm/mach-imx/spl_sd.cfg,MX6Q"
> CONFIG_USE_BOOTARGS=y
> @@ -70,7 +70,7 @@ CONFIG_USB_ETH_CDC=y
> CONFIG_USB_HOST_ETHER=y
> CONFIG_USB_ETHER_ASIX=y
> CONFIG_USB_ETHER_SMSC95XX=y
> +CONFIG_DM_VIDEO=y
> +CONFIG_SYS_WHITE_ON_BLACK=y
> CONFIG_VIDEO_IPUV3=y
> -CONFIG_VIDEO=y
> -# CONFIG_VIDEO_SW_CURSOR is not set
> CONFIG_FAT_WRITE=y
> diff --git a/include/configs/novena.h b/include/configs/novena.h
> index bc7383e957..cdc437c492 100644
> --- a/include/configs/novena.h
> +++ b/include/configs/novena.h
> @@ -119,14 +119,12 @@
> #endif
>
> /* Video output */
> -#ifdef CONFIG_VIDEO
> #define CONFIG_VIDEO_BMP_RLE8
> #define CONFIG_SPLASH_SCREEN
> #define CONFIG_BMP_16BPP
> #define CONFIG_VIDEO_LOGO
> #define CONFIG_IMX_HDMI
> #define CONFIG_IMX_VIDEO_SKIP
> -#endif
>
> /* Extra U-Boot environment. */
> #ifndef CONFIG_SPL_BUILD
> @@ -144,6 +142,8 @@
> "ramdisk_addr_r=0x2800\0" \
> "fdt_addr_r=0x1800\0" \
> "fdtfile=imx6q-novena.dtb\0"\
> + "stdout=serial,vidconsole\0"\
> + "stderr=serial,vidconsole\0"\
> "addcons=" \
> "setenv bootargs ${bootargs} " \
> "console=${consdev},${baudrate}\0" \
> --
> 2.20.1
signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 5/6] ARM: imx: novena: Enable DM USB
On 2019-05-06, Marek Vasut wrote: > Enable DM USB support on iMX6Q Novena. Hrm. Not working so well: => load usb 0:1 $kernel_addr_r misc/Binaries/linux/Image data abort pc : [] lr : [] reloc pc : [<17832f0e>]lr : [<17832991>] sp : faf7d788 ip : 0003 fp : 0005 r10: faf8c258 r9 : faf88ea0 r8 : 0001 r7 : fafa9ba0 r6 : f9f7b040 r5 : faf7d7b0 r4 : 0038 r3 : 006d r2 : f9f7b0a3 r1 : fafa9c0c r0 : f9f7b09f Flags: nzCv IRQs off FIQs off Mode SVC_32 Code: 4630f801 81f0e8bd e7d84606 bf082b2f (f822235c) Resetting CPU ... That said, I haven't tested USB recently; it may be no worse. live well, vagrant > Signed-off-by: Marek Vasut > Cc: Fabio Estevam > Cc: Stefano Babic > Cc: Vagrant Cascadian > --- > configs/novena_defconfig | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/configs/novena_defconfig b/configs/novena_defconfig > index fa5fdea278..c5dbbb0b4d 100644 > --- a/configs/novena_defconfig > +++ b/configs/novena_defconfig > @@ -60,6 +60,7 @@ CONFIG_PINCTRL=y > CONFIG_PINCTRL_IMX6=y > CONFIG_DM_SCSI=y > CONFIG_USB=y > +CONFIG_DM_USB=y > CONFIG_USB_KEYBOARD=y > CONFIG_SYS_USB_EVENT_POLL_VIA_CONTROL_EP=y > CONFIG_USB_GADGET=y > -- > 2.20.1 signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 4/6] ARM: imx: novena: Convert block devices to DM
On 2019-05-06, Marek Vasut wrote:
> Enable DM block, DM MMC and DM SATA support on iMX6Q Novena
> convert board code to match the DM support.
Tested booting from MMC and SATA.
SATA performance was *much* faster, too! Thanks!
Tested-by: Vagrant Cascadian
live well,
vagrant
> Signed-off-by: Marek Vasut
> Cc: Fabio Estevam
> Cc: Stefano Babic
> Cc: Vagrant Cascadian
> ---
> arch/arm/dts/imx6q-novena.dts | 5 ++
> board/kosagi/novena/novena.c | 107 +-
> configs/novena_defconfig | 3 +
> include/configs/novena.h | 5 --
> 4 files changed, 61 insertions(+), 59 deletions(-)
>
> diff --git a/arch/arm/dts/imx6q-novena.dts b/arch/arm/dts/imx6q-novena.dts
> index 61347a545d..35383c9a2b 100644
> --- a/arch/arm/dts/imx6q-novena.dts
> +++ b/arch/arm/dts/imx6q-novena.dts
> @@ -61,6 +61,11 @@
> reg = <0x1000 0>;
> };
>
> + aliases {
> + mmc0 =
> + mmc1 =
> + };
> +
> chosen {
> stdout-path =
> };
> diff --git a/board/kosagi/novena/novena.c b/board/kosagi/novena/novena.c
> index 0750c4667e..4b31e2961c 100644
> --- a/board/kosagi/novena/novena.c
> +++ b/board/kosagi/novena/novena.c
> @@ -6,6 +6,9 @@
> */
>
> #include
> +#include
> +#include
> +#include
> #include
> #include
> #include
> @@ -20,6 +23,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -101,60 +105,6 @@ int drv_keyboard_init(void)
> }
> #endif
>
> -/*
> - * SDHC
> - */
> -#ifdef CONFIG_FSL_ESDHC
> -static struct fsl_esdhc_cfg usdhc_cfg[] = {
> - { USDHC3_BASE_ADDR, 0, 4 }, /* Micro SD */
> - { USDHC2_BASE_ADDR, 0, 4 }, /* Big SD */
> -};
> -
> -int board_mmc_getcd(struct mmc *mmc)
> -{
> - struct fsl_esdhc_cfg *cfg = (struct fsl_esdhc_cfg *)mmc->priv;
> -
> - /* There is no CD for a microSD card, assume always present. */
> - if (cfg->esdhc_base == USDHC3_BASE_ADDR)
> - return 1;
> - else
> - return !gpio_get_value(NOVENA_SD_CD);
> -}
> -
> -int board_mmc_getwp(struct mmc *mmc)
> -{
> - struct fsl_esdhc_cfg *cfg = (struct fsl_esdhc_cfg *)mmc->priv;
> -
> - /* There is no WP for a microSD card, assume always read-write. */
> - if (cfg->esdhc_base == USDHC3_BASE_ADDR)
> - return 0;
> - else
> - return gpio_get_value(NOVENA_SD_WP);
> -}
> -
> -
> -int board_mmc_init(bd_t *bis)
> -{
> - s32 status = 0;
> - int index;
> -
> - usdhc_cfg[0].sdhc_clk = mxc_get_clock(MXC_ESDHC3_CLK);
> - usdhc_cfg[1].sdhc_clk = mxc_get_clock(MXC_ESDHC2_CLK);
> -
> - /* Big SD write-protect and card-detect */
> - gpio_direction_input(NOVENA_SD_WP);
> - gpio_direction_input(NOVENA_SD_CD);
> -
> - for (index = 0; index < ARRAY_SIZE(usdhc_cfg); index++) {
> - status = fsl_esdhc_initialize(bis, _cfg[index]);
> - if (status)
> - return status;
> - }
> -
> - return status;
> -}
> -#endif
> -
> int board_early_init_f(void)
> {
> #if defined(CONFIG_VIDEO_IPUV3)
> @@ -270,3 +220,52 @@ int misc_init_r(void)
>
> return ret;
> }
> +
> +#if CONFIG_IS_ENABLED(AHCI)
> +static int sata_imx_probe(struct udevice *dev)
> +{
> + int i, err;
> +
> + for (i = 0; i < 10; i++) {
> + err = setup_sata();
> + if (err) {
> + printf("SATA setup failed: %d\n", err);
> + return err;
> + }
> +
> + udelay(100);
> +
> + err = dwc_ahsata_probe(dev);
> + if (!err)
> + break;
> +
> + /* There is no device on the SATA port */
> + if (sata_dm_port_status(0, 0) == 0)
> + break;
> +
> + /* There's a device, but link not established. Retry */
> + device_remove(dev, DM_REMOVE_NORMAL);
> + }
> +
> + return 0;
> +}
> +
> +struct ahci_ops sata_imx_ops = {
> + .port_status = dwc_ahsata_port_status,
> + .reset = dwc_ahsata_bus_reset,
> + .scan = dwc_ahsata_scan,
> +};
> +
> +static const struct udevice_id sata_imx_ids[] = {
> + { .compatible = "fsl,imx6q-ahci" },
> + { }
> +};
> +
> +U_BOOT_DRIVER(sata_imx) = {
> + .name = "dwc_ahci",
> + .id = UCLASS_AHCI,
> + .of_match = sata_imx_ids,
> + .ops= _i
