Re: [U-Boot] [EXT] Re: XHCI behavior
Yes, I'm looking at the top of trunk xhci.h from the master branch. There is no definition for bit 8 of the HCCPARAMS1 register. Also, in looking at the latest kernel xhci.c I don't see any reference to the PAE bit. With USB NIC cards if the buffer spans a 64K boundary and the data fits in the first half, I get two event responses. The first is a short packet, but the length is based only on the first TRB and a second success event is also received. We have also seen stability problems in the Linux kernel which we now suspect is due to this. -Aaron On Friday, September 6, 2019 8:59:00 PM PDT Bin Meng wrote: > External Email > > -- > Hi Aaron, > > On Sat, Sep 7, 2019 at 11:08 AM Aaron Williams wrote: > > Hi, > > > > I am seeing crashes in our XHCI implementation based on a Designware USB > > 3.1 core. One thing I noticed is that this core sets the PAE bit in the > > HCCparams. The result of this is that when there is a short packet and > > there are two TDs, then when PAE is set there will be two responses with > > the second one being success. I'm still not sure if the length field I'm > > seeing is correct or not, but it appears that neither Linux nor U-Boot > > can handle HCs with the PAE bit set. See the eXtendable Host Controller > > Interface 1.1 sections 4.10.1.1 and 5.3.6. > > It looks this PAE bit was introduced in spec 1.1. U-Boot xHCI driver > was ported from an earlier version of Linux xHCI driver, and I doubt > it could correctly handle it. But you mentioned that Linux could not > handle HCs with PAE set. Did you try the latest kernel? > > > With short packets with the PAE bit set with to TRBs I get two responses > > when the data fits in the first TRB. The first event TRB contains a short > > packet response with the length set to the amount of space within the > > first TRB that is actually used. The second TRB event is a success > > completion code, as is described in section 4.10.1.1.1. > > > > Personally I find this PAE bit a major pain in the arse that causes more > > trouble than it's worth. > > Regards, > Bin -- Aaron Williams Senior Software Engineer Marvell Semiconductor, Inc. (408) 943-7198 (510) 789-8988 (cell) signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 0/2] arm64: dts: sun50i: Add support for A64 OLinuXino (with eMMC)
On Fri, Aug 23, 2019 at 1:56 AM Sunil Mohan Adapa wrote: > > This is a follow up a patch that didn't create a separate dts: > https://lists.denx.de/pipermail/u-boot/2019-July/379109.html > > A64 OLinuXino board from Olimex has three variants with onboard eMMC: > A64-OLinuXino-1Ge16GW, A64-OLinuXino-1Ge4GW and A64-OLinuXino-2Ge8G-IND. In > addition, there are two variants without eMMC. One without eMMC and one with > SPI > flash. This suggests the need for separate device tree for the three eMMC > variants. > > The Linux kernel upstream has chosen to create and use a separate device tree > for the eMMC variants instead of adding eMMC support existing device tree. > These > changes to Linux kernel are queued for Linux 5.4. > > https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux.git/commit/?h=sunxi/dt-for-5.4=02bb66b347ff8115f53948f86b884e008ba385b9 > > This patch has been tested on A64-OLinuXino-1Ge16GW and is based on Linux > device-tree. > > Changes: > > v2: Separate device tree for emmc models. > > Sunil Mohan Adapa (2): > arm64: dts: sun50i: Add support for A64 OLinuXino (with eMMC) > configs: sun50i: Add support for Olimex A64-Olinuxino-eMMC Please squash and send it as single patch, all look fine to me. Reviewed-by: Jagan Teki ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] dm: spi: Check cs number before accessing slaves
Hi Jagan,
On Sat, Sep 7, 2019 at 11:58 AM Jagan Teki wrote:
>
> On Sat, Sep 7, 2019 at 9:19 AM Bin Meng wrote:
> >
> > Hi Jagan,
> >
> > On Sat, Sep 7, 2019 at 11:45 AM Jagan Teki
> > wrote:
> > >
> > > On Thu, Aug 29, 2019 at 7:40 PM Bin Meng wrote:
> > > >
> > > > In spi_get_bus_and_cs() only bus number is checked before accessing
> > > > slaves. We should check cs number as well.
> > > >
> > > > Signed-off-by: Bin Meng
> > > > ---
> > > >
> > > > drivers/spi/spi-uclass.c | 6 ++
> > > > 1 file changed, 6 insertions(+)
> > > >
> > > > diff --git a/drivers/spi/spi-uclass.c b/drivers/spi/spi-uclass.c
> > > > index 24de0b5..f633eb5 100644
> > > > --- a/drivers/spi/spi-uclass.c
> > > > +++ b/drivers/spi/spi-uclass.c
> > > > @@ -271,6 +271,7 @@ int spi_get_bus_and_cs(int busnum, int cs, int
> > > > speed, int mode,
> > > > {
> > > > struct udevice *bus, *dev;
> > > > struct dm_spi_slave_platdata *plat;
> > > > + struct spi_cs_info info;
> > > > bool created = false;
> > > > int ret;
> > > >
> > > > @@ -283,6 +284,11 @@ int spi_get_bus_and_cs(int busnum, int cs, int
> > > > speed, int mode,
> > > > printf("Invalid bus %d (err=%d)\n", busnum, ret);
> > > > return ret;
> > > > }
> > > > + ret = spi_cs_info(bus, cs, );
> > > > + if (ret) {
> > > > + printf("Invalid cs %d (err=%d)\n", cs, ret);
> > > > + return ret;
> > > > + }
> > > > ret = spi_find_chip_select(bus, cs, );
> > >
> > > I think it would rather check the cs_info in spi_find_chip_select
> > > function itself, make more sense.
> >
> > This routine spi_get_bus_and_cs() has both busnum and cs as
> > parameters, but only busnum is checked so far. It looks to me more
> > appropriate to check the cs in spi_get_bus_and_cs() directly, instead
> > of going into spi_find_chip_select().
>
> True, but the spi_find_chip_select is also used in other calls (like
> spi_find_bus_and_cs). Checking cs_info on the core function might help
> to calling it on multiple places. what do you think?
Ok, makes sense. I will do it in v2.
Regards,
Bin
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] spi: Add spi_write_then_read
On Tue, Jul 23, 2019 at 7:58 PM Adam Ford wrote: > > On Mon, Jul 22, 2019 at 7:01 AM Jagan Teki wrote: > > > > Add support for SPI synchronous write followed by read, > > this is common interface call from spi-nor to spi drivers. > > > For the while series: > Tested-by: Adam Ford #da850-evm Applied to u-boot-spi/master ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] XHCI behavior
Hi Aaron, On Sat, Sep 7, 2019 at 11:08 AM Aaron Williams wrote: > > Hi, > > I am seeing crashes in our XHCI implementation based on a Designware USB 3.1 > core. One thing I noticed is that this core sets the PAE bit in the HCCparams. > The result of this is that when there is a short packet and there are two TDs, > then when PAE is set there will be two responses with the second one being > success. I'm still not sure if the length field I'm seeing is correct or not, > but it appears that neither Linux nor U-Boot can handle HCs with the PAE bit > set. See the eXtendable Host Controller Interface 1.1 sections 4.10.1.1 and > 5.3.6. > It looks this PAE bit was introduced in spec 1.1. U-Boot xHCI driver was ported from an earlier version of Linux xHCI driver, and I doubt it could correctly handle it. But you mentioned that Linux could not handle HCs with PAE set. Did you try the latest kernel? > With short packets with the PAE bit set with to TRBs I get two responses when > the data fits in the first TRB. The first event TRB contains a short packet > response with the length set to the amount of space within the first TRB that > is actually used. The second TRB event is a success completion code, as is > described in section 4.10.1.1.1. > > Personally I find this PAE bit a major pain in the arse that causes more > trouble than it's worth. > Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] dm: spi: Check cs number before accessing slaves
On Sat, Sep 7, 2019 at 9:19 AM Bin Meng wrote:
>
> Hi Jagan,
>
> On Sat, Sep 7, 2019 at 11:45 AM Jagan Teki wrote:
> >
> > On Thu, Aug 29, 2019 at 7:40 PM Bin Meng wrote:
> > >
> > > In spi_get_bus_and_cs() only bus number is checked before accessing
> > > slaves. We should check cs number as well.
> > >
> > > Signed-off-by: Bin Meng
> > > ---
> > >
> > > drivers/spi/spi-uclass.c | 6 ++
> > > 1 file changed, 6 insertions(+)
> > >
> > > diff --git a/drivers/spi/spi-uclass.c b/drivers/spi/spi-uclass.c
> > > index 24de0b5..f633eb5 100644
> > > --- a/drivers/spi/spi-uclass.c
> > > +++ b/drivers/spi/spi-uclass.c
> > > @@ -271,6 +271,7 @@ int spi_get_bus_and_cs(int busnum, int cs, int speed,
> > > int mode,
> > > {
> > > struct udevice *bus, *dev;
> > > struct dm_spi_slave_platdata *plat;
> > > + struct spi_cs_info info;
> > > bool created = false;
> > > int ret;
> > >
> > > @@ -283,6 +284,11 @@ int spi_get_bus_and_cs(int busnum, int cs, int
> > > speed, int mode,
> > > printf("Invalid bus %d (err=%d)\n", busnum, ret);
> > > return ret;
> > > }
> > > + ret = spi_cs_info(bus, cs, );
> > > + if (ret) {
> > > + printf("Invalid cs %d (err=%d)\n", cs, ret);
> > > + return ret;
> > > + }
> > > ret = spi_find_chip_select(bus, cs, );
> >
> > I think it would rather check the cs_info in spi_find_chip_select
> > function itself, make more sense.
>
> This routine spi_get_bus_and_cs() has both busnum and cs as
> parameters, but only busnum is checked so far. It looks to me more
> appropriate to check the cs in spi_get_bus_and_cs() directly, instead
> of going into spi_find_chip_select().
True, but the spi_find_chip_select is also used in other calls (like
spi_find_bus_and_cs). Checking cs_info on the core function might help
to calling it on multiple places. what do you think?
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] dm: spi: Check cs number before accessing slaves
Hi Jagan,
On Sat, Sep 7, 2019 at 11:45 AM Jagan Teki wrote:
>
> On Thu, Aug 29, 2019 at 7:40 PM Bin Meng wrote:
> >
> > In spi_get_bus_and_cs() only bus number is checked before accessing
> > slaves. We should check cs number as well.
> >
> > Signed-off-by: Bin Meng
> > ---
> >
> > drivers/spi/spi-uclass.c | 6 ++
> > 1 file changed, 6 insertions(+)
> >
> > diff --git a/drivers/spi/spi-uclass.c b/drivers/spi/spi-uclass.c
> > index 24de0b5..f633eb5 100644
> > --- a/drivers/spi/spi-uclass.c
> > +++ b/drivers/spi/spi-uclass.c
> > @@ -271,6 +271,7 @@ int spi_get_bus_and_cs(int busnum, int cs, int speed,
> > int mode,
> > {
> > struct udevice *bus, *dev;
> > struct dm_spi_slave_platdata *plat;
> > + struct spi_cs_info info;
> > bool created = false;
> > int ret;
> >
> > @@ -283,6 +284,11 @@ int spi_get_bus_and_cs(int busnum, int cs, int speed,
> > int mode,
> > printf("Invalid bus %d (err=%d)\n", busnum, ret);
> > return ret;
> > }
> > + ret = spi_cs_info(bus, cs, );
> > + if (ret) {
> > + printf("Invalid cs %d (err=%d)\n", cs, ret);
> > + return ret;
> > + }
> > ret = spi_find_chip_select(bus, cs, );
>
> I think it would rather check the cs_info in spi_find_chip_select
> function itself, make more sense.
This routine spi_get_bus_and_cs() has both busnum and cs as
parameters, but only busnum is checked so far. It looks to me more
appropriate to check the cs in spi_get_bus_and_cs() directly, instead
of going into spi_find_chip_select().
Regards,
Bin
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] dm: spi: Check cs number before accessing slaves
On Thu, Aug 29, 2019 at 7:40 PM Bin Meng wrote:
>
> In spi_get_bus_and_cs() only bus number is checked before accessing
> slaves. We should check cs number as well.
>
> Signed-off-by: Bin Meng
> ---
>
> drivers/spi/spi-uclass.c | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/drivers/spi/spi-uclass.c b/drivers/spi/spi-uclass.c
> index 24de0b5..f633eb5 100644
> --- a/drivers/spi/spi-uclass.c
> +++ b/drivers/spi/spi-uclass.c
> @@ -271,6 +271,7 @@ int spi_get_bus_and_cs(int busnum, int cs, int speed, int
> mode,
> {
> struct udevice *bus, *dev;
> struct dm_spi_slave_platdata *plat;
> + struct spi_cs_info info;
> bool created = false;
> int ret;
>
> @@ -283,6 +284,11 @@ int spi_get_bus_and_cs(int busnum, int cs, int speed,
> int mode,
> printf("Invalid bus %d (err=%d)\n", busnum, ret);
> return ret;
> }
> + ret = spi_cs_info(bus, cs, );
> + if (ret) {
> + printf("Invalid cs %d (err=%d)\n", cs, ret);
> + return ret;
> + }
> ret = spi_find_chip_select(bus, cs, );
I think it would rather check the cs_info in spi_find_chip_select
function itself, make more sense.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [usb dwc3] xHCI driver -- a hint needed.
Hi Neil, On Thu, Sep 5, 2019 at 11:48 PM Neil Armstrong wrote: > > Hi Bin, > > I've been having the same behavior on the Amlogic S905X SoC with a DWC3 XHCI > controller > connected to 2 HS-only PHYs and no SS PHY. > > When a device is connected on the second PHY, I have the same BUG(), > but no more when a device is also connected on the first PHY, and no issues > at all on the first PHY. > > XHCI timeout on event type 33... cannot recover. > > What kind of debug output would you need to debug this ? > > => When Port 1 is disconnected, but Port 2 is populated: > usb_control_msg: request: 0x1, requesttype: 0x23, value 0x10 index 0x2 length > 0x0 > clear port connect change, actual port 2 status = 0x6e1 > ... > usb_control_msg: request: 0x3, requesttype: 0x23, value 0x4 index 0x2 length > 0x0 > ... > usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x2 length > 0x4 > SPEED = FULLSPEED > ... > usb_control_msg: request: 0x3, requesttype: 0x23, value 0x4 index 0x2 length > 0x0 > ... > usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x2 length > 0x4 > SPEED = FULLSPEED > ... > usb_control_msg: request: 0x1, requesttype: 0x23, value 0x14 index 0x2 length > 0x0 > clear port reset change, actual port 2 status = 0x603 > > > => When Port 1 is populated: > usb_control_msg: request: 0x1, requesttype: 0x23, value 0x10 index 0x2 length > 0x0 > clear port connect change, actual port 2 status = 0x6e1 > ... > usb_control_msg: request: 0x3, requesttype: 0x23, value 0x4 index 0x2 length > 0x0 > ... > usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x2 length > 0x4 > SPEED = FULLSPEED > ... > usb_control_msg: request: 0x3, requesttype: 0x23, value 0x4 index 0x2 length > 0x0 > ... > usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x2 length > 0x4 > SPEED = HIGHSPEED > ... > usb_control_msg: request: 0x1, requesttype: 0x23, value 0x14 index 0x2 length > 0x0 > clear port reset change, actual port 2 status = 0xe03 > > When Port 1 is populated, Port 2 status correctly switches to HIGHSPEED, > but why ? > This looks really strange. Sounds like a hardware internal state depends on the first USB port. Do you know if Linux works? Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] dm: spi: Return 0 if driver does not implement ops->cs_info
On Thu, Aug 29, 2019 at 7:40 PM Bin Meng wrote: > > If an SPI controller driver does not implement ops->cs_info, that > probably means any chip select number could be valid, hence let's > return 0 for spi_cs_info(). > > Signed-off-by: Bin Meng > --- Reviewed-by: Jagan Teki ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] MTD: SPI: revert removing SST26* flash IC protection ops
On Wed, Sep 4, 2019 at 11:37 PM Eugeniy Paltsev
wrote:
>
> Commit c4e8862308d4 (mtd: spi: Switch to new SPI NOR framework)
> performs switch from previous 'spi_flash' infrastructure without
> proper testing/investigations which results in regressions.
>
> Fix regression related to SST26 flash IC series which is lacking
> protection ops implementation which were introduced previously by
> Commit 3d4fed87a5fa (mtd: sf: Add support of sst26wf* flash ICs
> protection ops)
>
> Signed-off-by: Eugeniy Paltsev
> ---
> Tom, could you please pick this patch to 2019.10?
>
> drivers/mtd/spi/sf_internal.h | 1 +
> drivers/mtd/spi/spi-nor-core.c | 181 +
> drivers/mtd/spi/spi-nor-ids.c | 8 +-
> include/linux/mtd/spi-nor.h| 4 +
> 4 files changed, 190 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/mtd/spi/sf_internal.h b/drivers/mtd/spi/sf_internal.h
> index a6bf734830a..e6da768bf36 100644
> --- a/drivers/mtd/spi/sf_internal.h
> +++ b/drivers/mtd/spi/sf_internal.h
> @@ -65,6 +65,7 @@ struct flash_info {
> #define NO_CHIP_ERASE BIT(12) /* Chip does not support chip erase */
> #define SPI_NOR_SKIP_SFDP BIT(13) /* Skip parsing of SFDP tables */
> #define USE_CLSR BIT(14) /* use CLSR command */
> +#define SPI_NOR_HAS_SST26LOCK BIT(15) /* Flash supports lock/unlock via BPR
> */
> };
>
> extern const struct flash_info spi_nor_ids[];
> diff --git a/drivers/mtd/spi/spi-nor-core.c b/drivers/mtd/spi/spi-nor-core.c
> index 1acff745d1a..990e39d7c2f 100644
> --- a/drivers/mtd/spi/spi-nor-core.c
> +++ b/drivers/mtd/spi/spi-nor-core.c
> @@ -945,6 +945,177 @@ read_err:
> }
>
> #ifdef CONFIG_SPI_FLASH_SST
> +/*
> + * sst26 flash series has its own block protection implementation:
> + * 4x - 8 KByte blocks - read & write protection bits - upper addresses
> + * 1x - 32 KByte blocks - write protection bits
> + * rest - 64 KByte blocks - write protection bits
> + * 1x - 32 KByte blocks - write protection bits
> + * 4x - 8 KByte blocks - read & write protection bits - lower addresses
> + *
> + * We'll support only per 64k lock/unlock so lower and upper 64 KByte region
> + * will be treated as single block.
> + */
> +#define SST26_BPR_8K_NUM 4
> +#define SST26_MAX_BPR_REG_LEN (18 + 1)
> +#define SST26_BOUND_REG_SIZE ((32 + SST26_BPR_8K_NUM * 8) * SZ_1K)
> +
> +enum lock_ctl {
> + SST26_CTL_LOCK,
> + SST26_CTL_UNLOCK,
> + SST26_CTL_CHECK
> +};
> +
> +static bool sst26_process_bpr(u32 bpr_size, u8 *cmd, u32 bit, enum lock_ctl
> ctl)
> +{
> + switch (ctl) {
> + case SST26_CTL_LOCK:
> + cmd[bpr_size - (bit / 8) - 1] |= BIT(bit % 8);
> + break;
> + case SST26_CTL_UNLOCK:
> + cmd[bpr_size - (bit / 8) - 1] &= ~BIT(bit % 8);
> + break;
> + case SST26_CTL_CHECK:
> + return !!(cmd[bpr_size - (bit / 8) - 1] & BIT(bit % 8));
> + }
> +
> + return false;
> +}
> +
> +/*
> + * Lock, unlock or check lock status of the flash region of the flash
> (depending
> + * on the lock_ctl value)
> + */
> +static int sst26_lock_ctl(struct spi_nor *nor, loff_t ofs, uint64_t len,
> enum lock_ctl ctl)
> +{
> + struct mtd_info *mtd = >mtd;
> + u32 i, bpr_ptr, rptr_64k, lptr_64k, bpr_size;
> + bool lower_64k = false, upper_64k = false;
> + u8 bpr_buff[SST26_MAX_BPR_REG_LEN] = {};
> + int ret;
> +
> + /* Check length and offset for 64k alignment */
> + if ((ofs & (SZ_64K - 1)) || (len & (SZ_64K - 1))) {
> + dev_err(nor->dev, "length or offset is not 64KiB
> allighned\n");
> + return -EINVAL;
> + }
> +
> + if (ofs + len > mtd->size) {
> + dev_err(nor->dev, "range is more than device size: %#llx +
> %#llx > %#llx\n",
> + ofs, len, mtd->size);
> + return -EINVAL;
> + }
> +
> + /* SST26 family has only 16 Mbit, 32 Mbit and 64 Mbit IC */
> + if (mtd->size != SZ_2M &&
> + mtd->size != SZ_4M &&
> + mtd->size != SZ_8M)
> + return -EINVAL;
> +
> + bpr_size = 2 + (mtd->size / SZ_64K / 8);
> +
> + ret = nor->read_reg(nor, SPINOR_OP_READ_BPR, bpr_buff, bpr_size);
> + if (ret < 0) {
> + dev_err(nor->dev, "fail to read block-protection register\n");
> + return ret;
> + }
> +
> + rptr_64k = min_t(u32, ofs + len, mtd->size - SST26_BOUND_REG_SIZE);
> + lptr_64k = max_t(u32, ofs, SST26_BOUND_REG_SIZE);
> +
> + upper_64k = ((ofs + len) > (mtd->size - SST26_BOUND_REG_SIZE));
> + lower_64k = (ofs < SST26_BOUND_REG_SIZE);
> +
> + /* Lower bits in block-protection register are about 64k region */
> + bpr_ptr = lptr_64k / SZ_64K - 1;
> +
> + /* Process 64K blocks region */
> + while (lptr_64k < rptr_64k) {
> + if (sst26_process_bpr(bpr_size,
Re: [U-Boot] [PATCH] Revert "spi: Kconfig: Mark MXS_SPI has DEPRECATED"
On Sat, Sep 7, 2019 at 4:32 AM Tom Rini wrote:
>
> On Fri, Sep 06, 2019 at 11:32:46PM +0200, Lukasz Majewski wrote:
> > Hi Jagan,
> >
> > > On Thu, Aug 1, 2019 at 9:27 PM Lukasz Majewski wrote:
> > > >
> > > > This reverts commit d5ded320a14b0a2f97cbed072286748895ad18ac.
> > >
> > > This wouldn't be a revert.
> > >
> > > The deprecated patch been merged in May, 29 and
> > >
> > > >
> > > > The mxs_spi.c driver for i.MX2{38} devices has been converted:
> > > > 'commit d99b018a6e3d ("spi: mxs: Add support DM/DTS for i.MX28 mxs
> > > > SPI driver (DM_SPI conversion)")'
> > >
> > > This was merged in June, 19 so please send a separate patch.
> >
> > Cannot we just revert the patch? Is there any issue or technical
> > problem with doing that ?
>
> To me it's a fairly odd to say revert. It's "re-enable" of support.
> That said, Jagan, can you just reword the commit or something? It needs
> to go in either way and the contents don't change. Thanks all!
Updated the commit message, and
Applied to u-boot-spi/master
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] XHCI behavior
Hi, I am seeing crashes in our XHCI implementation based on a Designware USB 3.1 core. One thing I noticed is that this core sets the PAE bit in the HCCparams. The result of this is that when there is a short packet and there are two TDs, then when PAE is set there will be two responses with the second one being success. I'm still not sure if the length field I'm seeing is correct or not, but it appears that neither Linux nor U-Boot can handle HCs with the PAE bit set. See the eXtendable Host Controller Interface 1.1 sections 4.10.1.1 and 5.3.6. With short packets with the PAE bit set with to TRBs I get two responses when the data fits in the first TRB. The first event TRB contains a short packet response with the length set to the amount of space within the first TRB that is actually used. The second TRB event is a success completion code, as is described in section 4.10.1.1.1. Personally I find this PAE bit a major pain in the arse that causes more trouble than it's worth. -Aaron -- Aaron Williams Senior Software Engineer Marvell Semiconductor, Inc. (408) 943-7198 (510) 789-8988 (cell) signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] please pull u-boot-samsung master
On Fri, Sep 06, 2019 at 05:42:36PM +0900, Minkyu Kang wrote: > Dear Tom, > > The following changes since commit 448f11f7503995746a7b71e5e3b3a831c4651be9: > > Merge tag 'arc-for-2019.10-rc4' of > https://gitlab.denx.de/u-boot/custodians/u-boot-arc (2019-09-03 12:40:50 > -0400) > > are available in the git repository at: > > > g...@gitlab.denx.de:u-boot/custodians/u-boot-samsung.git master > > for you to fetch changes up to d7441d8a9ac9602afa92bf2649890a2208ffada1: > > ARM: exynos5: Try to boot on mmc2 before mmc0/1 (2019-09-05 18:36:59 > +0900) > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Pull request for UEFI sub-system for v2019.10-rc4 (3)
On Fri, Sep 06, 2019 at 09:27:45AM +0200, Heinrich Schuchardt wrote: > The following changes since commit ece9834f7d223097cec92e3d3c70cd37b3768482: > > Merge branch 'master' of > https://gitlab.denx.de/u-boot/custodians/u-boot-net (2019-09-04 16:02:03 > -0400) > > are available in the Git repository at: > > https://gitlab.denx.de/u-boot/custodians/u-boot-efi.git > tags/efi-2019-10-rc4-3 > > for you to fetch changes up to fe1a81c1a47737d3ce6b6855a05468b7546d4982: > > doc: UEFI API documentation (2019-09-05 23:18:52 +0200) > > No problems where observed in Gitlab: > https://gitlab.denx.de/u-boot/custodians/u-boot-efi/pipelines/620 > > Primary key fingerprint: > 6DC4 F9C7 1F29 A6FA 06B7 6D33 C481 DBBC 2C05 1AC4 Applied to u-boot/master, thanks! But we've once again applied a PR that gives every board that enables EFI loader 1KiB or so of growth. Are there things we can do here? -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] riscv: image: save space on the magic number field
Hi,
Chester Lin 於 2019年9月6日 週五 下午3:28寫道：
>
> Change the symbol from "RISCV" to "RSCV" so the magic number can be 32-bit
> long, which is consistent with other architectures.
>
> Signed-off-by: Chester Lin
> ---
> arch/riscv/lib/image.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/arch/riscv/lib/image.c b/arch/riscv/lib/image.c
> index d063beb7df..e8a8cb7190 100644
> --- a/arch/riscv/lib/image.c
> +++ b/arch/riscv/lib/image.c
> @@ -14,8 +14,8 @@
>
> DECLARE_GLOBAL_DATA_PTR;
>
> -/* ASCII version of "RISCV" defined in Linux kernel */
> -#define LINUX_RISCV_IMAGE_MAGIC 0x5643534952
> +/* ASCII version of "RSCV" defined in Linux kernel */
> +#define LINUX_RISCV_IMAGE_MAGIC 0x56435352
>
> struct linux_image_h {
> uint32_tcode0; /* Executable code */
> @@ -25,8 +25,8 @@ struct linux_image_h {
> uint64_tres1; /* reserved */
> uint64_tres2; /* reserved */
> uint64_tres3; /* reserved */
> - uint64_tmagic; /* Magic number */
> - uint32_tres4; /* reserved */
> + uint64_tres4; /* reserved */
> + uint32_tmagic; /* Magic number */
> uint32_tres5; /* reserved */
> };
>
> --
> 2.20.1
>
Sorry for sending this patch again by a personal email account because
somehow I can't send an email to the mailing list by my company email.
I always got rejected by a middle server.
Anyway, I have submitted a patch to the kernel mailing lists as well.
Here is a reference link:
https://lkml.org/lkml/2019/9/6/80
Regards,
Chester
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] tpm2: Don't assume active low reset value
The reset function sets the pin to 0 then 1 but if the pin is marked
ACTIVE_LOW in the DT it gets inverted and leaves the TPM in reset.
Let the gpio driver take care of the reset polarity.
Signed-off-by: Kayla Theil
---
drivers/tpm/tpm2_tis_spi.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/tpm/tpm2_tis_spi.c b/drivers/tpm/tpm2_tis_spi.c
index 7186c179d1..3d105fddba 100644
--- a/drivers/tpm/tpm2_tis_spi.c
+++ b/drivers/tpm/tpm2_tis_spi.c
@@ -596,9 +596,9 @@ static int tpm_tis_spi_probe(struct udevice *dev)
log(LOGC_NONE, LOGL_NOTICE, "%s: missing reset GPIO\n",
__func__);
} else {
- dm_gpio_set_value(_gpio, 0);
- mdelay(1);
dm_gpio_set_value(_gpio, 1);
+ mdelay(1);
+ dm_gpio_set_value(_gpio, 0);
}
}
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] riscv: image: save space on the magic number field
From: Chester Lin
Change the symbol from "RISCV" to "RSCV" so the magic number can be 32-bit
long, which is consistent with other architectures.
Signed-off-by: Chester Lin
---
arch/riscv/lib/image.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/riscv/lib/image.c b/arch/riscv/lib/image.c
index d063beb7df..e8a8cb7190 100644
--- a/arch/riscv/lib/image.c
+++ b/arch/riscv/lib/image.c
@@ -14,8 +14,8 @@
DECLARE_GLOBAL_DATA_PTR;
-/* ASCII version of "RISCV" defined in Linux kernel */
-#define LINUX_RISCV_IMAGE_MAGIC 0x5643534952
+/* ASCII version of "RSCV" defined in Linux kernel */
+#define LINUX_RISCV_IMAGE_MAGIC 0x56435352
struct linux_image_h {
uint32_tcode0; /* Executable code */
@@ -25,8 +25,8 @@ struct linux_image_h {
uint64_tres1; /* reserved */
uint64_tres2; /* reserved */
uint64_tres3; /* reserved */
- uint64_tmagic; /* Magic number */
- uint32_tres4; /* reserved */
+ uint64_tres4; /* reserved */
+ uint32_tmagic; /* Magic number */
uint32_tres5; /* reserved */
};
--
2.20.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] Revert "spi: Kconfig: Mark MXS_SPI has DEPRECATED"
On Fri, Sep 06, 2019 at 11:32:46PM +0200, Lukasz Majewski wrote:
> Hi Jagan,
>
> > On Thu, Aug 1, 2019 at 9:27 PM Lukasz Majewski wrote:
> > >
> > > This reverts commit d5ded320a14b0a2f97cbed072286748895ad18ac.
> >
> > This wouldn't be a revert.
> >
> > The deprecated patch been merged in May, 29 and
> >
> > >
> > > The mxs_spi.c driver for i.MX2{38} devices has been converted:
> > > 'commit d99b018a6e3d ("spi: mxs: Add support DM/DTS for i.MX28 mxs
> > > SPI driver (DM_SPI conversion)")'
> >
> > This was merged in June, 19 so please send a separate patch.
>
> Cannot we just revert the patch? Is there any issue or technical
> problem with doing that ?
To me it's a fairly odd to say revert. It's "re-enable" of support.
That said, Jagan, can you just reword the commit or something? It needs
to go in either way and the contents don't change. Thanks all!
--
Tom
signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] rpi3: Enable verified boot from FIT image
On 9/6/19 11:04 PM, Simon Glass wrote: Hi Heinrich, U-Boot is the main boot loader for ARM. I wish that distros would just support it (adding what is needed) instead of trying to pretend that U-Boot is a variant of UEFI :-) Distros may have a different viewpoint than you. They may not want to add anything boot loader specific and are happy if all systems independent of their architecture can be booted in the same way, e.g. via UEFI and GRUB. Cf. https://fedoraproject.org/wiki/Changes/uEFIforARMv7 Currently OpenBSD, FreeBSD, Fedora, and Suse rely on booting via UEFI. And Debian is ready for it. That U-Boot implements the UEFI API and this is in wide use in no way contradicts U-Boot being the main boot loader for ARM. Nothing pretended here ¯\_(ツ)_/¯ Regards Heinrich ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Using CONFIG_ENV_FLAGS_LIST
Hi Claudius, > Hi, > > I am currently looking into variable flags in order to make some > variables read-only for secure boot. > > The idea is that the u-boot binary is signed, while the environment > file/partition is not. So the built-in default environment of u-boot > can be trusted, while the external environment cannot. The assumption > is that those flags can be used to customize the validation when the > external environment is loaded or scripts/commands are executed. > > From the '/README' I gather that the access attributes can be any of > "any", "read-only", "write-once" or "change-default". > > I first tried to restrict the variables by choosing 'read-only', but > apparently this applies to the internal environment as well, and now > those variables are not loaded from the internal environment. > > Then I tried 'write-once', this worked now as expected from within > u-boot, but I could modify the environment from the linux userspace > via fw_setenv and those changes appear in u-boot as well. The same for > 'change-default'. > > Is there another way to fill the internal environment variable hash > table, so that 'read-only' works as expected? > > Heiko wrote some patches that change the behavior of the environment > loading so that the internal environment is loaded first before the > external environment. This way 'write-once' should work as expected, > but I think 'read-only' should work that way already and we are > missing something here. I think that Wolfgang had a long discussion with Takahiro AKASHI (both CC'ed) about similar problem with u-boot envs. For example: https://patchwork.ozlabs.org/patch/1158770/ > > Thanks, > Claudius > Best regards, Lukasz Majewski -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lu...@denx.de pgpICVLMFd2UJ.pgp Description: OpenPGP digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] Revert "spi: Kconfig: Mark MXS_SPI has DEPRECATED"
Hi Jagan,
> On Thu, Aug 1, 2019 at 9:27 PM Lukasz Majewski wrote:
> >
> > This reverts commit d5ded320a14b0a2f97cbed072286748895ad18ac.
>
> This wouldn't be a revert.
>
> The deprecated patch been merged in May, 29 and
>
> >
> > The mxs_spi.c driver for i.MX2{38} devices has been converted:
> > 'commit d99b018a6e3d ("spi: mxs: Add support DM/DTS for i.MX28 mxs
> > SPI driver (DM_SPI conversion)")'
>
> This was merged in June, 19 so please send a separate patch.
Cannot we just revert the patch? Is there any issue or technical
problem with doing that ?
> I was
> expected this changes would be part of dm spi conversion on that
> driver.
Ok.
Best regards,
Lukasz Majewski
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lu...@denx.de
pgp7whak9gGv5.pgp
Description: OpenPGP digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] dm: core: Decouple DM from DT
On Sun, 1 Sep 2019 at 09:28, Marek Vasut wrote: > > Some of the DM functions depend on OF_CONTROL, which is incorrect. > DM and DT are orthogonal. Add macro guards around such functions to > avoid compiling them in when DM is enabled, while OF_CONTROL is not. > > Signed-off-by: Marek Vasut > Cc: Simon Glass > --- > drivers/core/device.c | 4 > drivers/core/root.c | 8 +--- > drivers/core/util.c | 2 ++ > 3 files changed, 7 insertions(+), 7 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] spl: Introduce SPL_DM_GPIO Kconfig define
On Tue, 3 Sep 2019 at 07:16, Lukasz Majewski wrote: > > This define indicates if DM_GPIO shall be supported in SPL. This allows > proper operation of DM converted GPIO drivers in SPL, which use > #if !CONFIG_IS_ENABLED(DM_GPIO) to also support not yet DM/DTS converted > boards. > > Signed-off-by: Lukasz Majewski > --- > > common/spl/Kconfig | 6 ++ > 1 file changed, 6 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] doc: fix: Replace SPL_OF_PLATDATA with OF_PLATDATA in examples
On Tue, 3 Sep 2019 at 06:43, Lukasz Majewski wrote: > > The of-plat.rst file till this change has been using > > This is at best misleading as SPL_OF_PLATDATA is always defined when we > want to use this SPL tinification feature (also in U-Boot proper). > As a result the OF_PLATDATA SPL specific code is also compiled in when > U-Boot proper is build. > > Signed-off-by: Lukasz Majewski > Reviewed-by: Peng Fan > > --- > > doc/driver-model/of-plat.rst | 8 > 1 file changed, 4 insertions(+), 4 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] rpi3: Enable verified boot from FIT image
Hi Heinrich,
On Mon, 2 Sep 2019 at 04:24, Heinrich Schuchardt wrote:
>
> On 9/2/19 12:30 PM, Matthias Brugger wrote:
> > +Alex, Lukas, Heinrich, Bin and Simon
> >
> > On 31/07/2019 10:16, Jun Nie wrote:
> >> Matthias Brugger 于2019年7月31日周三 下午4:05写道：
> >>>
> >>>
> >>>
> >>> On 11/07/2019 05:55, Jun Nie wrote:
> Enable verified boot from FIT image with select configs
> and specify boot script image node in FIT image, the FIT
> image is verified before it is run.
>
> Code that reusing dtb in firmware is disabled, so that
> the dtb with pubic key packed in u-boot.bin can be used
> to verify the signature of next stage FIT image.
>
> Signed-off-by: Jun Nie
> ---
> board/raspberrypi/rpi/rpi.c | 6 ++
> include/configs/rpi.h | 15 ++-
> 2 files changed, 20 insertions(+), 1 deletion(-)
>
> diff --git a/board/raspberrypi/rpi/rpi.c b/board/raspberrypi/rpi/rpi.c
> index 617c892..950ee84 100644
> --- a/board/raspberrypi/rpi/rpi.c
> +++ b/board/raspberrypi/rpi/rpi.c
> @@ -297,6 +297,7 @@ static void set_fdtfile(void)
> env_set("fdtfile", fdtfile);
> }
>
> +#ifndef CONFIG_FIT_SIGNATURE
> /*
> * If the firmware provided a valid FDT at boot time, let's expose it
> in
> * ${fdt_addr} so it may be passed unmodified to the kernel.
> @@ -311,6 +312,7 @@ static void set_fdt_addr(void)
>
> env_set_hex("fdt_addr", fw_dtb_pointer);
> }
> +#endif
>
> /*
> * Prevent relocation from stomping on a firmware provided FDT blob.
> @@ -393,7 +395,9 @@ static void set_serial_number(void)
>
> int misc_init_r(void)
> {
> +#ifndef CONFIG_FIT_SIGNATURE
> set_fdt_addr();
> +#endif
> set_fdtfile();
> set_usbethaddr();
> #ifdef CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG
> @@ -470,6 +474,7 @@ int board_init(void)
> return bcm2835_power_on_module(BCM2835_MBOX_POWER_DEVID_USB_HCD);
> }
>
> +#ifndef CONFIG_FIT_SIGNATURE
> /*
> * If the firmware passed a device tree use it for U-Boot.
> */
> @@ -479,6 +484,7 @@ void *board_fdt_blob_setup(void)
> return NULL;
> return (void *)fw_dtb_pointer;
> }
> +#endif
> >>>
> >>> Just to get this clear we need this because we want to pass the device
> >>> tree via
> >>> OF_SEPARATE, correct?
> >>
> >> You are right. U-boot need to read he signature from dtb.
> >>
> >>>
>
> int ft_board_setup(void *blob, bd_t *bd)
> {
> diff --git a/include/configs/rpi.h b/include/configs/rpi.h
> index f76c7d1..ba91205 100644
> --- a/include/configs/rpi.h
> +++ b/include/configs/rpi.h
> @@ -180,11 +180,24 @@
>
> #include
>
> +#ifdef CONFIG_FIT_SIGNATURE
> +#define FIT_BOOT_CMD \
> + "boot_a_script="\
> + "load ${devtype} ${devnum}:${distro_bootpart} " \
> + "${scriptaddr} ${prefix}${script}; "\
> + "iminfo ${scriptaddr};" \
> + "if test $? -eq 1; then reset; fi;" \
> + "source ${scriptaddr}:bootscr\0"
> +#else
> +#define FIT_BOOT_CMD ""
> +#endif
> +
> >>>
> >>> Doesn't this overwrite the boot_a_script in distro_bootcmd?
> >>>
> >>> Would it make sense to add FIT booting to the distro boot command?
> >>>
> >>> Regards,
> >>> Matthias
> >>
> >> Yes, it overwrite the boot_a_script in distro_bootcmd. It is make
> >> sense to add this to the distro boot command. I can send another patch
> >> to move these lines to common code later.
> >>
> >
> > Question to the people just added, as you have relevant submission to
> > distroboot. Do you think it makes sense to add FIT_BOOT_CMD to that?
> >
> > Regards,
> > Matthias
>
> The idea of distro-boot was to make it easier for Linux distributions to
> update the information needed by U-Boot to find the right kernel and
> ramdisk.
>
> According to doc/README.distro file extlinux.conf should be used for the
> communication between the distribution and U-Boot. Some distributions
> like Debian still rely on boot.scr.
>
> Many distributions (OpenBSD, FreeBSD, Suse, Fedora) have moved from
> distro-boot to UEFI as booting standard. Unfortunately we have not
> documented our support for this in doc/README.distro (TODO for me).
> Takahiro is working on secure boot using UEFI. Once completed this could
> obsolete FIT images.
Oh please no.
>
> Would we expect Linux distributions to provide FIT images upon kernel
> updates?
> Is there any Linux distribution doing so?
>
> Only if we can answer these questions with yes, adding FIT_BOOT_CMD to
Re: [U-Boot] [PATCH] spi: soft_spi: Fix data abort if slave is not probed
On Fri, Aug 2, 2019 at 7:16 PM Patrice Chotard wrote: > > From: Christophe Kerello > > In case spi_get_bus_and_cs callback is used, spi bus is first probed > then slave devices are probed. To avoid a data abort in soft_spi probe > function, we need to check that (slave != NULL). > > If slave is NULL, cs_flags and clk_flags will be initialized with > respectively GPIOD_ACTIVE_LOW and 0. > > Signed-off-by: Christophe Kerello > Signed-off-by: Patrice Chotard > --- Applied to u-boot-spi/master ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] sunxi: video: HDMI: Fix LCD clock divider
On Sat, Aug 10, 2019 at 2:00 AM Mark Kettenis wrote:
>
> Currently we may end up with an LCD clock divider that differs from
> the HDMI PHY clock divider if we can't exactly match the pixel clock.
> Fix this by using DIV_ROUND_UP to calculate the divider. This works
> since the PLL is chosen such that the resulting pixel clock is
> never higher than the requested pixel clock.
>
> Fixes: 1feed358ed15 ("sunxi: video: HDMI: Fix clock setup")
>
> Signed-off-by: Mark Kettenis
> ---
Acked-by: Jagan Teki
Moved, to Anatolij on pw
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] sunxi: Fix pll1 clock calculation
On Wed, Jul 31, 2019 at 6:46 PM Stefan Mavrodiev wrote: > > clock_sun6i.c is used for sun6i, sun8i and sun50i SoC families. > PLL1 clock sets the default system clock, defined as: > sun6i: 100800 > sun8i: 100800 > sun50i: 81600 > > With the current calculation, m = 2 and k = 3. Solving for n, > this results 28. Solving back: > (24MHz * 28 * 3) / 2 = 1008MHz > > However if the requested clock is 816, n is 22.66 rounded > to 22, which results: > (24MHz * 28 * 3) / 2 = 792MHz > > Changing k to 4 satisfies both system clocks: > (24E6 * 21 * 4) / 2 = 1008MHz > (24E6 * 17 * 4) / 2 = 816MHz > > Signed-off-by: Stefan Mavrodiev > --- Acked-by: Jagan Teki Need to test on respective sun boards, any results? ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2] sunxi: Add H6 SPI SPL support
On Fri, Jul 26, 2019 at 2:26 PM Marek Kraus wrote: > > Add H6 SPI addresses and masks > (since H6 memory map is totally different). > Tested on Pine H64 rev B with Winbond W25Q128FW, > > Signed-off-by: Marek Kraus > Cc: Jagan Teki > --- Reviewed-by: Jagan Teki ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] Revert "spi: Kconfig: Mark MXS_SPI has DEPRECATED"
On Thu, Aug 1, 2019 at 9:27 PM Lukasz Majewski wrote:
>
> This reverts commit d5ded320a14b0a2f97cbed072286748895ad18ac.
This wouldn't be a revert.
The deprecated patch been merged in May, 29 and
>
> The mxs_spi.c driver for i.MX2{38} devices has been converted:
> 'commit d99b018a6e3d ("spi: mxs: Add support DM/DTS for i.MX28 mxs SPI driver
> (DM_SPI conversion)")'
This was merged in June, 19 so please send a separate patch. I was
expected this changes would be part of dm spi conversion on that
driver.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [GIT PULL] rpi: updates for v2019.10
Hi Tom, Please have a look on the following updates for Raspberry Pi. Especially we introduce basic RPi4 support \o/ I did some mistake while creating the tag, so I had to fix the rebase and overwrite the tag. That's why travis-ci [1] is not yet finished. Nevertheless travis-ci finished successfully with the old tag (same patches but different base) [2]. Regards, Matthias [1] https://travis-ci.org/mbgg/u-boot/builds/581754574 [2] https://travis-ci.org/mbgg/u-boot/builds/581603847 --- The following changes since commit d39221f33f0e78cc80d1304ab4ca4e4a3886fbff: Prepare v2019.10-rc3 (2019-08-26 20:16:42 -0400) are available in the Git repository at: https://github.com/mbgg/u-boot.git tags/rpi-next-2019.10 for you to fetch changes up to e0351b242a9bf60dd6abdfd44104bb702e7000a0: git-mailrc: Add rpi and bcm283x maintainer (2019-09-06 18:16:59 +0200) - fix mailbox status register used for polling - fix bcm2835_sdhost to wait long enough for a transfer to complete - increase kernel image size from 8 MB to 64 MB on arm64 - add support for RPi4 - add prefixes for raspberry pi related stuff to git-mailrc Andrei Gherzan (6): RPI: Add defconfigs for rpi4 (32/64) ARM: bcm283x: Define configs for RaspberryPi 4 RPI: Add entry for Raspberry Pi 4 model B ARM: bcm283x: Include definition for additional emmc clock RPI: Add memory map for bcm2711 git-mailrc: Add rpi and bcm283x maintainer Bonnans, Laurent (1): rpi: increase SYS_BOOTM_LEN to 64M on ARM64 Fabian Vogt (1): ARM: bcm283x mbox: Fix send status register Matthias Brugger (2): ARM: bcm283x: Add BCM283x_BASE define mmc: bcm283x: Add support for bcm2711 device in bcm2835_sdhci Raul Benet (1): mmc: bcm2835-host: Fix wait_transfer_complete arch/arm/mach-bcm283x/Kconfig | 67 ++ arch/arm/mach-bcm283x/include/mach/mbox.h | 14 +++ arch/arm/mach-bcm283x/include/mach/sdhci.h | 6 +-- arch/arm/mach-bcm283x/include/mach/timer.h | 6 +-- arch/arm/mach-bcm283x/include/mach/wdog.h | 6 +-- arch/arm/mach-bcm283x/mbox.c | 6 +-- board/raspberrypi/rpi/rpi.c| 32 -- configs/rpi_4_32b_defconfig| 33 +++ configs/rpi_4_defconfig| 33 +++ doc/git-mailrc | 4 ++ drivers/mmc/bcm2835_sdhci.c| 12 +- drivers/mmc/bcm2835_sdhost.c | 12 +++--- include/configs/rpi.h | 4 ++ 13 files changed, 200 insertions(+), 35 deletions(-) create mode 100644 configs/rpi_4_32b_defconfig create mode 100644 configs/rpi_4_defconfig ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] dm: device: Request next sequence number
Hi Thomas,
On Fri, Sep 6, 2019 at 7:52 PM Thomas Fitzsimmons wrote:
>
> For CONFIG_OF_PRIOR_STAGE, in the absence of a device tree alias for a
> given device, use the next request number for that type of device.
> This allows aliases to be used when they're available, while still
> allowing unaliased devices to be probed.
>
> Signed-off-by: Thomas Fitzsimmons
> Cc: Bin Meng
> Cc: Simon Glass
> ---
> drivers/core/device.c | 5 +
> drivers/core/uclass.c | 4 +++-
> 2 files changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/core/device.c b/drivers/core/device.c
> index 474c1642ee..ca8be208a9 100644
> --- a/drivers/core/device.c
> +++ b/drivers/core/device.c
> @@ -82,6 +82,11 @@ static int device_bind_common(struct udevice *parent,
> const struct driver *drv,
> if (CONFIG_IS_ENABLED(OF_CONTROL) &&
> !CONFIG_IS_ENABLED(OF_PLATDATA)) {
> if (uc->uc_drv->name && ofnode_valid(node))
> dev_read_alias_seq(dev, >req_seq);
> +#if CONFIG_IS_ENABLED(OF_PRIOR_STAGE)
I was wondering whether we should limit such only for OF_PRIOR_STATE,
instead change the behaviors for all DM devices.
Because as I pointed out in
https://lists.denx.de/pipermail/u-boot/2019-August/382368.html, it
seems there are quite some codes in the existing code base that tried
to workaround such limitation in their own way.
> + if (dev->req_seq == -1)
> + dev->req_seq =
> +
> uclass_find_next_free_req_seq(drv->id);
> +#endif
> } else {
> dev->req_seq = uclass_find_next_free_req_seq(drv->id);
> }
> diff --git a/drivers/core/uclass.c b/drivers/core/uclass.c
> index b33296542f..d7aedac351 100644
> --- a/drivers/core/uclass.c
> +++ b/drivers/core/uclass.c
> @@ -269,7 +269,9 @@ int uclass_find_device_by_name(enum uclass_id id, const
> char *name,
> return -ENODEV;
> }
>
> -#if !CONFIG_IS_ENABLED(OF_CONTROL) || CONFIG_IS_ENABLED(OF_PLATDATA)
> +#if !CONFIG_IS_ENABLED(OF_CONTROL) || \
> +CONFIG_IS_ENABLED(OF_PLATDATA) || \
> +CONFIG_IS_ENABLED(OF_PRIOR_STAGE)
> int uclass_find_next_free_req_seq(enum uclass_id id)
> {
> struct uclass *uc;
> --
Regards,
Bin
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] rpi4: enable dram bank initialization
On 06/09/2019 15:03, Alexander Graf wrote:
>
> On 06.09.19 14:58, Matthias Brugger wrote:
>>
>> On 06/09/2019 14:11, Alexander Graf wrote:
>>> On 06.09.19 13:56, matthias@kernel.org wrote:
From: Matthias Brugger
When booting through the efi stub, the memory map get's created by
reading the dram bank information. Depending on the version of the RPi4
this information changes. Read the device tree to initialize the dram
bank data structure. This way the kernel is able to access the whole
range of available memory.
Signed-off-by: Matthias Brugger
---
This patch is based on basic RPi4 support implemented by series:
https://www.mail-archive.com/u-boot@lists.denx.de/msg335667.html
To actually work correctly we need the series that fixes the libftd:
https://patchwork.ozlabs.org/cover/1158304/
board/raspberrypi/rpi/rpi.c | 8
configs/rpi_4_defconfig | 2 +-
2 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/board/raspberrypi/rpi/rpi.c b/board/raspberrypi/rpi/rpi.c
index fa57d50c95..eea8a69551 100644
--- a/board/raspberrypi/rpi/rpi.c
+++ b/board/raspberrypi/rpi/rpi.c
@@ -312,6 +312,14 @@ int dram_init(void)
return 0;
}
+#ifdef CONFIG_BCM2711
+int dram_init_banksize(void)
+{
+ return fdtdec_decode_ram_size(gd->fdt_blob, NULL, 0, NULL,
>>>
>>> This also depends on CONFIG_OF_BOARD, no?
>>>
>> I would need to double check if at this point gd->fdt_blob is in it's final
>> state or might get updated afterwards.
>>
>> Actually I think we should change all RPi configs to OF_BOARD, which would
>> also
>> be necessary to implement a single binary for RPi3 and RPi4. But that's
>> another
>> story.
>
>
> Yes, but until then please fail compilation on !OF_BOARD if you know it can't
> work. Or create a Kconfig dependency.
>
Sounds like a plan, thanks :)
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] rpi4: enable dram bank initialization
On 06.09.19 14:58, Matthias Brugger wrote:
On 06/09/2019 14:11, Alexander Graf wrote:
On 06.09.19 13:56, matthias@kernel.org wrote:
From: Matthias Brugger
When booting through the efi stub, the memory map get's created by
reading the dram bank information. Depending on the version of the RPi4
this information changes. Read the device tree to initialize the dram
bank data structure. This way the kernel is able to access the whole
range of available memory.
Signed-off-by: Matthias Brugger
---
This patch is based on basic RPi4 support implemented by series:
https://www.mail-archive.com/u-boot@lists.denx.de/msg335667.html
To actually work correctly we need the series that fixes the libftd:
https://patchwork.ozlabs.org/cover/1158304/
board/raspberrypi/rpi/rpi.c | 8
configs/rpi_4_defconfig | 2 +-
2 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/board/raspberrypi/rpi/rpi.c b/board/raspberrypi/rpi/rpi.c
index fa57d50c95..eea8a69551 100644
--- a/board/raspberrypi/rpi/rpi.c
+++ b/board/raspberrypi/rpi/rpi.c
@@ -312,6 +312,14 @@ int dram_init(void)
return 0;
}
+#ifdef CONFIG_BCM2711
+int dram_init_banksize(void)
+{
+ return fdtdec_decode_ram_size(gd->fdt_blob, NULL, 0, NULL,
This also depends on CONFIG_OF_BOARD, no?
I would need to double check if at this point gd->fdt_blob is in it's final
state or might get updated afterwards.
Actually I think we should change all RPi configs to OF_BOARD, which would also
be necessary to implement a single binary for RPi3 and RPi4. But that's another
story.
Yes, but until then please fail compilation on !OF_BOARD if you know it
can't work. Or create a Kconfig dependency.
Alex
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] rpi4: enable dram bank initialization
On 06/09/2019 14:11, Alexander Graf wrote:
>
> On 06.09.19 13:56, matthias@kernel.org wrote:
>> From: Matthias Brugger
>>
>> When booting through the efi stub, the memory map get's created by
>> reading the dram bank information. Depending on the version of the RPi4
>> this information changes. Read the device tree to initialize the dram
>> bank data structure. This way the kernel is able to access the whole
>> range of available memory.
>>
>> Signed-off-by: Matthias Brugger
>> ---
>> This patch is based on basic RPi4 support implemented by series:
>> https://www.mail-archive.com/u-boot@lists.denx.de/msg335667.html
>>
>> To actually work correctly we need the series that fixes the libftd:
>> https://patchwork.ozlabs.org/cover/1158304/
>>
>> board/raspberrypi/rpi/rpi.c | 8
>> configs/rpi_4_defconfig | 2 +-
>> 2 files changed, 9 insertions(+), 1 deletion(-)
>>
>> diff --git a/board/raspberrypi/rpi/rpi.c b/board/raspberrypi/rpi/rpi.c
>> index fa57d50c95..eea8a69551 100644
>> --- a/board/raspberrypi/rpi/rpi.c
>> +++ b/board/raspberrypi/rpi/rpi.c
>> @@ -312,6 +312,14 @@ int dram_init(void)
>> return 0;
>> }
>> +#ifdef CONFIG_BCM2711
>> +int dram_init_banksize(void)
>> +{
>> + return fdtdec_decode_ram_size(gd->fdt_blob, NULL, 0, NULL,
>
>
> This also depends on CONFIG_OF_BOARD, no?
>
I would need to double check if at this point gd->fdt_blob is in it's final
state or might get updated afterwards.
Actually I think we should change all RPi configs to OF_BOARD, which would also
be necessary to implement a single binary for RPi3 and RPi4. But that's another
story.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] rpi4: enable dram bank initialization
On 06.09.19 13:56, matthias@kernel.org wrote:
From: Matthias Brugger
When booting through the efi stub, the memory map get's created by
reading the dram bank information. Depending on the version of the RPi4
this information changes. Read the device tree to initialize the dram
bank data structure. This way the kernel is able to access the whole
range of available memory.
Signed-off-by: Matthias Brugger
---
This patch is based on basic RPi4 support implemented by series:
https://www.mail-archive.com/u-boot@lists.denx.de/msg335667.html
To actually work correctly we need the series that fixes the libftd:
https://patchwork.ozlabs.org/cover/1158304/
board/raspberrypi/rpi/rpi.c | 8
configs/rpi_4_defconfig | 2 +-
2 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/board/raspberrypi/rpi/rpi.c b/board/raspberrypi/rpi/rpi.c
index fa57d50c95..eea8a69551 100644
--- a/board/raspberrypi/rpi/rpi.c
+++ b/board/raspberrypi/rpi/rpi.c
@@ -312,6 +312,14 @@ int dram_init(void)
return 0;
}
+#ifdef CONFIG_BCM2711
+int dram_init_banksize(void)
+{
+ return fdtdec_decode_ram_size(gd->fdt_blob, NULL, 0, NULL,
This also depends on CONFIG_OF_BOARD, no?
Alex
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] rpi4: enable dram bank initialization
From: Matthias Brugger
When booting through the efi stub, the memory map get's created by
reading the dram bank information. Depending on the version of the RPi4
this information changes. Read the device tree to initialize the dram
bank data structure. This way the kernel is able to access the whole
range of available memory.
Signed-off-by: Matthias Brugger
---
This patch is based on basic RPi4 support implemented by series:
https://www.mail-archive.com/u-boot@lists.denx.de/msg335667.html
To actually work correctly we need the series that fixes the libftd:
https://patchwork.ozlabs.org/cover/1158304/
board/raspberrypi/rpi/rpi.c | 8
configs/rpi_4_defconfig | 2 +-
2 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/board/raspberrypi/rpi/rpi.c b/board/raspberrypi/rpi/rpi.c
index fa57d50c95..eea8a69551 100644
--- a/board/raspberrypi/rpi/rpi.c
+++ b/board/raspberrypi/rpi/rpi.c
@@ -312,6 +312,14 @@ int dram_init(void)
return 0;
}
+#ifdef CONFIG_BCM2711
+int dram_init_banksize(void)
+{
+ return fdtdec_decode_ram_size(gd->fdt_blob, NULL, 0, NULL,
+(phys_size_t *)>ram_size, gd->bd);
+}
+#endif
+
static void set_fdtfile(void)
{
const char *fdtfile;
diff --git a/configs/rpi_4_defconfig b/configs/rpi_4_defconfig
index da8c960a2a..c639ac93de 100644
--- a/configs/rpi_4_defconfig
+++ b/configs/rpi_4_defconfig
@@ -4,7 +4,7 @@ CONFIG_SYS_TEXT_BASE=0x0008
CONFIG_TARGET_RPI_4=y
CONFIG_SYS_MALLOC_F_LEN=0x2000
CONFIG_DISTRO_DEFAULTS=y
-CONFIG_NR_DRAM_BANKS=1
+CONFIG_NR_DRAM_BANKS=2
# CONFIG_ARCH_FIXUP_FDT_MEMORY is not set
CONFIG_OF_BOARD=y
CONFIG_OF_BOARD_SETUP=y
--
2.22.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 2/2] dm: spi: Do not assume first SPI bus
When CONFIG_OF_PRIOR_STAGE is enabled, this workaround was needed before device_bind_common assigned request numbers sequentially in the absence of aliases. Signed-off-by: Thomas Fitzsimmons Cc: Bin Meng Cc: Simon Glass --- drivers/spi/spi-uclass.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/spi/spi-uclass.c b/drivers/spi/spi-uclass.c index 88cb2a1262..5e1f2232e5 100644 --- a/drivers/spi/spi-uclass.c +++ b/drivers/spi/spi-uclass.c @@ -275,7 +275,7 @@ int spi_get_bus_and_cs(int busnum, int cs, int speed, int mode, bool created = false; int ret; -#if CONFIG_IS_ENABLED(OF_PLATDATA) || CONFIG_IS_ENABLED(OF_PRIOR_STAGE) +#if CONFIG_IS_ENABLED(OF_PLATDATA) ret = uclass_first_device_err(UCLASS_SPI, ); #else ret = uclass_get_device_by_seq(UCLASS_SPI, busnum, ); -- 2.23.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/2] dm: device: Request next sequence number
For CONFIG_OF_PRIOR_STAGE, in the absence of a device tree alias for a
given device, use the next request number for that type of device.
This allows aliases to be used when they're available, while still
allowing unaliased devices to be probed.
Signed-off-by: Thomas Fitzsimmons
Cc: Bin Meng
Cc: Simon Glass
---
drivers/core/device.c | 5 +
drivers/core/uclass.c | 4 +++-
2 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/core/device.c b/drivers/core/device.c
index 474c1642ee..ca8be208a9 100644
--- a/drivers/core/device.c
+++ b/drivers/core/device.c
@@ -82,6 +82,11 @@ static int device_bind_common(struct udevice *parent, const
struct driver *drv,
if (CONFIG_IS_ENABLED(OF_CONTROL) &&
!CONFIG_IS_ENABLED(OF_PLATDATA)) {
if (uc->uc_drv->name && ofnode_valid(node))
dev_read_alias_seq(dev, >req_seq);
+#if CONFIG_IS_ENABLED(OF_PRIOR_STAGE)
+ if (dev->req_seq == -1)
+ dev->req_seq =
+ uclass_find_next_free_req_seq(drv->id);
+#endif
} else {
dev->req_seq = uclass_find_next_free_req_seq(drv->id);
}
diff --git a/drivers/core/uclass.c b/drivers/core/uclass.c
index b33296542f..d7aedac351 100644
--- a/drivers/core/uclass.c
+++ b/drivers/core/uclass.c
@@ -269,7 +269,9 @@ int uclass_find_device_by_name(enum uclass_id id, const
char *name,
return -ENODEV;
}
-#if !CONFIG_IS_ENABLED(OF_CONTROL) || CONFIG_IS_ENABLED(OF_PLATDATA)
+#if !CONFIG_IS_ENABLED(OF_CONTROL) || \
+CONFIG_IS_ENABLED(OF_PLATDATA) || \
+CONFIG_IS_ENABLED(OF_PRIOR_STAGE)
int uclass_find_next_free_req_seq(enum uclass_id id)
{
struct uclass *uc;
--
2.23.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 0/2] dm: CONFIG_OF_PRIOR_STAGE request number fixes
These patches remove a workaround that was needed for ports that use CONFIG_OF_PRIOR_STAGE, that need to probe a SPI bus, and whose prior stage device tree does not provide SPI bus aliases. Thomas Fitzsimmons (2): dm: device: Request next sequence number dm: spi: Do not assume first SPI bus drivers/core/device.c| 5 + drivers/core/uclass.c| 4 +++- drivers/spi/spi-uclass.c | 2 +- 3 files changed, 9 insertions(+), 2 deletions(-) -- 2.23.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] rpi3: Enable verified boot from FIT image
On 03/09/2019 09:12, Jun Nie wrote:
> Heinrich Schuchardt 于2019年9月2日周一 下午7:19写道：
>>
>> On 9/2/19 12:30 PM, Matthias Brugger wrote:
>>> +Alex, Lukas, Heinrich, Bin and Simon
>>>
>>> On 31/07/2019 10:16, Jun Nie wrote:
Matthias Brugger 于2019年7月31日周三 下午4:05写道：
>
>
>
> On 11/07/2019 05:55, Jun Nie wrote:
>> Enable verified boot from FIT image with select configs
>> and specify boot script image node in FIT image, the FIT
>> image is verified before it is run.
>>
>> Code that reusing dtb in firmware is disabled, so that
>> the dtb with pubic key packed in u-boot.bin can be used
>> to verify the signature of next stage FIT image.
>>
>> Signed-off-by: Jun Nie
>> ---
>> board/raspberrypi/rpi/rpi.c | 6 ++
>> include/configs/rpi.h | 15 ++-
>> 2 files changed, 20 insertions(+), 1 deletion(-)
>>
>> diff --git a/board/raspberrypi/rpi/rpi.c b/board/raspberrypi/rpi/rpi.c
>> index 617c892..950ee84 100644
>> --- a/board/raspberrypi/rpi/rpi.c
>> +++ b/board/raspberrypi/rpi/rpi.c
>> @@ -297,6 +297,7 @@ static void set_fdtfile(void)
>>env_set("fdtfile", fdtfile);
>> }
>>
>> +#ifndef CONFIG_FIT_SIGNATURE
>> /*
>>* If the firmware provided a valid FDT at boot time, let's expose it
>> in
>>* ${fdt_addr} so it may be passed unmodified to the kernel.
>> @@ -311,6 +312,7 @@ static void set_fdt_addr(void)
>>
>>env_set_hex("fdt_addr", fw_dtb_pointer);
>> }
>> +#endif
>>
>> /*
>>* Prevent relocation from stomping on a firmware provided FDT blob.
>> @@ -393,7 +395,9 @@ static void set_serial_number(void)
>>
>> int misc_init_r(void)
>> {
>> +#ifndef CONFIG_FIT_SIGNATURE
>>set_fdt_addr();
>> +#endif
>>set_fdtfile();
>>set_usbethaddr();
>> #ifdef CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG
>> @@ -470,6 +474,7 @@ int board_init(void)
>>return bcm2835_power_on_module(BCM2835_MBOX_POWER_DEVID_USB_HCD);
>> }
>>
>> +#ifndef CONFIG_FIT_SIGNATURE
>> /*
>>* If the firmware passed a device tree use it for U-Boot.
>>*/
>> @@ -479,6 +484,7 @@ void *board_fdt_blob_setup(void)
>>return NULL;
>>return (void *)fw_dtb_pointer;
>> }
>> +#endif
>
> Just to get this clear we need this because we want to pass the device
> tree via
> OF_SEPARATE, correct?
You are right. U-boot need to read he signature from dtb.
>
>>
>> int ft_board_setup(void *blob, bd_t *bd)
>> {
>> diff --git a/include/configs/rpi.h b/include/configs/rpi.h
>> index f76c7d1..ba91205 100644
>> --- a/include/configs/rpi.h
>> +++ b/include/configs/rpi.h
>> @@ -180,11 +180,24 @@
>>
>> #include
>>
>> +#ifdef CONFIG_FIT_SIGNATURE
>> +#define FIT_BOOT_CMD \
>> + "boot_a_script="\
>> + "load ${devtype} ${devnum}:${distro_bootpart} " \
>> + "${scriptaddr} ${prefix}${script}; "\
>> + "iminfo ${scriptaddr};" \
>> + "if test $? -eq 1; then reset; fi;" \
>> + "source ${scriptaddr}:bootscr\0"
>> +#else
>> +#define FIT_BOOT_CMD ""
>> +#endif
>> +
>
> Doesn't this overwrite the boot_a_script in distro_bootcmd?
>
> Would it make sense to add FIT booting to the distro boot command?
>
> Regards,
> Matthias
Yes, it overwrite the boot_a_script in distro_bootcmd. It is make
sense to add this to the distro boot command. I can send another patch
to move these lines to common code later.
>>>
>>> Question to the people just added, as you have relevant submission to
>>> distroboot. Do you think it makes sense to add FIT_BOOT_CMD to that?
>>>
>>> Regards,
>>> Matthias
>>
>> The idea of distro-boot was to make it easier for Linux distributions to
>> update the information needed by U-Boot to find the right kernel and
>> ramdisk.
>>
>> According to doc/README.distro file extlinux.conf should be used for the
>> communication between the distribution and U-Boot. Some distributions
>> like Debian still rely on boot.scr.
>>
>> Many distributions (OpenBSD, FreeBSD, Suse, Fedora) have moved from
>> distro-boot to UEFI as booting standard. Unfortunately we have not
>> documented our support for this in doc/README.distro (TODO for me).
>> Takahiro is working on secure boot using UEFI. Once completed this could
>> obsolete FIT images.
>>
>> Would we expect Linux distributions to provide FIT images upon kernel
>> updates?
>> Is there any Linux distribution doing so?
>
> Embedded Linux, a new distribution from ARM, is
Re: [U-Boot] [PATCH v4 0/1] imx: support i.MX8QM ROM 7720 a1 board
Hi Oliver, > Hello list, > > need some information howto avoid the imx-mkimage repo and create full > boostream directly from u-boot with all the binary blobs. You may want to look into binman tool (./tools/binman), which is supposed to pack all binary data together and produce one image. Also - you may be interested in fitImage, which allows packing kernel, dtb(s), initramfs, and some binary blobs together. I've also added Peng to CC, so he may help you as well as he also provided recently some patches to add i.MX8 support to U-Boot. > > Best regards, > > Oliver > > > Oliver Graute (1): > imx: support i.MX8QM ROM 7720 a1 board > > arch/arm/dts/Makefile | 1 + > arch/arm/dts/imx8qm-rom7720-a1.dts| 373 > ++ arch/arm/mach-imx/imx8/Kconfig| > 7 + board/advantech/imx8qm_rom7720_a1/Kconfig | 14 + > board/advantech/imx8qm_rom7720_a1/MAINTAINERS | 6 + > board/advantech/imx8qm_rom7720_a1/Makefile| 11 + > board/advantech/imx8qm_rom7720_a1/README | 70 > .../imx8qm_rom7720_a1/imx8qm_rom7720_a1.c | 141 +++ > .../advantech/imx8qm_rom7720_a1/imximage.cfg | 21 + > board/advantech/imx8qm_rom7720_a1/spl.c | 223 +++ > configs/imx8qm_rom7720_a1_4G_defconfig| 83 > include/configs/imx8qm_rom7720.h | 176 + > 12 files changed, 1126 insertions(+) > create mode 100644 arch/arm/dts/imx8qm-rom7720-a1.dts > create mode 100644 board/advantech/imx8qm_rom7720_a1/Kconfig > create mode 100644 board/advantech/imx8qm_rom7720_a1/MAINTAINERS > create mode 100644 board/advantech/imx8qm_rom7720_a1/Makefile > create mode 100644 board/advantech/imx8qm_rom7720_a1/README > create mode 100644 > board/advantech/imx8qm_rom7720_a1/imx8qm_rom7720_a1.c create mode > 100644 board/advantech/imx8qm_rom7720_a1/imximage.cfg create mode > 100644 board/advantech/imx8qm_rom7720_a1/spl.c create mode 100644 > configs/imx8qm_rom7720_a1_4G_defconfig create mode 100644 > include/configs/imx8qm_rom7720.h > Best regards, Lukasz Majewski -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lu...@denx.de pgpDJeVBr2H8B.pgp Description: OpenPGP digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RFC 1/3] lib: rsa: decouple rsa from FIT image verification
On Fri, Sep 06, 2019 at 09:39:05AM +0200, Heinrich Schuchardt wrote: > On 9/6/19 9:08 AM, AKASHI Takahiro wrote: > >Introduce new configuration, CONFIG_RSA_VERIFY which will decouple building > >RSA functions from FIT verification and allow for adding a RSA-based > >signature verification for other file formats, in particular PE file > >for UEFI secure boot. > > > >Signed-off-by: AKASHI Takahiro > >--- > > lib/rsa/Kconfig | 7 +++ > > lib/rsa/Makefile | 2 +- > > 2 files changed, 8 insertions(+), 1 deletion(-) > > > >diff --git a/lib/rsa/Kconfig b/lib/rsa/Kconfig > >index 2b33f323bccc..338c8124da59 100644 > >--- a/lib/rsa/Kconfig > >+++ b/lib/rsa/Kconfig > >@@ -1,5 +1,6 @@ > > config RSA > > bool "Use RSA Library" > >+select RSA_VERIFY > > select RSA_FREESCALE_EXP if FSL_CAAM && !ARCH_MX7 && !ARCH_MX6 && > > !ARCH_MX5 > > select RSA_SOFTWARE_EXP if !RSA_FREESCALE_EXP > > help > >@@ -17,6 +18,12 @@ if RSA > > > > config SPL_RSA > > bool "Use RSA Library within SPL" > >+select RSA_VERIFY > >+ > >+config RSA_VERIFY > >+bool > >+help > >+ Add RSA signature verification support. > > > > config RSA_SOFTWARE_EXP > > bool "Enable driver for RSA Modular Exponentiation in software" > >diff --git a/lib/rsa/Makefile b/lib/rsa/Makefile > >index a51c6e1685fb..226d8f3514a9 100644 > >--- a/lib/rsa/Makefile > >+++ b/lib/rsa/Makefile > >@@ -5,5 +5,5 @@ > > # (C) Copyright 2000-2007 > > # Wolfgang Denk, DENX Software Engineering, w...@denx.de. > > > >-obj-$(CONFIG_$(SPL_)FIT_SIGNATURE) += rsa-verify.o rsa-checksum.o > >+obj-$(CONFIG_RSA_VERIFY) += rsa-verify.o rsa-checksum.o > > obj-$(CONFIG_RSA_SOFTWARE_EXP) += rsa-mod-exp.o > > > > pine64-lts_defconfig with CONFIG_RSA=y > compiles fine without this patch. But with this patch: Right. It seems that include/image.h will also have to be modified. Thanks, -Takahiro Akashi > lib/rsa/rsa-verify.c:60:5: error: redefinition of ‘padding_pkcs_15_verify’ >60 | int padding_pkcs_15_verify(struct image_sign_info *info, > | ^~ > In file included from lib/rsa/rsa-verify.c:21: > include/u-boot/rsa.h:118:19: note: previous definition of > ‘padding_pkcs_15_verify’ was here > 118 | static inline int padding_pkcs_15_verify(struct image_sign_info > *info, > | ^~ > lib/rsa/rsa-verify.c:399:5: error: redefinition of ‘rsa_verify’ > 399 | int rsa_verify(struct image_sign_info *info, > | ^~ > CC lib/efi_loader/efi_hii.o > In file included from lib/rsa/rsa-verify.c:21: > include/u-boot/rsa.h:111:19: note: previous definition of ‘rsa_verify’ > was here > 111 | static inline int rsa_verify(struct image_sign_info *info, > | ^~ > > Best regards > > Heinrich ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v4 0/1] imx: support i.MX8QM ROM 7720 a1 board
Hello list, need some information howto avoid the imx-mkimage repo and create full boostream directly from u-boot with all the binary blobs. Best regards, Oliver Oliver Graute (1): imx: support i.MX8QM ROM 7720 a1 board arch/arm/dts/Makefile | 1 + arch/arm/dts/imx8qm-rom7720-a1.dts| 373 ++ arch/arm/mach-imx/imx8/Kconfig| 7 + board/advantech/imx8qm_rom7720_a1/Kconfig | 14 + board/advantech/imx8qm_rom7720_a1/MAINTAINERS | 6 + board/advantech/imx8qm_rom7720_a1/Makefile| 11 + board/advantech/imx8qm_rom7720_a1/README | 70 .../imx8qm_rom7720_a1/imx8qm_rom7720_a1.c | 141 +++ .../advantech/imx8qm_rom7720_a1/imximage.cfg | 21 + board/advantech/imx8qm_rom7720_a1/spl.c | 223 +++ configs/imx8qm_rom7720_a1_4G_defconfig| 83 include/configs/imx8qm_rom7720.h | 176 + 12 files changed, 1126 insertions(+) create mode 100644 arch/arm/dts/imx8qm-rom7720-a1.dts create mode 100644 board/advantech/imx8qm_rom7720_a1/Kconfig create mode 100644 board/advantech/imx8qm_rom7720_a1/MAINTAINERS create mode 100644 board/advantech/imx8qm_rom7720_a1/Makefile create mode 100644 board/advantech/imx8qm_rom7720_a1/README create mode 100644 board/advantech/imx8qm_rom7720_a1/imx8qm_rom7720_a1.c create mode 100644 board/advantech/imx8qm_rom7720_a1/imximage.cfg create mode 100644 board/advantech/imx8qm_rom7720_a1/spl.c create mode 100644 configs/imx8qm_rom7720_a1_4G_defconfig create mode 100644 include/configs/imx8qm_rom7720.h -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v4] imx: support i.MX8QM ROM 7720 a1 board
Add i.MX8QM ROM 7720a1 board support
Boot log as below:
U-Boot 2019.10-rc3-00217-g1b7f3d7865 (Sep 06 2019 - 08:03:23 +0200)
CPU: NXP i.MX8QM RevB A53 at 1200 MHz
Model: Advantech iMX8QM Qseven series
Board: ROM-7720-A1 4GB
Build: SCFW 65afe5f6
Boot: SD2
DRAM: 3.9 GiB
MMC: FSL_SDHC: 0, FSL_SDHC: 1, FSL_SDHC: 2
Loading Environment from MMC... OK
In:serial@5a06
Out: serial@5a06
Err: serial@5a06
Net: eth0: ethernet@5b04Could not get PHY for FEC1: addr 1
, eth-1: ethernet@5b05
Hit any key to stop autoboot: 0
Signed-off-by: Oliver Graute
Cc: Stefano Babic
Cc: Fabio Estevam
Cc: Peng Fan
Cc: Simon Glass
Cc: Ye Li
Cc: uboot-imx
---
These changes are based on this vendor tree:
https://github.com/ADVANTECH-Corp/uboot-imx6.git
I adapted the files and compared them with code from similar imx8qm-mek board
Changes for v4:
- changed SYS_VENDOR to advantech
- use sc_pm_setup_uart
- removed CONFIG_OF_BOARD_SETUP
- dropped board_gpio_init
- enabled CONFIG_SPL_DM_MMC
- dropped USDHC defines
- dropped CONFIG_AHAB_BOOT
Changes for v3:
- removed duplicate build_info
- removed CONFIG_FSL_ESDHC
Changes for v2:
- cleanup of u-boot environment
- set power mode SC_R_DC_0 for full boot of linux kernel
- enabled usdhc2
- enabled FEC defines
- updated README.md
- enabled readwrite for nfs rootfs
- removed include of environment header
arch/arm/dts/Makefile | 1 +
arch/arm/dts/imx8qm-rom7720-a1.dts| 373 ++
arch/arm/mach-imx/imx8/Kconfig| 7 +
board/advantech/imx8qm_rom7720_a1/Kconfig | 14 +
board/advantech/imx8qm_rom7720_a1/MAINTAINERS | 6 +
board/advantech/imx8qm_rom7720_a1/Makefile| 11 +
board/advantech/imx8qm_rom7720_a1/README | 70
.../imx8qm_rom7720_a1/imx8qm_rom7720_a1.c | 141 +++
.../advantech/imx8qm_rom7720_a1/imximage.cfg | 21 +
board/advantech/imx8qm_rom7720_a1/spl.c | 223 +++
configs/imx8qm_rom7720_a1_4G_defconfig| 83
include/configs/imx8qm_rom7720.h | 176 +
12 files changed, 1126 insertions(+)
create mode 100644 arch/arm/dts/imx8qm-rom7720-a1.dts
create mode 100644 board/advantech/imx8qm_rom7720_a1/Kconfig
create mode 100644 board/advantech/imx8qm_rom7720_a1/MAINTAINERS
create mode 100644 board/advantech/imx8qm_rom7720_a1/Makefile
create mode 100644 board/advantech/imx8qm_rom7720_a1/README
create mode 100644 board/advantech/imx8qm_rom7720_a1/imx8qm_rom7720_a1.c
create mode 100644 board/advantech/imx8qm_rom7720_a1/imximage.cfg
create mode 100644 board/advantech/imx8qm_rom7720_a1/spl.c
create mode 100644 configs/imx8qm_rom7720_a1_4G_defconfig
create mode 100644 include/configs/imx8qm_rom7720.h
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index aac1b83d49..aa139afd57 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -625,6 +625,7 @@ dtb-$(CONFIG_ARCH_MX7ULP) += imx7ulp-evk.dtb
dtb-$(CONFIG_ARCH_IMX8) += \
fsl-imx8qm-apalis.dtb \
fsl-imx8qm-mek.dtb \
+ imx8qm-rom7720-a1.dtb \
fsl-imx8qxp-colibri.dtb \
fsl-imx8qxp-mek.dtb
diff --git a/arch/arm/dts/imx8qm-rom7720-a1.dts
b/arch/arm/dts/imx8qm-rom7720-a1.dts
new file mode 100644
index 00..5f9ac955ed
--- /dev/null
+++ b/arch/arm/dts/imx8qm-rom7720-a1.dts
@@ -0,0 +1,373 @@
+// SPDX-License-Identifier:GPL-2.0+
+/*
+ * Copyright (C) 2016 Freescale Semiconductor, Inc.
+ * Copyright 2017 NXP
+ */
+
+/dts-v1/;
+
+/* First 128KB is for PSCI ATF. */
+/memreserve/ 0x8000 0x0002;
+
+#include "fsl-imx8qm.dtsi"
+
+/ {
+ model = "Advantech iMX8QM Qseven series";
+ compatible = "fsl,imx8qm-mek", "fsl,imx8qm";
+
+ chosen {
+ bootargs = "console=ttyLP0,115200
earlycon=lpuart32,0x5a06,115200";
+ stdout-path =
+ };
+
+ leds {
+ compatible = "gpio-leds";
+ pinctrl-names = "default";
+ pinctrl-0 = <_gpio_leds>;
+ user {
+ label = "heartbeat";
+ gpios = < 15 0>;
+ default-state = "on";
+ linux,default-trigger = "heartbeat";
+ };
+ };
+
+ regulators {
+ compatible = "simple-bus";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ reg_usb_otg1_vbus: regulator@0 {
+ compatible = "regulator-fixed";
+ reg = <0>;
+ regulator-name = "usb_otg1_vbus";
+ regulator-min-microvolt = <500>;
+ regulator-max-microvolt = <500>;
+ gpio = < 3 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
+
+ reg_usdhc2_vmmc: usdhc2_vmmc {
+ compatible = "regulator-fixed";
+ regulator-name =
[U-Boot] please pull u-boot-samsung master
Dear Tom, The following changes since commit 448f11f7503995746a7b71e5e3b3a831c4651be9: Merge tag 'arc-for-2019.10-rc4' of https://gitlab.denx.de/u-boot/custodians/u-boot-arc (2019-09-03 12:40:50 -0400) are available in the git repository at: g...@gitlab.denx.de:u-boot/custodians/u-boot-samsung.git master for you to fetch changes up to d7441d8a9ac9602afa92bf2649890a2208ffada1: ARM: exynos5: Try to boot on mmc2 before mmc0/1 (2019-09-05 18:36:59 +0900) Guillaume GARDET (1): ARM: exynos5: Try to boot on mmc2 before mmc0/1 include/configs/exynos5-common.h |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) -- Thanks, Minkyu Kang. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2] arm: dts: sync dts for Allwinner H6
Hi,
On Sun, 25 Aug 2019 at 18:04, Clément Péron wrote:
>
> Sync Kernel DTS for Allwinner H6 boards.
This sync avoid the random mac on the beelink GS1.
Could you check if it's ok for you ?
Thanks,
Clément
>
> Drop /omit-if-no-ref/ keyword as it's not supported by U-boot.
>
> commit Linux 5.3-rc4
>
> Signed-off-by: Clément Péron
> ---
> arch/arm/dts/sun50i-h6-beelink-gs1.dts | 76 ++
> arch/arm/dts/sun50i-h6-pine-h64.dts| 12
> arch/arm/dts/sun50i-h6.dtsi| 46 +++-
> 3 files changed, 131 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/dts/sun50i-h6-beelink-gs1.dts
> b/arch/arm/dts/sun50i-h6-beelink-gs1.dts
> index 54b0882bed..0dc33c90dd 100644
> --- a/arch/arm/dts/sun50i-h6-beelink-gs1.dts
> +++ b/arch/arm/dts/sun50i-h6-beelink-gs1.dts
> @@ -14,6 +14,7 @@
> compatible = "azw,beelink-gs1", "allwinner,sun50i-h6";
>
> aliases {
> + ethernet0 =
> serial0 =
> };
>
> @@ -21,6 +22,17 @@
> stdout-path = "serial0:115200n8";
> };
>
> + connector {
> + compatible = "hdmi-connector";
> + type = "a";
> +
> + port {
> + hdmi_con_in: endpoint {
> + remote-endpoint = <_out_con>;
> + };
> + };
> + };
> +
> leds {
> compatible = "gpio-leds";
>
> @@ -41,6 +53,40 @@
> };
> };
>
> + {
> + status = "okay";
> +};
> +
> + {
> + status = "okay";
> +};
> +
> + {
> + pinctrl-names = "default";
> + pinctrl-0 = <_rgmii_pins>;
> + phy-mode = "rgmii";
> + phy-handle = <_rgmii_phy>;
> + phy-supply = <_aldo2>;
> + status = "okay";
> +};
> +
> + {
> + status = "okay";
> +};
> +
> +_out {
> + hdmi_out_con: endpoint {
> + remote-endpoint = <_con_in>;
> + };
> +};
> +
> + {
> + ext_rgmii_phy: ethernet-phy@1 {
> + compatible = "ethernet-phy-ieee802.3-c22";
> + reg = <1>;
> + };
> +};
> +
> {
> vmmc-supply = <_cldo1>;
> cd-gpios = < 5 6 GPIO_ACTIVE_LOW>;
> @@ -57,6 +103,15 @@
> status = "okay";
> };
>
> + {
> + status = "okay";
> +};
> +
> + {
> + vcc-pd-supply = <_cldo1>;
> + vcc-pg-supply = <_aldo1>;
> +};
> +
> _i2c {
> status = "okay";
>
> @@ -177,8 +232,29 @@
> };
> };
>
> +_pio {
> + /*
> +* PL0 and PL1 are used for PMIC I2C
> +* don't enable the pl-supply else
> +* it will fail at boot
> +*
> +* vcc-pl-supply = <_aldo1>;
> +*/
> + vcc-pm-supply = <_aldo1>;
> +};
> +
> {
> pinctrl-names = "default";
> pinctrl-0 = <_ph_pins>;
> status = "okay";
> };
> +
> + {
> + dr_mode = "host";
> + status = "okay";
> +};
> +
> + {
> + usb0_vbus-supply = <_vcc5v>;
> + status = "okay";
> +};
> diff --git a/arch/arm/dts/sun50i-h6-pine-h64.dts
> b/arch/arm/dts/sun50i-h6-pine-h64.dts
> index 4802902e12..1898345183 100644
> --- a/arch/arm/dts/sun50i-h6-pine-h64.dts
> +++ b/arch/arm/dts/sun50i-h6-pine-h64.dts
> @@ -127,6 +127,12 @@
> status = "okay";
> };
>
> + {
> + vcc-pc-supply = <_bldo2>;
> + vcc-pd-supply = <_cldo1>;
> + vcc-pg-supply = <_aldo1>;
> +};
> +
> _i2c {
> status = "okay";
>
> @@ -243,10 +249,16 @@
> pcf8563: rtc@51 {
> compatible = "nxp,pcf8563";
> reg = <0x51>;
> + interrupt-parent = <_intc>;
> + interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
> #clock-cells = <0>;
> };
> };
>
> +_pio {
> + vcc-pm-supply = <_aldo1>;
> +};
> +
> {
> pinctrl-names = "default";
> pinctrl-0 = <_ph_pins>;
> diff --git a/arch/arm/dts/sun50i-h6.dtsi b/arch/arm/dts/sun50i-h6.dtsi
> index e0dc4a05c1..a117f479ae 100644
> --- a/arch/arm/dts/sun50i-h6.dtsi
> +++ b/arch/arm/dts/sun50i-h6.dtsi
> @@ -101,7 +101,7 @@
> #size-cells = <1>;
> ranges;
>
> - display-engine@100 {
> + bus@100 {
> compatible = "allwinner,sun50i-h6-de3",
> "allwinner,sun50i-a64-de2";
> reg = <0x100 0x40>;
> @@ -203,11 +203,32 @@
> #reset-cells = <1>;
> };
>
> + dma: dma-controller@3002000 {
> + compatible = "allwinner,sun50i-h6-dma";
> + reg = <0x03002000 0x1000>;
> + interrupts = ;
> + clocks = < CLK_BUS_DMA>, < CLK_MBUS_DMA>;
> + clock-names = "bus", "mbus";
> + dma-channels = <16>;
> + dma-requests = <46>;
> + resets = < RST_BUS_DMA>;
> +
Re: [U-Boot] [PATCH v2 5/5] imx: add i.MX6ULZ board
> Subject: Re: [U-Boot] [PATCH v2 5/5] imx: add i.MX6ULZ board > > Hi Stefan, > > On Thu, Sep 5, 2019 at 5:59 AM Stefan Roese wrote: > > > a) > > Why is SPL not used in the mainline i.MX6ULL/ULZ port? The i.MX6UL > > (14x14) does use SPL. > > Yes, I think it could SPL as well. Maybe Peng can comment. NXP vendor tree not support SPL, so when I upstream the code, SPL was not included. Regards, Peng. > > > b) > > Do you have a reference board (eval kit) that supports LPDDR2 on the > > i.MX6ULL/ULZ with the U-Boot source code? I'm asking since we plan to > > use LPDDR2 instead of DDR3. > > I am only aware of a mx6ul LPDDR2 target, which can probably help: > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsource > .codeaurora.org%2Fexternal%2Fimx%2Fuboot-imx%2Ftree%2Fboard%2Ffree > scale%2Fmx6ul_14x14_lpddr2_arm2%2Fimximage.cfg%3Fh%3Dimx_v2019.0 > 4_4.19.35_1.0.0data=02%7C01%7Cpeng.fan%40nxp.com%7C432044d > 939ee4717a16808d731f4b329%7C686ea1d3bc2b4c6fa92cd99c5c301635%7 > C0%7C0%7C637032799372346468sdata=MM2aitptGVWj3M7fdrgryth > cLoCif6wm9RAWDL7EaHc%3Dreserved=0 > > Regards, > > Fabio Estevam ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 2/2] configs: opos6uldev: Select CONFIG_SYS_FSL_ESDHC_HAS_DDR_MODE
This significally increases performance: reading zImage, without DDR: 6203640 bytes read in 157 ms (37.7 MiB/s) reading zImage, with DDR: 6203640 bytes read in 88 ms (67.2 MiB/s) Signed-off-by: Sébastien Szymanski --- configs/opos6uldev_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/configs/opos6uldev_defconfig b/configs/opos6uldev_defconfig index 1b68b8e12f..50450a7114 100644 --- a/configs/opos6uldev_defconfig +++ b/configs/opos6uldev_defconfig @@ -70,6 +70,7 @@ CONFIG_SYS_I2C_MXC=y CONFIG_PWRSEQ=y CONFIG_SUPPORT_EMMC_BOOT=y CONFIG_FSL_USDHC=y +CONFIG_SYS_FSL_ESDHC_HAS_DDR_MODE=y CONFIG_PHYLIB=y CONFIG_PHY_MICREL=y CONFIG_PHY_MICREL_KSZ8XXX=y -- 2.21.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/2] Convert CONFIG_SYS_FSL_ESDHC_HAS_DDR_MODE to Kconfig
This converts the following to Kconfig: CONFIG_SYS_FSL_ESDHC_HAS_DDR_MODE Signed-off-by: Sébastien Szymanski --- configs/warp7_defconfig | 1 + configs/warp_defconfig | 1 + drivers/mmc/Kconfig | 6 ++ include/configs/warp.h | 1 - include/configs/warp7.h | 1 - scripts/config_whitelist.txt | 1 - 6 files changed, 8 insertions(+), 3 deletions(-) diff --git a/configs/warp7_defconfig b/configs/warp7_defconfig index a022454976..9a167d2c43 100644 --- a/configs/warp7_defconfig +++ b/configs/warp7_defconfig @@ -40,6 +40,7 @@ CONFIG_DM_I2C=y CONFIG_DM_MMC=y CONFIG_SUPPORT_EMMC_BOOT=y CONFIG_FSL_USDHC=y +CONFIG_SYS_FSL_ESDHC_HAS_DDR_MODE=y CONFIG_PINCTRL=y CONFIG_PINCTRL_IMX7=y CONFIG_DM_PMIC=y diff --git a/configs/warp_defconfig b/configs/warp_defconfig index 7a6ea6f8c6..d719dc779a 100644 --- a/configs/warp_defconfig +++ b/configs/warp_defconfig @@ -31,6 +31,7 @@ CONFIG_ENV_IS_IN_MMC=y CONFIG_DFU_MMC=y CONFIG_SUPPORT_EMMC_BOOT=y CONFIG_FSL_USDHC=y +CONFIG_SYS_FSL_ESDHC_HAS_DDR_MODE=y CONFIG_USB=y CONFIG_USB_STORAGE=y CONFIG_USB_GADGET=y diff --git a/drivers/mmc/Kconfig b/drivers/mmc/Kconfig index 0ccb1ea701..f61b17b86b 100644 --- a/drivers/mmc/Kconfig +++ b/drivers/mmc/Kconfig @@ -701,6 +701,12 @@ config FSL_USDHC help This enables the Ultra Secured Digital Host Controller enhancements +config SYS_FSL_ESDHC_HAS_DDR_MODE + depends on FSL_ESDHC || FSL_ESDHC_IMX + bool "Enable Dual Data Rate support" + help + This enables Dual Data Rate support (DDR52) + endmenu config SYS_FSL_ERRATUM_ESDHC111 diff --git a/include/configs/warp.h b/include/configs/warp.h index 5345f5314d..a00c535b50 100644 --- a/include/configs/warp.h +++ b/include/configs/warp.h @@ -22,7 +22,6 @@ /* MMC Configs */ #define CONFIG_SYS_FSL_ESDHC_ADDR USDHC2_BASE_ADDR -#define CONFIG_SYS_FSL_ESDHC_HAS_DDR_MODE /* Watchdog */ #define CONFIG_WATCHDOG_TIMEOUT_MSECS 3 /* 30s */ diff --git a/include/configs/warp7.h b/include/configs/warp7.h index 73541fe176..aa259cd9ef 100644 --- a/include/configs/warp7.h +++ b/include/configs/warp7.h @@ -18,7 +18,6 @@ /* MMC Config*/ #define CONFIG_SYS_FSL_ESDHC_ADDR USDHC3_BASE_ADDR -#define CONFIG_SYS_FSL_ESDHC_HAS_DDR_MODE #define CONFIG_SYS_MMC_IMG_LOAD_PART 1 /* Switch on SERIAL_TAG */ diff --git a/scripts/config_whitelist.txt b/scripts/config_whitelist.txt index b18eab1707..49c041b59e 100644 --- a/scripts/config_whitelist.txt +++ b/scripts/config_whitelist.txt @@ -2555,7 +2555,6 @@ CONFIG_SYS_FSL_ERRATUM_A_004934 CONFIG_SYS_FSL_ESDHC_ADDR CONFIG_SYS_FSL_ESDHC_BE CONFIG_SYS_FSL_ESDHC_BROKEN_TIMEOUT -CONFIG_SYS_FSL_ESDHC_HAS_DDR_MODE CONFIG_SYS_FSL_ESDHC_LE CONFIG_SYS_FSL_ESDHC_NUM CONFIG_SYS_FSL_ESDHC_P1010_BROKEN_SDCLK -- 2.21.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RFC 1/3] lib: rsa: decouple rsa from FIT image verification
On 9/6/19 9:08 AM, AKASHI Takahiro wrote: Introduce new configuration, CONFIG_RSA_VERIFY which will decouple building RSA functions from FIT verification and allow for adding a RSA-based signature verification for other file formats, in particular PE file for UEFI secure boot. Signed-off-by: AKASHI Takahiro --- lib/rsa/Kconfig | 7 +++ lib/rsa/Makefile | 2 +- 2 files changed, 8 insertions(+), 1 deletion(-) diff --git a/lib/rsa/Kconfig b/lib/rsa/Kconfig index 2b33f323bccc..338c8124da59 100644 --- a/lib/rsa/Kconfig +++ b/lib/rsa/Kconfig @@ -1,5 +1,6 @@ config RSA bool "Use RSA Library" + select RSA_VERIFY select RSA_FREESCALE_EXP if FSL_CAAM && !ARCH_MX7 && !ARCH_MX6 && !ARCH_MX5 select RSA_SOFTWARE_EXP if !RSA_FREESCALE_EXP help @@ -17,6 +18,12 @@ if RSA config SPL_RSA bool "Use RSA Library within SPL" + select RSA_VERIFY + +config RSA_VERIFY + bool + help + Add RSA signature verification support. config RSA_SOFTWARE_EXP bool "Enable driver for RSA Modular Exponentiation in software" diff --git a/lib/rsa/Makefile b/lib/rsa/Makefile index a51c6e1685fb..226d8f3514a9 100644 --- a/lib/rsa/Makefile +++ b/lib/rsa/Makefile @@ -5,5 +5,5 @@ # (C) Copyright 2000-2007 # Wolfgang Denk, DENX Software Engineering, w...@denx.de. -obj-$(CONFIG_$(SPL_)FIT_SIGNATURE) += rsa-verify.o rsa-checksum.o +obj-$(CONFIG_RSA_VERIFY) += rsa-verify.o rsa-checksum.o obj-$(CONFIG_RSA_SOFTWARE_EXP) += rsa-mod-exp.o pine64-lts_defconfig with CONFIG_RSA=y compiles fine without this patch. But with this patch: lib/rsa/rsa-verify.c:60:5: error: redefinition of ‘padding_pkcs_15_verify’ 60 | int padding_pkcs_15_verify(struct image_sign_info *info, | ^~ In file included from lib/rsa/rsa-verify.c:21: include/u-boot/rsa.h:118:19: note: previous definition of ‘padding_pkcs_15_verify’ was here 118 | static inline int padding_pkcs_15_verify(struct image_sign_info *info, | ^~ lib/rsa/rsa-verify.c:399:5: error: redefinition of ‘rsa_verify’ 399 | int rsa_verify(struct image_sign_info *info, | ^~ CC lib/efi_loader/efi_hii.o In file included from lib/rsa/rsa-verify.c:21: include/u-boot/rsa.h:111:19: note: previous definition of ‘rsa_verify’ was here 111 | static inline int rsa_verify(struct image_sign_info *info, | ^~ Best regards Heinrich ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Regressions in MTD / SPI FLASH
Hi, On 04/09/19 11:37 PM, Eugeniy Paltsev wrote: > We faced with regressions caused by > commit c4e8862308d4 (mtd: spi: Switch to new SPI NOR framework) > This switch was performed by removing entire u-boot spi-flash > core implementation and copying it from another project. > However the switch is performed without proper testing and > investigations about fixes/improvements were made in u-boot > spi-flash core. This results in regressions. > Apologies for the trouble... As stated in cover letter, this change was necessary as U-Boot SPI flash stack at that time did not features such as 4 byte addressing, SFDP parsing, SPI controllers with MMIO interfaces etc. Also there was need to move to SPI MEM framework to support both SPI NAND and SPI NOR flashes using a single SPI controller drivers. I have to disagree on the part that there was no proper testing... As evident from mailing list archives, patch series was reviewed by multiple reviewers and tested on their platforms as well... Unfortunately its impossible to get all boards owners to test it. > One of regression we faced with is related to SST26 flash series which > is used on HSDK board. The cause is that SST26 protection ops > implementation was dropped. The fix of this regression is send > as a patch in this series. > I retained most U-Boot specific code as is (like support for BANK address registers, restriction in transfer sizes) but I somehow overlooked this part. Sorry for that > However there are another regressions. I.E: we also faced with broken > SPI flash on another SNPS boards - AXS101 and AXS103. They use different > flash IC (n25q512ax3) and I didn't investigate the cause yet. > Could you provide more details here: What exactly fails? Is the detected correctly? Does reads work fine? Is Erase or Write broken? Could you enable debug prints in your driver as well as debug prints in spi_mem_exec_op() (in drivers/spi/spi-mem.c) and post the logs? Regards Vignesh > I can also expect regressions among other u-boot users > and I believe that subsystem changes mustn't be done such harmful way. > > Eugeniy Paltsev (1): > MTD: SPI: revert removing SST26* flash IC protection ops > > drivers/mtd/spi/sf_internal.h | 1 + > drivers/mtd/spi/spi-nor-core.c | 181 + > drivers/mtd/spi/spi-nor-ids.c | 8 +- > include/linux/mtd/spi-nor.h| 4 + > 4 files changed, 190 insertions(+), 4 deletions(-) > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] Pull request for UEFI sub-system for v2019.10-rc4 (3)
The following changes since commit ece9834f7d223097cec92e3d3c70cd37b3768482: Merge branch 'master' of https://gitlab.denx.de/u-boot/custodians/u-boot-net (2019-09-04 16:02:03 -0400) are available in the Git repository at: https://gitlab.denx.de/u-boot/custodians/u-boot-efi.git tags/efi-2019-10-rc4-3 for you to fetch changes up to fe1a81c1a47737d3ce6b6855a05468b7546d4982: doc: UEFI API documentation (2019-09-05 23:18:52 +0200) No problems where observed in Gitlab: https://gitlab.denx.de/u-boot/custodians/u-boot-efi/pipelines/620 Primary key fingerprint: 6DC4 F9C7 1F29 A6FA 06B7 6D33 C481 DBBC 2C05 1AC4 Pull request for UEFI sub-system for v2019.10-rc4 (3) This includes the patches from Pull request for UEFI sub-system for v2019.10-rc4 (2) Fix UEFI specification compliance issues in the simple network protocol: * Correctly set and reset the interrupt status. * Support filling the header in the Transmit() service. * Correct the checking and setting of the network state. * Implement the MCastIPtoMAC() service. * Adjust the simple network protocol unit test. Fix UEFI specification compliance issues in the protocol. Fix UEFI specification compliance issues in the simple text output protocol: * Avoid out of bounds cursor position. * Do not set illegal screen mode. Fix UEFI specification compliance issues in the block IO protocol: * Check parameters. * Return correct status code if buffer is unaligned. Refactor initialization of EFI memory in preparation of support for > 3GB memory on x86. Heinrich Schuchardt (16): riscv: qemu: enable CONFIG_CMD_BOOTEFI_SELFTEST efi_loader: interrupts in simple network protocol efi_selftest: check EFI_SIMPLE_NETWORK_RECEIVE_INTERRUPT efi_loader: EFI_SIMPLE_NETWORK.Transmit() fill header efi_loader: fix status management in network stack efi_loader: implement MCastIPtoMAC efi_loader: correct text conversion for vendor DP efi_loader: correctly render MAC address device path nodes efi_loader: correctly render CD-ROM device path nodes efi_loader: correctly render UsbClass DP nodes as text efi_loader: cursor positioning efi_loader: do not set invalid screen mode efi_loader: parameter checks BLOCK_IO_PROTOCOL efi_loader: use EFI_PRINT() instead of debug() efi_loader: EFI_BLOCK_IO_PROTOCOL.Reset() doc: UEFI API documentation Park, Aiden (1): efi_loader: Extract adding a conventional memory in separate routine configs/qemu-riscv32_defconfig | 1 + configs/qemu-riscv32_smode_defconfig | 1 + configs/qemu-riscv64_defconfig | 1 + configs/qemu-riscv64_smode_defconfig | 1 + doc/api/efi.rst | 33 ++ include/efi_api.h| 4 +- include/efi_loader.h | 4 + lib/efi_loader/efi_console.c | 33 -- lib/efi_loader/efi_device_path.c | 2 +- lib/efi_loader/efi_device_path_to_text.c | 31 +++-- lib/efi_loader/efi_disk.c| 60 +- lib/efi_loader/efi_gop.c | 2 +- lib/efi_loader/efi_memory.c | 82 - lib/efi_loader/efi_net.c | 193 +-- lib/efi_selftest/efi_selftest_snp.c | 64 -- 15 files changed, 410 insertions(+), 102 deletions(-) ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2] env: Add CONFIG_ENV_SUPPORT
Add a new flag CONFIG_ENV_SUPPORT to compile all
the environment features in U-Boot (attributes, callbacks
and flags); it is the supplement of the 2 existing flags
for SPL/TPL.
To have ENV support, enable the flag:
- CONFIG_ENV_SUPPORT for U-Boot proper
- CONFIG_SPL_ENV_SUPPORT for SPL
- CONFIG_TPL_ENV_SUPPORT for TPL
This new configuration allows to use the macro
CONFIG_IS_ENABLED(ENV_SUPPORT) in the code without
issue and solves the regression introduced by
commit 7d4776545b0f ("env: solve compilation error
in SPL"); change_ok was always NULL in U-Boot.
Signed-off-by: Patrick Delaunay
---
Changes in v2:
- Update commit message after Lukasz Majewki review
cmd/Kconfig| 2 ++
env/Kconfig| 7 +++
env/Makefile | 11 ---
include/env_callback.h | 4
include/env_flags.h| 4
5 files changed, 21 insertions(+), 7 deletions(-)
diff --git a/cmd/Kconfig b/cmd/Kconfig
index 05872fa0d7..f7a1b1faf5 100644
--- a/cmd/Kconfig
+++ b/cmd/Kconfig
@@ -465,6 +465,7 @@ config CMD_ENV_EXISTS
config CMD_ENV_CALLBACK
bool "env callbacks - print callbacks and their associated variables"
+ depends on ENV_SUPPORT
help
Some environment variable have callbacks defined by
U_BOOT_ENV_CALLBACK. These are called when the variable changes.
@@ -473,6 +474,7 @@ config CMD_ENV_CALLBACK
config CMD_ENV_FLAGS
bool "env flags -print variables that have non-default flags"
+ depends on ENV_SUPPORT
help
Some environment variables have special flags that control their
behaviour. For example, serial# can only be written once and cannot
diff --git a/env/Kconfig b/env/Kconfig
index 74db2f38cc..f0c5a7a39c 100644
--- a/env/Kconfig
+++ b/env/Kconfig
@@ -1,5 +1,12 @@
menu "Environment"
+config ENV_SUPPORT
+ bool "Support all environment features"
+ default y
+ help
+ Enable full environment support in U-Boot,
+ including attributes, callbacks and flags.
+
config ENV_IS_NOWHERE
bool "Environment is not stored"
default y if !ENV_IS_IN_EEPROM && !ENV_IS_IN_EXT4 && \
diff --git a/env/Makefile b/env/Makefile
index 90144d6caf..2a468ac16b 100644
--- a/env/Makefile
+++ b/env/Makefile
@@ -5,10 +5,11 @@
obj-y += common.o env.o
+obj-$(CONFIG_$(SPL_TPL_)ENV_SUPPORT) += attr.o
+obj-$(CONFIG_$(SPL_TPL_)ENV_SUPPORT) += flags.o
+obj-$(CONFIG_$(SPL_TPL_)ENV_SUPPORT) += callback.o
+
ifndef CONFIG_SPL_BUILD
-obj-y += attr.o
-obj-y += callback.o
-obj-y += flags.o
obj-$(CONFIG_ENV_IS_IN_EEPROM) += eeprom.o
extra-$(CONFIG_ENV_IS_EMBEDDED) += embedded.o
obj-$(CONFIG_ENV_IS_IN_EEPROM) += embedded.o
@@ -19,10 +20,6 @@ obj-$(CONFIG_ENV_IS_IN_ONENAND) += onenand.o
obj-$(CONFIG_ENV_IS_IN_SATA) += sata.o
obj-$(CONFIG_ENV_IS_IN_REMOTE) += remote.o
obj-$(CONFIG_ENV_IS_IN_UBI) += ubi.o
-else
-obj-$(CONFIG_$(SPL_TPL_)ENV_SUPPORT) += attr.o
-obj-$(CONFIG_$(SPL_TPL_)ENV_SUPPORT) += flags.o
-obj-$(CONFIG_$(SPL_TPL_)ENV_SUPPORT) += callback.o
endif
obj-$(CONFIG_$(SPL_TPL_)ENV_IS_NOWHERE) += nowhere.o
diff --git a/include/env_callback.h b/include/env_callback.h
index 982c07854d..a757fe6b5f 100644
--- a/include/env_callback.h
+++ b/include/env_callback.h
@@ -72,6 +72,10 @@
"serial#:serialno," \
CONFIG_ENV_CALLBACK_LIST_STATIC
+#if CONFIG_IS_ENABLED(ENV_SUPPORT)
void env_callback_init(struct env_entry *var_entry);
+#else
+static inline void env_callback_init(struct env_entry *var_entry) { }
+#endif
#endif /* __ENV_CALLBACK_H__ */
diff --git a/include/env_flags.h b/include/env_flags.h
index e5380f2948..ec480e3ed7 100644
--- a/include/env_flags.h
+++ b/include/env_flags.h
@@ -153,7 +153,11 @@ int env_flags_validate_env_set_params(char *name, char
*const val[], int count);
* When adding a variable to the environment, initialize the flags for that
* variable.
*/
+#if CONFIG_IS_ENABLED(ENV_SUPPORT)
void env_flags_init(struct env_entry *var_entry);
+#else
+static inline void env_flags_init(struct env_entry *var_entry) { }
+#endif
/*
* Validate the newval for to conform with the requirements defined by its
flags
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [RFC 3/3] lib: rsa: add rsa_verify_with_pkey()
This function, and hence rsa_verify(), will perform RSA verification
with two essential parameters for a RSA public key in contract of
rsa_verify_with_keynode(), which requires additional three parameters
stored in FIT image.
It will be used in implementing UEFI secure boot, i.e. image authentication
and variable authentication.
Signed-off-by: AKASHI Takahiro
---
lib/rsa/Kconfig | 7 +
lib/rsa/Makefile | 3 ++-
lib/rsa/rsa-verify.c | 63 ++--
3 files changed, 64 insertions(+), 9 deletions(-)
diff --git a/lib/rsa/Kconfig b/lib/rsa/Kconfig
index 338c8124da59..3c1986a26f8c 100644
--- a/lib/rsa/Kconfig
+++ b/lib/rsa/Kconfig
@@ -25,6 +25,13 @@ config RSA_VERIFY
help
Add RSA signature verification support.
+config RSA_VERIFY_WITH_PKEY
+ bool "Execute RSA verification without key parameters from FDT"
+ depends on RSA
+ help
+ This options enables RSA signature verification without
+ using public key parameters which is embedded control FDT.
+
config RSA_SOFTWARE_EXP
bool "Enable driver for RSA Modular Exponentiation in software"
depends on DM
diff --git a/lib/rsa/Makefile b/lib/rsa/Makefile
index d66eef74c514..fd4592fd6a8a 100644
--- a/lib/rsa/Makefile
+++ b/lib/rsa/Makefile
@@ -5,5 +5,6 @@
# (C) Copyright 2000-2007
# Wolfgang Denk, DENX Software Engineering, w...@denx.de.
-obj-$(CONFIG_RSA_VERIFY) += rsa-verify.o rsa-checksum.o rsa-keyprop.o
+obj-$(CONFIG_RSA_VERIFY) += rsa-verify.o rsa-checksum.o
+obj-$(CONFIG_RSA_VERIFY_WITH_PKEY) += rsa-keyprop.o
obj-$(CONFIG_RSA_SOFTWARE_EXP) += rsa-mod-exp.o
diff --git a/lib/rsa/rsa-verify.c b/lib/rsa/rsa-verify.c
index 287fcc4d234d..80eabff3e940 100644
--- a/lib/rsa/rsa-verify.c
+++ b/lib/rsa/rsa-verify.c
@@ -17,9 +17,14 @@
#include "mkimage.h"
#include
#endif
+#include
#include
#include
+#ifndef __UBOOT__ /* for host tools */
+#undef CONFIG_RSA_VERIFY_WITH_PKEY
+#endif
+
/* Default public exponent for backward compatibility */
#define RSA_DEFAULT_PUBEXP 65537
@@ -342,6 +347,34 @@ static int rsa_verify_key(struct image_sign_info *info,
return 0;
}
+#ifdef CONFIG_RSA_VERIFY_WITH_PKEY
+/**
+ * rsa_verify_with_pkey()
+ *
+ */
+static int rsa_verify_with_pkey(struct image_sign_info *info,
+ const void *hash, uint8_t *sig, uint sig_len)
+{
+ struct key_prop *prop;
+ int ret;
+
+ /* Public key is self-described to fill key_prop */
+ prop = rsa_gen_key_prop(info->key, info->keylen);
+ if (!prop) {
+ debug("Generating necessary parameter for decoding failed\n");
+ return -EACCES;
+ }
+
+ ret = rsa_verify_key(info, prop, sig, sig_len, hash,
+info->crypto->key_len);
+
+ rsa_free_key_prop(prop);
+
+ return ret;
+}
+#endif
+
+#if CONFIG_IS_ENABLED(FIT_SIGNATURE)
/**
* rsa_verify_with_keynode() - Verify a signature against some data using
* information in node with prperties of RSA Key like modulus, exponent etc.
@@ -395,18 +428,21 @@ static int rsa_verify_with_keynode(struct image_sign_info
*info,
return ret;
}
+#endif
int rsa_verify(struct image_sign_info *info,
const struct image_region region[], int region_count,
uint8_t *sig, uint sig_len)
{
- const void *blob = info->fdt_blob;
/* Reserve memory for maximum checksum-length */
uint8_t hash[info->crypto->key_len];
+ int ret = -EACCES;
+#if CONFIG_IS_ENABLED(FIT_SIGNATURE)
+ const void *blob = info->fdt_blob;
int ndepth, noffset;
int sig_node, node;
char name[100];
- int ret;
+#endif
/*
* Verify that the checksum-length does not exceed the
@@ -419,12 +455,6 @@ int rsa_verify(struct image_sign_info *info,
return -EINVAL;
}
- sig_node = fdt_subnode_offset(blob, 0, FIT_SIG_NODENAME);
- if (sig_node < 0) {
- debug("%s: No signature node found\n", __func__);
- return -ENOENT;
- }
-
/* Calculate checksum with checksum-algorithm */
ret = info->checksum->calculate(info->checksum->name,
region, region_count, hash);
@@ -433,6 +463,22 @@ int rsa_verify(struct image_sign_info *info,
return -EINVAL;
}
+#ifdef CONFIG_RSA_VERIFY_WITH_PKEY
+ if (!info->fdt_blob) {
+ /* don't rely on fdt properties */
+ ret = rsa_verify_with_pkey(info, hash, sig, sig_len);
+
+ return ret;
+ }
+#endif
+
+#if CONFIG_IS_ENABLED(FIT_SIGNATURE)
+ sig_node = fdt_subnode_offset(blob, 0, FIT_SIG_NODENAME);
+ if (sig_node < 0) {
+ debug("%s: No signature node found\n", __func__);
+ return -ENOENT;
+ }
+
/* See if we must use a particular key */
if (info->required_keynode != -1)
[U-Boot] [RFC 2/3] lib: rsa: generate additional parameters for public key
In the current implementation of FIT_SIGNATURE, five parameters for
a RSA public key are required while only two of them are essential.
(See rsa-mod-exp.h and uImage.FIT/signature.txt)
This is a result of considering relatively limited computer power
and resources on embedded systems, while such a assumption may not
be quite practical for other use cases.
In this patch, added is a function, rsa_gen_key_prop(), which will
generate additional parameters for other uses, in particular
UEFI secure boot, on the fly.
Note: the current code uses some "big number" routines from BearSSL
for the calculation.
Signed-off-by: AKASHI Takahiro
---
include/u-boot/rsa-mod-exp.h | 3 +
lib/rsa/Makefile | 2 +-
lib/rsa/rsa-keyprop.c| 631 +++
3 files changed, 635 insertions(+), 1 deletion(-)
create mode 100644 lib/rsa/rsa-keyprop.c
diff --git a/include/u-boot/rsa-mod-exp.h b/include/u-boot/rsa-mod-exp.h
index 8a428c4b6a1a..ca189292d869 100644
--- a/include/u-boot/rsa-mod-exp.h
+++ b/include/u-boot/rsa-mod-exp.h
@@ -26,6 +26,9 @@ struct key_prop {
uint32_t exp_len; /* Exponent length in number of uint8_t */
};
+struct key_prop *rsa_gen_key_prop(const void *key, uint32_t keylen);
+void rsa_free_key_prop(struct key_prop *prop);
+
/**
* rsa_mod_exp_sw() - Perform RSA Modular Exponentiation in sw
*
diff --git a/lib/rsa/Makefile b/lib/rsa/Makefile
index 226d8f3514a9..d66eef74c514 100644
--- a/lib/rsa/Makefile
+++ b/lib/rsa/Makefile
@@ -5,5 +5,5 @@
# (C) Copyright 2000-2007
# Wolfgang Denk, DENX Software Engineering, w...@denx.de.
-obj-$(CONFIG_RSA_VERIFY) += rsa-verify.o rsa-checksum.o
+obj-$(CONFIG_RSA_VERIFY) += rsa-verify.o rsa-checksum.o rsa-keyprop.o
obj-$(CONFIG_RSA_SOFTWARE_EXP) += rsa-mod-exp.o
diff --git a/lib/rsa/rsa-keyprop.c b/lib/rsa/rsa-keyprop.c
new file mode 100644
index ..e650a931dff9
--- /dev/null
+++ b/lib/rsa/rsa-keyprop.c
@@ -0,0 +1,631 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * RSA library - generate parameters for a public key
+ *
+ * Copyright (c) 2019 Linaro Limited
+ * Author: AKASHI Takahiro
+ *
+ * Big number routines in this file come from BearSSL.
+ * See the original copyright below.
+ *
+ * Copyright (c) 2016 Thomas Pornin
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining
+ * a copy of this software and associated documentation files (the
+ * "Software"), to deal in the Software without restriction, including
+ * without limitation the rights to use, copy, modify, merge, publish,
+ * distribute, sublicense, and/or sell copies of the Software, and to
+ * permit persons to whom the Software is furnished to do so, subject to
+ * the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+ * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
+ * BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
+ * ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
+ * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+ * SOFTWARE.
+ */
+#include
+
+#include
+#include
+#include
+#include
+
+/* stripped version of src/inner.h */
+
+static inline unsigned
+br_dec16be(const void *src)
+{
+#if 0 /* BR_BE_UNALIGNED */
+ return ((const br_union_u16 *)src)->u;
+#else
+ const unsigned char *buf;
+
+ buf = src;
+ return ((unsigned)buf[0] << 8) | (unsigned)buf[1];
+#endif
+}
+
+static inline uint32_t
+br_dec32be(const void *src)
+{
+#if 0 /* BR_BE_UNALIGNED */
+ return ((const br_union_u32 *)src)->u;
+#else
+ const unsigned char *buf;
+
+ buf = src;
+ return ((uint32_t)buf[0] << 24)
+ | ((uint32_t)buf[1] << 16)
+ | ((uint32_t)buf[2] << 8)
+ | (uint32_t)buf[3];
+#endif
+}
+
+static inline void
+br_enc32be(void *dst, uint32_t x)
+{
+#if 0 /* BR_BE_UNALIGNED */
+ ((br_union_u32 *)dst)->u = x;
+#else
+ unsigned char *buf;
+
+ buf = dst;
+ buf[0] = (unsigned char)(x >> 24);
+ buf[1] = (unsigned char)(x >> 16);
+ buf[2] = (unsigned char)(x >> 8);
+ buf[3] = (unsigned char)x;
+#endif
+}
+
+static inline uint32_t
+NOT(uint32_t ctl)
+{
+ return ctl ^ 1;
+}
+
+static inline uint32_t
+MUX(uint32_t ctl, uint32_t x, uint32_t y)
+{
+ return y ^ (-ctl & (x ^ y));
+}
+
+static inline uint32_t
+EQ(uint32_t x, uint32_t y)
+{
+ uint32_t q;
+
+ q = x ^ y;
+ return NOT((q | -q) >> 31);
+}
+
+static inline uint32_t
+NEQ(uint32_t x, uint32_t y)
+{
+ uint32_t q;
+
+ q = x ^ y;
+ return (q | -q) >> 31;
+}
+
+static inline uint32_t
+GT(uint32_t x, uint32_t y)
+{
+
[U-Boot] [RFC 1/3] lib: rsa: decouple rsa from FIT image verification
Introduce new configuration, CONFIG_RSA_VERIFY which will decouple building RSA functions from FIT verification and allow for adding a RSA-based signature verification for other file formats, in particular PE file for UEFI secure boot. Signed-off-by: AKASHI Takahiro --- lib/rsa/Kconfig | 7 +++ lib/rsa/Makefile | 2 +- 2 files changed, 8 insertions(+), 1 deletion(-) diff --git a/lib/rsa/Kconfig b/lib/rsa/Kconfig index 2b33f323bccc..338c8124da59 100644 --- a/lib/rsa/Kconfig +++ b/lib/rsa/Kconfig @@ -1,5 +1,6 @@ config RSA bool "Use RSA Library" + select RSA_VERIFY select RSA_FREESCALE_EXP if FSL_CAAM && !ARCH_MX7 && !ARCH_MX6 && !ARCH_MX5 select RSA_SOFTWARE_EXP if !RSA_FREESCALE_EXP help @@ -17,6 +18,12 @@ if RSA config SPL_RSA bool "Use RSA Library within SPL" + select RSA_VERIFY + +config RSA_VERIFY + bool + help + Add RSA signature verification support. config RSA_SOFTWARE_EXP bool "Enable driver for RSA Modular Exponentiation in software" diff --git a/lib/rsa/Makefile b/lib/rsa/Makefile index a51c6e1685fb..226d8f3514a9 100644 --- a/lib/rsa/Makefile +++ b/lib/rsa/Makefile @@ -5,5 +5,5 @@ # (C) Copyright 2000-2007 # Wolfgang Denk, DENX Software Engineering, w...@denx.de. -obj-$(CONFIG_$(SPL_)FIT_SIGNATURE) += rsa-verify.o rsa-checksum.o +obj-$(CONFIG_RSA_VERIFY) += rsa-verify.o rsa-checksum.o obj-$(CONFIG_RSA_SOFTWARE_EXP) += rsa-mod-exp.o -- 2.21.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [RFC 0/3] rsa: extend rsa_verify() for UEFI secure boot
The current rsa_verify() requires five parameters for a RSA public key for efficiency while RSA, in theory, requires only two. In addition, those parameters are expected to come from FIT image. So this function won't fit very well when we want to use it for the purpose of implementing UEFI secure boot, in particular, image authentication as well as variable authentication, where the essential two parameters are set to be retrieved from one of X509 certificates in signature database. So, in this patch, additional three parameters will be calculated on the fly when rsa_verify() is called without fdt which should contain parameters above. This calculation heavily relies on "big-number (or multi-precision) library." Therefore some routines from BearSSL[1] under MIT license are imported in this implementation. See Patch#2. # Please let me know if this is not appropriate. # Checkpatch will complain with lots of warnings/errors, but # I intentionally don't fix them for maximum maintainability. [1] https://bearssl.org/ AKASHI Takahiro (3): lib: rsa: decouple rsa from FIT image verification lib: rsa: generate additional parameters for public key lib: rsa: add rsa_verify_with_pkey() include/u-boot/rsa-mod-exp.h | 3 + lib/rsa/Kconfig | 14 + lib/rsa/Makefile | 3 +- lib/rsa/rsa-keyprop.c| 631 +++ lib/rsa/rsa-verify.c | 63 +++- 5 files changed, 705 insertions(+), 9 deletions(-) create mode 100644 lib/rsa/rsa-keyprop.c -- 2.21.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] efi_loader: cursor positioning
> Am 05.09.2019 um 22:35 schrieb Heinrich Schuchardt :
>
>> On 9/5/19 10:21 PM, Alexander Graf wrote:
>>> On 05.09.19 10:06, Heinrich Schuchardt wrote:
>>> When backspacing in column 0 do no set the column index to ULONG_MAX.
>>> Ensure that the row number is not set to ULONG_MAX even if the row count is
>>> advertised as 0.
>>> Ignore control characters other the 0x08, 0x0a, 0x0d when updating the
>>> column.
>>>
>>> Signed-off-by: Heinrich Schuchardt
>>> ---
>>> lib/efi_loader/efi_console.c | 12
>>> 1 file changed, 8 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/lib/efi_loader/efi_console.c b/lib/efi_loader/efi_console.c
>>> index d4765afb98..d5222c46b4 100644
>>> --- a/lib/efi_loader/efi_console.c
>>> +++ b/lib/efi_loader/efi_console.c
>>> @@ -156,13 +156,14 @@ static efi_status_t EFIAPI efi_cout_output_string(
>>>* Update the cursor position.
>>>*
>>>* The UEFI spec provides advance rules for U+, U+0008, U+000A,
>>> - * and U000D. All other characters, including control characters
>>> - * U+0007 (BEL) and U+0009 (TAB), have to increase the column by one.
>>> + * and U000D. All other control characters are ignored. Any non-control
>>> + * character increase the column by one.
>>>*/
>>> for (p = string; *p; ++p) {
>>> switch (*p) {
>>> case '\b':/* U+0008, backspace */
>>> -con->cursor_column = max(0, con->cursor_column - 1);
>>> +if (con->cursor_column)
>>> +con->cursor_column--;
>>> break;
>>> case '\n':/* U+000A, newline */
>>> con->cursor_column = 0;
>>> @@ -178,13 +179,16 @@ static efi_status_t EFIAPI efi_cout_output_string(
>>>*/
>>> break;
>>> default:
>>> -con->cursor_column++;
>>> +if (*p > 0x1f)
>> What is the 0x1f here? I know, control character, but it's not obvious.
>> Probably wants either a comment or a define.
>
> I will add a comment
>
>>> +con->cursor_column++;
>>> break;
>>> }
>>> if (con->cursor_column >= mode->columns) {
>>> con->cursor_column = 0;
>>> con->cursor_row++;
>>> }
>>> +if (con->cursor_row >= mode->rows && con->cursor_row)
>>> +con->cursor_row--;
>> I don't understand this statement. When is the cursor_row >= mode->rows? Is
>> this just to offset an incorrect cursor_row from the line above? Can't we
>> just fold it in there?
>
> The row is incremented either by line feed or by exceeding the last column.
>
> When we exceed the row limit the terminal will take care of scrolling. We
> have to compensate for the scrolling by decrementing the row.
Please indicate either through a variable or a comment that this compensates
for already executed scrolling.
Alex
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Issue in u-boot; TFTP error: trying to overwrite reserved memory...
Hi, On Thu, Sep 5, 2019 at 4:14 PM Moses Christopher wrote: > Hello together, > > I was trying to build u-boot and spl for the arm target and tried to boot via > usb-ethernet. > I found an issue with one of the commit made in the early 2019, > http://patchwork.ozlabs.org/patch/1024795/ > > When using this CONFIG_LMB the max_size or the lmb_get_free_size(, > load_addr); returns 0, no matter what. > And it triggers the following error, > TFTP error: trying to overwrite reserved memory... > I did a quick fix by adding #undef CONFIG_LMB in the file, net/tftp.c > So, I would like to know why this doesn’t work as it was working before > applying this patch ? Can you add "#define DEBUG" as the first line in 'lib/lmb.c'? That should give you debug output when lmb is used. The lmb code works by getting the RAM size, adding reserved areas and then only allowing allocations in non-reserved areay. However, the RAM size is not fully used depending on some config options and/or environment variables. There's possibly something wrong in your configuration around that. Regards, Simon > > Best regards, > Moses Christopher ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 2/2] efi_loader: selftest: enable APPEND_WRITE tests
Now that APPEND_WRITE is supported,
the result check for the only existing test case should be changed to
'todo' to 'error', while two more test cases are added.
Signed-off-by: AKASHI Takahiro
---
lib/efi_selftest/efi_selftest_variables.c | 20 +++-
1 file changed, 19 insertions(+), 1 deletion(-)
diff --git a/lib/efi_selftest/efi_selftest_variables.c
b/lib/efi_selftest/efi_selftest_variables.c
index 06c1a032dd04..a6b41d1f008d 100644
--- a/lib/efi_selftest/efi_selftest_variables.c
+++ b/lib/efi_selftest/efi_selftest_variables.c
@@ -21,6 +21,9 @@ static const efi_guid_t guid_vendor0 =
static const efi_guid_t guid_vendor1 =
EFI_GUID(0xff629290, 0x1fc1, 0xd73f,
0x8f, 0xb1, 0x32, 0xf9, 0x0c, 0xa0, 0x42, 0xea);
+static const efi_guid_t guid_global =
+ EFI_GUID(0x8be4df61, 0x93ca, 0x11d2,
+0xaa, 0x0d, 0x00, 0xe0, 0x98, 0x03, 0x2b, 0x8c);
/*
* Setup unit test.
@@ -116,7 +119,7 @@ static int execute(void)
EFI_VARIABLE_APPEND_WRITE,
7, v + 8);
if (ret != EFI_SUCCESS) {
- efi_st_todo("SetVariable(APPEND_WRITE) failed\n");
+ efi_st_error("SetVariable(APPEND_WRITE) failed\n");
} else {
len = EFI_ST_MAX_DATA_SIZE;
ret = runtime->get_variable(L"efi_st_var1", _vendor1,
@@ -131,6 +134,21 @@ static int execute(void)
if (memcmp(data, v, len))
efi_st_todo("GetVariable returned wrong value\n");
}
+ /* Append variable 2 */
+ ret = runtime->set_variable(L"efi_none", _vendor1,
+ EFI_VARIABLE_BOOTSERVICE_ACCESS |
+ EFI_VARIABLE_APPEND_WRITE,
+ 15, v);
+ if (ret != EFI_NOT_FOUND)
+ efi_st_error("SetVariable(APPEND_WRITE) with size 0 to
non-existent variable returns wrong code\n");
+ /* Append variable 3 */
+ ret = runtime->set_variable(L"PlatformLangCodes", _global,
+ EFI_VARIABLE_BOOTSERVICE_ACCESS |
+ EFI_VARIABLE_RUNTIME_ACCESS |
+ EFI_VARIABLE_APPEND_WRITE,
+ 15, v);
+ if (ret != EFI_WRITE_PROTECTED)
+ efi_st_todo("SetVariable(APPEND_WRITE) to read-only variable
returns wrong code\n");
/* Enumerate variables */
boottime->set_mem(, 16, 0);
*varname = 0;
--
2.21.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2] cmd: env: extend "env [set|print] -e" to manage UEFI variables
With this patch, when setting UEFI variable with "env set -e" command,
we will be able to
- specify vendor guid with "-guid guid",
- specify variable attributes, BOOTSERVICE_ACCESS, RUNTIME_ACCESS,
respectively with "-bs" and "-rt",
- append a value instead of overwriting with "-a",
- use memory as variable's value instead of explicit values given
at the command line with "-i address,size"
If guid is not explicitly given, default value will be used.
When "-at" is given, a variable should be authenticated with
appropriate signature database before setting or modifying its value.
(Authentication is not supported yet though.)
Meanwhile, "env print -e," will be modified so that it will dump
a variable's value only if '-v' (verbose) is specified.
Signed-off-by: AKASHI Takahiro
---
Changes in v2 (Sept 6, 2019)
* remove "-at" option
---
cmd/nvedit.c | 19 +++--
cmd/nvedit_efi.c | 189 ++-
2 files changed, 168 insertions(+), 40 deletions(-)
diff --git a/cmd/nvedit.c b/cmd/nvedit.c
index 1cb0bc1460b9..1e542972db30 100644
--- a/cmd/nvedit.c
+++ b/cmd/nvedit.c
@@ -1387,7 +1387,7 @@ static char env_help_text[] =
#endif
"env print [-a | name ...] - print environment\n"
#if defined(CONFIG_CMD_NVEDIT_EFI)
- "env print -e [name ...] - print UEFI environment\n"
+ "env print -e [-v] [name ...] - print UEFI environment\n"
#endif
#if defined(CONFIG_CMD_RUN)
"env run var [...] - run commands in an environment variable\n"
@@ -1399,7 +1399,8 @@ static char env_help_text[] =
#endif
#endif
#if defined(CONFIG_CMD_NVEDIT_EFI)
- "env set -e name [arg ...] - set UEFI variable; unset if 'arg' not
specified\n"
+ "env set -e [-nv][-bs][-rt][-a][-i addr,size][-v] name [arg ...]\n"
+ "- set UEFI variable; unset if '-i' or 'arg' not specified\n"
#endif
"env set [-f] name [arg ...]\n";
#endif
@@ -1428,8 +1429,9 @@ U_BOOT_CMD_COMPLETE(
"print environment variables",
"[-a]\n- print [all] values of all environment variables\n"
#if defined(CONFIG_CMD_NVEDIT_EFI)
- "printenv -e [name ...]\n"
+ "printenv -e [-v] [name ...]\n"
"- print UEFI variable 'name' or all the variables\n"
+ " \"-v\": verbose for signature database\n"
#endif
"printenv name ...\n"
"- print value of environment variable 'name'",
@@ -1459,9 +1461,16 @@ U_BOOT_CMD_COMPLETE(
setenv, CONFIG_SYS_MAXARGS, 0, do_env_set,
"set environment variables",
#if defined(CONFIG_CMD_NVEDIT_EFI)
- "-e [-nv] name [value ...]\n"
+ "-e [-guid guid][-nv][-bs][-rt][-a][-v]\n"
+ "[-i addr,size name], or [name [value ...]]\n"
"- set UEFI variable 'name' to 'value' ...'\n"
- " 'nv' option makes the variable non-volatile\n"
+ " \"-guid\": set vendor guid\n"
+ " \"-nv\": set non-volatile attribute\n"
+ " \"-bs\": set boot-service attribute\n"
+ " \"-rt\": set runtime attribute\n"
+ " \"-a\": append-write\n"
+ " \"-i addr,size\": use as variable's value\n"
+ " \"-v\": verbose print\n"
"- delete UEFI variable 'name' if 'value' not specified\n"
#endif
"setenv [-f] name value ...\n"
diff --git a/cmd/nvedit_efi.c b/cmd/nvedit_efi.c
index ed6d09a53046..67e732e8d520 100644
--- a/cmd/nvedit_efi.c
+++ b/cmd/nvedit_efi.c
@@ -13,6 +13,7 @@
#include
#include
#include
+#include
#include
/*
@@ -34,15 +35,48 @@ static const struct {
{EFI_VARIABLE_TIME_BASED_AUTHENTICATED_WRITE_ACCESS, "AT"},
};
+static const struct {
+ efi_guid_t guid;
+ char *text;
+} efi_guid_text[] = {
+ /* signature database */
+ {EFI_GLOBAL_VARIABLE_GUID, "EFI_GLOBAL_VARIABLE_GUID"},
+};
+
+/* "----" */
+static char unknown_guid[37];
+
+/**
+ * efi_guid_to_str() - convert guid to readable name
+ *
+ * @guid: GUID
+ * Return: string for GUID
+ *
+ * convert guid to readable name
+ */
+static const char *efi_guid_to_str(efi_guid_t *guid)
+{
+ int i;
+
+ for (i = 0; i < ARRAY_SIZE(efi_guid_text); i++)
+ if (!guidcmp(guid, _guid_text[i].guid))
+ return efi_guid_text[i].text;
+
+ uuid_bin_to_str(guid->b, unknown_guid, UUID_STR_FORMAT_GUID);
+
+ return unknown_guid;
+}
+
/**
* efi_dump_single_var() - show information about a UEFI variable
*
* @name: Name of the variable
* @guid: Vendor GUID
+ * @verbose: if true, dump data
*
* Show information encoded in one UEFI variable
*/
-static void efi_dump_single_var(u16 *name, efi_guid_t *guid)
+static void efi_dump_single_var(u16 *name, efi_guid_t *guid, bool verbose)
{
u32 attributes;
u8 *data;
@@ -68,7 +102,7 @@ static void efi_dump_single_var(u16 *name, efi_guid_t *guid)
if (ret != EFI_SUCCESS)
goto out;
- printf("%ls:",
[U-Boot] [PATCH v2 1/2] efi_loader: variable: support APPEND_WRITE
If EFI_VARIABLE_APPEND_WRITE is specified in attributes at
efi_set_variable(), specified data will be appended to the variable's
original value. Attributes other than APPEND_WRITE should not be
modified.
With this patch, APPEND_WRITE test in 'variables' selftest will pass.
Signed-off-by: AKASHI Takahiro
---
lib/efi_loader/efi_variable.c | 70 ++-
1 file changed, 44 insertions(+), 26 deletions(-)
diff --git a/lib/efi_loader/efi_variable.c b/lib/efi_loader/efi_variable.c
index 6687b69a400d..48ee255f879b 100644
--- a/lib/efi_loader/efi_variable.c
+++ b/lib/efi_loader/efi_variable.c
@@ -424,17 +424,17 @@ efi_status_t EFIAPI efi_set_variable(u16 *variable_name,
efi_uintn_t data_size, const void *data)
{
char *native_name = NULL, *val = NULL, *s;
+ const char *old_val;
+ size_t old_size;
efi_status_t ret = EFI_SUCCESS;
u32 attr;
EFI_ENTRY("\"%ls\" %pUl %x %zu %p", variable_name, vendor, attributes,
data_size, data);
- /* TODO: implement APPEND_WRITE */
if (!variable_name || !*variable_name || !vendor ||
((attributes & EFI_VARIABLE_RUNTIME_ACCESS) &&
-!(attributes & EFI_VARIABLE_BOOTSERVICE_ACCESS)) ||
- (attributes & EFI_VARIABLE_APPEND_WRITE)) {
+!(attributes & EFI_VARIABLE_BOOTSERVICE_ACCESS))) {
ret = EFI_INVALID_PARAMETER;
goto out;
}
@@ -445,35 +445,51 @@ efi_status_t EFIAPI efi_set_variable(u16 *variable_name,
#define ACCESS_ATTR (EFI_VARIABLE_RUNTIME_ACCESS |
EFI_VARIABLE_BOOTSERVICE_ACCESS)
- if ((data_size == 0) || !(attributes & ACCESS_ATTR)) {
- /* delete the variable: */
- env_set(native_name, NULL);
- ret = EFI_SUCCESS;
- goto out;
- }
+ old_val = env_get(native_name);
+ if (old_val) {
+ old_val = parse_attr(old_val, );
- val = env_get(native_name);
- if (val) {
- parse_attr(val, );
-
- /* We should not free val */
- val = NULL;
+ /* check read-only first */
if (attr & READ_ONLY) {
ret = EFI_WRITE_PROTECTED;
goto out;
}
- /*
-* attributes won't be changed
-* TODO: take care of APPEND_WRITE once supported
-*/
- if (attr != attributes) {
+ if ((data_size == 0) || !(attributes & ACCESS_ATTR)) {
+ /* delete the variable: */
+ env_set(native_name, NULL);
+ ret = EFI_SUCCESS;
+ goto out;
+ }
+
+ /* attributes won't be changed */
+ if (attr != (attributes & ~EFI_VARIABLE_APPEND_WRITE)) {
ret = EFI_INVALID_PARAMETER;
goto out;
}
+
+ if (attributes & EFI_VARIABLE_APPEND_WRITE) {
+ if (!prefix(old_val, "(blob)")) {
+ return EFI_DEVICE_ERROR;
+ goto out;
+ }
+ old_size = strlen(old_val);
+ } else {
+ old_size = 0;
+ }
+ } else {
+ if ((data_size == 0) || !(attributes & ACCESS_ATTR) ||
+ (attributes & EFI_VARIABLE_APPEND_WRITE)) {
+ /* delete, but nothing to do */
+ ret = EFI_NOT_FOUND;
+ goto out;
+ }
+
+ old_size = 0;
}
- val = malloc(2 * data_size + strlen("{ro,run,boot,nv}(blob)") + 1);
+ val = malloc(old_size + 2 * data_size
++ strlen("{ro,run,boot,nv}(blob)") + 1);
if (!val) {
ret = EFI_OUT_OF_RESOURCES;
goto out;
@@ -481,10 +497,7 @@ efi_status_t EFIAPI efi_set_variable(u16 *variable_name,
s = val;
- /*
-* store attributes
-* TODO: several attributes are not supported
-*/
+ /* store attributes */
attributes &= (EFI_VARIABLE_NON_VOLATILE |
EFI_VARIABLE_BOOTSERVICE_ACCESS |
EFI_VARIABLE_RUNTIME_ACCESS);
@@ -505,8 +518,13 @@ efi_status_t EFIAPI efi_set_variable(u16 *variable_name,
}
s += sprintf(s, "}");
+ if (old_size)
+ /* APPEND_WRITE */
+ s += sprintf(s, old_val);
+ else
+ s += sprintf(s, "(blob)");
+
/* store payload: */
- s += sprintf(s, "(blob)");
s = bin2hex(s, data, data_size);
*s = '\0';
--
2.21.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 0/2] efi_loader: support APPEND_WRITE
Changes in v2 (Sept 6, 2019) * add a check against read-only variable to delete with APPEND_WRITE * add a check against non-existent variable to append * add/modify APPEND_WRITE tests AKASHI Takahiro (2): efi_loader: variable: support APPEND_WRITE efi_loader: selftest: enable APPEND_WRITE tests lib/efi_loader/efi_variable.c | 70 ++- lib/efi_selftest/efi_selftest_variables.c | 20 ++- 2 files changed, 63 insertions(+), 27 deletions(-) -- 2.21.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [v2, 1/3] mmc: fsl_esdhc: make BLK as hard requirement of DM_MMC
Current fsl_esdhc driver had support DM_MMC with BLK enabled.
Since BLK will be hard requirement of DM_MMC, let's do this
now in fsl_esdhc driver. Don't keep BLK conditioanl compiling.
Signed-off-by: Yangbo Lu
---
Changes for v2:
- None.
---
drivers/mmc/fsl_esdhc.c | 35 +--
1 file changed, 1 insertion(+), 34 deletions(-)
diff --git a/drivers/mmc/fsl_esdhc.c b/drivers/mmc/fsl_esdhc.c
index 0731847..ff5565c 100644
--- a/drivers/mmc/fsl_esdhc.c
+++ b/drivers/mmc/fsl_esdhc.c
@@ -23,10 +23,6 @@
#include
#include
-#if !CONFIG_IS_ENABLED(BLK)
-#include "mmc_private.h"
-#endif
-
DECLARE_GLOBAL_DATA_PTR;
#define SDHCI_IRQ_EN_BITS (IRQSTATEN_CC | IRQSTATEN_TC | \
@@ -35,7 +31,6 @@ DECLARE_GLOBAL_DATA_PTR;
IRQSTATEN_CIE | IRQSTATEN_DTOE | IRQSTATEN_DCE
| \
IRQSTATEN_DEBE | IRQSTATEN_BRR | IRQSTATEN_BWR
| \
IRQSTATEN_DINT)
-#define ESDHC_DRIVER_STAGE_VALUE 0x
struct fsl_esdhc {
uintdsaddr; /* SDMA system address register */
@@ -98,7 +93,7 @@ struct fsl_esdhc_priv {
struct clk per_clk;
unsigned int clock;
unsigned int bus_width;
-#if !CONFIG_IS_ENABLED(BLK)
+#if !CONFIG_IS_ENABLED(DM_MMC)
struct mmc *mmc;
#endif
struct udevice *dev;
@@ -961,9 +956,6 @@ static int fsl_esdhc_probe(struct udevice *dev)
fdt_addr_t addr;
unsigned int val;
struct mmc *mmc;
-#if !CONFIG_IS_ENABLED(BLK)
- struct blk_desc *bdesc;
-#endif
int ret;
addr = dev_read_addr(dev);
@@ -1027,32 +1019,12 @@ static int fsl_esdhc_probe(struct udevice *dev)
mmc = >mmc;
mmc->cfg = >cfg;
mmc->dev = dev;
-#if !CONFIG_IS_ENABLED(BLK)
- mmc->priv = priv;
-
- /* Setup dsr related values */
- mmc->dsr_imp = 0;
- mmc->dsr = ESDHC_DRIVER_STAGE_VALUE;
- /* Setup the universal parts of the block interface just once */
- bdesc = mmc_get_blk_desc(mmc);
- bdesc->if_type = IF_TYPE_MMC;
- bdesc->removable = 1;
- bdesc->devnum = mmc_get_next_devnum();
- bdesc->block_read = mmc_bread;
- bdesc->block_write = mmc_bwrite;
- bdesc->block_erase = mmc_berase;
-
- /* setup initial part type */
- bdesc->part_type = mmc->cfg->part_type;
- mmc_list_add(mmc);
-#endif
upriv->mmc = mmc;
return esdhc_init_common(priv, mmc);
}
-#if CONFIG_IS_ENABLED(DM_MMC)
static int fsl_esdhc_get_cd(struct udevice *dev)
{
struct fsl_esdhc_priv *priv = dev_get_priv(dev);
@@ -1082,30 +1054,25 @@ static const struct dm_mmc_ops fsl_esdhc_ops = {
.send_cmd = fsl_esdhc_send_cmd,
.set_ios= fsl_esdhc_set_ios,
};
-#endif
static const struct udevice_id fsl_esdhc_ids[] = {
{ .compatible = "fsl,esdhc", },
{ /* sentinel */ }
};
-#if CONFIG_IS_ENABLED(BLK)
static int fsl_esdhc_bind(struct udevice *dev)
{
struct fsl_esdhc_plat *plat = dev_get_platdata(dev);
return mmc_bind(dev, >mmc, >cfg);
}
-#endif
U_BOOT_DRIVER(fsl_esdhc) = {
.name = "fsl-esdhc-mmc",
.id = UCLASS_MMC,
.of_match = fsl_esdhc_ids,
.ops= _esdhc_ops,
-#if CONFIG_IS_ENABLED(BLK)
.bind = fsl_esdhc_bind,
-#endif
.probe = fsl_esdhc_probe,
.platdata_auto_alloc_size = sizeof(struct fsl_esdhc_plat),
.priv_auto_alloc_size = sizeof(struct fsl_esdhc_priv),
--
2.7.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [v2, 2/3] mmc: fsl_esdhc: clean up code
This patch is just to clean up code. There were not changes on function.
Signed-off-by: Yangbo Lu
---
Changes for v2:
- Involved esdhc_ops in non-DM conditional build.
---
drivers/mmc/fsl_esdhc.c | 286
include/fsl_esdhc.h | 203 --
2 files changed, 238 insertions(+), 251 deletions(-)
diff --git a/drivers/mmc/fsl_esdhc.c b/drivers/mmc/fsl_esdhc.c
index ff5565c..3b079f1 100644
--- a/drivers/mmc/fsl_esdhc.c
+++ b/drivers/mmc/fsl_esdhc.c
@@ -25,12 +25,13 @@
DECLARE_GLOBAL_DATA_PTR;
-#define SDHCI_IRQ_EN_BITS (IRQSTATEN_CC | IRQSTATEN_TC | \
- IRQSTATEN_CINT | \
- IRQSTATEN_CTOE | IRQSTATEN_CCE | IRQSTATEN_CEBE
| \
- IRQSTATEN_CIE | IRQSTATEN_DTOE | IRQSTATEN_DCE
| \
- IRQSTATEN_DEBE | IRQSTATEN_BRR | IRQSTATEN_BWR
| \
- IRQSTATEN_DINT)
+#define ESDHC_IRQ_EN_BITS (IRQSTATEN_CC | IRQSTATEN_TC | \
+ IRQSTATEN_DINT | IRQSTATEN_BWR | \
+ IRQSTATEN_BRR | IRQSTATEN_CINT | \
+ IRQSTATEN_CTOE | IRQSTATEN_CCE | \
+ IRQSTATEN_CEBE | IRQSTATEN_CIE | \
+ IRQSTATEN_DTOE | IRQSTATEN_DCE | \
+ IRQSTATEN_DEBE)
struct fsl_esdhc {
uintdsaddr; /* SDMA system address register */
@@ -76,16 +77,15 @@ struct fsl_esdhc_plat {
* struct fsl_esdhc_priv
*
* @esdhc_regs: registers of the sdhc controller
- * @sdhc_clk: Current clk of the sdhc controller
+ * @sdhc_clk: reference clk of the sdhc controller
+ * @per_clk: peripheral clock
+ * @clock: target clock
* @bus_width: bus width, 1bit, 4bit or 8bit
- * @cfg: mmc config
* @mmc: mmc
* Following is used when Driver Model is enabled for MMC
* @dev: pointer for the device
* @non_removable: 0: removable; 1: non-removable
* @wp_enable: 1: enable checking wp; 0: no check
- * @cd_gpio: gpio for card detection
- * @wp_gpio: gpio for write protection
*/
struct fsl_esdhc_priv {
struct fsl_esdhc *esdhc_regs;
@@ -102,7 +102,7 @@ struct fsl_esdhc_priv {
};
/* Return the XFERTYP flags for a given command and data packet */
-static uint esdhc_xfertyp(struct mmc_cmd *cmd, struct mmc_data *data)
+static uint esdhc_setup_xfertyp(struct mmc_cmd *cmd, struct mmc_data *data)
{
uint xfertyp = 0;
@@ -310,9 +310,9 @@ static int esdhc_setup_data(struct fsl_esdhc_priv *priv,
struct mmc *mmc,
return 0;
}
-static void check_and_invalidate_dcache_range
- (struct mmc_cmd *cmd,
-struct mmc_data *data) {
+static void esdhc_invalidate_dcache_range(struct mmc_cmd *cmd,
+ struct mmc_data *data)
+{
unsigned start = 0;
unsigned end = 0;
unsigned size = roundup(ARCH_DMA_MINALIGN,
@@ -377,11 +377,11 @@ static int esdhc_send_cmd_common(struct fsl_esdhc_priv
*priv, struct mmc *mmc,
return err;
if (data->flags & MMC_DATA_READ)
- check_and_invalidate_dcache_range(cmd, data);
+ esdhc_invalidate_dcache_range(cmd, data);
}
/* Figure out the transfer arguments */
- xfertyp = esdhc_xfertyp(cmd, data);
+ xfertyp = esdhc_setup_xfertyp(cmd, data);
/* Mask all irqs */
esdhc_write32(>irqsigen, 0);
@@ -479,7 +479,7 @@ static int esdhc_send_cmd_common(struct fsl_esdhc_priv
*priv, struct mmc *mmc,
* speculative pre-fetching etc.
*/
if (data->flags & MMC_DATA_READ) {
- check_and_invalidate_dcache_range(cmd, data);
+ esdhc_invalidate_dcache_range(cmd, data);
}
#endif
}
@@ -506,7 +506,8 @@ out:
return err;
}
-static void set_sysctl(struct fsl_esdhc_priv *priv, struct mmc *mmc, uint
clock)
+static void esdhc_set_clock(struct fsl_esdhc_priv *priv, struct mmc *mmc,
+ uint clock)
{
struct fsl_esdhc *regs = priv->esdhc_regs;
int div = 1;
@@ -581,7 +582,7 @@ static int esdhc_set_ios_common(struct fsl_esdhc_priv
*priv, struct mmc *mmc)
#endif
/* Set the clock speed */
if (priv->clock != mmc->clock)
- set_sysctl(priv, mmc, mmc->clock);
+ esdhc_set_clock(priv, mmc, mmc->clock);
/* Set the bus width */
esdhc_clrbits32(>proctl, PROCTL_DTW_4 | PROCTL_DTW_8);
@@ -670,41 +671,7 @@ static int esdhc_reset(struct fsl_esdhc *regs)
}
#if !CONFIG_IS_ENABLED(DM_MMC)
-static int esdhc_getcd(struct mmc *mmc)
-{
- struct fsl_esdhc_priv *priv = mmc->priv;
-
- return esdhc_getcd_common(priv);
-}
-
-static int esdhc_init(struct mmc *mmc)
-{
- struct fsl_esdhc_priv *priv = mmc->priv;
-
[U-Boot] [v2, 3/3] mmc: fsl_esdhc: rename fsl_esdhc_init to fsl_esdhc_get_cfg
For non-DM code, below functions had similar names.
- fsl_esdhc_initialize
- fsl_esdhc_mmc_init
- fsl_esdhc_init
However fsl_esdhc_init was mainly used to get cfg. So rename it
to fsl_esdhc_get_cfg. Fix up bus-width capability handling, and
drop controller initialization because it will be re-initialized
in later esdhc_init_common for DM or esdhc_init for non-DM when use
it.
Signed-off-by: Yangbo Lu
---
Changes for v2:
- Rebased.
---
drivers/mmc/fsl_esdhc.c | 68 -
1 file changed, 11 insertions(+), 57 deletions(-)
diff --git a/drivers/mmc/fsl_esdhc.c b/drivers/mmc/fsl_esdhc.c
index 3b079f1..03a7e89 100644
--- a/drivers/mmc/fsl_esdhc.c
+++ b/drivers/mmc/fsl_esdhc.c
@@ -25,14 +25,6 @@
DECLARE_GLOBAL_DATA_PTR;
-#define ESDHC_IRQ_EN_BITS (IRQSTATEN_CC | IRQSTATEN_TC | \
- IRQSTATEN_DINT | IRQSTATEN_BWR | \
- IRQSTATEN_BRR | IRQSTATEN_CINT | \
- IRQSTATEN_CTOE | IRQSTATEN_CCE | \
- IRQSTATEN_CEBE | IRQSTATEN_CIE | \
- IRQSTATEN_DTOE | IRQSTATEN_DCE | \
- IRQSTATEN_DEBE)
-
struct fsl_esdhc {
uintdsaddr; /* SDMA system address register */
uintblkattr;/* Block attributes register */
@@ -651,57 +643,25 @@ static int esdhc_getcd_common(struct fsl_esdhc_priv *priv)
return timeout > 0;
}
-static int esdhc_reset(struct fsl_esdhc *regs)
-{
- ulong start;
-
- /* reset the controller */
- esdhc_setbits32(>sysctl, SYSCTL_RSTA);
-
- /* hardware clears the bit when it is done */
- start = get_timer(0);
- while ((esdhc_read32(>sysctl) & SYSCTL_RSTA)) {
- if (get_timer(start) > 100) {
- printf("MMC/SD: Reset never completed.\n");
- return -ETIMEDOUT;
- }
- }
-
- return 0;
-}
-
#if !CONFIG_IS_ENABLED(DM_MMC)
static const struct mmc_ops esdhc_ops;
#endif
-static int fsl_esdhc_init(struct fsl_esdhc_priv *priv,
- struct fsl_esdhc_plat *plat)
+static int fsl_esdhc_get_cfg(struct fsl_esdhc_priv *priv,
+struct fsl_esdhc_plat *plat)
{
+ struct fsl_esdhc *regs = priv->esdhc_regs;
+ u32 caps, voltage_caps = 0;
struct mmc_config *cfg;
- struct fsl_esdhc *regs;
- u32 caps, voltage_caps;
- int ret;
if (!priv)
return -EINVAL;
- regs = priv->esdhc_regs;
-
- /* First reset the eSDHC controller */
- ret = esdhc_reset(regs);
- if (ret)
- return ret;
-
- esdhc_setbits32(>sysctl, SYSCTL_PEREN | SYSCTL_HCKEN |
- SYSCTL_IPGEN | SYSCTL_CKEN);
-
- writel(ESDHC_IRQ_EN_BITS, >irqstaten);
cfg = >cfg;
#ifndef CONFIG_DM_MMC
memset(cfg, '\0', sizeof(*cfg));
#endif
- voltage_caps = 0;
caps = esdhc_read32(>hostcapblt);
#ifdef CONFIG_SYS_FSL_ERRATUM_ESDHC135
@@ -739,18 +699,10 @@ static int fsl_esdhc_init(struct fsl_esdhc_priv *priv,
else if (priv->bus_width == 4)
cfg->host_caps = MMC_MODE_4BIT;
- cfg->host_caps = MMC_MODE_4BIT | MMC_MODE_8BIT;
#ifdef CONFIG_SYS_FSL_ESDHC_HAS_DDR_MODE
cfg->host_caps |= MMC_MODE_DDR_52MHz;
#endif
- if (priv->bus_width > 0) {
- if (priv->bus_width < 8)
- cfg->host_caps &= ~MMC_MODE_8BIT;
- if (priv->bus_width < 4)
- cfg->host_caps &= ~MMC_MODE_4BIT;
- }
-
if (caps & HOSTCAPBLT2_HSS)
cfg->host_caps |= MMC_MODE_HS_52MHz | MMC_MODE_HS;
@@ -761,7 +713,6 @@ static int fsl_esdhc_init(struct fsl_esdhc_priv *priv,
cfg->f_min = 40;
cfg->f_max = min(priv->sdhc_clk, (u32)2);
-
cfg->b_max = CONFIG_SYS_MMC_MAX_BLK_COUNT;
return 0;
@@ -884,7 +835,10 @@ static int fsl_esdhc_cfg_to_priv(struct fsl_esdhc_cfg *cfg,
return -EINVAL;
priv->esdhc_regs = (struct fsl_esdhc *)(unsigned long)(cfg->esdhc_base);
- priv->bus_width = cfg->max_bus_width;
+ if (cfg->max_bus_width)
+ priv->bus_width = cfg->max_bus_width;
+ else
+ priv->bus_width = 4;
priv->sdhc_clk = cfg->sdhc_clk;
priv->wp_enable = cfg->wp_enable;
@@ -919,7 +873,7 @@ int fsl_esdhc_initialize(bd_t *bis, struct fsl_esdhc_cfg
*cfg)
return ret;
}
- ret = fsl_esdhc_init(priv, plat);
+ ret = fsl_esdhc_get_cfg(priv, plat);
if (ret) {
debug("%s init failure\n", __func__);
free(plat);
@@ -1014,9 +968,9 @@ static int fsl_esdhc_probe(struct udevice *dev)
}
}
- ret = fsl_esdhc_init(priv, plat);
+ ret = fsl_esdhc_get_cfg(priv, plat);
if
[U-Boot] [v2, 0/3] mmc: fsl_esdhc: clean up code
This patch-set is to clean up fsl_esdhc code. Changes for v2: - Involved esdhc_ops in non-DM conditional build. Yangbo Lu (3): mmc: fsl_esdhc: make BLK as hard requirement of DM_MMC mmc: fsl_esdhc: clean up code mmc: fsl_esdhc: rename fsl_esdhc_init to fsl_esdhc_get_cfg drivers/mmc/fsl_esdhc.c | 369 +++- include/fsl_esdhc.h | 203 -- 2 files changed, 240 insertions(+), 332 deletions(-) -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 0/3] mmc: fsl_esdhc: clean up code
Hi Peng, > -Original Message- > From: Peng Fan > Sent: Friday, September 6, 2019 10:12 AM > To: Y.b. Lu ; u-boot@lists.denx.de > Subject: RE: [PATCH 0/3] mmc: fsl_esdhc: clean up code > > > Subject: RE: [PATCH 0/3] mmc: fsl_esdhc: clean up code > > > > Any comments? > > Patchset break build https://travis-ci.org/MrVan/u-boot/jobs/581073165 > > Please take a look. [Y.b. Lu] Sorry. I hadn't seen this issue with my toolchain. I have reproduced with buildman. Let me send out v2 patch-set. The esdhc_ops declaration should be involved in non-DM conditional build. Thanks. > > Regards, > Peng. > > > Thanks:) > > > > > -Original Message- > > > From: Yangbo Lu > > > Sent: Monday, August 19, 2019 4:28 PM > > > To: u-boot@lists.denx.de; Peng Fan > > > Cc: Y.b. Lu > > > Subject: [PATCH 0/3] mmc: fsl_esdhc: clean up code > > > > > > This patch-set is to clean up fsl_esdhc code. > > > > > > Yangbo Lu (3): > > > mmc: fsl_esdhc: make BLK as hard requirement of DM_MMC > > > mmc: fsl_esdhc: clean up code > > > mmc: fsl_esdhc: rename fsl_esdhc_init to fsl_esdhc_get_cfg > > > > > > drivers/mmc/fsl_esdhc.c | 371 > > +++- > > > include/fsl_esdhc.h | 203 -- > > > 2 files changed, 240 insertions(+), 334 deletions(-) > > > > > > -- > > > 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
