RE: [PATCH v1] LFU-544: Kconfig.nxp: Fixed secure boot on LS-CH2 platforms
Please remove the jira id. Regards Gaurav Jain > -Original Message- > From: Kshitiz Varshney > Sent: Thursday, June 22, 2023 2:55 PM > To: u-boot@lists.denx.de > Cc: Stefano Babic ; Fabio Estevam ; > Peng Fan ; Pankaj Gupta ; Varun > Sethi ; Gaurav Jain ; Rahul Kumar > Yadav ; Vabhav Sharma > ; Sahil Malhotra ; Ye Li > ; Tom Rini ; Kshitiz Varshney > > Subject: [PATCH v1] LFU-544: Kconfig.nxp: Fixed secure boot on LS-CH2 > platforms > > pimg64 image pointer is dependent on ESBC_ADDR_64BIT config, which is > getting disabled, due to dependency on ESBC_HDR_LS. > ESBC_HDR_LS is required for LS-CH3 platforms. > So, removing the dependency on ESBC_HDR_LS. > > Signed-off-by: Kshitiz Varshney > --- > arch/Kconfig.nxp | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/Kconfig.nxp b/arch/Kconfig.nxp index 6e1c44b7ea..fa9060a4db > 100644 > --- a/arch/Kconfig.nxp > +++ b/arch/Kconfig.nxp > @@ -45,7 +45,7 @@ config ESBC_HDR_LS > > config ESBC_ADDR_64BIT > def_bool y > - depends on ESBC_HDR_LS && FSL_LAYERSCAPE > + depends on FSL_LAYERSCAPE > help > For Layerscape based platforms, ESBC image Address in Header is 64bit. > > -- > 2.25.1
Re: U-Boot OMAP GPMC ECC change
Hi all Il sab 20 mag 2023, 19:28 Colin Foster ha scritto: > On Fri, May 19, 2023 at 03:41:34PM +0300, Roger Quadros wrote: > > Hi Colin, > > > > On 19/05/2023 02:19, Colin Foster wrote: > > > Hi Roger, > > > > > >> Can you please share your spl/u-boot.cfg? > > > > > > Attached > > > > Couple of questions there > > > > 1) CONFIG_MTDPARTS_DEFAULT > "mtdparts=nandflash:0x2(xload_raw),0x18(u-boot),0x18(u-boot-2),0x1fce(main)" > > Is this correct and matches with what kernel sees? > > I couldn't see the NAND partition table in the Kernel Device tree patch. > > Yes, this is correct. I intentionally left my MTD Partitions out of the > kernel patch, since I don't want any changes I might make to the flash > partitions to require further patches. I'm currently at this structure > (SPL, 2x U-Boot, and main UBI with A/B partitions and 2x U-Boot Envs) > > The SD Boot version of U-Boot doesn't use NAND, so it might have a stale > partition layout that I'll need to remove / modify. > Was any end up here? Michael > > > > > 2) > > #define CONFIG_SYS_NAND_U_BOOT_OFFS 0x2 > > #define CONFIG_SYS_NAND_U_BOOT_OFFS_REDUND 0x1a > > > > These don't seem to match what you have defined in MTDPARTS_DEFAULT. > > Which one is correct? > > This matches the above partition layout. 0x18 + 0x2 = 0x1a. > > It wasn't until recently I realized I needed to remove > CONFIG_SPL_RAW_IMAGE_SUPPORT in order for this fallback to succeed. > > > > > How do you flash the MLO and u-boot image to NAND? > > I boot to from SD card, then run a commissioning script that contains: > > ``` > echo "Erasing MLO partition $MLO_PART" > flash_erase $MLO_PART 0 0 > > echo "Programming MLO partition" > nandwrite -a -p $MLO_PART $MLO_FILE > > echo "Erasing U-Boot partition $U_BOOT_PART" > flash_erase $U_BOOT_PART 0 0 > > echo "Programming U-Boot partition" > nandwrite -a -p $U_BOOT_PART $U_BOOT_FILE > > echo "Erasing U-Boot redundant partition $U_BOOT_PART_REDUND" > flash_erase $U_BOOT_PART_REDUND 0 0 > > echo "Programming U-Boot redund partition" > nandwrite -a -p $U_BOOT_PART_REDUND $U_BOOT_FILE > > echo "Clearing UBI partition" > flash_erase $UBI_PART 0 0 > > echo "Formatting UBI partition" > ubiformat $UBI_PART -y > ubiattach -p $UBI_PART > > echo "Making UBI volumes" > ubimkvol /dev/ubi0 -N env1 -s 0x4 > ubimkvol /dev/ubi0 -N env2 -s 0x4 > ubimkvol /dev/ubi0 -N rootfs-a -s 0xc00 > ubimkvol /dev/ubi0 -N rootfs-b -s 0xc00 > > echo "Writing rootfs partitions" > ubiupdatevol /dev/ubi0_2 $ROOTFS_FILE > ubiupdatevol /dev/ubi0_3 $ROOTFS_FILE > ``` > > For all these tests I've been manually running the flash_erase / > nandwrite process for the SPL / U-Boot partitions. > > > > > I tried on AM335x-EVM and it works fine both before and after commit > 04fcd25873. > > > > Once change I had to do was to increase the u-boot partition size > > as u-boot image does not fit in original partition size. > > > > -boot log follows- > > > > U-Boot SPL 2023.01-rc4-00381-g04fcd25873-dirty (May 19 2023 - 15:10:15 > +0300) > > Trying to boot from NAND > > > > > > U-Boot 2023.01-rc4-00381-g04fcd25873-dirty (May 19 2023 - 15:10:15 +0300) > > > > CPU : AM335X-GP rev 1.0 > > Model: TI AM335x EVM > > DRAM: 512 MiB > > Core: 156 devices, 17 uclasses, devicetree: separate > > WDT: Started wdt@44e35000 with servicing every 1000ms (60s timeout) > > NAND: 256 MiB > > MMC: OMAP SD/MMC: 0 > > Loading Environment from FAT... Unable to read "uboot.env" from > mmc0:1... > > not set. Validating first E-fuse MAC > > Net: eth2: ethernet@4a10, eth3: usb_ether > > Hit any key to stop autoboot: 0 > > => > > > > => mtd > > > > device nand0 , # parts = 10 > > #: namesizeoffset mask_flags > > 0: NAND.SPL0x0002 0x 0 > > 1: NAND.SPL.backup10x0002 0x0002 0 > > 2: NAND.SPL.backup20x0002 0x0004 0 > > 3: NAND.SPL.backup30x0002 0x0006 0 > > I need to go back to the 4460 datasheet. I looked and don't remember > seeing anything about an SPL search. I'd sleep better at night knowing > that when the day comes I need to update the SPL, I can do so with some > redundancy. Sorry - I'm getting off topic. > > I'll be back with hardware on Monday to keep looking at this. > > > 4: NAND.u-boot-spl-os 0x0004 0x0008 0 > > 5: NAND.u-boot 0x0020 0x000c 0 > > 6: NAND.u-boot-env 0x0002 0x002c 0 > > 7: NAND.u-boot-env.backup10x0002 0x002e 0 > > 8: NAND.kernel 0x0070 0x0030 0 > > 9: NAND.file-system0x0f60 0x00a0 0 > > > > > > -- > > cheers, > > -roger >
Re: [EXTERNAL] Re: [PATCH] arch: arm: dts: k3-am625-sk: Update timings node name for panel-lvds
Hi Tom,
On 23/06/23 22:26, Tom Rini wrote:
On Fri, Jun 23, 2023 at 06:11:52PM +0530, Nikhil M Jain wrote:
Update the name of timing parameter node to panel-timing from
panel-timngs.
Signed-off-by: Nikhil M Jain
---
arch/arm/dts/k3-am625-sk.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/dts/k3-am625-sk.dts b/arch/arm/dts/k3-am625-sk.dts
index 73dec8781c..a87b48bfed 100644
--- a/arch/arm/dts/k3-am625-sk.dts
+++ b/arch/arm/dts/k3-am625-sk.dts
@@ -168,7 +168,7 @@
width-mm = <217>;
height-mm = <136>;
data-mapping = "vesa-24";
- panel-timings {
+ panel-timing {
bootph-pre-ram;
clock-frequency = <150274>;
hactive = <1920>;
First, what tree is this against? Second, you know this needs to go to
the linux dts file, first. Thanks.
Yes I understand this should first go to linux dts. Please ignore this
patch, once we have dss node in linux dts, I will send the pathces.
Thanks,
Nikhil
Re: [PATCH] clk: sifive: only build sifive-prci.o for CONFIG_CLK_SIFIVE_PRCI
On Tue, May 09, 2023 at 02:50:05PM +0100, Ben Dooks wrote: > If we're building non FU540/FU740 SoC drivers, then the sifive-prci.o > is not needed. Only build this when CONFIG_CLK_SIFIVE_PRCI is selected. > > Signed-off-by: Ben Dooks > --- > drivers/clk/sifive/Makefile | 4 +--- > 1 file changed, 1 insertion(+), 3 deletions(-) Reviewed-by: Leo Yu-Chi Liang
Re: [PATCH v2 1/3] riscv: timer: Update the sifive clint timer driver to support aclint
> From: Bin Meng > Sent: Wednesday, June 21, 2023 11:12 PM > To: u-boot@lists.denx.de > Cc: Anup Patel ; Atish Patra ; > Bin Meng ; Palmer Dabbelt ; Paul > Walmsley ; Rick Jian-Zhi Chen(陳建志) > > Subject: [PATCH v2 1/3] riscv: timer: Update the sifive clint timer driver to > support aclint > > This RISC-V ACLINT specification [1] defines a set of memory mapped devices > which provide inter-processor interrupts (IPI) and timer functionalities for > each HART on a multi-HART RISC-V platform. > > The RISC-V ACLINT specification is defined to be backward compatible with the > SiFive CLINT specification, however the device tree binding is a new one. > This change updates the sifive clint timer driver to support ACLINT mtimer > device, using a per-driver data field to hold the mtimer offset to the base > address encoded in the mtimer node. > > [1] https://github.com/riscv/riscv-aclint/blob/main/riscv-aclint.adoc > > Signed-off-by: Bin Meng > > --- > > Changes in v2: > - drop ae350.h changes > > drivers/timer/sifive_clint_timer.c | 16 +++- > include/configs/qemu-riscv.h | 2 +- > include/configs/sifive-unleashed.h | 2 +- > include/configs/starfive-visionfive2.h | 1 + > 4 files changed, 14 insertions(+), 7 deletions(-) Reviewed-by: Rick Chen
Re: [PATCH] ARM: imx: romapi: Fix signed integer bitwise ops misuse
On 6/25/2023 6:34 PM, Marek Vasut wrote:
Bitwise operations on signed integers are not defined,
replace then with per-call checks.
You mean C99 standard?
Thanks,
Peng.
Signed-off-by: Marek Vasut
---
Cc: "NXP i.MX U-Boot Team"
Cc: Fabio Estevam
Cc: Heiko Schocher
Cc: Heinrich Schuchardt
Cc: Rasmus Villemoes
Cc: Simon Glass
Cc: Stefano Babic
Cc: Tom Rini
Cc: Ye Li
---
arch/arm/mach-imx/spl_imx_romapi.c | 32 --
1 file changed, 21 insertions(+), 11 deletions(-)
diff --git a/arch/arm/mach-imx/spl_imx_romapi.c
b/arch/arm/mach-imx/spl_imx_romapi.c
index 9164045115f..4af41699678 100644
--- a/arch/arm/mach-imx/spl_imx_romapi.c
+++ b/arch/arm/mach-imx/spl_imx_romapi.c
@@ -76,13 +76,16 @@ static int spl_romapi_load_image_seekable(struct
spl_image_info *spl_image,
u32 image_offset;
ret = rom_api_query_boot_infor(QUERY_IVT_OFF, );
- ret |= rom_api_query_boot_infor(QUERY_PAGE_SZ, );
- ret |= rom_api_query_boot_infor(QUERY_IMG_OFF, _offset);
+ if (ret != ROM_API_OKAY)
+ goto err;
- if (ret != ROM_API_OKAY) {
- puts("ROMAPI: Failure query boot infor pagesize/offset\n");
- return -1;
- }
+ ret = rom_api_query_boot_infor(QUERY_PAGE_SZ, );
+ if (ret != ROM_API_OKAY)
+ goto err;
+
+ ret = rom_api_query_boot_infor(QUERY_IMG_OFF, _offset);
+ if (ret != ROM_API_OKAY)
+ goto err;
header = (struct legacy_img_hdr *)(CONFIG_SPL_IMX_ROMAPI_LOADADDR);
@@ -124,6 +127,10 @@ static int spl_romapi_load_image_seekable(struct spl_image_info *spl_image,
}
return 0;
+
+err:
+ puts("ROMAPI: Failure query boot infor pagesize/offset\n");
+ return -1;
}
static ulong spl_ram_load_read(struct spl_load_info *load, ulong sector,
@@ -344,12 +351,12 @@ int board_return_to_bootrom(struct spl_image_info
*spl_image,
u32 boot, bstage;
ret = rom_api_query_boot_infor(QUERY_BT_DEV, );
- ret |= rom_api_query_boot_infor(QUERY_BT_STAGE, );
+ if (ret != ROM_API_OKAY)
+ goto err;
- if (ret != ROM_API_OKAY) {
- puts("ROMAPI: failure at query_boot_info\n");
- return -1;
- }
+ ret = rom_api_query_boot_infor(QUERY_BT_STAGE, );
+ if (ret != ROM_API_OKAY)
+ goto err;
printf("Boot Stage: ");
@@ -374,4 +381,7 @@ int board_return_to_bootrom(struct spl_image_info *spl_image,
return spl_romapi_load_image_stream(spl_image, bootdev);
return spl_romapi_load_image_seekable(spl_image, bootdev, boot);
+err:
+ puts("ROMAPI: failure at query_boot_info\n");
+ return -1;
}
Re: [PATCH u-boot 0/3] Revert broken Bootmenu commits
On Sun, Jun 25, 2023 at 05:15:34PM +0200, Pali Rohár wrote: > On Sunday 25 June 2023 10:52:13 Tom Rini wrote: > > On Sun, Jun 25, 2023 at 09:50:39AM +0200, Pali Rohár wrote: > > > On Saturday 24 June 2023 12:58:07 Tom Rini wrote: > > > > On Sat, Jun 24, 2023 at 10:50:41AM +0200, Pali Rohár wrote: > > > > > On Tuesday 20 June 2023 11:20:35 Simon Glass wrote: > > > > > > Hi Tom, Pali, > > > > > > > > > > > > On Wed, 14 Jun 2023 at 20:51, Tom Rini wrote: > > > > > > > > > > > > > > On Sun, Jun 11, 2023 at 02:53:21PM +0200, Pali Rohár wrote: > > > > > > > > > > > > > > > These 3 commits broke support for U-Boot Bootmenu on Nokia N900. > > > > > > > > Issues were reported more than month ago, but nobody reacted to > > > > > > > > them. > > > > > > > > So revert these broken commits for now, to fix U-Boot Bootmenu > > > > > > > > support. > > > > > > > > > > > > > > > > With these revered commits, U-Boot Bootmenu from master branch > > > > > > > > is > > > > > > > > working fine again on Nokia N900. > > > > > > > > > > > > > > > > Pali Rohár (3): > > > > > > > > Revert "video: Enable VIDEO_ANSI by default only with EFI" > > > > > > > > Revert "menu: Factor out menu-keypress decoding" > > > > > > > > Revert "menu: Make use of CLI character processing" > > > > > > > > > > > > > > > > cmd/bootmenu.c| 9 ++-- > > > > > > > > cmd/eficonfig.c | 12 ++--- > > > > > > > > common/cli_getch.c| 12 ++--- > > > > > > > > common/menu.c | 122 > > > > > > > > ++ > > > > > > > > drivers/video/Kconfig | 7 +-- > > > > > > > > include/cli.h | 4 +- > > > > > > > > include/menu.h| 17 +- > > > > > > > > 7 files changed, 91 insertions(+), 92 deletions(-) > > > > > > > > > > > > > > Following up over here, while > > > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20230612201434.861700-1-...@chromium.org/ > > > > > > > addresses some of the issues, but not all (as it clearly isn't > > > > > > > working > > > > > > > in all of the cases Pali has explained), looking in to the > > > > > > > VIDEO_ANSI > > > > > > > part of this too, all three of these reverts are related > > > > > > > seemingly to > > > > > > > something escape-character related. I'm not taking any of the > > > > > > > revert > > > > > > > commits in just yet, but will by the next -rc if we don't have > > > > > > > something > > > > > > > that fixes all of the issues. > > > > > > > > > > > > I did send a series [1] with a fix for the nokia_rx51 keyboard > > > > > > driver, > > > > > > including the previous ansi-code patch. Given that: > > > > > > > > > > > > - this problem doesn't seem to manifest on other boards > > > > > > - it does not cause any CI test to fail > > > > > > - there seem to be bugs in the nokia_rx51 implementation which are a > > > > > > possible/likely cause > > > > > > - the nokia_rx51 CI uses a 10-year-old out-of-tree QEMU > > > > > > - the problem goes away if debugging is added, suggesting it is > > > > > > related to timing > > > > > > > > > > > > ...I don't think a revert is appropriate. > > > > > > > > > > Unfortunately it does not fix this issue :-( New patch series from [1] > > > > > applied on top of the master branch has still issue with DOWN key on > > > > > emulated UART terminal. > > > > > > > > > > > Pali, can you please take a look and see if you can debug what is > > > > > > actually going on? Here is my guess: > > > > > > > > > > > > 1. When an arrow key is pressed, cli_ch_process() handles it by > > > > > > being > > > > > > passed the codes in sequence: \e [ B > > > > > > 2. Calling cli_ch_process() with ichar = 0 causes it to think the > > > > > > sequence is finished: \e [ \0 B (this doesn't work since the \0 > > > > > > ends > > > > > > the sequence) > > > > > > 3. nokia_rx51 keyboard driver is returning '\0' even when key codes > > > > > > are pending, causing cli_ch_process() to be told that the sequence > > > > > > is > > > > > > done > > > > > > > > > > I can look at it later, but I'm loosing motivation to do whole > > > > > debugging > > > > > for another issue again, because for the last year my fixes and other > > > > > patches were stalled and u-boot devs show me that they are not > > > > > interested even in commenting them. I do not want to work again on > > > > > something which would be ignored. > > > > > > > > Well, unless your changes here break something else, I don't think a fix > > > > for your problem will be ignored. > > > > > > This is something which I read here more times in the past... and > > > reality was different. > > > > > > Should I remind you that there are waiting eMMC fixes for mvebu and > > > again discussion about them stalled? Or rather should I say that it is > > > again ignored? > > > > No, you should just say they're still waiting for review. Since they're > > waiting for review. The MMC custodian has been asked to review them, and > > hasn't yet.
Re: [PATCH v2 0/7] Enable DM_SERIAL for the LS104xA RDB/FRWY boards
On 6/16/2023 9:18 PM, Camelia Groza wrote: This series enables DM_SERIAL for ls1043ardb, ls1046ardb and ls1046afrwy. First, the device tree serial nodes are synced with their counterpart descriptions in Linux v6.3. Secondly, the serial nodes are tagged with 'bootph-all' to guarantee the drivers are initialized before relocation. New board specific *-u-boot.dtsi files are created to store these properties. We do this in order to keep serial node descriptions in sync with Linux. Lastly, CONFIG_DM_SERIAL is enabled in the relevant defconfigs. For the patchset, Reviewed-by: Peng Fan Changes in v2: - mention the Linux kernel version the serial nodes are synced with in 1/7 and 4/7 - create *-u-boot.dtsi files to store u-boot specific dts properties in 2/7 and 5/7 - pick up the status properties of the serial nodes from Linux in 4/7 Camelia Groza (7): arch: arm: dts: ls1043a: sync serial nodes with Linux arch: arm: dts: ls1043a: tag serial nodes with bootph-all configs: ls1043ardb: enable DM_SERIAL arch: arm: dts: ls1046a: sync serial nodes with Linux arch: arm: dts: ls1046a: tag serial nodes with bootph-all configs: ls1046ardb: enable DM_SERIAL configs: ls1046afrwy: enable DM_SERIAL arch/arm/dts/fsl-ls1043a-qds.dtsi | 2 +- arch/arm/dts/fsl-ls1043a-rdb-u-boot.dtsi | 5 arch/arm/dts/fsl-ls1043a-rdb.dts | 6 +++- arch/arm/dts/fsl-ls1043a-u-boot.dtsi | 19 + arch/arm/dts/fsl-ls1043a.dtsi | 16 +++ arch/arm/dts/fsl-ls1046a-frwy-u-boot.dtsi | 5 arch/arm/dts/fsl-ls1046a-frwy.dts | 22 ++- arch/arm/dts/fsl-ls1046a-qds.dtsi | 2 +- arch/arm/dts/fsl-ls1046a-rdb-u-boot.dtsi | 5 arch/arm/dts/fsl-ls1046a-rdb.dts | 14 +- arch/arm/dts/fsl-ls1046a-u-boot.dtsi | 19 + arch/arm/dts/fsl-ls1046a.dtsi | 28 +-- configs/ls1043ardb_SECURE_BOOT_defconfig | 4 ++- configs/ls1043ardb_defconfig | 4 ++- configs/ls1043ardb_nand_SECURE_BOOT_defconfig | 4 ++- configs/ls1043ardb_nand_defconfig | 3 +- .../ls1043ardb_sdcard_SECURE_BOOT_defconfig | 4 ++- configs/ls1043ardb_sdcard_defconfig | 3 +- configs/ls1043ardb_tfa_SECURE_BOOT_defconfig | 4 ++- configs/ls1043ardb_tfa_defconfig | 4 ++- configs/ls1046afrwy_tfa_SECURE_BOOT_defconfig | 4 ++- configs/ls1046afrwy_tfa_defconfig | 4 ++- configs/ls1046ardb_emmc_defconfig | 3 +- configs/ls1046ardb_qspi_SECURE_BOOT_defconfig | 4 ++- configs/ls1046ardb_qspi_defconfig | 4 ++- configs/ls1046ardb_qspi_spl_defconfig | 3 +- .../ls1046ardb_sdcard_SECURE_BOOT_defconfig | 4 ++- configs/ls1046ardb_sdcard_defconfig | 3 +- configs/ls1046ardb_tfa_SECURE_BOOT_defconfig | 4 ++- configs/ls1046ardb_tfa_defconfig | 4 ++- 30 files changed, 173 insertions(+), 37 deletions(-) create mode 100644 arch/arm/dts/fsl-ls1043a-rdb-u-boot.dtsi create mode 100644 arch/arm/dts/fsl-ls1043a-u-boot.dtsi create mode 100644 arch/arm/dts/fsl-ls1046a-frwy-u-boot.dtsi create mode 100644 arch/arm/dts/fsl-ls1046a-rdb-u-boot.dtsi create mode 100644 arch/arm/dts/fsl-ls1046a-u-boot.dtsi -- 2.17.1
Re: [PATCH] mmc:Remove the legacy mode clock setting operation
On 6/21/2023 11:11 AM, xf_...@163.com wrote:
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
From: xiefei
Due to the need to read the register value before
switching to hs mode, the standard protocol does
not explicitly specify that the setting before
switching to hs mode is in legacy mode. Therefore,
the code at this point may cause communication
abnormalities between the host and card
Signed-off-by: xiefei
---
drivers/mmc/mmc.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
index 1af6af82e6..915f446973 100644
--- a/drivers/mmc/mmc.c
+++ b/drivers/mmc/mmc.c
@@ -2138,7 +2138,6 @@ static int mmc_select_mode_and_width(struct mmc *mmc,
uint card_caps)
mmc_set_card_speed(mmc, MMC_HS, true);
else
#endif
- mmc_set_clock(mmc, mmc->legacy_speed, MMC_CLK_ENABLE);
Has you meet any issues without removing this line? or this is just code
inpsection?
BTW the upper "else" will met issue if you directly remove this line.
Regards,
Peng.
for_each_mmc_mode_by_pref(card_caps, mwt) {
for_each_supported_width(card_caps & mwt->widths,
--
2.17.1
Re: [PATCH v1] LFU-544: Kconfig.nxp: Fixed secure boot on LS-CH2 platforms
On 6/22/2023 5:24 PM, Kshitiz Varshney wrote: pimg64 image pointer is dependent on ESBC_ADDR_64BIT config, which is getting disabled, due to dependency on ESBC_HDR_LS. ESBC_HDR_LS is required for LS-CH3 platforms. So, removing the dependency on ESBC_HDR_LS. Signed-off-by: Kshitiz Varshney Acked-by: Peng Fan
Re: [PATCH] arm: dts: imx8m: add OPTEE_LOAD_ADDRESS config and tee.bin
On 6/23/2023 1:30 AM, Tim Harvey wrote:
Add a Kconfig for OPTEE_LOAD_ADDRESS which adds tee.bin to the
imx8m{m,n,p} FIT image.
Prior to using binman for image creation the presense of tee.bin in the
directory would cause mkimage_fit_atf.sh to add the tee.bin node
to the FIT image. Once boards moved away from using
CONFIG_SPL_FIT_GENERATOR this was lost. This patch restores that
functionality. A Kconfig option is added due to binman not being
able to utilize env variables.
Signed-off-by: Tim Harvey
Reviewed-by: Peng Fan
Re: [PATCH v2] powerpc: Add support for CZ.NIC Turris 1.x routers
On Sun, Jun 25, 2023 at 05:27:49PM +0200, Pali Rohár wrote: > On Saturday 24 June 2023 12:57:46 Tom Rini wrote: > > On Sat, Jun 24, 2023 at 11:19:51AM +0200, Pali Rohár wrote: > > > On Monday 12 June 2023 14:07:24 Tom Rini wrote: > > > > On Wed, Aug 17, 2022 at 10:56:22PM +0200, Pali Rohár wrote: > > > > > > > > > CZ.NIC Turris 1.0 and 1.1 are open source routers, they have dual-core > > > > > PowerPC Freescale P2020 CPU and are based on Freescale P2020RDB-PC-A > > > > > board. > > > > > > > > > > Hardware design is fully open source, all firmware and hardware design > > > > > files are available at Turris project website: > > > > > > > > > > https://docs.turris.cz/hw/turris-1x/turris-1x/ > > > > > https://project.turris.cz/en/hardware.html > > > > > > > > > > This patch adds full U-Boot support for CZ.NIC Turris 1.x routers. > > > > > P2020 > > > > > BootROM can load U-Boot either from NOR flash or from SD card. So > > > > > there is > > > > > defconfig file turris_1x_nor_defconfig which builds NOR version and > > > > > defconfig file turris_1x_sdcard_defconfig which builds SD card > > > > > version. > > > > > > > > > > Design of CZ.NIC Turris 1.x routers is based on Freescale > > > > > P2020RDB-PC-A > > > > > board, so common board code from boards/freescale/p1_p2_rdb_pc > > > > > directory is > > > > > shared and linked also into Turris 1.x U-Boot board code. > > > > > > > > > > Turris 1.x code in this patch uses modern distroboot and can boot > > > > > Linux > > > > > kernel from various locations, including NAND, SD card, USB flash > > > > > disks, > > > > > NVMe disks or SATA disks (connected to extra SATA/SCSI PCIe > > > > > controllers). > > > > > > > > > > Signed-off-by: Pali Rohár > > > > > > > > To be clear, this is something that if there's still interest in > > > > upstreaming this platform, this patch needs to be rebased and re-tested > > > > as it's non-trivially out of date. In addition: > > > > > > Meanwhile I have already done rebase and retest, v3 is here: > > > https://patchwork.ozlabs.org/project/uboot/patch/20220831164821.29109-1-p...@kernel.org/ > > > > Yes, and I replied to that with feedback. > > Seems that there is no feeback on above patch. Well, you're right, everything that is in this thread, and still applies right now is I guess in the v2 thread instead? -- Tom signature.asc Description: PGP signature
Re: [PATCH] arm: dts: imx8m: move CAAM nodes into common u-boot.dtsi
On 6/23/2023 2:52 AM, Tim Harvey wrote: Move the crypto and sec_jr* nodes from board-specific u-boot.dtsi files into the common files. Additionally protect the nodes with ifdef FSL_CAAM as they don't serve any purpose if that is not enabled. Signed-off-by: Tim Harvey Reviewed-by: Peng Fan
Re: [PATCH] board: gateworks: venice: switch to 2-bank dram config
On 6/24/2023 12:44 AM, Tim Harvey wrote: Switch to a 2-bank dram config to properly support 4GiB. Signed-off-by: Tim Harvey Reviewed-by: Peng Fan
Re: [PATCH] configs: imx8m: Prepare imx8m-venice boards for HAB support
On 6/24/2023 12:44 AM, Tim Harvey wrote: In order to enable HAB, FSL_CAAM, ARCH_MISC_INIT and SPL_CRYPTO should be enabled in Kconfig like other i.MX8M boards. This also needs to occur in the SPL so enable CONFIG_SPL_BOARD_INIT and add a void spl_board_init function which calls arch_misc_init to probe the CAAM driver. Signed-off-by: Tim Harvey Reviewed-by: Peng Fan
Re: imx8m optee load address?
On 6/21/2023 7:04 AM, Tim Harvey wrote:
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 Mon, Jun 19, 2023 at 1:40 PM Tim Harvey wrote:
On Fri, Jun 16, 2023 at 4:52 PM Tim Harvey wrote:
On Thu, Jun 15, 2023 at 8:31 PM Peng Fan wrote:
On 6/16/2023 9:56 AM, Tim Harvey wrote:
Greetings,
I've seen several IMX8M boards include a firmware/optee node in the
U-Boot dt (git grep optee arch/arm/dts/imx8m*.dtsi) yet but none that
I see configure binman to actually add the binary in the u-boot.dtsi,
do anything to keep U-Boot from accessing the OPTEE memory, or
document how to configure and build OPTEE for imx8m. I would like to
add such support but I find it odd that OPTEE needs to be built
differently depending on the dram size.
Prior to switching to binman (v2021.10)
arch/arm/mach-imx/mkimage_fit_atf.sh [1] would include tee.bin in the
FIT image if it was found in the current directory and it was expected
that you provide a proper TEE_LOAD_ADDR via the env (commit
a9eed6e1b8d8 ("imx: imx8m: introduce script to generate fit image").
According to the IMX OPTEE documentation [2] the size and location of
OPTEE is hard coded (CFG_TZDRAM_START and CFG_TZDRAM_SIZE) but looking
at the imx-optee source [3] this is calculated based off of
CFG_DDR_SIZE (which you can provide via env at build time or just
provide CFG_TZDRAM_START and CFG_TZDRAM_SIZE via env directly).
optee does not support PIE, it could only run at the address that built
time defined.
Hi Peng,
I wasn't thinking about PIE but just building it at a location other
than the top of DRAM in order to come up with a generalized location
instead of having to customize u-boot.dtsi for different RAM sizes and
to workaround the 4GiB boundary issue.
If my understanding is correct optee's load address needs to match between:
1. atf: BL32_BASE at build time defines the address in secure memory
where BL2 loads the BL32 binary image (tee.bin) (must be aligned on a
page-size boundary)
2. optee: CFG_TZDRAM_START at build time (calculated based off of
CFG_DDR_SIZE) defines the address it is built to run at. Note you must
still define CFG_DDR_SIZE properly as this is passed to
imx_tzc_auto_configure()
3. uboot: tee.bin is contained in u-boot.itb FIT image and specifies
the address that U-Boot SPL loads tee.bin into
I'm really trying to understand the imx8m 4GiB limit issue as that
seems to be a huge limiation.
Peng,
I've made good progress and now have a 4GiB imx8mm board working with
optee (with 1 hack):
On an imx8mm board with 4GiB of DRAM configured with
atf:BL32_BASE=0x13e00
optee:CFG_DDR_SIZE=0x1,CFG_TZDRAM_START=0x13e00 and
u-boot.dtsi tee.bin load/entry=<0x1 0x3e00> we get this:
U-Boot SPL 2023.04-00027-g578c653cbafa (Jun 16 2023 - 09:22:40 -0700)
GSCv3 : v58 0xf098 RST:VIN Thermal protection:disabled
RTC : 1970-01-01 0:05:40 UTC
Model : GW7201-01-EB
Serial : 852455
MFGDate : 11-10-2020
PMIC: MP5416 (IMX8MM)
DRAM: LPDDR4 4 GiB 3000MT/s 1500MHz
WDT: Started watchdog@3028 with servicing every 1000ms (60s timeout)
Trying to boot from eMMC
DTB : imx8mm-venice-gw72xx-0x
Cannot use 64 bit addresses with SDMA
^^^ This is the imx mmc driver warning that it can't load data into
dram across 32bit boundary
Authenticate image from DDR location 0x401fcdc0...
NOTICE: Do not release JR0 to NS as it can be used by HAB
ERROR: mmap_add_region_check() failed. error -34
ASSERT: lib/xlat_tables_v2/xlat_tables_core.c:793
BACKTRACE: START: assert
0: EL3: 0x9289cc
1: EL3: 0x929efc
2: EL3: 0x92469c
3: EL3: 0x9248f4
4: EL3: 0x928850
5: EL3: 0x927594
6: EL3: 0x920128
7: EL3: 0x7eb19c
8: EL3: 0x7f3de0
BACKTRACE: END: assert
This is where the atf jumps to optee so I can understand why the above
doesn't work as U-Boot can't load tee.bin from the FIT to 0x13e00
(not sure where it gets loaded... the 64bit address probably wraps).
I've also tried setting CFG_CORE_LARGE_PHYS_ADDR=y and
CFG_CORE_ARM64_PA_BITS=36 in optee as this is what the imx8mp-evk
config with 6GiB does and it ended with the same result but I do
notice that doing this changes the link address
The issue above appears to be a result of not setting
CFG_CORE_LARGE_PHYS_ADDR=y and CFG_CORE_ARM64_PA_BITS=36 in optee when
CFG_DDR_SIZE exceeds 3GiB.
The imx8mp-evk has 6GiB of dram on it. Does NXP not have a solution
for secure boot on boards with >3GiB of dram? Is there some support
in their downstream U-Boot that I'm maybe missing? Personally I can't
even get NXP's lf_v2022.04 u-boot branch to build flash.bin for
imx8mp_evk so I can try it out.
The optee configuration for imx8mp-evk in
core/arch/arm/plat-imx/conf.mk is misleading as it does not override
the default for CFG_TZDRAM_START which will get defaulted to above a
32bit address boundary and won't work. Instead it should set it below
the 32bit address boundary in
[PATCH 1/1] README: remove Minicom comment
The main README file is the wrong place to document how different terminal
emulations can be used to access the U-Boot serial console. C-Kermit which
requires a configuration file or several commands to access the U-Boot
console may not be the preferred choice for newcomers. The provided wiki
link is invalid.
The man-pages for loadb and loads already show how to use the commands with
picocom.
Signed-off-by: Heinrich Schuchardt
---
README | 21 -
1 file changed, 21 deletions(-)
diff --git a/README b/README
index bbf96e64c8..15a19caf74 100644
--- a/README
+++ b/README
@@ -2430,27 +2430,6 @@ Hit 'q':
[q, b, e, ?] ## Application terminated, rc = 0x0
-Minicom warning:
-
-
-Over time, many people have reported problems when trying to use the
-"minicom" terminal emulation program for serial download. I (wd)
-consider minicom to be broken, and recommend not to use it. Under
-Unix, I recommend to use C-Kermit for general purpose use (and
-especially for kermit binary protocol download ("loadb" command), and
-use "cu" for S-Record download ("loads" command). See
-https://www.denx.de/wiki/view/DULG/SystemSetup#Section_4.3.
-for help with kermit.
-
-
-Nevertheless, if you absolutely want to use it try adding this
-configuration to your "File transfer protocols" section:
-
- NameProgram Name U/D FullScr IO-Red. Multi
- X kermit /usr/bin/kermit -i -l %l -s YUY N N
- Y kermit /usr/bin/kermit -i -l %l -r NDY N N
-
-
Implementation Internals:
=
--
2.40.1
[PATCH 1/1] cmd: loads man-page
Provide a man-page for the loads command. Signed-off-by: Heinrich Schuchardt --- doc/usage/cmd/loads.rst | 96 + doc/usage/index.rst | 1 + 2 files changed, 97 insertions(+) create mode 100644 doc/usage/cmd/loads.rst diff --git a/doc/usage/cmd/loads.rst b/doc/usage/cmd/loads.rst new file mode 100644 index 00..5dd0ed70b6 --- /dev/null +++ b/doc/usage/cmd/loads.rst @@ -0,0 +1,96 @@ +.. SPDX-License-Identifier: GPL-2.0+: + +loads command += + +Synopsis + + +:: + +loads [offset [baud]] + +Description +--- + +The loads command is used to transfer a file to the device via the serial line +using the Motorola S-record file format. + +offset +offset added to the addresses in the S-record file + +baud +baud rate to use for download. This parameter is only available if +CONFIG_SYS_LOADS_BAUD_CHANGE=y + +Example +--- + +As example file to be transferred we use a script printing 'hello s-record'. +Here are the commands to create the S-record file: + +.. code-block:: bash + +$ echo 'echo hello s-record' > script.txt +$ mkimage -T script -d script.txt script.scr +Image Name: +Created: Sun Jun 25 10:35:02 2023 +Image Type: PowerPC Linux Script (gzip compressed) +Data Size:28 Bytes = 0.03 KiB = 0.00 MiB +Load Address: +Entry Point: +Contents: + Image 0: 20 Bytes = 0.02 KiB = 0.00 MiB +$ srec_cat script.scr -binary -CRLF -Output script.srec +$ echo -e "S903FC\r" >> script.srec +$ cat script.srec +S022687474703A2F2F737265636F72642E736F75726365666F7267652E6E65742F1D +S123270519566D773EB6649815E300173DE3D97005070601E2 +S1230020BC +S11A004F68656C6C6F20732D7265636F72640A39 +S5030003F9 +S903FC +$ + +The load address in the first S1 record is 0x. + +The terminal emulation program picocom is invoked with *cat* as the send +command to transfer the file. + +.. code-block:: + +picocom --send-cmd 'cat' --baud 115200 /dev/ttyUSB0 + +After entering the *loads* command the key sequence is used to +let picocom prompt for the file name. Picocom invokes the program *cat* for the +file transfer. The loaded script is executed using the *source* command. + +.. code-block:: + +=> loads $scriptaddr +## Ready for S-Record download ... + +*** file: script.srec +$ cat script.srec + +*** exit status: 0 *** + +## First Load Addr = 0x4FC0 +## Last Load Addr = 0x4FC0005B +## Total Size = 0x005C = 92 Bytes +## Start Addr = 0x +=> source $scriptaddr +## Executing script at 4fc0 +hello s-record +=> + +Configuration +- + +The command is only available if CONFIG_CMD_LOADS=y. The parameter to set the +baud rate is only available if CONFIG_SYS_LOADS_BAUD_CHANGE=y + +Return value + + +The return value $? is 0 (true) on success, 1 (false) otherwise. diff --git a/doc/usage/index.rst b/doc/usage/index.rst index 29ae8a176e..ef3e87fed0 100644 --- a/doc/usage/index.rst +++ b/doc/usage/index.rst @@ -68,6 +68,7 @@ Shell commands cmd/load cmd/loadb cmd/loadm + cmd/loads cmd/loadx cmd/loady cmd/mbr -- 2.40.1
[PATCH 1/1] doc: fix typo loady in loadb man-page
%s/loady/loadb/ Signed-off-by: Heinrich Schuchardt --- doc/usage/cmd/loadb.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/usage/cmd/loadb.rst b/doc/usage/cmd/loadb.rst index b37d1d7b59..0464b1f41c 100644 --- a/doc/usage/cmd/loadb.rst +++ b/doc/usage/cmd/loadb.rst @@ -13,7 +13,7 @@ Synopsis Description --- -The loady command is used to transfer a file to the device via the serial line +The loadb command is used to transfer a file to the device via the serial line using the Kermit protocol. The number of transferred bytes is saved in environment variable filesize. -- 2.40.1
[PATCH 5/5] MAINTAINERS: add myself as mcf_wdt.c maintainer
Signed-off-by: Angelo Dureghello --- MAINTAINERS | 1 + 1 file changed, 1 insertion(+) diff --git a/MAINTAINERS b/MAINTAINERS index 228d8af433..59d011ffcf 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -865,6 +865,7 @@ S: Maintained T: git https://source.denx.de/u-boot/custodians/u-boot-coldfire.git F: arch/m68k/ F: doc/arch/m68k.rst +F: drivers/watchdog/mcf_wdt.c CYCLIC M: Stefan Roese -- 2.41.0
[PATCH 4/5] configs: m68k: add watchdog driver
Add config options for mcf_wdt driver. Signed-off-by: Angelo Dureghello --- configs/M5208EVBE_defconfig | 2 ++ configs/astro_mcf5373l_defconfig | 4 ++-- configs/eb_cpu5282_defconfig | 1 + configs/eb_cpu5282_internal_defconfig | 1 + 4 files changed, 6 insertions(+), 2 deletions(-) diff --git a/configs/M5208EVBE_defconfig b/configs/M5208EVBE_defconfig index 0c5afe869b..aa054f753f 100644 --- a/configs/M5208EVBE_defconfig +++ b/configs/M5208EVBE_defconfig @@ -50,3 +50,5 @@ CONFIG_MCFFEC=y CONFIG_MII=y CONFIG_MCFUART=y CONFIG_WATCHDOG_TIMEOUT_MSECS=5000 +CONFIG_WDT=y +CONFIG_WDT_MCF=y diff --git a/configs/astro_mcf5373l_defconfig b/configs/astro_mcf5373l_defconfig index aade1f98be..f4dad3bcc8 100644 --- a/configs/astro_mcf5373l_defconfig +++ b/configs/astro_mcf5373l_defconfig @@ -46,5 +46,5 @@ CONFIG_DM_RTC=y CONFIG_MCFRTC=y CONFIG_SYS_MCFRTC_BASE=0xFC0A8000 CONFIG_MCFUART=y -CONFIG_WATCHDOG=y -CONFIG_WATCHDOG_TIMEOUT_MSECS=3355 +CONFIG_WDT=y +CONFIG_WDT_MCF=y diff --git a/configs/eb_cpu5282_defconfig b/configs/eb_cpu5282_defconfig index 24edecb510..2873322598 100644 --- a/configs/eb_cpu5282_defconfig +++ b/configs/eb_cpu5282_defconfig @@ -52,3 +52,4 @@ CONFIG_MII=y CONFIG_DM_RTC=y CONFIG_RTC_DS1338=y CONFIG_MCFUART=y +CONFIG_WDT=y diff --git a/configs/eb_cpu5282_internal_defconfig b/configs/eb_cpu5282_internal_defconfig index 44e22eb01d..bd780034ba 100644 --- a/configs/eb_cpu5282_internal_defconfig +++ b/configs/eb_cpu5282_internal_defconfig @@ -50,3 +50,4 @@ CONFIG_MII=y CONFIG_DM_RTC=y CONFIG_RTC_DS1338=y CONFIG_MCFUART=y +CONFIG_WDT=y -- 2.41.0
[PATCH 3/5] m68k: dts: add watchdog node
Add watchdog node for the implemented mcf_wdt driver.
Signed-off-by: Angelo Dureghello
---
arch/m68k/dts/M5208EVBE.dts | 5 +
arch/m68k/dts/mcf5208.dtsi | 7 +++
arch/m68k/dts/mcf523x.dtsi | 7 +++
arch/m68k/dts/mcf5271.dtsi | 7 +++
arch/m68k/dts/mcf5275.dtsi | 7 +++
arch/m68k/dts/mcf5282.dtsi | 7 +++
arch/m68k/dts/mcf5329.dtsi | 7 +++
arch/m68k/dts/mcf537x.dtsi | 7 +++
8 files changed, 54 insertions(+)
diff --git a/arch/m68k/dts/M5208EVBE.dts b/arch/m68k/dts/M5208EVBE.dts
index 1c32718af4..ec203e8b69 100644
--- a/arch/m68k/dts/M5208EVBE.dts
+++ b/arch/m68k/dts/M5208EVBE.dts
@@ -15,6 +15,11 @@
};
};
+ {
+ timeout-sec = <32>;
+ status = "okay";
+};
+
{
bootph-all;
status = "okay";
diff --git a/arch/m68k/dts/mcf5208.dtsi b/arch/m68k/dts/mcf5208.dtsi
index 9392facfa8..b06dc4bb26 100644
--- a/arch/m68k/dts/mcf5208.dtsi
+++ b/arch/m68k/dts/mcf5208.dtsi
@@ -16,6 +16,13 @@
#address-cells = <1>;
#size-cells = <1>;
+ wdog0: watchdog@fc08c000 {
+ compatible = "fsl,mcf5208-wdt";
+ reg = <0xfc08c000 0x10>;
+ big-endian;
+ status = "disabled";
+ };
+
uart0: uart@fc06 {
compatible = "fsl,mcf-uart";
reg = <0xfc06 0x40>;
diff --git a/arch/m68k/dts/mcf523x.dtsi b/arch/m68k/dts/mcf523x.dtsi
index 41c7b9b2d1..fb5a4cdc21 100644
--- a/arch/m68k/dts/mcf523x.dtsi
+++ b/arch/m68k/dts/mcf523x.dtsi
@@ -23,6 +23,13 @@
ranges = <0x 0x4000 0x4000>;
reg = <0x4000 0x4000>;
+ wdog0: watchdog@14 {
+ compatible = "fsl,mcf5208-wdt";
+ reg = <0x14 0x10>;
+ big-endian;
+ status = "disabled";
+ };
+
uart0: uart@200 {
compatible = "fsl,mcf-uart";
reg = <0x200 0x40>;
diff --git a/arch/m68k/dts/mcf5271.dtsi b/arch/m68k/dts/mcf5271.dtsi
index fc82bd3c24..0884c13ab1 100644
--- a/arch/m68k/dts/mcf5271.dtsi
+++ b/arch/m68k/dts/mcf5271.dtsi
@@ -23,6 +23,13 @@
ranges = <0x 0x4000 0x4000>;
reg = <0x4000 0x4000>;
+ wdog0: watchdog@14 {
+ compatible = "fsl,mcf5208-wdt";
+ reg = <0x14 0x10>;
+ big-endian;
+ status = "disabled";
+ };
+
uart0: uart@200 {
compatible = "fsl,mcf-uart";
reg = <0x200 0x40>;
diff --git a/arch/m68k/dts/mcf5275.dtsi b/arch/m68k/dts/mcf5275.dtsi
index 402517cdec..78210569da 100644
--- a/arch/m68k/dts/mcf5275.dtsi
+++ b/arch/m68k/dts/mcf5275.dtsi
@@ -24,6 +24,13 @@
ranges = <0x 0x4000 0x4000>;
reg = <0x4000 0x4000>;
+ wdog0: watchdog@14 {
+ compatible = "fsl,mcf5208-wdt";
+ reg = <0x14 0x10>;
+ big-endian;
+ status = "disabled";
+ };
+
uart0: uart@200 {
compatible = "fsl,mcf-uart";
reg = <0x200 0x40>;
diff --git a/arch/m68k/dts/mcf5282.dtsi b/arch/m68k/dts/mcf5282.dtsi
index 883c0d0324..40704c5202 100644
--- a/arch/m68k/dts/mcf5282.dtsi
+++ b/arch/m68k/dts/mcf5282.dtsi
@@ -23,6 +23,13 @@
ranges = <0x 0x4000 0x4000>;
reg = <0x4000 0x4000>;
+ wdog0: watchdog@14 {
+ compatible = "fsl,mcf5282-wdt";
+ reg = <0x14 0x10>;
+ big-endian;
+ status = "disabled";
+ };
+
uart0: uart@200 {
compatible = "fsl,mcf-uart";
reg = <0x200 0x40>;
diff --git a/arch/m68k/dts/mcf5329.dtsi b/arch/m68k/dts/mcf5329.dtsi
index 7501cc4b01..50ff73bca7 100644
--- a/arch/m68k/dts/mcf5329.dtsi
+++ b/arch/m68k/dts/mcf5329.dtsi
@@ -16,6 +16,13 @@
#address-cells = <1>;
#size-cells = <1>;
+ wdog0: watchdog@fc098000 {
+ compatible = "fsl,mcf5208-wdt";
+ reg = <0xfc08c000 0x10>;
+ big-endian;
+ status = "disabled";
+
[PATCH 2/5] m68k: move watchdog functions in mcf_wdt driver
Move watchdog functions inside a separate watchdog driver.
Signed-off-by: Angelo Dureghello
---
arch/m68k/cpu/mcf523x/cpu.c | 42 -
arch/m68k/cpu/mcf52x2/cpu.c | 47 +
arch/m68k/cpu/mcf532x/cpu.c | 44 --
3 files changed, 1 insertion(+), 132 deletions(-)
diff --git a/arch/m68k/cpu/mcf523x/cpu.c b/arch/m68k/cpu/mcf523x/cpu.c
index ba2c228911..bef67767b4 100644
--- a/arch/m68k/cpu/mcf523x/cpu.c
+++ b/arch/m68k/cpu/mcf523x/cpu.c
@@ -12,7 +12,6 @@
#include
#include
#include
-#include
#include
#include
#include
@@ -62,47 +61,6 @@ int print_cpuinfo(void)
};
#endif /* CONFIG_DISPLAY_CPUINFO */
-#if defined(CONFIG_WATCHDOG)
-/* Called by macro WATCHDOG_RESET */
-void watchdog_reset(void)
-{
- wdog_t *wdp = (wdog_t *) (MMAP_WDOG);
-
- /* Count register */
- out_be16(>sr, 0x);
- asm("nop");
- out_be16(>sr, 0x);
-}
-
-int watchdog_disable(void)
-{
- wdog_t *wdp = (wdog_t *) (MMAP_WDOG);
-
- /* UserManual, once the wdog is disabled, wdog cannot be re-enabled */
- /* halted watchdog timer */
- setbits_be16(>cr, WTM_WCR_HALTED);
-
- puts("WATCHDOG:disabled\n");
- return (0);
-}
-
-int watchdog_init(void)
-{
- wdog_t *wdp = (wdog_t *) (MMAP_WDOG);
- u32 wdog_module = 0;
-
- /* set timeout and enable watchdog */
- wdog_module = ((CFG_SYS_CLK / CONFIG_SYS_HZ) *
CONFIG_WATCHDOG_TIMEOUT_MSECS);
- wdog_module |= (wdog_module / 8192);
- out_be16(>mr, wdog_module);
-
- out_be16(>cr, WTM_WCR_EN);
- puts("WATCHDOG:enabled\n");
-
- return (0);
-}
-#endif /* CONFIG_WATCHDOG */
-
#if defined(CONFIG_MCFFEC)
/* Default initializations for MCFFEC controllers. To override,
* create a board-specific function called:
diff --git a/arch/m68k/cpu/mcf52x2/cpu.c b/arch/m68k/cpu/mcf52x2/cpu.c
index d7cbf11e25..5042a38b3e 100644
--- a/arch/m68k/cpu/mcf52x2/cpu.c
+++ b/arch/m68k/cpu/mcf52x2/cpu.c
@@ -17,7 +17,6 @@
#include
#include
#include
-#include
#include
#include
#include
@@ -53,51 +52,7 @@ int print_cpuinfo(void)
return 0;
};
#endif /* CONFIG_DISPLAY_CPUINFO */
-
-#if defined(CONFIG_WATCHDOG)
-/* Called by macro WATCHDOG_RESET */
-void watchdog_reset(void)
-{
- wdog_t *wdt = (wdog_t *)(MMAP_WDOG);
-
- out_be16(>sr, 0x);
- out_be16(>sr, 0x);
-}
-
-int watchdog_disable(void)
-{
- wdog_t *wdt = (wdog_t *)(MMAP_WDOG);
-
- /* reset watchdog counter */
- out_be16(>sr, 0x);
- out_be16(>sr, 0x);
- /* disable watchdog timer */
- out_be16(>cr, 0);
-
- puts("WATCHDOG:disabled\n");
- return (0);
-}
-
-int watchdog_init(void)
-{
- wdog_t *wdt = (wdog_t *)(MMAP_WDOG);
-
- /* disable watchdog */
- out_be16(>cr, 0);
-
- /* set timeout and enable watchdog */
- out_be16(>mr,
- (CONFIG_WATCHDOG_TIMEOUT_MSECS * CONFIG_SYS_HZ) / (32768 *
1000) - 1);
-
- /* reset watchdog counter */
- out_be16(>sr, 0x);
- out_be16(>sr, 0x);
-
- puts("WATCHDOG:enabled\n");
- return (0);
-}
-#endif /* #ifdef CONFIG_WATCHDOG */
-#endif /* #ifdef CONFIG_M5208 */
+#endif /* #ifdef CONFIG_M5208 */
#ifdef CONFIG_M5271
#if defined(CONFIG_DISPLAY_CPUINFO)
diff --git a/arch/m68k/cpu/mcf532x/cpu.c b/arch/m68k/cpu/mcf532x/cpu.c
index 548cbca36a..18d20a8926 100644
--- a/arch/m68k/cpu/mcf532x/cpu.c
+++ b/arch/m68k/cpu/mcf532x/cpu.c
@@ -12,7 +12,6 @@
#include
#include
#include
-#include
#include
#include
#include
@@ -102,49 +101,6 @@ int print_cpuinfo(void)
};
#endif /* CONFIG_DISPLAY_CPUINFO */
-#if defined(CONFIG_WATCHDOG)
-/* Called by macro WATCHDOG_RESET */
-void watchdog_reset(void)
-{
- wdog_t *wdp = (wdog_t *) (MMAP_WDOG);
-
- /* Count register */
- out_be16(>sr, 0x);
- out_be16(>sr, 0x);
-}
-
-int watchdog_disable(void)
-{
- wdog_t *wdp = (wdog_t *) (MMAP_WDOG);
-
- /* UserManual, once the wdog is disabled, wdog cannot be re-enabled */
- /* halted watchdog timer */
- setbits_be16(>cr, WTM_WCR_HALTED);
-
- puts("WATCHDOG:disabled\n");
- return (0);
-}
-
-int watchdog_init(void)
-{
- wdog_t *wdp = (wdog_t *) (MMAP_WDOG);
- u32 wdog_module = 0;
-
- /* set timeout and enable watchdog */
- wdog_module = ((CFG_SYS_CLK / 1000) * CONFIG_WATCHDOG_TIMEOUT_MSECS);
-#ifdef CONFIG_M5329
- out_be16(>mr, wdog_module / 8192);
-#else
- out_be16(>mr, wdog_module / 4096);
-#endif
-
- out_be16(>cr, WTM_WCR_EN);
- puts("WATCHDOG:enabled\n");
-
- return (0);
-}
-#endif /* CONFIG_WATCHDOG */
-
#if defined(CONFIG_MCFFEC)
/* Default initializations for MCFFEC controllers. To override,
* create a board-specific function called:
--
[PATCH 1/5] drivers: watchdog: add mcf watchdog support
This watchdog driver applies to the following
mcf families:
- mcf52x2 (5271 5275 5282)
- mcf532x (5329 5373)
- mcf523x (5235)
Cpu's not listed for each family does not have WDT module.
Note, after some attempts testing by qemu on 5208 i
finally abandoned, watchdog seems not implemented properly.
The driver has been tested in a real M5282EVM.
Signed-off-by: Angelo Dureghello
---
drivers/watchdog/Kconfig | 7 ++
drivers/watchdog/Makefile | 1 +
drivers/watchdog/mcf_wdt.c | 162 +
3 files changed, 170 insertions(+)
create mode 100644 drivers/watchdog/mcf_wdt.c
diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index 646663528a..07fc4940e9 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -178,6 +178,13 @@ config WDT_MAX6370
help
Select this to enable max6370 watchdog timer.
+config WDT_MCF
+ bool "ColdFire family watchdog timer support"
+ depends on WDT
+ help
+ Select this to enable ColdFire watchdog timer,
+ which supports mcf52x2 mcf532x mcf523x families.
+
config WDT_MESON_GXBB
bool "Amlogic watchdog timer support"
depends on WDT
diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
index fd5d9c7376..eef786f5e7 100644
--- a/drivers/watchdog/Makefile
+++ b/drivers/watchdog/Makefile
@@ -31,6 +31,7 @@ obj-$(CONFIG_WDT_CDNS) += cdns_wdt.o
obj-$(CONFIG_WDT_FTWDT010) += ftwdt010_wdt.o
obj-$(CONFIG_WDT_GPIO) += gpio_wdt.o
obj-$(CONFIG_WDT_MAX6370) += max6370_wdt.o
+obj-$(CONFIG_WDT_MCF) += mcf_wdt.o
obj-$(CONFIG_WDT_MESON_GXBB) += meson_gxbb_wdt.o
obj-$(CONFIG_WDT_MPC8xxx) += mpc8xxx_wdt.o
obj-$(CONFIG_WDT_MT7620) += mt7620_wdt.o
diff --git a/drivers/watchdog/mcf_wdt.c b/drivers/watchdog/mcf_wdt.c
new file mode 100644
index 00..03842135c5
--- /dev/null
+++ b/drivers/watchdog/mcf_wdt.c
@@ -0,0 +1,162 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * mcf_wdt.c - driver for ColdFire on-chip watchdog
+ *
+ * Author: Angelo Dureghello
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define TIMEOUT_MAX3360
+#define TIMEOUT_MIN500
+
+#define DIVIDER_5XXX 4096
+#define DIVIDER_5282 8192
+
+#define WCR_EN BIT(0)
+#define WCR_HALTED BIT(1)
+#define WCR_DOZEBIT(2)
+#define WCR_WAITBIT(3)
+
+struct watchdog_regs {
+ u16 wcr;/* Control */
+ u16 wmr;/* Service */
+ u16 wcntr; /* Counter */
+ u16 wsr;/* Reset Status */
+};
+
+#if defined(CONFIG_WDT_MCF)
+static void mcf_watchdog_reset(struct watchdog_regs *wdog)
+{
+#ifndef CONFIG_WATCHDOG_RESET_DISABLE
+ writew(0x, >wsr);
+ writew(0x, >wsr);
+#endif /* CONFIG_WATCHDOG_RESET_DISABLE*/
+}
+
+static void mcf_watchdog_init(struct watchdog_regs *wdog, u32 fixed_divider,
+ u64 timeout_msecs)
+{
+ u32 wdog_module;
+
+ /*
+* The timer watchdog can be set between
+* 0.5 and 128 Seconds.
+*/
+
+ /* set timeout and enable watchdog */
+ wdog_module = ((CFG_SYS_CLK / 1000) * timeout_msecs);
+
+ writew((u16)(wdog_module / fixed_divider), >wmr);
+ writew(WCR_EN, >wcr);
+
+ mcf_watchdog_reset(wdog);
+}
+
+#if !CONFIG_IS_ENABLED(WDT)
+void hw_watchdog_reset(void)
+{
+ struct watchdog_regs *wdog = (struct watchdog_regs *)MMAP_WDOG;
+
+ mcf_watchdog_reset(wdog);
+}
+
+void hw_watchdog_init(void)
+{
+ struct watchdog_regs *wdog = (struct watchdog_regs *)MMAP_WDOG;
+
+ if (IS_ENABLED(CONFIG_MCF5282))
+ writew(>wmr, wdog_module / DIVIDER_5282);
+ else
+ writew(>wmr, wdog_module / DIVIDER_5XXX);
+
+ mcf_watchdog_init(wdog, CONFIG_WATCHDOG_TIMEOUT_MSECS);
+}
+
+#else /* CONFIG_WDT */
+
+struct mcf_wdt_priv {
+ void __iomem *base;
+ u32 fixed_divider;
+};
+
+static int mcf_wdt_expire_now(struct udevice *dev, ulong flags)
+{
+ hang();
+
+ return 0;
+}
+
+static int mcf_wdt_reset(struct udevice *dev)
+{
+ struct mcf_wdt_priv *priv = dev_get_priv(dev);
+
+ mcf_watchdog_reset(priv->base);
+
+ return 0;
+}
+
+static int mcf_wdt_start(struct udevice *dev, u64 timeout, ulong flags)
+{
+ struct mcf_wdt_priv *priv = dev_get_priv(dev);
+
+ /* Timeout from fdt is in second, driver works in msecs */
+ mcf_watchdog_init(priv->base, priv->fixed_divider,
+ timeout * 1000);
+
+ return 0;
+}
+
+static int mcf_wdt_stop(struct udevice *dev)
+{
+ struct mcf_wdt_priv *priv = dev_get_priv(dev);
+ struct watchdog_regs *wdog = (struct watchdog_regs *)priv->base;
+
+ setbits_be16(>wcr, WCR_HALTED);
+
+ return 0;
+}
+
+static int mcf_wdt_probe(struct udevice *dev)
+{
+ struct mcf_wdt_priv *priv = dev_get_priv(dev);
+
+ priv->base = dev_read_addr_ptr(dev);
+ if (!priv->base)
+ return -ENOENT;
+
+
[PATCH 0/5] m68k: add ColdFire watchdog driver
This patch allows to reach 0 warning for the m68k family. Watchdog driver was the last one producing the "conversion to DM" warning, Angelo Dureghello (5): drivers: watchdog: add mcf watchdog support m68k: move watchdog functions in mcf_wdt driver m68k: dts: add watchdog node configs: m68k: add watchdog driver MAINTAINERS: add myself as mcf_wdt.c maintainer MAINTAINERS | 1 + arch/m68k/cpu/mcf523x/cpu.c | 42 --- arch/m68k/cpu/mcf52x2/cpu.c | 47 +--- arch/m68k/cpu/mcf532x/cpu.c | 44 --- arch/m68k/dts/M5208EVBE.dts | 5 + arch/m68k/dts/mcf5208.dtsi| 7 ++ arch/m68k/dts/mcf523x.dtsi| 7 ++ arch/m68k/dts/mcf5271.dtsi| 7 ++ arch/m68k/dts/mcf5275.dtsi| 7 ++ arch/m68k/dts/mcf5282.dtsi| 7 ++ arch/m68k/dts/mcf5329.dtsi| 7 ++ arch/m68k/dts/mcf537x.dtsi| 7 ++ configs/M5208EVBE_defconfig | 2 + configs/astro_mcf5373l_defconfig | 4 +- configs/eb_cpu5282_defconfig | 1 + configs/eb_cpu5282_internal_defconfig | 1 + drivers/watchdog/Kconfig | 7 ++ drivers/watchdog/Makefile | 1 + drivers/watchdog/mcf_wdt.c| 162 ++ 19 files changed, 232 insertions(+), 134 deletions(-) create mode 100644 drivers/watchdog/mcf_wdt.c -- 2.41.0
Re: [PATCH] menu: Re-enable the ANSI codes
Am 25. Juni 2023 17:26:34 MESZ schrieb "Pali Rohár" :
>On Saturday 24 June 2023 13:05:11 Tom Rini wrote:
>> On Sat, Jun 24, 2023 at 11:01:13AM +0200, Pali Rohár wrote:
>> > On Saturday 17 June 2023 22:28:24 Heinrich Schuchardt wrote:
>> > > On 6/17/23 12:48, Simon Glass wrote:
>> > > > Hi Pali,
>> > > >
>> > > > On Thu, 15 Jun 2023 at 17:56, Pali Rohár wrote:
>> > > > >
>> > > > > On Thursday 15 June 2023 13:34:09 Simon Glass wrote:
>> > > > > > Hi Pali,
>> > > > > >
>> > > > > > On Mon, 12 Jun 2023 at 22:33, Pali Rohár wrote:
>> > > > > > >
>> > > > > > > On Monday 12 June 2023 22:17:48 Simon Glass wrote:
>> > > > > > > > Hi Pali,
>> > > > > > > >
>> > > > > > > > On Mon, 12 Jun 2023 at 21:22, Pali Rohár
>> > > > > > > > wrote:
>> > > > > > > > >
>> > > > > > > > > On Monday 12 June 2023 21:14:32 Simon Glass wrote:
>> > > > > > > > > > The intent here was to allow ANSI codes to be disabled,
>> > > > > > > > > > since it was
>> > > > > > > > > > proving impoosible to test operation of the menu code when
>> > > > > > > > > > it kept moving
>> > > > > > > > > > the cursor. Unfortunately this ended up in the patch.
>> > > > > > > > > >
>> > > > > > > > > > Correct this by enabling ANSI again.
>> > > > > > > > > >
>> > > > > > > > > > Signed-off-by: Simon Glass
>> > > > > > > > > > Reported-by: Pali Rohár
>> > > > > > > > > > Reported-by: Mark Kettenis
>> > > > > > > > > > Reported-by: Frank Wunderlich
>> > > > > > > > > > Fixes: 32bab0eae51b ("menu: Make use of CLI character
>> > > > > > > > > > processing")
>> > > > > > > > > > ---
>> > > > > > > > > >
>> > > > > > > > > > common/menu.c | 2 +-
>> > > > > > > > > > 1 file changed, 1 insertion(+), 1 deletion(-)
>> > > > > > > > > >
>> > > > > > > > > > diff --git a/common/menu.c b/common/menu.c
>> > > > > > > > > > index 94514177e4e9..b55cf7b99967 100644
>> > > > > > > > > > --- a/common/menu.c
>> > > > > > > > > > +++ b/common/menu.c
>> > > > > > > > > > @@ -15,7 +15,7 @@
>> > > > > > > > > >
>> > > > > > > > > > #include "menu.h"
>> > > > > > > > > >
>> > > > > > > > > > -#define ansi 0
>> > > > > > > > > > +#define ansi 1
>> > > > > > > > > >
>> > > > > > > > > > /*
>> > > > > > > > > >* Internally, each item in a menu is represented by a
>> > > > > > > > > > struct menu_item.
>> > > > > > > > > > --
>> > > > > > > > > > 2.41.0.162.gfafddb0af9-goog
>> > > > > > > > > >
>> > > > > > > > >
>> > > > > > > > > Hello, I have tested this change but bootmenu still does not
>> > > > > > > > > work. There
>> > > > > > > > > is still same issue which I reported month ago. When I press
>> > > > > > > > > DOWN key
>> > > > > > > > > then bootmenu immediately quit instead of moving into the
>> > > > > > > > > next entry.
>> > > > > > > >
>> > > > > > > > Thanks for testing this.
>> > > > > > > >
>> > > > > > > > Is there a way for me to test this with sandbox? Or does your
>> > > > > > > > Nokia
>> > > > > > > > test check it?
>> > > > > > >
>> > > > > > > I guess that bootmenu command could work in sandbox. But I have
>> > > > > > > not
>> > > > > > > tried it.
>> > > > > > >
>> > > > > > > Nokia CI test does not try any terminal, keyboard or VGA
>> > > > > > > interaction, so
>> > > > > > > broken rendering or broken keyboard input is not caught by CI.
>> > > > > > >
>> > > > > > > But it is possible to test it manually. See U-Boot documentation
>> > > > > > > how to
>> > > > > > > run Nokia u-boot image in qemu. Bootmenu is automatically
>> > > > > > > started.
>> > > > > > > https://u-boot.readthedocs.io/en/latest/board/nokia/rx51.html#run-in-qemu
>> > > > > >
>> > > > > > I tried to follow this but got stuck here:
>> > > > > >
>> > > > > > ./configure --enable-system --target-list=arm-softmmu
>> > > > > > --disable-werror
>> > > > > >
>> > > > > > ERROR: Cannot use 'python', Python 2.4 or later is required.
>> > > > > > Note that Python 3 or later is not yet supported.
>> > > > > > Use --python=/path/to/python to specify a supported Python.
>> > > > > >
>> > > > > > Python 2 has been deprecated for years and I think it was removed
>> > > > > > recently.
>> >
>> > So install all required dependencies? It is really stupid argument to
>> > say that _I have removed X from my PC_ and then _I cannot compile Y
>> > because it depends on X_.
>>
>> We're not talking about adding some random but modern dependency. We're
>> talking about adding a language that every person responsible for it
>> says to not use and migrate away from. This is Heinrich's point.
>>
>> > > Our Docker image uses Ubuntu 22.04 (Jammy). Ubuntu 22.10 (Kinetic) was
>> > > the last Ubuntu release providing Python 2.7. So when upgrading our
>> > > Docker image next year we will have to quit emulating that 14 year old
>> > > device.
>> >
>> > Why to quit? Why you cannot compile and install required dependency?
>>
>> We'll have to quit because Python 2.7 won't be available from the
>> distribution. And no, we don't want to
Re: [PATCH v2 4/4] net: add NFSv1 support
On Sun, Jun 25, 2023 at 05:23:34PM +0200, Pali Rohár wrote: > On Saturday 24 June 2023 12:57:58 Tom Rini wrote: > > On Sat, Jun 24, 2023 at 11:08:59AM +0200, Pali Rohár wrote: > > > On Tuesday 13 June 2023 09:55:26 Peter Robinson wrote: > > > > > I can help with reviews in this area. In this case, please CC me. > > > > > > > > I suggest adding yourself to the MAINTAINERS file as a reviewer, > > > > people won't know you've offered and in a year Tom may not remember. > > > > > > Once people stop sending me unrelated u-boot emails then I can add > > > myself to another reviewer area in u-boot files. > > > > Were you going to follow up on my request for a patch to > > .get_maintainers.conf that tweaks the cut-off for git commits to your > > liking? I think that's where that particular issue stalled out. > > Me? Not, I'm not maintainer here. > > Do you really think that I'm willing to do any fix in this area now if > are writing me that locating u-boot commits which are breaking stuff and > proposing their revert until proper fix is ready, is not something you > would accept from me? > > Well, in this case you know the best how to fix this particular issue, > so do it yourself. It is clear that you would not accept any my change > here, so I'm not going to spend time on this issue as it would be just > waste of my free time. I have literally no idea what your cut-off point is for "git log says I care about this file, but it's wrong" is. So I can't come up with --git-min-signatures or --git-since that would make you happy, and in turn the one or two lines to add to the existing .git_maintainer.conf file. -- Tom signature.asc Description: PGP signature
Re: [PATCH v2] powerpc: Add support for CZ.NIC Turris 1.x routers
On Saturday 24 June 2023 12:57:46 Tom Rini wrote: > On Sat, Jun 24, 2023 at 11:19:51AM +0200, Pali Rohár wrote: > > On Monday 12 June 2023 14:07:24 Tom Rini wrote: > > > On Wed, Aug 17, 2022 at 10:56:22PM +0200, Pali Rohár wrote: > > > > > > > CZ.NIC Turris 1.0 and 1.1 are open source routers, they have dual-core > > > > PowerPC Freescale P2020 CPU and are based on Freescale P2020RDB-PC-A > > > > board. > > > > > > > > Hardware design is fully open source, all firmware and hardware design > > > > files are available at Turris project website: > > > > > > > > https://docs.turris.cz/hw/turris-1x/turris-1x/ > > > > https://project.turris.cz/en/hardware.html > > > > > > > > This patch adds full U-Boot support for CZ.NIC Turris 1.x routers. P2020 > > > > BootROM can load U-Boot either from NOR flash or from SD card. So there > > > > is > > > > defconfig file turris_1x_nor_defconfig which builds NOR version and > > > > defconfig file turris_1x_sdcard_defconfig which builds SD card version. > > > > > > > > Design of CZ.NIC Turris 1.x routers is based on Freescale P2020RDB-PC-A > > > > board, so common board code from boards/freescale/p1_p2_rdb_pc > > > > directory is > > > > shared and linked also into Turris 1.x U-Boot board code. > > > > > > > > Turris 1.x code in this patch uses modern distroboot and can boot Linux > > > > kernel from various locations, including NAND, SD card, USB flash disks, > > > > NVMe disks or SATA disks (connected to extra SATA/SCSI PCIe > > > > controllers). > > > > > > > > Signed-off-by: Pali Rohár > > > > > > To be clear, this is something that if there's still interest in > > > upstreaming this platform, this patch needs to be rebased and re-tested > > > as it's non-trivially out of date. In addition: > > > > Meanwhile I have already done rebase and retest, v3 is here: > > https://patchwork.ozlabs.org/project/uboot/patch/20220831164821.29109-1-p...@kernel.org/ > > Yes, and I replied to that with feedback. Seems that there is no feeback on above patch. > > > > diff --git a/board/CZ.NIC/turris_1x/Kconfig > > > > b/board/CZ.NIC/turris_1x/Kconfig > > > > new file mode 100644 > > > > index ..2a1cbd22c783 > > > > --- /dev/null > > > > +++ b/board/CZ.NIC/turris_1x/Kconfig > > > > @@ -0,0 +1,170 @@ > > > > +# SPDX-License-Identifier: GPL-2.0+ > > > > +# (C) 2022 Pali Rohár > > > > + > > > > +if TARGET_TURRIS_1X > > > > + > > > > +# Board identification > > > > +config SYS_BOARD > > > > + default "turris_1x" > > > > +config SYS_VENDOR > > > > + default "CZ.NIC" > > > > +config SYS_CONFIG_NAME > > > > + default "turris_1x" > > > > +config DEFAULT_DEVICE_TREE > > > > + default "turris1x" > > > > + > > > > +# Board functions > > > > +config ATSHA204A > > > > + default y > > > > +config BOARD_EARLY_INIT_F > > > > + default y > > > > +config BOARD_EARLY_INIT_R > > > > + default y > > > > +config LAST_STAGE_INIT > > > > + default y > > > > +config MISC > > > > + default y > > > > +config OF_BOARD_FIXUP > > > > + default y > > > > +config OF_BOARD_SETUP > > > > + default y > > > > + > > > > +# ENV > > > > +config ENV_SIZE > > > > + default 0x2000 > > > > +config ENV_SECT_SIZE > > > > + default 0x2 > > > > +config ENV_OVERWRITE > > > > + default y > > > > +config ENV_IS_IN_FLASH > > > > + default y > > > > +config ENV_ADDR > > > > + default 0xeff2 # in NOR > > > > +config SYS_RELOC_GD_ENV_ADDR > > > > + default y > > > > + > > > > +# DDR > > > > +config DDR_CLK_FREQ > > > > + default > > > > + > > > > +# UART > > > > +config DEBUG_UART_BASE > > > > + default 0xffe04500 if DEBUG_UART > > > > +config DEBUG_UART_CLOCK > > > > + default 3750 if DEBUG_UART > > > > +config SYS_NS16550 > > > > + default y > > > > + > > > > +# I2C > > > > +config I2C_SET_DEFAULT_BUS_NUM > > > > + default y > > > > +config SYS_FSL_I2C_OFFSET > > > > + default 0x3000 > > > > +config SYS_FSL_HAS_I2C2_OFFSET > > > > + default y > > > > +config SYS_FSL_I2C2_OFFSET > > > > + default 0x3100 > > > > +config SYS_I2C_FSL > > > > + default y > > > > + > > > > +# GPIO > > > > +config MPC8XXX_GPIO > > > > + default y > > > > + > > > > +# WDT > > > > +config WDT_MAX6370 > > > > + default y > > > > + > > > > +# PCIe > > > > +config PCI_INIT_R > > > > + default y > > > > +config PCIE_FSL > > > > + default y > > > > + > > > > +# Ethernet > > > > +config MII > > > > + default y > > > > +config PHY_FIXED > > > > + default y > > > > +config TSEC_ENET > > > > + default y > > > > + > > > > +# USB > > > > +config USB_EHCI_FSL > > > > + default y > > > > +config USB_XHCI_HCD > > > > + default y > > > > +config USB_XHCI_PCI > > > > + default y > > > > + > > > > +# SDHC > > > > +config FSL_ESDHC > > > > + default y > > > > +config FSL_PREPBL_ESDHC_BOOT_SECTOR > > > > +
Re: [PATCH] menu: Re-enable the ANSI codes
On Saturday 24 June 2023 13:05:11 Tom Rini wrote:
> On Sat, Jun 24, 2023 at 11:01:13AM +0200, Pali Rohár wrote:
> > On Saturday 17 June 2023 22:28:24 Heinrich Schuchardt wrote:
> > > On 6/17/23 12:48, Simon Glass wrote:
> > > > Hi Pali,
> > > >
> > > > On Thu, 15 Jun 2023 at 17:56, Pali Rohár wrote:
> > > > >
> > > > > On Thursday 15 June 2023 13:34:09 Simon Glass wrote:
> > > > > > Hi Pali,
> > > > > >
> > > > > > On Mon, 12 Jun 2023 at 22:33, Pali Rohár wrote:
> > > > > > >
> > > > > > > On Monday 12 June 2023 22:17:48 Simon Glass wrote:
> > > > > > > > Hi Pali,
> > > > > > > >
> > > > > > > > On Mon, 12 Jun 2023 at 21:22, Pali Rohár
> > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > On Monday 12 June 2023 21:14:32 Simon Glass wrote:
> > > > > > > > > > The intent here was to allow ANSI codes to be disabled,
> > > > > > > > > > since it was
> > > > > > > > > > proving impoosible to test operation of the menu code when
> > > > > > > > > > it kept moving
> > > > > > > > > > the cursor. Unfortunately this ended up in the patch.
> > > > > > > > > >
> > > > > > > > > > Correct this by enabling ANSI again.
> > > > > > > > > >
> > > > > > > > > > Signed-off-by: Simon Glass
> > > > > > > > > > Reported-by: Pali Rohár
> > > > > > > > > > Reported-by: Mark Kettenis
> > > > > > > > > > Reported-by: Frank Wunderlich
> > > > > > > > > > Fixes: 32bab0eae51b ("menu: Make use of CLI character
> > > > > > > > > > processing")
> > > > > > > > > > ---
> > > > > > > > > >
> > > > > > > > > > common/menu.c | 2 +-
> > > > > > > > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > > > > > > > >
> > > > > > > > > > diff --git a/common/menu.c b/common/menu.c
> > > > > > > > > > index 94514177e4e9..b55cf7b99967 100644
> > > > > > > > > > --- a/common/menu.c
> > > > > > > > > > +++ b/common/menu.c
> > > > > > > > > > @@ -15,7 +15,7 @@
> > > > > > > > > >
> > > > > > > > > > #include "menu.h"
> > > > > > > > > >
> > > > > > > > > > -#define ansi 0
> > > > > > > > > > +#define ansi 1
> > > > > > > > > >
> > > > > > > > > > /*
> > > > > > > > > >* Internally, each item in a menu is represented by a
> > > > > > > > > > struct menu_item.
> > > > > > > > > > --
> > > > > > > > > > 2.41.0.162.gfafddb0af9-goog
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > Hello, I have tested this change but bootmenu still does not
> > > > > > > > > work. There
> > > > > > > > > is still same issue which I reported month ago. When I press
> > > > > > > > > DOWN key
> > > > > > > > > then bootmenu immediately quit instead of moving into the
> > > > > > > > > next entry.
> > > > > > > >
> > > > > > > > Thanks for testing this.
> > > > > > > >
> > > > > > > > Is there a way for me to test this with sandbox? Or does your
> > > > > > > > Nokia
> > > > > > > > test check it?
> > > > > > >
> > > > > > > I guess that bootmenu command could work in sandbox. But I have
> > > > > > > not
> > > > > > > tried it.
> > > > > > >
> > > > > > > Nokia CI test does not try any terminal, keyboard or VGA
> > > > > > > interaction, so
> > > > > > > broken rendering or broken keyboard input is not caught by CI.
> > > > > > >
> > > > > > > But it is possible to test it manually. See U-Boot documentation
> > > > > > > how to
> > > > > > > run Nokia u-boot image in qemu. Bootmenu is automatically started.
> > > > > > > https://u-boot.readthedocs.io/en/latest/board/nokia/rx51.html#run-in-qemu
> > > > > >
> > > > > > I tried to follow this but got stuck here:
> > > > > >
> > > > > > ./configure --enable-system --target-list=arm-softmmu
> > > > > > --disable-werror
> > > > > >
> > > > > > ERROR: Cannot use 'python', Python 2.4 or later is required.
> > > > > > Note that Python 3 or later is not yet supported.
> > > > > > Use --python=/path/to/python to specify a supported Python.
> > > > > >
> > > > > > Python 2 has been deprecated for years and I think it was removed
> > > > > > recently.
> >
> > So install all required dependencies? It is really stupid argument to
> > say that _I have removed X from my PC_ and then _I cannot compile Y
> > because it depends on X_.
>
> We're not talking about adding some random but modern dependency. We're
> talking about adding a language that every person responsible for it
> says to not use and migrate away from. This is Heinrich's point.
>
> > > Our Docker image uses Ubuntu 22.04 (Jammy). Ubuntu 22.10 (Kinetic) was
> > > the last Ubuntu release providing Python 2.7. So when upgrading our
> > > Docker image next year we will have to quit emulating that 14 year old
> > > device.
> >
> > Why to quit? Why you cannot compile and install required dependency?
>
> We'll have to quit because Python 2.7 won't be available from the
> distribution. And no, we don't want to add building Python 2.7 to the
> list of things our container does. I don't even know that Python 2.7
> will compile with the gcc and related that will ship in the host. And
> that's
Re: [PATCH v2 4/4] net: add NFSv1 support
On Saturday 24 June 2023 12:57:58 Tom Rini wrote: > On Sat, Jun 24, 2023 at 11:08:59AM +0200, Pali Rohár wrote: > > On Tuesday 13 June 2023 09:55:26 Peter Robinson wrote: > > > > I can help with reviews in this area. In this case, please CC me. > > > > > > I suggest adding yourself to the MAINTAINERS file as a reviewer, > > > people won't know you've offered and in a year Tom may not remember. > > > > Once people stop sending me unrelated u-boot emails then I can add > > myself to another reviewer area in u-boot files. > > Were you going to follow up on my request for a patch to > .get_maintainers.conf that tweaks the cut-off for git commits to your > liking? I think that's where that particular issue stalled out. Me? Not, I'm not maintainer here. Do you really think that I'm willing to do any fix in this area now if are writing me that locating u-boot commits which are breaking stuff and proposing their revert until proper fix is ready, is not something you would accept from me? Well, in this case you know the best how to fix this particular issue, so do it yourself. It is clear that you would not accept any my change here, so I'm not going to spend time on this issue as it would be just waste of my free time.
Re: [PATCH u-boot 0/3] Revert broken Bootmenu commits
On Sunday 25 June 2023 10:52:13 Tom Rini wrote: > On Sun, Jun 25, 2023 at 09:50:39AM +0200, Pali Rohár wrote: > > On Saturday 24 June 2023 12:58:07 Tom Rini wrote: > > > On Sat, Jun 24, 2023 at 10:50:41AM +0200, Pali Rohár wrote: > > > > On Tuesday 20 June 2023 11:20:35 Simon Glass wrote: > > > > > Hi Tom, Pali, > > > > > > > > > > On Wed, 14 Jun 2023 at 20:51, Tom Rini wrote: > > > > > > > > > > > > On Sun, Jun 11, 2023 at 02:53:21PM +0200, Pali Rohár wrote: > > > > > > > > > > > > > These 3 commits broke support for U-Boot Bootmenu on Nokia N900. > > > > > > > Issues were reported more than month ago, but nobody reacted to > > > > > > > them. > > > > > > > So revert these broken commits for now, to fix U-Boot Bootmenu > > > > > > > support. > > > > > > > > > > > > > > With these revered commits, U-Boot Bootmenu from master branch is > > > > > > > working fine again on Nokia N900. > > > > > > > > > > > > > > Pali Rohár (3): > > > > > > > Revert "video: Enable VIDEO_ANSI by default only with EFI" > > > > > > > Revert "menu: Factor out menu-keypress decoding" > > > > > > > Revert "menu: Make use of CLI character processing" > > > > > > > > > > > > > > cmd/bootmenu.c| 9 ++-- > > > > > > > cmd/eficonfig.c | 12 ++--- > > > > > > > common/cli_getch.c| 12 ++--- > > > > > > > common/menu.c | 122 > > > > > > > ++ > > > > > > > drivers/video/Kconfig | 7 +-- > > > > > > > include/cli.h | 4 +- > > > > > > > include/menu.h| 17 +- > > > > > > > 7 files changed, 91 insertions(+), 92 deletions(-) > > > > > > > > > > > > Following up over here, while > > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20230612201434.861700-1-...@chromium.org/ > > > > > > addresses some of the issues, but not all (as it clearly isn't > > > > > > working > > > > > > in all of the cases Pali has explained), looking in to the > > > > > > VIDEO_ANSI > > > > > > part of this too, all three of these reverts are related seemingly > > > > > > to > > > > > > something escape-character related. I'm not taking any of the > > > > > > revert > > > > > > commits in just yet, but will by the next -rc if we don't have > > > > > > something > > > > > > that fixes all of the issues. > > > > > > > > > > I did send a series [1] with a fix for the nokia_rx51 keyboard driver, > > > > > including the previous ansi-code patch. Given that: > > > > > > > > > > - this problem doesn't seem to manifest on other boards > > > > > - it does not cause any CI test to fail > > > > > - there seem to be bugs in the nokia_rx51 implementation which are a > > > > > possible/likely cause > > > > > - the nokia_rx51 CI uses a 10-year-old out-of-tree QEMU > > > > > - the problem goes away if debugging is added, suggesting it is > > > > > related to timing > > > > > > > > > > ...I don't think a revert is appropriate. > > > > > > > > Unfortunately it does not fix this issue :-( New patch series from [1] > > > > applied on top of the master branch has still issue with DOWN key on > > > > emulated UART terminal. > > > > > > > > > Pali, can you please take a look and see if you can debug what is > > > > > actually going on? Here is my guess: > > > > > > > > > > 1. When an arrow key is pressed, cli_ch_process() handles it by being > > > > > passed the codes in sequence: \e [ B > > > > > 2. Calling cli_ch_process() with ichar = 0 causes it to think the > > > > > sequence is finished: \e [ \0 B (this doesn't work since the \0 ends > > > > > the sequence) > > > > > 3. nokia_rx51 keyboard driver is returning '\0' even when key codes > > > > > are pending, causing cli_ch_process() to be told that the sequence is > > > > > done > > > > > > > > I can look at it later, but I'm loosing motivation to do whole debugging > > > > for another issue again, because for the last year my fixes and other > > > > patches were stalled and u-boot devs show me that they are not > > > > interested even in commenting them. I do not want to work again on > > > > something which would be ignored. > > > > > > Well, unless your changes here break something else, I don't think a fix > > > for your problem will be ignored. > > > > This is something which I read here more times in the past... and > > reality was different. > > > > Should I remind you that there are waiting eMMC fixes for mvebu and > > again discussion about them stalled? Or rather should I say that it is > > again ignored? > > No, you should just say they're still waiting for review. Since they're > waiting for review. The MMC custodian has been asked to review them, and > hasn't yet. And they don't appear to be super critical changes, and they > conflict with other series, so yes, they'll get picked up when the > custodian has time to review everything. And what is "critical change" if it is not fixing booting (from eMMC)? > > I have already spend time on this and have done everything needed to > > make
Re: [PATCH u-boot 0/3] Revert broken Bootmenu commits
On Sun, Jun 25, 2023 at 09:50:39AM +0200, Pali Rohár wrote: > On Saturday 24 June 2023 12:58:07 Tom Rini wrote: > > On Sat, Jun 24, 2023 at 10:50:41AM +0200, Pali Rohár wrote: > > > On Tuesday 20 June 2023 11:20:35 Simon Glass wrote: > > > > Hi Tom, Pali, > > > > > > > > On Wed, 14 Jun 2023 at 20:51, Tom Rini wrote: > > > > > > > > > > On Sun, Jun 11, 2023 at 02:53:21PM +0200, Pali Rohár wrote: > > > > > > > > > > > These 3 commits broke support for U-Boot Bootmenu on Nokia N900. > > > > > > Issues were reported more than month ago, but nobody reacted to > > > > > > them. > > > > > > So revert these broken commits for now, to fix U-Boot Bootmenu > > > > > > support. > > > > > > > > > > > > With these revered commits, U-Boot Bootmenu from master branch is > > > > > > working fine again on Nokia N900. > > > > > > > > > > > > Pali Rohár (3): > > > > > > Revert "video: Enable VIDEO_ANSI by default only with EFI" > > > > > > Revert "menu: Factor out menu-keypress decoding" > > > > > > Revert "menu: Make use of CLI character processing" > > > > > > > > > > > > cmd/bootmenu.c| 9 ++-- > > > > > > cmd/eficonfig.c | 12 ++--- > > > > > > common/cli_getch.c| 12 ++--- > > > > > > common/menu.c | 122 > > > > > > ++ > > > > > > drivers/video/Kconfig | 7 +-- > > > > > > include/cli.h | 4 +- > > > > > > include/menu.h| 17 +- > > > > > > 7 files changed, 91 insertions(+), 92 deletions(-) > > > > > > > > > > Following up over here, while > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20230612201434.861700-1-...@chromium.org/ > > > > > addresses some of the issues, but not all (as it clearly isn't working > > > > > in all of the cases Pali has explained), looking in to the VIDEO_ANSI > > > > > part of this too, all three of these reverts are related seemingly to > > > > > something escape-character related. I'm not taking any of the revert > > > > > commits in just yet, but will by the next -rc if we don't have > > > > > something > > > > > that fixes all of the issues. > > > > > > > > I did send a series [1] with a fix for the nokia_rx51 keyboard driver, > > > > including the previous ansi-code patch. Given that: > > > > > > > > - this problem doesn't seem to manifest on other boards > > > > - it does not cause any CI test to fail > > > > - there seem to be bugs in the nokia_rx51 implementation which are a > > > > possible/likely cause > > > > - the nokia_rx51 CI uses a 10-year-old out-of-tree QEMU > > > > - the problem goes away if debugging is added, suggesting it is > > > > related to timing > > > > > > > > ...I don't think a revert is appropriate. > > > > > > Unfortunately it does not fix this issue :-( New patch series from [1] > > > applied on top of the master branch has still issue with DOWN key on > > > emulated UART terminal. > > > > > > > Pali, can you please take a look and see if you can debug what is > > > > actually going on? Here is my guess: > > > > > > > > 1. When an arrow key is pressed, cli_ch_process() handles it by being > > > > passed the codes in sequence: \e [ B > > > > 2. Calling cli_ch_process() with ichar = 0 causes it to think the > > > > sequence is finished: \e [ \0 B (this doesn't work since the \0 ends > > > > the sequence) > > > > 3. nokia_rx51 keyboard driver is returning '\0' even when key codes > > > > are pending, causing cli_ch_process() to be told that the sequence is > > > > done > > > > > > I can look at it later, but I'm loosing motivation to do whole debugging > > > for another issue again, because for the last year my fixes and other > > > patches were stalled and u-boot devs show me that they are not > > > interested even in commenting them. I do not want to work again on > > > something which would be ignored. > > > > Well, unless your changes here break something else, I don't think a fix > > for your problem will be ignored. > > This is something which I read here more times in the past... and > reality was different. > > Should I remind you that there are waiting eMMC fixes for mvebu and > again discussion about them stalled? Or rather should I say that it is > again ignored? No, you should just say they're still waiting for review. Since they're waiting for review. The MMC custodian has been asked to review them, and hasn't yet. And they don't appear to be super critical changes, and they conflict with other series, so yes, they'll get picked up when the custodian has time to review everything. > I have already spend time on this and have done everything needed to > make bootmenu working again. I have also prepared patches which are > fixing this problem and which were also tested. Note that "I reverted the commit" is not a fix. > And if you want something more from me then you show me why this time it > would be different, and again empty promises. What I'd like is for you to not assume worst-faith. If you can fix the problem
[PATCH 1/1] doc: saves man-page
Provide a man-page for the saves command. Signed-off-by: Heinrich Schuchardt --- doc/usage/cmd/saves.rst | 88 + doc/usage/index.rst | 1 + 2 files changed, 89 insertions(+) create mode 100644 doc/usage/cmd/saves.rst diff --git a/doc/usage/cmd/saves.rst b/doc/usage/cmd/saves.rst new file mode 100644 index 00..57299029ff --- /dev/null +++ b/doc/usage/cmd/saves.rst @@ -0,0 +1,88 @@ +.. SPDX-License-Identifier: GPL-2.0+: + +saves command += + +Synopsis + + +:: + +saves [offset [size [baud]]] + +Description +--- + +The *saves* command is used to transfer a file from the device via the serial +line using the Motorola S-record file format. + +offset +start address of memory area to save, defaults to 0x0 + +size +size of memory area to save, defaults to 0x0 + +baud +baud rate to use for download. This parameter is only available if +CONFIG_SYS_LOADS_BAUD_CHANGE=y + +Example +--- + +In the example the *screen* command is used to connect to the U-Boot serial +console. + +In a first screen session a file is loaded form the SD-card and the *saves* +command is invoked. is used to kill the screen session. + +A new screen session is started which logs the output to a file and the + key is hit to start the file output. is issued to kill the +screen session. + +The log file is converted to a binary file using the *srec_cat* command. +A negative offset of -1337982976 (= -0x4c00) is applied to compensate for +the offset used in the *saves* command. + +.. code-block:: + +$ screen /dev/ttyUSB0 115200 +=> echo $scriptaddr +0x4FC0 +=> load mmc 0:1 $scriptaddr boot.txt +124 bytes read in 1 ms (121.1 KiB/s) +=> saves $scriptaddr $filesize +## Ready for S-Record upload, press ENTER to proceed ... +Really kill this window [y/n] +$ screen -Logfile out.srec -L /dev/ttyUSB0 115200 +S003FC +S3154FC0736574656E76206175746F6C6F616420AD +S3154FC000106E6F0A646863700A6C6F6164206D6D633E +S3154FC0002020303A3120246664745F616464725F72B3 +S3154FC00030206474620A6C6F6164206D6D6320303AC0 +S3154FC000403120246B65726E656C5F616464725F72DA +S3154FC0005020736E702E6566690A626F6F74656669C6 +S3154FC0006020246B65726E656C5F616464725F7220CB +S3114FC00070246664745F616464725F720A38 +S705FA +## S-Record upload complete +=> +Really kill this window [y/n] +$ srec_cat out.srec -offset -1337982976 -Output out.txt -binary 2>/dev/null +$ cat out.txt +setenv autoload no +dhcp +load mmc 0:1 $fdt_addr_r dtb +load mmc 0:1 $kernel_addr_r snp.efi +bootefi $kernel_addr_r $fdt_addr_r +$ + +Configuration +- + +The command is only available if CONFIG_CMD_SAVES=y. The parameter to set the +baud rate is only available if CONFIG_SYS_LOADS_BAUD_CHANGE=y + +Return value + + +The return value $? is 0 (true) on success, 1 (false) otherwise. diff --git a/doc/usage/index.rst b/doc/usage/index.rst index ef3e87fed0..388e59f173 100644 --- a/doc/usage/index.rst +++ b/doc/usage/index.rst @@ -85,6 +85,7 @@ Shell commands cmd/read cmd/reset cmd/rng + cmd/saves cmd/sbi cmd/sf cmd/scp03 -- 2.40.1
[PATCH] sql: Kconfig: TPL_BANNER_PRINT depends on DEBUG_UART && TPL_SERIAL
From: Ying Sun As implemented in the arch/arm/mach-rockchip/tpl.c file, the CONFIG_TPL_BANNER_PRINT option will not work if either of these options is not enabled. Add dependency constraints to the CONFIG_TPL_BANNER_PRINT option definition to prevent configuration problems where option is enabled but do not take effect. Suggested-by: Yanjie Ren Signed-off-by: Ying Sun --- common/spl/Kconfig.tpl | 1 + 1 file changed, 1 insertion(+) diff --git a/common/spl/Kconfig.tpl b/common/spl/Kconfig.tpl index 1874f9db4f..3d6cf1e59f 100644 --- a/common/spl/Kconfig.tpl +++ b/common/spl/Kconfig.tpl @@ -43,6 +43,7 @@ config TPL_FRAMEWORK config TPL_BANNER_PRINT bool "Enable output of the TPL banner 'U-Boot TPL ...'" + depends on DEBUG_UART && TPL_SERIAL default y help If this option is enabled, TPL will print the banner with version -- 2.17.1
[PATCH] common: Kconfig: SYS_CONSOLE_ENV_OVERWRITE depends on SYS_CONSOLE_IS_IN_ENV
From: Ying Sun CONFIG_SYS_CONSOLE_ENV_OVERWRITE is implemented in common/console.c when "#if CONFIG_IS_ENABLED(SYS_CONSOLE_IS_IN_ENV)" is met. It is recommended to add dependency constraints to its definition. Suggested-by: Yanjie Ren Signed-off-by: Ying Sun --- common/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/common/Kconfig b/common/Kconfig index bbabadb35e..42baca20a6 100644 --- a/common/Kconfig +++ b/common/Kconfig @@ -256,6 +256,7 @@ config SYS_CONSOLE_OVERWRITE_ROUTINE config SYS_CONSOLE_ENV_OVERWRITE bool "Update environment variables during console init" + depends on SYS_CONSOLE_IS_IN_ENV help The console environment variables (stdout, stdin, stderr) can be used to determine the correct console devices on start-up. This -- 2.17.1
[PATCH] cmd: CONFIG_CMD_SAVES depends on CONFIG_CMD_LOADS
From: Ying Sun CONFIG_CMD_SAVES is used to enable support for the "saveenv" command and is only implemented in cmd/load.c when "#if defined(CONFIG_CMD_LOADS)" is met. It is recommended to add dependency constraints to its definition. Prevents "saveenv" command from not being supported when "CONFIG_CMD_SAVES=y CONFIG_CMD_LOADS=n". Suggested-by: Yanjie Ren Signed-off-by: Ying Sun --- cmd/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/cmd/Kconfig b/cmd/Kconfig index 02e54f1e50..c1941849f9 100644 --- a/cmd/Kconfig +++ b/cmd/Kconfig @@ -1228,6 +1228,7 @@ config LOADS_ECHO config CMD_SAVES bool "saves - Save a file over serial in S-Record format" + depends on CMD_LOADS help Provides a way to save a binary file using the Motorola S-Record format over the serial line. -- 2.17.1
[PATCH] ARM: imx: romapi: Fix signed integer bitwise ops misuse
Bitwise operations on signed integers are not defined,
replace then with per-call checks.
Signed-off-by: Marek Vasut
---
Cc: "NXP i.MX U-Boot Team"
Cc: Fabio Estevam
Cc: Heiko Schocher
Cc: Heinrich Schuchardt
Cc: Rasmus Villemoes
Cc: Simon Glass
Cc: Stefano Babic
Cc: Tom Rini
Cc: Ye Li
---
arch/arm/mach-imx/spl_imx_romapi.c | 32 --
1 file changed, 21 insertions(+), 11 deletions(-)
diff --git a/arch/arm/mach-imx/spl_imx_romapi.c
b/arch/arm/mach-imx/spl_imx_romapi.c
index 9164045115f..4af41699678 100644
--- a/arch/arm/mach-imx/spl_imx_romapi.c
+++ b/arch/arm/mach-imx/spl_imx_romapi.c
@@ -76,13 +76,16 @@ static int spl_romapi_load_image_seekable(struct
spl_image_info *spl_image,
u32 image_offset;
ret = rom_api_query_boot_infor(QUERY_IVT_OFF, );
- ret |= rom_api_query_boot_infor(QUERY_PAGE_SZ, );
- ret |= rom_api_query_boot_infor(QUERY_IMG_OFF, _offset);
+ if (ret != ROM_API_OKAY)
+ goto err;
- if (ret != ROM_API_OKAY) {
- puts("ROMAPI: Failure query boot infor pagesize/offset\n");
- return -1;
- }
+ ret = rom_api_query_boot_infor(QUERY_PAGE_SZ, );
+ if (ret != ROM_API_OKAY)
+ goto err;
+
+ ret = rom_api_query_boot_infor(QUERY_IMG_OFF, _offset);
+ if (ret != ROM_API_OKAY)
+ goto err;
header = (struct legacy_img_hdr *)(CONFIG_SPL_IMX_ROMAPI_LOADADDR);
@@ -124,6 +127,10 @@ static int spl_romapi_load_image_seekable(struct
spl_image_info *spl_image,
}
return 0;
+
+err:
+ puts("ROMAPI: Failure query boot infor pagesize/offset\n");
+ return -1;
}
static ulong spl_ram_load_read(struct spl_load_info *load, ulong sector,
@@ -344,12 +351,12 @@ int board_return_to_bootrom(struct spl_image_info
*spl_image,
u32 boot, bstage;
ret = rom_api_query_boot_infor(QUERY_BT_DEV, );
- ret |= rom_api_query_boot_infor(QUERY_BT_STAGE, );
+ if (ret != ROM_API_OKAY)
+ goto err;
- if (ret != ROM_API_OKAY) {
- puts("ROMAPI: failure at query_boot_info\n");
- return -1;
- }
+ ret = rom_api_query_boot_infor(QUERY_BT_STAGE, );
+ if (ret != ROM_API_OKAY)
+ goto err;
printf("Boot Stage: ");
@@ -374,4 +381,7 @@ int board_return_to_bootrom(struct spl_image_info
*spl_image,
return spl_romapi_load_image_stream(spl_image, bootdev);
return spl_romapi_load_image_seekable(spl_image, bootdev, boot);
+err:
+ puts("ROMAPI: failure at query_boot_info\n");
+ return -1;
}
--
2.40.1
[PATCH 1/1] cmd: fix loads, saves on sandbox
The loads and saves commands crash on the sandbox due to illegal memory
access.
For command line arguments the sandbox uses a virtual address space which
does not equal the addresses of the memory allocated with memmap(). Add the
missing address translations for the loads and saves commands.
Signed-off-by: Heinrich Schuchardt
---
cmd/load.c | 16
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/cmd/load.c b/cmd/load.c
index 5c4f34781d..2715cf5957 100644
--- a/cmd/load.c
+++ b/cmd/load.c
@@ -181,13 +181,17 @@ static ulong load_serial(long offset)
} else
#endif
{
+ void *dst;
+
ret = lmb_reserve(, store_addr, binlen);
if (ret) {
printf("\nCannot overwrite reserved area
(%08lx..%08lx)\n",
store_addr, store_addr + binlen);
return ret;
}
- memcpy((char *)(store_addr), binbuf, binlen);
+ dst = map_sysmem(store_addr, binlen);
+ memcpy(dst, binbuf, binlen);
+ unmap_sysmem(dst);
lmb_free(, store_addr, binlen);
}
if ((store_addr) < start_addr)
@@ -350,15 +354,19 @@ static int save_serial(ulong address, ulong count)
if(write_record(SREC3_START)) /* write the header */
return (-1);
do {
- if(count) { /*
collect hex data in the buffer */
- c = *(volatile uchar*)(address + reclen); /* get
one byte*/
- checksum += c;
/* accumulate checksum */
+ volatile uchar *src;
+
+ src = map_sysmem(address, count);
+ if (count) {/* collect hex data in
the buffer */
+ c = src[reclen];/* get one byte */
+ checksum += c; /* accumulate checksum
*/
data[2*reclen] = hex[(c>>4)&0x0f];
data[2*reclen+1] = hex[c & 0x0f];
data[2*reclen+2] = '\0';
++reclen;
--count;
}
+ unmap_sysmem((void *)src);
if(reclen == SREC_BYTES_PER_RECORD || count == 0) {
/* enough data collected for one record: dump it */
if(reclen) {/* build & write a data record: */
--
2.40.1
Re: [PATCH u-boot 0/3] Revert broken Bootmenu commits
On Saturday 24 June 2023 12:58:07 Tom Rini wrote: > On Sat, Jun 24, 2023 at 10:50:41AM +0200, Pali Rohár wrote: > > On Tuesday 20 June 2023 11:20:35 Simon Glass wrote: > > > Hi Tom, Pali, > > > > > > On Wed, 14 Jun 2023 at 20:51, Tom Rini wrote: > > > > > > > > On Sun, Jun 11, 2023 at 02:53:21PM +0200, Pali Rohár wrote: > > > > > > > > > These 3 commits broke support for U-Boot Bootmenu on Nokia N900. > > > > > Issues were reported more than month ago, but nobody reacted to them. > > > > > So revert these broken commits for now, to fix U-Boot Bootmenu > > > > > support. > > > > > > > > > > With these revered commits, U-Boot Bootmenu from master branch is > > > > > working fine again on Nokia N900. > > > > > > > > > > Pali Rohár (3): > > > > > Revert "video: Enable VIDEO_ANSI by default only with EFI" > > > > > Revert "menu: Factor out menu-keypress decoding" > > > > > Revert "menu: Make use of CLI character processing" > > > > > > > > > > cmd/bootmenu.c| 9 ++-- > > > > > cmd/eficonfig.c | 12 ++--- > > > > > common/cli_getch.c| 12 ++--- > > > > > common/menu.c | 122 > > > > > ++ > > > > > drivers/video/Kconfig | 7 +-- > > > > > include/cli.h | 4 +- > > > > > include/menu.h| 17 +- > > > > > 7 files changed, 91 insertions(+), 92 deletions(-) > > > > > > > > Following up over here, while > > > > https://patchwork.ozlabs.org/project/uboot/patch/20230612201434.861700-1-...@chromium.org/ > > > > addresses some of the issues, but not all (as it clearly isn't working > > > > in all of the cases Pali has explained), looking in to the VIDEO_ANSI > > > > part of this too, all three of these reverts are related seemingly to > > > > something escape-character related. I'm not taking any of the revert > > > > commits in just yet, but will by the next -rc if we don't have something > > > > that fixes all of the issues. > > > > > > I did send a series [1] with a fix for the nokia_rx51 keyboard driver, > > > including the previous ansi-code patch. Given that: > > > > > > - this problem doesn't seem to manifest on other boards > > > - it does not cause any CI test to fail > > > - there seem to be bugs in the nokia_rx51 implementation which are a > > > possible/likely cause > > > - the nokia_rx51 CI uses a 10-year-old out-of-tree QEMU > > > - the problem goes away if debugging is added, suggesting it is > > > related to timing > > > > > > ...I don't think a revert is appropriate. > > > > Unfortunately it does not fix this issue :-( New patch series from [1] > > applied on top of the master branch has still issue with DOWN key on > > emulated UART terminal. > > > > > Pali, can you please take a look and see if you can debug what is > > > actually going on? Here is my guess: > > > > > > 1. When an arrow key is pressed, cli_ch_process() handles it by being > > > passed the codes in sequence: \e [ B > > > 2. Calling cli_ch_process() with ichar = 0 causes it to think the > > > sequence is finished: \e [ \0 B (this doesn't work since the \0 ends > > > the sequence) > > > 3. nokia_rx51 keyboard driver is returning '\0' even when key codes > > > are pending, causing cli_ch_process() to be told that the sequence is > > > done > > > > I can look at it later, but I'm loosing motivation to do whole debugging > > for another issue again, because for the last year my fixes and other > > patches were stalled and u-boot devs show me that they are not > > interested even in commenting them. I do not want to work again on > > something which would be ignored. > > Well, unless your changes here break something else, I don't think a fix > for your problem will be ignored. This is something which I read here more times in the past... and reality was different. Should I remind you that there are waiting eMMC fixes for mvebu and again discussion about them stalled? Or rather should I say that it is again ignored? I have already spend time on this and have done everything needed to make bootmenu working again. I have also prepared patches which are fixing this problem and which were also tested. And if you want something more from me then you show me why this time it would be different, and again empty promises. > > Hence, now I did only smaller - but still important - task: Locate exact > > commits which broke particular feature and prepare reverts on top of the > > master branch which _really_ fix the broken functionality - and make > > code working again. > > Unfortunately you're also the only person able to replicate the problem, > and Simon has tried (and posted fixes to your platform for other issues, > and debugging patches to hopefully making finding the problem easier). Have somebody else even tried to reproduce this issue on any other HW board or any other qemu board?
