Re: [U-Boot] [PATCH v2 2/3] efi_loader: enumerate disk devices every time
Heinrich,
On Tue, Dec 11, 2018 at 08:55:41PM +0100, Heinrich Schuchardt wrote:
> On 11/15/18 5:58 AM, AKASHI Takahiro wrote:
> > Currently, efi_init_obj_list() scan disk devices only once, and never
> > change a list of efi disk devices. This will possibly result in failing
> > to find a removable storage which may be added later on. See [1].
> >
> > In this patch, called is efi_disk_update() which is responsible for
> > re-scanning UCLASS_BLK devices and removing/adding efi disks if necessary.
> >
> > For example,
> >
> > => efishell devices
> > Scanning disk pci_mmc.blk...
> > Found 3 disks
> > Device Name
> >
> > /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)
> > /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/SD(0)/SD(0)
> > /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/SD(0)/SD(0)/HD(2,MBR,0x086246ba,0x40800,0x3f800)
> > => usb start
> > starting USB...
> > USB0: USB EHCI 1.00
> > scanning bus 0 for devices... 3 USB Device(s) found
> >scanning usb for storage devices... 1 Storage Device(s) found
> > => efishell devices
> > Scanning disk usb_mass_storage.lun0...
> > Device Name
> >
> > /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)
> > /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/SD(0)/SD(0)
> > /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/SD(0)/SD(0)/HD(2,MBR,0x086246ba,0x40800,0x3f800)
> > /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/USBClass(0,0,9,0,1)/USBClass(46f4,1,0,0,0)/HD(1,0x01,0,0x40,0x14fe4c)
> >
> > Without this patch, the last device, USB mass storage, won't show up.
> >
> > [1] https://lists.denx.de/pipermail/u-boot/2018-October/345307.html
> >
> > Signed-off-by: AKASHI Takahiro
>
> Why should we try to fix something in the EFI subsystems that goes wrong
> in the handling of device enumeration.
No.
This is a natural result from how efi disks are currently implemented on u-boot.
Do you want to totally re-write/re-implement efi disks?
Furthermore, your comment here doesn't match your previous comment[1].
[1] https://lists.denx.de/pipermail/u-boot/2018-November/346860.html
-Takahiro Akashi
> @Marek
> Why should a 'usb start' command be needed to make a plugged in device
> available?
>
> Best regards
>
> Heirnich
>
>
>
> > ---
> > cmd/bootefi.c | 17 +++-
> > include/efi_loader.h | 4 +
> > lib/efi_loader/efi_disk.c | 191 ++
> > 3 files changed, 210 insertions(+), 2 deletions(-)
> >
> > diff --git a/cmd/bootefi.c b/cmd/bootefi.c
> > index 3cefb4d0ecaa..82649e211fda 100644
> > --- a/cmd/bootefi.c
> > +++ b/cmd/bootefi.c
> > @@ -56,9 +56,22 @@ efi_status_t efi_init_obj_list(void)
> > */
> > efi_save_gd();
> >
> > - /* Initialize once only */
> > - if (efi_obj_list_initialized != OBJ_LIST_NOT_INITIALIZED)
> > + if (efi_obj_list_initialized == EFI_SUCCESS) {
> > +#ifdef CONFIG_PARTITIONS
> > + ret = efi_disk_update();
> > + if (ret != EFI_SUCCESS)
> > + printf("+++ updating disks list failed\n");
> > +
> > + /*
> > +* It may sound odd, but most part of EFI should
> > +* yet work.
> > +*/
> > +#endif
> > return efi_obj_list_initialized;
> > + } else if (efi_obj_list_initialized != OBJ_LIST_NOT_INITIALIZED) {
> > + /* Initialize once only */
> > + return efi_obj_list_initialized;
> > + }
> >
> > /* Initialize system table */
> > ret = efi_initialize_system_table();
> > diff --git a/include/efi_loader.h b/include/efi_loader.h
> > index 5cc3bded03fa..3bae1844befb 100644
> > --- a/include/efi_loader.h
> > +++ b/include/efi_loader.h
> > @@ -260,6 +260,10 @@ efi_status_t efi_initialize_system_table(void);
> > efi_status_t efi_console_register(void);
> > /* Called by bootefi to make all disk storage accessible as EFI objects */
> > efi_status_t efi_disk_register(void);
> > +/* Check validity of efi disk */
> > +bool efi_disk_is_valid(efi_handle_t handle);
> > +/* Called by bootefi to find and update disk storage information */
> > +efi_status_t efi_disk_update(void);
> > /* Create handles and protocols for the partitions of a block device */
> > int efi_disk_create_partitions(efi_handle_t parent, struct blk_desc *desc,
> >const char *if_typename, int diskid,
> > diff --git a/lib/efi_loader/efi_disk.c b/lib/efi_loader/efi_disk.c
> > index c037526ad2d0..0c4d79ee3fc9 100644
> > --- a/lib/efi_loader/efi_disk.c
> > +++ b/lib/efi_loader/efi_disk.c
> > @@ -14,10 +14,14 @@
> >
> > const efi_guid_t efi_block_io_guid = BLOCK_IO_GUID;
> >
> > +#define _EFI_DISK_FLAG_DELETED 0x1 /* to be removed */
> > +#define _EFI_DISK_FLAG_INVALID 0x8000 /* in stale state */
> > +
> > /**
> > * struct efi_disk_obj - EFI disk object
> > *
> > * @header:EFI object header
> > + * @flags: control flags
> > * @ops: EFI disk I/O protocol interface
> >
Re: [U-Boot] [PATCH v3 11/31] blk: Call part_init() in the post_probe() method
On 12/13/18 8:40 AM, Bin Meng wrote:
Hi Hannes,
Hi Bin,
On Thu, Dec 13, 2018 at 3:19 PM Hannes Schmelzer wrote:
On 10/15/18 11:21 AM, Bin Meng wrote:
part_init() is currently called in every DM BLK driver, either
in its bind() or probe() method. However we can use the BLK
uclass driver's post_probe() method to do it automatically.
Update all DM BLK drivers to adopt this change.
Signed-off-by: Bin Meng
Reviewed-by: Simon Glass
---
Changes in v3: None
Changes in v2: None
cmd/sata.c| 9 -
common/usb_storage.c | 4 +---
drivers/block/blk-uclass.c| 12
drivers/block/ide.c | 2 --
drivers/block/sandbox.c | 2 +-
drivers/mmc/mmc.c | 3 ---
drivers/nvme/nvme.c | 1 -
drivers/scsi/scsi.c | 1 -
lib/efi_driver/efi_block_device.c | 2 --
9 files changed, 14 insertions(+), 22 deletions(-)
Hi Bin,
sorry for this very late report on this.
I Just merged the 'v2019.01-rc1' tag into my branch and noticed that
filesystem on my eMMC targets are not working anymore.
Bisect showed up, that this commit breaks the stuff.
I reviewed the change a bit and i would say that all other block devices
should work as known, except MMC, NVME and EFI (i do not have one, so i
cannot test).
diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
index 585951c..d6b9cdc 100644
--- a/drivers/mmc/mmc.c
+++ b/drivers/mmc/mmc.c
@@ -2444,9 +2444,6 @@ static int mmc_startup(struct mmc *mmc)
bdesc->product[0] = 0;
bdesc->revision[0] = 0;
#endif
-#if !defined(CONFIG_SPL_BUILD) || defined(CONFIG_SPL_LIBDISK_SUPPORT)
- part_init(bdesc);
-#endif
return 0;
}
i changed this to:
#if (!defined(CONFIG_SPL_BUILD) || defined(CONFIG_SPL_LIBDISK_SUPPORT)) && \
!defined(CONFIG_BLK)
part_init(bdesc);
#endif
I don't understand. The patch above removed 3 lines. Did you say that
you added back these 3 lines with additional "!defined(CONFIG_BLK)"?
Yes,
in case if CONFIG_BLK is disabled (meaning blk-uclass.c isn't compiled
in and does therefore nothing),
the part_init(...) has to be done here.
OK, now I understand. But you should convert your board to use DM MMC
instead. It's the right timing now.
OK, thats already on my plan to do this since the deadline becomes closer.
So we let the "bug" as it is and force people to convert more quickly ;-)
diff --git a/drivers/nvme/nvme.c b/drivers/nvme/nvme.c
index eb6fded..1ee0a0a 100644
--- a/drivers/nvme/nvme.c
+++ b/drivers/nvme/nvme.c
@@ -664,7 +664,6 @@ static int nvme_blk_probe(struct udevice *udev)
sprintf(desc->vendor, "0x%.4x", pplat->vendor);
memcpy(desc->product, ndev->serial, sizeof(ndev->serial));
memcpy(desc->revision, ndev->firmware_rev, sizeof(ndev->firmware_rev));
- part_init(desc);
return 0;
}
diff --git a/lib/efi_driver/efi_block_device.c
b/lib/efi_driver/efi_block_device.c
index 7b71b4d..3f147cf 100644
--- a/lib/efi_driver/efi_block_device.c
+++ b/lib/efi_driver/efi_block_device.c
@@ -173,8 +173,6 @@ static int efi_bl_bind(efi_handle_t handle, void *interface)
return ret;
EFI_PRINT("%s: block device '%s' created\n", __func__, bdev->name);
- ret = blk_prepare_device(bdev);
-
/* Create handles for the partions of the block device */
disks = efi_bl_bind_partitions(handle, bdev);
EFI_PRINT("Found %d partitions\n", disks);
here i cannot see some alternative if CONFIG_BLK is enabled.
I don't understand your comments here too...
With alternative i mean, that:
If CONFIG_BLK is disabled within the code here some part_init has to be
done.
No, this one I still don't understand. The EFI block device is a DM
driver. It cannot work when CONFIG_BLK is disabled.
OK. I don't catched that the EFI cannot work without DM,
i just took notice that there is no "non-DM" alternative.
So it is OK as it is.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 05/16] mtd: spi: Port SPI NOR framework from Linux
On 13.12.18 04:01, Tom Rini wrote: On Thu, Dec 13, 2018 at 04:51:56AM +0530, Jagan Teki wrote: On Thu, Dec 13, 2018 at 4:26 AM Tom Rini wrote: On Thu, Dec 13, 2018 at 02:01:15AM +0530, Jagan Teki wrote: On Wed, Dec 12, 2018 at 11:10 PM Vignesh R wrote: Current U-Boot SPI NOR support (sf layer) is quite outdated as it does not support 4 byte addressing opcodes, SFDP table parsing and different types of quad mode enable sequences. Many newer flashes no longer support BANK registers used by sf layer to a access >16MB space. Also, many SPI controllers have special MMIO interfaces which provide accelerated read/write access but require knowledge of flash parameters to make use of it. Recent spi-mem layer provides a way to support such flashes but sf layer isn't using that. So sync SPI NOR framework from Linux v4.19 and add spi-mem support on top. in order to gain 4 byte addressing support, SFDP support and a way to support SPI controllers with MMIO flash interface. Signed-off-by: Vignesh R --- drivers/mtd/spi/spi-nor-core.c | 2647 include/linux/mtd/cfi.h| 32 + include/linux/mtd/spi-nor.h| 421 + Please refer many mails about this comment. I don't look for carbon copy of the code from Linux, you can use the implementation and even macro names etc but the end code would be the code that require U-Boot. - no __UBOOT ifdef What? This is the exact opposite of what we're doing in several other areas, with a large amount of success precisely because it allows us to leverage developer base to catch and fix problems. Dropping in the code and minor and obvious deviations make for easier re-sync. Several areas, but not spi-flash or spi. ie what I'm maintaining from long. I'm always looking for persistent code to be IN. May be it can't be syn-cable but we can work it more maintainable in u-boot way like other opensource project. Well this is my experience with the U-Boot project development so-far, I never ever hold any features but if u-boot need the same features, better to add then like new code. I think that for flash related SPI we should follow the lead of the rest of MTD/NAND and adapt the kernel code. Yes, we should have learned this lesson from the past. So full ACK from me. Thanks, Stefan ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 09/16] sf_mtd: Simply mtd operations
Hi Vignesh,
On 12.12.18 18:32, Vignesh R wrote:
Now that there is new SPI NOR framework, simplify mtd device
registration and read/write/erase operations.
Signed-off-by: Vignesh R
---
drivers/mtd/spi/sf_internal.h | 2 +-
drivers/mtd/spi/sf_mtd.c | 52 ++-
drivers/mtd/spi/sf_probe.c| 5 ++--
3 files changed, 24 insertions(+), 35 deletions(-)
diff --git a/drivers/mtd/spi/sf_internal.h b/drivers/mtd/spi/sf_internal.h
index 7e7d400cdbdf..8b445bb0b506 100644
--- a/drivers/mtd/spi/sf_internal.h
+++ b/drivers/mtd/spi/sf_internal.h
@@ -99,6 +99,6 @@ int spi_flash_cmd_get_sw_write_prot(struct spi_flash *flash);
#ifdef CONFIG_SPI_FLASH_MTD
int spi_flash_mtd_register(struct spi_flash *flash);
-void spi_flash_mtd_unregister(void);
+void spi_flash_mtd_unregister(struct spi_flash *flash);
#endif
#endif /* _SF_INTERNAL_H_ */
diff --git a/drivers/mtd/spi/sf_mtd.c b/drivers/mtd/spi/sf_mtd.c
index 68c36002bee2..65185b7c57dc 100644
--- a/drivers/mtd/spi/sf_mtd.c
+++ b/drivers/mtd/spi/sf_mtd.c
@@ -9,21 +9,19 @@
#include
#include
-static struct mtd_info sf_mtd_info;
static bool sf_mtd_registered;
static char sf_mtd_name[8];
static int spi_flash_mtd_erase(struct mtd_info *mtd, struct erase_info *instr)
{
- struct spi_flash *flash = mtd->priv;
int err;
- if (!flash)
+ if (!mtd || !mtd->priv)
return -ENODEV;
instr->state = MTD_ERASING;
- err = spi_flash_erase(flash, instr->addr, instr->len);
+ err = mtd->_erase(mtd, instr);
if (err) {
instr->state = MTD_ERASE_FAILED;
instr->fail_addr = MTD_FAIL_ADDR_UNKNOWN;
@@ -39,13 +37,12 @@ static int spi_flash_mtd_erase(struct mtd_info *mtd, struct
erase_info *instr)
static int spi_flash_mtd_read(struct mtd_info *mtd, loff_t from, size_t len,
size_t *retlen, u_char *buf)
{
- struct spi_flash *flash = mtd->priv;
int err;
- if (!flash)
+ if (!mtd || !mtd->priv)
return -ENODEV;
- err = spi_flash_read(flash, from, len, buf);
+ err = mtd->_read(mtd, from, len, retlen, buf);
if (!err)
*retlen = len;
I just tested this patchset on my MIPS linkit smart platform and it
hangs in an infinite loop here in this read function. The callstack
is:
spi_flash_std_read -> spi_flash_mtd_read
spi_flash_mtd_read() now calls itself recursively.
Any ideas?
Thanks,
Stefan
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 11/31] blk: Call part_init() in the post_probe() method
Hi Hannes,
On Thu, Dec 13, 2018 at 3:32 PM Hannes Schmelzer wrote:
>
>
>
> On 12/13/18 8:26 AM, Bin Meng wrote:
> > Hi Hannes,
> Hi Bin,
> > On Thu, Dec 13, 2018 at 3:19 PM Hannes Schmelzer
> > wrote:
> >>
> >>
> >> On 10/15/18 11:21 AM, Bin Meng wrote:
> >>> part_init() is currently called in every DM BLK driver, either
> >>> in its bind() or probe() method. However we can use the BLK
> >>> uclass driver's post_probe() method to do it automatically.
> >>>
> >>> Update all DM BLK drivers to adopt this change.
> >>>
> >>> Signed-off-by: Bin Meng
> >>> Reviewed-by: Simon Glass
> >>> ---
> >>>
> >>> Changes in v3: None
> >>> Changes in v2: None
> >>>
> >>>cmd/sata.c| 9 -
> >>>common/usb_storage.c | 4 +---
> >>>drivers/block/blk-uclass.c| 12
> >>>drivers/block/ide.c | 2 --
> >>>drivers/block/sandbox.c | 2 +-
> >>>drivers/mmc/mmc.c | 3 ---
> >>>drivers/nvme/nvme.c | 1 -
> >>>drivers/scsi/scsi.c | 1 -
> >>>lib/efi_driver/efi_block_device.c | 2 --
> >>>9 files changed, 14 insertions(+), 22 deletions(-)
> >> Hi Bin,
> >>
> >> sorry for this very late report on this.
> >> I Just merged the 'v2019.01-rc1' tag into my branch and noticed that
> >> filesystem on my eMMC targets are not working anymore.
> >> Bisect showed up, that this commit breaks the stuff.
> >>
> >> I reviewed the change a bit and i would say that all other block devices
> >> should work as known, except MMC, NVME and EFI (i do not have one, so i
> >> cannot test).
> >>> diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
> >>> index 585951c..d6b9cdc 100644
> >>> --- a/drivers/mmc/mmc.c
> >>> +++ b/drivers/mmc/mmc.c
> >>> @@ -2444,9 +2444,6 @@ static int mmc_startup(struct mmc *mmc)
> >>>bdesc->product[0] = 0;
> >>>bdesc->revision[0] = 0;
> >>>#endif
> >>> -#if !defined(CONFIG_SPL_BUILD) || defined(CONFIG_SPL_LIBDISK_SUPPORT)
> >>> - part_init(bdesc);
> >>> -#endif
> >>>
> >>>return 0;
> >>>}
> >> i changed this to:
> >>
> >> #if (!defined(CONFIG_SPL_BUILD) || defined(CONFIG_SPL_LIBDISK_SUPPORT)) &&
> >> \
> >>!defined(CONFIG_BLK)
> >> part_init(bdesc);
> >> #endif
> > I don't understand. The patch above removed 3 lines. Did you say that
> > you added back these 3 lines with additional "!defined(CONFIG_BLK)"?
> Yes,
> in case if CONFIG_BLK is disabled (meaning blk-uclass.c isn't compiled
> in and does therefore nothing),
> the part_init(...) has to be done here.
OK, now I understand. But you should convert your board to use DM MMC
instead. It's the right timing now.
> >
> >>> diff --git a/drivers/nvme/nvme.c b/drivers/nvme/nvme.c
> >>> index eb6fded..1ee0a0a 100644
> >>> --- a/drivers/nvme/nvme.c
> >>> +++ b/drivers/nvme/nvme.c
> >>> @@ -664,7 +664,6 @@ static int nvme_blk_probe(struct udevice *udev)
> >>>sprintf(desc->vendor, "0x%.4x", pplat->vendor);
> >>>memcpy(desc->product, ndev->serial, sizeof(ndev->serial));
> >>>memcpy(desc->revision, ndev->firmware_rev,
> >>> sizeof(ndev->firmware_rev));
> >>> - part_init(desc);
> >>>
> >>>return 0;
> >>>}
> >>>
> >>> diff --git a/lib/efi_driver/efi_block_device.c
> >>> b/lib/efi_driver/efi_block_device.c
> >>> index 7b71b4d..3f147cf 100644
> >>> --- a/lib/efi_driver/efi_block_device.c
> >>> +++ b/lib/efi_driver/efi_block_device.c
> >>> @@ -173,8 +173,6 @@ static int efi_bl_bind(efi_handle_t handle, void
> >>> *interface)
> >>>return ret;
> >>>EFI_PRINT("%s: block device '%s' created\n", __func__, bdev->name);
> >>>
> >>> - ret = blk_prepare_device(bdev);
> >>> -
> >>>/* Create handles for the partions of the block device */
> >>>disks = efi_bl_bind_partitions(handle, bdev);
> >>>EFI_PRINT("Found %d partitions\n", disks);
> >> here i cannot see some alternative if CONFIG_BLK is enabled.
> >>
> >> I don't understand your comments here too...
> With alternative i mean, that:
> If CONFIG_BLK is disabled within the code here some part_init has to be
> done.
No, this one I still don't understand. The EFI block device is a DM
driver. It cannot work when CONFIG_BLK is disabled.
> Otherwise Partitions and following filesystems cannot work.
> >
> >> I know, everything shall be converted to DM since the deadline is quite
> >> close.
> >> But i also think that upon this day everything should work as expected.
> >>
Regards,
Bin
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 11/31] blk: Call part_init() in the post_probe() method
On 12/13/18 8:26 AM, Bin Meng wrote:
Hi Hannes,
Hi Bin,
On Thu, Dec 13, 2018 at 3:19 PM Hannes Schmelzer wrote:
On 10/15/18 11:21 AM, Bin Meng wrote:
part_init() is currently called in every DM BLK driver, either
in its bind() or probe() method. However we can use the BLK
uclass driver's post_probe() method to do it automatically.
Update all DM BLK drivers to adopt this change.
Signed-off-by: Bin Meng
Reviewed-by: Simon Glass
---
Changes in v3: None
Changes in v2: None
cmd/sata.c| 9 -
common/usb_storage.c | 4 +---
drivers/block/blk-uclass.c| 12
drivers/block/ide.c | 2 --
drivers/block/sandbox.c | 2 +-
drivers/mmc/mmc.c | 3 ---
drivers/nvme/nvme.c | 1 -
drivers/scsi/scsi.c | 1 -
lib/efi_driver/efi_block_device.c | 2 --
9 files changed, 14 insertions(+), 22 deletions(-)
Hi Bin,
sorry for this very late report on this.
I Just merged the 'v2019.01-rc1' tag into my branch and noticed that
filesystem on my eMMC targets are not working anymore.
Bisect showed up, that this commit breaks the stuff.
I reviewed the change a bit and i would say that all other block devices
should work as known, except MMC, NVME and EFI (i do not have one, so i
cannot test).
diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
index 585951c..d6b9cdc 100644
--- a/drivers/mmc/mmc.c
+++ b/drivers/mmc/mmc.c
@@ -2444,9 +2444,6 @@ static int mmc_startup(struct mmc *mmc)
bdesc->product[0] = 0;
bdesc->revision[0] = 0;
#endif
-#if !defined(CONFIG_SPL_BUILD) || defined(CONFIG_SPL_LIBDISK_SUPPORT)
- part_init(bdesc);
-#endif
return 0;
}
i changed this to:
#if (!defined(CONFIG_SPL_BUILD) || defined(CONFIG_SPL_LIBDISK_SUPPORT)) && \
!defined(CONFIG_BLK)
part_init(bdesc);
#endif
I don't understand. The patch above removed 3 lines. Did you say that
you added back these 3 lines with additional "!defined(CONFIG_BLK)"?
Yes,
in case if CONFIG_BLK is disabled (meaning blk-uclass.c isn't compiled
in and does therefore nothing),
the part_init(...) has to be done here.
diff --git a/drivers/nvme/nvme.c b/drivers/nvme/nvme.c
index eb6fded..1ee0a0a 100644
--- a/drivers/nvme/nvme.c
+++ b/drivers/nvme/nvme.c
@@ -664,7 +664,6 @@ static int nvme_blk_probe(struct udevice *udev)
sprintf(desc->vendor, "0x%.4x", pplat->vendor);
memcpy(desc->product, ndev->serial, sizeof(ndev->serial));
memcpy(desc->revision, ndev->firmware_rev, sizeof(ndev->firmware_rev));
- part_init(desc);
return 0;
}
diff --git a/lib/efi_driver/efi_block_device.c
b/lib/efi_driver/efi_block_device.c
index 7b71b4d..3f147cf 100644
--- a/lib/efi_driver/efi_block_device.c
+++ b/lib/efi_driver/efi_block_device.c
@@ -173,8 +173,6 @@ static int efi_bl_bind(efi_handle_t handle, void *interface)
return ret;
EFI_PRINT("%s: block device '%s' created\n", __func__, bdev->name);
- ret = blk_prepare_device(bdev);
-
/* Create handles for the partions of the block device */
disks = efi_bl_bind_partitions(handle, bdev);
EFI_PRINT("Found %d partitions\n", disks);
here i cannot see some alternative if CONFIG_BLK is enabled.
I don't understand your comments here too...
With alternative i mean, that:
If CONFIG_BLK is disabled within the code here some part_init has to be
done.
Otherwise Partitions and following filesystems cannot work.
I know, everything shall be converted to DM since the deadline is quite
close.
But i also think that upon this day everything should work as expected.
Regards,
Bin
cheers,
Hannes
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 11/31] blk: Call part_init() in the post_probe() method
Hi Hannes,
On Thu, Dec 13, 2018 at 3:19 PM Hannes Schmelzer wrote:
>
>
>
> On 10/15/18 11:21 AM, Bin Meng wrote:
> > part_init() is currently called in every DM BLK driver, either
> > in its bind() or probe() method. However we can use the BLK
> > uclass driver's post_probe() method to do it automatically.
> >
> > Update all DM BLK drivers to adopt this change.
> >
> > Signed-off-by: Bin Meng
> > Reviewed-by: Simon Glass
> > ---
> >
> > Changes in v3: None
> > Changes in v2: None
> >
> > cmd/sata.c| 9 -
> > common/usb_storage.c | 4 +---
> > drivers/block/blk-uclass.c| 12
> > drivers/block/ide.c | 2 --
> > drivers/block/sandbox.c | 2 +-
> > drivers/mmc/mmc.c | 3 ---
> > drivers/nvme/nvme.c | 1 -
> > drivers/scsi/scsi.c | 1 -
> > lib/efi_driver/efi_block_device.c | 2 --
> > 9 files changed, 14 insertions(+), 22 deletions(-)
> Hi Bin,
>
> sorry for this very late report on this.
> I Just merged the 'v2019.01-rc1' tag into my branch and noticed that
> filesystem on my eMMC targets are not working anymore.
> Bisect showed up, that this commit breaks the stuff.
>
> I reviewed the change a bit and i would say that all other block devices
> should work as known, except MMC, NVME and EFI (i do not have one, so i
> cannot test).
> > diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
> > index 585951c..d6b9cdc 100644
> > --- a/drivers/mmc/mmc.c
> > +++ b/drivers/mmc/mmc.c
> > @@ -2444,9 +2444,6 @@ static int mmc_startup(struct mmc *mmc)
> > bdesc->product[0] = 0;
> > bdesc->revision[0] = 0;
> > #endif
> > -#if !defined(CONFIG_SPL_BUILD) || defined(CONFIG_SPL_LIBDISK_SUPPORT)
> > - part_init(bdesc);
> > -#endif
> >
> > return 0;
> > }
> i changed this to:
>
> #if (!defined(CONFIG_SPL_BUILD) || defined(CONFIG_SPL_LIBDISK_SUPPORT)) && \
> !defined(CONFIG_BLK)
> part_init(bdesc);
> #endif
I don't understand. The patch above removed 3 lines. Did you say that
you added back these 3 lines with additional "!defined(CONFIG_BLK)"?
>
>
> > diff --git a/drivers/nvme/nvme.c b/drivers/nvme/nvme.c
> > index eb6fded..1ee0a0a 100644
> > --- a/drivers/nvme/nvme.c
> > +++ b/drivers/nvme/nvme.c
> > @@ -664,7 +664,6 @@ static int nvme_blk_probe(struct udevice *udev)
> > sprintf(desc->vendor, "0x%.4x", pplat->vendor);
> > memcpy(desc->product, ndev->serial, sizeof(ndev->serial));
> > memcpy(desc->revision, ndev->firmware_rev,
> > sizeof(ndev->firmware_rev));
> > - part_init(desc);
> >
> > return 0;
> > }
> >
> > diff --git a/lib/efi_driver/efi_block_device.c
> > b/lib/efi_driver/efi_block_device.c
> > index 7b71b4d..3f147cf 100644
> > --- a/lib/efi_driver/efi_block_device.c
> > +++ b/lib/efi_driver/efi_block_device.c
> > @@ -173,8 +173,6 @@ static int efi_bl_bind(efi_handle_t handle, void
> > *interface)
> > return ret;
> > EFI_PRINT("%s: block device '%s' created\n", __func__, bdev->name);
> >
> > - ret = blk_prepare_device(bdev);
> > -
> > /* Create handles for the partions of the block device */
> > disks = efi_bl_bind_partitions(handle, bdev);
> > EFI_PRINT("Found %d partitions\n", disks);
> here i cannot see some alternative if CONFIG_BLK is enabled.
>
I don't understand your comments here too...
> I know, everything shall be converted to DM since the deadline is quite
> close.
> But i also think that upon this day everything should work as expected.
>
Regards,
Bin
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 11/31] blk: Call part_init() in the post_probe() method
On 10/15/18 11:21 AM, Bin Meng wrote:
part_init() is currently called in every DM BLK driver, either
in its bind() or probe() method. However we can use the BLK
uclass driver's post_probe() method to do it automatically.
Update all DM BLK drivers to adopt this change.
Signed-off-by: Bin Meng
Reviewed-by: Simon Glass
---
Changes in v3: None
Changes in v2: None
cmd/sata.c| 9 -
common/usb_storage.c | 4 +---
drivers/block/blk-uclass.c| 12
drivers/block/ide.c | 2 --
drivers/block/sandbox.c | 2 +-
drivers/mmc/mmc.c | 3 ---
drivers/nvme/nvme.c | 1 -
drivers/scsi/scsi.c | 1 -
lib/efi_driver/efi_block_device.c | 2 --
9 files changed, 14 insertions(+), 22 deletions(-)
Hi Bin,
sorry for this very late report on this.
I Just merged the 'v2019.01-rc1' tag into my branch and noticed that
filesystem on my eMMC targets are not working anymore.
Bisect showed up, that this commit breaks the stuff.
I reviewed the change a bit and i would say that all other block devices
should work as known, except MMC, NVME and EFI (i do not have one, so i
cannot test).
diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
index 585951c..d6b9cdc 100644
--- a/drivers/mmc/mmc.c
+++ b/drivers/mmc/mmc.c
@@ -2444,9 +2444,6 @@ static int mmc_startup(struct mmc *mmc)
bdesc->product[0] = 0;
bdesc->revision[0] = 0;
#endif
-#if !defined(CONFIG_SPL_BUILD) || defined(CONFIG_SPL_LIBDISK_SUPPORT)
- part_init(bdesc);
-#endif
return 0;
}
i changed this to:
#if (!defined(CONFIG_SPL_BUILD) || defined(CONFIG_SPL_LIBDISK_SUPPORT)) && \
!defined(CONFIG_BLK)
part_init(bdesc);
#endif
diff --git a/drivers/nvme/nvme.c b/drivers/nvme/nvme.c
index eb6fded..1ee0a0a 100644
--- a/drivers/nvme/nvme.c
+++ b/drivers/nvme/nvme.c
@@ -664,7 +664,6 @@ static int nvme_blk_probe(struct udevice *udev)
sprintf(desc->vendor, "0x%.4x", pplat->vendor);
memcpy(desc->product, ndev->serial, sizeof(ndev->serial));
memcpy(desc->revision, ndev->firmware_rev, sizeof(ndev->firmware_rev));
- part_init(desc);
return 0;
}
diff --git a/lib/efi_driver/efi_block_device.c
b/lib/efi_driver/efi_block_device.c
index 7b71b4d..3f147cf 100644
--- a/lib/efi_driver/efi_block_device.c
+++ b/lib/efi_driver/efi_block_device.c
@@ -173,8 +173,6 @@ static int efi_bl_bind(efi_handle_t handle, void *interface)
return ret;
EFI_PRINT("%s: block device '%s' created\n", __func__, bdev->name);
- ret = blk_prepare_device(bdev);
-
/* Create handles for the partions of the block device */
disks = efi_bl_bind_partitions(handle, bdev);
EFI_PRINT("Found %d partitions\n", disks);
here i cannot see some alternative if CONFIG_BLK is enabled.
I know, everything shall be converted to DM since the deadline is quite
close.
But i also think that upon this day everything should work as expected.
cheers,
Hannes
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [imx/next V2] tools: imx8m_image: use bash
Hi Jon > -Original Message- > From: Jon Nettleton [mailto:j...@solid-run.com] > Sent: 2018年12月13日 14:54 > To: Peng Fan > Cc: sba...@denx.de; Fabio Estevam ; U-Boot > Mailing List > Subject: Re: [U-Boot] [imx/next V2] tools: imx8m_image: use bash > > On Wed, Dec 12, 2018 at 2:54 AM Peng Fan wrote: > > > > travis-ci reports > > "tools/imx8m_image.sh: 15: [: signed_hdmi_imx8m.bin: unexpected > operator" > > After use bash, no error, so use bash instead of sh. > > > > Signed-off-by: Peng Fan > > --- > > tools/imx8m_image.sh | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/tools/imx8m_image.sh b/tools/imx8m_image.sh index > > 6346fb64d8..0e9df4763c 100755 > > --- a/tools/imx8m_image.sh > > +++ b/tools/imx8m_image.sh > > @@ -1,4 +1,4 @@ > > -#!/bin/sh > > +#!/bin/bash > > # SPDX-License-Identifier: GPL-2.0+ > > # > > # script to check whether the file exists in imximage.cfg for i.MX8M > > We have a patch that fixes this to work with sh, dash, and bash if you prefer. Sure, please submit a patch based on imx/next, I would like those patches could be in master soon. Thanks, Peng. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] usb: musb-new: sunxi: Fix null pointer access
On 12/5/18 3:16 PM, Marek Vasut wrote:
On 12/05/2018 02:06 PM, Stefan Mavrodiev wrote:
On 12/5/18 2:57 PM, Marek Vasut wrote:
On 12/05/2018 01:49 PM, Stefan Mavrodiev wrote:
When the device is in peripheral mode
Can you have two devices, one in peripheral mode and one in host mode,
on the same system ?
Not 100% sure, but I'm thinking there is only one OTG port for
all sunxi boards. The operation is decided in the Kconfig.
I'm rather sure I saw sunxi boards with more than one USB port.
there is no
struct usb_bus_priv allocated pointer, as the uclass driver
("usb_dev_generic") doesn't call per_device_auto_alloc_size.
This results in writing to the internal SDRAM at
priv->desc_before_addr = true;
Signed-off-by: Stefan Mavrodiev
---
drivers/usb/musb-new/sunxi.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/musb-new/sunxi.c b/drivers/usb/musb-new/sunxi.c
index 6cf9826cda..f3deb9bc66 100644
--- a/drivers/usb/musb-new/sunxi.c
+++ b/drivers/usb/musb-new/sunxi.c
@@ -435,11 +435,14 @@ static int musb_usb_probe(struct udevice *dev)
{
struct sunxi_glue *glue = dev_get_priv(dev);
struct musb_host_data *host = >mdata;
- struct usb_bus_priv *priv = dev_get_uclass_priv(dev);
struct musb_hdrc_platform_data pdata;
void *base = dev_read_addr_ptr(dev);
int ret;
+#ifdef CONFIG_USB_MUSB_HOST
+ struct usb_bus_priv *priv = dev_get_uclass_priv(dev);
+#endif
+
if (!base)
return -EINVAL;
@@ -459,7 +462,6 @@ static int musb_usb_probe(struct udevice *dev)
return ret;
}
- priv->desc_before_addr = true;
See my question at the beginning, and if that can be the case, the fix
is to check if priv is not null here, eg.
if (priv)
priv->...
Still, why is the priv data not allocated for device ?
Depending on configuration, the device is registered ether as
UCLASS_USB_DEV_GENERIC or UCLASS_USB. There is no
.per_device_auto_alloc_size = sizeof(struct usb_bus_priv),
for the second. (As seen in drivers/usb/host/usb-uclass.c)
I see the code is rather horrible. I'd expect all that configuration to
come from DT otg-mode property instead of being hard-wired into the
code. Sigh.
Jagan, A-B ? I'd like to pick this .
memset(, 0, sizeof(pdata));
pdata.power = 250;
@@ -467,6 +469,8 @@ static int musb_usb_probe(struct udevice *dev)
pdata.config = glue->cfg->config;
#ifdef CONFIG_USB_MUSB_HOST
+ priv->desc_before_addr = true;
+
pdata.mode = MUSB_HOST;
host->host = musb_init_controller(, >dev, base);
if (!host->host)
Any further comments?
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] arm: sunxi: Add NULL pointer check
On 12/6/18 8:41 AM, Stefan Mavrodiev wrote:
On 12/5/18 5:46 PM, Maxime Ripard wrote:
On Wed, Dec 05, 2018 at 02:27:57PM +0200, Stefan Mavrodiev wrote:
Current driver doesn't check if the destination pointer is NULL.
This cause the data from the FIFO to be stored inside the internal
SDRAM ( address 0 ).
The patch add simple check if the destination pointer is NULL.
Signed-off-by: Stefan Mavrodiev
---
drivers/spi/sun4i_spi.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/spi/sun4i_spi.c b/drivers/spi/sun4i_spi.c
index b86b5a00ad..38cc743c61 100644
--- a/drivers/spi/sun4i_spi.c
+++ b/drivers/spi/sun4i_spi.c
@@ -129,7 +129,8 @@ static inline void sun4i_spi_drain_fifo(struct
sun4i_spi_priv *priv, int len)
while (len--) {
byte = readb(>regs->rxdata);
- *priv->rx_buf++ = byte;
+ if (priv->rx_buf)
+ *priv->rx_buf++ = byte;
It seems pretty inefficient to test the pointer at each access, it
would be better to check it once before starting the transfer.
I'm not sure if that can even happen?
I've tried to check that before draining the receive fifo, but then
the controller doesn't
work. I'm thinking that the fifo must be drained in any case.
Maxime
Any further comments?
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [imx/next V2] tools: imx8m_image: use bash
On Wed, Dec 12, 2018 at 2:54 AM Peng Fan wrote: > > travis-ci reports > "tools/imx8m_image.sh: 15: [: signed_hdmi_imx8m.bin: unexpected operator" > After use bash, no error, so use bash instead of sh. > > Signed-off-by: Peng Fan > --- > tools/imx8m_image.sh | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/tools/imx8m_image.sh b/tools/imx8m_image.sh > index 6346fb64d8..0e9df4763c 100755 > --- a/tools/imx8m_image.sh > +++ b/tools/imx8m_image.sh > @@ -1,4 +1,4 @@ > -#!/bin/sh > +#!/bin/bash > # SPDX-License-Identifier: GPL-2.0+ > # > # script to check whether the file exists in imximage.cfg for i.MX8M We have a patch that fixes this to work with sh, dash, and bash if you prefer. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH u-boot-marvell v3 09/10] board: turris_mox: Support 1 GB version of Turris Mox
Hi Marek,
On 13.12.18 04:53, Marek Behun wrote:
it turned out that what I found out was not causing the bug.
get_ram_size reported 1 GiB of ram because I tried it when dcache was
already enabled. If I call get_ram_size in dram_init, it returns the
correct size on both 512 MiB and 1 GiB board.
In the next patch I shall define dram_init and dram_init_banksize in
arm64-common.c as __weak, and the definition in turris_mox.c shall call
get_ram_size. Is this acceptable?
Okay, please prepare the patch and I'll review it then.
Thanks,
Stefan
Marek
On Wed, 12 Dec 2018 10:44:15 +0100
Stefan Roese wrote:
Hi Marek,
On 12.12.18 03:23, Marek Behun wrote:
Hi, I have found the bug causing this issue.
Good.
If I understand the algorithm in get_ram_size correctly, it does
approximately this. Suppose A, B, C, D, E, F are different
constatnts. X(i) is a value at address 1<
I have to admit that I didn't fully try to understand this issue you
describe above (sorry, lack of time). If you have found a bug and do
have a fix for it, then please submit a patch. Please add all
developers (e.g. Patrick Delaunay etc) who did some work on this code
to Cc, as changes here might be critical.
I have to confess that I do not like how this function is written at
all. It does not, for example, solve correctly the case when a
device has 768 MiB of RAM from two chips (512 + 256). Given 1024
MiB as argument, it would return 1024 MiB, but the system only has
768 MiB. This maybe is never an issue with devices that run u-boot,
but still.
If you have a nice and easy implementation to also support such
memory configurations, that would be perfect of course. But I really
think that such non-power-of-2 memory configurations are rather
uncommon for U-Boot and most likely don't need to be supported by
this function. Such configuration usually are a result of using
multiple DIMM's (or SODIMM's) which can be equipped with various
sized memories. And here the memory size can be read from the DIMM
itself. So no need to support this in get_ram_size().
Thanks,
Stefan
Marek
On Tue, 11 Dec 2018 16:06:42 +0100
Stefan Roese wrote:
On 11.12.18 15:53, Marek Behún wrote:
On Tue, 11 Dec 2018 15:28:11 +0100
Stefan Roese wrote:
Hi Marek,
On 11.12.18 14:59, Marek Behún wrote:
get_ram_size does not work correctly on Mox. On a 512 MiB board
it detects 1024 MiB of RAM, because on the 512 MiB RAM chip the
topmost address bit is simply ignored and the RAM wraps - on
0x2000-0x4000 CPU sees the same data as on
0x0-0x2000.
That's what get_ram_size() does: It does detect such aliases when
the same memory is mapped at multiple areas (power of 2). Did you
give it a try with a max value of 1024 MiB? It should return
512 on such boards.
I checked it and it returned 1024 MiB.
I did
printf("%08x %08x\n",
get_ram_size(0, 512<<20),
get_ram_size(0, 1024<<20));
on a 512 MiB board and
0x2000 0x4000
was printed.
Very strange. Could you please debug this issue? get_ram_size()
should be able to work in such situations.
Thanks,
Stefan
ATF does not run RAM size determining code either, it just gets
RAM size from a register, this register is written before ATF by
BootROM and we have done it so that there is always 1 GB so that
we could use same secure firmware image for all Moxes. I tried
to change this register in secure firmware, but this lead to
Synchornous Abort events in U-Boot.
Maybe we could move the dram_init funcitons from arm64-common.c
to specific board files, or maybe we could declare them __weak
in arm64-common.c and turris_mox can then redefine them.
Would that be OK with you?
Please fist check if get_ram_size() can't be used.
Thanks,
Stefan
Marek
On Thu, 29 Nov 2018 14:07:59 +0100
Stefan Roese wrote:
On 20.11.18 13:04, Marek Behún wrote:
Depending on the data in the OTP memory, differentiate between
the 512 MiB and 1 GiB versions of Turris Mox and report these
RAM sizes in dram_init and dram_init_banksize.
Signed-off-by: Marek Behún
---
arch/arm/mach-mvebu/arm64-common.c | 7 ++-
board/CZ.NIC/turris_mox/turris_mox.c | 27
+++ 2 files changed, 33
insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-mvebu/arm64-common.c
b/arch/arm/mach-mvebu/arm64-common.c index
f47273fde9..5e6ac9fc4a 100644 ---
a/arch/arm/mach-mvebu/arm64-common.c +++
b/arch/arm/mach-mvebu/arm64-common.c @@ -43,8 +43,12 @@ const
struct mbus_dram_target_info *mvebu_mbus_dram_info(void)
return NULL; }
-/* DRAM init code ... */
+/*
+ * DRAM init code ...
+ * Turris Mox defines this itself, depending on data in
burned eFuses
+ */
+#ifndef CONFIG_TARGET_TURRIS_MOX
int dram_init_banksize(void)
{
fdtdec_setup_memory_banksize();
@@ -59,6 +63,7 @@ int dram_init(void)
return 0;
}
+#endif /* !CONFIG_TARGET_TURRIS_MOX */
2 Problems with this:
a)
This does not
Re: [U-Boot] [PATCH v5 06/25] riscv: ax25: Hide the ax25-specific Kconfig option
> > Subject: [PATCH v5 06/25] riscv: ax25: Hide the ax25-specific Kconfig option
> >
> > There is no need to expose RISCV_NDS to the Kconfig menu as it is an
> > ax25-specific option. Introduce a dedicated Kconfig option for the cache
> > ops of
> > ax25 platform and use that to guard the cache ops.
> >
> > Signed-off-by: Bin Meng
> >
> > ---
> >
> > Changes in v5:
> > - Introduced another Kconfig option for the cache ops on AX25 CPU,
> > so that it remains selectable in Kconfig menu, but only visible
> > to AX25 platform.
> >
> > Changes in v4: None
> > Changes in v3: None
> > Changes in v2: None
> >
> > arch/riscv/cpu/ax25/Kconfig| 17 -
> > arch/riscv/cpu/ax25/cache.c| 12 ++--
> > board/AndesTech/ax25-ae350/Kconfig | 4
> > 3 files changed, 22 insertions(+), 11 deletions(-)
> >
> > diff --git a/arch/riscv/cpu/ax25/Kconfig b/arch/riscv/cpu/ax25/Kconfig index
> > 6c7022f..e9dbca2 100644
> > --- a/arch/riscv/cpu/ax25/Kconfig
> > +++ b/arch/riscv/cpu/ax25/Kconfig
> > @@ -1,7 +1,14 @@
> > config RISCV_NDS
> > - bool "AndeStar V5 ISA support"
> > - default n
> > + bool
> > help
> > - Say Y here if you plan to run U-Boot on AndeStar v5
> > - platforms and use some specific features which are
> > - provided by Andes Technology AndeStar V5 Families.
> > + Run U-Boot on AndeStar V5 platforms and use some specific features
> > + which are provided by Andes Technology AndeStar V5 families.
> > +
> > +if RISCV_NDS
> > +
> > +config RISCV_NDS_CACHE
> > + bool "AndeStar V5 families specific cache support"
> > + help
> > + Provide Andes Technology AndeStar V5 families specific cache
> > support.
> > +
> > +endif
> > diff --git a/arch/riscv/cpu/ax25/cache.c b/arch/riscv/cpu/ax25/cache.c index
> > 6600ac2..8d6ae17 100644
> > --- a/arch/riscv/cpu/ax25/cache.c
> > +++ b/arch/riscv/cpu/ax25/cache.c
> > @@ -9,7 +9,7 @@
> > void icache_enable(void)
> > {
> > #ifndef CONFIG_SYS_ICACHE_OFF
> > -#ifdef CONFIG_RISCV_NDS
> > +#ifdef CONFIG_RISCV_NDS_CACHE
> > asm volatile (
> > "csrr t1, mcache_ctl\n\t"
> > "ori t0, t1, 0x1\n\t"
> > @@ -22,7 +22,7 @@ void icache_enable(void) void icache_disable(void)
> > { #ifndef CONFIG_SYS_ICACHE_OFF -#ifdef CONFIG_RISCV_NDS
> > +#ifdef CONFIG_RISCV_NDS_CACHE
> > asm volatile (
> > "fence.i\n\t"
> > "csrr t1, mcache_ctl\n\t"
> > @@ -36,7 +36,7 @@ void icache_disable(void) void dcache_enable(void)
> > { #ifndef CONFIG_SYS_DCACHE_OFF -#ifdef CONFIG_RISCV_NDS
> > +#ifdef CONFIG_RISCV_NDS_CACHE
> > asm volatile (
> > "csrr t1, mcache_ctl\n\t"
> > "ori t0, t1, 0x2\n\t"
> > @@ -49,7 +49,7 @@ void dcache_enable(void) void dcache_disable(void)
> > { #ifndef CONFIG_SYS_DCACHE_OFF -#ifdef CONFIG_RISCV_NDS
> > +#ifdef CONFIG_RISCV_NDS_CACHE
> > asm volatile (
> > "fence\n\t"
> > "csrr t1, mcache_ctl\n\t"
> > @@ -64,7 +64,7 @@ int icache_status(void) {
> > int ret = 0;
> >
> > -#ifdef CONFIG_RISCV_NDS
> > +#ifdef CONFIG_RISCV_NDS_CACHE
> > asm volatile (
> > "csrr t1, mcache_ctl\n\t"
> > "andi %0, t1, 0x01\n\t"
> > @@ -81,7 +81,7 @@ int dcache_status(void) {
> > int ret = 0;
> >
> > -#ifdef CONFIG_RISCV_NDS
> > +#ifdef CONFIG_RISCV_NDS_CACHE
> > asm volatile (
> > "csrr t1, mcache_ctl\n\t"
> > "andi %0, t1, 0x02\n\t"
> > diff --git a/board/AndesTech/ax25-ae350/Kconfig
> > b/board/AndesTech/ax25-ae350/Kconfig
> > index bb69ea3..44cb302 100644
> > --- a/board/AndesTech/ax25-ae350/Kconfig
> > +++ b/board/AndesTech/ax25-ae350/Kconfig
> > @@ -21,4 +21,8 @@ config ENV_SIZE
> > config ENV_OFFSET
> > default 0x14 if ENV_IS_IN_SPI_FLASH
> >
> > +config BOARD_SPECIFIC_OPTIONS # dummy
> > + def_bool y
> > + select RISCV_NDS
> > +
> > endif
Reviewed-by: Rick Chen
> > --
> > 2.7.4
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 06/20] riscv: ax25: Hide the ax25-specific Kconfig option
Hi Bin Bin Meng 於 2018年12月12日 週三 下午10:16寫道： > > Hi Rick, > > On Wed, Dec 12, 2018 at 5:56 PM Rick Chen wrote: > > > > Bin Meng 於 2018年12月12日 週三 下午5:37寫道： > > > > > > Hi Rick, > > > > > > On Wed, Dec 12, 2018 at 5:02 PM Rick Chen wrote: > > > > > > > > Hi Bin > > > > > > > > Bin Meng 於 2018年12月11日 週二 下午3:17寫道： > > > > > > > > > > Hi Rick, > > > > > > > > > > On Tue, Dec 11, 2018 at 3:06 PM Rick Chen > > > > > wrote: > > > > > > > > > > > > > > Subject: [PATCH v2 06/20] riscv: ax25: Hide the ax25-specific > > > > > > > > Kconfig option > > > > > > > > > > > > > > > > There is no need to expose RISCV_NDS to the Kconfig menu as it > > > > > > > > is an > > > > > > > > ax25-specific option. > > > > > > > > > > > > > > > > > > > > Hi Bin > > > > > > > > > > > > Can you explain why there is no need to expose RISCV_NDS here ? > > > > > > > > > > > > > > > > This is specific to AX25, and there is no need to appear in the > > > > > Kconfig menu when people are building U-Boot for some other RISC-V > > > > > platforms. Also even if you select Y in the Kconfig menu for this > > > > > option for platforms other than AX25, it just does not help since all > > > > > its logic is within arch/riscv/cpu/ax25. > > > > > > > > > > > > > AX25 can not select RISCV_NDS by default, it may cause build fail > > > > problem. > > > > I still prefer to enable it by make menuconfig. > > > > Can you drop this patch ? > > > > > > > > > > I prefer not to drop this patch since it's not supposed to be exposed > > > to other platforms. > > > > > > Do you mean the build fail problem is custom CSR numbers like > > > mcache_ctl? Can we use hardcoded CSR number instead? > > > > > > > Thanks for your suggestion about hardcoded CSR number. > > > > But actually I hope the mcache_ctl will be disabled by default in this > > stage. > > Because some drivers of ae350 (like spi, smc flash driver, mac driver) > > still have some access problems when cache is enable. > > I am fixing it now. > > But mmc driver is ready when cache is enable. > > That is why I prefer enable cache by make menuconfig. > > It will be easy to switch cache enable or disable by make menuconfig > > without modifying Kconfig. > > > > How do you think about it ? > > > > Please check the v5 patch [1] which should satisfy your requirement. > > [1] http://patchwork.ozlabs.org/patch/1011983/ > Yes Thanks for this better solution. It is good to me. B.R Rick > Regards, > Bin ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Bogus message about SCSI during build
Hi Andy, On Wed, Dec 12, 2018 at 12:21 AM Andy Shevchenko wrote: > > Hi! > > Since X86 implies SCSI and Intel Edison board does not use it, I have got a > = WARNING == > This board does not use CONFIG_DM_SCSI. Please update > the storage controller to use CONFIG_DM_SCSI before the v2019.07 release. > Failure to update by the deadline may result in board removal. > See doc/driver-model/MIGRATION.txt for more info. > > > Is anybody aware of? AFAIK , this warning message is intentional to push board maintainers to convert their boards over to driver model. For the edison board, if SCSI is not used. you can turn it off in the board defconfig file. Regards, Bin Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] qemu x86 ide device not probing automatically with 2018.11
Hi Joshua,
On Thu, Dec 13, 2018 at 6:27 AM Joshua Watt wrote:
>
> Hello,
>
> I've been using u-boot as the boot loader for x86 qemu and some custom
> (e.g. non-default) boot commands. I recently upgraded from u-boot
> 2018.01 to 2018.11 and now my boot command fails because it doesn't
> look like u-boot is loading the driver for the ide device from which
> I'm attempting to load files.
>
> For reference, I'm basically building the qemu-x86 config only with
> changes to the default boot scripts. Namely, I have:
>
> #define CONFIG_BOOTCOMMAND \
> "ide dev ${bootpart}; " \
> "if run loadbootenv; then " \
> "run importbootenv; " \
> "fi; " \
> "run doboot; "
>
> The failure appears to occur when the script attempts to run "ide dev
> ${bootpart}", claiming the ide device doesn't exist. If I manually run
> the command "ide reset", and then "bootd" everything works fine, so I
> think this is being caused by the switch to using the device model for
Correct.
> ide(?). I suspect this means that I need to make some changes to my
> boot command to get it to probe the ide driver, but I wanted to make
> sure I'm doing that the correct way. Should I simply add a "ide reset"
> as the first line of CONFIG_BOOTCOMMAND, or is there a more "correct"
> way to get u-boot to probe the driver?
>
Yes, adding "ide reset" is the correct way.
Regards,
Bin
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v1] tools: mtk_image: replace strncpy(d, s, sizeof(d)) with snprintf()
On Tue, 2018-12-11 at 16:41 +0200, Andy Shevchenko wrote:
> Starting from version 8 the GCC, i.e. C compiler, starts complaining about
> possible '\0' terminator loss or, as in this case, garbage copy.
>
> In function ‘mtk_image_set_gen_header’,
> inlined from ‘mtk_image_set_header’ at tools/mtk_image.c:733:3:
> tools/mtk_image.c:659:2: warning: ‘strncpy’ specified bound 12 equals
> destination size [-Wstringop-truncation]
> strncpy(hdr->boot.name, bootname, sizeof(hdr->boot.name));
> ^
> In function ‘mtk_brom_parse_imagename’,
> inlined from ‘mtk_image_check_params’ at tools/mtk_image.c:388:9:
> tools/mtk_image.c:325:5: warning: ‘strncpy’ specified bound 32 equals
> destination size [-Wstringop-truncation]
> strncpy(lk_name, val, sizeof(lk_name));
> ^~
>
> Replace it with snprintf() to tell compiler how much room we have in the
> destination buffer for source string.
>
> Fixes: 3b975a147c3c ("tools: MediaTek: add MTK boot header generation to
> mkimage")
> Cc: Ryder Lee
> Cc: Weijie Gao
> Signed-off-by: Andy Shevchenko
> ---
> tools/mtk_image.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/tools/mtk_image.c b/tools/mtk_image.c
> index 2706d2de32..2ca519483d 100644
> --- a/tools/mtk_image.c
> +++ b/tools/mtk_image.c
> @@ -322,7 +322,7 @@ static int mtk_brom_parse_imagename(const char *imagename)
> lk = val;
>
> if (!strcmp(key, "lkname"))
> - strncpy(lk_name, val, sizeof(lk_name));
> + snprintf(lk_name, sizeof(lk_name), "%s", val);
> }
>
> if (next)
> @@ -656,7 +656,7 @@ static void mtk_image_set_gen_header(void *ptr, off_t
> filesize,
> bootname = SDMMC_BOOT_NAME;
>
> /* Generic device header */
> - strncpy(hdr->boot.name, bootname, sizeof(hdr->boot.name));
> + snprintf(hdr->boot.name, sizeof(hdr->boot.name), "%s", bootname);
> hdr->boot.version = cpu_to_le32(1);
> hdr->boot.size = cpu_to_le32(sizeof(hdr->boot));
>
Hi Andy,
The snprintf adds a NULL char at the end of the string which gives
only 31 available bytes for the lk name filed. But it's OK for this
because almost no one would like to give a name to fill the whole
field. The same applies to the device header.
Reviewed-by: Weijie Gao
Best Regards,
Weijie
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH u-boot-marvell v3 09/10] board: turris_mox: Support 1 GB version of Turris Mox
Hi Stefan,
it turned out that what I found out was not causing the bug.
get_ram_size reported 1 GiB of ram because I tried it when dcache was
already enabled. If I call get_ram_size in dram_init, it returns the
correct size on both 512 MiB and 1 GiB board.
In the next patch I shall define dram_init and dram_init_banksize in
arm64-common.c as __weak, and the definition in turris_mox.c shall call
get_ram_size. Is this acceptable?
Marek
On Wed, 12 Dec 2018 10:44:15 +0100
Stefan Roese wrote:
> Hi Marek,
>
> On 12.12.18 03:23, Marek Behun wrote:
> > Hi, I have found the bug causing this issue.
>
> Good.
>
> > If I understand the algorithm in get_ram_size correctly, it does
> > approximately this. Suppose A, B, C, D, E, F are different
> > constatnts. X(i) is a value at address 1< >
> > save[5] <- X(5)
> > X(5) <- F
> > save[4] <- X(4)
> > X(4) <- E
> > save[3] <- X(3)
> > X(3) <- D
> > save[2] <- X(2)
> > X(2) <- C
> > save[1] <- X(1)
> > X(1) <- B
> > save[0] <- X(0)
> > X(0) <- A
> >
> > So the previous values are stored in array save[]. The algorithm
> > then checks if the values written (the constants A, B, C, D, E, F)
> > are present at those addresses. The problem is that the previous
> > value from save[] is written during checking of address i:
> >
> > Now suppose the RAM is wrapped similarily as in MOX, so that X(i+3)
> > is the same as X(i).
> >
> > After the first part, the values are as follows
> >
> > X([0,1,2,3,4,5]) = [A,B,C,A,B,C]
> > save = [D,E,F,_3,_4,_5]
> >
> > Here _3, _4, _5 are the values at addresses X(3), X(4), X(5) before
> > the algorithm.
> >
> > The code that checks the values written does this:
> >
> > if X(0) != A
> > return 0
> > X(0) <- save[0] !!! this also writes D to X(3)
> >
> > if X(1) != B
> > return 1
> > X(1) <- save[1] !!! this also writes E to X(4)
> >
> > if X(2) != C
> > return 2
> > X(2) <- save[2] !!! this also writes F to X(F)
> >
> > if X(3) != D
> > return 3 !!! this should return, but won't
> > X(3) <- save[3]
> >
> > ...
> >
> > One solution would be to write the previous values from the array
> > save[] only immediately before return from the function.
>
> I have to admit that I didn't fully try to understand this issue you
> describe above (sorry, lack of time). If you have found a bug and do
> have a fix for it, then please submit a patch. Please add all
> developers (e.g. Patrick Delaunay etc) who did some work on this code
> to Cc, as changes here might be critical.
>
> > I have to confess that I do not like how this function is written at
> > all. It does not, for example, solve correctly the case when a
> > device has 768 MiB of RAM from two chips (512 + 256). Given 1024
> > MiB as argument, it would return 1024 MiB, but the system only has
> > 768 MiB. This maybe is never an issue with devices that run u-boot,
> > but still.
>
> If you have a nice and easy implementation to also support such
> memory configurations, that would be perfect of course. But I really
> think that such non-power-of-2 memory configurations are rather
> uncommon for U-Boot and most likely don't need to be supported by
> this function. Such configuration usually are a result of using
> multiple DIMM's (or SODIMM's) which can be equipped with various
> sized memories. And here the memory size can be read from the DIMM
> itself. So no need to support this in get_ram_size().
>
> Thanks,
> Stefan
>
> > Marek
> >
> > On Tue, 11 Dec 2018 16:06:42 +0100
> > Stefan Roese wrote:
> >
> >> On 11.12.18 15:53, Marek Behún wrote:
> >>> On Tue, 11 Dec 2018 15:28:11 +0100
> >>> Stefan Roese wrote:
> >>>
> Hi Marek,
>
> On 11.12.18 14:59, Marek Behún wrote:
> > get_ram_size does not work correctly on Mox. On a 512 MiB board
> > it detects 1024 MiB of RAM, because on the 512 MiB RAM chip the
> > topmost address bit is simply ignored and the RAM wraps - on
> > 0x2000-0x4000 CPU sees the same data as on
> > 0x0-0x2000.
>
> That's what get_ram_size() does: It does detect such aliases when
> the same memory is mapped at multiple areas (power of 2). Did you
> give it a try with a max value of 1024 MiB? It should return
> 512 on such boards.
> >>>
> >>> I checked it and it returned 1024 MiB.
> >>> I did
> >>> printf("%08x %08x\n",
> >>>get_ram_size(0, 512<<20),
> >>>get_ram_size(0, 1024<<20));
> >>> on a 512 MiB board and
> >>> 0x2000 0x4000
> >>> was printed.
> >>
> >> Very strange. Could you please debug this issue? get_ram_size()
> >> should be able to work in such situations.
> >>
> >> Thanks,
> >> Stefan
> >>
>
> > ATF does not run RAM size determining code either, it just gets
> > RAM size from a register, this register is written before ATF by
> > BootROM and we have done it so that there is always 1 GB so that
> > we could use same secure
Re: [U-Boot] [GIT] Pull request: u-boot-dfu (13.12.2018)
On 12/12/2018 11:58 PM, Lukasz Majewski wrote: > Dear Marek, This looks quite heavy after RC1 . How thoroughly was this tested ? > The following changes since commit 51b24944fdbfa760aa87a1ad812355e1df9c9355: > > usb: musb: Remove legacy CONFIG_USB_DA8XX (2018-12-12 15:23:04 +0100) > > are available in the git repository at: > > git://git.denx.de/u-boot-dfu.git > > for you to fetch changes up to 8a3755462f65c032528af70c6582abf89f91b2bc: > > configs: am335x_boneblack_vboot: enable DM_USB and RNDIS boot in SPl > (2018-12-12 15:35:08 +0100) > > > Jean-Jacques Hiblot (20): > usb: dwc3-generic: make it compatible with "ti, keystone-dwc3" > board: ks2_evm: Enable the USB clocks if DM_USB is used > ARM: dts: k2g-evm: enable USB0 and USB1 > PHY: Add phy driver for the keystone USB PHY > usb: host: replace xhci-keystone driver by the generic dwc3 driver > configs: k2g_evm: Enable DFU on K2G EVM > spl: drivers: Link usb common library to SPL if USB gadget is enabled > spl: net: dm: usb: bind the gadget before attempting to load the image > phy: omap_usb2: Add support for am437x > dwc3-generic: Add support for the am437x > board: ti: am43xx: turn on USB clocks > dts: Add a u-boot specific dtsi file for the am4372 > dts: am4372: Enable USB1 in SPL > configs: am43xx_evm: Enable DM_USB and DM_USB_GADGET > configs: am43xx: Enable RNDIS support in SPL > usb: musb-new: Allow the diver not to use the set_phy_power() callback > usb: musb-new: Add support for DM_USB > arm: am33xx: Register USB controllers if DM_USB is used but not > OF_CONTROL > configs: am335x_evm: Do not disable DM_USB in SPL > configs: am335x_boneblack_vboot: enable DM_USB and RNDIS boot in SPl > > arch/arm/dts/am4372-generic-u-boot.dtsi | 2 + > arch/arm/dts/am4372-u-boot.dtsi | 40 ++ > arch/arm/dts/am437x-gp-evm-u-boot.dtsi | 2 + > arch/arm/dts/am437x-idk-evm-u-boot.dtsi | 2 + > arch/arm/dts/am437x-sk-evm-u-boot.dtsi | 2 + > arch/arm/dts/keystone-k2g-evm.dts| 28 + > arch/arm/dts/keystone-k2g.dtsi | 56 + > arch/arm/include/asm/omap_musb.h | 8 > arch/arm/mach-omap2/am33xx/board.c | 58 ++ > board/ti/am43xx/board.c | 22 ++ > board/ti/ks2_evm/board.c | 12 ++ > common/Makefile | 3 ++ > common/spl/spl_net.c | 4 +- > configs/am335x_boneblack_vboot_defconfig | 10 + > configs/am43xx_evm_defconfig | 19 + > configs/k2e_evm_defconfig| 7 > configs/k2e_hs_evm_defconfig | 7 > configs/k2g_evm_defconfig| 12 ++ > configs/k2g_hs_evm_defconfig | 12 ++ > configs/k2hk_evm_defconfig | 7 > configs/k2hk_hs_evm_defconfig| 7 > configs/k2l_evm_defconfig| 7 > configs/k2l_hs_evm_defconfig | 7 > drivers/Makefile | 1 + > drivers/phy/Kconfig | 10 + > drivers/phy/Makefile | 1 + > drivers/phy/keystone-usb-phy.c | 109 > + > drivers/phy/omap-usb2-phy.c | 45 +++- > drivers/usb/dwc3/dwc3-generic.c | 2 + > drivers/usb/host/Makefile| 1 - > drivers/usb/host/xhci-keystone.c | 240 > --- > drivers/usb/musb-new/am35x.c | 8 ++-- > drivers/usb/musb-new/musb_dsps.c | 8 ++-- > drivers/usb/musb-new/musb_gadget.c | 11 + > drivers/usb/musb-new/musb_uboot.c| 4 +- > drivers/usb/musb-new/ti-musb.c | 181 > +++- > include/configs/am335x_evm.h | 1 - > include/configs/ti_armv7_keystone2.h | 17 +--- > 38 files changed, 649 insertions(+), 324 deletions(-) > create mode 100644 arch/arm/dts/am4372-u-boot.dtsi > create mode 100644 drivers/phy/keystone-usb-phy.c > delete mode 100644 drivers/usb/host/xhci-keystone.c > > Travis-Ci: https://travis-ci.org/lmajewski/u-boot-dfu/builds/467026476 > > This is the last instalment of patches from Jean-Jacques > > 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 > -- Best regards, Marek Vasut ___ U-Boot mailing
Re: [U-Boot] [PATCH 05/16] mtd: spi: Port SPI NOR framework from Linux
On Thu, Dec 13, 2018 at 04:51:56AM +0530, Jagan Teki wrote: > On Thu, Dec 13, 2018 at 4:26 AM Tom Rini wrote: > > > > On Thu, Dec 13, 2018 at 02:01:15AM +0530, Jagan Teki wrote: > > > On Wed, Dec 12, 2018 at 11:10 PM Vignesh R wrote: > > > > > > > > Current U-Boot SPI NOR support (sf layer) is quite outdated as it does > > > > not > > > > support 4 byte addressing opcodes, SFDP table parsing and different > > > > types of > > > > quad mode enable sequences. Many newer flashes no longer support BANK > > > > registers used by sf layer to a access >16MB space. > > > > Also, many SPI controllers have special MMIO interfaces which provide > > > > accelerated read/write access but require knowledge of flash parameters > > > > to make use of it. Recent spi-mem layer provides a way to support such > > > > flashes but sf layer isn't using that. > > > > So sync SPI NOR framework from Linux v4.19 and add spi-mem support on > > > > top. > > > > in order to gain 4 byte addressing support, SFDP support and a way to > > > > support SPI controllers with MMIO flash interface. > > > > > > > > Signed-off-by: Vignesh R > > > > --- > > > > drivers/mtd/spi/spi-nor-core.c | 2647 > > > > include/linux/mtd/cfi.h| 32 + > > > > include/linux/mtd/spi-nor.h| 421 + > > > > > > Please refer many mails about this comment. I don't look for carbon > > > copy of the code from Linux, you can use the implementation and even > > > macro names etc but the end code would be the code that require > > > U-Boot. > > > > > > - no __UBOOT ifdef > > > > What? This is the exact opposite of what we're doing in several other > > areas, with a large amount of success precisely because it allows us to > > leverage developer base to catch and fix problems. Dropping in the code > > and minor and obvious deviations make for easier re-sync. > > Several areas, but not spi-flash or spi. ie what I'm maintaining from > long. I'm always looking for persistent code to be IN. May be it can't > be syn-cable but we can work it more maintainable in u-boot way like > other opensource project. Well this is my experience with the U-Boot > project development so-far, I never ever hold any features but if > u-boot need the same features, better to add then like new code. I think that for flash related SPI we should follow the lead of the rest of MTD/NAND and adapt the kernel code. -- 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 09/16] sf_mtd: Simply mtd operations
Am 12.12.18 um 18:32 schrieb Vignesh R:
> Now that there is new SPI NOR framework, simplify mtd device
> registration and read/write/erase operations.
>
> Signed-off-by: Vignesh R
> ---
> drivers/mtd/spi/sf_internal.h | 2 +-
> drivers/mtd/spi/sf_mtd.c | 52 ++-
> drivers/mtd/spi/sf_probe.c| 5 ++--
> 3 files changed, 24 insertions(+), 35 deletions(-)
>
> diff --git a/drivers/mtd/spi/sf_internal.h b/drivers/mtd/spi/sf_internal.h
> index 7e7d400cdbdf..8b445bb0b506 100644
> --- a/drivers/mtd/spi/sf_internal.h
> +++ b/drivers/mtd/spi/sf_internal.h
> @@ -99,6 +99,6 @@ int spi_flash_cmd_get_sw_write_prot(struct spi_flash
> *flash);
>
> #ifdef CONFIG_SPI_FLASH_MTD
> int spi_flash_mtd_register(struct spi_flash *flash);
> -void spi_flash_mtd_unregister(void);
> +void spi_flash_mtd_unregister(struct spi_flash *flash);
> #endif
> #endif /* _SF_INTERNAL_H_ */
> diff --git a/drivers/mtd/spi/sf_mtd.c b/drivers/mtd/spi/sf_mtd.c
> index 68c36002bee2..65185b7c57dc 100644
> --- a/drivers/mtd/spi/sf_mtd.c
> +++ b/drivers/mtd/spi/sf_mtd.c
> @@ -9,21 +9,19 @@
> #include
> #include
>
> -static struct mtd_info sf_mtd_info;
> static bool sf_mtd_registered;
> static char sf_mtd_name[8];
>
> static int spi_flash_mtd_erase(struct mtd_info *mtd, struct erase_info
> *instr)
> {
> - struct spi_flash *flash = mtd->priv;
> int err;
>
> - if (!flash)
> + if (!mtd || !mtd->priv)
> return -ENODEV;
>
> instr->state = MTD_ERASING;
>
> - err = spi_flash_erase(flash, instr->addr, instr->len);
> + err = mtd->_erase(mtd, instr);
this looks strange. Now you're delegating from the MTD instance created
in this driver to the one created by spi-nor. This driver was only meant
as an adapter between MTD and legacy SPI flash API. After the switch to
spi-nor this driver is obsolete and should be removed in patch 6/16. Or
is there any reason why users like cmd_mtd can't directly use the
spi-nor MTD instance?
> if (err) {
> instr->state = MTD_ERASE_FAILED;
> instr->fail_addr = MTD_FAIL_ADDR_UNKNOWN;
> @@ -39,13 +37,12 @@ static int spi_flash_mtd_erase(struct mtd_info *mtd,
> struct erase_info *instr)
> static int spi_flash_mtd_read(struct mtd_info *mtd, loff_t from, size_t len,
> size_t *retlen, u_char *buf)
> {
> - struct spi_flash *flash = mtd->priv;
> int err;
>
> - if (!flash)
> + if (!mtd || !mtd->priv)
> return -ENODEV;
>
> - err = spi_flash_read(flash, from, len, buf);
> + err = mtd->_read(mtd, from, len, retlen, buf);
> if (!err)
> *retlen = len;
>
> @@ -55,13 +52,12 @@ static int spi_flash_mtd_read(struct mtd_info *mtd,
> loff_t from, size_t len,
> static int spi_flash_mtd_write(struct mtd_info *mtd, loff_t to, size_t len,
> size_t *retlen, const u_char *buf)
> {
> - struct spi_flash *flash = mtd->priv;
> int err;
>
> - if (!flash)
> + if (!mtd || !mtd->priv)
> return -ENODEV;
>
> - err = spi_flash_write(flash, to, len, buf);
> + err = mtd->_write(mtd, to, len, retlen, buf);
> if (!err)
> *retlen = len;
>
> @@ -83,10 +79,11 @@ static int spi_flash_mtd_number(void)
>
> int spi_flash_mtd_register(struct spi_flash *flash)
> {
> + struct mtd_info *mtd = >mtd;
> int ret;
>
> if (sf_mtd_registered) {
> - ret = del_mtd_device(_mtd_info);
> + ret = del_mtd_device(mtd);
> if (ret)
> return ret;
>
> @@ -94,42 +91,33 @@ int spi_flash_mtd_register(struct spi_flash *flash)
> }
>
> sf_mtd_registered = false;
> - memset(_mtd_info, 0, sizeof(sf_mtd_info));
> sprintf(sf_mtd_name, "nor%d", spi_flash_mtd_number());
>
> - sf_mtd_info.name = sf_mtd_name;
> - sf_mtd_info.type = MTD_NORFLASH;
> - sf_mtd_info.flags = MTD_CAP_NORFLASH;
> - sf_mtd_info.writesize = 1;
> - sf_mtd_info.writebufsize = flash->page_size;
> -
> - sf_mtd_info._erase = spi_flash_mtd_erase;
> - sf_mtd_info._read = spi_flash_mtd_read;
> - sf_mtd_info._write = spi_flash_mtd_write;
> - sf_mtd_info._sync = spi_flash_mtd_sync;
> -
> - sf_mtd_info.size = flash->size;
> - sf_mtd_info.priv = flash;
> + mtd->name = sf_mtd_name;
> + mtd->_erase = spi_flash_mtd_erase;
> + mtd->_read = spi_flash_mtd_read;
> + mtd->_write = spi_flash_mtd_write;
> + mtd->_sync = spi_flash_mtd_sync;
>
> /* Only uniform flash devices for now */
> - sf_mtd_info.numeraseregions = 0;
> - sf_mtd_info.erasesize = flash->sector_size;
> + mtd->numeraseregions = 0;
>
> - ret = add_mtd_device(_mtd_info);
> + ret = add_mtd_device(mtd);
> if (!ret)
> sf_mtd_registered = true;
>
> return ret;
> }
>
> -void spi_flash_mtd_unregister(void)
> +void spi_flash_mtd_unregister(struct spi_flash *flash)
> {
> +
Re: [U-Boot] policy regarding unused code
> > From: Jean-Jacques Hiblot [mailto:jjhib...@ti.com] > > Sent: Wednesday, December 12, 2018 8:00 PM > > To: Tom Rini > > Cc: U-Boot; Rick Jian-Zhi Chen(陳建志) > > Subject: Re: [U-Boot] policy regarding unused code > > > > Tom, Rick, > > > > On 11/12/2018 19:17, Tom Rini wrote: > > > On Tue, Dec 11, 2018 at 06:01:23PM +0100, Jean-Jacques Hiblot wrote: > > >> On 11/12/2018 17:35, Tom Rini wrote: > > >>> On Tue, Dec 11, 2018 at 04:46:01PM +0100, Jean-Jacques Hiblot wrote: > > On 11/12/2018 16:25, Jean-Jacques Hiblot wrote: > > > Hi Tom, > > > > > > Is there such a policy described somewhere ? > > > > > > There are quite a pieces of code that are not used/compiled > > > because no config enables it. > > > > > > A random pick among many others: > > > > > > - CONFIG_FPGA_LATTICE > > > > > > - CONFIG_MESON_SPIFC > > > > > > - CONFIG_POWER_BATTERY_TRATS2 > > > > > > - CONFIG_UPDATE_TFTP > > > > > > > > Here a more complete list of suspects (there may be options that do > > not even > > exist) > > > > Suspect means that the variable is probably referenced in a > > Makefile but not in configs/ nor in include/configs > > > > This is not a small list and a lot of them we probably want to keep. > > > > ['CONFIG_MX8M', 'CONFIG_POWER_PMIC_MAX77693', > > 'CONFIG_TPM2_TIS_SANDBOX', 'CONFIG_TPM_ST33ZP24_SPI', > > 'CONFIG_USB_SL811HS', 'CONFIG_RAM_SUPPORT', > > 'CONFIG_BCM2835_WDT', > > 'CONFIG_ENV_IS_IN_SATA', 'CONFIG_IO64', 'CONFIG_NAND_SUPPORT', > > 'CONFIG_NOR_SUPPORT', 'CONFIG_RISCV_ISA_A', > > 'CONFIG_I2C_MUX_GPIO', > > 'CONFIG_POWER_FG_MAX17042', 'CONFIG_DNET', > > 'CONFIG_CMD_SH_ZIMAGEBOOT', 'CONFIG_USE_DEFAULT_ENV_FILE', > > 'CONFIG_CMD_IOTRACE', 'CONFIG_ALI152X', 'CONFIG_M5271', > > 'CONFIG_CPU_MPC83XX', 'CONFIG_NXP_TDA19988', 'CONFIG_IMX', > > 'CONFIG_ADI_GPIO2', 'CONFIG_BUILD_ENVCRC', 'CONFIG_FTMAC110', > > 'CONFIG_CMD_CONITRACE', 'CONFIG_USB_DAVINCI', > > 'CONFIG_TARGET_XTFPGA', 'CONFIG_DLVISION_10G', > > 'CONFIG_CMD_KGDB', > > 'CONFIG_USB_SDP_SUPPORT', > > 'CONFIG_MESON_GX_VPU_POWER_DOMAIN', > > 'CONFIG_FSL_DMA', 'CONFIG_IHS_VIDEO_OUT', 'CONFIG_CMD_ZFS', > > 'CONFIG_P2020DS', 'CONFIG_RTC_DS1388', > > 'CONFIG_POWER_MUIC_MAX8997', > > 'CONFIG_TPM2_TIS_SPI', 'CONFIG_TEST_FDTDEC', > > 'CONFIG_AIS_CONFIG_FILE', 'CONFIG_GDSYS_SOC', > > 'CONFIG_CMD_DTIMG', > > 'CONFIG_DFU_SUPPORT', 'CONFIG_SYS_JFFS2_SORT_FRAGMENTS', > > 'CONFIG_ATF', 'CONFIG_BLOBLIST', 'CONFIG_NAND_SPEAR', > > 'CONFIG_MPC8XXX_GPIO', 'CONFIG_ULP_WATCHDOG', > > 'CONFIG_RTC_MK48T59', > > 'CONFIG_CMD_FITUPD', 'CONFIG_MODVERSIONS', 'CONFIG_CPU_SH3', > > 'CONFIG_CMD_BEDBUG', 'CONFIG_AT91_USB_CLK', > > 'CONFIG_CMD_UNIVERSE', > > 'CONFIG_DEBUG_UART_UNIPHIER', 'CONFIG_CMD_DISPLAY', > > 'CONFIG_ETH_SANDBOX_RAW', 'CONFIG_SANDBOX', 'CONFIG_CPU_SH2', > > 'CONFIG_SATA_SUPPORT', 'CONFIG_IOCON', 'CONFIG_MESON_SPIFC', > > 'CONFIG_NS8382X', 'CONFIG_SOC_DM355', > > 'CONFIG_BOARD_GAZERBEAM', > > 'CONFIG_CMD_AVB', 'CONFIG_MW_EEPROM', > > 'CONFIG_SHA1_CHECK_UB_IMG', > > 'CONFIG_IHS_FPGA', 'CONFIG_USE_PLUGIN', 'CONFIG_VIDEO_SIMPLE', > > 'CONFIG_CLK_VEXPRESS_OSC', 'CONFIG_MIPS_TUNE_14KC', > > 'CONFIG_MPC83XX_SDRAM', 'CONFIG_XIP_SUPPORT', > > 'CONFIG_MIPS_TUNE_34KC', 'CONFIG_ALTERA_UART', > > 'CONFIG_LOAD_FIT', > > 'CONFIG_RTC_DS1339', 'CONFIG_ENV_SUPPORT', > > 'CONFIG_DEFAULT_ENV_FILE', 'CONFIG_TPM_ST33ZP24_I2C', > > 'CONFIG_PCH_SUPPORT', 'CONFIG_UBOOT_PAD_TO', 'CONFIG_LYNXKDI', > > 'CONFIG_CMD_SMC', 'CONFIG_BOOTCOUNT_AT91', > > 'CONFIG_OF_PLATDATA', > > 'CONFIG_CONSOLE_TRUETYPE_NIMBUS', 'CONFIG_S6E8AX0', > > 'CONFIG_FPGA_ACEX1K', 'CONFIG_MVEBU_EFUSE', > > 'CONFIG_CONSOLE_TRUETYPE_RUFSCRIPT', > > 'CONFIG_XILINX_MICROBLAZE0_HW_VER', > > 'CONFIG_CONSOLE_TRUETYPE_ANKACODER', > > 'CONFIG_RTC_M41T60', 'CONFIG_CMD_ZIP', 'CONFIG_USB_SUPPORT', > > 'CONFIG_SPI_FLASH_SUPPORT', 'CONFIG_FLASH_PIC32', > > 'CONFIG_SAVEENV', > > 'CONFIG_FPGA_STRATIX_II', 'CONFIG_TEE', 'CONFIG_PIC32_SPI', > > 'CONFIG_FAT_SUPPORT', 'CONFIG_SERIAL_SUPPORT', > > 'CONFIG_RTC_DS174x', > > 'CONFIG_RTC_RS5C372A', 'CONFIG_DM_DEBUG', > > 'CONFIG_DISPLAY_ROCKCHIP_LVDS', 'CONFIG_CMD_ZYNQ_RSA', > > 'CONFIG_VEXPRESS_CONFIG', 'CONFIG_SPI_SUPPORT', > > 'CONFIG_POWER_BATTERY_TRATS2', 'CONFIG_CS8900', > > 'CONFIG_DRIVERS_MISC_SUPPORT', 'CONFIG_YMODEM_SUPPORT', > > 'CONFIG_MPC83XX_SERDES', 'CONFIG_NAND_KB9202', > > 'CONFIG_PL022_SPI', > > 'CONFIG_RTC_PCF2127', 'CONFIG_ARMV8_PSCI', 'CONFIG_KALLSYMS', > > 'CONFIG_LAN91C96', 'CONFIG_SHELL', 'CONFIG_SOC_DM646X', > > 'CONFIG_HASH_SUPPORT', 'CONFIG_ARMADA_39X', > > 'CONFIG_CMD_STRINGS', > > 'CONFIG_ARCH_RV32I', 'CONFIG_RTC_M48T35A', > > 'CONFIG_DATAFLASH_MMC_SELECT', 'CONFIG_UPDATE_TFTP', >
Re: [U-Boot] MIPS (mt7688): EBase change in U-Boot breaks Linux
Hi Stefan, Am 12.12.18 um 09:18 schrieb Stefan Roese: > Hi! > > I've been hunting for a problem for quite some time, where Linux > hangs / crashes in userspace at some point on my MT7688 based > systems. I found that this problem can be avoided (worked around) > by not giving Linux the full memory (by using DT memory node fixup > or mem= kernel cmdline). When reducing this memory by the memory > used by U-Boot (stack pointer minus some KiB value as this is the > "lowest" memory used by U-Boot), then Linux runs just fine. > > My first idea here was, that this issue is cache related (most > likely I-cache). But all tests and debugging in this area did not > fix this issue (even running with caches disabled). > > Finally I found that this line in U-Boot makes Linux break: > > arch/mips/lib/traps.c: > > void trap_init(ulong reloc_addr) > unsigned long ebase = gd->irq_sp; > ... > write_c0_ebase(ebase); > > This sets EBase to something like 0x87e9b000 on my system (128MiB). > And Linux then re-uses this value and copies the exceptions handlers > to this address, overwriting random code and leading to an unstable > system. > > So my questions now is, how should this be handled on the MT7688 > platform instead? One way would be to set EBase back to the > original value (0x8000) before booting into Linux. Another > solution would be to add some Linux code like board_ebase_setup() > to the MT7688 Linux port. > > Since I'm still no real MIPS expert yet, I would really like to get > some advise here on how to best solve this issue. Maybe I missed > something. Comments? > > Thanks, > Stefan the relevant code is in arch/mips/kernel/traps.c:trap_init(): Within the branch if (cpu_has_veic || cpu_has_vint) the kernel will allocate memory for the exception vectors and resets ebase to that memory. In the else branch ebase is statically assigned to CAC_BASE which should resolve to 0x8000 on Ralink platform. The ebase is only read from CP0 for MIPS r6 CPUs. So the ebase set by U-Boot shouldn't be relevant for Ralink platform. More likely some code at 0x8000 is overwritten when installing the exception handlers because all Ralink SoCs except MT7621 have 0x8000 defined as load address. So adding something like 0x1000 should fix your problem too. AFAIK the CPU probing should detect and set cpu_has_veic accordingly. Maybe it's a bug by Ralink to not set this bit. I guess that's why a platform could provide a cpu-feature-overrides.h. Or you could configure CPU_MIPSR2_IRQ_VI as Horatio stated in his response. @Paul regarding MIPS r6, is there some expectation of the bootloader to set ebase to a reasonable value or to not change the value at all? Maybe we need to fix U-Boot? -- - Daniel ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] ARM: davinci: Orphan Spectrum Digital AM18xx EVM
On Tue, Dec 11, 2018 at 07:41:03AM -0600, Adam Ford wrote: > I had requested the da850 boards because their previous maintainer > had an invalid e-mail address. I work at Logic PD who makes > the da850-evm kits, so I have access to various boards of theirs. > > The Spectrum Digital AM18xx board is based on the Logic PD > da850 EVM, but it's not the same company. Since I don't have the > hardware to test/verify changes, I would prefer to not be > responsible for this board. > > Signed-off-by: Adam Ford > > diff --git a/board/davinci/da8xxevm/MAINTAINERS > b/board/davinci/da8xxevm/MAINTAINERS > index 59589867b3..b77a5f6622 100644 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] firmware: psci: introduce SPL_ARM_PSCI_FW
On Sun, Dec 09, 2018 at 12:45:45PM +, Peng Fan wrote: > Introduce a new macro SPL_ARM_PSCI_FW > > Signed-off-by: Peng Fan > Reviewed-by: Stefano Babic 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] ARM: omap3_logic/omap35_logic: Move to DM_USB
On Fri, Dec 07, 2018 at 02:38:33PM -0600, Adam Ford wrote: > The existing config is setup as a gadget but it doesn't use > DM_USB. This patch converts all boards to DM_USB, but as host. > > As host, it is able to mount USB drives and browse them. > > Signed-off-by: Adam Ford > > diff --git a/configs/omap35_logic_defconfig b/configs/omap35_logic_defconfig > index 80219eeacf..82ddaa3a2b 100644 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] arm: am335x-pdu001: Move from embedded to separate DTB
On Fri, Dec 07, 2018 at 03:01:55PM +0100, Felix Brack wrote: > There is no need for an embedded device tree for this board so let the > build process generate a separate u-boot.dtb file instead. > > Signed-off-by: Felix Brack 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] defconfigs: am335x_hs_evm: Sync HS and non-HS defconfigs
On Wed, Dec 05, 2018 at 12:33:33PM -0600, Andrew F. Davis wrote: > Sync new additions to non-HS defconfig with HS defconfig. > > Signed-off-by: Andrew F. Davis > Reviewed-by: Tom Rini 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] ARM: omap3logic: Remove legacy USB code in favor of DM_USB
On Fri, Dec 07, 2018 at 05:28:03PM -0600, Adam Ford wrote: > With the defconfig options enabling DM_USB, the legacy code > can be removed. > > Signed-off-by: Adam Ford > > diff --git a/board/logicpd/omap3som/omap3logic.c > b/board/logicpd/omap3som/omap3logic.c > index 691d38fdf2..144e6f68a4 100644 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] spl: fix build failure with !CONFIG_SPL_PCI_SUPPORT
On Thu, Dec 06, 2018 at 03:40:08PM +0530, Sekhar Nori wrote: > Building U-Boot with CONFIG_PCI and CONFIG_DM_PCI enabled, but > CONFIG_SPL_PCI_SUPPORT disabled, results in following linker > error: > > lib/built-in.o: In function `fdtdec_get_pci_bar32': > lib/fdtdec.c:305: undefined reference to `dm_pci_read_bar32' > fdtdec.c:305:(.text.fdtdec_get_pci_bar32+0x24): relocation truncated to fit: > R_AARCH64_CALL26 against undefined symbol `dm_pci_read_bar32' > > This is because reference to dm_pci_read_bar32() remains in lib/fdtdec.c > while SPL build does not descend into drivers/pci directory in > drivers/Makefile if CONFIG_SPL_PCI_SUPPORT is not enabled. > > Fix this by applying appropriate #define guards in lib/fdtdec.c. > It looks like ns16550.c has the same problem, so fixed that too. > > To simplify this, CONFIG_SPL_PCI_SUPPORT is renamed to CONFIG_SPL_PCI > (enables use of CONFIG_IS_ENABLED() macro). > > Suggested-by: Vignesh R > Signed-off-by: Sekhar Nori > Reviewed-by: Lokesh Vutla > Reviewed-by: Tom Rini 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] am3517_evm: Use ttyS2 instead of ttyO2
On Mon, Dec 10, 2018 at 02:56:36PM -0600, Adam Ford wrote: > The serial driver in the kernel moved from ttyOx to ttySx a while > ago. This patch updates the console parameter to align with the > kernel change. > > Signed-off-by: Adam Ford > > diff --git a/include/configs/am3517_evm.h b/include/configs/am3517_evm.h > index 4e7e5209d4..eb50012ff7 100644 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] [U-Boot,1/1] test: overlay: NULL passed as fdt
On Sat, Dec 08, 2018 at 09:53:05AM +0100, Heinrich Schuchardt wrote:
> The uts created in do_ut_overlay() is not the one used in
> cmd_ut_category(). Currently all tests are therefore called with
> uts->priv = NULL and fail.
>
> Using a static variable is the easiest fix here.
>
> Fixes: e93232e15ec9 ("test: overlay: Use cmd_ut_category()")
> Signed-off-by: Heinrich Schuchardt
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] blk: Rework guard around part_init call
On Wed, Dec 05, 2018 at 08:23:38AM -0500, Tom Rini wrote: > The function part_init() will only be built when we have both > CONFIG_PARTITIONS and CONFIG_HAVE_BLOCK_DEVICE set. Protect the call to > this function with both of these tests now. > > Cc: Simon Glass > Cc: Philipp Tomsich > Cc: Michal Simek > Cc: York Sun > Cc: Prabhakar Kushwaha > Cc: Mingkai Hu > Cc: Stefan Roese > Cc: Marek Behún > Cc: Vanessa Maegima > Cc: Eugen Hristev > Cc: Adam Ford > Cc: Jagan Teki > Cc: Tom Warren > Cc: Stephen Warren > Cc: Vitaly Andrianov > Signed-off-by: Tom Rini > Reviewed-by: Simon Glass 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] test: hexdump: fix misplaced return
On Tue, Dec 04, 2018 at 09:30:08PM +0100, Simon Goldschmidt wrote: > One of the hexdump tests in test/lib/hexdump.c returns right at the > start of the function without testing anything. > > Fix this by moving the 'return 0;' statement to the end of the function. > > Signed-off-by: Simon Goldschmidt > Reviewed-by: Simon Glass 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] fdt: Add warning about CONFIG_OF_EMBED
On Wed, Dec 05, 2018 at 06:57:08AM -0700, Simon Glass wrote: > This option has crept into use with some boards. Add a warning to try to > prevent this. > > As an example: >https://lists.denx.de/pipermail/u-boot/2017-September/304966.html > > Signed-off-by: Simon Glass > Reviewed-by: Tom Rini 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] qemu-arm: Add persistent environment support
On Mon, Nov 26, 2018 at 04:50:17PM +0530, Sumit Garg wrote: > Currently on qemu-arm platforms environment is kept in RAM. Instead > use pflash device 1 to provide persistent environment support across > device reset. > > Also (optionally) provide support for persistent environment across > qemu machine OFF/ON using following instructions: > > - Create envstore.img using qemu-img: > qemu-img create -f raw envstore.img 64M > - Add a pflash drive parameter to the command line: > -drive if=pflash,format=raw,index=1,file=envstore.img > > Signed-off-by: Sumit Garg 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] [U-Boot,v2] qemu-arm: Enable VirtIO distro target
On Tue, Nov 13, 2018 at 10:21:24AM +0530, Sumit Garg wrote: > With -device virtio-blk-device,drive=hd0, it could detect distro boot > target. > > Signed-off-by: Sumit Garg > Reviewed-by: Alexander Graf 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] [PATCH] qemu-arm: Add persistent environment support
Hi Sumit, Takahiro, On Wed, 12 Dec 2018 10:42:56 +0900 Takahiro Akashi wrote: > On Tue, Dec 11, 2018 at 06:04:05PM +0530, Sumit Garg wrote: > > On Mon, 26 Nov 2018 at 16:51, Sumit Garg > > wrote: > > > > > > Currently on qemu-arm platforms environment is kept in RAM. > > > Instead use pflash device 1 to provide persistent environment > > > support across device reset. > > > > > > Also (optionally) provide support for persistent environment > > > across qemu machine OFF/ON using following instructions: > > > > > > - Create envstore.img using qemu-img: > > > qemu-img create -f raw envstore.img 64M > > > - Add a pflash drive parameter to the command line: > > > -drive if=pflash,format=raw,index=1,file=envstore.img > > > > > > Signed-off-by: Sumit Garg > > > --- > > > configs/qemu_arm64_defconfig | 7 +++ > > > configs/qemu_arm_defconfig | 7 +++ > > > doc/README.qemu-arm | 6 ++ > > > include/configs/qemu-arm.h | 8 +++- > > > 4 files changed, 27 insertions(+), 1 deletion(-) > > > > > > > Gentle reminder. Please let me know if you have any further > > comments. I'm not too familiar with the UEFI/ATF related aspects here, but I think that the read-only parts (aka u-boot.bin) and read-write parts (the U-Boot environment) should belong to different files (which is what this patch series does). Basically, IMO as a normal user I should be able to run QEMU on a distro-provided U-Boot binary with something like: qemu-system-arm -bios /usr/share/u-boot/qemu_arm.bin and not have it fail due to not having write permission to /usr/. > Another use case is atf + u-boot (although I don't know people are > interested in it). Put bl1.bin in flash0(0x0-0x400) and put > fip.bin in flash1(0x400-0x800). Please note that, with > secure=on, flash0 is in secure and flash1 is in non-secure. > While I admit that your patch is workable, my point is that there are > different use cases and it may not be a good idea to put one > configuration in qemu-arm.h. Can EDK2 in QEMU boot with ATF and if so, how does it lay out things? Would it be possible to build U-Boot in such a way that u-boot.bin could be substituted in existing build scripts or instructions in place of the EDK2 binary so that things still work the same? Or in other words, if EDK2 has already has a working implementation of something (such as the flash layout), IMO we should prefer to use that instead of reimplementing it in a different way. - Tuomas ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 03/16] spi: Add non DM version of SPI_MEM
On Thu, 13 Dec 2018 04:40:30 +0530 Jagan Teki wrote: > > I do really understand your intention about the real question. > - Any code or generic code will add in U-Boot should be driver-model > driven, are you agree this point? > Yes- thanks. > No - we need to have separate discussion. Depends on what you mean by driver-model driven. Yes, applying the DM sometimes makes sense, but blindly trying to push it everywhere just for the sake of being "DM compliant" is a huge mistake IMO. One example of the thing you suggested which didn't make sense at all: force MTD users to manipulate udevice objects instead of mtd_info ones. > > Any code that related to spi, or spi-flash should be driver-model > driven, ie what my AIM as a Maintainer (ie only reason for my spi-nor > changes resist for long time to fit). You seem to use the term "driver-model" a lot without clearly explaining what you have in mind. The driver-model should be used where it makes sense, but some of your suggestions don't make any sense to me. Like the proposal to add a SPI NOR uclass while we already have an MTD uclass which works just fine for all kind of flash devices. Oh, and this strict rule that says "don't provide wrappers to handle non-DM compliant cases" is just wrong. As I said, none of these dummy wrappers prevent you from enforcing DM_SPI conversion, and it allows us to support existing HW while getting rid of the old code base. Plus, I suggested to declare the spi-nor driver as an MTD uclass so it's not like we're completely ignoring your comments :P. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 05/16] mtd: spi: Port SPI NOR framework from Linux
On Thu, Dec 13, 2018 at 4:26 AM Tom Rini wrote: > > On Thu, Dec 13, 2018 at 02:01:15AM +0530, Jagan Teki wrote: > > On Wed, Dec 12, 2018 at 11:10 PM Vignesh R wrote: > > > > > > Current U-Boot SPI NOR support (sf layer) is quite outdated as it does not > > > support 4 byte addressing opcodes, SFDP table parsing and different types > > > of > > > quad mode enable sequences. Many newer flashes no longer support BANK > > > registers used by sf layer to a access >16MB space. > > > Also, many SPI controllers have special MMIO interfaces which provide > > > accelerated read/write access but require knowledge of flash parameters > > > to make use of it. Recent spi-mem layer provides a way to support such > > > flashes but sf layer isn't using that. > > > So sync SPI NOR framework from Linux v4.19 and add spi-mem support on top. > > > in order to gain 4 byte addressing support, SFDP support and a way to > > > support SPI controllers with MMIO flash interface. > > > > > > Signed-off-by: Vignesh R > > > --- > > > drivers/mtd/spi/spi-nor-core.c | 2647 > > > include/linux/mtd/cfi.h| 32 + > > > include/linux/mtd/spi-nor.h| 421 + > > > > Please refer many mails about this comment. I don't look for carbon > > copy of the code from Linux, you can use the implementation and even > > macro names etc but the end code would be the code that require > > U-Boot. > > > > - no __UBOOT ifdef > > What? This is the exact opposite of what we're doing in several other > areas, with a large amount of success precisely because it allows us to > leverage developer base to catch and fix problems. Dropping in the code > and minor and obvious deviations make for easier re-sync. Several areas, but not spi-flash or spi. ie what I'm maintaining from long. I'm always looking for persistent code to be IN. May be it can't be syn-cable but we can work it more maintainable in u-boot way like other opensource project. Well this is my experience with the U-Boot project development so-far, I never ever hold any features but if u-boot need the same features, better to add then like new code. > > > - file names in u-boot should have _ other than few uclass drivers > > There is no consistent naming scheme really. I see ~1500 "_" C files > and ~500 "-" files. I have the same experience when I rename spi_flash.c with spi-flash.c. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 03/16] spi: Add non DM version of SPI_MEM
On Thu, Dec 13, 2018 at 04:40:30AM +0530, Jagan Teki wrote: > On Thu, Dec 13, 2018 at 2:55 AM Boris Brezillon > wrote: > > > > On Wed, 12 Dec 2018 22:07:44 +0100 > > Jagan Teki wrote: > > > > > On Wed 12 Dec, 2018, 10:02 PM Boris Brezillon > > wrote: > > > > > > > On Thu, 13 Dec 2018 02:15:16 +0530 > > > > Jagan Teki wrote: > > > > > > > > > On Thu, Dec 13, 2018 at 2:10 AM Boris Brezillon > > > > > wrote: > > > > > > > > > > > > Hi Jagan, > > > > > > > > > > > > On Thu, 13 Dec 2018 01:55:08 +0530 > > > > > > Jagan Teki wrote: > > > > > > > > > > > > > On Wed, Dec 12, 2018 at 11:08 PM Vignesh R > > > > wrote: > > > > > > > > > > > > > > > > Add non DM version of SPI_MEM to support easy migration to new > > > > > > > > SPI > > > > NOR > > > > > > > > framework. This can be removed once DM_SPI conversion is > > > > complete. > > > > > > > > > > > > > > Our intention to use new driver to follow dm, why we need to > > > > > > > support > > > > > > > non-dm? any usecases? > > > > > > > > > > > > Looks like we're having the same discussion over and over. Vignesh > > > > > > is > > > > > > dropping spi_flash.c which AFAICT was not depending on DM_SPI, so, > > > > > > if > > > > > > we want to keep everyone happy while getting rid of some legacy > > > > > > code, > > > > > > that's the only solution. DM conversion is a nice goal, but it's > > > > > > kind > > > > > > of orthogonal to what Vignesh is working on. If DM_SPI conversion > > > > > > happens before the spi-nor stuff is merged (which I doubt) then > > > > > > this > > > > > > patch can simply be dropped. > > > > > > > > > > spi_flash.c is a core code not a specific driver it belongs. spi-mem > > > > > is new feature driver how come new driver will support legacy non-dm > > > > > do we have legacy use for that(ie what I'm asking about usecase) > > > > > > > > I recommend that you read the spi-mem code carefully. spi-mem is not > > > > driver specific, it's a thin layer on top of spi and driver *can* (but > > > > are not forced to) provide optimized methods to execute spi-mem > > > > operations. When that's not the case, the implementation falls back to > > > > regular spi transfers. AFAIK, both DM and non-DM drivers support > > > > regular spi transfers, right? So why should we depend on DM_SPI? And > > > > more importantly, if we do that, that means we can't get rid of > > > > spi_flash.c since some users might still have non-DM SPI drivers, which > > > > in turn means we keep more legacy code for no good reasons. > > > > > > > > > > I understand spi-mem is core file, but new code too. > > > > Sorry, I don't get it. > > > > > > > > > > > > You want non-DM SPI controller drivers to go away, then remove them, > > > > instead of blocking other changes using this excuse. > > > > > > > > > > Please understand uboot development flow, legacy driver can be removed if > > > possible once migration expire and NEW drivers or code must be dm driven. > > > > Sorry, but I think you're the one misunderstanding what we are trying > > to do here. Vignesh changes have simply no impact on the DM SPI > > conversion you're aiming at. All Vignesh does is provide a dummy > > wrapper for non-DM drivers, which would probably have been implemented > > by Miquel if you had not been so insistent on your precious DM_SPI > > conversion. That was not really a problem for spi-nand, as we were > > I'm sure, I'm in right direction. > > This is what I asked in the first mail, > > "Our intention to use new driver to follow dm, why we need to support > non-dm? any usecases?" > > and I have the answer on this thread about the use case. > > I do really understand your intention about the real question. > - Any code or generic code will add in U-Boot should be driver-model > driven, are you agree this point? > Yes- thanks. > No - we need to have separate discussion. > > Any code that related to spi, or spi-flash should be driver-model > driven, ie what my AIM as a Maintainer (ie only reason for my spi-nor > changes resist for long time to fit). And since we have both been "stuck" for so very long and a clear commitment from a few people to follow through on the "and DM it after" part, I'm OK with bending the rules. -- 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 03/16] spi: Add non DM version of SPI_MEM
On Thu, Dec 13, 2018 at 2:55 AM Boris Brezillon wrote: > > On Wed, 12 Dec 2018 22:07:44 +0100 > Jagan Teki wrote: > > > On Wed 12 Dec, 2018, 10:02 PM Boris Brezillon > wrote: > > > > > On Thu, 13 Dec 2018 02:15:16 +0530 > > > Jagan Teki wrote: > > > > > > > On Thu, Dec 13, 2018 at 2:10 AM Boris Brezillon > > > > wrote: > > > > > > > > > > Hi Jagan, > > > > > > > > > > On Thu, 13 Dec 2018 01:55:08 +0530 > > > > > Jagan Teki wrote: > > > > > > > > > > > On Wed, Dec 12, 2018 at 11:08 PM Vignesh R > > > wrote: > > > > > > > > > > > > > > Add non DM version of SPI_MEM to support easy migration to new SPI > > > NOR > > > > > > > framework. This can be removed once DM_SPI conversion is > > > complete. > > > > > > > > > > > > Our intention to use new driver to follow dm, why we need to support > > > > > > non-dm? any usecases? > > > > > > > > > > Looks like we're having the same discussion over and over. Vignesh is > > > > > dropping spi_flash.c which AFAICT was not depending on DM_SPI, so, if > > > > > we want to keep everyone happy while getting rid of some legacy code, > > > > > that's the only solution. DM conversion is a nice goal, but it's kind > > > > > of orthogonal to what Vignesh is working on. If DM_SPI conversion > > > > > happens before the spi-nor stuff is merged (which I doubt) then this > > > > > patch can simply be dropped. > > > > > > > > spi_flash.c is a core code not a specific driver it belongs. spi-mem > > > > is new feature driver how come new driver will support legacy non-dm > > > > do we have legacy use for that(ie what I'm asking about usecase) > > > > > > I recommend that you read the spi-mem code carefully. spi-mem is not > > > driver specific, it's a thin layer on top of spi and driver *can* (but > > > are not forced to) provide optimized methods to execute spi-mem > > > operations. When that's not the case, the implementation falls back to > > > regular spi transfers. AFAIK, both DM and non-DM drivers support > > > regular spi transfers, right? So why should we depend on DM_SPI? And > > > more importantly, if we do that, that means we can't get rid of > > > spi_flash.c since some users might still have non-DM SPI drivers, which > > > in turn means we keep more legacy code for no good reasons. > > > > > > > I understand spi-mem is core file, but new code too. > > Sorry, I don't get it. > > > > > > > > You want non-DM SPI controller drivers to go away, then remove them, > > > instead of blocking other changes using this excuse. > > > > > > > Please understand uboot development flow, legacy driver can be removed if > > possible once migration expire and NEW drivers or code must be dm driven. > > Sorry, but I think you're the one misunderstanding what we are trying > to do here. Vignesh changes have simply no impact on the DM SPI > conversion you're aiming at. All Vignesh does is provide a dummy > wrapper for non-DM drivers, which would probably have been implemented > by Miquel if you had not been so insistent on your precious DM_SPI > conversion. That was not really a problem for spi-nand, as we were I'm sure, I'm in right direction. This is what I asked in the first mail, "Our intention to use new driver to follow dm, why we need to support non-dm? any usecases?" and I have the answer on this thread about the use case. I do really understand your intention about the real question. - Any code or generic code will add in U-Boot should be driver-model driven, are you agree this point? Yes- thanks. No - we need to have separate discussion. Any code that related to spi, or spi-flash should be driver-model driven, ie what my AIM as a Maintainer (ie only reason for my spi-nor changes resist for long time to fit). ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [GIT] Pull request: u-boot-dfu (13.12.2018)
Dear Marek, The following changes since commit 51b24944fdbfa760aa87a1ad812355e1df9c9355: usb: musb: Remove legacy CONFIG_USB_DA8XX (2018-12-12 15:23:04 +0100) are available in the git repository at: git://git.denx.de/u-boot-dfu.git for you to fetch changes up to 8a3755462f65c032528af70c6582abf89f91b2bc: configs: am335x_boneblack_vboot: enable DM_USB and RNDIS boot in SPl (2018-12-12 15:35:08 +0100) Jean-Jacques Hiblot (20): usb: dwc3-generic: make it compatible with "ti, keystone-dwc3" board: ks2_evm: Enable the USB clocks if DM_USB is used ARM: dts: k2g-evm: enable USB0 and USB1 PHY: Add phy driver for the keystone USB PHY usb: host: replace xhci-keystone driver by the generic dwc3 driver configs: k2g_evm: Enable DFU on K2G EVM spl: drivers: Link usb common library to SPL if USB gadget is enabled spl: net: dm: usb: bind the gadget before attempting to load the image phy: omap_usb2: Add support for am437x dwc3-generic: Add support for the am437x board: ti: am43xx: turn on USB clocks dts: Add a u-boot specific dtsi file for the am4372 dts: am4372: Enable USB1 in SPL configs: am43xx_evm: Enable DM_USB and DM_USB_GADGET configs: am43xx: Enable RNDIS support in SPL usb: musb-new: Allow the diver not to use the set_phy_power() callback usb: musb-new: Add support for DM_USB arm: am33xx: Register USB controllers if DM_USB is used but not OF_CONTROL configs: am335x_evm: Do not disable DM_USB in SPL configs: am335x_boneblack_vboot: enable DM_USB and RNDIS boot in SPl arch/arm/dts/am4372-generic-u-boot.dtsi | 2 + arch/arm/dts/am4372-u-boot.dtsi | 40 ++ arch/arm/dts/am437x-gp-evm-u-boot.dtsi | 2 + arch/arm/dts/am437x-idk-evm-u-boot.dtsi | 2 + arch/arm/dts/am437x-sk-evm-u-boot.dtsi | 2 + arch/arm/dts/keystone-k2g-evm.dts| 28 + arch/arm/dts/keystone-k2g.dtsi | 56 + arch/arm/include/asm/omap_musb.h | 8 arch/arm/mach-omap2/am33xx/board.c | 58 ++ board/ti/am43xx/board.c | 22 ++ board/ti/ks2_evm/board.c | 12 ++ common/Makefile | 3 ++ common/spl/spl_net.c | 4 +- configs/am335x_boneblack_vboot_defconfig | 10 + configs/am43xx_evm_defconfig | 19 + configs/k2e_evm_defconfig| 7 configs/k2e_hs_evm_defconfig | 7 configs/k2g_evm_defconfig| 12 ++ configs/k2g_hs_evm_defconfig | 12 ++ configs/k2hk_evm_defconfig | 7 configs/k2hk_hs_evm_defconfig| 7 configs/k2l_evm_defconfig| 7 configs/k2l_hs_evm_defconfig | 7 drivers/Makefile | 1 + drivers/phy/Kconfig | 10 + drivers/phy/Makefile | 1 + drivers/phy/keystone-usb-phy.c | 109 + drivers/phy/omap-usb2-phy.c | 45 +++- drivers/usb/dwc3/dwc3-generic.c | 2 + drivers/usb/host/Makefile| 1 - drivers/usb/host/xhci-keystone.c | 240 --- drivers/usb/musb-new/am35x.c | 8 ++-- drivers/usb/musb-new/musb_dsps.c | 8 ++-- drivers/usb/musb-new/musb_gadget.c | 11 + drivers/usb/musb-new/musb_uboot.c| 4 +- drivers/usb/musb-new/ti-musb.c | 181 +++- include/configs/am335x_evm.h | 1 - include/configs/ti_armv7_keystone2.h | 17 +--- 38 files changed, 649 insertions(+), 324 deletions(-) create mode 100644 arch/arm/dts/am4372-u-boot.dtsi create mode 100644 drivers/phy/keystone-usb-phy.c delete mode 100644 drivers/usb/host/xhci-keystone.c Travis-Ci: https://travis-ci.org/lmajewski/u-boot-dfu/builds/467026476 This is the last instalment of patches from Jean-Jacques 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 pgpdlXUH1LBwR.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 05/16] mtd: spi: Port SPI NOR framework from Linux
On Thu, Dec 13, 2018 at 02:01:15AM +0530, Jagan Teki wrote: > On Wed, Dec 12, 2018 at 11:10 PM Vignesh R wrote: > > > > Current U-Boot SPI NOR support (sf layer) is quite outdated as it does not > > support 4 byte addressing opcodes, SFDP table parsing and different types of > > quad mode enable sequences. Many newer flashes no longer support BANK > > registers used by sf layer to a access >16MB space. > > Also, many SPI controllers have special MMIO interfaces which provide > > accelerated read/write access but require knowledge of flash parameters > > to make use of it. Recent spi-mem layer provides a way to support such > > flashes but sf layer isn't using that. > > So sync SPI NOR framework from Linux v4.19 and add spi-mem support on top. > > in order to gain 4 byte addressing support, SFDP support and a way to > > support SPI controllers with MMIO flash interface. > > > > Signed-off-by: Vignesh R > > --- > > drivers/mtd/spi/spi-nor-core.c | 2647 > > include/linux/mtd/cfi.h| 32 + > > include/linux/mtd/spi-nor.h| 421 + > > Please refer many mails about this comment. I don't look for carbon > copy of the code from Linux, you can use the implementation and even > macro names etc but the end code would be the code that require > U-Boot. > > - no __UBOOT ifdef What? This is the exact opposite of what we're doing in several other areas, with a large amount of success precisely because it allows us to leverage developer base to catch and fix problems. Dropping in the code and minor and obvious deviations make for easier re-sync. > - file names in u-boot should have _ other than few uclass drivers There is no consistent naming scheme really. I see ~1500 "_" C files and ~500 "-" files. -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] Questions about the mmc_spi driver
I'm trying to get U-Boot working on the SiFive Freedom Unleased u540-c000 board, and I have been following the RISC-V work here with much excitement. I would like to have access to the SD card connected to the SPI bus for reading kernels, storing configs and scripts, etc. Unlike most ARM systems, which have a full SDIO port, the SD card is attached to an SPI bus in MMC mode. Looking around, I found drivers/mmc/mmc_spi.c which looks like it may do what I would like, but it's config entry is not exposed in the Kconfig files anywhere. Is this driver incomplete? I'm also unclear if just enabling it would have it work as a "disk" or if it just becomes another "character device". I did not find any docs, and the driver is 8 years old. Was this supposed to be removed and is an oversight? Any insights would be appreciated. Thanks! -Carl ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 03/16] spi: Add non DM version of SPI_MEM
On Thu, 13 Dec 2018 02:15:16 +0530 Jagan Teki wrote: > On Thu, Dec 13, 2018 at 2:10 AM Boris Brezillon > wrote: > > > > Hi Jagan, > > > > On Thu, 13 Dec 2018 01:55:08 +0530 > > Jagan Teki wrote: > > > > > On Wed, Dec 12, 2018 at 11:08 PM Vignesh R wrote: > > > > > > > > Add non DM version of SPI_MEM to support easy migration to new SPI NOR > > > > framework. This can be removed once DM_SPI conversion is complete. > > > > > > Our intention to use new driver to follow dm, why we need to support > > > non-dm? any usecases? > > > > Looks like we're having the same discussion over and over. Vignesh is > > dropping spi_flash.c which AFAICT was not depending on DM_SPI, so, if > > we want to keep everyone happy while getting rid of some legacy code, > > that's the only solution. DM conversion is a nice goal, but it's kind > > of orthogonal to what Vignesh is working on. If DM_SPI conversion > > happens before the spi-nor stuff is merged (which I doubt) then this > > patch can simply be dropped. > > spi_flash.c is a core code not a specific driver it belongs. spi-mem > is new feature driver how come new driver will support legacy non-dm > do we have legacy use for that(ie what I'm asking about usecase) I recommend that you read the spi-mem code carefully. spi-mem is not driver specific, it's a thin layer on top of spi and driver *can* (but are not forced to) provide optimized methods to execute spi-mem operations. When that's not the case, the implementation falls back to regular spi transfers. AFAIK, both DM and non-DM drivers support regular spi transfers, right? So why should we depend on DM_SPI? And more importantly, if we do that, that means we can't get rid of spi_flash.c since some users might still have non-DM SPI drivers, which in turn means we keep more legacy code for no good reasons. You want non-DM SPI controller drivers to go away, then remove them, instead of blocking other changes using this excuse. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] qemu x86 ide device not probing automatically with 2018.11
Hello,
I've been using u-boot as the boot loader for x86 qemu and some custom
(e.g. non-default) boot commands. I recently upgraded from u-boot
2018.01 to 2018.11 and now my boot command fails because it doesn't
look like u-boot is loading the driver for the ide device from which
I'm attempting to load files.
For reference, I'm basically building the qemu-x86 config only with
changes to the default boot scripts. Namely, I have:
#define CONFIG_BOOTCOMMAND \
"ide dev ${bootpart}; " \
"if run loadbootenv; then " \
"run importbootenv; " \
"fi; " \
"run doboot; "
The failure appears to occur when the script attempts to run "ide dev
${bootpart}", claiming the ide device doesn't exist. If I manually run
the command "ide reset", and then "bootd" everything works fine, so I
think this is being caused by the switch to using the device model for
ide(?). I suspect this means that I need to make some changes to my
boot command to get it to probe the ide driver, but I wanted to make
sure I'm doing that the correct way. Should I simply add a "ide reset"
as the first line of CONFIG_BOOTCOMMAND, or is there a more "correct"
way to get u-boot to probe the driver?
Thanks,
--
Joshua Watt
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [BeagleBone Black] Possible bug in U-Boot efi loader for BeagleBone Black
Hello, I think that I have found a bug in U-Boot UEFI implementation for BeagleBone Black board. I have tested U-Boot UEFI implementation for BeagleBone Black. I am able to load Linux successfully via GRUB bootloader with U-Boot v2018.09-rc2 . U-Boot v2018.09-rc3 and above versions cause that the platform restarts over and over again. It starts booting, then it loads GRUB and when GRUB finishes its work an error occurs and the board restarts. I have looked through U-Boot repository and I have found the commit, which breaks booting. It's name is as follows: "efi_loader: update runtime services table crc32" (commit ID: a39f39cdd8be5cd3e7a8b696a463b621e3d827e0 ) . I have figured out, that when I comment out function call: efi_update_table_header_crc32(_runtime_services.hdr); in function efi_runtime_detach then I am able to launch Linux successfully. My setup of U-Boot, GRUB and Linux was as follows: https://github.com/DominikAdamski/Beaglebone_GRUB_Manual . For U-Boot v2018.09 I get following log when booting: U-Boot 2018.09 (Dec 11 2018 - 11:11:16 +0100) CPU : AM335X-GP rev 2.1 Model: TI AM335x BeagleBone Black DRAM: 512 MiB NAND: 0 MiB MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1 Loading Environment from FAT... *** Warning - bad CRC, using default environment No USB device found not set. Validating first E-fuse MAC Net: eth0: ethernet@4a10 Hit any key to stop autoboot: 2 ^H^H^H 1 ^H^H^H 0 switch to partitions #0, OK mmc0 is current device SD/MMC found on device 0 ** Unable to read file boot.scr ** 85 bytes read in 1 ms (83 KiB/s) Loaded env from uEnv.txt Importing environment from mmc0 ... Running uenvcmd ... 403968 bytes read in 28 ms (13.8 MiB/s) ^[[18tScanning disks on usb... Disk usb0 not ready Disk usb1 not ready Disk usb2 not ready Disk usb3 not ready Scanning disks on mmc... MMC Device 2 not found MMC Device 3 not found Found 4 disks WARNING: booting without device tree ## Starting EFI application at 8200 ... ^[[?25h^[[0;30;47mWelcome to GRUB! ^M ^M^[[0;37;40m^[[0;37;40m^[[0;37;40mEFI stub: Booting Linux Kernel...^M EFI stub: Using DTB from configuration table^M EFI stub: Exiting boot services and installing virtual address map...^M U-Boot EFI: Relocation at 9ff4a8a8 is out of range (2008214f) data abort pc : [<9ff4a7cc>] lr : [<9ff4a8b9>] reloc pc : [<808007cc>] lr : [<808008b9>] sp : 9df1ebac ip : 0020 fp : r10: 1000 r9 : 9df29eb8 r8 : 0028 r7 : 9ff4aa10 r6 : 9ff4aec4 r5 : 0003 r4 : 9ff4aa70 r3 : 2002aac0 r2 : 0050 r1 : 9ff4aa70 r0 : Flags: NzCv IRQs off FIQs on Mode SVC_32 Code: 61204621 f876f000 bd106120 b5f04b36 (b31c681c) UEFI image [0x9ceb1000:0x9cf139ff] '/\grub.efi' UEFI image [0x94728000:0x9510bfff] Resetting CPU ... resetting ... Please let me know, if I should add more detailed logs. Dominik Adamski ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 03/16] spi: Add non DM version of SPI_MEM
On Wed, 12 Dec 2018 22:07:44 +0100 Jagan Teki wrote: > On Wed 12 Dec, 2018, 10:02 PM Boris Brezillon wrote: > > > On Thu, 13 Dec 2018 02:15:16 +0530 > > Jagan Teki wrote: > > > > > On Thu, Dec 13, 2018 at 2:10 AM Boris Brezillon > > > wrote: > > > > > > > > Hi Jagan, > > > > > > > > On Thu, 13 Dec 2018 01:55:08 +0530 > > > > Jagan Teki wrote: > > > > > > > > > On Wed, Dec 12, 2018 at 11:08 PM Vignesh R > > wrote: > > > > > > > > > > > > Add non DM version of SPI_MEM to support easy migration to new SPI > > NOR > > > > > > framework. This can be removed once DM_SPI conversion is > > complete. > > > > > > > > > > Our intention to use new driver to follow dm, why we need to support > > > > > non-dm? any usecases? > > > > > > > > Looks like we're having the same discussion over and over. Vignesh is > > > > dropping spi_flash.c which AFAICT was not depending on DM_SPI, so, if > > > > we want to keep everyone happy while getting rid of some legacy code, > > > > that's the only solution. DM conversion is a nice goal, but it's kind > > > > of orthogonal to what Vignesh is working on. If DM_SPI conversion > > > > happens before the spi-nor stuff is merged (which I doubt) then this > > > > patch can simply be dropped. > > > > > > spi_flash.c is a core code not a specific driver it belongs. spi-mem > > > is new feature driver how come new driver will support legacy non-dm > > > do we have legacy use for that(ie what I'm asking about usecase) > > > > I recommend that you read the spi-mem code carefully. spi-mem is not > > driver specific, it's a thin layer on top of spi and driver *can* (but > > are not forced to) provide optimized methods to execute spi-mem > > operations. When that's not the case, the implementation falls back to > > regular spi transfers. AFAIK, both DM and non-DM drivers support > > regular spi transfers, right? So why should we depend on DM_SPI? And > > more importantly, if we do that, that means we can't get rid of > > spi_flash.c since some users might still have non-DM SPI drivers, which > > in turn means we keep more legacy code for no good reasons. > > > > I understand spi-mem is core file, but new code too. Sorry, I don't get it. > > > > You want non-DM SPI controller drivers to go away, then remove them, > > instead of blocking other changes using this excuse. > > > > Please understand uboot development flow, legacy driver can be removed if > possible once migration expire and NEW drivers or code must be dm driven. Sorry, but I think you're the one misunderstanding what we are trying to do here. Vignesh changes have simply no impact on the DM SPI conversion you're aiming at. All Vignesh does is provide a dummy wrapper for non-DM drivers, which would probably have been implemented by Miquel if you had not been so insistent on your precious DM_SPI conversion. That was not really a problem for spi-nand, as we were adding support for a new feature. This is not the case here. SPI NORs are already partially supported by the u-boot spi flash layer, and we need to keep things in a working state for those that were using it and didn't have their SPI controller drivers converted to the DM. This leaves us 2 options: 1/ keep the sf_flash code as is and add a new spi-nor code base 2/ replace spi_flash code by the spi-nor layer imported from Linux Vignesh chose option #2 which has the benefit of avoiding code duplication. Given the discussion we're having right now, I'm wondering if it wouldn't be easier to go for option #1 in order to avoid those endless discussions... ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 03/16] spi: Add non DM version of SPI_MEM
Hi Jagan, On Thu, 13 Dec 2018 01:55:08 +0530 Jagan Teki wrote: > On Wed, Dec 12, 2018 at 11:08 PM Vignesh R wrote: > > > > Add non DM version of SPI_MEM to support easy migration to new SPI NOR > > framework. This can be removed once DM_SPI conversion is complete. > > Our intention to use new driver to follow dm, why we need to support > non-dm? any usecases? Looks like we're having the same discussion over and over. Vignesh is dropping spi_flash.c which AFAICT was not depending on DM_SPI, so, if we want to keep everyone happy while getting rid of some legacy code, that's the only solution. DM conversion is a nice goal, but it's kind of orthogonal to what Vignesh is working on. If DM_SPI conversion happens before the spi-nor stuff is merged (which I doubt) then this patch can simply be dropped. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 10/16] configs: Get rid of SPI_FLASH_BAR
On Thu, 13 Dec 2018 02:11:48 +0530 Jagan Teki wrote: > On Wed, Dec 12, 2018 at 11:15 PM Vignesh R wrote: > > > > Now that we have new SPI NOR framework in place that supports 4 byte > > addressing mode by default, get rid of CONFIG_SPI_FLASH_BAR > > I already mentioned in previous mail, BAR is not exact replacement for > 4-byte. Some controllers do handle > 16MB flashes even-though > controller support 3-byte addressing. we have these board since from > 2014. That's something you should be able to detect with spi_mem_supports_op(). If the controller does not support sending 4 byte addresses, it should return -ENOTSUPP and the framework should fallback to BAR setting (if the NOR supports it). Do we really need a config option for that? ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 09/16] sf_mtd: Simply mtd operations
On Wed, 12 Dec 2018 23:02:21 +0530
Vignesh R wrote:
> @@ -39,13 +37,12 @@ static int spi_flash_mtd_erase(struct mtd_info *mtd,
> struct erase_info *instr)
> static int spi_flash_mtd_read(struct mtd_info *mtd, loff_t from, size_t len,
> size_t *retlen, u_char *buf)
> {
> - struct spi_flash *flash = mtd->priv;
> int err;
>
> - if (!flash)
> + if (!mtd || !mtd->priv)
> return -ENODEV;
>
> - err = spi_flash_read(flash, from, len, buf);
> + err = mtd->_read(mtd, from, len, retlen, buf);
Please use the wrappers instead of calling those hooks directly.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] mtd: Get rid of board_mtdparts_default()
On Wed, 12 Dec 2018 12:37:04 +0100
Ladislav Michl wrote:
> Now problem is that IGEPv2 comes with quite many configurations, some of
> them are even customized, so static configuration is a show stopper
> mainly as I do not know what devices are in field.
> Another issue is how ubispl code works: It expects struct ubispl_info
> filled with (among others) peb_offset of ubi partition. ubispl code counts
> in terms of eraseblocks regardless of their size. So we would need to touch
> this number when using static mtdparts.
Okay.
>
> > > Hence runtime detection. That code could be used
> > > on all OMAP3 boards as BootROM reads up to first four sectors searching
> > > for SPL (MLO).
> >
> > Note that, for the nand side of things, you can also automate that using
> > a u-boot script:
> >
> > nand info; setexpr splsize ${nand_erasesize} * 4; setenv mtdparts
> > mtdparts=omap2-nand:0x${splsize}(SPL),-(UBI)
>
> That seems as a way to go!
Glad you like this idea.
>
> > Shouldn't be hard to patch the onenand cmd to also expose writesize,
> > erasesize and oobsize.
>
> Side note: I never fully understand why is OneNAND using separate set of
> commands.
Hehe. That's exactly what Miquel tries to address with the mtd command
(one command to rule them all).
>
> Could you hold merging your paches until I implement above idea and test
> it on a few boards? I know u-boot is now using two months merge window,
> which is unfortunate, so I'll try to do it as soon as possible, but I do
> not think I'll finish it till end of week.
No worries. This is not urgent and can definitely wait 2019.04.
Thanks,
Boris
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2] armv8: ls2080ardb: enable eSDHC pin mux support
On 11/22/18 1:06 AM, Yinbo Zhu wrote: > CONFIG_FSL_ESDHC_PIN_MUX should be enabled for ls2080ardb > whose eSDHC has pin mux with DSPI. This config makes sure > esdhc dts node would be fixed with disabled status if > DSPI is used, in case of any mmc issue in linux. Also, > esdhc should be added in default hwconfig since eSDHC is > used in default. > > Signed-off-by: Yinbo Zhu > --- > Change in v2: > Update the commit information. > > include/configs/ls2080ardb.h |5 +++-- > 1 files changed, 3 insertions(+), 2 deletions(-) > > diff --git a/include/configs/ls2080ardb.h b/include/configs/ls2080ardb.h > index f6aa4ed..d2e80a8 100644 > --- a/include/configs/ls2080ardb.h > +++ b/include/configs/ls2080ardb.h > @@ -331,6 +331,7 @@ unsigned long get_board_sys_clk(void); > /* MMC */ > #ifdef CONFIG_MMC > #define CONFIG_SYS_FSL_MMC_HAS_CAPBLT_VS33 > +#define CONFIG_FSL_ESDHC_PIN_MUX > #endif > Please consider to detect pin mux at run time. We are moving to TFA boot flow. York ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v1] LS2080ardb: MMC: disable esdhc for dspi
On 11/22/18 12:23 AM, Yinbo Zhu wrote: > esdhc and dspi have Multiplexed pins, if dspi is enabled > and esdhc need to be disabled, This patch is to disable > esdhc when rcw config dspi enabled. > > Signed-off-by: Yinbo Zhu > --- > include/configs/ls2080ardb.h |5 +++-- > 1 files changed, 3 insertions(+), 2 deletions(-) > > diff --git a/include/configs/ls2080ardb.h b/include/configs/ls2080ardb.h > index f6aa4ed..d2e80a8 100644 > --- a/include/configs/ls2080ardb.h > +++ b/include/configs/ls2080ardb.h > @@ -331,6 +331,7 @@ unsigned long get_board_sys_clk(void); > /* MMC */ > #ifdef CONFIG_MMC > #define CONFIG_SYS_FSL_MMC_HAS_CAPBLT_VS33 > +#define CONFIG_FSL_ESDHC_PIN_MUX > #endif > We are moving to TFA boot flow. Please consider to detect the pin mux at runtime. York ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] armv8: Secure Boot: Modify boot_a_script definition
On 11/8/18 9:23 PM, Vinitha V Pillai wrote: > boot_script_hdr does not exist, it should not continue to > boot. So adding separate validation after loading boot_script If boot_script_hdr doesn't exist, the "load" command will fail. Why do you expect "esbc_validate" command to run without loading script header? York ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 03/16] spi: Add non DM version of SPI_MEM
On Wed 12 Dec, 2018, 10:02 PM Boris Brezillon On Thu, 13 Dec 2018 02:15:16 +0530 > Jagan Teki wrote: > > > On Thu, Dec 13, 2018 at 2:10 AM Boris Brezillon > > wrote: > > > > > > Hi Jagan, > > > > > > On Thu, 13 Dec 2018 01:55:08 +0530 > > > Jagan Teki wrote: > > > > > > > On Wed, Dec 12, 2018 at 11:08 PM Vignesh R > wrote: > > > > > > > > > > Add non DM version of SPI_MEM to support easy migration to new SPI > NOR > > > > > framework. This can be removed once DM_SPI conversion is > complete. > > > > > > > > Our intention to use new driver to follow dm, why we need to support > > > > non-dm? any usecases? > > > > > > Looks like we're having the same discussion over and over. Vignesh is > > > dropping spi_flash.c which AFAICT was not depending on DM_SPI, so, if > > > we want to keep everyone happy while getting rid of some legacy code, > > > that's the only solution. DM conversion is a nice goal, but it's kind > > > of orthogonal to what Vignesh is working on. If DM_SPI conversion > > > happens before the spi-nor stuff is merged (which I doubt) then this > > > patch can simply be dropped. > > > > spi_flash.c is a core code not a specific driver it belongs. spi-mem > > is new feature driver how come new driver will support legacy non-dm > > do we have legacy use for that(ie what I'm asking about usecase) > > I recommend that you read the spi-mem code carefully. spi-mem is not > driver specific, it's a thin layer on top of spi and driver *can* (but > are not forced to) provide optimized methods to execute spi-mem > operations. When that's not the case, the implementation falls back to > regular spi transfers. AFAIK, both DM and non-DM drivers support > regular spi transfers, right? So why should we depend on DM_SPI? And > more importantly, if we do that, that means we can't get rid of > spi_flash.c since some users might still have non-DM SPI drivers, which > in turn means we keep more legacy code for no good reasons. > I understand spi-mem is core file, but new code too. > You want non-DM SPI controller drivers to go away, then remove them, > instead of blocking other changes using this excuse. > Please understand uboot development flow, legacy driver can be removed if possible once migration expire and NEW drivers or code must be dm driven. > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 16/16] MAINTAINERS: Add an entry for SPI NOR
On Wed, Dec 12, 2018 at 11:19 PM Vignesh R wrote: > > Add myself as co-maintainer for U-Boot SPI NOR subsystem > > Signed-off-by: Vignesh R > --- > Jagan, > > If you agree, I can help in co-maintaining SPI NOR part especially for > the code that is added/sync'd from Linux. Thanks for the help and support. > > MAINTAINERS | 8 > 1 file changed, 8 insertions(+) > > diff --git a/MAINTAINERS b/MAINTAINERS > index 0cec39c542db..d09e0a478f52 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -634,6 +634,14 @@ F: drivers/mtd/spi/ > F: drivers/spi/ > F: include/spi* > > +SPI-NOR You missed my name :) > +M: Vignesh R > +S: Maintained > +F: drivers/mtd/spi/ > +F: include/spi_flash.h > +F: include/linux/mtd/cfi.h > +F: include/linux/mtd/spi-nor.h ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 10/16] configs: Get rid of SPI_FLASH_BAR
Am Mi., 12. Dez. 2018, 21:42 hat Jagan Teki geschrieben: > On Wed, Dec 12, 2018 at 11:15 PM Vignesh R wrote: > > > > Now that we have new SPI NOR framework in place that supports 4 byte > > addressing mode by default, get rid of CONFIG_SPI_FLASH_BAR > > I already mentioned in previous mail, BAR is not exact replacement for > 4-byte. Some controllers do handle > 16MB flashes even-though > controller support 3-byte addressing. we have these board since from > 2014. > > Better to make changes in accordance with that. While BAR is one possibility to address > 16 MiB, I think it's about the worst solution. So it's ok for boards that support no other methods, but how do we ensure it's only used for those and not the default? Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] changing of fastboot index
Hi Jean-Jacques,
After commit aec0081093e7 ("configs: am57xx_evm: Enable DM_USB and
DM_USB_DEV") I noticed that "fastboot 1" command doesn't work anymore
on BeagleBoard X15. Instead, "fastboot 0" works.
I can see that this happens because in dwc3_glue_bind() we only
register usb@488d as OTG controller ("dwc3-generic-peripheral"),
and usb@4889 is registered as HOST controller ("xhci-dwc3"). This
leads for dwc3_glue_probe() to be only called once (for OTG
controller), so now we only have registered controller with index = 0,
when we are calling usb_gadget_initialize() from do_fastboot_usb().
The reason why I'm bringing this up is that we still have
CONFIG_FASTBOOT_USB_DEV=1 for AM57x-based boards, and "fastboot
reboot-bootloader" won't work, and all documentation needs to be
changed.
In "help fastboot" output it only says that must be
passed. Do we actually understand which controller is referred here?
Frankly, I never thought about this before. Is it OTG controller
number, or USB controller number? As I understand it, it should be USB
controller index, so on X15 it actually should be "fastboot 1". But I
can be mistaken :) Is this an intended behavior or should we fix it?
If so, can you please help me here?
Thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 11/16] configs: Remove SF_DUAL_FLASH
On Wed, Dec 12, 2018 at 11:19 PM Vignesh R wrote: > > SF_DUAL_FLASH claims to enable support for SF_DUAL_STACKED_FLASH and > SF_DUAL_PARALLEL_FLASH. But, in current U-Boot code, grepping for above > enums yield no user and therefore support seems to be incomplete. Remove > these configs so as to avoid confusion. > > Signed-off-by: Vignesh R > --- > configs/topic_miamilite_defconfig | 1 - > configs/topic_miamiplus_defconfig | 1 - > configs/xilinx_zynqmp_mini_qspi_defconfig | 1 - > configs/xilinx_zynqmp_zc1232_revA_defconfig | 1 - > configs/xilinx_zynqmp_zc1254_revA_defconfig | 1 - > configs/xilinx_zynqmp_zc1275_revA_defconfig | 1 - > configs/xilinx_zynqmp_zc1275_revB_defconfig | 1 - > configs/xilinx_zynqmp_zcu104_revA_defconfig | 1 - > configs/xilinx_zynqmp_zcu104_revC_defconfig | 1 - > configs/xilinx_zynqmp_zcu106_revA_defconfig | 1 - > doc/SPI/README.dual-flash | 92 - > drivers/mtd/spi/Kconfig | 6 -- > include/configs/socfpga_stratix10_socdk.h | 1 - > 13 files changed, 109 deletions(-) > delete mode 100644 doc/SPI/README.dual-flash dual flash has used boards, even though spi driver can't enable it. I asked Siva, and(Michal) about the updates. we have some drivers and code in tree even-thought the relevant users out-of tree. Siva., Michal any inputs? ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 03/16] spi: Add non DM version of SPI_MEM
On Thu, Dec 13, 2018 at 2:10 AM Boris Brezillon wrote: > > Hi Jagan, > > On Thu, 13 Dec 2018 01:55:08 +0530 > Jagan Teki wrote: > > > On Wed, Dec 12, 2018 at 11:08 PM Vignesh R wrote: > > > > > > Add non DM version of SPI_MEM to support easy migration to new SPI NOR > > > framework. This can be removed once DM_SPI conversion is complete. > > > > Our intention to use new driver to follow dm, why we need to support > > non-dm? any usecases? > > Looks like we're having the same discussion over and over. Vignesh is > dropping spi_flash.c which AFAICT was not depending on DM_SPI, so, if > we want to keep everyone happy while getting rid of some legacy code, > that's the only solution. DM conversion is a nice goal, but it's kind > of orthogonal to what Vignesh is working on. If DM_SPI conversion > happens before the spi-nor stuff is merged (which I doubt) then this > patch can simply be dropped. spi_flash.c is a core code not a specific driver it belongs. spi-mem is new feature driver how come new driver will support legacy non-dm do we have legacy use for that(ie what I'm asking about usecase) ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 0/6] Add support for MIPS Creator CI20
Am 12.12.18 um 19:03 schrieb Ezequiel Garcia: > Hi Daniel, > > On Wed, 2018-12-12 at 18:27 +0100, Daniel Schwierzeck wrote: >> Hi Ezequiel, >> >> Am 12.12.18 um 14:58 schrieb Ezequiel Garcia: >>> A new round. >>> >>> For this new round: >>> >>> * Replaced infinite while loop with wait_for_bit. >>> * Added a MAINTAINERS file. If anyone wants to co-maintain this, >>>please let me know. >>> >>> This is based on top of yesterday's master (ee168783ae8) and has >>> been tested by SD-card booting both U-Boot and Linux. Booting >>> Linux via TFTP was also tested. >>> >>> Toolchain used to test: >>> >>> $ mips-linux-gcc -v >>> Using built-in specs. >>> COLLECT_GCC=mips-linux-gcc >>> COLLECT_LTO_WRAPPER=/home/zeta/.buildman-toolchains/gcc-7.3.0-nolibc/mips-linux/bin/../libexec/gcc/mips-linux/7.3.0/lto-wrapper >>> Target: mips-linux >>> Configured with: /home/arnd/git/gcc/configure --target=mips-linux >>> --enable-targets=all --prefix=/opt/crosstool/gcc-7.3.0-nolibc/mips-linux -- >>> enable-languages=c --without-headers --disable-bootstrap --disable-nls >>> --disable-threads --disable-shared --disable-libmudflap --disable-libssp -- >>> disable-libgomp --disable-decimal-float --disable-libquadmath >>> --disable-libatomic --disable-libcc1 --disable-libmpx >>> --enable-checking=release >>> Thread model: single >>> gcc version 7.3.0 (GCC) >>> >>> SPL size: >>> >>> $ size spl/u-boot-spl >>>textdata bss dec hex filename >>>9252 752 736 1074029f4 spl/u-boot-spl >>> >>> I've pushed a branch to >>> https://github.com/ezequielgarcia/u-boot/tree/ci20-v2 >>> and made sure travis passed. >>> >> >> Thanks for working on this but the problem with the original patch >> series was that it was not fully driver model compatible and that stuff >> like watchdog, reset and pin-muxing was open-coded instead of using the >> proper frameworks. As the ship is sailing towards having only driver >> model and device tree in U-Boot proper, it doesn't make sense to accept >> new SoC/boards with legacy code especially if there is no active >> maintainer who would do the conversion work. And with the upcoming dead >> lines for DM conversions, boards with legacy code will be removed when >> not converted. This is also one of the reasons why the Ingenic SoC >> support we already had in mainline was removed. And readding parts of >> the removed code doesn't make sense either because the patch series is >> based on that old Ingenic SoC code. >> > > I have to say I disagree with all of this. > > The open coded drivers are used in SPL, which most likely can't affort > any DM. Or **if** it can't afford it, it's a separate question that > needs research. > > The BootROM for this SoC can only load 14 KiB of code, and we are already > at roughly 11 KiB. I know that and I don't demand DM in SPL, only for U-Boot proper. And there is always a ways of factoring out driver code which can be shared by SPL and a DM compatible driver. > > This series, on the other side, is quite clean, quite small, has quite > simple drivers (with even a DM MMC driver for the second stage)... > ... and most importantly it works. > > Given how much history this particular series has, if we delay it now > with yet more requirements, we risk not ever having it. There are no more requirements, only the standard ones which blocked the merge of the original series in the first place. If someone is willing to work these out in the review process, the series will get merged. ? > > We want to put this board on kernelCI labs, and having upstream U-Boot > would be really nice for that, so we don't rely on ancient vendor forks. > > As for a maintainer doing the work, I'm here and not going anywhere. > I can do any follow-up work that's considered needed, including any DM > conversions. > > But, it would be really important to have a working starting point. > >> I wanted to work on Marek's patch series to fix those issues because >> it's quite some work which I couldn't expect from Marek ;) >> But I got stuck with EJTAG because halting the CPU didn't work. Then I >> hadn't time anymore. >> >> I'm little busy right now so I can't do a detailed review. But the >> issues which should be addressed at first are: >> >> - fix all SPDX license identifiers >> - convert GPIO driver to DM >> - add a DM watchdog driver >> - implement machine reset with the generic watchdog reset (see BMIPS for >> an example) >> - don't use SoC specific start.S and u-boot-spl.lds, the generic code is >> now configurable enough and non-generic things could be done in a >> lowlevel_init.S >> - reduce the hundreds of definitions of register addresses to the ones >> really needed in assembly or SPL. This stuff should come from device tree >> - define the remaining register base addresses as physical addresses and >> establish a mapping with ioremap_nocache() >> >> > > This really sounds that work that can be done as follow-up patches. > And, we don't know
Re: [U-Boot] [PATCH 10/16] configs: Get rid of SPI_FLASH_BAR
On Wed, Dec 12, 2018 at 11:15 PM Vignesh R wrote: > > Now that we have new SPI NOR framework in place that supports 4 byte > addressing mode by default, get rid of CONFIG_SPI_FLASH_BAR I already mentioned in previous mail, BAR is not exact replacement for 4-byte. Some controllers do handle > 16MB flashes even-though controller support 3-byte addressing. we have these board since from 2014. Better to make changes in accordance with that. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 07/16] mtd: spi: Remove unused files
On Wed, Dec 12, 2018 at 11:12 PM Vignesh R wrote: > > spi_flash and spi_flash_ids are no longer needed after SPI NOR > migration. Remove them. > > Signed-off-by: Vignesh R > --- > drivers/mtd/spi/spi_flash.c | 1337 --- > drivers/mtd/spi/spi_flash_ids.c | 211 - Better to keep this by renaming and other licesnes, ie what I did before. It's good for maintaining ids separately instead of having in one big spi-nor file. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 05/16] mtd: spi: Port SPI NOR framework from Linux
On Wed, Dec 12, 2018 at 11:10 PM Vignesh R wrote: > > Current U-Boot SPI NOR support (sf layer) is quite outdated as it does not > support 4 byte addressing opcodes, SFDP table parsing and different types of > quad mode enable sequences. Many newer flashes no longer support BANK > registers used by sf layer to a access >16MB space. > Also, many SPI controllers have special MMIO interfaces which provide > accelerated read/write access but require knowledge of flash parameters > to make use of it. Recent spi-mem layer provides a way to support such > flashes but sf layer isn't using that. > So sync SPI NOR framework from Linux v4.19 and add spi-mem support on top. > in order to gain 4 byte addressing support, SFDP support and a way to > support SPI controllers with MMIO flash interface. > > Signed-off-by: Vignesh R > --- > drivers/mtd/spi/spi-nor-core.c | 2647 > include/linux/mtd/cfi.h| 32 + > include/linux/mtd/spi-nor.h| 421 + Please refer many mails about this comment. I don't look for carbon copy of the code from Linux, you can use the implementation and even macro names etc but the end code would be the code that require U-Boot. - no __UBOOT ifdef - file names in u-boot should have _ other than few uclass drivers ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 03/16] spi: Add non DM version of SPI_MEM
On Wed, Dec 12, 2018 at 11:08 PM Vignesh R wrote: > > Add non DM version of SPI_MEM to support easy migration to new SPI NOR > framework. This can be removed once DM_SPI conversion is complete. Our intention to use new driver to follow dm, why we need to support non-dm? any usecases? ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 0/6] Add support for MIPS Creator CI20
On Wed, Dec 12, 2018 at 03:03:40PM -0300, Ezequiel Garcia wrote: > Hi Daniel, > > On Wed, 2018-12-12 at 18:27 +0100, Daniel Schwierzeck wrote: > > Hi Ezequiel, > > > > Am 12.12.18 um 14:58 schrieb Ezequiel Garcia: > > > A new round. > > > > > > For this new round: > > > > > > * Replaced infinite while loop with wait_for_bit. > > > * Added a MAINTAINERS file. If anyone wants to co-maintain this, > > >please let me know. > > > > > > This is based on top of yesterday's master (ee168783ae8) and has > > > been tested by SD-card booting both U-Boot and Linux. Booting > > > Linux via TFTP was also tested. > > > > > > Toolchain used to test: > > > > > > $ mips-linux-gcc -v > > > Using built-in specs. > > > COLLECT_GCC=mips-linux-gcc > > > COLLECT_LTO_WRAPPER=/home/zeta/.buildman-toolchains/gcc-7.3.0-nolibc/mips-linux/bin/../libexec/gcc/mips-linux/7.3.0/lto-wrapper > > > Target: mips-linux > > > Configured with: /home/arnd/git/gcc/configure --target=mips-linux > > > --enable-targets=all --prefix=/opt/crosstool/gcc-7.3.0-nolibc/mips-linux > > > -- > > > enable-languages=c --without-headers --disable-bootstrap --disable-nls > > > --disable-threads --disable-shared --disable-libmudflap --disable-libssp > > > -- > > > disable-libgomp --disable-decimal-float --disable-libquadmath > > > --disable-libatomic --disable-libcc1 --disable-libmpx > > > --enable-checking=release > > > Thread model: single > > > gcc version 7.3.0 (GCC) > > > > > > SPL size: > > > > > > $ size spl/u-boot-spl > > >text data bss dec hex filename > > >9252 752 736 1074029f4 spl/u-boot-spl > > > > > > I've pushed a branch to > > > https://github.com/ezequielgarcia/u-boot/tree/ci20-v2 > > > and made sure travis passed. > > > > > > > Thanks for working on this but the problem with the original patch > > series was that it was not fully driver model compatible and that stuff > > like watchdog, reset and pin-muxing was open-coded instead of using the > > proper frameworks. As the ship is sailing towards having only driver > > model and device tree in U-Boot proper, it doesn't make sense to accept > > new SoC/boards with legacy code especially if there is no active > > maintainer who would do the conversion work. And with the upcoming dead > > lines for DM conversions, boards with legacy code will be removed when > > not converted. This is also one of the reasons why the Ingenic SoC > > support we already had in mainline was removed. And readding parts of > > the removed code doesn't make sense either because the patch series is > > based on that old Ingenic SoC code. > > > > I have to say I disagree with all of this. > > The open coded drivers are used in SPL, which most likely can't affort > any DM. Or **if** it can't afford it, it's a separate question that > needs research. And this is a topic that keeps coming up, so I need to chime in again. For SPL, we _have_to_ keep in mind the various boot ROM hard space limits. This means that we end up needing to allow for some level of open-coded drivers used in limited cases like SPL and then a full / real driver in full U-Boot. -- 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 6/7] env: Read default speed and mode values from DT
On Mon, Dec 10, 2018 at 4:23 PM Patrick Delaunay wrote: > > In case of DT boot, don't read default speed and mode for SPI from > CONFIG_*, instead read from DT node. > > Signed-off-by: Patrick Delaunay > --- > > env/Kconfig | 4 ++-- > env/sf.c| 5 - > 2 files changed, 6 insertions(+), 3 deletions(-) > > diff --git a/env/Kconfig b/env/Kconfig > index 9011109..0f760ce 100644 > --- a/env/Kconfig > +++ b/env/Kconfig > @@ -329,11 +329,11 @@ config ENV_IS_IN_SPI_FLASH > > Define the SPI bus and chip select. If not defined they will be 0. > > - - CONFIG_ENV_SPI_MAX_HZ (optional): > + - CONFIG_ENV_SPI_MAX_HZ (optional if !DM_SPI_FLASH): > > Define the SPI max work clock. If not defined then use 1MHz. > > - - CONFIG_ENV_SPI_MODE (optional): > + - CONFIG_ENV_SPI_MODE (optional if !DM_SPI_FLASH): > > Define the SPI work mode. If not defined then use SPI_MODE_3. > > diff --git a/env/sf.c b/env/sf.c > index 2e3c600..edd36f1 100644 > --- a/env/sf.c > +++ b/env/sf.c > @@ -24,12 +24,15 @@ > #ifndef CONFIG_ENV_SPI_CS > # define CONFIG_ENV_SPI_CS CONFIG_SF_DEFAULT_CS > #endif > + > +#ifndef CONFIG_DM_SPI_FLASH > #ifndef CONFIG_ENV_SPI_MAX_HZ > # define CONFIG_ENV_SPI_MAX_HZ CONFIG_SF_DEFAULT_SPEED > #endif > #ifndef CONFIG_ENV_SPI_MODE > # define CONFIG_ENV_SPI_MODE CONFIG_SF_DEFAULT_MODE > #endif > +#endif Please try trim it for better, adding ifdef on top ifdef look, not good. see my comment on 1/7 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 3/7] da850evm: sf: Read default speed and mode values from DT
+ Adam On Mon, Dec 10, 2018 at 4:23 PM Patrick Delaunay wrote: > > In case of DT boot, don't read default speed and mode for SPI from > CONFIG_*, instead read from DT node. > > Signed-off-by: Patrick Delaunay > --- > > board/davinci/da8xxevm/da850evm.c | 7 +++ > 1 file changed, 7 insertions(+) > > diff --git a/board/davinci/da8xxevm/da850evm.c > b/board/davinci/da8xxevm/da850evm.c > index b0b29b3..4ef454e 100644 > --- a/board/davinci/da8xxevm/da850evm.c > +++ b/board/davinci/da8xxevm/da850evm.c > @@ -44,8 +44,15 @@ DECLARE_GLOBAL_DATA_PTR; > > #define CFG_MAC_ADDR_SPI_BUS 0 > #define CFG_MAC_ADDR_SPI_CS0 > + > +#ifdef CONFIG_DM_SPI_FLASH > +/* In DM mode, speed and mode value will be taken from DT */ > +#define CFG_MAC_ADDR_SPI_MAX_HZ0 > +#define CFG_MAC_ADDR_SPI_MODE 0 > +#else > #define CFG_MAC_ADDR_SPI_MAX_HZCONFIG_SF_DEFAULT_SPEED > #define CFG_MAC_ADDR_SPI_MODE SPI_MODE_3 > +#endif This board support DM_SPI_FLASH even in for SPL, so there is no need of non-dm if here. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/7] spi: update management of default speed and mode
On Mon, Dec 10, 2018 at 4:23 PM Patrick Delaunay
wrote:
>
> The 2 default values for SPI mode and speed are
> only if CONFIG_DM_SPI_FLASH is not defined
> - CONFIG_SF_DEFAULT_SPEED
> - CONFIG_SF_DEFAULT_MODE
>
> Inverse the logic of the test to remove these two defines.
>
> Signed-off-by: Patrick Delaunay
> ---
>
> cmd/sf.c | 10 ++
> common/spl/spl_spi.c | 11 ++-
> common/splash_source.c | 11 ++-
> 3 files changed, 18 insertions(+), 14 deletions(-)
>
> diff --git a/cmd/sf.c b/cmd/sf.c
> index 84bb057..cfea545 100644
> --- a/cmd/sf.c
> +++ b/cmd/sf.c
> @@ -81,16 +81,18 @@ static int do_spi_flash_probe(int argc, char * const
> argv[])
> {
> unsigned int bus = CONFIG_SF_DEFAULT_BUS;
> unsigned int cs = CONFIG_SF_DEFAULT_CS;
> - unsigned int speed = CONFIG_SF_DEFAULT_SPEED;
> - unsigned int mode = CONFIG_SF_DEFAULT_MODE;
> + /* In DM mode, defaults will be taken from DT */
> + unsigned int speed = 0;
> + unsigned int mode = 0;
> char *endp;
> #ifdef CONFIG_DM_SPI_FLASH
> struct udevice *new, *bus_dev;
> int ret;
> - /* In DM mode defaults will be taken from DT */
> - speed = 0, mode = 0;
> #else
> struct spi_flash *new;
> +
> + speed = CONFIG_SF_DEFAULT_SPEED;
> + mode = CONFIG_SF_DEFAULT_MODE;
Better define globally with in spi includes or some common include
instead of making ifdef changes all over.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [BeagleBone Black] Possible bug in U-Boot efi loader for BeagleBone Black
On 12/12/18 3:02 PM, Dominik Adamski wrote: > Hello, > I think that I have found a bug in U-Boot UEFI implementation for > BeagleBone Black board. > > I have tested U-Boot UEFI implementation for BeagleBone Black. I am able > to load Linux successfully via GRUB bootloader with U-Boot v2018.09-rc2 > . U-Boot v2018.09-rc3 and above versions cause that the platform > restarts over and over again. It starts booting, then it loads GRUB and > when GRUB finishes its work an error occurs and the board restarts. > > I have looked through U-Boot repository and I have found the commit, > which breaks booting. It's name is as follows: "efi_loader: update > runtime services table crc32" (commit ID: > a39f39cdd8be5cd3e7a8b696a463b621e3d827e0 ) . I have figured out, that > when I comment out function call: > efi_update_table_header_crc32(_runtime_services.hdr); in function > efi_runtime_detach then I am able to launch Linux successfully. > > My setup of U-Boot, GRUB and Linux was as follows: > https://github.com/DominikAdamski/Beaglebone_GRUB_Manual . For U-Boot > v2018.09 I get following log when booting: > > U-Boot 2018.09 (Dec 11 2018 - 11:11:16 +0100) > > CPU : AM335X-GP rev 2.1 > Model: TI AM335x BeagleBone Black > DRAM: 512 MiB > NAND: 0 MiB > MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1 > Loading Environment from FAT... *** Warning - bad CRC, using default > environment > > No USB device found > not set. Validating first E-fuse MAC > Net: eth0: ethernet@4a10 > Hit any key to stop autoboot: 2 ^H^H^H 1 ^H^H^H 0 > switch to partitions #0, OK > mmc0 is current device > SD/MMC found on device 0 > ** Unable to read file boot.scr ** > 85 bytes read in 1 ms (83 KiB/s) > Loaded env from uEnv.txt > Importing environment from mmc0 ... > Running uenvcmd ... > 403968 bytes read in 28 ms (13.8 MiB/s) > ^[[18tScanning disks on usb... > Disk usb0 not ready > Disk usb1 not ready > Disk usb2 not ready > Disk usb3 not ready > Scanning disks on mmc... > MMC Device 2 not found > MMC Device 3 not found > Found 4 disks > WARNING: booting without device tree > ## Starting EFI application at 8200 ... > ^[[?25h^[[0;30;47mWelcome to GRUB! > ^M > ^M^[[0;37;40m^[[0;37;40m^[[0;37;40mEFI stub: Booting Linux Kernel...^M > EFI stub: Using DTB from configuration table^M > EFI stub: Exiting boot services and installing virtual address map...^M > U-Boot EFI: Relocation at 9ff4a8a8 is out of range (2008214f) > data abort > pc : [<9ff4a7cc>] lr : [<9ff4a8b9>] > reloc pc : [<808007cc>] lr : [<808008b9>] > sp : 9df1ebac ip : 0020 fp : > r10: 1000 r9 : 9df29eb8 r8 : 0028 > r7 : 9ff4aa10 r6 : 9ff4aec4 r5 : 0003 r4 : 9ff4aa70 > r3 : 2002aac0 r2 : 0050 r1 : 9ff4aa70 r0 : > Flags: NzCv IRQs off FIQs on Mode SVC_32 > Code: 61204621 f876f000 bd106120 b5f04b36 (b31c681c) > UEFI image [0x9ceb1000:0x9cf139ff] '/\grub.efi' > UEFI image [0x94728000:0x9510bfff] > Resetting CPU ... > > resetting ... > > Please let me know, if I should add more detailed logs. > > Dominik Adamski > > Hello Dominik, you refer to an outdated release candidate v2018.09-rc2. The following patch is missing in the release candidate: commit 483dbab9f9318149e5ea97daacbfae320f53e35a Author: Heinrich Schuchardt Date: Sun Jul 29 09:49:03 2018 +0200 lib: crc32: mark function crc32() as __efi_runtime It is contained in the v2018.09 release. Please, update your page https://github.com/DominikAdamski/Beaglebone_GRUB_Manual accordingly. The latest release is v2018.11. Release v2018.11 will require a recent GRUB (later than patch d0c070179d4d). Or apply the following patch http://git.denx.de/?p=u-boot.git;a=commit;h=f31239acff61f7def88a06eef1f091fce74ecd61 Revert "efi_loader: remove efi_exit_caches()" Best regards Heinrich ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 0/6] Add support for MIPS Creator CI20
Hi Daniel, On Wed, 2018-12-12 at 18:27 +0100, Daniel Schwierzeck wrote: > Hi Ezequiel, > > Am 12.12.18 um 14:58 schrieb Ezequiel Garcia: > > A new round. > > > > For this new round: > > > > * Replaced infinite while loop with wait_for_bit. > > * Added a MAINTAINERS file. If anyone wants to co-maintain this, > >please let me know. > > > > This is based on top of yesterday's master (ee168783ae8) and has > > been tested by SD-card booting both U-Boot and Linux. Booting > > Linux via TFTP was also tested. > > > > Toolchain used to test: > > > > $ mips-linux-gcc -v > > Using built-in specs. > > COLLECT_GCC=mips-linux-gcc > > COLLECT_LTO_WRAPPER=/home/zeta/.buildman-toolchains/gcc-7.3.0-nolibc/mips-linux/bin/../libexec/gcc/mips-linux/7.3.0/lto-wrapper > > Target: mips-linux > > Configured with: /home/arnd/git/gcc/configure --target=mips-linux > > --enable-targets=all --prefix=/opt/crosstool/gcc-7.3.0-nolibc/mips-linux -- > > enable-languages=c --without-headers --disable-bootstrap --disable-nls > > --disable-threads --disable-shared --disable-libmudflap --disable-libssp -- > > disable-libgomp --disable-decimal-float --disable-libquadmath > > --disable-libatomic --disable-libcc1 --disable-libmpx > > --enable-checking=release > > Thread model: single > > gcc version 7.3.0 (GCC) > > > > SPL size: > > > > $ size spl/u-boot-spl > >textdata bss dec hex filename > >9252 752 736 1074029f4 spl/u-boot-spl > > > > I've pushed a branch to > > https://github.com/ezequielgarcia/u-boot/tree/ci20-v2 > > and made sure travis passed. > > > > Thanks for working on this but the problem with the original patch > series was that it was not fully driver model compatible and that stuff > like watchdog, reset and pin-muxing was open-coded instead of using the > proper frameworks. As the ship is sailing towards having only driver > model and device tree in U-Boot proper, it doesn't make sense to accept > new SoC/boards with legacy code especially if there is no active > maintainer who would do the conversion work. And with the upcoming dead > lines for DM conversions, boards with legacy code will be removed when > not converted. This is also one of the reasons why the Ingenic SoC > support we already had in mainline was removed. And readding parts of > the removed code doesn't make sense either because the patch series is > based on that old Ingenic SoC code. > I have to say I disagree with all of this. The open coded drivers are used in SPL, which most likely can't affort any DM. Or **if** it can't afford it, it's a separate question that needs research. The BootROM for this SoC can only load 14 KiB of code, and we are already at roughly 11 KiB. This series, on the other side, is quite clean, quite small, has quite simple drivers (with even a DM MMC driver for the second stage)... ... and most importantly it works. Given how much history this particular series has, if we delay it now with yet more requirements, we risk not ever having it. We want to put this board on kernelCI labs, and having upstream U-Boot would be really nice for that, so we don't rely on ancient vendor forks. As for a maintainer doing the work, I'm here and not going anywhere. I can do any follow-up work that's considered needed, including any DM conversions. But, it would be really important to have a working starting point. > I wanted to work on Marek's patch series to fix those issues because > it's quite some work which I couldn't expect from Marek ;) > But I got stuck with EJTAG because halting the CPU didn't work. Then I > hadn't time anymore. > > I'm little busy right now so I can't do a detailed review. But the > issues which should be addressed at first are: > > - fix all SPDX license identifiers > - convert GPIO driver to DM > - add a DM watchdog driver > - implement machine reset with the generic watchdog reset (see BMIPS for > an example) > - don't use SoC specific start.S and u-boot-spl.lds, the generic code is > now configurable enough and non-generic things could be done in a > lowlevel_init.S > - reduce the hundreds of definitions of register addresses to the ones > really needed in assembly or SPL. This stuff should come from device tree > - define the remaining register base addresses as physical addresses and > establish a mapping with ioremap_nocache() > > This really sounds that work that can be done as follow-up patches. And, we don't know if any of this will bloat the SPL beyond the current limit :-) I must admit, I have a hard time understanding this blocker policy, for a series that gives support to a new board, and affects no other platforms. Thanks, Ezequiel ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [RESEND PATCH 1/1] avb: add support for named persistent values
AVB version 1.1 introduces support for named persistent values
that must be tamper evident and allows AVB to store arbitrary key-value
pairs [1].
Introduce implementation of two additional AVB operations
read_persistent_value()/write_persistent_value() for retrieving/storing
named persistent values.
Correspondent pull request in the OP-TEE OS project repo [2].
[1]: https://android.googlesource.com/platform/external/avb/+/android-9.0.0_r22
[2]: https://github.com/OP-TEE/optee_os/pull/2699
Signed-off-by: Igor Opaniuk
---
cmd/avb.c | 78 +
common/avb_verify.c| 122 +
include/tee.h | 2 +
include/tee/optee_ta_avb.h | 16 ++
4 files changed, 218 insertions(+)
diff --git a/cmd/avb.c b/cmd/avb.c
index ff00be4..1df13a2 100644
--- a/cmd/avb.c
+++ b/cmd/avb.c
@@ -340,6 +340,76 @@ int do_avb_is_unlocked(cmd_tbl_t *cmdtp, int flag,
return CMD_RET_FAILURE;
}
+int do_avb_read_pvalue(cmd_tbl_t *cmdtp, int flag, int argc,
+ char * const argv[])
+{
+ const char *name;
+ size_t bytes;
+ size_t bytes_read;
+ void *buffer;
+
+ if (!avb_ops) {
+ printf("AVB 2.0 is not initialized, run 'avb init' first\n");
+ return CMD_RET_FAILURE;
+ }
+
+ if (argc != 3)
+ return CMD_RET_USAGE;
+
+ name = argv[1];
+ bytes = simple_strtoul(argv[2], NULL, 16);
+ buffer = malloc(bytes);
+ if (!buffer)
+ return CMD_RET_FAILURE;
+
+ printf("Reading persistent value, name = %s, bytes = %zu\n",
+ name, bytes);
+ if (avb_ops->read_persistent_value(avb_ops, name, bytes, buffer,
+ _read) == AVB_IO_RESULT_OK) {
+ printf("Read %zu bytes, value = %s\n", bytes_read,
+ (char *)buffer);
+ free(buffer);
+ return CMD_RET_SUCCESS;
+ }
+
+ printf("Failed to write in partition\n");
+
+ free(buffer);
+
+ return CMD_RET_FAILURE;
+}
+
+int do_avb_write_pvalue(cmd_tbl_t *cmdtp, int flag, int argc,
+ char * const argv[])
+{
+ const char *name;
+ const char *value;
+
+ if (!avb_ops) {
+ printf("AVB 2.0 is not initialized, run 'avb init' first\n");
+ return CMD_RET_FAILURE;
+ }
+
+ if (argc != 3)
+ return CMD_RET_USAGE;
+
+ name = argv[1];
+ value = argv[2];
+
+ printf("Writing persistent value, name = %s, value = %s\n",
+ name, value);
+ if (avb_ops->write_persistent_value(avb_ops, name, strlen(value) + 1,
+ (const uint8_t *)value) ==
+ AVB_IO_RESULT_OK) {
+ printf("Wrote %zu bytes\n", strlen(value) + 1);
+ return CMD_RET_SUCCESS;
+ }
+
+ printf("Failed to write persistent value\n");
+
+ return CMD_RET_FAILURE;
+}
+
static cmd_tbl_t cmd_avb[] = {
U_BOOT_CMD_MKENT(init, 2, 0, do_avb_init, "", ""),
U_BOOT_CMD_MKENT(read_rb, 2, 0, do_avb_read_rb, "", ""),
@@ -350,6 +420,10 @@ static cmd_tbl_t cmd_avb[] = {
U_BOOT_CMD_MKENT(read_part_hex, 4, 0, do_avb_read_part_hex, "", ""),
U_BOOT_CMD_MKENT(write_part, 5, 0, do_avb_write_part, "", ""),
U_BOOT_CMD_MKENT(verify, 1, 0, do_avb_verify_part, "", ""),
+#ifdef CONFIG_OPTEE_TA_AVB
+ U_BOOT_CMD_MKENT(read_pvalue, 3, 0, do_avb_read_pvalue, "", ""),
+ U_BOOT_CMD_MKENT(write_pvalue, 3, 0, do_avb_write_pvalue, "", ""),
+#endif
};
static int do_avb(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
@@ -384,6 +458,10 @@ U_BOOT_CMD(
"partition and print to stdout\n"
"avb write_part - write bytes
to\n"
" by using data from \n"
+#ifdef CONFIG_OPTEE_TA_AVB
+ "avb read_pvalue - read a persistent value \n"
+ "avb write_pvalue - write a persistent value \n"
+#endif
"avb verify - run verification process using hash data\n"
"from vbmeta structure\n"
);
diff --git a/common/avb_verify.c b/common/avb_verify.c
index a8c5a3e..c92e73c 100644
--- a/common/avb_verify.c
+++ b/common/avb_verify.c
@@ -647,6 +647,10 @@ static AvbIOResult invoke_func(struct AvbOpsData
*ops_data, u32 func,
return AVB_IO_RESULT_OK;
case TEE_ERROR_OUT_OF_MEMORY:
return AVB_IO_RESULT_ERROR_OOM;
+ case TEE_ERROR_STORAGE_NO_SPACE:
+ return AVB_IO_RESULT_ERROR_INSUFFICIENT_SPACE;
+ case TEE_ERROR_ITEM_NOT_FOUND:
+ return AVB_IO_RESULT_ERROR_NO_SUCH_VALUE;
case TEE_ERROR_TARGET_DEAD:
/*
* The TA has paniced, close the session to reload the TA
@@ -847,6 +851,120 @@ static AvbIOResult get_size_of_partition(AvbOps *ops,
return AVB_IO_RESULT_OK;
}
+static
[U-Boot] [PATCH 1/1] avb2.0: add support for named persistent values
AVB 1.1 introduces support for named persistent values which must be
tamper evident and allows AVB to store arbitrary key-value pairs [1].
Introduce two additional Avb operations read_persistent_value()/
write_persistent_value() for retrieving/storing names persistent values.
Correspondent pull request in the OP-TEE OS project repo [2].
[1]: https://android.googlesource.com/platform/external/avb/+/android-9.0.0_r22
[2]: https://github.com/OP-TEE/optee_os/pull/2699
Signed-off-by: Igor Opaniuk
---
cmd/avb.c | 78 +
common/avb_verify.c| 122 +
include/tee.h | 2 +
include/tee/optee_ta_avb.h | 16 ++
4 files changed, 218 insertions(+)
diff --git a/cmd/avb.c b/cmd/avb.c
index ff00be4..1df13a2 100644
--- a/cmd/avb.c
+++ b/cmd/avb.c
@@ -340,6 +340,76 @@ int do_avb_is_unlocked(cmd_tbl_t *cmdtp, int flag,
return CMD_RET_FAILURE;
}
+int do_avb_read_pvalue(cmd_tbl_t *cmdtp, int flag, int argc,
+ char * const argv[])
+{
+ const char *name;
+ size_t bytes;
+ size_t bytes_read;
+ void *buffer;
+
+ if (!avb_ops) {
+ printf("AVB 2.0 is not initialized, run 'avb init' first\n");
+ return CMD_RET_FAILURE;
+ }
+
+ if (argc != 3)
+ return CMD_RET_USAGE;
+
+ name = argv[1];
+ bytes = simple_strtoul(argv[2], NULL, 16);
+ buffer = malloc(bytes);
+ if (!buffer)
+ return CMD_RET_FAILURE;
+
+ printf("Reading persistent value, name = %s, bytes = %zu\n",
+ name, bytes);
+ if (avb_ops->read_persistent_value(avb_ops, name, bytes, buffer,
+ _read) == AVB_IO_RESULT_OK) {
+ printf("Read %zu bytes, value = %s\n", bytes_read,
+ (char *)buffer);
+ free(buffer);
+ return CMD_RET_SUCCESS;
+ }
+
+ printf("Failed to write in partition\n");
+
+ free(buffer);
+
+ return CMD_RET_FAILURE;
+}
+
+int do_avb_write_pvalue(cmd_tbl_t *cmdtp, int flag, int argc,
+ char * const argv[])
+{
+ const char *name;
+ const char *value;
+
+ if (!avb_ops) {
+ printf("AVB 2.0 is not initialized, run 'avb init' first\n");
+ return CMD_RET_FAILURE;
+ }
+
+ if (argc != 3)
+ return CMD_RET_USAGE;
+
+ name = argv[1];
+ value = argv[2];
+
+ printf("Writing persistent value, name = %s, value = %s\n",
+ name, value);
+ if (avb_ops->write_persistent_value(avb_ops, name, strlen(value) + 1,
+ (const uint8_t *)value) ==
+ AVB_IO_RESULT_OK) {
+ printf("Wrote %zu bytes\n", strlen(value) + 1);
+ return CMD_RET_SUCCESS;
+ }
+
+ printf("Failed to write persistent value\n");
+
+ return CMD_RET_FAILURE;
+}
+
static cmd_tbl_t cmd_avb[] = {
U_BOOT_CMD_MKENT(init, 2, 0, do_avb_init, "", ""),
U_BOOT_CMD_MKENT(read_rb, 2, 0, do_avb_read_rb, "", ""),
@@ -350,6 +420,10 @@ static cmd_tbl_t cmd_avb[] = {
U_BOOT_CMD_MKENT(read_part_hex, 4, 0, do_avb_read_part_hex, "", ""),
U_BOOT_CMD_MKENT(write_part, 5, 0, do_avb_write_part, "", ""),
U_BOOT_CMD_MKENT(verify, 1, 0, do_avb_verify_part, "", ""),
+#ifdef CONFIG_OPTEE_TA_AVB
+ U_BOOT_CMD_MKENT(read_pvalue, 3, 0, do_avb_read_pvalue, "", ""),
+ U_BOOT_CMD_MKENT(write_pvalue, 3, 0, do_avb_write_pvalue, "", ""),
+#endif
};
static int do_avb(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
@@ -384,6 +458,10 @@ U_BOOT_CMD(
"partition and print to stdout\n"
"avb write_part - write bytes
to\n"
" by using data from \n"
+#ifdef CONFIG_OPTEE_TA_AVB
+ "avb read_pvalue - read a persistent value \n"
+ "avb write_pvalue - write a persistent value \n"
+#endif
"avb verify - run verification process using hash data\n"
"from vbmeta structure\n"
);
diff --git a/common/avb_verify.c b/common/avb_verify.c
index a8c5a3e..c92e73c 100644
--- a/common/avb_verify.c
+++ b/common/avb_verify.c
@@ -647,6 +647,10 @@ static AvbIOResult invoke_func(struct AvbOpsData
*ops_data, u32 func,
return AVB_IO_RESULT_OK;
case TEE_ERROR_OUT_OF_MEMORY:
return AVB_IO_RESULT_ERROR_OOM;
+ case TEE_ERROR_STORAGE_NO_SPACE:
+ return AVB_IO_RESULT_ERROR_INSUFFICIENT_SPACE;
+ case TEE_ERROR_ITEM_NOT_FOUND:
+ return AVB_IO_RESULT_ERROR_NO_SUCH_VALUE;
case TEE_ERROR_TARGET_DEAD:
/*
* The TA has paniced, close the session to reload the TA
@@ -847,6 +851,120 @@ static AvbIOResult get_size_of_partition(AvbOps *ops,
return AVB_IO_RESULT_OK;
}
+static AvbIOResult
[U-Boot] [PATCH 16/16] MAINTAINERS: Add an entry for SPI NOR
Add myself as co-maintainer for U-Boot SPI NOR subsystem Signed-off-by: Vignesh R --- Jagan, If you agree, I can help in co-maintaining SPI NOR part especially for the code that is added/sync'd from Linux. MAINTAINERS | 8 1 file changed, 8 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 0cec39c542db..d09e0a478f52 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -634,6 +634,14 @@ F: drivers/mtd/spi/ F: drivers/spi/ F: include/spi* +SPI-NOR +M: Vignesh R +S: Maintained +F: drivers/mtd/spi/ +F: include/spi_flash.h +F: include/linux/mtd/cfi.h +F: include/linux/mtd/spi-nor.h + SPMI M: Mateusz Kulikowski S: Maintained -- 2.19.2 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 11/16] configs: Remove SF_DUAL_FLASH
SF_DUAL_FLASH claims to enable support for SF_DUAL_STACKED_FLASH and SF_DUAL_PARALLEL_FLASH. But, in current U-Boot code, grepping for above enums yield no user and therefore support seems to be incomplete. Remove these configs so as to avoid confusion. Signed-off-by: Vignesh R --- configs/topic_miamilite_defconfig | 1 - configs/topic_miamiplus_defconfig | 1 - configs/xilinx_zynqmp_mini_qspi_defconfig | 1 - configs/xilinx_zynqmp_zc1232_revA_defconfig | 1 - configs/xilinx_zynqmp_zc1254_revA_defconfig | 1 - configs/xilinx_zynqmp_zc1275_revA_defconfig | 1 - configs/xilinx_zynqmp_zc1275_revB_defconfig | 1 - configs/xilinx_zynqmp_zcu104_revA_defconfig | 1 - configs/xilinx_zynqmp_zcu104_revC_defconfig | 1 - configs/xilinx_zynqmp_zcu106_revA_defconfig | 1 - doc/SPI/README.dual-flash | 92 - drivers/mtd/spi/Kconfig | 6 -- include/configs/socfpga_stratix10_socdk.h | 1 - 13 files changed, 109 deletions(-) delete mode 100644 doc/SPI/README.dual-flash diff --git a/configs/topic_miamilite_defconfig b/configs/topic_miamilite_defconfig index fe27239c94bf..8e912d8586d2 100644 --- a/configs/topic_miamilite_defconfig +++ b/configs/topic_miamilite_defconfig @@ -40,7 +40,6 @@ CONFIG_ZYNQ_I2C1=y CONFIG_MMC_SDHCI=y CONFIG_MMC_SDHCI_ZYNQ=y CONFIG_SPI_FLASH=y -CONFIG_SF_DUAL_FLASH=y CONFIG_SPI_FLASH_STMICRO=y # CONFIG_SPI_FLASH_USE_4K_SECTORS is not set CONFIG_DEBUG_UART_ZYNQ=y diff --git a/configs/topic_miamiplus_defconfig b/configs/topic_miamiplus_defconfig index 4b7ff3ae1815..371b2ad91571 100644 --- a/configs/topic_miamiplus_defconfig +++ b/configs/topic_miamiplus_defconfig @@ -39,7 +39,6 @@ CONFIG_ZYNQ_I2C1=y CONFIG_MMC_SDHCI=y CONFIG_MMC_SDHCI_ZYNQ=y CONFIG_SPI_FLASH=y -CONFIG_SF_DUAL_FLASH=y CONFIG_SPI_FLASH_STMICRO=y # CONFIG_SPI_FLASH_USE_4K_SECTORS is not set # CONFIG_NETDEVICES is not set diff --git a/configs/xilinx_zynqmp_mini_qspi_defconfig b/configs/xilinx_zynqmp_mini_qspi_defconfig index e6e024a8098e..9f2a2f59f6ea 100644 --- a/configs/xilinx_zynqmp_mini_qspi_defconfig +++ b/configs/xilinx_zynqmp_mini_qspi_defconfig @@ -55,7 +55,6 @@ CONFIG_SPL_DM_SEQ_ALIAS=y # CONFIG_MMC is not set CONFIG_DM_SPI_FLASH=y CONFIG_SPI_FLASH=y -CONFIG_SF_DUAL_FLASH=y CONFIG_SPI_FLASH_MACRONIX=y CONFIG_SPI_FLASH_SPANSION=y CONFIG_SPI_FLASH_STMICRO=y diff --git a/configs/xilinx_zynqmp_zc1232_revA_defconfig b/configs/xilinx_zynqmp_zc1232_revA_defconfig index 1e8529098f74..06247a0628fb 100644 --- a/configs/xilinx_zynqmp_zc1232_revA_defconfig +++ b/configs/xilinx_zynqmp_zc1232_revA_defconfig @@ -37,7 +37,6 @@ CONFIG_FPGA_ZYNQMPPL=y CONFIG_MISC=y CONFIG_DM_MMC=y CONFIG_SPI_FLASH=y -CONFIG_SF_DUAL_FLASH=y CONFIG_SPI_FLASH_MACRONIX=y CONFIG_SPI_FLASH_SPANSION=y CONFIG_SPI_FLASH_STMICRO=y diff --git a/configs/xilinx_zynqmp_zc1254_revA_defconfig b/configs/xilinx_zynqmp_zc1254_revA_defconfig index f883f8ecc692..5bc1aaba696b 100644 --- a/configs/xilinx_zynqmp_zc1254_revA_defconfig +++ b/configs/xilinx_zynqmp_zc1254_revA_defconfig @@ -37,7 +37,6 @@ CONFIG_FPGA_ZYNQMPPL=y CONFIG_MISC=y CONFIG_DM_MMC=y CONFIG_SPI_FLASH=y -CONFIG_SF_DUAL_FLASH=y CONFIG_SPI_FLASH_MACRONIX=y CONFIG_SPI_FLASH_SPANSION=y CONFIG_SPI_FLASH_STMICRO=y diff --git a/configs/xilinx_zynqmp_zc1275_revA_defconfig b/configs/xilinx_zynqmp_zc1275_revA_defconfig index 2aa71b3fbc1c..d0b0a19caf93 100644 --- a/configs/xilinx_zynqmp_zc1275_revA_defconfig +++ b/configs/xilinx_zynqmp_zc1275_revA_defconfig @@ -37,7 +37,6 @@ CONFIG_FPGA_ZYNQMPPL=y CONFIG_MISC=y CONFIG_DM_MMC=y CONFIG_SPI_FLASH=y -CONFIG_SF_DUAL_FLASH=y CONFIG_SPI_FLASH_MACRONIX=y CONFIG_SPI_FLASH_SPANSION=y CONFIG_SPI_FLASH_STMICRO=y diff --git a/configs/xilinx_zynqmp_zc1275_revB_defconfig b/configs/xilinx_zynqmp_zc1275_revB_defconfig index debb23739bfd..6bc3b6af9a67 100644 --- a/configs/xilinx_zynqmp_zc1275_revB_defconfig +++ b/configs/xilinx_zynqmp_zc1275_revB_defconfig @@ -40,7 +40,6 @@ CONFIG_DM_MMC=y CONFIG_MMC_SDHCI=y CONFIG_MMC_SDHCI_ZYNQ=y CONFIG_SPI_FLASH=y -CONFIG_SF_DUAL_FLASH=y CONFIG_SPI_FLASH_MACRONIX=y CONFIG_SPI_FLASH_SPANSION=y CONFIG_SPI_FLASH_STMICRO=y diff --git a/configs/xilinx_zynqmp_zcu104_revA_defconfig b/configs/xilinx_zynqmp_zcu104_revA_defconfig index 4a24d5d9cfe0..28e18ae1252e 100644 --- a/configs/xilinx_zynqmp_zcu104_revA_defconfig +++ b/configs/xilinx_zynqmp_zcu104_revA_defconfig @@ -57,7 +57,6 @@ CONFIG_DM_MMC=y CONFIG_MMC_SDHCI=y CONFIG_MMC_SDHCI_ZYNQ=y CONFIG_SPI_FLASH=y -CONFIG_SF_DUAL_FLASH=y CONFIG_SPI_FLASH_MACRONIX=y CONFIG_SPI_FLASH_SPANSION=y CONFIG_SPI_FLASH_STMICRO=y diff --git a/configs/xilinx_zynqmp_zcu104_revC_defconfig b/configs/xilinx_zynqmp_zcu104_revC_defconfig index a3f4c7f36614..3ddd63181603 100644 --- a/configs/xilinx_zynqmp_zcu104_revC_defconfig +++ b/configs/xilinx_zynqmp_zcu104_revC_defconfig @@ -58,7 +58,6 @@ CONFIG_DM_MMC=y CONFIG_MMC_SDHCI=y CONFIG_MMC_SDHCI_ZYNQ=y CONFIG_SPI_FLASH=y
[U-Boot] [PATCH 15/16] turris_omnia_defconfig: Enable tiny printf
Enable tiny printf to reduce SPL size Signed-off-by: Vignesh R --- configs/turris_omnia_defconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configs/turris_omnia_defconfig b/configs/turris_omnia_defconfig index 38c5de18bb2d..4655d6561a13 100644 --- a/configs/turris_omnia_defconfig +++ b/configs/turris_omnia_defconfig @@ -52,6 +52,6 @@ CONFIG_KIRKWOOD_SPI=y CONFIG_USB=y CONFIG_DM_USB=y CONFIG_USB_EHCI_HCD=y -CONFIG_USB_STORAGE=y CONFIG_WDT=y CONFIG_WDT_ORION=y +CONFIG_USE_TINY_PRINTF=y -- 2.19.2 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 13/16] taurus_defconfig: Enable simple malloc in SPL
Enable SPL simple malloc to reduce SPL size Signed-off-by: Vignesh R --- configs/taurus_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/configs/taurus_defconfig b/configs/taurus_defconfig index e53e075d4825..9c3a1276aa8f 100644 --- a/configs/taurus_defconfig +++ b/configs/taurus_defconfig @@ -64,3 +64,4 @@ CONFIG_USE_TINY_PRINTF=y CONFIG_WDT=y CONFIG_WDT_AT91=y CONFIG_AT91_HW_WDT_TIMEOUT=y +CONFIG_SPL_SYS_MALLOC_SIMPLE=y -- 2.19.2 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 12/16] axm_defconfig: Enable simple malloc in SPL
Enable CONFIG_SPL_SYS_MALLOC_SIMPLE in SPL to reduce SPL size Signed-off-by: Vignesh R --- configs/axm_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/configs/axm_defconfig b/configs/axm_defconfig index 89d6b6f2012c..16c093b37b83 100644 --- a/configs/axm_defconfig +++ b/configs/axm_defconfig @@ -44,3 +44,4 @@ CONFIG_SPI_FLASH=y CONFIG_SPI_FLASH_STMICRO=y CONFIG_PHYLIB=y CONFIG_USE_TINY_PRINTF=y +CONFIG_SPL_SYS_MALLOC_SIMPLE=y -- 2.19.2 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 14/16] da850_am18xxevm: Enable tiny printf
Enable tiny printf to reduce SPL size Signed-off-by: Vignesh R --- configs/da850_am18xxevm_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/configs/da850_am18xxevm_defconfig b/configs/da850_am18xxevm_defconfig index 58745fec8267..5fecfccba50c 100644 --- a/configs/da850_am18xxevm_defconfig +++ b/configs/da850_am18xxevm_defconfig @@ -57,3 +57,4 @@ CONFIG_SPI=y CONFIG_DM_SPI=y CONFIG_DAVINCI_SPI=y # CONFIG_FAT_WRITE is not set +CONFIG_USE_TINY_PRINTF=y -- 2.19.2 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 10/16] configs: Get rid of SPI_FLASH_BAR
Now that we have new SPI NOR framework in place that supports 4 byte addressing mode by default, get rid of CONFIG_SPI_FLASH_BAR Signed-off-by: Vignesh R --- arch/arm/mach-omap2/am33xx/Kconfig | 1 - configs/alt_defconfig| 1 - configs/am57xx_evm_defconfig | 1 - configs/am57xx_hs_evm_defconfig | 1 - configs/ap121_defconfig | 1 - configs/ap143_defconfig | 1 - configs/avnet_ultra96_rev1_defconfig | 1 - configs/axs101_defconfig | 1 - configs/axs103_defconfig | 1 - configs/bg0900_defconfig | 1 - configs/blanche_defconfig| 1 - configs/cl-som-am57x_defconfig | 1 - configs/clearfog_defconfig | 1 - configs/cm_t43_defconfig | 1 - configs/db-88f6820-amc_defconfig | 1 - configs/display5_defconfig | 1 - configs/display5_factory_defconfig | 1 - configs/dra7xx_evm_defconfig | 1 - configs/dra7xx_hs_evm_defconfig | 1 - configs/ds109_defconfig | 1 - configs/ds414_defconfig | 1 - configs/evb-rv1108_defconfig | 1 - configs/gose_defconfig | 1 - configs/helios4_defconfig| 1 - configs/k2g_evm_defconfig| 1 - configs/k2g_hs_evm_defconfig | 1 - configs/koelsch_defconfig| 1 - configs/lager_defconfig | 1 - configs/maxbcm_defconfig | 1 - configs/mt7629_rfb_defconfig | 1 - configs/mx6sxsabreauto_defconfig | 1 - configs/mx6sxsabresd_defconfig | 1 - configs/mx6ul_14x14_evk_defconfig| 1 - configs/mx6ul_9x9_evk_defconfig | 1 - configs/mx6ull_14x14_evk_defconfig | 1 - configs/mx6ull_14x14_evk_plugin_defconfig| 1 - configs/mx7dsabresd_qspi_defconfig | 1 - configs/porter_defconfig | 1 - configs/r8a77970_eagle_defconfig | 1 - configs/silk_defconfig | 1 - configs/socfpga_arria5_defconfig | 1 - configs/socfpga_cyclone5_defconfig | 1 - configs/socfpga_is1_defconfig| 1 - configs/socfpga_sockit_defconfig | 1 - configs/socfpga_socrates_defconfig | 1 - configs/socfpga_sr1500_defconfig | 1 - configs/socfpga_stratix10_defconfig | 1 - configs/stout_defconfig | 1 - configs/topic_miami_defconfig| 1 - configs/topic_miamilite_defconfig| 1 - configs/topic_miamiplus_defconfig| 1 - configs/xilinx_versal_virt_defconfig | 1 - configs/xilinx_zynqmp_mini_qspi_defconfig| 1 - configs/xilinx_zynqmp_zc1232_revA_defconfig | 1 - configs/xilinx_zynqmp_zc1254_revA_defconfig | 1 - configs/xilinx_zynqmp_zc1275_revA_defconfig | 1 - configs/xilinx_zynqmp_zc1275_revB_defconfig | 1 - configs/xilinx_zynqmp_zc1751_xm015_dc1_defconfig | 1 - configs/xilinx_zynqmp_zc1751_xm016_dc2_defconfig | 1 - configs/xilinx_zynqmp_zc1751_xm018_dc4_defconfig | 1 - configs/xilinx_zynqmp_zcu100_revC_defconfig | 1 - configs/xilinx_zynqmp_zcu102_rev1_0_defconfig| 1 - configs/xilinx_zynqmp_zcu102_revA_defconfig | 1 - configs/xilinx_zynqmp_zcu102_revB_defconfig | 1 - configs/xilinx_zynqmp_zcu104_revA_defconfig | 1 - configs/xilinx_zynqmp_zcu104_revC_defconfig | 1 - configs/xilinx_zynqmp_zcu106_revA_defconfig | 1 - configs/xilinx_zynqmp_zcu111_revA_defconfig | 1 - configs/zynq_cc108_defconfig | 1 - configs/zynq_cse_qspi_defconfig | 1 - configs/zynq_dlc20_rev1_0_defconfig | 1 - configs/zynq_microzed_defconfig | 1 - configs/zynq_minized_defconfig | 1 - configs/zynq_z_turn_defconfig| 1 - configs/zynq_zc702_defconfig | 1 - configs/zynq_zc706_defconfig | 1 - configs/zynq_zc770_xm010_defconfig | 1 - configs/zynq_zc770_xm013_defconfig | 1 - configs/zynq_zed_defconfig | 1 - configs/zynq_zybo_defconfig | 1 - configs/zynq_zybo_z7_defconfig | 1 - doc/SPI/README.ti_qspi_dra_test | 1 - drivers/mtd/spi/Kconfig | 7 --- include/configs/T102xQDS.h | 1 - include/configs/T102xRDB.h | 1 - include/configs/T104xRDB.h | 1 -
[U-Boot] [PATCH 08/16] mtd: spi: Add lightweight SPI flash stack for SPL
Add a tiny SPI flash stack that just supports reading data/images from
SPI flash. This is useful for boards that have SPL size constraints and
would need to use SPI flash framework just to read images/data from
flash. There is approximately 1.5 to 2KB savings with this.
Based on prior work of reducing spi flash id table by
Simon Goldschmidt
Signed-off-by: Vignesh R
---
common/spl/Kconfig | 9 +
drivers/mtd/spi/Makefile | 10 +-
drivers/mtd/spi/sf_internal.h | 2 +
drivers/mtd/spi/spi-nor-core.c | 266 +--
drivers/mtd/spi/spi-nor-ids.c | 294
drivers/mtd/spi/spi-nor-tiny.c | 810 +
6 files changed, 1128 insertions(+), 263 deletions(-)
create mode 100644 drivers/mtd/spi/spi-nor-ids.c
create mode 100644 drivers/mtd/spi/spi-nor-tiny.c
diff --git a/common/spl/Kconfig b/common/spl/Kconfig
index ba6d4d71fbc6..7433c049332d 100644
--- a/common/spl/Kconfig
+++ b/common/spl/Kconfig
@@ -729,8 +729,17 @@ config SPL_SPI_FLASH_SUPPORT
if SPL_SPI_FLASH_SUPPORT
+config SPL_SPI_FLASH_TINY
+ bool "Enable low footprint SPL SPI Flash support"
+ help
+Enable lightweight SPL SPI Flash support that supports just reading
+data/images from flash. No support to write/erase flash. Enable
+this if you have SPL size limitations and don't need full
+fledged SPI flash support.
+
config SPL_SPI_FLASH_SFDP_SUPPORT
bool "SFDP table parsing support for SPI NOR flashes"
+ depends on !SPL_SPI_FLASH_TINY
help
Enable support for parsing and auto discovery of parameters for
SPI NOR flashes using Serial Flash Discoverable Parameters (SFDP)
diff --git a/drivers/mtd/spi/Makefile b/drivers/mtd/spi/Makefile
index 70058d3df2b9..f99f6cb16e29 100644
--- a/drivers/mtd/spi/Makefile
+++ b/drivers/mtd/spi/Makefile
@@ -4,12 +4,20 @@
# Wolfgang Denk, DENX Software Engineering, w...@denx.de.
obj-$(CONFIG_DM_SPI_FLASH) += sf-uclass.o
+spi-nor-y := sf_probe.o spi-nor-ids.o
ifdef CONFIG_SPL_BUILD
obj-$(CONFIG_SPL_SPI_BOOT) += fsl_espi_spl.o
+ifeq ($(CONFIG_SPL_SPI_FLASH_TINY),y)
+spi-nor-y += spi-nor-tiny.o
+else
+spi-nor-y += spi-nor-core.o
+endif
+else
+spi-nor-y += spi-nor-core.o
endif
-obj-$(CONFIG_SPI_FLASH) += sf_probe.o spi-nor-core.o
+obj-$(CONFIG_SPI_FLASH) += spi-nor.o
obj-$(CONFIG_SPI_FLASH_DATAFLASH) += sf_dataflash.o sf.o
obj-$(CONFIG_SPI_FLASH_MTD) += sf_mtd.o
obj-$(CONFIG_SPI_FLASH_SANDBOX) += sandbox.o
diff --git a/drivers/mtd/spi/sf_internal.h b/drivers/mtd/spi/sf_internal.h
index 55619f5aea5c..7e7d400cdbdf 100644
--- a/drivers/mtd/spi/sf_internal.h
+++ b/drivers/mtd/spi/sf_internal.h
@@ -16,7 +16,9 @@
#define SPI_NOR_MAX_ADDR_WIDTH 4
struct flash_info {
+#if !CONFIG_IS_ENABLED(SPI_FLASH_TINY)
char*name;
+#endif
/*
* This array stores the ID bytes.
diff --git a/drivers/mtd/spi/spi-nor-core.c b/drivers/mtd/spi/spi-nor-core.c
index 97bf205c2d2d..879da2ee74e1 100644
--- a/drivers/mtd/spi/spi-nor-core.c
+++ b/drivers/mtd/spi/spi-nor-core.c
@@ -824,284 +824,26 @@ static int spi_nor_is_locked(struct mtd_info *mtd,
loff_t ofs, uint64_t len)
return ret;
}
-/* Used when the "_ext_id" is two bytes at most */
-#define INFO(_jedec_id, _ext_id, _sector_size, _n_sectors, _flags) \
- .id = { \
- ((_jedec_id) >> 16) & 0xff, \
- ((_jedec_id) >> 8) & 0xff, \
- (_jedec_id) & 0xff, \
- ((_ext_id) >> 8) & 0xff,\
- (_ext_id) & 0xff, \
- }, \
- .id_len = (!(_jedec_id) ? 0 : (3 + ((_ext_id) ? 2 : 0))),
\
- .sector_size = (_sector_size), \
- .n_sectors = (_n_sectors), \
- .page_size = 256, \
- .flags = (_flags),
-
-#define INFO6(_jedec_id, _ext_id, _sector_size, _n_sectors, _flags)\
- .id = { \
- ((_jedec_id) >> 16) & 0xff, \
- ((_jedec_id) >> 8) & 0xff, \
- (_jedec_id) & 0xff, \
- ((_ext_id) >> 16) & 0xff, \
- ((_ext_id) >> 8) & 0xff,\
- (_ext_id) & 0xff, \
- }, \
- .id_len = 6,\
- .sector_size = (_sector_size),
[U-Boot] [PATCH 09/16] sf_mtd: Simply mtd operations
Now that there is new SPI NOR framework, simplify mtd device
registration and read/write/erase operations.
Signed-off-by: Vignesh R
---
drivers/mtd/spi/sf_internal.h | 2 +-
drivers/mtd/spi/sf_mtd.c | 52 ++-
drivers/mtd/spi/sf_probe.c| 5 ++--
3 files changed, 24 insertions(+), 35 deletions(-)
diff --git a/drivers/mtd/spi/sf_internal.h b/drivers/mtd/spi/sf_internal.h
index 7e7d400cdbdf..8b445bb0b506 100644
--- a/drivers/mtd/spi/sf_internal.h
+++ b/drivers/mtd/spi/sf_internal.h
@@ -99,6 +99,6 @@ int spi_flash_cmd_get_sw_write_prot(struct spi_flash *flash);
#ifdef CONFIG_SPI_FLASH_MTD
int spi_flash_mtd_register(struct spi_flash *flash);
-void spi_flash_mtd_unregister(void);
+void spi_flash_mtd_unregister(struct spi_flash *flash);
#endif
#endif /* _SF_INTERNAL_H_ */
diff --git a/drivers/mtd/spi/sf_mtd.c b/drivers/mtd/spi/sf_mtd.c
index 68c36002bee2..65185b7c57dc 100644
--- a/drivers/mtd/spi/sf_mtd.c
+++ b/drivers/mtd/spi/sf_mtd.c
@@ -9,21 +9,19 @@
#include
#include
-static struct mtd_info sf_mtd_info;
static bool sf_mtd_registered;
static char sf_mtd_name[8];
static int spi_flash_mtd_erase(struct mtd_info *mtd, struct erase_info *instr)
{
- struct spi_flash *flash = mtd->priv;
int err;
- if (!flash)
+ if (!mtd || !mtd->priv)
return -ENODEV;
instr->state = MTD_ERASING;
- err = spi_flash_erase(flash, instr->addr, instr->len);
+ err = mtd->_erase(mtd, instr);
if (err) {
instr->state = MTD_ERASE_FAILED;
instr->fail_addr = MTD_FAIL_ADDR_UNKNOWN;
@@ -39,13 +37,12 @@ static int spi_flash_mtd_erase(struct mtd_info *mtd, struct
erase_info *instr)
static int spi_flash_mtd_read(struct mtd_info *mtd, loff_t from, size_t len,
size_t *retlen, u_char *buf)
{
- struct spi_flash *flash = mtd->priv;
int err;
- if (!flash)
+ if (!mtd || !mtd->priv)
return -ENODEV;
- err = spi_flash_read(flash, from, len, buf);
+ err = mtd->_read(mtd, from, len, retlen, buf);
if (!err)
*retlen = len;
@@ -55,13 +52,12 @@ static int spi_flash_mtd_read(struct mtd_info *mtd, loff_t
from, size_t len,
static int spi_flash_mtd_write(struct mtd_info *mtd, loff_t to, size_t len,
size_t *retlen, const u_char *buf)
{
- struct spi_flash *flash = mtd->priv;
int err;
- if (!flash)
+ if (!mtd || !mtd->priv)
return -ENODEV;
- err = spi_flash_write(flash, to, len, buf);
+ err = mtd->_write(mtd, to, len, retlen, buf);
if (!err)
*retlen = len;
@@ -83,10 +79,11 @@ static int spi_flash_mtd_number(void)
int spi_flash_mtd_register(struct spi_flash *flash)
{
+ struct mtd_info *mtd = >mtd;
int ret;
if (sf_mtd_registered) {
- ret = del_mtd_device(_mtd_info);
+ ret = del_mtd_device(mtd);
if (ret)
return ret;
@@ -94,42 +91,33 @@ int spi_flash_mtd_register(struct spi_flash *flash)
}
sf_mtd_registered = false;
- memset(_mtd_info, 0, sizeof(sf_mtd_info));
sprintf(sf_mtd_name, "nor%d", spi_flash_mtd_number());
- sf_mtd_info.name = sf_mtd_name;
- sf_mtd_info.type = MTD_NORFLASH;
- sf_mtd_info.flags = MTD_CAP_NORFLASH;
- sf_mtd_info.writesize = 1;
- sf_mtd_info.writebufsize = flash->page_size;
-
- sf_mtd_info._erase = spi_flash_mtd_erase;
- sf_mtd_info._read = spi_flash_mtd_read;
- sf_mtd_info._write = spi_flash_mtd_write;
- sf_mtd_info._sync = spi_flash_mtd_sync;
-
- sf_mtd_info.size = flash->size;
- sf_mtd_info.priv = flash;
+ mtd->name = sf_mtd_name;
+ mtd->_erase = spi_flash_mtd_erase;
+ mtd->_read = spi_flash_mtd_read;
+ mtd->_write = spi_flash_mtd_write;
+ mtd->_sync = spi_flash_mtd_sync;
/* Only uniform flash devices for now */
- sf_mtd_info.numeraseregions = 0;
- sf_mtd_info.erasesize = flash->sector_size;
+ mtd->numeraseregions = 0;
- ret = add_mtd_device(_mtd_info);
+ ret = add_mtd_device(mtd);
if (!ret)
sf_mtd_registered = true;
return ret;
}
-void spi_flash_mtd_unregister(void)
+void spi_flash_mtd_unregister(struct spi_flash *flash)
{
+ struct mtd_info *mtd = >mtd;
int ret;
if (!sf_mtd_registered)
return;
- ret = del_mtd_device(_mtd_info);
+ ret = del_mtd_device(mtd);
if (!ret) {
sf_mtd_registered = false;
return;
@@ -141,7 +129,7 @@ void spi_flash_mtd_unregister(void)
* use-after-free bug. Still, things should be fixed to prevent the
* spi_flash object from being destroyed when del_mtd_device() fails.
*/
- sf_mtd_info.priv = NULL;
+ mtd->priv = NULL;
printf("Failed to
[U-Boot] [PATCH 07/16] mtd: spi: Remove unused files
spi_flash and spi_flash_ids are no longer needed after SPI NOR
migration. Remove them.
Signed-off-by: Vignesh R
---
drivers/mtd/spi/spi_flash.c | 1337 ---
drivers/mtd/spi/spi_flash_ids.c | 211 -
2 files changed, 1548 deletions(-)
delete mode 100644 drivers/mtd/spi/spi_flash.c
delete mode 100644 drivers/mtd/spi/spi_flash_ids.c
diff --git a/drivers/mtd/spi/spi_flash.c b/drivers/mtd/spi/spi_flash.c
deleted file mode 100644
index 0c2392f28a43..
--- a/drivers/mtd/spi/spi_flash.c
+++ /dev/null
@@ -1,1337 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0+
-/*
- * SPI Flash Core
- *
- * Copyright (C) 2015 Jagan Teki
- * Copyright (C) 2013 Jagannadha Sutradharudu Teki, Xilinx Inc.
- * Copyright (C) 2010 Reinhard Meyer, EMK Elektronik
- * Copyright (C) 2008 Atmel Corporation
- */
-
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-
-#include "sf_internal.h"
-
-static void spi_flash_addr(u32 addr, u8 *cmd)
-{
- /* cmd[0] is actual command */
- cmd[1] = addr >> 16;
- cmd[2] = addr >> 8;
- cmd[3] = addr >> 0;
-}
-
-static int read_sr(struct spi_flash *flash, u8 *rs)
-{
- int ret;
- u8 cmd;
-
- cmd = CMD_READ_STATUS;
- ret = spi_flash_read_common(flash, , 1, rs, 1);
- if (ret < 0) {
- debug("SF: fail to read status register\n");
- return ret;
- }
-
- return 0;
-}
-
-static int read_fsr(struct spi_flash *flash, u8 *fsr)
-{
- int ret;
- const u8 cmd = CMD_FLAG_STATUS;
-
- ret = spi_flash_read_common(flash, , 1, fsr, 1);
- if (ret < 0) {
- debug("SF: fail to read flag status register\n");
- return ret;
- }
-
- return 0;
-}
-
-static int write_sr(struct spi_flash *flash, u8 ws)
-{
- u8 cmd;
- int ret;
-
- cmd = CMD_WRITE_STATUS;
- ret = spi_flash_write_common(flash, , 1, , 1);
- if (ret < 0) {
- debug("SF: fail to write status register\n");
- return ret;
- }
-
- return 0;
-}
-
-#if defined(CONFIG_SPI_FLASH_SPANSION) || defined(CONFIG_SPI_FLASH_WINBOND)
-static int read_cr(struct spi_flash *flash, u8 *rc)
-{
- int ret;
- u8 cmd;
-
- cmd = CMD_READ_CONFIG;
- ret = spi_flash_read_common(flash, , 1, rc, 1);
- if (ret < 0) {
- debug("SF: fail to read config register\n");
- return ret;
- }
-
- return 0;
-}
-
-static int write_cr(struct spi_flash *flash, u8 wc)
-{
- u8 data[2];
- u8 cmd;
- int ret;
-
- ret = read_sr(flash, [0]);
- if (ret < 0)
- return ret;
-
- cmd = CMD_WRITE_STATUS;
- data[1] = wc;
- ret = spi_flash_write_common(flash, , 1, , 2);
- if (ret) {
- debug("SF: fail to write config register\n");
- return ret;
- }
-
- return 0;
-}
-#endif
-
-int spi_flash_cmd_get_sw_write_prot(struct spi_flash *flash)
-{
- u8 status;
- int ret;
-
- ret = read_sr(flash, );
- if (ret)
- return ret;
-
- return (status >> 2) & 7;
-}
-
-#ifdef CONFIG_SPI_FLASH_BAR
-/*
- * This "clean_bar" is necessary in a situation when one was accessing
- * spi flash memory > 16 MiB by using Bank Address Register's BA24 bit.
- *
- * After it the BA24 bit shall be cleared to allow access to correct
- * memory region after SW reset (by calling "reset" command).
- *
- * Otherwise, the BA24 bit may be left set and then after reset, the
- * ROM would read/write/erase SPL from 16 MiB * bank_sel address.
- */
-static int clean_bar(struct spi_flash *flash)
-{
- u8 cmd, bank_sel = 0;
-
- if (flash->bank_curr == 0)
- return 0;
- cmd = flash->bank_write_cmd;
- flash->bank_curr = 0;
-
- return spi_flash_write_common(flash, , 1, _sel, 1);
-}
-
-static int write_bar(struct spi_flash *flash, u32 offset)
-{
- u8 cmd, bank_sel;
- int ret;
-
- bank_sel = offset / (SPI_FLASH_16MB_BOUN << flash->shift);
- if (bank_sel == flash->bank_curr)
- goto bar_end;
-
- cmd = flash->bank_write_cmd;
- ret = spi_flash_write_common(flash, , 1, _sel, 1);
- if (ret < 0) {
- debug("SF: fail to write bank register\n");
- return ret;
- }
-
-bar_end:
- flash->bank_curr = bank_sel;
- return flash->bank_curr;
-}
-
-static int read_bar(struct spi_flash *flash, const struct spi_flash_info *info)
-{
- u8 curr_bank = 0;
- int ret;
-
- if (flash->size <= SPI_FLASH_16MB_BOUN)
- goto bar_end;
-
- switch (JEDEC_MFR(info)) {
- case SPI_FLASH_CFI_MFR_SPANSION:
- flash->bank_read_cmd = CMD_BANKADDR_BRRD;
- flash->bank_write_cmd = CMD_BANKADDR_BRWR;
- break;
- default:
- flash->bank_read_cmd = CMD_EXTNADDR_RDEAR;
-
[U-Boot] [PATCH 05/16] mtd: spi: Port SPI NOR framework from Linux
Current U-Boot SPI NOR support (sf layer) is quite outdated as it does not
support 4 byte addressing opcodes, SFDP table parsing and different types of
quad mode enable sequences. Many newer flashes no longer support BANK
registers used by sf layer to a access >16MB space.
Also, many SPI controllers have special MMIO interfaces which provide
accelerated read/write access but require knowledge of flash parameters
to make use of it. Recent spi-mem layer provides a way to support such
flashes but sf layer isn't using that.
So sync SPI NOR framework from Linux v4.19 and add spi-mem support on top.
in order to gain 4 byte addressing support, SFDP support and a way to
support SPI controllers with MMIO flash interface.
Signed-off-by: Vignesh R
---
drivers/mtd/spi/spi-nor-core.c | 2647
include/linux/mtd/cfi.h| 32 +
include/linux/mtd/spi-nor.h| 421 +
3 files changed, 3100 insertions(+)
create mode 100644 drivers/mtd/spi/spi-nor-core.c
create mode 100644 include/linux/mtd/cfi.h
create mode 100644 include/linux/mtd/spi-nor.h
diff --git a/drivers/mtd/spi/spi-nor-core.c b/drivers/mtd/spi/spi-nor-core.c
new file mode 100644
index ..4563cd74c2e8
--- /dev/null
+++ b/drivers/mtd/spi/spi-nor-core.c
@@ -0,0 +1,2647 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Based on m25p80.c, by Mike Lavender (m...@steroidmicros.com), with
+ * influence from lart.c (Abraham Van Der Merwe) and mtd_dataflash.c
+ *
+ * Copyright (C) 2005, Intec Automation Inc.
+ * Copyright (C) 2014, Freescale Semiconductor, Inc.
+ *
+ * Synced from Linux v4.19
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+
+/* Define max times to check status register before we give up. */
+
+/*
+ * For everything but full-chip erase; probably could be much smaller, but kept
+ * around for safety for now
+ */
+
+#define HZ CONFIG_SYS_HZ
+
+#define DEFAULT_READY_WAIT_JIFFIES (40UL * HZ)
+
+#define SPI_NOR_MAX_ID_LEN 6
+#define SPI_NOR_MAX_ADDR_WIDTH 4
+
+struct flash_info {
+ char*name;
+
+ /*
+* This array stores the ID bytes.
+* The first three bytes are the JEDIC ID.
+* JEDEC ID zero means "no ID" (mostly older chips).
+*/
+ u8 id[SPI_NOR_MAX_ID_LEN];
+ u8 id_len;
+
+ /* The size listed here is what works with SPINOR_OP_SE, which isn't
+* necessarily called a "sector" by the vendor.
+*/
+ unsigned intsector_size;
+ u16 n_sectors;
+
+ u16 page_size;
+ u16 addr_width;
+
+ u16 flags;
+#define SECT_4KBIT(0) /* SPINOR_OP_BE_4K works
uniformly */
+#define SPI_NOR_NO_ERASE BIT(1) /* No erase command needed */
+#define SST_WRITE BIT(2) /* use SST byte programming */
+#define SPI_NOR_NO_FR BIT(3) /* Can't do fastread */
+#define SECT_4K_PMCBIT(4) /* SPINOR_OP_BE_4K_PMC works uniformly
*/
+#define SPI_NOR_DUAL_READ BIT(5) /* Flash supports Dual Read */
+#define SPI_NOR_QUAD_READ BIT(6) /* Flash supports Quad Read */
+#define USE_FSRBIT(7) /* use flag status register */
+#define SPI_NOR_HAS_LOCK BIT(8) /* Flash supports lock/unlock via SR */
+#define SPI_NOR_HAS_TB BIT(9) /*
+* Flash SR has Top/Bottom (TB) protect
+* bit. Must be used with
+* SPI_NOR_HAS_LOCK.
+*/
+#defineSPI_S3ANBIT(10) /*
+* Xilinx Spartan 3AN In-System Flash
+* (MFR cannot be used for probing
+* because it has the same value as
+* ATMEL flashes)
+*/
+#define SPI_NOR_4B_OPCODES BIT(11) /*
+* Use dedicated 4byte address op codes
+* to support memory size above 128Mib.
+*/
+#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 */
+
+ int (*quad_enable)(struct spi_nor *nor);
+};
+
+#define JEDEC_MFR(info)((info)->id[0])
+
+static int spi_nor_read_write_reg(struct spi_nor *nor, struct spi_mem_op
+ *op, void *buf)
+{
+ if (op->data.dir == SPI_MEM_DATA_IN)
+ op->data.buf.in = buf;
+ else
+ op->data.buf.out = buf;
+ return spi_mem_exec_op(nor->spi, op);
+}
+
+static int
[U-Boot] [PATCH 06/16] mtd: spi: Switch to new SPI NOR framework
Switch spi_flash_* interfaces to call into new SPI NOR framework via MTD
layer. Fix up sf_dataflash to work in legacy way. And update sandbox to
use new interfaces/defintions
Signed-off-by: Vignesh R
---
common/spl/Kconfig | 12 +-
drivers/mtd/spi/Kconfig| 15 ++-
drivers/mtd/spi/Makefile | 4 +-
drivers/mtd/spi/sandbox.c | 36 +++---
drivers/mtd/spi/sf_dataflash.c | 11 +-
drivers/mtd/spi/sf_internal.h | 228 +++--
drivers/mtd/spi/sf_probe.c | 33 +++--
drivers/mtd/spi/spi-nor-core.c | 59 +
drivers/spi/stm32_qspi.c | 4 +-
include/spi_flash.h| 105 ---
10 files changed, 137 insertions(+), 370 deletions(-)
diff --git a/common/spl/Kconfig b/common/spl/Kconfig
index 0ddbffc7d1c6..ba6d4d71fbc6 100644
--- a/common/spl/Kconfig
+++ b/common/spl/Kconfig
@@ -727,13 +727,23 @@ config SPL_SPI_FLASH_SUPPORT
lines). This enables the drivers in drivers/mtd/spi as part of an
SPL build. This normally requires SPL_SPI_SUPPORT.
+if SPL_SPI_FLASH_SUPPORT
+
+config SPL_SPI_FLASH_SFDP_SUPPORT
+ bool "SFDP table parsing support for SPI NOR flashes"
+ help
+Enable support for parsing and auto discovery of parameters for
+SPI NOR flashes using Serial Flash Discoverable Parameters (SFDP)
+tables as per JESD216 standard in SPL.
+
config SPL_SPI_LOAD
bool "Support loading from SPI flash"
- depends on SPL_SPI_FLASH_SUPPORT
help
Enable support for loading next stage, U-Boot or otherwise, from
SPI NOR in U-Boot SPL.
+endif # SPL_SPI_FLASH_SUPPORT
+
config SPL_SPI_SUPPORT
bool "Support SPI drivers"
help
diff --git a/drivers/mtd/spi/Kconfig b/drivers/mtd/spi/Kconfig
index 76d5a1d11527..8bd6db6ff4d3 100644
--- a/drivers/mtd/spi/Kconfig
+++ b/drivers/mtd/spi/Kconfig
@@ -27,6 +27,8 @@ config SPI_FLASH_SANDBOX
config SPI_FLASH
bool "Legacy SPI Flash Interface support"
+ depends on SPI
+ select SPI_MEM
help
Enable the legacy SPI flash support. This will include basic
standard support for things like probing, read / write, and
@@ -34,9 +36,17 @@ config SPI_FLASH
If unsure, say N
+if SPI_FLASH
+
+config SPI_FLASH_SFDP_SUPPORT
+ bool "SFDP table parsing support for SPI NOR flashes"
+ help
+Enable support for parsing and auto discovery of parameters for
+SPI NOR flashes using Serial Flash Discoverable Parameters (SFDP)
+tables as per JESD216 standard.
+
config SPI_FLASH_BAR
bool "SPI flash Bank/Extended address register support"
- depends on SPI_FLASH
help
Enable the SPI flash Bank/Extended address register support.
Bank/Extended address registers are used to access the flash
@@ -44,13 +54,10 @@ config SPI_FLASH_BAR
config SF_DUAL_FLASH
bool "SPI DUAL flash memory support"
- depends on SPI_FLASH
help
Enable this option to support two flash memories connected to a single
controller. Currently Xilinx Zynq qspi supports this.
-if SPI_FLASH
-
config SPI_FLASH_ATMEL
bool "Atmel SPI flash support"
help
diff --git a/drivers/mtd/spi/Makefile b/drivers/mtd/spi/Makefile
index b4c7e1c98bd5..70058d3df2b9 100644
--- a/drivers/mtd/spi/Makefile
+++ b/drivers/mtd/spi/Makefile
@@ -9,7 +9,7 @@ ifdef CONFIG_SPL_BUILD
obj-$(CONFIG_SPL_SPI_BOOT) += fsl_espi_spl.o
endif
-obj-$(CONFIG_SPI_FLASH) += sf_probe.o spi_flash.o spi_flash_ids.o sf.o
-obj-$(CONFIG_SPI_FLASH_DATAFLASH) += sf_dataflash.o
+obj-$(CONFIG_SPI_FLASH) += sf_probe.o spi-nor-core.o
+obj-$(CONFIG_SPI_FLASH_DATAFLASH) += sf_dataflash.o sf.o
obj-$(CONFIG_SPI_FLASH_MTD) += sf_mtd.o
obj-$(CONFIG_SPI_FLASH_SANDBOX) += sandbox.o
diff --git a/drivers/mtd/spi/sandbox.c b/drivers/mtd/spi/sandbox.c
index 7b9891cb981c..084c66e9840b 100644
--- a/drivers/mtd/spi/sandbox.c
+++ b/drivers/mtd/spi/sandbox.c
@@ -92,7 +92,7 @@ struct sandbox_spi_flash {
/* The current flash status (see STAT_XXX defines above) */
u16 status;
/* Data describing the flash we're emulating */
- const struct spi_flash_info *data;
+ const struct flash_info *data;
/* The file on disk to serv up data from */
int fd;
};
@@ -122,7 +122,7 @@ static int sandbox_sf_probe(struct udevice *dev)
/* spec = idcode:file */
struct sandbox_spi_flash *sbsf = dev_get_priv(dev);
size_t len, idname_len;
- const struct spi_flash_info *data;
+ const struct flash_info *data;
struct sandbox_spi_flash_plat_data *pdata = dev_get_platdata(dev);
struct sandbox_state *state = state_get_current();
struct dm_spi_slave_platdata *slave_plat;
@@ -155,7 +155,7 @@ static int sandbox_sf_probe(struct udevice *dev)
idname_len = strlen(spec);
debug("%s: device='%s'\n", __func__, spec);
- for (data =
[U-Boot] [PATCH 02/16] spi-mem: Claim SPI bus before spi mem access
It is necessary to call spi_claim_bus() before starting any SPI transactions and this restriction would also apply when calling spi-mem operationss. Therefore claim and release bus before requesting transfer via exec_op. Signed-off-by: Vignesh R --- drivers/spi/spi-mem.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/drivers/spi/spi-mem.c b/drivers/spi/spi-mem.c index 1da20b8de5c4..4c1463118ab2 100644 --- a/drivers/spi/spi-mem.c +++ b/drivers/spi/spi-mem.c @@ -231,7 +231,13 @@ int spi_mem_exec_op(struct spi_slave *slave, const struct spi_mem_op *op) mutex_lock(>bus_lock_mutex); mutex_lock(>io_mutex); #endif + ret = spi_claim_bus(slave); + if (ret < 0) + return ret; + ret = ops->mem_ops->exec_op(slave, op); + + spi_release_bus(slave); #ifndef __UBOOT__ mutex_unlock(>io_mutex); mutex_unlock(>bus_lock_mutex); -- 2.19.2 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 03/16] spi: Add non DM version of SPI_MEM
Add non DM version of SPI_MEM to support easy migration to new SPI NOR
framework. This can be removed once DM_SPI conversion is complete.
Signed-off-by: Vignesh R
---
drivers/spi/Kconfig| 4 +-
drivers/spi/Makefile | 1 +
drivers/spi/spi-mem-nodm.c | 89 ++
3 files changed, 92 insertions(+), 2 deletions(-)
create mode 100644 drivers/spi/spi-mem-nodm.c
diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index a7bb5b35c294..5ee855fc5319 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -16,8 +16,6 @@ config DM_SPI
typically use driver-private data instead of extending the
spi_slave structure.
-if DM_SPI
-
config SPI_MEM
bool "SPI memory extension"
help
@@ -25,6 +23,8 @@ config SPI_MEM
This extension is meant to simplify interaction with SPI memories
by providing an high-level interface to send memory-like commands.
+if DM_SPI
+
config ALTERA_SPI
bool "Altera SPI driver"
help
diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile
index 392a92579578..32ba3b61f70d 100644
--- a/drivers/spi/Makefile
+++ b/drivers/spi/Makefile
@@ -11,6 +11,7 @@ obj-$(CONFIG_SOFT_SPI) += soft_spi.o
obj-$(CONFIG_SPI_MEM) += spi-mem.o
else
obj-y += spi.o
+obj-$(CONFIG_SPI_MEM) += spi-mem-nodm.o
obj-$(CONFIG_SOFT_SPI) += soft_spi_legacy.o
endif
diff --git a/drivers/spi/spi-mem-nodm.c b/drivers/spi/spi-mem-nodm.c
new file mode 100644
index ..4d91761f56d3
--- /dev/null
+++ b/drivers/spi/spi-mem-nodm.c
@@ -0,0 +1,89 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2018 Texas Instruments Incorporated - http://www.ti.com/
+ */
+
+#include
+#include
+
+int spi_mem_exec_op(struct spi_slave *slave,
+ const struct spi_mem_op *op)
+{
+ unsigned int pos = 0;
+ const u8 *tx_buf = NULL;
+ u8 *rx_buf = NULL;
+ u8 *op_buf;
+ int op_len;
+ u32 flag;
+ int ret;
+ int i;
+
+ if (op->data.nbytes) {
+ if (op->data.dir == SPI_MEM_DATA_IN)
+ rx_buf = op->data.buf.in;
+ else
+ tx_buf = op->data.buf.out;
+ }
+
+ op_len = sizeof(op->cmd.opcode) + op->addr.nbytes + op->dummy.nbytes;
+ op_buf = calloc(1, op_len);
+
+ ret = spi_claim_bus(slave);
+ if (ret < 0)
+ return ret;
+
+ op_buf[pos++] = op->cmd.opcode;
+
+ if (op->addr.nbytes) {
+ for (i = 0; i < op->addr.nbytes; i++)
+ op_buf[pos + i] = op->addr.val >>
+ (8 * (op->addr.nbytes - i - 1));
+
+ pos += op->addr.nbytes;
+ }
+
+ if (op->dummy.nbytes)
+ memset(op_buf + pos, 0xff, op->dummy.nbytes);
+
+ /* 1st transfer: opcode + address + dummy cycles */
+ flag = SPI_XFER_BEGIN;
+ /* Make sure to set END bit if no tx or rx data messages follow */
+ if (!tx_buf && !rx_buf)
+ flag |= SPI_XFER_END;
+
+ ret = spi_xfer(slave, op_len * 8, op_buf, NULL, flag);
+ if (ret)
+ return ret;
+
+ /* 2nd transfer: rx or tx data path */
+ if (tx_buf || rx_buf) {
+ ret = spi_xfer(slave, op->data.nbytes * 8, tx_buf,
+ rx_buf, SPI_XFER_END);
+ if (ret)
+ return ret;
+ }
+
+ spi_release_bus(slave);
+
+ for (i = 0; i < pos; i++)
+ debug("%02x ", op_buf[i]);
+ debug("| [%dB %s] ",
+ tx_buf || rx_buf ? op->data.nbytes : 0,
+ tx_buf || rx_buf ? (tx_buf ? "out" : "in") : "-");
+ for (i = 0; i < op->data.nbytes; i++)
+ debug("%02x ", tx_buf ? tx_buf[i] : rx_buf[i]);
+ debug("[ret %d]\n", ret);
+
+ free(op_buf);
+
+ if (ret < 0)
+ return ret;
+
+ return 0;
+}
+
+int spi_mem_adjust_op_size(struct spi_slave *slave,
+ struct spi_mem_op *op)
+{
+ return 0;
+}
--
2.19.2
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 04/16] sh: bitops: add hweight*() macros
Add hweight*() macros required for moving to new SF layer Signed-off-by: Vignesh R --- arch/sh/include/asm/bitops.h | 4 1 file changed, 4 insertions(+) diff --git a/arch/sh/include/asm/bitops.h b/arch/sh/include/asm/bitops.h index 8cb8385d76db..765f28f116bc 100644 --- a/arch/sh/include/asm/bitops.h +++ b/arch/sh/include/asm/bitops.h @@ -153,6 +153,10 @@ static inline int ffs (int x) } #define PLATFORM_FFS +#define hweight32(x) generic_hweight32(x) +#define hweight16(x) generic_hweight16(x) +#define hweight8(x) generic_hweight8(x) + #endif /* __KERNEL__ */ #endif /* __ASM_SH_BITOPS_H */ -- 2.19.2 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 01/16] spi: spi-mem: Allow use of spi_mem_exec_op for all SPI modes
SPI controllers support all types of SPI modes including dual/quad bus
widths. Therefore remove constraint wrt SPI mode from spi-mem layer.
Signed-off-by: Vignesh R
---
drivers/spi/spi-mem.c | 9 -
1 file changed, 9 deletions(-)
diff --git a/drivers/spi/spi-mem.c b/drivers/spi/spi-mem.c
index af9aef009a73..1da20b8de5c4 100644
--- a/drivers/spi/spi-mem.c
+++ b/drivers/spi/spi-mem.c
@@ -323,15 +323,6 @@ int spi_mem_exec_op(struct spi_slave *slave, const struct
spi_mem_op *op)
return -EIO;
#else
- /* U-Boot does not support parallel SPI data lanes */
- if ((op->cmd.buswidth != 1) ||
- (op->addr.nbytes && op->addr.buswidth != 1) ||
- (op->dummy.nbytes && op->dummy.buswidth != 1) ||
- (op->data.nbytes && op->data.buswidth != 1)) {
- printf("Dual/Quad raw SPI transfers not supported\n");
- return -ENOTSUPP;
- }
-
if (op->data.nbytes) {
if (op->data.dir == SPI_MEM_DATA_IN)
rx_buf = op->data.buf.in;
--
2.19.2
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 00/16] SF: Migrate to Linux SPI NOR framework
U-Boot SPI NOR support (sf layer) is quite outdated as it does not support 4 byte addressing opcodes, SFDP table parsing and different types of quad mode enable sequences. Many newer flashes no longer support BANK registers used by sf layer to a access >16MB space. Also, many SPI controllers have special MMIO interfaces which provide accelerated read/write access but require knowledge of flash parameters to make use of it. Recent spi-mem layer provides a way to support such flashes but sf layer isn't using that. This patch series syncs SPI NOR framework from Linux v4.19. It also adds spi-mem support on top. So, we gain 4byte addressing support and SFDP support. This makes migrating to U-Boot MTD framework easier. Tested with few Spansion, micron and macronix flashes with TI's dra7xx, k2g, am43xx EVMs. I dont have access to flashes from other vendors. So, I would greatly appreciate testing on other platforms. Complete series with dependencies here[1] For clean build on some platforms, depends on CONFIG_SPI_FLASH migration to defconfigs [2] [1] https://github.com/r-vignesh/u-boot.git branch: spi-nor-mig-patch-v1 [2] https://patchwork.ozlabs.org/patch/1007485/ Patch 12-15 are compile tested. Change log: Since RFC v2: Fix issues reported by Simon Goldschmidt wrt 4 use of byte addressing opcode Fix issues in compiling SFDP code Re organize file names and Makefile to simply spi-nor-tiny inclusion Remove SPI_FLASH_BAR and SF_DUAL_FLASH as these are no longer used RFC v2: https://patchwork.ozlabs.org/cover/1007589/ Since RFC v1: Add lightweight SPI flash stack for boards with SPL size constraints Provide non DM version of spi-mem Fix build issues on different platforms as reported by travis-ci on v1 RFC v1: https://patchwork.ozlabs.org/cover/1004689/ Vignesh R (16): spi: spi-mem: Allow use of spi_mem_exec_op for all SPI modes spi-mem: Claim SPI bus before spi mem access spi: Add non DM version of SPI_MEM sh: bitops: add hweight*() macros mtd: spi: Port SPI NOR framework from Linux mtd: spi: Switch to new SPI NOR framework mtd: spi: Remove unused files mtd: spi: Add lightweight SPI flash stack for SPL sf_mtd: Simply mtd operations configs: Get rid of SPI_FLASH_BAR configs: Remove SF_DUAL_FLASH axm_defconfig: Enable simple malloc in SPL taurus_defconfig: Enable simple malloc in SPL da850_am18xxevm: Enable tiny printf turris_omnia_defconfig: Enable tiny printf MAINTAINERS: Add an entry for SPI NOR MAINTAINERS |8 + arch/arm/mach-omap2/am33xx/Kconfig|1 - arch/sh/include/asm/bitops.h |4 + common/spl/Kconfig| 21 +- configs/alt_defconfig |1 - configs/am57xx_evm_defconfig |1 - configs/am57xx_hs_evm_defconfig |1 - configs/ap121_defconfig |1 - configs/ap143_defconfig |1 - configs/avnet_ultra96_rev1_defconfig |1 - configs/axm_defconfig |1 + configs/axs101_defconfig |1 - configs/axs103_defconfig |1 - configs/bg0900_defconfig |1 - configs/blanche_defconfig |1 - configs/cl-som-am57x_defconfig|1 - configs/clearfog_defconfig|1 - configs/cm_t43_defconfig |1 - configs/da850_am18xxevm_defconfig |1 + configs/db-88f6820-amc_defconfig |1 - configs/display5_defconfig|1 - configs/display5_factory_defconfig|1 - configs/dra7xx_evm_defconfig |1 - configs/dra7xx_hs_evm_defconfig |1 - configs/ds109_defconfig |1 - configs/ds414_defconfig |1 - configs/evb-rv1108_defconfig |1 - configs/gose_defconfig|1 - configs/helios4_defconfig |1 - configs/k2g_evm_defconfig |1 - configs/k2g_hs_evm_defconfig |1 - configs/koelsch_defconfig |1 - configs/lager_defconfig |1 - configs/maxbcm_defconfig |1 - configs/mt7629_rfb_defconfig |1 - configs/mx6sxsabreauto_defconfig |1 - configs/mx6sxsabresd_defconfig|1 - configs/mx6ul_14x14_evk_defconfig |1 - configs/mx6ul_9x9_evk_defconfig |1 - configs/mx6ull_14x14_evk_defconfig|1 - configs/mx6ull_14x14_evk_plugin_defconfig |1 - configs/mx7dsabresd_qspi_defconfig|1 - configs/porter_defconfig |1 - configs/r8a77970_eagle_defconfig |1 - configs/silk_defconfig|1 -
Re: [U-Boot] [PATCH v2 0/6] Add support for MIPS Creator CI20
Hi Ezequiel, Am 12.12.18 um 14:58 schrieb Ezequiel Garcia: > A new round. > > For this new round: > > * Replaced infinite while loop with wait_for_bit. > * Added a MAINTAINERS file. If anyone wants to co-maintain this, >please let me know. > > This is based on top of yesterday's master (ee168783ae8) and has > been tested by SD-card booting both U-Boot and Linux. Booting > Linux via TFTP was also tested. > > Toolchain used to test: > > $ mips-linux-gcc -v > Using built-in specs. > COLLECT_GCC=mips-linux-gcc > COLLECT_LTO_WRAPPER=/home/zeta/.buildman-toolchains/gcc-7.3.0-nolibc/mips-linux/bin/../libexec/gcc/mips-linux/7.3.0/lto-wrapper > Target: mips-linux > Configured with: /home/arnd/git/gcc/configure --target=mips-linux > --enable-targets=all --prefix=/opt/crosstool/gcc-7.3.0-nolibc/mips-linux > --enable-languages=c --without-headers --disable-bootstrap --disable-nls > --disable-threads --disable-shared --disable-libmudflap --disable-libssp > --disable-libgomp --disable-decimal-float --disable-libquadmath > --disable-libatomic --disable-libcc1 --disable-libmpx > --enable-checking=release > Thread model: single > gcc version 7.3.0 (GCC) > > SPL size: > > $ size spl/u-boot-spl >text data bss dec hex filename >9252 752 736 1074029f4 spl/u-boot-spl > > I've pushed a branch to https://github.com/ezequielgarcia/u-boot/tree/ci20-v2 > and made sure travis passed. > Thanks for working on this but the problem with the original patch series was that it was not fully driver model compatible and that stuff like watchdog, reset and pin-muxing was open-coded instead of using the proper frameworks. As the ship is sailing towards having only driver model and device tree in U-Boot proper, it doesn't make sense to accept new SoC/boards with legacy code especially if there is no active maintainer who would do the conversion work. And with the upcoming dead lines for DM conversions, boards with legacy code will be removed when not converted. This is also one of the reasons why the Ingenic SoC support we already had in mainline was removed. And readding parts of the removed code doesn't make sense either because the patch series is based on that old Ingenic SoC code. I wanted to work on Marek's patch series to fix those issues because it's quite some work which I couldn't expect from Marek ;) But I got stuck with EJTAG because halting the CPU didn't work. Then I hadn't time anymore. I'm little busy right now so I can't do a detailed review. But the issues which should be addressed at first are: - fix all SPDX license identifiers - convert GPIO driver to DM - add a DM watchdog driver - implement machine reset with the generic watchdog reset (see BMIPS for an example) - don't use SoC specific start.S and u-boot-spl.lds, the generic code is now configurable enough and non-generic things could be done in a lowlevel_init.S - reduce the hundreds of definitions of register addresses to the ones really needed in assembly or SPL. This stuff should come from device tree - define the remaining register base addresses as physical addresses and establish a mapping with ioremap_nocache() -- - Daniel ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 4/7] cmd: Add 'ab_select' command
For A/B system update support the Android boot process requires to send
'androidboot.slot_suffix' parameter as a command line argument. This
patch implementes 'ab_select' command which allows us to obtain current
slot by processing the A/B metadata.
The patch was extracted from commit [1] with one modification: the
separator for specifying the name of metadata partition was changed
from ';' to '#', because ';' is used for commands separation.
[1]
https://android-review.googlesource.com/c/platform/external/u-boot/+/729880/2
Signed-off-by: Ruslan Trofymenko
Reviewed-by: Alistair Strachan
Reviewed-by: Sam Protsenko
---
Changes in v2:
* 'android_ab_select' command is renamed to 'ab_select' command
* command is moved to the separate 'Android support commands' menu
cmd/Kconfig | 15 +++
cmd/Makefile| 1 +
cmd/ab_select.c | 52
3 files changed, 68 insertions(+)
create mode 100644 cmd/ab_select.c
diff --git a/cmd/Kconfig b/cmd/Kconfig
index ea1a325..ed60e1e 100644
--- a/cmd/Kconfig
+++ b/cmd/Kconfig
@@ -1123,6 +1123,21 @@ config CMD_SETEXPR
endmenu
+menu "Android support commands"
+
+config CMD_AB_SELECT
+ bool "ab_select"
+ default n
+ depends on ANDROID_AB
+ help
+ On Android devices with more than one boot slot (multiple copies of
+ the kernel and system images) this provides a command to select which
+ slot should be used to boot from and register the boot attempt. This
+ is used by the new A/B update model where one slot is updated in the
+ background while running from the other slot.
+
+endmenu
+
if NET
menuconfig CMD_NET
diff --git a/cmd/Makefile b/cmd/Makefile
index 4998643..1d345c1 100644
--- a/cmd/Makefile
+++ b/cmd/Makefile
@@ -12,6 +12,7 @@ obj-y += version.o
# command
obj-$(CONFIG_CMD_AES) += aes.o
+obj-$(CONFIG_CMD_AB_SELECT) += ab_select.o
obj-$(CONFIG_CMD_ADC) += adc.o
obj-$(CONFIG_CMD_ARMFLASH) += armflash.o
obj-y += blk_common.o
diff --git a/cmd/ab_select.c b/cmd/ab_select.c
new file mode 100644
index 000..2a9e524
--- /dev/null
+++ b/cmd/ab_select.c
@@ -0,0 +1,52 @@
+// SPDX-License-Identifier: BSD-2-Clause
+/*
+ * Copyright (C) 2017 The Android Open Source Project
+ */
+
+#include
+#include
+
+static int do_ab_select(cmd_tbl_t *cmdtp, int flag, int argc,
+ char * const argv[])
+{
+ int ret;
+ struct blk_desc *dev_desc;
+ disk_partition_t part_info;
+ char slot[2];
+
+ if (argc != 4)
+ return CMD_RET_USAGE;
+
+ /* Lookup the "misc" partition from argv[2] and argv[3] */
+ if (part_get_info_by_dev_and_name_or_num(argv[2], argv[3],
+_desc, _info) < 0) {
+ return CMD_RET_FAILURE;
+ }
+
+ ret = ab_select_slot(dev_desc, _info);
+ if (ret < 0) {
+ printf("Android boot failed, error %d.\n", ret);
+ return CMD_RET_FAILURE;
+ }
+
+ /* Android standard slot names are 'a', 'b', ... */
+ slot[0] = ANDROID_BOOT_SLOT_NAME(ret);
+ slot[1] = '\0';
+ env_set(argv[1], slot);
+ printf("ANDROID: Booting slot: %s\n", slot);
+ return CMD_RET_SUCCESS;
+}
+
+U_BOOT_CMD(ab_select, 4, 0, do_ab_select,
+ "Select the slot used to boot from and register the boot attempt.",
+ " \n"
+ "- Load the slot metadata from the partition 'part' on\n"
+ " device type 'interface' instance 'dev' and store the active\n"
+ " slot in the 'slot_var_name' variable. This also updates the\n"
+ " Android slot metadata with a boot attempt, which can cause\n"
+ " successive calls to this function to return a different
result\n"
+ " if the returned slot runs out of boot attempts.\n"
+ "- If 'part_name' is passed, preceded with a # instead of :,
the\n"
+ " partition name whose label is 'part_name' will be looked up
in\n"
+ " the partition table. This is commonly the \"misc\"
partition.\n"
+);
--
2.7.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 7/7] env: am57xx: Implement A/B boot process
Add support for A/B boot process on AM57xx based boards:
1. Define 'slot_suffix' variable (using 'ab_select' command)
2. Extend 'emmc_android_boot' boot command (add commands for A/B boot
process)
'ab_select' command is used to decide which slot should be used for
booting up. A/B metadata resides in 'misc' partition.
To activate the A/B boot process, the following config options must be
set:
CONFIG_ANDROID_AB=y
CONFIG_CMD_AB_SELECT=y
For successful A/B boot, the corresponding A/B infrastructure must be
involved on Android side [1] (including mounting system as root), and
disk must be partitioned accordingly.
When A/B boot is enabled, there are some known limitations currently
exist (not related to A/B patches, need to be implemented later):
1. The 'Verified Boot' sequence is not supported
2. dev path to system partition (system_a or system_b) is passed via
'bootargs' as 'root=' argument like 'root=/dev/mmcblk1p12', but
further we'll need to rework it with respect to dm-verity
requirements [2]
In case when A/B partitions are not present in system (and A/B boot is
enabled), boot up process will be terminated and next message will be
shown:
"boot_a(b) partition not found"
[1] https://source.android.com/devices/tech/ota/ab
[2] https://source.android.com/devices/tech/ota/ab/ab_implement#kernel
Signed-off-by: Ruslan Trofymenko
Reviewed-by: Alistair Strachan
Reviewed-by: Sam Protsenko
---
Changes in v2:
* Сhanges related to command renaming (android_ab_select -> ab_select)
* Slotted sections (e.g. system_a and system_b) are added to the
default sections if CONFIG_CMD_AB_SELECT flag is defined
* Rebased on top of master
* system partitions sizes increased to 1024 MiB (to be consistent with
recent changes to boot.h file)
include/environment/ti/boot.h | 58 ++-
1 file changed, 52 insertions(+), 6 deletions(-)
diff --git a/include/environment/ti/boot.h b/include/environment/ti/boot.h
index 5891009..e3ba689 100644
--- a/include/environment/ti/boot.h
+++ b/include/environment/ti/boot.h
@@ -23,6 +23,18 @@
#define VBMETA_PART""
#endif
+#if defined(CONFIG_CMD_AB_SELECT)
+#define COMMON_PARTS \
+ "name=boot_a,size=10M,uuid=${uuid_gpt_boot_a};" \
+ "name=boot_b,size=10M,uuid=${uuid_gpt_boot_b};" \
+ "name=system_a,size=1024M,uuid=${uuid_gpt_system_a};" \
+ "name=system_b,size=1024M,uuid=${uuid_gpt_system_b};"
+#else
+#define COMMON_PARTS \
+ "name=boot,size=10M,uuid=${uuid_gpt_boot};" \
+ "name=system,size=1024M,uuid=${uuid_gpt_system};"
+#endif
+
#ifndef PARTS_DEFAULT
/* Define the default GPT table for eMMC */
#define PARTS_DEFAULT \
@@ -40,8 +52,7 @@
"name=efs,size=16M,uuid=${uuid_gpt_efs};" \
"name=crypto,size=16K,uuid=${uuid_gpt_crypto};" \
"name=recovery,size=40M,uuid=${uuid_gpt_recovery};" \
- "name=boot,size=10M,uuid=${uuid_gpt_boot};" \
- "name=system,size=768M,uuid=${uuid_gpt_system};" \
+ COMMON_PARTS \
"name=vendor,size=256M,uuid=${uuid_gpt_vendor};" \
"name=cache,size=256M,uuid=${uuid_gpt_cache};" \
"name=ipu1,size=1M,uuid=${uuid_gpt_ipu1};" \
@@ -63,6 +74,35 @@
#define AVB_VERIFY_CMD ""
#endif
+#define CONTROL_PARTITION "misc"
+
+#if defined(CONFIG_CMD_AB_SELECT)
+#define AB_SELECT \
+ "if part number mmc 1 " CONTROL_PARTITION " control_part_number; " \
+ "then " \
+ "echo " CONTROL_PARTITION \
+ " partition number:${control_part_number};" \
+ "ab_select slot_name mmc ${mmcdev}:${control_part_number};" \
+ "else " \
+ "echo " CONTROL_PARTITION " partition not found;" \
+ "exit;" \
+ "fi;" \
+ "setenv slot_suffix _${slot_name};" \
+ "if part number mmc ${mmcdev} system${slot_suffix} " \
+ "system_part_number; then " \
+ "setenv bootargs_ab " \
+ "ro root=/dev/mmcblk${mmcdev}p${system_part_number} " \
+ "rootwait init=/init skip_initramfs " \
+ "androidboot.slot_suffix=${slot_suffix};" \
+ "echo A/B cmdline addition: ${bootargs_ab};" \
+ "setenv bootargs ${bootargs} ${bootargs_ab};" \
+ "else " \
+ "echo system${slot_suffix} partition not found;" \
+ "fi;"
+#else
+#define AB_SELECT ""
+#endif
+
#define DEFAULT_COMMON_BOOT_TI_ARGS \
"console=" CONSOLEDEV ",115200n8\0" \
"fdtfile=undefined\0" \
@@ -91,10 +131,16 @@
"mmc dev $mmcdev; " \
"mmc rescan; " \
AVB_VERIFY_CHECK \
- "part start mmc ${mmcdev} boot boot_start; " \
- "part size mmc ${mmcdev} boot boot_size; " \
- "mmc read ${loadaddr} ${boot_start} ${boot_size}; " \
- "bootm ${loadaddr}#${fdtfile};\0 "
+ AB_SELECT \
+ "if
[U-Boot] [PATCH v2 6/7] doc: android: Add simple guide for A/B updates
Add a short documentation for A/B enablement and 'ab_select' command usage. Signed-off-by: Ruslan Trofymenko Reviewed-by: Alistair Strachan Reviewed-by: Sam Protsenko --- Changes in v2: * Сhanges related to command renaming (android_ab_select -> ab_select) doc/README.android-ab | 67 +++ 1 file changed, 67 insertions(+) create mode 100644 doc/README.android-ab diff --git a/doc/README.android-ab b/doc/README.android-ab new file mode 100644 index 000..9f37ed5 --- /dev/null +++ b/doc/README.android-ab @@ -0,0 +1,67 @@ +Android A/B updates +=== + +Overview + + +A/B system updates ensures modern approach for system update. This feature +allows one to use two sets (or more) of partitions referred to as slots +(normally slot A and slot B). The system runs from the current slot while the +partitions in the unused slot can be updated [1]. + +A/B enablement +-- + +The A/B updates support can be activated by specifying next options in +your board configuration file: + +CONFIG_ANDROID_AB=y +CONFIG_CMD_AB_SELECT=y + +The disk space on target device must be partitioned in a way so that each +partition which needs to be updated has two or more instances. The name of +each instance must be formed by adding suffixes: _a, _b, _c, etc. +For example: boot_a, boot_b, system_a, system_b, vendor_a, vendor_b. + +As a result you can use 'ab_select' command to ensure A/B boot process in your +boot script. This command analyzes and processes A/B metadata stored on a +special partition (e.g. "misc") and determines which slot should be used for +booting up. + +Command usage +- + +ab_select + +for example: + +=> ab_select slot_name mmc 1:4 + +or + +=> ab_select slot_name mmc 1#misc + +Result: + +=> printenv slot_name +slot_name=a + +Based on this slot information, the current boot partition should be defined, +and next kernel command line parameters should be generated: + + - androidboot.slot_suffix= + - root= + +For example: + +androidboot.slot_suffix=_a root=/dev/mmcblk1p12 + +A/B metadata is organized according to AOSP reference [2]. On the first system +start with A/B enabled, when 'misc' partition doesn't contain required data, +the default A/B metadata will be created and written to 'misc' partition. + +References +-- + +[1] https://source.android.com/devices/tech/ota/ab +[2] bootable/recovery/bootloader_message/include/bootloader_message/bootloader_message.h -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 2/7] disk: part: Extend API to get partition info
This patch adds part_get_info_by_dev_and_name_or_num() function which
allows us to get partition info from its number or name. Partition of
interest is specified by string like "device_num:partition_number" or
"device_num#partition_name".
The patch was extracted from [1].
[1]
https://android-review.googlesource.com/c/platform/external/u-boot/+/729880/2
Signed-off-by: Ruslan Trofymenko
Reviewed-by: Alistair Strachan
Reviewed-by: Sam Protsenko
---
Changes in v2:
* Error codes are changed to -EINVAL instead of -1
disk/part.c| 68 ++
include/part.h | 21 ++
2 files changed, 89 insertions(+)
diff --git a/disk/part.c b/disk/part.c
index f30f9e9..7b739ad 100644
--- a/disk/part.c
+++ b/disk/part.c
@@ -675,6 +675,74 @@ int part_get_info_by_name(struct blk_desc *dev_desc, const
char *name,
return part_get_info_by_name_type(dev_desc, name, info, PART_TYPE_ALL);
}
+/**
+ * Get partition info from device number and partition name.
+ *
+ * Parse a device number and partition name string in the form of
+ * "device_num#partition_name", for example "0#misc". If the partition
+ * is found, sets dev_desc and part_info accordingly with the information
+ * of the partition with the given partition_name.
+ *
+ * @param[in] dev_iface Device interface
+ * @param[in] dev_part_str Input string argument, like "0#misc"
+ * @param[out] dev_desc Place to store the device description pointer
+ * @param[out] part_info Place to store the partition information
+ * @return 0 on success, or a negative on error
+ */
+static int part_get_info_by_dev_and_name(const char *dev_iface,
+const char *dev_part_str,
+struct blk_desc **dev_desc,
+disk_partition_t *part_info)
+{
+ char *ep;
+ const char *part_str;
+ int dev_num;
+
+ part_str = strchr(dev_part_str, '#');
+ if (!part_str || part_str == dev_part_str)
+ return -EINVAL;
+
+ dev_num = simple_strtoul(dev_part_str, , 16);
+ if (ep != part_str) {
+ /* Not all the first part before the # was parsed. */
+ return -EINVAL;
+ }
+ part_str++;
+
+ *dev_desc = blk_get_dev(dev_iface, dev_num);
+ if (!*dev_desc) {
+ printf("Could not find %s %d\n", dev_iface, dev_num);
+ return -EINVAL;
+ }
+ if (part_get_info_by_name(*dev_desc, part_str, part_info) < 0) {
+ printf("Could not find \"%s\" partition\n", part_str);
+ return -EINVAL;
+ }
+ return 0;
+}
+
+int part_get_info_by_dev_and_name_or_num(const char *dev_iface,
+const char *dev_part_str,
+struct blk_desc **dev_desc,
+disk_partition_t *part_info)
+{
+ /* Split the part_name if passed as "$dev_num#part_name". */
+ if (!part_get_info_by_dev_and_name(dev_iface, dev_part_str,
+ dev_desc, part_info))
+ return 0;
+ /*
+* Couldn't lookup by name, try looking up the partition description
+* directly.
+*/
+ if (blk_get_device_part_str(dev_iface, dev_part_str,
+ dev_desc, part_info, 1) < 0) {
+ printf("Couldn't find partition %s %s\n",
+ dev_iface, dev_part_str);
+ return -EINVAL;
+ }
+ return 0;
+}
+
void part_set_generic_name(const struct blk_desc *dev_desc,
int part_num, char *name)
{
diff --git a/include/part.h b/include/part.h
index 0750aee..9d57b65 100644
--- a/include/part.h
+++ b/include/part.h
@@ -202,6 +202,27 @@ int part_get_info_by_name(struct blk_desc *dev_desc,
const char *name, disk_partition_t *info);
/**
+ * Get partition info from dev number + part name, or dev number + part number.
+ *
+ * Parse a device number and partition description (either name or number)
+ * in the form of device number plus partition name separated by a "#"
+ * (like "device_num#partition_name") or a device number plus a partition
number
+ * separated by a ":". For example both "0#misc" and "0:1" can be valid
+ * partition descriptions for a given interface. If the partition is found,
sets
+ * dev_desc and part_info accordingly with the information of the partition.
+ *
+ * @param[in] dev_ifaceDevice interface
+ * @param[in] dev_part_str Input partition description, like "0#misc" or "0:1"
+ * @param[out] dev_descPlace to store the device description pointer
+ * @param[out] part_info Place to store the partition information
+ * @return 0 on success, or a negative on error
+ */
+int part_get_info_by_dev_and_name_or_num(const char *dev_iface,
+const char
[U-Boot] [PATCH v2 3/7] common: Implement A/B metadata
This patch determines the A/B-specific bootloader message structure
that is the basis for implementation of recovery and A/B update
functions. A/B metadata is stored in this structure and used to decide
which slot should we use to boot the device. Also some basic functions
for A/B metadata manipulation are implemented (like slot selection).
The patch was extracted from commits [1], [2] with some coding style
fixes.
[1]
https://android-review.googlesource.com/c/platform/external/u-boot/+/729878/2
[2]
https://android-review.googlesource.com/c/platform/external/u-boot/+/729880/2
Signed-off-by: Ruslan Trofymenko
Reviewed-by: Sam Protsenko
---
Changes in v2:
* Function return codes are clarified
* Some types and constants are renamed (for compactness)
* android_bootloader_message.h is renamed to android_bl_msg.h
* 'debug' calls are changed to 'log_debug'
* Order of headers is changed
* android_bl_msg.h was synced with AOSP master counterpart
common/Kconfig | 10 ++
common/Makefile | 1 +
common/android_ab.c | 277 +++
include/android_ab.h | 34 ++
include/android_bl_msg.h | 169 +
5 files changed, 491 insertions(+)
create mode 100644 common/android_ab.c
create mode 100644 include/android_ab.h
create mode 100644 include/android_bl_msg.h
diff --git a/common/Kconfig b/common/Kconfig
index 57bd16d..0ff4679 100644
--- a/common/Kconfig
+++ b/common/Kconfig
@@ -748,6 +748,16 @@ config UPDATE_TFTP_MSEC_MAX
default 100
depends on UPDATE_TFTP
+config ANDROID_AB
+ bool "Android A/B updates"
+ default n
+ help
+ If enabled, adds support for the new Android A/B update model. This
+ allows the bootloader to select which slot to boot from based on the
+ information provided by userspace via the Android boot_ctrl HAL. This
+ allows a bootloader to try a new version of the system but roll back
+ to previous version if the new one didn't boot all the way.
+
endmenu
menu "Blob list"
diff --git a/common/Makefile b/common/Makefile
index 65d89dc..acc3851 100644
--- a/common/Makefile
+++ b/common/Makefile
@@ -104,6 +104,7 @@ endif
endif
obj-y += image.o
+obj-$(CONFIG_ANDROID_AB) += android_ab.o
obj-$(CONFIG_ANDROID_BOOT_IMAGE) += image-android.o
obj-$(CONFIG_$(SPL_TPL_)OF_LIBFDT) += image-fdt.o
obj-$(CONFIG_$(SPL_TPL_)FIT) += image-fit.o
diff --git a/common/android_ab.c b/common/android_ab.c
new file mode 100644
index 000..dda2263
--- /dev/null
+++ b/common/android_ab.c
@@ -0,0 +1,277 @@
+// SPDX-License-Identifier: BSD-2-Clause
+/*
+ * Copyright (C) 2017 The Android Open Source Project
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+/**
+ * Compute the CRC-32 of the bootloader control struct.
+ *
+ * Only the bytes up to the crc32_le field are considered for the CRC-32
+ * calculation.
+ */
+static uint32_t ab_control_compute_crc(struct andr_bl_control *abc)
+{
+ return crc32(0, (void *)abc, offsetof(typeof(*abc), crc32_le));
+}
+
+/**
+ * Initialize andr_bl_control to the default value.
+ *
+ * It allows us to boot all slots in order from the first one. This value
+ * should be used when the bootloader message is corrupted, but not when
+ * a valid message indicates that all slots are unbootable.
+ */
+static void ab_control_default(struct andr_bl_control *abc)
+{
+ int i;
+ const struct andr_slot_metadata metadata = {
+ .priority = 15,
+ .tries_remaining = 7,
+ .successful_boot = 0,
+ .verity_corrupted = 0,
+ .reserved = 0
+ };
+
+ memcpy(abc->slot_suffix, "a\0\0\0", 4);
+ abc->magic = ANDROID_BOOT_CTRL_MAGIC;
+ abc->version = ANDROID_BOOT_CTRL_VERSION;
+ abc->nb_slot = ANDROID_NUM_SLOTS;
+ memset(abc->reserved0, 0, sizeof(abc->reserved0));
+ for (i = 0; i < abc->nb_slot; ++i)
+ abc->slot_info[i] = metadata;
+
+ memset(abc->reserved1, 0, sizeof(abc->reserved1));
+ abc->crc32_le = ab_control_compute_crc(abc);
+}
+
+/**
+ * Load the boot_control struct from disk into newly allocated memory.
+ *
+ * This function allocates and returns an integer number of disk blocks,
+ * based on the block size of the passed device to help performing a
+ * read-modify-write operation on the boot_control struct.
+ * The boot_control struct offset (2 KiB) must be a multiple of the device
+ * block size, for simplicity.
+ *
+ * @param[in] dev_desc Device where to read the boot_control struct from
+ * @param[in] part_info Partition in 'dev_desc' where to read from, normally
+ * the "misc" partition should be used
+ * @param[out] pointer to pointer to andr_bl_control data
+ * @return 0 on success and a negative on error
+ */
+static int ab_control_create_from_disk(struct blk_desc *dev_desc,
+ const
[U-Boot] [PATCH v2 5/7] test/py: Add base test case for A/B updates
Add sandbox test for 'ab_select' command.
Test: ./test/py/test.py --bd sandbox --build -k test_ab
Signed-off-by: Ruslan Trofymenko
Reviewed-by: Alistair Strachan
Reviewed-by: Sam Protsenko
---
Changes in v2:
* Сhanges related to command renaming
* Assertion condition was clarified. Full command output is controlled.
configs/sandbox_defconfig | 2 ++
test/py/tests/test_ab.py | 74 +++
2 files changed, 76 insertions(+)
create mode 100644 test/py/tests/test_ab.py
diff --git a/configs/sandbox_defconfig b/configs/sandbox_defconfig
index 5b65c61..b6a642e 100644
--- a/configs/sandbox_defconfig
+++ b/configs/sandbox_defconfig
@@ -21,6 +21,7 @@ CONFIG_PRE_CON_BUF_ADDR=0x10
CONFIG_LOG_MAX_LEVEL=6
CONFIG_LOG_ERROR_RETURN=y
CONFIG_DISPLAY_BOARDINFO_LATE=y
+CONFIG_ANDROID_AB=y
CONFIG_CMD_CPU=y
CONFIG_CMD_LICENSE=y
CONFIG_CMD_BOOTZ=y
@@ -49,6 +50,7 @@ CONFIG_CMD_SF=y
CONFIG_CMD_SPI=y
CONFIG_CMD_USB=y
CONFIG_CMD_AXI=y
+CONFIG_CMD_AB_SELECT=y
CONFIG_CMD_TFTPPUT=y
CONFIG_CMD_TFTPSRV=y
CONFIG_CMD_RARP=y
diff --git a/test/py/tests/test_ab.py b/test/py/tests/test_ab.py
new file mode 100644
index 000..b90ca87
--- /dev/null
+++ b/test/py/tests/test_ab.py
@@ -0,0 +1,74 @@
+# SPDX-License-Identifier: GPL-2.0
+# (C) Copyright 2018 Texas Instruments,
+
+# Test A/B update commands.
+
+import os
+import pytest
+import u_boot_utils
+
+class ABTestDiskImage(object):
+"""Disk Image used by the A/B tests."""
+
+def __init__(self, u_boot_console):
+"""Initialize a new ABTestDiskImage object.
+
+Args:
+u_boot_console: A U-Boot console.
+
+Returns:
+Nothing.
+"""
+
+filename = 'test_ab_disk_image.bin'
+
+persistent = u_boot_console.config.persistent_data_dir + '/' + filename
+self.path = u_boot_console.config.result_dir + '/' + filename
+
+with u_boot_utils.persistent_file_helper(u_boot_console.log,
persistent):
+if os.path.exists(persistent):
+u_boot_console.log.action('Disk image file ' + persistent +
+' already exists')
+else:
+u_boot_console.log.action('Generating ' + persistent)
+fd = os.open(persistent, os.O_RDWR | os.O_CREAT)
+os.ftruncate(fd, 524288)
+os.close(fd)
+cmd = ('sgdisk', persistent)
+u_boot_utils.run_and_log(u_boot_console, cmd)
+
+cmd = ('sgdisk', '--new=1:64:512', '-c 1:misc', persistent)
+u_boot_utils.run_and_log(u_boot_console, cmd)
+cmd = ('sgdisk', '-l', persistent)
+u_boot_utils.run_and_log(u_boot_console, cmd)
+
+cmd = ('cp', persistent, self.path)
+u_boot_utils.run_and_log(u_boot_console, cmd)
+
+di = None
+@pytest.fixture(scope='function')
+def ab_disk_image(u_boot_console):
+global di
+if not di:
+di = ABTestDiskImage(u_boot_console)
+return di
+
+@pytest.mark.boardspec('sandbox')
+@pytest.mark.buildconfigspec('android_ab')
+@pytest.mark.buildconfigspec('cmd_ab_select')
+@pytest.mark.requiredtool('sgdisk')
+def test_ab(ab_disk_image, u_boot_console):
+"""Test the 'ab_select' command."""
+
+u_boot_console.run_command('host bind 0 ' + ab_disk_image.path)
+
+output = u_boot_console.run_command('ab_select slot_name host 0#misc')
+assert 're-initializing A/B metadata' in output
+assert 'Attempting slot a, tries remaining 7' in output
+output = u_boot_console.run_command('printenv slot_name')
+assert 'slot_name=a' in output
+
+output = u_boot_console.run_command('ab_select slot_name host 0:1')
+assert 'Attempting slot b, tries remaining 7' in output
+output = u_boot_console.run_command('printenv slot_name')
+assert 'slot_name=b' in output
--
2.7.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
