Re: [U-Boot] [PATCH 2/2] riscv: qemu-riscv.h: define CONFIG_PREBOOT (enables extlinux)
> -Original Message-
> From: David Abdurachmanov
> Sent: Tuesday, April 9, 2019 4:13 PM
> To: r...@andestech.com; Atish Patra ; Anup Patel
> ; lukas.a...@aisec.fraunhofer.de; u-
> b...@lists.denx.de
> Cc: David Abdurachmanov
> Subject: [PATCH 2/2] riscv: qemu-riscv.h: define CONFIG_PREBOOT (enables
> extlinux)
>
> - Set fdt_addr variable, which is needed for extlinux to find FDT.
> Otherwise booting kernel using extlinux results in missing FDT.
>
> - Also run fdt addr with FDT address so that fdt commands would
> work out of the box in U-Boot prompt.
>
> This is successfully used by Fedora/RISCV with 5.1-rc3+ kernel using OpenSBI
> -> U-Boot (S-mode) [extlinux] -> Kernel setup.
>
> Signed-off-by: David Abdurachmanov
> ---
> include/configs/qemu-riscv.h | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/include/configs/qemu-riscv.h b/include/configs/qemu-riscv.h
> index 22a5cd7365..b7110edebc 100644
> --- a/include/configs/qemu-riscv.h
> +++ b/include/configs/qemu-riscv.h
> @@ -48,4 +48,8 @@
> "ramdisk_addr_r=0x8830\0" \
> BOOTENV
>
> +#define CONFIG_PREBOOT \
> + "setenv fdt_addr ${fdtcontroladdr};" \
> + "fdt addr ${fdtcontroladdr};"
> +
> #endif /* __CONFIG_H */
> --
> 2.20.1
Looks good to me.
Reviewed-by: Anup Patel
Regards,
Anup
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] riscv: set CONFIG_SYS_BOOTM_LEN to SZ_64M
> -Original Message- > From: David Abdurachmanov > Sent: Tuesday, April 9, 2019 4:13 PM > To: r...@andestech.com; Atish Patra ; Anup Patel > ; lukas.a...@aisec.fraunhofer.de; u- > b...@lists.denx.de > Cc: David Abdurachmanov > Subject: [PATCH 1/2] riscv: set CONFIG_SYS_BOOTM_LEN to SZ_64M > > After updating Fedora/RISCV kernel to 5.1-rc3+ the size increased above the > current threshold. Looking into HiKey, Dragonboards, etc. seems that > SZ_64M is a popular option. > > This sucessfully boots Fedora/RISCV with 5.1-rc3+ kernel on QEMU 4.0 > (master) with OpenSBI -> U-Boot (S-mode) [extlinux] -> Kernel setup. > > Signed-off-by: David Abdurachmanov > --- > include/configs/qemu-riscv.h | 12 ++-- > 1 file changed, 6 insertions(+), 6 deletions(-) > > diff --git a/include/configs/qemu-riscv.h b/include/configs/qemu-riscv.h > index 2588c5a0b2..22a5cd7365 100644 > --- a/include/configs/qemu-riscv.h > +++ b/include/configs/qemu-riscv.h > @@ -15,7 +15,7 @@ > > #define CONFIG_SYS_MALLOC_LENSZ_8M > > -#define CONFIG_SYS_BOOTM_LEN SZ_16M > +#define CONFIG_SYS_BOOTM_LEN SZ_64M > > #define CONFIG_STANDALONE_LOAD_ADDR 0x8020 > > @@ -41,11 +41,11 @@ > #define CONFIG_EXTRA_ENV_SETTINGS \ > "fdt_high=0x\0" \ > "initrd_high=0x\0" \ > - "kernel_addr_r=0x8100\0" \ > - "fdt_addr_r=0x8200\0" \ > - "scriptaddr=0x8210\0" \ > - "pxefile_addr_r=0x8220\0" \ > - "ramdisk_addr_r=0x8230\0" \ > + "kernel_addr_r=0x8400\0" \ > + "fdt_addr_r=0x8800\0" \ > + "scriptaddr=0x8810\0" \ > + "pxefile_addr_r=0x8820\0" \ > + "ramdisk_addr_r=0x8830\0" \ > BOOTENV > > #endif /* __CONFIG_H */ > -- > 2.20.1 Looks good to me. Reviewed-by: Anup Patel Regards, Anup ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 3/3] i2c: muxes: pca954x: support PCA9543 I2C switch
Hello Luca, Am 09.04.2019 um 08:57 schrieb Luca Ceresoli: The PCA9543 is a 2-channel I2C switch. Signed-off-by: Luca Ceresoli Reviewed-by: Heiko Schocher --- Changes v1 -> v2: - rebase on current tree --- drivers/i2c/muxes/Kconfig | 3 ++- drivers/i2c/muxes/pca954x.c | 6 ++ 2 files changed, 8 insertions(+), 1 deletion(-) Applied to u-boot-i2c.git master Thanks! bye, Heiko -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-52 Fax: +49-8142-66989-80 Email: h...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/3] i2c: muxes: pca954x: clarify enable field
Hello Luca, Am 09.04.2019 um 08:57 schrieb Luca Ceresoli: The chip_desc.enable field is used only for muxes, not for switches. Document it and remove the unused values. Signed-off-by: Luca Ceresoli Reviewed-by: Heiko Schocher --- Changes v1 -> v2: - fix typo in commit message (Michal) --- drivers/i2c/muxes/pca954x.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) Applied to u-boot-i2c.git master Thanks! bye, Heiko -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-52 Fax: +49-8142-66989-80 Email: h...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/3] i2c: muxes: pca954x: update list of supported devices
Hello Luca, Am 09.04.2019 um 08:57 schrieb Luca Ceresoli: The Kconfig help has not been updated while adding PCA9547 and PCA9646. Signed-off-by: Luca Ceresoli --- Changes v1 -> v2: - add missing comma (Michal) - reword and rewrap the sentence --- drivers/i2c/muxes/Kconfig | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) Applied to u-boot-i2c.git master Thanks! bye, Heiko -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-52 Fax: +49-8142-66989-80 Email: h...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] DTS: imx53: Add imx53-kp-u-boot.dtsi file with u-boot specific property
Hello Lukasz, Am 04.04.2019 um 12:35 schrieb Lukasz Majewski: This file adds the "u-boot,i2c-transaction-bytes" to mc34708 PMIC. Signed-off-by: Lukasz Majewski --- arch/arm/dts/imx53-kp-u-boot.dtsi | 10 ++ 1 file changed, 10 insertions(+) create mode 100644 arch/arm/dts/imx53-kp-u-boot.dtsi Applied to u-boot-i2c.git master Thanks! bye, Heiko -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-52 Fax: +49-8142-66989-80 Email: h...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] DM: I2C: Introduce 'u-boot, i2c-transaction-bytes' property
Hello Lukasz, Am 04.04.2019 um 12:35 schrieb Lukasz Majewski: The 'u-boot,i2c-transaction-bytes' device tree property provides information regarding number of bytes transferred by a device in a single transaction. This change is necessary to avoid hanging devices after soft reset. One notable example is communication with MC34708 device: 1. Reset when communicating with MC34708 via I2C. 2. The u-boot (after reboot -f) tries to setup the I2C and then calls force_idle_bus. In the same time MC34708 still has some data to be sent (as it transfers data in 24 bits chunks). 3. The force_idle_bus() is not able to make the bus idle as 8 SCL clocks may be not enough to have the full transmission. 4. We end up with I2C inconsistency with MC34708. This PMIC device requires 24+ SCL cycles to make finish any pending I2C transmission. Signed-off-by: Lukasz Majewski --- doc/device-tree-bindings/i2c/i2c.txt | 5 + drivers/i2c/i2c-uclass.c | 24 drivers/i2c/mxc_i2c.c| 19 +-- include/i2c.h| 2 ++ 4 files changed, 48 insertions(+), 2 deletions(-) Applied to u-boot-i2c.git master Thanks! bye, Heiko -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-52 Fax: +49-8142-66989-80 Email: h...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] misc: i2c_eeprom: add eeprom write support
Hello Baruch, Am 07.04.2019 um 11:38 schrieb Baruch Siach: Write up to page size in each i2c transfer. Signed-off-by: Baruch Siach --- drivers/misc/i2c_eeprom.c | 20 +++- 1 file changed, 19 insertions(+), 1 deletion(-) Applied to u-boot-i2c.git master Thanks! bye, Heiko -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-52 Fax: +49-8142-66989-80 Email: h...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] misc: i2c_eeprom: support DT pagesize property
Hello Baruch, Am 07.04.2019 um 11:38 schrieb Baruch Siach: Read the page size from DT when available. Signed-off-by: Baruch Siach --- drivers/misc/i2c_eeprom.c | 6 ++ 1 file changed, 6 insertions(+) Applied to u-boot-i2c.git master Thanks! bye, Heiko -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-52 Fax: +49-8142-66989-80 Email: h...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] i2c: mvtwsi: fix hang on SPL bind
Hello Baruch, Am 07.04.2019 um 11:30 schrieb Baruch Siach: The mvebu specific debug register is not accessible when the bind code runs in SPL. Skip it. Signed-off-by: Baruch Siach --- drivers/i2c/mvtwsi.c | 4 1 file changed, 4 insertions(+) Applied to u-boot-i2c.git master Thanks! bye, Heiko -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-52 Fax: +49-8142-66989-80 Email: h...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] misc: i2c_eeprom: add eeprom write support
Hello Baruch, Am 07.04.2019 um 11:38 schrieb Baruch Siach: Write up to page size in each i2c transfer. Signed-off-by: Baruch Siach --- drivers/misc/i2c_eeprom.c | 20 +++- 1 file changed, 19 insertions(+), 1 deletion(-) Reviewed-by: Heiko Schocher bye, Heiko -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-52 Fax: +49-8142-66989-80 Email: h...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] misc: i2c_eeprom: support DT pagesize property
Hello Baruch, Am 07.04.2019 um 11:38 schrieb Baruch Siach: Read the page size from DT when available. Signed-off-by: Baruch Siach --- drivers/misc/i2c_eeprom.c | 6 ++ 1 file changed, 6 insertions(+) Reviewed-by: Heiko Schocher bye, Heiko -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-52 Fax: +49-8142-66989-80 Email: h...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/2] Revert "cmd: Kconfig: Do not include EEPROM if DM_I2C is used without DM_I2C_COMPAT"
Hello Heiko,
On Wed, Apr 10, 2019 at 7:20 AM Heiko Schocher wrote:
>
> Hello Marek, Simon,
>
> Am 09.04.2019 um 21:30 schrieb Marek Vasut:
> > On 4/9/19 8:53 PM, Simon Goldschmidt wrote:
> >> Am 30.03.2019 um 22:18 schrieb Simon Glass:
> >>> On Tue, 26 Mar 2019 at 06:39, Simon Goldschmidt
> >>> wrote:
>
> This reverts commit 65a97e7fcf54feb7c4ebe1aee8a572830af4cf51.
>
> The 'eeprom' command has been converted to work with DM_I2C in a patch
> submitted around the same time as this commit:
> commit 0c07a9b4078d ("eeprom: Add device model based I2C support to
> eeprom command")
>
> Signed-off-by: Simon Goldschmidt
> ---
>
> Changes in v2:
> - added patch to fix DM_I2C eeprom code to work without
> CONFIG_SYS_I2C_EEPROM_BUS
>
> cmd/Kconfig | 1 -
> 1 file changed, 1 deletion(-)
> >>>
> >>> Reviewed-by: Simon Glass
> >>>
> >>
> >>
> >> Who will take this series? It's assigned in to Marek in patchwork, but
> >> might go via Heiko's i2c tree? Or directly via Tom?
> >>
> >> I have sent patches (move socfpga_vining to DM_I2C) that are based on
> >> this series...
> >
> > Heiko should at least AB/RB it , then I can take it via socfpga tree to
> > avoid dependency problems.
>
> Just add to this patches my RB tag, so please pick it up, to prevent
> dependency problems, thanks!
OK, I'll do that.
Thanks,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/2] Revert "cmd: Kconfig: Do not include EEPROM if DM_I2C is used without DM_I2C_COMPAT"
Hello Marek, Simon,
Am 09.04.2019 um 21:30 schrieb Marek Vasut:
On 4/9/19 8:53 PM, Simon Goldschmidt wrote:
Am 30.03.2019 um 22:18 schrieb Simon Glass:
On Tue, 26 Mar 2019 at 06:39, Simon Goldschmidt
wrote:
This reverts commit 65a97e7fcf54feb7c4ebe1aee8a572830af4cf51.
The 'eeprom' command has been converted to work with DM_I2C in a patch
submitted around the same time as this commit:
commit 0c07a9b4078d ("eeprom: Add device model based I2C support to
eeprom command")
Signed-off-by: Simon Goldschmidt
---
Changes in v2:
- added patch to fix DM_I2C eeprom code to work without
CONFIG_SYS_I2C_EEPROM_BUS
cmd/Kconfig | 1 -
1 file changed, 1 deletion(-)
Reviewed-by: Simon Glass
Who will take this series? It's assigned in to Marek in patchwork, but
might go via Heiko's i2c tree? Or directly via Tom?
I have sent patches (move socfpga_vining to DM_I2C) that are based on
this series...
Heiko should at least AB/RB it , then I can take it via socfpga tree to
avoid dependency problems.
Just add to this patches my RB tag, so please pick it up, to prevent
dependency problems, thanks!
bye,
Heiko
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-52 Fax: +49-8142-66989-80 Email: h...@denx.de
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/2] eeprom: fix DM_I2C support without CONFIG_SYS_I2C_EEPROM_BUS
Hello Simon, Am 26.03.2019 um 13:38 schrieb Simon Goldschmidt: The current device model enabled eeprom code only works if CONFIG_SYS_I2C_EEPROM_BUS is set. This patch makes it work without that define so that the bus number passed to 'eeprom_init' is used. Signed-off-by: Simon Goldschmidt --- Changes in v2: None cmd/eeprom.c | 23 +++ 1 file changed, 15 insertions(+), 8 deletions(-) Reviewed-by: Heiko Schocher bye, Heiko -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-52 Fax: +49-8142-66989-80 Email: h...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/2] Revert "cmd: Kconfig: Do not include EEPROM if DM_I2C is used without DM_I2C_COMPAT"
Hello Simon,
Am 26.03.2019 um 13:38 schrieb Simon Goldschmidt:
This reverts commit 65a97e7fcf54feb7c4ebe1aee8a572830af4cf51.
The 'eeprom' command has been converted to work with DM_I2C in a patch
submitted around the same time as this commit:
commit 0c07a9b4078d ("eeprom: Add device model based I2C support to eeprom
command")
Signed-off-by: Simon Goldschmidt
---
Changes in v2:
- added patch to fix DM_I2C eeprom code to work without
CONFIG_SYS_I2C_EEPROM_BUS
Reviewed-by: Heiko Schocher
bye,
Heiko
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-52 Fax: +49-8142-66989-80 Email: h...@denx.de
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RFC PATCH v2] MLK-12883 usb: limit USB_MAX_XFER_BLK to 256
On Tue, 9 Apr 2019 17:14:26 -0400 Tom Rini wrote: > On Tue, Apr 09, 2019 at 05:20:45PM +0200, Marcel Ziswiler wrote: > > > From: Peng Fan > > > > For Some USB mass storage devices, such as: > > " > > - Kingston DataTraveler 2.0 001D7D06CF09B04199C7B3EA > > - Class: (from Interface) Mass Storage > > - PacketSize: 64 Configurations: 1 > > - Vendor: 0x0930 Product 0x6545 Version 1.16 > > " > > When `usb read 0x8000 0 0x2000`, we met > > "EHCI timed out on TD - token=0x80008d80". > > > > The devices does not support scsi VPD page, we are not able > > to get the maximum transfer length for READ(10)/WRITE(10). > > > > So we limit this to 256 blocks as READ(6). > > > > Signed-off-by: Peng Fan > > Acked-by: Marcel Ziswiler > > (cherry picked from commit df0052575b2bc9d66ae73584768e1a457ed5d914) > > > > --- > > This comes from NXP's downstream and has proven to tremendously > > improve the situation with those odd USB mass storage aka memory > > sticks. This is why I post it here asking whether or not this may > > be something benefiting more people. Any feedback and suggestions > > are welcome. > > > > Changes in v2: > > - Fixed spelling in comment as suggested by Igor. > > > > common/usb_storage.c | 6 +- > > 1 file changed, 5 insertions(+), 1 deletion(-) > > > > diff --git a/common/usb_storage.c b/common/usb_storage.c > > index 8c889bb1a6..4e284645f5 100644 > > --- a/common/usb_storage.c > > +++ b/common/usb_storage.c > > @@ -949,7 +949,11 @@ static void usb_stor_set_max_xfer_blk(struct > > usb_device *udev, > > * there is enough free heap space left, but the SCSI > > READ(10) and > > * WRITE(10) commands are limited to 65535 blocks. > > */ > > - blk = USHRT_MAX; > > + /* > > +* Some USB mass storage devices have issues, limiting > > this to 256 Could you name those devices? > > +* fixes this. > > +*/ > > + blk = 256; > > #else > > blk = 20; > > #endif > > -- > > 2.20.1 > > Adding in Lukasz now that get_maintainers.pl shows this should be > Cc'd to him as well, thanks! > Best regards, Lukasz Majewski -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lu...@denx.de pgpN4YgMCea8u.pgp Description: OpenPGP digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2] ARM: dts: i.MX6Q: fix avoid_unnecessary_addr_size warnings
On Tue, 9 Apr 2019 17:21:13 +0200 Marcel Ziswiler wrote: > From: Marcel Ziswiler > > Re-synced the device tree with Linux 5.0. > > This fixes the following warnings: > > w+arch/arm/dts/imx6-apalis.dtb: Warning > (reg_format): /soc/ipu@280/ port@2/endpoint@0:reg: property has > invalid length (4 bytes) (#address-cells == 2, #size-cells == 1) > w+arch/arm/dts/imx6-apalis.dtb: Warning > (reg_format): /soc/ipu@280/ port@2/endpoint@1:reg: property has > invalid length (4 bytes) (#address-cells == 2, #size-cells == 1) > w+arch/arm/dts/imx6-apalis.dtb: Warning > (reg_format): /soc/ipu@280/ port@2/endpoint@2:reg: property has > invalid length (4 bytes) (#address-cells == 2, #size-cells == 1) > w+arch/arm/dts/imx6-apalis.dtb: Warning > (reg_format): /soc/ipu@280/ port@2/endpoint@3:reg: property has > invalid length (4 bytes) (#address-cells == 2, #size-cells == 1) > w+arch/arm/dts/imx6-apalis.dtb: Warning > (reg_format): /soc/ipu@280/ port@2/endpoint@4:reg: property has > invalid length (4 bytes) (#address-cells == 2, #size-cells == 1) > w+arch/arm/dts/imx6-apalis.dtb: Warning > (reg_format): /soc/ipu@280/ port@3/endpoint@1:reg: property has > invalid length (4 bytes) (#address-cells == 2, #size-cells == 1) > w+arch/arm/dts/imx6-apalis.dtb: Warning > (reg_format): /soc/ipu@280/ port@3/endpoint@2:reg: property has > invalid length (4 bytes) (#address-cells == 2, #size-cells == 1) > w+arch/arm/dts/imx6-apalis.dtb: Warning > (reg_format): /soc/ipu@280/ port@3/endpoint@3:reg: property has > invalid length (4 bytes) (#address-cells == 2, #size-cells == 1) > w+arch/arm/dts/imx6-apalis.dtb: Warning > (reg_format): /soc/ipu@280/ port@3/endpoint@4:reg: property has > invalid length (4 bytes) (#address-cells == 2, #size-cells == 1) > w+arch/arm/dts/imx6-apalis.dtb: Warning (avoid_default_addr_size): > /soc/ipu@280/port@2/endpoint@0: Relying on default #address-cells > value > w+arch/arm/dts/imx6-apalis.dtb: Warning (avoid_default_addr_size): > /soc/ipu@280/port@2/endpoint@0: Relying on default #size-cells > value > w+arch/arm/dts/imx6-apalis.dtb: Warning (avoid_default_addr_size): > /soc/ipu@280/port@2/endpoint@1: Relying on default #address-cells > value > w+arch/arm/dts/imx6-apalis.dtb: Warning (avoid_default_addr_size): > /soc/ipu@280/port@2/endpoint@1: Relying on default #size-cells > value > w+arch/arm/dts/imx6-apalis.dtb: Warning (avoid_default_addr_size): > /soc/ipu@280/port@2/endpoint@2: Relying on default #address-cells > value > w+arch/arm/dts/imx6-apalis.dtb: Warning (avoid_default_addr_size): > /soc/ipu@280/port@2/endpoint@2: Relying on default #size-cells > value > w+arch/arm/dts/imx6-apalis.dtb: Warning (avoid_default_addr_size): > /soc/ipu@280/port@2/endpoint@3: Relying on default #address-cells > value > w+arch/arm/dts/imx6-apalis.dtb: Warning (avoid_default_addr_size): > /soc/ipu@280/port@2/endpoint@3: Relying on default #size-cells > value > w+arch/arm/dts/imx6-apalis.dtb: Warning (avoid_default_addr_size): > /soc/ipu@280/port@2/endpoint@4: Relying on default #address-cells > value > w+arch/arm/dts/imx6-apalis.dtb: Warning (avoid_default_addr_size): > /soc/ipu@280/port@2/endpoint@4: Relying on default #size-cells > value > w+arch/arm/dts/imx6-apalis.dtb: Warning (avoid_default_addr_size): > /soc/ipu@280/port@3/endpoint@1: Relying on default #address-cells > value > w+arch/arm/dts/imx6-apalis.dtb: Warning (avoid_default_addr_size): > /soc/ipu@280/port@3/endpoint@1: Relying on default #size-cells > value > w+arch/arm/dts/imx6-apalis.dtb: Warning (avoid_default_addr_size): > /soc/ipu@280/port@3/endpoint@2: Relying on default #address-cells > value > w+arch/arm/dts/imx6-apalis.dtb: Warning (avoid_default_addr_size): > /soc/ipu@280/port@3/endpoint@2: Relying on default #size-cells > value > w+arch/arm/dts/imx6-apalis.dtb: Warning (avoid_default_addr_size): > /soc/ipu@280/port@3/endpoint@3: Relying on default #address-cells > value > w+arch/arm/dts/imx6-apalis.dtb: Warning (avoid_default_addr_size): > /soc/ipu@280/port@3/endpoint@3: Relying on default #size-cells > value > w+arch/arm/dts/imx6-apalis.dtb: Warning (avoid_default_addr_size): > /soc/ipu@280/port@3/endpoint@4: Relying on default #address-cells > value > w+arch/arm/dts/imx6-apalis.dtb: Warning (avoid_default_addr_size): > /soc/ipu@280/port@3/endpoint@4: Relying on default #size-cells > value > w+arch/arm/dts/imx6-apalis.dtb: Warning (avoid_unnecessary_addr_size): > Failed prerequisite 'avoid_default_addr_size' > > Signed-off-by: Marcel Ziswiler > > --- > > Changes in v2: > - Re-synced the device tree with Linux 5.0 as suggested by Fabio. > > arch/arm/dts/imx6q.dtsi | 5 + > 1 file changed, 5 insertions(+) > > diff --git a/arch/arm/dts/imx6q.dtsi b/arch/arm/dts/imx6q.dtsi > index ab1716b6b0..d038f41170 100644 > --- a/arch/arm/dts/imx6q.dtsi > +++ b/arch/arm/dts/imx6q.dtsi > @@ -202,6 +202,7
Re: [U-Boot] [U-Boot, RESEND, v5, 3/7] test: fs: Add filesystem integrity checks
On Wed, Apr 10, 2019 at 11:51:20AM +0900, Takahiro Akashi wrote: > On Tue, Apr 09, 2019 at 10:25:14PM -0400, Tom Rini wrote: > > On Wed, Apr 10, 2019 at 10:37:42AM +0900, Takahiro Akashi wrote: > > > On Tue, Apr 09, 2019 at 08:19:40PM -0400, Tom Rini wrote: > > > > On Wed, Apr 10, 2019 at 02:10:12AM +0200, Heinrich Schuchardt wrote: > > > > > On 4/9/19 10:03 PM, Tom Rini wrote: > > > > > > On Wed, Feb 13, 2019 at 12:15:23PM +0100, Jean-Jacques Hiblot wrote: > > > > > > > > > > > >> We need to make sure that file writes,file creation, etc. are > > > > > >> properly > > > > > >> performed and do not corrupt the filesystem. > > > > > >> To help with this, introduce the assert_fs_integrity() function > > > > > >> that > > > > > >> executes the appropriate fsck tool. It should be called at the end > > > > > >> of any > > > > > >> test that modify the content/organization of the filesystem. > > > > > >> Currently only supports FATs and EXT4. > > > > > >> > > > > > >> Signed-off-by: Jean-Jacques Hiblot > > > > > >> Reviewed-by: Tom Rini > > > > > > > > > > > > OK, I'm adding in a bunch of people to CC here. The issue with this > > > > > > patch is that by adding fsck to our tests we see 34 FAT16/FAT32 > > > > > > failures: > > > > > > TestFsBasic.test_fs13[fat16] > > > > > > TestFsBasic.test_fs11[fat32] > > > > > > TestFsBasic.test_fs12[fat32] > > > > > > TestFsBasic.test_fs13[fat32] > > > > > > TestFsExt.test_fs_ext1[fat32] > > > > > > TestFsExt.test_fs_ext2[fat32] > > > > > > TestFsExt.test_fs_ext3[fat32] > > > > > > TestFsExt.test_fs_ext4[fat32] > > > > > > TestFsExt.test_fs_ext5[fat32] > > > > > > TestFsExt.test_fs_ext6[fat32] > > > > > > TestFsExt.test_fs_ext7[fat32] > > > > > > TestFsExt.test_fs_ext8[fat32] > > > > > > TestFsExt.test_fs_ext9[fat32] > > > > > > TestMkdir.test_mkdir6[fat16] > > > > > > TestMkdir.test_mkdir1[fat32] > > > > > > TestMkdir.test_mkdir2[fat32] > > > > > > TestMkdir.test_mkdir3[fat32] > > > > > > TestMkdir.test_mkdir4[fat32] > > > > > > TestMkdir.test_mkdir5[fat32] > > > > > > TestMkdir.test_mkdir6[fat32] > > > > > > TestUnlink.test_unlink1[fat16] > > > > > > TestUnlink.test_unlink2[fat16] > > > > > > TestUnlink.test_unlink3[fat16] > > > > > > TestUnlink.test_unlink4[fat16] > > > > > > TestUnlink.test_unlink5[fat16] > > > > > > TestUnlink.test_unlink6[fat16] > > > > > > TestUnlink.test_unlink7[fat16] > > > > > > TestUnlink.test_unlink1[fat32] > > > > > > TestUnlink.test_unlink2[fat32] > > > > > > TestUnlink.test_unlink3[fat32] > > > > > > TestUnlink.test_unlink4[fat32] > > > > > > TestUnlink.test_unlink5[fat32] > > > > > > TestUnlink.test_unlink6[fat32] > > > > > > TestUnlink.test_unlink7[fat32] > > > > > > > > > > I appreciate that we get tests for file system functions. > > > > > > > > > > Unfortunately the test output is rudimentary. Can we have something > > > > > more > > > > > expressive than unlink1 - unlink7? > > > > > > > > > > CCing Takahiro as he was contributing recently to FAT. > > > > > > > > Sorry, yes, kind of? I pasted that in for brevity, but it's basically > > > > that for example all of test/py/tests/test_fs/test_unlink.py fails if > > > > you fsck the image in question after each test. If you apply > > > > https://patchwork.ozlabs.org/patch/1041186/ (to avoid spurious ext4 > > > > failures) and then https://patchwork.ozlabs.org/patch/1041181/ and run > > > > 'make tests' you'll see the full output. > > > > > > I have no time to dig into this issue right now, > > > but if you give me a log from fsck, particularly > > > why fsck failed here, it would help me to understand > > > the problem. > > > > The raw log can be seen here: > > https://gist.github.com/trini/b68799ed9880a31a3289e9bea033831d > > Thanks. I can find error messages like: > Free cluster summary wrong (144636 vs. really 144380) > > So there seems to be a leak in reclaiming freed clusters. A count of free clusters, along with other info, is kept in an "info sector" on a file system (only for fat32), but in U-Boot fat, none of information in that sector is currently maintained. So this error would be inevitable. I don't know any fsck option to suppress this kind of check. -Takahiro Akashi > > > # like the case of ext4, we might have to turn off > > > # some option at fsck? > > > > Note that for ext4 we're turning off the metadata csum feature of the > > filesystem as we do not support it. > > I'm afraid that this is not the case. > > -Takahiro Akashi > > > -- > > Tom > > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, RESEND, v5, 3/7] test: fs: Add filesystem integrity checks
On Tue, Apr 09, 2019 at 10:25:14PM -0400, Tom Rini wrote: > On Wed, Apr 10, 2019 at 10:37:42AM +0900, Takahiro Akashi wrote: > > On Tue, Apr 09, 2019 at 08:19:40PM -0400, Tom Rini wrote: > > > On Wed, Apr 10, 2019 at 02:10:12AM +0200, Heinrich Schuchardt wrote: > > > > On 4/9/19 10:03 PM, Tom Rini wrote: > > > > > On Wed, Feb 13, 2019 at 12:15:23PM +0100, Jean-Jacques Hiblot wrote: > > > > > > > > > >> We need to make sure that file writes,file creation, etc. are > > > > >> properly > > > > >> performed and do not corrupt the filesystem. > > > > >> To help with this, introduce the assert_fs_integrity() function that > > > > >> executes the appropriate fsck tool. It should be called at the end > > > > >> of any > > > > >> test that modify the content/organization of the filesystem. > > > > >> Currently only supports FATs and EXT4. > > > > >> > > > > >> Signed-off-by: Jean-Jacques Hiblot > > > > >> Reviewed-by: Tom Rini > > > > > > > > > > OK, I'm adding in a bunch of people to CC here. The issue with this > > > > > patch is that by adding fsck to our tests we see 34 FAT16/FAT32 > > > > > failures: > > > > > TestFsBasic.test_fs13[fat16] > > > > > TestFsBasic.test_fs11[fat32] > > > > > TestFsBasic.test_fs12[fat32] > > > > > TestFsBasic.test_fs13[fat32] > > > > > TestFsExt.test_fs_ext1[fat32] > > > > > TestFsExt.test_fs_ext2[fat32] > > > > > TestFsExt.test_fs_ext3[fat32] > > > > > TestFsExt.test_fs_ext4[fat32] > > > > > TestFsExt.test_fs_ext5[fat32] > > > > > TestFsExt.test_fs_ext6[fat32] > > > > > TestFsExt.test_fs_ext7[fat32] > > > > > TestFsExt.test_fs_ext8[fat32] > > > > > TestFsExt.test_fs_ext9[fat32] > > > > > TestMkdir.test_mkdir6[fat16] > > > > > TestMkdir.test_mkdir1[fat32] > > > > > TestMkdir.test_mkdir2[fat32] > > > > > TestMkdir.test_mkdir3[fat32] > > > > > TestMkdir.test_mkdir4[fat32] > > > > > TestMkdir.test_mkdir5[fat32] > > > > > TestMkdir.test_mkdir6[fat32] > > > > > TestUnlink.test_unlink1[fat16] > > > > > TestUnlink.test_unlink2[fat16] > > > > > TestUnlink.test_unlink3[fat16] > > > > > TestUnlink.test_unlink4[fat16] > > > > > TestUnlink.test_unlink5[fat16] > > > > > TestUnlink.test_unlink6[fat16] > > > > > TestUnlink.test_unlink7[fat16] > > > > > TestUnlink.test_unlink1[fat32] > > > > > TestUnlink.test_unlink2[fat32] > > > > > TestUnlink.test_unlink3[fat32] > > > > > TestUnlink.test_unlink4[fat32] > > > > > TestUnlink.test_unlink5[fat32] > > > > > TestUnlink.test_unlink6[fat32] > > > > > TestUnlink.test_unlink7[fat32] > > > > > > > > I appreciate that we get tests for file system functions. > > > > > > > > Unfortunately the test output is rudimentary. Can we have something more > > > > expressive than unlink1 - unlink7? > > > > > > > > CCing Takahiro as he was contributing recently to FAT. > > > > > > Sorry, yes, kind of? I pasted that in for brevity, but it's basically > > > that for example all of test/py/tests/test_fs/test_unlink.py fails if > > > you fsck the image in question after each test. If you apply > > > https://patchwork.ozlabs.org/patch/1041186/ (to avoid spurious ext4 > > > failures) and then https://patchwork.ozlabs.org/patch/1041181/ and run > > > 'make tests' you'll see the full output. > > > > I have no time to dig into this issue right now, > > but if you give me a log from fsck, particularly > > why fsck failed here, it would help me to understand > > the problem. > > The raw log can be seen here: > https://gist.github.com/trini/b68799ed9880a31a3289e9bea033831d Thanks. I can find error messages like: Free cluster summary wrong (144636 vs. really 144380) So there seems to be a leak in reclaiming freed clusters. > > # like the case of ext4, we might have to turn off > > # some option at fsck? > > Note that for ext4 we're turning off the metadata csum feature of the > filesystem as we do not support it. I'm afraid that this is not the case. -Takahiro Akashi > -- > Tom ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, RESEND, v5, 3/7] test: fs: Add filesystem integrity checks
On Wed, Apr 10, 2019 at 10:37:42AM +0900, Takahiro Akashi wrote: > On Tue, Apr 09, 2019 at 08:19:40PM -0400, Tom Rini wrote: > > On Wed, Apr 10, 2019 at 02:10:12AM +0200, Heinrich Schuchardt wrote: > > > On 4/9/19 10:03 PM, Tom Rini wrote: > > > > On Wed, Feb 13, 2019 at 12:15:23PM +0100, Jean-Jacques Hiblot wrote: > > > > > > > >> We need to make sure that file writes,file creation, etc. are properly > > > >> performed and do not corrupt the filesystem. > > > >> To help with this, introduce the assert_fs_integrity() function that > > > >> executes the appropriate fsck tool. It should be called at the end of > > > >> any > > > >> test that modify the content/organization of the filesystem. > > > >> Currently only supports FATs and EXT4. > > > >> > > > >> Signed-off-by: Jean-Jacques Hiblot > > > >> Reviewed-by: Tom Rini > > > > > > > > OK, I'm adding in a bunch of people to CC here. The issue with this > > > > patch is that by adding fsck to our tests we see 34 FAT16/FAT32 > > > > failures: > > > > TestFsBasic.test_fs13[fat16] > > > > TestFsBasic.test_fs11[fat32] > > > > TestFsBasic.test_fs12[fat32] > > > > TestFsBasic.test_fs13[fat32] > > > > TestFsExt.test_fs_ext1[fat32] > > > > TestFsExt.test_fs_ext2[fat32] > > > > TestFsExt.test_fs_ext3[fat32] > > > > TestFsExt.test_fs_ext4[fat32] > > > > TestFsExt.test_fs_ext5[fat32] > > > > TestFsExt.test_fs_ext6[fat32] > > > > TestFsExt.test_fs_ext7[fat32] > > > > TestFsExt.test_fs_ext8[fat32] > > > > TestFsExt.test_fs_ext9[fat32] > > > > TestMkdir.test_mkdir6[fat16] > > > > TestMkdir.test_mkdir1[fat32] > > > > TestMkdir.test_mkdir2[fat32] > > > > TestMkdir.test_mkdir3[fat32] > > > > TestMkdir.test_mkdir4[fat32] > > > > TestMkdir.test_mkdir5[fat32] > > > > TestMkdir.test_mkdir6[fat32] > > > > TestUnlink.test_unlink1[fat16] > > > > TestUnlink.test_unlink2[fat16] > > > > TestUnlink.test_unlink3[fat16] > > > > TestUnlink.test_unlink4[fat16] > > > > TestUnlink.test_unlink5[fat16] > > > > TestUnlink.test_unlink6[fat16] > > > > TestUnlink.test_unlink7[fat16] > > > > TestUnlink.test_unlink1[fat32] > > > > TestUnlink.test_unlink2[fat32] > > > > TestUnlink.test_unlink3[fat32] > > > > TestUnlink.test_unlink4[fat32] > > > > TestUnlink.test_unlink5[fat32] > > > > TestUnlink.test_unlink6[fat32] > > > > TestUnlink.test_unlink7[fat32] > > > > > > I appreciate that we get tests for file system functions. > > > > > > Unfortunately the test output is rudimentary. Can we have something more > > > expressive than unlink1 - unlink7? > > > > > > CCing Takahiro as he was contributing recently to FAT. > > > > Sorry, yes, kind of? I pasted that in for brevity, but it's basically > > that for example all of test/py/tests/test_fs/test_unlink.py fails if > > you fsck the image in question after each test. If you apply > > https://patchwork.ozlabs.org/patch/1041186/ (to avoid spurious ext4 > > failures) and then https://patchwork.ozlabs.org/patch/1041181/ and run > > 'make tests' you'll see the full output. > > I have no time to dig into this issue right now, > but if you give me a log from fsck, particularly > why fsck failed here, it would help me to understand > the problem. The raw log can be seen here: https://gist.github.com/trini/b68799ed9880a31a3289e9bea033831d > # like the case of ext4, we might have to turn off > # some option at fsck? Note that for ext4 we're turning off the metadata csum feature of the filesystem as we do not support it. -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 0/6] pico-imx7d: Add support for BL33 case
Otavio Salvador 于2019年4月4日周四 下午8:40写道： > > On Wed, Apr 3, 2019 at 9:00 AM Jun Nie wrote: > > And for the file name pico-imx7d_bl33_defconfig, > > pico-pi-imx7d_bl33_defconfig should be better in my later thought. > > Because a concrete device tree source file should be specified in > > defconfig file, so that public key can be stored in u-boot FDT blob > > for kernel/initramfs FIT signature verification. What's your comments? > > The FIT image might have them all, no? It would allow a single binary > to work on all baseboards, giving a very nice user experience. The FIT image have all device trees. I mean the device tree for u-boot should be specified. As device trees are copied from kernel, while there is no dts file for pico-imx7d. It is a bit peculiar if you specify device tree as pico-pi-imx7d in pico-imx7d_bl33_defconfig. > > -- > Otavio Salvador O.S. Systems > http://www.ossystems.com.brhttp://code.ossystems.com.br > Mobile: +55 (53) 9 9981-7854 Mobile: +1 (347) 903-9750 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, RESEND, v5, 3/7] test: fs: Add filesystem integrity checks
On Tue, Apr 09, 2019 at 08:19:40PM -0400, Tom Rini wrote: > On Wed, Apr 10, 2019 at 02:10:12AM +0200, Heinrich Schuchardt wrote: > > On 4/9/19 10:03 PM, Tom Rini wrote: > > > On Wed, Feb 13, 2019 at 12:15:23PM +0100, Jean-Jacques Hiblot wrote: > > > > > >> We need to make sure that file writes,file creation, etc. are properly > > >> performed and do not corrupt the filesystem. > > >> To help with this, introduce the assert_fs_integrity() function that > > >> executes the appropriate fsck tool. It should be called at the end of any > > >> test that modify the content/organization of the filesystem. > > >> Currently only supports FATs and EXT4. > > >> > > >> Signed-off-by: Jean-Jacques Hiblot > > >> Reviewed-by: Tom Rini > > > > > > OK, I'm adding in a bunch of people to CC here. The issue with this > > > patch is that by adding fsck to our tests we see 34 FAT16/FAT32 > > > failures: > > > TestFsBasic.test_fs13[fat16] > > > TestFsBasic.test_fs11[fat32] > > > TestFsBasic.test_fs12[fat32] > > > TestFsBasic.test_fs13[fat32] > > > TestFsExt.test_fs_ext1[fat32] > > > TestFsExt.test_fs_ext2[fat32] > > > TestFsExt.test_fs_ext3[fat32] > > > TestFsExt.test_fs_ext4[fat32] > > > TestFsExt.test_fs_ext5[fat32] > > > TestFsExt.test_fs_ext6[fat32] > > > TestFsExt.test_fs_ext7[fat32] > > > TestFsExt.test_fs_ext8[fat32] > > > TestFsExt.test_fs_ext9[fat32] > > > TestMkdir.test_mkdir6[fat16] > > > TestMkdir.test_mkdir1[fat32] > > > TestMkdir.test_mkdir2[fat32] > > > TestMkdir.test_mkdir3[fat32] > > > TestMkdir.test_mkdir4[fat32] > > > TestMkdir.test_mkdir5[fat32] > > > TestMkdir.test_mkdir6[fat32] > > > TestUnlink.test_unlink1[fat16] > > > TestUnlink.test_unlink2[fat16] > > > TestUnlink.test_unlink3[fat16] > > > TestUnlink.test_unlink4[fat16] > > > TestUnlink.test_unlink5[fat16] > > > TestUnlink.test_unlink6[fat16] > > > TestUnlink.test_unlink7[fat16] > > > TestUnlink.test_unlink1[fat32] > > > TestUnlink.test_unlink2[fat32] > > > TestUnlink.test_unlink3[fat32] > > > TestUnlink.test_unlink4[fat32] > > > TestUnlink.test_unlink5[fat32] > > > TestUnlink.test_unlink6[fat32] > > > TestUnlink.test_unlink7[fat32] > > > > I appreciate that we get tests for file system functions. > > > > Unfortunately the test output is rudimentary. Can we have something more > > expressive than unlink1 - unlink7? > > > > CCing Takahiro as he was contributing recently to FAT. > > Sorry, yes, kind of? I pasted that in for brevity, but it's basically > that for example all of test/py/tests/test_fs/test_unlink.py fails if > you fsck the image in question after each test. If you apply > https://patchwork.ozlabs.org/patch/1041186/ (to avoid spurious ext4 > failures) and then https://patchwork.ozlabs.org/patch/1041181/ and run > 'make tests' you'll see the full output. I have no time to dig into this issue right now, but if you give me a log from fsck, particularly why fsck failed here, it would help me to understand the problem. # like the case of ext4, we might have to turn off # some option at fsck? Thanks, -Takahiro Akashi > -- > Tom ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RFC PATCH v1] MLK-12883 usb: limit USB_MAX_XFER_BLK to 256
Hi Marcel, > -Original Message- > From: Marcel Ziswiler [mailto:mar...@ziswiler.com] > Sent: 2019年2月2日 0:43 > To: u-boot@lists.denx.de > Cc: Peng Fan ; Marcel Ziswiler > ; Masahiro Yamada > ; Bin Meng ; > Sven Schwermer > Subject: [RFC PATCH v1] MLK-12883 usb: limit USB_MAX_XFER_BLK to 256 Thanks for upstreaming this. The MLK-xxx could be dropped, it is NXP internal tracking number. Regards, Peng. > > From: Peng Fan > > For Some USB mass storage devices, such as: > " > - Kingston DataTraveler 2.0 001D7D06CF09B04199C7B3EA > - Class: (from Interface) Mass Storage > - PacketSize: 64 Configurations: 1 > - Vendor: 0x0930 Product 0x6545 Version 1.16 " > When `usb read 0x8000 0 0x2000`, we met "EHCI timed out on TD - > token=0x80008d80". > > The devices does not support scsi VPD page, we are not able to get the > maximum transfer length for READ(10)/WRITE(10). > > So we limit this to 256 blocks as READ(6). > > Signed-off-by: Peng Fan > Acked-by: Marcel Ziswiler (cherry picked > from commit df0052575b2bc9d66ae73584768e1a457ed5d914) > > --- > This comes from NXP's downstream and has proven to tremendously improve > the situation with those odd USB mass storage aka memory sticks. This is why > I post it here asking whether or not this may be something benefiting more > people. Any feedback and suggestions are welcome. > > common/usb_storage.c | 6 +- > 1 file changed, 5 insertions(+), 1 deletion(-) > > diff --git a/common/usb_storage.c b/common/usb_storage.c index > 8c889bb1a6..7420438363 100644 > --- a/common/usb_storage.c > +++ b/common/usb_storage.c > @@ -949,7 +949,11 @@ static void usb_stor_set_max_xfer_blk(struct > usb_device *udev, >* there is enough free heap space left, but the SCSI READ(10) and >* WRITE(10) commands are limited to 65535 blocks. >*/ > - blk = USHRT_MAX; > + /* > + * Some USB Massstorage devices have issues, limiting this to 256 > + * fixes this. > + */ > + blk = 256; > #else > blk = 20; > #endif > -- > 2.20.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] efi: fix memory calculation overflow on 32-bit systems
On 4/9/19 10:58 PM, Patrick Wildt wrote:
> Hi,
>
> There are Cubox-i machines out there with nearly 4 GiB of RAM. The
> RAM starts at 0x1000 with a size of 0xf000. Thus the end
> of RAM is at 0x1. This overflows a 32-bit integer, which
> should be fine since in the EFI memory code the variables used are
> all 64-bit with a fixed size. Unfortunately EFI_PAGE_MASK, which is
> used in the EFI memory code to remove the lower bits, is based on
> the EFI_PAGE_SIZE macro which, uses 1UL with a shift. This means
> the resulting mask is UL, which is only 32-bit on ARMv7. Use ULL to
> make sure that even on 32-bit platforms we use a 64-bit long mask.
> Without this there will be no memory available in the EFI memory map
> and bootefi will fail allocating pages.
>
> Best regards,
> Patrick
We are using `& ~EFI_PAGE_MASK` in multiplaces for 64bit operations. So
it makes sense to use a 64bit value.
Reviewed-by: Heinrich Schuchardt
>
> diff --git a/include/efi.h b/include/efi.h
> index d98441ab19d..3c9d20f8c0b 100644
> --- a/include/efi.h
> +++ b/include/efi.h
> @@ -190,7 +190,7 @@ enum efi_mem_type {
> #define EFI_MEM_DESC_VERSION 1
>
> #define EFI_PAGE_SHIFT 12
> -#define EFI_PAGE_SIZE(1UL << EFI_PAGE_SHIFT)
> +#define EFI_PAGE_SIZE(1ULL << EFI_PAGE_SHIFT)
> #define EFI_PAGE_MASK(EFI_PAGE_SIZE - 1)
>
> struct efi_mem_desc {
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, RESEND, v5, 3/7] test: fs: Add filesystem integrity checks
On Wed, Apr 10, 2019 at 02:10:12AM +0200, Heinrich Schuchardt wrote: > On 4/9/19 10:03 PM, Tom Rini wrote: > > On Wed, Feb 13, 2019 at 12:15:23PM +0100, Jean-Jacques Hiblot wrote: > > > >> We need to make sure that file writes,file creation, etc. are properly > >> performed and do not corrupt the filesystem. > >> To help with this, introduce the assert_fs_integrity() function that > >> executes the appropriate fsck tool. It should be called at the end of any > >> test that modify the content/organization of the filesystem. > >> Currently only supports FATs and EXT4. > >> > >> Signed-off-by: Jean-Jacques Hiblot > >> Reviewed-by: Tom Rini > > > > OK, I'm adding in a bunch of people to CC here. The issue with this > > patch is that by adding fsck to our tests we see 34 FAT16/FAT32 > > failures: > > TestFsBasic.test_fs13[fat16] > > TestFsBasic.test_fs11[fat32] > > TestFsBasic.test_fs12[fat32] > > TestFsBasic.test_fs13[fat32] > > TestFsExt.test_fs_ext1[fat32] > > TestFsExt.test_fs_ext2[fat32] > > TestFsExt.test_fs_ext3[fat32] > > TestFsExt.test_fs_ext4[fat32] > > TestFsExt.test_fs_ext5[fat32] > > TestFsExt.test_fs_ext6[fat32] > > TestFsExt.test_fs_ext7[fat32] > > TestFsExt.test_fs_ext8[fat32] > > TestFsExt.test_fs_ext9[fat32] > > TestMkdir.test_mkdir6[fat16] > > TestMkdir.test_mkdir1[fat32] > > TestMkdir.test_mkdir2[fat32] > > TestMkdir.test_mkdir3[fat32] > > TestMkdir.test_mkdir4[fat32] > > TestMkdir.test_mkdir5[fat32] > > TestMkdir.test_mkdir6[fat32] > > TestUnlink.test_unlink1[fat16] > > TestUnlink.test_unlink2[fat16] > > TestUnlink.test_unlink3[fat16] > > TestUnlink.test_unlink4[fat16] > > TestUnlink.test_unlink5[fat16] > > TestUnlink.test_unlink6[fat16] > > TestUnlink.test_unlink7[fat16] > > TestUnlink.test_unlink1[fat32] > > TestUnlink.test_unlink2[fat32] > > TestUnlink.test_unlink3[fat32] > > TestUnlink.test_unlink4[fat32] > > TestUnlink.test_unlink5[fat32] > > TestUnlink.test_unlink6[fat32] > > TestUnlink.test_unlink7[fat32] > > I appreciate that we get tests for file system functions. > > Unfortunately the test output is rudimentary. Can we have something more > expressive than unlink1 - unlink7? > > CCing Takahiro as he was contributing recently to FAT. Sorry, yes, kind of? I pasted that in for brevity, but it's basically that for example all of test/py/tests/test_fs/test_unlink.py fails if you fsck the image in question after each test. If you apply https://patchwork.ozlabs.org/patch/1041186/ (to avoid spurious ext4 failures) and then https://patchwork.ozlabs.org/patch/1041181/ and run 'make tests' you'll see the full output. -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, RESEND, v5, 3/7] test: fs: Add filesystem integrity checks
On 4/9/19 10:03 PM, Tom Rini wrote: > On Wed, Feb 13, 2019 at 12:15:23PM +0100, Jean-Jacques Hiblot wrote: > >> We need to make sure that file writes,file creation, etc. are properly >> performed and do not corrupt the filesystem. >> To help with this, introduce the assert_fs_integrity() function that >> executes the appropriate fsck tool. It should be called at the end of any >> test that modify the content/organization of the filesystem. >> Currently only supports FATs and EXT4. >> >> Signed-off-by: Jean-Jacques Hiblot >> Reviewed-by: Tom Rini > > OK, I'm adding in a bunch of people to CC here. The issue with this > patch is that by adding fsck to our tests we see 34 FAT16/FAT32 > failures: > TestFsBasic.test_fs13[fat16] > TestFsBasic.test_fs11[fat32] > TestFsBasic.test_fs12[fat32] > TestFsBasic.test_fs13[fat32] > TestFsExt.test_fs_ext1[fat32] > TestFsExt.test_fs_ext2[fat32] > TestFsExt.test_fs_ext3[fat32] > TestFsExt.test_fs_ext4[fat32] > TestFsExt.test_fs_ext5[fat32] > TestFsExt.test_fs_ext6[fat32] > TestFsExt.test_fs_ext7[fat32] > TestFsExt.test_fs_ext8[fat32] > TestFsExt.test_fs_ext9[fat32] > TestMkdir.test_mkdir6[fat16] > TestMkdir.test_mkdir1[fat32] > TestMkdir.test_mkdir2[fat32] > TestMkdir.test_mkdir3[fat32] > TestMkdir.test_mkdir4[fat32] > TestMkdir.test_mkdir5[fat32] > TestMkdir.test_mkdir6[fat32] > TestUnlink.test_unlink1[fat16] > TestUnlink.test_unlink2[fat16] > TestUnlink.test_unlink3[fat16] > TestUnlink.test_unlink4[fat16] > TestUnlink.test_unlink5[fat16] > TestUnlink.test_unlink6[fat16] > TestUnlink.test_unlink7[fat16] > TestUnlink.test_unlink1[fat32] > TestUnlink.test_unlink2[fat32] > TestUnlink.test_unlink3[fat32] > TestUnlink.test_unlink4[fat32] > TestUnlink.test_unlink5[fat32] > TestUnlink.test_unlink6[fat32] > TestUnlink.test_unlink7[fat32] I appreciate that we get tests for file system functions. Unfortunately the test output is rudimentary. Can we have something more expressive than unlink1 - unlink7? CCing Takahiro as he was contributing recently to FAT. Best regards Heinrich > > So... I'm inclined to say that to start with, I bring this patch in and > then disable FAT fsck (as I cannot see how to mark these as xfail with > a comment that we need to fix them, only for FAT). But we should get > these FAT problems fixed. > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] test: call hexdump tests via `ut lib`
On 2/11/19 8:42 PM, Simon Goldschmidt wrote:
> Am 11.02.2019 um 18:29 schrieb Heinrich Schuchardt:
>> The unit tests in test/lib/hexdump.c are not related to the device tree.
>> So they should be executed via `ut lib` and not via `ut dm`.
>>
>> Signed-off-by: Heinrich Schuchardt
>
> Reviewed-by: Simon Goldschmidt
Hello Tom,
please, consider the patch for v2019-07.
Best regards
Heinrich
>
> Excellent idea, I'll send the same for test/lib/lmb.c.
>
> Thanks,
> Simon
>
>> ---
>> test/lib/hexdump.c | 9 +
>> 1 file changed, 5 insertions(+), 4 deletions(-)
>>
>> diff --git a/test/lib/hexdump.c b/test/lib/hexdump.c
>> index 567b57686a..5dccf43886 100644
>> --- a/test/lib/hexdump.c
>> +++ b/test/lib/hexdump.c
>> @@ -6,7 +6,8 @@
>> #include
>> #include
>> -#include
>> +#include
>> +#include
>> #include
>> static int lib_test_hex_to_bin(struct unit_test_state *uts)
>> @@ -32,7 +33,7 @@ static int lib_test_hex_to_bin(struct
>> unit_test_state *uts)
>> return 0;
>> }
>> -DM_TEST(lib_test_hex_to_bin, DM_TESTF_SCAN_PDATA | DM_TESTF_SCAN_FDT);
>> +LIB_TEST(lib_test_hex_to_bin, 0);
>> static int lib_test_hex2bin(struct unit_test_state *uts)
>> {
>> @@ -62,7 +63,7 @@ static int lib_test_hex2bin(struct unit_test_state
>> *uts)
>> return 0;
>> }
>> -DM_TEST(lib_test_hex2bin, DM_TESTF_SCAN_PDATA | DM_TESTF_SCAN_FDT);
>> +LIB_TEST(lib_test_hex2bin, 0);
>> static int lib_test_bin2hex(struct unit_test_state *uts)
>> {
>> @@ -92,4 +93,4 @@ static int lib_test_bin2hex(struct unit_test_state
>> *uts)
>> return 0;
>> }
>> -DM_TEST(lib_test_bin2hex, DM_TESTF_SCAN_PDATA | DM_TESTF_SCAN_FDT);
>> +LIB_TEST(lib_test_bin2hex, 0);
>>
>
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Bug in saveenv handling?
Tom Rini wrote on 04/09/2019 11:09 PM: On Tue, Apr 09, 2019 at 10:53:36PM +0200, U.Mutlu wrote: Frank Wunderlich wrote on 04/09/2019 09:39 PM: this looks for me like the CONFIG_ENV_OFFSET+CONFIG_ENV_SIZE is overlapping uboots code can you post these values and position of uboot and its size for your device? which env-storage do you use (EMV_IN_MMC or ENV_FAT)? I looked up in the .config file: # U-Boot 2019.04-rc4 Configuration So, -rc4 has a bug that the final release does not, on this platform. Please try the v2019.04 release first and then if you see the problem still, continue reporting and also make sure to Cc Jagan, thanks! # U-Boot 2019.04 Configuration Yes, I too can confirm now that the problem of saveenv overwriting u-boot doesn't happen in the 2019.04 release version. But the said crash when issuing the command "scsi scan" is still present, but this maybe has some other reasons. Thx. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Possible bug in release: fdisk in linux cannot read /dev/mmcblk0 anymore
Sorry, seems to be a false alert. After rebuilding u-boot it works fine again. U.Mutlu wrote on 04/10/2019 12:37 AM: Hi folks, # U-Boot 2019.04 Configuration I just updated to the latest version via git. My previous version was the recent 2019.04-rc4. Now in this latest version I think a bug shows up: Inside Linux on the device, suddenly the following command no longer works: # fdisk -l /dev/mmcblk0 fdisk: cannot open /dev/mmcblk0: Input/output error # ls -l /dev/mmcblk0 brw-rw 1 root disk 179, 0 Jan 1 1970 /dev/mmcblk0 The device is present, but fdisk cannot read the partitions, although u-boot has successfully used the boot partition of this SD card to boot Linux. IMHO a funny situation, isn't it? :-) This always had worked for me, up until now. Is this more a linux issue or a u-boot issue? Let me know if you need specific data. Thx ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] u-boot-video failure in ut dm video_ansi
Anatolij, The latest changes in u-boot-video.git master branch break the "ut dm video_ansi" unit test: => ut dm video_ansi Test: dm_test_video_ansi: video.c /var/lib/jenkins/workspace/u-boot-denx_uboot_video-master-build/src/u-boot/test/dm/video.c:186, dm_test_video_ansi(): 272 == compress_frame_buffer(dev): Expected 272, got 274 Failures: 1 This is a new failure in the last 8 commits or so; the previous push earlier today did not have this issue. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] Possible bug in release: fdisk in linux cannot read /dev/mmcblk0 anymore
Hi folks, # U-Boot 2019.04 Configuration I just updated to the latest version via git. My previous version was the recent 2019.04-rc4. Now in this latest version I think a bug shows up: Inside Linux on the device, suddenly the following command no longer works: # fdisk -l /dev/mmcblk0 fdisk: cannot open /dev/mmcblk0: Input/output error # ls -l /dev/mmcblk0 brw-rw 1 root disk 179, 0 Jan 1 1970 /dev/mmcblk0 The device is present, but fdisk cannot read the partitions, although u-boot has successfully used the boot partition of this SD card to boot Linux. IMHO a funny situation, isn't it? :-) This always had worked for me, up until now. Is this more a linux issue or a u-boot issue? Let me know if you need specific data. Thx ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/1] efi_loader: remove stray #define LOG_CATEGORY LOGL_ERR
The statement '#define LOG_CATEGORY LOGL_ERR' makes not sense. LOGL_ERR is not a LOG_CATEGORY. Remove the statement. Signed-off-by: Heinrich Schuchardt --- lib/efi_loader/efi_device_path.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/lib/efi_loader/efi_device_path.c b/lib/efi_loader/efi_device_path.c index 53b40c8c3c..1b08ca8f62 100644 --- a/lib/efi_loader/efi_device_path.c +++ b/lib/efi_loader/efi_device_path.c @@ -5,8 +5,6 @@ * (C) Copyright 2017 Rob Clark */ -#define LOG_CATEGORY LOGL_ERR - #include #include #include -- 2.20.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RFC 1/1] cmd: fs: fix data abort in load cmd
On 4/9/19 3:08 PM, Igor Opaniuk wrote:
> With CONFIG_CMD_BOOTEFI=y, load command causes data abort
> when path_to_uefi(fp->str, path) tries to write uefi path out of
> bounds of u16 str[] array (check efi_device_path_file_path struct for
> details). This is caused by unproper handling of void *buf pointer
> in efi_dp_from_file(), particularly when the buf pointer value is changed
> after dp_part_fill() invocation.
>
>> load usb 0:1 0x1200 imx6dl-colibri-eval-v3.dtb
> pc : [<2fab48ae>]lr : [<2fab4339>]
> reloc pc : [<178338ae>] lr : [<1789>]
> sp : 2da77120 ip : 0003 fp : 0005
> r10: 2daa31d0 r9 : 2da80ea8 r8 : 0001
> r7 : 2daa3098 r6 : 2ca75040 r5 : 2da77148 r4 : 003a
> r3 : 0069 r2 : 2ca750a3 r1 : 2daa3104 r0 : 2ca7509f
> Flags: nzCv IRQs off FIQs off Mode SVC_32
> Code: 4630fb31 81f0e8bd e7d84606 bf082b2f (f822235c)
> Resetting CPU ...
>
Thanks for reporting the problem.
> With the change suggested:
>
>> load usb 0:1 0x1200 imx6dl-colibri-eval-v3.dtb
> 5675440 bytes read in 188 ms (28.8 MiB/s)
>
> Signed-off-by: Igor Opaniuk
> ---
> lib/efi_loader/efi_device_path.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/lib/efi_loader/efi_device_path.c
> b/lib/efi_loader/efi_device_path.c
> index 53b40c8c3c..97b4356167 100644
> --- a/lib/efi_loader/efi_device_path.c
> +++ b/lib/efi_loader/efi_device_path.c
> @@ -829,7 +829,7 @@ struct efi_device_path *efi_dp_from_file(struct blk_desc
> *desc, int part,
> buf = dp_part_fill(buf, desc, part);
>
> /* add file-path: */
> - fp = buf;
> + fp = start;
This cannot be correct. dp_part_fill() is meant to set buf to the end of
the partition device path, e.g.
/VenHw(dbca4c98-6cb0-694d-0872-819c650cb7b8)/HD(1,MBR,0xd1535d21,0x1,0x7f)
In the lines below we want to add a further device path node with the
filename followed by the end node, e.g.
/VenHw(dbca4c98-6cb0-694d-0872-819c650cb7b8)/HD(1,MBR,0xd1535d21,0x1,0x7f)/Shell.efi
With your patch we end up with a device path containing only the file
name and the end node, e.g.
/Shell.efi
If you think this is an out of bound problem we must fix the estimation
of the device path size.
For better understanding the problem could you, please, print the value
of dpsize and then call dp_alloc() with a sufficiently large argument.
Before the return statement add
printf("desc %p\n", desc);
printf("dp length %zu\n", efi_dp_size(start));
This should provide the calculated device path length and its actual size.
Please, indicate the config file that you are using.
Best regards
Heinrich
> fp->dp.type = DEVICE_PATH_TYPE_MEDIA_DEVICE;
> fp->dp.sub_type = DEVICE_PATH_SUB_TYPE_FILE_PATH;
> fp->dp.length = fpsize;
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Bug in saveenv handling?
U.Mutlu wrote on 04/09/2019 11:01 PM: U.Mutlu wrote on 04/09/2019 10:53 PM: Frank Wunderlich wrote on 04/09/2019 09:39 PM: this looks for me like the CONFIG_ENV_OFFSET+CONFIG_ENV_SIZE is overlapping uboots code can you post these values and position of uboot and its size for your device? $ ls -l u-boot-sunxi-with-spl.bin -rw-r--r-- 1 xy xy 479836 Apr 9 17:55 u-boot-sunxi-with-spl.bin I used the following to write u-boot to the SD card (/dev/sdb): # dd if=/dev/zero of=/dev/sdb bs=1k count=1023 seek=1 # dd if=u-boot-sunxi-with-spl.bin of=/dev/sdb bs=1024 seek=8 If you need more data let me know pls. which env-storage do you use (EMV_IN_MMC or ENV_FAT)? I looked up in the .config file: # U-Boot 2019.04-rc4 Configuration $ grep CONFIG_ENV_OFFSET .config CONFIG_ENV_OFFSET=0x88000 $ grep CONFIG_ENV_SIZE .config CONFIG_ENV_SIZE=0x2 $ grep EMV_IN_MMC .config Maybe EMV_ is a typo and should rather be ENV_ ? $ grep -i EMV_ .config $ grep -i ENV_ .config CONFIG_ENV_SIZE=0x2 CONFIG_ENV_OFFSET=0x88000 CONFIG_ENV_VARS_UBOOT_CONFIG=y # CONFIG_SYS_CONSOLE_ENV_OVERWRITE is not set # CONFIG_SPL_ENV_SUPPORT is not set CONFIG_CMD_ENV_EXISTS=y # CONFIG_CMD_ENV_CALLBACK is not set # CONFIG_CMD_ENV_FLAGS is not set # CONFIG_ENV_IS_IN_EEPROM is not set CONFIG_ENV_IS_IN_FAT=y # CONFIG_ENV_IS_IN_EXT4 is not set # CONFIG_ENV_IS_IN_FLASH is not set # CONFIG_ENV_IS_IN_MMC is not set # CONFIG_ENV_IS_IN_NAND is not set # CONFIG_ENV_IS_IN_NVRAM is not set # CONFIG_ENV_IS_IN_ONENAND is not set # CONFIG_ENV_IS_IN_REMOTE is not set # CONFIG_ENV_IS_IN_SPI_FLASH is not set # CONFIG_ENV_IS_IN_UBI is not set CONFIG_ENV_FAT_INTERFACE="mmc" CONFIG_ENV_FAT_DEVICE_AND_PART="0:auto" CONFIG_ENV_FAT_FILE="uboot.env" # CONFIG_USE_DEFAULT_ENV_FILE is not set # CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG is not set $ grep ENV_FAT .config CONFIG_ENV_FAT_INTERFACE="mmc" CONFIG_ENV_FAT_DEVICE_AND_PART="0:auto" CONFIG_ENV_FAT_FILE="uboot.env" I guess the uboot.env is a hidden file, but occassionally (esp. after saveenv & reboot) I see this file as a normal file in /, not hidden. I used "Lamobo_R1_defconfig" as basis and made just a few irrelevant minor changes in make menuconfig. It's actually a Banana Pi R1 board. CONFIG_DEFAULT_DEVICE_TREE="sun7i-a20-lamobo-r1" Thx Gesendet: Dienstag, 09. April 2019 um 21:05 Uhr Von: "U.Mutlu" It seems u-boot has overwritten parts of itself on the storage medium (uSD with FAT boot partition). ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] video: backlight: Parse PWM polarity cell
On Mon, 25 Mar 2019 09:53:48 +0200 Stefan Mavrodiev ste...@olimex.com wrote: > This patch enables the reading of the polarity cell from a PWM > phandle and calls pwm_set_invert(). > --- > drivers/video/pwm_backlight.c | 10 ++ > 1 file changed, 10 insertions(+) Applied to u-boot-video/master, added SoB. Please next time don't forget to add Signed-off-by tag. Thanks! -- Anatolij ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RFC PATCH v2] MLK-12883 usb: limit USB_MAX_XFER_BLK to 256
On Tue, Apr 09, 2019 at 05:20:45PM +0200, Marcel Ziswiler wrote: > From: Peng Fan > > For Some USB mass storage devices, such as: > " > - Kingston DataTraveler 2.0 001D7D06CF09B04199C7B3EA > - Class: (from Interface) Mass Storage > - PacketSize: 64 Configurations: 1 > - Vendor: 0x0930 Product 0x6545 Version 1.16 > " > When `usb read 0x8000 0 0x2000`, we met > "EHCI timed out on TD - token=0x80008d80". > > The devices does not support scsi VPD page, we are not able > to get the maximum transfer length for READ(10)/WRITE(10). > > So we limit this to 256 blocks as READ(6). > > Signed-off-by: Peng Fan > Acked-by: Marcel Ziswiler > (cherry picked from commit df0052575b2bc9d66ae73584768e1a457ed5d914) > > --- > This comes from NXP's downstream and has proven to tremendously improve > the situation with those odd USB mass storage aka memory sticks. This is > why I post it here asking whether or not this may be something > benefiting more people. Any feedback and suggestions are welcome. > > Changes in v2: > - Fixed spelling in comment as suggested by Igor. > > common/usb_storage.c | 6 +- > 1 file changed, 5 insertions(+), 1 deletion(-) > > diff --git a/common/usb_storage.c b/common/usb_storage.c > index 8c889bb1a6..4e284645f5 100644 > --- a/common/usb_storage.c > +++ b/common/usb_storage.c > @@ -949,7 +949,11 @@ static void usb_stor_set_max_xfer_blk(struct usb_device > *udev, >* there is enough free heap space left, but the SCSI READ(10) and >* WRITE(10) commands are limited to 65535 blocks. >*/ > - blk = USHRT_MAX; > + /* > + * Some USB mass storage devices have issues, limiting this to 256 > + * fixes this. > + */ > + blk = 256; > #else > blk = 20; > #endif > -- > 2.20.1 Adding in Lukasz now that get_maintainers.pl shows this should be Cc'd to him as well, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] uboot sandbox tracing
Hi Andrzej, On Mon, 1 Apr 2019 at 08:26, Witkowski, Andrzej wrote: > > Hi, > > > > I’m SW Developer at Intel, Poland. > > I try to enable tracing in u-boot to see how it works. > > I follow the procedure described in “doc/README.trace” file. > > Unfortunately, I always receive segmentation fault. > > > > I compile and run u-boot on my development machine with Fedora 28. > > - for the latest u-boot code on master branch I receive segmentation fault > (refer to latest_u-boot_master_branch.log in attachment) > > After setting CONFIG_TRACE_EARLY_SIZE to 8725512 in > “include/configs/sandbox.h” file, I receive different segmentation fault > (refer to latest_u-boot_maseter_branch_1.log in attachment). > > > > What I do wrong? (Please always send emails to the mailing list - it is OK to cc me but it should go to this list. In this instance I'm copying the list in the reply.) I found that the early console conflicts with the early trace buffer, which causes the segfault. Also the early trace buffer as given in sandbox.h is too small (although you got around that one). I've sent some patches to fix this and a few other things I think could be improved. Thanks for the report. Regards, Simon > > > > Andrzej Witkowski > > NSG Poland > > Host Storage SW & FW Development > > > > Intel Technology Poland > > ul. Slowackiego 173 > > 80-298 Gdansk > > Poland > > > > - > Intel Technology Poland sp. z o.o. > ul. Sowackiego 173 | 80-298 Gdask |
Re: [U-Boot] Bug in saveenv handling?
On Tue, Apr 09, 2019 at 10:53:36PM +0200, U.Mutlu wrote: > Frank Wunderlich wrote on 04/09/2019 09:39 PM: > >this looks for me like the CONFIG_ENV_OFFSET+CONFIG_ENV_SIZE is overlapping > >uboots code > > > >can you post these values and position of uboot and its size for your device? > > > >which env-storage do you use (EMV_IN_MMC or ENV_FAT)? > > I looked up in the .config file: > > # U-Boot 2019.04-rc4 Configuration > > > $ grep CONFIG_ENV_OFFSET .config > CONFIG_ENV_OFFSET=0x88000 > > $ grep CONFIG_ENV_SIZE .config > CONFIG_ENV_SIZE=0x2 > > $ grep EMV_IN_MMC .config > > $ grep ENV_FAT .config > CONFIG_ENV_FAT_INTERFACE="mmc" > CONFIG_ENV_FAT_DEVICE_AND_PART="0:auto" > CONFIG_ENV_FAT_FILE="uboot.env" > > I guess the uboot.env is a hidden file, but occassionally (esp. after > saveenv & reboot) I see this file as a normal file in /, not hidden. > > I used "Lamobo_R1_defconfig" as basis and made just a few So, -rc4 has a bug that the final release does not, on this platform. Please try the v2019.04 release first and then if you see the problem still, continue reporting and also make sure to Cc Jagan, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 8/8] sunxi: allow boards to de-select SYS_WHITE_ON_BLACK font scheme
On Sat, 23 Mar 2019 01:30:02 + Andre Przywara andre.przyw...@arm.com wrote: > In the sunxi-common.h config header we unconditionally define > CONFIG_SYS_WHITE_ON_BLACK, although it's actually a Kconfig option which > could be individually selected by a user. > Remove this #define from the header and let it default to "y" on sunxi > boards (like we do for other platforms). > > Signed-off-by: Andre Przywara > --- > drivers/video/Kconfig | 2 +- > include/configs/sunxi-common.h | 1 - > 2 files changed, 1 insertion(+), 2 deletions(-) Applied to u-boot-video/master, thanks! -- Anatolij ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 7/8] usb: kbd: Properly translate up/down arrow keys
On Sat, 23 Mar 2019 01:30:01 + Andre Przywara andre.przyw...@arm.com wrote: > So far arrows key pressed on an USB keyboard got translated to some > low ASCII control sequences (Ctrl+N, Ctrl+P). Some programs understand > these codes, but the standard for those keys is to use ANSI control > sequences for cursor movement (ESC [ A). > Our own boot menu is a victim of this, currently we cannot change the > selection with an USB keyboard due to this. > > Since we already implement a queue for USB key codes, we can just insert > the three character ANSI sequence into the key buffer. This fixes the > bootmenu, and is more universal for other users (UEFI) as well. > > Signed-off-by: Andre Przywara > --- > common/usb_kbd.c | 24 +++- > 1 file changed, 23 insertions(+), 1 deletion(-) Applied to u-boot-video/master, thanks! -- Anatolij ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 4/8] video/console: Implement ANSI clear line command
On Sat, 23 Mar 2019 01:29:58 + Andre Przywara andre.przyw...@arm.com wrote: > There is a standard ANSI terminal escape sequence to clear a whole line > of text. So far the DM_VIDEO console was missing this code. > > Detect the sequence and use vidconsole_set_row with the background > colour to fix this omission. > > Signed-off-by: Andre Przywara > --- > drivers/video/vidconsole-uclass.c | 19 +++ > 1 file changed, 19 insertions(+) Applied to u-boot-video/master, thanks! -- Anatolij ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 5/8] video/console: Factor out actual character output
On Sat, 23 Mar 2019 01:29:59 + Andre Przywara andre.przyw...@arm.com wrote: > In preparation for doing character set translations, factor out the > actual glyph display functionality into a separate function. > This will be used in a subsequent patch. > > Signed-off-by: Andre Przywara > --- > drivers/video/vidconsole-uclass.c | 42 > +-- > 1 file changed, 27 insertions(+), 15 deletions(-) Applied to u-boot-video/master, thanks! -- Anatolij ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 3/8] video/console: Implement relative cursor movement ANSI handling
On Sat, 23 Mar 2019 01:29:57 + Andre Przywara andre.przyw...@arm.com wrote: > The ANSI terminal escapce sequence standard defines relative cursor > movement commands (ESC [ A-F). So far the DM_VIDEO console code was > ignoring them. > > Interpret those sequences and move the cursor by the requested amount of > rows or columns in the right direction. This brings the code on par with > the legacy video console driver (cfb_console). > > Signed-off-by: Andre Przywara > --- > drivers/video/vidconsole-uclass.c | 37 + > 1 file changed, 37 insertions(+) Applied to u-boot-video/master, thanks! -- Anatolij ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/8] video/console: Implement reverse video ANSI sequence for DM_VIDEO
On Sat, 23 Mar 2019 01:29:56 + Andre Przywara andre.przyw...@arm.com wrote: > The video console for DM_VIDEO compliant drivers only understands a very > small number of ANSI sequences. First and foremost it misses the "reverse > video" command, which is used by our own bootmenu command to highlight > the selected entry. > > To avoid forcing people to use their imagination when using the > bootmenu, let's just implement the rather simple reverse effect. We need > to store the background colour index for that, so that we can > recalculate both the foreground and background colour pixel values. > > Signed-off-by: Andre Przywara > --- > drivers/video/vidconsole-uclass.c | 11 ++- > drivers/video/video-uclass.c | 1 + > include/video.h | 2 ++ > 3 files changed, 13 insertions(+), 1 deletion(-) Applied to u-boot-video/master, thanks! -- Anatolij ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/8] video/console: Fix DM_VIDEO font glyph array indexing
On Sat, 23 Mar 2019 01:29:55 + Andre Przywara andre.przyw...@arm.com wrote: > When the character to be printed on a DM_VIDEO console is from the > "extended ASCII" range (0x80 - 0xff), it will be treated as a negative > number, as it's declared as a signed char. This leads to negative array > indicies into the glyph bitmap array, and random garbled characters. > > Cast the character to an unsigned type to make the index always positive > and avoid an out-of-bounds access. > > Signed-off-by: Andre Przywara > --- > drivers/video/console_normal.c | 3 ++- > drivers/video/console_rotate.c | 7 --- > 2 files changed, 6 insertions(+), 4 deletions(-) Applied (with s/uint8_t/u8/) to u-boot-video/master, thanks! -- Anatolij ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Bug in saveenv handling?
U.Mutlu wrote on 04/09/2019 10:53 PM: Frank Wunderlich wrote on 04/09/2019 09:39 PM: this looks for me like the CONFIG_ENV_OFFSET+CONFIG_ENV_SIZE is overlapping uboots code can you post these values and position of uboot and its size for your device? which env-storage do you use (EMV_IN_MMC or ENV_FAT)? I looked up in the .config file: # U-Boot 2019.04-rc4 Configuration $ grep CONFIG_ENV_OFFSET .config CONFIG_ENV_OFFSET=0x88000 $ grep CONFIG_ENV_SIZE .config CONFIG_ENV_SIZE=0x2 $ grep EMV_IN_MMC .config Maybe EMV_ is a typo and should rather be ENV_ ? $ grep -i EMV_ .config $ grep -i ENV_ .config CONFIG_ENV_SIZE=0x2 CONFIG_ENV_OFFSET=0x88000 CONFIG_ENV_VARS_UBOOT_CONFIG=y # CONFIG_SYS_CONSOLE_ENV_OVERWRITE is not set # CONFIG_SPL_ENV_SUPPORT is not set CONFIG_CMD_ENV_EXISTS=y # CONFIG_CMD_ENV_CALLBACK is not set # CONFIG_CMD_ENV_FLAGS is not set # CONFIG_ENV_IS_IN_EEPROM is not set CONFIG_ENV_IS_IN_FAT=y # CONFIG_ENV_IS_IN_EXT4 is not set # CONFIG_ENV_IS_IN_FLASH is not set # CONFIG_ENV_IS_IN_MMC is not set # CONFIG_ENV_IS_IN_NAND is not set # CONFIG_ENV_IS_IN_NVRAM is not set # CONFIG_ENV_IS_IN_ONENAND is not set # CONFIG_ENV_IS_IN_REMOTE is not set # CONFIG_ENV_IS_IN_SPI_FLASH is not set # CONFIG_ENV_IS_IN_UBI is not set CONFIG_ENV_FAT_INTERFACE="mmc" CONFIG_ENV_FAT_DEVICE_AND_PART="0:auto" CONFIG_ENV_FAT_FILE="uboot.env" # CONFIG_USE_DEFAULT_ENV_FILE is not set # CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG is not set $ grep ENV_FAT .config CONFIG_ENV_FAT_INTERFACE="mmc" CONFIG_ENV_FAT_DEVICE_AND_PART="0:auto" CONFIG_ENV_FAT_FILE="uboot.env" I guess the uboot.env is a hidden file, but occassionally (esp. after saveenv & reboot) I see this file as a normal file in /, not hidden. I used "Lamobo_R1_defconfig" as basis and made just a few irrelevant minor changes in make menuconfig. It's actually a Banana Pi R1 board. CONFIG_DEFAULT_DEVICE_TREE="sun7i-a20-lamobo-r1" Thx Gesendet: Dienstag, 09. April 2019 um 21:05 Uhr Von: "U.Mutlu" It seems u-boot has overwritten parts of itself on the storage medium (uSD with FAT boot partition). ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] efi: fix memory calculation overflow on 32-bit systems
Hi,
There are Cubox-i machines out there with nearly 4 GiB of RAM. The
RAM starts at 0x1000 with a size of 0xf000. Thus the end
of RAM is at 0x1. This overflows a 32-bit integer, which
should be fine since in the EFI memory code the variables used are
all 64-bit with a fixed size. Unfortunately EFI_PAGE_MASK, which is
used in the EFI memory code to remove the lower bits, is based on
the EFI_PAGE_SIZE macro which, uses 1UL with a shift. This means
the resulting mask is UL, which is only 32-bit on ARMv7. Use ULL to
make sure that even on 32-bit platforms we use a 64-bit long mask.
Without this there will be no memory available in the EFI memory map
and bootefi will fail allocating pages.
Best regards,
Patrick
diff --git a/include/efi.h b/include/efi.h
index d98441ab19d..3c9d20f8c0b 100644
--- a/include/efi.h
+++ b/include/efi.h
@@ -190,7 +190,7 @@ enum efi_mem_type {
#define EFI_MEM_DESC_VERSION 1
#define EFI_PAGE_SHIFT 12
-#define EFI_PAGE_SIZE (1UL << EFI_PAGE_SHIFT)
+#define EFI_PAGE_SIZE (1ULL << EFI_PAGE_SHIFT)
#define EFI_PAGE_MASK (EFI_PAGE_SIZE - 1)
struct efi_mem_desc {
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, v1] fdt: Fix mkimage list to try every header type
On 2019-04-09, Jordan Hand wrote:
> Signed-off-by: Jordan Hand
> ---
> Image type is not supplied to `mkimage -l`. For this reason, we cannot
> use imagetool_verify_print_header_by_type. Instead, this patch uses
> imagetool_verify_print_header to look through all header types to find
> one where image validation succeeds.
>
> This patch fixes failures in test/image/test-imagetools.sh
>
> tools/mkimage.c | 23 +++
> 1 file changed, 15 insertions(+), 8 deletions(-)
Works for me.
Tested-by: Vagrant Cascadian
live well,
vagrant
> diff --git a/tools/mkimage.c b/tools/mkimage.c
> index 2899adff81..d1e1a6743d 100644
> --- a/tools/mkimage.c
> +++ b/tools/mkimage.c
> @@ -403,14 +403,21 @@ int main(int argc, char **argv)
> exit (EXIT_FAILURE);
> }
>
> - /*
> - * scan through mkimage registry for all supported image types
> - * and verify the input image file header for match
> - * Print the image information for matched image type
> - * Returns the error code if not matched
> - */
> - retval = imagetool_verify_print_header_by_type(ptr, ,
> - tparams, );
> + if (params.fflag) {
> + /*
> + * Verifies the header format based on the expected
> header for image
> + * type in tparams
> + */
> + retval = imagetool_verify_print_header_by_type(ptr,
> ,
> + tparams, );
> + } else {
> + /**
> + * When listing the image, we are not given the image
> type. Simply check all
> + * image types to find one that matches our header
> + */
> + retval = imagetool_verify_print_header(ptr, ,
> + tparams, );
> + }
>
> (void) munmap((void *)ptr, sbuf.st_size);
> (void) close (ifd);
signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Bug in saveenv handling?
Frank Wunderlich wrote on 04/09/2019 09:39 PM: this looks for me like the CONFIG_ENV_OFFSET+CONFIG_ENV_SIZE is overlapping uboots code can you post these values and position of uboot and its size for your device? which env-storage do you use (EMV_IN_MMC or ENV_FAT)? I looked up in the .config file: # U-Boot 2019.04-rc4 Configuration $ grep CONFIG_ENV_OFFSET .config CONFIG_ENV_OFFSET=0x88000 $ grep CONFIG_ENV_SIZE .config CONFIG_ENV_SIZE=0x2 $ grep EMV_IN_MMC .config $ grep ENV_FAT .config CONFIG_ENV_FAT_INTERFACE="mmc" CONFIG_ENV_FAT_DEVICE_AND_PART="0:auto" CONFIG_ENV_FAT_FILE="uboot.env" I guess the uboot.env is a hidden file, but occassionally (esp. after saveenv & reboot) I see this file as a normal file in /, not hidden. I used "Lamobo_R1_defconfig" as basis and made just a few irrelevant minor changes in make menuconfig. It's actually a Banana Pi R1 board. CONFIG_DEFAULT_DEVICE_TREE="sun7i-a20-lamobo-r1" Thx Gesendet: Dienstag, 09. April 2019 um 21:05 Uhr Von: "U.Mutlu" It seems u-boot has overwritten parts of itself on the storage medium (uSD with FAT boot partition). ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/4] arm: socfpga: clean up socfpga_common.h
On 4/9/19 9:45 PM, Simon Goldschmidt wrote: > Am 09.04.2019 um 21:28 schrieb Marek Vasut: >> On 4/9/19 8:52 PM, Simon Goldschmidt wrote: >>> Remove outdated defines (not used any more, outdated due to DM >>> conversion) from socfpga_common.h. >> >> s/defines/macros and comments/ > >>> Signed-off-by: Simon Goldschmidt >>> --- >>> >>> Changes in v2: >>> - remove even more outdated things >>> >>> include/configs/socfpga_common.h | 40 >>> 1 file changed, 40 deletions(-) >>> >>> diff --git a/include/configs/socfpga_common.h >>> b/include/configs/socfpga_common.h >>> index a65fc804e3..5b5e5f5d43 100644 >>> --- a/include/configs/socfpga_common.h >>> +++ b/include/configs/socfpga_common.h >>> @@ -72,29 +72,12 @@ >>> #define CONFIG_SYS_BARGSIZE CONFIG_SYS_CBSIZE >>> /* Boot argument buffer size */ >>> -#ifndef CONFIG_SYS_HOSTNAME >>> -#define CONFIG_SYS_HOSTNAME CONFIG_SYS_BOARD >>> -#endif >>> - >>> /* >>> * Cache >>> */ >>> #define CONFIG_SYS_L2_PL310 >>> #define CONFIG_SYS_PL310_BASE SOCFPGA_MPUL2_ADDRESS >>> -/* >>> - * EPCS/EPCQx1 Serial Flash Controller >>> - */ >>> -#ifdef CONFIG_ALTERA_SPI >>> -/* >>> - * The base address is configurable in QSys, each board must specify >>> the >>> - * base address based on it's particular FPGA configuration. Please >>> note >>> - * that the address here is incremented by 0x400 from the Base >>> address >>> - * selected in QSys, since the SPI registers are at offset +0x400. >>> - * #define CONFIG_SYS_SPI_BASE 0xff240400 >>> - */ >>> -#endif >>> - >>> /* >>> * Ethernet on SoC (EMAC) >>> */ >>> @@ -162,15 +145,6 @@ unsigned int cm_get_qspi_controller_clk_hz(void); >>> #define CONFIG_CQSPI_REF_CLK cm_get_qspi_controller_clk_hz() >>> #endif >>> -/* >>> - * Designware SPI support >>> - */ >>> - >>> -/* >>> - * Serial Driver >>> - */ >>> -#define CONFIG_SYS_NS16550_SERIAL >> >> Are you sure about this one ? > > Yes. This is only used in 'drivers/serial/Makefile' if CONFIG_DM_SERIAL > is not defined. No need to keep it. > > Should I still send a v3 for the commit message? Would be nice. Can you prep me a PR with the patches for current release? -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/4] arm: socfpga: move vining_fpga to DM_I2C
On 4/9/19 9:38 PM, Simon Goldschmidt wrote: > Am 09.04.2019 um 21:27 schrieb Marek Vasut: >> On 4/9/19 8:52 PM, Simon Goldschmidt wrote: >>> All socfpga boards except for vining_fpga use DM_I2C. Enable >>> DM_I2C for this board and set the EEPROM defines via Kconfig >>> (enabling CONFIG_I2C_EEPROM from MISC). >>> >>> Signed-off-by: Simon Goldschmidt >>> --- >>> >>> Changes in v2: >>> - added (this) patch to move socfpga_vining to DM_I2C >>> >>> configs/socfpga_vining_fpga_defconfig | 8 +++- >>> include/configs/socfpga_common.h | 26 -- >>> include/configs/socfpga_vining_fpga.h | 9 - >>> 3 files changed, 7 insertions(+), 36 deletions(-) >> >> Isn't this missing some DT bit which would enable the I2C controller ? >> Or is that already in the DT for this platform ? >> > > Well, I don't have the board (I tested with socfpga_socrates + Phy1 > addon board which does have an i2c eeprom but needs an FPGA config to > work), but to me it seems 'socfpga_cyclone5_vining_fpga.dts' should have > everything we need, or what do you think is missing? I was just curious whether you checked that. > Having this tested on a real socfpga_vining board would be great of > course... I'll arrange for that. -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] test.py: Disable fsck for FAT tests for now
Currently enabling fsck on FAT16/FAT32 exposes that we have problems
with:
TestFsBasic.test_fs13[fat16]
TestFsBasic.test_fs11[fat32]
TestFsBasic.test_fs12[fat32]
TestFsBasic.test_fs13[fat32]
TestFsExt.test_fs_ext1[fat32]
TestFsExt.test_fs_ext2[fat32]
TestFsExt.test_fs_ext3[fat32]
TestFsExt.test_fs_ext4[fat32]
TestFsExt.test_fs_ext5[fat32]
TestFsExt.test_fs_ext6[fat32]
TestFsExt.test_fs_ext7[fat32]
TestFsExt.test_fs_ext8[fat32]
TestFsExt.test_fs_ext9[fat32]
TestMkdir.test_mkdir6[fat16]
TestMkdir.test_mkdir1[fat32]
TestMkdir.test_mkdir2[fat32]
TestMkdir.test_mkdir3[fat32]
TestMkdir.test_mkdir4[fat32]
TestMkdir.test_mkdir5[fat32]
TestMkdir.test_mkdir6[fat32]
TestUnlink.test_unlink1[fat16]
TestUnlink.test_unlink2[fat16]
TestUnlink.test_unlink3[fat16]
TestUnlink.test_unlink4[fat16]
TestUnlink.test_unlink5[fat16]
TestUnlink.test_unlink6[fat16]
TestUnlink.test_unlink7[fat16]
TestUnlink.test_unlink1[fat32]
TestUnlink.test_unlink2[fat32]
TestUnlink.test_unlink3[fat32]
TestUnlink.test_unlink4[fat32]
TestUnlink.test_unlink5[fat32]
TestUnlink.test_unlink6[fat32]
TestUnlink.test_unlink7[fat32]
While we need to resolve these problems we also should enable fsck for
ext4 to ensure that things remain in good shape there.
Signed-off-by: Tom Rini
---
test/py/tests/test_fs/fstest_helpers.py | 2 --
1 file changed, 2 deletions(-)
diff --git a/test/py/tests/test_fs/fstest_helpers.py
b/test/py/tests/test_fs/fstest_helpers.py
index 637bc30a9141..faec2982489d 100644
--- a/test/py/tests/test_fs/fstest_helpers.py
+++ b/test/py/tests/test_fs/fstest_helpers.py
@@ -9,7 +9,5 @@ def assert_fs_integrity(fs_type, fs_img):
try:
if fs_type == 'ext4':
check_call('fsck.ext4 -n -f %s' % fs_img, shell=True)
-if fs_type == 'fat':
-check_call('fsck.fat -n %s' % fs_img, shell=True)
except CalledProcessError:
raise
--
2.7.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, RESEND, v5, 3/7] test: fs: Add filesystem integrity checks
On Wed, Feb 13, 2019 at 12:15:23PM +0100, Jean-Jacques Hiblot wrote: > We need to make sure that file writes,file creation, etc. are properly > performed and do not corrupt the filesystem. > To help with this, introduce the assert_fs_integrity() function that > executes the appropriate fsck tool. It should be called at the end of any > test that modify the content/organization of the filesystem. > Currently only supports FATs and EXT4. > > Signed-off-by: Jean-Jacques Hiblot > Reviewed-by: Tom Rini OK, I'm adding in a bunch of people to CC here. The issue with this patch is that by adding fsck to our tests we see 34 FAT16/FAT32 failures: TestFsBasic.test_fs13[fat16] TestFsBasic.test_fs11[fat32] TestFsBasic.test_fs12[fat32] TestFsBasic.test_fs13[fat32] TestFsExt.test_fs_ext1[fat32] TestFsExt.test_fs_ext2[fat32] TestFsExt.test_fs_ext3[fat32] TestFsExt.test_fs_ext4[fat32] TestFsExt.test_fs_ext5[fat32] TestFsExt.test_fs_ext6[fat32] TestFsExt.test_fs_ext7[fat32] TestFsExt.test_fs_ext8[fat32] TestFsExt.test_fs_ext9[fat32] TestMkdir.test_mkdir6[fat16] TestMkdir.test_mkdir1[fat32] TestMkdir.test_mkdir2[fat32] TestMkdir.test_mkdir3[fat32] TestMkdir.test_mkdir4[fat32] TestMkdir.test_mkdir5[fat32] TestMkdir.test_mkdir6[fat32] TestUnlink.test_unlink1[fat16] TestUnlink.test_unlink2[fat16] TestUnlink.test_unlink3[fat16] TestUnlink.test_unlink4[fat16] TestUnlink.test_unlink5[fat16] TestUnlink.test_unlink6[fat16] TestUnlink.test_unlink7[fat16] TestUnlink.test_unlink1[fat32] TestUnlink.test_unlink2[fat32] TestUnlink.test_unlink3[fat32] TestUnlink.test_unlink4[fat32] TestUnlink.test_unlink5[fat32] TestUnlink.test_unlink6[fat32] TestUnlink.test_unlink7[fat32] So... I'm inclined to say that to start with, I bring this patch in and then disable FAT fsck (as I cannot see how to mark these as xfail with a comment that we need to fix them, only for FAT). But we should get these FAT problems fixed. -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/4] arm: socfpga: clean up socfpga_common.h
Am 09.04.2019 um 21:28 schrieb Marek Vasut: On 4/9/19 8:52 PM, Simon Goldschmidt wrote: Remove outdated defines (not used any more, outdated due to DM conversion) from socfpga_common.h. s/defines/macros and comments/ > Signed-off-by: Simon Goldschmidt --- Changes in v2: - remove even more outdated things include/configs/socfpga_common.h | 40 1 file changed, 40 deletions(-) diff --git a/include/configs/socfpga_common.h b/include/configs/socfpga_common.h index a65fc804e3..5b5e5f5d43 100644 --- a/include/configs/socfpga_common.h +++ b/include/configs/socfpga_common.h @@ -72,29 +72,12 @@ #define CONFIG_SYS_BARGSIZE CONFIG_SYS_CBSIZE /* Boot argument buffer size */ -#ifndef CONFIG_SYS_HOSTNAME -#define CONFIG_SYS_HOSTNAMECONFIG_SYS_BOARD -#endif - /* * Cache */ #define CONFIG_SYS_L2_PL310 #define CONFIG_SYS_PL310_BASE SOCFPGA_MPUL2_ADDRESS -/* - * EPCS/EPCQx1 Serial Flash Controller - */ -#ifdef CONFIG_ALTERA_SPI -/* - * The base address is configurable in QSys, each board must specify the - * base address based on it's particular FPGA configuration. Please note - * that the address here is incremented by 0x400 from the Base address - * selected in QSys, since the SPI registers are at offset +0x400. - * #define CONFIG_SYS_SPI_BASE 0xff240400 - */ -#endif - /* * Ethernet on SoC (EMAC) */ @@ -162,15 +145,6 @@ unsigned int cm_get_qspi_controller_clk_hz(void); #define CONFIG_CQSPI_REF_CLK cm_get_qspi_controller_clk_hz() #endif -/* - * Designware SPI support - */ - -/* - * Serial Driver - */ -#define CONFIG_SYS_NS16550_SERIAL Are you sure about this one ? Yes. This is only used in 'drivers/serial/Makefile' if CONFIG_DM_SERIAL is not defined. No need to keep it. Should I still send a v3 for the commit message? Regards, Simon /* * USB */ @@ -206,20 +180,6 @@ unsigned int cm_get_qspi_controller_clk_hz(void); #define CONFIG_ENV_SECT_SIZE (64 * 1024) #endif -/* - * mtd partitioning for serial NOR flash - * - * device nor0 , # parts = 6 - * #: namesizeoffset mask_flags - * 0: u-boot 0x0010 0x 0 - * 1: env10x0004 0x0010 0 - * 2: env20x0004 0x0014 0 - * 3: UBI 0x03e8 0x0018 0 - * 4: boot0x00e8 0x0018 0 - * 5: rootfs 0x0100 0x0100 0 - * - */ - /* * SPL * ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Bug in saveenv handling?
this looks for me like the CONFIG_ENV_OFFSET+CONFIG_ENV_SIZE is overlapping uboots code can you post these values and position of uboot and its size for your device? which env-storage do you use (EMV_IN_MMC or ENV_FAT)? regards Frank > Gesendet: Dienstag, 09. April 2019 um 21:05 Uhr > Von: "U.Mutlu" > It seems u-boot has overwritten parts of itself on the storage medium (uSD > with FAT boot partition). ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/4] arm: socfpga: move vining_fpga to DM_I2C
Am 09.04.2019 um 21:27 schrieb Marek Vasut: On 4/9/19 8:52 PM, Simon Goldschmidt wrote: All socfpga boards except for vining_fpga use DM_I2C. Enable DM_I2C for this board and set the EEPROM defines via Kconfig (enabling CONFIG_I2C_EEPROM from MISC). Signed-off-by: Simon Goldschmidt --- Changes in v2: - added (this) patch to move socfpga_vining to DM_I2C configs/socfpga_vining_fpga_defconfig | 8 +++- include/configs/socfpga_common.h | 26 -- include/configs/socfpga_vining_fpga.h | 9 - 3 files changed, 7 insertions(+), 36 deletions(-) Isn't this missing some DT bit which would enable the I2C controller ? Or is that already in the DT for this platform ? Well, I don't have the board (I tested with socfpga_socrates + Phy1 addon board which does have an i2c eeprom but needs an FPGA config to work), but to me it seems 'socfpga_cyclone5_vining_fpga.dts' should have everything we need, or what do you think is missing? Having this tested on a real socfpga_vining board would be great of course... Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v4 3/4] arm: socfpga: imply/default common config options
On 4/9/19 9:02 PM, Simon Goldschmidt wrote: > This commit moves common config options used in all socfpga boards > to select/imply in Kconfig. This both cleans up the defconfig files > as well as makes future changes easier. > > Options implied/defaulted for all sub-arches: > - SPL, SPL_DM, USE_TINY_PRINTF, NR_DRAM_BANKS > > Options implied/defaulted for implied for A10 & gen5: > - FPGA_SOCFPGA, SYS_MALLOC_F_LEN, SYS_TEXT_BASE > > Options implied/defaulted for gen5: > - SPL_STACK_R, SPL_SYS_MALLOC_SIMPLE, SPL_STACK_R_ADDR > > Signed-off-by: Simon Goldschmidt > --- > > Changes in v4: > - adapt to socfpga-next > > Changes in v3: > - adapt to socfpge-next: imply USE_TINY_PRINTF only for gen5 & a10, > not s10 > > Changes in v2: > - added patch to imply/default common config options > > arch/arm/Kconfig | 2 ++ > arch/arm/mach-socfpga/Kconfig | 20 > configs/socfpga_arria10_defconfig | 6 -- > configs/socfpga_arria5_defconfig | 10 -- > configs/socfpga_cyclone5_defconfig | 10 -- > configs/socfpga_dbm_soc1_defconfig | 10 -- > configs/socfpga_de0_nano_soc_defconfig | 10 -- > configs/socfpga_de10_nano_defconfig| 10 -- > configs/socfpga_de1_soc_defconfig | 10 -- > configs/socfpga_is1_defconfig | 8 > configs/socfpga_sockit_defconfig | 10 -- > configs/socfpga_socrates_defconfig | 10 -- > configs/socfpga_sr1500_defconfig | 10 -- > configs/socfpga_stratix10_defconfig| 2 -- > configs/socfpga_vining_fpga_defconfig | 10 -- > 15 files changed, 22 insertions(+), 116 deletions(-) > > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig > index 77a534f81f..6554ad94f8 100644 > --- a/arch/arm/Kconfig > +++ b/arch/arm/Kconfig > @@ -841,6 +841,8 @@ config ARCH_SOCFPGA > imply DM_SPI > imply DM_SPI_FLASH > imply FAT_WRITE > + imply SPL > + imply SPL_DM > imply SPL_LIBDISK_SUPPORT > imply SPL_MMC_SUPPORT > imply SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION > diff --git a/arch/arm/mach-socfpga/Kconfig b/arch/arm/mach-socfpga/Kconfig > index 5e87371f8c..3c6c63067d 100644 > --- a/arch/arm/mach-socfpga/Kconfig > +++ b/arch/arm/mach-socfpga/Kconfig > @@ -1,8 +1,22 @@ > if ARCH_SOCFPGA > > +config NR_DRAM_BANKS > + default 1 > + > +config SPL_STACK_R_ADDR > + default 0x0080 if TARGET_SOCFPGA_GEN5 > + > config SYS_MMCSD_RAW_MODE_U_BOOT_PARTITION_TYPE > default 0xa2 > > +config SYS_MALLOC_F_LEN > + default 0x2000 if TARGET_SOCFPGA_ARRIA10 > + default 0x2000 if TARGET_SOCFPGA_GEN5 > + > +config SYS_TEXT_BASE > + default 0x0140 if TARGET_SOCFPGA_ARRIA10 > + default 0x0140 if TARGET_SOCFPGA_GEN5 > + > config TARGET_SOCFPGA_ARRIA5 > bool > select TARGET_SOCFPGA_GEN5 > @@ -21,6 +35,8 @@ config TARGET_SOCFPGA_ARRIA10 > select SYSCON > select SPL_SYSCON if SPL > select ETH_DESIGNWARE_SOCFPGA > + imply FPGA_SOCFPGA > + imply USE_TINY_PRINTF > > config TARGET_SOCFPGA_CYCLONE5 > bool > @@ -29,6 +45,10 @@ config TARGET_SOCFPGA_CYCLONE5 > config TARGET_SOCFPGA_GEN5 > bool > select ALTERA_SDRAM > + imply FPGA_SOCFPGA > + imply SPL_STACK_R > + imply SPL_SYS_MALLOC_SIMPLE > + imply USE_TINY_PRINTF > > config TARGET_SOCFPGA_STRATIX10 > bool > diff --git a/configs/socfpga_arria10_defconfig > b/configs/socfpga_arria10_defconfig > index f321a0ac3b..b3540cfe42 100644 > --- a/configs/socfpga_arria10_defconfig > +++ b/configs/socfpga_arria10_defconfig > @@ -1,12 +1,9 @@ > CONFIG_ARM=y > CONFIG_ARCH_SOCFPGA=y > -CONFIG_SYS_TEXT_BASE=0x0140 > CONFIG_SYS_MALLOC_F_LEN=0x2000 > CONFIG_TARGET_SOCFPGA_ARRIA10_SOCDK=y > -CONFIG_SPL=y > CONFIG_IDENT_STRING="socfpga_arria10" > CONFIG_DISTRO_DEFAULTS=y > -CONFIG_NR_DRAM_BANKS=1 > CONFIG_USE_BOOTARGS=y > CONFIG_BOOTARGS="console=ttyS0,115200" > # CONFIG_USE_BOOTCOMMAND is not set > @@ -28,9 +25,7 @@ CONFIG_MTDIDS_DEFAULT="nor0=ff705000.spi.0" > # CONFIG_EFI_PARTITION is not set > CONFIG_DEFAULT_DEVICE_TREE="socfpga_arria10_socdk_sdmmc" > CONFIG_ENV_IS_IN_MMC=y > -CONFIG_SPL_DM=y > CONFIG_SPL_DM_SEQ_ALIAS=y > -CONFIG_FPGA_SOCFPGA=y > CONFIG_DM_GPIO=y > CONFIG_DWAPB_GPIO=y > CONFIG_DM_MMC=y > @@ -42,4 +37,3 @@ CONFIG_SPI=y > CONFIG_TIMER=y > CONFIG_SPL_TIMER=y > CONFIG_DESIGNWARE_APB_TIMER=y > -CONFIG_USE_TINY_PRINTF=y > diff --git a/configs/socfpga_arria5_defconfig > b/configs/socfpga_arria5_defconfig > index 2f04092649..d514b14364 100644 > --- a/configs/socfpga_arria5_defconfig > +++ b/configs/socfpga_arria5_defconfig > @@ -1,12 +1,7 @@ > CONFIG_ARM=y > CONFIG_ARCH_SOCFPGA=y > -CONFIG_SYS_TEXT_BASE=0x0140 > -CONFIG_SYS_MALLOC_F_LEN=0x2000 > CONFIG_TARGET_SOCFPGA_ARRIA5_SOCDK=y > -CONFIG_SPL=y > -CONFIG_SPL_STACK_R_ADDR=0x0080 > CONFIG_DISTRO_DEFAULTS=y > -CONFIG_NR_DRAM_BANKS=1 > CONFIG_FIT=y
Re: [U-Boot] [PATCH v4 4/4] arm: socfpga: gen5: reduce SPL pre-reloc malloc
On 4/9/19 9:02 PM, Simon Goldschmidt wrote: > By enabling debug prints in malloc_simple, we can see that SPL for socfpga > gen5 does by far not need the 8 KiB malloc pool currently allocated for > SPL in pre-reloc phase. > > On socfpga_socrates, 1304 bytes are currently used (and this increases by > ~200 bytes only for the sdram/reset fixes in socfpga-next). > > To prevent wasting precious SRAM space, let's reduce the initial heap used > for SPL to 2 KiB. This is still some hundred bytes more than currently > used. Also, the gen5 SPL enables stack and heap in DDR memory pretty > early. Only the initial uclass/dm parsing, serial console and DDR > initialization is done in the initial heap, so these 2 KiB should be > enough for all boards. > > Signed-off-by: Simon Goldschmidt > --- > > Changes in v4: None > Changes in v3: > - adapt to socfpga-next > > Changes in v2: > - added patch to reduce gen5 SPL initial malloc pool to 2 KiB > > arch/arm/mach-socfpga/Kconfig | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/arch/arm/mach-socfpga/Kconfig b/arch/arm/mach-socfpga/Kconfig > index 3c6c63067d..8f7b79f586 100644 > --- a/arch/arm/mach-socfpga/Kconfig > +++ b/arch/arm/mach-socfpga/Kconfig > @@ -6,6 +6,9 @@ config NR_DRAM_BANKS > config SPL_STACK_R_ADDR > default 0x0080 if TARGET_SOCFPGA_GEN5 > > +config SPL_SYS_MALLOC_F_LEN > + default 0x800 if TARGET_SOCFPGA_GEN5 > + > config SYS_MMCSD_RAW_MODE_U_BOOT_PARTITION_TYPE > default 0xa2 > > Acked-by: Marek Vasut -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v4 1/4] arm: socfpga: fix comment about SPL memory layout
On 4/9/19 9:02 PM, Simon Goldschmidt wrote: > The comment about SPL memory layout for socfpga gen5 is outdated: the > initial malloc memory is now at the end of the SRAM, gd is below it > (see board_init_f_alloc_reserve). > > Signed-off-by: Simon Goldschmidt > --- > > Changes in v4: None > Changes in v3: None > Changes in v2: None > > include/configs/socfpga_common.h | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/include/configs/socfpga_common.h > b/include/configs/socfpga_common.h > index f9e2cdc1b3..32ee7426b6 100644 > --- a/include/configs/socfpga_common.h > +++ b/include/configs/socfpga_common.h > @@ -236,9 +236,9 @@ unsigned int cm_get_qspi_controller_clk_hz(void); > * > * 0x_ .. Start of SRAM > * 0x_ .. Top of stack (grows down) > - * 0x_ .. Malloc area > - * 0x_ .. Global Data > - * 0x_FF00 .. End of SRAM > + * 0x_ .. Global Data > + * 0x_ .. Malloc area > + * 0x_ .. End of SRAM > * > * SRAM Memory layout for Arria 10: > * 0xFFE0_ .. Start of SRAM (bottom) > Acked-by: Marek Vasut -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v4 0/4] arm: socfpga: stack and Kconfig cleanups
On 4/9/19 9:02 PM, Simon Goldschmidt wrote: > This series cleans up stack definitions in socfpga_common.h as well as > cleans up defconfig files by implying/defaulting common things in Kconfig > files. > > Finally, it reduces the malloc pool size used in first stage of gen5 SPL > (without ddr available) in order to have more space available for code. > > As this series does not contain direct bugfixes, it targets the > socfpga-next branch. > > Note that this series is meant for socfpga-next but depends on the generic > series "spl: full-featured heap cleanups" from: > https://patchwork.ozlabs.org/project/uboot/list/?series=99561 > > Changes in v4: > - make this patch 2/4 work without changing a10 heap allocation strategy > (as the series doing that has been rejected) > - adapt to socfpga-next > > Changes in v3: > - removed patch 2/5 from v2 (moved to patchwork #1067366, series #99561) > - adapt to socfpge-next: imply USE_TINY_PRINTF only for gen5 & a10, > not s10 > - adapt to socfpga-next > > Changes in v2: > - fix commit message: "SPL post-reloc", not "SPL pre-reloc" > - added patch to imply/default common config options > - added patch to reduce gen5 SPL initial malloc pool to 2 KiB > > Simon Goldschmidt (4): > arm: socfpga: fix comment about SPL memory layout > arm: socfpga: put initial U-Boot stack into DDR > arm: socfpga: imply/default common config options > arm: socfpga: gen5: reduce SPL pre-reloc malloc > > arch/arm/Kconfig | 2 ++ > arch/arm/mach-socfpga/Kconfig | 23 > configs/socfpga_arria10_defconfig | 6 > configs/socfpga_arria5_defconfig | 10 -- > configs/socfpga_cyclone5_defconfig | 10 -- > configs/socfpga_dbm_soc1_defconfig | 10 -- > configs/socfpga_de0_nano_soc_defconfig | 10 -- > configs/socfpga_de10_nano_defconfig| 10 -- > configs/socfpga_de1_soc_defconfig | 10 -- > configs/socfpga_is1_defconfig | 8 - > configs/socfpga_sockit_defconfig | 10 -- > configs/socfpga_socrates_defconfig | 10 -- > configs/socfpga_sr1500_defconfig | 10 -- > configs/socfpga_stratix10_defconfig| 2 -- > configs/socfpga_vining_fpga_defconfig | 10 -- > include/configs/socfpga_common.h | 48 -- > 16 files changed, 48 insertions(+), 141 deletions(-) > Acked-by: Marek Vasut -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 3/4] arm: socfpga: remove CONFIG_SYS_BOOTMAPSZ
On 4/9/19 8:52 PM, Simon Goldschmidt wrote: > socfpga_common.h defines CONFIG_SYS_BOOTMAPSZ to 64 MiB. > > Since having this define overrides the 'bootm_size' env variable for > the whole socfpga platform, let's remove this define from socfpga_common.h > and instead rely on the 'bootm_size' env variable (which is initialized > to 160 MiB in the same file's default env). This gives users the > chance to override it in their own environment. > > Signed-off-by: Simon Goldschmidt > --- > > Changes in v2: None > > include/configs/socfpga_common.h | 2 -- > 1 file changed, 2 deletions(-) > > diff --git a/include/configs/socfpga_common.h > b/include/configs/socfpga_common.h > index 5b5e5f5d43..5eccb01d1d 100644 > --- a/include/configs/socfpga_common.h > +++ b/include/configs/socfpga_common.h > @@ -10,8 +10,6 @@ > */ > #define CONFIG_CLOCKS > > -#define CONFIG_SYS_BOOTMAPSZ (64 * 1024 * 1024) > - > #define CONFIG_TIMESTAMP /* Print image info with timestamp */ > > /* > Acked-by: Marek Vasut -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 4/4] arm: socfpga: clean up board config files
On 4/9/19 8:52 PM, Simon Goldschmidt wrote: > Remove outdated defines (not used any more, outdated due to DM > conversion) from various socfpga files in include/config. > > Signed-off-by: Simon Goldschmidt > --- > > Changes in v2: > - added (this) patch with further cleanups to the socfpga board config > files > > include/configs/socfpga_arria10_socdk.h | 6 -- > include/configs/socfpga_arria5_socdk.h | 2 -- > include/configs/socfpga_cyclone5_socdk.h | 2 -- > include/configs/socfpga_de0_nano_soc.h | 2 -- > include/configs/socfpga_de10_nano.h | 2 -- > include/configs/socfpga_de1_soc.h| 2 -- > include/configs/socfpga_is1.h| 2 -- > include/configs/socfpga_sockit.h | 2 -- > include/configs/socfpga_socrates.h | 2 -- > include/configs/socfpga_sr1500.h | 11 --- > include/configs/socfpga_vining_fpga.h| 9 - > 11 files changed, 42 deletions(-) > > diff --git a/include/configs/socfpga_arria10_socdk.h > b/include/configs/socfpga_arria10_socdk.h > index 0f116fbf2d..92630c5e6e 100644 > --- a/include/configs/socfpga_arria10_socdk.h > +++ b/include/configs/socfpga_arria10_socdk.h > @@ -19,12 +19,6 @@ > /* Memory configurations */ > #define PHYS_SDRAM_1_SIZE0x4000 > > -/* Ethernet on SoC (EMAC) */ > - > -/* > - * U-Boot environment configurations > - */ > - > /* > * Serial / UART configurations > */ > diff --git a/include/configs/socfpga_arria5_socdk.h > b/include/configs/socfpga_arria5_socdk.h > index 24fcdd8b5a..af6137aeb1 100644 > --- a/include/configs/socfpga_arria5_socdk.h > +++ b/include/configs/socfpga_arria5_socdk.h > @@ -14,8 +14,6 @@ > #define CONFIG_LOADADDR 0x0100 > #define CONFIG_SYS_LOAD_ADDR CONFIG_LOADADDR > > -/* Ethernet on SoC (EMAC) */ > - > /* The rest of the configuration is shared */ > #include > > diff --git a/include/configs/socfpga_cyclone5_socdk.h > b/include/configs/socfpga_cyclone5_socdk.h > index 18da8496ef..028db2a09e 100644 > --- a/include/configs/socfpga_cyclone5_socdk.h > +++ b/include/configs/socfpga_cyclone5_socdk.h > @@ -14,8 +14,6 @@ > #define CONFIG_LOADADDR 0x0100 > #define CONFIG_SYS_LOAD_ADDR CONFIG_LOADADDR > > -/* Ethernet on SoC (EMAC) */ > - > /* The rest of the configuration is shared */ > #include > > diff --git a/include/configs/socfpga_de0_nano_soc.h > b/include/configs/socfpga_de0_nano_soc.h > index d3224d5bd3..21108e3447 100644 > --- a/include/configs/socfpga_de0_nano_soc.h > +++ b/include/configs/socfpga_de0_nano_soc.h > @@ -14,8 +14,6 @@ > #define CONFIG_LOADADDR 0x0100 > #define CONFIG_SYS_LOAD_ADDR CONFIG_LOADADDR > > -/* Ethernet on SoC (EMAC) */ > - > /* The rest of the configuration is shared */ > #include > > diff --git a/include/configs/socfpga_de10_nano.h > b/include/configs/socfpga_de10_nano.h > index 2fcabff8af..d85f98fbd4 100644 > --- a/include/configs/socfpga_de10_nano.h > +++ b/include/configs/socfpga_de10_nano.h > @@ -14,8 +14,6 @@ > #define CONFIG_LOADADDR 0x0100 > #define CONFIG_SYS_LOAD_ADDR CONFIG_LOADADDR > > -/* Ethernet on SoC (EMAC) */ > - > /* The rest of the configuration is shared */ > #include > > diff --git a/include/configs/socfpga_de1_soc.h > b/include/configs/socfpga_de1_soc.h > index f37099c58f..9919d292dc 100644 > --- a/include/configs/socfpga_de1_soc.h > +++ b/include/configs/socfpga_de1_soc.h > @@ -14,8 +14,6 @@ > #define CONFIG_LOADADDR 0x0100 > #define CONFIG_SYS_LOAD_ADDR CONFIG_LOADADDR > > -/* Ethernet on SoC (EMAC) */ > - > /* The rest of the configuration is shared */ > #include > > diff --git a/include/configs/socfpga_is1.h b/include/configs/socfpga_is1.h > index c233c208a5..c4da5947f3 100644 > --- a/include/configs/socfpga_is1.h > +++ b/include/configs/socfpga_is1.h > @@ -19,8 +19,6 @@ > /* Ethernet on SoC (EMAC) */ > #if defined(CONFIG_CMD_NET) > #define CONFIG_ARP_TIMEOUT 500UL > - > -/* PHY */ > #endif > > /* The rest of the configuration is shared */ > diff --git a/include/configs/socfpga_sockit.h > b/include/configs/socfpga_sockit.h > index 3a7f354914..97249a 100644 > --- a/include/configs/socfpga_sockit.h > +++ b/include/configs/socfpga_sockit.h > @@ -14,8 +14,6 @@ > #define CONFIG_LOADADDR 0x0100 > #define CONFIG_SYS_LOAD_ADDR CONFIG_LOADADDR > > -/* Ethernet on SoC (EMAC) */ > - > /* The rest of the configuration is shared */ > #include > > diff --git a/include/configs/socfpga_socrates.h > b/include/configs/socfpga_socrates.h > index f0d9347891..7faea150a9 100644 > --- a/include/configs/socfpga_socrates.h > +++ b/include/configs/socfpga_socrates.h > @@ -14,8 +14,6 @@ > #define CONFIG_LOADADDR 0x0100 > #define CONFIG_SYS_LOAD_ADDR CONFIG_LOADADDR > > -/* Ethernet on SoC (EMAC) */ > - > /* The rest of the configuration is shared */ > #include > > diff --git
Re: [U-Boot] [PATCH v2 2/4] arm: socfpga: clean up socfpga_common.h
On 4/9/19 8:52 PM, Simon Goldschmidt wrote: > Remove outdated defines (not used any more, outdated due to DM > conversion) from socfpga_common.h. s/defines/macros and comments/ > Signed-off-by: Simon Goldschmidt > --- > > Changes in v2: > - remove even more outdated things > > include/configs/socfpga_common.h | 40 > 1 file changed, 40 deletions(-) > > diff --git a/include/configs/socfpga_common.h > b/include/configs/socfpga_common.h > index a65fc804e3..5b5e5f5d43 100644 > --- a/include/configs/socfpga_common.h > +++ b/include/configs/socfpga_common.h > @@ -72,29 +72,12 @@ > #define CONFIG_SYS_BARGSIZE CONFIG_SYS_CBSIZE > /* Boot argument buffer size */ > > -#ifndef CONFIG_SYS_HOSTNAME > -#define CONFIG_SYS_HOSTNAME CONFIG_SYS_BOARD > -#endif > - > /* > * Cache > */ > #define CONFIG_SYS_L2_PL310 > #define CONFIG_SYS_PL310_BASESOCFPGA_MPUL2_ADDRESS > > -/* > - * EPCS/EPCQx1 Serial Flash Controller > - */ > -#ifdef CONFIG_ALTERA_SPI > -/* > - * The base address is configurable in QSys, each board must specify the > - * base address based on it's particular FPGA configuration. Please note > - * that the address here is incremented by 0x400 from the Base address > - * selected in QSys, since the SPI registers are at offset +0x400. > - * #define CONFIG_SYS_SPI_BASE 0xff240400 > - */ > -#endif > - > /* > * Ethernet on SoC (EMAC) > */ > @@ -162,15 +145,6 @@ unsigned int cm_get_qspi_controller_clk_hz(void); > #define CONFIG_CQSPI_REF_CLK cm_get_qspi_controller_clk_hz() > #endif > > -/* > - * Designware SPI support > - */ > - > -/* > - * Serial Driver > - */ > -#define CONFIG_SYS_NS16550_SERIAL Are you sure about this one ? > /* > * USB > */ > @@ -206,20 +180,6 @@ unsigned int cm_get_qspi_controller_clk_hz(void); > #define CONFIG_ENV_SECT_SIZE (64 * 1024) > #endif > > -/* > - * mtd partitioning for serial NOR flash > - * > - * device nor0 , # parts = 6 > - * #: namesizeoffset mask_flags > - * 0: u-boot 0x0010 0x 0 > - * 1: env10x0004 0x0010 0 > - * 2: env20x0004 0x0014 0 > - * 3: UBI 0x03e8 0x0018 0 > - * 4: boot0x00e8 0x0018 0 > - * 5: rootfs 0x0100 0x0100 0 > - * > - */ > - > /* > * SPL > * > -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v4 2/4] arm: socfpga: put initial U-Boot stack into DDR
On 4/9/19 9:02 PM, Simon Goldschmidt wrote: > If SPL post-reloc stage puts the stack into DDR, U-Boot should be able to > do that, too. > > The reason to do so is that this way, U-Boot initial stack can be larger > than SPL initial stack. In situations where we want to save the SPL > in SRAM for next boot without reloading, this prevents overwriting the > SPL DTB in SRAM if U-Boot stack usage gets too high. > > To achieve this, the malloc definition for a10 is moved up and sligthly > changed to ensure CONFIG_SYS_INIT_RAM_SIZE is the remaining available size. > > Signed-off-by: Simon Goldschmidt > --- > > Changes in v4: > - make this patch 2/4 work without changing a10 heap allocation strategy > (as the series doing that has been rejected) > > Changes in v3: > - removed patch 2/5 from v2 (moved to patchwork #1067366, series #99561) > > Changes in v2: > - fix commit message: "SPL post-reloc", not "SPL pre-reloc" > > include/configs/socfpga_common.h | 42 +++- > 1 file changed, 20 insertions(+), 22 deletions(-) > > diff --git a/include/configs/socfpga_common.h > b/include/configs/socfpga_common.h > index 32ee7426b6..a501b5209f 100644 > --- a/include/configs/socfpga_common.h > +++ b/include/configs/socfpga_common.h > @@ -26,7 +26,13 @@ > #define CONFIG_SYS_INIT_RAM_SIZE 0x1 > #elif defined(CONFIG_TARGET_SOCFPGA_ARRIA10) > #define CONFIG_SYS_INIT_RAM_ADDR 0xFFE0 > -#define CONFIG_SYS_INIT_RAM_SIZE 0x4 /* 256KB */ > +/* SPL memory allocation configuration, this is for FAT implementation */ > +#ifndef CONFIG_SYS_SPL_MALLOC_SIZE > +#define CONFIG_SYS_SPL_MALLOC_SIZE 0x1 > +#endif > +#define CONFIG_SYS_INIT_RAM_SIZE (0x4 - CONFIG_SYS_SPL_MALLOC_SIZE) > +#define CONFIG_SYS_SPL_MALLOC_START (CONFIG_SYS_INIT_RAM_ADDR + \ > + CONFIG_SYS_INIT_RAM_SIZE) > #endif > > /* > @@ -38,12 +44,23 @@ > #if ((CONFIG_SYS_BOOTCOUNT_ADDR > CONFIG_SYS_INIT_RAM_ADDR) && \ > (CONFIG_SYS_BOOTCOUNT_ADDR < (CONFIG_SYS_INIT_RAM_ADDR +\ > CONFIG_SYS_INIT_RAM_SIZE))) > -#define CONFIG_SYS_INIT_SP_ADDR CONFIG_SYS_BOOTCOUNT_ADDR > +#define CONFIG_SPL_STACK CONFIG_SYS_BOOTCOUNT_ADDR > #else > -#define CONFIG_SYS_INIT_SP_ADDR \ > +#define CONFIG_SPL_STACK \ > (CONFIG_SYS_INIT_RAM_ADDR + CONFIG_SYS_INIT_RAM_SIZE) > #endif > > +/* > + * U-Boot stack setup: if SPL post-reloc uses DDR stack, use it in pre-reloc > + * phase of U-Boot, too. This prevents overwriting SPL data if stack/heap > usage > + * in U-Boot pre-reloc is higher than in SPL. > + */ > +#if defined(CONFIG_SPL_STACK_R_ADDR) && CONFIG_SPL_STACK_R_ADDR > +#define CONFIG_SYS_INIT_SP_ADDR CONFIG_SPL_STACK_R_ADDR > +#else > +#define CONFIG_SYS_INIT_SP_ADDR CONFIG_SPL_STACK > +#endif > + > #define CONFIG_SYS_SDRAM_BASEPHYS_SDRAM_1 > > /* > @@ -252,16 +269,6 @@ unsigned int cm_get_qspi_controller_clk_hz(void); > #define CONFIG_SPL_MAX_SIZE CONFIG_SYS_INIT_RAM_SIZE > #endif > > -#if defined(CONFIG_TARGET_SOCFPGA_ARRIA10) > -/* SPL memory allocation configuration, this is for FAT implementation */ > -#ifndef CONFIG_SYS_SPL_MALLOC_START > -#define CONFIG_SYS_SPL_MALLOC_SIZE 0x0001 > -#define CONFIG_SYS_SPL_MALLOC_START (CONFIG_SYS_INIT_RAM_SIZE - \ > - CONFIG_SYS_SPL_MALLOC_SIZE + \ > - CONFIG_SYS_INIT_RAM_ADDR) > -#endif > -#endif > - > /* SPL SDMMC boot support */ > #ifdef CONFIG_SPL_MMC_SUPPORT > #if defined(CONFIG_SPL_FS_FAT) || defined(CONFIG_SPL_FS_EXT4) > @@ -292,15 +299,6 @@ unsigned int cm_get_qspi_controller_clk_hz(void); > #endif > #endif > > -/* > - * Stack setup > - */ > -#if defined(CONFIG_TARGET_SOCFPGA_GEN5) > -#define CONFIG_SPL_STACK CONFIG_SYS_INIT_SP_ADDR > -#elif defined(CONFIG_TARGET_SOCFPGA_ARRIA10) > -#define CONFIG_SPL_STACK CONFIG_SYS_SPL_MALLOC_START > -#endif > - > /* Extra Environment */ > #ifndef CONFIG_SPL_BUILD > > Acked-by: Marek Vasut -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/2] Revert "cmd: Kconfig: Do not include EEPROM if DM_I2C is used without DM_I2C_COMPAT"
On 4/9/19 8:53 PM, Simon Goldschmidt wrote:
> Am 30.03.2019 um 22:18 schrieb Simon Glass:
>> On Tue, 26 Mar 2019 at 06:39, Simon Goldschmidt
>> wrote:
>>>
>>> This reverts commit 65a97e7fcf54feb7c4ebe1aee8a572830af4cf51.
>>>
>>> The 'eeprom' command has been converted to work with DM_I2C in a patch
>>> submitted around the same time as this commit:
>>> commit 0c07a9b4078d ("eeprom: Add device model based I2C support to
>>> eeprom command")
>>>
>>> Signed-off-by: Simon Goldschmidt
>>> ---
>>>
>>> Changes in v2:
>>> - added patch to fix DM_I2C eeprom code to work without
>>> CONFIG_SYS_I2C_EEPROM_BUS
>>>
>>> cmd/Kconfig | 1 -
>>> 1 file changed, 1 deletion(-)
>>
>> Reviewed-by: Simon Glass
>>
>
>
> Who will take this series? It's assigned in to Marek in patchwork, but
> might go via Heiko's i2c tree? Or directly via Tom?
>
> I have sent patches (move socfpga_vining to DM_I2C) that are based on
> this series...
Heiko should at least AB/RB it , then I can take it via socfpga tree to
avoid dependency problems.
--
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/4] arm: socfpga: move vining_fpga to DM_I2C
On 4/9/19 8:52 PM, Simon Goldschmidt wrote: > All socfpga boards except for vining_fpga use DM_I2C. Enable > DM_I2C for this board and set the EEPROM defines via Kconfig > (enabling CONFIG_I2C_EEPROM from MISC). > > Signed-off-by: Simon Goldschmidt > --- > > Changes in v2: > - added (this) patch to move socfpga_vining to DM_I2C > > configs/socfpga_vining_fpga_defconfig | 8 +++- > include/configs/socfpga_common.h | 26 -- > include/configs/socfpga_vining_fpga.h | 9 - > 3 files changed, 7 insertions(+), 36 deletions(-) Isn't this missing some DT bit which would enable the I2C controller ? Or is that already in the DT for this platform ? -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, RESEND, v5, 1/7] fs: ext4: do not allow writes if metadata checksum is active
On Wed, Feb 13, 2019 at 12:15:21PM +0100, Jean-Jacques Hiblot wrote: > u-boot does not supports updating the metadata chacksums > > Signed-off-by: Jean-Jacques Hiblot > Reviewed-by: Tom Rini Deferred as I picked up commit 2e7365518acdb8fb6e9be332c8a6c57b457188d9 Author: Sébastien Szymanski Date: Fri Mar 22 09:33:52 2019 +0100 fs: ext4: do not write on filesystem with metadata_csum feature as it slipped my mind you had posted this patch in this series, sorry! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] fastboot: add support for 'getvar platform'
Our R-Car3 Android userspace relies on the output of 'fastboot
getvar platform' and U-Boot currently is not able to handle it:
host $> fastboot getvar platform
getvar:platform FAILED (remote: Variable not implemented)
finished. total time: 0.001s
We either have the option of adding 'fastboot.platform' variable
to the default/saved environment as a workaround or add proper
'fastboot getvar platform' support in U-Boot via this patch.
In the latter case, other platforms can benefit from it too.
Note that R-Car3 already exports 'platform' environment variable via
v2019.01 commit 00e4b57e9e71c3 ("ARM: rmobile: Set environment variable
containing CPU type").
Signed-off-by: Eugeniu Rosca
---
drivers/fastboot/fb_getvar.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/drivers/fastboot/fb_getvar.c b/drivers/fastboot/fb_getvar.c
index 4d264c985d7e..bc2481b57d73 100644
--- a/drivers/fastboot/fb_getvar.c
+++ b/drivers/fastboot/fb_getvar.c
@@ -17,6 +17,7 @@ static void getvar_downloadsize(char *var_parameter, char
*response);
static void getvar_serialno(char *var_parameter, char *response);
static void getvar_version_baseband(char *var_parameter, char *response);
static void getvar_product(char *var_parameter, char *response);
+static void getvar_platform(char *var_parameter, char *response);
static void getvar_current_slot(char *var_parameter, char *response);
static void getvar_slot_suffixes(char *var_parameter, char *response);
static void getvar_has_slot(char *var_parameter, char *response);
@@ -55,6 +56,9 @@ static const struct {
}, {
.variable = "product",
.dispatch = getvar_product
+ }, {
+ .variable = "platform",
+ .dispatch = getvar_platform
}, {
.variable = "current-slot",
.dispatch = getvar_current_slot
@@ -117,6 +121,16 @@ static void getvar_product(char *var_parameter, char
*response)
fastboot_fail("Board not set", response);
}
+static void getvar_platform(char *var_parameter, char *response)
+{
+ const char *p = env_get("platform");
+
+ if (p)
+ fastboot_okay(p, response);
+ else
+ fastboot_fail("platform not set", response);
+}
+
static void getvar_current_slot(char *var_parameter, char *response)
{
/* A/B not implemented, for now always return _a */
--
2.21.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] Bug in saveenv handling?
I just made this unpleasant observation while playing with u-boot: On the u-boot CLI I changed an envvar and saved the env: setenv bootdelay 5 ; saveenv Then I issued, just for fun, the command "scsi scan", but it crashed and rebooted the device. But this time on the display only the tuxx logo and the very first u-boot line is displayed, nothing else happens. It seems u-boot has overwritten parts of itself on the storage medium (uSD with FAT boot partition). I had this experience some more times in the past; after writing u-boot anew to the uSD it continued working again. Btw, I once even had the case where saveenv overwrote boot.cmd (but nothing else) with garbage (IIRC it was filled full with the char @ ). I mention this just because it seems that there's maybe a bug in u-boot's saveenv handling (maybe data was not completely flushed, file handle was not closed, or maybe the fat write routine is buggy?...). => setenv bootdelay 5 ; saveenv Saving Environment to FAT... OK => printenv bootdelay bootdelay=5 => scsi scan scanning bus for devices... data abort pc : [<7ef94f8e>] lr : [<7ef911a1>] reloc pc : [<4a01af8e>]lr : [<4a0171a1>] sp : 7af51bf8 ip : 001c fp : 00c0 r10: r9 : 7af59ed8 r8 : r7 : 7af51e78 r6 : 7efd3f54 r5 : 7efdb9b8 r4 : 7efdb9b8 r3 : r2 : r1 : ea16 r0 : 7efdb9b8 Flags: nZcv IRQs off FIQs off Mode SVC_32 Code: e92dbd10 f8d045f0 b0858080 1000f8d8 (f8d14604) Resetting CPU ... resetting ... ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v4 4/4] arm: socfpga: gen5: reduce SPL pre-reloc malloc
By enabling debug prints in malloc_simple, we can see that SPL for socfpga gen5 does by far not need the 8 KiB malloc pool currently allocated for SPL in pre-reloc phase. On socfpga_socrates, 1304 bytes are currently used (and this increases by ~200 bytes only for the sdram/reset fixes in socfpga-next). To prevent wasting precious SRAM space, let's reduce the initial heap used for SPL to 2 KiB. This is still some hundred bytes more than currently used. Also, the gen5 SPL enables stack and heap in DDR memory pretty early. Only the initial uclass/dm parsing, serial console and DDR initialization is done in the initial heap, so these 2 KiB should be enough for all boards. Signed-off-by: Simon Goldschmidt --- Changes in v4: None Changes in v3: - adapt to socfpga-next Changes in v2: - added patch to reduce gen5 SPL initial malloc pool to 2 KiB arch/arm/mach-socfpga/Kconfig | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/arm/mach-socfpga/Kconfig b/arch/arm/mach-socfpga/Kconfig index 3c6c63067d..8f7b79f586 100644 --- a/arch/arm/mach-socfpga/Kconfig +++ b/arch/arm/mach-socfpga/Kconfig @@ -6,6 +6,9 @@ config NR_DRAM_BANKS config SPL_STACK_R_ADDR default 0x0080 if TARGET_SOCFPGA_GEN5 +config SPL_SYS_MALLOC_F_LEN + default 0x800 if TARGET_SOCFPGA_GEN5 + config SYS_MMCSD_RAW_MODE_U_BOOT_PARTITION_TYPE default 0xa2 -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v4 2/4] arm: socfpga: put initial U-Boot stack into DDR
If SPL post-reloc stage puts the stack into DDR, U-Boot should be able to do that, too. The reason to do so is that this way, U-Boot initial stack can be larger than SPL initial stack. In situations where we want to save the SPL in SRAM for next boot without reloading, this prevents overwriting the SPL DTB in SRAM if U-Boot stack usage gets too high. To achieve this, the malloc definition for a10 is moved up and sligthly changed to ensure CONFIG_SYS_INIT_RAM_SIZE is the remaining available size. Signed-off-by: Simon Goldschmidt --- Changes in v4: - make this patch 2/4 work without changing a10 heap allocation strategy (as the series doing that has been rejected) Changes in v3: - removed patch 2/5 from v2 (moved to patchwork #1067366, series #99561) Changes in v2: - fix commit message: "SPL post-reloc", not "SPL pre-reloc" include/configs/socfpga_common.h | 42 +++- 1 file changed, 20 insertions(+), 22 deletions(-) diff --git a/include/configs/socfpga_common.h b/include/configs/socfpga_common.h index 32ee7426b6..a501b5209f 100644 --- a/include/configs/socfpga_common.h +++ b/include/configs/socfpga_common.h @@ -26,7 +26,13 @@ #define CONFIG_SYS_INIT_RAM_SIZE 0x1 #elif defined(CONFIG_TARGET_SOCFPGA_ARRIA10) #define CONFIG_SYS_INIT_RAM_ADDR 0xFFE0 -#define CONFIG_SYS_INIT_RAM_SIZE 0x4 /* 256KB */ +/* SPL memory allocation configuration, this is for FAT implementation */ +#ifndef CONFIG_SYS_SPL_MALLOC_SIZE +#define CONFIG_SYS_SPL_MALLOC_SIZE 0x1 +#endif +#define CONFIG_SYS_INIT_RAM_SIZE (0x4 - CONFIG_SYS_SPL_MALLOC_SIZE) +#define CONFIG_SYS_SPL_MALLOC_START(CONFIG_SYS_INIT_RAM_ADDR + \ +CONFIG_SYS_INIT_RAM_SIZE) #endif /* @@ -38,12 +44,23 @@ #if ((CONFIG_SYS_BOOTCOUNT_ADDR > CONFIG_SYS_INIT_RAM_ADDR) && \ (CONFIG_SYS_BOOTCOUNT_ADDR < (CONFIG_SYS_INIT_RAM_ADDR + \ CONFIG_SYS_INIT_RAM_SIZE))) -#define CONFIG_SYS_INIT_SP_ADDRCONFIG_SYS_BOOTCOUNT_ADDR +#define CONFIG_SPL_STACK CONFIG_SYS_BOOTCOUNT_ADDR #else -#define CONFIG_SYS_INIT_SP_ADDR\ +#define CONFIG_SPL_STACK \ (CONFIG_SYS_INIT_RAM_ADDR + CONFIG_SYS_INIT_RAM_SIZE) #endif +/* + * U-Boot stack setup: if SPL post-reloc uses DDR stack, use it in pre-reloc + * phase of U-Boot, too. This prevents overwriting SPL data if stack/heap usage + * in U-Boot pre-reloc is higher than in SPL. + */ +#if defined(CONFIG_SPL_STACK_R_ADDR) && CONFIG_SPL_STACK_R_ADDR +#define CONFIG_SYS_INIT_SP_ADDRCONFIG_SPL_STACK_R_ADDR +#else +#define CONFIG_SYS_INIT_SP_ADDRCONFIG_SPL_STACK +#endif + #define CONFIG_SYS_SDRAM_BASE PHYS_SDRAM_1 /* @@ -252,16 +269,6 @@ unsigned int cm_get_qspi_controller_clk_hz(void); #define CONFIG_SPL_MAX_SIZECONFIG_SYS_INIT_RAM_SIZE #endif -#if defined(CONFIG_TARGET_SOCFPGA_ARRIA10) -/* SPL memory allocation configuration, this is for FAT implementation */ -#ifndef CONFIG_SYS_SPL_MALLOC_START -#define CONFIG_SYS_SPL_MALLOC_SIZE 0x0001 -#define CONFIG_SYS_SPL_MALLOC_START(CONFIG_SYS_INIT_RAM_SIZE - \ -CONFIG_SYS_SPL_MALLOC_SIZE + \ -CONFIG_SYS_INIT_RAM_ADDR) -#endif -#endif - /* SPL SDMMC boot support */ #ifdef CONFIG_SPL_MMC_SUPPORT #if defined(CONFIG_SPL_FS_FAT) || defined(CONFIG_SPL_FS_EXT4) @@ -292,15 +299,6 @@ unsigned int cm_get_qspi_controller_clk_hz(void); #endif #endif -/* - * Stack setup - */ -#if defined(CONFIG_TARGET_SOCFPGA_GEN5) -#define CONFIG_SPL_STACK CONFIG_SYS_INIT_SP_ADDR -#elif defined(CONFIG_TARGET_SOCFPGA_ARRIA10) -#define CONFIG_SPL_STACK CONFIG_SYS_SPL_MALLOC_START -#endif - /* Extra Environment */ #ifndef CONFIG_SPL_BUILD -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v4 3/4] arm: socfpga: imply/default common config options
This commit moves common config options used in all socfpga boards to select/imply in Kconfig. This both cleans up the defconfig files as well as makes future changes easier. Options implied/defaulted for all sub-arches: - SPL, SPL_DM, USE_TINY_PRINTF, NR_DRAM_BANKS Options implied/defaulted for implied for A10 & gen5: - FPGA_SOCFPGA, SYS_MALLOC_F_LEN, SYS_TEXT_BASE Options implied/defaulted for gen5: - SPL_STACK_R, SPL_SYS_MALLOC_SIMPLE, SPL_STACK_R_ADDR Signed-off-by: Simon Goldschmidt --- Changes in v4: - adapt to socfpga-next Changes in v3: - adapt to socfpge-next: imply USE_TINY_PRINTF only for gen5 & a10, not s10 Changes in v2: - added patch to imply/default common config options arch/arm/Kconfig | 2 ++ arch/arm/mach-socfpga/Kconfig | 20 configs/socfpga_arria10_defconfig | 6 -- configs/socfpga_arria5_defconfig | 10 -- configs/socfpga_cyclone5_defconfig | 10 -- configs/socfpga_dbm_soc1_defconfig | 10 -- configs/socfpga_de0_nano_soc_defconfig | 10 -- configs/socfpga_de10_nano_defconfig| 10 -- configs/socfpga_de1_soc_defconfig | 10 -- configs/socfpga_is1_defconfig | 8 configs/socfpga_sockit_defconfig | 10 -- configs/socfpga_socrates_defconfig | 10 -- configs/socfpga_sr1500_defconfig | 10 -- configs/socfpga_stratix10_defconfig| 2 -- configs/socfpga_vining_fpga_defconfig | 10 -- 15 files changed, 22 insertions(+), 116 deletions(-) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 77a534f81f..6554ad94f8 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -841,6 +841,8 @@ config ARCH_SOCFPGA imply DM_SPI imply DM_SPI_FLASH imply FAT_WRITE + imply SPL + imply SPL_DM imply SPL_LIBDISK_SUPPORT imply SPL_MMC_SUPPORT imply SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION diff --git a/arch/arm/mach-socfpga/Kconfig b/arch/arm/mach-socfpga/Kconfig index 5e87371f8c..3c6c63067d 100644 --- a/arch/arm/mach-socfpga/Kconfig +++ b/arch/arm/mach-socfpga/Kconfig @@ -1,8 +1,22 @@ if ARCH_SOCFPGA +config NR_DRAM_BANKS + default 1 + +config SPL_STACK_R_ADDR + default 0x0080 if TARGET_SOCFPGA_GEN5 + config SYS_MMCSD_RAW_MODE_U_BOOT_PARTITION_TYPE default 0xa2 +config SYS_MALLOC_F_LEN + default 0x2000 if TARGET_SOCFPGA_ARRIA10 + default 0x2000 if TARGET_SOCFPGA_GEN5 + +config SYS_TEXT_BASE + default 0x0140 if TARGET_SOCFPGA_ARRIA10 + default 0x0140 if TARGET_SOCFPGA_GEN5 + config TARGET_SOCFPGA_ARRIA5 bool select TARGET_SOCFPGA_GEN5 @@ -21,6 +35,8 @@ config TARGET_SOCFPGA_ARRIA10 select SYSCON select SPL_SYSCON if SPL select ETH_DESIGNWARE_SOCFPGA + imply FPGA_SOCFPGA + imply USE_TINY_PRINTF config TARGET_SOCFPGA_CYCLONE5 bool @@ -29,6 +45,10 @@ config TARGET_SOCFPGA_CYCLONE5 config TARGET_SOCFPGA_GEN5 bool select ALTERA_SDRAM + imply FPGA_SOCFPGA + imply SPL_STACK_R + imply SPL_SYS_MALLOC_SIMPLE + imply USE_TINY_PRINTF config TARGET_SOCFPGA_STRATIX10 bool diff --git a/configs/socfpga_arria10_defconfig b/configs/socfpga_arria10_defconfig index f321a0ac3b..b3540cfe42 100644 --- a/configs/socfpga_arria10_defconfig +++ b/configs/socfpga_arria10_defconfig @@ -1,12 +1,9 @@ CONFIG_ARM=y CONFIG_ARCH_SOCFPGA=y -CONFIG_SYS_TEXT_BASE=0x0140 CONFIG_SYS_MALLOC_F_LEN=0x2000 CONFIG_TARGET_SOCFPGA_ARRIA10_SOCDK=y -CONFIG_SPL=y CONFIG_IDENT_STRING="socfpga_arria10" CONFIG_DISTRO_DEFAULTS=y -CONFIG_NR_DRAM_BANKS=1 CONFIG_USE_BOOTARGS=y CONFIG_BOOTARGS="console=ttyS0,115200" # CONFIG_USE_BOOTCOMMAND is not set @@ -28,9 +25,7 @@ CONFIG_MTDIDS_DEFAULT="nor0=ff705000.spi.0" # CONFIG_EFI_PARTITION is not set CONFIG_DEFAULT_DEVICE_TREE="socfpga_arria10_socdk_sdmmc" CONFIG_ENV_IS_IN_MMC=y -CONFIG_SPL_DM=y CONFIG_SPL_DM_SEQ_ALIAS=y -CONFIG_FPGA_SOCFPGA=y CONFIG_DM_GPIO=y CONFIG_DWAPB_GPIO=y CONFIG_DM_MMC=y @@ -42,4 +37,3 @@ CONFIG_SPI=y CONFIG_TIMER=y CONFIG_SPL_TIMER=y CONFIG_DESIGNWARE_APB_TIMER=y -CONFIG_USE_TINY_PRINTF=y diff --git a/configs/socfpga_arria5_defconfig b/configs/socfpga_arria5_defconfig index 2f04092649..d514b14364 100644 --- a/configs/socfpga_arria5_defconfig +++ b/configs/socfpga_arria5_defconfig @@ -1,12 +1,7 @@ CONFIG_ARM=y CONFIG_ARCH_SOCFPGA=y -CONFIG_SYS_TEXT_BASE=0x0140 -CONFIG_SYS_MALLOC_F_LEN=0x2000 CONFIG_TARGET_SOCFPGA_ARRIA5_SOCDK=y -CONFIG_SPL=y -CONFIG_SPL_STACK_R_ADDR=0x0080 CONFIG_DISTRO_DEFAULTS=y -CONFIG_NR_DRAM_BANKS=1 CONFIG_FIT=y # CONFIG_USE_BOOTCOMMAND is not set CONFIG_SYS_CONSOLE_IS_IN_ENV=y @@ -16,8 +11,6 @@ CONFIG_DEFAULT_FDT_FILE="socfpga_arria5_socdk.dtb" CONFIG_VERSION_VARIABLE=y # CONFIG_DISPLAY_BOARDINFO is not set CONFIG_DISPLAY_BOARDINFO_LATE=y -CONFIG_SPL_SYS_MALLOC_SIMPLE=y
[U-Boot] [PATCH v4 1/4] arm: socfpga: fix comment about SPL memory layout
The comment about SPL memory layout for socfpga gen5 is outdated: the initial malloc memory is now at the end of the SRAM, gd is below it (see board_init_f_alloc_reserve). Signed-off-by: Simon Goldschmidt --- Changes in v4: None Changes in v3: None Changes in v2: None include/configs/socfpga_common.h | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/include/configs/socfpga_common.h b/include/configs/socfpga_common.h index f9e2cdc1b3..32ee7426b6 100644 --- a/include/configs/socfpga_common.h +++ b/include/configs/socfpga_common.h @@ -236,9 +236,9 @@ unsigned int cm_get_qspi_controller_clk_hz(void); * * 0x_ .. Start of SRAM * 0x_ .. Top of stack (grows down) - * 0x_ .. Malloc area - * 0x_ .. Global Data - * 0x_FF00 .. End of SRAM + * 0x_ .. Global Data + * 0x_ .. Malloc area + * 0x_ .. End of SRAM * * SRAM Memory layout for Arria 10: * 0xFFE0_ .. Start of SRAM (bottom) -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v4 0/4] arm: socfpga: stack and Kconfig cleanups
This series cleans up stack definitions in socfpga_common.h as well as cleans up defconfig files by implying/defaulting common things in Kconfig files. Finally, it reduces the malloc pool size used in first stage of gen5 SPL (without ddr available) in order to have more space available for code. As this series does not contain direct bugfixes, it targets the socfpga-next branch. Note that this series is meant for socfpga-next but depends on the generic series "spl: full-featured heap cleanups" from: https://patchwork.ozlabs.org/project/uboot/list/?series=99561 Changes in v4: - make this patch 2/4 work without changing a10 heap allocation strategy (as the series doing that has been rejected) - adapt to socfpga-next Changes in v3: - removed patch 2/5 from v2 (moved to patchwork #1067366, series #99561) - adapt to socfpge-next: imply USE_TINY_PRINTF only for gen5 & a10, not s10 - adapt to socfpga-next Changes in v2: - fix commit message: "SPL post-reloc", not "SPL pre-reloc" - added patch to imply/default common config options - added patch to reduce gen5 SPL initial malloc pool to 2 KiB Simon Goldschmidt (4): arm: socfpga: fix comment about SPL memory layout arm: socfpga: put initial U-Boot stack into DDR arm: socfpga: imply/default common config options arm: socfpga: gen5: reduce SPL pre-reloc malloc arch/arm/Kconfig | 2 ++ arch/arm/mach-socfpga/Kconfig | 23 configs/socfpga_arria10_defconfig | 6 configs/socfpga_arria5_defconfig | 10 -- configs/socfpga_cyclone5_defconfig | 10 -- configs/socfpga_dbm_soc1_defconfig | 10 -- configs/socfpga_de0_nano_soc_defconfig | 10 -- configs/socfpga_de10_nano_defconfig| 10 -- configs/socfpga_de1_soc_defconfig | 10 -- configs/socfpga_is1_defconfig | 8 - configs/socfpga_sockit_defconfig | 10 -- configs/socfpga_socrates_defconfig | 10 -- configs/socfpga_sr1500_defconfig | 10 -- configs/socfpga_stratix10_defconfig| 2 -- configs/socfpga_vining_fpga_defconfig | 10 -- include/configs/socfpga_common.h | 48 -- 16 files changed, 48 insertions(+), 141 deletions(-) -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] Add domain mapping for Pepperl+Fuchs
Wolfang, Am 21.03.2019 um 20:30 schrieb Simon Goldschmidt: Hi Wolfgang, Am 24.01.2019 um 13:22 schrieb Tom Rini: On Thu, Jan 24, 2019 at 12:40:14PM +0100, Simon Goldschmidt wrote: On Mon, Aug 13, 2018 at 12:07 PM Simon Goldschmidt wrote: Signed-off-by: Simon Goldschmidt Gentle ping for: https://patchwork.ozlabs.org/patch/956901/ https://patchwork.ozlabs.org/patch/956902/ Who is responsible for the gitdm repo? That would be Wolfgang. Would you consider merging this series into the gitdm repo? https://patchwork.ozlabs.org/project/uboot/list/?series=60515 Gentle ping? I'd be happy to get this series merged before the stats for v2019.04 Thanks, Simon Thanks, Simon Thanks, Simon --- u-boot-config/domain-map | 1 + 1 file changed, 1 insertion(+) diff --git a/u-boot-config/domain-map b/u-boot-config/domain-map index f2abba9..74c1538 100644 --- a/u-boot-config/domain-map +++ b/u-boot-config/domain-map @@ -262,6 +262,7 @@ parallels.com Parallels pasemi.com PA Semi Corporation pcs.de PCS Systemtechnik pengutronix.de Pengutronix +pepperl-fuchs.com Pepperl+Fuchs pheonix.comPhoeonix philosys.dePhilosys Software phytec.de Phytec -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/2] Revert "cmd: Kconfig: Do not include EEPROM if DM_I2C is used without DM_I2C_COMPAT"
Am 30.03.2019 um 22:18 schrieb Simon Glass:
On Tue, 26 Mar 2019 at 06:39, Simon Goldschmidt
wrote:
This reverts commit 65a97e7fcf54feb7c4ebe1aee8a572830af4cf51.
The 'eeprom' command has been converted to work with DM_I2C in a patch
submitted around the same time as this commit:
commit 0c07a9b4078d ("eeprom: Add device model based I2C support to eeprom
command")
Signed-off-by: Simon Goldschmidt
---
Changes in v2:
- added patch to fix DM_I2C eeprom code to work without
CONFIG_SYS_I2C_EEPROM_BUS
cmd/Kconfig | 1 -
1 file changed, 1 deletion(-)
Reviewed-by: Simon Glass
Who will take this series? It's assigned in to Marek in patchwork, but
might go via Heiko's i2c tree? Or directly via Tom?
I have sent patches (move socfpga_vining to DM_I2C) that are based on
this series...
Thanks,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 3/4] arm: socfpga: remove CONFIG_SYS_BOOTMAPSZ
socfpga_common.h defines CONFIG_SYS_BOOTMAPSZ to 64 MiB. Since having this define overrides the 'bootm_size' env variable for the whole socfpga platform, let's remove this define from socfpga_common.h and instead rely on the 'bootm_size' env variable (which is initialized to 160 MiB in the same file's default env). This gives users the chance to override it in their own environment. Signed-off-by: Simon Goldschmidt --- Changes in v2: None include/configs/socfpga_common.h | 2 -- 1 file changed, 2 deletions(-) diff --git a/include/configs/socfpga_common.h b/include/configs/socfpga_common.h index 5b5e5f5d43..5eccb01d1d 100644 --- a/include/configs/socfpga_common.h +++ b/include/configs/socfpga_common.h @@ -10,8 +10,6 @@ */ #define CONFIG_CLOCKS -#define CONFIG_SYS_BOOTMAPSZ (64 * 1024 * 1024) - #define CONFIG_TIMESTAMP /* Print image info with timestamp */ /* -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 4/4] arm: socfpga: clean up board config files
Remove outdated defines (not used any more, outdated due to DM conversion) from various socfpga files in include/config. Signed-off-by: Simon Goldschmidt --- Changes in v2: - added (this) patch with further cleanups to the socfpga board config files include/configs/socfpga_arria10_socdk.h | 6 -- include/configs/socfpga_arria5_socdk.h | 2 -- include/configs/socfpga_cyclone5_socdk.h | 2 -- include/configs/socfpga_de0_nano_soc.h | 2 -- include/configs/socfpga_de10_nano.h | 2 -- include/configs/socfpga_de1_soc.h| 2 -- include/configs/socfpga_is1.h| 2 -- include/configs/socfpga_sockit.h | 2 -- include/configs/socfpga_socrates.h | 2 -- include/configs/socfpga_sr1500.h | 11 --- include/configs/socfpga_vining_fpga.h| 9 - 11 files changed, 42 deletions(-) diff --git a/include/configs/socfpga_arria10_socdk.h b/include/configs/socfpga_arria10_socdk.h index 0f116fbf2d..92630c5e6e 100644 --- a/include/configs/socfpga_arria10_socdk.h +++ b/include/configs/socfpga_arria10_socdk.h @@ -19,12 +19,6 @@ /* Memory configurations */ #define PHYS_SDRAM_1_SIZE 0x4000 -/* Ethernet on SoC (EMAC) */ - -/* - * U-Boot environment configurations - */ - /* * Serial / UART configurations */ diff --git a/include/configs/socfpga_arria5_socdk.h b/include/configs/socfpga_arria5_socdk.h index 24fcdd8b5a..af6137aeb1 100644 --- a/include/configs/socfpga_arria5_socdk.h +++ b/include/configs/socfpga_arria5_socdk.h @@ -14,8 +14,6 @@ #define CONFIG_LOADADDR0x0100 #define CONFIG_SYS_LOAD_ADDR CONFIG_LOADADDR -/* Ethernet on SoC (EMAC) */ - /* The rest of the configuration is shared */ #include diff --git a/include/configs/socfpga_cyclone5_socdk.h b/include/configs/socfpga_cyclone5_socdk.h index 18da8496ef..028db2a09e 100644 --- a/include/configs/socfpga_cyclone5_socdk.h +++ b/include/configs/socfpga_cyclone5_socdk.h @@ -14,8 +14,6 @@ #define CONFIG_LOADADDR0x0100 #define CONFIG_SYS_LOAD_ADDR CONFIG_LOADADDR -/* Ethernet on SoC (EMAC) */ - /* The rest of the configuration is shared */ #include diff --git a/include/configs/socfpga_de0_nano_soc.h b/include/configs/socfpga_de0_nano_soc.h index d3224d5bd3..21108e3447 100644 --- a/include/configs/socfpga_de0_nano_soc.h +++ b/include/configs/socfpga_de0_nano_soc.h @@ -14,8 +14,6 @@ #define CONFIG_LOADADDR0x0100 #define CONFIG_SYS_LOAD_ADDR CONFIG_LOADADDR -/* Ethernet on SoC (EMAC) */ - /* The rest of the configuration is shared */ #include diff --git a/include/configs/socfpga_de10_nano.h b/include/configs/socfpga_de10_nano.h index 2fcabff8af..d85f98fbd4 100644 --- a/include/configs/socfpga_de10_nano.h +++ b/include/configs/socfpga_de10_nano.h @@ -14,8 +14,6 @@ #define CONFIG_LOADADDR0x0100 #define CONFIG_SYS_LOAD_ADDR CONFIG_LOADADDR -/* Ethernet on SoC (EMAC) */ - /* The rest of the configuration is shared */ #include diff --git a/include/configs/socfpga_de1_soc.h b/include/configs/socfpga_de1_soc.h index f37099c58f..9919d292dc 100644 --- a/include/configs/socfpga_de1_soc.h +++ b/include/configs/socfpga_de1_soc.h @@ -14,8 +14,6 @@ #define CONFIG_LOADADDR0x0100 #define CONFIG_SYS_LOAD_ADDR CONFIG_LOADADDR -/* Ethernet on SoC (EMAC) */ - /* The rest of the configuration is shared */ #include diff --git a/include/configs/socfpga_is1.h b/include/configs/socfpga_is1.h index c233c208a5..c4da5947f3 100644 --- a/include/configs/socfpga_is1.h +++ b/include/configs/socfpga_is1.h @@ -19,8 +19,6 @@ /* Ethernet on SoC (EMAC) */ #if defined(CONFIG_CMD_NET) #define CONFIG_ARP_TIMEOUT 500UL - -/* PHY */ #endif /* The rest of the configuration is shared */ diff --git a/include/configs/socfpga_sockit.h b/include/configs/socfpga_sockit.h index 3a7f354914..97249a 100644 --- a/include/configs/socfpga_sockit.h +++ b/include/configs/socfpga_sockit.h @@ -14,8 +14,6 @@ #define CONFIG_LOADADDR0x0100 #define CONFIG_SYS_LOAD_ADDR CONFIG_LOADADDR -/* Ethernet on SoC (EMAC) */ - /* The rest of the configuration is shared */ #include diff --git a/include/configs/socfpga_socrates.h b/include/configs/socfpga_socrates.h index f0d9347891..7faea150a9 100644 --- a/include/configs/socfpga_socrates.h +++ b/include/configs/socfpga_socrates.h @@ -14,8 +14,6 @@ #define CONFIG_LOADADDR0x0100 #define CONFIG_SYS_LOAD_ADDR CONFIG_LOADADDR -/* Ethernet on SoC (EMAC) */ - /* The rest of the configuration is shared */ #include diff --git a/include/configs/socfpga_sr1500.h b/include/configs/socfpga_sr1500.h index b6a98611c0..3a8ccc3021 100644 --- a/include/configs/socfpga_sr1500.h +++ b/include/configs/socfpga_sr1500.h @@ -19,8 +19,6 @@ /* The PHY is autodetected, so no MII PHY address is needed here */ #define PHY_ANEG_TIMEOUT 8000 -/* Environment */ - /* Enable SPI
[U-Boot] [PATCH v2 2/4] arm: socfpga: clean up socfpga_common.h
Remove outdated defines (not used any more, outdated due to DM conversion) from socfpga_common.h. Signed-off-by: Simon Goldschmidt --- Changes in v2: - remove even more outdated things include/configs/socfpga_common.h | 40 1 file changed, 40 deletions(-) diff --git a/include/configs/socfpga_common.h b/include/configs/socfpga_common.h index a65fc804e3..5b5e5f5d43 100644 --- a/include/configs/socfpga_common.h +++ b/include/configs/socfpga_common.h @@ -72,29 +72,12 @@ #define CONFIG_SYS_BARGSIZECONFIG_SYS_CBSIZE /* Boot argument buffer size */ -#ifndef CONFIG_SYS_HOSTNAME -#define CONFIG_SYS_HOSTNAMECONFIG_SYS_BOARD -#endif - /* * Cache */ #define CONFIG_SYS_L2_PL310 #define CONFIG_SYS_PL310_BASE SOCFPGA_MPUL2_ADDRESS -/* - * EPCS/EPCQx1 Serial Flash Controller - */ -#ifdef CONFIG_ALTERA_SPI -/* - * The base address is configurable in QSys, each board must specify the - * base address based on it's particular FPGA configuration. Please note - * that the address here is incremented by 0x400 from the Base address - * selected in QSys, since the SPI registers are at offset +0x400. - * #define CONFIG_SYS_SPI_BASE 0xff240400 - */ -#endif - /* * Ethernet on SoC (EMAC) */ @@ -162,15 +145,6 @@ unsigned int cm_get_qspi_controller_clk_hz(void); #define CONFIG_CQSPI_REF_CLK cm_get_qspi_controller_clk_hz() #endif -/* - * Designware SPI support - */ - -/* - * Serial Driver - */ -#define CONFIG_SYS_NS16550_SERIAL - /* * USB */ @@ -206,20 +180,6 @@ unsigned int cm_get_qspi_controller_clk_hz(void); #define CONFIG_ENV_SECT_SIZE (64 * 1024) #endif -/* - * mtd partitioning for serial NOR flash - * - * device nor0 , # parts = 6 - * #: namesizeoffset mask_flags - * 0: u-boot 0x0010 0x 0 - * 1: env10x0004 0x0010 0 - * 2: env20x0004 0x0014 0 - * 3: UBI 0x03e8 0x0018 0 - * 4: boot0x00e8 0x0018 0 - * 5: rootfs 0x0100 0x0100 0 - * - */ - /* * SPL * -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 0/4] arm: socfpga: clean up socfpga_common.h
This series cleans up the include/configs/socfpga_common.h file a bit. It removes some defines that are used nowhere and cleans up some leftovers after various subsystems have been converted to use DM. Changes in v2: - added patch to move socfpga_vining to DM_I2C - remove even more outdated things - added patch with further cleanups to the socfpga board config files Simon Goldschmidt (4): arm: socfpga: move vining_fpga to DM_I2C arm: socfpga: clean up socfpga_common.h arm: socfpga: remove CONFIG_SYS_BOOTMAPSZ arm: socfpga: clean up board config files configs/socfpga_vining_fpga_defconfig| 8 ++- include/configs/socfpga_arria10_socdk.h | 6 --- include/configs/socfpga_arria5_socdk.h | 2 - include/configs/socfpga_common.h | 68 include/configs/socfpga_cyclone5_socdk.h | 2 - include/configs/socfpga_de0_nano_soc.h | 2 - include/configs/socfpga_de10_nano.h | 2 - include/configs/socfpga_de1_soc.h| 2 - include/configs/socfpga_is1.h| 2 - include/configs/socfpga_sockit.h | 2 - include/configs/socfpga_socrates.h | 2 - include/configs/socfpga_sr1500.h | 11 include/configs/socfpga_vining_fpga.h| 18 --- 13 files changed, 7 insertions(+), 120 deletions(-) -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 1/4] arm: socfpga: move vining_fpga to DM_I2C
All socfpga boards except for vining_fpga use DM_I2C. Enable DM_I2C for this board and set the EEPROM defines via Kconfig (enabling CONFIG_I2C_EEPROM from MISC). Signed-off-by: Simon Goldschmidt --- Changes in v2: - added (this) patch to move socfpga_vining to DM_I2C configs/socfpga_vining_fpga_defconfig | 8 +++- include/configs/socfpga_common.h | 26 -- include/configs/socfpga_vining_fpga.h | 9 - 3 files changed, 7 insertions(+), 36 deletions(-) diff --git a/configs/socfpga_vining_fpga_defconfig b/configs/socfpga_vining_fpga_defconfig index 7b47b111b7..4a7f775337 100644 --- a/configs/socfpga_vining_fpga_defconfig +++ b/configs/socfpga_vining_fpga_defconfig @@ -16,8 +16,8 @@ CONFIG_VERSION_VARIABLE=y CONFIG_DISPLAY_BOARDINFO_LATE=y CONFIG_SPL_SPI_LOAD=y CONFIG_CMD_ASKENV=y -CONFIG_CMD_GREPENV=y CONFIG_CMD_EEPROM=y +CONFIG_CMD_GREPENV=y CONFIG_CMD_DFU=y # CONFIG_CMD_FLASH is not set CONFIG_CMD_GPIO=y @@ -44,6 +44,7 @@ CONFIG_DFU_RAM=y CONFIG_DFU_SF=y CONFIG_DM_GPIO=y CONFIG_DWAPB_GPIO=y +CONFIG_DM_I2C=y CONFIG_LED_STATUS=y CONFIG_LED_STATUS_GPIO=y CONFIG_LED_STATUS0=y @@ -55,6 +56,11 @@ CONFIG_LED_STATUS_BIT2=54 CONFIG_LED_STATUS3=y CONFIG_LED_STATUS_BIT3=65 CONFIG_LED_STATUS_CMD=y +CONFIG_MISC=y +CONFIG_I2C_EEPROM=y +CONFIG_SYS_I2C_EEPROM_ADDR=0x50 +CONFIG_SYS_EEPROM_PAGE_WRITE_BITS=3 +CONFIG_SYS_EEPROM_PAGE_WRITE_DELAY_MS=70 CONFIG_DM_MMC=y CONFIG_MMC_DW=y CONFIG_MTD_DEVICE=y diff --git a/include/configs/socfpga_common.h b/include/configs/socfpga_common.h index a501b5209f..a65fc804e3 100644 --- a/include/configs/socfpga_common.h +++ b/include/configs/socfpga_common.h @@ -149,32 +149,6 @@ #define CONFIG_SYS_NAND_DATA_BASE SOCFPGA_NANDDATA_ADDRESS #endif -/* - * I2C support - */ -#ifndef CONFIG_DM_I2C -#define CONFIG_SYS_I2C -#define CONFIG_SYS_I2C_BASESOCFPGA_I2C0_ADDRESS -#define CONFIG_SYS_I2C_BASE1 SOCFPGA_I2C1_ADDRESS -#define CONFIG_SYS_I2C_BASE2 SOCFPGA_I2C2_ADDRESS -#define CONFIG_SYS_I2C_BASE3 SOCFPGA_I2C3_ADDRESS -/* Using standard mode which the speed up to 100Kb/s */ -#define CONFIG_SYS_I2C_SPEED 10 -#define CONFIG_SYS_I2C_SPEED1 10 -#define CONFIG_SYS_I2C_SPEED2 10 -#define CONFIG_SYS_I2C_SPEED3 10 -/* Address of device when used as slave */ -#define CONFIG_SYS_I2C_SLAVE 0x02 -#define CONFIG_SYS_I2C_SLAVE1 0x02 -#define CONFIG_SYS_I2C_SLAVE2 0x02 -#define CONFIG_SYS_I2C_SLAVE3 0x02 -#ifndef __ASSEMBLY__ -/* Clock supplied to I2C controller in unit of MHz */ -unsigned int cm_get_l4_sp_clk_hz(void); -#define IC_CLK (cm_get_l4_sp_clk_hz() / 100) -#endif -#endif /* CONFIG_DM_I2C */ - /* * QSPI support */ diff --git a/include/configs/socfpga_vining_fpga.h b/include/configs/socfpga_vining_fpga.h index 5517ed722d..0e547a1295 100644 --- a/include/configs/socfpga_vining_fpga.h +++ b/include/configs/socfpga_vining_fpga.h @@ -16,15 +16,6 @@ #define CONFIG_LOADADDR0x0100 #define CONFIG_SYS_LOAD_ADDR CONFIG_LOADADDR -/* I2C EEPROM */ -#ifdef CONFIG_CMD_EEPROM -#define CONFIG_SYS_I2C_EEPROM_ADDR 0x50 -#define CONFIG_SYS_I2C_EEPROM_ADDR_LEN 1 -#define CONFIG_SYS_I2C_EEPROM_BUS 0 -#define CONFIG_SYS_EEPROM_PAGE_WRITE_BITS 3 -#define CONFIG_SYS_EEPROM_PAGE_WRITE_DELAY_MS 70 -#endif - /* * Status LEDs: * 0 ... Top Green -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] rockchip: add Kever Yang as co-custodian
On Tue, Apr 09, 2019 at 03:54:07PM +0800, Kever Yang wrote: > Add Tom. > > > Thanks, > - Kever > On 04/03/2019 03:59 PM, Philipp Tomsich wrote: > > > >> On 03.04.2019, at 09:28, Kever Yang wrote: > >> > >> This updates MAINTAINERS and git-mailrc to add me as a > >> co-custodian for rockchip > >> > >> Signed-off-by: Kever Yang > > As previously discussed off-list: happy to have you on board. > > I sincerely hope that this will finally give us the ability to get > > changes tested > > across a wider range of boards than today! > > > > Reviewed-by: Philipp Tomsich > > Acked-by: Philipp Tomsich Acked-by: Tom Rini I assume this will come in via a rockchip PR and please consult with me off-list if we need to add more ssh keys. Thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] fastboot: Replace literal 32 with PART_NAME_LEN
Running `md5sum drivers/fastboot/fb_mmc.o` before and after the change returns the same result, so this is expectedly a non-functional change. In addition, `git grep -w 32 -- drivers/fastboot/` reveals no other occurrences of the magic number, except in below line where it stands for something unrelated to partition name length: drivers/fastboot/fb_command.c:char cmdbuf[32]; Reviewed-by: Eugeniu Rosca ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Automatic starting of netconsole at boot
I think there is a bug in netconsole of u-boot: about every 8 seconds it pauses for about another 8 seconds. Ie. some of the pressed keys on the netconsole host get struck (gets lost), after a while it continues. Happens with "tools/netconsole" as well with "nc -u -l -p ". This can also be seen from another terminal when pinging the device: every a while (~ every 8 seconds) the output of ping pauses for about 8 seconds... ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] Revert "fdt: Fix FIT header verification in mkimage and conduct same checks as bootm"
FTR, using updated email addresses for agraf and sjg. On 2019-04-09, Jordan Hand wrote: > On Mon, Apr 8, 2019 at 9:54 PM Vagrant Cascadian wrote: >> >> This reverts commit d32aa3cae44e618048ff7f378577d44f9b6d6dcc. >> >> This breaks the "list_image" test in tests/image/test-imagetools.sh, >> where mkimage and dumpimage are expected to have the same output: >> >> Listing image contents... >> # debian/build/tools/tools/mkimage -l linux.itb >> debian/build/tools/tools/mkimage: verify_header failed for Default Image >> support with exit code -9 >> >> Obviously, blindly reverting this patch may not the best way forward, > > I'll take a look at this today and see if there's a simple way forward > without reverting Thanks! >> but the same verify_header failed message occurs also with some >> real-world .itb files, such as that used on the pinebook. So it's not > > Would you be able to point me to any .its files that fail this check > in the real world. The one created by: board/sunxi/mksunxi_fit_atf.sh I haven't confirmed, but I would guess possibly also: arch/arm/mach-rockchip/make_fit_atf.py If needed, I can try to get some actual .its/.itb files to work with. > Also are you seeing failures while creating the image from its as well > with real world images (mkimage -l its itb) or only when listing the > header with -l? It *seems* to create the images just fine; apparently only when listing them. The output of "dumpimage -l" and "mkimage -l" used to be the same, and "dumpimage -l" still works fine. live well, vagrant signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] Revert "fdt: Fix FIT header verification in mkimage and conduct same checks as bootm"
(Forgot to reply all. Sorry for the clutter Vagrant)
See the patch I just submitted "fdt: Fix mkimage list to try every
header type" for what I believe to be the correct fix for this
problem.
Thanks,
Jordan
>
> On Mon, Apr 8, 2019 at 9:54 PM Vagrant Cascadian wrote:
> >
> > This reverts commit d32aa3cae44e618048ff7f378577d44f9b6d6dcc.
> >
> > This breaks the "list_image" test in tests/image/test-imagetools.sh,
> > where mkimage and dumpimage are expected to have the same output:
> >
> > Listing image contents...
> > # debian/build/tools/tools/mkimage -l linux.itb
> > debian/build/tools/tools/mkimage: verify_header failed for Default Image
> > support with exit code -9
> >
> > Obviously, blindly reverting this patch may not the best way forward,
>
> I'll take a look at this today and see if there's a simple way forward
> without reverting
>
> > but the same verify_header failed message occurs also with some
> > real-world .itb files, such as that used on the pinebook. So it's not
>
> Would you be able to point me to any .its files that fail this check
> in the real world.
>
> Also are you seeing failures while creating the image from its as well
> with real world images (mkimage -l its itb) or only when listing the
> header with -l?
>
> > just the tests that need to be updated.
> >
> >
> > live well,
> > vagrant
> >
> > Signed-off-by: Vagrant Cascadian
> > ---
> >
> > tools/fit_common.c | 5 +
> > tools/fit_common.h | 8
> > tools/imagetool.c | 34 +-
> > tools/imagetool.h | 19 ---
> > tools/mkimage.c| 2 +-
> > 5 files changed, 3 insertions(+), 65 deletions(-)
> >
> > diff --git a/tools/fit_common.c b/tools/fit_common.c
> > index 9506390214..d96085eaad 100644
> > --- a/tools/fit_common.c
> > +++ b/tools/fit_common.c
> > @@ -26,10 +26,7 @@
> > int fit_verify_header(unsigned char *ptr, int image_size,
> > struct image_tool_params *params)
> > {
> > - if (fdt_check_header(ptr) != EXIT_SUCCESS || !fit_check_format(ptr))
> > - return EXIT_FAILURE;
> > -
> > - return EXIT_SUCCESS;
> > + return fdt_check_header(ptr);
> > }
> >
> > int fit_check_image_types(uint8_t type)
> > diff --git a/tools/fit_common.h b/tools/fit_common.h
> > index 9e09624f64..71e792e3c4 100644
> > --- a/tools/fit_common.h
> > +++ b/tools/fit_common.h
> > @@ -10,14 +10,6 @@
> > #include "mkimage.h"
> > #include
> >
> > -/**
> > - * Verify the format of FIT header pointed to by ptr
> > - *
> > - * @ptr: image header to be verified
> > - * @image_size: size of while image
> > - * @params: mkimage parameters
> > - * @return 0 if OK, -1 on error
> > - */
> > int fit_verify_header(unsigned char *ptr, int image_size,
> > struct image_tool_params *params);
> >
> > diff --git a/tools/imagetool.c b/tools/imagetool.c
> > index ba1f64aa37..b3e628f612 100644
> > --- a/tools/imagetool.c
> > +++ b/tools/imagetool.c
> > @@ -46,7 +46,7 @@ int imagetool_verify_print_header(
> >
> > if (retval == 0) {
> > /*
> > -* Print the image information if verify is
> > +* Print the image information if verify is
> > * successful
> > */
> > if ((*curr)->print_header) {
> > @@ -65,38 +65,6 @@ int imagetool_verify_print_header(
> > return retval;
> > }
> >
> > -int imagetool_verify_print_header_by_type(
> > - void *ptr,
> > - struct stat *sbuf,
> > - struct image_type_params *tparams,
> > - struct image_tool_params *params)
> > -{
> > - int retval;
> > -
> > - retval = tparams->verify_header((unsigned char *)ptr, sbuf->st_size,
> > - params);
> > -
> > - if (retval == 0) {
> > - /*
> > -* Print the image information if verify is successful
> > -*/
> > - if (tparams->print_header) {
> > - if (!params->quiet)
> > - tparams->print_header(ptr);
> > - } else {
> > - fprintf(stderr,
> > - "%s: print_header undefined for %s\n",
> > - params->cmdname, tparams->name);
> > - }
> > - } else {
> > - fprintf(stderr,
> > - "%s: verify_header failed for %s with exit code
> > %d\n",
> > - params->cmdname, tparams->name, retval);
> > - }
> > -
> > - return retval;
> > -}
> > -
> > int imagetool_save_subimage(
> > const char *file_name,
> > ulong file_data,
> > diff --git a/tools/imagetool.h b/tools/imagetool.h
> > index 2689a4004a..71471420f9 100644
> > --- a/tools/imagetool.h
> > +++ b/tools/imagetool.h
> > @@ -179,25
Re: [U-Boot] [PATCH] i2c: mvtwsi: fix hang on SPL bind
Hi Stefan,
On Tue, Apr 09 2019, Stefan Roese wrote:
> On 07.04.19 11:30, Baruch Siach wrote:
>> The mvebu specific debug register is not accessible when the bind code
>> runs in SPL. Skip it.
>
> The other I2C registers can be accessed but only the debug register
> not? Do you know, why this is the case?
Access to other registers might hang as well, I have not tested. The
debug register is the only one that the .bind callback touches. .bind
callbacks are called before board_early_init_f() that configures the
MPP.
baruch
>> Signed-off-by: Baruch Siach
>> ---
>> drivers/i2c/mvtwsi.c | 4
>> 1 file changed, 4 insertions(+)
>>
>> diff --git a/drivers/i2c/mvtwsi.c b/drivers/i2c/mvtwsi.c
>> index 74ac0a4aa789..05560e112729 100644
>> --- a/drivers/i2c/mvtwsi.c
>> +++ b/drivers/i2c/mvtwsi.c
>> @@ -801,6 +801,10 @@ static int mvtwsi_i2c_ofdata_to_platdata(struct udevice
>> *bus)
>> static void twsi_disable_i2c_slave(struct mvtwsi_registers *twsi)
>> {
>> +/* The debug register is not accessible in early boot */
>> +if (IS_ENABLED(CONFIG_SPL_BUILD))
>> +return;
>> +
>> clrbits_le32(>debug, BIT(18));
>> }
--
http://baruch.siach.name/blog/ ~. .~ Tk Open Systems
=}ooO--U--Ooo{=
- bar...@tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v1] fdt: Fix mkimage list to try every header type
Signed-off-by: Jordan Hand
---
Image type is not supplied to `mkimage -l`. For this reason, we cannot
use imagetool_verify_print_header_by_type. Instead, this patch uses
imagetool_verify_print_header to look through all header types to find
one where image validation succeeds.
This patch fixes failures in test/image/test-imagetools.sh
tools/mkimage.c | 23 +++
1 file changed, 15 insertions(+), 8 deletions(-)
diff --git a/tools/mkimage.c b/tools/mkimage.c
index 2899adff81..d1e1a6743d 100644
--- a/tools/mkimage.c
+++ b/tools/mkimage.c
@@ -403,14 +403,21 @@ int main(int argc, char **argv)
exit (EXIT_FAILURE);
}
- /*
-* scan through mkimage registry for all supported image types
-* and verify the input image file header for match
-* Print the image information for matched image type
-* Returns the error code if not matched
-*/
- retval = imagetool_verify_print_header_by_type(ptr, ,
- tparams, );
+ if (params.fflag) {
+ /*
+* Verifies the header format based on the expected
header for image
+* type in tparams
+*/
+ retval = imagetool_verify_print_header_by_type(ptr,
,
+ tparams, );
+ } else {
+ /**
+* When listing the image, we are not given the image
type. Simply check all
+* image types to find one that matches our header
+*/
+ retval = imagetool_verify_print_header(ptr, ,
+ tparams, );
+ }
(void) munmap((void *)ptr, sbuf.st_size);
(void) close (ifd);
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2] ARM: rmobile: rcar-common: Zap arch_preboot_os()
On 4/9/19 7:11 PM, Eugeniu Rosca wrote:
> v2018.01 commit e23eb942ad103f ("ARM: rmobile: Stop using
> rcar-common/common.c on Gen3") removed
> board/renesas/rcar-common/common.c from the build chain with the
> reasoning that calling arch_preboot_os() is no longer needed.
>
> However, it left the arch_preboot_os() in place. Get rid of it.
> This is done in preparation of resurrecting rcar-common/common.c.
>
> NOTE: The three removed header includes (io.h, sys_proto.h, rcar-mstp.h)
> are in direct relationship with the dropped arch_preboot_os() hook. The
> other headers (common.h, rmobile.h) are going to be needed by pretty
> much anything that is going to appear in the rcar common code. So, keep
> the two in place.
>
> Signed-off-by: Eugeniu Rosca
> ---
> v2:
> - [Marek] Drop Makefile changes. Reword the title/description.
>
> v1:
> - https://patchwork.ozlabs.org/patch/1082364/
> ---
> board/renesas/rcar-common/common.c | 53 --
> 1 file changed, 53 deletions(-)
>
> diff --git a/board/renesas/rcar-common/common.c
> b/board/renesas/rcar-common/common.c
> index 1129f4bf0c08..1ce6e2eac1bf 100644
> --- a/board/renesas/rcar-common/common.c
> +++ b/board/renesas/rcar-common/common.c
> @@ -8,57 +8,4 @@
> */
>
> #include
> -#include
> -#include
> #include
> -#include
> -
> -#define TSTR00x04
> -#define TSTR0_STR0 0x01
> -
> -static struct mstp_ctl mstptbl[] = {
> - { SMSTPCR0, MSTP0_BITS, CONFIG_SMSTP0_ENA,
> - RMSTPCR0, MSTP0_BITS, CONFIG_RMSTP0_ENA },
> - { SMSTPCR1, MSTP1_BITS, CONFIG_SMSTP1_ENA,
> - RMSTPCR1, MSTP1_BITS, CONFIG_RMSTP1_ENA },
> - { SMSTPCR2, MSTP2_BITS, CONFIG_SMSTP2_ENA,
> - RMSTPCR2, MSTP2_BITS, CONFIG_RMSTP2_ENA },
> - { SMSTPCR3, MSTP3_BITS, CONFIG_SMSTP3_ENA,
> - RMSTPCR3, MSTP3_BITS, CONFIG_RMSTP3_ENA },
> - { SMSTPCR4, MSTP4_BITS, CONFIG_SMSTP4_ENA,
> - RMSTPCR4, MSTP4_BITS, CONFIG_RMSTP4_ENA },
> - { SMSTPCR5, MSTP5_BITS, CONFIG_SMSTP5_ENA,
> - RMSTPCR5, MSTP5_BITS, CONFIG_RMSTP5_ENA },
> -#ifdef CONFIG_RCAR_GEN3
> - { SMSTPCR6, MSTP6_BITS, CONFIG_SMSTP6_ENA,
> - RMSTPCR6, MSTP6_BITS, CONFIG_RMSTP6_ENA },
> -#endif
> - { SMSTPCR7, MSTP7_BITS, CONFIG_SMSTP7_ENA,
> - RMSTPCR7, MSTP7_BITS, CONFIG_RMSTP7_ENA },
> - { SMSTPCR8, MSTP8_BITS, CONFIG_SMSTP8_ENA,
> - RMSTPCR8, MSTP8_BITS, CONFIG_RMSTP8_ENA },
> - { SMSTPCR9, MSTP9_BITS, CONFIG_SMSTP9_ENA,
> - RMSTPCR9, MSTP9_BITS, CONFIG_RMSTP9_ENA },
> - { SMSTPCR10, MSTP10_BITS, CONFIG_SMSTP10_ENA,
> - RMSTPCR10, MSTP10_BITS, CONFIG_RMSTP10_ENA },
> - { SMSTPCR11, MSTP11_BITS, CONFIG_SMSTP1_ENA,
> - RMSTPCR11, MSTP11_BITS, CONFIG_RMSTP11_ENA },
> -};
> -
> -void arch_preboot_os(void)
> -{
> - int i;
> -
> - /* stop TMU0 */
> - mstp_clrbits_le32(TMU_BASE + TSTR0, TMU_BASE + TSTR0, TSTR0_STR0);
> -
> - /* Stop module clock */
> - for (i = 0; i < ARRAY_SIZE(mstptbl); i++) {
> - mstp_setclrbits_le32((uintptr_t)mstptbl[i].s_addr,
> - mstptbl[i].s_dis,
> - mstptbl[i].s_ena);
> - mstp_setclrbits_le32((uintptr_t)mstptbl[i].r_addr,
> - mstptbl[i].r_dis,
> - mstptbl[i].r_ena);
> - }
> -}
>
Applied, thanks
--
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: rmobile: ulcb/salvator-x: re-enable rcar-common/common.c
On Tue, Apr 09, 2019 at 06:00:57PM +0200, Marek Vasut wrote: > On 4/9/19 5:34 PM, Eugeniu Rosca wrote: > > On Tue, Apr 09, 2019 at 05:23:17PM +0200, Marek Vasut wrote: > >> On 4/9/19 5:08 PM, Eugeniu Rosca wrote: > > [..] > >>> diff --git a/board/renesas/rcar-common/common.c > >>> b/board/renesas/rcar-common/common.c > > > > [..] > > > >> This should be a separate patch, one which only removes this code which > >> is unused. Presumably the whole file should just be removed. > > > > [..] > > > >>> diff --git a/board/renesas/ulcb/Makefile b/board/renesas/ulcb/Makefile > >>> > >>> -obj-y:= ulcb.o cpld.o > >>> +obj-y:= ulcb.o cpld.o ../rcar-common/common.o > >> > >> This ends up including an empty file, which is useless. > > > > Do you plan to push a v2 for > > https://patchwork.ozlabs.org/patch/1051603/ ? > > I was rather thinking of doing a follow-up patch, so that in case > something broke, I could bisect it. And maybe this is actually better, > since I could apply the patches in this order: > - The DRAM DT config > - The common.c cleanup of this patch > - Perform the deduplication as needed and enable common.c in the build The sequence looks good to me. > So can you split the common.c cleanup from this patch so I can use it? Done in https://patchwork.ozlabs.org/patch/1082549/ > > > If so, board/renesas/rcar-common/common.c might be the perfect > > place to host the duplicated code, i.e. you will need to re-add > > board/renesas/rcar-common/common.c to the build chain. > > > >> > >> -- > >> Best regards, > >> Marek Vasut > > > > Best regards, > > Eugeniu. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] phy: ti: Init node before reading
Hi Michal, On Tue, Apr 9, 2019 at 5:51 AM Michal Simek wrote: > > On 17. 03. 19 0:06, Hannes Schmelzer wrote: > > "U-Boot" schrieb am 16.03.2019 12:43:17: > > > >> Von: Michal Simek > >> An: u-boot@lists.denx.de > >> Kopie: Janine Hagemann , Joe Hershberger > >> , Hannes Schmelzer > >> Datum: 16.03.2019 12:43 > >> Betreff: [U-Boot] [PATCH] phy: ti: Init node before reading > >> Gesendet von: "U-Boot" > >> > >> There is a need to fill node before clk_output_sel is setup. > >> > >> Signed-off-by: Michal Simek > >> Acked-by: Siva Durga Prasad Paladugu > >> --- > >> > >> drivers/net/phy/ti.c | 8 > >> 1 file changed, 4 insertions(+), 4 deletions(-) > > > > Reviewed-by: > > Joe: Do you want to take it via your net tree? Sure, I'll take it through my tree. I have to figure out which patch on my tree is breaking Tom's board, but once I get that figured out, I'll be pulling things in. I see it is already delegated to me in patchwork. Thanks, -Joe ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2] ARM: rmobile: rcar-common: Zap arch_preboot_os()
v2018.01 commit e23eb942ad103f ("ARM: rmobile: Stop using
rcar-common/common.c on Gen3") removed
board/renesas/rcar-common/common.c from the build chain with the
reasoning that calling arch_preboot_os() is no longer needed.
However, it left the arch_preboot_os() in place. Get rid of it.
This is done in preparation of resurrecting rcar-common/common.c.
NOTE: The three removed header includes (io.h, sys_proto.h, rcar-mstp.h)
are in direct relationship with the dropped arch_preboot_os() hook. The
other headers (common.h, rmobile.h) are going to be needed by pretty
much anything that is going to appear in the rcar common code. So, keep
the two in place.
Signed-off-by: Eugeniu Rosca
---
v2:
- [Marek] Drop Makefile changes. Reword the title/description.
v1:
- https://patchwork.ozlabs.org/patch/1082364/
---
board/renesas/rcar-common/common.c | 53 --
1 file changed, 53 deletions(-)
diff --git a/board/renesas/rcar-common/common.c
b/board/renesas/rcar-common/common.c
index 1129f4bf0c08..1ce6e2eac1bf 100644
--- a/board/renesas/rcar-common/common.c
+++ b/board/renesas/rcar-common/common.c
@@ -8,57 +8,4 @@
*/
#include
-#include
-#include
#include
-#include
-
-#define TSTR0 0x04
-#define TSTR0_STR0 0x01
-
-static struct mstp_ctl mstptbl[] = {
- { SMSTPCR0, MSTP0_BITS, CONFIG_SMSTP0_ENA,
- RMSTPCR0, MSTP0_BITS, CONFIG_RMSTP0_ENA },
- { SMSTPCR1, MSTP1_BITS, CONFIG_SMSTP1_ENA,
- RMSTPCR1, MSTP1_BITS, CONFIG_RMSTP1_ENA },
- { SMSTPCR2, MSTP2_BITS, CONFIG_SMSTP2_ENA,
- RMSTPCR2, MSTP2_BITS, CONFIG_RMSTP2_ENA },
- { SMSTPCR3, MSTP3_BITS, CONFIG_SMSTP3_ENA,
- RMSTPCR3, MSTP3_BITS, CONFIG_RMSTP3_ENA },
- { SMSTPCR4, MSTP4_BITS, CONFIG_SMSTP4_ENA,
- RMSTPCR4, MSTP4_BITS, CONFIG_RMSTP4_ENA },
- { SMSTPCR5, MSTP5_BITS, CONFIG_SMSTP5_ENA,
- RMSTPCR5, MSTP5_BITS, CONFIG_RMSTP5_ENA },
-#ifdef CONFIG_RCAR_GEN3
- { SMSTPCR6, MSTP6_BITS, CONFIG_SMSTP6_ENA,
- RMSTPCR6, MSTP6_BITS, CONFIG_RMSTP6_ENA },
-#endif
- { SMSTPCR7, MSTP7_BITS, CONFIG_SMSTP7_ENA,
- RMSTPCR7, MSTP7_BITS, CONFIG_RMSTP7_ENA },
- { SMSTPCR8, MSTP8_BITS, CONFIG_SMSTP8_ENA,
- RMSTPCR8, MSTP8_BITS, CONFIG_RMSTP8_ENA },
- { SMSTPCR9, MSTP9_BITS, CONFIG_SMSTP9_ENA,
- RMSTPCR9, MSTP9_BITS, CONFIG_RMSTP9_ENA },
- { SMSTPCR10, MSTP10_BITS, CONFIG_SMSTP10_ENA,
-RMSTPCR10, MSTP10_BITS, CONFIG_RMSTP10_ENA },
- { SMSTPCR11, MSTP11_BITS, CONFIG_SMSTP1_ENA,
-RMSTPCR11, MSTP11_BITS, CONFIG_RMSTP11_ENA },
-};
-
-void arch_preboot_os(void)
-{
- int i;
-
- /* stop TMU0 */
- mstp_clrbits_le32(TMU_BASE + TSTR0, TMU_BASE + TSTR0, TSTR0_STR0);
-
- /* Stop module clock */
- for (i = 0; i < ARRAY_SIZE(mstptbl); i++) {
- mstp_setclrbits_le32((uintptr_t)mstptbl[i].s_addr,
-mstptbl[i].s_dis,
-mstptbl[i].s_ena);
- mstp_setclrbits_le32((uintptr_t)mstptbl[i].r_addr,
-mstptbl[i].r_dis,
-mstptbl[i].r_ena);
- }
-}
--
2.21.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] Automatic starting of netconsole at boot
Hi, I built u-boot with CONFIG_NETCONSOLE=y. It works, but how can I set up u-boot so that after rebooting, it automatically (ie. w/o manual interaction) goes into netconsole mode? Ie. controlling the device remotely via netconsole by using the tools/netconsole script on the host as shown in doc/README.NetConsole, but there only a manual setup is given. For auto-starting netconsole I put these commands into boot.cmd and compiled it to boot.scr on the device: setenv ipaddr 192.168.1.7 setenv ncip 192.168.1.2 setenv nc 'setenv stdout nc;setenv stdin nc;setenv stderr nc' run nc At boot the netconnect connection seems to work as I get some output on the host, but after only a few seconds the device reboots itself: root@xy:/.../u-boot# tools/netconsole 192.168.1.7 Board out port: Board in port: NOTE: the interrupt signal (normally ^C) has been remapped to ^T ncb: not found #MYINFO: the following output comes from the remote board via netconsole: SCRIPT FAILED: continuing... scanning bus for devices... data abort pc : [<7ef94f8e>] lr : [<7ef911a1>] reloc pc : [<4a01af8e>]lr : [<4a0171a1>] sp : 7af515b0 ip : 001c fp : 00c0 r10: r9 : 7af59ed8 r8 : r7 : 7af51830 r6 : 7efd3f54 r5 : 7efdb9b8 r4 : 7efdb9b8 r3 : r2 : r1 : ea16 r0 : 7efdb9b8 Flags: nZcv IRQs off FIQs off Mode SVC_32 Code: e92dbd10 f8d045f0 b0858080 1000f8d8 (f8d14604) Resetting CPU ... It seems one needs some more commands when doing it inside boot.scr, or a different method. Or is the use of the envvar "nc" above maybe buggy: recursive definitions maybe? [I just followed the above u-boot doc] Is such an auto-start of netconsole possible at boot, and if yes how? Thx -- U.Mutlu ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] Rpi: Fix compilation error if CONFIG_USB is disabled
On 01/04/2019 16:36, Tom Rini wrote: > On Mon, Apr 01, 2019 at 10:19:18AM +, Ajay Kaher wrote: > >> Few weeks ago sent patch (as in below mail) to include in U-Boot, And >> still waiting for response and even not present in U-Boot mailing list. > > Can you please re-send the patch and ensure to Cc the maintainer? Thanks! > >> >> As per checkpatch.pl, there is following CHECK. However it doesn't have >> side-effects and similar to include/configs/rockchip-common.h: >> >> CHECK: Macro argument reuse 'func' - possible side-effects? #43: FILE: >> include/configs/rpi.h:150: + #define BOOT_TARGET_MMC(func) \ + >> func(MMC, >> mmc, 0) \ + func(MMC, mmc, 1) >> >> Please suggest if anything wrong I have done to submit the patch or >> anything wrong in the patch or is it because of above CHECK. >> >> - Ajay >> >> >> On 13/03/19, 4:42 PM, "akaher" wrote: >> >> This patch is to fix the following compilation error when disabling >> CONFIG_USB for Rpi3: >> >> include/config_distro_bootcmd.h:242:2: error: expected ‘}’ before >> ‘BOOT_TARGET_DEVICES_references_USB_without_CONFIG_CMD_USB’ >> BOOT_TARGET_DEVICES_references_USB_without_CONFIG_CMD_USB >> >> After merging rpi.h changes as per this patch, still getting compilation >> error if CONFIG_CMD_USB is enabled, so CONFIG_CMD_USB should depends upon >> CONFIG_USB. That indicates to me that this is an independent patch. You want to be able to enable CMD_USB only when USB is enabled. But that is independent from RPi. Regards, Matthias >> Signed-off-by: Ajay Kaher --- cmd/Kconfig | >> 1 + include/configs/rpi.h | 36 +++- 2 >> files changed, 32 insertions(+), 5 deletions(-) >> >> diff --git a/cmd/Kconfig b/cmd/Kconfig index 4bcc5c4557..96e665a1c9 >> 100644 --- a/cmd/Kconfig +++ b/cmd/Kconfig @@ -1059,6 +1059,7 @@ config >> CMD_UNIVERSE config CMD_USB bool "usb" select HAVE_BLOCK_DEVICE +depends >> on USB help USB support. >> >> diff --git a/include/configs/rpi.h b/include/configs/rpi.h index >> 9ce41767a9..f76c7d18ef 100644 --- a/include/configs/rpi.h +++ >> b/include/configs/rpi.h @@ -146,12 +146,38 @@ "fdt_addr_r=0x0260\0" >> \ "ramdisk_addr_r=0x0270\0" >> >> +#if CONFIG_IS_ENABLED(CMD_MMC) +#define BOOT_TARGET_MMC(func) \ + >> func(MMC, mmc, 0) \ +func(MMC, mmc, 1) +#else + #define >> BOOT_TARGET_MMC(func) +#endif + +#if CONFIG_IS_ENABLED(CMD_USB) +#define >> BOOT_TARGET_USB(func) func(USB, usb, 0) +#else + #define >> BOOT_TARGET_USB(func) +#endif + +#if CONFIG_IS_ENABLED(CMD_PXE) +#define >> BOOT_TARGET_PXE(func) func(PXE, pxe, na) +#else +#define >> BOOT_TARGET_PXE(func) +#endif + +#if CONFIG_IS_ENABLED(CMD_DHCP) + >> #define BOOT_TARGET_DHCP(func) func(DHCP, dhcp, na) +#else + #define >> BOOT_TARGET_DHCP(func) +#endif + #define BOOT_TARGET_DEVICES(func) \ - >> func(MMC, mmc, 0) \ -func(MMC, mmc, 1) \ - func(USB, usb, 0) \ - >> func(PXE, pxe, na) \ - func(DHCP, dhcp, na) + BOOT_TARGET_MMC(func) \ >> + >> BOOT_TARGET_USB(func) \ +BOOT_TARGET_PXE(func) \ + >> BOOT_TARGET_DHCP(func) + #include >> >> #define CONFIG_EXTRA_ENV_SETTINGS \ -- 2.14.2 >> >> >> > > > ___ U-Boot mailing list > U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: dts: i.MX6ULL: U-Boot specific dts for u-boot, dm-spl
Hi Marcel,
On 4/8/19 3:53 PM, Marcel Ziswiler wrote:
Hi Parthiban
On Sun, 2019-04-07 at 20:32 +0200, Parthiban Nallathambi wrote:
u-boot,dm-spl property is specific to U-Boot, so created one
for i.MX6ULL platforms.
What exactly makes you so sure others do want your exact configuration
thereof as well? Shouldn't you make this board specific instead like
e.g. done elsewhere [1]?
Sure, thanks for pointing it. I will move them to my board specific
files.
Thanks,
Parthiban N
[1]
https://git.denx.de/?p=u-boot.git;a=blob;f=arch/arm/dts/am335x-chiliboard-u-boot.dtsi;h=4f9d3080394be001f79731b736c5eac934c07ebf;hb=HEAD
Cheers
Marcel
Signed-off-by: Parthiban Nallathambi
---
arch/arm/dts/imx6ull-u-boot.dtsi | 34
board/phytec/pcl063/MAINTAINERS | 1 +
2 files changed, 35 insertions(+)
create mode 100644 arch/arm/dts/imx6ull-u-boot.dtsi
diff --git a/arch/arm/dts/imx6ull-u-boot.dtsi b/arch/arm/dts/imx6ull-
u-boot.dtsi
new file mode 100644
index 00..74ca95fa2c
--- /dev/null
+++ b/arch/arm/dts/imx6ull-u-boot.dtsi
@@ -0,0 +1,34 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2019 Parthiban Nallathambi
+ */
+
+/ {
+ soc {
+ u-boot,dm-spl;
+ };
+};
+
+ {
+ u-boot,dm-spl;
+};
+
+ {
+ u-boot,dm-spl;
+};
+
+ {
+ u-boot,dm-spl;
+};
+
+ {
+ u-boot,dm-spl;
+};
+
+ {
+ u-boot,dm-spl;
+};
+
+ {
+ u-boot,dm-spl;
+};
diff --git a/board/phytec/pcl063/MAINTAINERS
b/board/phytec/pcl063/MAINTAINERS
index 70e03cfe71..7d9978c339 100644
--- a/board/phytec/pcl063/MAINTAINERS
+++ b/board/phytec/pcl063/MAINTAINERS
@@ -3,6 +3,7 @@ M: Martyn Welch
M:Parthiban Nallathambi
S:Maintained
F:arch/arm/dts/imx6ul-phycore-segin.dts
+F: arch/arm/dts/imx6ull-u-boot.dtsi
F:arch/arm/dts/imx6ull-phycore-segin.dts
F:arch/arm/dts/pcl063-common.dtsi
F:board/phytec/pcl063/
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] imx: Extend PCL063 support for phyCORE-i.MX6ULL SOM
Hello Martyn,
On 4/9/19 12:46 PM, Martyn Welch wrote:
On Tue, 2019-04-09 at 11:30 +0200, Parthiban Nallathambi wrote:
Hello Martyn,
On 4/9/19 10:49 AM, Martyn Welch wrote:
On Mon, 2019-04-08 at 20:04 +0200, Parthiban wrote:
Hello Martyn,
On 4/8/19 7:45 PM, Martyn Welch wrote:
On Sun, 2019-04-07 at 19:56 +0200, Parthiban Nallathambi wrote:
diff --git a/board/phytec/pcl063/spl.c
b/board/phytec/pcl063/spl.c
index b93cd493f2..73a774645d 100644
--- a/board/phytec/pcl063/spl.c
+++ b/board/phytec/pcl063/spl.c
@@ -13,6 +13,7 @@
#include
#include
#include
+#include
#include
/* Configuration for Micron MT41K256M16TW-107 IT:P, 32M x
16 x 8
->
256MiB */
@@ -117,11 +118,32 @@ static iomux_v3_cfg_t const
usdhc1_pads[] =
{
MX6_PAD_UART1_RTS_B__USDHC1_CD_B |
MUX_PAD_CTRL(USDHC_PAD_CTRL),
};
+#ifndef CONFIG_NAND_MXS
+static iomux_v3_cfg_t const usdhc2_pads[] = {
+ MX6_PAD_NAND_RE_B__USDHC2_CLK|
MUX_PAD_CTRL(USDHC_PAD_CTRL),
+ MX6_PAD_NAND_WE_B__USDHC2_CMD|
MUX_PAD_CTRL(USDHC_PAD_CTRL),
+ MX6_PAD_NAND_DATA00__USDHC2_DATA0 |
MUX_PAD_CTRL(USDHC_PAD_CTRL),
+ MX6_PAD_NAND_DATA01__USDHC2_DATA1 |
MUX_PAD_CTRL(USDHC_PAD_CTRL),
+ MX6_PAD_NAND_DATA02__USDHC2_DATA2 |
MUX_PAD_CTRL(USDHC_PAD_CTRL),
+ MX6_PAD_NAND_DATA03__USDHC2_DATA3 |
MUX_PAD_CTRL(USDHC_PAD_CTRL),
+ MX6_PAD_NAND_DATA04__USDHC2_DATA4 |
MUX_PAD_CTRL(USDHC_PAD_CTRL),
+ MX6_PAD_NAND_DATA05__USDHC2_DATA5 |
MUX_PAD_CTRL(USDHC_PAD_CTRL),
+ MX6_PAD_NAND_DATA06__USDHC2_DATA6 |
MUX_PAD_CTRL(USDHC_PAD_CTRL),
+ MX6_PAD_NAND_DATA07__USDHC2_DATA7 |
MUX_PAD_CTRL(USDHC_PAD_CTRL),
+};
+#endif
+
Umm, these pins are already used a few lines up for the NAND,
via
gpmi:
I understand. But pcl063 can't co-exit with NAND and eMMC
together. I
comes
either with eMMC or NAND.
Opps, sorry, just realised that I added this comment in the wrong
place. This is in relation to the following being added to
pcl063-common.dtsi:
+
+ pinctrl_usdhc2: usdhc2grp {
+ fsl,pins = <
+ MX6UL_PAD_NAND_WE_B__USDHC2_CMD 0x1
70f9
+ MX6UL_PAD_NAND_RE_B__USDHC2_CLK 0x1
00f9
+ MX6UL_PAD_NAND_DATA00__USDHC2_DATA0 0x1
70f9
+ MX6UL_PAD_NAND_DATA01__USDHC2_DATA1 0x1
70f9
+ MX6UL_PAD_NAND_DATA02__USDHC2_DATA2 0x1
70f9
+ MX6UL_PAD_NAND_DATA03__USDHC2_DATA3 0x1
70f9
+ MX6UL_PAD_NAND_DATA04__USDHC2_DATA4 0x1
70f9
+ MX6UL_PAD_NAND_DATA05__USDHC2_DATA5 0x1
70f9
+ MX6UL_PAD_NAND_DATA06__USDHC2_DATA6 0x1
70f9
+ MX6UL_PAD_NAND_DATA07__USDHC2_DATA7 0x1
70f9
+ >;
+ };
If there exists pcl063 modules that have eMMC and others that have
NAND
using the same pins, then this configuration is not common and
therefore shouldn't be in pcl063-common.dtsi. Is it dependent on
the
flavour of i.MX used? If so I'd suggest the gpmi config needs to be
pulled out into imx6ul-phycore-segin.dts and the usdhc2 config
needs to
be in imx6ull-phycore-segin.dts.
From phytec I understand that pcl063 SoM is a common platform for
imx6UL
and imx6ULL. This can either be shipped with eMMC or NAND, but not
both.
Looking a bit deeper, this seems a little odd as the product
description suggests that NAND is provided onboard and 2 SD/SDIO/MMC
connections are provided to the edge connector of the pcl063 for
expansion.
The schematic suggests the only way they could achieve eMMC onboard
would be with an eMMC that is pin compatible with the NAND they use.
Additionally, looking at the DTBs for this board in Phytec's own kernel
tree, the only use of usdhc2 that I can see is for their WLAN expansion
board[1] and I would have expected their tree to have supported such an
option if it was available (they seem to have gone to some length to
support a lot of configurations there).
Are you sure that the eMMC is provided on the pcl063 and not off board?
Yes, I have this SoM with me and the changes are tested in it already.
Pinmuxing details are based on phytec's barebox which is yet to be in
mainline [1].
Phytec already published the booting from eMMC option and configurations
which are needed in the hardware level here [2].
(CCing Wadim who might be able to shed some light on this)
So there exist a possibility that phytec can provide imx6UL with eMMC
as
well. IMO, both pinmux detailing for NAND and eMMC should still
reside
in common.dtsi.
Assuming Phytec do in fact sell a pcl0063 with eMMC on board, the DTB
describes the hardware. You've said Phytec provide the board
either with eMMC *or* NAND. The device tree, as used on a specific
board, should show either the existence of NAND or eMMC.
I suspect having both options in the common file is going to lead to
issues with the pinmuxing for one or the other option. The pins can't
be muxed
Re: [U-Boot] [PATCH] Revert "fdt: Fix FIT header verification in mkimage and conduct same checks as bootm"
On Mon, Apr 8, 2019 at 9:54 PM Vagrant Cascadian wrote:
>
> This reverts commit d32aa3cae44e618048ff7f378577d44f9b6d6dcc.
>
> This breaks the "list_image" test in tests/image/test-imagetools.sh,
> where mkimage and dumpimage are expected to have the same output:
>
> Listing image contents...
> # debian/build/tools/tools/mkimage -l linux.itb
> debian/build/tools/tools/mkimage: verify_header failed for Default Image
> support with exit code -9
>
> Obviously, blindly reverting this patch may not the best way forward,
I'll take a look at this today and see if there's a simple way forward
without reverting
> but the same verify_header failed message occurs also with some
> real-world .itb files, such as that used on the pinebook. So it's not
Would you be able to point me to any .its files that fail this check
in the real world.
Also are you seeing failures while creating the image from its as well
with real world images (mkimage -l its itb) or only when listing the
header with -l?
> just the tests that need to be updated.
>
>
> live well,
> vagrant
>
> Signed-off-by: Vagrant Cascadian
> ---
>
> tools/fit_common.c | 5 +
> tools/fit_common.h | 8
> tools/imagetool.c | 34 +-
> tools/imagetool.h | 19 ---
> tools/mkimage.c| 2 +-
> 5 files changed, 3 insertions(+), 65 deletions(-)
>
> diff --git a/tools/fit_common.c b/tools/fit_common.c
> index 9506390214..d96085eaad 100644
> --- a/tools/fit_common.c
> +++ b/tools/fit_common.c
> @@ -26,10 +26,7 @@
> int fit_verify_header(unsigned char *ptr, int image_size,
> struct image_tool_params *params)
> {
> - if (fdt_check_header(ptr) != EXIT_SUCCESS || !fit_check_format(ptr))
> - return EXIT_FAILURE;
> -
> - return EXIT_SUCCESS;
> + return fdt_check_header(ptr);
> }
>
> int fit_check_image_types(uint8_t type)
> diff --git a/tools/fit_common.h b/tools/fit_common.h
> index 9e09624f64..71e792e3c4 100644
> --- a/tools/fit_common.h
> +++ b/tools/fit_common.h
> @@ -10,14 +10,6 @@
> #include "mkimage.h"
> #include
>
> -/**
> - * Verify the format of FIT header pointed to by ptr
> - *
> - * @ptr: image header to be verified
> - * @image_size: size of while image
> - * @params: mkimage parameters
> - * @return 0 if OK, -1 on error
> - */
> int fit_verify_header(unsigned char *ptr, int image_size,
> struct image_tool_params *params);
>
> diff --git a/tools/imagetool.c b/tools/imagetool.c
> index ba1f64aa37..b3e628f612 100644
> --- a/tools/imagetool.c
> +++ b/tools/imagetool.c
> @@ -46,7 +46,7 @@ int imagetool_verify_print_header(
>
> if (retval == 0) {
> /*
> -* Print the image information if verify is
> +* Print the image information if verify is
> * successful
> */
> if ((*curr)->print_header) {
> @@ -65,38 +65,6 @@ int imagetool_verify_print_header(
> return retval;
> }
>
> -int imagetool_verify_print_header_by_type(
> - void *ptr,
> - struct stat *sbuf,
> - struct image_type_params *tparams,
> - struct image_tool_params *params)
> -{
> - int retval;
> -
> - retval = tparams->verify_header((unsigned char *)ptr, sbuf->st_size,
> - params);
> -
> - if (retval == 0) {
> - /*
> -* Print the image information if verify is successful
> -*/
> - if (tparams->print_header) {
> - if (!params->quiet)
> - tparams->print_header(ptr);
> - } else {
> - fprintf(stderr,
> - "%s: print_header undefined for %s\n",
> - params->cmdname, tparams->name);
> - }
> - } else {
> - fprintf(stderr,
> - "%s: verify_header failed for %s with exit code %d\n",
> - params->cmdname, tparams->name, retval);
> - }
> -
> - return retval;
> -}
> -
> int imagetool_save_subimage(
> const char *file_name,
> ulong file_data,
> diff --git a/tools/imagetool.h b/tools/imagetool.h
> index 2689a4004a..71471420f9 100644
> --- a/tools/imagetool.h
> +++ b/tools/imagetool.h
> @@ -179,25 +179,6 @@ int imagetool_verify_print_header(
> struct image_type_params *tparams,
> struct image_tool_params *params);
>
> -/*
> - * imagetool_verify_print_header_by_type() - verifies the image header
> - *
> - * Verify the image_header for the image type given by tparams.
> - * If verification is successful, this prints the respective header.
> - * @ptr: pointer the the image header
> - * @sbuf: stat information about the file pointed to by ptr
> - * @tparams:
[U-Boot] [PATCH] ARM: dts: rmobile: Enable USB on E2 Alt
The E2 Alt board has two USB ports, add missing DT nodes to make the
USB available.
Signed-off-by: Marek Vasut
Cc: Nobuhiro Iwamatsu
---
arch/arm/dts/r8a7794-alt-u-boot.dts | 28
1 file changed, 28 insertions(+)
diff --git a/arch/arm/dts/r8a7794-alt-u-boot.dts
b/arch/arm/dts/r8a7794-alt-u-boot.dts
index 14cd39297e..29b0e32d14 100644
--- a/arch/arm/dts/r8a7794-alt-u-boot.dts
+++ b/arch/arm/dts/r8a7794-alt-u-boot.dts
@@ -13,6 +13,30 @@
clock-frequency = <10>;
};
+ {
+ status = "okay";
+ pinctrl-0 = <_pins>;
+ pinctrl-names = "default";
+};
+
+ {
+ status = "okay";
+ pinctrl-0 = <_pins>;
+ pinctrl-names = "default";
+};
+
+ {
+ usb0_pins: usb0 {
+ groups = "usb0";
+ function = "usb0";
+ };
+
+ usb1_pins: usb1 {
+ groups = "usb1";
+ function = "usb1";
+ };
+};
+
{
u-boot,dm-pre-reloc;
};
@@ -23,3 +47,7 @@
spi-rx-bus-width = <1>;
};
};
+
+ {
+ status = "okay";
+};
--
2.20.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 6/7] ARM: dts: rmobile: Synchronize Gen2 DTs with Linux 5.0
Synchronize R-Car Gen2 device trees with Linux 5.0,
commit 1c163f4c7b3f621efff9b28a47abb36f7378d783 .
Signed-off-by: Marek Vasut
Cc: Nobuhiro Iwamatsu
---
arch/arm/dts/r8a7790-lager.dts | 2 --
arch/arm/dts/r8a7790-stout.dts | 19 ---
arch/arm/dts/r8a7790.dtsi| 6 +++---
arch/arm/dts/r8a7791-koelsch.dts | 2 --
arch/arm/dts/r8a7791-porter.dts | 2 --
arch/arm/dts/r8a7791.dtsi| 6 +++---
arch/arm/dts/r8a7792.dtsi| 3 +--
arch/arm/dts/r8a7793-gose.dts| 16
arch/arm/dts/r8a7793.dtsi| 2 +-
arch/arm/dts/r8a7794-silk.dts| 25 +
arch/arm/dts/r8a7794.dtsi| 3 +--
11 files changed, 66 insertions(+), 20 deletions(-)
diff --git a/arch/arm/dts/r8a7790-lager.dts b/arch/arm/dts/r8a7790-lager.dts
index 50312e752e..7b9508e83d 100644
--- a/arch/arm/dts/r8a7790-lager.dts
+++ b/arch/arm/dts/r8a7790-lager.dts
@@ -489,8 +489,6 @@
};
{
- status = "okay";
-
ports {
port@1 {
lvds_connector: endpoint {
diff --git a/arch/arm/dts/r8a7790-stout.dts b/arch/arm/dts/r8a7790-stout.dts
index a13a92c266..7a7d3b84d1 100644
--- a/arch/arm/dts/r8a7790-stout.dts
+++ b/arch/arm/dts/r8a7790-stout.dts
@@ -94,9 +94,8 @@
status = "okay";
clocks = < CPG_MOD 724>, < CPG_MOD 723>, < CPG_MOD 722>,
-< CPG_MOD 726>, < CPG_MOD 725>,
<_clk>;
- clock-names = "du.0", "du.1", "du.2", "lvds.0", "lvds.1", "dclkin.0";
+ clock-names = "du.0", "du.1", "du.2", "dclkin.0";
ports {
port@0 {
@@ -104,11 +103,21 @@
remote-endpoint = <_in>;
};
};
+ };
+};
+
+ {
+ ports {
port@1 {
lvds_connector0: endpoint {
};
};
- port@2 {
+ };
+};
+
+ {
+ ports {
+ port@1 {
lvds_connector1: endpoint {
};
};
@@ -318,6 +327,10 @@
interrupts = <2 IRQ_TYPE_LEVEL_LOW>;
interrupt-controller;
+ onkey {
+ compatible = "dlg,da9063-onkey";
+ };
+
rtc {
compatible = "dlg,da9063-rtc";
};
diff --git a/arch/arm/dts/r8a7790.dtsi b/arch/arm/dts/r8a7790.dtsi
index 0925bdca43..5a2747758f 100644
--- a/arch/arm/dts/r8a7790.dtsi
+++ b/arch/arm/dts/r8a7790.dtsi
@@ -1,6 +1,6 @@
// SPDX-License-Identifier: GPL-2.0
/*
- * Device Tree Source for the r8a7790 SoC
+ * Device Tree Source for the R-Car H2 (R8A77900) SoC
*
* Copyright (C) 2015 Renesas Electronics Corporation
* Copyright (C) 2013-2014 Renesas Solutions Corp.
@@ -1559,7 +1559,7 @@
sata0: sata@ee30 {
compatible = "renesas,sata-r8a7790",
"renesas,rcar-gen2-sata";
- reg = <0 0xee30 0 0x2000>;
+ reg = <0 0xee30 0 0x20>;
interrupts = ;
clocks = < CPG_MOD 815>;
power-domains = < R8A7790_PD_ALWAYS_ON>;
@@ -1570,7 +1570,7 @@
sata1: sata@ee50 {
compatible = "renesas,sata-r8a7790",
"renesas,rcar-gen2-sata";
- reg = <0 0xee50 0 0x2000>;
+ reg = <0 0xee50 0 0x20>;
interrupts = ;
clocks = < CPG_MOD 814>;
power-domains = < R8A7790_PD_ALWAYS_ON>;
diff --git a/arch/arm/dts/r8a7791-koelsch.dts b/arch/arm/dts/r8a7791-koelsch.dts
index ce22db01fb..e6580aa0ce 100644
--- a/arch/arm/dts/r8a7791-koelsch.dts
+++ b/arch/arm/dts/r8a7791-koelsch.dts
@@ -479,8 +479,6 @@
};
{
- status = "okay";
-
ports {
port@1 {
lvds_connector: endpoint {
diff --git a/arch/arm/dts/r8a7791-porter.dts b/arch/arm/dts/r8a7791-porter.dts
index f02036e5de..fefdf8238b 100644
--- a/arch/arm/dts/r8a7791-porter.dts
+++ b/arch/arm/dts/r8a7791-porter.dts
@@ -482,8 +482,6 @@
};
{
- status = "okay";
-
ports {
port@1 {
lvds_connector: endpoint {
diff --git a/arch/arm/dts/r8a7791.dtsi b/arch/arm/dts/r8a7791.dtsi
index 991ac6feed..6f87550245 100644
--- a/arch/arm/dts/r8a7791.dtsi
+++ b/arch/arm/dts/r8a7791.dtsi
@@ -1,6 +1,6 @@
// SPDX-License-Identifier: GPL-2.0
/*
- * Device Tree Source for the r8a7791 SoC
+ * Device Tree Source for the R-Car M2-W (R8A77910) SoC
*
* Copyright (C) 2013-2015 Renesas Electronics Corporation
* Copyright (C) 2013-2014 Renesas Solutions Corp.
@@ -1543,7 +1543,7 @@
sata0: sata@ee30 {
compatible = "renesas,sata-r8a7791",
