Re: [EXTERNAL] Re: [PATCH] mtd: nand: pxa3xx: Incorrect bitflip return on page read
On 4/29/24 09:59, Michael Nazzareno Trimarchi wrote:
> --
> On Mon, Apr 29, 2024 at 6:22 PM Chris Packham wrote:
>>
>> On Sun, Apr 28, 2024 at 4:15 AM Ravi Minnikanti
>> wrote:
>>>
>>> Once a page is read with higher bitflips all subsequent reads
>>> are returning the same bitflip value even though they have none.
>>> max_bitflip variable is not being reset to 0 across page reads.
>>>
>>> This is causing problems like incorrectly
>>> marking erase blocks bad by UBI and causing read failures.
>>>
>>> Verified the change with both MTD reads and UBI.
>>> This change is inline with other NFC drivers.
>>>
>>> Sample error log where a block is marked bad incorrectly:
>>>
>>> ubi0: fixable bit-flip detected at PEB 125
>>> ubi0: run torture test for PEB 125
>>> ubi0: fixable bit-flip detected at PEB 125
>>> ubi0 error: torture_peb: read problems on freshly erased PEB 125,
>>> must be bad
>>> ubi0 error: erase_worker: failed to erase PEB 125, error -5
>>> ubi0: mark PEB 125 as bad
>>>
>>> Signed-off-by: rminnikanti
>>
>> Looks good to me
>>
>> Reviewed-by: Chris Packham
>>
>>> ---
>>> drivers/mtd/nand/raw/pxa3xx_nand.c | 5 +
>>> 1 file changed, 5 insertions(+)
>>>
>>> diff --git a/drivers/mtd/nand/raw/pxa3xx_nand.c
>>> b/drivers/mtd/nand/raw/pxa3xx_nand.c
>>> index 1d9a6d107b..d2a4faad56 100644
>>> --- a/drivers/mtd/nand/raw/pxa3xx_nand.c
>>> +++ b/drivers/mtd/nand/raw/pxa3xx_nand.c
>>> @@ -800,6 +800,11 @@ static void prepare_start_command(struct
>>> pxa3xx_nand_info *info, int command)
>>> info->ecc_err_cnt = 0;
>>> info->ndcb3 = 0;
>>> info->need_wait = 0;
>>> + /*
>>> +* Reset max_bitflips to zero. Once command is complete,
>>> +* max_bitflips for this READ is returned in ecc.read_page()
>>> +*/
>>> + info->max_bitflips = 0;
>>>
>
> Why this should not be put to 0 in read_page instead on prepare_start_command?
>
> Michael
>
ecc.read_page is invoked after the read command execution.
First chip->cmdfunc is executed with NAND_CMD_READ0 and then ecc.read_page is
invoked
to read the page from buffer. So, by the time read_page is invoked,
info->max_bitflips
must already have the bit flip value.
Thanks, Ravi.
>>> switch (command) {
>>> case NAND_CMD_READ0:
>>> --
>>> 2.17.1
>
Re: [PATCH] ARM: imx: Enable kaslrseed command on DH i.MX8M Plus DHCOM
On 4/29/24 10:52 PM, Tim Harvey wrote:
On Mon, Apr 29, 2024 at 1:51 PM Marek Vasut wrote:
On 4/29/24 9:10 PM, Tim Harvey wrote:
On Tue, Apr 23, 2024 at 4:18 PM Marek Vasut wrote:
On 4/19/24 5:24 PM, Tim Harvey wrote:
On Thu, Apr 18, 2024 at 11:42 AM Marek Vasut wrote:
On 4/18/24 8:02 PM, Fabio Estevam wrote:
Hi Tim,
On Thu, Apr 18, 2024 at 2:54 PM Tim Harvey wrote:
Fabio, if you enable CONFIG_DM_RNG on an imx8m{m,p}_evk do you get the
following in the SPL?
Couldn't bind rng driver (-96)
SEC0: RNG instantiated
sec_init failed!
Yes, if I add CONFIG_DM_RNG=y to imx8mm_evk_defconfig I get:
U-Boot SPL 2024.04-00793-g3434b88d2c2f-dirty (Apr 18 2024 - 14:58:57 -0300)
No pmic
Couldn't bind rng driver (-96)
SEC0: RNG instantiated
sec_init failed!
Interesting. Which TFA blob version do you use ? I used the mainline
2.10 for my tests.
Marek,
Were you able to reproduce this as well with the board you enabled
DM_RNG for? If it does work fine what dtb were you using... perhaps
there is something in its u-boot.dtsi that we need?
This one arch/arm/dts/imx8mp-dhcom-pdk3.dts , see log below. The build
has a few extra patches in it, but nothing which affects the KASLR:
$ export SOURCE_DATE_EPOCH=1672531200 ; echo tst > .scmversion
$ make imx8mp_dhcom_pdk3_defconfig ; make
U-Boot SPL 2024.07-rc1tst (Jan 01 2023 - 00:00:00 +)
DDR: 4096 MiB [0x5]
DDR: Inline ECC enabled
WDT: Started watchdog@3028 with servicing every 1000ms (60s timeout)
Trying to boot from BOOTROM
Boot Stage: Primary boot
image offset 0x1000, pagesize 0x1, ivt offset 0x0
NOTICE: Do not release JR0 to NS as it can be used by HAB
NOTICE: BL31: v2.10.0 (release):v2.10.0-5-gfb51ca229
NOTICE: BL31: Built : 20:30:36, Apr 23 2024
U-Boot 2024.07-rc1tst (Jan 01 2023 - 00:00:00 +)
CPU: Freescale i.MX8MP[8] rev1.1 1600 MHz (running at 1200 MHz)
CPU: Industrial temperature grade (-40C to 105C) at 70C
Reset cause: POR
Model: DH electronics i.MX8M Plus DHCOM Premium Developer Kit (3)
DRAM: 3.5 GiB
Core: 183 devices, 34 uclasses, devicetree: separate
WDT: Started watchdog@3028 with servicing every 1000ms (60s timeout)
MMC: FSL_SDHC: 0, FSL_SDHC: 1
Loading Environment from SPIFlash... SF: Detected w25q128jw with page
size 256 Bytes, erase size 4 KiB, total 16 MiB
OK
In:serial
Out: serial
Err: serial
SEC0: RNG instantiated
Net: eth1: ethernet@30be, eth0: ethernet@30bf
...
The error -EPFNOSUPPORT is interesting and helps point to the only
place it can be where the comment says the strange errno is to make
this easier to find:
https://elixir.bootlin.com/u-boot/latest/source/drivers/core/uclass.c#L70:
if (!uc_drv) {
debug("Cannot find uclass for id %d: please add the
UCLASS_DRIVER() declaration for this UCLASS_... id\n",
id);
/*
* Use a strange error to make this case easier to find. When
* a uclass is not available it can prevent driver model from
* starting up and this failure is otherwise hard to debug.
*/
return -EPFNOSUPPORT;
}
I'm not very familiar with the dm driver binding - does the
U-BOOT_DRIVER usage in drivers/crypto/fsl/rng.c need to be refactored
to use UCLASS_DRIVER for it to be usable in both SPL and U-Boot?
I don't think you need the CAAM RNG in SPL in the first place, or do you ?
Honestly I don't know why we need DM_RNG in SPL anyway and we could
just add support for disabling it there to avoid unwanted bloat.
I think you can disable it , yes.
Marek,
Would it be advantageous for the kaslr-seed to be added automatically
from image_setup_libfdt?
Yes, can you prepare a patch ? (I wanted to do this, just haven't had
the time)
I notice arch/arm/cpu/armv8/fsl-layerscape/fdt.c:ft_cpu_setup does
this and board/raspberrypi/rpi/rpi.c looks like it copies kaslr-seed
from the control fdt which I assume was added by an earlier layer for
that target.
Right, exactly, this .
I'm not clear if there is a disadvantage to automatically adding this
node if DM_RNG is enabled.
I would say, add it.
Yes, I'll submit something this week.
Thank you, much appreciated.
Re: [PATCH v4] mmc: Poll CD in case cyclic framework is enabled
On 4/30/24 12:36 AM, Jaehoon Chung wrote: -Original Message- From: Marek Vasut Sent: Friday, April 26, 2024 8:41 PM To: Jaehoon Chung ; u-boot@lists.denx.de Cc: 'Peng Fan' ; 'Simon Glass' Subject: Re: [PATCH v4] mmc: Poll CD in case cyclic framework is enabled On 4/26/24 8:27 AM, Jaehoon Chung wrote: Dear Marek, -Original Message- From: Marek Vasut Sent: Wednesday, April 24, 2024 8:18 AM To: u-boot@lists.denx.de; Jaehoon Chung Cc: Peng Fan ; Simon Glass Subject: Re: [PATCH v4] mmc: Poll CD in case cyclic framework is enabled On 3/16/24 9:13 PM, Marek Vasut wrote: In case the cyclic framework is enabled, poll the card detect of already initialized cards and deinitialize them in case they are removed. Since the card initialization is a longer process and card initialization is done on first access to an uninitialized card anyway, avoid initializing newly detected uninitialized cards in the cyclic callback. Any input on this ? When I have applied your patch from patchwork, it didn't apply directly. If you're ok, I will apply after touch your patch. Is it ok? Sure. After touching your patch, I will inform again to you. btw. what is the problem with the patch ?
Re: [PATCH 0/5] Update PHYTEC SOM Detection
On Fri, 19 Apr 2024 08:55:35 -0700, Daniel Schultz wrote: > This patch series extends PHYTEC's SOM detection by minor > fixes, a generic helper function and a new valid flag. > > Moreover, it adds a module to provide access to the SOM > detection for our TI AM6 products. > > Daniel Schultz (3): > board: phytec: common: Generic "add extension" function > board: phytec: common: Fix eepom is empty check > board: phytec: Add SOM detection for AM6x > > [...] Applied to u-boot/master, thanks! -- Tom
Re: [PATCH 0/3] *** Migrate some PHYTEC boards to OF_UPSTREAM ***
On Fri, 19 Apr 2024 08:51:14 +0200, Wadim Egorov wrote: > Migrate the boards I maintain to OF_UPSTREAM. > > Wadim Egorov (3): > phycore-am62x: Migrate to OF_UPSTREAM > phycore-am64x: Migrate to OF_UPSTREAM > phycore-rk3288: Migrate to OF_UPSTREAM > > [...] Applied to u-boot/master, thanks! -- Tom
Re: [PATCH v2 0/5] Fix MMC tuning algorithm
On Thu, 18 Apr 2024 14:00:55 -0500, Judith Mendez wrote: > The following patch series includes a MMC tuning algorithm > fix according to the following published paper [0]. > > This seris also includes fixes for OTAP/ITAP delay values > in j721e_4bit_sdhci_set_ios_post and for HS400 mode. > > For DDR52 mode, also set ENDLL=1 and call am654_sdhci_setup_dll() > instead of am654_sdhci_setup_delay_chain() according to > device datasheet[1]. > > [...] Applied to u-boot/master, thanks! -- Tom
Re: [PATCH v4 0/3] upstream DT compatibility
On Thu, 18 Apr 2024 19:39:55 +0100, Caleb Connolly wrote: > This is a subset of [1]. With more platform maintainers switching to > OF_UPSTREAM I didn't want to get in the way (it has also proven more > difficult than I hoped to remove only the fully compatible header > files). > > This series removes only the dt-bindings headers which contain generic > data like GPIO flags, input event codes, etc. > > [...] Applied to u-boot/master, thanks! -- Tom
Re: [PATCH v4 0/6] Enable ICSSG Ethernet Driver for AM65x
On Tue, 16 Apr 2024 14:50:12 +0530, MD Danish Anwar wrote: > The series introduces device tree and config changes and AM65x > to enable ICSSG driver. The series also enables SPL_LOAD_FIT_APPLY_OVERLAY > for AM65x in order to load overlay over spl. > > The ICSSG2 node is added in device tree overlay so that it remains in > sync with linux kernel. > > [...] Applied to u-boot/master, thanks! -- Tom
Re: [PATCH] arm: mach-k3: am62ax: Fix typo in ROM data macro name
On Fri, 26 Apr 2024 10:44:23 -0500, Andrew Davis wrote: > s/ENTENDED/EXTENDED > > Applied to u-boot/master, thanks! -- Tom
Re: [PATCH] .gitignore: add LTO generated file
On Tue, 23 Apr 2024 13:05:40 +0200, Robert Marko wrote: > Currently, keep-syms-lto.c is being generated if LTO is enabled but unlike > keep-syms-lto.o it is not being ignored, so lets add keep-syms-lto.* to > .gitignore. > > Applied to u-boot/master, thanks! -- Tom
Re: [PATCH 1/1] cmd: CONFIG_CMD_BLOBLIST must depend on CONFIG_BLOBLIST
On Mon, 22 Apr 2024 15:50:10 +0200, Heinrich Schuchardt wrote: > With CONFIG_CMD_BLOBLIST=y, CONFIG_BLOBLIST=n linker errors occur: > > usr/bin/ld: cmd/bloblist.o: in function `do_bloblist_list': > cmd/bloblist.c:27:(.text.do_bloblist_list+0x6): > undefined reference to `bloblist_show_list' > > /usr/bin/ld: cmd/bloblist.o: in function `do_bloblist_info': > cmd/bloblist.c:19:(.text.do_bloblist_info+0x6): > undefined reference to `bloblist_show_stats' > > [...] Applied to u-boot/master, thanks! -- Tom
Re: [PATCH] arm: mach-k3: am642: Fix reset for workaround errata ID i2331
On Thu, 18 Apr 2024 12:58:28 -0500, Andrew Davis wrote: > To workaround an issue in AM642 we reset the SoC in early boot. For that > we first probed the sysreset driver by calling uclass_get_device(). The > ti-sci sysreset driver is now probed during the ti-sci firmware probe. > Update this call to probe the firmware driver which will then probe > the sysreset driver allowing do_reset() to again function as expected. > > > [...] Applied to u-boot/master, thanks! -- Tom
Re: [PATCH 1/1] mailmap: add entry for AKASHI Takahiro
On Thu, 18 Apr 2024 16:11:12 +0200, Heinrich Schuchardt wrote: > Akashi-san's Linaro email address in not valid anymore. > > Applied to u-boot/master, thanks! -- Tom
Re: [PATCH v1] board: toradex: verdin-am62: Remove not needed env variables
On Thu, 18 Apr 2024 15:13:02 +0200, Francesco Dolcini wrote: > Remove not needed variables from environment. > > - boot_scripts is not needed, the default value is just fine and >already includes boot.scr > - setup variable used to be executed from some bootscript, however >it's not required and there is no point on having this small helper >here > > [...] Applied to u-boot/master, thanks! -- Tom
Re: [PATCH] .gitignore: Add files produced by TI platform
On Wed, 17 Apr 2024 18:24:34 +0200, Andrea Calabrese wrote: > Add files produced by compilation of TI platforms: > > *.ti-secure(-rom) > *.map > *-board-config > custMpk.pem > *.bin_* > *.fit > *.itb > tispl.bin_unsigned > > [...] Applied to u-boot/master, thanks! -- Tom
Re: [PATCH v1] arm: dts: verdin-am62: use gpio-hog for sleep moci
On Wed, 17 Apr 2024 10:39:21 +0200, Stefan Eichenberger wrote:
> In Linux, we allow sleep moci to be turned off when the carrier board
> supports it and the system is in suspend. In U-Boot, however, we want
> the sleep moci to be always on. So we use a gpio hog and disable the
> regulator. This change is necessary because we switched to upstream
> device tree files with commit c07bba7a2c7e ("verdin-am62: move verdin
> am62 to OF_UPSTREAM"). A recent upstream patch removes the gpio hog from
> the Linux device tree, so we need to add it to the u-boot dtsi. The
> following patch will remove the gpio hog from the Linux device tree:
> https://lore.kernel.org/linux-devicetree/20240301084901.16656-1-eich...@gmail.com/
> The U-Boot patch can be applied without it and will not break the build.
>
> [...]
Applied to u-boot/master, thanks!
--
Tom
Re: [PATCH] board: ti: j721e: Add support for both esm probe
On Wed, 17 Apr 2024 10:06:50 +0530, Udit Kumar wrote: > At present only MCU domain ESM is probed, this means errors > occurred in mcu domain will be propagate to MCU_SAFETY_ERRORn. > MCU ESM accepts SOC_SAFETY_ERRORn signal as Error > event and propagate to MCU_SAFETY_ERRORn.[0] > > Therefore adding support to probe both main domain and mcu > domain ESM. > > [...] Applied to u-boot/master, thanks! -- Tom
Re: [PATCH v2] configs: am62px_evm_a53_defconfig: Enable MMC UHS config option
On Tue, 16 Apr 2024 11:21:15 -0500, Judith Mendez wrote: > Enable MMC UHS support for to allow to enter the UHS > modes for MMC1. > > Applied to u-boot/master, thanks! -- Tom
Re: [PATCH 1/1] Makefile: don't add -Wno-maybe-uninitialized twice
On Tue, 16 Apr 2024 09:35:24 +0200, Heinrich Schuchardt wrote: > Avoid adding the same flag to KBUILD_CFLAGS twice. > > Applied to u-boot/master, thanks! -- Tom
Re: [PATCH v1] arm: dts: k3-am625-verdin: add tifsstub to tispl.bin
On Mon, 15 Apr 2024 09:54:58 +0200, Francesco Dolcini wrote:
> Adds tifsstub binaries, this is required for deepsleep functionality.
>
> This implements the same change as commit 128f81290b7d ("arm: dts: k3:
> binman: am625: add support for signing TIFSSTUB Images") did for TI AM62
> SK board.
>
>
> [...]
Applied to u-boot/master, thanks!
--
Tom
Re: [PATCH 2/4] board: add support for Milk-V Mars CM
On Sun, Apr 28, 2024 at 9:13 AM Emil Renner Berthing
wrote:
>
> Heinrich Schuchardt wrote:
> > We already support the VisionFive 2 and the Milk-V Mars board by
> > patching the VisionFive 2 device tree. With this patch the same
> > is done for the Milk-V Mars CM.
>
> Hi Heinrich.
>
> Thanks for the patch. As far as I can tell the Milk-V documentation[1] is
> pretty consistent in calling the version without eMMC "Milk-V Mars CM Lite"
> and the version with eMMC just "Milk-V Mars CM". So I'd prefer the model,
> compatible and filenames suggested below.
>
> [1]: https://milkv.io/docs/mars/compute-module/introduction#design-philosophy
>
Are there any actual differences that need representation in the dtb
file for downstream OS different from Milk-V Mars to Milk-V Mars CM
(or CM Lite)?
I did find this vendor repo commit "kernel: dts reconfig sdio0 for
SDCard version"
https://github.com/milkv-mars/mars-buildroot-sdk/commit/042ea06598995db99dd252ee439c42b9c1a9
but it does not seem necessary in mainline Linux, SD Card is working
without changes.
It was necessary for U-Boot and the Mars CM Lite with SD Card to apply
s/GPIO62/GPIO22/ as in the vendor commit "u-boot: configure sdio0 as
mars-cm sdcard version"
https://github.com/milkv-mars/mars-buildroot-sdk/commit/880a249518f72ecf1e2947dfeb2c66e5035fce90
Then also there is some mention about PMIC and renamed i2c reference,
already obsolete. That's all, is there more to it? Possibly a dtb for
Mars is enough to also be used on Mars CM and Mars Lite?
-E
> > Signed-off-by: Heinrich Schuchardt
> > ---
> > board/starfive/visionfive2/spl.c | 27 ++-
> > .../visionfive2/starfive_visionfive2.c| 11 +++-
> > 2 files changed, 36 insertions(+), 2 deletions(-)
> >
> > diff --git a/board/starfive/visionfive2/spl.c
> > b/board/starfive/visionfive2/spl.c
> > index 45848db6d8b..bb0f28d7aad 100644
> > --- a/board/starfive/visionfive2/spl.c
> > +++ b/board/starfive/visionfive2/spl.c
> > @@ -129,6 +129,29 @@ void spl_fdt_fixup_mars(void *fdt)
> > }
> > }
> >
> > +void spl_fdt_fixup_marc(void *fdt)
> > +{
> > + const char *compat;
> > + const char *model;
> > +
> > + spl_fdt_fixup_mars(fdt);
> > +
> > + if (!get_mmc_size_from_eeprom()) {
> > + int offset;
> > +
> > + model = "Milk-V Mars CM SDCard";
>
> "Milk-V Mars CM Lite"
>
> > + compat = "milkv,mars-cm-sdcard\0starfive,jh7110";
>
> "milkv,mars-cm-lite\0starfive,jh7110"
>
> > +
> > + offset = fdt_path_offset(fdt,
> > "/soc/pinctrl/mmc0-pins/mmc0-pins-rest");
> > + fdt_setprop_u32(fdt, offset, "pinmux", 0xff130016);
> > + } else {
> > + model = "Milk-V Mars CM eMMC";
>
> "Milk-V Mars CM"
>
> > + compat = "milkv,mars-cm-emmc\0starfive,jh7110";
>
> "milkv,mars-cm\0starfive,jh7110"
>
> > + }
> > + fdt_setprop(fdt, fdt_path_offset(fdt, "/"), "compatible", compat,
> > sizeof(compat));
> > + fdt_setprop_string(fdt, fdt_path_offset(fdt, "/"), "model", model);
> > +}
> > +
> > void spl_fdt_fixup_version_a(void *fdt)
> > {
> > static const char compat[] =
> > "starfive,visionfive-2-v1.2a\0starfive,jh7110";
> > @@ -236,7 +259,9 @@ void spl_perform_fixups(struct spl_image_info
> > *spl_image)
> > pr_err("Can't read EEPROM\n");
> > return;
> > }
> > - if (!strncmp(product_id, "MARS", 4)) {
> > + if (!strncmp(product_id, "MARC", 4)) {
> > + spl_fdt_fixup_marc(spl_image->fdt_addr);
> > + } else if (!strncmp(product_id, "MARS", 4)) {
> > spl_fdt_fixup_mars(spl_image->fdt_addr);
> > } else if (!strncmp(product_id, "VF7110", 6)) {
> > version = get_pcb_revision_from_eeprom();
> > diff --git a/board/starfive/visionfive2/starfive_visionfive2.c
> > b/board/starfive/visionfive2/starfive_visionfive2.c
> > index a86bca533b2..be6ca85b030 100644
> > --- a/board/starfive/visionfive2/starfive_visionfive2.c
> > +++ b/board/starfive/visionfive2/starfive_visionfive2.c
> > @@ -17,6 +17,10 @@
> > DECLARE_GLOBAL_DATA_PTR;
> > #define JH7110_L2_PREFETCHER_BASE_ADDR 0x203
> > #define JH7110_L2_PREFETCHER_HART_OFFSET 0x2000
> > +#define FDTFILE_MILK_V_MARC_SD \
> > + "starfive/jh7110-milkv-mars-cm-sdcard.dtb"
>
> "starfive/jh7110-milkv-mars-cm-lite.dtb"
>
> > +#define FDTFILE_MILK_V_MARC_MMC \
> > + "starfive/jh7110-milkv-mars-cm-emmc.dtb"
>
> "starfive/jh7110-milkv-mars-cm.dtb"
>
> > #define FDTFILE_MILK_V_MARS \
> > "starfive/jh7110-milkv-mars.dtb"
> > #define FDTFILE_VISIONFIVE2_1_2A \
> > @@ -61,7 +65,12 @@ static void set_fdtfile(void)
> > log_err("Can't read EEPROM\n");
> > return;
> > }
> > - if (!strncmp(product_id, "MARS", 4)) {
> > + if (!strncmp(product_id, "MARC", 4)) {
> > + if (get_mmc_size_from_eeprom())
> > + fdtfile = FDTFILE_MILK_V_MARC_MMC;
> > +
RE: [PATCH v4] mmc: Poll CD in case cyclic framework is enabled
> -Original Message- > From: Marek Vasut > Sent: Friday, April 26, 2024 8:41 PM > To: Jaehoon Chung ; u-boot@lists.denx.de > Cc: 'Peng Fan' ; 'Simon Glass' > Subject: Re: [PATCH v4] mmc: Poll CD in case cyclic framework is enabled > > On 4/26/24 8:27 AM, Jaehoon Chung wrote: > > Dear Marek, > > > >> -Original Message- > >> From: Marek Vasut > >> Sent: Wednesday, April 24, 2024 8:18 AM > >> To: u-boot@lists.denx.de; Jaehoon Chung > >> Cc: Peng Fan ; Simon Glass > >> Subject: Re: [PATCH v4] mmc: Poll CD in case cyclic framework is enabled > >> > >> On 3/16/24 9:13 PM, Marek Vasut wrote: > >>> In case the cyclic framework is enabled, poll the card detect of already > >>> initialized cards and deinitialize them in case they are removed. Since > >>> the card initialization is a longer process and card initialization is > >>> done on first access to an uninitialized card anyway, avoid initializing > >>> newly detected uninitialized cards in the cyclic callback. > >> > >> Any input on this ? > > > > When I have applied your patch from patchwork, it didn't apply directly. > > If you're ok, I will apply after touch your patch. Is it ok? > > Sure. After touching your patch, I will inform again to you. Best Regards, Jaehoon Chung
RE: [GIT PULL] Please pull u-boot-mmc master
Dear Judith, > -Original Message- > From: Judith Mendez > Sent: Tuesday, April 30, 2024 5:40 AM > To: Tom Rini ; Jaehoon Chung > Cc: U-Boot Mailing List ; > maximilian.br...@9elements.com; > curtis.mach...@intel.com; Jonas Karlman ; > greg.mal...@timesys.com; > ian.robe...@timesys.com; Jae hoon Chung ; Peng Fan > ; > sheng@9elements.com > Subject: Re: [GIT PULL] Please pull u-boot-mmc master > > Hi all, > > On 4/26/24 10:51 AM, Tom Rini wrote: > > On Fri, Apr 26, 2024 at 07:38:30PM +0900, Jaehoon Chung wrote: > > > >> Dear Tom, > >> > >> Please pull u-boot-mmc master into u-boot master branch. > >> If there is any problem, let me know, plz > >> > >> Best Regards, > >> Jaehoon Chung > >> > >> CI: > >> https://protect2.fireeye.com/v1/url?k=aa60f1d5-cbebe4f5-aa617a9a-74fe485fb347- > 9095c5a77eabfca7=1=d67a142c-0b69-4de3-be99-de9292c603f2=https%3A%2F%2Fsource.denx.de%2Fu- > boot%2Fcustodians%2Fu-boot-mmc%2F-%2Fpipelines%2F20547 > >> > >> The following changes since commit > >> d097f9e1299a3bdb7de468f0d9bbc63932f461cd: > >> > >>Merge tag 'fsl-qoriq-2024-4-24' of > >> https://protect2.fireeye.com/v1/url?k=93e2c287-f269d7a7- > 93e349c8-74fe485fb347-247fe01368500b3b=1=d67a142c-0b69-4de3-be99- > de9292c603f2=https%3A%2F%2Fsource.denx.de%2Fu-boot%2Fcustodians%2Fu-boot-fsl-qoriq > (2024-04-23 > 17:53:06 -0600) > >> > >> are available in the Git repository at: > >> > >>g...@source.denx.de:u-boot/custodians/u-boot-mmc.git master > >> > >> for you to fetch changes up to 1776213dadef4b578f98bcf18beb152f8975a8bf: > >> > >>mmc: arm_pl180: Limit data transfer to U16_MAX (2024-04-26 15:32:06 > >> +0900) > >> > > > > Applied to u-boot/master, thanks! > > > > > A patch in this series caused a regression for AM62x SK with the > following error: > > Error reading cluster > spl_load_image_fat: error reading image u-boot.img, err - -22 > SPL: failed to boot from all boot devices (err=-6) > ### ERROR ### Please RESET the board ### > > Git bisect showed "mmc: sdhci: introduce adma_write_desc() hook to > struct sdhci_ops" to be the offending commit. > > Could someone point me to the next steps to fix this issue? I will check this problem. Thanks for pointing out. Best Regards, Jaehoon Chung > > regards, > Judith
[PATCH] configs: am62x_evm_r5: Increase size of malloc_simple heap after relocation
On AM62x SK we can see a boot failure with signature "alloc space
exhausted", so fix by increasing size of SPL_STACK_R_MALLOC_SIMPLE_LEN.
Fixes: 128f81290b ("arm: dts: k3: binman: am625: add support for signing
TIFSSTUB Images")
Signed-off-by: Judith Mendez
---
configs/am62x_evm_r5_defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/configs/am62x_evm_r5_defconfig b/configs/am62x_evm_r5_defconfig
index 4b2e57b13a0..648241488ed 100644
--- a/configs/am62x_evm_r5_defconfig
+++ b/configs/am62x_evm_r5_defconfig
@@ -26,6 +26,7 @@ CONFIG_SPL_HAS_BSS_LINKER_SECTION=y
CONFIG_SPL_BSS_START_ADDR=0x43c3b000
CONFIG_SPL_BSS_MAX_SIZE=0x3000
CONFIG_SPL_STACK_R=y
+CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN=0x20
CONFIG_SPL_SIZE_LIMIT=0x3A7F0
CONFIG_SPL_SIZE_LIMIT_PROVIDE_STACK=0x3500
CONFIG_SPL_FS_FAT=y
base-commit: 174ac987655c888017c82df1883c0c2ea0dc2495
--
2.43.2
Re: [PATCH] ARM: imx: Enable kaslrseed command on DH i.MX8M Plus DHCOM
On Mon, Apr 29, 2024 at 1:51 PM Marek Vasut wrote:
>
> On 4/29/24 9:10 PM, Tim Harvey wrote:
> > On Tue, Apr 23, 2024 at 4:18 PM Marek Vasut wrote:
> >>
> >> On 4/19/24 5:24 PM, Tim Harvey wrote:
> >>> On Thu, Apr 18, 2024 at 11:42 AM Marek Vasut wrote:
>
> On 4/18/24 8:02 PM, Fabio Estevam wrote:
> > Hi Tim,
> >
> > On Thu, Apr 18, 2024 at 2:54 PM Tim Harvey
> > wrote:
> >
> >> Fabio, if you enable CONFIG_DM_RNG on an imx8m{m,p}_evk do you get the
> >> following in the SPL?
> >> Couldn't bind rng driver (-96)
> >> SEC0: RNG instantiated
> >>
> >> sec_init failed!
> >
> > Yes, if I add CONFIG_DM_RNG=y to imx8mm_evk_defconfig I get:
> >
> > U-Boot SPL 2024.04-00793-g3434b88d2c2f-dirty (Apr 18 2024 - 14:58:57
> > -0300)
> > No pmic
> > Couldn't bind rng driver (-96)
> > SEC0: RNG instantiated
> >
> > sec_init failed!
>
> Interesting. Which TFA blob version do you use ? I used the mainline
> 2.10 for my tests.
> >>>
> >>> Marek,
> >>>
> >>> Were you able to reproduce this as well with the board you enabled
> >>> DM_RNG for? If it does work fine what dtb were you using... perhaps
> >>> there is something in its u-boot.dtsi that we need?
> >>
> >> This one arch/arm/dts/imx8mp-dhcom-pdk3.dts , see log below. The build
> >> has a few extra patches in it, but nothing which affects the KASLR:
> >>
> >> $ export SOURCE_DATE_EPOCH=1672531200 ; echo tst > .scmversion
> >> $ make imx8mp_dhcom_pdk3_defconfig ; make
> >>
> >> U-Boot SPL 2024.07-rc1tst (Jan 01 2023 - 00:00:00 +)
> >> DDR: 4096 MiB [0x5]
> >> DDR: Inline ECC enabled
> >> WDT: Started watchdog@3028 with servicing every 1000ms (60s timeout)
> >> Trying to boot from BOOTROM
> >> Boot Stage: Primary boot
> >> image offset 0x1000, pagesize 0x1, ivt offset 0x0
> >> NOTICE: Do not release JR0 to NS as it can be used by HAB
> >> NOTICE: BL31: v2.10.0 (release):v2.10.0-5-gfb51ca229
> >> NOTICE: BL31: Built : 20:30:36, Apr 23 2024
> >>
> >>
> >> U-Boot 2024.07-rc1tst (Jan 01 2023 - 00:00:00 +)
> >>
> >> CPU: Freescale i.MX8MP[8] rev1.1 1600 MHz (running at 1200 MHz)
> >> CPU: Industrial temperature grade (-40C to 105C) at 70C
> >> Reset cause: POR
> >> Model: DH electronics i.MX8M Plus DHCOM Premium Developer Kit (3)
> >> DRAM: 3.5 GiB
> >> Core: 183 devices, 34 uclasses, devicetree: separate
> >> WDT: Started watchdog@3028 with servicing every 1000ms (60s timeout)
> >> MMC: FSL_SDHC: 0, FSL_SDHC: 1
> >> Loading Environment from SPIFlash... SF: Detected w25q128jw with page
> >> size 256 Bytes, erase size 4 KiB, total 16 MiB
> >> OK
> >> In:serial
> >> Out: serial
> >> Err: serial
> >> SEC0: RNG instantiated
> >> Net: eth1: ethernet@30be, eth0: ethernet@30bf
> >> ...
> >>
> >>> The error -EPFNOSUPPORT is interesting and helps point to the only
> >>> place it can be where the comment says the strange errno is to make
> >>> this easier to find:
> >>> https://elixir.bootlin.com/u-boot/latest/source/drivers/core/uclass.c#L70:
> >>> if (!uc_drv) {
> >>> debug("Cannot find uclass for id %d: please add the
> >>> UCLASS_DRIVER() declaration for this UCLASS_... id\n",
> >>> id);
> >>> /*
> >>>* Use a strange error to make this case easier to
> >>> find. When
> >>>* a uclass is not available it can prevent driver
> >>> model from
> >>>* starting up and this failure is otherwise hard to
> >>> debug.
> >>>*/
> >>> return -EPFNOSUPPORT;
> >>> }
> >>>
> >>> I'm not very familiar with the dm driver binding - does the
> >>> U-BOOT_DRIVER usage in drivers/crypto/fsl/rng.c need to be refactored
> >>> to use UCLASS_DRIVER for it to be usable in both SPL and U-Boot?
> >>
> >> I don't think you need the CAAM RNG in SPL in the first place, or do you ?
> >>
> >>> Honestly I don't know why we need DM_RNG in SPL anyway and we could
> >>> just add support for disabling it there to avoid unwanted bloat.
> >>
> >> I think you can disable it , yes.
> >
> > Marek,
> >
> > Would it be advantageous for the kaslr-seed to be added automatically
> > from image_setup_libfdt?
>
> Yes, can you prepare a patch ? (I wanted to do this, just haven't had
> the time)
>
> > I notice arch/arm/cpu/armv8/fsl-layerscape/fdt.c:ft_cpu_setup does
> > this and board/raspberrypi/rpi/rpi.c looks like it copies kaslr-seed
> > from the control fdt which I assume was added by an earlier layer for
> > that target.
>
> Right, exactly, this .
>
> > I'm not clear if there is a disadvantage to automatically adding this
> > node if DM_RNG is enabled.
>
> I would say, add it.
Yes, I'll submit something this week.
Best Regards,
Tim
Re: [PATCH v3] mmc: allow use of hardware partition names for mmc partconf
On 4/29/24 6:48 PM, Tim Harvey wrote:
On Sat, Apr 27, 2024 at 4:20 PM Marek Vasut wrote:
On 4/27/24 2:11 AM, Tim Harvey wrote:
[...]
diff --git a/include/mmc.h b/include/mmc.h
index 4b8327f1f93b..7243bd761202 100644
--- a/include/mmc.h
+++ b/include/mmc.h
@@ -381,6 +381,21 @@ enum mmc_voltage {
#define MMC_TIMING_MMC_HS2009
#define MMC_TIMING_MMC_HS40010
+/* emmc hardware partition values */
+enum emmc_hwpart {
+ EMMC_HWPART_DEFAULT = 0,
One more thing ... eMMC hardware partition 0 and 7 are both referring to
USER HW partition. Have a look at the git log, there have been patches
which handled this case in the MMC subsystem from about a year ago.
Hi Marek,
I can't find what you are referring to. I assume you are talking about
calling the first name something other than 'user' as technically it's
not (but it gets treated as user).
Can you find the commit or discussion you are thinking about?
It seems this whole thing is much older:
7dbe63bc950b ("SPL: Add CONFIG_SUPPORT_EMMC_BOOT support to
CONFIG_SPL_FRAMEWORK")
+* We need to check what the partition is configured to.
+* 1 and 2 match up to boot0 / boot1 and 7 is user data
+* which is the first physical partition (0).
+*/
+ int part = (mmc->part_config >> 3) & PART_ACCESS_MASK;
+
+ if (part == 7)
+ part = 0;
Re: [PATCH] ARM: imx: Enable kaslrseed command on DH i.MX8M Plus DHCOM
On 4/29/24 9:10 PM, Tim Harvey wrote:
On Tue, Apr 23, 2024 at 4:18 PM Marek Vasut wrote:
On 4/19/24 5:24 PM, Tim Harvey wrote:
On Thu, Apr 18, 2024 at 11:42 AM Marek Vasut wrote:
On 4/18/24 8:02 PM, Fabio Estevam wrote:
Hi Tim,
On Thu, Apr 18, 2024 at 2:54 PM Tim Harvey wrote:
Fabio, if you enable CONFIG_DM_RNG on an imx8m{m,p}_evk do you get the
following in the SPL?
Couldn't bind rng driver (-96)
SEC0: RNG instantiated
sec_init failed!
Yes, if I add CONFIG_DM_RNG=y to imx8mm_evk_defconfig I get:
U-Boot SPL 2024.04-00793-g3434b88d2c2f-dirty (Apr 18 2024 - 14:58:57 -0300)
No pmic
Couldn't bind rng driver (-96)
SEC0: RNG instantiated
sec_init failed!
Interesting. Which TFA blob version do you use ? I used the mainline
2.10 for my tests.
Marek,
Were you able to reproduce this as well with the board you enabled
DM_RNG for? If it does work fine what dtb were you using... perhaps
there is something in its u-boot.dtsi that we need?
This one arch/arm/dts/imx8mp-dhcom-pdk3.dts , see log below. The build
has a few extra patches in it, but nothing which affects the KASLR:
$ export SOURCE_DATE_EPOCH=1672531200 ; echo tst > .scmversion
$ make imx8mp_dhcom_pdk3_defconfig ; make
U-Boot SPL 2024.07-rc1tst (Jan 01 2023 - 00:00:00 +)
DDR: 4096 MiB [0x5]
DDR: Inline ECC enabled
WDT: Started watchdog@3028 with servicing every 1000ms (60s timeout)
Trying to boot from BOOTROM
Boot Stage: Primary boot
image offset 0x1000, pagesize 0x1, ivt offset 0x0
NOTICE: Do not release JR0 to NS as it can be used by HAB
NOTICE: BL31: v2.10.0 (release):v2.10.0-5-gfb51ca229
NOTICE: BL31: Built : 20:30:36, Apr 23 2024
U-Boot 2024.07-rc1tst (Jan 01 2023 - 00:00:00 +)
CPU: Freescale i.MX8MP[8] rev1.1 1600 MHz (running at 1200 MHz)
CPU: Industrial temperature grade (-40C to 105C) at 70C
Reset cause: POR
Model: DH electronics i.MX8M Plus DHCOM Premium Developer Kit (3)
DRAM: 3.5 GiB
Core: 183 devices, 34 uclasses, devicetree: separate
WDT: Started watchdog@3028 with servicing every 1000ms (60s timeout)
MMC: FSL_SDHC: 0, FSL_SDHC: 1
Loading Environment from SPIFlash... SF: Detected w25q128jw with page
size 256 Bytes, erase size 4 KiB, total 16 MiB
OK
In:serial
Out: serial
Err: serial
SEC0: RNG instantiated
Net: eth1: ethernet@30be, eth0: ethernet@30bf
...
The error -EPFNOSUPPORT is interesting and helps point to the only
place it can be where the comment says the strange errno is to make
this easier to find:
https://elixir.bootlin.com/u-boot/latest/source/drivers/core/uclass.c#L70:
if (!uc_drv) {
debug("Cannot find uclass for id %d: please add the
UCLASS_DRIVER() declaration for this UCLASS_... id\n",
id);
/*
* Use a strange error to make this case easier to find. When
* a uclass is not available it can prevent driver model from
* starting up and this failure is otherwise hard to debug.
*/
return -EPFNOSUPPORT;
}
I'm not very familiar with the dm driver binding - does the
U-BOOT_DRIVER usage in drivers/crypto/fsl/rng.c need to be refactored
to use UCLASS_DRIVER for it to be usable in both SPL and U-Boot?
I don't think you need the CAAM RNG in SPL in the first place, or do you ?
Honestly I don't know why we need DM_RNG in SPL anyway and we could
just add support for disabling it there to avoid unwanted bloat.
I think you can disable it , yes.
Marek,
Would it be advantageous for the kaslr-seed to be added automatically
from image_setup_libfdt?
Yes, can you prepare a patch ? (I wanted to do this, just haven't had
the time)
I notice arch/arm/cpu/armv8/fsl-layerscape/fdt.c:ft_cpu_setup does
this and board/raspberrypi/rpi/rpi.c looks like it copies kaslr-seed
from the control fdt which I assume was added by an earlier layer for
that target.
Right, exactly, this .
I'm not clear if there is a disadvantage to automatically adding this
node if DM_RNG is enabled.
I would say, add it.
Re: [GIT PULL] Please pull u-boot-mmc master
Hi all, On 4/26/24 10:51 AM, Tom Rini wrote: On Fri, Apr 26, 2024 at 07:38:30PM +0900, Jaehoon Chung wrote: Dear Tom, Please pull u-boot-mmc master into u-boot master branch. If there is any problem, let me know, plz Best Regards, Jaehoon Chung CI: https://source.denx.de/u-boot/custodians/u-boot-mmc/-/pipelines/20547 The following changes since commit d097f9e1299a3bdb7de468f0d9bbc63932f461cd: Merge tag 'fsl-qoriq-2024-4-24' of https://source.denx.de/u-boot/custodians/u-boot-fsl-qoriq (2024-04-23 17:53:06 -0600) are available in the Git repository at: g...@source.denx.de:u-boot/custodians/u-boot-mmc.git master for you to fetch changes up to 1776213dadef4b578f98bcf18beb152f8975a8bf: mmc: arm_pl180: Limit data transfer to U16_MAX (2024-04-26 15:32:06 +0900) Applied to u-boot/master, thanks! A patch in this series caused a regression for AM62x SK with the following error: Error reading cluster spl_load_image_fat: error reading image u-boot.img, err - -22 SPL: failed to boot from all boot devices (err=-6) ### ERROR ### Please RESET the board ### Git bisect showed "mmc: sdhci: introduce adma_write_desc() hook to struct sdhci_ops" to be the offending commit. Could someone point me to the next steps to fix this issue? regards, Judith
Re: [PATCH] ARM: imx: Enable kaslrseed command on DH i.MX8M Plus DHCOM
On Tue, Apr 23, 2024 at 4:18 PM Marek Vasut wrote:
>
> On 4/19/24 5:24 PM, Tim Harvey wrote:
> > On Thu, Apr 18, 2024 at 11:42 AM Marek Vasut wrote:
> >>
> >> On 4/18/24 8:02 PM, Fabio Estevam wrote:
> >>> Hi Tim,
> >>>
> >>> On Thu, Apr 18, 2024 at 2:54 PM Tim Harvey wrote:
> >>>
> Fabio, if you enable CONFIG_DM_RNG on an imx8m{m,p}_evk do you get the
> following in the SPL?
> Couldn't bind rng driver (-96)
> SEC0: RNG instantiated
>
> sec_init failed!
> >>>
> >>> Yes, if I add CONFIG_DM_RNG=y to imx8mm_evk_defconfig I get:
> >>>
> >>> U-Boot SPL 2024.04-00793-g3434b88d2c2f-dirty (Apr 18 2024 - 14:58:57
> >>> -0300)
> >>> No pmic
> >>> Couldn't bind rng driver (-96)
> >>> SEC0: RNG instantiated
> >>>
> >>> sec_init failed!
> >>
> >> Interesting. Which TFA blob version do you use ? I used the mainline
> >> 2.10 for my tests.
> >
> > Marek,
> >
> > Were you able to reproduce this as well with the board you enabled
> > DM_RNG for? If it does work fine what dtb were you using... perhaps
> > there is something in its u-boot.dtsi that we need?
>
> This one arch/arm/dts/imx8mp-dhcom-pdk3.dts , see log below. The build
> has a few extra patches in it, but nothing which affects the KASLR:
>
> $ export SOURCE_DATE_EPOCH=1672531200 ; echo tst > .scmversion
> $ make imx8mp_dhcom_pdk3_defconfig ; make
>
> U-Boot SPL 2024.07-rc1tst (Jan 01 2023 - 00:00:00 +)
> DDR: 4096 MiB [0x5]
> DDR: Inline ECC enabled
> WDT: Started watchdog@3028 with servicing every 1000ms (60s timeout)
> Trying to boot from BOOTROM
> Boot Stage: Primary boot
> image offset 0x1000, pagesize 0x1, ivt offset 0x0
> NOTICE: Do not release JR0 to NS as it can be used by HAB
> NOTICE: BL31: v2.10.0 (release):v2.10.0-5-gfb51ca229
> NOTICE: BL31: Built : 20:30:36, Apr 23 2024
>
>
> U-Boot 2024.07-rc1tst (Jan 01 2023 - 00:00:00 +)
>
> CPU: Freescale i.MX8MP[8] rev1.1 1600 MHz (running at 1200 MHz)
> CPU: Industrial temperature grade (-40C to 105C) at 70C
> Reset cause: POR
> Model: DH electronics i.MX8M Plus DHCOM Premium Developer Kit (3)
> DRAM: 3.5 GiB
> Core: 183 devices, 34 uclasses, devicetree: separate
> WDT: Started watchdog@3028 with servicing every 1000ms (60s timeout)
> MMC: FSL_SDHC: 0, FSL_SDHC: 1
> Loading Environment from SPIFlash... SF: Detected w25q128jw with page
> size 256 Bytes, erase size 4 KiB, total 16 MiB
> OK
> In:serial
> Out: serial
> Err: serial
> SEC0: RNG instantiated
> Net: eth1: ethernet@30be, eth0: ethernet@30bf
> ...
>
> > The error -EPFNOSUPPORT is interesting and helps point to the only
> > place it can be where the comment says the strange errno is to make
> > this easier to find:
> > https://elixir.bootlin.com/u-boot/latest/source/drivers/core/uclass.c#L70:
> > if (!uc_drv) {
> > debug("Cannot find uclass for id %d: please add the
> > UCLASS_DRIVER() declaration for this UCLASS_... id\n",
> >id);
> > /*
> > * Use a strange error to make this case easier to find.
> > When
> > * a uclass is not available it can prevent driver model
> > from
> > * starting up and this failure is otherwise hard to debug.
> > */
> > return -EPFNOSUPPORT;
> > }
> >
> > I'm not very familiar with the dm driver binding - does the
> > U-BOOT_DRIVER usage in drivers/crypto/fsl/rng.c need to be refactored
> > to use UCLASS_DRIVER for it to be usable in both SPL and U-Boot?
>
> I don't think you need the CAAM RNG in SPL in the first place, or do you ?
>
> > Honestly I don't know why we need DM_RNG in SPL anyway and we could
> > just add support for disabling it there to avoid unwanted bloat.
>
> I think you can disable it , yes.
Marek,
Would it be advantageous for the kaslr-seed to be added automatically
from image_setup_libfdt?
I notice arch/arm/cpu/armv8/fsl-layerscape/fdt.c:ft_cpu_setup does
this and board/raspberrypi/rpi/rpi.c looks like it copies kaslr-seed
from the control fdt which I assume was added by an earlier layer for
that target.
I'm not clear if there is a disadvantage to automatically adding this
node if DM_RNG is enabled.
Best Regards,
Tim
[PATCH] Fix neighbor discovery ethernet address saving
From: Sean Edmond When a successful neighbor advertisement is received, the ethernet address should be saved for later use to avoid having to redo the neighbor discovery process. For example, with TFTP the address should get saved into "net_server_ethaddr". This is being done correctly with ARP for IPv4, but not for neighbor discovery with IPv6. Signed-off-by: Sean Edmond --- net/ndisc.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/net/ndisc.c b/net/ndisc.c index d1cec0601c8..505515f2d95 100644 --- a/net/ndisc.c +++ b/net/ndisc.c @@ -461,8 +461,8 @@ int ndisc_receive(struct ethernet_hdr *et, struct ip6_hdr *ip6, int len) ndisc_extract_enetaddr(ndisc, neigh_eth_addr); /* save address for later use */ - if (!net_nd_packet_mac) - net_nd_packet_mac = neigh_eth_addr; + if (net_nd_packet_mac) + memcpy(net_nd_packet_mac, neigh_eth_addr, 6); /* modify header, and transmit it */ memcpy(((struct ethernet_hdr *)net_nd_tx_packet)->et_dest, -- 2.42.0
[PATCH v6 3/3] net: bootp: add config option BOOTP_RANDOM_XID
The new config option BOOTP_RANDOM_XID will randomize the transaction ID
for each new BOOT/DHCPv4 exchange.
Signed-off-by: Sean Edmond
Reviewed-by: Tom Rini
---
(no changes since v5)
Changes in v5:
- fix depends for BOOTP_RANDOM_XID:
"depends on CMD_BOOTP && (LIB_RAND || LIB_HW_RAND)"
Changes in v3:
- Add depends for BOOTP_RANDOM_XID
cmd/Kconfig | 7 +++
net/bootp.c | 31 +--
2 files changed, 24 insertions(+), 14 deletions(-)
diff --git a/cmd/Kconfig b/cmd/Kconfig
index 54c4ab8570c..82f6a089586 100644
--- a/cmd/Kconfig
+++ b/cmd/Kconfig
@@ -1909,6 +1909,13 @@ config BOOTP_VCI_STRING
default "U-Boot.arm" if ARM
default "U-Boot"
+config BOOTP_RANDOM_XID
+ bool "Send random transaction ID to BOOTP/DHCP server"
+ depends on CMD_BOOTP && (LIB_RAND || LIB_HW_RAND)
+ help
+ Selecting this will allow for a random transaction ID to get
+ selected for each BOOTP/DHCPv4 exchange.
+
if CMD_DHCP6
config DHCP6_PXE_CLIENTARCH
diff --git a/net/bootp.c b/net/bootp.c
index 0109446dd6f..e336282cb8f 100644
--- a/net/bootp.c
+++ b/net/bootp.c
@@ -837,22 +837,25 @@ void bootp_request(void)
/* Only generate a new transaction ID for each new BOOTP request */
if (bootp_try == 1) {
- /*
-* Bootp ID is the lower 4 bytes of our ethernet address
-* plus the current time in ms.
-*/
- bootp_id = ((u32)net_ethaddr[2] << 24)
- | ((u32)net_ethaddr[3] << 16)
- | ((u32)net_ethaddr[4] << 8)
- | (u32)net_ethaddr[5];
- bootp_id += get_timer(0);
- bootp_id = htonl(bootp_id);
- bootp_add_id(bootp_id);
- net_copy_u32(>bp_id, _id);
- } else {
- net_copy_u32(>bp_id, _id);
+ if (IS_ENABLED(CONFIG_BOOTP_RANDOM_XID)) {
+ srand(get_ticks() + rand());
+ bootp_id = rand();
+ } else {
+ /*
+* Bootp ID is the lower 4 bytes of our ethernet
address
+* plus the current time in ms.
+*/
+ bootp_id = ((u32)net_ethaddr[2] << 24)
+ | ((u32)net_ethaddr[3] << 16)
+ | ((u32)net_ethaddr[4] << 8)
+ | (u32)net_ethaddr[5];
+ bootp_id += get_timer(0);
+ bootp_id = htonl(bootp_id);
+ }
}
+ bootp_add_id(bootp_id);
+ net_copy_u32(>bp_id, _id);
/*
* Calculate proper packet lengths taking into account the
* variable size of the options field
--
2.42.0
[PATCH v6 2/3] net: bootp: BOOTP/DHCPv4 retransmission improvements
This patch introduces 3 improvements to align with RFC 951:
- retransmission backoff interval maximum is configurable
- initial retranmission backoff interval is configurable
- transaction ID is kept the same for each BOOTP/DHCPv4 request
In applications where thousands of nodes are serviced by a single DHCP
server, maximizing the retransmission backoff interval at 2 seconds (the
current u-boot default) exerts high pressure on the DHCP server and
network layer.
RFC 951 “7.2. Client Retransmission Strategy” states that the
retransmission backoff interval should be limited to 60 seconds. This
patch allows the interval to be configurable using the environment
variable "bootpretransmitperiodmax"
The initial retranmission backoff period defaults to 250ms, which is
also too small for these scenarios with many clients. This patch makes
the initial retransmission interval to be configurable using the
environment variable "bootpretransmitperiodinit".
Also, on a retransmission it is not expected for the transaction ID to
change (only the 'secs' field should be updated). Let's save the
transaction ID and use the same transaction ID for each BOOTP/DHCPv4
exchange.
Signed-off-by: Sean Edmond
---
Changes in v7:
- Remove "depends on LIB_RAND || LIB_HW_RAND" from CMD_BOOTP
- Add CMD_BOOTP/CMD_DHCP/CMD_DHCP6 to LIB_RAND menu choice
- Add space after "config CMD_DHCP"
Changes in v6:
- CMD_BOOTP should "depends on LIB_RAND || LIB_HW_RAND"
Changes in v4:
- Add "select LIB_RAND" for "config CMD_BOOTP" (retransmission
improvements require rand())
Changes in v3:
- Set RETRANSMIT_PERIOD_MAX_MS=6
- Add randomization factor to retransmission timeout
Changes in v2:
- use env_get_ulong() to get environment variables
lib/Kconfig | 3 ++-
net/bootp.c | 71 +
2 files changed, 57 insertions(+), 17 deletions(-)
diff --git a/lib/Kconfig b/lib/Kconfig
index 189e6eb31aa..9b62b3bbea7 100644
--- a/lib/Kconfig
+++ b/lib/Kconfig
@@ -265,7 +265,8 @@ config REGEX
choice
prompt "Pseudo-random library support type"
depends on NET_RANDOM_ETHADDR || RANDOM_UUID || CMD_UUID || \
- RNG_SANDBOX || UT_LIB && AES || FAT_WRITE
+ RNG_SANDBOX || UT_LIB && AES || FAT_WRITE || CMD_BOOTP || \
+ CMD_DHCP || CMD_DHCP6
default LIB_RAND
help
Select the library to provide pseudo-random number generator
diff --git a/net/bootp.c b/net/bootp.c
index b9e3cccb4f9..0109446dd6f 100644
--- a/net/bootp.c
+++ b/net/bootp.c
@@ -42,6 +42,22 @@
*/
#define TIMEOUT_MS ((3 + (CONFIG_NET_RETRY_COUNT * 5)) * 1000)
+/*
+ * According to rfc951 : 7.2. Client Retransmission Strategy
+ * "After the 'average' backoff reaches about 60 seconds, it should be
+ * increased no further, but still randomized."
+ *
+ * U-Boot has saturated this backoff at 2 seconds for a long time.
+ * To modify, set the environment variable "bootpretransmitperiodmax"
+ */
+#define RETRANSMIT_PERIOD_MAX_MS 6
+
+/* Retransmission timeout for the initial packet (in milliseconds).
+ * This timeout will double on each retry. To modify, set the
+ * environment variable bootpretransmitperiodinit.
+ */
+#define RETRANSMIT_PERIOD_INIT_MS 250
+
#ifndef CFG_DHCP_MIN_EXT_LEN /* minimal length of extension list */
#define CFG_DHCP_MIN_EXT_LEN 64
#endif
@@ -53,6 +69,7 @@
u32bootp_ids[CFG_BOOTP_ID_CACHE_SIZE];
unsigned int bootp_num_ids;
intbootp_try;
+u32bootp_id;
ulong bootp_start;
ulong bootp_timeout;
char net_nis_domain[32] = {0,}; /* Our NIS domain */
@@ -60,6 +77,7 @@ char net_hostname[32] = {0,}; /* Our hostname */
char net_root_path[CONFIG_BOOTP_MAX_ROOT_PATH_LEN] = {0,}; /* Our bootpath */
static ulong time_taken_max;
+static u32 retransmit_period_max_ms;
#if defined(CONFIG_CMD_DHCP)
static dhcp_state_t dhcp_state = INIT;
@@ -396,6 +414,7 @@ static void bootp_handler(uchar *pkt, unsigned dest, struct
in_addr sip,
static void bootp_timeout_handler(void)
{
ulong time_taken = get_timer(bootp_start);
+ int rand_minus_plus_100;
if (time_taken >= time_taken_max) {
#ifdef CONFIG_BOOTP_MAY_FAIL
@@ -414,8 +433,17 @@ static void bootp_timeout_handler(void)
}
} else {
bootp_timeout *= 2;
- if (bootp_timeout > 2000)
- bootp_timeout = 2000;
+ if (bootp_timeout > retransmit_period_max_ms)
+ bootp_timeout = retransmit_period_max_ms;
+
+ /* Randomize by adding bootp_timeout*RAND, where RAND
+* is a randomization factor between -0.1..+0.1
+*/
+ srand(get_ticks() + rand());
+ rand_minus_plus_100 = ((rand() % 200) - 100);
+ bootp_timeout = bootp_timeout +
+ (((int)bootp_timeout * rand_minus_plus_100) /
1000);
[PATCH v6 1/3] net: Enhancements for dhcp option 209
- Enable option 209 by default
- Set pxelinux_configfile to NULL to avoid potential double free
- change hardcoded 209 to a define
Signed-off-by: Sean Edmond
---
Changes in v7:
- Reword this commit
Changes in v6:
- Reword this commit
Changes in v4:
- rebase master and resolve conflicts
- default y for BOOTP_PXE_DHCP_OPTION (feedback from review)
- change commit description for this patch (this is now
an enhancement patch)
Changes in v3:
- add define for option 209 and rfc5071 reference
cmd/Kconfig | 1 +
cmd/pxe.c | 2 ++
net/bootp.c | 4 ++--
net/bootp.h | 2 ++
4 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/cmd/Kconfig b/cmd/Kconfig
index c182d73ddbd..54c4ab8570c 100644
--- a/cmd/Kconfig
+++ b/cmd/Kconfig
@@ -1898,6 +1898,7 @@ config BOOTP_PXE_CLIENTARCH
config BOOTP_PXE_DHCP_OPTION
bool "Request & store 'pxe_configfile' from BOOTP/DHCP server"
+ default y
depends on BOOTP_PXE
config BOOTP_VCI_STRING
diff --git a/cmd/pxe.c b/cmd/pxe.c
index 21134eb7a30..9404f445187 100644
--- a/cmd/pxe.c
+++ b/cmd/pxe.c
@@ -65,6 +65,8 @@ static int pxe_dhcp_option_path(struct pxe_context *ctx,
unsigned long pxefile_a
int ret = get_pxe_file(ctx, pxelinux_configfile, pxefile_addr_r);
free(pxelinux_configfile);
+ /* set to NULL to avoid double-free if DHCP is tried again */
+ pxelinux_configfile = NULL;
return ret;
}
diff --git a/net/bootp.c b/net/bootp.c
index c15472f5d37..b9e3cccb4f9 100644
--- a/net/bootp.c
+++ b/net/bootp.c
@@ -603,7 +603,7 @@ static int dhcp_extended(u8 *e, int message_type, struct
in_addr server_ip,
*cnt += 1;
#endif
if (IS_ENABLED(CONFIG_BOOTP_PXE_DHCP_OPTION)) {
- *e++ = 209; /* PXELINUX Config File */
+ *e++ = DHCP_OPTION_PXE_CONFIG_FILE; /* PXELINUX Config File
*/
*cnt += 1;
}
/* no options, so back up to avoid sending an empty request list */
@@ -922,7 +922,7 @@ static void dhcp_process_options(uchar *popt, uchar *end)
net_boot_file_name[size] = 0;
}
break;
- case 209: /* PXELINUX Config File */
+ case DHCP_OPTION_PXE_CONFIG_FILE: /* PXELINUX Config File
*/
if (IS_ENABLED(CONFIG_BOOTP_PXE_DHCP_OPTION)) {
/* In case it has already been allocated when
get DHCP Offer packet,
* free first to avoid memory leak.
diff --git a/net/bootp.h b/net/bootp.h
index 4e32b19d424..24b32c73f62 100644
--- a/net/bootp.h
+++ b/net/bootp.h
@@ -91,6 +91,8 @@ typedef enum { INIT,
#define DHCP_NAK 6
#define DHCP_RELEASE 7
+#define DHCP_OPTION_PXE_CONFIG_FILE209 /* "ConfigFile" option
according to rfc5071 */
+
/**/
#endif /* __BOOTP_H__ */
--
2.42.0
[PATCH v6 0/3] BOOTP/DHCPv4 enhancements
In our datacenter application, a single DHCP server is servicing 36000+ clients. Improvements are required to the DHCPv4 retransmission behavior to align with RFC and ensure less pressure is exerted on the server: - retransmission backoff interval maximum is configurable (environment variable bootpretransmitperiodmax) - initial retransmission backoff interval is configurable (environment variable bootpretransmitperiodinit) - transaction ID is kept the same for each BOOTP/DHCPv4 request (not recreated on each retry) For our application we'll use: - bootpretransmitperiodmax=16000 - bootpretransmitperiodinit=2000 A new configuration BOOTP_RANDOM_XID has been added to enable a randomized BOOTP/DHCPv4 transaction ID. Enhance DHCPv4 sending/parsing option 209 (PXE config file). A previous patch was accepted. A new patch fixes a possible double free() and addresses latest review comments. Changes in v7: - Remove "depends on LIB_RAND || LIB_HW_RAND" from CMD_BOOTP - Add CMD_BOOTP/CMD_DHCP/CMD_DHCP6 to LIB_RAND menu choice - Add space after "config CMD_DHCP" Changes in v6: - CMD_BOOTP should "depends on LIB_RAND || LIB_HW_RAND" Changes in v5: - add change log to individual patches - fix depends for BOOTP_RANDOM_XID: "depends on CMD_BOOTP && (LIB_RAND || LIB_HW_RAND)" Changes in v4: - rebase master and resolve conflicts - default y for BOOTP_PXE_DHCP_OPTION (feedback from review) - Add "select LIB_RAND" for "config CMD_BOOTP" (retransmission improvements require rand()) Changes in v3: - add define for option 209 and rfc5071 reference - Set RETRANSMIT_PERIOD_MAX_MS=6 - Add randomization factor to retransmission timeout - Add depends for BOOTP_RANDOM_XID Changes in v2: - use env_get_ulong() to get environment variables Sean Edmond (3): net: Enhancements for dhcp option 209 net: bootp: BOOTP/DHCPv4 retransmission improvements net: bootp: add config option BOOTP_RANDOM_XID cmd/Kconfig | 8 ++ cmd/pxe.c | 2 ++ lib/Kconfig | 3 ++- net/bootp.c | 76 + net/bootp.h | 2 ++ 5 files changed, 73 insertions(+), 18 deletions(-) -- 2.42.0
Re: [PATCH] mtd: nand: pxa3xx: Incorrect bitflip return on page read
On Mon, Apr 29, 2024 at 6:22 PM Chris Packham wrote:
>
> On Sun, Apr 28, 2024 at 4:15 AM Ravi Minnikanti
> wrote:
> >
> > Once a page is read with higher bitflips all subsequent reads
> > are returning the same bitflip value even though they have none.
> > max_bitflip variable is not being reset to 0 across page reads.
> >
> > This is causing problems like incorrectly
> > marking erase blocks bad by UBI and causing read failures.
> >
> > Verified the change with both MTD reads and UBI.
> > This change is inline with other NFC drivers.
> >
> > Sample error log where a block is marked bad incorrectly:
> >
> > ubi0: fixable bit-flip detected at PEB 125
> > ubi0: run torture test for PEB 125
> > ubi0: fixable bit-flip detected at PEB 125
> > ubi0 error: torture_peb: read problems on freshly erased PEB 125,
> > must be bad
> > ubi0 error: erase_worker: failed to erase PEB 125, error -5
> > ubi0: mark PEB 125 as bad
> >
> > Signed-off-by: rminnikanti
>
> Looks good to me
>
> Reviewed-by: Chris Packham
>
> > ---
> > drivers/mtd/nand/raw/pxa3xx_nand.c | 5 +
> > 1 file changed, 5 insertions(+)
> >
> > diff --git a/drivers/mtd/nand/raw/pxa3xx_nand.c
> > b/drivers/mtd/nand/raw/pxa3xx_nand.c
> > index 1d9a6d107b..d2a4faad56 100644
> > --- a/drivers/mtd/nand/raw/pxa3xx_nand.c
> > +++ b/drivers/mtd/nand/raw/pxa3xx_nand.c
> > @@ -800,6 +800,11 @@ static void prepare_start_command(struct
> > pxa3xx_nand_info *info, int command)
> > info->ecc_err_cnt = 0;
> > info->ndcb3 = 0;
> > info->need_wait = 0;
> > + /*
> > +* Reset max_bitflips to zero. Once command is complete,
> > +* max_bitflips for this READ is returned in ecc.read_page()
> > +*/
> > + info->max_bitflips = 0;
> >
Why this should not be put to 0 in read_page instead on prepare_start_command?
Michael
> > switch (command) {
> > case NAND_CMD_READ0:
> > --
> > 2.17.1
--
Michael Nazzareno Trimarchi
Co-Founder & Chief Executive Officer
M. +39 347 913 2170
mich...@amarulasolutions.com
__
Amarula Solutions BV
Joop Geesinkweg 125, 1114 AB, Amsterdam, NL
T. +31 (0)85 111 9172
i...@amarulasolutions.com
www.amarulasolutions.com
Re: [GIT PULL] Please pull u-boot-pmic master
On Mon, Apr 29, 2024 at 05:20:58PM +0900, Jaehoon Chung wrote: > Dear Tom, > > > Please pull u-boot-pmic master into u-boot master branch. > If there is a problem, let me know, plz > > Best Regards, > Jaehoon Chung > > CI: https://source.denx.de/u-boot/custodians/u-boot-pmic/-/pipelines/20569 > > The following changes since commit 174ac987655c888017c82df1883c0c2ea0dc2495: > > Merge branch 'master' of > https://source.denx.de/u-boot/custodians/u-boot-mmc (2024-04-26 07:39:18 > -0600) > > are available in the Git repository at: > > g...@source.denx.de:u-boot/custodians/u-boot-pmic.git master > > for you to fetch changes up to 17fd67aedde714556895a0d39431f482accd0cc3: > > power: pmic: tps65941: Update compatible to aling with kernel DT > (2024-04-29 09:20:51 +0900) > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [GIT PULL] Please pull u-boot-imx-master-20240429
On Mon, Apr 29, 2024 at 07:35:24AM -0300, Fabio Estevam wrote: > Hi Tom, > > Please pull from u-boot-imx/master, thanks. > > The following changes since commit 174ac987655c888017c82df1883c0c2ea0dc2495: > > Merge branch 'master' of > https://source.denx.de/u-boot/custodians/u-boot-mmc (2024-04-26 07:39:18 > -0600) > > are available in the Git repository at: > > https://gitlab.denx.de/u-boot/custodians/u-boot-imx.git > tags/u-boot-imx-master-20240429 > > for you to fetch changes up to 37e50627efacd8dae18b564e9d8886a033e181bc: > > ARM: dts: imx: Convert i.MX8M flash.bin image generation to binman > (2024-04-28 12:10:13 -0300) > > u-boot-imx-master-20240429 Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 3/3] patman: Add a tag for when a patch gets added to a series
Hi, On Thu, Apr 18, 2024 at 7:36 PM Sean Anderson wrote: > > When a patch is added to a series after the initial version, there are no > changes to note except that it is new. This is typically done to suppress > the "(no changes in vN)" message. It's also nice to add a change to the > cover letter so reviewers know there is an additional patch. Add a tag to > automate this process a bit. > > There are two nits with the current approach: > > - It favors '-' as a bullet point, but some people may prefer '*' (or > something else) > - Tags (e.g. 'patman: ' in 'patman: foo bar') are not stripped. They are > probably just noise in most series, but they may be useful for treewide > series to distinguish 'gpio: frobnicate' from 'reset: frobnicate', so > I've left them in. > > Suggestions for the above appreciated. > > Suggested-by: Douglas Anderson > Signed-off-by: Sean Anderson > --- > > tools/patman/func_test.py | 2 ++ > tools/patman/patchstream.py | 5 + > tools/patman/patman.rst | 13 + > ...t-cast-for-sandbox-in-fdtdec_setup_mem_siz.patch | 1 + > tools/patman/test/test01.txt| 1 + > 5 files changed, 22 insertions(+) I love it, thanks! Reviewed-by: Douglas Anderson
Re: [PATCH v3] mmc: allow use of hardware partition names for mmc partconf
On Sat, Apr 27, 2024 at 4:20 PM Marek Vasut wrote:
>
> On 4/27/24 2:11 AM, Tim Harvey wrote:
>
> [...]
>
> > diff --git a/include/mmc.h b/include/mmc.h
> > index 4b8327f1f93b..7243bd761202 100644
> > --- a/include/mmc.h
> > +++ b/include/mmc.h
> > @@ -381,6 +381,21 @@ enum mmc_voltage {
> > #define MMC_TIMING_MMC_HS2009
> > #define MMC_TIMING_MMC_HS40010
> >
> > +/* emmc hardware partition values */
> > +enum emmc_hwpart {
> > + EMMC_HWPART_DEFAULT = 0,
>
> One more thing ... eMMC hardware partition 0 and 7 are both referring to
> USER HW partition. Have a look at the git log, there have been patches
> which handled this case in the MMC subsystem from about a year ago.
Hi Marek,
I can't find what you are referring to. I assume you are talking about
calling the first name something other than 'user' as technically it's
not (but it gets treated as user).
Can you find the commit or discussion you are thinking about?
Best Regards,
Tim
Re: [PATCH] mtd: nand: pxa3xx: Incorrect bitflip return on page read
On Sun, Apr 28, 2024 at 4:15 AM Ravi Minnikanti wrote:
>
> Once a page is read with higher bitflips all subsequent reads
> are returning the same bitflip value even though they have none.
> max_bitflip variable is not being reset to 0 across page reads.
>
> This is causing problems like incorrectly
> marking erase blocks bad by UBI and causing read failures.
>
> Verified the change with both MTD reads and UBI.
> This change is inline with other NFC drivers.
>
> Sample error log where a block is marked bad incorrectly:
>
> ubi0: fixable bit-flip detected at PEB 125
> ubi0: run torture test for PEB 125
> ubi0: fixable bit-flip detected at PEB 125
> ubi0 error: torture_peb: read problems on freshly erased PEB 125,
> must be bad
> ubi0 error: erase_worker: failed to erase PEB 125, error -5
> ubi0: mark PEB 125 as bad
>
> Signed-off-by: rminnikanti
Looks good to me
Reviewed-by: Chris Packham
> ---
> drivers/mtd/nand/raw/pxa3xx_nand.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/mtd/nand/raw/pxa3xx_nand.c
> b/drivers/mtd/nand/raw/pxa3xx_nand.c
> index 1d9a6d107b..d2a4faad56 100644
> --- a/drivers/mtd/nand/raw/pxa3xx_nand.c
> +++ b/drivers/mtd/nand/raw/pxa3xx_nand.c
> @@ -800,6 +800,11 @@ static void prepare_start_command(struct
> pxa3xx_nand_info *info, int command)
> info->ecc_err_cnt = 0;
> info->ndcb3 = 0;
> info->need_wait = 0;
> + /*
> +* Reset max_bitflips to zero. Once command is complete,
> +* max_bitflips for this READ is returned in ecc.read_page()
> +*/
> + info->max_bitflips = 0;
>
> switch (command) {
> case NAND_CMD_READ0:
> --
> 2.17.1
Re: [PATCH 2/2] armv8: generic_timer: Use event stream for udelay
On Tue, 23 Apr 2024 09:10:05 +0100
Peter Hoyes wrote:
Hi,
> From: Peter Hoyes
>
> Polling cntpct_el0 in a tight loop for delays is inefficient.
> This is particularly apparent on Arm FVPs, which do not simulate
> real time, meaning that a 1s sleep can take a couple of orders
> of magnitude longer to execute in wall time.
>
> If running at EL2 or above (where CNTHCTL_EL2 is available), enable
> the cntpct_el0 event stream temporarily and use wfe to implement
> the delay more efficiently. The event period is chosen as a
> trade-off between efficiency and the fact that Arm FVPs do not
> typically simulate real time.
>
> This is only implemented for Armv8 boards, where an architectural
> timer exists.
>
> Some mach-socfpga AArch64 boards already override __udelay to make
> it always inline, so guard the functionality with a new
> ARMV8_UDELAY_EVENT_STREAM Kconfig, enabled by default.
So the code looks alright, and it works for me, tested on some hardware I
just had at hand.
However I am a bit worried about the scope of this patch. While it's
indeed purely architectural and should work on all systems, I think we
need to be careful with messing with the arch timer *while the OS is
running*. U-Boot code will run for UEFI runtime services and for serving
PSCI on some platforms, and I guess messing with CNTHCTL_EL2 is not a good
idea then. And udelay sounds like a basic function that this code might
use.
So I wonder if we should limit this to the Arm FVPs for now? To not create
subtle and hard-to-diagnose problems for a lot of boards?
Or maybe there is some mechanism to limit this to U-Boot boot time/UEFI
boot services?
> Signed-off-by: Peter Hoyes
> ---
> arch/arm/cpu/armv8/Kconfig | 8
> arch/arm/cpu/armv8/generic_timer.c | 27 +++
> arch/arm/include/asm/system.h | 6 --
> 3 files changed, 39 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/cpu/armv8/Kconfig b/arch/arm/cpu/armv8/Kconfig
> index 9f0fb369f7..544c5e2d74 100644
> --- a/arch/arm/cpu/armv8/Kconfig
> +++ b/arch/arm/cpu/armv8/Kconfig
> @@ -191,6 +191,14 @@ config ARMV8_EA_EL3_FIRST
> Exception handling at all exception levels for External Abort and
> SError interrupt exception are taken in EL3.
>
> +config ARMV8_UDELAY_EVENT_STREAM
> + bool "Use the event stream for udelay"
> + default y if !ARCH_SOCFPGA
As described above, change this to something like "... if ARCH_VEXPRESS64".
Cheers,
Andre
> + help
> + Use the event stream provided by the AArch64 architectural timer for
> + delays. This is more efficient than the default polling
> + implementation.
> +
> menuconfig ARMV8_CRYPTO
> bool "ARM64 Accelerated Cryptographic Algorithms"
>
> diff --git a/arch/arm/cpu/armv8/generic_timer.c
> b/arch/arm/cpu/armv8/generic_timer.c
> index 8f83372cbc..e18b5c8187 100644
> --- a/arch/arm/cpu/armv8/generic_timer.c
> +++ b/arch/arm/cpu/armv8/generic_timer.c
> @@ -115,3 +115,30 @@ ulong timer_get_boot_us(void)
>
> return val / get_tbclk();
> }
> +
> +#if CONFIG_IS_ENABLED(ARMV8_UDELAY_EVENT_STREAM)
> +void __udelay(unsigned long usec)
> +{
> + u64 target = get_ticks() + usec_to_tick(usec);
> +
> + /* At EL2 or above, use the event stream to avoid polling CNTPCT_EL0 so
> often */
> + if (current_el() >= 2) {
> + u32 cnthctl_val;
> + const u8 event_period = 0x7;
> +
> + asm volatile("mrs %0, cnthctl_el2" : "=r" (cnthctl_val));
> + asm volatile("msr cnthctl_el2, %0" : : "r"
> + (cnthctl_val | CNTHCTL_EL2_EVNT_EN |
> CNTHCTL_EL2_EVNT_I(event_period)));
> +
> + while (get_ticks() + (1ULL << event_period) <= target)
> + wfe();
> +
> + /* Reset the event stream */
> + asm volatile("msr cnthctl_el2, %0" : : "r" (cnthctl_val));
> + }
> +
> + /* Fall back to polling CNTPCT_EL0 */
> + while (get_ticks() <= target)
> + ;
> +}
> +#endif
> diff --git a/arch/arm/include/asm/system.h b/arch/arm/include/asm/system.h
> index 51123c2968..7e30cac32a 100644
> --- a/arch/arm/include/asm/system.h
> +++ b/arch/arm/include/asm/system.h
> @@ -69,8 +69,10 @@
> /*
> * CNTHCTL_EL2 bits definitions
> */
> -#define CNTHCTL_EL2_EL1PCEN_EN (1 << 1) /* Physical timer regs
> accessible */
> -#define CNTHCTL_EL2_EL1PCTEN_EN (1 << 0) /* Physical counter
> accessible */
> +#define CNTHCTL_EL2_EVNT_EN BIT(2) /* Enable the event stream */
> +#define CNTHCTL_EL2_EVNT_I(val) ((val) << 4) /* Event stream trigger
> bits */
> +#define CNTHCTL_EL2_EL1PCEN_EN (1 << 1) /* Physical timer regs
> accessible */
> +#define CNTHCTL_EL2_EL1PCTEN_EN (1 << 0) /* Physical counter
> accessible */
>
> /*
> * HCR_EL2 bits definitions
Re: [PATCH v2 1/6] mtd: ubi: Do not zero out EC and VID on ECC-ed NOR flashes
On 4/29/24 15:17, Pratyush Yadav wrote:
> On Thu, Apr 25 2024, tkuw584...@gmail.com wrote:
>
>> From: Takahiro Kuwano
>
> I wonder how authorship should work for such patches. Patches 1, 2, and
> 6 in this series are very close to what my patches did for Linux. So I
> wonder who should get authorship in this case: the person porting the
> patch or the person who wrote the original one. Same for patch 5 but
> that is still a little more changed from its Linux counterpart.
>
I saw it's the one that ports the patch to u-boot even when it's a
1-to-1 match. I guess it's because u-boot has its own dedicated repo.
cut
>>
>> This patch replicates the following upstream linux commit:
>> f669e74be820 ("ubi: Do not zero out EC and VID on ECC-ed NOR flashes")
This paragraph shall give credit to the linux author and at the same
time help others review the changes.
Re: [PATCH v2 1/6] mtd: ubi: Do not zero out EC and VID on ECC-ed NOR flashes
On Thu, Apr 25 2024, tkuw584...@gmail.com wrote:
> From: Takahiro Kuwano
I wonder how authorship should work for such patches. Patches 1, 2, and
6 in this series are very close to what my patches did for Linux. So I
wonder who should get authorship in this case: the person porting the
patch or the person who wrote the original one. Same for patch 5 but
that is still a little more changed from its Linux counterpart.
>
> For NOR flashes EC and VID are zeroed out before an erase is issued to
> make sure UBI does not mistakenly treat the PEB as used and associate it
> with an LEB.
>
> But on some flashes, like the Infineon Semper NOR flash family,
> multi-pass page programming is not allowed on the default ECC scheme.
> This means zeroing out these magic numbers will result in the flash
> throwing a page programming error.
>
> Do not zero out EC and VID for such flashes. A writesize > 1 is an
> indication of an ECC-ed flash.
>
> This patch replicates the following upstream linux commit:
> f669e74be820 ("ubi: Do not zero out EC and VID on ECC-ed NOR flashes")
>
> Acked-by: Tudor Ambarus
> Signed-off-by: Takahiro Kuwano
Apart from my comment above,
Acked-by: Pratyush Yadav
--
Regards,
Pratyush Yadav
Usage of fdt_addr vs fdt_addr_r
Hi, there are multiple definitions of fdt_addr and fdt_addr_r: usage/environment.rst: Tells us fdt_addr is in flash location and _r in RAM develop/distro.rst: fdt_addr -> Mandatory for any system that provides the DTB in HW (e.g. ROM) I also noticed that bootmeth_efi.c/distro_efi_try_bootflow_files() will copy the dtb it has found into fdt_addr_r. But efi_install_fdt() try to load first from fdt_addr. Shouldn't they use the same environment variable? Doing so would allow efiboot to use the dtb it has detected using bootflow. Right now it seems to fallback to fdtcontroladdr. Regards, Wadim
Re: [EXT] Re: [PATCH 2/3] crypto/fsl: Introduce SPL_FSL_CAAM_RNG
On 4/29/24 11:02 AM, Gaurav Jain wrote: Hi, diff --git a/drivers/crypto/fsl/Makefile b/drivers/crypto/fsl/Makefile index 7a2543e16cc..4fbce519a0b 100644 --- a/drivers/crypto/fsl/Makefile +++ b/drivers/crypto/fsl/Makefile @@ -6,6 +6,6 @@ obj-y += sec.o obj-$(CONFIG_FSL_CAAM) += jr.o fsl_hash.o jobdesc.o error.o obj-$(CONFIG_CMD_BLOB)$(CONFIG_IMX_CAAM_DEK_ENCAP) += fsl_blob.o obj-$(CONFIG_RSA_FREESCALE_EXP) += fsl_rsa.o -obj-$(CONFIG_FSL_CAAM_RNG) += rng.o +obj-$(CONFIG_$(SPL_TPL_)FSL_CAAM_RNG) += rng.o obj-$(CONFIG_FSL_DCP_RNG) += dcp_rng.o obj-$(CONFIG_FSL_MFGPROT) += fsl_mfgprot.o -- 2.43.0 Marek, Hi, Thanks - this series does solve the issue I am seeing in the SPL when enabling DM_RNG. Is this going to cause an issue for people who expect it to be currently enabled and now have to manually enable it? That's a good question. If I do '$ git grep FSL_CAAM_RNG' , there seem to be no users, so I don't think we need to worry here, right ? With SPL_DM_RNG i.e. 1/3 I am a bit more concerned. But, looking at the users that enable DM_RNG, I am not seeing any obvious ones that would require SPL_DM_RNG too. What do you think ? FSL_CAAM_RNG is enabled based on DM_RNG. This patch will disable the build of drivers/crypto/fsl/rng.c in SPL. Is that actually a problem for any supported platform ? (that is what is being discussed in this thread already)
Re: [PATCH 1/2] arm: Move sev() and wfe() definitions to common Arm header file
On Tue, 23 Apr 2024 09:10:04 +0100
Peter Hoyes wrote:
Hi,
> From: Peter Hoyes
>
> The sev() and wfe() asm macros are currently defined only for
> mach-exynos. As these are common Arm instructions, move them to the
> common asm/system.h header file, for both Armv7 and Armv8, so they
> can be used by other machines.
>
> wfe may theoretically trigger a context switch if an interrupt occurs
> so add a memory barrier to this call.
>
> Signed-off-by: Peter Hoyes
Looks alright to me, and the memory barrier for wfe looks justified.
For the records: we couldn't come up with a reason why "sev" would need
one as well, so even while the kernel has this, this seems to be more a
copy incident rather than something intentional.
Reviewed-by: Andre Przywara
Cheers,
Andre
> ---
> arch/arm/include/asm/system.h | 9 +
> arch/arm/mach-exynos/include/mach/system.h | 19 ---
> 2 files changed, 9 insertions(+), 19 deletions(-)
>
> diff --git a/arch/arm/include/asm/system.h b/arch/arm/include/asm/system.h
> index 43f7503571..51123c2968 100644
> --- a/arch/arm/include/asm/system.h
> +++ b/arch/arm/include/asm/system.h
> @@ -154,6 +154,13 @@ enum dcache_option {
> "wfi" : : : "memory"); \
> })
>
> +#define wfe()\
> + ({asm volatile( \
> + "wfe" : : : "memory"); \
> + })
> +
> +#define sev() asm volatile("sev")
> +
> static inline unsigned int current_el(void)
> {
> unsigned long el;
> @@ -369,6 +376,8 @@ void switch_to_hypervisor_ret(void);
>
> #ifdef __ARM_ARCH_7A__
> #define wfi() __asm__ __volatile__ ("wfi" : : : "memory")
> +#define wfe() __asm__ __volatile__ ("wfe" : : : "memory")
> +#define sev() __asm__ __volatile__ ("sev")
> #else
> #define wfi()
> #endif
> diff --git a/arch/arm/mach-exynos/include/mach/system.h
> b/arch/arm/mach-exynos/include/mach/system.h
> index 5d0bebac57..0aed4c3e2b 100644
> --- a/arch/arm/mach-exynos/include/mach/system.h
> +++ b/arch/arm/mach-exynos/include/mach/system.h
> @@ -36,25 +36,6 @@ struct exynos5_sysreg {
>
> #define USB20_PHY_CFG_HOST_LINK_EN (1 << 0)
>
> -/*
> - * This instruction causes an event to be signaled to all cores
> - * within a multiprocessor system. If SEV is implemented,
> - * WFE must also be implemented.
> - */
> -#define sev() __asm__ __volatile__ ("sev\n\t" : : );
> -/*
> - * If the Event Register is not set, WFE suspends execution until
> - * one of the following events occurs:
> - * - an IRQ interrupt, unless masked by the CPSR I-bit
> - * - an FIQ interrupt, unless masked by the CPSR F-bit
> - * - an Imprecise Data abort, unless masked by the CPSR A-bit
> - * - a Debug Entry request, if Debug is enabled
> - * - an Event signaled by another processor using the SEV instruction.
> - * If the Event Register is set, WFE clears it and returns immediately.
> - * If WFE is implemented, SEV must also be implemented.
> - */
> -#define wfe() __asm__ __volatile__ ("wfe\n\t" : : );
> -
> /* Move 0xd3 value to CPSR register to enable SVC mode */
> #define svc32_mode_en() __asm__ __volatile__ \
> ("@ I disable, Mode: 0x13 - SVC\n\t" \
Re: [PATCH v2 1/3] binman: Add nxp_imx8mimage etype
On Thu, Apr 25, 2024 at 8:01 PM Marek Vasut wrote: > > Add new binman etype derived from mkimage etype which generates configuration > input file for mkimage -T imx8mimage, and runs the mkimage on input data. The > mkimage -T imx8mimage is used to generate combined image with SPL and DDR PHY > blobs which is bootable on i.MX8M. > > The configuration file generated here is equivalent of imx8mimage.cfg, which > is the file passed to '$ mkimage -T imx8mimage -n imx8mimage.cfg ...' . The > settings generated into the imx8mimage.cfg file are configured via supported > binman DT properties, nxp,boot-from, nxp,loader-address, nxp,rom-version. > > Signed-off-by: Marek Vasut Applied all, thanks.
Re: [PATCH 0/2] imx93-11x11-evk: Convert to OF_UPSTREAM
On Wed, Apr 24, 2024 at 5:12 AM Peng Fan (OSS) wrote: > > From: Peng Fan > > patch 1 is to avoid build break when using upstream dts > Patch 2 is moving to OF_UPSTREAM > > This is a resend of V3 imx93: Conver to OF_UPSTREAM patch 5,6 > > Peng Fan (2): > dt-bindings: imx93: sync clock header > imx: imx93-11x11-evk: convert to OF_UPSTREAM Applied all, thanks.
Re: [PATCH] ARM: dts: imx: Enable PCIe and NVMe on DH i.MX8M Plus DHCOM PDK3
On Tue, Apr 23, 2024 at 8:15 PM Marek Vasut wrote: > > Enable PCIe/NVMe support on DH i.MX8M Plus DHCOM PDK3. Except for > the configuration options which are enabled, add slight adjustment > to board u-boot.dtsi, which is necessary as there is currently no > driver for the I2C PCIe clock generator. Since the generator is > strapped to be always on, it is possible to supplant the generator > functionality by fixed-clock. > > Signed-off-by: Marek Vasut Applied, thanks.
Re: [PATCH v1] board: toradex: colibri-imx(6ull|imx7): Fix missing fdt_fixup boot error
On Tue, Apr 23, 2024 at 12:57 PM Francesco Dolcini wrote:
>
> From: Francesco Dolcini
>
> In commit 51aaaf5e7975 ("board: toradex: imx: Remove not needed env
> variables")
> the empty definition of fdt_fixup variable was removed, however this was
> still referenced from the boot command leading to boot failures:
> ## Error: \"fdt_fixup\" not defined`
>
> Fix this by removing "run fdt_fixup" from the boot command and instead
> enable CONFIG_OF_ENV_SETUP in the defconfig that would achieve the same
> but in a more robust way (it works fine even if the variable is not
> defined).
>
> Fixes: 51aaaf5e7975 ("board: toradex: imx: Remove not needed env variables")
> Signed-off-by: Francesco Dolcini
Applied, thanks.
[GIT PULL] Please pull u-boot-imx-master-20240429
Hi Tom, Please pull from u-boot-imx/master, thanks. The following changes since commit 174ac987655c888017c82df1883c0c2ea0dc2495: Merge branch 'master' of https://source.denx.de/u-boot/custodians/u-boot-mmc (2024-04-26 07:39:18 -0600) are available in the Git repository at: https://gitlab.denx.de/u-boot/custodians/u-boot-imx.git tags/u-boot-imx-master-20240429 for you to fetch changes up to 37e50627efacd8dae18b564e9d8886a033e181bc: ARM: dts: imx: Convert i.MX8M flash.bin image generation to binman (2024-04-28 12:10:13 -0300) u-boot-imx-master-20240429 -- CI: https://source.denx.de/u-boot/custodians/u-boot-imx/-/pipelines/20563 - Fix missing fdt_fixup on colibri-imx(6ull|imx7). - Enable PCIe and NVMe on DH i.MX8M Plus DHCOM PDK3. - Convert i.MX8M flash.bin image generation to binman - Convert imx93-11x11-evk to OF_UPSTREAM. Francesco Dolcini (1): board: toradex: colibri-imx(6ull|imx7): Fix missing fdt_fixup boot error Marek Vasut (4): ARM: dts: imx: Enable PCIe and NVMe on DH i.MX8M Plus DHCOM PDK3 binman: Add nxp_imx8mimage etype ARM: dts: imx: Switch Ronetix iMX8MQ-CM to imx8mq-u-boot.dtsi ARM: dts: imx: Convert i.MX8M flash.bin image generation to binman Peng Fan (2): dt-bindings: imx93: sync clock header imx: imx93-11x11-evk: convert to OF_UPSTREAM arch/arm/dts/Makefile | 1 - arch/arm/dts/imx8mm-u-boot.dtsi | 126 -- arch/arm/dts/imx8mm-verdin-wifi-dev-u-boot.dtsi | 8 +- arch/arm/dts/imx8mn-u-boot.dtsi | 147 +-- arch/arm/dts/imx8mp-dhcom-pdk3-u-boot.dtsi | 12 + arch/arm/dts/imx8mp-dhcom-u-boot.dtsi | 2 +- arch/arm/dts/imx8mp-rsb3720-a1-u-boot.dtsi | 2 +- arch/arm/dts/imx8mp-u-boot.dtsi | 96 +++ arch/arm/dts/imx8mq-cm-u-boot.dtsi | 111 +--- arch/arm/dts/imx8mq-librem5-r4-u-boot.dtsi | 15 +- arch/arm/dts/imx8mq-u-boot.dtsi | 109 arch/arm/dts/imx93-11x11-evk-u-boot.dtsi| 118 + arch/arm/dts/imx93-11x11-evk.dts| 322 arch/arm/dts/imx93-u-boot.dtsi | 15 ++ arch/arm/mach-imx/imx9/Kconfig | 1 + configs/colibri-imx6ull_defconfig | 1 + configs/colibri_imx7_defconfig | 1 + configs/imx8mp_dhcom_pdk3_defconfig | 5 + configs/imx93_11x11_evk_defconfig | 2 +- configs/imx93_11x11_evk_ld_defconfig| 2 +- include/configs/colibri-imx6ull.h | 2 +- include/configs/colibri_imx7.h | 2 +- include/dt-bindings/clock/imx93-clock.h | 3 +- tools/binman/etype/nxp_imx8mimage.py| 74 ++ 24 files changed, 437 insertions(+), 740 deletions(-) delete mode 100644 arch/arm/dts/imx93-11x11-evk.dts create mode 100644 tools/binman/etype/nxp_imx8mimage.py
RE: [EXT] Re: [PATCH 2/3] crypto/fsl: Introduce SPL_FSL_CAAM_RNG
Hi Marek > -Original Message- > From: Marek Vasut > Sent: Friday, April 26, 2024 9:33 AM > To: thar...@gateworks.com > Cc: u-boot@lists.denx.de; Angelo Dureghello ; > Emanuele Ghidoli ; Fabio Estevam > ; Gaurav Jain ; Heinrich > Schuchardt ; Michal Simek ; > Simon Glass ; Stefan Roese ; Sughosh Ganu > ; Svyatoslav Ryhel ; Tom Rini > > Subject: [EXT] Re: [PATCH 2/3] crypto/fsl: Introduce SPL_FSL_CAAM_RNG > > Caution: This is an external email. Please take care when clicking links or > opening > attachments. When in doubt, report the message using the 'Report this email' > button > > > On 4/26/24 2:16 AM, Tim Harvey wrote: > > >> diff --git a/drivers/crypto/fsl/Makefile > >> b/drivers/crypto/fsl/Makefile index 7a2543e16cc..4fbce519a0b 100644 > >> --- a/drivers/crypto/fsl/Makefile > >> +++ b/drivers/crypto/fsl/Makefile > >> @@ -6,6 +6,6 @@ obj-y += sec.o > >> obj-$(CONFIG_FSL_CAAM) += jr.o fsl_hash.o jobdesc.o error.o > >> obj-$(CONFIG_CMD_BLOB)$(CONFIG_IMX_CAAM_DEK_ENCAP) += fsl_blob.o > >> obj-$(CONFIG_RSA_FREESCALE_EXP) += fsl_rsa.o > >> -obj-$(CONFIG_FSL_CAAM_RNG) += rng.o > >> +obj-$(CONFIG_$(SPL_TPL_)FSL_CAAM_RNG) += rng.o > >> obj-$(CONFIG_FSL_DCP_RNG) += dcp_rng.o > >> obj-$(CONFIG_FSL_MFGPROT) += fsl_mfgprot.o > >> -- > >> 2.43.0 > >> > > > > Marek, > > Hi, > > > Thanks - this series does solve the issue I am seeing in the SPL when > > enabling DM_RNG. Is this going to cause an issue for people who expect > > it to be currently enabled and now have to manually enable it? > > That's a good question. If I do '$ git grep FSL_CAAM_RNG' , there seem to be > no > users, so I don't think we need to worry here, right ? > > With SPL_DM_RNG i.e. 1/3 I am a bit more concerned. But, looking at the users > that enable DM_RNG, I am not seeing any obvious ones that would require > SPL_DM_RNG too. What do you think ? FSL_CAAM_RNG is enabled based on DM_RNG. This patch will disable the build of drivers/crypto/fsl/rng.c in SPL. Regards Gaurav Jain
Re: [PATCH] clk: zynq: Fix EMIO clock use detection for gem0
On 4/25/24 17:18, Ondřej Jirman wrote:
On Thu, Apr 25, 2024 at 12:59:29PM GMT, Michal Simek wrote:
Well, it doesn't help that the code is almost all refering to CLK_CTRL while
actually accessing gem1_rclk_ctrl in the struct.
In any case it can't detect the case when sourcing the clock from EMIO and
not one of the PLLs, apparently.
The failure I'm talking about is here in zynq_gem.c:
ret = clk_get_rate(>tx_clk);
if (ret != clk_rate) {
ret = clk_set_rate(>tx_clk, clk_rate);
if (IS_ERR_VALUE(ret)) {
dev_err(dev, "failed to set tx clock rate %ld\n",
clk_rate);
return ret;
}
}
And all I get is "failed to set tx clock rate" from U-Boot and no ethernet.
Zynq is quite a old device but I expect you have external clock out of chip
or you generate it in PL. For that you need to describe it.
How does your DT looks like for external clocks?
The situation is that RX/TX clocks just come from outside
https://megous.com/dl/tmp/af9e7c9e8d51781b.png via PL. 25MHz clock is
generated by the PHY.
I solved it eventually.
I described the PHY generated clock as a fixed-clock node, and added a
reference to it under as a source for "gem0_emio_clk".
https://megous.com/git/u-boot/tree/arch/arm/dts/zynq-ebaz-megi.dts?h=v2024.07#n26
Zynq clk code seems to fetch gem0_emio_clk from DT for the purpose of
determining the clk rate for gem0 in emio mode:
https://elixir.bootlin.com/u-boot/latest/source/drivers/clk/clk_zynq.c#L524
https://elixir.bootlin.com/u-boot/latest/source/drivers/clk/clk_zynq.c#L280
This got rid of the "failed to set tx clock rate" error. Thank you for the hint.
BTW, I managed to get the .bit file loaded via SPL only with a SPL patch:
https://megous.com/git/u-boot/commit/?h=v2024.07=c1403bd080bc517c9dc6f507ee12b62fa85153bc
It's similar to how it's done in:
https://elixir.bootlin.com/u-boot/latest/source/boot/image-board.c#L677
fpga_load() function doesn't work with .bit file I get from Vivado but
fpga_loadbitstream() one does. SPL doesn't call it, though. Is that by design?
Should I be converting .bit file to something else usable by fpga_load()
somehow?
Yes there was limitation or missing detection which fpga format is supported.
I'd like to load bitstream in SPL from FIT because U-Boot proper may already
need some PL logic activated for ethernet to work there. Also it's one less
file on the /boot filesystem to worry about. :)
I think you have two options.
1. convert your bitstream in bit format to bin format
2. Extend SPL code to support both formats.
I would go with option 1 but patches for option 2 are definitely welcome.
Thanks,
Michal
[GIT PULL] Please pull u-boot-pmic master
Dear Tom, Please pull u-boot-pmic master into u-boot master branch. If there is a problem, let me know, plz Best Regards, Jaehoon Chung CI: https://source.denx.de/u-boot/custodians/u-boot-pmic/-/pipelines/20569 The following changes since commit 174ac987655c888017c82df1883c0c2ea0dc2495: Merge branch 'master' of https://source.denx.de/u-boot/custodians/u-boot-mmc (2024-04-26 07:39:18 -0600) are available in the Git repository at: g...@source.denx.de:u-boot/custodians/u-boot-pmic.git master for you to fetch changes up to 17fd67aedde714556895a0d39431f482accd0cc3: power: pmic: tps65941: Update compatible to aling with kernel DT (2024-04-29 09:20:51 +0900) Bhargav Raviprakash (5): power: tps65941: Add macros of TPS65224 PMIC power: pmic: tps65941: Add TI TPS65224 PMIC power: regulator: tps65941: Added macros for BUCK ID power: regulator: tps65941: use function callbacks for conversion ops power: regulator: tps65941: Add TPS65224 PMIC regulator support Udit Kumar (1): power: pmic: tps65941: Update compatible to aling with kernel DT drivers/power/pmic/tps65941.c| 4 + drivers/power/regulator/tps65941_regulator.c | 381 --- include/power/tps65941.h | 30 +++ 3 files changed, 384 insertions(+), 31 deletions(-)
[PATCH v1] crypto: nuvoton: npcm_sha: Support SHA 384/512
1. Use vendor naming rule to rename each function
2. add SHA 384/512 support
Signed-off-by: Jim Liu
---
drivers/crypto/nuvoton/npcm_sha.c | 1024 +++--
1 file changed, 252 insertions(+), 772 deletions(-)
diff --git a/drivers/crypto/nuvoton/npcm_sha.c
b/drivers/crypto/nuvoton/npcm_sha.c
index 7ebdfa16f4..2a5e672688 100644
--- a/drivers/crypto/nuvoton/npcm_sha.c
+++ b/drivers/crypto/nuvoton/npcm_sha.c
@@ -1,868 +1,345 @@
// SPDX-License-Identifier: GPL-2.0+
/*
- * Copyright (c) 2022 Nuvoton Technology Corp.
+ * Copyright (c) 2024 Nuvoton Technology Corp.
*/
#include
#include
#include
#include
-#include
#include
+#include
-#define HASH_DIG_H_NUM 8
+#define SHA512_BLOCK_LENGTH (1024 / 8)
+/* Register fields */
#define HASH_CTR_STS_SHA_EN BIT(0)
#define HASH_CTR_STS_SHA_BUSY BIT(1)
#define HASH_CTR_STS_SHA_RSTBIT(2)
#define HASH_CFG_SHA1_SHA2 BIT(0)
-
-/* SHA type */
-enum npcm_sha_type {
- npcm_sha_type_sha2 = 0,
- npcm_sha_type_sha1,
- npcm_sha_type_num
+#define SHA512_CMD_SHA_512 BIT(3)
+#define SHA512_CMD_INTERNAL_ROUND BIT(2)
+#define SHA512_CMD_WRITE BIT(1)
+#define SHA512_CMD_READBIT(0)
+
+enum {
+ type_sha1 = 0,
+ type_sha256,
+ type_sha384,
+ type_sha512,
};
struct npcm_sha_regs {
- unsigned int hash_data_in;
- unsigned char hash_ctr_sts;
- unsigned char reserved_0[0x03];
- unsigned char hash_cfg;
- unsigned char reserved_1[0x03];
- unsigned char hash_ver;
- unsigned char reserved_2[0x13];
- unsigned int hash_dig[HASH_DIG_H_NUM];
+ u8 data_in;
+ u8 data_out;
+ u8 ctr_sts;
+ u8 hash_cfg;
+ u8 sha512_cmd;
};
-struct npcm_sha_priv {
- struct npcm_sha_regs *regs;
+struct hash_info {
+ u32 block_sz;
+ u32 digest_len;
+ u8 length_bytes;
+ u8 type;
};
-static struct npcm_sha_priv *sha_priv;
+struct message_block {
+ u64 length[2];
+ u64 nonhash_sz;
+ u8 buffer[SHA512_BLOCK_LENGTH * 2];
+};
-#ifdef SHA_DEBUG_MODULE
-#define sha_print(fmt, args...) printf(fmt, ##args)
-#else
-#define sha_print(fmt, args...) (void)0
-#endif
-
-#define SHA_BLOCK_LENGTH(512 / 8)
-#define SHA_2_HASH_LENGTH (256 / 8)
-#define SHA_1_HASH_LENGTH (160 / 8)
-#define SHA_HASH_LENGTH(type) ((type == npcm_sha_type_sha2) ? \
- (SHA_2_HASH_LENGTH) :
(SHA_1_HASH_LENGTH))
-
-#define SHA_SECRUN_BUFF_SIZE64
-#define SHA_TIMEOUT 100
-#define SHA_DATA_LAST_BYTE 0x80
-
-#define SHA2_NUM_OF_SELF_TESTS 3
-#define SHA1_NUM_OF_SELF_TESTS 4
-
-#define NUVOTON_ALIGNMENT 4
-
-/*-*/
-/* SHA instance struct handler
*/
-/*-*/
-struct SHA_HANDLE_T {
- u32 hv[SHA_2_HASH_LENGTH / sizeof(u32)];
- u32 length0;
- u32 length1;
- u32 block[SHA_BLOCK_LENGTH /
sizeof(u32)];
- u8 type;
- boolactive;
+struct npcm_sha_priv {
+ void *base;
+ struct npcm_sha_regs *regs;
+ struct hash_info *hash;
+ struct message_block block;
+ bool internal_round;
+ bool support_sha512;
};
-// The # of bytes currently in the sha block buffer
-#define SHA_BUFF_POS(length)((length) & (SHA_BLOCK_LENGTH - 1))
-
-// The # of free bytes in the sha block buffer
-#define SHA_BUFF_FREE(length) (SHA_BLOCK_LENGTH - SHA_BUFF_POS(length))
-
-static void SHA_FlushLocalBuffer_l(const u32 *buff);
-static int SHA_BusyWait_l(void);
-static void SHA_GetShaDigest_l(u8 *hashdigest, u8 type);
-static void SHA_SetShaDigest_l(const u32 *hashdigest, u8 type);
-static void SHA_SetBlock_l(const u8 *data, u32 len, u16 position, u32 *block);
-static void SHA_ClearBlock_l(u16 len, u16 position, u32 *block);
-static void SHA_SetLength32_l(struct SHA_HANDLE_T *handleptr, u32 *block);
-
-static int SHA_Init(struct SHA_HANDLE_T *handleptr);
-static int SHA_Start(struct SHA_HANDLE_T *handleptr, u8 type);
-static int SHA_Update(struct SHA_HANDLE_T *handleptr, const u8 *buffer, u32
len);
-static int SHA_Finish(struct SHA_HANDLE_T *handleptr, u8 *hashdigest);
-static int SHA_Reset(void);
-static int SHA_Power(bool on);
-#ifdef SHA_PRINT
-static void SHA_PrintRegs(void);
-static void SHA_PrintVersion(void);
-#endif
-
-static struct SHA_HANDLE_T sha_handle;
-
-/**/
-/* Checks if give function returns int error, and returns the error
*/
-/* immediately after SHA
