Usage of device-tree for blobs
Hello Simon, some boards like qemu-riscv64_defconfig do not use any device-tree at build time. A device-tree is only supplied at runtime by the prior boot stage (CONFIG_OF_PRIOR_STAGE=y). In doc/develop/devicetree/intro.rst you suggest to put binary blobs into the device-tree. Could you, please, update the documentation to explain how adding blobs to the device-tree works in the different scenarios depending on the values of: CONFIG_OF_EMBED CONFIG_OF_SEPARATE CONFIG_OF_BOARD CONFIG_OF_HOSTFILE CONFIG_OF_PRIOR_STAGE It would be especially important to understand how one can develop a board independent feature which works for all of these settings. Please, describe CONFIG_OF_PRIOR_STAGE in doc/develop/devicetree/control.rst. Best regards Heinrich
Re: [PATCH v2 4/9] verdin-imx8mm: switch to use binman to pack images
On 24.08.21 18:13, Simon Glass wrote:
> Hi Marcel,
>
> On Mon, 23 Aug 2021 at 09:09, Marcel Ziswiler wrote:
>>
>> From: Marcel Ziswiler
>>
>> Use binman to pack images.
>>
>> Signed-off-by: Marcel Ziswiler
>>
>> ---
>>
>> Changes in v2:
>> - Explicitly pass filename to binman when generating binaries as
>> suggested by Heiko.
>> - Use proper intermediate binary u-boot-spl-ddr.bin for imximage as
>> pointed out by Heiko.
>>
>> arch/arm/dts/imx8mm-verdin-u-boot.dtsi | 124 ++-
>> arch/arm/mach-imx/imx8m/Kconfig | 1 +
>> board/toradex/verdin-imx8mm/imximage.cfg | 11 +-
>> configs/verdin-imx8mm_defconfig | 2 +-
>> doc/board/toradex/verdin-imx8mm.rst | 53 +-
>> 5 files changed, 157 insertions(+), 34 deletions(-)
>>
>> diff --git a/arch/arm/dts/imx8mm-verdin-u-boot.dtsi
>> b/arch/arm/dts/imx8mm-verdin-u-boot.dtsi
>> index a97626fa0c1..a3ad8f3ad37 100644
>> --- a/arch/arm/dts/imx8mm-verdin-u-boot.dtsi
>> +++ b/arch/arm/dts/imx8mm-verdin-u-boot.dtsi
>> @@ -1,11 +1,15 @@
>> // SPDX-License-Identifier: GPL-2.0+ OR MIT
>> /*
>> - * Copyright 2020 Toradex
>> + * Copyright 2021 Toradex
>> */
>>
>> #include "imx8mm-u-boot.dtsi"
>>
>> / {
>> + binman: binman {
>> + multiple-images;
>> + };
>> +
>> firmware {
>> optee {
>> compatible = "linaro,optee-tz";
>> @@ -91,3 +95,121 @@
>> &wdog1 {
>> u-boot,dm-spl;
>> };
>> +
>> +&binman {
>> +u-boot-spl-ddr {
>> + align = <4>;
>> + align-size = <4>;
>> + filename = "u-boot-spl-ddr.bin";
>> + pad-byte = <0xff>;
>> +
>> + u-boot-spl {
>> + align-end = <4>;
>> + };
>> +
>> + blob_1: blob-ext@1 {
>
> This works but the naming is a little odd. You can do:
>
> 1d-imem {
>type = "blob-ext";
This is copied from the existing binman config for imx8mm-evk. Before we do
such cosmetic changes for each i.MX8M board separately, maybe it would be a
good idea to switch to a common binman config first and then do this for all
boards at once.
>
>> + filename = "lpddr4_pmu_train_1d_imem.bin";
>> + size = <0x8000>;
>> + };
>> +
>> + blob_2: blob-ext@2 {
>> + filename = "lpddr4_pmu_train_1d_dmem.bin";
>> + size = <0x4000>;
>> + };
>> +
>> + blob_3: blob-ext@3 {
>> + filename = "lpddr4_pmu_train_2d_imem.bin";
>> + size = <0x8000>;
>> + };
>> +
>> + blob_4: blob-ext@4 {
>> + filename = "lpddr4_pmu_train_2d_dmem.bin";
>> + size = <0x4000>;
>> + };
>> + };
>> +
[...]
Re: SPL SPI boot problem after commit "spi: Update speed/mode on change"
On 8/22/21 6:22 PM, Marek Vasut wrote:
On 8/22/21 4:47 PM, Oskari Lemmelä wrote:
On 22.8.2021 14.50, Marek Vasut wrote:
On 8/22/21 9:41 AM, Oskari Lemmelä wrote:
Hi Marek,
I was bisecting SPI flash boot problem in rockpro64 board and commit
e2e95e5e25421fb seems to broke it.
It seems that after speed and mode change SPL is unable to load BL31
anymore from SPI flash device.
There is no errors it just hangs forever.
If I change default mode to 0 (CONFIG_SF_DEFAULT_MODE=0), loading
BL31 seems to work. In that case spi_set_speed_mode is also called
but only speed is changed from 1Mhz to 10Mhz.
So changing mode from 0 to 3 in SPL stage seems to be the problem.
Any idea what could be the problem?
See 8c6d8c3219 ("configs: libretech: set SPI mode to 0")
Rockchip SPI supports both SCLK polarity and phase config and mode 3 is
working fine if uboot is booted from MMC.
However RK3399 documentation says SPI should be disabled while modifying
master settings (speed, mode and so on).
So this could be rk_spi.c driver issue.
Hmm, I don't have any rockchip device, so I cannot help you with that
part.
Are you sure the SPI mode 3 (default) is the correct mode in the first
place ?
After further debugging I think I found the problem. struct dm_spi_bus
speed and
mode are not updated after new spi_set_speed_mode function call.
I tested and updating those values inside spi_set_speed_mode function
fixes issues.
And there is no need to duplicate code to set those after both calls.
diff --git a/drivers/spi/spi-uclass.c b/drivers/spi/spi-uclass.c
index d867b27806..fef567caad 100644
--- a/drivers/spi/spi-uclass.c
+++ b/drivers/spi/spi-uclass.c
@@ -25,10 +25,10 @@ DECLARE_GLOBAL_DATA_PTR;
static int spi_set_speed_mode(struct udevice *bus, int speed, int mode)
{
- struct dm_spi_ops *ops;
+ struct dm_spi_ops *ops = spi_get_ops(bus);
+ struct dm_spi_bus *spi = dev_get_uclass_priv(bus);
int ret;
- ops = spi_get_ops(bus);
if (ops->set_speed)
ret = ops->set_speed(bus, speed);
else
@@ -36,6 +36,8 @@ static int spi_set_speed_mode(struct udevice *bus, int
speed, int mode)
if (ret) {
dev_err(bus, "Cannot set speed (err=%d)\n", ret);
return ret;
+ } else {
+ spi->speed = speed;
}
if (ops->set_mode)
@@ -45,6 +47,8 @@ static int spi_set_speed_mode(struct udevice *bus, int
speed, int mode)
if (ret) {
dev_err(bus, "Cannot set mode (err=%d)\n", ret);
return ret;
+ } else {
+ spi->mode = mode;
}
return 0;
@@ -75,9 +79,6 @@ int dm_spi_claim_bus(struct udevice *dev)
if (ret)
return log_ret(ret);
-
- spi->speed = speed;
- spi->mode = mode;
}
return log_ret(ops->claim_bus ? ops->claim_bus(dev) : 0);
Oskari
Re: [PATCH v2 4/9] verdin-imx8mm: switch to use binman to pack images
On Wed, 2021-08-25 at 10:41 +0200, Frieder Schrempf wrote:
> On 24.08.21 18:13, Simon Glass wrote:
>
> ...
> > This works but the naming is a little odd. You can do:
> >
> > 1d-imem {
> > type = "blob-ext";
>
> This is copied from the existing binman config for imx8mm-evk. Before we do
> such cosmetic changes for each
> i.MX8M board separately, maybe it would be a good idea to switch to a common
> binman config first and then do
> this for all boards at once.
Yes, I agree. Let me revert to a plain copy thereof and subsequently send
another patch set migrating to a
common binman config and then further improving on this one.
> [...]
[PATCH] list: include linux/kernel.h
linux/list.h uses container_of, therefore it depends on linux/kernel.h.
Sync from below linux commit:
commit 8b21d9ca17ff8 ("list: include linux/kernel.h")
Signed-off-by: Mark-PK Tsai
Cc: YJ Chiang
---
include/linux/list.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/linux/list.h b/include/linux/list.h
index f62afa092c..5320c04bf3 100644
--- a/include/linux/list.h
+++ b/include/linux/list.h
@@ -3,6 +3,7 @@
#include
#include
+#include
#ifndef ARCH_HAS_PREFETCH
#define ARCH_HAS_PREFETCH
--
2.18.0
Re: [PATCH 00/28] Initial implementation of bootmethod/bootflow
On Tue, 24 Aug 2021 12:22:42 +0200 (CEST)
Mark Kettenis wrote:
> > Date: Mon, 23 Aug 2021 16:01:46 -0400
> > From: Tom Rini
> >
> > On Mon, Aug 23, 2021 at 11:25:42AM -0600, Simon Glass wrote:
> > > Hi Mark,
> > >
> > > On Mon, 23 Aug 2021 at 05:54, Mark Kettenis
> > > wrote:
> > > >
> > > > > From: Simon Glass
> > > > > Date: Wed, 18 Aug 2021 21:45:33 -0600
> > > > >
> > > > > Bootmethod and bootflow provide a built-in way for U-Boot to
> > > > > automatically boot
> > > > > an Operating System without custom scripting and other customisation:
> > > > >
> > > > > - bootmethod - a method to scan a device to find bootflows (owned
> > > > > by U-Boot)
> > > > > - bootflow - a description of how to boot (owned by the distro)
> > > > >
> > > > > This series provides an initial implementation of these, enable to
> > > > > scan
> > > > > for bootflows from MMC and Ethernet. The only bootflow supported is
> > > > > distro boot, i.e. an extlinux.conf file included on a filesystem or
> > > > > tftp server. It works similiarly to the existing script-based
> > > > > approach,
> > > > > but is native to U-Boot.
> > > > >
> > > > > With this we can boot on a Raspberry Pi 3 with just one command:
> > > > >
> > > > >bootflow scan -lb
> > > > >
> > > > > which means to scan, listing (-l) each bootflow and trying to boot
> > > > > each
> > > > > one (-b). The final patch shows this.
> > > > >
> > > > > It is intended that this approach be expanded to support mechanisms
> > > > > other
> > > > > than distro boot, including EFI-related ones. With a standard way to
> > > > > identify boot devices, these features become easier. It also should
> > > > > support U-Boot scripts, for backwards compatibility only.
> > > > >
> > > > > The first patch of this series moves boot-related code out of common/
> > > > > and
> > > > > into a new boot/ directory. This helps to collect these related files
> > > > > in one place, as common/ is quite large.
> > > > >
> > > > > Like sysboot, this feature makes use of the existing PXE
> > > > > implementation.
> > > > > Much of this series consists of cleaning up that code and refactoring
> > > > > it
> > > > > into something closer to a module that can be called, teasing apart
> > > > > its
> > > > > reliance on the command-line interpreter to access filesystems and the
> > > > > like. Also it now uses function arguments and its own context struct
> > > > > internally rather than environment variables, which is very hard to
> > > > > follow. No core functional change is included in the included PXE
> > > > > patches.
> > > > >
> > > > > For documentation, see the 'doc' patch.
> > > > >
> > > > > There is quite a long list of future work included in the
> > > > > documentation.
> > > > > One question is the choice of naming. Since this is a bootloader,
> > > > > should
> > > > > we just call this a 'method' and a 'flow' ? The 'boot' prefix is
> > > > > already
> > > > > shared by other commands like bootm, booti, etc.
> > > > >
> > > > > The design is described here:
> > > > >
> > > > > https://drive.google.com/file/d/1ggW0KJpUOR__vBkj3l61L2dav4ZkNC12/view?usp=sharing
> > > > >
> > > > > The series is available at u-boot-dm/bmea-working
> > > >
> > > > How does the user control the order in which devices are scanned/booted?
> > >
> > > That is not supported in distroboot at present, at least so far as I
> > > can see. For Fedora it seems to happen in grub. Do I have that right?
> >
> > Well, there's "find the next stage", which is boot_targets environment
> > variable, and then "where that next stage looks for stuff" which is
> > OS-dependent. Sometimes the ESP grub.cfg file is just enough to tell
> > grub to find the full grub.cfg file elsewhere, and sometimes it's a full
> > grub.cfg file. I think Mark is talking about the former, and you've
> > said it's not part of this series, yet, but on the TODO list.
>
> Right. With the current distroboot code the order of the devices that
> appears in boot_targets is determined by per-board/SOC/machine config
> files and the order isn't the same for all of them. Users can change
> the order if necessary by modifying the environment variable and
> saving the environment. And for a one-off boot from a different
> device they can simply run an appropriate boot command. The
> boot_targets variable in particular is documented in various install
> documents so it would probably be good of the new "bootmethod" code
> would respect this variable.
>
> For OpenBSD I'm not really interested in the bootflow part. As I
> explained in the past, that part of the problem is solved in a
> (mostly) uniform way across platforms by the OpenBSD bootloader which
> can read an /etc/boot.conf that allows bootflow customization. So as
> long as the default of the new code still results in
> \EFI\BOOT\BOOT{machine type short-name}.EFI being loaded and run if
> there is no U-Boot specific bootflow configured, I'm happy.
Mostly the same f
Re: [PATCH v2 0/6] Call phy_config at port probe time for the Felix DSA driver
On Tue, Aug 24, 2021 at 03:00:37PM +0300, Vladimir Oltean wrote: > Changes in v2: > Rebased on top of the master branch (solves this conflict: > https://patchwork.ozlabs.org/project/uboot/patch/20210629170839.2583797-4-olte...@gmail.com/ > with Tim Harvey's patch to make DSA masters promiscuous) > > This series makes the Felix DSA driver initialize all its connected PHYs > regardless of whether those will be used for networking or not. This is > in order to satisfy the expectations of some software in later boot > stages. > > To make this work, it is necessary to introduce a new method in struct > dsa_ops: .port_probe(). > > There is some further refactoring/cleanup along the way. > > Vladimir Oltean (6): > net: dsa: felix: felix_init() can be static > net: dsa: use "err" instead of "ret" in dsa_port_probe > net: dsa: refactor the code to set the port MAC address into a > dedicated function > net: dsa: introduce a .port_probe() method in struct dsa_ops > net: dsa: felix: call phy_config at .port_probe() time > net: dsa: felix: propagate the error code from phy_startup() > > drivers/net/mscc_eswitch/felix_switch.c | 28 ++- > include/net/dsa.h | 5 +- > net/dsa-uclass.c| 62 +++-- > 3 files changed, 59 insertions(+), 36 deletions(-) > > -- > 2.25.1 > It would be nice if these patches could go in through the networking tree, I would like to send one more DM_DSA driver and it also needs the new "port_probe" method introduced by this change set. Thanks.
Pull request: SoCFPGA changes for efi-2021-10-rc3
Hi Tom
Please pull the SoCFPGA changes for efi-2021-10-rc3.
Regards
Tien Fong
The following changes since commit 4865db07169126ca0205f1a6265adf01bd69b3df:
Merge tag 'efi-2021-10-rc3' of
https://source.denx.de/u-boot/custodians/u-boot-efi (2021-08-23 12:44:12 -0400)
are available in the Git repository at:
https://github.com/tienfong/uboot_mainline.git next-socfpga
for you to fetch changes up to 31b51cb1d2b4114085cb5565502d39d6f6daa2a7:
arm: socfpga: Enable Intel N5X device build (2021-08-25 15:26:38 +0800)
Siew Chin Lim (14):
arm: socfpga: Move linux_qspi_enable from bootcommand to board_prep_linux
function
arm: socfpga: Changed base_addr_s10.h to base_addr_soc64.h
arm: socfpga: Add base address for Intel N5X device
drivers: clk: Add clock driver for Intel N5X device
arm: socfpga: Get clock manager base address for Intel N5X device
drivers: clk: Add memory clock driver for Intel N5X device
arm: socfpga: Move cm_get_mpu_clk_hz function declaration to
clock_manager.h
arm: socfpga: Add clock manager for Intel N5X device
arm: socfpga: Changed misc_s10.c to misc_soc64.c
arm: socfpga: Add SPL for Intel N5X device
board: intel: Add socdk board support for Intel N5X device
arm: dts: Add base dtsi and devkit dts for Intel N5X device
include: configs: Add Intel N5X device CONFIGs
arm: socfpga: Enable Intel N5X device build
Tien Fong Chee (3):
arm: socfpga: Add handoff data support for Intel N5X device
ddr: socfpga: Enable memory test on memory size less than 1GB
ddr: altera: Add SDRAM driver for Intel N5X device
arch/arm/dts/Makefile |
1 +
arch/arm/dts/socfpga_n5x-u-boot.dtsi |
191 +
arch/arm/dts/socfpga_n5x_socdk-u-boot.dtsi|
63 ++
arch/arm/dts/socfpga_n5x_socdk.dts|
122 +++
arch/arm/mach-socfpga/Kconfig |
21 +-
arch/arm/mach-socfpga/Makefile|
32 ++-
arch/arm/mach-socfpga/board.c |
17 +-
arch/arm/mach-socfpga/clock_manager_n5x.c |
80 +++
arch/arm/mach-socfpga/include/mach/{base_addr_s10.h => base_addr_soc64.h} |
11 +-
arch/arm/mach-socfpga/include/mach/clock_manager.h|
3 +
arch/arm/mach-socfpga/include/mach/clock_manager_agilex.h |
2 -
arch/arm/mach-socfpga/include/mach/clock_manager_arria10.h|
1 -
arch/arm/mach-socfpga/include/mach/clock_manager_gen5.h |
1 -
arch/arm/mach-socfpga/include/mach/clock_manager_n5x.h|
12 ++
arch/arm/mach-socfpga/include/mach/clock_manager_s10.h|
1 -
arch/arm/mach-socfpga/include/mach/firewall.h |
6 +
arch/arm/mach-socfpga/include/mach/handoff_soc64.h|
38 +++-
arch/arm/mach-socfpga/include/mach/system_manager_soc64.h |
10 +-
arch/arm/mach-socfpga/misc.c |
3 +
arch/arm/mach-socfpga/{misc_s10.c => misc_soc64.c}|
12 +-
arch/arm/mach-socfpga/spl_n5x.c |
94 +
arch/arm/mach-socfpga/system_manager_soc64.c |
18 +-
arch/arm/mach-socfpga/wrap_handoff_soc64.c|
132 +---
board/intel/n5x-socdk/MAINTAINERS |
7 +
board/intel/n5x-socdk/Makefile|
7 +
board/intel/n5x-socdk/socfpga.c |
7 +
configs/socfpga_agilex_atf_defconfig |
2 +-
configs/socfpga_n5x_atf_defconfig |
74 +++
configs/socfpga_n5x_defconfig |
65 ++
configs/socfpga_n5x_vab_defconfig |
75 +++
configs/socfpga_stratix10_atf_defconfig |
2 +-
drivers/clk/altera/Makefile |
4 +-
drivers/clk/altera/clk-mem-n5x.c |
136
drivers/clk/altera/clk-mem-n5x.h |
84
drivers/clk/altera/clk-n5x.c |
489 ++
drivers/clk/altera/clk-n5x.h |
217 +++
drivers/ddr/altera/Makefile |
3 +-
drivers/ddr
Re: Pull request for efi-2021-10-rc2-2
+U-Boot Mailing List which I seemed to drop, sorry On Tue, 24 Aug 2021 at 10:19, Simon Glass wrote: > > Hi Ilias, > > On Tue, 24 Aug 2021 at 00:05, Ilias Apalodimas > wrote: > > > > > > > > >> > > > > [...] > > > > > > > > >> I don't think we should wait any longer for this as we are > > > > > > >> already at rc2. > > > > > > >> > > > > > > >> I'd like to see my revert patches (or something similar) applied > > > > > > >> ASAP > > > > > > >> please. We can then figure out a better solution. > > > > > > > > > > > > > > Heinrich feel free to revert those, but keep in mind that will > > > > > > > break > > > > > > > authenticated capsules for anything apart from qemu (and also > > > > > > > U-Boot > > > > > > > compilation if that feature is selected). We'll also have to > > > > > > > carry the > > > > > > > mkeficapsule code, until we document Akashi's changes for > > > > > > > injecting the key > > > > > > > in the dtb, without using that application. > > > > > > > > > > > > > > Alternatively we could just put the key in an authenticated > > > > > > > variable > > > > > > > (perhaps with it's own GUID?). I'll go back and check EDK2, but > > > > > > > I think > > > > > > > that's what they've implemented. > > > > > > > > > > > > > > Regards > > > > > > > /Ilias > > > > > > > > > > > > Simon, > > > > > > > > > > > > as Ilias pointed out you series "efi: Minimal revert to rodata > > > > > > change " > > > > > > https://patchwork.ozlabs.org/project/uboot/list/?series=256272 is > > > > > > breaking capsule updates on non-QEMU boards. > > > > > > > > > > Isn't that what was just implemented? I am happy for you to apply a > > > > > different revert. I was just responding to what Ilias said needed to > > > > > be reverted. > > > > > > > > > > > > > > > > > Furthermove your proposal does not work securitywise: The fdt > > > > > > command is > > > > > > needed to apply overlays and cannot be removed from all boards using > > > > > > capsule updates. Putting validation keys into the fdt would require > > > > > > to > > > > > > disable that the fdt command can change the capsule verification > > > > > > key. > > > > > > > > > > That is one of the many points Ilias and I discussed in the call. > > > > > There are many solutions to that and many other problems to solve > > > > > (e.g. the mw command and adding memory protection). These issues are > > > > > not going to be solved immediately, particularly on a very new > > > > > feature. > > > > > > > > > > > > > > > > > So it seems you series is not in a state for being merged. > > > > > > > > > > A revert takes us back to where we were so that the path forward can > > > > > be determined. A revert does not, by its nature, reimplement a > > > > > feature. It is a revert. > > > > > > > > > > Please can you accept the revert or tell me what you will accept, or > > > > > come up with another plan to revert this. This is taking far too much > > > > > energy and, as I said, should never have happened if proper processes > > > > > were followed. > > > > > > > > > > > > > Please stop trying to create false impressions. On the initial revert > > > > you > > > > sent, you said something along the lines of "this patch was applied in > > > > spite of my objections" and I responded the same thing back then. > > > > > > > > The patch was merged on v2, after it has been reviewed on the mailing > > > > list. It > > > > wasn't sneaked in, or whatever you are trying to imply here. Despite > > > > the > > > > fact that I *still* think it's far better than the proposed > > > > alternatives, I > > > > am very willing to discuss it. What really happened is that you noticed > > > > the patch *after* the PR from Heinrich was merged. The patch was > > > > reviewed, > > > > it has documentation on how to use it and it was tested on 3 different > > > > platforms. So I am failing to see the "proper processes" you keep > > > > repeating. > > > > > > I am referring to: > > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20210717142648.26588-1-ilias.apalodi...@linaro.org/ > > > > > > There is no indication that it was applied. In fact our discussion > > > apparently continued long after it was applied. I don't think even you > > > were aware? > > > > I think I am pretty much aware of what I respond to emails. I am also aware > > of the dates and things I am pointing out. > > > > The patches were merged here: > > https://lore.kernel.org/u-boot/f55c615b-6f94-2828-3e5e-5a7cfaaab...@gmx.de/ > > and you responded 2 days after the merge. I even pointed out the fact in > > IRC and email, but you kept ignoring it. > > This does not match with my understanding, which perhaps explains part > of the disconnect. Let me explain how I saw it: > > That is a pull request, not an 'Applied to EFI' response to the patch, > which is the normal procedure. The pull request was not even copied to > me, so I'm not sure how I should have known, even if I did have time > to dig through i
Re: Pull request for efi-2021-10-rc2-2
+U-Boot Mailing List (sorry for somehow dropping it) On Wed, 25 Aug 2021 at 03:23, Ilias Apalodimas wrote: > > Hi Simon, > > [...] > > > > > > > > > > > Please stop trying to create false impressions. On the initial revert > > > > > you > > > > > sent, you said something along the lines of "this patch was applied in > > > > > spite of my objections" and I responded the same thing back then. > > > > > > > > > > The patch was merged on v2, after it has been reviewed on the mailing > > > > > list. It > > > > > wasn't sneaked in, or whatever you are trying to imply here. Despite > > > > > the > > > > > fact that I *still* think it's far better than the proposed > > > > > alternatives, I > > > > > am very willing to discuss it. What really happened is that you > > > > > noticed > > > > > the patch *after* the PR from Heinrich was merged. The patch was > > > > > reviewed, > > > > > it has documentation on how to use it and it was tested on 3 different > > > > > platforms. So I am failing to see the "proper processes" you keep > > > > > repeating. > > > > > > > > I am referring to: > > > > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20210717142648.26588-1-ilias.apalodi...@linaro.org/ > > > > > > > > There is no indication that it was applied. In fact our discussion > > > > apparently continued long after it was applied. I don't think even you > > > > were aware? > > > > > > I think I am pretty much aware of what I respond to emails. I am also > > > aware > > > of the dates and things I am pointing out. > > > > > > The patches were merged here: > > > https://lore.kernel.org/u-boot/f55c615b-6f94-2828-3e5e-5a7cfaaab...@gmx.de/ > > > and you responded 2 days after the merge. I even pointed out the fact in > > > IRC and email, but you kept ignoring it. > > > > This does not match with my understanding, which perhaps explains part > > of the disconnect. Let me explain how I saw it: > > > > That is a pull request, not an 'Applied to EFI' response to the patch, > > which is the normal procedure. The pull request was not even copied to > > me, so I'm not sure how I should have known, even if I did have time > > to dig through it and look for patches still under discussion I had no > > idea this had been merged and that should be obvious from the fact > > that you had to tell me a week later. > > > > If you really want to dig in, the original patch was here: > > https://patchwork.ozlabs.org/project/uboot/patch/20210715170030.97758-1-ilias.apalodi...@linaro.org/ > > > > I queried your comment about the fdt command and got a partial > > response from you which did not address my question properly. Before I > > had time to follow up, a v2 patch was sent on the 17th. Apparently it > > was applied the next day without the 'Applied to' response. Presumably > > Heinrich did not know at this point that there was an open question. I > > found the v2 patch on the 20th and asked my question again, not > > knowing it was applied. > > > > So can we put that point to bed? > > As long as you understand this wasn't some effort to merge something you > objected to, sure. I'm not suggesting that, just that it was done too soon. > > > > > > > > > > > > > > Look I'm sorry if this all seems a bit much. My initial request was > > > > rebuffed, other emails have been ignored and a large number of > > > > objections have been raised. It's just too hard. As far as I can > > > > remember, I've not come across anything like this in my time > > > > contributing to U-Boot. > > > > > > That's because putting in the DTB makes no sense whatsoever. On the > > > contrary due to the different options of the control DTB origin, it > > > overcomplicates the security of the key. > > > > I think you imagine that the DTB needs to be created in another > > project and then not modified through the build system. But that is > > not the intent. > > But it might as well be a reality, with TF-A. Of course there are always exceptions. > > > The DTB is created from source but then other things > > can be added to it. For example, mkimage adds a public key and so did > > the EFI implementation until your patch series. > > Not exactly. You had to configure U-Boot with OF_SEPARATE, fixup the dtb > manually with mkeficapsule application (which is what Akashi proposed to > revert) and the concatenate u-boot-nodtb.bin and the edited dtb Well of course if the DT holds the key and you want to add the key after the build, you have to modify the DT. You make it sounds like a huge deal... OF_SEPARATE is required, actually. We try to use OF_EMBED just for testing and development. If mkeficapsule is how you want to write to the DT, that is fine. You could also add support for this to binman, which might be easier to maintain. Concatenating is handled by binman. > > > That is easy to do > > with a DTB but of course a real pain to do with an executable binary. > > > > What really complicates things is building the key into the source > > code of
Re: [PATCH 00/28] Initial implementation of bootmethod/bootflow
Hi, On Wed, 25 Aug 2021 at 04:45, Emmanuel Vadot wrote: > > On Tue, 24 Aug 2021 12:22:42 +0200 (CEST) > Mark Kettenis wrote: > > > > Date: Mon, 23 Aug 2021 16:01:46 -0400 > > > From: Tom Rini > > > > > > On Mon, Aug 23, 2021 at 11:25:42AM -0600, Simon Glass wrote: > > > > Hi Mark, > > > > > > > > On Mon, 23 Aug 2021 at 05:54, Mark Kettenis > > > > wrote: > > > > > > > > > > > From: Simon Glass > > > > > > Date: Wed, 18 Aug 2021 21:45:33 -0600 > > > > > > > > > > > > Bootmethod and bootflow provide a built-in way for U-Boot to > > > > > > automatically boot > > > > > > an Operating System without custom scripting and other > > > > > > customisation: > > > > > > > > > > > > - bootmethod - a method to scan a device to find bootflows (owned > > > > > > by U-Boot) > > > > > > - bootflow - a description of how to boot (owned by the distro) > > > > > > > > > > > > This series provides an initial implementation of these, enable to > > > > > > scan > > > > > > for bootflows from MMC and Ethernet. The only bootflow supported is > > > > > > distro boot, i.e. an extlinux.conf file included on a filesystem or > > > > > > tftp server. It works similiarly to the existing script-based > > > > > > approach, > > > > > > but is native to U-Boot. > > > > > > > > > > > > With this we can boot on a Raspberry Pi 3 with just one command: > > > > > > > > > > > >bootflow scan -lb > > > > > > > > > > > > which means to scan, listing (-l) each bootflow and trying to boot > > > > > > each > > > > > > one (-b). The final patch shows this. > > > > > > > > > > > > It is intended that this approach be expanded to support mechanisms > > > > > > other > > > > > > than distro boot, including EFI-related ones. With a standard way to > > > > > > identify boot devices, these features become easier. It also should > > > > > > support U-Boot scripts, for backwards compatibility only. > > > > > > > > > > > > The first patch of this series moves boot-related code out of > > > > > > common/ and > > > > > > into a new boot/ directory. This helps to collect these related > > > > > > files > > > > > > in one place, as common/ is quite large. > > > > > > > > > > > > Like sysboot, this feature makes use of the existing PXE > > > > > > implementation. > > > > > > Much of this series consists of cleaning up that code and > > > > > > refactoring it > > > > > > into something closer to a module that can be called, teasing apart > > > > > > its > > > > > > reliance on the command-line interpreter to access filesystems and > > > > > > the > > > > > > like. Also it now uses function arguments and its own context struct > > > > > > internally rather than environment variables, which is very hard to > > > > > > follow. No core functional change is included in the included PXE > > > > > > patches. > > > > > > > > > > > > For documentation, see the 'doc' patch. > > > > > > > > > > > > There is quite a long list of future work included in the > > > > > > documentation. > > > > > > One question is the choice of naming. Since this is a bootloader, > > > > > > should > > > > > > we just call this a 'method' and a 'flow' ? The 'boot' prefix is > > > > > > already > > > > > > shared by other commands like bootm, booti, etc. > > > > > > > > > > > > The design is described here: > > > > > > > > > > > > https://drive.google.com/file/d/1ggW0KJpUOR__vBkj3l61L2dav4ZkNC12/view?usp=sharing > > > > > > > > > > > > The series is available at u-boot-dm/bmea-working > > > > > > > > > > How does the user control the order in which devices are > > > > > scanned/booted? > > > > > > > > That is not supported in distroboot at present, at least so far as I > > > > can see. For Fedora it seems to happen in grub. Do I have that right? > > > > > > Well, there's "find the next stage", which is boot_targets environment > > > variable, and then "where that next stage looks for stuff" which is > > > OS-dependent. Sometimes the ESP grub.cfg file is just enough to tell > > > grub to find the full grub.cfg file elsewhere, and sometimes it's a full > > > grub.cfg file. I think Mark is talking about the former, and you've > > > said it's not part of this series, yet, but on the TODO list. > > > > Right. With the current distroboot code the order of the devices that > > appears in boot_targets is determined by per-board/SOC/machine config > > files and the order isn't the same for all of them. Users can change > > the order if necessary by modifying the environment variable and > > saving the environment. And for a one-off boot from a different > > device they can simply run an appropriate boot command. The > > boot_targets variable in particular is documented in various install > > documents so it would probably be good of the new "bootmethod" code > > would respect this variable. > > > > For OpenBSD I'm not really interested in the bootflow part. As I > > explained in the past, that part of the problem is solved in a > > (mostly) uniform way across platforms b
Re: [PATCH 00/28] Initial implementation of bootmethod/bootflow
Hi Ilias, On Tue, 24 Aug 2021 at 03:30, Ilias Apalodimas wrote: > > Hi Tom, > > > > > > > > > > > [...] > > > > > > > > > The series is available at u-boot-dm/bmea-working > > > > > > > > > > > > > > My question / concern is this. Would the next step here be to > > > > > > > implement the generic UEFI boot path? Today, I can write Fedora > > > > > > > 34 for > > > > > > > AArch64 to a USB stick, boot U-Boot off of uSD card and the > > > > > > > installer > > > > > > > automatically boots. I'm sure I could do the same with the BSDs. > > > > > > > Reading the documentation left me with the impression that every > > > > > > > OSV > > > > > > > would be expected to write something, so that their installer / > > > > > > > OS boot. > > > > > > > But there's already standards for that, which they do, and we > > > > > > > should be > > > > > > > implementing (and do, via the current distro_boot) or making > > > > > > > easier to > > > > > > > enable. Thanks! > > > > > > > > > > > > Here you are talking about scanning for a bootflow. It is not > > > > > > actually > > > > > > OS-specific. If it were, there would be no point to this :-) > > > > > > > > > > > > If you look in the distro scripts you will see 'scan_dev_for_efi' > > > > > > (and > > > > > > also scan_dev_for_scrips). At least the first needs to be > > > > > > implemented > > > > > > a bit like the distro boot is at present. So far I have only > > > > > > implemented scan_dev_for_extlinux (plus pxe) as it is enough to show > > > > > > the concept. > > > > > > > > > > > > Adding EFI it's likely to be about the same amount of code as > > > > > > distro.c > > > > > > at present, perhaps a little less since we don't have the network > > > > > > case. It is used by Fedora 34, I believe, so is easy enough for me > > > > > > to > > > > > > do. But I wanted to get something out as the concept is visible in > > > > > > this series. > > > > > > > > > > OK, good. I'd certainly like to see how this looks with EFI added. > > > > > > > > > > > > > What would be the order preference after scanning? > > > > > > (from other thread) > > > With distro boot this is done with an environment variable, as I > > > understand it. That is not implemented in this series, but is easy to > > > do and is in the TODO. For now it can only be done with aliases to set > > > the order of the bootmethods and that requires adding to the DT, so I > > > don't think it scales well. I'm open to ideas though. > > > > > > > > > > > Keep in mind that our efibootmgr is pretty complete wrt to booting. > > > > It can even support booting multiple OS'es without GRUB2 (even loading > > > > different initrds is supported). Ideally (and assuming we want to > > > > support > > > > EFI booting for more devices), I would map existing extlinux configs > > > > into > > > > efibootmgr entries. > > > > > > Yes I understand. I believe distro boot supports multiple OSes too, > > > but perhaps only on different media? I'm not sure. Anywayt ere are > > > always going to be people who don't want or need to use EFI (or grub) > > > > Well, here's where I'm a bit curious. I have seen at least twice "wait, > > EFI stub in the linux kernel adds how much?" type commentary. I don't > > know how prevalent that type of concern will really be given just how > > often I don't see the Linux kernel config shrunk down from what the > > reference platform started with. And as Ilias is pointing out, you can > > do _a_lot_ with efibootmgr and without grub/whatever. And both Arm (the > > company) and RISC-V (the overarching organization) are both pushing to > > standardize around the idea that if you're on something bigger than an > > MCU, EFI-the-ABI should get you up and running. > > Exactly. Keep in mind that RISC-V is looking into EBBR as well, so this is > far from an 'Arm thing'. Moreover, the efi stub side of the kernel for > risc-v, will only load an initrd using the EFI_LOAD_FILE2 protocol we added > support for. So right now the only way to properly boot a RISC-V with EFI is > through the manager. I had heard that RISC-V was just going to use UEFI (and not U-Boot), but perhaps that is not correct. So far I have not really done anything with RISC-V so am not familiar with it. Regards, Simon
[PATCH v1] driver: spi: add bcm iproc qspi support.
From: Rayagonda Kokatanur IPROC qspi driver supports both BSPI and MSPI modes. Signed-off-by: Rayagonda Kokatanur Signed-off-by: Bharat Gooty --- drivers/spi/Kconfig | 6 + drivers/spi/Makefile | 1 + drivers/spi/iproc_qspi.c | 736 +++ drivers/spi/iproc_qspi.h | 18 + 4 files changed, 761 insertions(+) create mode 100644 drivers/spi/iproc_qspi.c create mode 100644 drivers/spi/iproc_qspi.h diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig index e12699bec7..3253d6badf 100644 --- a/drivers/spi/Kconfig +++ b/drivers/spi/Kconfig @@ -178,6 +178,12 @@ config ICH_SPI access the SPI NOR flash on platforms embedding this Intel ICH IP core. +config IPROC_QSPI + bool "QSPI driver for BCM iProc QSPI Controller" + help + This selects the BCM iProc QSPI controller. + This driver support spi flash single, quad and memory reads. + config KIRKWOOD_SPI bool "Marvell Kirkwood SPI Driver" help diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile index d2f24bccef..8697631870 100644 --- a/drivers/spi/Makefile +++ b/drivers/spi/Makefile @@ -33,6 +33,7 @@ obj-$(CONFIG_FSL_DSPI) += fsl_dspi.o obj-$(CONFIG_FSL_ESPI) += fsl_espi.o obj-$(CONFIG_SYNQUACER_SPI) += spi-synquacer.o obj-$(CONFIG_ICH_SPI) += ich.o +obj-$(CONFIG_IPROC_QSPI) += iproc_qspi.o obj-$(CONFIG_KIRKWOOD_SPI) += kirkwood_spi.o obj-$(CONFIG_MESON_SPIFC) += meson_spifc.o obj-$(CONFIG_MPC8XX_SPI) += mpc8xx_spi.o diff --git a/drivers/spi/iproc_qspi.c b/drivers/spi/iproc_qspi.c new file mode 100644 index 00..89c6a56858 --- /dev/null +++ b/drivers/spi/iproc_qspi.c @@ -0,0 +1,736 @@ +// SPDX-License-Identifier: GPL-2.0+ +/* + * Copyright 2020-2021 Broadcom + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include "iproc_qspi.h" + +/* 175MHz */ +#define QSPI_AXI_CLK 17500 +#define QSPI_DEF_SCK_FREQ 5000 +#define QSPI_WAIT_TIMEOUT_MS 200U +#define DWORD_ALIGNED(a) (!(((ulong)(a)) & 3)) + +/* Chip attributes */ +#define SPBR_MIN 8U +#define SPBR_MAX 255U +#define NUM_CDRAM 16U + +#define CDRAM_PCS0 2 +#define CDRAM_CONT BIT(7) +#define CDRAM_BITS_EN BIT(6) +#define CDRAM_QUAD_MODEBIT(8) +#define CDRAM_RBIT_INPUT BIT(10) +#define MSPI_SPE BIT(6) +#define MSPI_CONT_AFTER_CMDBIT(7) + +/* Register fields */ +#define MSPI_SPCR0_MSB_BITS_8 0x0020 +#define BSPI_RAF_CONTROL_START_MASK0x0001 +#define BSPI_RAF_STATUS_SESSION_BUSY_MASK 0x0001 +#define BSPI_RAF_STATUS_FIFO_EMPTY_MASK0x0002 +#define BSPI_BITS_PER_PHASE_ADDR_MARK 0x0001 +#define BSPI_BITS_PER_CYCLE_DATA_SHIFT 0 +#define BSPI_BITS_PER_CYCLE_ADDR_SHIFT 16 +#define BSPI_STRAP_OVERRIDE_DATA_QUAD_SHIFT3 +#define BSPI_STRAP_OVERRIDE_DATA_DUAL_SHIFT1 +#define BSPI_STRAP_OVERRIDE_SHIFT 0 + +/* MSPI registers */ +#define MSPI_SPCR0_LSB_REG 0x000 +#define MSPI_SPCR0_MSB_REG 0x004 +#define MSPI_SPCR1_LSB_REG 0x008 +#define MSPI_SPCR1_MSB_REG 0x00c +#define MSPI_NEWQP_REG 0x010 +#define MSPI_ENDQP_REG 0x014 +#define MSPI_SPCR2_REG 0x018 +#define MSPI_STATUS_REG0x020 +#define MSPI_CPTQP_REG 0x024 +#define MSPI_TXRAM_REG 0x040 +#define MSPI_RXRAM_REG 0x0c0 +#define MSPI_CDRAM_REG 0x140 +#define MSPI_WRITE_LOCK_REG0x180 +#define MSPI_DISABLE_FLUSH_GEN_REG 0x184 + +/* BSPI registers */ +#define BSPI_REVISION_ID_REG 0x000 +#define BSPI_SCRATCH_REG 0x004 +#define BSPI_MAST_N_BOOT_CTRL_REG 0x008 +#define BSPI_BUSY_STATUS_REG 0x00c +#define BSPI_INTR_STATUS_REG 0x010 +#define BSPI_B0_STATUS_REG 0x014 +#define BSPI_B0_CTRL_REG 0x018 +#define BSPI_B1_STATUS_REG 0x01c +#define BSPI_B1_CTRL_REG 0x020 +#define BSPI_STRAP_OVERRIDE_CTRL_REG 0x024 +#define BSPI_FLEX_MODE_ENABLE_REG 0x028 +#define BSPI_BITS_PER_CYCLE_REG0x02C +#define BSPI_BITS_PER_PHASE_REG0x030 +#define BSPI_CMD_AND_MODE_BYTE_REG 0x034 +#define BSPI_FLASH_UPPER_ADDR_BYTE_REG 0x038 +#define BSPI_XOR_VALUE_REG 0x03C +#define BSPI_XO
Re: [PATCH 00/28] Initial implementation of bootmethod/bootflow
> > Exactly. Keep in mind that RISC-V is looking into EBBR as well, so this is > > far from an 'Arm thing'. Moreover, the efi stub side of the kernel for > > risc-v, will only load an initrd using the EFI_LOAD_FILE2 protocol we added > > support for. So right now the only way to properly boot a RISC-V with EFI is > > through the manager. > > I had heard that RISC-V was just going to use UEFI (and not U-Boot), > but perhaps that is not correct. So far I have not really done > anything with RISC-V so am not familiar with it. My understanding is the intention is to just use UEFI of which U-Boot has a UEFI implementation.
[PATCH] board: ea: mx7ulp_com: allocate specific region of memory to OP-TEE
From: Ricardo Salveti
On the iMX7ULP uCOM board, OP-TEE uses the memory region defined by the
maximum DRAM address minus CONFIG_OPTEE_TZDRAM_SIZE, so subtract
CONFIG_OPTEE_TZDRAM_SIZE from the available DRAM size to avoid
conflicts.
Note the OPTEE boot process itself subtracts the DRAM region it
lives in from the memory map passed to Linux.
Signed-off-by: Ricardo Salveti
---
board/ea/mx7ulp_com/mx7ulp_com.c | 4
1 file changed, 4 insertions(+)
diff --git a/board/ea/mx7ulp_com/mx7ulp_com.c b/board/ea/mx7ulp_com/mx7ulp_com.c
index 5b2d444366..7fce75ade9 100644
--- a/board/ea/mx7ulp_com/mx7ulp_com.c
+++ b/board/ea/mx7ulp_com/mx7ulp_com.c
@@ -20,6 +20,10 @@ int dram_init(void)
{
gd->ram_size = imx_ddr_size();
+#ifdef CONFIG_OPTEE_TZDRAM_SIZE
+ gd->ram_size -= CONFIG_OPTEE_TZDRAM_SIZE;
+#endif
+
return 0;
}
--
2.31.1
[PATCH] board: ea: mx7ulp_com: allow setting CONFIG_BOOTCOMMAND in defconfig
From: Ricardo Salveti
Allow replacing the board defined CONFIG_BOOTCOMMAND via defconfig.
Signed-off-by: Ricardo Salveti
Signed-off-by: Oleksandr Suvorov
---
include/configs/mx7ulp_com.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/configs/mx7ulp_com.h b/include/configs/mx7ulp_com.h
index 28672c4f94..85ae513ffb 100644
--- a/include/configs/mx7ulp_com.h
+++ b/include/configs/mx7ulp_com.h
@@ -69,10 +69,12 @@
"bootz ${loadaddr} - ${fdt_addr}; " \
"fi;\0" \
+#ifndef CONFIG_BOOTCOMMAND
#define CONFIG_BOOTCOMMAND \
"if run loadimage; then " \
"run mmcboot; " \
"fi; " \
+#endif
#define CONFIG_SYS_LOAD_ADDR CONFIG_LOADADDR
--
2.31.1
[PATCH u-boot-marvell 02/29] tools: kwboot: Fix buffer overflow in kwboot_terminal()
The `in` variable is set to -1 in kwboot_terminal() if stdin is not a
tty. In this case we should not look whether -1 is set in fd_set, for it
can lead to a buffer overflow, which can be reproduced with
echo "xyz" | ./tools/kwboot -t /dev/ttyUSB0
Signed-off-by: Marek Behún
---
tools/kwboot.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/kwboot.c b/tools/kwboot.c
index 7feeaa45a2..e6e99849a7 100644
--- a/tools/kwboot.c
+++ b/tools/kwboot.c
@@ -552,7 +552,7 @@ kwboot_terminal(int tty)
break;
}
- if (FD_ISSET(in, &rfds)) {
+ if (in >= 0 && FD_ISSET(in, &rfds)) {
rc = kwboot_term_pipe(in, tty, quit, &s);
if (rc)
break;
--
2.31.1
[PATCH u-boot-marvell 00/29] kwboot higher baudrate
Hello Stefan and others, this series adds support for booting Marvell platforms via UART (those bootable with kwboot) at higher baudrates. Tested on Turris Omnia up to 5.15 MBd, which is 44x faster than 115200 Bd. The user can direct kwboot to use higher baudrate via the -B option. (BTW this option was there before but did not work with the -b option.) Only the payload part of the KWB image is uploaded at this higher baudrate. The header part is still uploaded at 115200 Bd, since the code that changes baudrate is injected into header as a binary extension. (The payload part makes up majority of the binary, though. On Turris Omnia the payload currently makes ~87%.) The series also contains various other fixes, refactors and improvements of the code, upon which the main change is done. Marek & Pali Marek Behún (13): tools: kwbimage: Fix printf format warning tools: kwboot: Fix buffer overflow in kwboot_terminal() tools: kwboot: Make the quit sequence buffer const tools: kwboot: Refactor and fix writing buffer tools: kwboot: Fix comparison of integers with different size tools: kwboot: Use a function to check whether received byte is a Xmodem reply tools: kwboot: Print new line after SPL output tools: kwboot: Allow greater timeout when executing header code tools: kwbimage: Simplify iteration over version 1 optional headers tools: kwbimage: Refactor image_version() tools: kwbimage: Refactor kwbimage header size determination doc/kwboot.1: Update man page MAINTAINERS: Add entry for kwbimage / kwboot tools Pali Rohár (16): tools: kwboot: Print version information header tools: kwboot: Fix kwboot_xm_sendblock() function when kwboot_tty_recv() fails tools: kwboot: Fix return type of kwboot_xm_makeblock() function tools: kwboot: Fix printing progress tools: kwboot: Print newline on error when progress was not completed tools: kwboot: Split sending image into header and data stages tools: kwboot: Allow non-xmodem text output from BootROM only in a specific case tools: kwboot: Properly finish xmodem transfer tools: kwboot: Always call kwboot_img_patch_hdr() tools: kwboot: Don't patch image header if signed tools: kwboot: Patch source address in image header tools: kwboot: Patch destination address to DDR area for SPI image tools: kwboot: Round up header size to 128 B when patching tools: kwboot: Support higher baudrates when booting via UART tools: kwboot: Allow any baudrate on Linux tools: kwboot: Add Pali and Marek as authors MAINTAINERS | 10 + doc/kwboot.1 | 58 ++- tools/kwbimage.c | 127 ++--- tools/kwbimage.h | 93 +++- tools/kwboot.c| 1103 +++-- tools/termios_linux.h | 170 +++ 6 files changed, 1289 insertions(+), 272 deletions(-) create mode 100644 tools/termios_linux.h -- 2.31.1
[PATCH u-boot-marvell 01/29] tools: kwbimage: Fix printf format warning
On 32-bit ARM the compiler complains:
tools/kwbimage.c:547: warning: format ‘%lu’ expects argument of type
‘long unsigned int’, but argument 4 has
type ‘unsigned int’
Fix this by using %zu instead of %lu format specifier.
Signed-off-by: Marek Behún
---
tools/kwbimage.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/kwbimage.c b/tools/kwbimage.c
index aa865cc443..ed11c835a5 100644
--- a/tools/kwbimage.c
+++ b/tools/kwbimage.c
@@ -544,7 +544,7 @@ static int kwb_export_pubkey(RSA *key, struct pubkey_der_v1
*dst, FILE *hashf,
}
if (4 + size_seq > sizeof(dst->key)) {
- fprintf(stderr, "export pk failed: seq too large (%d, %lu)\n",
+ fprintf(stderr, "export pk failed: seq too large (%d, %zu)\n",
4 + size_seq, sizeof(dst->key));
fprintf(stderr, errmsg, keyname);
return -ENOBUFS;
--
2.31.1
[PATCH u-boot-marvell 03/29] tools: kwboot: Make the quit sequence buffer const
This buffer is never written to. Make it const.
Signed-off-by: Marek Behún
---
tools/kwboot.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tools/kwboot.c b/tools/kwboot.c
index e6e99849a7..f18f6d2134 100644
--- a/tools/kwboot.c
+++ b/tools/kwboot.c
@@ -460,7 +460,7 @@ can:
}
static int
-kwboot_term_pipe(int in, int out, char *quit, int *s)
+kwboot_term_pipe(int in, int out, const char *quit, int *s)
{
ssize_t nin, nout;
char _buf[128], *buf = _buf;
@@ -504,7 +504,7 @@ static int
kwboot_terminal(int tty)
{
int rc, in, s;
- char *quit = "\34c";
+ const char *quit = "\34c";
struct termios otio, tio;
rc = -1;
--
2.31.1
[PATCH u-boot-marvell 04/29] tools: kwboot: Refactor and fix writing buffer
There are 3 instances in kwboot.c where we need to write() a given
buffer whole (iteratively writing until all data are written), and 2 of
those instances are wrong, for they do not increment the buffer pointer.
Refactor the code into a new function kwboot_write() where it is fixed.
Signed-off-by: Marek Behún
---
tools/kwboot.c | 55 --
1 file changed, 26 insertions(+), 29 deletions(-)
diff --git a/tools/kwboot.c b/tools/kwboot.c
index f18f6d2134..22cdd137ad 100644
--- a/tools/kwboot.c
+++ b/tools/kwboot.c
@@ -72,6 +72,23 @@ static int msg_req_delay = KWBOOT_MSG_REQ_DELAY;
static int msg_rsp_timeo = KWBOOT_MSG_RSP_TIMEO;
static int blk_rsp_timeo = KWBOOT_BLK_RSP_TIMEO;
+static ssize_t
+kwboot_write(int fd, const char *buf, size_t len)
+{
+ size_t tot = 0;
+
+ while (tot < len) {
+ ssize_t wr = write(fd, buf + tot, len - tot);
+
+ if (wr < 0)
+ return -1;
+
+ tot += wr;
+ }
+
+ return tot;
+}
+
static void
kwboot_printv(const char *fmt, ...)
{
@@ -191,26 +208,13 @@ out:
static int
kwboot_tty_send(int fd, const void *buf, size_t len)
{
- int rc;
- ssize_t n;
-
if (!buf)
return 0;
- rc = -1;
-
- do {
- n = write(fd, buf, len);
- if (n < 0)
- goto out;
-
- buf = (char *)buf + n;
- len -= n;
- } while (len > 0);
+ if (kwboot_write(fd, buf, len) < 0)
+ return -1;
- rc = tcdrain(fd);
-out:
- return rc;
+ return tcdrain(fd);
}
static int
@@ -462,7 +466,7 @@ can:
static int
kwboot_term_pipe(int in, int out, const char *quit, int *s)
{
- ssize_t nin, nout;
+ ssize_t nin;
char _buf[128], *buf = _buf;
nin = read(in, buf, sizeof(_buf));
@@ -480,22 +484,15 @@ kwboot_term_pipe(int in, int out, const char *quit, int
*s)
buf++;
nin--;
} else {
- while (*s > 0) {
- nout = write(out, quit, *s);
- if (nout <= 0)
- return -1;
- (*s) -= nout;
- }
+ if (kwboot_write(out, quit, *s) < 0)
+ return -1;
+ *s = 0;
}
}
}
- while (nin > 0) {
- nout = write(out, buf, nin);
- if (nout <= 0)
- return -1;
- nin -= nout;
- }
+ if (kwboot_write(out, buf, nin) < 0)
+ return -1;
return 0;
}
--
2.31.1
[PATCH u-boot-marvell 05/29] tools: kwboot: Print version information header
From: Pali Rohár
Print kwboot's (U-Boot's) version when printing usage.
Signed-off-by: Pali Rohár
Reviewed-by: Marek Behún
---
tools/kwboot.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/tools/kwboot.c b/tools/kwboot.c
index 22cdd137ad..454339db14 100644
--- a/tools/kwboot.c
+++ b/tools/kwboot.c
@@ -11,6 +11,7 @@
#include "kwbimage.h"
#include "mkimage.h"
+#include "version.h"
#include
#include
@@ -681,6 +682,7 @@ out:
static void
kwboot_usage(FILE *stream, char *progname)
{
+ fprintf(stream, "kwboot version %s\n", PLAIN_VERSION);
fprintf(stream,
"Usage: %s [OPTIONS] [-b | -D ] [-B ]
\n",
progname);
--
2.31.1
[PATCH u-boot-marvell 08/29] tools: kwboot: Fix comparison of integers with different size
The compiler complains that we are comparing int with size_t when
compiled with -W.
Signed-off-by: Marek Behún
---
tools/kwboot.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/tools/kwboot.c b/tools/kwboot.c
index 88353d19c0..3d9f73e697 100644
--- a/tools/kwboot.c
+++ b/tools/kwboot.c
@@ -352,8 +352,7 @@ kwboot_xm_makeblock(struct kwboot_block *block, const void
*data,
size_t size, int pnum)
{
const size_t blksz = sizeof(block->data);
- size_t n;
- int i;
+ size_t i, n;
block->soh = SOH;
block->pnum = pnum;
--
2.31.1
[PATCH u-boot-marvell 09/29] tools: kwboot: Fix printing progress
From: Pali Rohár
Ensure that `pos` is still in range up to the `width` so printing 100%
works also for bigger images. After printing 100% progress reset it to
zero, so that next progressbar can be started.
Signed-off-by: Pali Rohár
Reviewed-by: Marek Behún
---
tools/kwboot.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/tools/kwboot.c b/tools/kwboot.c
index 3d9f73e697..eb4b3fe230 100644
--- a/tools/kwboot.c
+++ b/tools/kwboot.c
@@ -140,12 +140,14 @@ __progress(int pct, char c)
fputc(c, stdout);
nl = "]\n";
- pos++;
+ pos = (pos + 1) % width;
if (pct == 100) {
- while (pos++ < width)
+ while (pos && pos++ < width)
fputc(' ', stdout);
fputs(nl, stdout);
+ nl = "";
+ pos = 0;
}
fflush(stdout);
@@ -162,6 +164,9 @@ kwboot_progress(int _pct, char c)
if (kwboot_verbose)
__progress(pct, c);
+
+ if (pct == 100)
+ pct = 0;
}
static int
--
2.31.1
[PATCH u-boot-marvell 14/29] tools: kwboot: Print new line after SPL output
There is no separation between output from the code from binary header
(U-Boot SPL in most cases) and subsequent kwboot output.
Print '\n' to make distinguishing these two easier.
Signed-off-by: Marek Behún
---
tools/kwboot.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/tools/kwboot.c b/tools/kwboot.c
index 2829b74a2e..2e16db83fa 100644
--- a/tools/kwboot.c
+++ b/tools/kwboot.c
@@ -385,6 +385,7 @@ static int
kwboot_xm_sendblock(int fd, struct kwboot_block *block, int allow_non_xm,
int *done_print)
{
+ int non_xm_print = 0;
int rc, retries;
char c;
@@ -413,6 +414,7 @@ kwboot_xm_sendblock(int fd, struct kwboot_block *block, int
allow_non_xm,
if (!_is_xm_reply(c) && allow_non_xm) {
putchar(c);
fflush(stdout);
+ non_xm_print = 1;
}
} while (!_is_xm_reply(c));
@@ -420,6 +422,9 @@ kwboot_xm_sendblock(int fd, struct kwboot_block *block, int
allow_non_xm,
kwboot_progress(-1, '+');
} while (c == NAK && retries-- > 0);
+ if (non_xm_print)
+ kwboot_printv("\n");
+
rc = -1;
switch (c) {
--
2.31.1
[PATCH u-boot-marvell 13/29] tools: kwboot: Allow non-xmodem text output from BootROM only in a specific case
From: Pali Rohár
When sending image header / image data, BootROM does not send any
non-xmodem text output. We should therefore interpret unknown bytes in
the xmodem protocol as errors and resend current packet. This should
improve the transfer in case there are errors on the UART line.
Text output from BootROM may only happen after whole image header is
sent and before ACK for the last packet of image header is received.
In this case BootROM may execute code from the image, which may interact
with UART (U-Boot SPL, for example, prints stuff on UART).
Print received non-xmodem output from BootROM only in this case.
Signed-off-by: Pali Rohár
[ refactored & simplified ]
Signed-off-by: Marek Behún
---
tools/kwboot.c | 34 +-
1 file changed, 25 insertions(+), 9 deletions(-)
diff --git a/tools/kwboot.c b/tools/kwboot.c
index 2e5684b91c..2829b74a2e 100644
--- a/tools/kwboot.c
+++ b/tools/kwboot.c
@@ -382,17 +382,26 @@ _is_xm_reply(char c)
}
static int
-kwboot_xm_sendblock(int fd, struct kwboot_block *block)
+kwboot_xm_sendblock(int fd, struct kwboot_block *block, int allow_non_xm,
+ int *done_print)
{
int rc, retries;
char c;
+ *done_print = 0;
+
retries = 16;
do {
rc = kwboot_tty_send(fd, block, sizeof(*block));
if (rc)
return rc;
+ if (allow_non_xm && !*done_print) {
+ kwboot_progress(100, '.');
+ kwboot_printv("Done\n");
+ *done_print = 1;
+ }
+
do {
rc = kwboot_tty_recv(fd, &c, 1, blk_rsp_timeo);
if (rc) {
@@ -401,14 +410,14 @@ kwboot_xm_sendblock(int fd, struct kwboot_block *block)
c = NAK;
}
- if (!_is_xm_reply(c))
- printf("%c", c);
-
+ if (!_is_xm_reply(c) && allow_non_xm) {
+ putchar(c);
+ fflush(stdout);
+ }
} while (!_is_xm_reply(c));
- if (c != ACK)
+ if (!allow_non_xm && c != ACK)
kwboot_progress(-1, '+');
-
} while (c == NAK && retries-- > 0);
rc = -1;
@@ -435,6 +444,7 @@ static int
kwboot_xmodem_one(int tty, int *pnum, int header, const uint8_t *data,
size_t size)
{
+ int done_print = 0;
size_t sent, left;
int rc;
@@ -446,22 +456,28 @@ kwboot_xmodem_one(int tty, int *pnum, int header, const
uint8_t *data,
while (sent < size) {
struct kwboot_block block;
+ int last_block;
size_t blksz;
blksz = kwboot_xm_makeblock(&block, data, left, (*pnum)++);
data += blksz;
- rc = kwboot_xm_sendblock(tty, &block);
+ last_block = (left <= blksz);
+
+ rc = kwboot_xm_sendblock(tty, &block, header && last_block,
+&done_print);
if (rc)
goto out;
sent += blksz;
left -= blksz;
- kwboot_progress(sent * 100 / size, '.');
+ if (!done_print)
+ kwboot_progress(sent * 100 / size, '.');
}
- kwboot_printv("Done\n");
+ if (!done_print)
+ kwboot_printv("Done\n");
return 0;
out:
--
2.31.1
[PATCH u-boot-marvell 19/29] tools: kwboot: Don't patch image header if signed
From: Pali Rohár
It is not possible to modify image with secure header due to
cryptographic signature.
Signed-off-by: Pali Rohár
[ refactored ]
Signed-off-by: Marek Behún
---
tools/kwboot.c | 27 ---
1 file changed, 24 insertions(+), 3 deletions(-)
diff --git a/tools/kwboot.c b/tools/kwboot.c
index 031cea7550..c23357f5bc 100644
--- a/tools/kwboot.c
+++ b/tools/kwboot.c
@@ -739,6 +739,18 @@ kwboot_img_csum8(void *_data, size_t size)
return csum;
}
+static int
+kwboot_img_is_secure(void *img)
+{
+ struct opt_hdr_v1 *ohdr;
+
+ for_each_opt_hdr_v1 (ohdr, img)
+ if (ohdr->headertype == OPT_HDR_V1_SECURE_TYPE)
+ return 1;
+
+ return 0;
+}
+
static int
kwboot_img_patch_hdr(void *img, size_t size)
{
@@ -747,7 +759,9 @@ kwboot_img_patch_hdr(void *img, size_t size)
uint8_t csum;
size_t hdrsz = sizeof(*hdr);
int image_ver;
+ int is_secure;
+ is_secure = 0;
rc = -1;
hdr = img;
@@ -779,9 +793,16 @@ kwboot_img_patch_hdr(void *img, size_t size)
goto out;
}
- if (hdr->blockid == IBR_HDR_UART_ID) {
- rc = 0;
- goto out;
+ is_secure = kwboot_img_is_secure(img);
+
+ if (hdr->blockid != IBR_HDR_UART_ID) {
+ if (is_secure) {
+ fprintf(stderr,
+ "Image has secure header with signature for
non-UART booting\n");
+ errno = EINVAL;
+ goto out;
+ }
+ kwboot_printv("Patching image boot signature to UART\n");
}
hdr->blockid = IBR_HDR_UART_ID;
--
2.31.1
[PATCH u-boot-marvell 15/29] tools: kwboot: Allow greater timeout when executing header code
When executing header code (which contains U-Boot SPL in most cases),
wait 10s after every non-xmodem character received (i.e. printed by
U-Boot SPL) before timing out.
Sometimes DDR training, which runs in SPL, may be slow.
Signed-off-by: Marek Behún
---
tools/kwboot.c | 44 +---
1 file changed, 41 insertions(+), 3 deletions(-)
diff --git a/tools/kwboot.c b/tools/kwboot.c
index 2e16db83fa..0e60cc8a70 100644
--- a/tools/kwboot.c
+++ b/tools/kwboot.c
@@ -24,6 +24,7 @@
#include
#include
#include
+#include
#include
#include
@@ -68,6 +69,7 @@ struct kwboot_block {
} __packed;
#define KWBOOT_BLK_RSP_TIMEO 1000 /* ms */
+#define KWBOOT_HDR_RSP_TIMEO 1 /* ms */
static int kwboot_verbose;
@@ -381,12 +383,35 @@ _is_xm_reply(char c)
return c == ACK || c == NAK || c == CAN;
}
+static uint64_t
+_now(void)
+{
+ struct timespec ts;
+
+ if (clock_gettime(CLOCK_MONOTONIC, &ts)) {
+ static int err_print;
+
+ if (!err_print) {
+ perror("clock_gettime() does not work");
+ err_print = 1;
+ }
+
+ /* this will just make the timeout not work */
+ return -1ULL;
+ }
+
+ return ts.tv_sec * 1000 + (ts.tv_nsec + 50) / 100;
+}
+
static int
kwboot_xm_sendblock(int fd, struct kwboot_block *block, int allow_non_xm,
int *done_print)
{
+ int recv_timeo = allow_non_xm ? KWBOOT_HDR_RSP_TIMEO : blk_rsp_timeo;
int non_xm_print = 0;
+ uint64_t timeout = 0;
int rc, retries;
+ int err;
char c;
*done_print = 0;
@@ -404,14 +429,22 @@ kwboot_xm_sendblock(int fd, struct kwboot_block *block,
int allow_non_xm,
}
do {
- rc = kwboot_tty_recv(fd, &c, 1, blk_rsp_timeo);
+ err = 0;
+ rc = kwboot_tty_recv(fd, &c, 1, recv_timeo);
if (rc) {
- if (errno != ETIMEDOUT)
+ if (errno != ETIMEDOUT) {
return rc;
- c = NAK;
+ } else if (timeout && timeout < _now()) {
+ errno = ETIMEDOUT;
+ return -1;
+ } else {
+ err = errno;
+ c = NAK;
+ }
}
if (!_is_xm_reply(c) && allow_non_xm) {
+ timeout = _now() + recv_timeo;
putchar(c);
fflush(stdout);
non_xm_print = 1;
@@ -425,6 +458,11 @@ kwboot_xm_sendblock(int fd, struct kwboot_block *block,
int allow_non_xm,
if (non_xm_print)
kwboot_printv("\n");
+ if (err) {
+ errno = err;
+ return -1;
+ }
+
rc = -1;
switch (c) {
--
2.31.1
[PATCH u-boot-marvell 06/29] tools: kwboot: Fix kwboot_xm_sendblock() function when kwboot_tty_recv() fails
From: Pali Rohár
When kwboot_tty_recv() fails or times out, it does not set the `c`
variable to NAK. The variable is then compared, while it holds either
an undefined value or a value from previous iteration. Set `c` to NAK so
that the other side will try to resend current block, and remove the
now unnecessary break.
In other failure cases return immediately.
Signed-off-by: Pali Rohár
Reviewed-by: Marek Behún
---
tools/kwboot.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/tools/kwboot.c b/tools/kwboot.c
index 454339db14..b9a402ca91 100644
--- a/tools/kwboot.c
+++ b/tools/kwboot.c
@@ -380,12 +380,15 @@ kwboot_xm_sendblock(int fd, struct kwboot_block *block)
do {
rc = kwboot_tty_send(fd, block, sizeof(*block));
if (rc)
- break;
+ return rc;
do {
rc = kwboot_tty_recv(fd, &c, 1, blk_rsp_timeo);
- if (rc)
- break;
+ if (rc) {
+ if (errno != ETIMEDOUT)
+ return rc;
+ c = NAK;
+ }
if (c != ACK && c != NAK && c != CAN)
printf("%c", c);
--
2.31.1
[PATCH u-boot-marvell 10/29] tools: kwboot: Print newline on error when progress was not completed
From: Pali Rohár
When progress was not completed, current terminal position is in progress
bar. So print newline before printing error message to make error message
more readable.
Signed-off-by: Pali Rohár
Reviewed-by: Marek Behún
---
tools/kwboot.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/tools/kwboot.c b/tools/kwboot.c
index eb4b3fe230..0e533e3698 100644
--- a/tools/kwboot.c
+++ b/tools/kwboot.c
@@ -459,6 +459,7 @@ kwboot_xmodem(int tty, const void *_data, size_t size)
rc = kwboot_tty_send_char(tty, EOT);
out:
+ kwboot_printv("\n");
return rc;
can:
--
2.31.1
[PATCH u-boot-marvell 12/29] tools: kwboot: Use a function to check whether received byte is a Xmodem reply
This is a non-functional change that should make the code more readable.
Signed-off-by: Marek Behún
---
tools/kwboot.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/tools/kwboot.c b/tools/kwboot.c
index 7f231c0823..2e5684b91c 100644
--- a/tools/kwboot.c
+++ b/tools/kwboot.c
@@ -375,6 +375,12 @@ kwboot_xm_makeblock(struct kwboot_block *block, const void
*data,
return n;
}
+static int
+_is_xm_reply(char c)
+{
+ return c == ACK || c == NAK || c == CAN;
+}
+
static int
kwboot_xm_sendblock(int fd, struct kwboot_block *block)
{
@@ -395,10 +401,10 @@ kwboot_xm_sendblock(int fd, struct kwboot_block *block)
c = NAK;
}
- if (c != ACK && c != NAK && c != CAN)
+ if (!_is_xm_reply(c))
printf("%c", c);
- } while (c != ACK && c != NAK && c != CAN);
+ } while (!_is_xm_reply(c));
if (c != ACK)
kwboot_progress(-1, '+');
--
2.31.1
[PATCH u-boot-marvell 17/29] tools: kwboot: Always call kwboot_img_patch_hdr()
From: Pali Rohár
The kwboot_img_patch_hdr() function already decides if header patching
is needed. Always call this function and deprecate the unneeded command
line option `-p`.
Signed-off-by: Pali Rohár
Reviewed-by: Marek Behún
---
tools/kwboot.c | 23 ++-
1 file changed, 6 insertions(+), 17 deletions(-)
diff --git a/tools/kwboot.c b/tools/kwboot.c
index 6674a253ff..031cea7550 100644
--- a/tools/kwboot.c
+++ b/tools/kwboot.c
@@ -692,9 +692,9 @@ out:
}
static void *
-kwboot_mmap_image(const char *path, size_t *size, int prot)
+kwboot_mmap_image(const char *path, size_t *size)
{
- int rc, fd, flags;
+ int rc, fd;
struct stat st;
void *img;
@@ -709,9 +709,7 @@ kwboot_mmap_image(const char *path, size_t *size, int prot)
if (rc)
goto out;
- flags = (prot & PROT_WRITE) ? MAP_PRIVATE : MAP_SHARED;
-
- img = mmap(NULL, st.st_size, prot, flags, fd, 0);
+ img = mmap(NULL, st.st_size, PROT_READ | PROT_WRITE, MAP_PRIVATE, fd,
0);
if (img == MAP_FAILED) {
img = NULL;
goto out;
@@ -816,7 +814,6 @@ kwboot_usage(FILE *stream, char *progname)
fprintf(stream, "\n");
fprintf(stream,
" -b : boot with preamble (Kirkwood, Armada
370/XP)\n");
- fprintf(stream, " -p: patch to type 0x69 (uart boot)\n");
fprintf(stream,
" -D : boot without preamble (Dove)\n");
fprintf(stream, " -d: enter debug mode\n");
@@ -836,7 +833,7 @@ int
main(int argc, char **argv)
{
const char *ttypath, *imgpath;
- int rv, rc, tty, term, prot, patch;
+ int rv, rc, tty, term;
void *bootmsg;
void *debugmsg;
void *img;
@@ -850,7 +847,6 @@ main(int argc, char **argv)
imgpath = NULL;
img = NULL;
term = 0;
- patch = 0;
size = 0;
speed = B115200;
@@ -877,7 +873,7 @@ main(int argc, char **argv)
break;
case 'p':
- patch = 1;
+ /* nop, for backward compatibility */
break;
case 't':
@@ -917,9 +913,6 @@ main(int argc, char **argv)
if (!bootmsg && !term && !debugmsg)
goto usage;
- if (patch && !imgpath)
- goto usage;
-
if (argc - optind < 1)
goto usage;
@@ -932,16 +925,12 @@ main(int argc, char **argv)
}
if (imgpath) {
- prot = PROT_READ | (patch ? PROT_WRITE : 0);
-
- img = kwboot_mmap_image(imgpath, &size, prot);
+ img = kwboot_mmap_image(imgpath, &size);
if (!img) {
perror(imgpath);
goto out;
}
- }
- if (patch) {
rc = kwboot_img_patch_hdr(img, size);
if (rc) {
fprintf(stderr, "%s: Invalid image.\n", imgpath);
--
2.31.1
[PATCH u-boot-marvell 20/29] tools: kwboot: Patch source address in image header
From: Pali Rohár
Some image types have source address in non-bytes unit; for example for
SATA images, it is in 512 B units.
We need to multiply by unit size when patching image type to UART.
Signed-off-by: Pali Rohár
[ refactored ]
Signed-off-by: Marek Behún
---
tools/kwboot.c | 26 --
1 file changed, 24 insertions(+), 2 deletions(-)
diff --git a/tools/kwboot.c b/tools/kwboot.c
index c23357f5bc..9cc7936959 100644
--- a/tools/kwboot.c
+++ b/tools/kwboot.c
@@ -756,6 +756,7 @@ kwboot_img_patch_hdr(void *img, size_t size)
{
int rc;
struct main_hdr_v1 *hdr;
+ uint32_t srcaddr;
uint8_t csum;
size_t hdrsz = sizeof(*hdr);
int image_ver;
@@ -805,8 +806,6 @@ kwboot_img_patch_hdr(void *img, size_t size)
kwboot_printv("Patching image boot signature to UART\n");
}
- hdr->blockid = IBR_HDR_UART_ID;
-
if (image_ver == 0) {
struct main_hdr_v0 *hdr_v0 = img;
@@ -818,6 +817,29 @@ kwboot_img_patch_hdr(void *img, size_t size)
: sizeof(*hdr_v0);
}
+ srcaddr = le32_to_cpu(hdr->srcaddr);
+
+ switch (hdr->blockid) {
+ case IBR_HDR_SATA_ID:
+ if (srcaddr < 1) {
+ errno = EINVAL;
+ goto out;
+ }
+ hdr->srcaddr = cpu_to_le32((srcaddr - 1) * 512);
+ break;
+
+ case IBR_HDR_SDIO_ID:
+ hdr->srcaddr = cpu_to_le32(srcaddr * 512);
+ break;
+
+ case IBR_HDR_PEX_ID:
+ if (hdr->srcaddr == 0x)
+ hdr->srcaddr = cpu_to_le32(hdrsz);
+ break;
+ }
+
+ hdr->blockid = IBR_HDR_UART_ID;
+
hdr->checksum = kwboot_img_csum8(hdr, hdrsz) - csum;
rc = 0;
--
2.31.1
[PATCH u-boot-marvell 23/29] tools: kwbimage: Refactor kwbimage header size determination
Add functions kwbheader_size() and kwbheader_size_for_csum().
Refactor code determining header size to use these functions.
Refactor header checksum determining function.
Remove stuff that is not needed anymore.
This simplifies the code a little and fixes one instance of validating
header size meant for checksum instead of whole header size.
Signed-off-by: Marek Behún
---
tools/kwbimage.c | 29 +++--
tools/kwbimage.h | 35 +++
tools/kwboot.c | 26 +++---
3 files changed, 41 insertions(+), 49 deletions(-)
diff --git a/tools/kwbimage.c b/tools/kwbimage.c
index e98ef455de..d3a52df736 100644
--- a/tools/kwbimage.c
+++ b/tools/kwbimage.c
@@ -282,14 +282,6 @@ static uint8_t image_checksum8(void *start, uint32_t len)
return csum;
}
-size_t kwbimage_header_size(unsigned char *ptr)
-{
- if (kwbimage_version((void *)ptr) == 0)
- return sizeof(struct main_hdr_v0);
- else
- return KWBHEADER_V1_SIZE((struct main_hdr_v1 *)ptr);
-}
-
/*
* Verify checksum over a complete header that includes the checksum field.
* Return 1 when OK, otherwise 0.
@@ -300,7 +292,7 @@ static int main_hdr_checksum_ok(void *hdr)
struct main_hdr_v0 *main_hdr = (struct main_hdr_v0 *)hdr;
uint8_t checksum;
- checksum = image_checksum8(hdr, kwbimage_header_size(hdr));
+ checksum = image_checksum8(hdr, kwbheader_size_for_csum(hdr));
/* Calculated checksum includes the header checksum field. Compensate
* for that.
*/
@@ -1651,8 +1643,8 @@ static int kwbimage_check_image_types(uint8_t type)
static int kwbimage_verify_header(unsigned char *ptr, int image_size,
struct image_tool_params *params)
{
- uint8_t checksum;
- size_t header_size = kwbimage_header_size(ptr);
+ size_t header_size = kwbheader_size(ptr);
+ uint8_t csum;
if (header_size > image_size)
return -FDT_ERR_BADSTRUCTURE;
@@ -1665,17 +1657,10 @@ static int kwbimage_verify_header(unsigned char *ptr,
int image_size,
struct main_hdr_v0 *mhdr = (struct main_hdr_v0 *)ptr;
if (mhdr->ext & 0x1) {
- struct ext_hdr_v0 *ext_hdr;
-
- if (header_size + sizeof(*ext_hdr) > image_size)
- return -FDT_ERR_BADSTRUCTURE;
+ struct ext_hdr_v0 *ext_hdr = (void *)(mhdr + 1);
- ext_hdr = (struct ext_hdr_v0 *)
- (ptr + sizeof(struct main_hdr_v0));
- checksum = image_checksum8(ext_hdr,
- sizeof(struct ext_hdr_v0)
- - sizeof(uint8_t));
- if (checksum != ext_hdr->checksum)
+ csum = image_checksum8(ext_hdr, sizeof(*ext_hdr) - 1);
+ if (csum != ext_hdr->checksum)
return -FDT_ERR_BADSTRUCTURE;
}
} else if (kwbimage_version(ptr) == 1) {
@@ -1834,7 +1819,7 @@ static int kwbimage_generate(struct image_tool_params
*params,
static int kwbimage_extract_subimage(void *ptr, struct image_tool_params
*params)
{
struct main_hdr_v1 *mhdr = (struct main_hdr_v1 *)ptr;
- size_t header_size = kwbimage_header_size(ptr);
+ size_t header_size = kwbheader_size(ptr);
struct opt_hdr_v1 *ohdr;
int idx = params->pflag;
int cur_idx = 0;
diff --git a/tools/kwbimage.h b/tools/kwbimage.h
index 738034beb1..56a748d4cf 100644
--- a/tools/kwbimage.h
+++ b/tools/kwbimage.h
@@ -69,11 +69,6 @@ struct ext_hdr_v0 {
uint8_t checksum;
} __packed;
-struct kwb_header {
- struct main_hdr_v0 kwb_hdr;
- struct ext_hdr_v0 kwb_exthdr;
-} __packed;
-
/* Structure of the main header, version 1 (Armada 370/38x/XP) */
struct main_hdr_v1 {
uint8_t blockid; /* 0x0 */
@@ -195,13 +190,6 @@ struct register_set_hdr_v1 {
#define OPT_HDR_V1_BINARY_TYPE 0x2
#define OPT_HDR_V1_REGISTER_TYPE 0x3
-#define KWBHEADER_V0_SIZE(hdr) \
- (((hdr)->ext & 0x1) ? sizeof(struct kwb_header) : \
- sizeof(struct main_hdr_v0))
-
-#define KWBHEADER_V1_SIZE(hdr) \
- (((hdr)->headersz_msb << 16) | le16_to_cpu((hdr)->headersz_lsb))
-
enum kwbimage_cmd {
CMD_INVALID,
CMD_BOOT_FROM,
@@ -235,6 +223,29 @@ static inline unsigned int kwbimage_version(const void
*header)
return ptr[8];
}
+static inline size_t kwbheader_size(const void *header)
+{
+ if (kwbimage_version(header) == 0) {
+ const struct main_hdr_v0 *hdr = header;
+
+ return sizeof(*hdr) +
+ (hdr->ext & 0x1) ? sizeof(struct ext_hdr_v0) : 0;
+ } else {
+ const struct main_hdr_v1 *
[PATCH u-boot-marvell 21/29] tools: kwboot: Patch destination address to DDR area for SPI image
From: Pali Rohár
SPI/NOR kwbimage may have destination address set to 0x, which
means that the image is not downloaded to DDR but rather it is executed
directly from SPI/NOR. In this case execution address is set to SPI/NOR
area.
When patching image to UART type, change destination and execution
addresses from SPI/NOR XIP area to DDR area 0x0080 (which is default
for A38x).
Signed-off-by: Pali Rohár
[ refactored ]
Signed-off-by: Marek Behún
---
tools/kwboot.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/tools/kwboot.c b/tools/kwboot.c
index 9cc7936959..7c6ea2f75d 100644
--- a/tools/kwboot.c
+++ b/tools/kwboot.c
@@ -836,6 +836,13 @@ kwboot_img_patch_hdr(void *img, size_t size)
if (hdr->srcaddr == 0x)
hdr->srcaddr = cpu_to_le32(hdrsz);
break;
+
+ case IBR_HDR_SPI_ID:
+ if (hdr->destaddr == 0x) {
+ kwboot_printv("Patching destination and execution
addresses from SPI/NOR XIP area to DDR area 0x0080\n");
+ hdr->destaddr = cpu_to_le32(0x0080);
+ hdr->execaddr = cpu_to_le32(0x0080);
+ }
}
hdr->blockid = IBR_HDR_UART_ID;
--
2.31.1
[PATCH u-boot-marvell 24/29] tools: kwboot: Round up header size to 128 B when patching
From: Pali Rohár
The beginning of image data must be sent in a separate xmodem block;
the block must not contain end of header with the beginning of data.
Therefore we need to ensure that the image header size is a multiple of
xmodem block size (which is 128 B).
Read the file into a malloc()ed buffer of enough size instead of
mmap()ing it. (If we are going to move the data, most of the pages will
be dirty anyway.) Then move the payload if header size needs to be
increased.
Signed-off-by: Pali Rohár
[ refactored ]
Signed-off-by: Marek Behún
---
tools/kwboot.c | 91 +++---
1 file changed, 79 insertions(+), 12 deletions(-)
diff --git a/tools/kwboot.c b/tools/kwboot.c
index 1481735346..6d7d812416 100644
--- a/tools/kwboot.c
+++ b/tools/kwboot.c
@@ -25,7 +25,6 @@
#include
#include
#include
-#include
#include
/*
@@ -689,11 +688,12 @@ out:
}
static void *
-kwboot_mmap_image(const char *path, size_t *size)
+kwboot_read_image(const char *path, size_t *size, size_t reserve)
{
int rc, fd;
struct stat st;
void *img;
+ off_t tot;
rc = -1;
img = NULL;
@@ -706,17 +706,30 @@ kwboot_mmap_image(const char *path, size_t *size)
if (rc)
goto out;
- img = mmap(NULL, st.st_size, PROT_READ | PROT_WRITE, MAP_PRIVATE, fd,
0);
- if (img == MAP_FAILED) {
- img = NULL;
+ img = malloc(st.st_size + reserve);
+ if (!img)
goto out;
+
+ tot = 0;
+ while (tot < st.st_size) {
+ ssize_t rd = read(fd, img + tot, st.st_size - tot);
+
+ if (rd < 0)
+ goto out;
+
+ tot += rd;
+
+ if (!rd && tot < st.st_size) {
+ errno = EIO;
+ goto out;
+ }
}
rc = 0;
*size = st.st_size;
out:
if (rc && img) {
- munmap(img, st.st_size);
+ free(img);
img = NULL;
}
if (fd >= 0)
@@ -752,8 +765,41 @@ kwboot_img_is_secure(void *img)
return 0;
}
+static void
+kwboot_img_grow_hdr(void *img, size_t *size, size_t grow)
+{
+ uint32_t hdrsz, datasz, srcaddr;
+ struct main_hdr_v1 *hdr = img;
+ uint8_t *data;
+
+ srcaddr = le32_to_cpu(hdr->srcaddr);
+
+ hdrsz = kwbheader_size(hdr);
+ data = (uint8_t *)img + srcaddr;
+ datasz = *size - srcaddr;
+
+ /* only move data if there is not enough space */
+ if (hdrsz + grow > srcaddr) {
+ size_t need = hdrsz + grow - srcaddr;
+
+ /* move data by enough bytes */
+ memmove(data + need, data, datasz);
+
+ hdr->srcaddr = cpu_to_le32(srcaddr + need);
+ *size += need;
+ }
+
+ if (kwbimage_version(img) == 1) {
+ struct main_hdr_v1 *hdr = img;
+
+ hdrsz += grow;
+ hdr->headersz_msb = hdrsz >> 16;
+ hdr->headersz_lsb = cpu_to_le16(hdrsz & 0x);
+ }
+}
+
static int
-kwboot_img_patch_hdr(void *img, size_t size)
+kwboot_img_patch_hdr(void *img, size_t *size)
{
int rc;
struct main_hdr_v1 *hdr;
@@ -767,7 +813,7 @@ kwboot_img_patch_hdr(void *img, size_t size)
rc = -1;
hdr = img;
- if (size < hdrsz) {
+ if (*size < hdrsz) {
errno = EINVAL;
goto out;
}
@@ -781,7 +827,7 @@ kwboot_img_patch_hdr(void *img, size_t size)
hdrsz = kwbheader_size(hdr);
- if (size < hdrsz) {
+ if (*size < hdrsz) {
errno = EINVAL;
goto out;
}
@@ -841,10 +887,31 @@ kwboot_img_patch_hdr(void *img, size_t size)
}
}
+ if (hdrsz > le32_to_cpu(hdr->srcaddr) ||
+ *size < le32_to_cpu(hdr->srcaddr) + le32_to_cpu(hdr->blocksize)) {
+ errno = EINVAL;
+ goto out;
+ }
+
hdr->blockid = IBR_HDR_UART_ID;
+ if (hdrsz % KWBOOT_XM_BLKSZ) {
+ size_t offset = (KWBOOT_XM_BLKSZ - hdrsz % KWBOOT_XM_BLKSZ) %
+ KWBOOT_XM_BLKSZ;
+
+ if (is_secure) {
+ fprintf(stderr, "Cannot align image with secure
header\n");
+ errno = EINVAL;
+ goto out;
+ }
+
+ kwboot_printv("Aligning image header to Xmodem block size\n");
+ kwboot_img_grow_hdr(img, size, offset);
+ }
+
hdr->checksum = kwboot_hdr_csum8(hdr) - csum;
+ *size = le32_to_cpu(hdr->srcaddr) + le32_to_cpu(hdr->blocksize);
rc = 0;
out:
return rc;
@@ -971,13 +1038,13 @@ main(int argc, char **argv)
}
if (imgpath) {
- img = kwboot_mmap_image(imgpath, &size);
+ img = kwboot_read_image(imgpath, &size, KWBOOT_XM_BLKSZ);
if (
[PATCH u-boot-marvell 22/29] tools: kwbimage: Refactor image_version()
Rename this function to kwbimage_version() and don't cast argument if
not needed.
Signed-off-by: Marek Behún
---
tools/kwbimage.c | 8
tools/kwbimage.h | 4 ++--
tools/kwboot.c | 4 ++--
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/tools/kwbimage.c b/tools/kwbimage.c
index 6678ef15bd..e98ef455de 100644
--- a/tools/kwbimage.c
+++ b/tools/kwbimage.c
@@ -284,7 +284,7 @@ static uint8_t image_checksum8(void *start, uint32_t len)
size_t kwbimage_header_size(unsigned char *ptr)
{
- if (image_version((void *)ptr) == 0)
+ if (kwbimage_version((void *)ptr) == 0)
return sizeof(struct main_hdr_v0);
else
return KWBHEADER_V1_SIZE((struct main_hdr_v1 *)ptr);
@@ -1624,7 +1624,7 @@ static void kwbimage_print_header(const void *ptr)
printf("Image Type: MVEBU Boot from %s Image\n",
image_boot_mode_name(mhdr->blockid));
- printf("Image version:%d\n", image_version((void *)ptr));
+ printf("Image version:%d\n", kwbimage_version(ptr));
for_each_opt_hdr_v1 (ohdr, mhdr) {
if (ohdr->headertype == OPT_HDR_V1_BINARY_TYPE) {
@@ -1661,7 +1661,7 @@ static int kwbimage_verify_header(unsigned char *ptr, int
image_size,
return -FDT_ERR_BADSTRUCTURE;
/* Only version 0 extended header has checksum */
- if (image_version((void *)ptr) == 0) {
+ if (kwbimage_version(ptr) == 0) {
struct main_hdr_v0 *mhdr = (struct main_hdr_v0 *)ptr;
if (mhdr->ext & 0x1) {
@@ -1678,7 +1678,7 @@ static int kwbimage_verify_header(unsigned char *ptr, int
image_size,
if (checksum != ext_hdr->checksum)
return -FDT_ERR_BADSTRUCTURE;
}
- } else if (image_version((void *)ptr) == 1) {
+ } else if (kwbimage_version(ptr) == 1) {
struct main_hdr_v1 *mhdr = (struct main_hdr_v1 *)ptr;
const uint8_t *mhdr_end;
struct opt_hdr_v1 *ohdr;
diff --git a/tools/kwbimage.h b/tools/kwbimage.h
index 9a949e03c0..738034beb1 100644
--- a/tools/kwbimage.h
+++ b/tools/kwbimage.h
@@ -229,7 +229,7 @@ void init_kwb_image_type (void);
* header, byte 8 was reserved, and always set to 0. In the v1 header,
* byte 8 has been changed to a proper field, set to 1.
*/
-static inline unsigned int image_version(const void *header)
+static inline unsigned int kwbimage_version(const void *header)
{
const unsigned char *ptr = header;
return ptr[8];
@@ -258,7 +258,7 @@ static inline int opt_hdr_v1_valid_size(const struct
opt_hdr_v1 *ohdr,
static inline struct opt_hdr_v1 *opt_hdr_v1_first(void *img) {
struct main_hdr_v1 *mhdr;
- if (image_version(img) != 1)
+ if (kwbimage_version(img) != 1)
return NULL;
mhdr = img;
diff --git a/tools/kwboot.c b/tools/kwboot.c
index 7c6ea2f75d..f3afe2d383 100644
--- a/tools/kwboot.c
+++ b/tools/kwboot.c
@@ -565,7 +565,7 @@ kwboot_xmodem(int tty, const void *_img, size_t size)
int rc, pnum;
size_t hdrsz;
- if (image_version(img) == 0)
+ if (kwbimage_version(img) == 0)
hdrsz = KWBHEADER_V0_SIZE((struct main_hdr_v0 *)img);
else
hdrsz = KWBHEADER_V1_SIZE((struct main_hdr_v1 *)img);
@@ -771,7 +771,7 @@ kwboot_img_patch_hdr(void *img, size_t size)
goto out;
}
- image_ver = image_version(img);
+ image_ver = kwbimage_version(img);
if (image_ver != 0 && image_ver != 1) {
fprintf(stderr, "Invalid image header version\n");
errno = EINVAL;
--
2.31.1
[PATCH u-boot-marvell 29/29] MAINTAINERS: Add entry for kwbimage / kwboot tools
Add entry for these tools with Marek, Pali and Stefan as maintainers. Signed-off-by: Marek Behún --- MAINTAINERS | 10 ++ 1 file changed, 10 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 776ff703b9..d4b21dd660 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -772,6 +772,16 @@ S: Maintained T: git https://source.denx.de/u-boot/custodians/u-boot-i2c.git F: drivers/i2c/ +KWBIMAGE / KWBOOT TOOLS +M: Pali Rohár +M: Marek Behún +M: Stefan Roese +S: Maintained +T: git https://source.denx.de/u-boot/custodians/u-boot-marvell.git +F: doc/README.kwbimage +F: doc/kwboot.1 +F: tools/kwb* + LOGGING M: Simon Glass S: Maintained -- 2.31.1
[PATCH u-boot-marvell 27/29] tools: kwboot: Add Pali and Marek as authors
From: Pali Rohár Add Pali and Marek as another authors of the kwboot utility. Signed-off-by: Pali Rohár Signed-off-by: Marek Behún --- tools/kwboot.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/tools/kwboot.c b/tools/kwboot.c index f60cfd130e..b183e4b35b 100644 --- a/tools/kwboot.c +++ b/tools/kwboot.c @@ -3,6 +3,8 @@ * supports Kirkwood, Dove, Armada 370, Armada XP * * (c) 2012 Daniel Stodden + * (c) 2021 Pali Rohár + * (c) 2021 Marek Behún * * References: marvell.com, "88F6180, 88F6190, 88F6192, and 88F6281 * Integrated Controller: Functional Specifications" December 2, -- 2.31.1
[PATCH u-boot-marvell 26/29] tools: kwboot: Allow any baudrate on Linux
From: Pali Rohár
The A38x platform supports more baudrates than just those defined by the
Bn constants, and some of them are higher than the highest Bn baudrate
(the highest is 4 MBd while A38x support 5.15 MBd).
On Linux, add support for arbitrary baudrates. (Since there is no
standard POSIX API to specify arbitrary baudrate for a tty device, this
change is Linux-specific.)
We need to use raw TCGETS2/TCSETS2 or TCGETS/TCSETS ioctls with the
BOTHER flag in struct termios2/termios, defined in Linux headers
and . Since these headers conflict with
glibc's header file , it is not possible to use libc's
termios functions and we need to reimplement them via ioctl() calls.
Note that the Bnnn constants from need not be compatible
with Bnnn constants from .
Signed-off-by: Pali Rohár
[ termios macros rewritten to static inline functions (for type control)
and moved to tools/termios.h ]
Signed-off-by: Marek Behún
---
tools/kwboot.c| 16 +++-
tools/termios_linux.h | 170 ++
2 files changed, 185 insertions(+), 1 deletion(-)
create mode 100644 tools/termios_linux.h
diff --git a/tools/kwboot.c b/tools/kwboot.c
index dbe59833eb..f60cfd130e 100644
--- a/tools/kwboot.c
+++ b/tools/kwboot.c
@@ -23,10 +23,15 @@
#include
#include
#include
-#include
#include
#include
+#ifdef __linux__
+#include "termios_linux.h"
+#else
+#include
+#endif
+
/*
* Marvell BootROM UART Sensing
*/
@@ -553,7 +558,11 @@ kwboot_tty_baudrate_to_speed(int baudrate)
return B50;
#endif
default:
+#ifdef BOTHER
+ return BOTHER;
+#else
return B0;
+#endif
}
}
@@ -574,6 +583,11 @@ kwboot_tty_change_baudrate(int fd, int baudrate)
return -1;
}
+#ifdef BOTHER
+ if (speed == BOTHER)
+ tio.c_ospeed = tio.c_ispeed = baudrate;
+#endif
+
rc = cfsetospeed(&tio, speed);
if (rc)
return rc;
diff --git a/tools/termios_linux.h b/tools/termios_linux.h
new file mode 100644
index 00..1c4223afa7
--- /dev/null
+++ b/tools/termios_linux.h
@@ -0,0 +1,170 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * termios fuctions to support arbitrary baudrates (on Linux)
+ *
+ * Copyright (c) 2021 Pali Rohár
+ * Copyright (c) 2021 Marek Behún
+ */
+
+#ifndef _TERMIOS_LINUX_H_
+#define _TERMIOS_LINUX_H_
+
+/*
+ * We need to use raw TCGETS2/TCSETS2 or TCGETS/TCSETS ioctls with the BOTHER
+ * flag in struct termios2/termios, defined in Linux headers and
+ * . Since these headers conflict with glibc's header file
+ * , it is not possible to use libc's termios functions and we need
+ * to reimplement them via ioctl() calls.
+ *
+ * An arbitrary baudrate is supported when the macro BOTHER is defined. The
+ * baudrate value itself is then stored into the c_ospeed and c_ispeed members.
+ * If ioctls TCGETS2/TCSETS2 are defined and supported then these fields are
+ * present in struct termios2, otherwise these fields are present in struct
+ * termios.
+ *
+ * Note that the Bnnn constants from need not be compatible with
Bnnn
+ * constants from .
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#if defined(BOTHER) && defined(TCGETS2)
+#define termios termios2
+#endif
+
+static inline int tcgetattr(int fd, struct termios *t)
+{
+#if defined(BOTHER) && defined(TCGETS2)
+ return ioctl(fd, TCGETS2, t);
+#else
+ return ioctl(fd, TCGETS, t);
+#endif
+}
+
+static inline int tcsetattr(int fd, int a, const struct termios *t)
+{
+ int cmd;
+
+ switch (a) {
+#if defined(BOTHER) && defined(TCGETS2)
+ case TCSANOW:
+ cmd = TCSETS2;
+ break;
+ case TCSADRAIN:
+ cmd = TCSETSW2;
+ break;
+ case TCSAFLUSH:
+ cmd = TCSETSF2;
+ break;
+#else
+ case TCSANOW:
+ cmd = TCSETS;
+ break;
+ case TCSADRAIN:
+ cmd = TCSETSW;
+ break;
+ case TCSAFLUSH:
+ cmd = TCSETSF;
+ break;
+#endif
+ default:
+ errno = EINVAL;
+ return -1;
+ }
+
+ return ioctl(fd, cmd, t);
+}
+
+static inline int tcdrain(int fd)
+{
+ return ioctl(fd, TCSBRK, 1);
+}
+
+static inline int tcflush(int fd, int q)
+{
+ return ioctl(fd, TCFLSH, q);
+}
+
+static inline int tcsendbreak(int fd, int d)
+{
+ return ioctl(fd, TCSBRK, d);
+}
+
+static inline int tcflow(int fd, int a)
+{
+ return ioctl(fd, TCXONC, a);
+}
+
+static inline pid_t tcgetsid(int fd)
+{
+ pid_t sid;
+
+ if (ioctl(fd, TIOCGSID, &sid) < 0)
+ return (pid_t)-1;
+
+ return sid;
+}
+
+static inline speed_t cfgetospeed(const struct termios *t)
+{
+ return t->c_cflag & CBAUD;
+}
+
+static inline int cfsetospeed(struct termios *t, speed_t s)
+{
+ t->c_cflag &= ~CBAUD;
+ t->c_cflag |= s;
+
+ return 0;
+}
+
+
[PATCH u-boot-marvell 28/29] doc/kwboot.1: Update man page
Update man page for the kwboot utility. Signed-off-by: Marek Behún --- doc/kwboot.1 | 58 ++-- 1 file changed, 38 insertions(+), 20 deletions(-) diff --git a/doc/kwboot.1 b/doc/kwboot.1 index 1e9ca268f7..cf113b8b27 100644 --- a/doc/kwboot.1 +++ b/doc/kwboot.1 @@ -1,21 +1,22 @@ -.TH KWBOOT 1 "2012-05-19" +.TH KWBOOT 1 "2021-08-25" .SH NAME -kwboot \- Boot Marvell Kirkwood SoCs over a serial link. +kwboot \- Boot Marvell Kirkwood (and others 32-bit) SoCs over a serial link. .SH SYNOPSIS .B kwboot .RB [ "-b \fIimage\fP" ] -.RB [ "-p" ] .RB [ "-t" ] .RB [ "-B \fIbaudrate\fP" ] .RB \fITTY\fP .SH "DESCRIPTION" -The \fBmkimage\fP program boots boards based on Marvell's Kirkwood -platform over their integrated UART. Boot image files will typically +The \fBkwboot\fP program boots boards based on Marvell's 32-bit +platforms including Orion, Kirkwood, Dove, Discovery, AXP, A37x, A38x +and A39x over their integrated UART. Boot image files will typically contain a second stage boot loader, such as U-Boot. The image file must conform to Marvell's BootROM firmware image format -(\fIkwbimage\fP), created using a tool such as \fBmkimage\fP. +(\fIkwbimage v0\fP or \fIv1\fP), created using a tool such as +\fBmkimage\fP. Following power-up or a system reset, system BootROM code polls the UART for a brief period of time, sensing a handshake message which @@ -36,25 +37,23 @@ by the second-stage loader. Handshake; then upload file \fIimage\fP over \fITTY\fP. Note that for the encapsulated boot code to be executed, \fIimage\fP -must be of type "UART boot" (0x69). Boot images of different types, -such as backup images of vendor firmware downloaded from flash memory -(type 0x8B), will not work (or not as expected). See \fB-p\fP for a -workaround. +must be of type "UART boot" (0x69). The \fBkwboot\fP program changes +this type automatically, unless the \fIimage\fP is signed, in which +case it cannot be changed. This mode writes handshake status and upload progress indication to -stdout. +stdout. It is possible that \fIimage\fP contains an optional binary +code in it's header which may also print some output via UART (for +example U-Boot SPL does this). In such a case, this output is also +written to stdout after the header is sent. .TP .BI "\-p" -In combination with \fB-b\fP, patches the header in \fIimage\fP prior -to upload, to "UART boot" type. +Obsolete. Does nothing. -This option attempts on-the-fly conversion of some none-UART image -types, such as images which were originally formatted to be stored in -flash memory. - -Conversion is performed in memory. The contents of \fIimage\fP will -not be altered. +In the past, when this option was used, the program patched the header +in the image prior upload, to "UART boot" type. This is now done by +default. .TP .BI "\-t" @@ -69,7 +68,22 @@ after receiving 'ctrl-\\' followed by 'c' from console input. .TP .BI "\-B \fIbaudrate\fP" -Adjust the baud rate on \fITTY\fP. Default rate is 115200. +If used in combination with \fB-b\fP, inject into the image header +code that changes baud rate to \fIbaudrate\fP after uploading image +header, and code that changes the baud rate back to the default +(115200 Bd) before executing payload, and also adjust the baud rate +on \fITTY\fP correspondingly. This can make the upload significantly +faster. + +If used in combination with \fB-t\fP, adjust the baud rate to +\fIbaudrate\fP on \fITTY\fP before starting terminal. + +If both \fB-b\fP and \fB-t\fP are used, the baud rate is changed +back to 115200 after the upload. + +Tested values for \fIbaudrate\fP for Armada 38x include: 115200, +230400, 460800, 50, 576000, 921600, 100, 1152000, 150, +200, 250, 3125000, 400 and 515. .SH "SEE ALSO" .PP @@ -82,3 +96,7 @@ Daniel Stodden Luka Perkov .br David Purdy +.br +Pali Rohár +.br +Marek Behún -- 2.31.1
Re: [PATCH] board: ea: mx7ulp_com: allocate specific region of memory to OP-TEE
On Wed, Aug 25, 2021 at 04:22:55PM +0300, Oleksandr Suvorov wrote: > From: Ricardo Salveti > > On the iMX7ULP uCOM board, OP-TEE uses the memory region defined by the > maximum DRAM address minus CONFIG_OPTEE_TZDRAM_SIZE, so subtract > CONFIG_OPTEE_TZDRAM_SIZE from the available DRAM size to avoid > conflicts. > > Note the OPTEE boot process itself subtracts the DRAM region it > lives in from the memory map passed to Linux. Is this something true of all OP-TEE? All OP-TEE on ARMv7? All OP-TEE on i.MX7? I'm asking since currently this hook is done the exact same way on a few other i.MX7 boards, and nowhere else. That says to me we should probably move this hook up somewhere, perhaps to imx_ddr_size() and poke the boards that aren't using that today to use it. -- Tom signature.asc Description: PGP signature
[PATCH u-boot-marvell 25/29] tools: kwboot: Support higher baudrates when booting via UART
From: Pali Rohár
Add support for uploading the boot image (the data part only) at higher
baudrate than the standard one.
The kwboot utility already has -B option, but choosing other baudrate
than the standard one (115200 Bd) can only work for debug mode, not for
booting the device. The BootROM for kwboot supported platforms (Orion,
Kirkwood, Dove, Discovery, AXP, A37x, A38x, A39x) cannot change the
baudrate when uploading boot image via the Xmodem protocol, nor can it
be configured via strapping pins.
So instead we add this support by injecting baudrate changing code into
the kwbimage v1 header as a new optional binary extension. This code is
executed by BootROM after it receives the whole header. The code sends
the magic string "$baudratechange\0" just before changing the baudrate
to let kwboot know that it should also change it. This is because the
injected code is run as the last binary extension, and we do not want
to loose possible output from other possible binary extensions that
came before it (in most cases this is U-Boot SPL).
We also inject the code before the payload (the data part of the image),
to change the baudrate back to the standard value, in case the payload
does not reset UART.
This change improves boot time via UART significantly (depending on the
chosen baudrate), which is very useful when debugging.
Signed-off-by: Pali Rohár
[ major refactor ]
Signed-off-by: Marek Behún
---
tools/kwboot.c | 617 ++---
1 file changed, 589 insertions(+), 28 deletions(-)
diff --git a/tools/kwboot.c b/tools/kwboot.c
index 6d7d812416..dbe59833eb 100644
--- a/tools/kwboot.c
+++ b/tools/kwboot.c
@@ -70,6 +70,186 @@ struct kwboot_block {
#define KWBOOT_BLK_RSP_TIMEO 1000 /* ms */
#define KWBOOT_HDR_RSP_TIMEO 1 /* ms */
+/* ARM code making baud rate changing function return to _start. */
+static unsigned char kwboot_pre_baud_code[] = {
+ 0xf8, 0xe0, 0x8f, 0xe2, /* adr lr, _start */
+};
+
+/* ARM code for binary header injection to change baudrate */
+static unsigned char kwboot_baud_code[] = {
+ /* ; #define UART_BASE 0xd0012000 */
+ /* ; #define THR 0x00 */
+ /* ; #define DLL 0x00 */
+ /* ; #define DLH 0x04 */
+ /* ; #define LCR 0x0c */
+ /* ; #define DLAB0x80 */
+ /* ; #define LSR 0x14 */
+ /* ; #define THRE0x20 */
+ /* ; #define TEMT0x40 */
+ /* ; #define DIV_ROUND(a, b) ((a + b/2) / b) */
+ /* ; */
+ /* ; u32 set_baudrate(u32 old_b, u32 new_b) { */
+ /* ; const u8 *str = "$baudratechange"; */
+ /* ; u8 c; */
+ /* ; do { */
+ /* ; c = *str++;*/
+ /* ; writel(UART_BASE + THR, c);*/
+ /* ; } while (c); */
+ /* ; while */
+ /* ; (!(readl(UART_BASE + LSR) & TEMT)); */
+ /* ; u32 lcr = readl(UART_BASE + LCR); */
+ /* ; writel(UART_BASE + LCR, lcr | DLAB); */
+ /* ; u8 old_dll = readl(UART_BASE + DLL); */
+ /* ; u8 old_dlh = readl(UART_BASE + DLH); */
+ /* ; u16 old_dl = old_dll | (old_dlh << 8); */
+ /* ; u32 clk = old_b * old_dl; */
+ /* ; u16 new_dl = DIV_ROUND(clk, new_b);*/
+ /* ; u8 new_dll = new_dl & 0xff;*/
+ /* ; u8 new_dlh = (new_dl >> 8) & 0xff; */
+ /* ; writel(UART_BASE + DLL, new_dll); */
+ /* ; writel(UART_BASE + DLH, new_dlh); */
+ /* ; writel(UART_BASE + LCR, lcr & ~DLAB); */
+ /* ; msleep(1); */
+ /* ; return 0; */
+ /* ; }*/
+
+ 0xfe, 0x5f, 0x2d, 0xe9, /* push { r1 - r12, lr }
Re: [PATCH] board: ea: mx7ulp_com: allow setting CONFIG_BOOTCOMMAND in defconfig
On Wed, Aug 25, 2021 at 04:37:49PM +0300, Oleksandr Suvorov wrote:
> From: Ricardo Salveti
>
> Allow replacing the board defined CONFIG_BOOTCOMMAND via defconfig.
>
> Signed-off-by: Ricardo Salveti
> Signed-off-by: Oleksandr Suvorov
> ---
>
> include/configs/mx7ulp_com.h | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/include/configs/mx7ulp_com.h b/include/configs/mx7ulp_com.h
> index 28672c4f94..85ae513ffb 100644
> --- a/include/configs/mx7ulp_com.h
> +++ b/include/configs/mx7ulp_com.h
> @@ -69,10 +69,12 @@
> "bootz ${loadaddr} - ${fdt_addr}; " \
> "fi;\0" \
>
> +#ifndef CONFIG_BOOTCOMMAND
> #define CONFIG_BOOTCOMMAND \
> "if run loadimage; then " \
> "run mmcboot; " \
> "fi; " \
> +#endif
>
> #define CONFIG_SYS_LOAD_ADDR CONFIG_LOADADDR
Please just move this to the defconfig. It's not a long/complex
command, which is the general (understandable) excuse to not migrate it.
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH] board: ea: mx7ulp_com: allocate specific region of memory to OP-TEE
Hi Oleksandr, On Wed, Aug 25, 2021 at 10:37 AM Oleksandr Suvorov wrote: > > From: Ricardo Salveti > > On the iMX7ULP uCOM board, OP-TEE uses the memory region defined by the > maximum DRAM address minus CONFIG_OPTEE_TZDRAM_SIZE, so subtract > CONFIG_OPTEE_TZDRAM_SIZE from the available DRAM size to avoid > conflicts. > > Note the OPTEE boot process itself subtracts the DRAM region it > lives in from the memory map passed to Linux. > > Signed-off-by: Ricardo Salveti You missed adding your own Signed-off-by here. With this fixed: Reviewed-by: Fabio Estevam
[PATCH u-boot-marvell 11/29] tools: kwboot: Split sending image into header and data stages
From: Pali Rohár
This change is required to implement other features in kwboot.
Split sending header and data parts of the image into two stages.
Signed-off-by: Pali Rohár
[ refactored ]
Signed-off-by: Marek Behún
---
tools/kwbimage.h | 8 +++--
tools/kwboot.c | 84 +++-
2 files changed, 61 insertions(+), 31 deletions(-)
diff --git a/tools/kwbimage.h b/tools/kwbimage.h
index e063e3e41e..074bdfbe46 100644
--- a/tools/kwbimage.h
+++ b/tools/kwbimage.h
@@ -195,6 +195,10 @@ struct register_set_hdr_v1 {
#define OPT_HDR_V1_BINARY_TYPE 0x2
#define OPT_HDR_V1_REGISTER_TYPE 0x3
+#define KWBHEADER_V0_SIZE(hdr) \
+ (((hdr)->ext & 0x1) ? sizeof(struct kwb_header) : \
+ sizeof(struct main_hdr_v0))
+
#define KWBHEADER_V1_SIZE(hdr) \
(((hdr)->headersz_msb << 16) | le16_to_cpu((hdr)->headersz_lsb))
@@ -225,9 +229,9 @@ void init_kwb_image_type (void);
* header, byte 8 was reserved, and always set to 0. In the v1 header,
* byte 8 has been changed to a proper field, set to 1.
*/
-static inline unsigned int image_version(void *header)
+static inline unsigned int image_version(const void *header)
{
- unsigned char *ptr = header;
+ const unsigned char *ptr = header;
return ptr[8];
}
diff --git a/tools/kwboot.c b/tools/kwboot.c
index 0e533e3698..7f231c0823 100644
--- a/tools/kwboot.c
+++ b/tools/kwboot.c
@@ -57,11 +57,13 @@ static unsigned char kwboot_msg_debug[] = {
#define NAK21 /* target block negative ack */
#define CAN24 /* target/sender transfer cancellation */
+#define KWBOOT_XM_BLKSZ128 /* xmodem block size */
+
struct kwboot_block {
uint8_t soh;
uint8_t pnum;
uint8_t _pnum;
- uint8_t data[128];
+ uint8_t data[KWBOOT_XM_BLKSZ];
uint8_t csum;
} __packed;
@@ -356,16 +358,15 @@ static size_t
kwboot_xm_makeblock(struct kwboot_block *block, const void *data,
size_t size, int pnum)
{
- const size_t blksz = sizeof(block->data);
size_t i, n;
block->soh = SOH;
block->pnum = pnum;
block->_pnum = ~block->pnum;
- n = size < blksz ? size : blksz;
+ n = size < KWBOOT_XM_BLKSZ ? size : KWBOOT_XM_BLKSZ;
memcpy(&block->data[0], data, n);
- memset(&block->data[n], 0, blksz - n);
+ memset(&block->data[n], 0, KWBOOT_XM_BLKSZ - n);
block->csum = 0;
for (i = 0; i < n; i++)
@@ -425,48 +426,73 @@ kwboot_xm_sendblock(int fd, struct kwboot_block *block)
}
static int
-kwboot_xmodem(int tty, const void *_data, size_t size)
+kwboot_xmodem_one(int tty, int *pnum, int header, const uint8_t *data,
+ size_t size)
{
- const uint8_t *data = _data;
- int rc, pnum, N, err;
-
- pnum = 1;
- N = 0;
+ size_t sent, left;
+ int rc;
- kwboot_printv("Sending boot image...\n");
+ kwboot_printv("Sending boot image %s (%zu bytes)...\n",
+ header ? "header" : "data", size);
- sleep(2); /* flush isn't effective without it */
- tcflush(tty, TCIOFLUSH);
+ left = size;
+ sent = 0;
- do {
+ while (sent < size) {
struct kwboot_block block;
- int n;
+ size_t blksz;
- n = kwboot_xm_makeblock(&block,
- data + N, size - N,
- pnum++);
- if (!n)
- break;
+ blksz = kwboot_xm_makeblock(&block, data, left, (*pnum)++);
+ data += blksz;
rc = kwboot_xm_sendblock(tty, &block);
if (rc)
goto out;
- N += n;
- kwboot_progress(N * 100 / size, '.');
- } while (1);
+ sent += blksz;
+ left -= blksz;
+
+ kwboot_progress(sent * 100 / size, '.');
+ }
- rc = kwboot_tty_send_char(tty, EOT);
+ kwboot_printv("Done\n");
+ return 0;
out:
kwboot_printv("\n");
return rc;
+}
-can:
- err = errno;
- kwboot_tty_send_char(tty, CAN);
- errno = err;
- goto out;
+static int
+kwboot_xmodem(int tty, const void *_img, size_t size)
+{
+ const uint8_t *img = _img;
+ int rc, pnum;
+ size_t hdrsz;
+
+ if (image_version(img) == 0)
+ hdrsz = KWBHEADER_V0_SIZE((struct main_hdr_v0 *)img);
+ else
+ hdrsz = KWBHEADER_V1_SIZE((struct main_hdr_v1 *)img);
+
+ kwboot_printv("Waiting 2s and flushing tty\n");
+ sleep(2); /* flush isn't effective without it */
+ tcflush(tty, TCIOFLUSH);
+
+ pnum = 1;
+
+ rc = kwboot_xmodem_one(tty, &pnum, 1, img, hdrsz);
+ if (rc)
+ return rc;
+
+ img += hdrsz;
+ size -= hdrsz;
+
+ rc = kwboot_xmodem_one(tty, &pnum, 0, img, siz
[PATCH u-boot-marvell 07/29] tools: kwboot: Fix return type of kwboot_xm_makeblock() function
From: Pali Rohár
Function kwboot_xm_makeblock() always returns length of xmodem block. It
is always non-negative and calculated from variable with size_t type. Set
return type of this function to size_t and remove dead code which checks
for negative value.
Signed-off-by: Pali Rohár
Reviewed-by: Marek Behún
---
tools/kwboot.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/tools/kwboot.c b/tools/kwboot.c
index b9a402ca91..88353d19c0 100644
--- a/tools/kwboot.c
+++ b/tools/kwboot.c
@@ -347,7 +347,7 @@ kwboot_debugmsg(int tty, void *msg)
return rc;
}
-static int
+static size_t
kwboot_xm_makeblock(struct kwboot_block *block, const void *data,
size_t size, int pnum)
{
@@ -441,9 +441,6 @@ kwboot_xmodem(int tty, const void *_data, size_t size)
n = kwboot_xm_makeblock(&block,
data + N, size - N,
pnum++);
- if (n < 0)
- goto can;
-
if (!n)
break;
--
2.31.1
[PATCH u-boot-marvell 16/29] tools: kwboot: Properly finish xmodem transfer
From: Pali Rohár
After kwboot sends EOT, BootROM sends back ACK. Add code for handling
this and retry sending EOT on error.
Signed-off-by: Pali Rohár
[ refactored ]
Signed-off-by: Marek Behún
---
tools/kwboot.c | 65 +-
1 file changed, 48 insertions(+), 17 deletions(-)
diff --git a/tools/kwboot.c b/tools/kwboot.c
index 0e60cc8a70..6674a253ff 100644
--- a/tools/kwboot.c
+++ b/tools/kwboot.c
@@ -383,6 +383,28 @@ _is_xm_reply(char c)
return c == ACK || c == NAK || c == CAN;
}
+static int
+_xm_reply_to_error(int c) {
+ int rc = -1;
+
+ switch (c) {
+ case ACK:
+ rc = 0;
+ break;
+ case NAK:
+ errno = EBADMSG;
+ break;
+ case CAN:
+ errno = ECANCELED;
+ break;
+ default:
+ errno = EPROTO;
+ break;
+ }
+
+ return rc;
+}
+
static uint64_t
_now(void)
{
@@ -463,24 +485,32 @@ kwboot_xm_sendblock(int fd, struct kwboot_block *block,
int allow_non_xm,
return -1;
}
- rc = -1;
+ return _xm_reply_to_error(c);
+}
- switch (c) {
- case ACK:
- rc = 0;
- break;
- case NAK:
- errno = EBADMSG;
- break;
- case CAN:
- errno = ECANCELED;
- break;
- default:
- errno = EPROTO;
- break;
- }
+static int
+kwboot_xm_finish(int tty)
+{
+ int rc, retries;
+ char c;
- return rc;
+ retries = 16;
+ do {
+ rc = kwboot_tty_send_char(tty, EOT);
+ if (rc)
+ return rc;
+
+ do {
+ rc = kwboot_tty_recv(tty, &c, 1, blk_rsp_timeo);
+ if (rc) {
+ if (errno != ETIMEDOUT)
+ return rc;
+ c = NAK;
+ }
+ } while (!_is_xm_reply(c) && retries-- > 0);
+ } while (c == NAK && retries-- > 0);
+
+ return _xm_reply_to_error(c);
}
static int
@@ -557,7 +587,8 @@ kwboot_xmodem(int tty, const void *_img, size_t size)
if (rc)
return rc;
- return kwboot_tty_send_char(tty, EOT);
+ kwboot_printv("Finishing transfer\n");
+ return kwboot_xm_finish(tty);
}
static int
--
2.31.1
[PATCH] Kconfig: Don't use RSA_FREESCALE_EXP on MX7ULP
From: Ricardo Salveti
The CAAM on IMX7ULP doesn't support public key hardware acceleration
(PKHA), as in other NXP parts. Disable RSA_FREESCALE_EXP for IMX7ULP
too.
Fixed: f4e9ff7135 ("Kconfig: Don't use RSA_FREESCALE_EXP on IMX")
Signed-off-by: Ricardo Salveti
Signed-off-by: Oleksandr Suvorov
---
lib/rsa/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/rsa/Kconfig b/lib/rsa/Kconfig
index a90d67e5a8..55e17596f0 100644
--- a/lib/rsa/Kconfig
+++ b/lib/rsa/Kconfig
@@ -1,6 +1,6 @@
config RSA
bool "Use RSA Library"
- select RSA_FREESCALE_EXP if FSL_CAAM && !ARCH_MX7 && !ARCH_MX6 &&
!ARCH_MX5
+ select RSA_FREESCALE_EXP if FSL_CAAM && !ARCH_MX7 && !ARCH_MX7ULP &&
!ARCH_MX6 && !ARCH_MX5
select RSA_SOFTWARE_EXP if !RSA_FREESCALE_EXP
help
RSA support. This enables the RSA algorithm used for FIT image
--
2.31.1
incompatible device trees between u-boot and linux
Hi,
I noticed that there is a fallback to the u-boot device tree for linux
(esp. EFI boot) if no other device tree was found, see [1]. It seems
this
is working fine for imx devices, for example, where you can just boot a
stock installer iso via EFI. It will just work and it is quite a nice
feature as a fallback.
Now for the layerscape architecture, the ls1028a in my case, things are
more difficult because the bindings differ between u-boot and linux -
one
which comes to mind is DSA and ethernet.
Which begs the general question, is it encouraged to have both bindings
diverge? To me it seems, that most bindings in u-boot are ad-hoc and
there
is no real review or alignment but just added as needed, which is ok if
they are local to u-boot. But since they are nowadays passed to linux
(by default!) I'm not so sure anymore.
OTOH The whole structure around a .dts{,i} and -u-boot.dtsi looks like
they should (could?) be shared between linux and u-boot.
-michael
[1]
https://elixir.bootlin.com/u-boot/v2021.10-rc2/source/common/board_r.c#L471
Re: incompatible device trees between u-boot and linux
On Wed, Aug 25, 2021 at 03:58:10PM +0200, Michael Walle wrote:
> Hi,
>
> I noticed that there is a fallback to the u-boot device tree for linux
> (esp. EFI boot) if no other device tree was found, see [1]. It seems this
> is working fine for imx devices, for example, where you can just boot a
> stock installer iso via EFI. It will just work and it is quite a nice
> feature as a fallback.
>
> Now for the layerscape architecture, the ls1028a in my case, things are
> more difficult because the bindings differ between u-boot and linux - one
> which comes to mind is DSA and ethernet.
>
> Which begs the general question, is it encouraged to have both bindings
> diverge? To me it seems, that most bindings in u-boot are ad-hoc and there
> is no real review or alignment but just added as needed, which is ok if
> they are local to u-boot. But since they are nowadays passed to linux
> (by default!) I'm not so sure anymore.
>
> OTOH The whole structure around a .dts{,i} and -u-boot.dtsi looks like
> they should (could?) be shared between linux and u-boot.
>
> -michael
>
> [1]
> https://elixir.bootlin.com/u-boot/v2021.10-rc2/source/common/board_r.c#L471
The U-Boot device tree is supposed to be able to be passed on to Linux
and Just Work. The bindings are not supposed to be different between
the two (except for when we take the binding while it's being hashed out
upstream BUT THEN RESYNCED). Incompatible device trees / bindings are a
bug that needs to be fixed.
--
Tom
signature.asc
Description: PGP signature
Re: Pull request: SoCFPGA changes for efi-2021-10-rc3
On Wed, Aug 25, 2021 at 11:15:08AM +, Chee, Tien Fong wrote: > Hi Tom > > Please pull the SoCFPGA changes for efi-2021-10-rc3. > > Regards > Tien Fong > > The following changes since commit 4865db07169126ca0205f1a6265adf01bd69b3df: > > Merge tag 'efi-2021-10-rc3' of > https://source.denx.de/u-boot/custodians/u-boot-efi (2021-08-23 12:44:12 > -0400) > > are available in the Git repository at: > > https://github.com/tienfong/uboot_mainline.git next-socfpga > > for you to fetch changes up to 31b51cb1d2b4114085cb5565502d39d6f6daa2a7: > > arm: socfpga: Enable Intel N5X device build (2021-08-25 15:26:38 +0800) > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] Kconfig: Don't use RSA_FREESCALE_EXP on MX7ULP
On Wed, Aug 25, 2021 at 04:56:51PM +0300, Oleksandr Suvorov wrote:
> From: Ricardo Salveti
>
> The CAAM on IMX7ULP doesn't support public key hardware acceleration
> (PKHA), as in other NXP parts. Disable RSA_FREESCALE_EXP for IMX7ULP
> too.
>
> Fixed: f4e9ff7135 ("Kconfig: Don't use RSA_FREESCALE_EXP on IMX")
> Signed-off-by: Ricardo Salveti
> Signed-off-by: Oleksandr Suvorov
> ---
>
> lib/rsa/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/lib/rsa/Kconfig b/lib/rsa/Kconfig
> index a90d67e5a8..55e17596f0 100644
> --- a/lib/rsa/Kconfig
> +++ b/lib/rsa/Kconfig
> @@ -1,6 +1,6 @@
> config RSA
> bool "Use RSA Library"
> - select RSA_FREESCALE_EXP if FSL_CAAM && !ARCH_MX7 && !ARCH_MX6 &&
> !ARCH_MX5
> + select RSA_FREESCALE_EXP if FSL_CAAM && !ARCH_MX7 && !ARCH_MX7ULP &&
> !ARCH_MX6 && !ARCH_MX5
> select RSA_SOFTWARE_EXP if !RSA_FREESCALE_EXP
> help
> RSA support. This enables the RSA algorithm used for FIT image
What iMX families does this work on? I think we need to look at fixing
the logic to be a bit more restrictive to start with, instead of opting
families out.
--
Tom
signature.asc
Description: PGP signature
Re: incompatible device trees between u-boot and linux
On Wed, Aug 25, 2021 at 10:00:45AM -0400, Tom Rini wrote:
> On Wed, Aug 25, 2021 at 03:58:10PM +0200, Michael Walle wrote:
>
> > Hi,
> >
> > I noticed that there is a fallback to the u-boot device tree for linux
> > (esp. EFI boot) if no other device tree was found, see [1]. It seems this
> > is working fine for imx devices, for example, where you can just boot a
> > stock installer iso via EFI. It will just work and it is quite a nice
> > feature as a fallback.
> >
> > Now for the layerscape architecture, the ls1028a in my case, things are
> > more difficult because the bindings differ between u-boot and linux - one
> > which comes to mind is DSA and ethernet.
> >
> > Which begs the general question, is it encouraged to have both bindings
> > diverge? To me it seems, that most bindings in u-boot are ad-hoc and there
> > is no real review or alignment but just added as needed, which is ok if
> > they are local to u-boot. But since they are nowadays passed to linux
> > (by default!) I'm not so sure anymore.
> >
> > OTOH The whole structure around a .dts{,i} and -u-boot.dtsi looks like
> > they should (could?) be shared between linux and u-boot.
> >
> > -michael
> >
> > [1]
> > https://elixir.bootlin.com/u-boot/v2021.10-rc2/source/common/board_r.c#L471
>
> The U-Boot device tree is supposed to be able to be passed on to Linux
> and Just Work. The bindings are not supposed to be different between
> the two (except for when we take the binding while it's being hashed out
> upstream BUT THEN RESYNCED).
You might need to spell that out a bit clearer.
You are saying that both U-Boot and Linux are allowed to have their own
custom properties (like 'u-boot,dm-spl' for U-Boot, and 'managed =
"in-band-status"'
for Linux), as long as the device tree files themselves are in sync, and
the subset of the device tree blob understood by Linux (i.e. the U-Boot
blob sans the U-Boot specifics) is compatible with the Linux DT blob?
To expand even further on that, it means we should put 'managed =
"in-band-status"'
in U-Boot, which is a Linux phylink device tree property, even if U-Boot
does not use phylink?
> Incompatible device trees / bindings are a
> bug that needs to be fixed.
Curious that Michael mentions Ethernet and DSA on LS1028A.
I decompiled the two:
dtc -I dtb -O dts < arch/arm/dts/fsl-ls1028a-rdb.dtb > u-boot.dts
dtc -I dtb -O dts < arch/arm64/boot/dts/freescale/fsl-ls1028a-rdb.dtb >
linux.dts
and analyzed the Ethernet portion.
U-Boot looks like this:
/dts-v1/;
/ {
compatible = "fsl,ls1028a-rdb", "fsl,ls1028a";
interrupt-parent = <0x1>;
#address-cells = <0x2>;
#size-cells = <0x2>;
model = "NXP Layerscape 1028a RDB Board";
pcie@1f000 {
compatible = "pci-host-ecam-generic";
bus-range = <0x0 0x0>;
reg = <0x1 0xf000 0x0 0x10>;
#address-cells = <0x3>;
#size-cells = <0x2>;
device_type = "pci";
ranges = <0x8200 0x0 0x0 0x1 0xf800 0x0 0x16>;
pci@0,0 {
reg = <0x0 0x0 0x0 0x0 0x0>;
status = "okay";
phy-mode = "sgmii";
phy-handle = <0x4>;
phandle = <0x11>;
};
pci@0,1 {
reg = <0x100 0x0 0x0 0x0 0x0>;
status = "disabled";
phandle = <0x12>;
};
pci@0,2 {
reg = <0x200 0x0 0x0 0x0 0x0>;
status = "okay";
phy-mode = "internal";
phandle = <0x9>;
fixed-link {
speed = <0x9c4>;
full-duplex;
};
};
pci@0,3 {
#address-cells = <0x0>;
#size-cells = <0x1>;
reg = <0x300 0x0 0x0 0x0 0x0>;
status = "okay";
phandle = <0x13>;
fixed-link {
speed = <0x3e8>;
full-duplex;
};
phy@2 {
reg = <0x2>;
phandle = <0x4>;
};
phy@10 {
reg = <0x10>;
phandle = <0x5>;
};
phy@11 {
reg = <0x11>;
phandle = <0x6>;
};
phy@12 {
reg = <0x12>;
phandle = <0x7>;
};
phy@13 {
Re: incompatible device trees between u-boot and linux
On Wed, Aug 25, 2021 at 05:18:16PM +0300, Vladimir Oltean wrote:
> On Wed, Aug 25, 2021 at 10:00:45AM -0400, Tom Rini wrote:
> > On Wed, Aug 25, 2021 at 03:58:10PM +0200, Michael Walle wrote:
> >
> > > Hi,
> > >
> > > I noticed that there is a fallback to the u-boot device tree for linux
> > > (esp. EFI boot) if no other device tree was found, see [1]. It seems this
> > > is working fine for imx devices, for example, where you can just boot a
> > > stock installer iso via EFI. It will just work and it is quite a nice
> > > feature as a fallback.
> > >
> > > Now for the layerscape architecture, the ls1028a in my case, things are
> > > more difficult because the bindings differ between u-boot and linux - one
> > > which comes to mind is DSA and ethernet.
> > >
> > > Which begs the general question, is it encouraged to have both bindings
> > > diverge? To me it seems, that most bindings in u-boot are ad-hoc and there
> > > is no real review or alignment but just added as needed, which is ok if
> > > they are local to u-boot. But since they are nowadays passed to linux
> > > (by default!) I'm not so sure anymore.
> > >
> > > OTOH The whole structure around a .dts{,i} and -u-boot.dtsi looks like
> > > they should (could?) be shared between linux and u-boot.
> > >
> > > -michael
> > >
> > > [1]
> > > https://elixir.bootlin.com/u-boot/v2021.10-rc2/source/common/board_r.c#L471
> >
> > The U-Boot device tree is supposed to be able to be passed on to Linux
> > and Just Work. The bindings are not supposed to be different between
> > the two (except for when we take the binding while it's being hashed out
> > upstream BUT THEN RESYNCED).
>
> You might need to spell that out a bit clearer.
>
> You are saying that both U-Boot and Linux are allowed to have their own
> custom properties (like 'u-boot,dm-spl' for U-Boot, and 'managed =
> "in-band-status"'
> for Linux), as long as the device tree files themselves are in sync, and
> the subset of the device tree blob understood by Linux (i.e. the U-Boot
> blob sans the U-Boot specifics) is compatible with the Linux DT blob?
I don't know what about the Linux example makes it Linux specific. But
yes, 'u-boot,dm-spl' is clearly in our namespace and should be ignored
by Linux. The whole reason we have the -u-boot.dtsi automatic drop-in
logic (as much as it can be used is that device trees are device trees
and describe the hardware and developers don't need to write a device
tree for Linux and a device tree for U-Boot and a device tree for
FreeBSD and ... So yes, you're supposed to use the device tree for a
platform and it works here and there and every where.
> To expand even further on that, it means we should put 'managed =
> "in-band-status"'
> in U-Boot, which is a Linux phylink device tree property, even if U-Boot
> does not use phylink?
We should be able to drop in the device trees from Linux and use them.
Custodians should be re-syncing them periodically. Some are, even.
> > Incompatible device trees / bindings are a
> > bug that needs to be fixed.
>
> Curious that Michael mentions Ethernet and DSA on LS1028A.
>
> I decompiled the two:
>
> dtc -I dtb -O dts < arch/arm/dts/fsl-ls1028a-rdb.dtb > u-boot.dts
> dtc -I dtb -O dts < arch/arm64/boot/dts/freescale/fsl-ls1028a-rdb.dtb >
> linux.dts
>
> and analyzed the Ethernet portion.
>
> U-Boot looks like this:
>
> /dts-v1/;
>
> / {
> compatible = "fsl,ls1028a-rdb", "fsl,ls1028a";
> interrupt-parent = <0x1>;
> #address-cells = <0x2>;
> #size-cells = <0x2>;
> model = "NXP Layerscape 1028a RDB Board";
>
> pcie@1f000 {
> compatible = "pci-host-ecam-generic";
> bus-range = <0x0 0x0>;
> reg = <0x1 0xf000 0x0 0x10>;
> #address-cells = <0x3>;
> #size-cells = <0x2>;
> device_type = "pci";
> ranges = <0x8200 0x0 0x0 0x1 0xf800 0x0 0x16>;
>
> pci@0,0 {
> reg = <0x0 0x0 0x0 0x0 0x0>;
> status = "okay";
> phy-mode = "sgmii";
> phy-handle = <0x4>;
> phandle = <0x11>;
> };
>
> pci@0,1 {
> reg = <0x100 0x0 0x0 0x0 0x0>;
> status = "disabled";
> phandle = <0x12>;
> };
>
> pci@0,2 {
> reg = <0x200 0x0 0x0 0x0 0x0>;
> status = "okay";
> phy-mode = "internal";
> phandle = <0x9>;
>
> fixed-link {
> speed = <0x9c4>;
> full-duplex;
> };
> };
>
> pci@0,3 {
> #address-cells = <0x0>;
> #size-cells = <0x1>;
> reg = <0x300 0x0 0x0 0x0 0x0>;
>
[PATCH] ARM: at91: remove references to RM9200DK
The AT91 RM9200DK board was removed long time ago.
Remove existing references that were not cleaned up.
Fixes: 1c85752258 ("ARM: remove broken "at91rm9200dk" board")
Signed-off-by: Eugen Hristev
---
arch/arm/cpu/arm920t/start.S | 14 --
arch/arm/include/asm/mach-types.h | 1 -
2 files changed, 15 deletions(-)
diff --git a/arch/arm/cpu/arm920t/start.S b/arch/arm/cpu/arm920t/start.S
index e2b5f2bff4..32190369f7 100644
--- a/arch/arm/cpu/arm920t/start.S
+++ b/arch/arm/cpu/arm920t/start.S
@@ -35,20 +35,6 @@ reset:
orr r0, r0, #0xd3
msr cpsr, r0
-#ifdefined(CONFIG_AT91RM9200DK)
- /*
-* relocate exception table
-*/
- ldr r0, =_start
- ldr r1, =0x0
- mov r2, #16
-copyex:
- subsr2, r2, #1
- ldr r3, [r0], #4
- str r3, [r1], #4
- bne copyex
-#endif
-
/*
* we do sys-critical inits only at reboot,
* not when booting from ram!
diff --git a/arch/arm/include/asm/mach-types.h
b/arch/arm/include/asm/mach-types.h
index 32532b3ca4..2713b1d2c5 100644
--- a/arch/arm/include/asm/mach-types.h
+++ b/arch/arm/include/asm/mach-types.h
@@ -267,7 +267,6 @@
#define MACH_TYPE_BMS 259
#define MACH_TYPE_IXCDP1100260
#define MACH_TYPE_PRPMC1100261
-#define MACH_TYPE_AT91RM9200DK 262
#define MACH_TYPE_ARMSTICK 263
#define MACH_TYPE_ARMONIE 264
#define MACH_TYPE_MPORT1 265
--
2.25.1
[PATCH] net: remove unused CONFIG_DRIVER_AT91EMAC_*
AT91EMAC driver is unused, thus removing.
Signed-off-by: Eugen Hristev
---
README | 11 -
drivers/net/Makefile | 1 -
drivers/net/at91_emac.c | 519 ---
include/netdev.h | 1 -
scripts/config_whitelist.txt | 2 -
5 files changed, 534 deletions(-)
delete mode 100644 drivers/net/at91_emac.c
diff --git a/README b/README
index 1c1db98098..18e116c36f 100644
--- a/README
+++ b/README
@@ -879,17 +879,6 @@ The following options need to be configured:
Support for National dp8382[01] gigabit chips.
- NETWORK Support (other):
-
- CONFIG_DRIVER_AT91EMAC
- Support for AT91RM9200 EMAC.
-
- CONFIG_RMII
- Define this to use reduced MII inteface
-
- CONFIG_DRIVER_AT91EMAC_QUIET
- If this defined, the driver is quiet.
- The driver doen't show link status messages.
-
CONFIG_CALXEDA_XGMAC
Support for the Calxeda XGMAC device
diff --git a/drivers/net/Makefile b/drivers/net/Makefile
index b94ccea100..2685da7c13 100644
--- a/drivers/net/Makefile
+++ b/drivers/net/Makefile
@@ -9,7 +9,6 @@ obj-$(CONFIG_ARMADA100_FEC) += armada100_fec.o
obj-$(CONFIG_BCM6348_ETH) += bcm6348-eth.o
obj-$(CONFIG_BCM6368_ETH) += bcm6368-eth.o
obj-$(CONFIG_BCMGENET) += bcmgenet.o
-obj-$(CONFIG_DRIVER_AT91EMAC) += at91_emac.o
obj-$(CONFIG_DRIVER_AX88180) += ax88180.o
obj-$(CONFIG_BCM_SF2_ETH) += bcm-sf2-eth.o
obj-$(CONFIG_BCM_SF2_ETH_GMAC) += bcm-sf2-eth-gmac.o
diff --git a/drivers/net/at91_emac.c b/drivers/net/at91_emac.c
deleted file mode 100644
index e40b94ad89..00
--- a/drivers/net/at91_emac.c
+++ /dev/null
@@ -1,519 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0+
-/*
- * Copyright (C) 2009 BuS Elektronik GmbH & Co. KG
- * Jens Scharsig (e...@bus-elektronik.de)
- *
- * (C) Copyright 2003
- * Author : Hamid Ikdoumi (Atmel)
- */
-
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-
-#undef MII_DEBUG
-#undef ET_DEBUG
-
-#if (CONFIG_SYS_RX_ETH_BUFFER > 1024)
-#error AT91 EMAC supports max 1024 RX buffers. \
- Please decrease the CONFIG_SYS_RX_ETH_BUFFER value
-#endif
-
-#ifndef CONFIG_DRIVER_AT91EMAC_PHYADDR
-#define CONFIG_DRIVER_AT91EMAC_PHYADDR 0
-#endif
-
-/* MDIO clock must not exceed 2.5 MHz, so enable MCK divider */
-#if (AT91C_MASTER_CLOCK > 8000)
- #define HCLK_DIVAT91_EMAC_CFG_MCLK_64
-#elif (AT91C_MASTER_CLOCK > 4000)
- #define HCLK_DIVAT91_EMAC_CFG_MCLK_32
-#elif (AT91C_MASTER_CLOCK > 2000)
- #define HCLK_DIVAT91_EMAC_CFG_MCLK_16
-#else
- #define HCLK_DIVAT91_EMAC_CFG_MCLK_8
-#endif
-
-#ifdef ET_DEBUG
-#define DEBUG_AT91EMAC 1
-#else
-#define DEBUG_AT91EMAC 0
-#endif
-
-#ifdef MII_DEBUG
-#define DEBUG_AT91PHY 1
-#else
-#define DEBUG_AT91PHY 0
-#endif
-
-#ifndef CONFIG_DRIVER_AT91EMAC_QUIET
-#define VERBOSEP 1
-#else
-#define VERBOSEP 0
-#endif
-
-#define RBF_ADDR 0xfffc
-#define RBF_OWNER (1<<0)
-#define RBF_WRAP (1<<1)
-#define RBF_BROADCAST (1<<31)
-#define RBF_MULTICAST (1<<30)
-#define RBF_UNICAST (1<<29)
-#define RBF_EXTERNAL (1<<28)
-#define RBF_UNKNOWN (1<<27)
-#define RBF_SIZE 0x07ff
-#define RBF_LOCAL4(1<<26)
-#define RBF_LOCAL3(1<<25)
-#define RBF_LOCAL2(1<<24)
-#define RBF_LOCAL1(1<<23)
-
-#define RBF_FRAMEMAX CONFIG_SYS_RX_ETH_BUFFER
-#define RBF_FRAMELEN 0x600
-
-typedef struct {
- unsigned long addr, size;
-} rbf_t;
-
-typedef struct {
- rbf_t rbfdt[RBF_FRAMEMAX];
- unsigned long rbindex;
-} emac_device;
-
-void at91emac_EnableMDIO(at91_emac_t *at91mac)
-{
- /* Mac CTRL reg set for MDIO enable */
- writel(readl(&at91mac->ctl) | AT91_EMAC_CTL_MPE, &at91mac->ctl);
-}
-
-void at91emac_DisableMDIO(at91_emac_t *at91mac)
-{
- /* Mac CTRL reg set for MDIO disable */
- writel(readl(&at91mac->ctl) & ~AT91_EMAC_CTL_MPE, &at91mac->ctl);
-}
-
-int at91emac_read(at91_emac_t *at91mac, unsigned char addr,
- unsigned char reg, unsigned short *value)
-{
- unsigned long netstat;
- at91emac_EnableMDIO(at91mac);
-
- writel(AT91_EMAC_MAN_HIGH | AT91_EMAC_MAN_RW_R |
- AT91_EMAC_MAN_REGA(reg) | AT91_EMAC_MAN_CODE_802_3 |
- AT91_EMAC_MAN_PHYA(addr),
- &at91mac->man);
-
- do {
- netstat = readl(&at91mac->sr);
- debug_cond(DEBUG_AT91PHY, "poll SR %08lx\n", netstat);
- } while (!(netstat & AT91_EMAC_SR_IDLE));
-
- *value = readl(&at91mac->man) & AT91_EMAC_MAN_DATA_MASK;
-
- at91emac_DisableMDIO(at91mac);
-
- debug_cond(DEBUG_AT91PHY,
- "AT91PHY read %p REG(%d)=%x\n", at91mac, reg, *value);
-
- return 0;
-}
-
-int at91emac_write(at91_emac_t *at
Re: incompatible device trees between u-boot and linux
Am 2021-08-25 16:18, schrieb Vladimir Oltean: Curious that Michael mentions Ethernet and DSA on LS1028A. [..] I mean, they look pretty similar to me? The biggest difference is that the ENETC ECAM is under the /soc node in Linux, but under / in U-Boot, as well as some BAR memory areas that are not marked as prefetchable or non-prefetchable in the U-Boot device tree. But excuse me, that isn't an Ethernet/DSA problem, is it? Mh, you're right. I had something in mind you've mentioned during the initial DSA patches for u-boot. I must have remembered incorrectly. My intention was to have a clear message if the u-boot device tree should be following the linux one before I'm digging deeper into what is different between these two and try to sync both. -michael
Re: [PATCH 00/28] Initial implementation of bootmethod/bootflow
Simon, On Wed, Aug 25, 2021 at 07:11:44AM -0600, Simon Glass wrote: > Hi, > > On Wed, 25 Aug 2021 at 04:45, Emmanuel Vadot wrote: > > > > On Tue, 24 Aug 2021 12:22:42 +0200 (CEST) > > Mark Kettenis wrote: > > > > > > Date: Mon, 23 Aug 2021 16:01:46 -0400 > > > > From: Tom Rini > > > > > > > > On Mon, Aug 23, 2021 at 11:25:42AM -0600, Simon Glass wrote: > > > > > Hi Mark, > > > > > > > > > > On Mon, 23 Aug 2021 at 05:54, Mark Kettenis > > > > > wrote: > > > > > > > > > > > > > From: Simon Glass > > > > > > > Date: Wed, 18 Aug 2021 21:45:33 -0600 > > > > > > > > > > > > > > Bootmethod and bootflow provide a built-in way for U-Boot to > > > > > > > automatically boot > > > > > > > an Operating System without custom scripting and other > > > > > > > customisation: > > > > > > > > > > > > > > - bootmethod - a method to scan a device to find bootflows > > > > > > > (owned by U-Boot) > > > > > > > - bootflow - a description of how to boot (owned by the distro) > > > > > > > > > > > > > > This series provides an initial implementation of these, enable > > > > > > > to scan > > > > > > > for bootflows from MMC and Ethernet. The only bootflow supported > > > > > > > is > > > > > > > distro boot, i.e. an extlinux.conf file included on a filesystem > > > > > > > or > > > > > > > tftp server. It works similiarly to the existing script-based > > > > > > > approach, > > > > > > > but is native to U-Boot. > > > > > > > > > > > > > > With this we can boot on a Raspberry Pi 3 with just one command: > > > > > > > > > > > > > >bootflow scan -lb > > > > > > > > > > > > > > which means to scan, listing (-l) each bootflow and trying to > > > > > > > boot each > > > > > > > one (-b). The final patch shows this. > > > > > > > > > > > > > > It is intended that this approach be expanded to support > > > > > > > mechanisms other > > > > > > > than distro boot, including EFI-related ones. With a standard way > > > > > > > to > > > > > > > identify boot devices, these features become easier. It also > > > > > > > should > > > > > > > support U-Boot scripts, for backwards compatibility only. > > > > > > > > > > > > > > The first patch of this series moves boot-related code out of > > > > > > > common/ and > > > > > > > into a new boot/ directory. This helps to collect these related > > > > > > > files > > > > > > > in one place, as common/ is quite large. > > > > > > > > > > > > > > Like sysboot, this feature makes use of the existing PXE > > > > > > > implementation. > > > > > > > Much of this series consists of cleaning up that code and > > > > > > > refactoring it > > > > > > > into something closer to a module that can be called, teasing > > > > > > > apart its > > > > > > > reliance on the command-line interpreter to access filesystems > > > > > > > and the > > > > > > > like. Also it now uses function arguments and its own context > > > > > > > struct > > > > > > > internally rather than environment variables, which is very hard > > > > > > > to > > > > > > > follow. No core functional change is included in the included PXE > > > > > > > patches. > > > > > > > > > > > > > > For documentation, see the 'doc' patch. > > > > > > > > > > > > > > There is quite a long list of future work included in the > > > > > > > documentation. > > > > > > > One question is the choice of naming. Since this is a bootloader, > > > > > > > should > > > > > > > we just call this a 'method' and a 'flow' ? The 'boot' prefix is > > > > > > > already > > > > > > > shared by other commands like bootm, booti, etc. > > > > > > > > > > > > > > The design is described here: > > > > > > > > > > > > > > https://drive.google.com/file/d/1ggW0KJpUOR__vBkj3l61L2dav4ZkNC12/view?usp=sharing > > > > > > > > > > > > > > The series is available at u-boot-dm/bmea-working > > > > > > > > > > > > How does the user control the order in which devices are > > > > > > scanned/booted? > > > > > > > > > > That is not supported in distroboot at present, at least so far as I > > > > > can see. For Fedora it seems to happen in grub. Do I have that right? > > > > > > > > Well, there's "find the next stage", which is boot_targets environment > > > > variable, and then "where that next stage looks for stuff" which is > > > > OS-dependent. Sometimes the ESP grub.cfg file is just enough to tell > > > > grub to find the full grub.cfg file elsewhere, and sometimes it's a full > > > > grub.cfg file. I think Mark is talking about the former, and you've > > > > said it's not part of this series, yet, but on the TODO list. > > > > > > Right. With the current distroboot code the order of the devices that > > > appears in boot_targets is determined by per-board/SOC/machine config > > > files and the order isn't the same for all of them. Users can change > > > the order if necessary by modifying the environment variable and > > > saving the environment. And for a one-off boot from a different > > > device they can simply run an appropriate boot command.
Re: [PATCH 00/28] Initial implementation of bootmethod/bootflow
On Wed, Aug 25, 2021 at 11:42:51PM +0900, AKASHI Takahiro wrote: > Simon, > > On Wed, Aug 25, 2021 at 07:11:44AM -0600, Simon Glass wrote: > > Hi, > > > > On Wed, 25 Aug 2021 at 04:45, Emmanuel Vadot wrote: > > > > > > On Tue, 24 Aug 2021 12:22:42 +0200 (CEST) > > > Mark Kettenis wrote: > > > > > > > > Date: Mon, 23 Aug 2021 16:01:46 -0400 > > > > > From: Tom Rini > > > > > > > > > > On Mon, Aug 23, 2021 at 11:25:42AM -0600, Simon Glass wrote: > > > > > > Hi Mark, > > > > > > > > > > > > On Mon, 23 Aug 2021 at 05:54, Mark Kettenis > > > > > > wrote: > > > > > > > > > > > > > > > From: Simon Glass > > > > > > > > Date: Wed, 18 Aug 2021 21:45:33 -0600 > > > > > > > > > > > > > > > > Bootmethod and bootflow provide a built-in way for U-Boot to > > > > > > > > automatically boot > > > > > > > > an Operating System without custom scripting and other > > > > > > > > customisation: > > > > > > > > > > > > > > > > - bootmethod - a method to scan a device to find bootflows > > > > > > > > (owned by U-Boot) > > > > > > > > - bootflow - a description of how to boot (owned by the > > > > > > > > distro) > > > > > > > > > > > > > > > > This series provides an initial implementation of these, enable > > > > > > > > to scan > > > > > > > > for bootflows from MMC and Ethernet. The only bootflow > > > > > > > > supported is > > > > > > > > distro boot, i.e. an extlinux.conf file included on a > > > > > > > > filesystem or > > > > > > > > tftp server. It works similiarly to the existing script-based > > > > > > > > approach, > > > > > > > > but is native to U-Boot. > > > > > > > > > > > > > > > > With this we can boot on a Raspberry Pi 3 with just one command: > > > > > > > > > > > > > > > >bootflow scan -lb > > > > > > > > > > > > > > > > which means to scan, listing (-l) each bootflow and trying to > > > > > > > > boot each > > > > > > > > one (-b). The final patch shows this. > > > > > > > > > > > > > > > > It is intended that this approach be expanded to support > > > > > > > > mechanisms other > > > > > > > > than distro boot, including EFI-related ones. With a standard > > > > > > > > way to > > > > > > > > identify boot devices, these features become easier. It also > > > > > > > > should > > > > > > > > support U-Boot scripts, for backwards compatibility only. > > > > > > > > > > > > > > > > The first patch of this series moves boot-related code out of > > > > > > > > common/ and > > > > > > > > into a new boot/ directory. This helps to collect these related > > > > > > > > files > > > > > > > > in one place, as common/ is quite large. > > > > > > > > > > > > > > > > Like sysboot, this feature makes use of the existing PXE > > > > > > > > implementation. > > > > > > > > Much of this series consists of cleaning up that code and > > > > > > > > refactoring it > > > > > > > > into something closer to a module that can be called, teasing > > > > > > > > apart its > > > > > > > > reliance on the command-line interpreter to access filesystems > > > > > > > > and the > > > > > > > > like. Also it now uses function arguments and its own context > > > > > > > > struct > > > > > > > > internally rather than environment variables, which is very > > > > > > > > hard to > > > > > > > > follow. No core functional change is included in the included > > > > > > > > PXE patches. > > > > > > > > > > > > > > > > For documentation, see the 'doc' patch. > > > > > > > > > > > > > > > > There is quite a long list of future work included in the > > > > > > > > documentation. > > > > > > > > One question is the choice of naming. Since this is a > > > > > > > > bootloader, should > > > > > > > > we just call this a 'method' and a 'flow' ? The 'boot' prefix > > > > > > > > is already > > > > > > > > shared by other commands like bootm, booti, etc. > > > > > > > > > > > > > > > > The design is described here: > > > > > > > > > > > > > > > > https://drive.google.com/file/d/1ggW0KJpUOR__vBkj3l61L2dav4ZkNC12/view?usp=sharing > > > > > > > > > > > > > > > > The series is available at u-boot-dm/bmea-working > > > > > > > > > > > > > > How does the user control the order in which devices are > > > > > > > scanned/booted? > > > > > > > > > > > > That is not supported in distroboot at present, at least so far as I > > > > > > can see. For Fedora it seems to happen in grub. Do I have that > > > > > > right? > > > > > > > > > > Well, there's "find the next stage", which is boot_targets environment > > > > > variable, and then "where that next stage looks for stuff" which is > > > > > OS-dependent. Sometimes the ESP grub.cfg file is just enough to tell > > > > > grub to find the full grub.cfg file elsewhere, and sometimes it's a > > > > > full > > > > > grub.cfg file. I think Mark is talking about the former, and you've > > > > > said it's not part of this series, yet, but on the TODO list. > > > > > > > > Right. With the current distroboot code the order of the devices that > > > > appears in boot_targets is
Re: incompatible device trees between u-boot and linux
On Wed, Aug 25, 2021 at 10:26:10AM -0400, Tom Rini wrote:
> On Wed, Aug 25, 2021 at 05:18:16PM +0300, Vladimir Oltean wrote:
> > On Wed, Aug 25, 2021 at 10:00:45AM -0400, Tom Rini wrote:
> > > On Wed, Aug 25, 2021 at 03:58:10PM +0200, Michael Walle wrote:
> > >
> > > > Hi,
> > > >
> > > > I noticed that there is a fallback to the u-boot device tree for linux
> > > > (esp. EFI boot) if no other device tree was found, see [1]. It seems
> > > > this
> > > > is working fine for imx devices, for example, where you can just boot a
> > > > stock installer iso via EFI. It will just work and it is quite a nice
> > > > feature as a fallback.
> > > >
> > > > Now for the layerscape architecture, the ls1028a in my case, things are
> > > > more difficult because the bindings differ between u-boot and linux -
> > > > one
> > > > which comes to mind is DSA and ethernet.
> > > >
> > > > Which begs the general question, is it encouraged to have both bindings
> > > > diverge? To me it seems, that most bindings in u-boot are ad-hoc and
> > > > there
> > > > is no real review or alignment but just added as needed, which is ok if
> > > > they are local to u-boot. But since they are nowadays passed to linux
> > > > (by default!) I'm not so sure anymore.
> > > >
> > > > OTOH The whole structure around a .dts{,i} and -u-boot.dtsi looks like
> > > > they should (could?) be shared between linux and u-boot.
> > > >
> > > > -michael
> > > >
> > > > [1]
> > > > https://elixir.bootlin.com/u-boot/v2021.10-rc2/source/common/board_r.c#L471
> > >
> > > The U-Boot device tree is supposed to be able to be passed on to Linux
> > > and Just Work. The bindings are not supposed to be different between
> > > the two (except for when we take the binding while it's being hashed out
> > > upstream BUT THEN RESYNCED).
> >
> > You might need to spell that out a bit clearer.
> >
> > You are saying that both U-Boot and Linux are allowed to have their own
> > custom properties (like 'u-boot,dm-spl' for U-Boot, and 'managed =
> > "in-band-status"'
> > for Linux), as long as the device tree files themselves are in sync, and
> > the subset of the device tree blob understood by Linux (i.e. the U-Boot
> > blob sans the U-Boot specifics) is compatible with the Linux DT blob?
>
> I don't know what about the Linux example makes it Linux specific. But
> yes, 'u-boot,dm-spl' is clearly in our namespace and should be ignored
> by Linux. The whole reason we have the -u-boot.dtsi automatic drop-in
> logic (as much as it can be used is that device trees are device trees
^
I don't think this parenthesis ever closes...
> and describe the hardware and developers don't need to write a device
> tree for Linux and a device tree for U-Boot and a device tree for
> FreeBSD and ... So yes, you're supposed to use the device tree for a
^
so I never get the answer to "the whole reason is...".
> platform and it works here and there and every where.
The fact that only Linux uses it makes it Linux specific.
> > To expand even further on that, it means we should put 'managed =
> > "in-band-status"'
> > in U-Boot, which is a Linux phylink device tree property, even if U-Boot
> > does not use phylink?
>
> We should be able to drop in the device trees from Linux and use them.
> Custodians should be re-syncing them periodically. Some are, even.
Are you ready to take up device tree bindings for PTP timers, PCIe root
complex event collectors, cascaded interrupt controllers, things which
U-Boot will never ever need to support?
At least in Linux there is a policy to not add device tree nodes that do
not have drivers. Is the same policy not true for U-Boot? At least your
./scripts/checkpatch.pl does have the same "check for DT compatible
documentation" section as Linux. You might consider removing it if you
want people to not strip the DTs they submit to U-Boot.
And why do we even maintain the device tree bindings in Linux at all?
It seems rather counter-productive for both ends to do that, if it is
expected that the kernel works with DT blobs provided by third parties too,
and if all third parties need to resync with it (there are other boot
loaders too beyond U-Boot, and other kernels beyond Linux). Somehow it
doesn't feel right for the reference to be the Linux kernel. Maybe this
is something that needs to be brought up with higher-level Linux maintainers.
I have no problem at all with structuring the device tree in the same
way in U-Boot as in Linux, as long as that proves to not be a foolish
endeavor.
[PATCH v3 01/10] imx8m: clean-up kconfig indentation
From: Marcel Ziswiler Replace spurious spaces with proper tabs. Signed-off-by: Marcel Ziswiler Reviewed-by: Fabio Estevam --- (no changes since v1) arch/arm/mach-imx/imx8m/Kconfig | 20 ++-- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/arch/arm/mach-imx/imx8m/Kconfig b/arch/arm/mach-imx/imx8m/Kconfig index 1d08a2977f5..a2ba30cf332 100644 --- a/arch/arm/mach-imx/imx8m/Kconfig +++ b/arch/arm/mach-imx/imx8m/Kconfig @@ -25,14 +25,14 @@ config SYS_SOC default "imx8m" choice - prompt "NXP i.MX8M board select" + prompt "NXP i.MX8M board select" optional config TARGET_IMX8MQ_CM -bool "Ronetix iMX8MQ-CM SoM" + bool "Ronetix iMX8MQ-CM SoM" select BINMAN -select IMX8MQ -select IMX8M_LPDDR4 + select IMX8MQ + select IMX8M_LPDDR4 config TARGET_IMX8MQ_EVK bool "imx8mq_evk" @@ -105,10 +105,10 @@ config TARGET_PICO_IMX8MQ select IMX8M_LPDDR4 config TARGET_VERDIN_IMX8MM - bool "Support Toradex Verdin iMX8M Mini module" - select IMX8MM - select SUPPORT_SPL - select IMX8M_LPDDR4 + bool "Support Toradex Verdin iMX8M Mini module" + select IMX8MM + select SUPPORT_SPL + select IMX8M_LPDDR4 config TARGET_IMX8MM_BEACON bool "imx8mm Beacon Embedded devkit" @@ -125,14 +125,14 @@ config TARGET_IMX8MN_BEACON config TARGET_PHYCORE_IMX8MM bool "PHYTEC PHYCORE i.MX8MM" select IMX8MM -select SUPPORT_SPL + select SUPPORT_SPL select IMX8M_LPDDR4 config TARGET_PHYCORE_IMX8MP bool "PHYTEC PHYCORE i.MX8MP" select BINMAN select IMX8MP -select SUPPORT_SPL + select SUPPORT_SPL select IMX8M_LPDDR4 config TARGET_IMX8MM_CL_IOT_GATE -- 2.26.2
[PATCH v3 03/10] ARM: dts: imx8mm-verdin: prepare for dek blob encapsulation
From: Marcel Ziswiler
Prepare for DEK blob encapsulation support through "dek_blob" command.
On ARMv8, u-boot runs in non-secure, thus cannot encapsulate a DEK blob
for encrypted boot.
The DEK blob is encapsulated by OP-TEE through a trusted application
call. U-boot sends and receives the DEK and the DEK blob binaries
through OP-TEE dynamic shared memory.
To enable the DEK blob encapsulation, add to the defconfig:
CONFIG_SECURE_BOOT=y
CONFIG_FAT_WRITE=y
CONFIG_CMD_DEKBLOB=y
Taken from NXP's commit 56d2050f4028 ("imx8m: Add DEK blob encapsulation
for imx8m").
Signed-off-by: Marcel Ziswiler
Reviewed-by: Fabio Estevam
---
(no changes since v1)
arch/arm/dts/imx8mm-verdin-u-boot.dtsi | 7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/arm/dts/imx8mm-verdin-u-boot.dtsi
b/arch/arm/dts/imx8mm-verdin-u-boot.dtsi
index 67c31c49b6c..a97626fa0c1 100644
--- a/arch/arm/dts/imx8mm-verdin-u-boot.dtsi
+++ b/arch/arm/dts/imx8mm-verdin-u-boot.dtsi
@@ -6,6 +6,13 @@
#include "imx8mm-u-boot.dtsi"
/ {
+ firmware {
+ optee {
+ compatible = "linaro,optee-tz";
+ method = "smc";
+ };
+ };
+
wdt-reboot {
compatible = "wdt-reboot";
wdt = <&wdog1>;
--
2.26.2
[PATCH v3 05/10] verdin-imx8mm: enable sleep_moci output
From: Max Krummenacher
This powers some peripherals on the carrier board e.g. the USB hub.
Related-to: ELB-3206
Signed-off-by: Max Krummenacher
Signed-off-by: Marcel Ziswiler
Reviewed-by: Fabio Estevam
---
(no changes since v1)
arch/arm/dts/imx8mm-verdin.dts | 18 ++
configs/verdin-imx8mm_defconfig | 1 +
2 files changed, 19 insertions(+)
diff --git a/arch/arm/dts/imx8mm-verdin.dts b/arch/arm/dts/imx8mm-verdin.dts
index ac2a4b69d3c..a2331627d72 100644
--- a/arch/arm/dts/imx8mm-verdin.dts
+++ b/arch/arm/dts/imx8mm-verdin.dts
@@ -196,6 +196,18 @@
};
};
+&gpio5 {
+ ctrl_sleep_moci {
+ gpio-hog;
+ /* Verdin CTRL_SLEEP_MOCI# (SODIMM 256) */
+ gpios = <1 GPIO_ACTIVE_HIGH>;
+ line-name = "CTRL_SLEEP_MOCI#";
+ output-high;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_ctrl_sleep_moci>;
+ };
+};
+
/* On-module I2C */
&i2c1 {
clock-frequency = <40>;
@@ -548,6 +560,12 @@
>;
};
+ pinctrl_ctrl_sleep_moci: ctrlsleepmocigrp {
+ fsl,pins = <
+ MX8MM_IOMUXC_SAI3_TXD_GPIO5_IO1 0x1c4
/* SODIMM 256 */
+ >;
+ };
+
pinctrl_dsi_bkl_en: dsi_bkl_en {
fsl,pins = <
MX8MM_IOMUXC_NAND_CE2_B_GPIO3_IO3 0x1c4
/* SODIMM 21 */
diff --git a/configs/verdin-imx8mm_defconfig b/configs/verdin-imx8mm_defconfig
index b323ceb19af..ad9c00a3cc4 100644
--- a/configs/verdin-imx8mm_defconfig
+++ b/configs/verdin-imx8mm_defconfig
@@ -71,6 +71,7 @@ CONFIG_SPL_CLK_COMPOSITE_CCF=y
CONFIG_CLK_COMPOSITE_CCF=y
CONFIG_SPL_CLK_IMX8MM=y
CONFIG_CLK_IMX8MM=y
+CONFIG_GPIO_HOG=y
CONFIG_MXC_GPIO=y
CONFIG_DM_I2C=y
CONFIG_SYS_I2C_MXC=y
--
2.26.2
[PATCH v3 02/10] verdin-imx8mm: fix ethernet
From: Marcel Ziswiler
Turns out Microship (formerly Micrel) meanwhile integrated proper
support for the DLL setup on their KSZ9131. Unfortunately, this
conflicts with our previous board code doing that.
Fix this by getting rid of our board code and just relying on the
generic implementation relying on rgmii-id being used as phy-mode.
Fixes: commit c6df0e2ffdc4
("net: phy: micrel: add support for DLL setup on ksz9131")
Signed-off-by: Marcel Ziswiler
Reviewed-by: Fabio Estevam
---
(no changes since v1)
arch/arm/dts/imx8mm-verdin.dts | 2 +-
board/toradex/verdin-imx8mm/verdin-imx8mm.c | 64 -
2 files changed, 1 insertion(+), 65 deletions(-)
diff --git a/arch/arm/dts/imx8mm-verdin.dts b/arch/arm/dts/imx8mm-verdin.dts
index fb0756d6e19..ac2a4b69d3c 100644
--- a/arch/arm/dts/imx8mm-verdin.dts
+++ b/arch/arm/dts/imx8mm-verdin.dts
@@ -160,7 +160,7 @@
&fec1 {
fsl,magic-packet;
phy-handle = <ðphy0>;
- phy-mode = "rgmii";
+ phy-mode = "rgmii-id";
phy-supply = <®_ethphy>;
pinctrl-names = "default", "sleep";
pinctrl-0 = <&pinctrl_fec1>;
diff --git a/board/toradex/verdin-imx8mm/verdin-imx8mm.c
b/board/toradex/verdin-imx8mm/verdin-imx8mm.c
index 76f4a1e209a..1644f4b3081 100644
--- a/board/toradex/verdin-imx8mm/verdin-imx8mm.c
+++ b/board/toradex/verdin-imx8mm/verdin-imx8mm.c
@@ -36,70 +36,6 @@ static int setup_fec(void)
return 0;
}
-
-int board_phy_config(struct phy_device *phydev)
-{
- int tmp;
-
- switch (ksz9xx1_phy_get_id(phydev) & MII_KSZ9x31_SILICON_REV_MASK) {
- case PHY_ID_KSZ9031:
- /*
-* The PHY adds 1.2ns for the RXC and 0ns for TXC clock by
-* default. The MAC and the layout don't add a skew between
-* clock and data.
-* Add 0.3ns for the RXC path and 0.96 + 0.42 ns (1.38 ns) for
-* the TXC path to get the required clock skews.
-*/
- /* control data pad skew - devaddr = 0x02, register = 0x04 */
- ksz9031_phy_extended_write(phydev, 0x02,
- MII_KSZ9031_EXT_RGMII_CTRL_SIG_SKEW,
- MII_KSZ9031_MOD_DATA_NO_POST_INC,
- 0x0070);
- /* rx data pad skew - devaddr = 0x02, register = 0x05 */
- ksz9031_phy_extended_write(phydev, 0x02,
- MII_KSZ9031_EXT_RGMII_RX_DATA_SKEW,
- MII_KSZ9031_MOD_DATA_NO_POST_INC,
- 0x);
- /* tx data pad skew - devaddr = 0x02, register = 0x06 */
- ksz9031_phy_extended_write(phydev, 0x02,
- MII_KSZ9031_EXT_RGMII_TX_DATA_SKEW,
- MII_KSZ9031_MOD_DATA_NO_POST_INC,
- 0x);
- /* gtx and rx clock pad skew - devaddr = 0x02,register = 0x08 */
- ksz9031_phy_extended_write(phydev, 0x02,
- MII_KSZ9031_EXT_RGMII_CLOCK_SKEW,
- MII_KSZ9031_MOD_DATA_NO_POST_INC,
- 0x03f4);
- break;
- case PHY_ID_KSZ9131:
- default:
- /* read rxc dll control - devaddr = 0x2, register = 0x4c */
- tmp = ksz9031_phy_extended_read(phydev, 0x02,
- MII_KSZ9131_EXT_RGMII_2NS_SKEW_RXDLL,
- MII_KSZ9031_MOD_DATA_NO_POST_INC);
- /* disable rxdll bypass (enable 2ns skew delay on RXC) */
- tmp &= ~MII_KSZ9131_RXTXDLL_BYPASS;
- /* rxc data pad skew 2ns - devaddr = 0x02, register = 0x4c */
- tmp = ksz9031_phy_extended_write(phydev, 0x02,
- MII_KSZ9131_EXT_RGMII_2NS_SKEW_RXDLL,
- MII_KSZ9031_MOD_DATA_NO_POST_INC, tmp);
- /* read txc dll control - devaddr = 0x02, register = 0x4d */
- tmp = ksz9031_phy_extended_read(phydev, 0x02,
- MII_KSZ9131_EXT_RGMII_2NS_SKEW_TXDLL,
- MII_KSZ9031_MOD_DATA_NO_POST_INC);
- /* disable txdll bypass (enable 2ns skew delay on TXC) */
- tmp &= ~MII_KSZ9131_RXTXDLL_BYPASS;
- /* rxc data pad skew 2ns - devaddr = 0x02, register = 0x4d */
- tmp = ksz9031_phy_extended_write(phydev, 0x02,
- MII_KSZ9131_EXT_RGMII_2NS_SKEW_TXDLL,
- MII_KSZ9031_MOD_DATA_NO_POST_INC, tmp);
- break;
- }
-
- if (phydev->drv->config)
- phydev->drv->config(phydev);
- return 0;
[PATCH v3 00/10] board: toradex: verdin-imx8mm: target refresh
From: Marcel Ziswiler
An assortment of fixes and improvements like an Ethernet PHY
configuration fix, DEK blob encapsulation preparation, migration to
using binman to pack images, SLEEP_MOCI# enablement, dropping of V1.0
hardware support [1], renaming kernel image variable, using preboot
for fdtfile evaluation and watchdog pinctrl fix.
Note that this series is applied on top of Peng's Makefile fix [2] as
otherwise, it may not quite generate all binman artefacts in the right
order as discussed here [3].
[1] https://developer.toradex.com/verdin-sample-phase-over
[2] https://marc.info/?l=u-boot&m=162908373904742
[3] https://marc.info/?l=u-boot&m=162945614207220
Changes in v3:
- Case fold hex string.
- Revert binman part of imx8mm-verdin-u-boot.dtsi to a plain copy from
imx8mm-evk and postpone further improvements to after migrating to a
common binman config as agreed with Frieder and Simon.
- New patch cleaning up include order.
- Add Fabio's reviewed-by tag.
- Fix patch.
- Add missing apalis-imx8 part.
- While at it update copyright year resp. period.
- Fix closing endif comment.
Changes in v2:
- Explicitly pass filename to binman when generating binaries as
suggested by Heiko.
- Use proper intermediate binary u-boot-spl-ddr.bin for imximage as
pointed out by Heiko.
- Drop first patch ("imx: mkimage_fit_atf: fix legacy image generation")
as a similar fix was already refused earlier.
- New patch allows booting recent embedded Linux BSPs.
- New patch addressing dynamic fdtfile definition.
- New patch fixing watchdog pinctrl issue.
Igor Opaniuk (1):
verdin-imx8mm: use preboot for fdtfile evaluation
Marcel Ziswiler (6):
imx8m: clean-up kconfig indentation
verdin-imx8mm: fix ethernet
ARM: dts: imx8mm-verdin: prepare for dek blob encapsulation
verdin-imx8mm: switch to use binman to pack images
verdin-imx8mm: clean-up include order
verdin-imx8mm: fix watchdog pinctrl issue
Max Krummenacher (2):
verdin-imx8mm: enable sleep_moci output
verdin-imx8mm: drop support for v1.0 hardware
Oleksandr Suvorov (1):
include/configs: apalis-imx8/verdin-imx8mm: rename kernel image
variable
arch/arm/dts/imx8mm-verdin-u-boot.dtsi | 135 +++-
arch/arm/dts/imx8mm-verdin.dts | 20 ++-
arch/arm/mach-imx/imx8m/Kconfig | 21 +--
board/toradex/verdin-imx8mm/imximage.cfg| 11 +-
board/toradex/verdin-imx8mm/verdin-imx8mm.c | 81 +---
configs/verdin-imx8mm_defconfig | 6 +-
doc/board/toradex/verdin-imx8mm.rst | 53
include/configs/apalis-imx8.h | 6 +-
include/configs/verdin-imx8mm.h | 11 +-
9 files changed, 215 insertions(+), 129 deletions(-)
--
2.26.2
[PATCH v3 06/10] verdin-imx8mm: clean-up include order
From: Marcel Ziswiler Alphabetically order includes. While at it also update copyright year resp. period. Signed-off-by: Marcel Ziswiler --- Changes in v3: - New patch cleaning up include order. board/toradex/verdin-imx8mm/verdin-imx8mm.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/board/toradex/verdin-imx8mm/verdin-imx8mm.c b/board/toradex/verdin-imx8mm/verdin-imx8mm.c index 1644f4b3081..71ceb26e811 100644 --- a/board/toradex/verdin-imx8mm/verdin-imx8mm.c +++ b/board/toradex/verdin-imx8mm/verdin-imx8mm.c @@ -1,6 +1,6 @@ // SPDX-License-Identifier: GPL-2.0+ /* - * Copyright 2020 Toradex + * Copyright 2020-2021 Toradex */ #include @@ -10,9 +10,9 @@ #include #include #include +#include #include #include -#include #include "../common/tdx-cfg-block.h" -- 2.26.2
[PATCH v3 04/10] verdin-imx8mm: switch to use binman to pack images
From: Marcel Ziswiler
Use binman to pack images.
Signed-off-by: Marcel Ziswiler
Reviewed-by: Heiko Thiery
Reviewed-by: Fabio Estevam
---
Changes in v3:
- Case fold hex string.
- Revert binman part of imx8mm-verdin-u-boot.dtsi to a plain copy from
imx8mm-evk and postpone further improvements to after migrating to a
common binman config as agreed with Frieder and Simon.
Changes in v2:
- Explicitly pass filename to binman when generating binaries as
suggested by Heiko.
- Use proper intermediate binary u-boot-spl-ddr.bin for imximage as
pointed out by Heiko.
arch/arm/dts/imx8mm-verdin-u-boot.dtsi | 124 ++-
arch/arm/mach-imx/imx8m/Kconfig | 1 +
board/toradex/verdin-imx8mm/imximage.cfg | 11 +-
configs/verdin-imx8mm_defconfig | 2 +-
doc/board/toradex/verdin-imx8mm.rst | 53 +-
5 files changed, 157 insertions(+), 34 deletions(-)
diff --git a/arch/arm/dts/imx8mm-verdin-u-boot.dtsi
b/arch/arm/dts/imx8mm-verdin-u-boot.dtsi
index a97626fa0c1..0e041865021 100644
--- a/arch/arm/dts/imx8mm-verdin-u-boot.dtsi
+++ b/arch/arm/dts/imx8mm-verdin-u-boot.dtsi
@@ -1,11 +1,15 @@
// SPDX-License-Identifier: GPL-2.0+ OR MIT
/*
- * Copyright 2020 Toradex
+ * Copyright 2021 Toradex
*/
#include "imx8mm-u-boot.dtsi"
/ {
+ binman: binman {
+ multiple-images;
+ };
+
firmware {
optee {
compatible = "linaro,optee-tz";
@@ -91,3 +95,121 @@
&wdog1 {
u-boot,dm-spl;
};
+
+&binman {
+u-boot-spl-ddr {
+ filename = "u-boot-spl-ddr.bin";
+ pad-byte = <0xff>;
+ align-size = <4>;
+ align = <4>;
+
+ u-boot-spl {
+ align-end = <4>;
+ };
+
+ blob_1: blob-ext@1 {
+ filename = "lpddr4_pmu_train_1d_imem.bin";
+ size = <0x8000>;
+ };
+
+ blob_2: blob-ext@2 {
+ filename = "lpddr4_pmu_train_1d_dmem.bin";
+ size = <0x4000>;
+ };
+
+ blob_3: blob-ext@3 {
+ filename = "lpddr4_pmu_train_2d_imem.bin";
+ size = <0x8000>;
+ };
+
+ blob_4: blob-ext@4 {
+ filename = "lpddr4_pmu_train_2d_dmem.bin";
+ size = <0x4000>;
+ };
+ };
+
+ spl {
+ filename = "spl.bin";
+
+ mkimage {
+ args = "-n spl/u-boot-spl.cfgout -T imx8mimage -e
0x7e1000";
+
+ blob {
+ filename = "u-boot-spl-ddr.bin";
+ };
+ };
+ };
+
+ itb {
+ filename = "u-boot.itb";
+
+ fit {
+ description = "Configuration to load ATF before U-Boot";
+ #address-cells = <1>;
+ fit,external-offset = ;
+
+ images {
+ uboot {
+ description = "U-Boot (64-bit)";
+ type = "standalone";
+ arch = "arm64";
+ compression = "none";
+ load = ;
+
+ uboot_blob: blob-ext {
+ filename = "u-boot-nodtb.bin";
+ };
+ };
+
+ atf {
+ description = "ARM Trusted Firmware";
+ type = "firmware";
+ arch = "arm64";
+ compression = "none";
+ load = <0x92>;
+ entry = <0x92>;
+
+ atf_blob: blob-ext {
+ filename = "bl31.bin";
+ };
+ };
+
+ fdt {
+ description = "NAME";
+ type = "flat_dt";
+ compression = "none";
+
+ uboot_fdt_blob: blob-ext {
+ filename = "u-boot.dtb";
+ };
+ };
+ };
+
+ configurations {
+ default = "conf";
+
+ conf {
+ description = "NAME";
+ firmware
[PATCH v3 07/10] verdin-imx8mm: drop support for v1.0 hardware
From: Max Krummenacher
We drop support for Verdin iMX8M Mini V1.0B.
Related-to: ELB-3551
Signed-off-by: Max Krummenacher
Signed-off-by: Marcel Ziswiler
Reviewed-by: Fabio Estevam
---
Changes in v3:
- Add Fabio's reviewed-by tag.
Changes in v2:
- Drop first patch ("imx: mkimage_fit_atf: fix legacy image generation")
as a similar fix was already refused earlier.
board/toradex/verdin-imx8mm/verdin-imx8mm.c | 13 +
1 file changed, 5 insertions(+), 8 deletions(-)
diff --git a/board/toradex/verdin-imx8mm/verdin-imx8mm.c
b/board/toradex/verdin-imx8mm/verdin-imx8mm.c
index 71ceb26e811..c51c99b5156 100644
--- a/board/toradex/verdin-imx8mm/verdin-imx8mm.c
+++ b/board/toradex/verdin-imx8mm/verdin-imx8mm.c
@@ -9,6 +9,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -87,17 +88,13 @@ static void select_dt_from_module_version(void)
switch (get_pcb_revision()) {
case PCB_VERSION_1_0:
- printf("Detected a V1.0 module\n");
- if (is_wifi)
- strncpy(&variant[0], "wifi", sizeof(variant));
- else
- strncpy(&variant[0], "nonwifi", sizeof(variant));
- break;
+ printf("Detected a V1.0 module which is no longer supported in
this BSP version\n");
+ hang();
default:
if (is_wifi)
- strncpy(&variant[0], "wifi-v1.1", sizeof(variant));
+ strlcpy(&variant[0], "wifi", sizeof(variant));
else
- strncpy(&variant[0], "nonwifi-v1.1", sizeof(variant));
+ strlcpy(&variant[0], "nonwifi", sizeof(variant));
break;
}
--
2.26.2
[PATCH v3 09/10] verdin-imx8mm: use preboot for fdtfile evaluation
From: Igor Opaniuk
Enable and set preboot var with fdtfile evaluation.
It will be checked and run immediately before starting the
CONFIG_BOOTDELAY countdown and/or running the auto-boot command resp.
entering interactive mode.
This provides possibility to use different boot cmds in interactive mode
without manual setting fdtfile value, as it it's already evaluated
before entering interactive mode.
Signed-off-by: Igor Opaniuk
Signed-off-by: Marcel Ziswiler
Reviewed-by: Fabio Estevam
---
(no changes since v2)
Changes in v2:
- New patch addressing dynamic fdtfile definition.
configs/verdin-imx8mm_defconfig | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/configs/verdin-imx8mm_defconfig b/configs/verdin-imx8mm_defconfig
index ad9c00a3cc4..ab549ebbada 100644
--- a/configs/verdin-imx8mm_defconfig
+++ b/configs/verdin-imx8mm_defconfig
@@ -28,7 +28,8 @@ CONFIG_SPL_LOAD_FIT=y
CONFIG_OF_SYSTEM_SETUP=y
CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=board/toradex/verdin-imx8mm/imximage.cfg"
# CONFIG_USE_BOOTCOMMAND is not set
-CONFIG_DEFAULT_FDT_FILE="fsl-imx8mm-verdin-dev.dtb"
+CONFIG_USE_PREBOOT=y
+CONFIG_PREBOOT="setenv fdtfile imx8mm-verdin-${variant}-${fdt_board}.dtb"
CONFIG_LOG=y
# CONFIG_DISPLAY_BOARDINFO is not set
CONFIG_DISPLAY_BOARDINFO_LATE=y
--
2.26.2
[PATCH v3 10/10] verdin-imx8mm: fix watchdog pinctrl issue
From: Marcel Ziswiler
Finally, found the root cause of the issue already once mentioned back
here [2] which caused the following error message during boot:
imx_wdt watchdog@3028:
pinctrl_select_state_full: uclass_get_device_by_phandle_id: err=-19
Turns out while the watchdog node itself was already u-boot,dm-spl its
pinctrl node was not which caused it to be unavailable at that early
stage. Note that any and all other boards I checked also seem to be
missing this. However, I can't judge whether or not they might indeed
need a similar fix or not.
[2] https://marc.info/?l=u-boot&m=161786572422973
Fixes: commit d304e7ace3a6
("ARM: imx8m: Fix reset in SPL on Toradex iMX8MM Verdin")
Signed-off-by: Marcel Ziswiler
Reviewed-by: Fabio Estevam
---
(no changes since v2)
Changes in v2:
- New patch fixing watchdog pinctrl issue.
arch/arm/dts/imx8mm-verdin-u-boot.dtsi | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/dts/imx8mm-verdin-u-boot.dtsi
b/arch/arm/dts/imx8mm-verdin-u-boot.dtsi
index 0e041865021..6962bb40b6e 100644
--- a/arch/arm/dts/imx8mm-verdin-u-boot.dtsi
+++ b/arch/arm/dts/imx8mm-verdin-u-boot.dtsi
@@ -68,6 +68,10 @@
u-boot,dm-spl;
};
+&pinctrl_wdog {
+ u-boot,dm-spl;
+};
+
&{/soc@0/bus@3080/i2c@30a2/pmic} {
u-boot,dm-spl;
};
--
2.26.2
[PATCH v3 08/10] include/configs: apalis-imx8/verdin-imx8mm: rename kernel image variable
From: Oleksandr Suvorov
Variable "kernel_image" is used in boot.scr script only, that sets its
own default value to the constant string @@KERNEL_IMAGETYPE@@ in case
"kernel_image" is not set.
The default name of the kernel image shipped with BSP 5.x is "Image.gz".
Setting kernel_image="Image" as a pre-defined u-boot variable
breaks booting systems with modern versions of boot.scr, whereas
renaming it fixes booting with modern scripts and does not break working
of earlier versions of boot.scr.
Signed-off-by: Oleksandr Suvorov
Signed-off-by: Marcel Ziswiler
Reviewed-by: Fabio Estevam
---
Changes in v3:
- Fix patch.
- Add missing apalis-imx8 part.
- While at it update copyright year resp. period.
- Fix closing endif comment.
Changes in v2:
- New patch allows booting recent embedded Linux BSPs.
include/configs/apalis-imx8.h | 6 +++---
include/configs/verdin-imx8mm.h | 11 +--
2 files changed, 8 insertions(+), 9 deletions(-)
diff --git a/include/configs/apalis-imx8.h b/include/configs/apalis-imx8.h
index b04a03f76da..1757f025fc5 100644
--- a/include/configs/apalis-imx8.h
+++ b/include/configs/apalis-imx8.h
@@ -1,6 +1,6 @@
/* SPDX-License-Identifier: GPL-2.0+ */
/*
- * Copyright 2019 Toradex
+ * Copyright 2019-2021 Toradex
*/
#ifndef __APALIS_IMX8_H
@@ -44,12 +44,12 @@
#define CONFIG_EXTRA_ENV_SETTINGS \
BOOTENV \
MEM_LAYOUT_ENV_SETTINGS \
+ "boot_file=Image\0" \
"console=ttyLP1 earlycon\0" \
"fdt_addr=0x8300\0" \
"fdt_file=fsl-imx8qm-apalis-eval.dtb\0" \
"fdtfile=fsl-imx8qm-apalis-eval.dtb\0" \
"finduuid=part uuid mmc ${mmcdev}:2 uuid\0" \
- "image=Image\0" \
"initrd_addr=0x8380\0" \
"initrd_high=0x\0" \
"mmcargs=setenv bootargs console=${console},${baudrate} " \
@@ -59,7 +59,7 @@
"netargs=setenv bootargs console=${console},${baudrate} " \
"root=/dev/nfs ip=dhcp nfsroot=${serverip}:${nfsroot},v3,tcp" \
"\0" \
- "nfsboot=run netargs; dhcp ${loadaddr} ${image}; tftp ${fdt_addr} " \
+ "nfsboot=run netargs; dhcp ${loadaddr} ${boot_file}; tftp ${fdt_addr} "
\
"apalis-imx8/${fdt_file}; booti ${loadaddr} - ${fdt_addr}\0" \
"panel=NULL\0" \
"script=boot.scr\0" \
diff --git a/include/configs/verdin-imx8mm.h b/include/configs/verdin-imx8mm.h
index 7be5e5ddf11..d15a3e05fcc 100644
--- a/include/configs/verdin-imx8mm.h
+++ b/include/configs/verdin-imx8mm.h
@@ -1,6 +1,6 @@
/* SPDX-License-Identifier: GPL-2.0+ */
/*
- * Copyright 2020 Toradex
+ * Copyright 2020-2021 Toradex
*/
#ifndef __VERDIN_IMX8MM_H
@@ -57,16 +57,16 @@
BOOTENV \
MEM_LAYOUT_ENV_SETTINGS \
"bootcmd_mfg=fastboot 0\0" \
+ "boot_file=Image\0" \
"console=ttymxc0\0" \
"fdt_addr=0x4300\0" \
- "fdtfile=" CONFIG_DEFAULT_FDT_FILE "\0" \
+ "fdt_board=dev\0" \
"initrd_addr=0x4380\0" \
"initrd_high=0x\0" \
- "kernel_image=Image\0" \
"netargs=setenv bootargs console=${console},${baudrate} " \
"root=/dev/nfs ip=dhcp nfsroot=${serverip}:${nfsroot},v3,tcp" \
"\0" \
- "nfsboot=run netargs; dhcp ${loadaddr} ${kernel_image}; " \
+ "nfsboot=run netargs; dhcp ${loadaddr} ${boot_file}; " \
"tftp ${fdt_addr} verdin/${fdtfile}; " \
"booti ${loadaddr} - ${fdt_addr}\0" \
"setup=setenv setupargs console=${console},${baudrate} " \
@@ -124,5 +124,4 @@
#define CONFIG_MXC_USB_PORTSC (PORT_PTS_UTMI | PORT_PTS_PTW)
#define CONFIG_USB_MAX_CONTROLLER_COUNT 2
-#endif /*_VERDIN_IMX8MM_H */
-
+#endif /* __VERDIN_IMX8MM_H */
--
2.26.2
Re: incompatible device trees between u-boot and linux
On Wed, Aug 25, 2021 at 06:12:20PM +0300, Vladimir Oltean wrote:
> On Wed, Aug 25, 2021 at 10:26:10AM -0400, Tom Rini wrote:
> > On Wed, Aug 25, 2021 at 05:18:16PM +0300, Vladimir Oltean wrote:
> > > On Wed, Aug 25, 2021 at 10:00:45AM -0400, Tom Rini wrote:
> > > > On Wed, Aug 25, 2021 at 03:58:10PM +0200, Michael Walle wrote:
> > > >
> > > > > Hi,
> > > > >
> > > > > I noticed that there is a fallback to the u-boot device tree for linux
> > > > > (esp. EFI boot) if no other device tree was found, see [1]. It seems
> > > > > this
> > > > > is working fine for imx devices, for example, where you can just boot
> > > > > a
> > > > > stock installer iso via EFI. It will just work and it is quite a nice
> > > > > feature as a fallback.
> > > > >
> > > > > Now for the layerscape architecture, the ls1028a in my case, things
> > > > > are
> > > > > more difficult because the bindings differ between u-boot and linux -
> > > > > one
> > > > > which comes to mind is DSA and ethernet.
> > > > >
> > > > > Which begs the general question, is it encouraged to have both
> > > > > bindings
> > > > > diverge? To me it seems, that most bindings in u-boot are ad-hoc and
> > > > > there
> > > > > is no real review or alignment but just added as needed, which is ok
> > > > > if
> > > > > they are local to u-boot. But since they are nowadays passed to linux
> > > > > (by default!) I'm not so sure anymore.
> > > > >
> > > > > OTOH The whole structure around a .dts{,i} and -u-boot.dtsi looks like
> > > > > they should (could?) be shared between linux and u-boot.
> > > > >
> > > > > -michael
> > > > >
> > > > > [1]
> > > > > https://elixir.bootlin.com/u-boot/v2021.10-rc2/source/common/board_r.c#L471
> > > >
> > > > The U-Boot device tree is supposed to be able to be passed on to Linux
> > > > and Just Work. The bindings are not supposed to be different between
> > > > the two (except for when we take the binding while it's being hashed out
> > > > upstream BUT THEN RESYNCED).
> > >
> > > You might need to spell that out a bit clearer.
> > >
> > > You are saying that both U-Boot and Linux are allowed to have their own
> > > custom properties (like 'u-boot,dm-spl' for U-Boot, and 'managed =
> > > "in-band-status"'
> > > for Linux), as long as the device tree files themselves are in sync, and
> > > the subset of the device tree blob understood by Linux (i.e. the U-Boot
> > > blob sans the U-Boot specifics) is compatible with the Linux DT blob?
> >
> > I don't know what about the Linux example makes it Linux specific. But
> > yes, 'u-boot,dm-spl' is clearly in our namespace and should be ignored
> > by Linux. The whole reason we have the -u-boot.dtsi automatic drop-in
> > logic (as much as it can be used is that device trees are device trees
> ^
> I don't think this parenthesis ever closes...
Ah, whoops. Should have been "(as much as it can be used)" because it
does get #included instead in some cases, for reasons.
>
> > and describe the hardware and developers don't need to write a device
> > tree for Linux and a device tree for U-Boot and a device tree for
> > FreeBSD and ... So yes, you're supposed to use the device tree for a
> ^
> so I never get the answer to "the whole reason is...".
>
> > platform and it works here and there and every where.
>
> The fact that only Linux uses it makes it Linux specific.
>
> > > To expand even further on that, it means we should put 'managed =
> > > "in-band-status"'
> > > in U-Boot, which is a Linux phylink device tree property, even if U-Boot
> > > does not use phylink?
> >
> > We should be able to drop in the device trees from Linux and use them.
> > Custodians should be re-syncing them periodically. Some are, even.
>
> Are you ready to take up device tree bindings for PTP timers, PCIe root
> complex event collectors, cascaded interrupt controllers, things which
> U-Boot will never ever need to support?
>
> At least in Linux there is a policy to not add device tree nodes that do
> not have drivers. Is the same policy not true for U-Boot? At least your
> ./scripts/checkpatch.pl does have the same "check for DT compatible
> documentation" section as Linux. You might consider removing it if you
> want people to not strip the DTs they submit to U-Boot.
>
> And why do we even maintain the device tree bindings in Linux at all?
> It seems rather counter-productive for both ends to do that, if it is
> expected that the kernel works with DT blobs provided by third parties too,
> and if all third parties need to resync with it (there are other boot
> loaders too beyond U-Boot, and other kernels beyond Linux). Somehow it
> doesn't feel right for the reference to be the Linux kernel. Maybe this
> is something that needs to be brought up with higher-level Linux maintainers.
>
> I have no problem at all with structuring the device tree in the same
> way in U-Boot as in Linux, as long as that proves to not be a foolish
> endeavor.
DT is
[PATCH] arm: dts: imx8mp: Generate single bootable binary
binman conversion made flashing flash.bin
and u-boot.itb necessary. Update binman config
to create a single flash.bin image again.
This updates imx8mp_evk and phyCORE-i.MX8MP as they share the
same binman config.
Updated also imx8mp_evk documentation.
Tested on phyCORE-i.MX8MP.
Signed-off-by: Teresa Remmet
---
arch/arm/dts/imx8mp-u-boot.dtsi | 17 -
.../imx8mp_evk/imximage-8mp-lpddr4.cfg | 2 +-
board/phytec/phycore_imx8mp/imximage-8mp-sd.cfg | 2 +-
doc/board/nxp/imx8mp_evk.rst| 1 -
4 files changed, 18 insertions(+), 4 deletions(-)
diff --git a/arch/arm/dts/imx8mp-u-boot.dtsi b/arch/arm/dts/imx8mp-u-boot.dtsi
index a6ede2ed6e30..ace7b2051e7f 100644
--- a/arch/arm/dts/imx8mp-u-boot.dtsi
+++ b/arch/arm/dts/imx8mp-u-boot.dtsi
@@ -82,7 +82,7 @@
};
};
- flash {
+ spl {
mkimage {
args = "-n spl/u-boot-spl.cfgout -T imx8mimage -e
0x92";
@@ -149,4 +149,19 @@
};
};
};
+
+ imx-boot {
+ filename = "flash.bin";
+ pad-byte = <0x00>;
+
+ spl: blob-ext@1 {
+ filename = "spl.bin";
+ offset = <0x0>;
+ };
+
+ uboot: blob-ext@2 {
+ filename = "u-boot.itb";
+ offset = <0x58000>;
+ };
+ };
};
diff --git a/board/freescale/imx8mp_evk/imximage-8mp-lpddr4.cfg
b/board/freescale/imx8mp_evk/imximage-8mp-lpddr4.cfg
index b2920b4908ed..2be18de674ba 100644
--- a/board/freescale/imx8mp_evk/imximage-8mp-lpddr4.cfg
+++ b/board/freescale/imx8mp_evk/imximage-8mp-lpddr4.cfg
@@ -7,4 +7,4 @@
ROM_VERSIONv2
BOOT_FROM sd
-LOADER mkimage.flash.mkimage 0x92
+LOADER mkimage.spl.mkimage 0x92
diff --git a/board/phytec/phycore_imx8mp/imximage-8mp-sd.cfg
b/board/phytec/phycore_imx8mp/imximage-8mp-sd.cfg
index b2920b4908ed..2be18de674ba 100644
--- a/board/phytec/phycore_imx8mp/imximage-8mp-sd.cfg
+++ b/board/phytec/phycore_imx8mp/imximage-8mp-sd.cfg
@@ -7,4 +7,4 @@
ROM_VERSIONv2
BOOT_FROM sd
-LOADER mkimage.flash.mkimage 0x92
+LOADER mkimage.spl.mkimage 0x92
diff --git a/doc/board/nxp/imx8mp_evk.rst b/doc/board/nxp/imx8mp_evk.rst
index 609a29f3ebc3..b996ae055e69 100644
--- a/doc/board/nxp/imx8mp_evk.rst
+++ b/doc/board/nxp/imx8mp_evk.rst
@@ -52,7 +52,6 @@ Burn the flash.bin to the MicroSD card at offset 32KB:
.. code-block:: bash
$sudo dd if=build/flash.bin of=/dev/sd[x] bs=1K seek=32 conv=notrunc; sync
- $sudo dd if=build/u-boot.itb of=/dev/sd[x] bs=1K seek=384 conv=notrunc; sync
Boot
--
2.25.1
Re: [PATCH] board: ea: mx7ulp_com: allocate specific region of memory to OP-TEE
Hi Tom, On Wed, Aug 25, 2021 at 4:46 PM Tom Rini wrote: > > On Wed, Aug 25, 2021 at 04:22:55PM +0300, Oleksandr Suvorov wrote: > > > From: Ricardo Salveti > > > > On the iMX7ULP uCOM board, OP-TEE uses the memory region defined by the > > maximum DRAM address minus CONFIG_OPTEE_TZDRAM_SIZE, so subtract > > CONFIG_OPTEE_TZDRAM_SIZE from the available DRAM size to avoid > > conflicts. > > > > Note the OPTEE boot process itself subtracts the DRAM region it > > lives in from the memory map passed to Linux. > > Is this something true of all OP-TEE? All OP-TEE on ARMv7? All OP-TEE > on i.MX7? I'm asking since currently this hook is done the exact same > way on a few other i.MX7 boards, and nowhere else. That says to me we > should probably move this hook up somewhere, perhaps to imx_ddr_size() > and poke the boards that aren't using that today to use it. Shortly, no. There are different solutions for different boards and they seem not vendor-specific. Say, solutions for both stm32mp1 and zynqmp boards use fdt's reserve memory section to avoid conflicts with the OP-TEE memory region. We're thinking about providing a generic solution, but it will take some time and can't be done right now. > > -- > Tom -- Best regards, Oleksandr Suvorov Software Engineer W: www.foundries.io
Re: [PATCH] board: ea: mx7ulp_com: allocate specific region of memory to OP-TEE
On Wed, Aug 25, 2021 at 06:35:05PM +0300, Oleksandr Suvorov wrote: > Hi Tom, > > > On Wed, Aug 25, 2021 at 4:46 PM Tom Rini wrote: > > > > On Wed, Aug 25, 2021 at 04:22:55PM +0300, Oleksandr Suvorov wrote: > > > > > From: Ricardo Salveti > > > > > > On the iMX7ULP uCOM board, OP-TEE uses the memory region defined by the > > > maximum DRAM address minus CONFIG_OPTEE_TZDRAM_SIZE, so subtract > > > CONFIG_OPTEE_TZDRAM_SIZE from the available DRAM size to avoid > > > conflicts. > > > > > > Note the OPTEE boot process itself subtracts the DRAM region it > > > lives in from the memory map passed to Linux. > > > > Is this something true of all OP-TEE? All OP-TEE on ARMv7? All OP-TEE > > on i.MX7? I'm asking since currently this hook is done the exact same > > way on a few other i.MX7 boards, and nowhere else. That says to me we > > should probably move this hook up somewhere, perhaps to imx_ddr_size() > > and poke the boards that aren't using that today to use it. > > Shortly, no. There are different solutions for different boards and > they seem not > vendor-specific. Say, solutions for both stm32mp1 and zynqmp boards use fdt's > reserve memory section to avoid conflicts with the OP-TEE memory region. > We're thinking about providing a generic solution, but it will take > some time and > can't be done right now. So it's board-specific up at the OP-TEE level? OK, sigh. This is fine then. Thanks. -- Tom signature.asc Description: PGP signature
Re: incompatible device trees between u-boot and linux
On Wed, Aug 25, 2021 at 11:24:08AM -0400, Tom Rini wrote:
> On Wed, Aug 25, 2021 at 06:12:20PM +0300, Vladimir Oltean wrote:
> > On Wed, Aug 25, 2021 at 10:26:10AM -0400, Tom Rini wrote:
> > > On Wed, Aug 25, 2021 at 05:18:16PM +0300, Vladimir Oltean wrote:
> > > > On Wed, Aug 25, 2021 at 10:00:45AM -0400, Tom Rini wrote:
> > > > > On Wed, Aug 25, 2021 at 03:58:10PM +0200, Michael Walle wrote:
> > > > >
> > > > > > Hi,
> > > > > >
> > > > > > I noticed that there is a fallback to the u-boot device tree for
> > > > > > linux
> > > > > > (esp. EFI boot) if no other device tree was found, see [1]. It
> > > > > > seems this
> > > > > > is working fine for imx devices, for example, where you can just
> > > > > > boot a
> > > > > > stock installer iso via EFI. It will just work and it is quite a
> > > > > > nice
> > > > > > feature as a fallback.
> > > > > >
> > > > > > Now for the layerscape architecture, the ls1028a in my case, things
> > > > > > are
> > > > > > more difficult because the bindings differ between u-boot and linux
> > > > > > - one
> > > > > > which comes to mind is DSA and ethernet.
> > > > > >
> > > > > > Which begs the general question, is it encouraged to have both
> > > > > > bindings
> > > > > > diverge? To me it seems, that most bindings in u-boot are ad-hoc
> > > > > > and there
> > > > > > is no real review or alignment but just added as needed, which is
> > > > > > ok if
> > > > > > they are local to u-boot. But since they are nowadays passed to
> > > > > > linux
> > > > > > (by default!) I'm not so sure anymore.
> > > > > >
> > > > > > OTOH The whole structure around a .dts{,i} and -u-boot.dtsi looks
> > > > > > like
> > > > > > they should (could?) be shared between linux and u-boot.
> > > > > >
> > > > > > -michael
> > > > > >
> > > > > > [1]
> > > > > > https://elixir.bootlin.com/u-boot/v2021.10-rc2/source/common/board_r.c#L471
> > > > >
> > > > > The U-Boot device tree is supposed to be able to be passed on to Linux
> > > > > and Just Work. The bindings are not supposed to be different between
> > > > > the two (except for when we take the binding while it's being hashed
> > > > > out
> > > > > upstream BUT THEN RESYNCED).
> > > >
> > > > You might need to spell that out a bit clearer.
> > > >
> > > > You are saying that both U-Boot and Linux are allowed to have their own
> > > > custom properties (like 'u-boot,dm-spl' for U-Boot, and 'managed =
> > > > "in-band-status"'
> > > > for Linux), as long as the device tree files themselves are in sync, and
> > > > the subset of the device tree blob understood by Linux (i.e. the U-Boot
> > > > blob sans the U-Boot specifics) is compatible with the Linux DT blob?
> > >
> > > I don't know what about the Linux example makes it Linux specific. But
> > > yes, 'u-boot,dm-spl' is clearly in our namespace and should be ignored
> > > by Linux. The whole reason we have the -u-boot.dtsi automatic drop-in
> > > logic (as much as it can be used is that device trees are device trees
> > ^
> > I don't think this parenthesis ever closes...
>
> Ah, whoops. Should have been "(as much as it can be used)" because it
> does get #included instead in some cases, for reasons.
>
> >
> > > and describe the hardware and developers don't need to write a device
> > > tree for Linux and a device tree for U-Boot and a device tree for
> > > FreeBSD and ... So yes, you're supposed to use the device tree for a
> > ^
> > so I never get the answer to "the whole reason is...".
> >
> > > platform and it works here and there and every where.
> >
> > The fact that only Linux uses it makes it Linux specific.
> >
> > > > To expand even further on that, it means we should put 'managed =
> > > > "in-band-status"'
> > > > in U-Boot, which is a Linux phylink device tree property, even if U-Boot
> > > > does not use phylink?
> > >
> > > We should be able to drop in the device trees from Linux and use them.
> > > Custodians should be re-syncing them periodically. Some are, even.
> >
> > Are you ready to take up device tree bindings for PTP timers, PCIe root
> > complex event collectors, cascaded interrupt controllers, things which
> > U-Boot will never ever need to support?
> >
> > At least in Linux there is a policy to not add device tree nodes that do
> > not have drivers. Is the same policy not true for U-Boot? At least your
> > ./scripts/checkpatch.pl does have the same "check for DT compatible
> > documentation" section as Linux. You might consider removing it if you
> > want people to not strip the DTs they submit to U-Boot.
> >
> > And why do we even maintain the device tree bindings in Linux at all?
> > It seems rather counter-productive for both ends to do that, if it is
> > expected that the kernel works with DT blobs provided by third parties too,
> > and if all third parties need to resync with it (there are other boot
> > loaders too beyond U-Boot, and other kernels beyond Linux). Somehow it
> > doesn't f
[PATCH v2] board: ea: mx7ulp_com: allocate specific region of memory to OP-TEE
From: Ricardo Salveti
On the iMX7ULP uCOM board, OP-TEE uses the memory region defined by the
maximum DRAM address minus CONFIG_OPTEE_TZDRAM_SIZE, so subtract
CONFIG_OPTEE_TZDRAM_SIZE from the available DRAM size to avoid
conflicts.
Note the OPTEE boot process itself subtracts the DRAM region it
lives in from the memory map passed to Linux.
Signed-off-by: Ricardo Salveti
Signed-off-by: Oleksandr Suvorov
Reviewed-by: Fabio Estevam
---
Changes in v2:
- add missed Signed-off-by
- add Reviewed-by
board/ea/mx7ulp_com/mx7ulp_com.c | 4
1 file changed, 4 insertions(+)
diff --git a/board/ea/mx7ulp_com/mx7ulp_com.c b/board/ea/mx7ulp_com/mx7ulp_com.c
index 5b2d444366..7fce75ade9 100644
--- a/board/ea/mx7ulp_com/mx7ulp_com.c
+++ b/board/ea/mx7ulp_com/mx7ulp_com.c
@@ -20,6 +20,10 @@ int dram_init(void)
{
gd->ram_size = imx_ddr_size();
+#ifdef CONFIG_OPTEE_TZDRAM_SIZE
+ gd->ram_size -= CONFIG_OPTEE_TZDRAM_SIZE;
+#endif
+
return 0;
}
--
2.31.1
Re: [PATCH] arm: dts: imx8mp: Generate single bootable binary
Hi Teresa,
On Wed, Aug 25, 2021 at 12:25 PM Teresa Remmet wrote:
>
> binman conversion made flashing flash.bin
> and u-boot.itb necessary. Update binman config
> to create a single flash.bin image again.
>
> This updates imx8mp_evk and phyCORE-i.MX8MP as they share the
> same binman config.
>
> Updated also imx8mp_evk documentation.
>
> Tested on phyCORE-i.MX8MP.
Thanks for taking care of this.
> Signed-off-by: Teresa Remmet
> ---
> arch/arm/dts/imx8mp-u-boot.dtsi | 17 -
> .../imx8mp_evk/imximage-8mp-lpddr4.cfg | 2 +-
> board/phytec/phycore_imx8mp/imximage-8mp-sd.cfg | 2 +-
> doc/board/nxp/imx8mp_evk.rst| 1 -
> 4 files changed, 18 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm/dts/imx8mp-u-boot.dtsi b/arch/arm/dts/imx8mp-u-boot.dtsi
> index a6ede2ed6e30..ace7b2051e7f 100644
> --- a/arch/arm/dts/imx8mp-u-boot.dtsi
> +++ b/arch/arm/dts/imx8mp-u-boot.dtsi
> @@ -82,7 +82,7 @@
> };
> };
>
> - flash {
> + spl {
To make this more standard, could you please also pass 'filename =
"spl.bin" here too?
Please check:
https://lists.denx.de/pipermail/u-boot/2021-August/458754.html
> BOOT_FROM sd
> -LOADER mkimage.flash.mkimage 0x92
> +LOADER mkimage.spl.mkimage 0x92
Please use "LOADER u-boot-spl-ddr.bin 0x92" here instead.
> diff --git a/board/phytec/phycore_imx8mp/imximage-8mp-sd.cfg
> b/board/phytec/phycore_imx8mp/imximage-8mp-sd.cfg
> index b2920b4908ed..2be18de674ba 100644
> --- a/board/phytec/phycore_imx8mp/imximage-8mp-sd.cfg
> +++ b/board/phytec/phycore_imx8mp/imximage-8mp-sd.cfg
> @@ -7,4 +7,4 @@
>
> ROM_VERSIONv2
> BOOT_FROM sd
> -LOADER mkimage.flash.mkimage 0x92
> +LOADER mkimage.spl.mkimage 0x92
Ditto.
With these changes, you can add:
Reviewed-by: Fabio Estevam
Thanks
Re: [PATCH v2] ARM: dts: Fix node status to "okay" on TI boards
On 14:07-20210824, Roger Quadros wrote: > As per Device Tree Specification [1], the status parameter of nodes can > be "okay", "disabled", etc. "ok" is not a valid parameter. > > U-boot Driver Model does not recognize status="ok" either and treats > the node as disabled. > > [1] > https://github.com/devicetree-org/devicetree-specification/releases/tag/v0.3 > > Signed-off-by: Roger Quadros Ideally, I'd prefer if we were doing a copy from upstream k.org against a specific kernel tag version. but a fixup does make sense.. some of which indicates missing sync with k.org dts, I suspect.. Reviewed-by: Nishanth Menon -- Regards, Nishanth Menon Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
[PATCH 1/1] riscv: enable booting HiFive Unmatched from SATA
On the HiFive Unmatched a PCI to SATA adapter may be used to install a SATA drive. Enable booting from it. Signed-off-by: Heinrich Schuchardt --- configs/sifive_unmatched_defconfig | 5 + include/configs/sifive-unmatched.h | 3 +++ 2 files changed, 8 insertions(+) diff --git a/configs/sifive_unmatched_defconfig b/configs/sifive_unmatched_defconfig index 38b7acd536..1dde98e0ae 100644 --- a/configs/sifive_unmatched_defconfig +++ b/configs/sifive_unmatched_defconfig @@ -7,6 +7,7 @@ CONFIG_DEFAULT_DEVICE_TREE="hifive-unmatched-a00" CONFIG_SPL_MMC_SUPPORT=y CONFIG_SPL=y CONFIG_SPL_SPI_SUPPORT=y +CONFIG_AHCI=y CONFIG_TARGET_SIFIVE_UNMATCHED=y CONFIG_ARCH_RV64I=y CONFIG_RISCV_SMODE=y @@ -28,12 +29,16 @@ CONFIG_CMD_GPT_RENAME=y CONFIG_CMD_PCI=y CONFIG_CMD_USB=y CONFIG_SYS_RELOC_GD_ENV_ADDR=y +CONFIG_SCSI_AHCI=y +CONFIG_AHCI_PCI=y CONFIG_SPL_CLK=y CONFIG_E1000=y CONFIG_NVME=y CONFIG_PCI=y CONFIG_PCIE_DW_SIFIVE=y CONFIG_DM_RESET=y +CONFIG_SCSI=y +CONFIG_DM_SCSI=y CONFIG_USB=y CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_PCI=y diff --git a/include/configs/sifive-unmatched.h b/include/configs/sifive-unmatched.h index cb7f0c0fd9..f8ad2cce1f 100644 --- a/include/configs/sifive-unmatched.h +++ b/include/configs/sifive-unmatched.h @@ -40,6 +40,8 @@ #define CONFIG_SYS_CACHELINE_SIZE 64 +#define CONFIG_SYS_SCSI_MAX_SCSI_ID4 + /* Environment options */ #ifndef CONFIG_SPL_BUILD @@ -47,6 +49,7 @@ func(NVME, nvme, 0) \ func(USB, usb, 0) \ func(MMC, mmc, 0) \ + func(SCSI, scsi, 0) \ func(PXE, pxe, na) \ func(DHCP, dhcp, na) -- 2.32.0
[PATCH 1/2] cmd: kaslrseed: add command to generate value from hwrng
From: Chris Morgan
Allow the kaslr-seed value in the chosen node to be set from a hardware
rng source.
Tested on a Rockchip PX30 (Odroid Go Advance), you must have loaded
the devicetree first and prepared it for editing. On my device the
workflow goes as follows:
setenv dtb_loadaddr "0x01f0"
load mmc 0:1 ${dtb_loadaddr} rk3326-odroid-go2.dtb
fdt addr ${dtb_loadaddr}
fdt resize
kaslrseed
and the output can be seen here:
fdt print /chosen
chosen {
kaslr-seed = <0x6f61df74 0x6f7b996c>;
stdout-path = "serial2:115200n8";
};
Signed-off-by: Chris Morgan
---
cmd/Kconfig | 7 +
cmd/Makefile| 1 +
cmd/kaslrseed.c | 81 +
3 files changed, 89 insertions(+)
create mode 100644 cmd/kaslrseed.c
diff --git a/cmd/Kconfig b/cmd/Kconfig
index ffef3cc76c..e62adff939 100644
--- a/cmd/Kconfig
+++ b/cmd/Kconfig
@@ -1790,6 +1790,13 @@ config CMD_RNG
help
Print bytes from the hardware random number generator.
+config CMD_KASLRSEED
+ bool "kaslrseed"
+ depends on DM_RNG
+ help
+ Set the kaslr-seed in the chosen node with entropy provided by a
+ hardware random number generator.
+
config CMD_SLEEP
bool "sleep"
default y
diff --git a/cmd/Makefile b/cmd/Makefile
index ed3669411e..34cbda72f5 100644
--- a/cmd/Makefile
+++ b/cmd/Makefile
@@ -131,6 +131,7 @@ obj-$(CONFIG_CMD_REGINFO) += reginfo.o
obj-$(CONFIG_CMD_REISER) += reiser.o
obj-$(CONFIG_CMD_REMOTEPROC) += remoteproc.o
obj-$(CONFIG_CMD_RNG) += rng.o
+obj-$(CONFIG_CMD_KASLRSEED) += kaslrseed.o
obj-$(CONFIG_CMD_ROCKUSB) += rockusb.o
obj-$(CONFIG_CMD_RTC) += rtc.o
obj-$(CONFIG_SANDBOX) += host.o
diff --git a/cmd/kaslrseed.c b/cmd/kaslrseed.c
new file mode 100644
index 00..27c2648c91
--- /dev/null
+++ b/cmd/kaslrseed.c
@@ -0,0 +1,81 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * The 'kaslrseed' command takes bytes from the hardware random number
+ * generator and uses them to set the kaslr-seed value in the chosen node.
+ *
+ * Copyright (c) 2021, Chris Morgan
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+static int do_kaslr_seed(struct cmd_tbl *cmdtp, int flag, int argc, char
*const argv[])
+{
+ size_t n = 0x8;
+ struct udevice *dev;
+ u64 *buf;
+ int nodeoffset;
+ int ret = CMD_RET_SUCCESS;
+
+ if (uclass_get_device(UCLASS_RNG, 0, &dev) || !dev) {
+ printf("No RNG device\n");
+ return CMD_RET_FAILURE;
+ }
+
+ buf = malloc(n);
+ if (!buf) {
+ printf("Out of memory\n");
+ return CMD_RET_FAILURE;
+ }
+
+ if (dm_rng_read(dev, buf, n)) {
+ printf("Reading RNG failed\n");
+ return CMD_RET_FAILURE;
+ }
+
+ if (!working_fdt) {
+ printf("No FDT memory address configured. Please configure\n"
+ "the FDT address via \"fdt addr \" command.\n"
+ "Aborting!\n");
+ return CMD_RET_FAILURE;
+ }
+
+ ret = fdt_check_header(working_fdt);
+ if (ret < 0) {
+ printf("fdt_chosen: %s\n", fdt_strerror(ret));
+ return CMD_RET_FAILURE;
+ }
+
+ nodeoffset = fdt_find_or_add_subnode(working_fdt, 0, "chosen");
+ if (nodeoffset < 0) {
+ printf("Reading chosen node failed\n");
+ return CMD_RET_FAILURE;
+ }
+
+ ret = fdt_setprop(working_fdt, nodeoffset, "kaslr-seed", buf,
sizeof(buf));
+ if (ret < 0) {
+ printf("Unable to set kaslr-seed on chosen node: %s\n",
fdt_strerror(ret));
+ return CMD_RET_FAILURE;
+ }
+
+ free(buf);
+
+ return ret;
+}
+
+#ifdef CONFIG_SYS_LONGHELP
+static char kaslrseed_help_text[] =
+ "[n]\n"
+ " - append random bytes to chosen kaslr-seed node\n";
+#endif
+
+U_BOOT_CMD(
+ kaslrseed, 1, 0, do_kaslr_seed,
+ "feed bytes from the hardware random number generator to the
kaslr-seed",
+ kaslrseed_help_text
+);
--
2.25.1
[PATCH 1/1] rockchip: px30: add support for HW RNG for Odroid Go Advance
From: Chris Morgan
The Odroid Go Advance has a hardware random number generator present.
The device does not have an upstream Linux driver, but does have a
U-Boot driver. Add the appropriate node so that the hardware RNG can be
used in U-Boot.
Signed-off-by: Chris Morgan
---
arch/arm/dts/rk3326-odroid-go2-u-boot.dtsi | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/dts/rk3326-odroid-go2-u-boot.dtsi
b/arch/arm/dts/rk3326-odroid-go2-u-boot.dtsi
index 741e8dd935..6d4edc5855 100644
--- a/arch/arm/dts/rk3326-odroid-go2-u-boot.dtsi
+++ b/arch/arm/dts/rk3326-odroid-go2-u-boot.dtsi
@@ -16,6 +16,12 @@
serial2 = &uart2;
spi0 = &sfc;
};
+
+ rng: rng@ff0b {
+ compatible = "rockchip,cryptov2-rng";
+ reg = <0x0 0xff0b 0x0 0x4000>;
+ status = "okay";
+ };
};
&cru {
--
2.25.1
Re: [PATCH 1/1] riscv: enable booting HiFive Unmatched from SATA
On Thu, Aug 26, 2021 at 12:21 AM Heinrich Schuchardt wrote: > > On the HiFive Unmatched a PCI to SATA adapter may be used to install a SATA > drive. Enable booting from it. > > Signed-off-by: Heinrich Schuchardt > --- > configs/sifive_unmatched_defconfig | 5 + > include/configs/sifive-unmatched.h | 3 +++ > 2 files changed, 8 insertions(+) > Reviewed-by: Bin Meng
Re: [PATCH u-boot-marvell 25/29] tools: kwboot: Support higher baudrates when booting via UART
On Wed, 25 Aug 2021 15:46:30 +0200
Marek Behún wrote:
> @@ -765,6 +1187,37 @@ kwboot_img_is_secure(void *img)
> return 0;
> }
>
> +static void *
> +kwboot_img_grow_data_left(void *img, size_t *size, size_t grow)
> +{
> + uint32_t hdrsz, datasz, srcaddr;
> + struct main_hdr_v1 *hdr = img;
> + uint8_t *data;
> +
> + srcaddr = le32_to_cpu(hdr->srcaddr);
> +
> + hdrsz = kwbheader_size(hdr);
> + data = (uint8_t *)img + srcaddr;
> + datasz = *size - srcaddr;
> +
> + /* only move data if there is not enough space */
> + if (hdrsz + grow > srcaddr) {
> + size_t need = hdrsz + grow - srcaddr;
> +
> + /* move data by enough bytes */
> + memmove(data + need, data, datasz);
> + *size += need;
> + srcaddr += need;
> + }
> +
> + srcaddr -= grow;
> + hdr->srcaddr = cpu_to_le32(srcaddr);
> + hdr->destaddr = cpu_to_le32(le32_to_cpu(hdr->destaddr) - grow);
> + hdr->execaddr = cpu_to_le32(le32_to_cpu(hdr->execaddr) - grow);
Sorry, we need to do one more thing here:
hdr->blocksize = cpu_to_le32(le32_to_cpu(hdr->blocksize) + grow);
I will fix this in v2, unless Stefan is willing to fix this himself.
Marek
[PATCH u-boot-marvell 18/29] tools: kwbimage: Simplify iteration over version 1 optional headers
Create macro
for_each_opt_hdr_v1
and functions
opt_hdr_v1_size(),
opt_hdr_v1_valid_size(),
opt_hdr_v1_ext(),
opt_hdr_v1_first() and
opt_hdr_v1_next()
to simplify iteration over version 1 optional headers.
This prevents ugly code repetition and makes it nicer to read.
Signed-off-by: Marek Behún
---
tools/kwbimage.c | 90 +---
tools/kwbimage.h | 58 +++
2 files changed, 81 insertions(+), 67 deletions(-)
diff --git a/tools/kwbimage.c b/tools/kwbimage.c
index ed11c835a5..6678ef15bd 100644
--- a/tools/kwbimage.c
+++ b/tools/kwbimage.c
@@ -1620,34 +1620,20 @@ static void kwbimage_set_header(void *ptr, struct stat
*sbuf, int ifd,
static void kwbimage_print_header(const void *ptr)
{
struct main_hdr_v0 *mhdr = (struct main_hdr_v0 *)ptr;
+ struct opt_hdr_v1 *ohdr;
printf("Image Type: MVEBU Boot from %s Image\n",
image_boot_mode_name(mhdr->blockid));
printf("Image version:%d\n", image_version((void *)ptr));
- if (image_version((void *)ptr) == 1) {
- struct main_hdr_v1 *mhdr = (struct main_hdr_v1 *)ptr;
- if (mhdr->ext & 0x1) {
- struct opt_hdr_v1 *ohdr = (struct opt_hdr_v1 *)
- ((uint8_t *)ptr +
- sizeof(*mhdr));
-
- while (1) {
- uint32_t ohdr_size;
-
- ohdr_size = (ohdr->headersz_msb << 16) |
- le16_to_cpu(ohdr->headersz_lsb);
- if (ohdr->headertype == OPT_HDR_V1_BINARY_TYPE)
{
- printf("BIN Hdr Size: ");
- genimg_print_size(ohdr_size - 12 - 4 *
ohdr->data[0]);
- }
- if (!(*((uint8_t *)ohdr + ohdr_size - 4) & 0x1))
- break;
- ohdr = (struct opt_hdr_v1 *)((uint8_t *)ohdr +
-ohdr_size);
- }
+ for_each_opt_hdr_v1 (ohdr, mhdr) {
+ if (ohdr->headertype == OPT_HDR_V1_BINARY_TYPE) {
+ printf("BIN Hdr Size: ");
+ genimg_print_size(opt_hdr_v1_size(ohdr) - 12 -
+ 4 * ohdr->data[0]);
}
}
+
printf("Data Size:");
genimg_print_size(mhdr->blocksize - sizeof(uint32_t));
printf("Load Address: %08x\n", mhdr->destaddr);
@@ -1694,33 +1680,15 @@ static int kwbimage_verify_header(unsigned char *ptr,
int image_size,
}
} else if (image_version((void *)ptr) == 1) {
struct main_hdr_v1 *mhdr = (struct main_hdr_v1 *)ptr;
+ const uint8_t *mhdr_end;
+ struct opt_hdr_v1 *ohdr;
uint32_t offset;
uint32_t size;
- if (mhdr->ext & 0x1) {
- uint32_t ohdr_size;
- struct opt_hdr_v1 *ohdr = (struct opt_hdr_v1 *)
- (ptr + sizeof(*mhdr));
-
- while (1) {
- if ((uint8_t *)ohdr + sizeof(*ohdr) >
- (uint8_t *)mhdr + header_size)
- return -FDT_ERR_BADSTRUCTURE;
-
- ohdr_size = (ohdr->headersz_msb << 16) |
- le16_to_cpu(ohdr->headersz_lsb);
-
- if (ohdr_size < 8 ||
- (uint8_t *)ohdr + ohdr_size >
- (uint8_t *)mhdr + header_size)
- return -FDT_ERR_BADSTRUCTURE;
-
- if (!(*((uint8_t *)ohdr + ohdr_size - 4) & 0x1))
- break;
- ohdr = (struct opt_hdr_v1 *)((uint8_t *)ohdr +
-ohdr_size);
- }
- }
+ mhdr_end = (uint8_t *)mhdr + header_size;
+ for_each_opt_hdr_v1 (ohdr, ptr)
+ if (!opt_hdr_v1_valid_size(ohdr, mhdr_end))
+ return -FDT_ERR_BADSTRUCTURE;
offset = le32_to_cpu(mhdr->srcaddr);
@@ -1867,36 +1835,24 @@ static int kwbimage_extract_subimage(void *ptr, struct
image_tool_params *params
{
struct main_hdr_v1 *mhdr = (struct main_hdr_v1 *)ptr;
size_t header_size = kwbimage_header_size(ptr);
+ struct opt_hdr_v1 *ohdr;
int idx = params->pflag;
int cur_idx = 0;
uint32_t offset;
ulong image;
ulong size;
-
Re: [PATCH] ARM: mach-at91: fix multiple cpu_reset definition when enabling SYSRESET
Le Tue, 24 Aug 2021 09:51:24 +, a écrit : > On 8/24/21 12:37 PM, Clément Léger wrote: > > Le Mon, 23 Aug 2021 07:42:58 +, > > a écrit : > > > >> On 8/4/21 5:55 PM, Clément Léger wrote: > >>> When SYSRESET is enabled, cpu_reset function is also defined in > >>> sysreset-uclass.c which lead to multiple definitions of this > >>> function since reset.c is build unconditionally. Add a check in > >>> Makefile to build this file only if SYSRESET isn't enabled. > >>> SYSRESET can be enabled when building SYSRESET_PSCI for instance > >>> on this platform. > >> > >> Hello Clement, > >> > >> Does this mean that in fact, the cpu_reset function from the > >> reset.c file has to be implemented as a reset driver in the > >> sysreset uclass ? > > > > Hello Eugen, > > > > In fact, when SYSRESET is selected, the reset_cpu function is > > defined in sysreset-uclass.c. This function will then call the > > appropriate reset function according to registered reset drivers. > > Yes, so, my assumption is then correct, the cpu_reset from reset.c > should be converted to a real driver that has to be registered with > the sysreset-uclass . Oh yes, sorry I did not understood you were talking about converting the sama5d2 reset driver to a read sysreset driver. > > Meanwhile, I guess it's fine to avoid build errors when selecting the > SYSRESET from menuconfig, so I will apply your patch. I wanted to > make sure I fully understand the situation there. Yes, this allows to build using another sysreset driver in the meantime. Clément > > Eugen > > > > > Clément > > > >> > >> Eugen > >> > >>> > >>> Signed-off-by: Clément Léger > >>> --- > >>>arch/arm/mach-at91/armv7/Makefile | 4 +++- > >>>1 file changed, 3 insertions(+), 1 deletion(-) > >>> > >>> diff --git a/arch/arm/mach-at91/armv7/Makefile > >>> b/arch/arm/mach-at91/armv7/Makefile index f5b2665957..246050b67b > >>> 100644 --- a/arch/arm/mach-at91/armv7/Makefile > >>> +++ b/arch/arm/mach-at91/armv7/Makefile > >>> @@ -11,7 +11,9 @@ obj-$(CONFIG_SAMA5D3) += sama5d3_devices.o > >>> clock.o obj-$(CONFIG_SAMA5D4) += sama5d4_devices.o clock.o > >>>obj-$(CONFIG_SAMA7G5) += sama7g5_devices.o > >>>obj-y += cpu.o > >>> -obj-y += reset.o > >>> +ifndef CONFIG_$(SPL_TPL_)SYSRESET > >>> +obj-y += reset.o > >>> +endif > >>>ifneq ($(CONFIG_ATMEL_PIT_TIMER),y) > >>>ifneq ($(CONFIG_MCHP_PIT64B_TIMER),y) > >>># old non-DM timer driver > >>> -- > >>> 2.32.0 > >>> > >> > > > > > > > > -- > > Clément Léger, > > Embedded Linux and Kernel engineer at Bootlin > > https://bootlin.com > > > -- Clément Léger, Embedded Linux and Kernel engineer at Bootlin https://bootlin.com
Re: incompatible device trees between u-boot and linux
On Wed, Aug 25, 2021 at 06:43:23PM +0300, Vladimir Oltean wrote:
> On Wed, Aug 25, 2021 at 11:24:08AM -0400, Tom Rini wrote:
> > On Wed, Aug 25, 2021 at 06:12:20PM +0300, Vladimir Oltean wrote:
> > > On Wed, Aug 25, 2021 at 10:26:10AM -0400, Tom Rini wrote:
> > > > On Wed, Aug 25, 2021 at 05:18:16PM +0300, Vladimir Oltean wrote:
> > > > > On Wed, Aug 25, 2021 at 10:00:45AM -0400, Tom Rini wrote:
> > > > > > On Wed, Aug 25, 2021 at 03:58:10PM +0200, Michael Walle wrote:
> > > > > >
> > > > > > > Hi,
> > > > > > >
> > > > > > > I noticed that there is a fallback to the u-boot device tree for
> > > > > > > linux
> > > > > > > (esp. EFI boot) if no other device tree was found, see [1]. It
> > > > > > > seems this
> > > > > > > is working fine for imx devices, for example, where you can just
> > > > > > > boot a
> > > > > > > stock installer iso via EFI. It will just work and it is quite a
> > > > > > > nice
> > > > > > > feature as a fallback.
> > > > > > >
> > > > > > > Now for the layerscape architecture, the ls1028a in my case,
> > > > > > > things are
> > > > > > > more difficult because the bindings differ between u-boot and
> > > > > > > linux - one
> > > > > > > which comes to mind is DSA and ethernet.
> > > > > > >
> > > > > > > Which begs the general question, is it encouraged to have both
> > > > > > > bindings
> > > > > > > diverge? To me it seems, that most bindings in u-boot are ad-hoc
> > > > > > > and there
> > > > > > > is no real review or alignment but just added as needed, which is
> > > > > > > ok if
> > > > > > > they are local to u-boot. But since they are nowadays passed to
> > > > > > > linux
> > > > > > > (by default!) I'm not so sure anymore.
> > > > > > >
> > > > > > > OTOH The whole structure around a .dts{,i} and -u-boot.dtsi looks
> > > > > > > like
> > > > > > > they should (could?) be shared between linux and u-boot.
> > > > > > >
> > > > > > > -michael
> > > > > > >
> > > > > > > [1]
> > > > > > > https://elixir.bootlin.com/u-boot/v2021.10-rc2/source/common/board_r.c#L471
> > > > > >
> > > > > > The U-Boot device tree is supposed to be able to be passed on to
> > > > > > Linux
> > > > > > and Just Work. The bindings are not supposed to be different
> > > > > > between
> > > > > > the two (except for when we take the binding while it's being
> > > > > > hashed out
> > > > > > upstream BUT THEN RESYNCED).
> > > > >
> > > > > You might need to spell that out a bit clearer.
> > > > >
> > > > > You are saying that both U-Boot and Linux are allowed to have their
> > > > > own
> > > > > custom properties (like 'u-boot,dm-spl' for U-Boot, and 'managed =
> > > > > "in-band-status"'
> > > > > for Linux), as long as the device tree files themselves are in sync,
> > > > > and
> > > > > the subset of the device tree blob understood by Linux (i.e. the
> > > > > U-Boot
> > > > > blob sans the U-Boot specifics) is compatible with the Linux DT blob?
> > > >
> > > > I don't know what about the Linux example makes it Linux specific. But
> > > > yes, 'u-boot,dm-spl' is clearly in our namespace and should be ignored
> > > > by Linux. The whole reason we have the -u-boot.dtsi automatic drop-in
> > > > logic (as much as it can be used is that device trees are device trees
> > > ^
> > > I don't think this parenthesis ever closes...
> >
> > Ah, whoops. Should have been "(as much as it can be used)" because it
> > does get #included instead in some cases, for reasons.
> >
> > >
> > > > and describe the hardware and developers don't need to write a device
> > > > tree for Linux and a device tree for U-Boot and a device tree for
> > > > FreeBSD and ... So yes, you're supposed to use the device tree for a
> > > ^
> > > so I never get the answer to "the whole reason is...".
> > >
> > > > platform and it works here and there and every where.
> > >
> > > The fact that only Linux uses it makes it Linux specific.
> > >
> > > > > To expand even further on that, it means we should put 'managed =
> > > > > "in-band-status"'
> > > > > in U-Boot, which is a Linux phylink device tree property, even if
> > > > > U-Boot
> > > > > does not use phylink?
> > > >
> > > > We should be able to drop in the device trees from Linux and use them.
> > > > Custodians should be re-syncing them periodically. Some are, even.
> > >
> > > Are you ready to take up device tree bindings for PTP timers, PCIe root
> > > complex event collectors, cascaded interrupt controllers, things which
> > > U-Boot will never ever need to support?
> > >
> > > At least in Linux there is a policy to not add device tree nodes that do
> > > not have drivers. Is the same policy not true for U-Boot? At least your
> > > ./scripts/checkpatch.pl does have the same "check for DT compatible
> > > documentation" section as Linux. You might consider removing it if you
> > > want people to not strip the DTs they submit to U-Boot.
> > >
> > > And why do we even maintain the device tree bindings
[PATCH 1/1] Revert "arm64: Layerscape: Survive LPI one-way reset workaround"
Ad-hoc bindings that are not part of the upstream device tree / bindings
are not allowed in-tree. Only bindings that are in-progress with
upstream and then re-synced once agreed upon are.
This reverts commit af288cb291da3abef6be0875527729296f7de7a0.
Cc: Hou Zhiqiang
Cc: Priyanka Jain
Reported-by: Michael Walle
Signed-off-by: Tom Rini
---
arch/arm/cpu/armv8/fsl-layerscape/soc.c | 17 +
arch/arm/dts/fsl-ls1028a.dtsi | 6 --
arch/arm/dts/fsl-ls1088a.dtsi | 6 --
arch/arm/dts/fsl-ls2080a.dtsi | 6 --
arch/arm/dts/fsl-lx2160a.dtsi | 6 --
5 files changed, 1 insertion(+), 40 deletions(-)
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/soc.c
b/arch/arm/cpu/armv8/fsl-layerscape/soc.c
index 42a096854629..12a64baf 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/soc.c
+++ b/arch/arm/cpu/armv8/fsl-layerscape/soc.c
@@ -43,22 +43,7 @@ DECLARE_GLOBAL_DATA_PTR;
#ifdef CONFIG_GIC_V3_ITS
int ls_gic_rd_tables_init(void *blob)
{
- struct fdt_memory lpi_base;
- fdt_addr_t addr;
- fdt_size_t size;
- int offset, ret;
-
- offset = fdt_path_offset(gd->fdt_blob, "/syscon@0x8000");
- addr = fdtdec_get_addr_size_auto_noparent(gd->fdt_blob, offset, "reg",
- 0, &size, false);
-
- lpi_base.start = addr;
- lpi_base.end = addr + size - 1;
- ret = fdtdec_add_reserved_memory(blob, "lpi_rd_table", &lpi_base, NULL,
false);
- if (ret) {
- debug("%s: failed to add reserved memory\n", __func__);
- return ret;
- }
+ int ret;
ret = gic_lpi_tables_init();
if (ret)
diff --git a/arch/arm/dts/fsl-ls1028a.dtsi b/arch/arm/dts/fsl-ls1028a.dtsi
index 50f9b527cde1..53b052ed3271 100644
--- a/arch/arm/dts/fsl-ls1028a.dtsi
+++ b/arch/arm/dts/fsl-ls1028a.dtsi
@@ -44,12 +44,6 @@
IRQ_TYPE_LEVEL_LOW)>;
};
- gic_lpi_base: syscon@0x8000 {
- compatible = "gic-lpi-base";
- reg = <0x0 0x8000 0x0 0x10>;
- max-gic-redistributors = <2>;
- };
-
timer {
compatible = "arm,armv8-timer";
interrupts = ;
};
- gic_lpi_base: syscon@0x8000 {
- compatible = "gic-lpi-base";
- reg = <0x0 0x8000 0x0 0x10>;
- max-gic-redistributors = <8>;
- };
-
timer {
compatible = "arm,armv8-timer";
interrupts = <1 13 0x8>, /* Physical Secure PPI, active-low */
diff --git a/arch/arm/dts/fsl-ls2080a.dtsi b/arch/arm/dts/fsl-ls2080a.dtsi
index 7374d580e07e..278daeeb6eea 100644
--- a/arch/arm/dts/fsl-ls2080a.dtsi
+++ b/arch/arm/dts/fsl-ls2080a.dtsi
@@ -27,12 +27,6 @@
interrupts = <1 9 0x4>;
};
- gic_lpi_base: syscon@0x8000 {
- compatible = "gic-lpi-base";
- reg = <0x0 0x8000 0x0 0x10>;
- max-gic-redistributors = <8>;
- };
-
timer {
compatible = "arm,armv8-timer";
interrupts = <1 13 0x8>, /* Physical Secure PPI, active-low */
diff --git a/arch/arm/dts/fsl-lx2160a.dtsi b/arch/arm/dts/fsl-lx2160a.dtsi
index a6f0e9bc56be..3b5f0d119e76 100644
--- a/arch/arm/dts/fsl-lx2160a.dtsi
+++ b/arch/arm/dts/fsl-lx2160a.dtsi
@@ -43,12 +43,6 @@
interrupts = <1 9 0x4>;
};
- gic_lpi_base: syscon@0x8000 {
- compatible = "gic-lpi-base";
- reg = <0x0 0x8000 0x0 0x20>;
- max-gic-redistributors = <16>;
- };
-
timer {
compatible = "arm,armv8-timer";
interrupts = <1 13 0x8>, /* Physical Secure PPI, active-low */
--
2.17.1
Re: incompatible device trees between u-boot and linux
> Date: Wed, 25 Aug 2021 18:12:20 +0300
> From: Vladimir Oltean
>
> On Wed, Aug 25, 2021 at 10:26:10AM -0400, Tom Rini wrote:
> > On Wed, Aug 25, 2021 at 05:18:16PM +0300, Vladimir Oltean wrote:
> > > On Wed, Aug 25, 2021 at 10:00:45AM -0400, Tom Rini wrote:
> > > > On Wed, Aug 25, 2021 at 03:58:10PM +0200, Michael Walle wrote:
> > > >
> > > > > Hi,
> > > > >
> > > > > I noticed that there is a fallback to the u-boot device tree
> > > > > for linux (esp. EFI boot) if no other device tree was found,
> > > > > see [1]. It seems this is working fine for imx devices, for
> > > > > example, where you can just boot a stock installer iso via
> > > > > EFI. It will just work and it is quite a nice feature as a
> > > > > fallback.
> > > > >
> > > > > Now for the layerscape architecture, the ls1028a in my case,
> > > > > things are more difficult because the bindings differ
> > > > > between u-boot and linux - one which comes to mind is DSA
> > > > > and ethernet.
> > > > >
> > > > > Which begs the general question, is it encouraged to have
> > > > > both bindings diverge? To me it seems, that most bindings in
> > > > > u-boot are ad-hoc and there is no real review or alignment
> > > > > but just added as needed, which is ok if they are local to
> > > > > u-boot. But since they are nowadays passed to linux (by
> > > > > default!) I'm not so sure anymore.
> > > > >
> > > > > OTOH The whole structure around a .dts{,i} and -u-boot.dtsi
> > > > > looks like they should (could?) be shared between linux and
> > > > > u-boot.
> > > > >
> > > > > -michael
> > > > >
> > > > > [1]
> > > > > https://elixir.bootlin.com/u-boot/v2021.10-rc2/source/common/board_r.c#L471
> > > >
> > > > The U-Boot device tree is supposed to be able to be passed on
> > > > to Linux and Just Work. The bindings are not supposed to be
> > > > different between the two (except for when we take the binding
> > > > while it's being hashed out upstream BUT THEN RESYNCED).
> > >
> > > You might need to spell that out a bit clearer.
> > >
> > > You are saying that both U-Boot and Linux are allowed to have
> > > their own custom properties (like 'u-boot,dm-spl' for U-Boot,
> > > and 'managed = "in-band-status"' for Linux), as long as the
> > > device tree files themselves are in sync, and the subset of the
> > > device tree blob understood by Linux (i.e. the U-Boot blob sans
> > > the U-Boot specifics) is compatible with the Linux DT blob?
> >
> > I don't know what about the Linux example makes it Linux specific. But
> > yes, 'u-boot,dm-spl' is clearly in our namespace and should be ignored
> > by Linux. The whole reason we have the -u-boot.dtsi automatic drop-in
> > logic (as much as it can be used is that device trees are device trees
> ^
> I don't think this parenthesis ever closes...
>
> > and describe the hardware and developers don't need to write a device
> > tree for Linux and a device tree for U-Boot and a device tree for
> > FreeBSD and ... So yes, you're supposed to use the device tree for a
> ^
> so I never get the answer to "the whole reason is...".
>
> > platform and it works here and there and every where.
>
> The fact that only Linux uses it makes it Linux specific.
Huh? Other OSes use device trees as well on various platforms. There
are (somewhat) linux-specific properties in those device trees in the
"linux," namespace.
For OpenBSD we don't maintain our own set of device trees. Instead we
rely on the device tree provided by U-Boot and distribute device trees
built from the Linux tree as an alternative that users can install if
the U-Boot device tree is a bit behind.
> > > To expand even further on that, it means we should put 'managed
> > > = "in-band-status"' in U-Boot, which is a Linux phylink device
> > > tree property, even if U-Boot does not use phylink?
> >
> > We should be able to drop in the device trees from Linux and use them.
> > Custodians should be re-syncing them periodically. Some are, even.
>
> Are you ready to take up device tree bindings for PTP timers, PCIe root
> complex event collectors, cascaded interrupt controllers, things which
> U-Boot will never ever need to support?
The policy is that U-Boot uses a verbatim copy of the device tree
source files from Linux (.dts and .dtsi files) and augments that
device tree if necessary by using a *-u-boot.dts files that ideally
only add properties in the "u-boot," namespace.
That policy isn't always followed though. In some cases support for
certain hardware is added to U-Boot early, before "official" DT
bindings have been established. These should be replaced with the
"official" device tree from Linux as soon as possible, but that
doesn't always happen in a timely fashion.
Unfortunately what happens quite often is that hardware vendors
provide patches with preliminary bindings from their own Linux fork
before their devices are fully supported in the mainline Linux tree.
What also happens is that the DT binding
Re: [PATCH 1/1] riscv: enable booting HiFive Unmatched from SATA
> From: Heinrich Schuchardt > Date: Wed, 25 Aug 2021 18:21:57 +0200 > > On the HiFive Unmatched a PCI to SATA adapter may be used to install a SATA > drive. Enable booting from it. > > Signed-off-by: Heinrich Schuchardt Reviewed-by: Mark Kettenis > --- > configs/sifive_unmatched_defconfig | 5 + > include/configs/sifive-unmatched.h | 3 +++ > 2 files changed, 8 insertions(+) > > diff --git a/configs/sifive_unmatched_defconfig > b/configs/sifive_unmatched_defconfig > index 38b7acd536..1dde98e0ae 100644 > --- a/configs/sifive_unmatched_defconfig > +++ b/configs/sifive_unmatched_defconfig > @@ -7,6 +7,7 @@ CONFIG_DEFAULT_DEVICE_TREE="hifive-unmatched-a00" > CONFIG_SPL_MMC_SUPPORT=y > CONFIG_SPL=y > CONFIG_SPL_SPI_SUPPORT=y > +CONFIG_AHCI=y > CONFIG_TARGET_SIFIVE_UNMATCHED=y > CONFIG_ARCH_RV64I=y > CONFIG_RISCV_SMODE=y > @@ -28,12 +29,16 @@ CONFIG_CMD_GPT_RENAME=y > CONFIG_CMD_PCI=y > CONFIG_CMD_USB=y > CONFIG_SYS_RELOC_GD_ENV_ADDR=y > +CONFIG_SCSI_AHCI=y > +CONFIG_AHCI_PCI=y > CONFIG_SPL_CLK=y > CONFIG_E1000=y > CONFIG_NVME=y > CONFIG_PCI=y > CONFIG_PCIE_DW_SIFIVE=y > CONFIG_DM_RESET=y > +CONFIG_SCSI=y > +CONFIG_DM_SCSI=y > CONFIG_USB=y > CONFIG_USB_XHCI_HCD=y > CONFIG_USB_XHCI_PCI=y > diff --git a/include/configs/sifive-unmatched.h > b/include/configs/sifive-unmatched.h > index cb7f0c0fd9..f8ad2cce1f 100644 > --- a/include/configs/sifive-unmatched.h > +++ b/include/configs/sifive-unmatched.h > @@ -40,6 +40,8 @@ > > #define CONFIG_SYS_CACHELINE_SIZE64 > > +#define CONFIG_SYS_SCSI_MAX_SCSI_ID 4 > + > /* Environment options */ > > #ifndef CONFIG_SPL_BUILD > @@ -47,6 +49,7 @@ > func(NVME, nvme, 0) \ > func(USB, usb, 0) \ > func(MMC, mmc, 0) \ > + func(SCSI, scsi, 0) \ > func(PXE, pxe, na) \ > func(DHCP, dhcp, na) > > -- > 2.32.0 > >
Re: [PATCH 00/28] Initial implementation of bootmethod/bootflow
> From: Peter Robinson > Date: Wed, 25 Aug 2021 14:29:45 +0100 > > > > Exactly. Keep in mind that RISC-V is looking into EBBR as well, > > > so this is far from an 'Arm thing'. Moreover, the efi stub side > > > of the kernel for risc-v, will only load an initrd using the > > > EFI_LOAD_FILE2 protocol we added support for. So right now the > > > only way to properly boot a RISC-V with EFI is through the > > > manager. > > > > I had heard that RISC-V was just going to use UEFI (and not U-Boot), > > but perhaps that is not correct. So far I have not really done > > anything with RISC-V so am not familiar with it. > > My understanding is the intention is to just use UEFI of which U-Boot > has a UEFI implementation. The HiFive Unmatched ships with U-Boot. I'm booting OpenBSD via UEFI on that board by using the uSD card that came with the board. The folks pushing the spec for RISC-V server hardware are probably considering a more traditional UEFI implementation for those systems since they also seem to be pushing for ACPI. But they explicitly mention EBBR for "embedded" systems, and EBBR was deliberately designed to allow the implementation of compliant systems using U-Boot's UEFI implementation.
Re: [PATCH v5 4/7] mmc: zynq_sdhci: Add xilinx_pm_request() method to set tapdelays
On 8/3/21 2:20 PM, Ashok Reddy Soma wrote:
> Currently xilinx sdhci driver is using zynqmp_mmio_write() to set
> tapdelay values and DLL resets. Continue to use this for SPL and mini
> U-Boot where U-Boot will be executed at EL3 level.
>
> Use firmware call xilinx_pm_request() using appropriate arguments to
> set input/output tapdelays and also for DLL resets in regular flow(EL2).
>
> Host driver should explicitly request DLL reset before ITAP (assert DLL)
> and after OTAP (release DLL) to avoid issues in some cases. Also handle
> error return where possible.
>
> Signed-off-by: T Karthik Reddy
> Signed-off-by: Ashok Reddy Soma
Reviewed-by: Jaehoon Chung
Best Regards,
Jaehoon Chung
> ---
>
> (no changes since v3)
>
> Changes in v3:
> - As we are seeing issues with SPL flow, keep zynqmp_mmio_write method
>to set tapdelay's and DLL resets. Add xilinx_pm_request on top of it
>for regular flow.
> - Changed the patch title to reflect these changes
>
> Changes in v2:
> - Added comment for why 1ms delay is needed between DLL assert and
> release
> - Remove mmc->dev->seq_ and use priv->deviceid instead
>
> board/xilinx/zynqmp/tap_delays.c | 148 +--
> drivers/mmc/zynq_sdhci.c | 73 ---
> include/zynqmp_tap_delay.h | 25 --
> 3 files changed, 159 insertions(+), 87 deletions(-)
>
> diff --git a/board/xilinx/zynqmp/tap_delays.c
> b/board/xilinx/zynqmp/tap_delays.c
> index d16bbb8eff..514f86a29a 100644
> --- a/board/xilinx/zynqmp/tap_delays.c
> +++ b/board/xilinx/zynqmp/tap_delays.c
> @@ -8,94 +8,108 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> +#include
>
> #define SD_DLL_CTRL 0xFF180358
> #define SD_ITAP_DLY 0xFF180314
> #define SD_OTAP_DLY 0xFF180318
> -#define SD0_DLL_RST_MASK 0x0004
> -#define SD0_DLL_RST 0x0004
> -#define SD1_DLL_RST_MASK 0x0004
> -#define SD1_DLL_RST 0x0004
> -#define SD0_ITAPCHGWIN_MASK 0x0200
> -#define SD0_ITAPCHGWIN 0x0200
> -#define SD1_ITAPCHGWIN_MASK 0x0200
> -#define SD1_ITAPCHGWIN 0x0200
> -#define SD0_ITAPDLYENA_MASK 0x0100
> -#define SD0_ITAPDLYENA 0x0100
> -#define SD1_ITAPDLYENA_MASK 0x0100
> -#define SD1_ITAPDLYENA 0x0100
> -#define SD0_ITAPDLYSEL_MASK 0x00FF
> -#define SD1_ITAPDLYSEL_MASK 0x00FF
> -#define SD0_OTAPDLYSEL_MASK 0x003F
> -#define SD1_OTAPDLYSEL_MASK 0x003F
> +#define SD0_DLL_RST BIT(2)
> +#define SD1_DLL_RST BIT(18)
> +#define SD0_ITAPCHGWIN BIT(9)
> +#define SD1_ITAPCHGWIN BIT(25)
> +#define SD0_ITAPDLYENA BIT(8)
> +#define SD1_ITAPDLYENA BIT(24)
> +#define SD0_ITAPDLYSEL_MASK GENMASK(7, 0)
> +#define SD1_ITAPDLYSEL_MASK GENMASK(23, 16)
> +#define SD0_OTAPDLYSEL_MASK GENMASK(5, 0)
> +#define SD1_OTAPDLYSEL_MASK GENMASK(21, 16)
>
> -void zynqmp_dll_reset(u8 deviceid)
> +int zynqmp_dll_reset(u8 node_id, u32 type)
> {
> - /* Issue DLL Reset */
> - if (deviceid == 0)
> - zynqmp_mmio_write(SD_DLL_CTRL, SD0_DLL_RST_MASK,
> - SD0_DLL_RST);
> - else
> - zynqmp_mmio_write(SD_DLL_CTRL, SD1_DLL_RST_MASK,
> - SD1_DLL_RST);
> + if (IS_ENABLED(CONFIG_SPL_BUILD) || current_el() == 3) {
> + if (node_id == NODE_SD_0)
> + return zynqmp_mmio_write(SD_DLL_CTRL, SD0_DLL_RST,
> + type == PM_DLL_RESET_ASSERT ?
> + SD0_DLL_RST : 0);
>
> - mdelay(1);
> -
> - /* Release DLL Reset */
> - if (deviceid == 0)
> - zynqmp_mmio_write(SD_DLL_CTRL, SD0_DLL_RST_MASK, 0x0);
> - else
> - zynqmp_mmio_write(SD_DLL_CTRL, SD1_DLL_RST_MASK, 0x0);
> + return zynqmp_mmio_write(SD_DLL_CTRL, SD1_DLL_RST,
> + type == PM_DLL_RESET_ASSERT ?
> + SD1_DLL_RST : 0);
> + } else {
> + return xilinx_pm_request(PM_IOCTL, (u32)node_id,
> + IOCTL_SD_DLL_RESET, type, 0, NULL);
> + }
> }
>
> -void arasan_zynqmp_set_in_tapdelay(u8 deviceid, u32 itap_delay)
> +int arasan_zynqmp_set_in_tapdelay(u8 node_id, u32 itap_delay)
> {
> - if (deviceid == 0) {
> - zynqmp_mmio_write(SD_DLL_CTRL, SD0_DLL_RST_MASK, SD0_DLL_RST);
> + int ret;
>
> - /* Program ITAP delay */
> - zynqmp_mmio_write(SD_ITAP_DLY, SD0_ITAPCHGWIN_MASK,
> - SD0_ITAPCHGWIN);
>
Re: [PATCH v5 5/7] mmc: zynq_sdhci: Move setting tapdelay code to driver
On 8/3/21 2:20 PM, Ashok Reddy Soma wrote:
> Move tapdelay function calls to zynq_sdhci.c and make them static
> inline. zynqmp_tap_delay.h has function prototypes for the functions
> defined in tap_delays.c, which will not be needed anymore.
>
> Remove tap_delays.c and zynqmp_tap_delay.h files.
>
> Signed-off-by: Ashok Reddy Soma
Reviewed-by: Jaehoon Chung
Best Regards,
Jaehoon Chung
> ---
>
> (no changes since v3)
>
> Changes in v3:
> - Make the changes on top of patch 4/7 to move the code to zynq_sdhci.c
>
> board/xilinx/zynqmp/Makefile | 2 -
> board/xilinx/zynqmp/tap_delays.c | 115 ---
> drivers/mmc/zynq_sdhci.c | 108 -
> include/zynqmp_tap_delay.h | 34 -
> 4 files changed, 107 insertions(+), 152 deletions(-)
> delete mode 100644 board/xilinx/zynqmp/tap_delays.c
> delete mode 100644 include/zynqmp_tap_delay.h
>
> diff --git a/board/xilinx/zynqmp/Makefile b/board/xilinx/zynqmp/Makefile
> index 7d8277ca40..a914028753 100644
> --- a/board/xilinx/zynqmp/Makefile
> +++ b/board/xilinx/zynqmp/Makefile
> @@ -44,8 +44,6 @@ $(obj)/pm_cfg_obj.o: $(shell cd $(srctree); readlink -f
> $(CONFIG_ZYNQMP_SPL_PM_C
> endif
> endif
>
> -obj-$(CONFIG_MMC_SDHCI_ZYNQ) += tap_delays.o
> -
> ifndef CONFIG_SPL_BUILD
> obj-$(CONFIG_CMD_ZYNQMP) += cmds.o
> endif
> diff --git a/board/xilinx/zynqmp/tap_delays.c
> b/board/xilinx/zynqmp/tap_delays.c
> deleted file mode 100644
> index 514f86a29a..00
> --- a/board/xilinx/zynqmp/tap_delays.c
> +++ /dev/null
> @@ -1,115 +0,0 @@
> -// SPDX-License-Identifier: GPL-2.0
> -/*
> - * Xilinx ZynqMP SoC Tap Delay Programming
> - *
> - * Copyright (C) 2018 Xilinx, Inc.
> - */
> -
> -#include
> -#include
> -#include
> -#include
> -#include
> -#include
> -#include
> -
> -#define SD_DLL_CTRL 0xFF180358
> -#define SD_ITAP_DLY 0xFF180314
> -#define SD_OTAP_DLY 0xFF180318
> -#define SD0_DLL_RST BIT(2)
> -#define SD1_DLL_RST BIT(18)
> -#define SD0_ITAPCHGWIN BIT(9)
> -#define SD1_ITAPCHGWIN BIT(25)
> -#define SD0_ITAPDLYENA BIT(8)
> -#define SD1_ITAPDLYENA BIT(24)
> -#define SD0_ITAPDLYSEL_MASK GENMASK(7, 0)
> -#define SD1_ITAPDLYSEL_MASK GENMASK(23, 16)
> -#define SD0_OTAPDLYSEL_MASK GENMASK(5, 0)
> -#define SD1_OTAPDLYSEL_MASK GENMASK(21, 16)
> -
> -int zynqmp_dll_reset(u8 node_id, u32 type)
> -{
> - if (IS_ENABLED(CONFIG_SPL_BUILD) || current_el() == 3) {
> - if (node_id == NODE_SD_0)
> - return zynqmp_mmio_write(SD_DLL_CTRL, SD0_DLL_RST,
> - type == PM_DLL_RESET_ASSERT ?
> - SD0_DLL_RST : 0);
> -
> - return zynqmp_mmio_write(SD_DLL_CTRL, SD1_DLL_RST,
> - type == PM_DLL_RESET_ASSERT ?
> - SD1_DLL_RST : 0);
> - } else {
> - return xilinx_pm_request(PM_IOCTL, (u32)node_id,
> - IOCTL_SD_DLL_RESET, type, 0, NULL);
> - }
> -}
> -
> -int arasan_zynqmp_set_in_tapdelay(u8 node_id, u32 itap_delay)
> -{
> - int ret;
> -
> - if (IS_ENABLED(CONFIG_SPL_BUILD) || current_el() == 3) {
> - if (node_id == NODE_SD_0) {
> - ret = zynqmp_mmio_write(SD_ITAP_DLY, SD0_ITAPCHGWIN,
> - SD0_ITAPCHGWIN);
> - if (ret)
> - return ret;
> -
> - ret = zynqmp_mmio_write(SD_ITAP_DLY, SD0_ITAPDLYENA,
> - SD0_ITAPDLYENA);
> - if (ret)
> - return ret;
> -
> - ret = zynqmp_mmio_write(SD_ITAP_DLY,
> - SD0_ITAPDLYSEL_MASK,
> - itap_delay);
> - if (ret)
> - return ret;
> -
> - ret = zynqmp_mmio_write(SD_ITAP_DLY, SD0_ITAPCHGWIN, 0);
> - if (ret)
> - return ret;
> - }
> - ret = zynqmp_mmio_write(SD_ITAP_DLY, SD1_ITAPCHGWIN,
> - SD1_ITAPCHGWIN);
> - if (ret)
> - return ret;
> -
> - ret = zynqmp_mmio_write(SD_ITAP_DLY, SD1_ITAPDLYENA,
> - SD1_ITAPDLYENA);
> - if (ret)
> - return ret;
> -
> - ret = zynqmp_mmio_write(SD_ITAP_DLY, SD1_ITAPDLYSEL_MASK,
> - (itap_delay << 16));
> - if (ret)
> - return ret;
> -
> - ret = zynqmp_mmio_writ
Re: [PATCH] mmc: fsl_esdhc_imx: Fix clock disable issue
On 8/17/21 6:09 PM, Ye Li wrote:
> The SD clock disable is wrapped by MMC_SUPPORTS_TUNING. So it
> only works when UHS is enabled. However, in SD initialization the
> power cycle does not depends on UHS. But the power cycle needs
> disable the SD clock before power down.
> So this causes a problem when UHS is not enabled. Some cards can't
> become ready (ACMD14 timeout) due to the clock is enabled during
> power cycle.
>
> Signed-off-by: Ye Li
> Reviewed-by: Haibo Chen
Reviewed-by: Jaehoon Chung
Best Regards,
Jaehoon Chung
> ---
> drivers/mmc/fsl_esdhc_imx.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/mmc/fsl_esdhc_imx.c b/drivers/mmc/fsl_esdhc_imx.c
> index aabf395..7b67972 100644
> --- a/drivers/mmc/fsl_esdhc_imx.c
> +++ b/drivers/mmc/fsl_esdhc_imx.c
> @@ -971,7 +971,6 @@ static int esdhc_set_ios_common(struct fsl_esdhc_priv
> *priv, struct mmc *mmc)
> if (priv->clock != clock)
> set_sysctl(priv, mmc, clock);
>
> -#ifdef MMC_SUPPORTS_TUNING
> if (mmc->clk_disable) {
> #ifdef CONFIG_FSL_USDHC
> esdhc_clrbits32(®s->vendorspec, VENDORSPEC_CKEN);
> @@ -987,6 +986,7 @@ static int esdhc_set_ios_common(struct fsl_esdhc_priv
> *priv, struct mmc *mmc)
> #endif
> }
>
> +#ifdef MMC_SUPPORTS_TUNING
> /*
>* For HS400/HS400ES mode, make sure set the strobe dll in the
>* target clock rate. So call esdhc_set_strobe_dll() after the
>
Re: [PATCH 00/28] Initial implementation of bootmethod/bootflow
> Date: Wed, 25 Aug 2021 10:56:35 -0400 > From: Tom Rini > > On Wed, Aug 25, 2021 at 11:42:51PM +0900, AKASHI Takahiro wrote: > > Simon, > > > > On Wed, Aug 25, 2021 at 07:11:44AM -0600, Simon Glass wrote: > > > Hi, > > > > > > On Wed, 25 Aug 2021 at 04:45, Emmanuel Vadot > > > wrote: > > > > > > > > On Tue, 24 Aug 2021 12:22:42 +0200 (CEST) > > > > Mark Kettenis wrote: > > > > > > > > > > Date: Mon, 23 Aug 2021 16:01:46 -0400 > > > > > > From: Tom Rini > > > > > > > > > > > > On Mon, Aug 23, 2021 at 11:25:42AM -0600, Simon Glass wrote: > > > > > > > Hi Mark, > > > > > > > > > > > > > > On Mon, 23 Aug 2021 at 05:54, Mark Kettenis > > > > > > > wrote: > > > > > > > > > > > > > > > > > From: Simon Glass > > > > > > > > > Date: Wed, 18 Aug 2021 21:45:33 -0600 > > > > > > > > > > > > > > > > > > Bootmethod and bootflow provide a built-in way for U-Boot to > > > > > > > > > automatically boot > > > > > > > > > an Operating System without custom scripting and other > > > > > > > > > customisation: > > > > > > > > > > > > > > > > > > - bootmethod - a method to scan a device to find bootflows > > > > > > > > > (owned by U-Boot) > > > > > > > > > - bootflow - a description of how to boot (owned by the > > > > > > > > > distro) > > > > > > > > > > > > > > > > > > This series provides an initial implementation of these, > > > > > > > > > enable to scan > > > > > > > > > for bootflows from MMC and Ethernet. The only bootflow > > > > > > > > > supported is > > > > > > > > > distro boot, i.e. an extlinux.conf file included on a > > > > > > > > > filesystem or > > > > > > > > > tftp server. It works similiarly to the existing script-based > > > > > > > > > approach, > > > > > > > > > but is native to U-Boot. > > > > > > > > > > > > > > > > > > With this we can boot on a Raspberry Pi 3 with just one > > > > > > > > > command: > > > > > > > > > > > > > > > > > >bootflow scan -lb > > > > > > > > > > > > > > > > > > which means to scan, listing (-l) each bootflow and trying to > > > > > > > > > boot each > > > > > > > > > one (-b). The final patch shows this. > > > > > > > > > > > > > > > > > > It is intended that this approach be expanded to support > > > > > > > > > mechanisms other > > > > > > > > > than distro boot, including EFI-related ones. With a standard > > > > > > > > > way to > > > > > > > > > identify boot devices, these features become easier. It also > > > > > > > > > should > > > > > > > > > support U-Boot scripts, for backwards compatibility only. > > > > > > > > > > > > > > > > > > The first patch of this series moves boot-related code out of > > > > > > > > > common/ and > > > > > > > > > into a new boot/ directory. This helps to collect these > > > > > > > > > related files > > > > > > > > > in one place, as common/ is quite large. > > > > > > > > > > > > > > > > > > Like sysboot, this feature makes use of the existing PXE > > > > > > > > > implementation. > > > > > > > > > Much of this series consists of cleaning up that code and > > > > > > > > > refactoring it > > > > > > > > > into something closer to a module that can be called, teasing > > > > > > > > > apart its > > > > > > > > > reliance on the command-line interpreter to access > > > > > > > > > filesystems and the > > > > > > > > > like. Also it now uses function arguments and its own context > > > > > > > > > struct > > > > > > > > > internally rather than environment variables, which is very > > > > > > > > > hard to > > > > > > > > > follow. No core functional change is included in the included > > > > > > > > > PXE patches. > > > > > > > > > > > > > > > > > > For documentation, see the 'doc' patch. > > > > > > > > > > > > > > > > > > There is quite a long list of future work included in the > > > > > > > > > documentation. > > > > > > > > > One question is the choice of naming. Since this is a > > > > > > > > > bootloader, should > > > > > > > > > we just call this a 'method' and a 'flow' ? The 'boot' prefix > > > > > > > > > is already > > > > > > > > > shared by other commands like bootm, booti, etc. > > > > > > > > > > > > > > > > > > The design is described here: > > > > > > > > > > > > > > > > > > https://drive.google.com/file/d/1ggW0KJpUOR__vBkj3l61L2dav4ZkNC12/view?usp=sharing > > > > > > > > > > > > > > > > > > The series is available at u-boot-dm/bmea-working > > > > > > > > > > > > > > > > How does the user control the order in which devices are > > > > > > > > scanned/booted? > > > > > > > > > > > > > > That is not supported in distroboot at present, at least so far > > > > > > > as I > > > > > > > can see. For Fedora it seems to happen in grub. Do I have that > > > > > > > right? > > > > > > > > > > > > Well, there's "find the next stage", which is boot_targets > > > > > > environment > > > > > > variable, and then "where that next stage looks for stuff" which is > > > > > > OS-dependent. Sometimes the ESP grub.cfg file is just enough to > > > > > > tell > > > > > > grub to find t
Re: [PATCH 00/28] Initial implementation of bootmethod/bootflow
On Wed, Aug 25, 2021 at 11:34:45PM +0200, Mark Kettenis wrote: > > From: Peter Robinson > > Date: Wed, 25 Aug 2021 14:29:45 +0100 > > > > > > Exactly. Keep in mind that RISC-V is looking into EBBR as well, > > > > so this is far from an 'Arm thing'. Moreover, the efi stub side > > > > of the kernel for risc-v, will only load an initrd using the > > > > EFI_LOAD_FILE2 protocol we added support for. So right now the > > > > only way to properly boot a RISC-V with EFI is through the > > > > manager. > > > > > > I had heard that RISC-V was just going to use UEFI (and not U-Boot), > > > but perhaps that is not correct. So far I have not really done > > > anything with RISC-V so am not familiar with it. > > > > My understanding is the intention is to just use UEFI of which U-Boot > > has a UEFI implementation. > > The HiFive Unmatched ships with U-Boot. I'm booting OpenBSD via UEFI > on that board by using the uSD card that came with the board. > > The folks pushing the spec for RISC-V server hardware are probably > considering a more traditional UEFI implementation for those systems > since they also seem to be pushing for ACPI. But they explicitly > mention EBBR for "embedded" systems, and EBBR was deliberately > designed to allow the implementation of compliant systems using > U-Boot's UEFI implementation. I don't know if any of the "right" people are listening here, but, I don't see why ACPI precludes U-Boot. We ship ACPI tables for x86 already... -- Tom signature.asc Description: PGP signature
Re: [PATCH 00/28] Initial implementation of bootmethod/bootflow
On Wed, Aug 25, 2021 at 11:54:58PM +0200, Mark Kettenis wrote: > > Date: Wed, 25 Aug 2021 10:56:35 -0400 > > From: Tom Rini > > > > On Wed, Aug 25, 2021 at 11:42:51PM +0900, AKASHI Takahiro wrote: > > > Simon, > > > > > > On Wed, Aug 25, 2021 at 07:11:44AM -0600, Simon Glass wrote: > > > > Hi, > > > > > > > > On Wed, 25 Aug 2021 at 04:45, Emmanuel Vadot > > > > wrote: > > > > > > > > > > On Tue, 24 Aug 2021 12:22:42 +0200 (CEST) > > > > > Mark Kettenis wrote: > > > > > > > > > > > > Date: Mon, 23 Aug 2021 16:01:46 -0400 > > > > > > > From: Tom Rini > > > > > > > > > > > > > > On Mon, Aug 23, 2021 at 11:25:42AM -0600, Simon Glass wrote: > > > > > > > > Hi Mark, > > > > > > > > > > > > > > > > On Mon, 23 Aug 2021 at 05:54, Mark Kettenis > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > From: Simon Glass > > > > > > > > > > Date: Wed, 18 Aug 2021 21:45:33 -0600 > > > > > > > > > > > > > > > > > > > > Bootmethod and bootflow provide a built-in way for U-Boot > > > > > > > > > > to automatically boot > > > > > > > > > > an Operating System without custom scripting and other > > > > > > > > > > customisation: > > > > > > > > > > > > > > > > > > > > - bootmethod - a method to scan a device to find > > > > > > > > > > bootflows (owned by U-Boot) > > > > > > > > > > - bootflow - a description of how to boot (owned by the > > > > > > > > > > distro) > > > > > > > > > > > > > > > > > > > > This series provides an initial implementation of these, > > > > > > > > > > enable to scan > > > > > > > > > > for bootflows from MMC and Ethernet. The only bootflow > > > > > > > > > > supported is > > > > > > > > > > distro boot, i.e. an extlinux.conf file included on a > > > > > > > > > > filesystem or > > > > > > > > > > tftp server. It works similiarly to the existing > > > > > > > > > > script-based approach, > > > > > > > > > > but is native to U-Boot. > > > > > > > > > > > > > > > > > > > > With this we can boot on a Raspberry Pi 3 with just one > > > > > > > > > > command: > > > > > > > > > > > > > > > > > > > >bootflow scan -lb > > > > > > > > > > > > > > > > > > > > which means to scan, listing (-l) each bootflow and trying > > > > > > > > > > to boot each > > > > > > > > > > one (-b). The final patch shows this. > > > > > > > > > > > > > > > > > > > > It is intended that this approach be expanded to support > > > > > > > > > > mechanisms other > > > > > > > > > > than distro boot, including EFI-related ones. With a > > > > > > > > > > standard way to > > > > > > > > > > identify boot devices, these features become easier. It > > > > > > > > > > also should > > > > > > > > > > support U-Boot scripts, for backwards compatibility only. > > > > > > > > > > > > > > > > > > > > The first patch of this series moves boot-related code out > > > > > > > > > > of common/ and > > > > > > > > > > into a new boot/ directory. This helps to collect these > > > > > > > > > > related files > > > > > > > > > > in one place, as common/ is quite large. > > > > > > > > > > > > > > > > > > > > Like sysboot, this feature makes use of the existing PXE > > > > > > > > > > implementation. > > > > > > > > > > Much of this series consists of cleaning up that code and > > > > > > > > > > refactoring it > > > > > > > > > > into something closer to a module that can be called, > > > > > > > > > > teasing apart its > > > > > > > > > > reliance on the command-line interpreter to access > > > > > > > > > > filesystems and the > > > > > > > > > > like. Also it now uses function arguments and its own > > > > > > > > > > context struct > > > > > > > > > > internally rather than environment variables, which is very > > > > > > > > > > hard to > > > > > > > > > > follow. No core functional change is included in the > > > > > > > > > > included PXE patches. > > > > > > > > > > > > > > > > > > > > For documentation, see the 'doc' patch. > > > > > > > > > > > > > > > > > > > > There is quite a long list of future work included in the > > > > > > > > > > documentation. > > > > > > > > > > One question is the choice of naming. Since this is a > > > > > > > > > > bootloader, should > > > > > > > > > > we just call this a 'method' and a 'flow' ? The 'boot' > > > > > > > > > > prefix is already > > > > > > > > > > shared by other commands like bootm, booti, etc. > > > > > > > > > > > > > > > > > > > > The design is described here: > > > > > > > > > > > > > > > > > > > > https://drive.google.com/file/d/1ggW0KJpUOR__vBkj3l61L2dav4ZkNC12/view?usp=sharing > > > > > > > > > > > > > > > > > > > > The series is available at u-boot-dm/bmea-working > > > > > > > > > > > > > > > > > > How does the user control the order in which devices are > > > > > > > > > scanned/booted? > > > > > > > > > > > > > > > > That is not supported in distroboot at present, at least so far > > > > > > > > as I > > > > > > > > can see. For Fedora it seems to happen in grub. Do I have that > > > > > > > > right? > > > > > > > > > > > > > > We
Re: How should we deal with actual hush odd behavior?
On Fri, Aug 20, 2021 at 12:22:22PM -0600, Simon Glass wrote: > Hi Francis, > > On Fri, 20 Aug 2021 at 10:12, Francis Laniel > wrote: > > > > Hi. > > > > > > I hope you are fine and the same for your family and friends. > > > > In July, a proposal to add a new shell for U-Boot was posted on the mailing > > list [1]. > > The community discussed a lot about this changes, some people did not agree > > with it because the new shell is not compatible with the actual one (hush) > > [2]. > > So, a proposal to update U-Boot actual hush to follow what they currently > > have > > in Busybox was made [3]. > > > > Porting 2021 Busybox hush to U-Boot seems, for me, to be a good idea as we > > would benefit from Busybox bug fixes as well as being compatible with actual > > hush (in theory). > > We could also add new features to U-Boot hush, like functions, as they were > > added to Busybox. > > > > Nonetheless, the idea of this port is to be compatible. > > In practice, I noted some cases when this is actually not the case. > > The first one can be related to how && and || operators were handled in > > hush. > > So, the following: false && false || true > > Returns 0 on Busybox 2021 hush and 1 on U-Boot. > > The behavior of 2021 is coherent with the definition of these operators [4]: > > >The return status of AND and OR lists is the exit > > >status of the last command executed in the list. > > An other example concerns variable expansion, where foo='bar "quux" is > > expanded to bar quux in U-Boot and bar "quux in Busybox. > > > > I do not have a real opinion on the second one, as I think local variable > > set > > in U-Boot scripts are quite simple as people do not try to do: foo="bar > > \"quux > > 'quuz' \"\"\"corge". > > The first one is maybe more problematic. > > Grepping "if test" shows me that the more complex if condition seems to be > > under the form: > > if first_test_ AND/OR second_test > > Here also, people seems to no try to write complex expression like: foo || > > bar; echo quux && quuz. > > > > So, porting Busybox 2021 hush can solve bugs we have currently in U-Boot, > > but > > what if fixing these bugs lead to a board script failing and so a device not > > booting... > > I would like to have the opinion of the community on this question. > > My feeling is that we should go with the newer (correct?) behaviour. > Boards not booting can be found with the existing release process. > > Also if we keep the old hush around for a while people can still use > it, particularly if it is much smaller. I would at this point echo this sentiment as well. Thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v2 1/3] fs/erofs: add erofs filesystem support
On Mon, Aug 23, 2021 at 08:36:44PM +0800, Huang Jianan wrote: > From: Huang Jianan > > This patch mainly deals with uncompressed files. > > Signed-off-by: Huang Jianan > --- > fs/Kconfig | 1 + > fs/Makefile | 1 + > fs/erofs/Kconfig| 12 ++ > fs/erofs/Makefile | 7 + > fs/erofs/data.c | 124 ++ > fs/erofs/erofs_fs.h | 384 > fs/erofs/fs.c | 231 ++ > fs/erofs/internal.h | 203 +++ > fs/erofs/namei.c| 238 +++ > fs/erofs/super.c| 65 > fs/fs.c | 22 +++ > include/erofs.h | 19 +++ > include/fs.h| 1 + > 13 files changed, 1308 insertions(+) > create mode 100644 fs/erofs/Kconfig > create mode 100644 fs/erofs/Makefile > create mode 100644 fs/erofs/data.c > create mode 100644 fs/erofs/erofs_fs.h > create mode 100644 fs/erofs/fs.c > create mode 100644 fs/erofs/internal.h > create mode 100644 fs/erofs/namei.c > create mode 100644 fs/erofs/super.c > create mode 100644 include/erofs.h Do the style problems checkpatch.pl complains about here match what's in the linux kernel? I expect at lease some of them come from using custom debug/etc macros rather than the standard logging functions. Thanks. -- Tom signature.asc Description: PGP signature
