Re: [RFC 07/22] dm: blk: add UCLASS_PARTITION
Am 29. Oktober 2021 23:17:56 MESZ schrieb Simon Glass : >Hi, > >On Fri, 29 Oct 2021 at 13:26, Heinrich Schuchardt wrote: >> >> >> >> Am 29. Oktober 2021 08:15:56 MESZ schrieb AKASHI Takahiro >> : >> >On Fri, Oct 29, 2021 at 06:57:24AM +0200, Heinrich Schuchardt wrote: >> >> >> >> >> >> > I agree with Heinrich that we are better to leave BLK as it is, both >> >> > in name and meaning. I think maybe I am missing the gist of your >> >> > argument. >> >> > >> >> > If we use UCLASS_PART, for example, can we have that refer to both s/w >> >> > and h/w partitions, as Herinch seems to allude to below? What would >> >> > the picture look like the, and would it get us closer to agreement? >> >> >> >> In the driver model: >> >> >> >> A UCLASS is a class of drivers that share the same interface. >> >> A UDEVICE is a logical device that belongs to exactly one UCLASS and is >> >> accessed through this UCLASS's interface. >> > >> >Please be careful about "accessed through" which is a quite confusing >> >expression. I don't always agree with this view. >> > >> >> A hardware partition is an object that exposes only a single interface >> >> for block IO. >> >> >> >> A software partition is an object that may expose two interfaces: one >> >> for block IO, the other for file IO. >> > >> >Are you talking about UEFI world or U-Boot? >> >Definitely, a hw partitions can provide a file system >> >if you want. >> >It's a matter of usage. >> > >> >I remember that we had some discussion about whether block devices >> >on UEFI system should always have a (sw) partition table or not. >> >But it is a different topic. >> > >> >> The UEFI model does not have a problem with this because on a handle you >> >> can install as many different protocols as you wish. But U-Boot's driver >> >> model only allows a single interface per device. Up to now U-Boot has >> >> overcome this limitation by creating child devices for the extra >> >> interfaces. >> > >> >> We have the following logical levels: >> >> >> >> Controller | Block device | Software Partition| File system >> >> +--+---+ >> >> NVMe Drive | Namespace| Partition 1..n| FAT, EXT4 >> >> ATA Controller | ATA-Drive| | >> >> SCSI Controller | LUN | | >> >> MMC Controller | HW-Partition | | >> >> MMC Controller | SD-Card | | >> >> USB-Node| USB-Drive| | >> >> >> >> In the device tree this could be modeled as: >> >> >> >> |-- Controller (UCLASS_CTRL) >> >> | |-- Block device / HW Partition (UCLASS_BLK)(A) >> >> | | |-- Partition table (UCLASS_PARTITION_TABLE) (B) >> >> | | |-- Software Partition (UCLASS_BLK) >> >> | | |-- File system (UCLASS_FS) >> >> | | >> >> | |-- Block device (UCLASS_BLK) >> >> | |-- File system (UCLASS_FS) >> > >> >I don't know why we expect PARTITION_TABLE and FS to appear in DM tree. >> >What is the benefit? >> >(A) and (B) always have 1:1 relationship. >> >> No. You can have a bare device without a partition table. > >I can have a DOS partition that covers the whole device, without a >partition table. This is supported in U-Boot and Linux. > >> >> We have several partition table drivers: DOS, GPT, OSX, ... . In future we >> should also have one for the NOR Flash partitions. All of these drivers have >> a common interface. As the partition table type is mostly independent of the >> block device type we should use separate uclasses and udevices. >> >> >I also remember that you claimed that not all efi objects(handles and >> >protocols like SIMPE_FILE_SYSTEM_PROTOCOL) need to have corresponding >> >U-Boot counterparts in our 2019 discussion. >> > >> >If we *need* PARTITION_TALBLE, why don't we have HW_PARTITION_TABLE, >> >which should support other type of hw partitions as well? >> >> How hardware partitions, LUNs, ATA drives are enumerated is specific to the >> type of controller while the type of software partition table is >> independent of the block device. >> >> > >> >|-- eMMC controller (UCLASS_MMC) >> >| |-- eMMC device1 / Physical media (UCLASS_HW_PARTITION_TABLE?) >> >| |-- Block device / HW Partition:user data (UCLASS_BLK) >> >| | |-- Partition table (UCLASS_PARTITION_TABLE) >> >| | |-- Software Partition (UCLASS_BLK) >> >| | |-- File system (UCLASS_FS) >> >| | >> >| |-- Block device / HW Partition:boot0 (UCLASS_BLK) >> >| |-- Block device / HW Partition:boot1 (UCLASS_BLK) >> > ... >> >| |-- eMMC device2 / Physical media (UCLASS_HW_PARTITION_TABLE?) >> > >> >|-- scsi controller (UCLASS_SCSI) >> >| |-- scsi disk / Physical media (UCLASS_HW_PARTITION_TABLE?) >> >| |-- scsi LUN1 (UCLASS_HW_PARTITION_TABLE?) >> >| | |-- Partition table (UCLASS_PARTITION_TABLE) >> >| | |-- Software Partition (UCLASS_BLK) >> >| |-- scsi LUN2 (UCLASS_HW_PARTITION_TABLE?) >> > ... >> > >> >(Here I ignored scsi
[PATCH v4 2/2] arm: imx8m: add support for Advantech RSB-3720
From: "Ying-Chun Liu (PaulLiu)" Add initial support for Advantech RSB-3720 board. The initial support includes: - MMC - eMMC - I2C - FEC - Serial console Signed-off-by: Darren Huang Signed-off-by: Kevin12.Chen Signed-off-by: Phill.Liu Signed-off-by: Tim Liang Signed-off-by: wei.zeng Signed-off-by: Ying-Chun Liu (PaulLiu) Cc: uboot-imx Cc: Peng Fan (OSS) --- v3: remove unnecessary code. move board code to board/advantech v4: rebase to latest master branch --- arch/arm/dts/Makefile |3 + arch/arm/mach-imx/imx8m/Kconfig | 15 + board/advantech/imx8mp_rsb3720a1/Kconfig | 14 + board/advantech/imx8mp_rsb3720a1/MAINTAINERS |7 + board/advantech/imx8mp_rsb3720a1/Makefile | 24 + .../imx8mp_rsb3720a1/imx8mp_rsb3720a1.c | 213 ++ .../imx8mp_rsb3720a1/imximage-8mp-lpddr4.cfg | 11 + .../lpddr4_timing_rsb3720a1_4G.c | 1848 .../lpddr4_timing_rsb3720a1_6G.c | 1875 + board/advantech/imx8mp_rsb3720a1/spl.c| 263 +++ configs/imx8mp_rsb3720a1_4G_defconfig | 163 ++ configs/imx8mp_rsb3720a1_6G_defconfig | 164 ++ include/configs/imx8mp_rsb3720.h | 233 ++ 13 files changed, 4833 insertions(+) create mode 100644 board/advantech/imx8mp_rsb3720a1/Kconfig create mode 100644 board/advantech/imx8mp_rsb3720a1/MAINTAINERS create mode 100644 board/advantech/imx8mp_rsb3720a1/Makefile create mode 100644 board/advantech/imx8mp_rsb3720a1/imx8mp_rsb3720a1.c create mode 100644 board/advantech/imx8mp_rsb3720a1/imximage-8mp-lpddr4.cfg create mode 100644 board/advantech/imx8mp_rsb3720a1/lpddr4_timing_rsb3720a1_4G.c create mode 100644 board/advantech/imx8mp_rsb3720a1/lpddr4_timing_rsb3720a1_6G.c create mode 100644 board/advantech/imx8mp_rsb3720a1/spl.c create mode 100644 configs/imx8mp_rsb3720a1_4G_defconfig create mode 100644 configs/imx8mp_rsb3720a1_6G_defconfig create mode 100644 include/configs/imx8mp_rsb3720.h diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile index a88aecc5bd..37770e47f5 100644 --- a/arch/arm/dts/Makefile +++ b/arch/arm/dts/Makefile @@ -1148,6 +1148,9 @@ dtb-$(CONFIG_TARGET_DURIAN) += phytium-durian.dtb dtb-$(CONFIG_TARGET_PRESIDIO_ASIC) += ca-presidio-engboard.dtb dtb-$(CONFIG_TARGET_IMX8MM_CL_IOT_GATE) += imx8mm-cl-iot-gate.dtb +ifneq ($(CONFIG_TARGET_IMX8MP_RSB3720A1_4G)$(CONFIG_TARGET_IMX8MP_RSB3720A1_6G),) +dtb-y += imx8mp-rsb3720-a1.dtb +endif dtb-$(CONFIG_TARGET_IMX8MM_CL_IOT_GATE_OPTEE) += imx8mm-cl-iot-gate-optee.dtb diff --git a/arch/arm/mach-imx/imx8m/Kconfig b/arch/arm/mach-imx/imx8m/Kconfig index 276b8bd974..6b870c1593 100644 --- a/arch/arm/mach-imx/imx8m/Kconfig +++ b/arch/arm/mach-imx/imx8m/Kconfig @@ -154,8 +154,23 @@ config TARGET_IMX8MM_CL_IOT_GATE_OPTEE select IMX8MM select SUPPORT_SPL select IMX8M_LPDDR4 + +config TARGET_IMX8MP_RSB3720A1_4G + bool "Support i.MX8MP RSB3720A1 4G" + select BINMAN + select IMX8MP + select SUPPORT_SPL + select IMX8M_LPDDR4 + +config TARGET_IMX8MP_RSB3720A1_6G + bool "Support i.MX8MP RSB3720A1 6G" + select BINMAN + select IMX8MP + select SUPPORT_SPL + select IMX8M_LPDDR4 endchoice +source "board/advantech/imx8mp_rsb3720a1/Kconfig" source "board/beacon/imx8mm/Kconfig" source "board/beacon/imx8mn/Kconfig" source "board/compulab/imx8mm-cl-iot-gate/Kconfig" diff --git a/board/advantech/imx8mp_rsb3720a1/Kconfig b/board/advantech/imx8mp_rsb3720a1/Kconfig new file mode 100644 index 00..4486ed6d33 --- /dev/null +++ b/board/advantech/imx8mp_rsb3720a1/Kconfig @@ -0,0 +1,14 @@ +if TARGET_IMX8MP_RSB3720A1_4G || TARGET_IMX8MP_RSB3720A1_6G + +config SYS_BOARD + default "imx8mp_rsb3720a1" + +config SYS_VENDOR + default "advantech" + +config SYS_CONFIG_NAME + default "imx8mp_rsb3720" + +source "board/freescale/common/Kconfig" + +endif diff --git a/board/advantech/imx8mp_rsb3720a1/MAINTAINERS b/board/advantech/imx8mp_rsb3720a1/MAINTAINERS new file mode 100644 index 00..bc967af4f5 --- /dev/null +++ b/board/advantech/imx8mp_rsb3720a1/MAINTAINERS @@ -0,0 +1,7 @@ +i.MX8MP RSB3720 BOARD +M: Ying-Chun Liu (PaulLiu) +S: Maintained +F: board/advantech/imx8mp_rsb3720a1/ +F: include/configs/imx8mp_rsb3720a1.h +F: configs/imx8mp_rsb3720a1_4G_defconfig +F: configs/imx8mp_rsb3720a1_6G_defconfig diff --git a/board/advantech/imx8mp_rsb3720a1/Makefile b/board/advantech/imx8mp_rsb3720a1/Makefile new file mode 100644 index 00..ae5b8b83eb --- /dev/null +++ b/board/advantech/imx8mp_rsb3720a1/Makefile @@ -0,0 +1,24 @@ +# +# Copyright 2019 NXP +# Copyright 2021 Linaro +# +# SPDX-License-Identifier: GPL-2.0+ +# + +ifdef CONFIG_TARGET_IMX8MP_RSB3720A1_6G +obj-y += imx8mp_rsb3720a1.o + +ifdef CONFIG_SPL_BUILD +obj-y += spl.o +obj-$(CONFIG_IMX8M_LPDDR4) += lpddr4_timing_rsb3720a1_6G.o +endif +endif + +ifdef
Re: [RFC 07/22] dm: blk: add UCLASS_PARTITION
Hi, On Fri, 29 Oct 2021 at 13:26, Heinrich Schuchardt wrote: > > > > Am 29. Oktober 2021 08:15:56 MESZ schrieb AKASHI Takahiro > : > >On Fri, Oct 29, 2021 at 06:57:24AM +0200, Heinrich Schuchardt wrote: > >> > >> > >> > I agree with Heinrich that we are better to leave BLK as it is, both > >> > in name and meaning. I think maybe I am missing the gist of your > >> > argument. > >> > > >> > If we use UCLASS_PART, for example, can we have that refer to both s/w > >> > and h/w partitions, as Herinch seems to allude to below? What would > >> > the picture look like the, and would it get us closer to agreement? > >> > >> In the driver model: > >> > >> A UCLASS is a class of drivers that share the same interface. > >> A UDEVICE is a logical device that belongs to exactly one UCLASS and is > >> accessed through this UCLASS's interface. > > > >Please be careful about "accessed through" which is a quite confusing > >expression. I don't always agree with this view. > > > >> A hardware partition is an object that exposes only a single interface > >> for block IO. > >> > >> A software partition is an object that may expose two interfaces: one > >> for block IO, the other for file IO. > > > >Are you talking about UEFI world or U-Boot? > >Definitely, a hw partitions can provide a file system > >if you want. > >It's a matter of usage. > > > >I remember that we had some discussion about whether block devices > >on UEFI system should always have a (sw) partition table or not. > >But it is a different topic. > > > >> The UEFI model does not have a problem with this because on a handle you > >> can install as many different protocols as you wish. But U-Boot's driver > >> model only allows a single interface per device. Up to now U-Boot has > >> overcome this limitation by creating child devices for the extra > >> interfaces. > > > >> We have the following logical levels: > >> > >> Controller | Block device | Software Partition| File system > >> +--+---+ > >> NVMe Drive | Namespace| Partition 1..n| FAT, EXT4 > >> ATA Controller | ATA-Drive| | > >> SCSI Controller | LUN | | > >> MMC Controller | HW-Partition | | > >> MMC Controller | SD-Card | | > >> USB-Node| USB-Drive| | > >> > >> In the device tree this could be modeled as: > >> > >> |-- Controller (UCLASS_CTRL) > >> | |-- Block device / HW Partition (UCLASS_BLK)(A) > >> | | |-- Partition table (UCLASS_PARTITION_TABLE) (B) > >> | | |-- Software Partition (UCLASS_BLK) > >> | | |-- File system (UCLASS_FS) > >> | | > >> | |-- Block device (UCLASS_BLK) > >> | |-- File system (UCLASS_FS) > > > >I don't know why we expect PARTITION_TABLE and FS to appear in DM tree. > >What is the benefit? > >(A) and (B) always have 1:1 relationship. > > No. You can have a bare device without a partition table. I can have a DOS partition that covers the whole device, without a partition table. This is supported in U-Boot and Linux. > > We have several partition table drivers: DOS, GPT, OSX, ... . In future we > should also have one for the NOR Flash partitions. All of these drivers have > a common interface. As the partition table type is mostly independent of the > block device type we should use separate uclasses and udevices. > > >I also remember that you claimed that not all efi objects(handles and > >protocols like SIMPE_FILE_SYSTEM_PROTOCOL) need to have corresponding > >U-Boot counterparts in our 2019 discussion. > > > >If we *need* PARTITION_TALBLE, why don't we have HW_PARTITION_TABLE, > >which should support other type of hw partitions as well? > > How hardware partitions, LUNs, ATA drives are enumerated is specific to the > type of controller while the type of software partition table is independent > of the block device. > > > > >|-- eMMC controller (UCLASS_MMC) > >| |-- eMMC device1 / Physical media (UCLASS_HW_PARTITION_TABLE?) > >| |-- Block device / HW Partition:user data (UCLASS_BLK) > >| | |-- Partition table (UCLASS_PARTITION_TABLE) > >| | |-- Software Partition (UCLASS_BLK) > >| | |-- File system (UCLASS_FS) > >| | > >| |-- Block device / HW Partition:boot0 (UCLASS_BLK) > >| |-- Block device / HW Partition:boot1 (UCLASS_BLK) > > ... > >| |-- eMMC device2 / Physical media (UCLASS_HW_PARTITION_TABLE?) > > > >|-- scsi controller (UCLASS_SCSI) > >| |-- scsi disk / Physical media (UCLASS_HW_PARTITION_TABLE?) > >| |-- scsi LUN1 (UCLASS_HW_PARTITION_TABLE?) > >| | |-- Partition table (UCLASS_PARTITION_TABLE) > >| | |-- Software Partition (UCLASS_BLK) > >| |-- scsi LUN2 (UCLASS_HW_PARTITION_TABLE?) > > ... > > > >(Here I ignored scsi buses/channels which make things more complicated.) > > > >This kind of complex hierarchy doesn't benefit anybody. > > All these levels exist already. We simply do not model them yet in the
Re: [PATCH 0/2] arch: arm: gic-v3-its: stop abusing the device tree
Hi Michael, On Fri, 29 Oct 2021 at 05:54, Michael Walle wrote: > > Am 2021-10-29 00:36, schrieb Simon Glass: > > On Wed, 27 Oct 2021 at 10:55, Michael Walle wrote: > >> > >> Please stop throwing every ad-hoc information in the device tree. Use > >> the > >> official bindings (or maybe some bindings which will get approved > >> soon). > > > > Can I suggest that your commit subject be a little more specific? > > Sure. Actually, it should have be a bit provocant; and the cover letter > subject doesn't really matter, does it? I suppose not and it is somewhat entertaining. > > > Perhaps 'Drop use of unwanted binding' ? It seems quite vague to me, > > like 'Fix a horrible bug' or 'Sort out all the problems' :-) Regards, SImon
Re: [PATCH v3 0/7] arm64: dts: imx8mm: use common binman configuration and further clean-up
On Fri, Oct 29, 2021 at 12:56 PM Adam Ford wrote: > > On Fri, Oct 22, 2021 at 6:16 PM Marcel Ziswiler wrote: > > > > From: Marcel Ziswiler > > > > > > With the move to using binman to generate SPL aka u-boot-spl-ddr.bin and > > U-Boot proper aka u-boot.itb every board now covers such configuration > > in its own U-Boot specific device tree include. Move the comon part of > > that configuration to the common imx8mm-u-boot.dtsi include file. > > > > The initial patch fixes an issue with intermediate binary naming for the > > imx8mm-cl-iot-gate. And subsequent patches further clean up that dtsi. > > > > This series is based on my refresh of Adam's imx8mm_beacon switch to > > binman patch [1], my refresh of Michael's sl28 patches [2] and Tim's > > switching imx8mm_venice to using binman to pack images [3]. > > Thanks for doing the rebase. I wonder if we should drop the > imx8mm-beacon patch and just add the adjusted defconfig changes rather > than applying either my patch or the rebased patch, then undoing it > right away with this series. I like the idea of merging them all > together into one nice series using the common imx8mm-u-boot.dtsi > file, but I wonder if we should split this into another sub-file > called im8mm-lpddr4-u-boot.dtsi. If someone uses a different DDR, > these referenced files won't be appropriate for their DDR type. > > I tried applying this series on u-boot/master, but it didn't apply > correctly, so the rest of my message might not apply if there is a > patch somewhere that fixes it, and I just missed it. > > 1. The build fails because there is a file in a location different > than what's expected: > > make flash.bin CROSS_COMPILE=aarch64-linux-gnu- -j8 > > BINMAN flash.bin > MKIMAGE flash.bin > ./tools/mkimage: Can't open spl/u-boot-spl-ddr.bin: No such file or directory > make[1]: *** [arch/arm/mach-imx/Makefile:167: flash.bin] Error 1 > make[1]: *** Deleting file 'flash.bin' > make: *** [Makefile:1516: flash.bin] Error 2 > > If I copy u-boot-spl-ddr.bin from the main build directory to the spl > directory and run make again, it completes successfully. > > 2. I noticed that the offset doesn't appear to be jumping to the > right location. I am not sure if something has changed in binman, but > I intentionally loaded this over a much older flash.bin file because I > wanted to make sure the correct version of u-boot loaded, but it did > not. > > Notice the version mismatch between SPL and U-Boot. > > U-Boot SPL 2021.10-00983-geed0aab6ff-dirty (Oct 29 2021 - 14:24:10 -0500) > WDT: Started watchdog@3028 with servicing (60s timeout) > Trying to boot from MMC1 > NOTICE: BL31: v2.2(release):imx_5.4.24_er3-0-gb0a00f22b-dirty > NOTICE: BL31: Built : 03:05:00, May 12 2021 > > > U-Boot 2019.04-4.19.35-1.1.0+g4d377539a1 (Jun 03 2021 - 19:41:40 +) > > CPU: Freescale i.MX8MMQ rev1.0 1600 MHz (running at 500 MHz) > CPU: Industrial temperature grade (-40C to 105C) at 56C > Reset cause: POR > Model: Beacon EmbeddedWorks i.MX8M Mini Development Kit > DRAM: 2 GiB > MMC: FSL_SDHC: 0, FSL_SDHC: 1, FSL_SDHC: 2 > Loading Environment from MMC... OK > In:serial > Out: serial > Err: serial > > I can try to determine the proper offset again, but there is another > binman patch that might make this easier if the elf properly has the > offset defined [4]. > > > > > > [1] https://marc.info/?l=u-boot=163493902915471 > > [2] https://marc.info/?l=u-boot=163494122816224 > > [3] https://marc.info/?l=u-boot=163355140309636 > > [4] - > https://patchwork.ozlabs.org/project/uboot/patch/20211026033058.430010-6-...@chromium.org/ > > > If there is a patch I missed somewhere, please let me know, and I will > go back and try again. I'll try to figure out what's going on with the > u-boot offset sometime this weekend. > > > > > Changes in v3: > > - Integrated imx8mm_beacon as well. > > - Re-based on top of imx/master. > > > > Changes in v2: > > - New patch preparing cl-iot-gate. > > - New patch preparing cl-iot-gate. > > - Morph common binman dtsi into regular common u-boot dtsi as discussed > > on mailing list. > > - Re-based. > > - Rather than doing that clean-up to the separate binman dtsi now do it > > to the common u-boot dtsi one. > > - Rather than doing that clean-up to the separate binman dtsi now do it > > to the common u-boot dtsi one. > > - Rather than doing that clean-up to the separate binman dtsi now do it > > to the common u-boot dtsi one. > > > > Changes in v1: > > - This was suggested by Simon on my earlier patch set upon which we > > decided to first break this up into a common binman dtsi and then > > subsequently do such further improvements. > > > > Marcel Ziswiler (7): > > imx8mm-cl-iot-gate: fix imximage intermediate binary naming > > arm64: dts: imx8mm-cl-iot-gate-u-boot.dtsi: alphabetically re-order > > arm64: dts: imx8mm-cl-iot-gate-u-boot.dtsi: use common > > imx8mm-u-boot.dtsi > > arm64: dts: imx8mm: use common binman configuration >
Re: [PATCH v3 0/7] arm64: dts: imx8mm: use common binman configuration and further clean-up
On Fri, Oct 22, 2021 at 6:16 PM Marcel Ziswiler wrote: > > From: Marcel Ziswiler > > > With the move to using binman to generate SPL aka u-boot-spl-ddr.bin and > U-Boot proper aka u-boot.itb every board now covers such configuration > in its own U-Boot specific device tree include. Move the comon part of > that configuration to the common imx8mm-u-boot.dtsi include file. > > The initial patch fixes an issue with intermediate binary naming for the > imx8mm-cl-iot-gate. And subsequent patches further clean up that dtsi. > > This series is based on my refresh of Adam's imx8mm_beacon switch to > binman patch [1], my refresh of Michael's sl28 patches [2] and Tim's > switching imx8mm_venice to using binman to pack images [3]. Thanks for doing the rebase. I wonder if we should drop the imx8mm-beacon patch and just add the adjusted defconfig changes rather than applying either my patch or the rebased patch, then undoing it right away with this series. I like the idea of merging them all together into one nice series using the common imx8mm-u-boot.dtsi file, but I wonder if we should split this into another sub-file called im8mm-lpddr4-u-boot.dtsi. If someone uses a different DDR, these referenced files won't be appropriate for their DDR type. I tried applying this series on u-boot/master, but it didn't apply correctly, so the rest of my message might not apply if there is a patch somewhere that fixes it, and I just missed it. 1. The build fails because there is a file in a location different than what's expected: make flash.bin CROSS_COMPILE=aarch64-linux-gnu- -j8 BINMAN flash.bin MKIMAGE flash.bin ./tools/mkimage: Can't open spl/u-boot-spl-ddr.bin: No such file or directory make[1]: *** [arch/arm/mach-imx/Makefile:167: flash.bin] Error 1 make[1]: *** Deleting file 'flash.bin' make: *** [Makefile:1516: flash.bin] Error 2 If I copy u-boot-spl-ddr.bin from the main build directory to the spl directory and run make again, it completes successfully. 2. I noticed that the offset doesn't appear to be jumping to the right location. I am not sure if something has changed in binman, but I intentionally loaded this over a much older flash.bin file because I wanted to make sure the correct version of u-boot loaded, but it did not. Notice the version mismatch between SPL and U-Boot. U-Boot SPL 2021.10-00983-geed0aab6ff-dirty (Oct 29 2021 - 14:24:10 -0500) WDT: Started watchdog@3028 with servicing (60s timeout) Trying to boot from MMC1 NOTICE: BL31: v2.2(release):imx_5.4.24_er3-0-gb0a00f22b-dirty NOTICE: BL31: Built : 03:05:00, May 12 2021 U-Boot 2019.04-4.19.35-1.1.0+g4d377539a1 (Jun 03 2021 - 19:41:40 +) CPU: Freescale i.MX8MMQ rev1.0 1600 MHz (running at 500 MHz) CPU: Industrial temperature grade (-40C to 105C) at 56C Reset cause: POR Model: Beacon EmbeddedWorks i.MX8M Mini Development Kit DRAM: 2 GiB MMC: FSL_SDHC: 0, FSL_SDHC: 1, FSL_SDHC: 2 Loading Environment from MMC... OK In:serial Out: serial Err: serial I can try to determine the proper offset again, but there is another binman patch that might make this easier if the elf properly has the offset defined [4]. > > [1] https://marc.info/?l=u-boot=163493902915471 > [2] https://marc.info/?l=u-boot=163494122816224 > [3] https://marc.info/?l=u-boot=163355140309636 [4] - https://patchwork.ozlabs.org/project/uboot/patch/20211026033058.430010-6-...@chromium.org/ If there is a patch I missed somewhere, please let me know, and I will go back and try again. I'll try to figure out what's going on with the u-boot offset sometime this weekend. > > Changes in v3: > - Integrated imx8mm_beacon as well. > - Re-based on top of imx/master. > > Changes in v2: > - New patch preparing cl-iot-gate. > - New patch preparing cl-iot-gate. > - Morph common binman dtsi into regular common u-boot dtsi as discussed > on mailing list. > - Re-based. > - Rather than doing that clean-up to the separate binman dtsi now do it > to the common u-boot dtsi one. > - Rather than doing that clean-up to the separate binman dtsi now do it > to the common u-boot dtsi one. > - Rather than doing that clean-up to the separate binman dtsi now do it > to the common u-boot dtsi one. > > Changes in v1: > - This was suggested by Simon on my earlier patch set upon which we > decided to first break this up into a common binman dtsi and then > subsequently do such further improvements. > > Marcel Ziswiler (7): > imx8mm-cl-iot-gate: fix imximage intermediate binary naming > arm64: dts: imx8mm-cl-iot-gate-u-boot.dtsi: alphabetically re-order > arm64: dts: imx8mm-cl-iot-gate-u-boot.dtsi: use common > imx8mm-u-boot.dtsi > arm64: dts: imx8mm: use common binman configuration > arm64: dts: imx8mm-u-boot.dtsi: alphabetically re-order properties > arm64: dts: imx8mm-u-boot.dtsi: explicitly add spl filename > arm64: dts: imx8mm-u-boot.dtsi: improve odd blob-ext naming > > arch/arm/dts/imx8mm-beacon-kit-u-boot.dtsi| 122 -- >
Re: [RFC 07/22] dm: blk: add UCLASS_PARTITION
Am 29. Oktober 2021 08:15:56 MESZ schrieb AKASHI Takahiro : >On Fri, Oct 29, 2021 at 06:57:24AM +0200, Heinrich Schuchardt wrote: >> >> >> > I agree with Heinrich that we are better to leave BLK as it is, both >> > in name and meaning. I think maybe I am missing the gist of your >> > argument. >> > >> > If we use UCLASS_PART, for example, can we have that refer to both s/w >> > and h/w partitions, as Herinch seems to allude to below? What would >> > the picture look like the, and would it get us closer to agreement? >> >> In the driver model: >> >> A UCLASS is a class of drivers that share the same interface. >> A UDEVICE is a logical device that belongs to exactly one UCLASS and is >> accessed through this UCLASS's interface. > >Please be careful about "accessed through" which is a quite confusing >expression. I don't always agree with this view. > >> A hardware partition is an object that exposes only a single interface >> for block IO. >> >> A software partition is an object that may expose two interfaces: one >> for block IO, the other for file IO. > >Are you talking about UEFI world or U-Boot? >Definitely, a hw partitions can provide a file system >if you want. >It's a matter of usage. > >I remember that we had some discussion about whether block devices >on UEFI system should always have a (sw) partition table or not. >But it is a different topic. > >> The UEFI model does not have a problem with this because on a handle you >> can install as many different protocols as you wish. But U-Boot's driver >> model only allows a single interface per device. Up to now U-Boot has >> overcome this limitation by creating child devices for the extra interfaces. > >> We have the following logical levels: >> >> Controller | Block device | Software Partition| File system >> +--+---+ >> NVMe Drive | Namespace| Partition 1..n| FAT, EXT4 >> ATA Controller | ATA-Drive| | >> SCSI Controller | LUN | | >> MMC Controller | HW-Partition | | >> MMC Controller | SD-Card | | >> USB-Node| USB-Drive| | >> >> In the device tree this could be modeled as: >> >> |-- Controller (UCLASS_CTRL) >> | |-- Block device / HW Partition (UCLASS_BLK)(A) >> | | |-- Partition table (UCLASS_PARTITION_TABLE) (B) >> | | |-- Software Partition (UCLASS_BLK) >> | | |-- File system (UCLASS_FS) >> | | >> | |-- Block device (UCLASS_BLK) >> | |-- File system (UCLASS_FS) > >I don't know why we expect PARTITION_TABLE and FS to appear in DM tree. >What is the benefit? >(A) and (B) always have 1:1 relationship. No. You can have a bare device without a partition table. We have several partition table drivers: DOS, GPT, OSX, ... . In future we should also have one for the NOR Flash partitions. All of these drivers have a common interface. As the partition table type is mostly independent of the block device type we should use separate uclasses and udevices. >I also remember that you claimed that not all efi objects(handles and >protocols like SIMPE_FILE_SYSTEM_PROTOCOL) need to have corresponding >U-Boot counterparts in our 2019 discussion. > >If we *need* PARTITION_TALBLE, why don't we have HW_PARTITION_TABLE, >which should support other type of hw partitions as well? How hardware partitions, LUNs, ATA drives are enumerated is specific to the type of controller while the type of software partition table is independent of the block device. > >|-- eMMC controller (UCLASS_MMC) >| |-- eMMC device1 / Physical media (UCLASS_HW_PARTITION_TABLE?) >| |-- Block device / HW Partition:user data (UCLASS_BLK) >| | |-- Partition table (UCLASS_PARTITION_TABLE) >| | |-- Software Partition (UCLASS_BLK) >| | |-- File system (UCLASS_FS) >| | >| |-- Block device / HW Partition:boot0 (UCLASS_BLK) >| |-- Block device / HW Partition:boot1 (UCLASS_BLK) > ... >| |-- eMMC device2 / Physical media (UCLASS_HW_PARTITION_TABLE?) > >|-- scsi controller (UCLASS_SCSI) >| |-- scsi disk / Physical media (UCLASS_HW_PARTITION_TABLE?) >| |-- scsi LUN1 (UCLASS_HW_PARTITION_TABLE?) >| | |-- Partition table (UCLASS_PARTITION_TABLE) >| | |-- Software Partition (UCLASS_BLK) >| |-- scsi LUN2 (UCLASS_HW_PARTITION_TABLE?) > ... > >(Here I ignored scsi buses/channels which make things more complicated.) > >This kind of complex hierarchy doesn't benefit anybody. All these levels exist already. We simply do not model them yet in the DM way. The device tree depth is the outcome of the udevice exposing always only a single interface defined by the uclass. The UEFI design allows installing multiple protocol interfaces on a single handle. This may result in simpler device trees in some cases. Best regards Heinrich > >-Takahiro Akashi > >> UCLASS_PARTITION_TABLE would be for the drivers in disk/. >> UCLASS_FS would be for the
Re: [PATCH V2 1/6] ARM: rmobile: Enable board detection when FIT is enabled
On Tue, Oct 5, 2021 at 7:35 AM Adam Ford wrote:
>
> On Mon, Sep 20, 2021 at 11:14 AM Adam Ford wrote:
> >
> > There are three boards from Beacon, RZ/G2 M/N/H which all
> > use the same board file, but different device trees.
> > Add code to automatically select the proper device tree
> > based on the CPU type.
> >
> > Signed-off-by: Adam Ford
>
> Marek,
>
> You previously asked me to remind you after 2 weeks, so it doesn't get
> too stale. I rebased at the time I did the V2. Can you give
> feedback?
Marek,
Ping #2. It's been three weeks since my last ping, and I was hoping
you might have some feedback and/or be able to apply this.
thank you,
adam
>
> thank you,
>
> adam
> > ---
> > board/beacon/beacon-rzg2m/beacon-rzg2m.c | 16
> > 1 file changed, 16 insertions(+)
> >
> > diff --git a/board/beacon/beacon-rzg2m/beacon-rzg2m.c
> > b/board/beacon/beacon-rzg2m/beacon-rzg2m.c
> > index c12ff77fb2..b3521fcbc1 100644
> > --- a/board/beacon/beacon-rzg2m/beacon-rzg2m.c
> > +++ b/board/beacon/beacon-rzg2m/beacon-rzg2m.c
> > @@ -36,3 +36,19 @@ void reset_cpu(void)
> > {
> > writel(RST_CODE, RST_CA57RESCNT);
> > }
> > +
> > +#if IS_ENABLED(CONFIG_MULTI_DTB_FIT)
> > +int board_fit_config_name_match(const char *name)
> > +{
> > + if (!strcmp(rzg_get_cpu_name(), "R8A774A1") && !strcmp(name,
> > "r8a774a1-beacon-rzg2m-kit"))
> > + return 0;
> > +
> > + if (!strcmp(rzg_get_cpu_name(), "R8A774B1") && !strcmp(name,
> > "r8a774b1-beacon-rzg2n-kit"))
> > + return 0;
> > +
> > + if (!strcmp(rzg_get_cpu_name(), "R8A774E1") && !strcmp(name,
> > "r8a774e1-beacon-rzg2h-kit"))
> > + return 0;
> > +
> > + return -1;
> > +}
> > +#endif
> > --
> > 2.25.1
> >
Re: [PATCH] board: ti: am335x: Choose CPSW or PRUSS configuration based on jumper setting
On Fri, Oct 29, 2021 at 04:08:17PM +0200, Amjad Ouled-Ameur wrote: > The am335x-ice-v2 board's Ethernet ports can be configured > in 'MII' or 'RMII' mode to be connected to 'PRUSS' or 'CPSW' > Ethernet subsystems. > > This patch sets the environment variable 'ice_mii' to > 'mii' or 'rmii' accordingly. Based on that we choose the > appropriate board devicetree i.e. 'am335x-ice-v2.dtb' or > 'am335x-ice-v2-prueth.dtb'. > > Since there are 2 Ethernet ports with 2 modes, there can be 4 > configurations but for now we consider both ports in different modes > to be an invalid configuration and prevent boot in that case. > > Signed-off-by: Roger Quadros > [Amjad: use overlay instead of using new am335x-ice-v2-prueth.dtb] > Signed-off-by: Amjad Ouled-Ameur > > Reviewed-by: Tom Rini -- Tom signature.asc Description: PGP signature
Re: [GIT PULL] Please pull u-boot-mmc master
On Fri, Oct 29, 2021 at 07:52:00PM +0900, Jaehoon Chung wrote: > Hi Tom, > > Please pull u-boot-mmc master into u-boot master branch. > If there is a problem, let me know, plz. > > Best Regards, > Jaehoon Chung > > CI: https://source.denx.de/u-boot/custodians/u-boot-mmc/-/pipelines/9649 > > The following changes since commit aafc378a6caef453a40f2f9f3d6bef69e592c28d: > > Merge https://source.denx.de/u-boot/custodians/u-boot-marvell (2021-10-28 > 07:57:54 -0400) > > are available in the Git repository at: > > g...@source.denx.de:u-boot/custodians/u-boot-mmc.git master > > for you to fetch changes up to c95b0297e95613fc68b1d92118ee64720d142f8c: > > mmc: arm_pl180_mmci: Enable HWFC for specific versions of MCI (2021-10-29 > 18:22:32 +0900) > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] ARM: amlogic: add JetHub D1 eth mac generation with manufacturer OUI
On 29/10/2021 16:49, Vyacheslav wrote: > #include Thanks, Applied & squashed ! Neil
Re: [PATCH v2 31/41] bootstd: Add an implementation of EFI boot
Hi Mark, On Fri, 29 Oct 2021 at 19:37, Mark Kettenis wrote: > > > From: Ilias Apalodimas > > Date: Fri, 29 Oct 2021 16:42:45 +0300 > > > > Hi Tom, > > > > On Fri, 29 Oct 2021 at 15:39, Tom Rini wrote: > > > > > > On Fri, Oct 29, 2021 at 08:45:06AM +0300, Ilias Apalodimas wrote: > > > > On Wed, Oct 27, 2021 at 12:34:40PM -0600, Simon Glass wrote: > > > > > Hi Ilias, > > > > > > > > > > On Wed, 27 Oct 2021 at 08:48, Ilias Apalodimas > > > > > wrote: > > > > > > > > > > > > Hi Simon, > > > > > > > > > > > > On Wed, Oct 27, 2021 at 08:09:04AM -0600, Simon Glass wrote: > > > > > > > Hi Ilias, > > > > > > > > > > > > > > On Wed, 27 Oct 2021 at 02:36, Ilias Apalodimas > > > > > > > wrote: > > > > > > > > > > > > > > > > Hi Simon, > > > > > > > > > > > > > > > > On Sun, 24 Oct 2021 at 02:27, Simon Glass > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > Add a bootmeth driver which handles EFI boot, using > > > > > > > > > EFI_LOADER. > > > > > > > > > > > > > > > > > > In effect, this provides the same functionality as the > > > > > > > > > 'bootefi' command > > > > > > > > > and shares the same code. But the interface into it is via a > > > > > > > > > bootmeth, > > > > > > > > > so it does not require any special scripts, etc. > > > > > > > > > > > > > > > > > > For now this requires the 'bootefi' command be enabled. > > > > > > > > > Future work may > > > > > > > > > tidy this up so that it can be used without CONFIG_CMDLINE > > > > > > > > > being enabled. > > > > > > > > > > > > > > > > I'll leave this up to Heinrich, but personally I wouldn't > > > > > > > > include this > > > > > > > > patch at all. EFI has it's bootmgr which can handle booting > > > > > > > > just fine. > > > > > > > > I don't see why we should duplicate the functionality. The new > > > > > > > > boot > > > > > > > > method can just have an entry called 'EFI' and then let the > > > > > > > > existing > > > > > > > > EFI code to decide. > > > > > > > > > > > > > > This is needed so that EFI boot is actually invoked. If bootmgr > > > > > > > starts > > > > > > > being used then it can still be invoked from standard boot. The > > > > > > > point > > > > > > > is that there is a standard way of booting that supports EFI and > > > > > > > other > > > > > > > things. > > > > > > > > > > > > This patch tries to reason about the default naming EFI imposes on > > > > > > it's > > > > > > boot files. distro_efi_read_bootflow() will try to find files > > > > > > following the > > > > > > EFI naming convention (e.g bootaarch64.efi, bootarm.efi etc). If > > > > > > those are > > > > > > found it will try to boot them right? That's not the right thing > > > > > > to do though. > > > > > > On the EFI spec these files are tried if no Boot variables are > > > > > > found. > > > > > > So we can get rid of this entirely, add a dummy entry on the > > > > > > bootflow that > > > > > > says 'boot the efi manager' (which is what the next patch does). > > > > > > > > > > > > The efibootmgr then will check Boot variables and if none are > > > > > > found, > > > > > > it's going to fallback into loading bootaarch64.efi, bootarm.efi etc > > > > > > essentially offering identical functionality. > > > > > > > > > > Yes that's fine, and when EFI's boot manager is in use I have a driver > > > > > for that too, as you can see in the other patch. We may need to adjust > > > > > the order, by the sound of it, if it needs to run before EFI things. > > > > > But that is easy enough. > > > > > > > > That's the point though. I don't want to have 2 different ways of > > > > booting EFI > > > > as I don't see any benefit. Do you? > > > > > > Unless we're saying that "bootefi bootmgr" is ready to be used always > > > and without further pre-req support (which I don't think is quite the > > > case, since we don't have persistent EFI vars, so can't set Boot### > > > persistently or via userspace) _something_ is likely needed to either > > > set those, or scan a configurable list of where, to find the EFI > > > payload. > > > > The efibootmgr will try to boot bootaa64.efi, bootarm.efi etc if > > Boot### variables are not found. The Boot themselves are > > obviously configurable from U-Boot(at boot time). Since this method > > doesn't allow Linux to edit the boot options either, is it something > > we need? Since distros usually name their SHIM as bootaa64.efi, I am > > afraid we are adding code that we will rarely (if at all) ever use. > > Hi Ilias, > > I'm still seeing: > > Device 0: Vendor: LexarRev: 1100 Prod: USB Flash Drive > Type: Removable Hard Disk > Capacity: 30526.0 MB = 29.8 GB (62517248 x 512) > ... is now current device > Scanning usb 0:1... > ** Unable to read file / ** > Failed to load '/' > libfdt fdt_check_header(): FDT_ERR_BADMAGIC > BootOrder not defined > EFI boot manager: Cannot load any image > Found EFI removable media binary efi/boot/bootaa64.efi >
Re: [PATCH v5 02/26] doc: Add documentation about devicetree usage
Hi Simon (I keep getting messages about delivery problems so I don't know what went through or not) On Wed, 27 Oct 2021 at 21:52, Simon Glass wrote: > > Hi Ilias, > > On Wed, 27 Oct 2021 at 13:13, Ilias Apalodimas > wrote: > > > > On Wed, 27 Oct 2021 at 21:33, Simon Glass wrote: > > > > > > Hi François, > > > > > > On Wed, 27 Oct 2021 at 09:38, François Ozog > > > wrote: > > > > > > > > Hi Simon, > > > > > > > > On Wed, 27 Oct 2021 at 16:13, Simon Glass wrote: > > > >> > > > >> Hi François, > > > >> > > > >> On Tue, 26 Oct 2021 at 09:57, François Ozog > > > >> wrote: > > > >> > > > > >> > > > > >> > > > > >> > On Tue, 26 Oct 2021 at 17:27, Simon Glass wrote: > > > >> >> > > > >> >> Hi François, > > > >> >> > > > >> >> On Tue, 26 Oct 2021 at 08:31, François Ozog > > > >> >> wrote: > > > >> >> > > > > >> >> > Hi Simon, > > > >> >> > > > > >> >> > On Tue, 26 Oct 2021 at 02:25, Simon Glass > > > >> >> > wrote: > > > >> >> >> > > > >> >> >> At present some of the ideas and techniques behind devicetree in > > > >> >> >> U-Boot > > > >> >> >> are assumed, implied or unsaid. Add some documentation to cover > > > >> >> >> how > > > >> >> >> devicetree is build, how it can be modified and the rules about > > > >> >> >> using > > > >> >> >> the various CONFIG_OF_... options. > > > >> >> >> > > > >> > > > >> [..] > > > >> > > > >> >> >> +Why not have two devicetrees? > > > >> >> >> +- > > > >> >> >> + > > > >> >> >> +Setting aside the argument for restricting U-Boot from having > > > >> >> >> its own nodes and > > > >> >> >> +properties, another idea proposed is to have two devicetrees, > > > >> >> >> one for the > > > >> >> >> +U-Boot-specific bits (here called `special`) and one for > > > >> >> >> everything else (here > > > >> >> >> +called `linux`). > > > >> >> >> + > > > >> >> >> +On the positive side, it might quieten the discussion alluded > > > >> >> >> to in the section > > > >> >> >> +above. But there are many negatives to consider and many open > > > >> >> >> questions to > > > >> >> >> +resolve. > > > >> >> >> + > > > >> >> >> +- **Bindings** - Presumably the special devicetree would have > > > >> >> >> its own bindings. > > > >> >> >> + It would not be necessary to put a `u-boot,` prefix on > > > >> >> >> anything. People coming > > > >> >> >> + across the devicetree source would wonder how it fits in with > > > >> >> >> the Linux > > > >> >> >> + devicetree. > > > >> >> >> + > > > >> >> >> +- **Access** - U-Boot has a nice `ofnode` API for accessing the > > > >> >> >> devicetree. This > > > >> >> >> + would need to be expanded to support two trees. Features > > > >> >> >> which need to access > > > >> >> >> + both (such as a device driver which reads the special > > > >> >> >> devicetree to get some > > > >> >> >> + configuration info) could become quite confusing to read and > > > >> >> >> write. > > > >> >> >> + > > > >> >> >> +- **Merging** - Can the two devicetree be merged if a platform > > > >> >> >> desires it? If > > > >> >> >> + so, how is this managed in tooling? Does it happen during the > > > >> >> >> build, in which > > > >> >> >> + case they are not really separate at all. Or does U-Boot > > > >> >> >> merge them at > > > >> >> >> + runtime, in which case this adds time and memory? > > > >> >> >> + > > > >> >> >> +- **Efficiency** - A second device tree adds more code and more > > > >> >> >> code paths. It > > > >> >> >> + requires that both be made available to the code in U-Boot, > > > >> >> >> e.g. via a > > > >> >> >> + separate pointer or argument or API. Overall the separation > > > >> >> >> would certainly > > > >> >> >> + not speed up U-Boot, nor decrease its size. > > > >> >> >> + > > > >> >> >> +- **Source code** - At present `u-boot.dtsi` files provide the > > > >> >> >> pieces needed for > > > >> >> >> + U-Boot for a particular board. Would we use these same files > > > >> >> >> for the special > > > >> >> >> + devicetree? > > > >> >> >> + > > > >> >> >> +- **Complexity** - Two devicetrees complicates the build system > > > >> >> >> since it must > > > >> >> >> + build and package them both. Errors must be reported in such > > > >> >> >> a way that it > > > >> >> >> + is obvious which one is failing. > > > >> >> >> + > > > >> >> >> +- **Referencing each other** - The `u-boot,dm-xxx` tags used by > > > >> >> >> driver model > > > >> >> >> + are currently placed in the nodes they relate to. How would > > > >> >> >> these tags > > > >> >> >> + reference a node that is in a separate devicetree? What extra > > > >> >> >> validation would > > > >> >> >> + be needed? > > > >> >> >> + > > > >> >> >> +- **Storage** - How would the two devicetrees be stored in the > > > >> >> >> image? At present > > > >> >> >> + we simply concatenate the U-Boot binary and the devicetree. > > > >> >> >> We could add the > > > >> >> >> + special devicetree before the Linux one, so two are > > > >> >> >>
Re: [PATCH v2 31/41] bootstd: Add an implementation of EFI boot
> From: Ilias Apalodimas > Date: Fri, 29 Oct 2021 16:42:45 +0300 > > Hi Tom, > > On Fri, 29 Oct 2021 at 15:39, Tom Rini wrote: > > > > On Fri, Oct 29, 2021 at 08:45:06AM +0300, Ilias Apalodimas wrote: > > > On Wed, Oct 27, 2021 at 12:34:40PM -0600, Simon Glass wrote: > > > > Hi Ilias, > > > > > > > > On Wed, 27 Oct 2021 at 08:48, Ilias Apalodimas > > > > wrote: > > > > > > > > > > Hi Simon, > > > > > > > > > > On Wed, Oct 27, 2021 at 08:09:04AM -0600, Simon Glass wrote: > > > > > > Hi Ilias, > > > > > > > > > > > > On Wed, 27 Oct 2021 at 02:36, Ilias Apalodimas > > > > > > wrote: > > > > > > > > > > > > > > Hi Simon, > > > > > > > > > > > > > > On Sun, 24 Oct 2021 at 02:27, Simon Glass > > > > > > > wrote: > > > > > > > > > > > > > > > > Add a bootmeth driver which handles EFI boot, using EFI_LOADER. > > > > > > > > > > > > > > > > In effect, this provides the same functionality as the > > > > > > > > 'bootefi' command > > > > > > > > and shares the same code. But the interface into it is via a > > > > > > > > bootmeth, > > > > > > > > so it does not require any special scripts, etc. > > > > > > > > > > > > > > > > For now this requires the 'bootefi' command be enabled. Future > > > > > > > > work may > > > > > > > > tidy this up so that it can be used without CONFIG_CMDLINE > > > > > > > > being enabled. > > > > > > > > > > > > > > I'll leave this up to Heinrich, but personally I wouldn't include > > > > > > > this > > > > > > > patch at all. EFI has it's bootmgr which can handle booting just > > > > > > > fine. > > > > > > > I don't see why we should duplicate the functionality. The new > > > > > > > boot > > > > > > > method can just have an entry called 'EFI' and then let the > > > > > > > existing > > > > > > > EFI code to decide. > > > > > > > > > > > > This is needed so that EFI boot is actually invoked. If bootmgr > > > > > > starts > > > > > > being used then it can still be invoked from standard boot. The > > > > > > point > > > > > > is that there is a standard way of booting that supports EFI and > > > > > > other > > > > > > things. > > > > > > > > > > This patch tries to reason about the default naming EFI imposes on > > > > > it's > > > > > boot files. distro_efi_read_bootflow() will try to find files > > > > > following the > > > > > EFI naming convention (e.g bootaarch64.efi, bootarm.efi etc). If > > > > > those are > > > > > found it will try to boot them right? That's not the right thing to > > > > > do though. > > > > > On the EFI spec these files are tried if no Boot variables are > > > > > found. > > > > > So we can get rid of this entirely, add a dummy entry on the > > > > > bootflow that > > > > > says 'boot the efi manager' (which is what the next patch does). > > > > > > > > > > The efibootmgr then will check Boot variables and if none are > > > > > found, > > > > > it's going to fallback into loading bootaarch64.efi, bootarm.efi etc > > > > > essentially offering identical functionality. > > > > > > > > Yes that's fine, and when EFI's boot manager is in use I have a driver > > > > for that too, as you can see in the other patch. We may need to adjust > > > > the order, by the sound of it, if it needs to run before EFI things. > > > > But that is easy enough. > > > > > > That's the point though. I don't want to have 2 different ways of > > > booting EFI > > > as I don't see any benefit. Do you? > > > > Unless we're saying that "bootefi bootmgr" is ready to be used always > > and without further pre-req support (which I don't think is quite the > > case, since we don't have persistent EFI vars, so can't set Boot### > > persistently or via userspace) _something_ is likely needed to either > > set those, or scan a configurable list of where, to find the EFI > > payload. > > The efibootmgr will try to boot bootaa64.efi, bootarm.efi etc if > Boot### variables are not found. The Boot themselves are > obviously configurable from U-Boot(at boot time). Since this method > doesn't allow Linux to edit the boot options either, is it something > we need? Since distros usually name their SHIM as bootaa64.efi, I am > afraid we are adding code that we will rarely (if at all) ever use. Hi Ilias, I'm still seeing: Device 0: Vendor: LexarRev: 1100 Prod: USB Flash Drive Type: Removable Hard Disk Capacity: 30526.0 MB = 29.8 GB (62517248 x 512) ... is now current device Scanning usb 0:1... ** Unable to read file / ** Failed to load '/' libfdt fdt_check_header(): FDT_ERR_BADMAGIC BootOrder not defined EFI boot manager: Cannot load any image Found EFI removable media binary efi/boot/bootaa64.efi 170694 bytes read in 9 ms (18.1 MiB/s) libfdt fdt_check_header(): FDT_ERR_BADMAGIC Booting /efi\boot\bootaa64.efi So it doesn't seem that efibootmgr will try to bootaa64.efi just yet. Cheers, Mark
Re: [PATCH v3 1/3] mmc: rockchip_sdhci: add phy and clock config for rk3399
Hi,
> snip
> +
> +static int rk3399_emmc_get_phy(struct udevice *dev)
> +{
> + struct rockchip_sdhc *priv = dev_get_priv(dev);
> + ofnode phy_node;
> + void *grf_base;
> + u32 grf_phy_offset, phandle;
> +
> + phandle = dev_read_u32_default(dev, "phys", 0);
> + phy_node = ofnode_get_by_phandle(phandle);
> + if (!ofnode_valid(phy_node)) {
> + debug("Not found emmc phy device\n");
> + return -ENODEV;
> + }
I've just upgraded u-boot on my 3399 board and the emmc is failing to
initialise as it can't find this "phys" node. It's a standard board
setup with the following in the DT.
{
bus-width = <8>;
mmc-hs400-1_8v;
mmc-hs400-enhanced-strobe;
non-removable;
status = "okay";
};
_phy {
status = "okay";
};
and a vanilla rk3399.dtsi from 2021.10. Do you have any idea why this
might be failing?
U-Boot SPL 2021.10-00075-g8db2642c55-dirty (Oct 29 2021 - 16:42:46 +0100)
Not found emmc phy device
Trying to boot from MMC1
Has anyone booted a 3399 board sucessfully since these patches went in?
Regards,
Jack.
> +
> + grf_base = syscon_get_first_range(ROCKCHIP_SYSCON_GRF);
> + if (grf_base < 0) {
> + printf("%s Get syscon grf failed", __func__);
> + return -ENODEV;
> + }
> + grf_phy_offset = ofnode_read_u32_default(phy_node, "reg", 0);
> +
> + priv->phy = (struct rockchip_emmc_phy *)(grf_base + grf_phy_offset);
> +
> + return 0;
> +}
> +
> +static int rk3399_sdhci_emmc_set_clock(struct sdhci_host *host, unsigned int
> clock)
> +{
> + struct rockchip_sdhc *priv = container_of(host, struct rockchip_sdhc,
> host);
> + int cycle_phy = host->clock != clock && clock > EMMC_MIN_FREQ;
> +
> + if (cycle_phy)
> + rk3399_emmc_phy_power_off(priv->phy);
> +
> + sdhci_set_clock(host->mmc, clock);
> +
> + if (cycle_phy)
> + rk3399_emmc_phy_power_on(priv->phy, clock);
> +
> + return 0;
> +}
> +
> +static int rockchip_sdhci_set_ios_post(struct sdhci_host *host)
> +{
> + struct rockchip_sdhc *priv = container_of(host, struct rockchip_sdhc,
> host);
> + struct sdhci_data *data = (struct sdhci_data
> *)dev_get_driver_data(priv->dev);
> + struct mmc *mmc = host->mmc;
> + uint clock = mmc->tran_speed;
> + u32 reg;
> +
> + if (!clock)
> + clock = mmc->clock;
> +
> + if (data->emmc_set_clock)
> + data->emmc_set_clock(host, clock);
> +
> + if (mmc->selected_mode == MMC_HS_400 || mmc->selected_mode ==
> MMC_HS_400_ES) {
> + reg = sdhci_readw(host, SDHCI_HOST_CONTROL2);
> + reg &= ~SDHCI_CTRL_UHS_MASK;
> + reg |= SDHCI_CTRL_HS400;
> + sdhci_writew(host, reg, SDHCI_HOST_CONTROL2);
> + } else {
> + sdhci_set_uhs_timing(host);
> + }
> +
> + return 0;
> +}
> +
> +static int rockchip_sdhci_execute_tuning(struct mmc *mmc, u8 opcode)
> +{
> + struct sdhci_host *host = dev_get_priv(mmc->dev);
> + char tuning_loop_counter = SDHCI_TUNING_LOOP_COUNT;
> + struct mmc_cmd cmd;
> + u32 ctrl, blk_size;
> + int ret = 0;
> +
> + ctrl = sdhci_readw(host, SDHCI_HOST_CONTROL2);
> + ctrl |= SDHCI_CTRL_EXEC_TUNING;
> + sdhci_writew(host, ctrl, SDHCI_HOST_CONTROL2);
> +
> + sdhci_writel(host, SDHCI_INT_DATA_AVAIL, SDHCI_INT_ENABLE);
> + sdhci_writel(host, SDHCI_INT_DATA_AVAIL, SDHCI_SIGNAL_ENABLE);
> +
> + blk_size = SDHCI_MAKE_BLKSZ(SDHCI_DEFAULT_BOUNDARY_ARG, 64);
> + if (opcode == MMC_CMD_SEND_TUNING_BLOCK_HS200 && host->mmc->bus_width
> == 8)
> + blk_size = SDHCI_MAKE_BLKSZ(SDHCI_DEFAULT_BOUNDARY_ARG, 128);
> + sdhci_writew(host, blk_size, SDHCI_BLOCK_SIZE);
> + sdhci_writew(host, SDHCI_TRNS_READ, SDHCI_TRANSFER_MODE);
> +
> + cmd.cmdidx = opcode;
> + cmd.resp_type = MMC_RSP_R1;
> + cmd.cmdarg = 0;
> +
> + do {
> + if (tuning_loop_counter-- == 0)
> + break;
> +
> + mmc_send_cmd(mmc, , NULL);
> +
> + if (opcode == MMC_CMD_SEND_TUNING_BLOCK)
> + /*
> + * For tuning command, do not do busy loop. As tuning
> + * is happening (CLK-DATA latching for setup/hold time
> + * requirements), give time to complete
> + */
> + udelay(1);
> +
> + ctrl = sdhci_readw(host, SDHCI_HOST_CONTROL2);
> + } while (ctrl & SDHCI_CTRL_EXEC_TUNING);
> +
> + if (!(ctrl & SDHCI_CTRL_TUNED_CLK)) {
> + printf("%s:Tuning failed\n", __func__);
> + ret = -EIO;
> + }
> +
> + if (tuning_loop_counter < 0) {
> + ctrl &= ~SDHCI_CTRL_TUNED_CLK;
> + sdhci_writel(host, ctrl, SDHCI_HOST_CONTROL2);
> + }
> +
> + /* Enable only interrupts served by the SD controller */
> + sdhci_writel(host, SDHCI_INT_DATA_MASK | SDHCI_INT_CMD_MASK,
Re: Pull request: u-boot-sunxi/master for 2021.10 - 2nd part
On Fri, 29 Oct 2021 23:14:45 +0800
Icenowy Zheng wrote:
> 在 2021-10-29星期五的 10:41 -0400，Tom Rini写道：
> > On Fri, Oct 29, 2021 at 10:20:32PM +0800, Icenowy Zheng wrote:
> > > 在 2021-10-29星期五的 11:53 +0100，Andre Przywara写道：
> > > > On Mon, 25 Oct 2021 14:29:10 -0400
> > > > Tom Rini wrote:
> > > >
> > > > Hi Tom,
> > > >
> > > > > On Mon, Oct 25, 2021 at 03:06:58PM +0100, Andre Przywara wrote:
> > > > >
> > > > > > Hi Tom,
> > > > > >
> > > > > > please pull the second sunxi PR for the 2021.10 merge window.
> > > > > > I decided to merge most of Samuel's rework and some smaller
> > > > > > patches that
> > > > > > pave the way for more DM transitions and for accommodating
> > > > > > the
> > > > > > RISC-V SoC
> > > > > > in the future. Merging them now gives us the opportunity to
> > > > > > get
> > > > > > some wider
> > > > > > testing, since those subtle changes tend to break things.
> > > > > >
> > > > > > Compile-tested for all 159 sunxi boards, boot-tested on
> > > > > > Pine64-
> > > > > > LTS
> > > > > > and OrangePi Zero.
> > > > > >
> > > > > > Summary:
> > > > > > - Add and enable watchdog driver
> > > > > > - Prepare for SYSRESET driven AXP poweroff
> > > > > > - Prepare for SoCs without MMC2
> > > > > > - Some fixes for extending SPL (SPL-DM for RISC-V)
> > > > > > - Some preparations for proper VBUS management
> > > > > > - Fix secure monitor move
> > > > > >
> > > > > > Thanks,
> > > > > > Andre
> > > > > >
> > > > > >
> > > > > > The following changes since commit
> > > > > > 355d1e24f6143c4839be3c015c191421c4e9449c:
> > > > > >
> > > > > > Merge
> > > > > > https://source.denx.de/u-boot/custodians/u-boot-spi (2021-10-
> > > > > > 23
> > > > > > 10:49:28 -0400)
> > > > > >
> > > > > > are available in the Git repository at:
> > > > > >
> > > > > >
> > > > > > https://source.denx.de/u-boot/custodians/u-boot-sunxi.git mas
> > > > > > ter
> > > > > >
> > > > > > for you to fetch changes up to
> > > > > > c846fe43f0561311eb7261b34023a04646cdbd0d:
> > > > > >
> > > > > > mmc: sunxi: conditionally include MMC2 initialization code
> > > > > > (2021-10-25 14:54:57 +0100)
> > > > > >
> > > > >
> > > > > So first, up, this is now applied to u-boot/master.
> > > >
> > > > Many thanks, and sorry for the late push!
> > > >
> > > > > Next, I dug out my original Kickstarted Pine A64 board (as it's
> > > > > the
> > > > > only
> > > > > sunxi platform I have), and I see it's detected with 1GB memory
> > > > > and
> > > > > as
> > > > > Pine64+ which seems wrong, with the pine64_plus_defconfig
> > > > > (which is
> > > > > what
> > > > > I thought handled all of the A64 platforms).
> > > >
> > > > For the naming: There are three SKUs for the original Pine A64
> > > > board:
> > > > - Pine A64: 512 MB with 100Mbit Ethernet PHY, lacking display and
> > > > camera
> > > > connectors (rare, mostly to meet the original 15 USD price tag)
> > > > - Pine A64+ 1GB: 1GB DRAM with 1Gbit Ethernet PHY, with all
> > > > connectors
> > > > - Pine A64+ 2GB: 2GB DRAM with 1Gbit Ethernet PHY, with all
> > > > connectors
> > >
> > > You can check whether your board is non-Plus or Plus 1G by the
> > > model of
> > > the Ethernet PHY (non-Plus has RTL8201) or not soldered FPC
> > > connectors.
> > > They do share a PCB design. Plus 2G is a dedicated PCB design as it
> > > needs to use 4x 512MB DRAM chips.
> >
> > OK, mine has an RTL8211E and is 1G for sure now that I look harder at
> > it.
> >
> > On a related note, this board will draw power via the UART, is there
> > any
> > easy HW change I can do, to fix that? It's otherwise a lot harder to
> > put this in to my CI lab.
>
> What UART pins are you using? The ones in Euler bus or the ones in EXP
> bus?
>
> The UART pins in EXP bus should have transistors to prevent power
> leakage...
Yes, https://linux-sunxi.org/Pine64#Serial_port_.2F_UART has the
details. On the picture it's the pins on the right, next to the SD card
slot.
Cheers,
Andre
>
> >
> > > > Also note that for those first boards from Pine64 the name of the
> > > > company (Pine64) is sometimes uses for the boards as well
> > > > ("Pine64
> > > > board"), even though this should be "Pine A64 board from Pine64".
> > > > That
> > > > is somewhat reflected in the defconfig name. In hindsight the
> > > > defconfig
> > > > should have been named more "pine-a64_defconfig", but I guess
> > > > this is
> > > > too late now? I see a lot of inconsistencies in naming,
> > > > especially
> > > > regarding capitalisation and dashes vs. underscores, check
> > > > configs/[bB]anana* for instance, but probably renaming causes
> > > > more
> > > > harm
> > > > than good?
> > > >
> > > > So I guess you have the middle one (the most common among the
> > > > first
> > > > wave), so that all seems correct? We differentiate between the
> > > > non-
> > > > plus
> > > > and plus version at runtime, by the amount of DRAM
Re: [PATCH v7] arm: add initial support for the Phytium Pomelo Board
On Mon, Sep 13, 2021 at 01:59:11PM +0800, nicholas_zh...@outlook.com wrote:
> From: weichangzheng
>
> This adds platform code and the device tree for the Phytium Pomelo Board.
> The initial support comprises the UART and the PCIE.
>
> Signed-off-by: weichangzheng
> Changes since v1:
> updated to DT
> Changes since v2:
> Modify some explicit types and macro
> Changes since v3:
> Modify some SDRAM related macro definitions and distro_bootcmd
> Changes since v4:
> Modify distro_bootcmd
> Changes since v5:
> Modify the CPU node description of the DT
> Changes since v6:
> Modify DT
> ---
[snip]
> diff --git a/arch/arm/dts/phytium-pomelo.dts b/arch/arm/dts/phytium-pomelo.dts
> new file mode 100644
> index 00..4ed97e090d
> --- /dev/null
> +++ b/arch/arm/dts/phytium-pomelo.dts
> @@ -0,0 +1,118 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * dts file for Phytium Pomelo board
> + * Copyright (C) 2021, Phytium Ltd.
> + * lixinde
> + * weichangzheng
> + */
> +/dts-v1/;
> +
> +/ {
> + model = "Phytium Pomelo";
> + compatible = "phytium,d2000";
> + #address-cells = <2>;
> + #size-cells = <2>;
> +
> + aliases {
> + serial0 =
> + };
> +
> + cpus {
> + #address-cells = <0x2>;
> + #size-cells = <0x0>;
> +
> + cpu0: cpu@0 {
> + device_type = "cpu";
> + compatible = "arm,armv8";
> + reg = <0x0 0x0>;
> + enable-method = "psci";
> + };
> +
> + cpu1: cpu@1 {
> + device_type = "cpu";
> + compatible = "arm,armv8";
> + reg = <0x0 0x1>;
> + enable-method = "psci";
> + };
> +
> + cpu2: cpu@100 {
> + device_type = "cpu";
> + compatible = "arm,armv8";
> + reg = <0x0 0x100>;
> + enable-method = "psci";
> + };
> +
> + cpu3: cpu@101 {
> + device_type = "cpu";
> + compatible = "arm,armv8";
> + reg = <0x0 0x101>;
> + enable-method = "psci";
> + };
> +
> + cpu4: cpu@200 {
> + device_type = "cpu";
> + compatible = "arm,armv8";
> + reg = <0x0 0x200>;
> + enable-method = "psci";
> + };
> +
> + cpu5: cpu@201 {
> + device_type = "cpu";
> + compatible = "arm,armv8";
> + reg = <0x0 0x201>;
> + enable-method = "psci";
> + };
> +
> + cpu6: cpu@300 {
> + device_type = "cpu";
> + compatible = "arm,armv8";
> + reg = <0x0 0x300>;
> + enable-method = "psci";
> + };
> +
> + cpu7: cpu@301 {
> + device_type = "cpu";
> + compatible = "arm,armv8";
> + reg = <0x0 0x301>;
> + enable-method = "psci";
> + };
> + };
> +
> + clocks {
> + #address-cells = <2>;
> + #size-cells = <2>;
> + ranges;
> +
> + sysclk_48mhz: clk48mhz {
> + compatible = "fixed-clock";
> + #clock-cells = <0x0>;
> + clock-frequency = <4800>;
> + clock-output-names = "sysclk_48mhz";
> + };
> + };
> +
> + soc {
> + compatible = "simple-bus";
> + #address-cells = <2>;
> + #size-cells = <2>;
> + ranges;
> +
> + uart0: serial@28001000 {
> + compatible = "arm,pl011";
> + reg = <0x0 0x28001000 0x0 0x1000>;
> + clocks = <_48mhz>;
> + };
> +
> + pcie@4000 {
> + compatible = "pci-host-ecam-generic";
> + device_type = "pci";
> + #address-cells = <3>;
> + #size-cells = <2>;
> + reg = <0x0 0x4000 0x0 0x1000>;
> + bus-range = <0x0 0xff>;
> + ranges = <0x0100 0x00 0x 0x0 0x5000
> 0x0 0x00F0>,
> + <0x0200 0x00 0x5800 0x0 0x5800 0x0
> 0x2800>,
> + <0x4300 0x10 0x 0x10 0x 0x10
> 0x>;
> + };
> + };
> +};
Any further device tree comments, Rob? Thanks!
--
Tom
signature.asc
Description: PGP signature
Re: Pull request: u-boot-sunxi/master for 2021.10 - 2nd part
On Fri, Oct 29, 2021 at 11:14:45PM +0800, Icenowy Zheng wrote: > 在 2021-10-29星期五的 10:41 -0400，Tom Rini写道： > > On Fri, Oct 29, 2021 at 10:20:32PM +0800, Icenowy Zheng wrote: > > > 在 2021-10-29星期五的 11:53 +0100，Andre Przywara写道： > > > > On Mon, 25 Oct 2021 14:29:10 -0400 > > > > Tom Rini wrote: > > > > > > > > Hi Tom, > > > > > > > > > On Mon, Oct 25, 2021 at 03:06:58PM +0100, Andre Przywara wrote: > > > > > > > > > > > Hi Tom, > > > > > > > > > > > > please pull the second sunxi PR for the 2021.10 merge window. > > > > > > I decided to merge most of Samuel's rework and some smaller > > > > > > patches that > > > > > > pave the way for more DM transitions and for accommodating > > > > > > the > > > > > > RISC-V SoC > > > > > > in the future. Merging them now gives us the opportunity to > > > > > > get > > > > > > some wider > > > > > > testing, since those subtle changes tend to break things. > > > > > > > > > > > > Compile-tested for all 159 sunxi boards, boot-tested on > > > > > > Pine64- > > > > > > LTS > > > > > > and OrangePi Zero. > > > > > > > > > > > > Summary: > > > > > > - Add and enable watchdog driver > > > > > > - Prepare for SYSRESET driven AXP poweroff > > > > > > - Prepare for SoCs without MMC2 > > > > > > - Some fixes for extending SPL (SPL-DM for RISC-V) > > > > > > - Some preparations for proper VBUS management > > > > > > - Fix secure monitor move > > > > > > > > > > > > Thanks, > > > > > > Andre > > > > > > > > > > > > > > > > > > The following changes since commit > > > > > > 355d1e24f6143c4839be3c015c191421c4e9449c: > > > > > > > > > > > > Merge > > > > > > https://source.denx.de/u-boot/custodians/u-boot-spi (2021-10- > > > > > > 23 > > > > > > 10:49:28 -0400) > > > > > > > > > > > > are available in the Git repository at: > > > > > > > > > > > > > > > > > > https://source.denx.de/u-boot/custodians/u-boot-sunxi.git mas > > > > > > ter > > > > > > > > > > > > for you to fetch changes up to > > > > > > c846fe43f0561311eb7261b34023a04646cdbd0d: > > > > > > > > > > > > mmc: sunxi: conditionally include MMC2 initialization code > > > > > > (2021-10-25 14:54:57 +0100) > > > > > > > > > > > > > > > > So first, up, this is now applied to u-boot/master. > > > > > > > > Many thanks, and sorry for the late push! > > > > > > > > > Next, I dug out my original Kickstarted Pine A64 board (as it's > > > > > the > > > > > only > > > > > sunxi platform I have), and I see it's detected with 1GB memory > > > > > and > > > > > as > > > > > Pine64+ which seems wrong, with the pine64_plus_defconfig > > > > > (which is > > > > > what > > > > > I thought handled all of the A64 platforms). > > > > > > > > For the naming: There are three SKUs for the original Pine A64 > > > > board: > > > > - Pine A64: 512 MB with 100Mbit Ethernet PHY, lacking display and > > > > camera > > > > connectors (rare, mostly to meet the original 15 USD price tag) > > > > - Pine A64+ 1GB: 1GB DRAM with 1Gbit Ethernet PHY, with all > > > > connectors > > > > - Pine A64+ 2GB: 2GB DRAM with 1Gbit Ethernet PHY, with all > > > > connectors > > > > > > You can check whether your board is non-Plus or Plus 1G by the > > > model of > > > the Ethernet PHY (non-Plus has RTL8201) or not soldered FPC > > > connectors. > > > They do share a PCB design. Plus 2G is a dedicated PCB design as it > > > needs to use 4x 512MB DRAM chips. > > > > OK, mine has an RTL8211E and is 1G for sure now that I look harder at > > it. > > > > On a related note, this board will draw power via the UART, is there > > any > > easy HW change I can do, to fix that? It's otherwise a lot harder to > > put this in to my CI lab. > > What UART pins are you using? The ones in Euler bus or the ones in EXP > bus? > > The UART pins in EXP bus should have transistors to prevent power > leakage... It's the EXP header (I've got the UART adapter from the kickstarter) and I swear I saw the power LED staying on at least twice, in my previous experiments. But maybe that was just some bad luck / timing and capacitor draining still or something, rather than continued leakage. I'll assume user error until I can reliably break it. Thanks again! -- Tom signature.asc Description: PGP signature
Re: Pull request: u-boot-sunxi/master for 2021.10 - 2nd part
在 2021-10-29星期五的 10:41 -0400，Tom Rini写道：
> On Fri, Oct 29, 2021 at 10:20:32PM +0800, Icenowy Zheng wrote:
> > 在 2021-10-29星期五的 11:53 +0100，Andre Przywara写道：
> > > On Mon, 25 Oct 2021 14:29:10 -0400
> > > Tom Rini wrote:
> > >
> > > Hi Tom,
> > >
> > > > On Mon, Oct 25, 2021 at 03:06:58PM +0100, Andre Przywara wrote:
> > > >
> > > > > Hi Tom,
> > > > >
> > > > > please pull the second sunxi PR for the 2021.10 merge window.
> > > > > I decided to merge most of Samuel's rework and some smaller
> > > > > patches that
> > > > > pave the way for more DM transitions and for accommodating
> > > > > the
> > > > > RISC-V SoC
> > > > > in the future. Merging them now gives us the opportunity to
> > > > > get
> > > > > some wider
> > > > > testing, since those subtle changes tend to break things.
> > > > >
> > > > > Compile-tested for all 159 sunxi boards, boot-tested on
> > > > > Pine64-
> > > > > LTS
> > > > > and OrangePi Zero.
> > > > >
> > > > > Summary:
> > > > > - Add and enable watchdog driver
> > > > > - Prepare for SYSRESET driven AXP poweroff
> > > > > - Prepare for SoCs without MMC2
> > > > > - Some fixes for extending SPL (SPL-DM for RISC-V)
> > > > > - Some preparations for proper VBUS management
> > > > > - Fix secure monitor move
> > > > >
> > > > > Thanks,
> > > > > Andre
> > > > >
> > > > >
> > > > > The following changes since commit
> > > > > 355d1e24f6143c4839be3c015c191421c4e9449c:
> > > > >
> > > > > Merge
> > > > > https://source.denx.de/u-boot/custodians/u-boot-spi (2021-10-
> > > > > 23
> > > > > 10:49:28 -0400)
> > > > >
> > > > > are available in the Git repository at:
> > > > >
> > > > >
> > > > > https://source.denx.de/u-boot/custodians/u-boot-sunxi.git mas
> > > > > ter
> > > > >
> > > > > for you to fetch changes up to
> > > > > c846fe43f0561311eb7261b34023a04646cdbd0d:
> > > > >
> > > > > mmc: sunxi: conditionally include MMC2 initialization code
> > > > > (2021-10-25 14:54:57 +0100)
> > > > >
> > > >
> > > > So first, up, this is now applied to u-boot/master.
> > >
> > > Many thanks, and sorry for the late push!
> > >
> > > > Next, I dug out my original Kickstarted Pine A64 board (as it's
> > > > the
> > > > only
> > > > sunxi platform I have), and I see it's detected with 1GB memory
> > > > and
> > > > as
> > > > Pine64+ which seems wrong, with the pine64_plus_defconfig
> > > > (which is
> > > > what
> > > > I thought handled all of the A64 platforms).
> > >
> > > For the naming: There are three SKUs for the original Pine A64
> > > board:
> > > - Pine A64: 512 MB with 100Mbit Ethernet PHY, lacking display and
> > > camera
> > > connectors (rare, mostly to meet the original 15 USD price tag)
> > > - Pine A64+ 1GB: 1GB DRAM with 1Gbit Ethernet PHY, with all
> > > connectors
> > > - Pine A64+ 2GB: 2GB DRAM with 1Gbit Ethernet PHY, with all
> > > connectors
> >
> > You can check whether your board is non-Plus or Plus 1G by the
> > model of
> > the Ethernet PHY (non-Plus has RTL8201) or not soldered FPC
> > connectors.
> > They do share a PCB design. Plus 2G is a dedicated PCB design as it
> > needs to use 4x 512MB DRAM chips.
>
> OK, mine has an RTL8211E and is 1G for sure now that I look harder at
> it.
>
> On a related note, this board will draw power via the UART, is there
> any
> easy HW change I can do, to fix that? It's otherwise a lot harder to
> put this in to my CI lab.
What UART pins are you using? The ones in Euler bus or the ones in EXP
bus?
The UART pins in EXP bus should have transistors to prevent power
leakage...
>
> > > Also note that for those first boards from Pine64 the name of the
> > > company (Pine64) is sometimes uses for the boards as well
> > > ("Pine64
> > > board"), even though this should be "Pine A64 board from Pine64".
> > > That
> > > is somewhat reflected in the defconfig name. In hindsight the
> > > defconfig
> > > should have been named more "pine-a64_defconfig", but I guess
> > > this is
> > > too late now? I see a lot of inconsistencies in naming,
> > > especially
> > > regarding capitalisation and dashes vs. underscores, check
> > > configs/[bB]anana* for instance, but probably renaming causes
> > > more
> > > harm
> > > than good?
> > >
> > > So I guess you have the middle one (the most common among the
> > > first
> > > wave), so that all seems correct? We differentiate between the
> > > non-
> > > plus
> > > and plus version at runtime, by the amount of DRAM detected, so
> > > that's
> > > pretty reliable. The 1GB and 2GB are otherwise the same, so same
> > > DT.
> > > The actual non-plus versions are somewhat rare, I guess most
> > > people
> > > just added the 4(!) bucks to get more RAM and Gigabit Ethernet.
> > >
> > > > I've not booted this up in
> > > > forever, and Armbian (the first binary I grabbed) does this as
> > > > well
> > > > with
> > > > v2020.10 (and I'm using the same TF-A rev of 87311b4) so maybe
> > > > the
> > > > answer is I should just
[PATCH v3] cmd: usb_mass_storage: Use part_get_info_by_dev_and_name_or_num
This allows specifying partitions using more extended syntax. This is particularly useful to access eMMC hardware partitions. For example, this allows something like ums 0 mmc 0.0,0.1,0.2,0.3 to expose four LUNs for each of the four default eMMC hardware partitions. Note that the comma syntax was already present, and this syntax is already documented. Signed-off-by: Sean Anderson --- Changes in v3: - Fix example in commit message Changes in v2: - Reword commit message to include an example cmd/usb_mass_storage.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/cmd/usb_mass_storage.c b/cmd/usb_mass_storage.c index 14fa7233c7..d4e619b842 100644 --- a/cmd/usb_mass_storage.c +++ b/cmd/usb_mass_storage.c @@ -74,8 +74,8 @@ static int ums_init(const char *devtype, const char *devnums_part_str) if (!devnum_part_str) break; - partnum = blk_get_device_part_str(devtype, devnum_part_str, - _dev, , 1); + partnum = part_get_info_by_dev_and_name_or_num(devtype, devnum_part_str, + _dev, , 1); if (partnum < 0) goto cleanup; -- 2.25.1
Re: Pull request: u-boot-sunxi/master for 2021.10 - 2nd part
On Fri, Oct 29, 2021 at 10:41:01AM -0400, Tom Rini wrote:
> On Fri, Oct 29, 2021 at 10:20:32PM +0800, Icenowy Zheng wrote:
> > 在 2021-10-29星期五的 11:53 +0100，Andre Przywara写道：
> > > On Mon, 25 Oct 2021 14:29:10 -0400
> > > Tom Rini wrote:
> > >
> > > Hi Tom,
> > >
> > > > On Mon, Oct 25, 2021 at 03:06:58PM +0100, Andre Przywara wrote:
> > > >
> > > > > Hi Tom,
> > > > >
> > > > > please pull the second sunxi PR for the 2021.10 merge window.
> > > > > I decided to merge most of Samuel's rework and some smaller
> > > > > patches that
> > > > > pave the way for more DM transitions and for accommodating the
> > > > > RISC-V SoC
> > > > > in the future. Merging them now gives us the opportunity to get
> > > > > some wider
> > > > > testing, since those subtle changes tend to break things.
> > > > >
> > > > > Compile-tested for all 159 sunxi boards, boot-tested on Pine64-
> > > > > LTS
> > > > > and OrangePi Zero.
> > > > >
> > > > > Summary:
> > > > > - Add and enable watchdog driver
> > > > > - Prepare for SYSRESET driven AXP poweroff
> > > > > - Prepare for SoCs without MMC2
> > > > > - Some fixes for extending SPL (SPL-DM for RISC-V)
> > > > > - Some preparations for proper VBUS management
> > > > > - Fix secure monitor move
> > > > >
> > > > > Thanks,
> > > > > Andre
> > > > >
> > > > >
> > > > > The following changes since commit
> > > > > 355d1e24f6143c4839be3c015c191421c4e9449c:
> > > > >
> > > > > Merge
> > > > > https://source.denx.de/u-boot/custodians/u-boot-spi (2021-10-23
> > > > > 10:49:28 -0400)
> > > > >
> > > > > are available in the Git repository at:
> > > > >
> > > > >
> > > > > https://source.denx.de/u-boot/custodians/u-boot-sunxi.git master
> > > > >
> > > > > for you to fetch changes up to
> > > > > c846fe43f0561311eb7261b34023a04646cdbd0d:
> > > > >
> > > > > mmc: sunxi: conditionally include MMC2 initialization code
> > > > > (2021-10-25 14:54:57 +0100)
> > > > >
> > > >
> > > > So first, up, this is now applied to u-boot/master.
> > >
> > > Many thanks, and sorry for the late push!
> > >
> > > > Next, I dug out my original Kickstarted Pine A64 board (as it's the
> > > > only
> > > > sunxi platform I have), and I see it's detected with 1GB memory and
> > > > as
> > > > Pine64+ which seems wrong, with the pine64_plus_defconfig (which is
> > > > what
> > > > I thought handled all of the A64 platforms).
> > >
> > > For the naming: There are three SKUs for the original Pine A64 board:
> > > - Pine A64: 512 MB with 100Mbit Ethernet PHY, lacking display and
> > > camera
> > > connectors (rare, mostly to meet the original 15 USD price tag)
> > > - Pine A64+ 1GB: 1GB DRAM with 1Gbit Ethernet PHY, with all
> > > connectors
> > > - Pine A64+ 2GB: 2GB DRAM with 1Gbit Ethernet PHY, with all
> > > connectors
> >
> > You can check whether your board is non-Plus or Plus 1G by the model of
> > the Ethernet PHY (non-Plus has RTL8201) or not soldered FPC connectors.
> > They do share a PCB design. Plus 2G is a dedicated PCB design as it
> > needs to use 4x 512MB DRAM chips.
>
> OK, mine has an RTL8211E and is 1G for sure now that I look harder at
> it.
>
> On a related note, this board will draw power via the UART, is there any
> easy HW change I can do, to fix that? It's otherwise a lot harder to
> put this in to my CI lab.
>
> > > Also note that for those first boards from Pine64 the name of the
> > > company (Pine64) is sometimes uses for the boards as well ("Pine64
> > > board"), even though this should be "Pine A64 board from Pine64".
> > > That
> > > is somewhat reflected in the defconfig name. In hindsight the
> > > defconfig
> > > should have been named more "pine-a64_defconfig", but I guess this is
> > > too late now? I see a lot of inconsistencies in naming, especially
> > > regarding capitalisation and dashes vs. underscores, check
> > > configs/[bB]anana* for instance, but probably renaming causes more
> > > harm
> > > than good?
> > >
> > > So I guess you have the middle one (the most common among the first
> > > wave), so that all seems correct? We differentiate between the non-
> > > plus
> > > and plus version at runtime, by the amount of DRAM detected, so
> > > that's
> > > pretty reliable. The 1GB and 2GB are otherwise the same, so same DT.
> > > The actual non-plus versions are somewhat rare, I guess most people
> > > just added the 4(!) bucks to get more RAM and Gigabit Ethernet.
> > >
> > > > I've not booted this up in
> > > > forever, and Armbian (the first binary I grabbed) does this as well
> > > > with
> > > > v2020.10 (and I'm using the same TF-A rev of 87311b4) so maybe the
> > > > answer is I should just e-waste this board and pick up something
> > > > else?
> > >
> > > Not sure exactly why? Is there anything that's broken, apart from the
> > > presumed misnaming? I would be happy to hear about any issues you
> > > have,
> > > in my experience those "outsider" inputs are very useful (I am far
>
Re: [PATCH] ARM: amlogic: add JetHub D1 eth mac generation with manufacturer OUI
Fix build warning in misc_init_r jethub-j100.c
Signed-off-by: Vyacheslav Bocharov
---
board/amlogic/jethub-j100/jethub-j100.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/board/amlogic/jethub-j100/jethub-j100.c
b/board/amlogic/jethub-j100/jethub-j100.c
index 575bb31573..6a2c4ad4c3 100644
--- a/board/amlogic/jethub-j100/jethub-j100.c
+++ b/board/amlogic/jethub-j100/jethub-j100.c
@@ -13,6 +13,7 @@
#include
#include
#include
+#include
int misc_init_r(void)
{
--
2.30.2
Re: Pull request: u-boot-sunxi/master for 2021.10 - 2nd part
On Fri, Oct 29, 2021 at 10:20:32PM +0800, Icenowy Zheng wrote:
> 在 2021-10-29星期五的 11:53 +0100，Andre Przywara写道：
> > On Mon, 25 Oct 2021 14:29:10 -0400
> > Tom Rini wrote:
> >
> > Hi Tom,
> >
> > > On Mon, Oct 25, 2021 at 03:06:58PM +0100, Andre Przywara wrote:
> > >
> > > > Hi Tom,
> > > >
> > > > please pull the second sunxi PR for the 2021.10 merge window.
> > > > I decided to merge most of Samuel's rework and some smaller
> > > > patches that
> > > > pave the way for more DM transitions and for accommodating the
> > > > RISC-V SoC
> > > > in the future. Merging them now gives us the opportunity to get
> > > > some wider
> > > > testing, since those subtle changes tend to break things.
> > > >
> > > > Compile-tested for all 159 sunxi boards, boot-tested on Pine64-
> > > > LTS
> > > > and OrangePi Zero.
> > > >
> > > > Summary:
> > > > - Add and enable watchdog driver
> > > > - Prepare for SYSRESET driven AXP poweroff
> > > > - Prepare for SoCs without MMC2
> > > > - Some fixes for extending SPL (SPL-DM for RISC-V)
> > > > - Some preparations for proper VBUS management
> > > > - Fix secure monitor move
> > > >
> > > > Thanks,
> > > > Andre
> > > >
> > > >
> > > > The following changes since commit
> > > > 355d1e24f6143c4839be3c015c191421c4e9449c:
> > > >
> > > > Merge
> > > > https://source.denx.de/u-boot/custodians/u-boot-spi (2021-10-23
> > > > 10:49:28 -0400)
> > > >
> > > > are available in the Git repository at:
> > > >
> > > >
> > > > https://source.denx.de/u-boot/custodians/u-boot-sunxi.git master
> > > >
> > > > for you to fetch changes up to
> > > > c846fe43f0561311eb7261b34023a04646cdbd0d:
> > > >
> > > > mmc: sunxi: conditionally include MMC2 initialization code
> > > > (2021-10-25 14:54:57 +0100)
> > > >
> > >
> > > So first, up, this is now applied to u-boot/master.
> >
> > Many thanks, and sorry for the late push!
> >
> > > Next, I dug out my original Kickstarted Pine A64 board (as it's the
> > > only
> > > sunxi platform I have), and I see it's detected with 1GB memory and
> > > as
> > > Pine64+ which seems wrong, with the pine64_plus_defconfig (which is
> > > what
> > > I thought handled all of the A64 platforms).
> >
> > For the naming: There are three SKUs for the original Pine A64 board:
> > - Pine A64: 512 MB with 100Mbit Ethernet PHY, lacking display and
> > camera
> > connectors (rare, mostly to meet the original 15 USD price tag)
> > - Pine A64+ 1GB: 1GB DRAM with 1Gbit Ethernet PHY, with all
> > connectors
> > - Pine A64+ 2GB: 2GB DRAM with 1Gbit Ethernet PHY, with all
> > connectors
>
> You can check whether your board is non-Plus or Plus 1G by the model of
> the Ethernet PHY (non-Plus has RTL8201) or not soldered FPC connectors.
> They do share a PCB design. Plus 2G is a dedicated PCB design as it
> needs to use 4x 512MB DRAM chips.
OK, mine has an RTL8211E and is 1G for sure now that I look harder at
it.
On a related note, this board will draw power via the UART, is there any
easy HW change I can do, to fix that? It's otherwise a lot harder to
put this in to my CI lab.
> > Also note that for those first boards from Pine64 the name of the
> > company (Pine64) is sometimes uses for the boards as well ("Pine64
> > board"), even though this should be "Pine A64 board from Pine64".
> > That
> > is somewhat reflected in the defconfig name. In hindsight the
> > defconfig
> > should have been named more "pine-a64_defconfig", but I guess this is
> > too late now? I see a lot of inconsistencies in naming, especially
> > regarding capitalisation and dashes vs. underscores, check
> > configs/[bB]anana* for instance, but probably renaming causes more
> > harm
> > than good?
> >
> > So I guess you have the middle one (the most common among the first
> > wave), so that all seems correct? We differentiate between the non-
> > plus
> > and plus version at runtime, by the amount of DRAM detected, so
> > that's
> > pretty reliable. The 1GB and 2GB are otherwise the same, so same DT.
> > The actual non-plus versions are somewhat rare, I guess most people
> > just added the 4(!) bucks to get more RAM and Gigabit Ethernet.
> >
> > > I've not booted this up in
> > > forever, and Armbian (the first binary I grabbed) does this as well
> > > with
> > > v2020.10 (and I'm using the same TF-A rev of 87311b4) so maybe the
> > > answer is I should just e-waste this board and pick up something
> > > else?
> >
> > Not sure exactly why? Is there anything that's broken, apart from the
> > presumed misnaming? I would be happy to hear about any issues you
> > have,
> > in my experience those "outsider" inputs are very useful (I am far
> > too
> > familiar with all those tiny quirks).
> > When U-Boot starts, UEFI boot should work out of the box, just pop a
> > generic arm64 Debian/SuSE/Fedora/Ubuntu EFI installer USB stick in,
> > should work even with HDMI and USB keyboard.
Ah, so Armbian is a fails to boot (I can't even
Re: [PATCH v2 31/41] bootstd: Add an implementation of EFI boot
On Fri, 29 Oct 2021 at 17:03, AKASHI Takahiro wrote: > > On Fri, Oct 29, 2021 at 04:42:45PM +0300, Ilias Apalodimas wrote: > > Hi Tom, > > > > On Fri, 29 Oct 2021 at 15:39, Tom Rini wrote: > > > > > > On Fri, Oct 29, 2021 at 08:45:06AM +0300, Ilias Apalodimas wrote: > > > > On Wed, Oct 27, 2021 at 12:34:40PM -0600, Simon Glass wrote: > > > > > Hi Ilias, > > > > > > > > > > On Wed, 27 Oct 2021 at 08:48, Ilias Apalodimas > > > > > wrote: > > > > > > > > > > > > Hi Simon, > > > > > > > > > > > > On Wed, Oct 27, 2021 at 08:09:04AM -0600, Simon Glass wrote: > > > > > > > Hi Ilias, > > > > > > > > > > > > > > On Wed, 27 Oct 2021 at 02:36, Ilias Apalodimas > > > > > > > wrote: > > > > > > > > > > > > > > > > Hi Simon, > > > > > > > > > > > > > > > > On Sun, 24 Oct 2021 at 02:27, Simon Glass > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > Add a bootmeth driver which handles EFI boot, using > > > > > > > > > EFI_LOADER. > > > > > > > > > > > > > > > > > > In effect, this provides the same functionality as the > > > > > > > > > 'bootefi' command > > > > > > > > > and shares the same code. But the interface into it is via a > > > > > > > > > bootmeth, > > > > > > > > > so it does not require any special scripts, etc. > > > > > > > > > > > > > > > > > > For now this requires the 'bootefi' command be enabled. > > > > > > > > > Future work may > > > > > > > > > tidy this up so that it can be used without CONFIG_CMDLINE > > > > > > > > > being enabled. > > > > > > > > > > > > > > > > I'll leave this up to Heinrich, but personally I wouldn't > > > > > > > > include this > > > > > > > > patch at all. EFI has it's bootmgr which can handle booting > > > > > > > > just fine. > > > > > > > > I don't see why we should duplicate the functionality. The new > > > > > > > > boot > > > > > > > > method can just have an entry called 'EFI' and then let the > > > > > > > > existing > > > > > > > > EFI code to decide. > > > > > > > > > > > > > > This is needed so that EFI boot is actually invoked. If bootmgr > > > > > > > starts > > > > > > > being used then it can still be invoked from standard boot. The > > > > > > > point > > > > > > > is that there is a standard way of booting that supports EFI and > > > > > > > other > > > > > > > things. > > > > > > > > > > > > This patch tries to reason about the default naming EFI imposes on > > > > > > it's > > > > > > boot files. distro_efi_read_bootflow() will try to find files > > > > > > following the > > > > > > EFI naming convention (e.g bootaarch64.efi, bootarm.efi etc). If > > > > > > those are > > > > > > found it will try to boot them right? That's not the right thing > > > > > > to do though. > > > > > > On the EFI spec these files are tried if no Boot variables are > > > > > > found. > > > > > > So we can get rid of this entirely, add a dummy entry on the > > > > > > bootflow that > > > > > > says 'boot the efi manager' (which is what the next patch does). > > > > > > > > > > > > The efibootmgr then will check Boot variables and if none are > > > > > > found, > > > > > > it's going to fallback into loading bootaarch64.efi, bootarm.efi etc > > > > > > essentially offering identical functionality. > > > > > > > > > > Yes that's fine, and when EFI's boot manager is in use I have a driver > > > > > for that too, as you can see in the other patch. We may need to adjust > > > > > the order, by the sound of it, if it needs to run before EFI things. > > > > > But that is easy enough. > > > > > > > > That's the point though. I don't want to have 2 different ways of > > > > booting EFI > > > > as I don't see any benefit. Do you? > > > > > > Unless we're saying that "bootefi bootmgr" is ready to be used always > > > and without further pre-req support (which I don't think is quite the > > > case, since we don't have persistent EFI vars, so can't set Boot### > > > persistently or via userspace) _something_ is likely needed to either > > > set those, or scan a configurable list of where, to find the EFI > > > payload. > > > > The efibootmgr will try to boot bootaa64.efi, bootarm.efi etc if > > Boot### variables are not found. > > To be clear, the current efibootmgr (or "bootefi bootmgr" command) > doesn't have this feature. Instead, distro_bootcmd mimics it in some way. > # I have an experimental patch to efibootmgr for the support, though. Ah thanks Akashi! I thought we had that already. In any case it makes much more sense adding that to efibootmgr, instead of inventing yet another way to do that, doesn't it? > > Nevertheless, > > > The Boot themselves are > > obviously configurable from U-Boot(at boot time). Since this method > > doesn't allow Linux to edit the boot options either,> > > Yeah. Please remember that, even on normal PCs, specifying an order of > boot devices (for "removable media" with the default path) is done > through UEFI UI. > > -Takahiro Akashi > > > is it something > > we need? Since distros usually name their
Re: Pull request: u-boot-sunxi/master for 2021.10 - 2nd part
在 2021-10-29星期五的 11:53 +0100，Andre Przywara写道：
> On Mon, 25 Oct 2021 14:29:10 -0400
> Tom Rini wrote:
>
> Hi Tom,
>
> > On Mon, Oct 25, 2021 at 03:06:58PM +0100, Andre Przywara wrote:
> >
> > > Hi Tom,
> > >
> > > please pull the second sunxi PR for the 2021.10 merge window.
> > > I decided to merge most of Samuel's rework and some smaller
> > > patches that
> > > pave the way for more DM transitions and for accommodating the
> > > RISC-V SoC
> > > in the future. Merging them now gives us the opportunity to get
> > > some wider
> > > testing, since those subtle changes tend to break things.
> > >
> > > Compile-tested for all 159 sunxi boards, boot-tested on Pine64-
> > > LTS
> > > and OrangePi Zero.
> > >
> > > Summary:
> > > - Add and enable watchdog driver
> > > - Prepare for SYSRESET driven AXP poweroff
> > > - Prepare for SoCs without MMC2
> > > - Some fixes for extending SPL (SPL-DM for RISC-V)
> > > - Some preparations for proper VBUS management
> > > - Fix secure monitor move
> > >
> > > Thanks,
> > > Andre
> > >
> > >
> > > The following changes since commit
> > > 355d1e24f6143c4839be3c015c191421c4e9449c:
> > >
> > > Merge
> > > https://source.denx.de/u-boot/custodians/u-boot-spi (2021-10-23
> > > 10:49:28 -0400)
> > >
> > > are available in the Git repository at:
> > >
> > >
> > > https://source.denx.de/u-boot/custodians/u-boot-sunxi.git master
> > >
> > > for you to fetch changes up to
> > > c846fe43f0561311eb7261b34023a04646cdbd0d:
> > >
> > > mmc: sunxi: conditionally include MMC2 initialization code
> > > (2021-10-25 14:54:57 +0100)
> > >
> >
> > So first, up, this is now applied to u-boot/master.
>
> Many thanks, and sorry for the late push!
>
> > Next, I dug out my original Kickstarted Pine A64 board (as it's the
> > only
> > sunxi platform I have), and I see it's detected with 1GB memory and
> > as
> > Pine64+ which seems wrong, with the pine64_plus_defconfig (which is
> > what
> > I thought handled all of the A64 platforms).
>
> For the naming: There are three SKUs for the original Pine A64 board:
> - Pine A64: 512 MB with 100Mbit Ethernet PHY, lacking display and
> camera
> connectors (rare, mostly to meet the original 15 USD price tag)
> - Pine A64+ 1GB: 1GB DRAM with 1Gbit Ethernet PHY, with all
> connectors
> - Pine A64+ 2GB: 2GB DRAM with 1Gbit Ethernet PHY, with all
> connectors
You can check whether your board is non-Plus or Plus 1G by the model of
the Ethernet PHY (non-Plus has RTL8201) or not soldered FPC connectors.
They do share a PCB design. Plus 2G is a dedicated PCB design as it
needs to use 4x 512MB DRAM chips.
>
> Also note that for those first boards from Pine64 the name of the
> company (Pine64) is sometimes uses for the boards as well ("Pine64
> board"), even though this should be "Pine A64 board from Pine64".
> That
> is somewhat reflected in the defconfig name. In hindsight the
> defconfig
> should have been named more "pine-a64_defconfig", but I guess this is
> too late now? I see a lot of inconsistencies in naming, especially
> regarding capitalisation and dashes vs. underscores, check
> configs/[bB]anana* for instance, but probably renaming causes more
> harm
> than good?
>
> So I guess you have the middle one (the most common among the first
> wave), so that all seems correct? We differentiate between the non-
> plus
> and plus version at runtime, by the amount of DRAM detected, so
> that's
> pretty reliable. The 1GB and 2GB are otherwise the same, so same DT.
> The actual non-plus versions are somewhat rare, I guess most people
> just added the 4(!) bucks to get more RAM and Gigabit Ethernet.
>
> > I've not booted this up in
> > forever, and Armbian (the first binary I grabbed) does this as well
> > with
> > v2020.10 (and I'm using the same TF-A rev of 87311b4) so maybe the
> > answer is I should just e-waste this board and pick up something
> > else?
>
> Not sure exactly why? Is there anything that's broken, apart from the
> presumed misnaming? I would be happy to hear about any issues you
> have,
> in my experience those "outsider" inputs are very useful (I am far
> too
> familiar with all those tiny quirks).
> When U-Boot starts, UEFI boot should work out of the box, just pop a
> generic arm64 Debian/SuSE/Fedora/Ubuntu EFI installer USB stick in,
> should work even with HDMI and USB keyboard.
>
> Cheers,
> Andre
[PATCH] board: ti: am335x: Choose CPSW or PRUSS configuration based on jumper setting
The am335x-ice-v2 board's Ethernet ports can be configured
in 'MII' or 'RMII' mode to be connected to 'PRUSS' or 'CPSW'
Ethernet subsystems.
This patch sets the environment variable 'ice_mii' to
'mii' or 'rmii' accordingly. Based on that we choose the
appropriate board devicetree i.e. 'am335x-ice-v2.dtb' or
'am335x-ice-v2-prueth.dtb'.
Since there are 2 Ethernet ports with 2 modes, there can be 4
configurations but for now we consider both ports in different modes
to be an invalid configuration and prevent boot in that case.
Signed-off-by: Roger Quadros
[Amjad: use overlay instead of using new am335x-ice-v2-prueth.dtb]
Signed-off-by: Amjad Ouled-Ameur
---
This depends on the currently in-review patch [0].
[0]: 20211022155526.54368-1-aouledam...@baylibre.com
board/ti/am335x/board.c | 17 +
include/configs/am335x_evm.h | 5 -
include/configs/ti_armv7_common.h | 1 +
3 files changed, 22 insertions(+), 1 deletion(-)
diff --git a/board/ti/am335x/board.c b/board/ti/am335x/board.c
index e8555de9c937..b50e7a0fa466 100644
--- a/board/ti/am335x/board.c
+++ b/board/ti/am335x/board.c
@@ -11,6 +11,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -691,6 +692,8 @@ done:
}
#endif
+static bool prueth_is_mii = true;
+
/*
* Basic board specific setup. Pinmux has been handled already.
*/
@@ -710,6 +713,8 @@ int board_init(void)
if (board_is_icev2()) {
int rv;
u32 reg;
+ bool eth0_is_mii = true;
+ bool eth1_is_mii = true;
REQUEST_AND_SET_GPIO(GPIO_PR1_MII_CTRL);
/* Make J19 status available on GPIO1_26 */
@@ -740,6 +745,7 @@ int board_init(void)
writel(reg, GPIO0_IRQSTATUS1); /* clear irq */
/* RMII mode */
printf("ETH0, CPSW\n");
+ eth0_is_mii = false;
} else {
/* MII mode */
printf("ETH0, PRU\n");
@@ -752,12 +758,21 @@ int board_init(void)
/* RMII mode */
printf("ETH1, CPSW\n");
gpio_set_value(GPIO_MUX_MII_CTRL, 1);
+ eth1_is_mii = false;
} else {
/* MII mode */
printf("ETH1, PRU\n");
cdce913_data.pdiv2 = 4; /* 25MHz PHY clk */
}
+ if (eth0_is_mii != eth1_is_mii) {
+ printf("Unsupported Ethernet port configuration\n");
+ printf("Both ports must be set as RMII or MII\n");
+ hang();
+ }
+
+ prueth_is_mii = eth0_is_mii;
+
/* disable rising edge IRQs */
reg = readl(GPIO0_RISINGDETECT) & ~BIT(11);
writel(reg, GPIO0_RISINGDETECT);
@@ -852,6 +867,8 @@ int board_late_init(void)
if (is_valid_ethaddr(mac_addr))
eth_env_set_enetaddr("eth1addr", mac_addr);
}
+
+ env_set("ice_mii", prueth_is_mii ? "mii" : "rmii");
#endif
if (!env_get("serial#")) {
diff --git a/include/configs/am335x_evm.h b/include/configs/am335x_evm.h
index 7fb1b3a3e3fa..0f340806efc9 100644
--- a/include/configs/am335x_evm.h
+++ b/include/configs/am335x_evm.h
@@ -143,7 +143,10 @@
"if test $board_name = A335X_SK; then " \
"setenv fdtfile am335x-evmsk.dtb; fi; " \
"if test $board_name = A335_ICE; then " \
- "setenv fdtfile am335x-icev2.dtb; fi; " \
+ "setenv fdtfile am335x-icev2.dtb; " \
+ "if test $ice_mii = mii; then " \
+ "setenv pxe_label_override Pruss; fi;" \
+ "fi; " \
"if test $fdtfile = undefined; then " \
"echo WARNING: Could not determine device tree to use;
fi; \0" \
"init_console=" \
diff --git a/include/configs/ti_armv7_common.h
b/include/configs/ti_armv7_common.h
index fa48cd2818ce..797e1211980d 100644
--- a/include/configs/ti_armv7_common.h
+++ b/include/configs/ti_armv7_common.h
@@ -37,6 +37,7 @@
"fdtaddr=0x8800\0" \
"dtboaddr=0x8900\0" \
"fdt_addr_r=0x8800\0" \
+ "fdtoverlay_addr_r=0x8900\0" \
"rdaddr=0x8808\0" \
"ramdisk_addr_r=0x8808\0" \
"scriptaddr=0x8000\0" \
--
2.25.1
Re: [PATCH v2 31/41] bootstd: Add an implementation of EFI boot
On Fri, Oct 29, 2021 at 04:42:45PM +0300, Ilias Apalodimas wrote: > Hi Tom, > > On Fri, 29 Oct 2021 at 15:39, Tom Rini wrote: > > > > On Fri, Oct 29, 2021 at 08:45:06AM +0300, Ilias Apalodimas wrote: > > > On Wed, Oct 27, 2021 at 12:34:40PM -0600, Simon Glass wrote: > > > > Hi Ilias, > > > > > > > > On Wed, 27 Oct 2021 at 08:48, Ilias Apalodimas > > > > wrote: > > > > > > > > > > Hi Simon, > > > > > > > > > > On Wed, Oct 27, 2021 at 08:09:04AM -0600, Simon Glass wrote: > > > > > > Hi Ilias, > > > > > > > > > > > > On Wed, 27 Oct 2021 at 02:36, Ilias Apalodimas > > > > > > wrote: > > > > > > > > > > > > > > Hi Simon, > > > > > > > > > > > > > > On Sun, 24 Oct 2021 at 02:27, Simon Glass > > > > > > > wrote: > > > > > > > > > > > > > > > > Add a bootmeth driver which handles EFI boot, using EFI_LOADER. > > > > > > > > > > > > > > > > In effect, this provides the same functionality as the > > > > > > > > 'bootefi' command > > > > > > > > and shares the same code. But the interface into it is via a > > > > > > > > bootmeth, > > > > > > > > so it does not require any special scripts, etc. > > > > > > > > > > > > > > > > For now this requires the 'bootefi' command be enabled. Future > > > > > > > > work may > > > > > > > > tidy this up so that it can be used without CONFIG_CMDLINE > > > > > > > > being enabled. > > > > > > > > > > > > > > I'll leave this up to Heinrich, but personally I wouldn't include > > > > > > > this > > > > > > > patch at all. EFI has it's bootmgr which can handle booting just > > > > > > > fine. > > > > > > > I don't see why we should duplicate the functionality. The new > > > > > > > boot > > > > > > > method can just have an entry called 'EFI' and then let the > > > > > > > existing > > > > > > > EFI code to decide. > > > > > > > > > > > > This is needed so that EFI boot is actually invoked. If bootmgr > > > > > > starts > > > > > > being used then it can still be invoked from standard boot. The > > > > > > point > > > > > > is that there is a standard way of booting that supports EFI and > > > > > > other > > > > > > things. > > > > > > > > > > This patch tries to reason about the default naming EFI imposes on > > > > > it's > > > > > boot files. distro_efi_read_bootflow() will try to find files > > > > > following the > > > > > EFI naming convention (e.g bootaarch64.efi, bootarm.efi etc). If > > > > > those are > > > > > found it will try to boot them right? That's not the right thing to > > > > > do though. > > > > > On the EFI spec these files are tried if no Boot variables are > > > > > found. > > > > > So we can get rid of this entirely, add a dummy entry on the > > > > > bootflow that > > > > > says 'boot the efi manager' (which is what the next patch does). > > > > > > > > > > The efibootmgr then will check Boot variables and if none are > > > > > found, > > > > > it's going to fallback into loading bootaarch64.efi, bootarm.efi etc > > > > > essentially offering identical functionality. > > > > > > > > Yes that's fine, and when EFI's boot manager is in use I have a driver > > > > for that too, as you can see in the other patch. We may need to adjust > > > > the order, by the sound of it, if it needs to run before EFI things. > > > > But that is easy enough. > > > > > > That's the point though. I don't want to have 2 different ways of > > > booting EFI > > > as I don't see any benefit. Do you? > > > > Unless we're saying that "bootefi bootmgr" is ready to be used always > > and without further pre-req support (which I don't think is quite the > > case, since we don't have persistent EFI vars, so can't set Boot### > > persistently or via userspace) _something_ is likely needed to either > > set those, or scan a configurable list of where, to find the EFI > > payload. > > The efibootmgr will try to boot bootaa64.efi, bootarm.efi etc if > Boot### variables are not found. To be clear, the current efibootmgr (or "bootefi bootmgr" command) doesn't have this feature. Instead, distro_bootcmd mimics it in some way. # I have an experimental patch to efibootmgr for the support, though. Nevertheless, > The Boot themselves are > obviously configurable from U-Boot(at boot time). Since this method > doesn't allow Linux to edit the boot options either,> Yeah. Please remember that, even on normal PCs, specifying an order of boot devices (for "removable media" with the default path) is done through UEFI UI. -Takahiro Akashi > is it something > we need? Since distros usually name their SHIM as bootaa64.efi, I am > afraid we are adding code that we will rarely (if at all) ever use. > > Regards > > > /Ilias > > > > -- > > Tom
Re: [PATCH] ARM: amlogic: add JetHub D1 eth mac generation with manufacturer OUI
Hi,
Ci fails with :
+board/amlogic/jethub-j100/jethub-j100.c: In function 'misc_init_r':
1516+board/amlogic/jethub-j100/jethub-j100.c:24:23: error: implicit declaration
of function 'crc32' [-Werror=implicit-function-declaration]
1517+ 24 | sid = crc32(0, (unsigned char *)serial,
SM_SERIAL_SIZE);
1518+ |
Can you send a fix I can squash on the commit ?
Neil
On 29/10/2021 14:21, Vyacheslav wrote:
> Thanks.
>
> 29.10.2021 15:08, Neil Armstrong пишет:
>> On 29/10/2021 09:08, Vyacheslav Bocharov wrote:
>>> JetHome has own MAC OUI. Add jethub-j100 board file. Update config.
>>>
>>> Signed-off-by: Vyacheslav Bocharov
>>> ---
>>> board/amlogic/jethub-j100/MAINTAINERS | 8 +
>>> board/amlogic/jethub-j100/Makefile | 6
>>> board/amlogic/jethub-j100/jethub-j100.c | 41 +
>>> board/amlogic/jethub-j80/MAINTAINERS | 3 +-
>>> configs/jethub_j100_defconfig | 1 +
>>> 5 files changed, 57 insertions(+), 2 deletions(-)
>>> create mode 100644 board/amlogic/jethub-j100/MAINTAINERS
>>> create mode 100644 board/amlogic/jethub-j100/Makefile
>>> create mode 100644 board/amlogic/jethub-j100/jethub-j100.c
>>>
>>> diff --git a/board/amlogic/jethub-j100/MAINTAINERS
>>> b/board/amlogic/jethub-j100/MAINTAINERS
>>> new file mode 100644
>>> index 00..43f6a5fc86
>>> --- /dev/null
>>> +++ b/board/amlogic/jethub-j100/MAINTAINERS
>>> @@ -0,0 +1,8 @@
>>> +JetHome JetHub
>>> +M: Vyacheslav Bocharov
>>> +S: Maintained
>>> +L: u-boot-amlo...@groups.io
>>> +F: board/amlogic/jethub-j100/
>>> +F: configs/jethub_j100_defconfig
>>> +F: doc/board/amlogic/jethub-j100.rst
>>> +F: include/configs/jethub.h
>>> diff --git a/board/amlogic/jethub-j100/Makefile
>>> b/board/amlogic/jethub-j100/Makefile
>>> new file mode 100644
>>> index 00..4d935af984
>>> --- /dev/null
>>> +++ b/board/amlogic/jethub-j100/Makefile
>>> @@ -0,0 +1,6 @@
>>> +# SPDX-License-Identifier: GPL-2.0+
>>> +#
>>> +# (C) Copyright 2021 Vyacheslav Bocharov
>>> +# Author: Vyacheslav Bocharov
>>> +
>>> +obj-y := jethub-j100.o
>>> diff --git a/board/amlogic/jethub-j100/jethub-j100.c
>>> b/board/amlogic/jethub-j100/jethub-j100.c
>>> new file mode 100644
>>> index 00..575bb31573
>>> --- /dev/null
>>> +++ b/board/amlogic/jethub-j100/jethub-j100.c
>>> @@ -0,0 +1,41 @@
>>> +// SPDX-License-Identifier: GPL-2.0+
>>> +/*
>>> + * Copyright (C) 2021 Vyacheslav Bocharov
>>> + * Author: Vyacheslav Bocharov
>>> + */
>>> +
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +
>>> +int misc_init_r(void)
>>> +{
>>> + u8 mac_addr[ARP_HLEN];
>>> + char serial[SM_SERIAL_SIZE];
>>> + u32 sid;
>>> +
>>> + if (!meson_sm_get_serial(serial, SM_SERIAL_SIZE)) {
>>> + sid = crc32(0, (unsigned char *)serial, SM_SERIAL_SIZE);
>>> + /* Ensure the NIC specific bytes of the mac are not all 0 */
>>> + if ((sid & 0x) == 0)
>>> + sid |= 0x80;
>>> +
>>> + /* OUI registered MAC address */
>>> + mac_addr[0] = 0x10;
>>> + mac_addr[1] = 0x27;
>>> + mac_addr[2] = 0xBE;
>>> + mac_addr[3] = (sid >> 16) & 0xff;
>>> + mac_addr[4] = (sid >> 8) & 0xff;
>>> + mac_addr[5] = (sid >> 0) & 0xff;
>>> +
>>> + eth_env_set_enetaddr("ethaddr", mac_addr);
>>> + }
>>> +
>>> + return 0;
>>> +}
>>> diff --git a/board/amlogic/jethub-j80/MAINTAINERS
>>> b/board/amlogic/jethub-j80/MAINTAINERS
>>> index 459e9f89da..a899153117 100644
>>> --- a/board/amlogic/jethub-j80/MAINTAINERS
>>> +++ b/board/amlogic/jethub-j80/MAINTAINERS
>>> @@ -4,6 +4,5 @@ S: Maintained
>>> L: u-boot-amlo...@groups.io
>>> F: board/amlogic/jethub-j80/
>>> F: configs/jethub_j80_defconfig
>>> -F: configs/jethub_j100_defconfig
>>> F: doc/board/amlogic/jethub-j80.rst
>>> -F: doc/board/amlogic/jethub-j100.rst
>>> +F: include/configs/jethub.h
>>> diff --git a/configs/jethub_j100_defconfig b/configs/jethub_j100_defconfig
>>> index 290ce4db85..ad026a89e0 100644
>>> --- a/configs/jethub_j100_defconfig
>>> +++ b/configs/jethub_j100_defconfig
>>> @@ -1,4 +1,5 @@
>>> CONFIG_ARM=y
>>> +CONFIG_SYS_BOARD="jethub-j100"
>>> CONFIG_SYS_CONFIG_NAME="jethub"
>>> CONFIG_ARCH_MESON=y
>>> CONFIG_SYS_TEXT_BASE=0x0100
>>>
>>
>> Applied to u-boot-amlogic
>>
>> I will probably send it next week along `add sm efuse write support and cmd
>> for read/write efuse`
>>
>> Thanks,
>> Neil
Re: [PATCH v2 31/41] bootstd: Add an implementation of EFI boot
Hi Tom, On Fri, 29 Oct 2021 at 15:39, Tom Rini wrote: > > On Fri, Oct 29, 2021 at 08:45:06AM +0300, Ilias Apalodimas wrote: > > On Wed, Oct 27, 2021 at 12:34:40PM -0600, Simon Glass wrote: > > > Hi Ilias, > > > > > > On Wed, 27 Oct 2021 at 08:48, Ilias Apalodimas > > > wrote: > > > > > > > > Hi Simon, > > > > > > > > On Wed, Oct 27, 2021 at 08:09:04AM -0600, Simon Glass wrote: > > > > > Hi Ilias, > > > > > > > > > > On Wed, 27 Oct 2021 at 02:36, Ilias Apalodimas > > > > > wrote: > > > > > > > > > > > > Hi Simon, > > > > > > > > > > > > On Sun, 24 Oct 2021 at 02:27, Simon Glass wrote: > > > > > > > > > > > > > > Add a bootmeth driver which handles EFI boot, using EFI_LOADER. > > > > > > > > > > > > > > In effect, this provides the same functionality as the 'bootefi' > > > > > > > command > > > > > > > and shares the same code. But the interface into it is via a > > > > > > > bootmeth, > > > > > > > so it does not require any special scripts, etc. > > > > > > > > > > > > > > For now this requires the 'bootefi' command be enabled. Future > > > > > > > work may > > > > > > > tidy this up so that it can be used without CONFIG_CMDLINE being > > > > > > > enabled. > > > > > > > > > > > > I'll leave this up to Heinrich, but personally I wouldn't include > > > > > > this > > > > > > patch at all. EFI has it's bootmgr which can handle booting just > > > > > > fine. > > > > > > I don't see why we should duplicate the functionality. The new boot > > > > > > method can just have an entry called 'EFI' and then let the existing > > > > > > EFI code to decide. > > > > > > > > > > This is needed so that EFI boot is actually invoked. If bootmgr starts > > > > > being used then it can still be invoked from standard boot. The point > > > > > is that there is a standard way of booting that supports EFI and other > > > > > things. > > > > > > > > This patch tries to reason about the default naming EFI imposes on it's > > > > boot files. distro_efi_read_bootflow() will try to find files following > > > > the > > > > EFI naming convention (e.g bootaarch64.efi, bootarm.efi etc). If those > > > > are > > > > found it will try to boot them right? That's not the right thing to do > > > > though. > > > > On the EFI spec these files are tried if no Boot variables are > > > > found. > > > > So we can get rid of this entirely, add a dummy entry on the bootflow > > > > that > > > > says 'boot the efi manager' (which is what the next patch does). > > > > > > > > The efibootmgr then will check Boot variables and if none are found, > > > > it's going to fallback into loading bootaarch64.efi, bootarm.efi etc > > > > essentially offering identical functionality. > > > > > > Yes that's fine, and when EFI's boot manager is in use I have a driver > > > for that too, as you can see in the other patch. We may need to adjust > > > the order, by the sound of it, if it needs to run before EFI things. > > > But that is easy enough. > > > > That's the point though. I don't want to have 2 different ways of booting > > EFI > > as I don't see any benefit. Do you? > > Unless we're saying that "bootefi bootmgr" is ready to be used always > and without further pre-req support (which I don't think is quite the > case, since we don't have persistent EFI vars, so can't set Boot### > persistently or via userspace) _something_ is likely needed to either > set those, or scan a configurable list of where, to find the EFI > payload. The efibootmgr will try to boot bootaa64.efi, bootarm.efi etc if Boot### variables are not found. The Boot themselves are obviously configurable from U-Boot(at boot time). Since this method doesn't allow Linux to edit the boot options either, is it something we need? Since distros usually name their SHIM as bootaa64.efi, I am afraid we are adding code that we will rarely (if at all) ever use. Regards /Ilias > > -- > Tom
Re: [PATCH v2 31/41] bootstd: Add an implementation of EFI boot
On Fri, Oct 29, 2021 at 08:45:06AM +0300, Ilias Apalodimas wrote: > On Wed, Oct 27, 2021 at 12:34:40PM -0600, Simon Glass wrote: > > Hi Ilias, > > > > On Wed, 27 Oct 2021 at 08:48, Ilias Apalodimas > > wrote: > > > > > > Hi Simon, > > > > > > On Wed, Oct 27, 2021 at 08:09:04AM -0600, Simon Glass wrote: > > > > Hi Ilias, > > > > > > > > On Wed, 27 Oct 2021 at 02:36, Ilias Apalodimas > > > > wrote: > > > > > > > > > > Hi Simon, > > > > > > > > > > On Sun, 24 Oct 2021 at 02:27, Simon Glass wrote: > > > > > > > > > > > > Add a bootmeth driver which handles EFI boot, using EFI_LOADER. > > > > > > > > > > > > In effect, this provides the same functionality as the 'bootefi' > > > > > > command > > > > > > and shares the same code. But the interface into it is via a > > > > > > bootmeth, > > > > > > so it does not require any special scripts, etc. > > > > > > > > > > > > For now this requires the 'bootefi' command be enabled. Future work > > > > > > may > > > > > > tidy this up so that it can be used without CONFIG_CMDLINE being > > > > > > enabled. > > > > > > > > > > I'll leave this up to Heinrich, but personally I wouldn't include this > > > > > patch at all. EFI has it's bootmgr which can handle booting just fine. > > > > > I don't see why we should duplicate the functionality. The new boot > > > > > method can just have an entry called 'EFI' and then let the existing > > > > > EFI code to decide. > > > > > > > > This is needed so that EFI boot is actually invoked. If bootmgr starts > > > > being used then it can still be invoked from standard boot. The point > > > > is that there is a standard way of booting that supports EFI and other > > > > things. > > > > > > This patch tries to reason about the default naming EFI imposes on it's > > > boot files. distro_efi_read_bootflow() will try to find files following > > > the > > > EFI naming convention (e.g bootaarch64.efi, bootarm.efi etc). If those > > > are > > > found it will try to boot them right? That's not the right thing to do > > > though. > > > On the EFI spec these files are tried if no Boot variables are found. > > > So we can get rid of this entirely, add a dummy entry on the bootflow > > > that > > > says 'boot the efi manager' (which is what the next patch does). > > > > > > The efibootmgr then will check Boot variables and if none are found, > > > it's going to fallback into loading bootaarch64.efi, bootarm.efi etc > > > essentially offering identical functionality. > > > > Yes that's fine, and when EFI's boot manager is in use I have a driver > > for that too, as you can see in the other patch. We may need to adjust > > the order, by the sound of it, if it needs to run before EFI things. > > But that is easy enough. > > That's the point though. I don't want to have 2 different ways of booting EFI > as I don't see any benefit. Do you? Unless we're saying that "bootefi bootmgr" is ready to be used always and without further pre-req support (which I don't think is quite the case, since we don't have persistent EFI vars, so can't set Boot### persistently or via userspace) _something_ is likely needed to either set those, or scan a configurable list of where, to find the EFI payload. -- Tom signature.asc Description: PGP signature
Re: [PATCH] ARM: amlogic: add JetHub D1 eth mac generation with manufacturer OUI
Thanks.
29.10.2021 15:08, Neil Armstrong пишет:
On 29/10/2021 09:08, Vyacheslav Bocharov wrote:
JetHome has own MAC OUI. Add jethub-j100 board file. Update config.
Signed-off-by: Vyacheslav Bocharov
---
board/amlogic/jethub-j100/MAINTAINERS | 8 +
board/amlogic/jethub-j100/Makefile | 6
board/amlogic/jethub-j100/jethub-j100.c | 41 +
board/amlogic/jethub-j80/MAINTAINERS| 3 +-
configs/jethub_j100_defconfig | 1 +
5 files changed, 57 insertions(+), 2 deletions(-)
create mode 100644 board/amlogic/jethub-j100/MAINTAINERS
create mode 100644 board/amlogic/jethub-j100/Makefile
create mode 100644 board/amlogic/jethub-j100/jethub-j100.c
diff --git a/board/amlogic/jethub-j100/MAINTAINERS
b/board/amlogic/jethub-j100/MAINTAINERS
new file mode 100644
index 00..43f6a5fc86
--- /dev/null
+++ b/board/amlogic/jethub-j100/MAINTAINERS
@@ -0,0 +1,8 @@
+JetHome JetHub
+M: Vyacheslav Bocharov
+S: Maintained
+L: u-boot-amlo...@groups.io
+F: board/amlogic/jethub-j100/
+F: configs/jethub_j100_defconfig
+F: doc/board/amlogic/jethub-j100.rst
+F: include/configs/jethub.h
diff --git a/board/amlogic/jethub-j100/Makefile
b/board/amlogic/jethub-j100/Makefile
new file mode 100644
index 00..4d935af984
--- /dev/null
+++ b/board/amlogic/jethub-j100/Makefile
@@ -0,0 +1,6 @@
+# SPDX-License-Identifier: GPL-2.0+
+#
+# (C) Copyright 2021 Vyacheslav Bocharov
+# Author: Vyacheslav Bocharov
+
+obj-y := jethub-j100.o
diff --git a/board/amlogic/jethub-j100/jethub-j100.c
b/board/amlogic/jethub-j100/jethub-j100.c
new file mode 100644
index 00..575bb31573
--- /dev/null
+++ b/board/amlogic/jethub-j100/jethub-j100.c
@@ -0,0 +1,41 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2021 Vyacheslav Bocharov
+ * Author: Vyacheslav Bocharov
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+int misc_init_r(void)
+{
+ u8 mac_addr[ARP_HLEN];
+ char serial[SM_SERIAL_SIZE];
+ u32 sid;
+
+ if (!meson_sm_get_serial(serial, SM_SERIAL_SIZE)) {
+ sid = crc32(0, (unsigned char *)serial, SM_SERIAL_SIZE);
+ /* Ensure the NIC specific bytes of the mac are not all 0 */
+ if ((sid & 0x) == 0)
+ sid |= 0x80;
+
+ /* OUI registered MAC address */
+ mac_addr[0] = 0x10;
+ mac_addr[1] = 0x27;
+ mac_addr[2] = 0xBE;
+ mac_addr[3] = (sid >> 16) & 0xff;
+ mac_addr[4] = (sid >> 8) & 0xff;
+ mac_addr[5] = (sid >> 0) & 0xff;
+
+ eth_env_set_enetaddr("ethaddr", mac_addr);
+ }
+
+ return 0;
+}
diff --git a/board/amlogic/jethub-j80/MAINTAINERS
b/board/amlogic/jethub-j80/MAINTAINERS
index 459e9f89da..a899153117 100644
--- a/board/amlogic/jethub-j80/MAINTAINERS
+++ b/board/amlogic/jethub-j80/MAINTAINERS
@@ -4,6 +4,5 @@ S: Maintained
L:u-boot-amlo...@groups.io
F:board/amlogic/jethub-j80/
F:configs/jethub_j80_defconfig
-F: configs/jethub_j100_defconfig
F:doc/board/amlogic/jethub-j80.rst
-F: doc/board/amlogic/jethub-j100.rst
+F: include/configs/jethub.h
diff --git a/configs/jethub_j100_defconfig b/configs/jethub_j100_defconfig
index 290ce4db85..ad026a89e0 100644
--- a/configs/jethub_j100_defconfig
+++ b/configs/jethub_j100_defconfig
@@ -1,4 +1,5 @@
CONFIG_ARM=y
+CONFIG_SYS_BOARD="jethub-j100"
CONFIG_SYS_CONFIG_NAME="jethub"
CONFIG_ARCH_MESON=y
CONFIG_SYS_TEXT_BASE=0x0100
Applied to u-boot-amlogic
I will probably send it next week along `add sm efuse write support and cmd for
read/write efuse`
Thanks,
Neil
[PATCH] arm: mvebu: Fix booting from SATA
Use proper SATA macro for boot_device switch in spl_boot_device() function.
Signed-off-by: Pali Rohár
Fixes: 2226ca173486 ("arm: mvebu: Load U-Boot proper binary in SPL code based
on kwbimage header")
---
arch/arm/mach-mvebu/spl.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-mvebu/spl.c b/arch/arm/mach-mvebu/spl.c
index cad3f0a48893..73c4b9af3e6d 100644
--- a/arch/arm/mach-mvebu/spl.c
+++ b/arch/arm/mach-mvebu/spl.c
@@ -199,8 +199,8 @@ u32 spl_boot_device(void)
return BOOT_DEVICE_MMC1;
#endif
#ifdef CONFIG_SPL_SATA
- case BOOT_FROM_SATA:
- return BOOT_FROM_SATA;
+ case BOOT_DEVICE_SATA:
+ return BOOT_DEVICE_SATA;
#endif
#ifdef CONFIG_SPL_SPI_FLASH_SUPPORT
case BOOT_DEVICE_SPI:
--
2.20.1
Re: [PATCH] ARM: amlogic: add JetHub D1 eth mac generation with manufacturer OUI
On 29/10/2021 09:08, Vyacheslav Bocharov wrote:
> JetHome has own MAC OUI. Add jethub-j100 board file. Update config.
>
> Signed-off-by: Vyacheslav Bocharov
> ---
> board/amlogic/jethub-j100/MAINTAINERS | 8 +
> board/amlogic/jethub-j100/Makefile | 6
> board/amlogic/jethub-j100/jethub-j100.c | 41 +
> board/amlogic/jethub-j80/MAINTAINERS| 3 +-
> configs/jethub_j100_defconfig | 1 +
> 5 files changed, 57 insertions(+), 2 deletions(-)
> create mode 100644 board/amlogic/jethub-j100/MAINTAINERS
> create mode 100644 board/amlogic/jethub-j100/Makefile
> create mode 100644 board/amlogic/jethub-j100/jethub-j100.c
>
> diff --git a/board/amlogic/jethub-j100/MAINTAINERS
> b/board/amlogic/jethub-j100/MAINTAINERS
> new file mode 100644
> index 00..43f6a5fc86
> --- /dev/null
> +++ b/board/amlogic/jethub-j100/MAINTAINERS
> @@ -0,0 +1,8 @@
> +JetHome JetHub
> +M: Vyacheslav Bocharov
> +S: Maintained
> +L: u-boot-amlo...@groups.io
> +F: board/amlogic/jethub-j100/
> +F: configs/jethub_j100_defconfig
> +F: doc/board/amlogic/jethub-j100.rst
> +F: include/configs/jethub.h
> diff --git a/board/amlogic/jethub-j100/Makefile
> b/board/amlogic/jethub-j100/Makefile
> new file mode 100644
> index 00..4d935af984
> --- /dev/null
> +++ b/board/amlogic/jethub-j100/Makefile
> @@ -0,0 +1,6 @@
> +# SPDX-License-Identifier: GPL-2.0+
> +#
> +# (C) Copyright 2021 Vyacheslav Bocharov
> +# Author: Vyacheslav Bocharov
> +
> +obj-y:= jethub-j100.o
> diff --git a/board/amlogic/jethub-j100/jethub-j100.c
> b/board/amlogic/jethub-j100/jethub-j100.c
> new file mode 100644
> index 00..575bb31573
> --- /dev/null
> +++ b/board/amlogic/jethub-j100/jethub-j100.c
> @@ -0,0 +1,41 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright (C) 2021 Vyacheslav Bocharov
> + * Author: Vyacheslav Bocharov
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +int misc_init_r(void)
> +{
> + u8 mac_addr[ARP_HLEN];
> + char serial[SM_SERIAL_SIZE];
> + u32 sid;
> +
> + if (!meson_sm_get_serial(serial, SM_SERIAL_SIZE)) {
> + sid = crc32(0, (unsigned char *)serial, SM_SERIAL_SIZE);
> + /* Ensure the NIC specific bytes of the mac are not all 0 */
> + if ((sid & 0x) == 0)
> + sid |= 0x80;
> +
> + /* OUI registered MAC address */
> + mac_addr[0] = 0x10;
> + mac_addr[1] = 0x27;
> + mac_addr[2] = 0xBE;
> + mac_addr[3] = (sid >> 16) & 0xff;
> + mac_addr[4] = (sid >> 8) & 0xff;
> + mac_addr[5] = (sid >> 0) & 0xff;
> +
> + eth_env_set_enetaddr("ethaddr", mac_addr);
> + }
> +
> + return 0;
> +}
> diff --git a/board/amlogic/jethub-j80/MAINTAINERS
> b/board/amlogic/jethub-j80/MAINTAINERS
> index 459e9f89da..a899153117 100644
> --- a/board/amlogic/jethub-j80/MAINTAINERS
> +++ b/board/amlogic/jethub-j80/MAINTAINERS
> @@ -4,6 +4,5 @@ S:Maintained
> L: u-boot-amlo...@groups.io
> F: board/amlogic/jethub-j80/
> F: configs/jethub_j80_defconfig
> -F: configs/jethub_j100_defconfig
> F: doc/board/amlogic/jethub-j80.rst
> -F: doc/board/amlogic/jethub-j100.rst
> +F: include/configs/jethub.h
> diff --git a/configs/jethub_j100_defconfig b/configs/jethub_j100_defconfig
> index 290ce4db85..ad026a89e0 100644
> --- a/configs/jethub_j100_defconfig
> +++ b/configs/jethub_j100_defconfig
> @@ -1,4 +1,5 @@
> CONFIG_ARM=y
> +CONFIG_SYS_BOARD="jethub-j100"
> CONFIG_SYS_CONFIG_NAME="jethub"
> CONFIG_ARCH_MESON=y
> CONFIG_SYS_TEXT_BASE=0x0100
>
Applied to u-boot-amlogic
I will probably send it next week along `add sm efuse write support and cmd for
read/write efuse`
Thanks,
Neil
Re: [PATCH 2/2] Revert "arch: arm: use dt and UCLASS_SYSCON to get gic lpi details"
Michael,
On Fri, 29 Oct 2021 12:49:21 +0100,
Michael Walle wrote:
>
> Hi,
>
> thanks for the review, as Tom already mentioned this is just
> a revert. I'm still unsure wether I should care or not. Actually,
> NXP or Broadcom should. OTOH it would be nice if the kontron_sl28
> can do kexec also with booti (and not just bootefi). Anyway, I
> still have some remarks.
>
> Am 2021-10-28 23:09, schrieb Marc Zyngier:
> > On Wed, 27 Oct 2021 17:54:54 +0100,
> > Michael Walle wrote:
> >>
> >> Stop using the device tree as a source for ad-hoc information.
> >>
> >> This reverts commit 2ae7adc659f7fca9ea65df4318e5bca2b8274310.
> >>
> >> Signed-off-by: Michael Walle
> >> ---
>
> >> int ls_gic_rd_tables_init(void *blob)
> >> {
> >> + u64 gic_lpi_base;
> >>int ret;
> >>
> >> - ret = gic_lpi_tables_init();
> >> + gic_lpi_base = ALIGN(gd->arch.resv_ram - GIC_LPI_SIZE, SZ_64K);
> >> + ret = fdt_add_resv_mem_gic_rd_tables(blob, gic_lpi_base,
> >> GIC_LPI_SIZE);
> >> + if (ret)
> >> + return ret;
> >> +
> >> + ret = gic_lpi_tables_init(gic_lpi_base, cpu_numcores());
> >
> > This really should fetch the number of CPUs from the DT rather then
> > some SoC specific black magic...
>
> Remember that this is the bootloader. There might be a chicken egg
> problem. I guess, usually the bootloader will fixup the number of cores
> in the DT. Therefore, if we rely on the DT here, it has to be fixed up
> before this code is run.
I appreciate that. However...
>
> Conceptually, I'm unsure if this should actually be a driver
> (UCLASS_IRQ). It's just setting up the interrupt controller, it doesn't
> provide any ops. So it might well be called from somewhere else instead
> of binding as a driver to the gic.
>
> If it will be a driver, then the call to gic_lpi_tables_init() should
> go away. Instead the driver should just set the tables up.
>
> If its not a driver, then gic_lpi_tables_init() (maybe renamed to
> gic_v3_lpi_tables_init()) should work without anything else and
> it should scan the device tree for the compatible node and fetch
> all needed information to set up the tables.
Exactly. This thing doesn't provide *any* service to u-boot itself. It
just grabs some memory, point a couple of registers at it, and flip a
bit. There is no actual ITS driver, so nothing makes use of it.
So this can be run as late as you want, long after you have worked out
how many CPUs you really have. Which means this can be done in a
SoC-agnostic way.
> In any case, all this code should be guarded by a Kconfig option which
> clearly states *why* this is needed.
Even more: if it is selected, it should be possible to disable this at
runtime (environment variable?) and leave the OS in charge of it. This
really should an opt-in, instead of being forced on the users.
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
Re: [PATCH 0/2] arch: arm: gic-v3-its: stop abusing the device tree
Am 2021-10-29 00:36, schrieb Simon Glass: On Wed, 27 Oct 2021 at 10:55, Michael Walle wrote: Please stop throwing every ad-hoc information in the device tree. Use the official bindings (or maybe some bindings which will get approved soon). Can I suggest that your commit subject be a little more specific? Sure. Actually, it should have be a bit provocant; and the cover letter subject doesn't really matter, does it? Perhaps 'Drop use of unwanted binding' ? It seems quite vague to me, like 'Fix a horrible bug' or 'Sort out all the problems' :-) -michael
Re: [PATCH 2/2] Revert "arch: arm: use dt and UCLASS_SYSCON to get gic lpi details"
Hi,
thanks for the review, as Tom already mentioned this is just
a revert. I'm still unsure wether I should care or not. Actually,
NXP or Broadcom should. OTOH it would be nice if the kontron_sl28
can do kexec also with booti (and not just bootefi). Anyway, I
still have some remarks.
Am 2021-10-28 23:09, schrieb Marc Zyngier:
On Wed, 27 Oct 2021 17:54:54 +0100,
Michael Walle wrote:
Stop using the device tree as a source for ad-hoc information.
This reverts commit 2ae7adc659f7fca9ea65df4318e5bca2b8274310.
Signed-off-by: Michael Walle
---
int ls_gic_rd_tables_init(void *blob)
{
+ u64 gic_lpi_base;
int ret;
- ret = gic_lpi_tables_init();
+ gic_lpi_base = ALIGN(gd->arch.resv_ram - GIC_LPI_SIZE, SZ_64K);
+ ret = fdt_add_resv_mem_gic_rd_tables(blob, gic_lpi_base,
GIC_LPI_SIZE);
+ if (ret)
+ return ret;
+
+ ret = gic_lpi_tables_init(gic_lpi_base, cpu_numcores());
This really should fetch the number of CPUs from the DT rather then
some SoC specific black magic...
Remember that this is the bootloader. There might be a chicken egg
problem. I guess, usually the bootloader will fixup the number of cores
in the DT. Therefore, if we rely on the DT here, it has to be fixed up
before this code is run.
Conceptually, I'm unsure if this should actually be a driver
(UCLASS_IRQ). It's just setting up the interrupt controller, it doesn't
provide any ops. So it might well be called from somewhere else instead
of binding as a driver to the gic.
If it will be a driver, then the call to gic_lpi_tables_init() should
go away. Instead the driver should just set the tables up.
If its not a driver, then gic_lpi_tables_init() (maybe renamed to
gic_v3_lpi_tables_init()) should work without anything else and
it should scan the device tree for the compatible node and fetch
all needed information to set up the tables.
In any case, all this code should be guarded by a Kconfig option which
clearly states *why* this is needed.
Thoughts?
--
-michael
[PATCH] net: gem: Reduce timeout of mdio phy idle status check
From: Ashok Reddy Soma Timeout for checking mdio phy idle status is 20seconds. In case of errors this timeout will be too much. Reduce it to 100ms. Signed-off-by: Ashok Reddy Soma Signed-off-by: Michal Simek --- drivers/net/zynq_gem.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/net/zynq_gem.c b/drivers/net/zynq_gem.c index c309c3c95499..033021f1cbfc 100644 --- a/drivers/net/zynq_gem.c +++ b/drivers/net/zynq_gem.c @@ -110,6 +110,8 @@ #define ZYNQ_GEM_DCFG_DBG6_DMA_64B BIT(23) +#define MDIO_IDLE_TIMEOUT_MS 100 + /* Use MII register 1 (MII status register) to detect PHY */ #define PHY_DETECT_REG 1 @@ -225,7 +227,7 @@ static int phy_setup_op(struct zynq_gem_priv *priv, u32 phy_addr, u32 regnum, int err; err = wait_for_bit_le32(>nwsr, ZYNQ_GEM_NWSR_MDIOIDLE_MASK, - true, 2, false); + true, MDIO_IDLE_TIMEOUT_MS, false); if (err) return err; @@ -238,7 +240,7 @@ static int phy_setup_op(struct zynq_gem_priv *priv, u32 phy_addr, u32 regnum, writel(mgtcr, >phymntnc); err = wait_for_bit_le32(>nwsr, ZYNQ_GEM_NWSR_MDIOIDLE_MASK, - true, 2, false); + true, MDIO_IDLE_TIMEOUT_MS, false); if (err) return err; -- 2.33.1
[PATCH] net: uclass: Save ethernet MAC address when generated
When MAC address is randomly generated it should be also saved to
variables. This step is there when MAC address is passed via pdata but not
when it is randomly generated.
Signed-off-by: Michal Simek
---
net/eth-uclass.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/net/eth-uclass.c b/net/eth-uclass.c
index 0da0e85be031..58c308f33276 100644
--- a/net/eth-uclass.c
+++ b/net/eth-uclass.c
@@ -583,6 +583,8 @@ static int eth_post_probe(struct udevice *dev)
net_random_ethaddr(pdata->enetaddr);
printf("\nWarning: %s (eth%d) using random MAC address - %pM\n",
dev->name, dev_seq(dev), pdata->enetaddr);
+ eth_env_set_enetaddr_by_index("eth", dev_seq(dev),
+ pdata->enetaddr);
#else
printf("\nError: %s address not set.\n",
dev->name);
--
2.33.1
[PATCH 2/2] clk: zynqmp: Fix gem tx/rx/ref clock handling
gemX_ref clock IDs starts at number 104. Till now it was at gemX_tx
location which wasn't correct.
Signed-off-by: Michal Simek
---
drivers/clk/clk_zynqmp.c | 23 ++-
1 file changed, 18 insertions(+), 5 deletions(-)
diff --git a/drivers/clk/clk_zynqmp.c b/drivers/clk/clk_zynqmp.c
index ca36df664069..9038fb8befd9 100644
--- a/drivers/clk/clk_zynqmp.c
+++ b/drivers/clk/clk_zynqmp.c
@@ -130,8 +130,8 @@ enum zynqmp_clk {
csu_spb, csu_pll, pcap,
iou_switch,
gem_tsu_ref, gem_tsu,
- gem0_ref, gem1_ref, gem2_ref, gem3_ref,
gem0_tx, gem1_tx, gem2_tx, gem3_tx,
+ gem0_rx, gem1_rx, gem2_rx, gem3_rx,
qspi_ref,
sdio0_ref, sdio1_ref,
uart0_ref, uart1_ref,
@@ -144,6 +144,8 @@ enum zynqmp_clk {
ams_ref,
pl0, pl1, pl2, pl3,
wdt,
+ gem0_ref = 104,
+ gem1_ref, gem2_ref, gem3_ref,
clk_max,
};
@@ -161,14 +163,18 @@ static const char * const clk_names[clk_max] = {
"usb1_bus_ref", "usb3_dual_ref", "usb0",
"usb1", "cpu_r5", "cpu_r5_core", "csu_spb",
"csu_pll", "pcap", "iou_switch", "gem_tsu_ref",
- "gem_tsu", "gem0_ref", "gem1_ref", "gem2_ref",
- "gem3_ref", "gem0_tx", "gem1_tx", "gem2_tx",
- "gem3_tx", "qspi_ref", "sdio0_ref", "sdio1_ref",
+ "gem_tsu", "gem0_tx", "gem1_tx", "gem2_tx",
+ "gem3_tx", "gem0_rx", "gem1_rx", "gem2_rx",
+ "gem3_rx", "qspi_ref", "sdio0_ref", "sdio1_ref",
"uart0_ref", "uart1_ref", "spi0_ref",
"spi1_ref", "nand_ref", "i2c0_ref", "i2c1_ref",
"can0_ref", "can1_ref", "can0", "can1",
"dll_ref", "adma_ref", "timestamp_ref",
- "ams_ref", "pl0", "pl1", "pl2", "pl3", "wdt"
+ "ams_ref", "pl0", "pl1", "pl2", "pl3", "wdt",
+ NULL, NULL, NULL, NULL,
+ NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL,
+ NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL,
+ NULL, NULL, NULL, NULL, "gem0_ref", "gem1_ref", "gem2_ref", "gem3_ref",
};
static const u32 pll_src[][4] = {
@@ -258,12 +264,16 @@ static u32 zynqmp_clk_get_register(enum zynqmp_clk id)
return CRL_APB_USB3_DUAL_REF_CTRL;
case gem_tsu_ref:
return CRL_APB_GEM_TSU_REF_CTRL;
+ case gem0_tx:
case gem0_ref:
return CRL_APB_GEM0_REF_CTRL;
+ case gem1_tx:
case gem1_ref:
return CRL_APB_GEM1_REF_CTRL;
+ case gem2_tx:
case gem2_ref:
return CRL_APB_GEM2_REF_CTRL;
+ case gem3_tx:
case gem3_ref:
return CRL_APB_GEM3_REF_CTRL;
case usb0_bus_ref:
@@ -665,6 +675,7 @@ static ulong zynqmp_clk_get_rate(struct clk *clk)
case gem_tsu_ref:
case pl0 ... pl3:
case gem0_ref ... gem3_ref:
+ case gem0_tx ... gem3_tx:
case qspi_ref ... can1_ref:
case usb0_bus_ref ... usb3_dual_ref:
two_divs = true;
@@ -698,6 +709,7 @@ static ulong zynqmp_clk_set_rate(struct clk *clk, ulong
rate)
switch (id) {
case gem0_ref ... gem3_ref:
+ case gem0_tx ... gem3_tx:
case qspi_ref ... can1_ref:
case usb0_bus_ref ... usb3_dual_ref:
return zynqmp_clk_set_peripheral_rate(priv, id,
@@ -809,6 +821,7 @@ static int zynqmp_clk_enable(struct clk *clk)
clkact_shift = 25;
mask = 0x1;
break;
+ case gem0_tx ... gem3_tx:
case gem0_ref ... gem3_ref:
clkact_shift = 25;
mask = 0x3;
--
2.33.1
[PATCH 1/2] clk: zynqmp: Add support for setting up clock for USB
USB range is not enabled but for setting up frequency it is needed.
Signed-off-by: Michal Simek
---
drivers/clk/clk_zynqmp.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/clk/clk_zynqmp.c b/drivers/clk/clk_zynqmp.c
index 52fecec7a7a9..ca36df664069 100644
--- a/drivers/clk/clk_zynqmp.c
+++ b/drivers/clk/clk_zynqmp.c
@@ -699,6 +699,7 @@ static ulong zynqmp_clk_set_rate(struct clk *clk, ulong
rate)
switch (id) {
case gem0_ref ... gem3_ref:
case qspi_ref ... can1_ref:
+ case usb0_bus_ref ... usb3_dual_ref:
return zynqmp_clk_set_peripheral_rate(priv, id,
rate, two_divs);
default:
--
2.33.1
[PATCH] zynqmp: gpio: Add support for zynqmp gpio modepin driver
From: T Karthik Reddy
ZynqMP modepin driver has capability to get/set/check status of modepin
gpios. These modepins are accessed using xilinx firmware. In modepin
register, [3:0] bits set direction, [7:4] bits read IO, [11:8] bits
set/clear IO.
Signed-off-by: T Karthik Reddy
Signed-off-by: Michal Simek
---
MAINTAINERS| 1 +
arch/arm/Kconfig | 1 +
drivers/gpio/Kconfig | 9 ++
drivers/gpio/Makefile | 1 +
drivers/gpio/zynqmp_gpio_modepin.c | 153 +
5 files changed, 165 insertions(+)
create mode 100644 drivers/gpio/zynqmp_gpio_modepin.c
diff --git a/MAINTAINERS b/MAINTAINERS
index 36f076b377f3..d945c23e28ac 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -591,6 +591,7 @@ F: drivers/clk/clk_zynqmp.c
F: driver/firmware/firmware-zynqmp.c
F: drivers/fpga/zynqpl.c
F: drivers/gpio/zynq_gpio.c
+F: drivers/gpio/zynqmp_gpio_modepin.c
F: drivers/i2c/i2c-cdns.c
F: drivers/i2c/muxes/pca954x.c
F: drivers/i2c/zynq_i2c.c
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 504abca0b717..f9d5234f05ce 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1190,6 +1190,7 @@ config ARCH_ZYNQMP
imply FAT_WRITE
imply MP
imply DM_USB_GADGET
+ imply ZYNQMP_GPIO_MODEPIN if DM_GPIO && USB
config ARCH_TEGRA
bool "NVIDIA Tegra"
diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index 40abc33772eb..8192ce5f676f 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -523,4 +523,13 @@ config NOMADIK_GPIO
into a number of banks each with 32 GPIOs. The GPIOs for a device are
defined in the device tree with one node for each bank.
+config ZYNQMP_GPIO_MODEPIN
+ bool "ZynqMP gpio modepin"
+ depends on DM_GPIO
+ help
+ This config enables the ZynqMP gpio modepin driver. ZynqMP modepin
+ driver will set and get the status of PS_MODE pins. These modepins
+ are accessed using xilinx firmware. In modepin register, [3:0] bits
+ set direction, [7:4] bits read IO, [11:8] bits set/clear IO.
+
endif
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index 3c851b38c7cc..3eb77f58c11d 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -69,3 +69,4 @@ obj-$(CONFIG_NX_GPIO) += nx_gpio.o
obj-$(CONFIG_SIFIVE_GPIO) += sifive-gpio.o
obj-$(CONFIG_NOMADIK_GPIO) += nmk_gpio.o
obj-$(CONFIG_MAX7320_GPIO) += max7320_gpio.o
+obj-$(CONFIG_ZYNQMP_GPIO_MODEPIN) += zynqmp_gpio_modepin.o
diff --git a/drivers/gpio/zynqmp_gpio_modepin.c
b/drivers/gpio/zynqmp_gpio_modepin.c
new file mode 100644
index ..078fd833959a
--- /dev/null
+++ b/drivers/gpio/zynqmp_gpio_modepin.c
@@ -0,0 +1,153 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * ZynqMP GPIO modepin driver
+ *
+ * Copyright (C) 2021 Xilinx, Inc.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define OUTEN(pin) (BIT(0) << (pin))
+#define INVAL(pin) (BIT(4) << (pin))
+#define OUTVAL(pin)(BIT(8) << (pin))
+
+#define ZYNQMP_CRL_APB_BOOTPIN_CTRL_MASK 0xF0F
+#define ZYNQMP_CRL_APB_BOOT_PIN_CTRL (ZYNQMP_CRL_APB_BASEADDR + \
+ (0x250U))
+
+static int get_gpio_modepin(u32 *ret_payload)
+{
+ return xilinx_pm_request(PM_MMIO_READ, ZYNQMP_CRL_APB_BOOT_PIN_CTRL,
+0, 0, 0, ret_payload);
+}
+
+static int set_gpio_modepin(int val)
+{
+ return xilinx_pm_request(PM_MMIO_WRITE, ZYNQMP_CRL_APB_BOOT_PIN_CTRL,
+ZYNQMP_CRL_APB_BOOTPIN_CTRL_MASK,
+val, 0, NULL);
+}
+
+static int modepin_gpio_direction_input(struct udevice *dev,
+ unsigned int offset)
+{
+ return 0;
+}
+
+static int modepin_gpio_set_value(struct udevice *dev, unsigned int offset,
+ int value)
+{
+ u32 ret_payload[PAYLOAD_ARG_CNT];
+ u32 out_val = 0;
+ int ret;
+
+ ret = get_gpio_modepin(ret_payload);
+ if (value)
+ out_val = OUTVAL(offset) | ret_payload[1];
+ else
+ out_val = ~OUTVAL(offset) & ret_payload[1];
+
+ return set_gpio_modepin(out_val);
+}
+
+static int modepin_gpio_direction_output(struct udevice *dev,
+unsigned int offset, int value)
+{
+ u32 ret_payload[PAYLOAD_ARG_CNT];
+ u32 out_en = 0;
+ int ret;
+
+ ret = get_gpio_modepin(ret_payload);
+ if (ret)
+ return ret;
+
+ if (value)
+ out_en = OUTEN(offset) | ret_payload[1];
+ else
+ out_en = ~OUTEN(offset) & ret_payload[1];
+
+ ret = set_gpio_modepin(out_en);
+ if (ret)
+ return ret;
+
+ return modepin_gpio_set_value(dev, offset, value);
+}
+
Re: [PATCH] arm64: zynqmp: Replace comma by semicolon
On 10/21/21 08:58, Michal Simek wrote: Fix issue reported by checkpatch.pl WARNING: Possible comma where semicolon could be used #499: FILE: board/xilinx/zynqmp/zynqmp.c:499: + size = ALIGN(CONFIG_SYS_MALLOC_LEN + total_size, MMU_SECTION_SIZE), + reg = lmb_alloc(, size, MMU_SECTION_SIZE); Signed-off-by: Michal Simek --- board/xilinx/zynqmp/zynqmp.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/board/xilinx/zynqmp/zynqmp.c b/board/xilinx/zynqmp/zynqmp.c index b24db5306ae0..b13b65182a48 100644 --- a/board/xilinx/zynqmp/zynqmp.c +++ b/board/xilinx/zynqmp/zynqmp.c @@ -496,7 +496,7 @@ ulong board_get_usable_ram_top(ulong total_size) lmb_init(); lmb_add(, gd->ram_base, gd->ram_size); boot_fdt_add_mem_rsv_regions(, (void *)gd->fdt_blob); - size = ALIGN(CONFIG_SYS_MALLOC_LEN + total_size, MMU_SECTION_SIZE), + size = ALIGN(CONFIG_SYS_MALLOC_LEN + total_size, MMU_SECTION_SIZE); reg = lmb_alloc(, size, MMU_SECTION_SIZE); if (!reg) Applied. M -- Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91 w: www.monstr.eu p: +42-0-721842854 Maintainer of Linux kernel - Xilinx Microblaze Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP/Versal SoCs
Re: [PATCH v2] xilinx: zynqmp: Save multiboot as variable
On 10/25/21 10:10, Michal Simek wrote:
Save multiboot register as u-boot variable. And use it as primary source
for composing dfu_alt_info for capsule update. If variable is not defined
Signed-off-by: Michal Simek
---
Changes in v2:
- Handle also error values from mult_boot() - Reported by Oleksandr Suvorov
board/xilinx/zynqmp/zynqmp.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/board/xilinx/zynqmp/zynqmp.c b/board/xilinx/zynqmp/zynqmp.c
index 5a1f8153409c..dfb5dab7afa3 100644
--- a/board/xilinx/zynqmp/zynqmp.c
+++ b/board/xilinx/zynqmp/zynqmp.c
@@ -640,7 +640,7 @@ int board_late_init(void)
const char *mode;
char *new_targets;
char *env_targets;
- int ret;
+ int ret, multiboot;
#if defined(CONFIG_USB_ETHER) && !defined(CONFIG_USB_GADGET_DOWNLOAD)
usb_ether_init();
@@ -658,6 +658,10 @@ int board_late_init(void)
if (ret)
return ret;
+ multiboot = multi_boot();
+ if (multiboot >= 0)
+ env_set_hex("multiboot", multiboot);
+
bootmode = zynqmp_get_bootmode();
puts("Bootmode: ");
@@ -864,6 +868,10 @@ void set_dfu_alt_info(char *interface, char *devstr)
memset(buf, 0, sizeof(buf));
multiboot = multi_boot();
+ if (multiboot < 0)
+ multiboot = 0;
+
+ multiboot = env_get_hex("multiboot", multiboot);
debug("Multiboot: %d\n", multiboot);
switch (zynqmp_get_bootmode()) {
Applied,
Michal
Re: Pull request: u-boot-sunxi/master for 2021.10 - 2nd part
On Mon, 25 Oct 2021 14:29:10 -0400
Tom Rini wrote:
Hi Tom,
> On Mon, Oct 25, 2021 at 03:06:58PM +0100, Andre Przywara wrote:
>
> > Hi Tom,
> >
> > please pull the second sunxi PR for the 2021.10 merge window.
> > I decided to merge most of Samuel's rework and some smaller patches that
> > pave the way for more DM transitions and for accommodating the RISC-V SoC
> > in the future. Merging them now gives us the opportunity to get some wider
> > testing, since those subtle changes tend to break things.
> >
> > Compile-tested for all 159 sunxi boards, boot-tested on Pine64-LTS
> > and OrangePi Zero.
> >
> > Summary:
> > - Add and enable watchdog driver
> > - Prepare for SYSRESET driven AXP poweroff
> > - Prepare for SoCs without MMC2
> > - Some fixes for extending SPL (SPL-DM for RISC-V)
> > - Some preparations for proper VBUS management
> > - Fix secure monitor move
> >
> > Thanks,
> > Andre
> >
> >
> > The following changes since commit 355d1e24f6143c4839be3c015c191421c4e9449c:
> >
> > Merge https://source.denx.de/u-boot/custodians/u-boot-spi (2021-10-23
> > 10:49:28 -0400)
> >
> > are available in the Git repository at:
> >
> > https://source.denx.de/u-boot/custodians/u-boot-sunxi.git master
> >
> > for you to fetch changes up to c846fe43f0561311eb7261b34023a04646cdbd0d:
> >
> > mmc: sunxi: conditionally include MMC2 initialization code (2021-10-25
> > 14:54:57 +0100)
> >
>
> So first, up, this is now applied to u-boot/master.
Many thanks, and sorry for the late push!
> Next, I dug out my original Kickstarted Pine A64 board (as it's the only
> sunxi platform I have), and I see it's detected with 1GB memory and as
> Pine64+ which seems wrong, with the pine64_plus_defconfig (which is what
> I thought handled all of the A64 platforms).
For the naming: There are three SKUs for the original Pine A64 board:
- Pine A64: 512 MB with 100Mbit Ethernet PHY, lacking display and camera
connectors (rare, mostly to meet the original 15 USD price tag)
- Pine A64+ 1GB: 1GB DRAM with 1Gbit Ethernet PHY, with all connectors
- Pine A64+ 2GB: 2GB DRAM with 1Gbit Ethernet PHY, with all connectors
Also note that for those first boards from Pine64 the name of the
company (Pine64) is sometimes uses for the boards as well ("Pine64
board"), even though this should be "Pine A64 board from Pine64". That
is somewhat reflected in the defconfig name. In hindsight the defconfig
should have been named more "pine-a64_defconfig", but I guess this is
too late now? I see a lot of inconsistencies in naming, especially
regarding capitalisation and dashes vs. underscores, check
configs/[bB]anana* for instance, but probably renaming causes more harm
than good?
So I guess you have the middle one (the most common among the first
wave), so that all seems correct? We differentiate between the non-plus
and plus version at runtime, by the amount of DRAM detected, so that's
pretty reliable. The 1GB and 2GB are otherwise the same, so same DT.
The actual non-plus versions are somewhat rare, I guess most people
just added the 4(!) bucks to get more RAM and Gigabit Ethernet.
> I've not booted this up in
> forever, and Armbian (the first binary I grabbed) does this as well with
> v2020.10 (and I'm using the same TF-A rev of 87311b4) so maybe the
> answer is I should just e-waste this board and pick up something else?
Not sure exactly why? Is there anything that's broken, apart from the
presumed misnaming? I would be happy to hear about any issues you have,
in my experience those "outsider" inputs are very useful (I am far too
familiar with all those tiny quirks).
When U-Boot starts, UEFI boot should work out of the box, just pop a
generic arm64 Debian/SuSE/Fedora/Ubuntu EFI installer USB stick in,
should work even with HDMI and USB keyboard.
Cheers,
Andre
[GIT PULL] Please pull u-boot-mmc master
Hi Tom, Please pull u-boot-mmc master into u-boot master branch. If there is a problem, let me know, plz. Best Regards, Jaehoon Chung CI: https://source.denx.de/u-boot/custodians/u-boot-mmc/-/pipelines/9649 The following changes since commit aafc378a6caef453a40f2f9f3d6bef69e592c28d: Merge https://source.denx.de/u-boot/custodians/u-boot-marvell (2021-10-28 07:57:54 -0400) are available in the Git repository at: g...@source.denx.de:u-boot/custodians/u-boot-mmc.git master for you to fetch changes up to c95b0297e95613fc68b1d92118ee64720d142f8c: mmc: arm_pl180_mmci: Enable HWFC for specific versions of MCI (2021-10-29 18:22:32 +0900) - Fix mmc_switch timeout - Update mmc hwpartitiion command - Support wait_dat0 for Freescale eSDHC/sdhci drivers Jaehoon Chung (1): cmd: mmc: check whether card is SD or eMMC before hwpartition Kirill Kapranov (1): mmc: Fix mmc_switch excessive timeout Marek Vasut (1): cmd: mmc: Support mmc hwpartition user enh start - Stephen Carlson (2): drivers: mmc: Add wait_dat0 support for Freescale eSDHC driver drivers: mmc: Add wait_dat0 support for sdhci driver Usama Arif (1): mmc: arm_pl180_mmci: Enable HWFC for specific versions of MCI cmd/mmc.c| 38 ++ drivers/mmc/arm_pl180_mmci.c | 14 ++ drivers/mmc/arm_pl180_mmci.h | 1 + drivers/mmc/fsl_esdhc.c | 16 drivers/mmc/mmc.c| 4 ++-- drivers/mmc/sdhci.c | 20 include/sdhci.h | 2 ++ 7 files changed, 89 insertions(+), 6 deletions(-)
Re: [PATCH v5 02/26] doc: Add documentation about devicetree usage
Hi Simon, [...] > > > > > > Why me? Perhaps Linaro could take this on instead of working in a > > > separate tool and domain? You guys could really pull things together > > > and reduce the fragmentation, if you took it on. > > > > > > Honestly it is hard enough to even get Linaro people to write a test > > > for code they have written. What gives? > > > > That's completely inaccurate. We've added selftests for *every* > > single feature we've sent for EFI up to now. Functionality wise the > > past 2 years we've added > > - EFI variables > > - EFI secure boot > > - capsule updates > > - initrd loading > > - efi TCG protocol > > - ESRT tables > > - RNG protocol > > > > 5a24239c951e8 efi_loader: selftest: enable APPEND_WRITE tests > > 3fc2b16335721 cmd: bootefi: carve out efi_selftest code from do_bootefi() > > 1170fee695197 efi_selftest: fix variables test for GetNextVariableName() > > ce62b0f8f45f1 test/py: Fix efidebug related tests > > 450596f2ac3fd test/py: efi_capsule: test for FIT image capsule > > de489d82e3189 test: test the ESRT creation > > 57be8cdce35 test/py: efi_secboot: small rework for adding a new test > > e1174c566a61c test/py: efi_secboot: add test for intermediate certificates > > 479ab6c17eda7 efi_selftest: add selftests for loadfile2 used to load > > initramfs > > > > and I am pretty sure I am forgetting more on functionality and selftests. > > > > So basically we've either contributed new selftests for *everything* > > we've or fixed the existing ones. The only thing that's not merged is > > the TCG selftests which are on upstream review. > > Er, I didn't say or mean that no tests were written, just that there > is too much push-back on it. Heinrich put a huge amount of effort into There's no pushback at all, apart from the TPM one. (and for a very good reason I've explained over and over again). In fact we add the sefltests as part of our patchsets. > the tests and basically created a strong base for it. Congrats and > huge kudos to him. As to Linaro, no offence intended, and it is great > that all these tests have been added. Thank you for your efforts and > it is very helpful. But I think you miss my point. Or perhaps you > don't even agree with it? I sent an email about this on one patch just > a day or two ago. I guess you mean [1]. I've lost count of how many times I responded to this. Threads [2], [3] and [4] are just a few examples, so I just got tired or replying the same thing over and over. So bottom line, we are contributing selftests as always, we just don't agree with the way *you* want this specific TPM test, trying to force us into sandbox. So instead of respecting what we have (which btw is acceptable from u-boot's perspective and cleans up a lot of the TPM crud along the way), you went ahead making misleading statements on the selftests we contribute, in general. What's even more annoying is that, as I showed you, we pretty much add a selftest for *every* feature we add. Excellent ... that's certainly ... encouraging ... and very productive. > > As to the leadership side (my bigger point), Linaro is leading us all > down this fragmented path, with TF-A, FIP, more and more binaries and > larger firmware diagrams. Or do you disagree with that too? > Of course I disagree. People decided not to use SPL for their own reasons. I am certainly not qualified to answer why Arm choose to do that, but it seems to be common nowdays (risc-v/OpenSBI). All Linaro is doing is making sure U-Boot is compatible and remains the de-facto choice for embedded boot loaders playing nicely with all the new FSBLs come up with. If you cosinder SPL and U-Boot the center of the known universe, we certainly view things differently. FWIW it's *our* work mostly that made U-Boot SystemReady compliant, which is something Arm pushes for [5]. > I'm sorry if you find this a bit sharp. Which part? The first one wrt to selftests is not sharp. It's manipulative and utterly unacceptable for me, not to mention entirely fabricated. The latter on bootloading fragmentation, I am always happy to discuss. > But someone needs to be > pointing these things out. I don't know who else is doing so. ARM > firmware has got noticeably more complicated and fragmented in the > last five years, hasn't it? What can Linaro do to address that? I am > very happy to help and provide part of the solution, but it needs a > shared vision. There's a TF-A mailing list, we can certainly engage there and try to align our ideas/designs. > > It's not even just a Linaro/ARM problem. On the x86 side it is fast > becoming a living nightmare. > > Perhaps the problem here is just the pandemic response and the > inability for people to get into a room and brainstorm / collaborate / > hack on ideas? I know you have made big efforts to engage, Ilias. We > have spoken many times and I'm sure f2f would be easier. > > > It's not even just a Linaro/ARM problem. On the x86 side it is fast > becoming a living
how is dts/dt.dtb is generated?
Hello, I found when I do make ARCH=arm CROSS_COMPILE=arm-none-eabi- vexpress_ca9x4_defconfig make ARCH=arm CROSS_COMPILE=arm-none-eabi- -j24 , the file dts/dt.dtb.S is executed (looks like linker script) and dts/dt.dtb file is placed in the u-boot.bin binary. Can anyone tell me how this dts/dt.dtb.S is included during the build and how dts/dt.dtb file is generated? Any comment will be deeply appreciated. Thank you. Chan Kim
Re: [PATCH] efi_loader: add EFI_TCG2_PROTOCOL.SubmitCommand
On Fri, 29 Oct 2021 at 15:26, Ilias Apalodimas
wrote:
>
>
> On Fri, Oct 22, 2021 at 08:20:55PM +0900, Masahisa Kojima wrote:
> > This commit adds the EFI_TCG2_PROTOCOL.SubmitCommand
> > required in the TCG PC Client PFP spec.
> > SubmitCommand enables to send the raw command to the TPM device.
> >
> > To implement this api, tpm2_submit_command() is added
> > into tpm-v2.c.
> >
> > Signed-off-by: Masahisa Kojima
> > ---
> > include/tpm-v2.h | 15 +++
> > lib/efi_loader/efi_tcg2.c | 37 +++--
> > lib/tpm-v2.c | 6 ++
> > 3 files changed, 52 insertions(+), 6 deletions(-)
> >
> > diff --git a/include/tpm-v2.h b/include/tpm-v2.h
> > index e6b68769f3..6b04a637ca 100644
> > --- a/include/tpm-v2.h
> > +++ b/include/tpm-v2.h
> > @@ -642,4 +642,19 @@ u32 tpm2_write_lock(struct udevice *dev, u32 index);
> > */
> > u32 tpm2_disable_platform_hierarchy(struct udevice *dev);
> >
> > +/**
> > + * submit user specified data to the TPM and get response
> > + *
> > + * @dev TPM device
> > + * @sendbuf: Buffer of the data to send
> > + * @send_size: Size of the data to send
> > + * @recvbuf: Buffer to save the response to
> > + * @recv_size: Pointer to the size of the response buffer
> > + *
> > + * Returns 0 on success (and places the number of response bytes at
> > + * recv_size) or -ve on failure.
> > + */
> > +u32 tpm2_submit_command(struct udevice *dev, const u8 *sendbuf,
> > + size_t send_size, u8 *recvbuf, size_t *recv_size);
> > +
> > #endif /* __TPM_V2_H */
> > diff --git a/lib/efi_loader/efi_tcg2.c b/lib/efi_loader/efi_tcg2.c
> > index da02e281e7..a0728b555e 100644
> > --- a/lib/efi_loader/efi_tcg2.c
> > +++ b/lib/efi_loader/efi_tcg2.c
> > @@ -1033,13 +1033,38 @@ out:
> > * Return: status code
> > */
> > static efi_status_t EFIAPI
> > -efi_tcg2_submit_command(__maybe_unused struct efi_tcg2_protocol *this,
> > - u32 __maybe_unused input_param_block_size,
> > - u8 __maybe_unused *input_param_block,
> > - u32 __maybe_unused output_param_block_size,
> > - u8 __maybe_unused *output_param_block)
> > +efi_tcg2_submit_command(struct efi_tcg2_protocol *this,
> > + u32 input_param_block_size,
> > + u8 *input_param_block,
> > + u32 output_param_block_size,
> > + u8 *output_param_block)
> > {
> > - return EFI_UNSUPPORTED;
> > + struct udevice *dev;
> > + efi_status_t ret;
> > + u32 rc;
> > + size_t resp_buf_size = output_param_block_size;
> > +
> > + EFI_ENTRY("%p, %u, %p, %u, %p", this, input_param_block_size,
> > + input_param_block, output_param_block_size,
> > output_param_block);
> > +
> > + if (!this || !input_param_block || !input_param_block_size) {
> > + ret = EFI_INVALID_PARAMETER;
> > + goto out;
> > + }
> > +
> > + ret = platform_get_tpm2_device();
> > + if (ret != EFI_SUCCESS)
> > + goto out;
> > +
> > + rc = tpm2_submit_command(dev, input_param_block,
> > input_param_block_size,
> > + output_param_block, _buf_size);
>
> Shouldn't you check resp_buf_size against output_param_block_size here and
> return EFI_BUFFER_TOO_SMALL if the output_param_block_size is smaller?
It should be checked, thank you.
>
> > + if (rc) {
> > + ret = EFI_DEVICE_ERROR;
> > + goto out;
> > + }
> > +
> > +out:
> > + return EFI_EXIT(ret);
> > }
> >
> > /**
> > diff --git a/lib/tpm-v2.c b/lib/tpm-v2.c
> > index 235f8c20d4..ee08948ec1 100644
> > --- a/lib/tpm-v2.c
> > +++ b/lib/tpm-v2.c
> > @@ -659,3 +659,9 @@ u32 tpm2_disable_platform_hierarchy(struct udevice *dev)
> >
> > return 0;
> > }
> > +
> > +u32 tpm2_submit_command(struct udevice *dev, const u8 *sendbuf,
> > + size_t send_size, u8 *recvbuf, size_t *recv_size)
>
> Why do we keep send_size in the arg list? tpm_sendrecv_command is exported
> anyway, so we can just use that?
Yes, send_size is not used, should be removed.
tpm_sendrecv_command() is exported, but declared in lib/tpm-utils.h,
it means this function can only be called under u-boot/lib, can not be
called from ./lib/efi_loader/*.
Also the tpm stack seems to be designed having following layers.
tpm-v1/2.c -> tpm-common.c -> device-dependent driver
Thanks,
Masahisa Kojima
>
> > +{
> > + return tpm_sendrecv_command(dev, sendbuf, recvbuf, recv_size);
> > +}
> > --
> > 2.17.1
> >
>
> Thanks!
> /Ilias
Re: [PATCH 2/5] env: Fix env_get() when returning empty string using env_get_f()
On Thursday 28 October 2021 21:17:38 Simon Glass wrote: > Hi Marek, > > On Wed, 27 Oct 2021 at 21:28, Marek Behún wrote: > > > > From: Marek Behún > > > > The env_get_f() function returns -1 on failure. Returning 0 means that > > the variable exists, and is empty string. > > > > Signed-off-by: Marek Behún > > --- > > env/common.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > Reviewed-by: Simon Glass > > But it isn't normally possible to set an env var to an empty string. > How does this happen? IIRC you can set variable to empty string via e.g.: setenv abc '' > > > > diff --git a/env/common.c b/env/common.c > > index 2aa23545ba..757c5f9ecd 100644 > > --- a/env/common.c > > +++ b/env/common.c > > @@ -125,7 +125,7 @@ char *env_get(const char *name) > > } > > > > /* restricted capabilities before import */ > > - if (env_get_f(name, (char *)(gd->env_buf), sizeof(gd->env_buf)) > 0) > > + if (env_get_f(name, (char *)(gd->env_buf), sizeof(gd->env_buf)) >= > > 0) > > return (char *)(gd->env_buf); > > > > return NULL; > > -- > > 2.32.0 > > > > Regards, > Simon
Re: [PATCH 4/5] env: Add support for board specific special default environment
On Thu, 28 Oct 2021 21:17:41 -0600 Simon Glass wrote: > Hi Marek, > > On Wed, 27 Oct 2021 at 21:28, Marek Behún wrote: > > > > From: Marek Behún > > > > The default_environment[] buffer is built at compile time, but sometimes > > it makes sense for some default environment variables to be determined > > at runtime, for example: > > - one board code may support different boards, and needs that > > fdtfile, board, board_name > > are set appropriately when command > > env default -a > > is executed > > - some boards may want to prohibit the > > env default -a > > command to remove device MAC addresses stored in > > ethaddr, ethNaddr. > > This is the case for the ESPRESSObin board code, for example, where > > currently the board_late_init() function rewrites the default > > environment array to achieve this. > > > > Add a new board specific function, > > > > const char *board_special_default_env(unsigned i, const char **name); > > > > which returns the value of i-th board special default environemnt > > variable, while storing it's name to *name. > > > > Add default weak implementation of this functions returning NULL. > > > > Add code to default environemnt handlers in env/common.c, which iterate > > these special board default environment variables and get it's values in > > precedence to values in the default_environment[] buffer. > > > > Signed-off-by: Marek Behún > > --- > > env/common.c | 99 ++-- > > 1 file changed, 96 insertions(+), 3 deletions(-) > > What do you think about using a sysinfo driver for this? There are > already a lot of weak functions in U-Boot. I confess I am looking at sysinfo API for the first time just now. It seems like a reasonable thing, but how to combine with default environment for this? The thing is that Pali's code for ESPRESSObin needs to prohibit deleting the ethaddrs from env with "env default -a", because there were issues with the mac address being lost... Marek
Re: [PATCH 2/5] env: Fix env_get() when returning empty string using env_get_f()
On Thu, 28 Oct 2021 21:17:38 -0600 Simon Glass wrote: > Hi Marek, > > On Wed, 27 Oct 2021 at 21:28, Marek Behún wrote: > > > > From: Marek Behún > > > > The env_get_f() function returns -1 on failure. Returning 0 means that > > the variable exists, and is empty string. > > > > Signed-off-by: Marek Behún > > --- > > env/common.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > Reviewed-by: Simon Glass > > But it isn't normally possible to set an env var to an empty string. > How does this happen? Hmm, I don't see code in cmd/nvedit.c's _do_env_set() that would prohibit empty string as value... Why isn't it possible?
Re: [PATCH v2] cmd: usb_mass_storage: Use part_get_info_by_dev_and_name_or_num
On 10/28/21 9:43 PM, Sean Anderson wrote: Hi Marek, On 7/22/21 2:24 PM, Sean Anderson wrote: On 7/8/21 2:02 PM, Sean Anderson wrote: On 7/8/21 2:00 PM, Marek Vasut wrote: On 7/8/21 7:36 PM, Sean Anderson wrote: This allows specifying partitions using more extended syntax. This is particularly useful to access eMMC hardware partitions. For example, this allows something like ums mmc 0.0,0.1,0.2,0.3 Shouldn't that be ums X mmc Y ? Yes. to expose four LUNs for each of the four default eMMC hardware partitions. Note that the comma syntax was already present. That's all good, but is there some specification of the syntax somewhere instead of a random example ?\ Yes, see https://u-boot.readthedocs.io/en/latest/usage/partitions.html I suppose that https://u-boot.readthedocs.io/en/latest/usage/ums.html should be updated as well, especially since the comma syntax is undocumented. Upon closer inspection, the partition syntax is actually already documented. This patch just brings the command in-line with what is documented. Does this patch need any additional modifications? As stated above, this new behavior is actually what is already documented. Update the commit message so the example isn't wrong (i.e. ums X mmc y). Validate that "ums 0 mmc 0" still works for exporting the entire block device, if it does, then I can pick it. Thanks
[PATCH 1/1] imx8mm-cl-iot-gate-optee: remove _SUPPORT from CONFIG_SPL_{MMC, SERIAL}
From: "Ying-Chun Liu (PaulLiu)" CONFIG_SPL_MMC_SUPPORT and CONFIG_SPL_SERIAL_SUPPORT is not there anymore. We need to use CONFIG_SPL_MMC and CONFIG_SPL_SERIAL. Signed-off-by: Ying-Chun Liu (PaulLiu) Cc: uboot-imx --- configs/imx8mm-cl-iot-gate-optee_defconfig | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/configs/imx8mm-cl-iot-gate-optee_defconfig b/configs/imx8mm-cl-iot-gate-optee_defconfig index d987328922..f6b77d87a7 100644 --- a/configs/imx8mm-cl-iot-gate-optee_defconfig +++ b/configs/imx8mm-cl-iot-gate-optee_defconfig @@ -16,8 +16,8 @@ CONFIG_DM_GPIO=y CONFIG_DEFAULT_DEVICE_TREE="imx8mm-cl-iot-gate-optee" CONFIG_SPL_TEXT_BASE=0x7E1000 CONFIG_TARGET_IMX8MM_CL_IOT_GATE_OPTEE=y -CONFIG_SPL_MMC_SUPPORT=y -CONFIG_SPL_SERIAL_SUPPORT=y +CONFIG_SPL_MMC=y +CONFIG_SPL_SERIAL=y CONFIG_SPL_DRIVERS_MISC=y CONFIG_SPL=y CONFIG_DISTRO_DEFAULTS=y -- 2.33.0
[PATCH 0/1] imx8mm-cl-iot-gate-optee: remove _SUPPORT from CONFIG_SPL_{MMC, SERIAL}
From: "Ying-Chun Liu (PaulLiu)"
CONFIG_SPL_MMC_SUPPORT and CONFIG_SPL_SERIAL_SUPPORT is not there
anymore. We need to use CONFIG_SPL_MMC and CONFIG_SPL_SERIAL.
Just found that master branch doesn't boot on Compulab's iot-gate-imx8.
This is a fix.
Ying-Chun Liu (PaulLiu) (1):
imx8mm-cl-iot-gate-optee: remove _SUPPORT from CONFIG_SPL_{MMC,SERIAL}
configs/imx8mm-cl-iot-gate-optee_defconfig | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--
2.33.0
[PATCH] ARM: amlogic: add JetHub D1 eth mac generation with manufacturer OUI
JetHome has own MAC OUI. Add jethub-j100 board file. Update config.
Signed-off-by: Vyacheslav Bocharov
---
board/amlogic/jethub-j100/MAINTAINERS | 8 +
board/amlogic/jethub-j100/Makefile | 6
board/amlogic/jethub-j100/jethub-j100.c | 41 +
board/amlogic/jethub-j80/MAINTAINERS| 3 +-
configs/jethub_j100_defconfig | 1 +
5 files changed, 57 insertions(+), 2 deletions(-)
create mode 100644 board/amlogic/jethub-j100/MAINTAINERS
create mode 100644 board/amlogic/jethub-j100/Makefile
create mode 100644 board/amlogic/jethub-j100/jethub-j100.c
diff --git a/board/amlogic/jethub-j100/MAINTAINERS
b/board/amlogic/jethub-j100/MAINTAINERS
new file mode 100644
index 00..43f6a5fc86
--- /dev/null
+++ b/board/amlogic/jethub-j100/MAINTAINERS
@@ -0,0 +1,8 @@
+JetHome JetHub
+M: Vyacheslav Bocharov
+S: Maintained
+L: u-boot-amlo...@groups.io
+F: board/amlogic/jethub-j100/
+F: configs/jethub_j100_defconfig
+F: doc/board/amlogic/jethub-j100.rst
+F: include/configs/jethub.h
diff --git a/board/amlogic/jethub-j100/Makefile
b/board/amlogic/jethub-j100/Makefile
new file mode 100644
index 00..4d935af984
--- /dev/null
+++ b/board/amlogic/jethub-j100/Makefile
@@ -0,0 +1,6 @@
+# SPDX-License-Identifier: GPL-2.0+
+#
+# (C) Copyright 2021 Vyacheslav Bocharov
+# Author: Vyacheslav Bocharov
+
+obj-y := jethub-j100.o
diff --git a/board/amlogic/jethub-j100/jethub-j100.c
b/board/amlogic/jethub-j100/jethub-j100.c
new file mode 100644
index 00..575bb31573
--- /dev/null
+++ b/board/amlogic/jethub-j100/jethub-j100.c
@@ -0,0 +1,41 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2021 Vyacheslav Bocharov
+ * Author: Vyacheslav Bocharov
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+int misc_init_r(void)
+{
+ u8 mac_addr[ARP_HLEN];
+ char serial[SM_SERIAL_SIZE];
+ u32 sid;
+
+ if (!meson_sm_get_serial(serial, SM_SERIAL_SIZE)) {
+ sid = crc32(0, (unsigned char *)serial, SM_SERIAL_SIZE);
+ /* Ensure the NIC specific bytes of the mac are not all 0 */
+ if ((sid & 0x) == 0)
+ sid |= 0x80;
+
+ /* OUI registered MAC address */
+ mac_addr[0] = 0x10;
+ mac_addr[1] = 0x27;
+ mac_addr[2] = 0xBE;
+ mac_addr[3] = (sid >> 16) & 0xff;
+ mac_addr[4] = (sid >> 8) & 0xff;
+ mac_addr[5] = (sid >> 0) & 0xff;
+
+ eth_env_set_enetaddr("ethaddr", mac_addr);
+ }
+
+ return 0;
+}
diff --git a/board/amlogic/jethub-j80/MAINTAINERS
b/board/amlogic/jethub-j80/MAINTAINERS
index 459e9f89da..a899153117 100644
--- a/board/amlogic/jethub-j80/MAINTAINERS
+++ b/board/amlogic/jethub-j80/MAINTAINERS
@@ -4,6 +4,5 @@ S: Maintained
L: u-boot-amlo...@groups.io
F: board/amlogic/jethub-j80/
F: configs/jethub_j80_defconfig
-F: configs/jethub_j100_defconfig
F: doc/board/amlogic/jethub-j80.rst
-F: doc/board/amlogic/jethub-j100.rst
+F: include/configs/jethub.h
diff --git a/configs/jethub_j100_defconfig b/configs/jethub_j100_defconfig
index 290ce4db85..ad026a89e0 100644
--- a/configs/jethub_j100_defconfig
+++ b/configs/jethub_j100_defconfig
@@ -1,4 +1,5 @@
CONFIG_ARM=y
+CONFIG_SYS_BOARD="jethub-j100"
CONFIG_SYS_CONFIG_NAME="jethub"
CONFIG_ARCH_MESON=y
CONFIG_SYS_TEXT_BASE=0x0100
--
2.30.2
Re: [PATCH] efi_loader: add EFI_TCG2_PROTOCOL.SubmitCommand
On Fri, Oct 22, 2021 at 08:20:55PM +0900, Masahisa Kojima wrote:
> This commit adds the EFI_TCG2_PROTOCOL.SubmitCommand
> required in the TCG PC Client PFP spec.
> SubmitCommand enables to send the raw command to the TPM device.
>
> To implement this api, tpm2_submit_command() is added
> into tpm-v2.c.
>
> Signed-off-by: Masahisa Kojima
> ---
> include/tpm-v2.h | 15 +++
> lib/efi_loader/efi_tcg2.c | 37 +++--
> lib/tpm-v2.c | 6 ++
> 3 files changed, 52 insertions(+), 6 deletions(-)
>
> diff --git a/include/tpm-v2.h b/include/tpm-v2.h
> index e6b68769f3..6b04a637ca 100644
> --- a/include/tpm-v2.h
> +++ b/include/tpm-v2.h
> @@ -642,4 +642,19 @@ u32 tpm2_write_lock(struct udevice *dev, u32 index);
> */
> u32 tpm2_disable_platform_hierarchy(struct udevice *dev);
>
> +/**
> + * submit user specified data to the TPM and get response
> + *
> + * @dev TPM device
> + * @sendbuf: Buffer of the data to send
> + * @send_size: Size of the data to send
> + * @recvbuf: Buffer to save the response to
> + * @recv_size: Pointer to the size of the response buffer
> + *
> + * Returns 0 on success (and places the number of response bytes at
> + * recv_size) or -ve on failure.
> + */
> +u32 tpm2_submit_command(struct udevice *dev, const u8 *sendbuf,
> + size_t send_size, u8 *recvbuf, size_t *recv_size);
> +
> #endif /* __TPM_V2_H */
> diff --git a/lib/efi_loader/efi_tcg2.c b/lib/efi_loader/efi_tcg2.c
> index da02e281e7..a0728b555e 100644
> --- a/lib/efi_loader/efi_tcg2.c
> +++ b/lib/efi_loader/efi_tcg2.c
> @@ -1033,13 +1033,38 @@ out:
> * Return: status code
> */
> static efi_status_t EFIAPI
> -efi_tcg2_submit_command(__maybe_unused struct efi_tcg2_protocol *this,
> - u32 __maybe_unused input_param_block_size,
> - u8 __maybe_unused *input_param_block,
> - u32 __maybe_unused output_param_block_size,
> - u8 __maybe_unused *output_param_block)
> +efi_tcg2_submit_command(struct efi_tcg2_protocol *this,
> + u32 input_param_block_size,
> + u8 *input_param_block,
> + u32 output_param_block_size,
> + u8 *output_param_block)
> {
> - return EFI_UNSUPPORTED;
> + struct udevice *dev;
> + efi_status_t ret;
> + u32 rc;
> + size_t resp_buf_size = output_param_block_size;
> +
> + EFI_ENTRY("%p, %u, %p, %u, %p", this, input_param_block_size,
> + input_param_block, output_param_block_size,
> output_param_block);
> +
> + if (!this || !input_param_block || !input_param_block_size) {
> + ret = EFI_INVALID_PARAMETER;
> + goto out;
> + }
> +
> + ret = platform_get_tpm2_device();
> + if (ret != EFI_SUCCESS)
> + goto out;
> +
> + rc = tpm2_submit_command(dev, input_param_block, input_param_block_size,
> + output_param_block, _buf_size);
Shouldn't you check resp_buf_size against output_param_block_size here and
return EFI_BUFFER_TOO_SMALL if the output_param_block_size is smaller?
> + if (rc) {
> + ret = EFI_DEVICE_ERROR;
> + goto out;
> + }
> +
> +out:
> + return EFI_EXIT(ret);
> }
>
> /**
> diff --git a/lib/tpm-v2.c b/lib/tpm-v2.c
> index 235f8c20d4..ee08948ec1 100644
> --- a/lib/tpm-v2.c
> +++ b/lib/tpm-v2.c
> @@ -659,3 +659,9 @@ u32 tpm2_disable_platform_hierarchy(struct udevice *dev)
>
> return 0;
> }
> +
> +u32 tpm2_submit_command(struct udevice *dev, const u8 *sendbuf,
> + size_t send_size, u8 *recvbuf, size_t *recv_size)
Why do we keep send_size in the arg list? tpm_sendrecv_command is exported
anyway, so we can just use that?
> +{
> + return tpm_sendrecv_command(dev, sendbuf, recvbuf, recv_size);
> +}
> --
> 2.17.1
>
Thanks!
/Ilias
Re: [RFC 07/22] dm: blk: add UCLASS_PARTITION
On Fri, Oct 29, 2021 at 06:57:24AM +0200, Heinrich Schuchardt wrote: > > > > I agree with Heinrich that we are better to leave BLK as it is, both > > in name and meaning. I think maybe I am missing the gist of your > > argument. > > > > If we use UCLASS_PART, for example, can we have that refer to both s/w > > and h/w partitions, as Herinch seems to allude to below? What would > > the picture look like the, and would it get us closer to agreement? > > In the driver model: > > A UCLASS is a class of drivers that share the same interface. > A UDEVICE is a logical device that belongs to exactly one UCLASS and is > accessed through this UCLASS's interface. Please be careful about "accessed through" which is a quite confusing expression. I don't always agree with this view. > A hardware partition is an object that exposes only a single interface > for block IO. > > A software partition is an object that may expose two interfaces: one > for block IO, the other for file IO. Are you talking about UEFI world or U-Boot? Definitely, a hw partitions can provide a file system if you want. It's a matter of usage. I remember that we had some discussion about whether block devices on UEFI system should always have a (sw) partition table or not. But it is a different topic. > The UEFI model does not have a problem with this because on a handle you > can install as many different protocols as you wish. But U-Boot's driver > model only allows a single interface per device. Up to now U-Boot has > overcome this limitation by creating child devices for the extra interfaces. > We have the following logical levels: > > Controller | Block device | Software Partition| File system > +--+---+ > NVMe Drive | Namespace| Partition 1..n| FAT, EXT4 > ATA Controller | ATA-Drive| | > SCSI Controller | LUN | | > MMC Controller | HW-Partition | | > MMC Controller | SD-Card | | > USB-Node| USB-Drive| | > > In the device tree this could be modeled as: > > |-- Controller (UCLASS_CTRL) > | |-- Block device / HW Partition (UCLASS_BLK)(A) > | | |-- Partition table (UCLASS_PARTITION_TABLE) (B) > | | |-- Software Partition (UCLASS_BLK) > | | |-- File system (UCLASS_FS) > | | > | |-- Block device (UCLASS_BLK) > | |-- File system (UCLASS_FS) I don't know why we expect PARTITION_TABLE and FS to appear in DM tree. What is the benefit? (A) and (B) always have 1:1 relationship. I also remember that you claimed that not all efi objects(handles and protocols like SIMPE_FILE_SYSTEM_PROTOCOL) need to have corresponding U-Boot counterparts in our 2019 discussion. If we *need* PARTITION_TALBLE, why don't we have HW_PARTITION_TABLE, which should support other type of hw partitions as well? |-- eMMC controller (UCLASS_MMC) | |-- eMMC device1 / Physical media (UCLASS_HW_PARTITION_TABLE?) | |-- Block device / HW Partition:user data (UCLASS_BLK) | | |-- Partition table (UCLASS_PARTITION_TABLE) | | |-- Software Partition (UCLASS_BLK) | | |-- File system (UCLASS_FS) | | | |-- Block device / HW Partition:boot0 (UCLASS_BLK) | |-- Block device / HW Partition:boot1 (UCLASS_BLK) ... | |-- eMMC device2 / Physical media (UCLASS_HW_PARTITION_TABLE?) |-- scsi controller (UCLASS_SCSI) | |-- scsi disk / Physical media (UCLASS_HW_PARTITION_TABLE?) | |-- scsi LUN1 (UCLASS_HW_PARTITION_TABLE?) | | |-- Partition table (UCLASS_PARTITION_TABLE) | | |-- Software Partition (UCLASS_BLK) | |-- scsi LUN2 (UCLASS_HW_PARTITION_TABLE?) ... (Here I ignored scsi buses/channels which make things more complicated.) This kind of complex hierarchy doesn't benefit anybody. -Takahiro Akashi > UCLASS_PARTITION_TABLE would be for the drivers in disk/. > UCLASS_FS would be for the drivers in fs/. > UCLASS_BLK will be for any objects exposing raw block IO. A software > partition does the same. It is created by the partition table driver as > child of the partition table udevice. > > In this model an eMMC device will not be a UCLASS_BLK device because it > does not expose block IO. It is the hardware partition that exposes this > interface. > > The suggested model will allow a clean description of nested partition > tables. > > In the UEFI world the software partition and its file system must be > mapped to a single handle with device path node type HD(). For the > parent block device we may create a child handle with partition number 0 > (HD(0)). For the partition table we will not create a handle. > > Best regards > > Heinrich
