Re: [U-Boot] [RFC PATCH v2 09/11] sf_mtd: Simply mtd operations
Hi Boris,
On 04/12/18 6:19 PM, Boris Brezillon wrote:
> On Tue, 4 Dec 2018 17:56:57 +0530
> Vignesh R wrote:
>
>> Now that there is new SPI NOR framework, simplify mtd device
>> registration and read/write/erase operations.
>>
>> Signed-off-by: Vignesh R
>> ---
>> drivers/mtd/spi/sf_internal.h | 2 +-
>> drivers/mtd/spi/sf_mtd.c | 39 ---
>> drivers/mtd/spi/sf_probe.c| 2 +-
>> 3 files changed, 15 insertions(+), 28 deletions(-)
>>
>> diff --git a/drivers/mtd/spi/sf_internal.h b/drivers/mtd/spi/sf_internal.h
>> index 7e7d400cdbdf..8b445bb0b506 100644
>> --- a/drivers/mtd/spi/sf_internal.h
>> +++ b/drivers/mtd/spi/sf_internal.h
>> @@ -99,6 +99,6 @@ int spi_flash_cmd_get_sw_write_prot(struct spi_flash
>> *flash);
>>
>> #ifdef CONFIG_SPI_FLASH_MTD
>> int spi_flash_mtd_register(struct spi_flash *flash);
>> -void spi_flash_mtd_unregister(void);
>> +void spi_flash_mtd_unregister(struct spi_flash *flash);
>> #endif
>> #endif /* _SF_INTERNAL_H_ */
>> diff --git a/drivers/mtd/spi/sf_mtd.c b/drivers/mtd/spi/sf_mtd.c
>> index 58d7e4439903..9c07ba3cadf7 100644
>> --- a/drivers/mtd/spi/sf_mtd.c
>> +++ b/drivers/mtd/spi/sf_mtd.c
>> @@ -9,17 +9,15 @@
>> #include
>> #include
>>
>> -static struct mtd_info sf_mtd_info;
>> static char sf_mtd_name[8];
>>
>> static int spi_flash_mtd_erase(struct mtd_info *mtd, struct erase_info
>> *instr)
>> {
>> -struct spi_flash *flash = mtd->priv;
>> int err;
>>
>> instr->state = MTD_ERASING;
>>
>> -err = spi_flash_erase(flash, instr->addr, instr->len);
>> +err = mtd->_erase(mtd, instr);
>
> Please don't dereference mtd hooks directly. I'm pretty sure the
> mtd_erase() overhead is negligible, and if it's not, you can
> implement dummy wrappers for the SPL case to reduce it to zero.
>
I did start with mtd_* APIs here. But, ended up with bunch of patches
just to get MTD configs in shape to satisfy compile time dependencies.
I will send a patch to use mtd_* APIs here once Miquel's MTD config
cleanups are in. Thanks for the review!
--
Regards
Vignesh
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] usb: dwc3: Add missing dependency on MISC uclass
Generic wrapper requires MISC uclass but dependency is not covered in Kconfig. misc0 [ + ] dwc3-generic-wrapper | |-- usb0@ff9d usb_dev_ge 0 [ + ] dwc3-generic-periphe | | `-- dwc3@fe20 misc1 [ ] dwc3-generic-wrapper | |-- usb1@ff9e usb 0 [ ] dwc3-generic-host | | `-- dwc3@fe30 watchdog0 [ + ] cdns_wdt | `-- watchdog@fd4d Signed-off-by: Michal Simek --- drivers/usb/dwc3/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/dwc3/Kconfig b/drivers/usb/dwc3/Kconfig index 943b7630eba4..9f0b8a2d0b4f 100644 --- a/drivers/usb/dwc3/Kconfig +++ b/drivers/usb/dwc3/Kconfig @@ -39,7 +39,7 @@ config USB_DWC3_OMAP config USB_DWC3_GENERIC bool "Xilinx ZynqMP and similar Platforms" - depends on DM_USB && USB_DWC3 + depends on DM_USB && USB_DWC3 && MISC help Some platforms can reuse this DWC3 generic implementation. -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2] common: command: Add support for $ auto-completion
Add the dollar_complete() function to auto-complete arguments starting
with a '$' and use it in the cmd_auto_complete() path such that all
args starting with a $ can be auto-completed based on the available env
vars.
Signed-off-by: Boris Brezillon
---
Changes in v2:
- Call dollar_complete() from cmd_auto_complete() to provide $
auto-completion to everyone (suggested by Wolfgang)
---
common/command.c | 33 ++--
env/common.c | 50 +---
include/common.h | 3 ++-
3 files changed, 76 insertions(+), 10 deletions(-)
diff --git a/common/command.c b/common/command.c
index 19f0534a76ea..0a93322814a6 100644
--- a/common/command.c
+++ b/common/command.c
@@ -143,22 +143,38 @@ int cmd_usage(const cmd_tbl_t *cmdtp)
#ifdef CONFIG_AUTO_COMPLETE
+static char env_complete_buf[512];
+
int var_complete(int argc, char * const argv[], char last_char, int maxv, char
*cmdv[])
{
- static char tmp_buf[512];
int space;
space = last_char == '\0' || isblank(last_char);
if (space && argc == 1)
- return env_complete("", maxv, cmdv, sizeof(tmp_buf), tmp_buf);
+ return env_complete("", maxv, cmdv, sizeof(env_complete_buf),
+ env_complete_buf, false);
if (!space && argc == 2)
- return env_complete(argv[1], maxv, cmdv, sizeof(tmp_buf),
tmp_buf);
+ return env_complete(argv[1], maxv, cmdv,
+ sizeof(env_complete_buf),
+ env_complete_buf, false);
return 0;
}
+static int dollar_complete(int argc, char * const argv[], char last_char,
+ int maxv, char *cmdv[])
+{
+ /* Make sure the last argument starts with a $. */
+ if (argc < 1 || argv[argc - 1][0] != '$' ||
+ last_char == '\0' || isblank(last_char))
+ return 0;
+
+ return env_complete(argv[argc - 1], maxv, cmdv,
sizeof(env_complete_buf),
+ env_complete_buf, true);
+}
+
/*/
int complete_subcmdv(cmd_tbl_t *cmdtp, int count, int argc,
@@ -357,9 +373,14 @@ int cmd_auto_complete(const char *const prompt, char *buf,
int *np, int *colp)
/* separate into argv */
argc = make_argv(tmp_buf, sizeof(argv)/sizeof(argv[0]), argv);
- /* do the completion and return the possible completions */
- i = complete_cmdv(argc, argv, last_char,
- sizeof(cmdv) / sizeof(cmdv[0]), cmdv);
+ /* first try a $ completion */
+ i = dollar_complete(argc, argv, last_char,
+ sizeof(cmdv) / sizeof(cmdv[0]), cmdv);
+ if (!i) {
+ /* do the completion and return the possible completions */
+ i = complete_cmdv(argc, argv, last_char,
+ sizeof(cmdv) / sizeof(cmdv[0]), cmdv);
+ }
/* no match; bell and out */
if (i == 0) {
diff --git a/env/common.c b/env/common.c
index 3317cef35522..aa9a097bced0 100644
--- a/env/common.c
+++ b/env/common.c
@@ -241,31 +241,75 @@ void env_relocate(void)
}
#if defined(CONFIG_AUTO_COMPLETE) && !defined(CONFIG_SPL_BUILD)
-int env_complete(char *var, int maxv, char *cmdv[], int bufsz, char *buf)
+int env_complete(char *var, int maxv, char *cmdv[], int bufsz, char *buf,
+bool dollar_comp)
{
ENTRY *match;
int found, idx;
+ if (dollar_comp) {
+ /*
+* When doing $ completion, the first character should
+* obviously be a '$'.
+*/
+ if (var[0] != '$')
+ return 0;
+
+ var++;
+
+ /*
+* The second one, if present, should be a '{', as some
+* configuration of the u-boot shell expand ${var} but not
+* $var.
+*/
+ if (var[0] == '{')
+ var++;
+ else if (var[0] != '\0')
+ return 0;
+ }
+
idx = 0;
found = 0;
cmdv[0] = NULL;
+
while ((idx = hmatch_r(var, idx, &match, &env_htab))) {
int vallen = strlen(match->key) + 1;
- if (found >= maxv - 2 || bufsz < vallen)
+ if (found >= maxv - 2 ||
+ bufsz < vallen + (dollar_comp ? 3 : 0))
break;
cmdv[found++] = buf;
+
+ /* Add the '${' prefix to each var when doing $ completion. */
+ if (dollar_comp) {
+ strcpy(buf, "${");
+ buf += 2;
+ bufsz -= 3;
+ }
+
memcpy(buf, match->key, vallen);
buf += vallen;
bufsz -= vallen;
+
+
Re: [U-Boot] [RFC PATCH v2 09/11] sf_mtd: Simply mtd operations
Hi Vignesh,
Vignesh R wrote on Wed, 5 Dec 2018 13:30:27 +0530:
> Hi Boris,
>
> On 04/12/18 6:19 PM, Boris Brezillon wrote:
> > On Tue, 4 Dec 2018 17:56:57 +0530
> > Vignesh R wrote:
> >
> >> Now that there is new SPI NOR framework, simplify mtd device
> >> registration and read/write/erase operations.
> >>
> >> Signed-off-by: Vignesh R
> >> ---
> >> drivers/mtd/spi/sf_internal.h | 2 +-
> >> drivers/mtd/spi/sf_mtd.c | 39 ---
> >> drivers/mtd/spi/sf_probe.c| 2 +-
> >> 3 files changed, 15 insertions(+), 28 deletions(-)
> >>
> >> diff --git a/drivers/mtd/spi/sf_internal.h b/drivers/mtd/spi/sf_internal.h
> >> index 7e7d400cdbdf..8b445bb0b506 100644
> >> --- a/drivers/mtd/spi/sf_internal.h
> >> +++ b/drivers/mtd/spi/sf_internal.h
> >> @@ -99,6 +99,6 @@ int spi_flash_cmd_get_sw_write_prot(struct spi_flash
> >> *flash);
> >>
> >> #ifdef CONFIG_SPI_FLASH_MTD
> >> int spi_flash_mtd_register(struct spi_flash *flash);
> >> -void spi_flash_mtd_unregister(void);
> >> +void spi_flash_mtd_unregister(struct spi_flash *flash);
> >> #endif
> >> #endif /* _SF_INTERNAL_H_ */
> >> diff --git a/drivers/mtd/spi/sf_mtd.c b/drivers/mtd/spi/sf_mtd.c
> >> index 58d7e4439903..9c07ba3cadf7 100644
> >> --- a/drivers/mtd/spi/sf_mtd.c
> >> +++ b/drivers/mtd/spi/sf_mtd.c
> >> @@ -9,17 +9,15 @@
> >> #include
> >> #include
> >>
> >> -static struct mtd_info sf_mtd_info;
> >> static char sf_mtd_name[8];
> >>
> >> static int spi_flash_mtd_erase(struct mtd_info *mtd, struct erase_info
> >> *instr)
> >> {
> >> - struct spi_flash *flash = mtd->priv;
> >>int err;
> >>
> >>instr->state = MTD_ERASING;
> >>
> >> - err = spi_flash_erase(flash, instr->addr, instr->len);
> >> + err = mtd->_erase(mtd, instr);
> >
> > Please don't dereference mtd hooks directly. I'm pretty sure the
> > mtd_erase() overhead is negligible, and if it's not, you can
> > implement dummy wrappers for the SPL case to reduce it to zero.
> >
>
> I did start with mtd_* APIs here. But, ended up with bunch of patches
> just to get MTD configs in shape to satisfy compile time dependencies.
> I will send a patch to use mtd_* APIs here once Miquel's MTD config
> cleanups are in. Thanks for the review!
>
As an FYI, it took me more than 30 Travis builds to get the
MTD Kconfigs/Makefiles (+ defconfigs) in shape :)
To find faulty configurations (for example, configurations using
CONFIG_SPI_FLASH_MTD but without enabling CONFIG_MTD) I wrote a small
script just to open these files automatically. As a reference if
someone wants to use/improve it, it is there [1].
[1] http://code.bulix.org/4ep8u5-518535
Thanks,
Miquèl
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 02/28] mtd: rename CONFIG_NAND -> CONFIG_MTD_RAW_NAND
On Wed, 5 Dec 2018 00:56:48 +0100 Miquel Raynal wrote: > Add more clarity by changing the Kconfig entry name. > > Signed-off-by: Miquel Raynal Reviewed-by: Boris Brezillon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 03/28] mtd: rename CONFIG_MTD -> CONFIG_DM_MTD
On Wed, 5 Dec 2018 00:56:49 +0100 Miquel Raynal wrote: > CONFIG_MTD must be reserved for the MTD core. Like any other > subsystem, prefix the symbol by DM when it comes to DM support. > > Signed-off-by: Miquel Raynal Reviewed-by: Boris Brezillon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 04/28] mtd: rename CONFIG_MTD_DEVICE -> CONFIG_MTD
On Wed, 5 Dec 2018 00:56:50 +0100 Miquel Raynal wrote: > Like in Linux, just use CONFIG_MTD to compile the MTD stack. > > Signed-off-by: Miquel Raynal Reviewed-by: Boris Brezillon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 05/28] mtd: ensure MTD is compiled when there is a NOR flash
On Wed, 5 Dec 2018 00:56:51 +0100 Miquel Raynal wrote: > CONFIG_MTD must be enabled when there is a NOR flash selected. > > Signed-off-by: Miquel Raynal Reviewed-by: Boris Brezillon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 01/28] Makefile: move MTD-related lines in coherent Makefiles
On Wed, 5 Dec 2018 00:56:47 +0100 Miquel Raynal wrote: > Move MTD-related lines out of the root Makefile. Put them in their > respective directories. > > Enclose some of these new lines to skip them when building the SPL > (the SPL directly points to what is needed). > > CONFIG_CMD_NAND is the symbol indicating support for raw NAND > devices. This logic is broken and will be fixed afterwards. To let the > 'mtd' command also use the raw NAND core, we add it in the > condition. This will be cleaned later. > > Signed-off-by: Miquel Raynal > --- > Makefile | 5 - > drivers/Makefile | 3 ++- > drivers/mtd/Makefile | 6 ++ > drivers/mtd/nand/Makefile | 3 +++ > 4 files changed, 11 insertions(+), 6 deletions(-) > > diff --git a/Makefile b/Makefile > index 552687db53..435d0257dd 100644 > --- a/Makefile > +++ b/Makefile > @@ -688,11 +688,6 @@ libs-y += drivers/ > libs-y += drivers/dma/ > libs-y += drivers/gpio/ > libs-y += drivers/i2c/ > -libs-y += drivers/mtd/ > -libs-$(CONFIG_CMD_NAND) += drivers/mtd/nand/raw/ > -libs-y += drivers/mtd/onenand/ > -libs-$(CONFIG_CMD_UBI) += drivers/mtd/ubi/ > -libs-y += drivers/mtd/spi/ > libs-y += drivers/net/ > libs-y += drivers/net/phy/ > libs-y += drivers/pci/ > diff --git a/drivers/Makefile b/drivers/Makefile > index 4453c62ad3..e7c93875bb 100644 > --- a/drivers/Makefile > +++ b/drivers/Makefile > @@ -6,7 +6,7 @@ obj-$(CONFIG_$(SPL_TPL_)DRIVERS_MISC_SUPPORT) += misc/ > sysreset/ firmware/ > obj-$(CONFIG_$(SPL_TPL_)I2C_SUPPORT) += i2c/ > obj-$(CONFIG_$(SPL_TPL_)LED) += led/ > obj-$(CONFIG_$(SPL_TPL_)MMC_SUPPORT) += mmc/ > -obj-$(CONFIG_$(SPL_TPL_)NAND_SUPPORT) += mtd/nand/raw/ > +obj-$(CONFIG_$(SPL_TPL_)NAND_SUPPORT) += mtd/nand/ I know re-ordering those patches is painful, but I'd prefer to have this patch moved at the end so that you directly include mtd instead of having the Makefile layering partially fixed (fixed for the non-SPL case, but not for the SPL/TPL case). > obj-$(CONFIG_$(SPL_TPL_)PHY) += phy/ > obj-$(CONFIG_$(SPL_TPL_)PINCTRL) += pinctrl/ > obj-$(CONFIG_$(SPL_TPL_)RAM) += ram/ > @@ -99,6 +99,7 @@ obj-$(CONFIG_QE) += qe/ > obj-$(CONFIG_U_QE) += qe/ > obj-y += mailbox/ > obj-y += memory/ > +obj-y += mtd/ > obj-y += pwm/ > obj-y += reset/ > obj-y += input/ > diff --git a/drivers/mtd/Makefile b/drivers/mtd/Makefile > index 22ceda93c0..aca3a0b811 100644 > --- a/drivers/mtd/Makefile > +++ b/drivers/mtd/Makefile > @@ -19,4 +19,10 @@ obj-$(CONFIG_ST_SMI) += st_smi.o > obj-$(CONFIG_STM32_FLASH) += stm32_flash.o > obj-$(CONFIG_RENESAS_RPC_HF) += renesas_rpc_hf.o > > +# SPL will manually build the files it needs > +ifeq ($(CONFIG_SPL_BUILD)$(CONFIG_TPL_BUILD),) > obj-y += nand/ > +obj-y += onenand/ > +obj-y += spi/ > +obj-$(CONFIG_CMD_UBI) += ubi/ > +endif > diff --git a/drivers/mtd/nand/Makefile b/drivers/mtd/nand/Makefile > index a358bc680e..99ca69ef95 100644 > --- a/drivers/mtd/nand/Makefile > +++ b/drivers/mtd/nand/Makefile > @@ -2,4 +2,7 @@ > > nandcore-objs := core.o bbt.o > obj-$(CONFIG_MTD_NAND_CORE) += nandcore.o > +ifneq (,$(findstring y,$(CONFIG_CMD_NAND)$(CONFIG_CMD_MTD))) > +obj-y += raw/ > +endif > obj-$(CONFIG_MTD_SPI_NAND) += spi/ ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] QE: ls1043a: modify CONFIG_SYS_QE_FW_ADDR to (512*4A00) in SD Card
Due to the new layout of Layerscape series, move the QE firmware to address (512*4A00) in SD Card. Signed-off-by: Zhao Qiang --- include/configs/ls1043a_common.h |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/include/configs/ls1043a_common.h b/include/configs/ls1043a_common.h index 4279d53..62ac915 100644 --- a/include/configs/ls1043a_common.h +++ b/include/configs/ls1043a_common.h @@ -194,7 +194,7 @@ */ #define CONFIG_SYS_QE_FMAN_FW_IN_MMC #define CONFIG_SYS_FMAN_FW_ADDR(512 * 0x4800) -#define CONFIG_SYS_QE_FW_ADDR (512 * 0x4a08) +#define CONFIG_SYS_QE_FW_ADDR (512 * 0x4A00) #elif defined(CONFIG_QSPI_BOOT) #define CONFIG_SYS_QE_FW_IN_SPIFLASH #define CONFIG_SYS_FMAN_FW_ADDR0x4090 -- 1.7.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 06/28] mtd: ensure MTD/the raw NAND core are compiled when there is a NAND flash
On Wed, 5 Dec 2018 00:56:52 +0100 Miquel Raynal wrote: > Both symbols must be enabled when there is a raw NAND driver > selected. Also enable them when CONFIG_CMD_NAND is selected to do not > break any build during later cleanup. "... to avoid breaking things when we'll further rework the MTD dependency description" or something like along those lines. > > Signed-off-by: Miquel Raynal Other than that Reviewed-by: Boris Brezillon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 07/28] mtd: ensure MTD is compiled when there is a SPI NOR flash using MTD
On Wed, 5 Dec 2018 00:56:53 +0100 Miquel Raynal wrote: > MTD must be enabled when there is a SPI NOR flash using the > SPI_FLASH_MTD config entry. > > Signed-off-by: Miquel Raynal With Vignesh's comment addressed Reviewed-by: Boris Brezillon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 09/28] mtd: ensure MTD is compiled when UBI is used
On Wed, 5 Dec 2018 00:56:55 +0100 Miquel Raynal wrote: > MTD must be enabled when UBI is used, this is mandatory and will later > be reflected thanks to a "depends on" in Kconfig. But first, > defconfigs needs to be fixed. ^ need > > Signed-off-by: Miquel Raynal Reviewed-by: Boris Brezillon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 08/28] mtd: ensure UBI is compiled when using fastmap
On Wed, 5 Dec 2018 00:56:54 +0100 Miquel Raynal wrote: > UBI must be enabled when using fastmap, reflect this is defconfigs. > > Signed-off-by: Miquel Raynal Reviewed-by: Boris Brezillon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 10/28] mtd: ensure UBI is compiled when CMD_UBI is selected
On Wed, 5 Dec 2018 00:56:56 +0100 Miquel Raynal wrote: > UBI must be enabled when CMD_UBI is used, this is mandatory and will > later be reflected thanks to a "depends on" in Kconfig. But first, > defconfigs needs to be fixed. > > Signed-off-by: Miquel Raynal Reviewed-by: Boris Brezillon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 11/28] mtd: ensure UBI is compiled when ENV_IS_IN_UBI is selected
On Wed, 5 Dec 2018 00:56:57 +0100 Miquel Raynal wrote: > UBI must be enabled when the environment is in UBI. > > Signed-off-by: Miquel Raynal Reviewed-by: Boris Brezillon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] pinctrl: meson: Fix GPIO direction registers access
On 05/12/2018 08:44, Jerome Brunet wrote: > On Mon, 2018-12-03 at 18:00 +, Carlo Caione wrote: >> The macros used to set the direction of the GPIO pins are misused, >> resulting in a wrong behavior when trying to read the GPIO input level >> from U-Boot. >> >> A better macro is also used when setting the output direction. >> >> Signed-off-by: Carlo Caione >> --- >> drivers/pinctrl/meson/pinctrl-meson.c | 4 ++-- >> 1 file changed, 2 insertions(+), 2 deletions(-) >> >> diff --git a/drivers/pinctrl/meson/pinctrl-meson.c >> b/drivers/pinctrl/meson/pinctrl-meson.c >> index 0bd6152803..b539749752 100644 >> --- a/drivers/pinctrl/meson/pinctrl-meson.c >> +++ b/drivers/pinctrl/meson/pinctrl-meson.c >> @@ -136,7 +136,7 @@ int meson_gpio_direction_input(struct udevice *dev, >> unsigned int offset) >> if (ret) >> return ret; >> >> -clrsetbits_le32(priv->reg_gpio + reg, BIT(bit), 1); >> +setbits_le32(priv->reg_gpio + reg, BIT(bit)); >> >> return 0; >> } >> @@ -152,7 +152,7 @@ int meson_gpio_direction_output(struct udevice *dev, >> if (ret) >> return ret; >> >> -clrsetbits_le32(priv->reg_gpio + reg, BIT(bit), 0); >> +clrbits_le32(priv->reg_gpio + reg, BIT(bit)); >> >> ret = meson_gpio_calc_reg_and_bit(dev, offset, REG_OUT, ®, &bit); >> if (ret) > > Reviewed-by: Jerome Brunet > Thanks, Applied ! Neil ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 12/28] mtd: ensure MTD_RAW_NAND is compiled when ENV_IS_IN_NAND is selected
On Wed, 5 Dec 2018 00:56:58 +0100 Miquel Raynal wrote: > Raw NAND support must be enabled when the environment is in NAND. > > Signed-off-by: Miquel Raynal Reviewed-by: Boris Brezillon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] common: fdt_support: print hexadecimal numbers in debug
We usually deal with hexadecimal addresses and sizes in
device-tree. Its much easier if debug logs print hexadecimal
values too.
Signed-off-by: Sekhar Nori
---
common/fdt_support.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/common/fdt_support.c b/common/fdt_support.c
index 3440e42a257b..194bb41d1414 100644
--- a/common/fdt_support.c
+++ b/common/fdt_support.c
@@ -1025,7 +1025,7 @@ static u64 of_bus_default_map(fdt32_t *addr, const
fdt32_t *range,
s = fdt_read_number(range + na + pna, ns);
da = fdt_read_number(addr, na);
- debug("OF: default map, cp=%llu, s=%llu, da=%llu\n", cp, s, da);
+ debug("OF: default map, cp=0x%llx, s=0x%llx, da=0x%llx\n", cp, s, da);
if (da < cp || da >= (cp + s))
return OF_BAD_ADDR;
@@ -1080,7 +1080,7 @@ static u64 of_bus_isa_map(fdt32_t *addr, const fdt32_t
*range,
s = fdt_read_number(range + na + pna, ns);
da = fdt_read_number(addr + 1, na - 1);
- debug("OF: ISA map, cp=%llu, s=%llu, da=%llu\n", cp, s, da);
+ debug("OF: ISA map, cp=0x%llx, s=0x%llx, da=0x%llx\n", cp, s, da);
if (da < cp || da >= (cp + s))
return OF_BAD_ADDR;
--
2.16.2
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 13/28] mtd: ensure MTD is compiled when ENV_IS_IN_FLASH is selected
On Wed, 5 Dec 2018 00:56:59 +0100 Miquel Raynal wrote: > MTD support must be enabled when the environment is in NOR. > > Signed-off-by: Miquel Raynal > --- > configs/armadillo-800eva_defconfig | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/configs/armadillo-800eva_defconfig > b/configs/armadillo-800eva_defconfig > index b1d923c069..45736a9b01 100644 > --- a/configs/armadillo-800eva_defconfig > +++ b/configs/armadillo-800eva_defconfig > @@ -32,6 +32,7 @@ CONFIG_CMD_PING=y > # CONFIG_CMD_MISC is not set > CONFIG_ENV_IS_IN_FLASH=y > # CONFIG_MMC is not set > +CONFIG_MTD=y Don't we need CONFIG_MTD_NOR_FLASH too? > CONFIG_SH_ETHER=y > CONFIG_SCIF_CONSOLE=y > CONFIG_OF_LIBFDT=y ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] Enable expression support for CONFIG_BOARD_SIZE_LIMIT
Dear Fabio, In message you wrote: > > Still not working for me. I do see a warning now: > > LD spl/u-boot-spl > /bin/sh: 1: arithmetic expression: expecting primary: ""((768 - 69) * 1024)"" > COPYu-boot.bin > MKIMAGE u-boot.img > OBJCOPY spl/u-boot-spl-nodtb.bin > COPYspl/u-boot-spl.bin > CFGSspl/u-boot-spl.cfgout > MKIMAGE SPL > CFGCHK u-boot.cfg I'm bulding with your modification: diff --git a/include/configs/pico-imx7d.h b/include/configs/pico-imx7d.h index 2bc42a04a0..67ca700a2f 100644 --- a/include/configs/pico-imx7d.h +++ b/include/configs/pico-imx7d.h @@ -134,7 +134,8 @@ /* FLASH and environment organization */ #define CONFIG_ENV_SIZESZ_8K -#define CONFIG_ENV_OFFSET (8 * SZ_64K) +#define CONFIG_ENV_OFFSET (768 * 1024) +#define CONFIG_BOARD_SIZE_LIMIT((768 - 69) * 1024) #define CONFIG_SYS_FSL_USDHC_NUM 2 #define CONFIG_SYS_MMC_ENV_DEV 0 ... LD spl/common/spl/built-in.o CC spl/lib/display_options.o LD spl/lib/built-in.o LD spl/u-boot-spl OBJCOPY spl/u-boot-spl-nodtb.bin COPYspl/u-boot-spl.bin MKIMAGE SPL OBJCOPY u-boot.srec OBJCOPY u-boot-nodtb.bin COPYu-boot.bin SYM u-boot.sym MKIMAGE u-boot.img CHK include/config.h CFG u-boot.cfg = WARNING == This board does not use CONFIG_DM_MMC. Please update the board to use CONFIG_DM_MMC before the v2019.04 release. Failure to update by the deadline may result in board removal. See doc/driver-model/MIGRATION.txt for more info. = WARNING == This board does not use CONFIG_DM_USB. Please update the board to use CONFIG_DM_USB before the v2019.07 release. Failure to update by the deadline may result in board removal. See doc/driver-model/MIGRATION.txt for more info. CFGCHK u-boot.cfg > It does allow the build to proceed, but it is not really detecting the > overlap anymore. > > For example: let's force the overlap by setting a very small > CONFIG_BOARD_SIZE_LIMIT of only 1K: > > #define CONFIG_ENV_OFFSET (768 * 1024) > #define CONFIG_BOARD_SIZE_LIMIT (1 * 1024) Please try it on the shell: -> echo $(( ((768 - 69) * 1024) )) 715776 -> echo $(( (1 * 1024) )) 1024 > /bin/sh: 1: arithmetic expression: expecting primary: ""(1 * 1024)"" I tested this with /bin/bash, /bin/sh and even /bin/dash - they all work fine here. > It still allowed a successful build, but it should have thrown an > error about the overlap. It does for me, if I set the limit low: OBJCOPY spl/u-boot-spl-nodtb.bin COPYspl/u-boot-spl.bin CFGSspl/u-boot-spl.cfgout MKIMAGE SPL OBJCOPY u-boot.srec OBJCOPY u-boot-nodtb.bin u-boot-nodtb.bin exceeds file size limit: limit: 1024 bytes actual: 480172 bytes excess: 479148 bytes make: *** [Makefile:1071: u-boot-nodtb.bin] Error 1 Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de The most exciting phrase to hear in science, the one that heralds new discoveries, is not "Eureka!" (I found it!) but "That's funny ..." -- Isaac Asimov ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 05/19] riscv: Add a SYSCON driver for Core Local Interruptor
Hi Lukas, On Wed, Nov 14, 2018 at 6:33 PM Auer, Lukas wrote: > > Hi Bin, > > On Wed, 2018-11-14 at 09:48 +0800, Bin Meng wrote: > > Hi Lukas, > > > > On Tue, Nov 13, 2018 at 10:45 PM Auer, Lukas > > wrote: > > > > > > Hi Bin, > > > > > > On Tue, 2018-11-13 at 00:21 -0800, Bin Meng wrote: > > > > This adds U-Boot syscon driver for RISC-V Core Local Interruptor > > > > (CLINT). The CLINT block holds memory-mapped control and status > > > > registers associated with software and timer interrupts. > > > > > > > > 3 APIs are provided for U-Boot to implement Supervisor Binary > > > > Interface (SBI) as defined by the RISC-V privileged architecture > > > > spec v1.10. > > > > > > > > Signed-off-by: Bin Meng > > > > --- > > > > > > Would it make sense to also abstract the functions provided by the > > > CLINT more? The reason why I am asking is because the CLINT is > > > (unfortunately) not specified as part of RISC-V. It is developing > > > into > > > a de facto standard since other platforms are following SiFive's > > > implementation, but there is nothing that would prevent them from > > > implementing something else. > > > > > > > I think your observation is correct about CLINT. Rick, does Andes's > > RISC-V processor also follow SiFive's CLINT model? > > > > > Two immediate examples I can think of would be mtime and the IPI > > > implementation. Many SoC vendors will likely already have a > > > suitable > > > timer IP block for mtime. I can imagine that they would choose to > > > re- > > > use their memory map instead of following that of the CLINT. > > > For the IPI implementation there is already an alternative, the > > > SBI. If > > > U-Boot should be able to run in supervisor mode, it would be > > > helpful to > > > support both the SBI and the CLINT interface. > > > > > > > I am not sure I followed you here. This driver provides 3 APIs: > > riscv_send_ipi() is for IPI, and the other 2 are for mtime/mtimecmp. > > > > It does, but I am not sure how easy it is to support different devices. > Supporting the SBI is not going to be an issue, more problematic would > be if we have two different devices and device tree nodes to implement > the functionality of the APIs. Now we have to bind this driver to two > devices and call the APIs from the correct instantiation, which would > not work. > > Thinking about this a little more, I think the only issue is that we > have both IPI- and mtime-related APIs in one driver. How about > something like this? Instead of binding this driver to riscv,clint0, we > add a new misc driver for the clint0. The only thing the driver does, > is to bind the syscon driver and the timer driver (see for example > tegra-car.c). Other architectures with separate device tree nodes for > the API functionality won't need the misc driver and can just bind the > devices to the syscon driver and a timer driver. > Sorry it took a long time before replying this. I did have a look at the tegra-car.c driver, and also tried various experiments. As Rick pointed out we have to handle mixed IP blocks like Andes chip for mtimer and IPIs. So it looks we need be able to flexibly handle the following cases (sigh): - SiFive's clint model which implements mtimer and IPI - mtimer following SiFive's clint model, but IPI does not (Andes chip) - IPI following SiFive's clint model, but mtimer follows (hypothetical model which does not exist today) - completely different mtimer and IPI models from SiFive's clint model I don't quite follow your idea of implementing clint as a misc driver, then binding syscon and timer devices in the misc driver. But I think we can only have the misc driver, and use misc uclass's ioctl() to implement the SBI required calls (set_timecmp, get_time, send_ipi), and we can have another ioctl code to report its capability to support mtimer and/or IPI functionality. This can support flexibility. However I believe this may affect performance if we go through many uclass function calls when doing SBI. The solution does not look clean to me :( Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 14/28] mtd: ensure CMD_NAND is compiled when its options are selected
On Wed, 5 Dec 2018 00:57:00 +0100 Miquel Raynal wrote: > In some files, options of CMD_NAND are selected but not the command > itself. Fix this inconsistency. > > Signed-off-by: Miquel Raynal Reviewed-by: Boris Brezillon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 15/28] mtd: ensure MTD is compiled when CMD_MTDPARTS is selected
On Wed, 5 Dec 2018 00:57:01 +0100 Miquel Raynal wrote: > MTD support must be enabled when using mtdparts. Indeed, functions > like get_mtd_info(), get_mtd_device() and put_mtd_device() are in > drivers/mtd/mtd_uboot.c and are built only with CONFIG_MTD. > > Signed-off-by: Miquel Raynal Reviewed-by: Boris Brezillon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 24/28] cmd: mtdparts: show Kconfig options only if the command is selected
On Wed, 5 Dec 2018 00:57:10 +0100 Miquel Raynal wrote: > Guard mtdparts options with an if/endif statement in Kconfig. Also > move the Kconfig entry of the option right after the entry of the > command. > > Signed-off-by: Miquel Raynal > --- > cmd/Kconfig | 21 +++-- > 1 file changed, 11 insertions(+), 10 deletions(-) > > diff --git a/cmd/Kconfig b/cmd/Kconfig > index bf9cc0c52d..cf58174013 100644 > --- a/cmd/Kconfig > +++ b/cmd/Kconfig > @@ -1741,6 +1741,17 @@ config CMD_MTDPARTS > declare the partitions in the mtdparts environment variable > but better use the MTD stack and the 'mtd' command instead. > > +if CMD_MTDPARTS > +config CMD_MTDPARTS_SPREAD > + bool "Padd partition size to take account of bad blocks" We usually use "depends on" in such cases depends on CMD_MTDPARTS > + help > + This enables the 'spread' sub-command of the mtdparts command. > + This command will modify the existing mtdparts variable by increasing > + the size of the partitions such that 1) each partition's net size is > + at least as large as the size specified in the mtdparts variable and > + 2) each partition starts on a good block. > +endif > + > config MTDIDS_DEFAULT > string "Default MTD IDs" > depends on MTD_PARTITIONS || CMD_MTDPARTS || CMD_NAND || CMD_FLASH > @@ -1755,16 +1766,6 @@ config MTDPARTS_DEFAULT > Defines a default MTD partitioning scheme in the Linux MTD command > line partitions format > > -config CMD_MTDPARTS_SPREAD > - bool "Padd partition size to take account of bad blocks" > - depends on CMD_MTDPARTS > - help > - This enables the 'spread' sub-command of the mtdparts command. > - This command will modify the existing mtdparts variable by increasing > - the size of the partitions such that 1) each partition's net size is > - at least as large as the size specified in the mtdparts variable and > - 2) each partition starts on a good block. > - > config CMD_REISER > bool "reiser - Access to reiserfs filesystems" > help ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 16/28] configs: move CONFIG_MTD in defconfigs when set in arch includes
On Wed, 5 Dec 2018 00:57:02 +0100 Miquel Raynal wrote: > Let's be consistent and always declare CONFIG_MTD from the defconfig > file when needed. > > Signed-off-by: Miquel Raynal Reviewed-by: Boris Brezillon One comment below. > --- > configs/socfpga_stratix10_defconfig | 1 + > configs/turris_mox_defconfig | 1 + > include/configs/mvebu_armada-37xx.h | 1 - > include/configs/socfpga_stratix10_socdk.h | 1 - > 4 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/configs/socfpga_stratix10_defconfig > b/configs/socfpga_stratix10_defconfig > index 5f3d733a8b..292dbd6973 100644 > --- a/configs/socfpga_stratix10_defconfig > +++ b/configs/socfpga_stratix10_defconfig > @@ -38,6 +38,7 @@ CONFIG_DM_I2C=y > CONFIG_SYS_I2C_DW=y > CONFIG_DM_MMC=y > CONFIG_MMC_DW=y > +CONFIG_MTD=y > CONFIG_SPI_FLASH=y > CONFIG_SPI_FLASH_BAR=y > CONFIG_SPI_FLASH_SPANSION=y > diff --git a/configs/turris_mox_defconfig b/configs/turris_mox_defconfig > index 749ed31acd..13e2af7e1b 100644 > --- a/configs/turris_mox_defconfig > +++ b/configs/turris_mox_defconfig > @@ -42,6 +42,7 @@ CONFIG_DM_MMC=y > CONFIG_MMC_SDHCI=y > CONFIG_MMC_SDHCI_SDMA=y > CONFIG_MMC_SDHCI_XENON=y > +CONFIG_MTD=y > CONFIG_SPI_FLASH=y > CONFIG_SPI_FLASH_MACRONIX=y > CONFIG_SPI_FLASH_SPANSION=y > diff --git a/include/configs/mvebu_armada-37xx.h > b/include/configs/mvebu_armada-37xx.h > index f93ab0f830..640267c9c2 100644 > --- a/include/configs/mvebu_armada-37xx.h > +++ b/include/configs/mvebu_armada-37xx.h > @@ -64,7 +64,6 @@ > #define CONFIG_SF_DEFAULT_SPEED 100 > #define CONFIG_SF_DEFAULT_MODE SPI_MODE_0 > #define CONFIG_ENV_SPI_MODE CONFIG_SF_DEFAULT_MODE > -#define CONFIG_MTD /* needed for mtdparts commands */ > #define CONFIG_MTD_PARTITIONS/* required for UBI partition > support */ > > /* Environment in SPI NOR flash */ > diff --git a/include/configs/socfpga_stratix10_socdk.h > b/include/configs/socfpga_stratix10_socdk.h > index 22e1dc84a1..967784e379 100644 > --- a/include/configs/socfpga_stratix10_socdk.h > +++ b/include/configs/socfpga_stratix10_socdk.h > @@ -76,7 +76,6 @@ > #endif /* CONFIG_ENV_IS_IN_SPI_FLASH */ > > #ifndef CONFIG_SPL_BUILD > -#define CONFIG_MTD > #define CONFIG_MTD_PARTITIONS Do you get rid of CONFIG_MTD_PARTITIONS at some point? > #define MTDIDS_DEFAULT "nor0=ff705000.spi.0" > #endif /* CONFIG_SPL_BUILD */ ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 17/28] configs: remove raw NAND core from k2g defconfigs
On Wed, 5 Dec 2018 00:57:03 +0100 Miquel Raynal wrote: > Due to previous Makefile organization, the raw NAND subdirectory was > not compiled in if CMD_NAND was not enabled. Because the Denali driver > does not compile with these boards (undefined environment offset), > remove the dependency within the defconfig over the controller driver > (was ignored anyway in the past). Maybe this should be moved before the Makefile re-organization if this the build of those defconfigs. > > Signed-off-by: Miquel Raynal > --- > configs/k2g_evm_defconfig| 1 - > configs/k2g_hs_evm_defconfig | 1 - > 2 files changed, 2 deletions(-) > > diff --git a/configs/k2g_evm_defconfig b/configs/k2g_evm_defconfig > index dee00ec8d4..b474781ccb 100644 > --- a/configs/k2g_evm_defconfig > +++ b/configs/k2g_evm_defconfig > @@ -41,7 +41,6 @@ CONFIG_MMC_OMAP_HS=y > CONFIG_MTD=y > CONFIG_MTD_UBI=y > CONFIG_MTD_RAW_NAND=y > -CONFIG_NAND_DAVINCI=y > CONFIG_DM_SPI_FLASH=y > CONFIG_SPI_FLASH=y > CONFIG_SPI_FLASH_BAR=y > diff --git a/configs/k2g_hs_evm_defconfig b/configs/k2g_hs_evm_defconfig > index b8c395d78d..a50a7abf30 100644 > --- a/configs/k2g_hs_evm_defconfig > +++ b/configs/k2g_hs_evm_defconfig > @@ -34,7 +34,6 @@ CONFIG_MMC_OMAP_HS=y > CONFIG_MTD=y > CONFIG_MTD_UBI=y > CONFIG_MTD_RAW_NAND=y > -CONFIG_NAND_DAVINCI=y > CONFIG_DM_SPI_FLASH=y > CONFIG_SPI_FLASH=y > CONFIG_SPI_FLASH_BAR=y ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 18/28] configs: remove MTD support from bcm11130 and M54418TWR defconfigs
On Wed, 5 Dec 2018 00:57:04 +0100 Miquel Raynal wrote: > While the right Kconfig entries were selected, because of the missing > CMD_NAND symbol the raw NAND core was never compiled. Remove it from > the defconfigs otherwise the build will fail. See my comment on patch 17. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 19/28] mtd: nand: add includes in NAND core to avoid warnings
On Wed, 5 Dec 2018 00:57:05 +0100 Miquel Raynal wrote: > Because of the include's game, when some files are compiled for a SPI > NAND device, no warning appears. But when it is for a raw NAND device, > GCC complains. Fix these warning by including . > > Signed-off-by: Miquel Raynal Reviewed-by: Boris Brezillon > --- > drivers/mtd/nand/bbt.c | 1 + > drivers/mtd/nand/core.c | 1 + > 2 files changed, 2 insertions(+) > > diff --git a/drivers/mtd/nand/bbt.c b/drivers/mtd/nand/bbt.c > index 7e0ad3190c..f3d05e6757 100644 > --- a/drivers/mtd/nand/bbt.c > +++ b/drivers/mtd/nand/bbt.c > @@ -9,6 +9,7 @@ > > #define pr_fmt(fmt) "nand-bbt: " fmt > > +#include > #include > #ifndef __UBOOT__ > #include > diff --git a/drivers/mtd/nand/core.c b/drivers/mtd/nand/core.c > index 0b793695cc..3abaef23c5 100644 > --- a/drivers/mtd/nand/core.c > +++ b/drivers/mtd/nand/core.c > @@ -9,6 +9,7 @@ > > #define pr_fmt(fmt) "nand: " fmt > > +#include > #ifndef __UBOOT__ > #include > #endif ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 20/28] dfu: add dependency on the NAND core
On Wed, 5 Dec 2018 00:57:06 +0100 Miquel Raynal wrote: > CONFIG_DFU_NAND needs the NAND core being compiled. > > Also fix the colibri_vf defconfig to reflect this dependency. > > Signed-off-by: Miquel Raynal Reviewed-by: Boris Brezillon BTW, it would be great to have an MTD backend instead of having one per type of flash ;-). > --- > configs/colibri_vf_defconfig | 1 + > drivers/dfu/Kconfig | 1 + > 2 files changed, 2 insertions(+) > > diff --git a/configs/colibri_vf_defconfig b/configs/colibri_vf_defconfig > index 305dfcccb5..73b7055de1 100644 > --- a/configs/colibri_vf_defconfig > +++ b/configs/colibri_vf_defconfig > @@ -50,6 +50,7 @@ CONFIG_FSL_ESDHC=y > CONFIG_NAND_VF610_NFC=y > CONFIG_SYS_NAND_VF610_NFC_60_ECC_BYTES=y > CONFIG_MTD=y > +CONFIG_MTD_RAW_NAND=y > CONFIG_MTD_UBI=y > CONFIG_MTD_UBI_FASTMAP=y > CONFIG_PHYLIB=y > diff --git a/drivers/dfu/Kconfig b/drivers/dfu/Kconfig > index 4692736c9d..5ee260913c 100644 > --- a/drivers/dfu/Kconfig > +++ b/drivers/dfu/Kconfig > @@ -31,6 +31,7 @@ config DFU_MMC > config DFU_NAND > bool "NAND back end for DFU" > depends on CMD_MTDPARTS > + depends on MTD_RAW_NAND > help > This option enables using DFU to read and write to NAND based > storage. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 22/28] mtd: nand: remove dependency on commands in Kconfig
On Wed, 5 Dec 2018 00:57:08 +0100 Miquel Raynal wrote: > Now that the defconfigs have been fixed, remove the dependencies on > commands in Kconfig. That's not what I'm seeing in this diff ;-). > The necessary symbols are enabled so this will > not break anything. > > Signed-off-by: Miquel Raynal > --- > drivers/mtd/nand/Makefile | 4 +--- > 1 file changed, 1 insertion(+), 3 deletions(-) > > diff --git a/drivers/mtd/nand/Makefile b/drivers/mtd/nand/Makefile > index 99ca69ef95..e5849dc02a 100644 > --- a/drivers/mtd/nand/Makefile > +++ b/drivers/mtd/nand/Makefile > @@ -2,7 +2,5 @@ > > nandcore-objs := core.o bbt.o > obj-$(CONFIG_MTD_NAND_CORE) += nandcore.o > -ifneq (,$(findstring y,$(CONFIG_CMD_NAND)$(CONFIG_CMD_MTD))) > -obj-y += raw/ > -endif > +obj-$(CONFIG_MTD_RAW_NAND) += raw/ > obj-$(CONFIG_MTD_SPI_NAND) += spi/ ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [RFC PATCH] spl/tpl: change banner into upper case
commit d6330064634a ("spl: Add a define for SPL_TPL_PROMPT")
changes the SPL/TPL banner from upper case into lower
case. As SPL and TPL are three-letter acronyms and they
are written in upper case, change it back to upper case.
Signed-off-by: Heiko Schocher
---
include/spl.h | 4 ++--
test/py/u_boot_console_base.py | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/include/spl.h b/include/spl.h
index ee92832f0a..ff4e6277d3 100644
--- a/include/spl.h
+++ b/include/spl.h
@@ -52,9 +52,9 @@ static inline bool u_boot_first_phase(void)
/* A string name for SPL or TPL */
#ifdef CONFIG_SPL_BUILD
# ifdef CONFIG_TPL_BUILD
-# define SPL_TPL_NAME "tpl"
+# define SPL_TPL_NAME "TPL"
# else
-# define SPL_TPL_NAME "spl"
+# define SPL_TPL_NAME "SPL"
# endif
# define SPL_TPL_PROMPTSPL_TPL_NAME ": "
#else
diff --git a/test/py/u_boot_console_base.py b/test/py/u_boot_console_base.py
index e044eb3ea1..326b2ac51f 100644
--- a/test/py/u_boot_console_base.py
+++ b/test/py/u_boot_console_base.py
@@ -16,7 +16,7 @@ import sys
import u_boot_spawn
# Regexes for text we expect U-Boot to send to the console.
-pattern_u_boot_spl_signon = re.compile('(U-Boot spl
\\d{4}\\.\\d{2}[^\r\n]*\\))')
+pattern_u_boot_spl_signon = re.compile('(U-Boot SPL
\\d{4}\\.\\d{2}[^\r\n]*\\))')
pattern_u_boot_main_signon = re.compile('(U-Boot \\d{4}\\.\\d{2}[^\r\n]*\\))')
pattern_stop_autoboot_prompt = re.compile('Hit any key to stop autoboot: ')
pattern_unknown_command = re.compile('Unknown command \'.*\' - try \'help\'')
--
2.17.2
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 21/28] mtd: nor: NOR flashes depend on MTD
On Wed, 5 Dec 2018 00:57:07 +0100 Miquel Raynal wrote: > A NOR flash needs the MTD core, ensure this dependency is met by > adding a "depends on" in Kconfig. This is fine since defconfigs have > been fixed. > > Signed-off-by: Miquel Raynal > --- > drivers/mtd/Kconfig | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/mtd/Kconfig b/drivers/mtd/Kconfig > index 345046c2a6..0832f5b411 100644 > --- a/drivers/mtd/Kconfig > +++ b/drivers/mtd/Kconfig > @@ -19,6 +19,7 @@ config DM_MTD > > config MTD_NOR_FLASH > bool "Enable parallel NOR flash support" > + depends on MTD > help > Enable support for parallel NOR flash. > Don't know if this applies here, but if you have almost all options in Kconfig that depend on MTD, you can add an if MTD endif section. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 25/28] cmd: nand/sf: isolate legacy code
On Wed, 5 Dec 2018 00:57:11 +0100 Miquel Raynal wrote: > The 'sf' command is not supposed to rely on the MTD stack, but both > 'sf' and 'nand' commands use helpers located in mtd_uboot.c. Despite > their location, these functions do not depend at all on the MTD > stack. > > This file (drivers/mtd/mtd_uboot.c) is only compiled if CONFIG_MTD is > selected, which is incoherent with the current situation. Solve this ^inconsistent > by mobing these three functions (which are only used by the above two ^ moving > commands) out of mtd_uboot.c and put them in a C file only compiled > with cmd/sf.c and cmd/nand.c. > > Signed-off-by: Miquel Raynal > --- > cmd/Makefile| 4 +- > cmd/legacy-mtd-utils.c | 99 + > cmd/legacy-mtd-utils.h | 14 ++ > cmd/nand.c | 2 + > cmd/sf.c| 2 + > drivers/mtd/mtd_uboot.c | 94 -- > include/linux/mtd/mtd.h | 6 --- > 7 files changed, 119 insertions(+), 102 deletions(-) > create mode 100644 cmd/legacy-mtd-utils.c > create mode 100644 cmd/legacy-mtd-utils.h > > diff --git a/cmd/Makefile b/cmd/Makefile > index 0534ddc679..54c54c062d 100644 > --- a/cmd/Makefile > +++ b/cmd/Makefile > @@ -94,7 +94,7 @@ obj-$(CONFIG_CMD_MMC_SPI) += mmc_spi.o > obj-$(CONFIG_MP) += mp.o > obj-$(CONFIG_CMD_MTD) += mtd.o > obj-$(CONFIG_CMD_MTDPARTS) += mtdparts.o > -obj-$(CONFIG_CMD_NAND) += nand.o > +obj-$(CONFIG_CMD_NAND) += nand.o legacy-mtd-utils.o > obj-$(CONFIG_CMD_NET) += net.o > obj-$(CONFIG_CMD_ONENAND) += onenand.o > obj-$(CONFIG_CMD_OSD) += osd.o > @@ -115,7 +115,7 @@ obj-$(CONFIG_CMD_ROCKUSB) += rockusb.o > obj-$(CONFIG_SANDBOX) += host.o > obj-$(CONFIG_CMD_SATA) += sata.o > obj-$(CONFIG_CMD_NVME) += nvme.o > -obj-$(CONFIG_CMD_SF) += sf.o > +obj-$(CONFIG_CMD_SF) += sf.o legacy-mtd-utils.o That won't work if you enable both CMD_SF and CMD_NAND. The linker will complain that some symbols are duplicated. Either you add a new hidden Kconfig option that is selected by CMD_NAND and CMD_SF, or you use the ifeq trick: ifeq (,$(findstring y,$(CONFIG_CMD_NAND)$(CONFIG_CMD_SF))) obj-y += legacy-mtd-utils.o endif ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] Issue with memcpy when booting a fitImage on SPEAr600
Hello everyone, I'm working on porting a mainline U-Boot on a custom board based on a SPEAr600. Right now, I'm facing an issue related with fitImage booting. Before starting on the fitImage issue, let me state that the zImage and the custom DTB concatenated in a uImage have the load address and entry point be respectively 0x0200. and 0x0200.0040. The fitImage load and entry are both 0x0200.. The uImage loaded at the address 0x0080. is booted fine by U-Boot, the fitImage at the same address, not. The datasheet of the SoC states that the external SDRAM is located between 0x. and 0x3fff.. The size of the fitImage is currently 0x0038.9484 bytes, the uImage 0x0038.9007. The fitImage booting abruptly stops right after "Loading Device Tree to 0778a000, end 0778e7d6 ... OK" with the following trace: "prefetch abort pc : [] lr : [<07fca8c7>] reloc pc : []lr : [<03f388c7>] sp : 0778fb78 ip : fffc4c98 fp : 03f00020 r10: deadbeef r9 : 0778ff00 r8 : 07f922a0 r7 : 00ff r6 : 47d7 r5 : 4700 r4 : 0778a1b8 r3 : 0008 r2 : 16c4 r1 : 0778a1b8 r0 : 0778a1b8 Flags: nZCv IRQs off FIQs off Mode SVC_32 Code: data abort pc : [<07f931c6>] lr : [<07fb2dd1>] reloc pc : [<03f011c6>]lr : [<03f20dd1>] sp : 0778fa80 ip : 0114 fp : 03f00020 r10: deadbeef r9 : 0778ff00 r8 : 07f922a0 r7 : 6000 r6 : 0698 r5 : f188af44 r4 : fffc r3 : fff0 r2 : 0778ff00 r1 : 0020 r0 : 0006 Flags: NzCv IRQs on FIQs on Mode SVC_32 Code: 23036be5 439d4818 f885f038 42642404 (595a00a3) Resetting CPU ... resetting ... System is going to reboot ..." I've narrowed down the issue to a memmove being called with destination pointer being the source pointer. If I print a debug message before and after this memcpy[1], the first debug message is printed but not the second one. If I add a condition for (dest == src) return dest in the very beginning of memmove, the fitImage boots just fine. This test seemed to have been removed by commit cb0eae8cf8aaca76910dee4c7eb536d0814d1bd2[12], and by reverting this commit, I was able to successfuly boot Linux with a fitImage. Here is the log without debug messages WITHOUT the dest == src check in memmove: U-Boot 2018.11-7-g0b16f8424a-dirty (Dec 05 2018 - 09:23:31 +0100)-SPEAr CPU: SPEAr600 DRAM: 128 MiB Flash: 512 KiB NAND: 128 MiB Loading Environment from Flash... OK Net: dwmac.e080 Hit SPACE in 3 seconds to stop autoboot. => dhcp; tftp fitImage; bootm Speed: 100, full duplex BOOTP broadcast 1 DHCP client bound to address 192.168.0.169 (3 ms) Speed: 100, full duplex Using dwmac.e080 device TFTP from server 192.168.0.13; our IP address is 192.168.0.169 Filename 'fitImage'. Load address: 0x80 Loading: # # # ## 5.5 MiB/s done Bytes transferred = 3708036 (389484 hex) ## Loading kernel from FIT Image at 0080 ... Using 'conf@default' configuration Trying 'kernel@0' kernel subimage Description: Linux Type: Kernel Image Compression: uncompressed Data Start: 0x008000b0 Data Size:3700720 Bytes = 3.5 MiB Architecture: ARM OS: Linux Load Address: 0x0200 Entry Point: 0x0200 Hash algo:sha1 Hash value: efe249f573647bad3ce87c9c4b244986a90234db ## Loading fdt from FIT Image at 0080 ... Using 'conf@default' configuration Trying 'fdt@0' fdt subimage Description: Device Tree Type: Flat Device Tree Compression: uncompressed Data Start: 0x00b87984 Data Size:6103 Bytes = 6 KiB Architecture: ARM Hash algo:sha1 Hash value: 53089fa031e727f094e6bf9ad4e93f4e95b7fba3 Booting using the fdt blob at 0xb87984 Loading Kernel Image ... OK Loading Device Tree to 0778a000, end 0778e7d6 ... OK prefetch abort pc : [] lr : [<07fca8c7>] reloc pc : []lr : [<03f388c7>] sp : 0778fb78 ip : fffc4c98 fp : 03f00020 r10: deadbeef r9 : 0778ff00 r8 : 07f922a0 r7 : 00ff r6 : 47d7 r5 : 4700 r4 : 0778a1b8 r3 : 0008 r2 : 16c4 r1 : 0778a1b8 r0 : 0778a1b8 Flags: nZCv IRQs off FIQs off Mode SVC_32 Code: data abort pc : [<07f931c6>] lr : [<07fb2dd1>] reloc pc : [<03f011c6>]lr : [<03f20dd1>] sp : 0778fa80 ip : 0114 fp : 03f00020 r10: deadbeef r9 : 0778ff00 r8 : 07f922a0 r7 : 6000 r6 : 0698 r5 : f188af44 r4 : fffc r3 : fff0 r2 : 0778ff00 r1 : 0020 r0 : 0006 Flags: NzCv IRQs on FIQs on Mode SVC_32 Code: 23036be5 439d4818 f885f038 42642404 (595a00a3) Resetting CPU ... resetting ... System is going to reboot ... With debug messages (_DE
Re: [U-Boot] [PATCH v3 23/28] mtd: ubi: remove dependency on command in Kconfig
On Wed, 5 Dec 2018 00:57:09 +0100 Miquel Raynal wrote: > Now that the defconfigs have been fixed, remove the dependencies on > commands in Kconfig. No changes in Kconfig in this patch. > The necessary symbols are enabled so this will > not break anything. > > Signed-off-by: Miquel Raynal > --- > drivers/mtd/Makefile | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/mtd/Makefile b/drivers/mtd/Makefile > index 486634b562..68b1029734 100644 > --- a/drivers/mtd/Makefile > +++ b/drivers/mtd/Makefile > @@ -24,5 +24,5 @@ ifeq ($(CONFIG_SPL_BUILD)$(CONFIG_TPL_BUILD),) > obj-y += nand/ > obj-y += onenand/ > obj-y += spi/ > -obj-$(CONFIG_CMD_UBI) += ubi/ > +obj-$(CONFIG_MTD_UBI) += ubi/ > endif ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 26/28] cmd: make MTD commands depend on MTD
On Wed, 5 Dec 2018 00:57:12 +0100
Miquel Raynal wrote:
> Defconfigs have been fixed, now we can add proper dependencies in
> Kconfig. SPI FLASH is still not dependent on MTD (deeper rework needed).
>
> Signed-off-by: Miquel Raynal
> ---
> cmd/Kconfig | 10 +++---
> 1 file changed, 7 insertions(+), 3 deletions(-)
>
> diff --git a/cmd/Kconfig b/cmd/Kconfig
> index cf58174013..7c166a07e6 100644
> --- a/cmd/Kconfig
> +++ b/cmd/Kconfig
> @@ -679,6 +679,7 @@ config CMD_FDC
> config CMD_FLASH
> bool "flinfo, erase, protect"
> default y
> + depends on MTD
> help
> NOR flash support.
> flinfo - print FLASH memory information
> @@ -868,6 +869,7 @@ config CMD_MMC_SWRITE
>
> config CMD_MTD
> bool "mtd"
> + depends on MTD
> select MTD_PARTITIONS
> help
> MTD commands support.
> @@ -875,6 +877,7 @@ config CMD_MTD
> config CMD_NAND
> bool "nand"
> default y if NAND_SUNXI
> + depends on MTD_RAW_NAND
> help
> NAND support.
>
> @@ -915,6 +918,7 @@ config CMD_MMC_SPI
>
> config CMD_ONENAND
> bool "onenand - access to onenand device"
> + depends on MTD
> help
> OneNAND is a brand of NAND ('Not AND' gate) flash which provides
> various useful features. This command allows reading, writing,
> @@ -1733,7 +1737,7 @@ config CMD_JFFS2
>
> config CMD_MTDPARTS
> bool "MTD partition support"
> - select MTD if (CMD_NAND || NAND)
> + depends on MTD
> help
> MTD partitioning tool support.
> It is strongly encouraged to avoid using this command
> @@ -1754,14 +1758,14 @@ endif
>
> config MTDIDS_DEFAULT
> string "Default MTD IDs"
> - depends on MTD_PARTITIONS || CMD_MTDPARTS || CMD_NAND || CMD_FLASH
> + depends on MTD || SPI_FLASH
Can't we have MTD enabled without MTD_PARTITIONS? I guess we don't need
to expose these options if MTD_PARTITIONS is disabled.
> help
> Defines a default MTD IDs list for use with MTD partitions in the
> Linux MTD command line partitions format.
>
> config MTDPARTS_DEFAULT
> string "Default MTD partition scheme"
> - depends on MTD_PARTITIONS || CMD_MTDPARTS || CMD_NAND || CMD_FLASH
> + depends on MTD || SPI_FLASH
> help
> Defines a default MTD partitioning scheme in the Linux MTD command
> line partitions format
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 28/28] mtd: properly handle SPL kbuild lines
Hi Miquel, On Wed, 5 Dec 2018 00:57:14 +0100 Miquel Raynal wrote: > Instead of compiling just a few files from the root Makefile, rework > the MTD Makefile tree to take into account SPL's needs. > As mentioned in my review of patch 1, I think patch 1, 27 and 28 could be merged in a single patch that would be placed at the end of this series as the final (real) Makefile cleanup. BTW, good job! I can only imagine how painful it was to do this without breaking builds. Regards, Boris ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 26/28] cmd: make MTD commands depend on MTD
Hi Boris,
Boris Brezillon wrote on Wed, 5 Dec 2018
11:42:08 +0100:
> On Wed, 5 Dec 2018 00:57:12 +0100
> Miquel Raynal wrote:
>
> > Defconfigs have been fixed, now we can add proper dependencies in
> > Kconfig. SPI FLASH is still not dependent on MTD (deeper rework needed).
> >
> > Signed-off-by: Miquel Raynal
> > ---
> > cmd/Kconfig | 10 +++---
> > 1 file changed, 7 insertions(+), 3 deletions(-)
> >
> > diff --git a/cmd/Kconfig b/cmd/Kconfig
> > index cf58174013..7c166a07e6 100644
> > --- a/cmd/Kconfig
> > +++ b/cmd/Kconfig
> > @@ -679,6 +679,7 @@ config CMD_FDC
> > config CMD_FLASH
> > bool "flinfo, erase, protect"
> > default y
> > + depends on MTD
> > help
> > NOR flash support.
> > flinfo - print FLASH memory information
> > @@ -868,6 +869,7 @@ config CMD_MMC_SWRITE
> >
> > config CMD_MTD
> > bool "mtd"
> > + depends on MTD
> > select MTD_PARTITIONS
> > help
> > MTD commands support.
> > @@ -875,6 +877,7 @@ config CMD_MTD
> > config CMD_NAND
> > bool "nand"
> > default y if NAND_SUNXI
> > + depends on MTD_RAW_NAND
> > help
> > NAND support.
> >
> > @@ -915,6 +918,7 @@ config CMD_MMC_SPI
> >
> > config CMD_ONENAND
> > bool "onenand - access to onenand device"
> > + depends on MTD
> > help
> > OneNAND is a brand of NAND ('Not AND' gate) flash which provides
> > various useful features. This command allows reading, writing,
> > @@ -1733,7 +1737,7 @@ config CMD_JFFS2
> >
> > config CMD_MTDPARTS
> > bool "MTD partition support"
> > - select MTD if (CMD_NAND || NAND)
> > + depends on MTD
> > help
> > MTD partitioning tool support.
> > It is strongly encouraged to avoid using this command
> > @@ -1754,14 +1758,14 @@ endif
> >
> > config MTDIDS_DEFAULT
> > string "Default MTD IDs"
> > - depends on MTD_PARTITIONS || CMD_MTDPARTS || CMD_NAND || CMD_FLASH
> > + depends on MTD || SPI_FLASH
>
> Can't we have MTD enabled without MTD_PARTITIONS? I guess we don't need
> to expose these options if MTD_PARTITIONS is disabled.
That's the theory. (Travis) Experience shows that adding a
dependency on MTD_PARTITIONS when removing the dependency on the above
commands is too restrictive and some header files using
MTDIDS/MTDPARTS_DEFAULT will produce build issues. This is insane but I
did not want to debug this issue and, anyway, it is harmless to have
these strings defined.
>
> > help
> > Defines a default MTD IDs list for use with MTD partitions in the
> > Linux MTD command line partitions format.
> >
> > config MTDPARTS_DEFAULT
> > string "Default MTD partition scheme"
> > - depends on MTD_PARTITIONS || CMD_MTDPARTS || CMD_NAND || CMD_FLASH
> > + depends on MTD || SPI_FLASH
> > help
> > Defines a default MTD partitioning scheme in the Linux MTD command
> > line partitions format
>
Thanks,
Miquèl
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 26/28] cmd: make MTD commands depend on MTD
On Wed, 5 Dec 2018 11:48:32 +0100
Miquel Raynal wrote:
> Hi Boris,
>
> Boris Brezillon wrote on Wed, 5 Dec 2018
> 11:42:08 +0100:
>
> > On Wed, 5 Dec 2018 00:57:12 +0100
> > Miquel Raynal wrote:
> >
> > > Defconfigs have been fixed, now we can add proper dependencies in
> > > Kconfig. SPI FLASH is still not dependent on MTD (deeper rework needed).
> > >
> > > Signed-off-by: Miquel Raynal
> > > ---
> > > cmd/Kconfig | 10 +++---
> > > 1 file changed, 7 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/cmd/Kconfig b/cmd/Kconfig
> > > index cf58174013..7c166a07e6 100644
> > > --- a/cmd/Kconfig
> > > +++ b/cmd/Kconfig
> > > @@ -679,6 +679,7 @@ config CMD_FDC
> > > config CMD_FLASH
> > > bool "flinfo, erase, protect"
> > > default y
> > > + depends on MTD
> > > help
> > > NOR flash support.
> > > flinfo - print FLASH memory information
> > > @@ -868,6 +869,7 @@ config CMD_MMC_SWRITE
> > >
> > > config CMD_MTD
> > > bool "mtd"
> > > + depends on MTD
> > > select MTD_PARTITIONS
> > > help
> > > MTD commands support.
> > > @@ -875,6 +877,7 @@ config CMD_MTD
> > > config CMD_NAND
> > > bool "nand"
> > > default y if NAND_SUNXI
> > > + depends on MTD_RAW_NAND
> > > help
> > > NAND support.
> > >
> > > @@ -915,6 +918,7 @@ config CMD_MMC_SPI
> > >
> > > config CMD_ONENAND
> > > bool "onenand - access to onenand device"
> > > + depends on MTD
> > > help
> > > OneNAND is a brand of NAND ('Not AND' gate) flash which provides
> > > various useful features. This command allows reading, writing,
> > > @@ -1733,7 +1737,7 @@ config CMD_JFFS2
> > >
> > > config CMD_MTDPARTS
> > > bool "MTD partition support"
> > > - select MTD if (CMD_NAND || NAND)
> > > + depends on MTD
> > > help
> > > MTD partitioning tool support.
> > > It is strongly encouraged to avoid using this command
> > > @@ -1754,14 +1758,14 @@ endif
> > >
> > > config MTDIDS_DEFAULT
> > > string "Default MTD IDs"
> > > - depends on MTD_PARTITIONS || CMD_MTDPARTS || CMD_NAND || CMD_FLASH
> > > + depends on MTD || SPI_FLASH
> >
> > Can't we have MTD enabled without MTD_PARTITIONS? I guess we don't need
> > to expose these options if MTD_PARTITIONS is disabled.
>
> That's the theory. (Travis) Experience shows that adding a
> dependency on MTD_PARTITIONS when removing the dependency on the above
> commands is too restrictive and some header files using
> MTDIDS/MTDPARTS_DEFAULT will produce build issues. This is insane but I
> did not want to debug this issue and, anyway, it is harmless to have
> these strings defined.
Fair enough.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 25/28] cmd: nand/sf: isolate legacy code
Hello, On Wed, 5 Dec 2018 11:37:54 +0100, Boris Brezillon wrote: > ifeq (,$(findstring y,$(CONFIG_CMD_NAND)$(CONFIG_CMD_SF))) This could be "simplified" as: ifneq ($(CONFIG_CMD_NAND)$(CONFIG_CMD_SF),) if either of the options is 'y', the string is non-empty, so the condition will be true. Best regards, Thomas -- Thomas Petazzoni, CTO, Bootlin Embedded Linux and Kernel engineering https://bootlin.com ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 16/28] configs: move CONFIG_MTD in defconfigs when set in arch includes
Hi Boris, Boris Brezillon wrote on Wed, 5 Dec 2018 11:17:28 +0100: > On Wed, 5 Dec 2018 00:57:02 +0100 > Miquel Raynal wrote: > > > Let's be consistent and always declare CONFIG_MTD from the defconfig > > file when needed. > > > > Signed-off-by: Miquel Raynal > > Reviewed-by: Boris Brezillon > > One comment below. > > > --- > > configs/socfpga_stratix10_defconfig | 1 + > > configs/turris_mox_defconfig | 1 + > > include/configs/mvebu_armada-37xx.h | 1 - > > include/configs/socfpga_stratix10_socdk.h | 1 - > > 4 files changed, 2 insertions(+), 2 deletions(-) > > > > diff --git a/configs/socfpga_stratix10_defconfig > > b/configs/socfpga_stratix10_defconfig > > index 5f3d733a8b..292dbd6973 100644 > > --- a/configs/socfpga_stratix10_defconfig > > +++ b/configs/socfpga_stratix10_defconfig > > @@ -38,6 +38,7 @@ CONFIG_DM_I2C=y > > CONFIG_SYS_I2C_DW=y > > CONFIG_DM_MMC=y > > CONFIG_MMC_DW=y > > +CONFIG_MTD=y > > CONFIG_SPI_FLASH=y > > CONFIG_SPI_FLASH_BAR=y > > CONFIG_SPI_FLASH_SPANSION=y > > diff --git a/configs/turris_mox_defconfig b/configs/turris_mox_defconfig > > index 749ed31acd..13e2af7e1b 100644 > > --- a/configs/turris_mox_defconfig > > +++ b/configs/turris_mox_defconfig > > @@ -42,6 +42,7 @@ CONFIG_DM_MMC=y > > CONFIG_MMC_SDHCI=y > > CONFIG_MMC_SDHCI_SDMA=y > > CONFIG_MMC_SDHCI_XENON=y > > +CONFIG_MTD=y > > CONFIG_SPI_FLASH=y > > CONFIG_SPI_FLASH_MACRONIX=y > > CONFIG_SPI_FLASH_SPANSION=y > > diff --git a/include/configs/mvebu_armada-37xx.h > > b/include/configs/mvebu_armada-37xx.h > > index f93ab0f830..640267c9c2 100644 > > --- a/include/configs/mvebu_armada-37xx.h > > +++ b/include/configs/mvebu_armada-37xx.h > > @@ -64,7 +64,6 @@ > > #define CONFIG_SF_DEFAULT_SPEED100 > > #define CONFIG_SF_DEFAULT_MODE SPI_MODE_0 > > #define CONFIG_ENV_SPI_MODECONFIG_SF_DEFAULT_MODE > > -#define CONFIG_MTD /* needed for mtdparts commands */ > > #define CONFIG_MTD_PARTITIONS /* required for UBI partition > > support */ > > > > /* Environment in SPI NOR flash */ > > diff --git a/include/configs/socfpga_stratix10_socdk.h > > b/include/configs/socfpga_stratix10_socdk.h > > index 22e1dc84a1..967784e379 100644 > > --- a/include/configs/socfpga_stratix10_socdk.h > > +++ b/include/configs/socfpga_stratix10_socdk.h > > @@ -76,7 +76,6 @@ > > #endif /* CONFIG_ENV_IS_IN_SPI_FLASH */ > > > > #ifndef CONFIG_SPL_BUILD > > -#define CONFIG_MTD > > #define CONFIG_MTD_PARTITIONS > > Do you get rid of CONFIG_MTD_PARTITIONS at some point? Not anymore, but I could probably add a patch for that. > > > #define MTDIDS_DEFAULT "nor0=ff705000.spi.0" > > #endif /* CONFIG_SPL_BUILD */ > Thanks, Miquèl ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 17/28] configs: remove raw NAND core from k2g defconfigs
Hi Boris, Boris Brezillon wrote on Wed, 5 Dec 2018 11:19:49 +0100: > On Wed, 5 Dec 2018 00:57:03 +0100 > Miquel Raynal wrote: > > > Due to previous Makefile organization, the raw NAND subdirectory was > > not compiled in if CMD_NAND was not enabled. Because the Denali driver > > does not compile with these boards (undefined environment offset), > > remove the dependency within the defconfig over the controller driver > > (was ignored anyway in the past). > > Maybe this should be moved before the Makefile re-organization if this > the build of those defconfigs. I will move the first Makefile change at the end and probably squash it with the two others, so this will happen before any Makefile change. Thanks, Miquèl ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v4 00/11] mtd/sf: Various fixes
Hi Jagan, On Sun, 2 Dec 2018 10:54:21 +0100 Boris Brezillon wrote: > Hello, > > This is the 4th version of the mtd / sf fixes patchset. This v4 just > adds a new check in del_mtd_device() (and a debug() when > del_mtd_partitions() fails). > > Regards, > > Boris > > P.S.: travis-ci results => > https://travis-ci.org/bbrezillon/u-boot/builds/461943011 Please don't wait too long before queuing this series and sending a fixes PR to Tom. I don't want to end up in the same situation we were for 2018.11. Thanks, Boris ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RFC PATCH v2 08/11] mtd: spi: Add lightweight SPI flash stack for SPL
On 05/12/18 12:31 PM, Simon Goldschmidt wrote:
> On Tue, Dec 4, 2018 at 1:27 PM Vignesh R wrote:
>>
>> Add a tiny SPI flash stack that just supports reading data/images from
>> SPI flash. This is useful for boards that have SPL size constraints and
>> would need to use SPI flash framework just to read images/data from
>> flash. There is approximately 1.5 to 2KB savings with this.
>
> We could reduce the size further by removing write functionality (and
> everything that's related to write, like write protection, etc.). If
> this was a Kconfig option, write-related code in drivers could be left
> out as well.
>
Yes, for now
> But that's probably work for the future?
>
>> Based on prior work of reducing spi flash id table by
>> Simon Goldschmidt
>>
>> Signed-off-by: Vignesh R
>> ---
>> common/spl/Kconfig | 9 +
>> drivers/mtd/spi/Makefile | 8 +-
>> drivers/mtd/spi/sf_internal.h | 2 +
>> drivers/mtd/spi/spi-nor-ids.c | 294
>> drivers/mtd/spi/spi-nor-tiny.c | 806 +
>> drivers/mtd/spi/spi-nor.c | 266 +--
>> 6 files changed, 1122 insertions(+), 263 deletions(-)
>> create mode 100644 drivers/mtd/spi/spi-nor-ids.c
>> create mode 100644 drivers/mtd/spi/spi-nor-tiny.c
>>
>> diff --git a/common/spl/Kconfig b/common/spl/Kconfig
>> index 2b6f315b1cf3..e3597249188c 100644
>> --- a/common/spl/Kconfig
>> +++ b/common/spl/Kconfig
>> @@ -727,6 +727,15 @@ config SPL_SPI_FLASH_SUPPORT
>> lines). This enables the drivers in drivers/mtd/spi as part of an
>> SPL build. This normally requires SPL_SPI_SUPPORT.
>>
>> +config SPL_SPI_FLASH_TINY
>> + bool "Enable low footprint SPL SPI Flash support"
>> + depends on SPL_SPI_FLASH_SUPPORT
>> + help
>> +Enable lightweight SPL SPI Flash support that supports just reading
>> +data/images from flash. No support to write/erase flash. Enable
>> +this if you have SPL size limitations and don't need full
>> +fledged SPI flash support.
>> +
>> config SPL_SPI_FLASH_SFDP_SUPPORT
>
> Am I right that this does not do anything when SPL_SPI_FLASH_TINY is
> enabled? Should it somehow depend on "not tiny"?
Will take care of that.
>
>> bool "SFDP table parsing support for SPI NOR flashes"
>> help
>> diff --git a/drivers/mtd/spi/Makefile b/drivers/mtd/spi/Makefile
>> index 9cd6672e93ce..4d1588ecc169 100644
>> --- a/drivers/mtd/spi/Makefile
>> +++ b/drivers/mtd/spi/Makefile
>> @@ -7,9 +7,15 @@ obj-$(CONFIG_DM_SPI_FLASH) += sf-uclass.o
>>
>> ifdef CONFIG_SPL_BUILD
>> obj-$(CONFIG_SPL_SPI_BOOT) += fsl_espi_spl.o
>> +ifeq ($(CONFIG_SPL_SPI_FLASH_TINY),y)
>> +obj-$(CONFIG_SPL_SPI_FLASH_TINY) += sf_probe.o spi-nor-tiny.o spi-nor-ids.o
>> +else
>> +obj-$(CONFIG_SPI_FLASH) += sf_probe.o spi-nor.o spi-nor-ids.o
>> +endif
>> +else
>> +obj-$(CONFIG_SPI_FLASH) += sf_probe.o spi-nor.o spi-nor-ids.o
>
> Would it make sense to have "sf_probe.o" and "spi-nor-ids.o" the same
> for all 3 configs to reduce duplicate lines?
>
>
Ok, I changed that to:
diff --git a/drivers/mtd/spi/Makefile b/drivers/mtd/spi/Makefile
index 9cd6672e93ce..9f7ab87b4c5f 100644
--- a/drivers/mtd/spi/Makefile
+++ b/drivers/mtd/spi/Makefile
@@ -4,12 +4,20 @@
# Wolfgang Denk, DENX Software Engineering, w...@denx.de.
obj-$(CONFIG_DM_SPI_FLASH) += sf-uclass.o
+spi-flash-y := sf_probe.o spi-nor-ids.o
ifdef CONFIG_SPL_BUILD
obj-$(CONFIG_SPL_SPI_BOOT) += fsl_espi_spl.o
+ifeq ($(CONFIG_SPL_SPI_FLASH_TINY),y)
+spi-flash-y += spi-nor-tiny.o
+else
+spi-flash-y += spi-nor.o
+endif
+else
+spi-flash-y += spi-nor.o
endif
-obj-$(CONFIG_SPI_FLASH) += sf_probe.o spi-nor.o
+obj-$(CONFIG_SPI_FLASH) += spi-flash.o
Regards
Vignesh
>> endif
>>
>> -obj-$(CONFIG_SPI_FLASH) += sf_probe.o spi-nor.o
>> obj-$(CONFIG_SPI_FLASH_DATAFLASH) += sf_dataflash.o sf.o
>> obj-$(CONFIG_SPI_FLASH_MTD) += sf_mtd.o
>> obj-$(CONFIG_SPI_FLASH_SANDBOX) += sandbox.o
>> diff --git a/drivers/mtd/spi/sf_internal.h b/drivers/mtd/spi/sf_internal.h
>> index 55619f5aea5c..7e7d400cdbdf 100644
>> --- a/drivers/mtd/spi/sf_internal.h
>> +++ b/drivers/mtd/spi/sf_internal.h
>> @@ -16,7 +16,9 @@
>> #define SPI_NOR_MAX_ADDR_WIDTH 4
>>
>> struct flash_info {
>> +#if !CONFIG_IS_ENABLED(SPI_FLASH_TINY)
>> char*name;
>> +#endif
>>
>> /*
>> * This array stores the ID bytes.
>> diff --git a/drivers/mtd/spi/spi-nor-ids.c b/drivers/mtd/spi/spi-nor-ids.c
>> new file mode 100644
>> index ..fd20c86b3aef
>> --- /dev/null
>> +++ b/drivers/mtd/spi/spi-nor-ids.c
>> @@ -0,0 +1,294 @@
>> +// SPDX-License-Identifier: GPL-2.0+
>> +/*
>> + * Copyright (C) 2018 Texas Instruments Incorporated - http://www.ti.com/
>> + */
>> +
>> +#include
>> +#include
>> +#include
>> +
>> +#include "sf_internal.h"
>> +
>> +/* Exclude chip names for SPL to save space */
>> +#if !CONFIG_IS_ENABLED(SPI_FLASH_TINY)
>> +#define INFO_NAME(_name) .name = _name,
>> +#else
>> +#defi
Re: [U-Boot] [RFC PATCH v2 06/11] mtd spi: Switch to new SPI NOR framework
On 05/12/18 12:34 PM, Simon Goldschmidt wrote:
> On Tue, Dec 4, 2018 at 1:27 PM Vignesh R wrote:
>>
>> Switch spi_flash_* interfaces to call into new SPI NOR framework via MTD
>> layer. Fix up sf_dataflash to work in legacy way. And update sandbox to
>> use new interfaces/defintions
>>
>> Signed-off-by: Vignesh R
>> ---
>> common/spl/Kconfig | 7 +
>> drivers/mtd/spi/Kconfig| 8 ++
>> drivers/mtd/spi/Makefile | 4 +-
>> drivers/mtd/spi/sandbox.c | 36 +++---
>> drivers/mtd/spi/sf_dataflash.c | 11 +-
>> drivers/mtd/spi/sf_internal.h | 228 +++--
>> drivers/mtd/spi/sf_probe.c | 33 +++--
>> drivers/mtd/spi/spi-nor.c | 59 +
>> drivers/spi/stm32_qspi.c | 4 +-
>> include/spi_flash.h| 105 ---
>> 10 files changed, 130 insertions(+), 365 deletions(-)
>>
>> diff --git a/common/spl/Kconfig b/common/spl/Kconfig
>> index 0ddbffc7d1c6..2b6f315b1cf3 100644
>> --- a/common/spl/Kconfig
>> +++ b/common/spl/Kconfig
>> @@ -727,6 +727,13 @@ config SPL_SPI_FLASH_SUPPORT
>> lines). This enables the drivers in drivers/mtd/spi as part of an
>> SPL build. This normally requires SPL_SPI_SUPPORT.
>>
>> +config SPL_SPI_FLASH_SFDP_SUPPORT
>> + bool "SFDP table parsing support for SPI NOR flashes"
>> + help
>> +Enable support for parsing and auto discovery of parameters for
>> +SPI NOR flashes using Serial Flash Discoverable Parameters (SFDP)
>> +tables as per JESD216 standard in SPL.
>> +
>
> I know other options are like this, too, but I would prefer it if this
> option was disabled or hidden when SPL_SPI_FLASH_SUPPORT is disabled.
>
I agree, will fix that in next revision.
Regards
Vignesh
> Regards,
> Simon
>
>> config SPL_SPI_LOAD
>> bool "Support loading from SPI flash"
>> depends on SPL_SPI_FLASH_SUPPORT
>> diff --git a/drivers/mtd/spi/Kconfig b/drivers/mtd/spi/Kconfig
>> index 76d5a1d11527..d735884b48db 100644
>> --- a/drivers/mtd/spi/Kconfig
>> +++ b/drivers/mtd/spi/Kconfig
>> @@ -27,6 +27,7 @@ config SPI_FLASH_SANDBOX
>>
>> config SPI_FLASH
>> bool "Legacy SPI Flash Interface support"
>> + select SPI_MEM
>> help
>> Enable the legacy SPI flash support. This will include basic
>> standard support for things like probing, read / write, and
>> @@ -34,6 +35,13 @@ config SPI_FLASH
>>
>> If unsure, say N
>>
>> +config SPI_FLASH_SFDP_SUPPORT
>> + bool "SFDP table parsing support for SPI NOR flashes"
>> + help
>> +Enable support for parsing and auto discovery of parameters for
>> +SPI NOR flashes using Serial Flash Discoverable Parameters (SFDP)
>> +tables as per JESD216 standard.
>> +
>> config SPI_FLASH_BAR
>> bool "SPI flash Bank/Extended address register support"
>> depends on SPI_FLASH
>> diff --git a/drivers/mtd/spi/Makefile b/drivers/mtd/spi/Makefile
>> index b4c7e1c98bd5..9cd6672e93ce 100644
>> --- a/drivers/mtd/spi/Makefile
>> +++ b/drivers/mtd/spi/Makefile
>> @@ -9,7 +9,7 @@ ifdef CONFIG_SPL_BUILD
>> obj-$(CONFIG_SPL_SPI_BOOT) += fsl_espi_spl.o
>> endif
>>
>> -obj-$(CONFIG_SPI_FLASH) += sf_probe.o spi_flash.o spi_flash_ids.o sf.o
>> -obj-$(CONFIG_SPI_FLASH_DATAFLASH) += sf_dataflash.o
>> +obj-$(CONFIG_SPI_FLASH) += sf_probe.o spi-nor.o
>> +obj-$(CONFIG_SPI_FLASH_DATAFLASH) += sf_dataflash.o sf.o
>> obj-$(CONFIG_SPI_FLASH_MTD) += sf_mtd.o
>> obj-$(CONFIG_SPI_FLASH_SANDBOX) += sandbox.o
>> diff --git a/drivers/mtd/spi/sandbox.c b/drivers/mtd/spi/sandbox.c
>> index 7b9891cb981c..084c66e9840b 100644
>> --- a/drivers/mtd/spi/sandbox.c
>> +++ b/drivers/mtd/spi/sandbox.c
>> @@ -92,7 +92,7 @@ struct sandbox_spi_flash {
>> /* The current flash status (see STAT_XXX defines above) */
>> u16 status;
>> /* Data describing the flash we're emulating */
>> - const struct spi_flash_info *data;
>> + const struct flash_info *data;
>> /* The file on disk to serv up data from */
>> int fd;
>> };
>> @@ -122,7 +122,7 @@ static int sandbox_sf_probe(struct udevice *dev)
>> /* spec = idcode:file */
>> struct sandbox_spi_flash *sbsf = dev_get_priv(dev);
>> size_t len, idname_len;
>> - const struct spi_flash_info *data;
>> + const struct flash_info *data;
>> struct sandbox_spi_flash_plat_data *pdata = dev_get_platdata(dev);
>> struct sandbox_state *state = state_get_current();
>> struct dm_spi_slave_platdata *slave_plat;
>> @@ -155,7 +155,7 @@ static int sandbox_sf_probe(struct udevice *dev)
>> idname_len = strlen(spec);
>> debug("%s: device='%s'\n", __func__, spec);
>>
>> - for (data = spi_flash_ids; data->name; data++) {
>> + for (data = spi_nor_ids; data->name; data++) {
>> len = strlen(data->name);
>> if (idname_len != len)
>> continue;
>> @
Re: [U-Boot] [PATCH v3 25/28] cmd: nand/sf: isolate legacy code
Hello, Thomas Petazzoni wrote on Wed, 5 Dec 2018 11:53:52 +0100: > Hello, > > On Wed, 5 Dec 2018 11:37:54 +0100, Boris Brezillon wrote: > > > ifeq (,$(findstring y,$(CONFIG_CMD_NAND)$(CONFIG_CMD_SF))) > > This could be "simplified" as: > > ifneq ($(CONFIG_CMD_NAND)$(CONFIG_CMD_SF),) > > if either of the options is 'y', the string is non-empty, so the > condition will be true. Thank you both of you, I will use this trick to avoid build failures with the situation raised by Boris. Thanks, Miquèl ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 21/28] mtd: nor: NOR flashes depend on MTD
Hi Boris, Boris Brezillon wrote on Wed, 5 Dec 2018 11:31:44 +0100: > On Wed, 5 Dec 2018 00:57:07 +0100 > Miquel Raynal wrote: > > > A NOR flash needs the MTD core, ensure this dependency is met by > > adding a "depends on" in Kconfig. This is fine since defconfigs have > > been fixed. > > > > Signed-off-by: Miquel Raynal > > --- > > drivers/mtd/Kconfig | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/drivers/mtd/Kconfig b/drivers/mtd/Kconfig > > index 345046c2a6..0832f5b411 100644 > > --- a/drivers/mtd/Kconfig > > +++ b/drivers/mtd/Kconfig > > @@ -19,6 +19,7 @@ config DM_MTD > > > > config MTD_NOR_FLASH > > bool "Enable parallel NOR flash support" > > + depends on MTD > > help > > Enable support for parallel NOR flash. > > > > Don't know if this applies here, but if you have almost all options in > Kconfig that depend on MTD, you can add an > > if MTD > endif > > section. Unfortunately, not yet. There are still a lot of MTD drivers that do not rely (at least in Kconfig) on CONFIG_MTD. This is inconsistent and should be fixed. I don't think I will do it in this series though. Thanks, Miquèl ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 16/28] configs: move CONFIG_MTD in defconfigs when set in arch includes
Hi Boris, Boris Brezillon wrote on Wed, 5 Dec 2018 11:17:28 +0100: > On Wed, 5 Dec 2018 00:57:02 +0100 > Miquel Raynal wrote: > > > Let's be consistent and always declare CONFIG_MTD from the defconfig > > file when needed. > > > > Signed-off-by: Miquel Raynal > > Reviewed-by: Boris Brezillon > > One comment below. > > > --- > > configs/socfpga_stratix10_defconfig | 1 + > > configs/turris_mox_defconfig | 1 + > > include/configs/mvebu_armada-37xx.h | 1 - > > include/configs/socfpga_stratix10_socdk.h | 1 - > > 4 files changed, 2 insertions(+), 2 deletions(-) > > > > diff --git a/configs/socfpga_stratix10_defconfig > > b/configs/socfpga_stratix10_defconfig > > index 5f3d733a8b..292dbd6973 100644 > > --- a/configs/socfpga_stratix10_defconfig > > +++ b/configs/socfpga_stratix10_defconfig > > @@ -38,6 +38,7 @@ CONFIG_DM_I2C=y > > CONFIG_SYS_I2C_DW=y > > CONFIG_DM_MMC=y > > CONFIG_MMC_DW=y > > +CONFIG_MTD=y > > CONFIG_SPI_FLASH=y > > CONFIG_SPI_FLASH_BAR=y > > CONFIG_SPI_FLASH_SPANSION=y > > diff --git a/configs/turris_mox_defconfig b/configs/turris_mox_defconfig > > index 749ed31acd..13e2af7e1b 100644 > > --- a/configs/turris_mox_defconfig > > +++ b/configs/turris_mox_defconfig > > @@ -42,6 +42,7 @@ CONFIG_DM_MMC=y > > CONFIG_MMC_SDHCI=y > > CONFIG_MMC_SDHCI_SDMA=y > > CONFIG_MMC_SDHCI_XENON=y > > +CONFIG_MTD=y > > CONFIG_SPI_FLASH=y > > CONFIG_SPI_FLASH_MACRONIX=y > > CONFIG_SPI_FLASH_SPANSION=y > > diff --git a/include/configs/mvebu_armada-37xx.h > > b/include/configs/mvebu_armada-37xx.h > > index f93ab0f830..640267c9c2 100644 > > --- a/include/configs/mvebu_armada-37xx.h > > +++ b/include/configs/mvebu_armada-37xx.h > > @@ -64,7 +64,6 @@ > > #define CONFIG_SF_DEFAULT_SPEED100 > > #define CONFIG_SF_DEFAULT_MODE SPI_MODE_0 > > #define CONFIG_ENV_SPI_MODECONFIG_SF_DEFAULT_MODE > > -#define CONFIG_MTD /* needed for mtdparts commands */ > > #define CONFIG_MTD_PARTITIONS /* required for UBI partition > > support */ > > > > /* Environment in SPI NOR flash */ > > diff --git a/include/configs/socfpga_stratix10_socdk.h > > b/include/configs/socfpga_stratix10_socdk.h > > index 22e1dc84a1..967784e379 100644 > > --- a/include/configs/socfpga_stratix10_socdk.h > > +++ b/include/configs/socfpga_stratix10_socdk.h > > @@ -76,7 +76,6 @@ > > #endif /* CONFIG_ENV_IS_IN_SPI_FLASH */ > > > > #ifndef CONFIG_SPL_BUILD > > -#define CONFIG_MTD > > #define CONFIG_MTD_PARTITIONS > > Do you get rid of CONFIG_MTD_PARTITIONS at some point? Not anymore. I know it would be preferable to push all MTD configurations in defconfigs but precisely in this case the definition is enclosed in a "#ifndef CONFIG_SPL_BUILD" condition, which makes the move to defconfig inconsistent. This is the reason why I decided to keep this definition in header files for now (another one in Armada 37xx header). > > > #define MTDIDS_DEFAULT "nor0=ff705000.spi.0" > > #endif /* CONFIG_SPL_BUILD */ > Thanks, Miquèl ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Issue with memcpy when booting a fitImage on SPEAr600
Hi Quentin, On 05.12.18 11:38, Quentin Schulz wrote: I'm working on porting a mainline U-Boot on a custom board based on a SPEAr600. Right now, I'm facing an issue related with fitImage booting. Before starting on the fitImage issue, let me state that the zImage and the custom DTB concatenated in a uImage have the load address and entry point be respectively 0x0200. and 0x0200.0040. The fitImage load and entry are both 0x0200.. The uImage loaded at the address 0x0080. is booted fine by U-Boot, the fitImage at the same address, not. The datasheet of the SoC states that the external SDRAM is located between 0x. and 0x3fff.. The size of the fitImage is currently 0x0038.9484 bytes, the uImage 0x0038.9007. The fitImage booting abruptly stops right after "Loading Device Tree to 0778a000, end 0778e7d6 ... OK" with the following trace: "prefetch abort pc : []lr : [<07fca8c7>] reloc pc : [] lr : [<03f388c7>] sp : 0778fb78 ip : fffc4c98 fp : 03f00020 r10: deadbeef r9 : 0778ff00 r8 : 07f922a0 r7 : 00ff r6 : 47d7 r5 : 4700 r4 : 0778a1b8 r3 : 0008 r2 : 16c4 r1 : 0778a1b8 r0 : 0778a1b8 Flags: nZCv IRQs off FIQs off Mode SVC_32 Code: data abort pc : [<07f931c6>]lr : [<07fb2dd1>] reloc pc : [<03f011c6>] lr : [<03f20dd1>] sp : 0778fa80 ip : 0114 fp : 03f00020 r10: deadbeef r9 : 0778ff00 r8 : 07f922a0 r7 : 6000 r6 : 0698 r5 : f188af44 r4 : fffc r3 : fff0 r2 : 0778ff00 r1 : 0020 r0 : 0006 Flags: NzCv IRQs on FIQs on Mode SVC_32 Code: 23036be5 439d4818 f885f038 42642404 (595a00a3) Resetting CPU ... resetting ... System is going to reboot ..." I've narrowed down the issue to a memmove being called with destination pointer being the source pointer. If I print a debug message before and after this memcpy[1], the first debug message is printed but not the second one. If I add a condition for (dest == src) return dest in the very beginning of memmove, the fitImage boots just fine. This test seemed to have been removed by commit cb0eae8cf8aaca76910dee4c7eb536d0814d1bd2[12], and by reverting this commit, I was able to successfuly boot Linux with a fitImage. Here is the log without debug messages WITHOUT the dest == src check in memmove: U-Boot 2018.11-7-g0b16f8424a-dirty (Dec 05 2018 - 09:23:31 +0100)-SPEAr CPU: SPEAr600 DRAM: 128 MiB Flash: 512 KiB NAND: 128 MiB Loading Environment from Flash... OK Net: dwmac.e080 Hit SPACE in 3 seconds to stop autoboot. => dhcp; tftp fitImage; bootm Speed: 100, full duplex BOOTP broadcast 1 DHCP client bound to address 192.168.0.169 (3 ms) Speed: 100, full duplex Using dwmac.e080 device TFTP from server 192.168.0.13; our IP address is 192.168.0.169 Filename 'fitImage'. Load address: 0x80 Loading: # # # ## 5.5 MiB/s done Bytes transferred = 3708036 (389484 hex) ## Loading kernel from FIT Image at 0080 ... Using 'conf@default' configuration Trying 'kernel@0' kernel subimage Description: Linux Type: Kernel Image Compression: uncompressed Data Start: 0x008000b0 Data Size:3700720 Bytes = 3.5 MiB Architecture: ARM OS: Linux Load Address: 0x0200 Entry Point: 0x0200 Hash algo:sha1 Hash value: efe249f573647bad3ce87c9c4b244986a90234db ## Loading fdt from FIT Image at 0080 ... Using 'conf@default' configuration Trying 'fdt@0' fdt subimage Description: Device Tree Type: Flat Device Tree Compression: uncompressed Data Start: 0x00b87984 Data Size:6103 Bytes = 6 KiB Architecture: ARM Hash algo:sha1 Hash value: 53089fa031e727f094e6bf9ad4e93f4e95b7fba3 Booting using the fdt blob at 0xb87984 Loading Kernel Image ... OK Loading Device Tree to 0778a000, end 0778e7d6 ... OK prefetch abort pc : []lr : [<07fca8c7>] reloc pc : [] lr : [<03f388c7>] sp : 0778fb78 ip : fffc4c98 fp : 03f00020 r10: deadbeef r9 : 0778ff00 r8 : 07f922a0 r7 : 00ff r6 : 47d7 r5 : 4700 r4 : 0778a1b8 r3 : 0008 r2 : 16c4 r1 : 0778a1b8 r0 : 0778a1b8 Flags: nZCv IRQs off FIQs off Mode SVC_32 Code: data abort pc : [<07f931c6>]lr : [<07fb2dd1>] reloc pc : [<03f011c6>] lr : [<03f20dd1>] sp : 0778fa80 ip : 0114 fp : 03f00020 r10: deadbeef r9 : 0778ff00 r8 : 07f922a0 r7 : 6000 r6 : 0698 r5 : f188af44 r4 : fffc r3 : fff0 r2 : 0778ff00 r1 : 0020 r0 : 0006 Flags: NzCv IRQs on FIQs on Mode SVC_32 Code: 23036be5 439d4818 f885f038 42642404 (595a00a3) Resetting CPU ... resetting ... System i
[U-Boot] [PATCH] mmc: zynq: Remove unused pwrseq variable
This variable was incorrectly added by:
"mmc: zynq_sdhci: Add support for SD3.0"
(sha1: d1f4e39d58db32a4fd1a1b4085e0ede498bd773f)
which had nothing to do with MMC power sequence provider.
Signed-off-by: Michal Simek
---
drivers/mmc/zynq_sdhci.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/mmc/zynq_sdhci.c b/drivers/mmc/zynq_sdhci.c
index 25d5688b4617..ae67ff0908ff 100644
--- a/drivers/mmc/zynq_sdhci.c
+++ b/drivers/mmc/zynq_sdhci.c
@@ -58,7 +58,6 @@ struct arasan_sdhci_priv {
u8 deviceid;
u8 bank;
u8 no_1p8;
- bool pwrseq;
};
#if defined(CONFIG_ARCH_ZYNQMP)
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [Fwd: [PATCH] mpc83xx: Add support for -msingle-pic-base]
Hi Joakim, On Wed, Dec 5, 2018 at 11:03 AM Joakim Tjernlund wrote: > > Ping ? > > On Thu, 2018-11-29 at 14:09 +0100, Joakim Tjernlund wrote: > > OOPS, I forgot to include you in this patch so I do that now :) > > > > > > --- Forwarded Message > > From: Joakim Tjernlund > > To: u-boot@lists.denx.de > > Cc: Joakim Tjernlund > > Subject: [PATCH] mpc83xx: Add support for -msingle-pic-base > > Date: Wed, 28 Nov 2018 10:59:55 +0100 > > > > -msingle-pic-base is a new gcc(from 4.6) option for ppc and > > it reduces the size of my u-boot with about 4 KB. > > While at it, add -fno-jump-tables too to save a > > few more bytes. > > > > Signed-off-by: Joakim Tjernlund > > --- > > > > I think all PowerPC's can use this but I have only tested > > 83xx so just enable for this cpu for now. > > > > arch/powerpc/cpu/mpc83xx/config.mk | 1 + > > arch/powerpc/cpu/mpc83xx/start.S | 3 +++ > > 2 files changed, 4 insertions(+) > > > > diff --git a/arch/powerpc/cpu/mpc83xx/config.mk > > b/arch/powerpc/cpu/mpc83xx/config.mk > > index 14870eec4d..a07df4d389 100644 > > --- a/arch/powerpc/cpu/mpc83xx/config.mk > > +++ b/arch/powerpc/cpu/mpc83xx/config.mk > > @@ -3,3 +3,4 @@ > > # Copyright 2004 Freescale Semiconductor, Inc. > > > > PLATFORM_CPPFLAGS += -DCONFIG_E300 -msoft-float > > +PLATFORM_RELFLAGS += -msingle-pic-base -fno-jump-tables > > diff --git a/arch/powerpc/cpu/mpc83xx/start.S > > b/arch/powerpc/cpu/mpc83xx/start.S > > index a3bacf138c..c00bb31363 100644 > > --- a/arch/powerpc/cpu/mpc83xx/start.S > > +++ b/arch/powerpc/cpu/mpc83xx/start.S > > @@ -288,6 +288,9 @@ in_flash: > > /*--*/ > > > > GET_GOT /* initialize GOT access*/ > > + /* Needed for -msingle-pic-base */ > > + bl _GLOBAL_OFFSET_TABLE_@local-4 > > + mflrr30 > > > > /* r3: IMMR */ > > lis r3, CONFIG_SYS_IMMR@h > Don't worry, I was aware of the patch; just had to find some time for testing :-) Reviewed-by: Mario Six Tested-by: Mario Six (on MPC8308) Best regards, Mario ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 13/28] mtd: ensure MTD is compiled when ENV_IS_IN_FLASH is selected
Dear Miquel, In message <20181204235714.11805-14-miquel.ray...@bootlin.com> you wrote: > MTD support must be enabled when the environment is in NOR. Naked-by: Wolfgang Denk Environment in NOR must not, I repeat: must not ever depend on MTD! For more than 19 years we have been using environment in NOR flash without the need for MTD support, which makes a lot of sense especially on smaller systems where resources are low and MTD is an expensive, but not really needed feature. It is not acceptable to create a dependency that costs so much. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Very ugly or very beautiful women should be flattered on their understanding, and mediocre ones on their beauty. -- Philip Earl of Chesterfield ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 06/28] mtd: ensure MTD/the raw NAND core are compiled when there is a NAND flash
Dear Miquel Raynal, In message <20181204235714.11805-7-miquel.ray...@bootlin.com> you wrote: > Both symbols must be enabled when there is a raw NAND driver > selected. Also enable them when CONFIG_CMD_NAND is selected to do not > break any build during later cleanup. Why would we need MTD for raw NAND support in U-Boot? It is perfectly fine to access NAND based on addesses / offsets, isn't it? MTD creates just overhead which is not needed on some systems, and which may not be acceptable due to size limitations on other. Naked-by: Wolfgang Denk Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de When all else fails, read the instructions. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 05/28] mtd: ensure MTD is compiled when there is a NOR flash
Dear Miquel Raynal, In message <20181204235714.11805-6-miquel.ray...@bootlin.com> you wrote: > CONFIG_MTD must be enabled when there is a NOR flash selected. This is a fundamental breakage. See previous messages. Naked-by: Wolfgang Denk Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de : ... and it's got weird formatting - Notepad, Write, Works 3 can't : decipher it, and it's too big to go in DOS Edit. Help! Install an operating system. :-) -- Tom Christiansen ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 21/28] mtd: nor: NOR flashes depend on MTD
Dear Miquel Raynal, In message <20181204235714.11805-22-miquel.ray...@bootlin.com> you wrote: > A NOR flash needs the MTD core, ensure this dependency is met by > adding a "depends on" in Kconfig. This is fine since defconfigs have > been fixed. If such a dependeny exists, it must be fixed. This is not acceptable. Naked-by: Wolfgang Denk Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de A fail-safe circuit will destroy others. -- Klipstein ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, PATCHv3, 2/4] dm: MIGRATION: Add migration plan for DM_USB
On Wed, Dec 05, 2018 at 08:14:14AM +0100, Stefan Roese wrote: > Hi Tom, > > On 04.12.18 05:49, Tom Rini wrote: > >On Thu, Nov 29, 2018 at 06:21:12PM -0500, Tom Rini wrote: > > > >>As much of the USB system has been migrated to DM now, formalize a > >>deadline for migration. > >> > >>Reviewed-by: Marek Vasut > >>Reviewed-by: Simon Glass > >>Signed-off-by: Tom Rini > > > >Applied to u-boot/master, thanks! > > Just a quick note on this, since I just tested compiling current > mainline on MVEBU "theadorable_debug". Here I get: > > = WARNING == > This board does not use CONFIG_DM_USB. Please update > the board to use CONFIG_DM_USB before the v2019.07 release. > Failure to update by the deadline may result in board removal. > See doc/driver-model/MIGRATION.txt for more info. > > = WARNING == > This board does not use CONFIG_DM_SCSI. Please update > the storage controller to use CONFIG_DM_SCSI before the v2019.07 release. > Failure to update by the deadline may result in board removal. > See doc/driver-model/MIGRATION.txt for more info. > > > The DM_SCSI warning seems to be okay, because of the not converted > ATA driver sata_mv.c (the controller is unfortunately not AHCI > compatible). I hope to find some time shortly to work on this. > > But the board definitely uses DM_USB: > > $ gg DM_USB configs/theadorable_debug_defconfig > configs/theadorable_debug_defconfig:CONFIG_DM_USB=y > > So the DM_USB warning seems to be wrong here. I think you're "stuck" here because you can't turn on CONFIG_BLK to silence the CONFIG_DM_USB warning without then breaking sata_mv.c. The CONFIG_DM_USB migration isn't complete until you're also using CONFIG_BLK. -- 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 1/1] arm: sunxi: Add NULL pointer check
Current driver doesn't check if the destination pointer is NULL.
This cause the data from the FIFO to be stored inside the internal
SDRAM ( address 0 ).
The patch add simple check if the destination pointer is NULL.
Signed-off-by: Stefan Mavrodiev
---
drivers/spi/sun4i_spi.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/spi/sun4i_spi.c b/drivers/spi/sun4i_spi.c
index b86b5a00ad..38cc743c61 100644
--- a/drivers/spi/sun4i_spi.c
+++ b/drivers/spi/sun4i_spi.c
@@ -129,7 +129,8 @@ static inline void sun4i_spi_drain_fifo(struct
sun4i_spi_priv *priv, int len)
while (len--) {
byte = readb(&priv->regs->rxdata);
- *priv->rx_buf++ = byte;
+ if (priv->rx_buf)
+ *priv->rx_buf++ = byte;
}
}
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/3] buildman: Drop comment about Ctrl-C problem
This bug is now fixed, so drop this comment. Signed-off-by: Simon Glass --- tools/buildman/README | 2 -- 1 file changed, 2 deletions(-) diff --git a/tools/buildman/README b/tools/buildman/README index 5a709c6ff9e..d688b7cf006 100644 --- a/tools/buildman/README +++ b/tools/buildman/README @@ -1169,8 +1169,6 @@ access to log files. Also it would be nice if buildman could 'hunt' for problems, perhaps by building a few boards for each arch, or checking commits for changed files and building only boards which use those files. -A specific problem to fix is that Ctrl-C does not exit buildman cleanly when -multiple builder threads are active. Credits === -- 2.20.0.rc1.387.gf8505762e3-goog ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 3/3] travis: Use buildman for building with clang
Now that buildman supports clang, use it.
Signed-off-by: Simon Glass
---
.travis.yml | 13 +++--
1 file changed, 3 insertions(+), 10 deletions(-)
diff --git a/.travis.yml b/.travis.yml
index a061f02399c..59a00d065e3 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -109,16 +109,9 @@ script:
#
# From buildman, exit code 129 means warnings only. If we've been asked to
# use clang only do one configuration.
- - if [[ "${TOOLCHAIN}" == "clang" ]]; then
+ - if [[ "${BUILDMAN}" != "" ]]; then
ret=0;
- make O=../.bm-work/${TEST_PY_BD} HOSTCC=clang-7 CC=clang-7 -j$(nproc)
- KCFLAGS=-Werror sandbox_config all || ret=$?;
- if [[ $ret -ne 0 ]]; then
- exit $ret;
- fi;
- elif [[ "${BUILDMAN}" != "" ]]; then
- ret=0;
- tools/buildman/buildman -P -E ${BUILDMAN} || ret=$?;
+ tools/buildman/buildman -P -E ${BUILDMAN} ${OVERRIDE}|| ret=$?;
if [[ $ret -ne 0 && $ret -ne 129 ]]; then
tools/buildman/buildman -sdeP ${BUILDMAN};
exit $ret;
@@ -343,7 +336,7 @@ matrix:
env:
- TEST_PY_BD="sandbox"
BUILDMAN="^sandbox$"
- TOOLCHAIN="clang"
+ OVERRIDE="clang-7"
- name: "test/py sandbox_spl"
env:
- TEST_PY_BD="sandbox_spl"
--
2.20.0.rc1.387.gf8505762e3-goog
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 2/3] buildman: Add support for building with clang
Add a -O option which allows building with clang.
Signed-off-by: Simon Glass
---
tools/buildman/README | 10 ++
tools/buildman/cmdline.py | 2 ++
tools/buildman/control.py | 2 +-
tools/buildman/toolchain.py | 18 ++
4 files changed, 27 insertions(+), 5 deletions(-)
diff --git a/tools/buildman/README b/tools/buildman/README
index d688b7cf006..56a99c70a2a 100644
--- a/tools/buildman/README
+++ b/tools/buildman/README
@@ -1046,6 +1046,16 @@ value for 'altbootcmd', but lost one for ' altbootcmd'.
The -U option uses the u-boot.env files which are produced by a build.
+
+Building with clang
+===
+
+To build with clang (sandbox only), use the -O option to override the
+toolchain. For example:
+
+ buildman -O clang-7 --board sandbox
+
+
Other options
=
diff --git a/tools/buildman/cmdline.py b/tools/buildman/cmdline.py
index 93d09ca08d7..832a5145d28 100644
--- a/tools/buildman/cmdline.py
+++ b/tools/buildman/cmdline.py
@@ -74,6 +74,8 @@ def ParseArgs():
parser.add_option('-o', '--output-dir', type='string',
dest='output_dir', default='..',
help='Directory where all builds happen and buildman has its
workspace (default is ../)')
+parser.add_option('-O', '--override-toolchain', type='string',
+ help="Override host toochain to use for sandbox (e.g. 'clang-7')")
parser.add_option('-Q', '--quick', action='store_true',
default=False, help='Do a rough build, with limited warning
resolution')
parser.add_option('-p', '--full-path', action='store_true',
diff --git a/tools/buildman/control.py b/tools/buildman/control.py
index c900211510e..27916d3c355 100644
--- a/tools/buildman/control.py
+++ b/tools/buildman/control.py
@@ -141,7 +141,7 @@ def DoBuildman(options, args, toolchains=None,
make_func=None, boards=None,
no_toolchains = toolchains is None
if no_toolchains:
-toolchains = toolchain.Toolchains()
+toolchains = toolchain.Toolchains(options.override_toolchain)
if options.fetch_arch:
if options.fetch_arch == 'list':
diff --git a/tools/buildman/toolchain.py b/tools/buildman/toolchain.py
index 4b35f400e97..a4a2e0e73a1 100644
--- a/tools/buildman/toolchain.py
+++ b/tools/buildman/toolchain.py
@@ -54,9 +54,11 @@ class Toolchain:
arch: Architecture of toolchain as determined from the first
component of the filename. E.g. arm-linux-gcc becomes arm
priority: Toolchain priority (0=highest, 20=lowest)
+override_toolchain: Toolchain to use for sandbox, overriding the normal
+one
"""
def __init__(self, fname, test, verbose=False, priority=PRIORITY_CALC,
- arch=None):
+ arch=None, override_toolchain=None):
"""Create a new toolchain object.
Args:
@@ -68,6 +70,7 @@ class Toolchain:
"""
self.gcc = fname
self.path = os.path.dirname(fname)
+self.override_toolchain = override_toolchain
# Find the CROSS_COMPILE prefix to use for U-Boot. For example,
# 'arm-linux-gnueabihf-gcc' turns into 'arm-linux-gnueabihf-'.
@@ -81,6 +84,8 @@ class Toolchain:
self.arch = arch
else:
self.arch = self.cross[:pos] if pos != -1 else 'sandbox'
+if self.arch == 'sandbox' and override_toolchain:
+self.gcc = override_toolchain
env = self.MakeEnvironment(False)
@@ -154,7 +159,10 @@ class Toolchain:
env = dict(os.environ)
wrapper = self.GetWrapper()
-if full_path:
+if self.override_toolchain:
+env['HOSTCC'] = self.override_toolchain
+env['CC'] = self.override_toolchain
+elif full_path:
env['CROSS_COMPILE'] = wrapper + os.path.join(self.path,
self.cross)
else:
env['CROSS_COMPILE'] = wrapper + self.cross
@@ -180,10 +188,11 @@ class Toolchains:
paths: List of paths to check for toolchains (may contain wildcards)
"""
-def __init__(self):
+def __init__(self, override_toolchain=None):
self.toolchains = {}
self.prefixes = {}
self.paths = []
+self.override_toolchain = override_toolchain
self._make_flags = dict(bsettings.GetItems('make-flags'))
def GetPathList(self, show_warning=True):
@@ -234,7 +243,8 @@ class Toolchains:
priority: Priority to use for this toolchain
arch: Toolchain architecture, or None if not known
"""
-toolchain = Toolchain(fname, test, verbose, priority, arch)
+toolchain = Toolchain(fname, test, verbose, priority, arch,
+ self.override_toolchain)
add_it = toolchain.ok
if toolchain.arch in self.toolchains:
add_it = (toolchain.priority <
--
2.20.0.rc1.387.gf8505762e3-goog
___
U-Boot mailing list
U-Boot
Re: [U-Boot] [PATCH 6/7] defconfigs: Add config for AM57xx High Security EVM with UART/USB Boot support
On 05/12/18 3:07 AM, Andrew F. Davis wrote:
On 12/2/18 11:24 PM, Lokesh Vutla wrote:
On 30/11/18 10:41 PM, Andrew F. Davis wrote:
Add a new defconfig file for the AM57xx High Security EVM. This config
is specific for the case of UART/USB booting.
Can you share the steps on how you verified uart boot?
All the verification for this defconfig was with USB boot for the first
stage (ULO). UART cannot be tested with our DRA7xx EVMs as you pointed
out and to test on AM57xx special scrips need to be used as the ROM UART
loading protocol is not standard. UART loading of the second stage is
possible after loading the first stage using some other boot media.
okay, drop uart support from dra7xx hs defconfig. We should not confuse anyone
looking at the commit description or code.
Thanks and regards,
Lokesh
On HS, both USB and UART are special in their load address requirements,
this patch set fixes that. The UART support on HS cannot work with the
old defconfig.
Andrew
Thanks and regards,
Lokesh
Signed-off-by: Andrew F. Davis
---
MAINTAINERS | 1 +
configs/am57xx_hs_evm_uart_defconfig | 92
2 files changed, 93 insertions(+)
create mode 100644 configs/am57xx_hs_evm_uart_defconfig
diff --git a/MAINTAINERS b/MAINTAINERS
index d0c208b93d..b7366cfc0a 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -647,6 +647,7 @@ F: configs/am335x_hs_evm_defconfig
F: configs/am335x_hs_evm_uart_defconfig
F: configs/am43xx_hs_evm_defconfig
F: configs/am57xx_hs_evm_defconfig
+F: configs/am57xx_hs_evm_uart_defconfig
F: configs/dra7xx_hs_evm_defconfig
F: configs/dra7xx_hs_evm_uart_defconfig
F: configs/k2hk_hs_evm_defconfig
diff --git a/configs/am57xx_hs_evm_uart_defconfig
b/configs/am57xx_hs_evm_uart_defconfig
new file mode 100644
index 00..a0c42387ec
--- /dev/null
+++ b/configs/am57xx_hs_evm_uart_defconfig
@@ -0,0 +1,92 @@
+CONFIG_ARM=y
+CONFIG_ARCH_OMAP2PLUS=y
+CONFIG_TI_SECURE_DEVICE=y
+CONFIG_TI_COMMON_CMD_OPTIONS=y
+CONFIG_SYS_MALLOC_F_LEN=0x2000
+CONFIG_OMAP54XX=y
+CONFIG_TI_SECURE_EMIF_REGION_START=0xbdb0
+CONFIG_TI_SECURE_EMIF_TOTAL_REGION_SIZE=0x0200
+CONFIG_TI_SECURE_EMIF_PROTECTED_REGION_SIZE=0x01c0
+CONFIG_ISW_ENTRY_ADDR=0x40306d50
+CONFIG_TARGET_AM57XX_EVM=y
+CONFIG_SPL=y
+CONFIG_SPL_SPI_FLASH_SUPPORT=y
+CONFIG_SPL_SPI_SUPPORT=y
+CONFIG_ARMV7_LPAE=y
+CONFIG_DISTRO_DEFAULTS=y
+CONFIG_NR_DRAM_BANKS=2
+CONFIG_FIT_IMAGE_POST_PROCESS=y
+CONFIG_SPL_LOAD_FIT=y
+CONFIG_SPL_FIT_IMAGE_POST_PROCESS=y
+CONFIG_OF_BOARD_SETUP=y
+CONFIG_USE_BOOTARGS=y
+CONFIG_BOOTARGS="androidboot.serialno=${serial#} console=ttyS2,115200
androidboot.console=ttyS2 androidboot.hardware=beagle_x15board"
+# CONFIG_USE_BOOTCOMMAND is not set
+CONFIG_SYS_CONSOLE_INFO_QUIET=y
+# CONFIG_MISC_INIT_R is not set
+CONFIG_VERSION_VARIABLE=y
+CONFIG_BOARD_EARLY_INIT_F=y
+CONFIG_SPL_SYS_MALLOC_SIMPLE=y
+CONFIG_SPL_SEPARATE_BSS=y
+CONFIG_SPL_DMA_SUPPORT=y
+# CONFIG_SPL_NAND_SUPPORT is not set
+CONFIG_SPL_RAM_SUPPORT=y
+CONFIG_SPL_SPI_LOAD=y
+CONFIG_SPL_USB_GADGET_SUPPORT=y
+CONFIG_SPL_DFU=y
+CONFIG_SPL_YMODEM_SUPPORT=y
+# CONFIG_CMD_FLASH is not set
+# CONFIG_CMD_SETEXPR is not set
+CONFIG_OF_CONTROL=y
+CONFIG_SPL_OF_CONTROL=y
+CONFIG_DEFAULT_DEVICE_TREE="am57xx-beagle-x15"
+CONFIG_OF_LIST="am57xx-beagle-x15 am57xx-beagle-x15-revb1
am57xx-beagle-x15-revc am572x-idk am571x-idk am574x-idk"
+CONFIG_ENV_IS_IN_MMC=y
+CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG=y
+CONFIG_DM=y
+CONFIG_SPL_DM=y
+CONFIG_SCSI_AHCI=y
+# CONFIG_BLK is not set
+CONFIG_DFU_MMC=y
+CONFIG_DFU_RAM=y
+CONFIG_USB_FUNCTION_FASTBOOT=y
+CONFIG_FASTBOOT_BUF_ADDR=0x8200
+CONFIG_FASTBOOT_BUF_SIZE=0x2F00
+CONFIG_FASTBOOT_USB_DEV=1
+CONFIG_FASTBOOT_FLASH=y
+CONFIG_FASTBOOT_FLASH_MMC_DEV=1
+CONFIG_FASTBOOT_CMD_OEM_FORMAT=y
+CONFIG_DM_GPIO=y
+CONFIG_DM_I2C=y
+CONFIG_DM_MMC=y
+CONFIG_MMC_OMAP_HS=y
+CONFIG_DM_SPI_FLASH=y
+CONFIG_SPI_FLASH=y
+CONFIG_SPI_FLASH_BAR=y
+CONFIG_SPI_FLASH_SPANSION=y
+CONFIG_PHY_MICREL=y
+CONFIG_PHY_MICREL_KSZ90X1=y
+CONFIG_DM_ETH=y
+CONFIG_MII=y
+CONFIG_DRIVER_TI_CPSW=y
+CONFIG_DM_PMIC=y
+CONFIG_PMIC_PALMAS=y
+CONFIG_DM_REGULATOR=y
+CONFIG_DM_REGULATOR_PALMAS=y
+CONFIG_DM_SERIAL=y
+CONFIG_SPI=y
+CONFIG_DM_SPI=y
+CONFIG_TI_QSPI=y
+CONFIG_USB=y
+CONFIG_USB_XHCI_HCD=y
+CONFIG_USB_XHCI_DWC3=y
+CONFIG_USB_DWC3=y
+CONFIG_USB_DWC3_GADGET=y
+CONFIG_USB_DWC3_OMAP=y
+CONFIG_USB_DWC3_PHY_OMAP=y
+CONFIG_OMAP_USB_PHY=y
+CONFIG_USB_STORAGE=y
+CONFIG_USB_GADGET=y
+CONFIG_USB_GADGET_MANUFACTURER="Texas Instruments"
+CONFIG_USB_GADGET_VENDOR_NUM=0x0451
+CONFIG_USB_GADGET_PRODUCT_NUM=0xd022
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/1] usb: musb-new: sunxi: Fix null pointer access
When the device is in peripheral mode there is no
struct usb_bus_priv allocated pointer, as the uclass driver
("usb_dev_generic") doesn't call per_device_auto_alloc_size.
This results in writing to the internal SDRAM at
priv->desc_before_addr = true;
Signed-off-by: Stefan Mavrodiev
---
drivers/usb/musb-new/sunxi.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/musb-new/sunxi.c b/drivers/usb/musb-new/sunxi.c
index 6cf9826cda..f3deb9bc66 100644
--- a/drivers/usb/musb-new/sunxi.c
+++ b/drivers/usb/musb-new/sunxi.c
@@ -435,11 +435,14 @@ static int musb_usb_probe(struct udevice *dev)
{
struct sunxi_glue *glue = dev_get_priv(dev);
struct musb_host_data *host = &glue->mdata;
- struct usb_bus_priv *priv = dev_get_uclass_priv(dev);
struct musb_hdrc_platform_data pdata;
void *base = dev_read_addr_ptr(dev);
int ret;
+#ifdef CONFIG_USB_MUSB_HOST
+ struct usb_bus_priv *priv = dev_get_uclass_priv(dev);
+#endif
+
if (!base)
return -EINVAL;
@@ -459,7 +462,6 @@ static int musb_usb_probe(struct udevice *dev)
return ret;
}
- priv->desc_before_addr = true;
memset(&pdata, 0, sizeof(pdata));
pdata.power = 250;
@@ -467,6 +469,8 @@ static int musb_usb_probe(struct udevice *dev)
pdata.config = glue->cfg->config;
#ifdef CONFIG_USB_MUSB_HOST
+ priv->desc_before_addr = true;
+
pdata.mode = MUSB_HOST;
host->host = musb_init_controller(&pdata, &glue->dev, base);
if (!host->host)
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 1/7] dm: serial: Add ->getconfig() callback
HI Andy, On Tue, 27 Nov 2018 at 09:03, Andy Shevchenko wrote: > > On Mon, Nov 26, 2018 at 06:02:28PM -0700, Simon Glass wrote: > > Hi Andy, > > > > On Tue, 20 Nov 2018 at 14:52, Andy Shevchenko > > wrote: > > > > > > In some cases it would be good to know the settings, such as parity, > > > of current serial console. One example might be an ACPI SPCR table > > > to generate using these parameters. > > > > > > Signed-off-by: Andy Shevchenko > > > --- > > > drivers/serial/sandbox.c | 13 + > > > drivers/serial/serial-uclass.c | 16 > > > include/common.h | 1 + > > > include/serial.h | 26 +++--- > > > test/dm/serial.c | 7 +++ > > > 5 files changed, 60 insertions(+), 3 deletions(-) > > > > > > > My only concern is that serial_get_config() should have a device parameter. > > It's obviously out of scope of this series. > > The rest of similar functions are operate on top of current console device and > do not have such parameter, while being DM-based functions. > > I would gladly rebase my series on top any work which is done regard above > request. > For now, I don't see such possibility. My point is that you are adding a new function which does not use driver model properly. The serial_getconfig() function should have a device parameter, and it should not support non-DM, since it is a new feature. I'm going to pick this up, absent any other issues, and see if I can do a patch for it afterwards. Reviewed-by: Simon Glass Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] test: hexdump: fix misplaced return
On Tue, 4 Dec 2018 at 13:30, Simon Goldschmidt wrote: > > One of the hexdump tests in test/lib/hexdump.c returns right at the > start of the function without testing anything. > > Fix this by moving the 'return 0;' statement to the end of the function. > > Signed-off-by: Simon Goldschmidt > --- > > test/lib/hexdump.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) That's one way to make a test pass. Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 2/7] dm: serial: Introduce ->getinfo() callback
On Tue, 20 Nov 2018 at 14:52, Andy Shevchenko wrote: > > New callback will give a necessary information to fill up ACPI SPCR table, > for example. Maybe used later for other purposes. > > Signed-off-by: Andy Shevchenko > --- > drivers/serial/sandbox.c | 21 ++ > drivers/serial/serial-uclass.c | 21 ++ > include/common.h | 3 +++ > include/serial.h | 40 ++ > test/dm/serial.c | 5 + > 5 files changed, 90 insertions(+) Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 7/7] x86: acpi: Generate SPCR table
On Tue, 20 Nov 2018 at 14:52, Andy Shevchenko wrote: > > Microsoft specifies a SPCR (Serial Port Console Redirection Table) [1]. > Let's provide it in U-Boot. > > [1]: > https://docs.microsoft.com/en-us/windows-hardware/drivers/serports/serial-port-console-redirection-table > > Signed-off-by: Andy Shevchenko > --- > arch/x86/include/asm/acpi_table.h | 2 + > arch/x86/lib/acpi_table.c | 118 ++ > 2 files changed, 120 insertions(+) Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 3/7] serial: ns16550: Group reg_* members of ns16550_platdata
On Tue, 20 Nov 2018 at 14:52, Andy Shevchenko wrote: > > Group reg_* members of struct ns16550_platdata together for better > maintenance. > > No functional change intended. > > Signed-off-by: Andy Shevchenko > --- > include/ns16550.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 4/7] serial: ns16550: Read reg-io-width from device tree
On Tue, 20 Nov 2018 at 14:52, Andy Shevchenko wrote: > > Cache the value of the reg-io-width property for the future use. > > Signed-off-by: Andy Shevchenko > --- > drivers/serial/ns16550.c | 1 + > include/ns16550.h| 2 ++ > 2 files changed, 3 insertions(+) Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 5/7] serial: ns16550: Provide ->getinfo() implementation
On Tue, 20 Nov 2018 at 14:52, Andy Shevchenko wrote: > > New callback will supply necessary information, for example, > to ACPI SPCR table. > > Signed-off-by: Andy Shevchenko > --- > drivers/serial/ns16550.c | 20 > 1 file changed, 20 insertions(+) Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] usb: musb-new: sunxi: Fix null pointer access
On 12/05/2018 01:49 PM, Stefan Mavrodiev wrote:
> When the device is in peripheral mode
Can you have two devices, one in peripheral mode and one in host mode,
on the same system ?
> there is no
> struct usb_bus_priv allocated pointer, as the uclass driver
> ("usb_dev_generic") doesn't call per_device_auto_alloc_size.
>
> This results in writing to the internal SDRAM at
> priv->desc_before_addr = true;
>
> Signed-off-by: Stefan Mavrodiev
> ---
> drivers/usb/musb-new/sunxi.c | 8 ++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/usb/musb-new/sunxi.c b/drivers/usb/musb-new/sunxi.c
> index 6cf9826cda..f3deb9bc66 100644
> --- a/drivers/usb/musb-new/sunxi.c
> +++ b/drivers/usb/musb-new/sunxi.c
> @@ -435,11 +435,14 @@ static int musb_usb_probe(struct udevice *dev)
> {
> struct sunxi_glue *glue = dev_get_priv(dev);
> struct musb_host_data *host = &glue->mdata;
> - struct usb_bus_priv *priv = dev_get_uclass_priv(dev);
> struct musb_hdrc_platform_data pdata;
> void *base = dev_read_addr_ptr(dev);
> int ret;
>
> +#ifdef CONFIG_USB_MUSB_HOST
> + struct usb_bus_priv *priv = dev_get_uclass_priv(dev);
> +#endif
> +
> if (!base)
> return -EINVAL;
>
> @@ -459,7 +462,6 @@ static int musb_usb_probe(struct udevice *dev)
> return ret;
> }
>
> - priv->desc_before_addr = true;
See my question at the beginning, and if that can be the case, the fix
is to check if priv is not null here, eg.
if (priv)
priv->...
Still, why is the priv data not allocated for device ?
> memset(&pdata, 0, sizeof(pdata));
> pdata.power = 250;
> @@ -467,6 +469,8 @@ static int musb_usb_probe(struct udevice *dev)
> pdata.config = glue->cfg->config;
>
> #ifdef CONFIG_USB_MUSB_HOST
> + priv->desc_before_addr = true;
> +
> pdata.mode = MUSB_HOST;
> host->host = musb_init_controller(&pdata, &glue->dev, base);
> if (!host->host)
>
--
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] usb: musb-new: sunxi: Fix null pointer access
On 12/5/18 2:57 PM, Marek Vasut wrote:
On 12/05/2018 01:49 PM, Stefan Mavrodiev wrote:
When the device is in peripheral mode
Can you have two devices, one in peripheral mode and one in host mode,
on the same system ?
Not 100% sure, but I'm thinking there is only one OTG port for
all sunxi boards. The operation is decided in the Kconfig.
there is no
struct usb_bus_priv allocated pointer, as the uclass driver
("usb_dev_generic") doesn't call per_device_auto_alloc_size.
This results in writing to the internal SDRAM at
priv->desc_before_addr = true;
Signed-off-by: Stefan Mavrodiev
---
drivers/usb/musb-new/sunxi.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/musb-new/sunxi.c b/drivers/usb/musb-new/sunxi.c
index 6cf9826cda..f3deb9bc66 100644
--- a/drivers/usb/musb-new/sunxi.c
+++ b/drivers/usb/musb-new/sunxi.c
@@ -435,11 +435,14 @@ static int musb_usb_probe(struct udevice *dev)
{
struct sunxi_glue *glue = dev_get_priv(dev);
struct musb_host_data *host = &glue->mdata;
- struct usb_bus_priv *priv = dev_get_uclass_priv(dev);
struct musb_hdrc_platform_data pdata;
void *base = dev_read_addr_ptr(dev);
int ret;
+#ifdef CONFIG_USB_MUSB_HOST
+ struct usb_bus_priv *priv = dev_get_uclass_priv(dev);
+#endif
+
if (!base)
return -EINVAL;
@@ -459,7 +462,6 @@ static int musb_usb_probe(struct udevice *dev)
return ret;
}
- priv->desc_before_addr = true;
See my question at the beginning, and if that can be the case, the fix
is to check if priv is not null here, eg.
if (priv)
priv->...
Still, why is the priv data not allocated for device ?
Depending on configuration, the device is registered ether as
UCLASS_USB_DEV_GENERIC or UCLASS_USB. There is no
.per_device_auto_alloc_size = sizeof(struct usb_bus_priv),
for the second. (As seen in drivers/usb/host/usb-uclass.c)
memset(&pdata, 0, sizeof(pdata));
pdata.power = 250;
@@ -467,6 +469,8 @@ static int musb_usb_probe(struct udevice *dev)
pdata.config = glue->cfg->config;
#ifdef CONFIG_USB_MUSB_HOST
+ priv->desc_before_addr = true;
+
pdata.mode = MUSB_HOST;
host->host = musb_init_controller(&pdata, &glue->dev, base);
if (!host->host)
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] network not work with u-boot
Hi all, Recently I came across a problem, and I tried many things but it still does not work. I have a board with a u-boot ready and the kernel image yet to upload. Unfortunately the board could not get the kernel image by ftp. The kernel image was built ready and the ftp server was running in my WIN 10 desktop, whose IP Addr is 172.16.0.10/255.255.0.0, accordingly, the board was configured as IP Addr to be 172.16.0.100/255.255.0.0. This was what I get: No progress could be made and stuck there. So I used the Wireshark to record what was going on from my desktop, and it showed me that: Destination unreachable (Port unreachable) I thought it was the uImage file missing, but it turned out that it was definitely there: I downloaded the uImage file by chrome browser on ftp://172.16.0.10/ At last, I checked the u-boot configurations and I found a strange thing, as shown below: The configuration item ipaddr1 could be introduced by misspelling, I guess this also happens sometime for everyone here. But strange enough that it could not be deleted, I tried "setenv ipaddr1", "setenv ipaddr1 72.16.0.100", and the item ipaddr1 was still there. What is the root cause for the failure of ftp operation? does it have something to do with the strange configuration item ipaddr1? Any information or suggestion is highly appreciated. -- Best wishes. Zhangguofu (Gary)___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] pcm058: fix NAND flash not using badblock table
Without setting this flag, U-Boot will silently use a memory only badblock table. This is not only bad because it means badblock info is ignored, but also leads to other issues if a driver ontop then tries to read the badblock table as filesystem info (eg. UBI). Signed-off-by: Harald Seiler --- include/configs/pcm058.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/configs/pcm058.h b/include/configs/pcm058.h index 49048c163f..b9bc08b388 100644 --- a/include/configs/pcm058.h +++ b/include/configs/pcm058.h @@ -55,6 +55,7 @@ #define CONFIG_SYS_NAND_BASE 0x4000 #define CONFIG_SYS_NAND_5_ADDR_CYCLE #define CONFIG_SYS_NAND_ONFI_DETECTION +#define CONFIG_SYS_NAND_USE_FLASH_BBT #endif /* DMA stuff, needed for GPMI/MXS NAND support */ -- 2.17.2 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] usb: musb-new: sunxi: Fix null pointer access
On Wed, Dec 05, 2018 at 01:57:14PM +0100, Marek Vasut wrote: > On 12/05/2018 01:49 PM, Stefan Mavrodiev wrote: > > When the device is in peripheral mode > > Can you have two devices, one in peripheral mode and one in host mode, > on the same system ? No, or at least, on all of the SoCs that Allwinner ever produced, there's only a single musb controller. Maxime -- Maxime Ripard, Bootlin Embedded Linux and Kernel engineering https://bootlin.com 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 v3 0/8] Fix CVE-2018-18440 and CVE-2018-18439
Hi Simon,
On Tue, 4 Dec 2018 at 04:54, Simon Goldschmidt
wrote:
>
> On Tue, Dec 4, 2018 at 12:45 AM Simon Glass wrote:
> >
> > Hi Simon,
> >
> > On Mon, 3 Dec 2018 at 12:05, Simon Goldschmidt
> > wrote:
> > >
> > >
> > >
> > > Am Mo., 3. Dez. 2018, 19:20 hat Simon Glass
> > > geschrieben:
> > >>
> > >> Hi Simon,
> > >>
> > >> On Mon, 3 Dec 2018 at 00:50, Simon Goldschmidt
> > >> wrote:
> > >> >
> > >> > Simon,
> > >> >
> > >> > On Tue, Nov 27, 2018 at 6:45 AM Simon Goldschmidt
> > >> > wrote:
> > >> > >
> > >> > > On Tue, Nov 27, 2018 at 2:02 AM Simon Glass
> > >> > > wrote:
> > >> > > >
> > >> > > > Hi Simon,
> > >> > > >
> > >> > > > On Sat, 17 Nov 2018 at 05:25, Simon Goldschmidt
> > >> > > > wrote:
> > >> > > > >
> > >> > > > > This series fixes CVE-2018-18440 ("insufficient boundary checks
> > >> > > > > in
> > >> > > > > filesystem image load") by adding restrictions to the 'load'
> > >> > > > > command and fixes CVE-2018-18439 ("insufficient boundary checks
> > >> > > > > in
> > >> > > > > network image boot") by adding restrictions to the tftp code.
> > >> > > > >
> > >> > > > > The functions from lmb.c are used to setup regions of allowed and
> > >> > > > > reserved memory. Then, the file size to load is checked against
> > >> > > > > these
> > >> > > > > addresses and loading the file is aborted if it would overwrite
> > >> > > > > reserved memory.
> > >> > > > >
> > >> > > > > The memory reservation code is reused from bootm/image.
> > >> > > > >
> > >> > > > > Changes in v3:
> > >> > > > > - No patch changes, but needed to resend since patman added too
> > >> > > > > many cc
> > >> > > > > addresses that gmail seemed to detect as spam :-(
> > >> > > > >
> > >> > > > > Changes in v2:
> > >> > > > > - added code to reserve devicetree reserved-memory in lmb
> > >> > > > > - added tftp fixes (patches 7 and 8)
> > >> > > > > - fixed a bug in new function lmb_alloc_addr
> > >> > > > >
> > >> > > > > Simon Goldschmidt (8):
> > >> > > > > lib: lmb: reserving overlapping regions should fail
> > >> > > > > fdt: parse "reserved-memory" for memory reservation
> > >> > > > > lib: lmb: extend lmb for checks at load time
> > >> > > > > fs: prevent overwriting reserved memory
> > >> > > > > bootm: use new common function lmb_init_and_reserve
> > >> > > > > lmb: remove unused extern declaration
> > >> > > > > net: remove CONFIG_MCAST_TFTP
> > >> > > > > tftp: prevent overwriting reserved memory
> > >> > > > >
> > >> > > > > README | 9 --
> > >> > > > > common/bootm.c | 8 +-
> > >> > > > > common/image-fdt.c | 52 ++-
> > >> > > > > drivers/net/rtl8139.c| 9 --
> > >> > > > > drivers/net/tsec.c | 52 ---
> > >> > > > > drivers/usb/gadget/ether.c | 3 -
> > >> > > > > fs/fs.c | 56 ++-
> > >> > > > > include/lmb.h| 7 +-
> > >> > > > > include/net.h| 17 ---
> > >> > > > > lib/lmb.c| 69 +
> > >> > > > > net/eth-uclass.c | 4 -
> > >> > > > > net/eth_legacy.c | 46 --
> > >> > > > > net/net.c| 9 +-
> > >> > > > > net/tftp.c | 289
> > >> > > > > +++
> > >> > > > > scripts/config_whitelist.txt | 1 -
> > >> > > > > 15 files changed, 232 insertions(+), 399 deletions(-)
> > >> > > >
> > >> > > > This is great work, but what is missing is a test for lmb.
> > >> > >
> > >> > > Yeah, well, the tests didn't work on my system and I figured it's
> > >> > > better to get the code fixed than to use my time on trying to get the
> > >> > > tests running.
> > >> > >
> > >> > > However, after searching for the required packages and fiddling
> > >> > > around
> > >> > > some more, I guess I made them work so I could add tests now...
> > >> > >
> > >> > > I also have work-in-progress for compressing fit image contents (we
> > >> > > currently only support uncompressing the kernel). It will switch some
> > >> > > 'lmb_reserve' calls to the new 'lmb_alloc_addr' as this is more safe.
> > >> > > Maybe I can combine the tests in that series?
> > >> >
> > >> > After managing to get the tests to run via 'make qcheck' (and 'make
> > >> > tests'; had to install much more than listed in 'test/py/README.md'),
> > >> > I tried to add tests to 'test/lib/' (next to hexdump.c), but I failed
> > >> > to get them run. Even chaning 'test/lib/hexdump.c' to fail did not
> > >> > produce errors. Are these tests not included in 'make qcheck'?
> > >>
> > >> That runs the Python tests which are in test/py/tests. Some of those
> > >> tests run compiled-in code (e.g. log_test.c and cmd_ut.c). Is your
> > >> test intended to be Python or C?
> > >
> > >
> > > I thought I'd create a unit test under test/lib that calls functions from
> > > lmb.c, so that would be C code. Python would not work without adding
> > > extra commands to call from Pyth
Re: [U-Boot] [PATCH v3 0/8] Fix CVE-2018-18440 and CVE-2018-18439
On Wed, Dec 5, 2018 at 2:13 PM Simon Glass wrote:
>
> Hi Simon,
>
> On Tue, 4 Dec 2018 at 04:54, Simon Goldschmidt
> wrote:
> >
> > On Tue, Dec 4, 2018 at 12:45 AM Simon Glass wrote:
> > >
> > > Hi Simon,
> > >
> > > On Mon, 3 Dec 2018 at 12:05, Simon Goldschmidt
> > > wrote:
> > > >
> > > >
> > > >
> > > > Am Mo., 3. Dez. 2018, 19:20 hat Simon Glass
> > > > geschrieben:
> > > >>
> > > >> Hi Simon,
> > > >>
> > > >> On Mon, 3 Dec 2018 at 00:50, Simon Goldschmidt
> > > >> wrote:
> > > >> >
> > > >> > Simon,
> > > >> >
> > > >> > On Tue, Nov 27, 2018 at 6:45 AM Simon Goldschmidt
> > > >> > wrote:
> > > >> > >
> > > >> > > On Tue, Nov 27, 2018 at 2:02 AM Simon Glass
> > > >> > > wrote:
> > > >> > > >
> > > >> > > > Hi Simon,
> > > >> > > >
> > > >> > > > On Sat, 17 Nov 2018 at 05:25, Simon Goldschmidt
> > > >> > > > wrote:
> > > >> > > > >
> > > >> > > > > This series fixes CVE-2018-18440 ("insufficient boundary
> > > >> > > > > checks in
> > > >> > > > > filesystem image load") by adding restrictions to the 'load'
> > > >> > > > > command and fixes CVE-2018-18439 ("insufficient boundary
> > > >> > > > > checks in
> > > >> > > > > network image boot") by adding restrictions to the tftp code.
> > > >> > > > >
> > > >> > > > > The functions from lmb.c are used to setup regions of allowed
> > > >> > > > > and
> > > >> > > > > reserved memory. Then, the file size to load is checked
> > > >> > > > > against these
> > > >> > > > > addresses and loading the file is aborted if it would overwrite
> > > >> > > > > reserved memory.
> > > >> > > > >
> > > >> > > > > The memory reservation code is reused from bootm/image.
> > > >> > > > >
> > > >> > > > > Changes in v3:
> > > >> > > > > - No patch changes, but needed to resend since patman added
> > > >> > > > > too many cc
> > > >> > > > > addresses that gmail seemed to detect as spam :-(
> > > >> > > > >
> > > >> > > > > Changes in v2:
> > > >> > > > > - added code to reserve devicetree reserved-memory in lmb
> > > >> > > > > - added tftp fixes (patches 7 and 8)
> > > >> > > > > - fixed a bug in new function lmb_alloc_addr
> > > >> > > > >
> > > >> > > > > Simon Goldschmidt (8):
> > > >> > > > > lib: lmb: reserving overlapping regions should fail
> > > >> > > > > fdt: parse "reserved-memory" for memory reservation
> > > >> > > > > lib: lmb: extend lmb for checks at load time
> > > >> > > > > fs: prevent overwriting reserved memory
> > > >> > > > > bootm: use new common function lmb_init_and_reserve
> > > >> > > > > lmb: remove unused extern declaration
> > > >> > > > > net: remove CONFIG_MCAST_TFTP
> > > >> > > > > tftp: prevent overwriting reserved memory
> > > >> > > > >
> > > >> > > > > README | 9 --
> > > >> > > > > common/bootm.c | 8 +-
> > > >> > > > > common/image-fdt.c | 52 ++-
> > > >> > > > > drivers/net/rtl8139.c| 9 --
> > > >> > > > > drivers/net/tsec.c | 52 ---
> > > >> > > > > drivers/usb/gadget/ether.c | 3 -
> > > >> > > > > fs/fs.c | 56 ++-
> > > >> > > > > include/lmb.h| 7 +-
> > > >> > > > > include/net.h| 17 ---
> > > >> > > > > lib/lmb.c| 69 +
> > > >> > > > > net/eth-uclass.c | 4 -
> > > >> > > > > net/eth_legacy.c | 46 --
> > > >> > > > > net/net.c| 9 +-
> > > >> > > > > net/tftp.c | 289
> > > >> > > > > +++
> > > >> > > > > scripts/config_whitelist.txt | 1 -
> > > >> > > > > 15 files changed, 232 insertions(+), 399 deletions(-)
> > > >> > > >
> > > >> > > > This is great work, but what is missing is a test for lmb.
> > > >> > >
> > > >> > > Yeah, well, the tests didn't work on my system and I figured it's
> > > >> > > better to get the code fixed than to use my time on trying to get
> > > >> > > the
> > > >> > > tests running.
> > > >> > >
> > > >> > > However, after searching for the required packages and fiddling
> > > >> > > around
> > > >> > > some more, I guess I made them work so I could add tests now...
> > > >> > >
> > > >> > > I also have work-in-progress for compressing fit image contents (we
> > > >> > > currently only support uncompressing the kernel). It will switch
> > > >> > > some
> > > >> > > 'lmb_reserve' calls to the new 'lmb_alloc_addr' as this is more
> > > >> > > safe.
> > > >> > > Maybe I can combine the tests in that series?
> > > >> >
> > > >> > After managing to get the tests to run via 'make qcheck' (and 'make
> > > >> > tests'; had to install much more than listed in 'test/py/README.md'),
> > > >> > I tried to add tests to 'test/lib/' (next to hexdump.c), but I failed
> > > >> > to get them run. Even chaning 'test/lib/hexdump.c' to fail did not
> > > >> > produce errors. Are these tests not included in 'make qcheck'?
> > > >>
> > > >> That runs the Python tests which are in test/py/tests. Som
Re: [U-Boot] [PATCH 1/1] usb: musb-new: sunxi: Fix null pointer access
On 12/05/2018 02:06 PM, Stefan Mavrodiev wrote:
>
> On 12/5/18 2:57 PM, Marek Vasut wrote:
>> On 12/05/2018 01:49 PM, Stefan Mavrodiev wrote:
>>> When the device is in peripheral mode
>> Can you have two devices, one in peripheral mode and one in host mode,
>> on the same system ?
>
> Not 100% sure, but I'm thinking there is only one OTG port for
> all sunxi boards. The operation is decided in the Kconfig.
I'm rather sure I saw sunxi boards with more than one USB port.
>>> there is no
>>> struct usb_bus_priv allocated pointer, as the uclass driver
>>> ("usb_dev_generic") doesn't call per_device_auto_alloc_size.
>>>
>>> This results in writing to the internal SDRAM at
>>> priv->desc_before_addr = true;
>>>
>>> Signed-off-by: Stefan Mavrodiev
>>> ---
>>> drivers/usb/musb-new/sunxi.c | 8 ++--
>>> 1 file changed, 6 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/usb/musb-new/sunxi.c b/drivers/usb/musb-new/sunxi.c
>>> index 6cf9826cda..f3deb9bc66 100644
>>> --- a/drivers/usb/musb-new/sunxi.c
>>> +++ b/drivers/usb/musb-new/sunxi.c
>>> @@ -435,11 +435,14 @@ static int musb_usb_probe(struct udevice *dev)
>>> {
>>> struct sunxi_glue *glue = dev_get_priv(dev);
>>> struct musb_host_data *host = &glue->mdata;
>>> - struct usb_bus_priv *priv = dev_get_uclass_priv(dev);
>>> struct musb_hdrc_platform_data pdata;
>>> void *base = dev_read_addr_ptr(dev);
>>> int ret;
>>> +#ifdef CONFIG_USB_MUSB_HOST
>>> + struct usb_bus_priv *priv = dev_get_uclass_priv(dev);
>>> +#endif
>>> +
>>> if (!base)
>>> return -EINVAL;
>>> @@ -459,7 +462,6 @@ static int musb_usb_probe(struct udevice *dev)
>>> return ret;
>>> }
>>> - priv->desc_before_addr = true;
>> See my question at the beginning, and if that can be the case, the fix
>> is to check if priv is not null here, eg.
>> if (priv)
>> priv->...
>>
>> Still, why is the priv data not allocated for device ?
>
> Depending on configuration, the device is registered ether as
> UCLASS_USB_DEV_GENERIC or UCLASS_USB. There is no
>
> .per_device_auto_alloc_size = sizeof(struct usb_bus_priv),
>
> for the second. (As seen in drivers/usb/host/usb-uclass.c)
I see the code is rather horrible. I'd expect all that configuration to
come from DT otg-mode property instead of being hard-wired into the
code. Sigh.
Jagan, A-B ? I'd like to pick this .
>>
>>> memset(&pdata, 0, sizeof(pdata));
>>> pdata.power = 250;
>>> @@ -467,6 +469,8 @@ static int musb_usb_probe(struct udevice *dev)
>>> pdata.config = glue->cfg->config;
>>> #ifdef CONFIG_USB_MUSB_HOST
>>> + priv->desc_before_addr = true;
>>> +
>>> pdata.mode = MUSB_HOST;
>>> host->host = musb_init_controller(&pdata, &glue->dev, base);
>>> if (!host->host)
>>>
>>
--
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 66/93] arm: Remove ot1200 board
Hi Simon, On Sun, 25 Nov 2018 at 23:05, Simon Goldschmidt wrote: > > [I've cut down the CC list a bit due to some gmail warnings] > On Mon, Nov 26, 2018 at 4:00 AM Simon Glass wrote: > > > > Hi Simon, > > > > On Sun, 25 Nov 2018 at 14:09, Simon Goldschmidt > > wrote: > > > > > > On Thu, Nov 22, 2018 at 9:50 PM Simon Glass wrote: > > > > > > > > Hi, > > > > > > > > On Thu, 22 Nov 2018 at 10:02, Tom Rini wrote: > > > > > > > > > > On Thu, Nov 22, 2018 at 03:44:28PM +0100, Simon Goldschmidt wrote: > > > > > > Am Do., 22. Nov. 2018, 14:44 hat Tom Rini > > > > > > geschrieben: > > > > > > > > > > > > > On Thu, Nov 22, 2018 at 02:24:49PM +0100, Marek Vasut wrote: > > > > > > > > On 11/22/2018 01:52 PM, Tom Rini wrote: > > > > > > > > > On Thu, Nov 22, 2018 at 10:25:14AM +0100, Christian Gmeiner > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > >> Am Mo., 19. Nov. 2018 um 16:56 Uhr schrieb Simon Glass < > > > > > > > s...@chromium.org>: > > > > > > > > >>> > > > > > > > > >>> This board has not been converted to CONFIG_DM_BLK by the > > > > > > > > >>> deadline. > > > > > > > > >>> Remove it. > > > > > > > > >>> > > > > > > > > >> > > > > > > > > >> As the board is still mainted I will NAK it for the moment. > > > > > > > > >> Are there > > > > > > > > >> any hints want needs to be done > > > > > > > > >> to port thie board over to new DM stuff? > > > > > > > > > > > > > > > > > > Yes, as a start you need to switch over to using > > > > > > > > > CONFIG_OF_CONTROL and > > > > > > > > > selecting/providing a dtb file. I see ot1200 is using > > > > > > > > > DWC_AHSATA which > > > > > > > > > needs more work, but this is the board-level work that needs > > > > > > > > > doing. > > > > > > > > > > > > > > > > Wasn't there a possibility to use platform data in board file > > > > > > > > instead of > > > > > > > > DT ? Or is DT mandatory now , including the libfdt overhead ? > > > > > > > > > > > > > > In short, DT for U-Boot and platform data for SPL is what's > > > > > > > recommended, > > > > > > > yes. > > > > > > > > > > > > > > > > > > > This is a little confusing for me. Socfpga gen5 SPL doesn't do > > > > > > that. And it > > > > > > seems a little strange or outdated overall. > > > > > > > > > > > > Would there be some kind of reference architecture or mach to look > > > > > > at > > > > > > what's the suggested/up-to-date way to implement SPL? Also > > > > > > regarding code > > > > > > flow? > > > > > > > > > > So, SPL is where things get, ahem, fuzzy. While I don't want to > > > > > encourage boundless growth in U-Boot proper, we aren't exactly size > > > > > constrained (but rather, functional/logical constrained). But in SPL, > > > > > yes, we have many platforms with 32/64/128 kilobyte hard limits (and > > > > > some smaller) and we can't always shove in a "TPL" before SPL either. > > > > > So in SPL we do make use of platform data instead. While not the > > > > > smallest size constraint, am335x_hs_evm is a reasonable thing to look > > > > > at > > > > > in this case. > > > > > > > > Also 'rock' uses CONFIG_OF_PLATDATA which provides a halfway house - > > > > still uses DT, but it gets converted into C structs so saves code > > > > space. > > > > > > > > firefly-rk3288 is a pretty good DM/DT example, including SPL. > > > > > > I've currently got an issue on socfpga gen5 that could be solved best > > > by enabling CONFIG_OF_EMBED (mixing const and non-const sections is a > > > problem for CRC calculation). However, it could probably also solve by > > > using platform data (but that doesn't work out of the box, yet). The > > > problem with CONFIG_OF_EMBED is that I think it's OK to enable this > > > for SPL but I don't like enabling it for U-Boot, so: > > > > > > Would it make sense to duplicate the whole "Provider of DTB for OF > > > control" choice so that it can be OF_EMBED for SPL but different for > > > U-Boot? Or does it make more sense to convert socfpga gen5 to use > > > OF_PLATDATA? > > > > We should not be using OF_EMBED in in-tree boards or production code. > > What's the reason for this? I can understand this for U-Boot, and I > can understand that it's at least theoretically a bit cleaner for SPL, > too. But there are some drawbacks when doing this in SPL where code is > not relocated: > - you lose the ability to check total size in linker file (which is > bad for size-constrained platforms: sometimes you notice failure only > when booting) You can add an SPL size check in Makefile.spl if you like. > - you get an inconsistent memory layout regarding read/write: the > linker places bss at the end but then, DTB follows as const data This should be handled by the $(SPL-BIN)-pad.bin file (or by binman if you are using that). > - binary size "on disk" grows due to this inconsistent memory layout > (since the flat binary includes the DTB, it needs to include the > zeroed-out bss, too) Right, but this is a few bytes. Why does it matter? > - "spl/u-boot-spl.hex
[U-Boot] [PATCH] blk: Rework guard around part_init call
The function part_init() will only be built when we have both CONFIG_PARTITIONS and CONFIG_HAVE_BLOCK_DEVICE set. Protect the call to this function with both of these tests now. Cc: Simon Glass Cc: Philipp Tomsich Cc: Michal Simek Cc: York Sun Cc: Prabhakar Kushwaha Cc: Mingkai Hu Cc: Stefan Roese Cc: Marek Behún Cc: Vanessa Maegima Cc: Eugen Hristev Cc: Adam Ford Cc: Jagan Teki Cc: Tom Warren Cc: Stephen Warren Cc: Vitaly Andrianov Signed-off-by: Tom Rini --- Changes in v2: - rockchip: evb-rk3036 and kylin-rk3036 are both targets that do not use CONFIG_SPL_FRAMEWORK but also do not fall into the legacy PowerPC SPL case. In order to avoid fail to builds on these platforms they must now turn off CONFIG_SPL_BLK, which they weren't using before, it was being discarded at link time. - Re-work common/spl/Kconfig and then various Makefiles to slightly clear up the logic of when we do and don't need both disk/part.o and drivers/block/blk-uclass.o. This is in fact not the greatest but it's all I could come up with to cover all the cases we have today. - Because of the above, add a note to the CONFIG_BLK migration to note that once we are complete there we need to revisit the symbols I used above as once that migration is done we should be able to rely on just BLK and maybe PARTITIONS. - Actually build-test the world and confirm the overall results are fairly sane. This results in pushing a few platforms that are using SPL and DM into using SPL_BLK now. - This also results in a number of 64bit rockchip, nxp and zynqmp platforms that have been enabling CONFIG_SPL_DOS_PARTITION / CONFIG_SPL_ISO_PARTITION now linking it. - On the 32bit ARM side, some Marvell, i.MX, ateml, TI, Tegra, zynq and rockchip platforms do the same. The full build log can be seen at: https://gist.github.com/trini/e3e73afec629bbda2625102120c2a9db --- common/spl/Kconfig | 3 +++ configs/evb-rk3036_defconfig | 1 + configs/kylin-rk3036_defconfig | 1 + doc/driver-model/MIGRATION.txt | 4 +++- drivers/Makefile | 3 +-- drivers/block/Makefile | 2 ++ drivers/block/blk-uclass.c | 2 +- scripts/Makefile.spl | 4 +++- 8 files changed, 15 insertions(+), 5 deletions(-) diff --git a/common/spl/Kconfig b/common/spl/Kconfig index 0ddbffc7d1c6..cab7220c9ace 100644 --- a/common/spl/Kconfig +++ b/common/spl/Kconfig @@ -449,6 +449,7 @@ config SPL_LIBCOMMON_SUPPORT config SPL_LIBDISK_SUPPORT bool "Support disk partitions" + select PARTITIONS help Enable support for disk partitions within SPL. 'Disk' is something of a misnomer as it includes non-spinning media such as flash (as @@ -480,6 +481,7 @@ config SPL_DM_MAILBOX config SPL_MMC_SUPPORT bool "Support MMC" depends on MMC + select HAVE_BLOCK_DEVICE help Enable support for MMC (Multimedia Card) within SPL. This enables the MMC protocol implementation and allows any enabled drivers to @@ -754,6 +756,7 @@ config SPL_THERMAL config SPL_USB_HOST_SUPPORT bool "Support USB host drivers" + select HAVE_BLOCK_DEVICE help Enable access to USB (Universal Serial Bus) host devices so that SPL can load U-Boot from a connected USB peripheral, such as a USB diff --git a/configs/evb-rk3036_defconfig b/configs/evb-rk3036_defconfig index 787d6f95c1bb..439e69138636 100644 --- a/configs/evb-rk3036_defconfig +++ b/configs/evb-rk3036_defconfig @@ -32,6 +32,7 @@ CONFIG_SPL_PARTITION_UUIDS=y CONFIG_DEFAULT_DEVICE_TREE="rk3036-sdk" CONFIG_REGMAP=y CONFIG_SYSCON=y +# CONFIG_SPL_BLK is not set CONFIG_CLK=y CONFIG_FASTBOOT_FLASH=y CONFIG_FASTBOOT_FLASH_MMC_DEV=0 diff --git a/configs/kylin-rk3036_defconfig b/configs/kylin-rk3036_defconfig index eb305e02aaa5..765003095ca1 100644 --- a/configs/kylin-rk3036_defconfig +++ b/configs/kylin-rk3036_defconfig @@ -30,6 +30,7 @@ CONFIG_DEFAULT_DEVICE_TREE="rk3036-sdk" CONFIG_ENV_IS_IN_MMC=y CONFIG_REGMAP=y CONFIG_SYSCON=y +# CONFIG_SPL_BLK is not set CONFIG_CLK=y CONFIG_FASTBOOT_FLASH=y CONFIG_FASTBOOT_FLASH_MMC_DEV=0 diff --git a/doc/driver-model/MIGRATION.txt b/doc/driver-model/MIGRATION.txt index 6b691338b4e7..dce4aa3e1dc9 100644 --- a/doc/driver-model/MIGRATION.txt +++ b/doc/driver-model/MIGRATION.txt @@ -44,7 +44,9 @@ Deadline: 2019.07 In concert with maintainers migrating their block device usage to the appropriate DM driver, CONFIG_BLK needs to be set as well. The final deadline here coincides with the final deadline for migration of the various block -subsystems. +subsystems. At this point we will be able to audit and correct the logic in +Kconfig around using CONFIG_PARTITIONS and CONFIG_HAVE_BLOCK_DEVICE and make +use of CONFIG_BLK / CONFIG_SPL_BLK as needed. CONFIG_DM_SPI CONFIG_DM_SPI_FLASH diff --git a/drivers/Makefile b/drivers/Makefile index 55de10926ef4..388d93a069e4 100644 --- a/drivers/Makefile +++ b/drivers/Makefile @@ -5
Re: [U-Boot] [ANN] U-Boot v2019.01-rc1 released
On Tue, Dec 04, 2018 at 04:06:49PM +0800, Kever Yang wrote: > Hi, > > Any one get any idea about below error? I'm using > evb-rk3229_defconfig and gcc-linaro-6.3.1-2017.05. > > LD u-boot > fs/built-in.o: In function `set_contents': > /home/kever/src/u-boot/fs/fat/fat_write.c:831: undefined reference to > `__aeabi_ldivmod' > /home/kever/src/prebuilts/gcc/linux-x86/arm/gcc-linaro-6.3.1-2017.05-x86_64_arm-linux-gnueabihf/bin/arm-linux-gnueabihf-ld.bfd: > BFD (Linaro_Binutils-2017.05) 2.27.0.20161019 assertion fail > /home/tcwg-buildslave/workspace/tcwg-make-release/builder_arch/amd64/label/tcwg-x86_64-build/target/arm-linux-gnueabihf/snapshots/binutils-gdb.git~linaro-local~linaro_binutils-2_27-branch/bfd/elf32-arm.c:8784 > make: *** [u-boot] Error 1 Please 'git bisect' this down to a specific commit (since it's a build failure, you can 'git bisect run make O=/tmp/ CROSS_COMPILE=...' and wait a few minutes at least). I suspect we have a place that needs do_div(). -- 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] network not work with u-boot
Dear 张国富, In message <3ddf0dcd.d340.1677de6d85a.coremail.cleanc...@163.com> you wrote: > > Recently I came across a problem, and I tried many things but it still > does not work. > I have a board with a u-boot ready and the kernel image yet to upload. > Unfortunately the board could not get the kernel image by ftp. If what you write is correct, then this is expected behaviour. U-Boot does not have support for TCP/IP, and so it cannot implement the FTP protocol. All we have is TFTP = TRIVIAL FTP. You your FTP server will not help - you need a TFTP server instead. This also explains the port mismatch you see in wireshark. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de One difference between a man and a machine is that a machine is quiet when well oiled. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 66/93] arm: Remove ot1200 board
On Wed, Dec 5, 2018 at 2:21 PM Simon Glass wrote: > > Hi Simon, > > On Sun, 25 Nov 2018 at 23:05, Simon Goldschmidt > wrote: > > > > [I've cut down the CC list a bit due to some gmail warnings] > > On Mon, Nov 26, 2018 at 4:00 AM Simon Glass wrote: > > > > > > Hi Simon, > > > > > > On Sun, 25 Nov 2018 at 14:09, Simon Goldschmidt > > > wrote: > > > > > > > > On Thu, Nov 22, 2018 at 9:50 PM Simon Glass wrote: > > > > > > > > > > Hi, > > > > > > > > > > On Thu, 22 Nov 2018 at 10:02, Tom Rini wrote: > > > > > > > > > > > > On Thu, Nov 22, 2018 at 03:44:28PM +0100, Simon Goldschmidt wrote: > > > > > > > Am Do., 22. Nov. 2018, 14:44 hat Tom Rini > > > > > > > geschrieben: > > > > > > > > > > > > > > > On Thu, Nov 22, 2018 at 02:24:49PM +0100, Marek Vasut wrote: > > > > > > > > > On 11/22/2018 01:52 PM, Tom Rini wrote: > > > > > > > > > > On Thu, Nov 22, 2018 at 10:25:14AM +0100, Christian Gmeiner > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > >> Am Mo., 19. Nov. 2018 um 16:56 Uhr schrieb Simon Glass < > > > > > > > > s...@chromium.org>: > > > > > > > > > >>> > > > > > > > > > >>> This board has not been converted to CONFIG_DM_BLK by the > > > > > > > > > >>> deadline. > > > > > > > > > >>> Remove it. > > > > > > > > > >>> > > > > > > > > > >> > > > > > > > > > >> As the board is still mainted I will NAK it for the > > > > > > > > > >> moment. Are there > > > > > > > > > >> any hints want needs to be done > > > > > > > > > >> to port thie board over to new DM stuff? > > > > > > > > > > > > > > > > > > > > Yes, as a start you need to switch over to using > > > > > > > > > > CONFIG_OF_CONTROL and > > > > > > > > > > selecting/providing a dtb file. I see ot1200 is using > > > > > > > > > > DWC_AHSATA which > > > > > > > > > > needs more work, but this is the board-level work that > > > > > > > > > > needs doing. > > > > > > > > > > > > > > > > > > Wasn't there a possibility to use platform data in board file > > > > > > > > > instead of > > > > > > > > > DT ? Or is DT mandatory now , including the libfdt overhead ? > > > > > > > > > > > > > > > > In short, DT for U-Boot and platform data for SPL is what's > > > > > > > > recommended, > > > > > > > > yes. > > > > > > > > > > > > > > > > > > > > > > This is a little confusing for me. Socfpga gen5 SPL doesn't do > > > > > > > that. And it > > > > > > > seems a little strange or outdated overall. > > > > > > > > > > > > > > Would there be some kind of reference architecture or mach to > > > > > > > look at > > > > > > > what's the suggested/up-to-date way to implement SPL? Also > > > > > > > regarding code > > > > > > > flow? > > > > > > > > > > > > So, SPL is where things get, ahem, fuzzy. While I don't want to > > > > > > encourage boundless growth in U-Boot proper, we aren't exactly size > > > > > > constrained (but rather, functional/logical constrained). But in > > > > > > SPL, > > > > > > yes, we have many platforms with 32/64/128 kilobyte hard limits (and > > > > > > some smaller) and we can't always shove in a "TPL" before SPL > > > > > > either. > > > > > > So in SPL we do make use of platform data instead. While not the > > > > > > smallest size constraint, am335x_hs_evm is a reasonable thing to > > > > > > look at > > > > > > in this case. > > > > > > > > > > Also 'rock' uses CONFIG_OF_PLATDATA which provides a halfway house - > > > > > still uses DT, but it gets converted into C structs so saves code > > > > > space. > > > > > > > > > > firefly-rk3288 is a pretty good DM/DT example, including SPL. > > > > > > > > I've currently got an issue on socfpga gen5 that could be solved best > > > > by enabling CONFIG_OF_EMBED (mixing const and non-const sections is a > > > > problem for CRC calculation). However, it could probably also solve by > > > > using platform data (but that doesn't work out of the box, yet). The > > > > problem with CONFIG_OF_EMBED is that I think it's OK to enable this > > > > for SPL but I don't like enabling it for U-Boot, so: > > > > > > > > Would it make sense to duplicate the whole "Provider of DTB for OF > > > > control" choice so that it can be OF_EMBED for SPL but different for > > > > U-Boot? Or does it make more sense to convert socfpga gen5 to use > > > > OF_PLATDATA? > > > > > > We should not be using OF_EMBED in in-tree boards or production code. > > > > What's the reason for this? I can understand this for U-Boot, and I > > can understand that it's at least theoretically a bit cleaner for SPL, > > too. But there are some drawbacks when doing this in SPL where code is > > not relocated: > > - you lose the ability to check total size in linker file (which is > > bad for size-constrained platforms: sometimes you notice failure only > > when booting) > > You can add an SPL size check in Makefile.spl if you like. That might be required, yes. > > - you get an inconsistent memory layout regarding read/write: the > > linker places bss at the end but then, DTB follows as const data > > This
Re: [U-Boot] [PATCH 66/93] arm: Remove ot1200 board
Hi Simon, On Wed, 5 Dec 2018 at 06:38, Simon Goldschmidt wrote: > > On Wed, Dec 5, 2018 at 2:21 PM Simon Glass wrote: > > > > Hi Simon, > > > > On Sun, 25 Nov 2018 at 23:05, Simon Goldschmidt > > wrote: > > > > > > [I've cut down the CC list a bit due to some gmail warnings] > > > On Mon, Nov 26, 2018 at 4:00 AM Simon Glass wrote: > > > > > > > > Hi Simon, > > > > > > > > On Sun, 25 Nov 2018 at 14:09, Simon Goldschmidt > > > > wrote: > > > > > > > > > > On Thu, Nov 22, 2018 at 9:50 PM Simon Glass wrote: > > > > > > > > > > > > Hi, > > > > > > > > > > > > On Thu, 22 Nov 2018 at 10:02, Tom Rini wrote: > > > > > > > > > > > > > > On Thu, Nov 22, 2018 at 03:44:28PM +0100, Simon Goldschmidt wrote: > > > > > > > > Am Do., 22. Nov. 2018, 14:44 hat Tom Rini > > > > > > > > geschrieben: > > > > > > > > > > > > > > > > > On Thu, Nov 22, 2018 at 02:24:49PM +0100, Marek Vasut wrote: > > > > > > > > > > On 11/22/2018 01:52 PM, Tom Rini wrote: > > > > > > > > > > > On Thu, Nov 22, 2018 at 10:25:14AM +0100, Christian > > > > > > > > > > > Gmeiner wrote: > > > > > > > > > > > > > > > > > > > > > >> Am Mo., 19. Nov. 2018 um 16:56 Uhr schrieb Simon Glass < > > > > > > > > > s...@chromium.org>: > > > > > > > > > > >>> > > > > > > > > > > >>> This board has not been converted to CONFIG_DM_BLK by > > > > > > > > > > >>> the deadline. > > > > > > > > > > >>> Remove it. > > > > > > > > > > >>> > > > > > > > > > > >> > > > > > > > > > > >> As the board is still mainted I will NAK it for the > > > > > > > > > > >> moment. Are there > > > > > > > > > > >> any hints want needs to be done > > > > > > > > > > >> to port thie board over to new DM stuff? > > > > > > > > > > > > > > > > > > > > > > Yes, as a start you need to switch over to using > > > > > > > > > > > CONFIG_OF_CONTROL and > > > > > > > > > > > selecting/providing a dtb file. I see ot1200 is using > > > > > > > > > > > DWC_AHSATA which > > > > > > > > > > > needs more work, but this is the board-level work that > > > > > > > > > > > needs doing. > > > > > > > > > > > > > > > > > > > > Wasn't there a possibility to use platform data in board > > > > > > > > > > file instead of > > > > > > > > > > DT ? Or is DT mandatory now , including the libfdt overhead > > > > > > > > > > ? > > > > > > > > > > > > > > > > > > In short, DT for U-Boot and platform data for SPL is what's > > > > > > > > > recommended, > > > > > > > > > yes. > > > > > > > > > > > > > > > > > > > > > > > > > This is a little confusing for me. Socfpga gen5 SPL doesn't do > > > > > > > > that. And it > > > > > > > > seems a little strange or outdated overall. > > > > > > > > > > > > > > > > Would there be some kind of reference architecture or mach to > > > > > > > > look at > > > > > > > > what's the suggested/up-to-date way to implement SPL? Also > > > > > > > > regarding code > > > > > > > > flow? > > > > > > > > > > > > > > So, SPL is where things get, ahem, fuzzy. While I don't want to > > > > > > > encourage boundless growth in U-Boot proper, we aren't exactly > > > > > > > size > > > > > > > constrained (but rather, functional/logical constrained). But in > > > > > > > SPL, > > > > > > > yes, we have many platforms with 32/64/128 kilobyte hard limits > > > > > > > (and > > > > > > > some smaller) and we can't always shove in a "TPL" before SPL > > > > > > > either. > > > > > > > So in SPL we do make use of platform data instead. While not the > > > > > > > smallest size constraint, am335x_hs_evm is a reasonable thing to > > > > > > > look at > > > > > > > in this case. > > > > > > > > > > > > Also 'rock' uses CONFIG_OF_PLATDATA which provides a halfway house - > > > > > > still uses DT, but it gets converted into C structs so saves code > > > > > > space. > > > > > > > > > > > > firefly-rk3288 is a pretty good DM/DT example, including SPL. > > > > > > > > > > I've currently got an issue on socfpga gen5 that could be solved best > > > > > by enabling CONFIG_OF_EMBED (mixing const and non-const sections is a > > > > > problem for CRC calculation). However, it could probably also solve by > > > > > using platform data (but that doesn't work out of the box, yet). The > > > > > problem with CONFIG_OF_EMBED is that I think it's OK to enable this > > > > > for SPL but I don't like enabling it for U-Boot, so: > > > > > > > > > > Would it make sense to duplicate the whole "Provider of DTB for OF > > > > > control" choice so that it can be OF_EMBED for SPL but different for > > > > > U-Boot? Or does it make more sense to convert socfpga gen5 to use > > > > > OF_PLATDATA? > > > > > > > > We should not be using OF_EMBED in in-tree boards or production code. > > > > > > What's the reason for this? I can understand this for U-Boot, and I > > > can understand that it's at least theoretically a bit cleaner for SPL, > > > too. But there are some drawbacks when doing this in SPL where code is > > > not relocated: > > > - you lose the ability to check total size in linker file (which is > >
[U-Boot] [PATCH] arm: dts: am33xx: Sync dts with Linux 4.20.0
This patch synchronizes the am33xx SoC specific files with those from
Linux 4.20.0. Hence all board maintainers of am33xx based boards are
on the cc list.
The main purpose of this patch is to prevent further diverging of the
dts files from U-Boot and those from Linux. It aims to set the stage
for the synchronization of board specific dts files. Example: I'm the
maintainer of the PDU001 board: once this patch is applied successfully
I will make changes to the board specific dts file in Linux only and
then post a patch with a copy of this exact dts file to U-Boot. This
will make U-Boot and Linux remain in sync.
The stumbling block of https://patchwork.ozlabs.org/patch/943627 was
removed by the patch https://patchwork.ozlabs.org/patch/962428 from
Lokesh Vutla (many thanks!). This omap-serial driver allows using the
Linux am33xx.dtsi file in U-Boot.
Other changes to dts and dtsi files made by this patch are mainly to
prevent _new_ warnings during the build process. Especially the warning
at pinmux@800 stating 'unnecessary #address-cells/#size-cells without
"ranges" or child "reg"' was not removed. This warning is a good example
showing the benefit of the synchronization: if it needs to be fixed it
will be fixed in Linux and ported back to U-Boot.
Buildman reports all 46 am33xx SoC based boards to build fine, with
warnings of course. Nevertheless this patch should be tested thoroughly
on as many boards as possible to prevent any collateral damage.
Signed-off-by: Felix Brack
---
arch/arm/dts/am335x-evm.dts | 6 +-
arch/arm/dts/am335x-evmsk.dts | 2 -
arch/arm/dts/am335x-pxm2.dtsi | 2 -
arch/arm/dts/am335x-rut.dts | 10 +-
arch/arm/dts/am33xx-clocks.dtsi | 271 -
arch/arm/dts/am33xx.dtsi| 347
arch/arm/dts/am4372.dtsi| 12 +-
arch/arm/dts/am437x-idk-evm.dts | 2 -
arch/arm/dts/dm816x.dtsi| 4 -
include/dt-bindings/clock/am3.h | 227 +
10 files changed, 620 insertions(+), 263 deletions(-)
create mode 100644 include/dt-bindings/clock/am3.h
diff --git a/arch/arm/dts/am335x-evm.dts b/arch/arm/dts/am335x-evm.dts
index a6f20af648..fe27207588 100644
--- a/arch/arm/dts/am335x-evm.dts
+++ b/arch/arm/dts/am335x-evm.dts
@@ -80,8 +80,6 @@
gpio_keys: volume_keys@0 {
compatible = "gpio-keys";
- #address-cells = <1>;
- #size-cells = <0>;
autorepeat;
switch@9 {
@@ -723,8 +721,8 @@
&mmc3 {
/* these are on the crossbar and are outlined in the
xbar-event-map element */
- dmas = <&edma 12
- &edma 13>;
+ dmas = <&edma 12 0
+ &edma 13 0>;
dma-names = "tx", "rx";
status = "okay";
vmmc-supply = <&wlan_en_reg>;
diff --git a/arch/arm/dts/am335x-evmsk.dts b/arch/arm/dts/am335x-evmsk.dts
index b3e9b61bae..0767578aee 100644
--- a/arch/arm/dts/am335x-evmsk.dts
+++ b/arch/arm/dts/am335x-evmsk.dts
@@ -109,8 +109,6 @@
gpio_buttons: gpio_buttons@0 {
compatible = "gpio-keys";
- #address-cells = <1>;
- #size-cells = <0>;
switch@1 {
label = "button0";
diff --git a/arch/arm/dts/am335x-pxm2.dtsi b/arch/arm/dts/am335x-pxm2.dtsi
index 8d58cd4c91..d9243d5d3d 100644
--- a/arch/arm/dts/am335x-pxm2.dtsi
+++ b/arch/arm/dts/am335x-pxm2.dtsi
@@ -50,8 +50,6 @@
gpio_keys: restart-keys {
compatible = "gpio-keys";
- #address-cells = <1>;
- #size-cells = <0>;
autorepeat;
restart0 {
diff --git a/arch/arm/dts/am335x-rut.dts b/arch/arm/dts/am335x-rut.dts
index c6cfbb8033..a5716a929f 100644
--- a/arch/arm/dts/am335x-rut.dts
+++ b/arch/arm/dts/am335x-rut.dts
@@ -36,8 +36,6 @@
gpio_keys: powerfail-keys {
compatible = "gpio-keys";
- #address-cells = <1>;
- #size-cells = <0>;
autorepeat;
pwr-fail0 {
@@ -190,12 +188,8 @@
&epwmss1 {
status = "okay";
-
- ehrpwm1: ehrpwm@48302200 {
- status = "okay";
- pinctrl-names = "default";
- pinctrl-0 = <&epwmss1_pins>;
- };
+ pinctrl-names = "default";
+ pinctrl-0 = <&epwmss1_pins>;
};
&gpmc {
diff --git a/arch/arm/dts/am33xx-clocks.dtsi b/arch/arm/dts/am33xx-clocks.dtsi
index afb4b3a7ba..95d5c9d136 100644
--- a/arch/arm/dts/am33xx-clocks.dtsi
+++ b/arch/arm/dts/am33xx-clocks.dtsi
@@ -8,7 +8,7 @@
* published by the Free Software Foundation.
*/
&scm_clocks {
- sys_clkin_ck: sys_clkin_ck {
+ sys_clkin_ck: sys_clkin_ck@40 {
#clock-cells = <0>;
compatible = "ti,mux-clock";
clocks = <&virt_1920_ck>, <&virt_2400_ck>,
<&virt_2500_ck>, <&virt_2600_ck>;
@@ -163,7 +163,7 @@
clock-frequency = <1200>;
Re: [U-Boot] [PATCH] blk: Rework guard around part_init call
On Wed, 5 Dec 2018 at 06:23, Tom Rini wrote: > > The function part_init() will only be built when we have both > CONFIG_PARTITIONS and CONFIG_HAVE_BLOCK_DEVICE set. Protect the call to > this function with both of these tests now. > > Cc: Simon Glass > Cc: Philipp Tomsich > Cc: Michal Simek > Cc: York Sun > Cc: Prabhakar Kushwaha > Cc: Mingkai Hu > Cc: Stefan Roese > Cc: Marek Behún > Cc: Vanessa Maegima > Cc: Eugen Hristev > Cc: Adam Ford > Cc: Jagan Teki > Cc: Tom Warren > Cc: Stephen Warren > Cc: Vitaly Andrianov > Signed-off-by: Tom Rini > --- > Changes in v2: > - rockchip: evb-rk3036 and kylin-rk3036 are both targets that do not use > CONFIG_SPL_FRAMEWORK but also do not fall into the legacy PowerPC SPL > case. In order to avoid fail to builds on these platforms they must > now turn off CONFIG_SPL_BLK, which they weren't using before, it was > being discarded at link time. > - Re-work common/spl/Kconfig and then various Makefiles to slightly > clear up the logic of when we do and don't need both disk/part.o and > drivers/block/blk-uclass.o. This is in fact not the greatest but it's > all I could come up with to cover all the cases we have today. > - Because of the above, add a note to the CONFIG_BLK migration to note > that once we are complete there we need to revisit the symbols I used > above as once that migration is done we should be able to rely on just > BLK and maybe PARTITIONS. Indeed. > - Actually build-test the world and confirm the overall results are > fairly sane. This results in pushing a few platforms that are using > SPL and DM into using SPL_BLK now. > - This also results in a number of 64bit rockchip, nxp and zynqmp > platforms that have been enabling CONFIG_SPL_DOS_PARTITION / > CONFIG_SPL_ISO_PARTITION now linking it. > - On the 32bit ARM side, some Marvell, i.MX, ateml, TI, Tegra, zynq and > rockchip platforms do the same. > > The full build log can be seen at: > https://gist.github.com/trini/e3e73afec629bbda2625102120c2a9db > --- > common/spl/Kconfig | 3 +++ > configs/evb-rk3036_defconfig | 1 + > configs/kylin-rk3036_defconfig | 1 + > doc/driver-model/MIGRATION.txt | 4 +++- > drivers/Makefile | 3 +-- > drivers/block/Makefile | 2 ++ > drivers/block/blk-uclass.c | 2 +- > scripts/Makefile.spl | 4 +++- > 8 files changed, 15 insertions(+), 5 deletions(-) Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] usb: dwc3: Add missing dependency on MISC uclass
On 12/05/2018 09:05 AM, Michal Simek wrote: > Generic wrapper requires MISC uclass but dependency is not covered in > Kconfig. > > misc0 [ + ] dwc3-generic-wrapper | |-- usb0@ff9d > usb_dev_ge 0 [ + ] dwc3-generic-periphe | | `-- dwc3@fe20 > misc1 [ ] dwc3-generic-wrapper | |-- usb1@ff9e > usb 0 [ ] dwc3-generic-host | | `-- dwc3@fe30 > watchdog0 [ + ] cdns_wdt | `-- watchdog@fd4d > > Signed-off-by: Michal Simek > --- > > drivers/usb/dwc3/Kconfig | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/usb/dwc3/Kconfig b/drivers/usb/dwc3/Kconfig > index 943b7630eba4..9f0b8a2d0b4f 100644 > --- a/drivers/usb/dwc3/Kconfig > +++ b/drivers/usb/dwc3/Kconfig > @@ -39,7 +39,7 @@ config USB_DWC3_OMAP > > config USB_DWC3_GENERIC > bool "Xilinx ZynqMP and similar Platforms" > - depends on DM_USB && USB_DWC3 > + depends on DM_USB && USB_DWC3 && MISC Platforms which do not select MISC will lose DWC3 now, did you verify that no platform is affected ? > help > Some platforms can reuse this DWC3 generic implementation. > > -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] fdt: Add warning about CONFIG_OF_EMBED
This option has crept into use with some boards. Add a warning to try to prevent this. As an example: https://lists.denx.de/pipermail/u-boot/2017-September/304966.html Signed-off-by: Simon Glass --- Makefile | 8 1 file changed, 8 insertions(+) diff --git a/Makefile b/Makefile index 0d11ff97971..05896598fe3 100644 --- a/Makefile +++ b/Makefile @@ -947,6 +947,14 @@ ifeq ($(CONFIG_LIBATA)$(CONFIG_DM_SCSI)$(CONFIG_MVSATA_IDE),y) @echo "Failure to update by the deadline may result in board removal." @echo "See doc/driver-model/MIGRATION.txt for more info." @echo "" +endif +ifeq ($(CONFIG_OF_EMBED),y) + @echo "= WARNING ==" + @echo "CONFIG_OF_EMBED is enabled. This option should only" + @echo "be used for debugging purposes. Please use" + @echo "CONFIG_OF_SEPARATE for boards in mainline." + @echo "See doc/README.fdt-control for more info." + @echo "" endif @# Check that this build does not use CONFIG options that we do not @# know about unless they are in Kconfig. All the existing CONFIG -- 2.20.0.rc1.387.gf8505762e3-goog ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 1/7] dm: serial: Add ->getconfig() callback
On Wed, Dec 05, 2018 at 05:55:37AM -0700, Simon Glass wrote: > On Tue, 27 Nov 2018 at 09:03, Andy Shevchenko > wrote: > > On Mon, Nov 26, 2018 at 06:02:28PM -0700, Simon Glass wrote: > > The rest of similar functions are operate on top of current console device > > and > > do not have such parameter, while being DM-based functions. > > > > I would gladly rebase my series on top any work which is done regard above > > request. > > For now, I don't see such possibility. > > My point is that you are adding a new function which does not use > driver model properly. The serial_getconfig() function should have a > device parameter, and it should not support non-DM, since it is a new > feature. I understand that, OTOH I can repeat myself that this would be very inconsistent with preexisting set of the functions. In my opinion that must be fixed altogether either before or after, but at once. > I'm going to pick this up, absent any other issues, and see if I can > do a patch for it afterwards. > > Reviewed-by: Simon Glass Thank you for review, and sorry for being persuader, I have several big tasks to be accomplished before my vacation starts. -- With Best Regards, Andy Shevchenko ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/2] x86: Wrap calls to 8259 with CONFIG_I8259_PIC
On Thu, 29 Nov 2018 at 20:52, Bin Meng wrote: > > mask_irq(), unmask_irq() and specific_eoi() are provided by the > i8259 PIC driver and should be wrapped with CONFIG_I8259_PIC. > > Signed-off-by: Bin Meng > Tested-by: Hannes Schmelzer > > --- > > Changes in v2: > - use if() instead of #if > > arch/x86/lib/interrupts.c | 16 ++-- > 1 file changed, 10 insertions(+), 6 deletions(-) Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/2] x86: kconfig: Allow board defconfig file to disable 8259 and APIC
On Thu, 29 Nov 2018 at 20:52, Bin Meng wrote: > > At present the Kconfig options (CONFIG_I8259_PIC and CONFIG_APIC) > do not include a prompt message, which makes it impossible to > be disabled from a board defconfig file. > > Signed-off-by: Bin Meng > > --- > > Changes in v2: None > > arch/x86/Kconfig | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 0/8] Fix CVE-2018-18440 and CVE-2018-18439
Hi Simon,
On Wed, 5 Dec 2018 at 06:16, Simon Goldschmidt
wrote:
>
> On Wed, Dec 5, 2018 at 2:13 PM Simon Glass wrote:
> >
> > Hi Simon,
> >
> > On Tue, 4 Dec 2018 at 04:54, Simon Goldschmidt
> > wrote:
> > >
> > > On Tue, Dec 4, 2018 at 12:45 AM Simon Glass wrote:
> > > >
> > > > Hi Simon,
> > > >
> > > > On Mon, 3 Dec 2018 at 12:05, Simon Goldschmidt
> > > > wrote:
> > > > >
> > > > >
> > > > >
> > > > > Am Mo., 3. Dez. 2018, 19:20 hat Simon Glass
> > > > > geschrieben:
> > > > >>
> > > > >> Hi Simon,
> > > > >>
> > > > >> On Mon, 3 Dec 2018 at 00:50, Simon Goldschmidt
> > > > >> wrote:
> > > > >> >
> > > > >> > Simon,
> > > > >> >
> > > > >> > On Tue, Nov 27, 2018 at 6:45 AM Simon Goldschmidt
> > > > >> > wrote:
> > > > >> > >
> > > > >> > > On Tue, Nov 27, 2018 at 2:02 AM Simon Glass
> > > > >> > > wrote:
> > > > >> > > >
> > > > >> > > > Hi Simon,
> > > > >> > > >
> > > > >> > > > On Sat, 17 Nov 2018 at 05:25, Simon Goldschmidt
> > > > >> > > > wrote:
> > > > >> > > > >
> > > > >> > > > > This series fixes CVE-2018-18440 ("insufficient boundary
> > > > >> > > > > checks in
> > > > >> > > > > filesystem image load") by adding restrictions to the 'load'
> > > > >> > > > > command and fixes CVE-2018-18439 ("insufficient boundary
> > > > >> > > > > checks in
> > > > >> > > > > network image boot") by adding restrictions to the tftp code.
> > > > >> > > > >
> > > > >> > > > > The functions from lmb.c are used to setup regions of
> > > > >> > > > > allowed and
> > > > >> > > > > reserved memory. Then, the file size to load is checked
> > > > >> > > > > against these
> > > > >> > > > > addresses and loading the file is aborted if it would
> > > > >> > > > > overwrite
> > > > >> > > > > reserved memory.
> > > > >> > > > >
> > > > >> > > > > The memory reservation code is reused from bootm/image.
> > > > >> > > > >
> > > > >> > > > > Changes in v3:
> > > > >> > > > > - No patch changes, but needed to resend since patman added
> > > > >> > > > > too many cc
> > > > >> > > > > addresses that gmail seemed to detect as spam :-(
> > > > >> > > > >
> > > > >> > > > > Changes in v2:
> > > > >> > > > > - added code to reserve devicetree reserved-memory in lmb
> > > > >> > > > > - added tftp fixes (patches 7 and 8)
> > > > >> > > > > - fixed a bug in new function lmb_alloc_addr
> > > > >> > > > >
> > > > >> > > > > Simon Goldschmidt (8):
> > > > >> > > > > lib: lmb: reserving overlapping regions should fail
> > > > >> > > > > fdt: parse "reserved-memory" for memory reservation
> > > > >> > > > > lib: lmb: extend lmb for checks at load time
> > > > >> > > > > fs: prevent overwriting reserved memory
> > > > >> > > > > bootm: use new common function lmb_init_and_reserve
> > > > >> > > > > lmb: remove unused extern declaration
> > > > >> > > > > net: remove CONFIG_MCAST_TFTP
> > > > >> > > > > tftp: prevent overwriting reserved memory
> > > > >> > > > >
> > > > >> > > > > README | 9 --
> > > > >> > > > > common/bootm.c | 8 +-
> > > > >> > > > > common/image-fdt.c | 52 ++-
> > > > >> > > > > drivers/net/rtl8139.c| 9 --
> > > > >> > > > > drivers/net/tsec.c | 52 ---
> > > > >> > > > > drivers/usb/gadget/ether.c | 3 -
> > > > >> > > > > fs/fs.c | 56 ++-
> > > > >> > > > > include/lmb.h| 7 +-
> > > > >> > > > > include/net.h| 17 ---
> > > > >> > > > > lib/lmb.c| 69 +
> > > > >> > > > > net/eth-uclass.c | 4 -
> > > > >> > > > > net/eth_legacy.c | 46 --
> > > > >> > > > > net/net.c| 9 +-
> > > > >> > > > > net/tftp.c | 289
> > > > >> > > > > +++
> > > > >> > > > > scripts/config_whitelist.txt | 1 -
> > > > >> > > > > 15 files changed, 232 insertions(+), 399 deletions(-)
> > > > >> > > >
> > > > >> > > > This is great work, but what is missing is a test for lmb.
> > > > >> > >
> > > > >> > > Yeah, well, the tests didn't work on my system and I figured it's
> > > > >> > > better to get the code fixed than to use my time on trying to
> > > > >> > > get the
> > > > >> > > tests running.
> > > > >> > >
> > > > >> > > However, after searching for the required packages and fiddling
> > > > >> > > around
> > > > >> > > some more, I guess I made them work so I could add tests now...
> > > > >> > >
> > > > >> > > I also have work-in-progress for compressing fit image contents
> > > > >> > > (we
> > > > >> > > currently only support uncompressing the kernel). It will switch
> > > > >> > > some
> > > > >> > > 'lmb_reserve' calls to the new 'lmb_alloc_addr' as this is more
> > > > >> > > safe.
> > > > >> > > Maybe I can combine the tests in that series?
> > > > >> >
> > > > >> > After managing to get the tests to run via 'make qcheck' (and 'make
> > > > >> > tests'; had to install much more than listed in
> >
Re: [U-Boot] [PATCH 66/93] arm: Remove ot1200 board
Am 05.12.2018 um 14:54 schrieb Simon Glass: Hi Simon, On Wed, 5 Dec 2018 at 06:38, Simon Goldschmidt wrote: On Wed, Dec 5, 2018 at 2:21 PM Simon Glass wrote: Hi Simon, On Sun, 25 Nov 2018 at 23:05, Simon Goldschmidt wrote: [I've cut down the CC list a bit due to some gmail warnings] On Mon, Nov 26, 2018 at 4:00 AM Simon Glass wrote: Hi Simon, On Sun, 25 Nov 2018 at 14:09, Simon Goldschmidt wrote: On Thu, Nov 22, 2018 at 9:50 PM Simon Glass wrote: Hi, On Thu, 22 Nov 2018 at 10:02, Tom Rini wrote: On Thu, Nov 22, 2018 at 03:44:28PM +0100, Simon Goldschmidt wrote: Am Do., 22. Nov. 2018, 14:44 hat Tom Rini geschrieben: On Thu, Nov 22, 2018 at 02:24:49PM +0100, Marek Vasut wrote: On 11/22/2018 01:52 PM, Tom Rini wrote: On Thu, Nov 22, 2018 at 10:25:14AM +0100, Christian Gmeiner wrote: Am Mo., 19. Nov. 2018 um 16:56 Uhr schrieb Simon Glass < s...@chromium.org>: This board has not been converted to CONFIG_DM_BLK by the deadline. Remove it. As the board is still mainted I will NAK it for the moment. Are there any hints want needs to be done to port thie board over to new DM stuff? Yes, as a start you need to switch over to using CONFIG_OF_CONTROL and selecting/providing a dtb file. I see ot1200 is using DWC_AHSATA which needs more work, but this is the board-level work that needs doing. Wasn't there a possibility to use platform data in board file instead of DT ? Or is DT mandatory now , including the libfdt overhead ? In short, DT for U-Boot and platform data for SPL is what's recommended, yes. This is a little confusing for me. Socfpga gen5 SPL doesn't do that. And it seems a little strange or outdated overall. Would there be some kind of reference architecture or mach to look at what's the suggested/up-to-date way to implement SPL? Also regarding code flow? So, SPL is where things get, ahem, fuzzy. While I don't want to encourage boundless growth in U-Boot proper, we aren't exactly size constrained (but rather, functional/logical constrained). But in SPL, yes, we have many platforms with 32/64/128 kilobyte hard limits (and some smaller) and we can't always shove in a "TPL" before SPL either. So in SPL we do make use of platform data instead. While not the smallest size constraint, am335x_hs_evm is a reasonable thing to look at in this case. Also 'rock' uses CONFIG_OF_PLATDATA which provides a halfway house - still uses DT, but it gets converted into C structs so saves code space. firefly-rk3288 is a pretty good DM/DT example, including SPL. I've currently got an issue on socfpga gen5 that could be solved best by enabling CONFIG_OF_EMBED (mixing const and non-const sections is a problem for CRC calculation). However, it could probably also solve by using platform data (but that doesn't work out of the box, yet). The problem with CONFIG_OF_EMBED is that I think it's OK to enable this for SPL but I don't like enabling it for U-Boot, so: Would it make sense to duplicate the whole "Provider of DTB for OF control" choice so that it can be OF_EMBED for SPL but different for U-Boot? Or does it make more sense to convert socfpga gen5 to use OF_PLATDATA? We should not be using OF_EMBED in in-tree boards or production code. What's the reason for this? I can understand this for U-Boot, and I can understand that it's at least theoretically a bit cleaner for SPL, too. But there are some drawbacks when doing this in SPL where code is not relocated: - you lose the ability to check total size in linker file (which is bad for size-constrained platforms: sometimes you notice failure only when booting) You can add an SPL size check in Makefile.spl if you like. That might be required, yes. - you get an inconsistent memory layout regarding read/write: the linker places bss at the end but then, DTB follows as const data This should be handled by the $(SPL-BIN)-pad.bin file (or by binman if you are using that). I don't understand that. How does the padding help? I have these sections (roughly): - text: readonly - bss: writable - DTB: readonly, added as post build step after linking How does $(SPL-BIN)-pad.bin help? It covers over the BSS section so that the image ends where the DTB starts, thus fixing the addressing issue you mentioned. It allows you to do this: cat u-boot-spl-nodtb.bin u-boot-spl.dtn >-u-boot-spl.bin - binary size "on disk" grows due to this inconsistent memory layout (since the flat binary includes the DTB, it needs to include the zeroed-out bss, too) Right, but this is a few bytes. Why does it matter? - "spl/u-boot-spl.hex" created by the default Makefiles does not seem to include the DTB That might just be a bug. It might, yes. The hex file is currently built from the elf file, so there's no DTB in there. OK. Could be worth a patch. Can you please explain the issue a bit more? Of course: socfpga gen5 has a feature where the boot rom can jump to SPL in SRAM on warm boot. To ensure SPL is still valid after a reboot
Re: [U-Boot] [PATCH] usb: dwc3: Add missing dependency on MISC uclass
On 05. 12. 18 14:26, Marek Vasut wrote: > On 12/05/2018 09:05 AM, Michal Simek wrote: >> Generic wrapper requires MISC uclass but dependency is not covered in >> Kconfig. >> >> misc0 [ + ] dwc3-generic-wrapper | |-- usb0@ff9d >> usb_dev_ge 0 [ + ] dwc3-generic-periphe | | `-- dwc3@fe20 >> misc1 [ ] dwc3-generic-wrapper | |-- usb1@ff9e >> usb 0 [ ] dwc3-generic-host | | `-- dwc3@fe30 >> watchdog0 [ + ] cdns_wdt | `-- watchdog@fd4d >> >> Signed-off-by: Michal Simek >> --- >> >> drivers/usb/dwc3/Kconfig | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/drivers/usb/dwc3/Kconfig b/drivers/usb/dwc3/Kconfig >> index 943b7630eba4..9f0b8a2d0b4f 100644 >> --- a/drivers/usb/dwc3/Kconfig >> +++ b/drivers/usb/dwc3/Kconfig >> @@ -39,7 +39,7 @@ config USB_DWC3_OMAP >> >> config USB_DWC3_GENERIC >> bool "Xilinx ZynqMP and similar Platforms" >> -depends on DM_USB && USB_DWC3 >> +depends on DM_USB && USB_DWC3 && MISC > > Platforms which do not select MISC will lose DWC3 now, did you verify > that no platform is affected ? This is what it is going to happen when MISC is not enabled. Model: ZynqMP ZCU100 RevC Board: Xilinx ZynqMP I2C: ready DRAM: 2 GiB Cannot find uclass for id 39: please add the UCLASS_DRIVER() declaration for this UCLASS_... id Error binding driver 'dwc3-generic-wrapper': -96 Cannot find uclass for id 39: please add the UCLASS_DRIVER() declaration for this UCLASS_... id Error binding driver 'dwc3-generic-wrapper': -96 Some drivers failed to bind Error binding driver 'generic_simple_bus': -96 Some drivers failed to bind initcall sequence 7ff9c3c8 failed at call 08015728 (err=-96) ### ERROR ### Please RESET the board ### It means if any platform is not enabling MISC then they have bigger problem then just missing DWC3. Anyway only ZynqMP board enables it and all of them have MISC enabled. [u-boot](wd)$ git log -n 1 --oneline d452f27b3ea8 Prepare v2019.01-rc1 [u-boot](wd)$ git grep DWC3_GENERIC configs/avnet_ultra96_rev1_defconfig:83:CONFIG_USB_DWC3_GENERIC=y configs/xilinx_zynqmp_zc1751_xm015_dc1_defconfig:89:CONFIG_USB_DWC3_GENERIC=y configs/xilinx_zynqmp_zc1751_xm016_dc2_defconfig:82:CONFIG_USB_DWC3_GENERIC=y configs/xilinx_zynqmp_zc1751_xm017_dc3_defconfig:80:CONFIG_USB_DWC3_GENERIC=y configs/xilinx_zynqmp_zcu100_revC_defconfig:83:CONFIG_USB_DWC3_GENERIC=y configs/xilinx_zynqmp_zcu102_rev1_0_defconfig:108:CONFIG_USB_DWC3_GENERIC=y configs/xilinx_zynqmp_zcu102_revA_defconfig:105:CONFIG_USB_DWC3_GENERIC=y configs/xilinx_zynqmp_zcu102_revB_defconfig:105:CONFIG_USB_DWC3_GENERIC=y configs/xilinx_zynqmp_zcu104_revA_defconfig:88:CONFIG_USB_DWC3_GENERIC=y configs/xilinx_zynqmp_zcu104_revC_defconfig:89:CONFIG_USB_DWC3_GENERIC=y configs/xilinx_zynqmp_zcu106_revA_defconfig:97:CONFIG_USB_DWC3_GENERIC=y configs/xilinx_zynqmp_zcu111_revA_defconfig:90:CONFIG_USB_DWC3_GENERIC=y drivers/usb/dwc3/Kconfig:40:config USB_DWC3_GENERIC drivers/usb/dwc3/Makefile:10:obj-$(CONFIG_USB_DWC3_GENERIC) += dwc3-generic.o Thanks, Michal ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] fdt: Add warning about CONFIG_OF_EMBED
Am 05.12.2018 um 14:57 schrieb Simon Glass: This option has crept into use with some boards. Add a warning to try to prevent this. As an example: https://lists.denx.de/pipermail/u-boot/2017-September/304966.html We have just discussed this in another thread. There seem to be ~109 defconfigs in the tree that enable OF_EMBED. I doubt all of them do this for fun, so we might want to collect the reasons they do so. I do know two: - socfpga_stratix10_defconfig needs this to get a correct u-boot-spl.hex - I would need it to ensure in SPL, the DTB is in one block with the other readonly parts. Without OF_EMBED, we have '.text', '.bss', DT. Regards, Simon Signed-off-by: Simon Glass --- Makefile | 8 1 file changed, 8 insertions(+) diff --git a/Makefile b/Makefile index 0d11ff97971..05896598fe3 100644 --- a/Makefile +++ b/Makefile @@ -947,6 +947,14 @@ ifeq ($(CONFIG_LIBATA)$(CONFIG_DM_SCSI)$(CONFIG_MVSATA_IDE),y) @echo "Failure to update by the deadline may result in board removal." @echo "See doc/driver-model/MIGRATION.txt for more info." @echo "" +endif +ifeq ($(CONFIG_OF_EMBED),y) + @echo "= WARNING ==" + @echo "CONFIG_OF_EMBED is enabled. This option should only" + @echo "be used for debugging purposes. Please use" + @echo "CONFIG_OF_SEPARATE for boards in mainline." + @echo "See doc/README.fdt-control for more info." + @echo "" endif @# Check that this build does not use CONFIG options that we do not @# know about unless they are in Kconfig. All the existing CONFIG ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] usb: dwc3: Add missing dependency on MISC uclass
On 12/05/2018 03:17 PM, Michal Simek wrote: > On 05. 12. 18 14:26, Marek Vasut wrote: >> On 12/05/2018 09:05 AM, Michal Simek wrote: >>> Generic wrapper requires MISC uclass but dependency is not covered in >>> Kconfig. >>> >>> misc0 [ + ] dwc3-generic-wrapper | |-- usb0@ff9d >>> usb_dev_ge 0 [ + ] dwc3-generic-periphe | | `-- dwc3@fe20 >>> misc1 [ ] dwc3-generic-wrapper | |-- usb1@ff9e >>> usb 0 [ ] dwc3-generic-host | | `-- dwc3@fe30 >>> watchdog0 [ + ] cdns_wdt | `-- watchdog@fd4d >>> >>> Signed-off-by: Michal Simek >>> --- >>> >>> drivers/usb/dwc3/Kconfig | 2 +- >>> 1 file changed, 1 insertion(+), 1 deletion(-) >>> >>> diff --git a/drivers/usb/dwc3/Kconfig b/drivers/usb/dwc3/Kconfig >>> index 943b7630eba4..9f0b8a2d0b4f 100644 >>> --- a/drivers/usb/dwc3/Kconfig >>> +++ b/drivers/usb/dwc3/Kconfig >>> @@ -39,7 +39,7 @@ config USB_DWC3_OMAP >>> >>> config USB_DWC3_GENERIC >>> bool "Xilinx ZynqMP and similar Platforms" >>> - depends on DM_USB && USB_DWC3 >>> + depends on DM_USB && USB_DWC3 && MISC >> >> Platforms which do not select MISC will lose DWC3 now, did you verify >> that no platform is affected ? > > This is what it is going to happen when MISC is not enabled. > > Model: ZynqMP ZCU100 RevC > Board: Xilinx ZynqMP > I2C: ready > DRAM: 2 GiB > Cannot find uclass for id 39: please add the UCLASS_DRIVER() declaration > for this UCLASS_... id > Error binding driver 'dwc3-generic-wrapper': -96 > Cannot find uclass for id 39: please add the UCLASS_DRIVER() declaration > for this UCLASS_... id > Error binding driver 'dwc3-generic-wrapper': -96 > Some drivers failed to bind > Error binding driver 'generic_simple_bus': -96 > Some drivers failed to bind > initcall sequence 7ff9c3c8 failed at call 08015728 (err=-96) > ### ERROR ### Please RESET the board ### > > It means if any platform is not enabling MISC then they have bigger > problem then just missing DWC3. > > Anyway only ZynqMP board enables it and all of them have MISC enabled. > > [u-boot](wd)$ git log -n 1 --oneline > d452f27b3ea8 Prepare v2019.01-rc1 > [u-boot](wd)$ git grep DWC3_GENERIC > configs/avnet_ultra96_rev1_defconfig:83:CONFIG_USB_DWC3_GENERIC=y > configs/xilinx_zynqmp_zc1751_xm015_dc1_defconfig:89:CONFIG_USB_DWC3_GENERIC=y > configs/xilinx_zynqmp_zc1751_xm016_dc2_defconfig:82:CONFIG_USB_DWC3_GENERIC=y > configs/xilinx_zynqmp_zc1751_xm017_dc3_defconfig:80:CONFIG_USB_DWC3_GENERIC=y > configs/xilinx_zynqmp_zcu100_revC_defconfig:83:CONFIG_USB_DWC3_GENERIC=y > configs/xilinx_zynqmp_zcu102_rev1_0_defconfig:108:CONFIG_USB_DWC3_GENERIC=y > configs/xilinx_zynqmp_zcu102_revA_defconfig:105:CONFIG_USB_DWC3_GENERIC=y > configs/xilinx_zynqmp_zcu102_revB_defconfig:105:CONFIG_USB_DWC3_GENERIC=y > configs/xilinx_zynqmp_zcu104_revA_defconfig:88:CONFIG_USB_DWC3_GENERIC=y > configs/xilinx_zynqmp_zcu104_revC_defconfig:89:CONFIG_USB_DWC3_GENERIC=y > configs/xilinx_zynqmp_zcu106_revA_defconfig:97:CONFIG_USB_DWC3_GENERIC=y > configs/xilinx_zynqmp_zcu111_revA_defconfig:90:CONFIG_USB_DWC3_GENERIC=y > drivers/usb/dwc3/Kconfig:40:config USB_DWC3_GENERIC > drivers/usb/dwc3/Makefile:10:obj-$(CONFIG_USB_DWC3_GENERIC) > += dwc3-generic.o I wanted to apply this, but it doesn't apply to u-boot-usb/master . -- 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/7] Fix CVE-2018-18440 and CVE-2018-18439
Am 05.12.2018 um 15:20 schrieb Frank Wunderlich:
Hi Simon,
have you any new infos here? last discussion is for v3...
I'm working on it. The bug you get is in lmb.c (and has been there for a
long time). It is rather hidden by the way the lmb functions are used
when booting, but it shows in my new usage.
I'll post v4 soon, hopefully.
Regards,
Simon
regards Frank
Gesendet: Sonntag, 02. Dezember 2018 um 18:44 Uhr
Von: "Frank Wunderlich"
An: "Simon Goldschmidt"
Cc: u-boot@lists.denx.de
Betreff: Re: [U-Boot] [PATCH v4 0/7] Fix CVE-2018-18440 and CVE-2018-18439
Right, i test on bananapi-r2. 2gb ram with 0x8000 base-adress
Seems you need (unsigned) int64 for calculations
Am 2. Dezember 2018 18:14:19 MEZ schrieb Simon Goldschmidt
:
Am 02.12.2018 um 16:48 schrieb Frank Wunderlich:
lmb_init: base: 0x8000, size: 0x8000
Ok, so I don't know your board, is that correct? Do you have 2 GByte
starting at 0x8000?
If so, that would result in an overflow to 0 on a 32-bit platform and
would explain why it doesn't work.
This is a perfect input for a test case :-)
Thanks,
Simon
https://github.com/frank-w/u-boot/commit/e0763252a8e135f00b996fbda7bb1067a192ca53
Regards Frank
Gesendet: Sonntag, 02. Dezember 2018 um 10:24 Uhr
Von: "Simon Goldschmidt"
An: "Frank Wunderlich"
Cc: u-boot@lists.denx.de
Betreff: Re: [U-Boot] [PATCH v4 0/7] Fix CVE-2018-18440 and
CVE-2018-18439
Am 01.12.2018 um 12:07 schrieb Frank Wunderlich:
forgot error-message and detailed command:
fatload ${device} ${partition} ${scriptaddr}
${bpi}/${board}/${service}/${bootenv}
** Reading file would overwrite reserved memory **
echo ${device} ${partition} ${scriptaddr}
${bpi}/${board}/${service}/${bootenv}
mmc 1:1 0x8300 bananapi/bpi-r2/linux/uEnv.txt
file exists i checked with test, but fatload failed, after
reverting the Patches same command works
Hmm, ok. With your configuration, I thought
'gd->bd->bi_dram[0].start'
and 'gd->bd->bi_dram[0].size' should be populated and correctly
describe
your DRAM.
Could you try adding this printf code to the function
'lmb_init_and_reserve':
printf("lmb_init: base: 0x%x, size: 0x%x\n", base, size);
and check if this correctly describes your memory?
Thanks,
Simon
regards Frank
Gesendet: Samstag, 01. Dezember 2018 um 10:46 Uhr
Von: "Frank Wunderlich"
An: "Simon Goldschmidt"
Cc: u-boot@lists.denx.de
Betreff: Re: [U-Boot] [PATCH v4 0/7] Fix CVE-2018-18440 and
CVE-2018-18439
Hi Simon
#define CONFIG_SYS_SDRAM_BASE 0x8000
https://github.com/frank-w/u-boot/blob/a6d0c3f8e992a2e428f05443647fe9f5b13f8634/include/configs/mt7623.h#L47
CONFIG_ARM=y
CONFIG_NR_DRAM_BANKS=1
https://github.com/frank-w/u-boot/blob/a6d0c3f8e992a2e428f05443647fe9f5b13f8634/configs/mt7623n_bpir2_defconfig#L7
i applied the patch-series on top of my 2018-11 final (currently
removed from github)
https://github.com/frank-w/u-boot/tree/bpi-r2_v5
tried ${scriptaddr}=0x8300
here the fatload-command:
https://github.com/frank-w/u-boot/blob/60bc4075c7744e36058fcba76cd6e6c3a4002265/uEnv.txt#L22
working before, 0x8100 and some higher values
HTH
regards Frank
Gesendet: Samstag, 01. Dezember 2018 um 10:25 Uhr
Von: "Simon Goldschmidt"
An: "Frank Wunderlich"
Cc: "U-Boot Mailing List"
Betreff: Re: [U-Boot] [PATCH v4 0/7] Fix CVE-2018-18440 and
CVE-2018-18439
On Fri, Nov 30, 2018 at 6:51 PM Frank Wunderlich
wrote:
Hi Simon,
after applying these Patch-series i cannot load to any address
(fatload). Do i need any additional Patch ("fdt: parse
"reserved-memory" for memory reservation" sounds like that). Maybe
there should be a fallback if no reservation is defined.
No, you should not need additional patches. The code makes use of
"lmb" memory allocation just like the "bootm" code does. The
"memory
reservation" patch you cited only ensures that memory which is
marked
as reserved in the fdt cannot be overwritten by load.
If it doesn't work for you at all, the available memory is
probably
not described correctly. Could you check the values of the
following
defines (or if they are defined at all):
- CONFIG_SYS_SDRAM_BASE
- CONFIG_ARM
- CONFIG_NR_DRAM_BANKS
I might need to improve the DRAM detection code in v5 (which is
still
pending as I am working on lmb tests).
Regards,
Simon
regards Frank
Gesendet: Samstag, 24. November 2018 um 15:11 Uhr
Von: "Simon Goldschmidt"
An: "Tom Rini" , u-boot@lists.denx.de, "Joe
Hershberger"
Cc: "Alexey Brodkin" , "Heinrich
Schuchardt" , "Michal Simek"
, "Alexander Graf" , "Andrea
Barisani"
Betreff: [U-Boot] [PATCH v4 0/7] Fix CVE-2018-18440 and
CVE-2018-18439
This series fixes CVE-2018-18440 ("insufficient boundary checks
in
filesystem image load") by adding restrictions to the 'load'
command and fixes CVE-2018-18439 ("insufficient boundary checks
in
network image boot") by adding restrictions to the tftp code.
The functions from lmb.c are used to setup regions of allowed
and
res
Re: [U-Boot] [PATCH v3 13/28] mtd: ensure MTD is compiled when ENV_IS_IN_FLASH is selected
Hi Wolfgang, Wolfgang Denk wrote on Wed, 05 Dec 2018 13:06:10 +0100: > Dear Miquel, > > In message <20181204235714.11805-14-miquel.ray...@bootlin.com> you wrote: > > MTD support must be enabled when the environment is in NOR. > > Naked-by: Wolfgang Denk > > Environment in NOR must not, I repeat: must not ever depend on MTD! > > For more than 19 years we have been using environment in NOR flash > without the need for MTD support, which makes a lot of sense > especially on smaller systems where resources are low and MTD is an > expensive, but not really needed feature. > > It is not acceptable to create a dependency that costs so much. I took a rather small configuration: stm32f429-discovery_defconfig which uses CONFIG_MTD_NOR_FLASH. Without CONFIG_MTD, u-boot.bin is 209416 bytes. With CONFIG_MTD, u-boot.bin is 214540 bytes. This is an additional 5124 bytes which represent about 2% of the entire size. I am talking about U-Boot only, there is a CONFIG_SPL_MTD_SUPPORT option that must be enabled to compile MTD in the SPL so the change I propose do not enlarge the SPL. Today, there are multiple boards having more than one type of MTD device (eg. raw NAND and SPI-NOR). In this case you need to compile two commands which interface only with the subsystem they have been written for. We propose to kill this approach and instead use an 'mtd' command which shares the same code for all MTD devices: less duplication, more users, and in the end, a reduced size. And I am not event talking about all the code that has been added over the years to "avoid using MTD" which enlarges the binary as well. The current situation is unmaintainable. Any change in U-Boot under the drivers/mtd/ directory results in hours of debugging to fix broken dependencies and crappy configurations. It took me one week to port the SPI-mem/SPI-NAND layers (which rely on MTD) and to have a working 'mtd' command. It took me and Boris almost 4 weeks to fix the fallouts. Now, either we keep U-Boot MTD subsystem maintainable and in sync as much as possible with Linux to continue to benefit from evolutions/drivers/fixes at the cost of a little overhead, or we continue in the current path, with the results we know. Thanks, Miquèl ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] boot.bin on SD Card for SAMA5D3 Xplained
On 05.12.2018 02:15, Daniel Evans wrote: > Trying to get uboot SPL boot.bin to run on an SD card for the sama5d3 > xplained board. All I get is RomBOOT and no other messages. I have tried > throwing in a couple test pins to toggle in board_early_init_f but still not > getting any debug. I can get at91bootstrap to produce a boot.bin that works > on the sama5d3 xplained so I am assuming I don’t have a bad board. My boot > partition is FAT16. To compile I just run the following on Debian Buster : > > make mrproper > make sama5d3_xplained_mmc_defconfig > make > > Cross Compiler is gcc-linaro-6.4.1-2018.05-x86_64_arm-linux-gnueabihf > > When finished compiling I just copy the boot.bin to my BOOT partition. > > Has to be something obvious that I am missing. Any insight is appreciated… Hello, Check the datasheet for sama5d3 SoC section 11.4.3. - Valid code detection (my datasheet is dated 2 Feb 2016 if it helps) Basically the vector 6 needs to have hardcoded the binary size. Are you doing that ? Otherwise the RomBOOT code will consider your binary as faulty. PS. make sure endianess is right, use a good hexeditor... Hope this helps, Eugen > > Dan > ___ > 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] usb: dwc3: Add missing dependency on MISC uclass
On 05. 12. 18 15:24, Marek Vasut wrote: > On 12/05/2018 03:17 PM, Michal Simek wrote: >> On 05. 12. 18 14:26, Marek Vasut wrote: >>> On 12/05/2018 09:05 AM, Michal Simek wrote: Generic wrapper requires MISC uclass but dependency is not covered in Kconfig. misc0 [ + ] dwc3-generic-wrapper | |-- usb0@ff9d usb_dev_ge 0 [ + ] dwc3-generic-periphe | | `-- dwc3@fe20 misc1 [ ] dwc3-generic-wrapper | |-- usb1@ff9e usb 0 [ ] dwc3-generic-host | | `-- dwc3@fe30 watchdog0 [ + ] cdns_wdt | `-- watchdog@fd4d Signed-off-by: Michal Simek --- drivers/usb/dwc3/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/dwc3/Kconfig b/drivers/usb/dwc3/Kconfig index 943b7630eba4..9f0b8a2d0b4f 100644 --- a/drivers/usb/dwc3/Kconfig +++ b/drivers/usb/dwc3/Kconfig @@ -39,7 +39,7 @@ config USB_DWC3_OMAP config USB_DWC3_GENERIC bool "Xilinx ZynqMP and similar Platforms" - depends on DM_USB && USB_DWC3 + depends on DM_USB && USB_DWC3 && MISC >>> >>> Platforms which do not select MISC will lose DWC3 now, did you verify >>> that no platform is affected ? >> >> This is what it is going to happen when MISC is not enabled. >> >> Model: ZynqMP ZCU100 RevC >> Board: Xilinx ZynqMP >> I2C: ready >> DRAM: 2 GiB >> Cannot find uclass for id 39: please add the UCLASS_DRIVER() declaration >> for this UCLASS_... id >> Error binding driver 'dwc3-generic-wrapper': -96 >> Cannot find uclass for id 39: please add the UCLASS_DRIVER() declaration >> for this UCLASS_... id >> Error binding driver 'dwc3-generic-wrapper': -96 >> Some drivers failed to bind >> Error binding driver 'generic_simple_bus': -96 >> Some drivers failed to bind >> initcall sequence 7ff9c3c8 failed at call 08015728 (err=-96) >> ### ERROR ### Please RESET the board ### >> >> It means if any platform is not enabling MISC then they have bigger >> problem then just missing DWC3. >> >> Anyway only ZynqMP board enables it and all of them have MISC enabled. >> >> [u-boot](wd)$ git log -n 1 --oneline >> d452f27b3ea8 Prepare v2019.01-rc1 >> [u-boot](wd)$ git grep DWC3_GENERIC >> configs/avnet_ultra96_rev1_defconfig:83:CONFIG_USB_DWC3_GENERIC=y >> configs/xilinx_zynqmp_zc1751_xm015_dc1_defconfig:89:CONFIG_USB_DWC3_GENERIC=y >> configs/xilinx_zynqmp_zc1751_xm016_dc2_defconfig:82:CONFIG_USB_DWC3_GENERIC=y >> configs/xilinx_zynqmp_zc1751_xm017_dc3_defconfig:80:CONFIG_USB_DWC3_GENERIC=y >> configs/xilinx_zynqmp_zcu100_revC_defconfig:83:CONFIG_USB_DWC3_GENERIC=y >> configs/xilinx_zynqmp_zcu102_rev1_0_defconfig:108:CONFIG_USB_DWC3_GENERIC=y >> configs/xilinx_zynqmp_zcu102_revA_defconfig:105:CONFIG_USB_DWC3_GENERIC=y >> configs/xilinx_zynqmp_zcu102_revB_defconfig:105:CONFIG_USB_DWC3_GENERIC=y >> configs/xilinx_zynqmp_zcu104_revA_defconfig:88:CONFIG_USB_DWC3_GENERIC=y >> configs/xilinx_zynqmp_zcu104_revC_defconfig:89:CONFIG_USB_DWC3_GENERIC=y >> configs/xilinx_zynqmp_zcu106_revA_defconfig:97:CONFIG_USB_DWC3_GENERIC=y >> configs/xilinx_zynqmp_zcu111_revA_defconfig:90:CONFIG_USB_DWC3_GENERIC=y >> drivers/usb/dwc3/Kconfig:40:config USB_DWC3_GENERIC >> drivers/usb/dwc3/Makefile:10:obj-$(CONFIG_USB_DWC3_GENERIC) >> += dwc3-generic.o > > I wanted to apply this, but it doesn't apply to u-boot-usb/master . Good thing on this is that "dwc3-generic: Handle the PHYs, the clocks and the reset lines" has done this change already. (Before I sent this I was checking Jean's patches for DWC3 but didn't find this change :-() Anyway please ignore this patch. Thanks, Michal ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
