Re: [U-Boot] [PATCH] fsl/usb: Workaround for USB erratum-A005275
Hi Chris, > On Friday, October 05, 2018 11:53 Chris Packham > wrote: > > On Thu, Oct 4, 2018 at 8:04 PM Marek Vasut wrote: > > > > On 10/04/2018 08:38 AM, Chris Packham wrote: > > > On Thu, Oct 4, 2018 at 11:17 AM Marek Vasut wrote: > > >> > > >> On 10/03/2018 10:21 PM, Chris Packham wrote: > > >>> Workaround makes FS as default mode on all affected socs. > > >>> > > >>> Add support to check erratum-A005275 validity for an soc. This > > >>> info is required to determine whether a given soc is affected by this > erratum. > > >>> Add quirk for this erratum "has_fsl_erratum_a005275" . This quirk > > >>> is used to enable workaround for the errata > > >>> > > >>> Force FS mode as default by: > > >>> - making EPS as FS > > >>> - setting PFSC bit to disable HS chirping > > >>> > > >>> This workaround can be disabled by mentioning > "no_erratum_a005275" > > >>> in hwconfig string > > >>> > > >>> Signed-off-by: Chris Packham > > >> [...] > > >> > > >>> diff --git a/drivers/usb/host/ehci-fsl.c > > >>> b/drivers/usb/host/ehci-fsl.c index a04f6a31c8e4..71e4ded53100 > > >>> 100644 > > >>> --- a/drivers/usb/host/ehci-fsl.c > > >>> +++ b/drivers/usb/host/ehci-fsl.c > > >>> @@ -93,6 +93,7 @@ static int ehci_fsl_probe(struct udevice *dev) > > >>> struct usb_ehci *ehci = NULL; > > >>> struct ehci_hccr *hccr; > > >>> struct ehci_hcor *hcor; > > >>> + struct ehci_ctrl *echi_ctrl = &priv->echi; > > >> > > >> Was this ever even compile-tested ? See echi_ctrl vs ehci_ctrl below ... > > >> > > > > > > I must confess no. The only targets that use this with DM_USB are > > > ARMv8 and I didn't have a toolchain for that. I did test P2040RDB. I > > > will fire the next version through travis-ci to catch dumb errors > > > like this. > > > > You can create a repo on github and enable travis to do CI on your > > patches every time you push. It has toolchains for all platform > > supported by U-Boot. > > Thanks I've got travis setup now[1]. But it probably wouldn't help for this > particular case. I'm struggling to find a target that configures > CONFIG_USB_EHCI_FSL and CONFIG_DM_USB in master (I think there might > be some ppc/mpc85xx work in flight). I did manage to enable EHCI_FSL on > ls1021aqds_nor_defconfig that showed the error which I've fixed in v2. Maybe you can try T1042D4RDB_defconfig or P2020RDB-PC_defconfig, according my work log, they will select CONFIG_USB_EHCI_FSL and CONFIG_DM_USB. Regards, Ran ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 3/9] dm: uclass: Add uclass_foreach_dev_probe
Hi Patrice, On Tue, Oct 9, 2018 at 9:41 PM Patrice Chotard wrote: > > Add uclass_foreach_dev_probe() which iterates through > devices of a given uclass. Devices are probed if necessary > and are ready to use. > > Signed-off-by: Patrice Chotard > Reviewed-by: Simon Glass > --- > > Changes in v3: None > Changes in v2: None > > include/dm/uclass.h | 16 > 1 file changed, 16 insertions(+) > > diff --git a/include/dm/uclass.h b/include/dm/uclass.h > index 6e7c1cd3e8bc..10ccfdce951e 100644 > --- a/include/dm/uclass.h > +++ b/include/dm/uclass.h > @@ -376,4 +376,20 @@ int uclass_resolve_seq(struct udevice *dev); > #define uclass_foreach_dev_safe(pos, next, uc) \ > list_for_each_entry_safe(pos, next, &uc->dev_head, uclass_node) > > +/** > + * uclass_foreach_dev_probe() - Helper function to iteration through devices > + * of given uclass > + * > + * This creates a for() loop which works through the available devices in > + * a uclass in order from start to end. Devices are probed if necessary, > + * and ready for use. > + * > + * @id: Uclass ID > + * @dev: struct udevice * to hold the current device. Set to NULL when there > + * are no more devices. > + */ > +#define uclass_foreach_dev_probe(id, dev) \ > + for (uclass_first_device(id, &dev); dev; \ > +uclass_next_device(&dev)) Shouldn't we check the return value of uclass_first_device() and uclass_next_device()? > + > #endif Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 02/27] dm: Add a new uclass driver for VirtIO transport devices
Hi Simon,
On Thu, Sep 27, 2018 at 9:42 PM Simon Glass wrote:
>
> Hi Bin,
>
> On 23 September 2018 at 06:42, Bin Meng wrote:
> > This adds a new virtio uclass driver for “virtio” [1] family of
> > devices that are are found in virtual environments like QEMU,
> > yet by design they look like physical devices to the guest.
> >
> > The uclass driver provides child_pre_probe() and child_post_probe()
> > methods to do some common operations for virtio device drivers like
> > device and driver supported feature negotiation, etc.
> >
> > [1] http://docs.oasis-open.org/virtio/virtio/v1.0/virtio-v1.0.pdf
>
> Can you add this link to the header file too? This seems to be lacking
> docs.in the source code. Also in a header file, a short statement of
> what virtio is for would be good.
>
Will add the link and a short statement for VirtIO in virtio.h,
virtio-uclass.c and driver/virtio/Kconfig in v2.
> >
> > Signed-off-by: Tuomas Tynkkynen
> > Signed-off-by: Bin Meng
> > ---
> >
> > drivers/Kconfig| 2 +
> > drivers/Makefile | 1 +
> > drivers/virtio/Kconfig | 14 +
> > drivers/virtio/Makefile| 6 +
> > drivers/virtio/virtio-uclass.c | 333
> > include/dm/uclass-id.h | 1 +
> > include/virtio.h | 694
> > +
> > include/virtio_types.h | 24 ++
> > 8 files changed, 1075 insertions(+)
> > create mode 100644 drivers/virtio/Kconfig
> > create mode 100644 drivers/virtio/Makefile
> > create mode 100644 drivers/virtio/virtio-uclass.c
> > create mode 100644 include/virtio.h
> > create mode 100644 include/virtio_types.h
> >
> > diff --git a/drivers/Kconfig b/drivers/Kconfig
> > index 56536c4..d40db0d 100644
> > --- a/drivers/Kconfig
> > +++ b/drivers/Kconfig
> > @@ -106,6 +106,8 @@ source "drivers/usb/Kconfig"
> >
> > source "drivers/video/Kconfig"
> >
> > +source "drivers/virtio/Kconfig"
> > +
> > source "drivers/watchdog/Kconfig"
> >
> > config PHYS_TO_BUS
> > diff --git a/drivers/Makefile b/drivers/Makefile
> > index 23ea609..f09daae 100644
> > --- a/drivers/Makefile
> > +++ b/drivers/Makefile
> > @@ -14,6 +14,7 @@ obj-$(CONFIG_$(SPL_TPL_)SERIAL_SUPPORT) += serial/
> > obj-$(CONFIG_$(SPL_TPL_)SPI_FLASH_SUPPORT) += mtd/spi/
> > obj-$(CONFIG_$(SPL_TPL_)SPI_SUPPORT) += spi/
> > obj-$(CONFIG_$(SPL_TPL_)TIMER) += timer/
> > +obj-$(CONFIG_$(SPL_TPL_)VIRTIO) += virtio/
> > obj-$(CONFIG_$(SPL_)DM_MAILBOX) += mailbox/
> > obj-$(CONFIG_$(SPL_)REMOTEPROC) += remoteproc/
> >
> > diff --git a/drivers/virtio/Kconfig b/drivers/virtio/Kconfig
> > new file mode 100644
> > index 000..bdfa96a
> > --- /dev/null
> > +++ b/drivers/virtio/Kconfig
> > @@ -0,0 +1,14 @@
> > +# SPDX-License-Identifier: GPL-2.0+
> > +#
> > +# Copyright (C) 2018, Tuomas Tynkkynen
> > +# Copyright (C) 2018, Bin Meng
> > +
> > +menu "VirtIO Drivers"
> > +
> > +config VIRTIO
> > + bool
> > + help
> > + This option is selected by any driver which implements the virtio
> > + bus, such as CONFIG_VIRTIO_MMIO or CONFIG_VIRTIO_PCI.
>
> What is a virtio bus?
>
Change to transport in v2, as suggested by Tuomas.
> > +
> > +endmenu
> > diff --git a/drivers/virtio/Makefile b/drivers/virtio/Makefile
> > new file mode 100644
> > index 000..23e7be7
> > --- /dev/null
> > +++ b/drivers/virtio/Makefile
> > @@ -0,0 +1,6 @@
> > +# SPDX-License-Identifier: GPL-2.0+
> > +#
> > +# Copyright (C) 2018, Tuomas Tynkkynen
> > +# Copyright (C) 2018, Bin Meng
> > +
> > +obj-y += virtio-uclass.o
> > diff --git a/drivers/virtio/virtio-uclass.c b/drivers/virtio/virtio-uclass.c
> > new file mode 100644
> > index 000..1c85856
> > --- /dev/null
> > +++ b/drivers/virtio/virtio-uclass.c
> > @@ -0,0 +1,333 @@
> > +// SPDX-License-Identifier: GPL-2.0+
> > +/*
> > + * Copyright (C) 2018, Tuomas Tynkkynen
> > + * Copyright (C) 2018, Bin Meng
> > + */
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +static const char *const virtio_drv_name[VIRTIO_ID_MAX_NUM] = {
> > + [VIRTIO_ID_NET] = VIRTIO_NET_DRV_NAME,
> > + [VIRTIO_ID_BLOCK] = VIRTIO_BLK_DRV_NAME,
> > +};
> > +
> > +int virtio_get_config(struct udevice *vdev, unsigned int offset,
> > + void *buf, unsigned int len)
> > +{
> > + struct dm_virtio_ops *ops;
> > +
> > + ops = virtio_get_ops(vdev->parent);
> > + if (!ops->get_config)
> > + return -ENOSYS;
>
> blank line before return (fix globally)
>
Fixed this in v2. However as Tuomas suggested, I added another check
in the uclass' pre_probe method to check these ops once and for all so
most of these checks here are unnecessary in v2.
> > + return ops->get_config(vdev->parent, offset, buf, len);
> > +}
> > +
> > +int virtio_set_config(struct udevice *vdev, unsigned int offset,
> > + void *buf, unsigned int len)
> > +{
> > + struct dm_virtio_ops *ops;
>
Re: [U-Boot] [PATCH 02/27] dm: Add a new uclass driver for VirtIO transport devices
Hi Tuomas,
On Fri, Sep 28, 2018 at 6:10 AM Tuomas Tynkkynen
wrote:
>
> Hi Bin,
>
> Thanks for the patches, they look great. Some minor comments:
>
> On 09/23/2018 04:42 PM, Bin Meng wrote:
> > This adds a new virtio uclass driver for “virtio” [1] family of
> > devices that are are found in virtual environments like QEMU,
> > yet by design they look like physical devices to the guest.
> >
> > The uclass driver provides child_pre_probe() and child_post_probe()
> > methods to do some common operations for virtio device drivers like
> > device and driver supported feature negotiation, etc.
> >
> > [1] http://docs.oasis-open.org/virtio/virtio/v1.0/virtio-v1.0.pdf
> >
> > Signed-off-by: Tuomas Tynkkynen
> > Signed-off-by: Bin Meng
> > ---...
> >+
> >+config VIRTIO
> >+ bool
> >+ help
> >+This option is selected by any driver which implements the virtio
> >+bus, such as CONFIG_VIRTIO_MMIO or CONFIG_VIRTIO_PCI.
>
> I think most other places use the term 'transport' over 'bus'.
>
Changed in v2.
> > +
> > +int virtio_get_config(struct udevice *vdev, unsigned int offset,
> > + void *buf, unsigned int len)
> > +{
> > + struct dm_virtio_ops *ops;
> > +
> > + ops = virtio_get_ops(vdev->parent);
> > + if (!ops->get_config)
> > + return -ENOSYS;
>
> I'm not sure how useful the -ENOSYS fallbacks for most of these ops
> are. E.g. a transport lacking .find_vqs() cannot ever be useful
> for implementing real-world devices.
>
Agreed. Address this in v2.
Regards,
Bin
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] mtd: nand: let the raw NAND devices be compiled upon selection
Today way is to rely on CMD_NAND to be selected and from the root Makefile compile what is in drivers/mtd/nand/raw. While this will work most of the time with decent configurations, it is better to also compile this subsystem upon simple request in the configuration. Otherwise, a user not selecting CMD_NAND but selecting NAND and any of the controller drivers will not see their build. Fix this weird situation by adding a single line in the nand/ directory Kconfig file. Signed-off-by: Miquel Raynal --- drivers/mtd/nand/Makefile | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/mtd/nand/Makefile b/drivers/mtd/nand/Makefile index a358bc680e..2c33447995 100644 --- a/drivers/mtd/nand/Makefile +++ b/drivers/mtd/nand/Makefile @@ -2,4 +2,5 @@ nandcore-objs := core.o bbt.o obj-$(CONFIG_MTD_NAND_CORE) += nandcore.o +obj-$(CONFIG_NAND) += raw/ obj-$(CONFIG_MTD_SPI_NAND) += spi/ -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [BUG] efi-x86_app_defconfig does not build with gcc 8.2
On Tue, Oct 09, 2018 at 07:28:36AM +0800, Bin Meng wrote:
> Hi Andy,
>
> On Tue, Oct 9, 2018 at 12:31 AM Andy Shevchenko
> wrote:
> >
> > On Mon, Oct 08, 2018 at 11:31:32PM +0800, Bin Meng wrote:
> > > +Andy
> > >
> > > On Sat, Sep 8, 2018 at 5:00 PM Heinrich Schuchardt
> > > wrote:
> > > >
> > > > make mrproper && make efi-x86_app_defconfig && make
> > > >
> > > > results in
> > > >
> > > > CC common/image.o
> > > > {standard input}: Assembler messages:
> > > > {standard input}:21662: Error: junk at end of line, first unrecognized
> > > > character is `@'
> > > > {standard input}:21707: Error: junk at end of line, first unrecognized
> > > > character is `@'
> > > > {standard input}:21662: Error: can't resolve `end.6878'
> > > > {.u_boot_list_2_fit_loadable_3 section} - `start.6875'
> > > > {.u_boot_list_2_fit_loadable_1 section}
> > > > {standard input}:21707: Error: can't resolve `end.6878'
> > > > {.u_boot_list_2_fit_loadable_3 section} - `start.6875'
> > > > {.u_boot_list_2_fit_loadable_1 section}
> > > >
> > > > I am using Debian Buster with gcc-8.2.0.
> > > >
> > > > Building with gcc-7.3.0 works fine.
> > > >
> > > > We had a similar issue for qemu-x86_defconfig in
> > > > https://lists.denx.de/pipermail/u-boot/2018-July/336393.html
> > > > which has been resolved.
> > >
> > > I can reproduce this with kernel.org GCC 8.1.0 toolchain now. But I
> > > have no idea how this error is related to anything. Andy may have some
> > > idea.
> >
> > Does below fixes the issue (check also if the resulting binary runs)?
> >
> > --- a/arch/x86/config.mk
> > +++ b/arch/x86/config.mk
> > @@ -41,7 +41,7 @@ OBJCOPYFLAGS_EFI := -j .text -j .sdata -j .data -j
> > .dynamic -j .dynsym \
> > ifeq ($(IS_32BIT),y)
> > CFLAGS_NON_EFI := -mregparm=3
> > endif
> > -CFLAGS_EFI := -fpic -fshort-wchar
> > +CFLAGS_EFI := -fshort-wchar
> >
>
> Thanks for checking. I tried this but the resulted binary does not
> boot. Hangs at "U-Boot EFI " and no console output anymore.
That's what I was suspecting after looking how EFI applications are being built.
So, someone familiar with compilers probably needs to check the following and
act accordingly:
- either new compiler provides new switches to change behaviour as it was in
GCC < 8, or
- create a small verifiable example with this linked list sections and submit a
bug report to GCC, or
- U-Boot code (for linked lists) should be reconsidered from new requirements
of the compiler, or
- EFI U-Boot application should have it's own relocation code (like normal
U-Boot does), or
- ...anything I missed...
The issue from my limited knowledge looks like this:
EFI loader relies on the sections that are natural for dynamically linked
libraries (AKA .so), while U-Boot (when runs on bare metal) has another
approach, i.e. specific code that does a relocation based only on .reloc
information. The linked list sections in U-Boot are meant to be statically
compiled, which is not the case for EFI by some reason.
OTOH, it's clearly a compiler behaviour change, since with -fPIC -g it
generates DWARF that can't be translated by its own assembler!
(See option 2 in above list)
--
With Best Regards,
Andy Shevchenko
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] i2c: fix: Add support for the Arm's Versatile Express I2C controller
On Thu, Oct 11, 2018 at 07:26:33AM +0200, Heiko Schocher wrote: > accidentially while fixing merge errors for patch: > https://lists.denx.de/pipermail/u-boot/2018-September/342278.html > > missed to add files: > > MAINTAINERS > drivers/i2c/Kconfig > drivers/i2c/Makefile > > add them with this patch. > > Signed-off-by: Heiko Schocher Acked-by: Liviu Dudau > --- > > MAINTAINERS | 1 + > drivers/i2c/Kconfig | 7 +++ > drivers/i2c/Makefile | 1 + > 3 files changed, 9 insertions(+) > > diff --git a/MAINTAINERS b/MAINTAINERS > index ace7d9a4b6..cc71a8f6be 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -453,6 +453,7 @@ M:Liviu Dudau > S: Supported > T: git git://github.com/ARM-software/u-boot.git > F: drivers/video/mali_dp.c > +F: drivers/i2c/i2c-versatile.c > > MICROBLAZE > M: Michal Simek > diff --git a/drivers/i2c/Kconfig b/drivers/i2c/Kconfig > index ae3b501555..1ef22e6bcd 100644 > --- a/drivers/i2c/Kconfig > +++ b/drivers/i2c/Kconfig > @@ -416,6 +416,13 @@ config SYS_I2C_UNIPHIER_F > Support for UniPhier FIFO-builtin I2C controller driver. > This I2C controller is used on PH1-Pro4 or newer UniPhier SoCs. > > +config SYS_I2C_VERSATILE > + bool "Arm Ltd Versatile I2C bus driver" > + depends on DM_I2C && (TARGET_VEXPRESS_CA15_TC2 || > TARGET_VEXPRESS64_JUNO) > + help > + Add support for the Arm Ltd Versatile Express I2C driver. The I2C host > + controller is present in the development boards manufactured by Arm > Ltd. > + > config SYS_I2C_MVTWSI > bool "Marvell I2C driver" > depends on DM_I2C > diff --git a/drivers/i2c/Makefile b/drivers/i2c/Makefile > index f2cbe78c53..d3637bcd8d 100644 > --- a/drivers/i2c/Makefile > +++ b/drivers/i2c/Makefile > @@ -36,6 +36,7 @@ obj-$(CONFIG_SYS_I2C_STM32F7) += stm32f7_i2c.o > obj-$(CONFIG_SYS_I2C_TEGRA) += tegra_i2c.o > obj-$(CONFIG_SYS_I2C_UNIPHIER) += i2c-uniphier.o > obj-$(CONFIG_SYS_I2C_UNIPHIER_F) += i2c-uniphier-f.o > +obj-$(CONFIG_SYS_I2C_VERSATILE) += i2c-versatile.o > obj-$(CONFIG_SYS_I2C_ZYNQ) += zynq_i2c.o > obj-$(CONFIG_TEGRA186_BPMP_I2C) += tegra186_bpmp_i2c.o > > -- > 2.14.4 > -- | I would like to | | fix the world, | | but they're not | | giving me the | \ source code! / --- ¯\_(ツ)_/¯ ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 03/27] virtio: Add codes for virtual queue/ring management
Hi Simon, On Thu, Sep 27, 2018 at 9:42 PM Simon Glass wrote: > > On 23 September 2018 at 06:42, Bin Meng wrote: > > From: Tuomas Tynkkynen > > > > This adds support for managing virtual queue/ring, the channel > > for high performance I/O between host and guest. > > > > Signed-off-by: Tuomas Tynkkynen > > Signed-off-by: Bin Meng > > --- > > > > drivers/virtio/Makefile | 2 +- > > drivers/virtio/virtio_ring.c | 356 > > +++ > > include/virtio_ring.h| 320 ++ > > 3 files changed, 677 insertions(+), 1 deletion(-) > > create mode 100644 drivers/virtio/virtio_ring.c > > create mode 100644 include/virtio_ring.h > > Seems like vring_create_virtqueue() should return an error code rather > than a pointer? I think NULL as a pointer can be a sign for the error. > > Reviewed-by: Simon Glass Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] axs10x/emdk/hsdk/iot_dk: Implement board_mmc_getcd()
So now we may detect MMC/SD-card existence and
instead of completely misleading message on missing card:
>8---
Loading Environment from FAT... Card did not respond to voltage select!
>8---
we now get very clear one:
>8---
Loading Environment from FAT... MMC: no card present
>8---
Signed-off-by: Alexey Brodkin
---
board/synopsys/axs10x/axs10x.c | 7 +++
board/synopsys/emdk/emdk.c | 7 +++
board/synopsys/hsdk/hsdk.c | 7 +++
board/synopsys/iot_devkit/iot_devkit.c | 7 +++
4 files changed, 28 insertions(+)
diff --git a/board/synopsys/axs10x/axs10x.c b/board/synopsys/axs10x/axs10x.c
index af78127..c95f7af 100644
--- a/board/synopsys/axs10x/axs10x.c
+++ b/board/synopsys/axs10x/axs10x.c
@@ -33,6 +33,13 @@ int board_mmc_init(bd_t *bis)
return 0;
}
+int board_mmc_getcd(struct mmc *mmc)
+{
+ struct dwmci_host *host = mmc->priv;
+
+ return !(dwmci_readl(host, DWMCI_CDETECT) & 1);
+}
+
#define AXS_MB_CREG0xE0011000
int board_early_init_f(void)
diff --git a/board/synopsys/emdk/emdk.c b/board/synopsys/emdk/emdk.c
index bbb946a..79cafef 100644
--- a/board/synopsys/emdk/emdk.c
+++ b/board/synopsys/emdk/emdk.c
@@ -34,6 +34,13 @@ int board_mmc_init(bd_t *bis)
return 0;
}
+int board_mmc_getcd(struct mmc *mmc)
+{
+ struct dwmci_host *host = mmc->priv;
+
+ return !(dwmci_readl(host, DWMCI_CDETECT) & 1);
+}
+
#define CREG_BASE 0xF0001000
#define CREG_BOOT_OFFSET 0
#define CREG_BOOT_WP_OFFSET8
diff --git a/board/synopsys/hsdk/hsdk.c b/board/synopsys/hsdk/hsdk.c
index 4f46d2e..b6aefdb 100644
--- a/board/synopsys/hsdk/hsdk.c
+++ b/board/synopsys/hsdk/hsdk.c
@@ -1019,6 +1019,13 @@ int board_late_init(void)
return 0;
}
+int board_mmc_getcd(struct mmc *mmc)
+{
+ struct dwmci_host *host = mmc->priv;
+
+ return !(dwmci_readl(host, DWMCI_CDETECT) & 1);
+}
+
int board_mmc_init(bd_t *bis)
{
struct dwmci_host *host = NULL;
diff --git a/board/synopsys/iot_devkit/iot_devkit.c
b/board/synopsys/iot_devkit/iot_devkit.c
index 40c29e7..f8838fb 100644
--- a/board/synopsys/iot_devkit/iot_devkit.c
+++ b/board/synopsys/iot_devkit/iot_devkit.c
@@ -170,6 +170,13 @@ int board_mmc_init(bd_t *bis)
return 0;
}
+int board_mmc_getcd(struct mmc *mmc)
+{
+ struct dwmci_host *host = mmc->priv;
+
+ return !(dwmci_readl(host, DWMCI_CDETECT) & 1);
+}
+
#define IOTDK_RESET_SEQ0x55AA6699
void reset_cpu(ulong addr)
--
2.7.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/4] scsi: ceva: add ls1046a soc support
Add ahci compatible support for ls1046a soc.
Signed-off-by: Peng Ma
---
drivers/ata/sata_ceva.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/drivers/ata/sata_ceva.c b/drivers/ata/sata_ceva.c
index 65896d1..a2d21d9 100644
--- a/drivers/ata/sata_ceva.c
+++ b/drivers/ata/sata_ceva.c
@@ -99,6 +99,7 @@ enum ceva_soc {
CEVA_LS1012A,
CEVA_LS1021A,
CEVA_LS1043A,
+ CEVA_LS1046A,
};
struct ceva_sata_priv {
@@ -138,6 +139,7 @@ static int ceva_init_sata(struct ceva_sata_priv *priv)
case CEVA_LS1012A:
case CEVA_LS1043A:
+ case CEVA_LS1046A:
writel(ECC_DIS_ADDR_CH2, ECC_DIS_VAL_CH2);
writel(CEVA_PHY1_CFG, base + AHCI_VEND_PPCFG);
writel(CEVA_TRANS_CFG, base + AHCI_VEND_PTC);
@@ -170,6 +172,7 @@ static const struct udevice_id sata_ceva_ids[] = {
{ .compatible = "fsl,ls1012a-ahci", .data = CEVA_LS1012A },
{ .compatible = "fsl,ls1021a-ahci", .data = CEVA_LS1021A },
{ .compatible = "fsl,ls1043a-ahci", .data = CEVA_LS1043A },
+ { .compatible = "fsl,ls1046a-ahci", .data = CEVA_LS1046A },
{ }
};
--
1.7.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 2/4] armv8: dts: fsl-ls1046a: add sata node support
One ls1046a, there is one SATA 3.0 advanced host controller interface
which is a high-performance SATA solution that delivers comprehensive
and fully-compliant generation 3 (1.5 Gb/s - 6.0 Gb/s) serial ATA
capabilities, in accordance with the serial ATA revision 3.0 of Serial
ATA International Organization.
Add sata node to support this feature.
Signed-off-by: Peng Ma
---
arch/arm/dts/fsl-ls1046a-qds.dtsi |4
arch/arm/dts/fsl-ls1046a-rdb.dts |4
arch/arm/dts/fsl-ls1046a.dtsi |8
3 files changed, 16 insertions(+), 0 deletions(-)
diff --git a/arch/arm/dts/fsl-ls1046a-qds.dtsi
b/arch/arm/dts/fsl-ls1046a-qds.dtsi
index ba36853..ada8a85 100644
--- a/arch/arm/dts/fsl-ls1046a-qds.dtsi
+++ b/arch/arm/dts/fsl-ls1046a-qds.dtsi
@@ -76,3 +76,7 @@
&lpuart0 {
status = "okay";
};
+
+&sata {
+ status = "okay";
+};
diff --git a/arch/arm/dts/fsl-ls1046a-rdb.dts b/arch/arm/dts/fsl-ls1046a-rdb.dts
index 136de24..ba30fd2 100644
--- a/arch/arm/dts/fsl-ls1046a-rdb.dts
+++ b/arch/arm/dts/fsl-ls1046a-rdb.dts
@@ -39,3 +39,7 @@
reg = <1>;
};
};
+
+&sata {
+ status = "okay";
+};
diff --git a/arch/arm/dts/fsl-ls1046a.dtsi b/arch/arm/dts/fsl-ls1046a.dtsi
index 7687d12..5ac10e0 100644
--- a/arch/arm/dts/fsl-ls1046a.dtsi
+++ b/arch/arm/dts/fsl-ls1046a.dtsi
@@ -291,5 +291,13 @@
ranges = <0x8100 0x0 0x 0x50 0x0002 0x0
0x0001 /* downstream I/O */
0x8200 0x0 0x4000 0x50 0x4000 0x0
0x4000>; /* non-prefetchable memory */
};
+
+ sata: sata@320 {
+ compatible = "fsl,ls1046a-ahci";
+ reg = <0x0 0x320 0x0 0x1>;
+ interrupts = <0 69 4>;
+ clocks = <&clockgen 4 1>;
+ status = "disabled";
+ };
};
};
--
1.7.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 4/4] arm64: ls1046aqds: enable DM support for sata
Enable related configs to support sata DM feature. Signed-off-by: Peng Ma --- configs/ls1046aqds_defconfig |5 + 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/configs/ls1046aqds_defconfig b/configs/ls1046aqds_defconfig index fad2eed..b09fc88 100644 --- a/configs/ls1046aqds_defconfig +++ b/configs/ls1046aqds_defconfig @@ -51,3 +51,8 @@ CONFIG_USB_XHCI_DWC3=y CONFIG_USB_STORAGE=y CONFIG_BLK=y CONFIG_DM_MMC=y +CONFIG_DM_SCSI=y +CONFIG_SATA_CEVA=y +CONFIG_SCSI_AHCI=y +CONFIG_SCSI=y +CONFIG_AHCI=y -- 1.7.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 3/4] arm64: ls1046ardb: enable DM support for sata
Enable related configs to support sata DM feature. Signed-off-by: Peng Ma --- configs/ls1046ardb_qspi_defconfig |5 + 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/configs/ls1046ardb_qspi_defconfig b/configs/ls1046ardb_qspi_defconfig index f9660c0..ea2cbb3 100644 --- a/configs/ls1046ardb_qspi_defconfig +++ b/configs/ls1046ardb_qspi_defconfig @@ -48,3 +48,8 @@ CONFIG_USB_XHCI_DWC3=y CONFIG_USB_STORAGE=y CONFIG_BLK=y CONFIG_DM_MMC=y +CONFIG_DM_SCSI=y +CONFIG_SATA_CEVA=y +CONFIG_SCSI_AHCI=y +CONFIG_SCSI=y +CONFIG_AHCI=y -- 1.7.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2] efi_loader: set image_base and image_size to correct values
Currently, image's image_base points to an address where the image was
temporarily uploaded for further loading. Since efi_loader relocates
the image to final destination, image_base and image_size should reflect
that.
This bug was detected in UEFI SCT, "Loaded Image Protocol Test - test 2,"
which shows that 'Unload' function doesn't fit into a range suggested by
image_base and image_size.
TestCase/UEFI/EFI/Protocol/LoadedImage/BlackBoxTest/
LoadedImageBBTestMain.c:1002
Changes in this patch also includes:
* reverts a patch, "efi_loader: save image relocation address
and size" since newly added fields are no longer needed.
* copy PE headers as well since those information will be needed
for module loading, in particular, at gurb.
(This bug was reported by Heinrich.)
Signed-off-by: AKASHI Takahiro
Reported-by: Heinrich Schuchardt
---
lib/efi_loader/efi_image_loader.c | 22 +++---
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/lib/efi_loader/efi_image_loader.c
b/lib/efi_loader/efi_image_loader.c
index a18ce0a5705e..d1b6c0d3cdf2 100644
--- a/lib/efi_loader/efi_image_loader.c
+++ b/lib/efi_loader/efi_image_loader.c
@@ -59,10 +59,10 @@ static efi_status_t efi_print_image_info(struct
efi_loaded_image_obj *obj,
{
printf("UEFI image");
printf(" [0x%p:0x%p]",
- obj->reloc_base, obj->reloc_base + obj->reloc_size - 1);
- if (pc && pc >= obj->reloc_base &&
- pc < obj->reloc_base + obj->reloc_size)
- printf(" pc=0x%zx", pc - obj->reloc_base);
+ image->image_base, image->image_base + image->image_size - 1);
+ if (pc && pc >= image->image_base &&
+ pc < image->image_base + image->image_size)
+ printf(" pc=0x%zx", pc - image->image_base);
if (image->file_path)
printf(" '%pD'", image->file_path);
printf("\n");
@@ -212,7 +212,6 @@ void *efi_load_pe(struct efi_loaded_image_obj *handle, void
*efi,
int rel_idx = IMAGE_DIRECTORY_ENTRY_BASERELOC;
void *entry;
uint64_t image_base;
- uint64_t image_size;
unsigned long virt_size = 0;
int supported = 0;
@@ -256,7 +255,6 @@ void *efi_load_pe(struct efi_loaded_image_obj *handle, void
*efi,
IMAGE_NT_HEADERS64 *nt64 = (void *)nt;
IMAGE_OPTIONAL_HEADER64 *opt = &nt64->OptionalHeader;
image_base = opt->ImageBase;
- image_size = opt->SizeOfImage;
efi_set_code_and_data_type(loaded_image_info, opt->Subsystem);
efi_reloc = efi_alloc(virt_size,
loaded_image_info->image_code_type);
@@ -272,7 +270,6 @@ void *efi_load_pe(struct efi_loaded_image_obj *handle, void
*efi,
} else if (nt->OptionalHeader.Magic == IMAGE_NT_OPTIONAL_HDR32_MAGIC) {
IMAGE_OPTIONAL_HEADER32 *opt = &nt->OptionalHeader;
image_base = opt->ImageBase;
- image_size = opt->SizeOfImage;
efi_set_code_and_data_type(loaded_image_info, opt->Subsystem);
efi_reloc = efi_alloc(virt_size,
loaded_image_info->image_code_type);
@@ -291,6 +288,11 @@ void *efi_load_pe(struct efi_loaded_image_obj *handle,
void *efi,
return NULL;
}
+ /* Copy PE headers */
+ memcpy(efi_reloc, efi, sizeof(*dos) + sizeof(*nt)
+ + nt->FileHeader.SizeOfOptionalHeader
+ + num_sections * sizeof(IMAGE_SECTION_HEADER));
+
/* Load sections into RAM */
for (i = num_sections - 1; i >= 0; i--) {
IMAGE_SECTION_HEADER *sec = §ions[i];
@@ -315,10 +317,8 @@ void *efi_load_pe(struct efi_loaded_image_obj *handle,
void *efi,
invalidate_icache_all();
/* Populate the loaded image interface bits */
- loaded_image_info->image_base = efi;
- loaded_image_info->image_size = image_size;
- handle->reloc_base = efi_reloc;
- handle->reloc_size = virt_size;
+ loaded_image_info->image_base = efi_reloc;
+ loaded_image_info->image_size = virt_size;
return entry;
}
--
2.19.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/1] cmd/bdinfo: correct output of numerical values
Display all digits on 64bit systems. Currently we print only the lower
32 bits. Examples of values that can exceed 32 bits are the size and start of
memory banks.
For fdt_blob use the same output method as for other values. This avoids
misalignment.
Signed-off-by: Heinrich Schuchardt
---
cmd/bdinfo.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/cmd/bdinfo.c b/cmd/bdinfo.c
index 60b438766d..cbeba6ba28 100644
--- a/cmd/bdinfo.c
+++ b/cmd/bdinfo.c
@@ -16,7 +16,7 @@ DECLARE_GLOBAL_DATA_PTR;
__maybe_unused
static void print_num(const char *name, ulong value)
{
- printf("%-12s= 0x%08lX\n", name, value);
+ printf("%-12s= 0x%0*lx\n", name, 2 * (int)sizeof(value), value);
}
__maybe_unused
@@ -348,7 +348,7 @@ static int do_bdinfo(cmd_tbl_t *cmdtp, int flag, int argc,
CONFIG_VAL(SYS_MALLOC_F_LEN));
#endif
if (gd->fdt_blob)
- printf("fdt_blob = %p\n", gd->fdt_blob);
+ print_num("fdt_blob", (ulong)gd->fdt_blob);
return 0;
}
--
2.19.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 02/19] dm: i2c: Add dm_i2c_probe_device() to test the presence of a chip
Hi Simon,
thanks for the reviews.
On 11/10/2018 05:13, Simon Glass wrote:
Hi Jean-Jacques,
On 5 October 2018 at 10:45, Jean-Jacques Hiblot wrote:
In a non-DM environment, it is possible to test the presence of a chip
using i2c_probe(chip_addr).
dm_i2c_probe_device() brings the same functionality with a DM interface.
The intent is to be able to test the presence of a chip for the device has
been created with i2c_get_chip_for_busnum(bus_num, chip_addr, ...)
Signed-off-by: Jean-Jacques Hiblot
---
Changes in v2: None
drivers/i2c/i2c-uclass.c | 8
include/i2c.h| 13 +
2 files changed, 21 insertions(+)
diff --git a/drivers/i2c/i2c-uclass.c b/drivers/i2c/i2c-uclass.c
index c5a3c4e..ec88168 100644
--- a/drivers/i2c/i2c-uclass.c
+++ b/drivers/i2c/i2c-uclass.c
@@ -378,6 +378,14 @@ int dm_i2c_probe(struct udevice *bus, uint chip_addr, uint
chip_flags,
return ret;
}
+int dm_i2c_probe_device(struct udevice *dev)
+{
+ struct udevice *bus = dev_get_parent(dev);
+ struct dm_i2c_chip *chip = dev_get_parent_platdata(dev);
+
+ return i2c_probe_chip(bus, chip->chip_addr, chip->flags);
+}
Why not just probe the device? That should have the same effect.
The device itself is not probed when using i2c_get_chip_for_busnum(). I
could have changed it there but was sure about possible side-effects on
all boards.
The code that uses the non-DM API usually calls I2C_probe() at some
point, this function is the equivalent in the DM world.
JJ
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 18/20] spi: mtk_qspi: add qspi driver for MT7629 SoC
Hi Jagan, On Thu, 2018-10-04 at 21:31 +0530, Jagan Teki wrote: > On Tue, Oct 2, 2018 at 4:38 PM Ryder Lee wrote: > > > > From: Guochun Mao > > > > This patch adds MT7629 qspi driver for accessing SPI NOR flash. > > > > Cc: Jagan Teki > > Signed-off-by: Guochun Mao > > --- > > drivers/spi/Kconfig| 7 + > > drivers/spi/Makefile | 1 + > > drivers/spi/mtk_qspi.c | 406 > > + > > 3 files changed, 414 insertions(+) > > create mode 100644 drivers/spi/mtk_qspi.c > > > > + > > +/* NOR flash commands */ > > +#define MTK_QSPI_OP_WREN 0x6 > > +#define MTK_QSPI_OP_READ_QUAD 0x6B > > +#define MTK_QSPI_OP_READ_DUAL 0x3B > > +#define MTK_QSPI_OP_FAST_READ 0xB > > +#define MTK_QSPI_OP_READ 0x3 > > +#define MTK_QSPI_OP_PP 0x2 > > NAK, we don't allow flash commands in spi. Better handle via spi-mem > or flash side. I saw fsl_qspi.c also use flash commands to distinguish operations for different setting. Due to controller IP's design, Flash register access is different from data access for our controller IP, it has to set specific controller's registers for specific operation. It seems that spi-mem will not handle this issue, it's specific controller's business. About read flash register and read data, Could you give some suggestions about how to distinguish these two kinds of ops? so that we can do properly setting for controller. Could we implement this driver without considering 0x65/0x71 flash command those that will have address parameters? And it seems that, Uboot will not use quad read or dual read? BR, Guochun ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] ARM: imx6: DHCOM i.MX6 PDK: ddr init for 32bit bus and 4GBit chips
Hello Marek,
>> From: Ludwig Zenz
>>
>> Support 1GIB + 2GIB DDR3 with 64bit bus width and 512MIB + 1GIB with 32bit
>> bus width
>>
>> Signed-off-by: Ludwig Zenz
>> ---
>> board/dhelectronics/dh_imx6/dh_imx6_spl.c | 191
>> +++---
>> 1 file changed, 173 insertions(+), 18 deletions(-)
>>
>> diff --git a/board/dhelectronics/dh_imx6/dh_imx6_spl.c
>> b/board/dhelectronics/dh_imx6/dh_imx6_spl.c
> [...]
>
> This patch causes memory instability on 1GiB MX6Q part.
>
> Can you check that and fix it ? Thanks.
Can you tell me more about the error? How do you test this? Did you run a git
bisect?
We did tests in a climate chamber with this configuration (with the MX6Q and
all others).
I think there is only one change that could make a difference:
static const struct mx6_ddr3_cfg dhcom_mem_ddr_2g = {
...
- .trcd = 1312,
+ .trcd = 1375,
Best Regards,
Ludwig Zenz
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] efi_loader: PSCI reset and shutdown for EL1
On Thu, 11 Oct 2018 at 08:56, Heinrich Schuchardt wrote:
>
> When starting an aarch64 system under QEMU it runs in EL1/EL0. So we have
> to use HVC for PSCI calls.
>
> Without the patch resetting Linux started with bootefi under
> qemu-system-aarch64 results in a crash.
>
> Signed-off-by: Heinrich Schuchardt
> ---
> arch/arm/cpu/armv8/fwcall.c | 14 +-
> 1 file changed, 9 insertions(+), 5 deletions(-)
>
I too was facing this crash and got it fixed before I saw this patch today.
Tested-by: Sumit Garg
> diff --git a/arch/arm/cpu/armv8/fwcall.c b/arch/arm/cpu/armv8/fwcall.c
> index 0ba3dad8cc..f1b6e60bae 100644
> --- a/arch/arm/cpu/armv8/fwcall.c
> +++ b/arch/arm/cpu/armv8/fwcall.c
> @@ -78,12 +78,10 @@ void __efi_runtime smc_call(struct pt_regs *args)
> }
>
> /*
> - * For now, all systems we support run at least in EL2 and thus
> - * trigger PSCI calls to EL3 using SMC. If anyone ever wants to
> - * use PSCI on U-Boot running below a hypervisor, please detect
> - * this and set the flag accordingly.
> + * This flag controls if SMC or HVC is used to call PSCI services. If U-Boot
> has
> + * been called by a hypervisor (e.g. QEMU), it has to be set to false.
> */
> -static const __efi_runtime_data bool use_smc_for_psci = true;
> +static __efi_runtime_data bool use_smc_for_psci = true;
>
> void __noreturn __efi_runtime psci_system_reset(void)
> {
> @@ -138,6 +136,12 @@ void reset_misc(void)
> }
>
> #ifdef CONFIG_EFI_LOADER
> +efi_status_t efi_reset_system_init(void)
> +{
> + use_smc_for_psci = (current_el() >= 2);
> + return EFI_SUCCESS;
> +}
> +
> void __efi_runtime EFIAPI efi_reset_system(
> enum efi_reset_type reset_type,
> efi_status_t reset_status,
> --
> 2.19.1
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 3/4] arm: socfpga: stratix10: Add Stratix10 FPGA into FPGA device table
On 10/11/2018 08:21 AM, Ang, Chee Hong wrote:
> On Wed, 2018-10-10 at 12:27 +0200, Marek Vasut wrote:
>> On 10/10/2018 07:30 AM, Ang, Chee Hong wrote:
>>>
>>> On Tue, 2018-10-09 at 14:48 +0200, Marek Vasut wrote:
On 10/09/2018 05:03 AM, Ang, Chee Hong wrote:
>
>
> On Mon, 2018-10-08 at 22:32 +0200, Marek Vasut wrote:
>>
>>
>> On 10/08/2018 05:10 PM, Ang, Chee Hong wrote:
>>>
>>>
>>>
>>> On Mon, 2018-10-08 at 11:57 +0200, Marek Vasut wrote:
On 10/08/2018 11:48 AM, chee.hong@intel.com wrote:
>
>
>
>
> From: "Ang, Chee Hong"
>
> Enable 'fpga' command in u-boot. User will be able to
> use
> the
> fpga
> command to program the FPGA on Stratix10 SoC.
>
> Signed-off-by: Ang, Chee Hong
> ---
> arch/arm/mach-socfpga/misc.c | 29
> +
> arch/arm/mach-socfpga/misc_s10.c | 2 ++
> drivers/fpga/altera.c| 6 ++
> include/altera.h | 4
> 4 files changed, 41 insertions(+)
>
> diff --git a/arch/arm/mach-socfpga/misc.c
> b/arch/arm/mach-
> socfpga/misc.c
> index a4f6d5c..7986b58 100644
> --- a/arch/arm/mach-socfpga/misc.c
> +++ b/arch/arm/mach-socfpga/misc.c
> @@ -88,6 +88,27 @@ int overwrite_console(void)
> #endif
>
> #ifdef CONFIG_FPGA
> +#ifdef CONFIG_FPGA_STRATIX10
> +/*
> + * FPGA programming support for SoC FPGA Stratix 10
> + */
> +static Altera_desc altera_fpga[] = {
> + {
> + /* Family */
> + Intel_FPGA_Stratix10,
> + /* Interface type */
> + secure_device_manager_mailbox,
> + /* No limitation as additional data
> will
> be
> ignored */
> + -1,
> + /* No device function table */
> + NULL,
> + /* Base interface address specified in
> driver
> */
> + NULL,
> + /* No cookie implementation */
> + 0
> + },
> +};
> +#else
> /*
> * FPGA programming support for SoC FPGA Cyclone V
> */
> @@ -107,6 +128,7 @@ static Altera_desc altera_fpga[] =
> {
> 0
> },
> };
> +#endif
>
> /* add device descriptor to FPGA device table */
> void socfpga_fpga_add(void)
> @@ -116,6 +138,13 @@ void socfpga_fpga_add(void)
> for (i = 0; i < ARRAY_SIZE(altera_fpga); i++)
> fpga_add(fpga_altera,
> &altera_fpga[i]);
> }
> +
> +#else
> +
> +__weak void socfpga_fpga_add(void)
> +{
> +}
Why is a __weak function defined only in else-statement ?
It should be defined always, with a sane default
implementation.
>>> I will remove the empty function in #else-statement and
>>> define
>>> the
>>> default function like this :
>>>
>>> /* add device descriptor to FPGA device table */
>>> void socfpga_fpga_add(void)
>>> {
>>> #ifdef CONFIG_FPGA
>>> int i;
>>> fpga_init();
>>> for (i = 0; i < ARRAY_SIZE(altera_fpga); i++)
>>> fpga_add(fpga_altera, &altera_fpga[i]);
>>> #endif
>>> }
>>>
>>> Is that OK?
>> Can't you have __weak empty implementation of
>> socfpga_fpga_add()
>> and
>> implement a version per platform ? Would that work and make
>> sense
>> ?
> socfpga_fpga_add() as shown above is a generic function for
> adding
> FPGA
> devices to FPGA driver which applies to all our platforms. This
> is
> the
> reason why it is defined in misc.c instead of
> misc_.c.
>
> It turned out we already have this defined in misc.h:
> #ifdef CONFIG_FPGA
> void socfpga_fpga_add(void);
> #else
> static inline void socfpga_fpga_add(void) {}
> #endif
Right, if you had one socfpga_fpga_add() per platform + generic
empty
one, you could drop that whole thing ^.
>>> Yes. It's being addressed in v3 patch:
>>> https://lists.denx.de/pipermail/u-boot/2018-October/343561.html
>> So where did the function go in there ? I don't see any __weak
>> anything.
> I don't have to add anything in my v3 patchsets to make this work.
> It's already taken care by arch/arm/mach-socfpga/include/mach/misc.h as
> shown below:
>
> #ifdef CONFIG_FPGA
> void socfpga_fpga_add(void);
> #else
> static inline void socfpga_fpga_add(void) {}
> #endif
>
> An empty default socfpga_fpga_a
Re: [U-Boot] [PATCH 3/3] ARM: imx6: DHCOM i.MX6 PDK: ddr init for 32bit bus and 4GBit chips
On 10/11/2018 09:09 AM, Ludwig Zenz wrote:
> Hello Marek,
Hello Ludwig,
>>> From: Ludwig Zenz
>>>
>>> Support 1GIB + 2GIB DDR3 with 64bit bus width and 512MIB + 1GIB with 32bit
>>> bus width
>>>
>>> Signed-off-by: Ludwig Zenz
>>> ---
>>> board/dhelectronics/dh_imx6/dh_imx6_spl.c | 191
>>> +++---
>>> 1 file changed, 173 insertions(+), 18 deletions(-)
>>>
>>> diff --git a/board/dhelectronics/dh_imx6/dh_imx6_spl.c
>>> b/board/dhelectronics/dh_imx6/dh_imx6_spl.c
>> [...]
>>
>> This patch causes memory instability on 1GiB MX6Q part.
>>
>> Can you check that and fix it ? Thanks.
>
> Can you tell me more about the error? How do you test this? Did you run a git
> bisect?
>
> We did tests in a climate chamber with this configuration (with the MX6Q and
> all others).
>
> I think there is only one change that could make a difference:
>
> static const struct mx6_ddr3_cfg dhcom_mem_ddr_2g = {
> ...
> - .trcd = 1312,
> + .trcd = 1375,
>
In this particular case, the board exhibited random instability. Try
running memtester in linux for a few days, maybe some board that you
have will start exhibiting this too.
--
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 16/27] arm: qemu: Enumerate virtio bus during early boot
Hi Simon, On Thu, Sep 27, 2018 at 9:43 PM Simon Glass wrote: > > On 23 September 2018 at 06:42, Bin Meng wrote: > > Currently devices on the virtio bus is not automatically enumerated, > > which means peripherals on the virtio bus are not discovered by their > > drivers. This uses board_init() to do the virtio enumeration. > > > > Signed-off-by: Bin Meng > > --- > > > > board/emulation/qemu-arm/Kconfig| 3 +++ > > board/emulation/qemu-arm/qemu-arm.c | 7 +++ > > 2 files changed, 10 insertions(+) > > > > Reviewed-by: Simon Glass > > But I wonder if we should have a flag in the uclass or perhaps device > tree, to indicate that all devices in it should be probed at start-up? > Could be useful for PCI too. > I think that's a good idea. I will leave this for now and when we have that capability we can revisit. [snip] Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 16/27] arm: qemu: Enumerate virtio bus during early boot
Hi Tuomas,
On Fri, Sep 28, 2018 at 6:13 AM Tuomas Tynkkynen
wrote:
>
> Hi Bin,
>
> On 09/23/2018 04:42 PM, Bin Meng wrote:
> > Currently devices on the virtio bus is not automatically enumerated,
> > which means peripherals on the virtio bus are not discovered by their
> > drivers. This uses board_init() to do the virtio enumeration.
> >
> > Signed-off-by: Bin Meng
> > ---
> >
> > board/emulation/qemu-arm/Kconfig| 3 +++
> > board/emulation/qemu-arm/qemu-arm.c | 7 +++
> > 2 files changed, 10 insertions(+)
> >
> ...
> >diff --git a/board/emulation/qemu-arm/Kconfig
> >b/board/emulation/qemu-arm/Kconfig
> >index d1c08c2..16b80fe 100644
> >--- a/board/emulation/qemu-arm/Kconfig
> >+++ b/board/emulation/qemu-arm/Kconfig
> >@@ -5,5 +5,8 @@ config SYS_TEXT_BASE
> >
> > config BOARD_SPECIFIC_OPTIONS # dummy
> > def_bool y
> >+ imply VIRTIO_MMIO
> >+ imply VIRTIO_NET
> >+ imply VIRTIO_BLK
>
> I think we should have VIRTIO_PCI here as well, so that QEMU command lines
> that work on x86 will work on ARM just as well.
>
Will do in v2.
> ...
> > --- a/board/emulation/qemu-arm/qemu-arm.c
> > +++ b/board/emulation/qemu-arm/qemu-arm.c
> > @@ -4,6 +4,7 @@
> >*/
> > #include
> > #include
> > +#include
> >
> > #ifdef CONFIG_ARM64
> > #include
> > @@ -58,6 +59,12 @@ struct mm_region *mem_map = qemu_arm64_mem_map;
> >
> > int board_init(void)
> > {
> > + /*
> > + * Make sure virtio bus is enumerated so that peripherals
> > + * on the virtio bus can be discovered by their drivers
> > + */
> > + virtio_init();
> > +
> > return 0;
> > }
> >
> >
>
> Note that in include/configs/qemu-arm.h, the boards auto-enumerate
> PCI devices with a different mechanism, like this:
>
> #define CONFIG_PREBOOT "pci enum"
>
> I am not sure which one is better but at least we should be consistent.
Ah yes, but I felt the same as you about which one is better :). I
think using PREBOOT is a little bit late, for example if we call
"virtio scan" here, we still see "Net: No ethernet found." which may
confuse people. Probably what Simon suggested (have a flag to indicate
that all devices in it should be probed at start-up) is an ideal
solution ...
Regards,
Bin
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 20/27] x86: Implement arch-specific io accessor routines
Hi Simon,
On Thu, Sep 27, 2018 at 9:43 PM Simon Glass wrote:
>
> On 23 September 2018 at 06:42, Bin Meng wrote:
> > At present the generic io{read,write}{8,16,32} routines only support
> > MMIO access. With architecture like x86 that has a separate IO space,
> > these routines cannot be used to access I/O ports.
> >
> > Implement x86-specific version to support both PIO and MMIO access,
> > so that drivers for multiple architectures can use these accessors
> > without the need to know whether it's MMIO or PIO.
> >
> > These are ported from Linux kernel lib/iomap.c, with slight changes.
> >
> > Signed-off-by: Bin Meng
> > ---
> >
> > arch/Kconfig | 1 +
> > arch/x86/include/asm/io.h | 66
> > +++
> > 2 files changed, 67 insertions(+)
>
> Reviewed-by: Simon Glass
>
> Should we use regmap instead?
No, regmap is for something else, e.g. the same driver to be used on
different buses.
Regards,
Bin
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 21/27] virtio: Add virtio over pci transport driver
Hi Simon, On Thu, Sep 27, 2018 at 9:43 PM Simon Glass wrote: > > Hi Bin, > > On 23 September 2018 at 06:42, Bin Meng wrote: > > This adds a transport driver that implements UCLASS_VIRTIO for > > virtio over pci, which is commonly used on x86. > > > > It only supports the legacy interface of the pci transport, which > > is the default device that QEMU emulates. > > > > Signed-off-by: Bin Meng > > --- > > > > drivers/virtio/Kconfig | 8 + > > drivers/virtio/Makefile | 1 + > > drivers/virtio/virtio_pci.c | 420 > > > > drivers/virtio/virtio_pci.h | 173 ++ > > 4 files changed, 602 insertions(+) > > create mode 100644 drivers/virtio/virtio_pci.c > > create mode 100644 drivers/virtio/virtio_pci.h > > Reviewed-by: Simon Glass > > vring_create_virtqueue() should return an error I think - you assume -ENOMEM > It returns a NULL pointer and the error is -ENOMEM, which will be checked by the caller via IS_ERR() > That is a huge table of PCI devices. Can you use a class instead? Unfortunately we can't. The virtio spec does not define a dedicated class. Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 25/27] virtio: pci: Support non-legacy PCI transport device
Hi Simon,
On Thu, Sep 27, 2018 at 9:43 PM Simon Glass wrote:
>
> On 23 September 2018 at 06:42, Bin Meng wrote:
> > By default QEMU creates legacy PCI transport devices, but we can
> > ask QEMU to create non-legacy one if we pass additional device
> > property/value pairs in the command line:
> >
> > -device virtio-blk-pci,disable-legacy=true,disable-modern=false
> >
> > This adds a new driver driver to support non-legacy (modern) device
> > mode. Previous driver/file name is changed accordingly.
> >
> > Signed-off-by: Bin Meng
> > ---
> >
> > drivers/virtio/Makefile| 2 +-
> > .../virtio/{virtio_pci.c => virtio_pci_legacy.c} | 6 +-
> > drivers/virtio/virtio_pci_modern.c | 612
> > +
> > 3 files changed, 616 insertions(+), 4 deletions(-)
> > rename drivers/virtio/{virtio_pci.c => virtio_pci_legacy.c} (98%)
> > create mode 100644 drivers/virtio/virtio_pci_modern.c
>
> Reviewed-by: Simon Glass
>
> Isn't there some common code between the two?
Unfortunately the legacy and modern PCI devices are quite different,
so we have to use 2 drivers which is how Linux does. For the
virtio-mmio driver, the difference are not that big so we can use one
driver to support both.
Regards,
Bin
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] sunxi: Imply fitImage support
On Wed, Oct 10, 2018 at 06:27:35PM +0200, Marek Vasut wrote: > Enable modern fitImage format on sunxi. > > Signed-off-by: Marek Vasut > Cc: Maxime Ripard > Cc: Tom Rini Acked-by: Maxime Ripard Thanks! Maxime -- Maxime Ripard, Bootlin Embedded Linux and Kernel engineering https://bootlin.com ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v1 04/19] arm: MediaTek: add basic support for MT7629 boards
On Tue, Oct 09, 2018 at 11:54:04AM +0800, Ryder Lee wrote: > This adds a general board file based on MT7629 SoCs from MediaTek. > > Apart from the generic parts (cpu) we add some low level init codes > and initialize the early clocks. > > Signed-off-by: Ryder Lee > Signed-off-by: Weijie Gao [snip] > diff --git a/include/configs/mt7629.h b/include/configs/mt7629.h > new file mode 100644 > index 000..e640108 > --- /dev/null > +++ b/include/configs/mt7629.h > @@ -0,0 +1,71 @@ > +/* SPDX-License-Identifier: GPL-2.0 */ > +/* > + * Configuration for MediaTek MT7629 SoC > + * > + * Copyright (C) 2018 MediaTek Inc. > + * Author: Ryder Lee > + */ > + > +#ifndef __MT7629_H > +#define __MT7629_H > + > +#include > + > +#include > +#include We don't want these two includes here. > +#ifndef __ASSEMBLY__ > +extern unsigned long get_spl_size(void); > +#endif Nor should we have this here. > +/* Machine ID */ > +#define CONFIG_MACH_TYPE 7629 Since this is for pre-DT kernels, lets drop this. > +#define NOR_MMAP_ADDR0x3000 > +#define CONFIG_SYS_SPI_U_BOOT_OFFS get_spl_size() > +#define CONFIG_SYS_UBOOT_BASE(NOR_MMAP_ADDR + get_spl_size()) Use the value of NOR_MMAP_ADDR directly, and we use some constant (rounded up as needed) for SYS_SPI_U_BOOT_OFFS not a function. And all of these comments apply to the other include/configs/ files in the rest of the series too, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PULL] u-boot-sh/master
On Wed, Oct 10, 2018 at 12:24:14AM +0200, Marek Vasut wrote: > The following changes since commit 0a60a81ba3860946551cb79aa6486aa076e357f3: > > Kconfig: sandbox: enable cmd_avb and dependencies (2018-10-07 13:34:19 > -0400) > > are available in the Git repository at: > > git://git.denx.de/u-boot-sh.git master > > for you to fetch changes up to ae400fde75703f2c0744fd60a5314a0d7857a67f: > > ARM: dts: rmobile: Reinstate missing CPLD on ULCB (2018-10-09 17:21:44 > +0200) > 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 v1 06/19] configs: MediaTek: add MT7629 reference board support
On Tue, Oct 09, 2018 at 11:54:06AM +0800, Ryder Lee wrote: > This patch adds defconfig for the MT7629 reference board. > > Signed-off-by: Ryder Lee > --- > configs/mt7629_rfb_defconfig | 72 > > 1 file changed, 72 insertions(+) > create mode 100644 configs/mt7629_rfb_defconfig This should be squashed into the patch which also adds include/configs/ for the platform and please make sure the MAINTAINERS entry also has these files, 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,1/2] gpio: da8xx: Add k2g compatible
On Wed, Oct 03, 2018 at 05:55:13PM +0530, Keerthy wrote: > Add k2g compatible so that k3 SoCs can be supported > > Signed-off-by: Keerthy > 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] [U-Boot, 4/5] arm: remove prototype for get_timer_masked
On Fri, Oct 05, 2018 at 11:33:52AM +0200, Patrick Delaunay wrote: > The interruption support had be removed for ARM architecture and > the function get_timer_masked() is no more used except in some > the timer.c files. > > This patch clean each timer.c which implement this function and > remove the associated prototype in u-boot-arm.h > > For timer.c, I don't verify if the weak version of get_timer > (in lib/time.c) can be used > > Signed-off-by: Patrick Delaunay 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] rtc: Add read8 and write8 support to isl1208 driver
On Thu, May 31, 2018 at 11:14:44AM -0700, Trent Piepho wrote: > This can be used for device register access from board code. > > This allows access to capabilities in the RTC chip not abstracted in > U-Boot's RTC class. E.g., device NVRAM or a tamper detection circuit. > > Cc: Klaus Goger > Cc: Philipp Tomsich > Cc: Simon Glass > Signed-off-by: Trent Piepho > Reviewed-by: Philipp Tomsich 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, 1/1] ARM: meson: Extend mem_map to support 3GiB of RAM
On Tue, Sep 25, 2018 at 04:30:35PM +0200, Loic Devulder wrote: > The current mem_map definition for Meson SoCs has support for up > to 2GiB of RAM. According to S905, S905X, S912 and S805X datasheets > the DDR region is set from 0x to 0xBFFF, so mem_map's > definition should be changed accordingly. > > It is also needed to be able to boot Khadas VIM2 board with S912 > SoC. > > Signed-off-by: Loic Devulder > Acked-by: Neil Armstrong > Acked-by: Marek Vasut 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] i2c: Fix pca953x endianess issue, commit daa75b34828d45b7c1d63009188d45f4a32d06ba
Hello, we have a 16 bit value here, so we have to define whether bit0(containin the information for IO0.0) is in the first or the second byte. Since the PCA9555 does this encoding little endian, the conversion is allright. Cheers Dirk Am Do., 11. Okt. 2018 um 07:42 Uhr schrieb Heiko Schocher : > > Hello Joakim, > > Am 10.10.2018 um 19:34 schrieb Joakim Tjernlund: > > This commit broke our pca953x usage(on ppc). > > > > I wonder why gpio pins here has an endian, its not a number. > > If there must be an endian connected with this, should it not > > be a cpu_to_be16 instead, which will retain compatibility ? > > Hmm.. good question, I think you are right. May dirk can do a test? > I have no pca953x with 16bit for doing a test. > > bye, > Heiko > -- > DENX Software Engineering GmbH, Managing Director: Wolfgang Denk > HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany > Phone: +49-8142-66989-52 Fax: +49-8142-66989-80 Email: h...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] fs: btrfs: Fix tree traversal with btrfs_next_slot()
On Fri, Sep 07, 2018 at 12:59:30PM +0300, Yevgeny Popovych wrote: > When traversing slots in a btree (via btrfs_path) with btrfs_next_slot(), > we didn't correctly identify that the last slot in the leaf was reached > and we should jump to the next leaf. > > This could lead to any kind of runtime errors or corruptions, like: > * file data not being read at all, or is read partially > * file is read but is corrupted > * (any) metadata being corrupted or not read at all, etc > > The easiest way to reproduce this is to read a large enough file that > its EXTENT_DATA items don't fit into a single leaf. > > Signed-off-by: Yevgeny Popovych > Cc: Marek Behun > Tested-by: Marek Behún 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] cmd: pxe: add support for FIT config selection
On Tue, Oct 02, 2018 at 10:54:48AM +0200, Patrick Delaunay wrote: > Add a way in configuration files (exlinux.conf for sysboot command) > to select a specific FIT configuration. The configuration is selected > with a string added after the FIT filename in the label "KERNEL" or > "LINUX", using the same format than bootm command: > > KERNEL [Filename]#[# > This configuration string, beginning by '#', is directly appended > to bootm argument 1 after . > > bootm []#[# > see doc/uImage.FIT/command_syntax_extensions.txt for details > > Example : > KERNEL /fit.itb#cfg1 > KERNEL /fit.itb#cfg2 > > Configuration can be use also for overlay management : > KERNEL /fit.itb#cfg1#dtbo1#dtbo3 > > see doc/uImage.FIT/overlay-fdt-boot.txt for details > > Signed-off-by: Patrick Delaunay 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] tests/test_bind.py: Update test to match the wider 'dm tree' output
On Tue, Oct 02, 2018 at 04:22:58PM +0100, Liviu Dudau wrote:
> Commit ("dm: core: Widen the dump tree to show more of the driver's
> name") has widened the field reserved for the name of a driver, so
> we need to update the test to match.
>
> Signed-off-by: Liviu Dudau
> ---
> test/py/tests/test_bind.py | 28 ++--
> 1 file changed, 14 insertions(+), 14 deletions(-)
For me, this breaks "make tests".
--
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, 5/5] arm: remove duplicated prototypes in u-boot.arm.h
On Fri, Oct 05, 2018 at 11:33:53AM +0200, Patrick Delaunay wrote: > Remove the function prototypes duplicated between u-boot.arm.h > and init.h/common.h > > Signed-off-by: Patrick Delaunay 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] Please pull u-boot-dm
On Tue, Oct 09, 2018 at 06:24:13PM -0600, Simon Glass wrote: > Hi Tom, > > Here is my attempt at a signed pull request. I've brought in most of the > outstanding dm patches. Please let me know if it looks OK. Do you have my > public key? Is it on the public key servers? > > > The following changes since commit 0a60a81ba3860946551cb79aa6486aa076e357f3: > > Kconfig: sandbox: enable cmd_avb and dependencies (2018-10-07 13:34:19 > -0400) > > are available in the Git repository at: > > git://git.denx.de/u-boot-dm.git tags/dm-9oct18 > > for you to fetch changes up to 41b781ddf1869f5349e05ace888979f3673fe8c6: > > dtoc: Fix the value of SetInt() (2018-10-09 04:40:27 -0600) > 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: dts: stm32mp1: Add usbotg_hs regulator for stm32mp157c-ev1
On Wed, Oct 03, 2018 at 09:38:38AM +0200, Patrice Chotard wrote: > Add usbotg_hs regulator to allow to use the USB mass-storage > feature on OTG usb port. > > Signed-off-by: Patrice Chotard 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, 2/5] arm: remove prototype for reset_timer_masked
On Fri, Oct 05, 2018 at 11:33:50AM +0200, Patrick Delaunay wrote: > Remove prototype for function only used in one file > > Signed-off-by: Patrick Delaunay 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/2] arm: K3: am654: Choose MMC boot device based on boot port
On Wed, Oct 03, 2018 at 10:03:22AM -0500, Andrew F. Davis wrote: > For most devices the boot mode maps directly to the boot > device. For MMC this is not the case as we have two MMC > boot modes and two MMC boot devices (ports). Check the > boot port to determine which MMC device was our boot > device. Make this change for both primary and secondary > boot modes. > > Signed-off-by: Andrew F. Davis > Reviewed-by: Tom Rini > Reviewed-by: Lokesh Vutla 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, 2/2] arm: K3: am654: Add support for getting boot mode
On Wed, Oct 03, 2018 at 10:03:23AM -0500, Andrew F. Davis wrote: > Read the boot mode register to find the boot mode. Only use eMMC boot0 > mode when the mode is eMMC boot (called BOOT_DEVICE_MMC1 currently due > to current conflating of boot mode and boot device), and not iff the > boot device is MMC port 0. > > Signed-off-by: Andrew F. Davis > Reviewed-by: Tom Rini > Reviewed-by: Lokesh Vutla 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, 1/2] fdt: add call to ft_board_setup_ex() for ks2 boards
On Wed, Oct 03, 2018 at 12:58:48PM +0200, Nicholas Faustini wrote: > When updating the board FDT, some of the operations > are performed by ft_board_setup_ex() and should be > executed also by the fdt command. > > Signed-off-by: Nicholas Faustini > 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
[U-Boot] [PATCH] ARC: Don't use COMMON section for global not-initialized variables
By default GCC puts global non-initialized variables in COMMON section. And we used to ignore existence of COMMON section in our linker scripts though smart LD silently appended it right after .bss. And the problem here is variables from COMMON section even though require zeroing in run-time were not zeroed as they were placed right after __bss_end symbol. It was a pure luck we never faced serious problem due to this, but now it is fixed. Now as for some other architectures we'll just force GCC to put those global variables in normal .bss section. This solution is much nicer than adding COMMON section to each and every linker script. Signed-off-by: Alexey Brodkin --- arch/arc/config.mk | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arc/config.mk b/arch/arc/config.mk index d255c90..18005d9 100644 --- a/arch/arc/config.mk +++ b/arch/arc/config.mk @@ -43,7 +43,7 @@ PLATFORM_CPPFLAGS += -mcpu=archs endif PLATFORM_CPPFLAGS += -ffixed-r25 -D__ARC__ -gdwarf-2 -mno-sdata -PLATFORM_RELFLAGS += -ffunction-sections -fdata-sections +PLATFORM_RELFLAGS += -ffunction-sections -fdata-sections -fno-common # Needed for relocation LDFLAGS_FINAL += -pie --gc-sections -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot,3/5] arm: remove prototype for udelay_masked
On Fri, Oct 05, 2018 at 11:33:51AM +0200, Patrick Delaunay wrote: > The interruption support had be removed for ARM architecture and > the function udelay_masked() is no more used except in some timer.c > files and have the same content than udelay() or __udelay(). > > This patch update each timer.c implementing this function and > remove the associated prototype in u-boot-arm.h. > > Signed-off-by: Patrick Delaunay 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/2] ARM: meson: Add Khadas VIM2 board DT
On Wed, Oct 03, 2018 at 12:02:06PM +0200, Loic Devulder wrote: > This adds Device Tree for the Khadas VIM2 board. > > The meson-gxm-khadas-vim2.dts is synchronized from Linux 4.18.10. > > Signed-off-by: Neil Armstrong > Signed-off-by: Loic Devulder > Acked-by: Neil Armstrong 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/5] arm: remove prototype for arch_interrupt_init
On Fri, Oct 05, 2018 at 11:33:49AM +0200, Patrick Delaunay wrote: > Remove prototype for no more existing function > > Signed-off-by: Patrick Delaunay 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, 2/2] board: ks2: move uinitrd fixup logic inside ft_board_setup_ex
On Wed, Oct 03, 2018 at 12:58:49PM +0200, Nicholas Faustini wrote: > The uinitrd fixup logic should be executed after the FDT /chosen > node has been properly populated by fdt_initrd() > > Signed-off-by: Nicholas Faustini > 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] [U-Boot, v2, 2/2] gpio: da8xx: Push generic defines of gpio.h out of mach-davinci
On Wed, Oct 03, 2018 at 05:55:14PM +0530, Keerthy wrote: > Push generic defines of gpio.h out of mach-davinci to drivers/gpio > now that non-davinci architectures are beginning to use this IP. > > Signed-off-by: Keerthy > 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] [U-Boot, 2/2] ARM: meson: Add Khadas VIM2 board support
On Wed, Oct 03, 2018 at 12:02:07PM +0200, Loic Devulder wrote: > This adds platform code for the Khadas VIM2 board based on a > Meson GXM (S912) SoC with the Meson GXM configuration. > > This initial submission supports UART, MMC/SDCard and Ethernet. > USB is partially supported. > > All the code is from Neil Armstrong! I just rebased the code, do > some cleanup and tested on my board. > > Signed-off-by: Neil Armstrong > Signed-off-by: Loic Devulder > Acked-by: Neil Armstrong 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] bootm: Add board specific OS preboot hook
On Thu, Oct 04, 2018 at 09:16:31PM +0200, Marek Vasut wrote: > Add board-specific hook which is executed before the code hands over > control to the OS. This lets the board perform some last-minute clean > ups. > > Signed-off-by: Marek Vasut > Cc: Tom Rini > Reviewed-by: Simon Goldschmidt 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 v2] efi_loader: set image_base and image_size to correct values
On 10/11/2018 01:11 PM, AKASHI Takahiro wrote:
> Currently, image's image_base points to an address where the image was
> temporarily uploaded for further loading. Since efi_loader relocates
> the image to final destination, image_base and image_size should reflect
> that.
>
> This bug was detected in UEFI SCT, "Loaded Image Protocol Test - test 2,"
> which shows that 'Unload' function doesn't fit into a range suggested by
> image_base and image_size.
> TestCase/UEFI/EFI/Protocol/LoadedImage/BlackBoxTest/
> LoadedImageBBTestMain.c:1002
>
> Changes in this patch also includes:
> * reverts a patch, "efi_loader: save image relocation address
> and size" since newly added fields are no longer needed.
> * copy PE headers as well since those information will be needed
> for module loading, in particular, at gurb.
> (This bug was reported by Heinrich.)
>
> Signed-off-by: AKASHI Takahiro
> Reported-by: Heinrich Schuchardt
> ---
> lib/efi_loader/efi_image_loader.c | 22 +++---
> 1 file changed, 11 insertions(+), 11 deletions(-)
>
> diff --git a/lib/efi_loader/efi_image_loader.c
> b/lib/efi_loader/efi_image_loader.c
> index a18ce0a5705e..d1b6c0d3cdf2 100644
> --- a/lib/efi_loader/efi_image_loader.c
> +++ b/lib/efi_loader/efi_image_loader.c
> @@ -59,10 +59,10 @@ static efi_status_t efi_print_image_info(struct
> efi_loaded_image_obj *obj,
> {
> printf("UEFI image");
> printf(" [0x%p:0x%p]",
> -obj->reloc_base, obj->reloc_base + obj->reloc_size - 1);
> - if (pc && pc >= obj->reloc_base &&
> - pc < obj->reloc_base + obj->reloc_size)
> - printf(" pc=0x%zx", pc - obj->reloc_base);
> +image->image_base, image->image_base + image->image_size - 1);
> + if (pc && pc >= image->image_base &&
> + pc < image->image_base + image->image_size)
> + printf(" pc=0x%zx", pc - image->image_base);
> if (image->file_path)
> printf(" '%pD'", image->file_path);
> printf("\n");
> @@ -212,7 +212,6 @@ void *efi_load_pe(struct efi_loaded_image_obj *handle,
> void *efi,
> int rel_idx = IMAGE_DIRECTORY_ENTRY_BASERELOC;
> void *entry;
> uint64_t image_base;
> - uint64_t image_size;
> unsigned long virt_size = 0;
> int supported = 0;
>
> @@ -256,7 +255,6 @@ void *efi_load_pe(struct efi_loaded_image_obj *handle,
> void *efi,
> IMAGE_NT_HEADERS64 *nt64 = (void *)nt;
> IMAGE_OPTIONAL_HEADER64 *opt = &nt64->OptionalHeader;
> image_base = opt->ImageBase;
> - image_size = opt->SizeOfImage;
> efi_set_code_and_data_type(loaded_image_info, opt->Subsystem);
> efi_reloc = efi_alloc(virt_size,
> loaded_image_info->image_code_type);
> @@ -272,7 +270,6 @@ void *efi_load_pe(struct efi_loaded_image_obj *handle,
> void *efi,
> } else if (nt->OptionalHeader.Magic == IMAGE_NT_OPTIONAL_HDR32_MAGIC) {
> IMAGE_OPTIONAL_HEADER32 *opt = &nt->OptionalHeader;
> image_base = opt->ImageBase;
> - image_size = opt->SizeOfImage;
> efi_set_code_and_data_type(loaded_image_info, opt->Subsystem);
> efi_reloc = efi_alloc(virt_size,
> loaded_image_info->image_code_type);
> @@ -291,6 +288,11 @@ void *efi_load_pe(struct efi_loaded_image_obj *handle,
> void *efi,
> return NULL;
> }
>
> + /* Copy PE headers */
> + memcpy(efi_reloc, efi, sizeof(*dos) + sizeof(*nt)
> + + nt->FileHeader.SizeOfOptionalHeader
> + + num_sections * sizeof(IMAGE_SECTION_HEADER));
> +
Why do we have to copy PE headers and the sections below separately? My
understanding is that the relative positions do not need any adjustment.
Nothing in the spec requires the COFF header to be at offset
sizeof(dos). You can put the COFF headder anywhere in the file. Please,
read
https://media.blackhat.com/bh-us-11/Vuksan/BH_US_11_VuksanPericin_PECOFF_WP.pdf
We should not assign new memory here. Nor should we copy anything here.
We should simply use the relocation table to update the indicated memory
locations.
Best regards
Heinrich
> /* Load sections into RAM */
> for (i = num_sections - 1; i >= 0; i--) {
> IMAGE_SECTION_HEADER *sec = §ions[i];
> @@ -315,10 +317,8 @@ void *efi_load_pe(struct efi_loaded_image_obj *handle,
> void *efi,
> invalidate_icache_all();
>
> /* Populate the loaded image interface bits */
> - loaded_image_info->image_base = efi;
> - loaded_image_info->image_size = image_size;
> - handle->reloc_base = efi_reloc;
> - handle->reloc_size = virt_size;
> + loaded_image_info->image_base = efi_reloc;
> + loaded_image_info->image_size = virt_size;
>
> return entry;
> }
>
___
U-Boot mailing list
U-Boot@lists.den
Re: [U-Boot] [PATCH] linux/compat.h: Add netdev_### log macros
Hi Joe, On Wed, Oct 10, 2018 at 4:39 AM Joe Hershberger wrote: > > On Sun, Oct 7, 2018 at 7:53 AM Bin Meng wrote: > > > > Hi Joe, > > > > On Sat, Sep 15, 2018 at 4:37 AM Joe Hershberger > > wrote: > > > > > > Hi Bin, > > > On Tue, Sep 11, 2018 at 5:07 AM Bin Meng wrote: > > > > > > > > Hi Joe, > > > > > > > > On Fri, Jul 27, 2018 at 2:52 AM Joe Hershberger > > > > wrote: > > > > > > > > > > On Thu, Jul 26, 2018 at 5:15 AM, Bin Meng wrote: > > > > > > Currently there are two ethernet drivers (mvneta.c and mvpp2.c) that > > > > > > has netdev_### (eg: netdev_dbg) log macros defined in its own driver > > > > > > file. This adds these log macros in a common place linux/compat.h. > > > > > > > > > > > > Signed-off-by: Bin Meng > > > > > > > > > > Acked-by: Joe Hershberger > > > > > > > > When will the following be merged? Thanks! > > > > > > Now that we have a release, I'll try to get them in my queue next week. > > > > > > > ping ? > > Part of my current test building on travis: > https://travis-ci.org/jhershbe/u-boot/builds/439322261 > Please let me know when the PR will be sent. I have some patches that are dependent on these. Thanks! Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] tests/test_bind.py: Update test to match the wider 'dm tree' output
Hi Tom,
On 11 October 2018 at 08:11, Tom Rini wrote:
>
> On Tue, Oct 02, 2018 at 04:22:58PM +0100, Liviu Dudau wrote:
>
> > Commit ("dm: core: Widen the dump tree to show more of the driver's
> > name") has widened the field reserved for the name of a driver, so
> > we need to update the test to match.
> >
> > Signed-off-by: Liviu Dudau
> > ---
> > test/py/tests/test_bind.py | 28 ++--
> > 1 file changed, 14 insertions(+), 14 deletions(-)
>
> For me, this breaks "make tests".
Yes, it needs another patch, that I dropped because it breaks the
tests. This patch fixes them but only if that patch is applied.
Liviu, how about sending a patch that combines both?
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2] sf: Add auto detection of 4-byte mode (vs standard 3-byte mode)
Some SPI NOR chips only support 4-byte mode addressing. Here the default
3-byte mode does not work and leads to incorrect accesses. This patch
now reads the 4-byte mode status bit (in this case in the CR register
of the Macronix SPI NOR) and configures the SPI transfers accordingly.
This was noticed on the LinkIt Smart 7688 modul, which is equipped with
an Macronix MX25L25635F device. But this device does *NOT* support
switching to 3-byte mode via the EX4B command.
This should also work when the bootrom configures the SPI flash to
4-byte mode and runs U-Boot after this. U-Boot should dectect this
mode (if the 4-byte mode detection is available for this chip) and
use the correct OPs in this case.
Signed-off-by: Stefan Roese
Cc: Jagan Teki
Cc: Simon Goldschmidt
---
v2:
- Integrated STMICRO 4-byte detection from Simon
drivers/mtd/spi/sf_internal.h | 3 +-
drivers/mtd/spi/spi_flash.c | 131 --
include/spi_flash.h | 5 ++
3 files changed, 118 insertions(+), 21 deletions(-)
diff --git a/drivers/mtd/spi/sf_internal.h b/drivers/mtd/spi/sf_internal.h
index 4f63cacc64..eb076401d1 100644
--- a/drivers/mtd/spi/sf_internal.h
+++ b/drivers/mtd/spi/sf_internal.h
@@ -26,7 +26,8 @@ enum spi_nor_option_flags {
};
#define SPI_FLASH_3B_ADDR_LEN 3
-#define SPI_FLASH_CMD_LEN (1 + SPI_FLASH_3B_ADDR_LEN)
+#define SPI_FLASH_4B_ADDR_LEN 4
+#define SPI_FLASH_CMD_MAX_LEN (1 + SPI_FLASH_4B_ADDR_LEN)
#define SPI_FLASH_16MB_BOUN0x100
/* CFI Manufacture ID's */
diff --git a/drivers/mtd/spi/spi_flash.c b/drivers/mtd/spi/spi_flash.c
index c159124259..e41c5a961b 100644
--- a/drivers/mtd/spi/spi_flash.c
+++ b/drivers/mtd/spi/spi_flash.c
@@ -20,12 +20,19 @@
#include "sf_internal.h"
-static void spi_flash_addr(u32 addr, u8 *cmd)
+static void spi_flash_addr(struct spi_flash *flash, u32 addr, u8 *cmd)
{
/* cmd[0] is actual command */
- cmd[1] = addr >> 16;
- cmd[2] = addr >> 8;
- cmd[3] = addr >> 0;
+ if (flash->in_4byte_mode) {
+ cmd[1] = addr >> 24;
+ cmd[2] = addr >> 16;
+ cmd[3] = addr >> 8;
+ cmd[4] = addr >> 0;
+ } else {
+ cmd[1] = addr >> 16;
+ cmd[2] = addr >> 8;
+ cmd[3] = addr >> 0;
+ }
}
static int read_sr(struct spi_flash *flash, u8 *rs)
@@ -110,6 +117,72 @@ static int write_cr(struct spi_flash *flash, u8 wc)
}
#endif
+#if defined(CONFIG_SPI_FLASH_MACRONIX)
+static bool flash_in_4byte_mode_macronix(struct spi_flash *flash)
+{
+ int ret;
+ u8 cr;
+ u8 cmd;
+
+ cmd = 0x15; /* Macronix: read configuration register RDCR */
+ ret = spi_flash_read_common(flash, &cmd, 1, &cr, 1);
+ if (ret < 0) {
+ debug("SF: fail to read config register\n");
+ return false;
+ }
+
+ /* Return true, if 4-byte mode is enabled */
+ if (cr & BIT(5))
+ return true;
+
+ return false;
+}
+#else
+static bool flash_in_4byte_mode_macronix(struct spi_flash *flash)
+{
+ return false;
+}
+#endif
+
+#if defined(CONFIG_SPI_FLASH_STMICRO)
+static bool flash_in_4byte_mode_stmicro(struct spi_flash *flash)
+{
+ int ret;
+ u8 fsr;
+ u8 cmd;
+
+ cmd = 0x70; /* STMicro/Micron: read flag status register */
+ ret = spi_flash_read_common(flash, &cmd, 1, &fsr, 1);
+ if (ret < 0) {
+ debug("SF: fail to read config register\n");
+ return false;
+ }
+
+ /* Return true, if 4-byte mode is enabled */
+ if (fsr & BIT(0))
+ return true;
+
+ return false;
+}
+#else
+static bool flash_in_4byte_mode_stmicro(struct spi_flash *flash)
+{
+ return false;
+}
+#endif
+
+static bool flash_in_4byte_mode(struct spi_flash *flash,
+ const struct spi_flash_info *info)
+{
+ if (JEDEC_MFR(info) == SPI_FLASH_CFI_MFR_MACRONIX)
+ return flash_in_4byte_mode_macronix(flash);
+
+ if (JEDEC_MFR(info) == SPI_FLASH_CFI_MFR_STMICRO)
+ return flash_in_4byte_mode_stmicro(flash);
+
+ return false;
+}
+
#ifdef CONFIG_SPI_FLASH_BAR
/*
* This "clean_bar" is necessary in a situation when one was accessing
@@ -314,7 +387,7 @@ int spi_flash_write_common(struct spi_flash *flash, const
u8 *cmd,
int spi_flash_cmd_erase_ops(struct spi_flash *flash, u32 offset, size_t len)
{
u32 erase_size, erase_addr;
- u8 cmd[SPI_FLASH_CMD_LEN];
+ u8 cmd[SPI_FLASH_CMD_MAX_LEN];
int ret = -1;
erase_size = flash->erase_size;
@@ -344,12 +417,13 @@ int spi_flash_cmd_erase_ops(struct spi_flash *flash, u32
offset, size_t len)
if (ret < 0)
return ret;
#endif
- spi_flash_addr(erase_addr, cmd);
+ spi_flash_addr(flash, erase_addr, cmd);
debug("SF: erase %2x
[U-Boot] [PATCH v3] sf: Add auto detection of 4-byte mode (vs standard 3-byte mode)
Some SPI NOR chips only support 4-byte mode addressing. Here the default
3-byte mode does not work and leads to incorrect accesses. This patch
now reads the 4-byte mode status bit (in this case in the CR register
of the Macronix SPI NOR) and configures the SPI transfers accordingly.
This was noticed on the LinkIt Smart 7688 modul, which is equipped with
an Macronix MX25L25635F device. But this device does *NOT* support
switching to 3-byte mode via the EX4B command.
This should also work when the bootrom configures the SPI flash to
4-byte mode and runs U-Boot after this. U-Boot should dectect this
mode (if the 4-byte mode detection is available for this chip) and
use the correct OPs in this case.
Signed-off-by: Stefan Roese
Cc: Jagan Teki
Tested-by: Simon Goldschmidt
---
v3:
- Rebased on latest version (merge conflict because of new patches
from Simon Glass)
- Added Tested-by tag from Simon Goldschmidt
v2:
- Integrated STMICRO 4-byte detection from Simon
drivers/mtd/spi/sf_internal.h | 3 +-
drivers/mtd/spi/spi_flash.c | 131 --
include/spi_flash.h | 5 ++
3 files changed, 118 insertions(+), 21 deletions(-)
diff --git a/drivers/mtd/spi/sf_internal.h b/drivers/mtd/spi/sf_internal.h
index 4f63cacc64..eb076401d1 100644
--- a/drivers/mtd/spi/sf_internal.h
+++ b/drivers/mtd/spi/sf_internal.h
@@ -26,7 +26,8 @@ enum spi_nor_option_flags {
};
#define SPI_FLASH_3B_ADDR_LEN 3
-#define SPI_FLASH_CMD_LEN (1 + SPI_FLASH_3B_ADDR_LEN)
+#define SPI_FLASH_4B_ADDR_LEN 4
+#define SPI_FLASH_CMD_MAX_LEN (1 + SPI_FLASH_4B_ADDR_LEN)
#define SPI_FLASH_16MB_BOUN0x100
/* CFI Manufacture ID's */
diff --git a/drivers/mtd/spi/spi_flash.c b/drivers/mtd/spi/spi_flash.c
index 9230060364..b22eea2d1c 100644
--- a/drivers/mtd/spi/spi_flash.c
+++ b/drivers/mtd/spi/spi_flash.c
@@ -20,12 +20,19 @@
#include "sf_internal.h"
-static void spi_flash_addr(u32 addr, u8 *cmd)
+static void spi_flash_addr(struct spi_flash *flash, u32 addr, u8 *cmd)
{
/* cmd[0] is actual command */
- cmd[1] = addr >> 16;
- cmd[2] = addr >> 8;
- cmd[3] = addr >> 0;
+ if (flash->in_4byte_mode) {
+ cmd[1] = addr >> 24;
+ cmd[2] = addr >> 16;
+ cmd[3] = addr >> 8;
+ cmd[4] = addr >> 0;
+ } else {
+ cmd[1] = addr >> 16;
+ cmd[2] = addr >> 8;
+ cmd[3] = addr >> 0;
+ }
}
static int read_sr(struct spi_flash *flash, u8 *rs)
@@ -110,6 +117,72 @@ static int write_cr(struct spi_flash *flash, u8 wc)
}
#endif
+#if defined(CONFIG_SPI_FLASH_MACRONIX)
+static bool flash_in_4byte_mode_macronix(struct spi_flash *flash)
+{
+ int ret;
+ u8 cr;
+ u8 cmd;
+
+ cmd = 0x15; /* Macronix: read configuration register RDCR */
+ ret = spi_flash_read_common(flash, &cmd, 1, &cr, 1);
+ if (ret < 0) {
+ debug("SF: fail to read config register\n");
+ return false;
+ }
+
+ /* Return true, if 4-byte mode is enabled */
+ if (cr & BIT(5))
+ return true;
+
+ return false;
+}
+#else
+static bool flash_in_4byte_mode_macronix(struct spi_flash *flash)
+{
+ return false;
+}
+#endif
+
+#if defined(CONFIG_SPI_FLASH_STMICRO)
+static bool flash_in_4byte_mode_stmicro(struct spi_flash *flash)
+{
+ int ret;
+ u8 fsr;
+ u8 cmd;
+
+ cmd = 0x70; /* STMicro/Micron: read flag status register */
+ ret = spi_flash_read_common(flash, &cmd, 1, &fsr, 1);
+ if (ret < 0) {
+ debug("SF: fail to read config register\n");
+ return false;
+ }
+
+ /* Return true, if 4-byte mode is enabled */
+ if (fsr & BIT(0))
+ return true;
+
+ return false;
+}
+#else
+static bool flash_in_4byte_mode_stmicro(struct spi_flash *flash)
+{
+ return false;
+}
+#endif
+
+static bool flash_in_4byte_mode(struct spi_flash *flash,
+ const struct spi_flash_info *info)
+{
+ if (JEDEC_MFR(info) == SPI_FLASH_CFI_MFR_MACRONIX)
+ return flash_in_4byte_mode_macronix(flash);
+
+ if (JEDEC_MFR(info) == SPI_FLASH_CFI_MFR_STMICRO)
+ return flash_in_4byte_mode_stmicro(flash);
+
+ return false;
+}
+
#ifdef CONFIG_SPI_FLASH_BAR
/*
* This "clean_bar" is necessary in a situation when one was accessing
@@ -314,7 +387,7 @@ int spi_flash_write_common(struct spi_flash *flash, const
u8 *cmd,
int spi_flash_cmd_erase_ops(struct spi_flash *flash, u32 offset, size_t len)
{
u32 erase_size, erase_addr;
- u8 cmd[SPI_FLASH_CMD_LEN];
+ u8 cmd[SPI_FLASH_CMD_MAX_LEN];
int ret = -1;
erase_size = flash->erase_size;
@@ -344,12 +417,13 @@ int spi_flash_cmd_erase_ops(struct spi_flash *flash, u32
offset, size_t len)
if (ret < 0)
return ret;
#endif
Re: [U-Boot] [PATCH 3/4] x86: doc: Mention qemu-x86_64 support
On 10/11/2018 03:53 AM, Bin Meng wrote: > Currently only 32-bit U-Boot for QEMU x86 is documented. Mention > the 64-bit support. > > Signed-off-by: Bin Meng > --- > > doc/README.x86 | 8 ++-- > 1 file changed, 6 insertions(+), 2 deletions(-) > > diff --git a/doc/README.x86 b/doc/README.x86 > index 8cc4672..ab48466 100644 > --- a/doc/README.x86 > +++ b/doc/README.x86 > @@ -32,7 +32,7 @@ are supported: > - Link (Chromebook Pixel) > - Minnowboard MAX > - Samus (Chromebook Pixel 2015) > - - QEMU x86 > + - QEMU x86 (32-bit & 64-bit) > > As for loading an OS, U-Boot supports directly booting a 32-bit or 64-bit > Linux kernel as part of a FIT image. It also supports a compressed zImage. > @@ -376,7 +376,9 @@ QEMU x86 target instructions for bare mode: > > To build u-boot.rom for QEMU x86 targets, just simply run > > -$ make qemu-x86_defconfig > +$ make qemu-x86_defconfig (for 32-bit) > +or > +$ make qemu-x86_64_defconfig (for 64-bit) > $ make all If your patch series creates a U-Boot usable with QEMU depends on the chosen CPU: This one seems to work: qemu-system-x86_64 -bios u-boot.rom -nographic -cpu core2duo This one fails (as expected): qemu-system-x86_64 -bios u-boot.rom --nographic -cpu pentium I could not get the emulation running without -nographic. Do you know why? The documentation above is insufficient. Please, provide a minimum QEMU command line which includes a CPU specification. I would prefer if you could specify two lines per bitness - one with kvm and one without, e.g. qemu-system-x86_64 -bios u-boot.rom -nographic -enable-kvm -cpu host qemu-system-x86_64 -bios u-boot.rom -nographic -cpu core2duo qemu-system-i386 -bios u-boot.rom -nographic -enable-kvm -cpu host qemu-system-i386 -bios u-boot.rom -nographic -cpu core2duo Best regards Heinrich > > Note this default configuration will build a U-Boot for the QEMU x86 i440FX > @@ -387,6 +389,8 @@ Device Tree Control ---> > ... > (qemu-x86_q35) Default Device Tree for DT control > > +To run 64-bit U-Boot, qemu-system-x86_64 should be used instead. > + > Test with coreboot > -- > For testing U-Boot as the coreboot payload, there are things that need be > paid > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] x86: Specify -march=core2 to build 64-bit U-Boot proper
On 10/11/2018 03:53 AM, Bin Meng wrote: > With newer kernel.org GCC (7.3.0 or 8.1.0), the u-boot.rom image > built for qemu-x86_64 target does not boot. It keeps resetting > soon after the 32-bit SPL jumps to 64-bit proper. Debugging shows > that the reset happens inside env_callback_init(). > > 0113dd85 : > 113dd85: 41 54 push %r12 > 113dd87: 55 push %rbp > 113dd88: 31 c0 xor%eax,%eax > 113dd8a: 53 push %rbx > 113dd8b: 0f 57 c0xorps %xmm0,%xmm0 > > Executing "xorps %xmm0,%xmm0" causes CPU to immediately reset. > However older GCC like 5.4.0 (the one shipped by Ubuntu 16.04) > does not generate such instructions that utilizes SSE for this > function - env_callback_init() and U-Boot boots without any issue. > Explicitly specifying -march=core2 for newer GCC allows U-Boot > proper to boot again. Examine assembly codes of env_callback_init > and there is no SSE instruction in that function hence U-Boot > continues to boot. > > core2 seems to be the oldest arch in GCC that supports 64-bit. > Like 32-bit U-Boot build we use -march=i386 which is the most > conservative cpu type so that the image can run on any x86 > processor, let's do the same for the 64-bit U-Boot build. > > Signed-off-by: Bin Meng Reviewed-by: Heinrich Schuchardt > --- > > arch/x86/config.mk | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/x86/config.mk b/arch/x86/config.mk > index cc94071..576501e 100644 > --- a/arch/x86/config.mk > +++ b/arch/x86/config.mk > @@ -23,7 +23,7 @@ endif > ifeq ($(IS_32BIT),y) > PLATFORM_CPPFLAGS += -march=i386 -m32 > else > -PLATFORM_CPPFLAGS += $(if $(CONFIG_SPL_BUILD),,-fpic) -fno-common -m64 > +PLATFORM_CPPFLAGS += $(if $(CONFIG_SPL_BUILD),,-fpic) -fno-common > -march=core2 -m64 > endif > > PLATFORM_RELFLAGS += -fdata-sections -ffunction-sections -fvisibility=hidden > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 3/4] x86: doc: Mention qemu-x86_64 support
Hi Heinrich, On Thu, Oct 11, 2018 at 11:15 PM Heinrich Schuchardt wrote: > > On 10/11/2018 03:53 AM, Bin Meng wrote: > > Currently only 32-bit U-Boot for QEMU x86 is documented. Mention > > the 64-bit support. > > > > Signed-off-by: Bin Meng > > --- > > > > doc/README.x86 | 8 ++-- > > 1 file changed, 6 insertions(+), 2 deletions(-) > > > > diff --git a/doc/README.x86 b/doc/README.x86 > > index 8cc4672..ab48466 100644 > > --- a/doc/README.x86 > > +++ b/doc/README.x86 > > @@ -32,7 +32,7 @@ are supported: > > - Link (Chromebook Pixel) > > - Minnowboard MAX > > - Samus (Chromebook Pixel 2015) > > - - QEMU x86 > > + - QEMU x86 (32-bit & 64-bit) > > > > As for loading an OS, U-Boot supports directly booting a 32-bit or 64-bit > > Linux kernel as part of a FIT image. It also supports a compressed zImage. > > @@ -376,7 +376,9 @@ QEMU x86 target instructions for bare mode: > > > > To build u-boot.rom for QEMU x86 targets, just simply run > > > > -$ make qemu-x86_defconfig > > +$ make qemu-x86_defconfig (for 32-bit) > > +or > > +$ make qemu-x86_64_defconfig (for 64-bit) > > $ make all > > If your patch series creates a U-Boot usable with QEMU depends on the > chosen CPU: > > This one seems to work: > qemu-system-x86_64 -bios u-boot.rom -nographic -cpu core2duo > > This one fails (as expected): > qemu-system-x86_64 -bios u-boot.rom --nographic -cpu pentium Pentium does not support 64-bit, so it is expected. In my testing I always omit the '-cpu' so this is not a problem. But I can document this. > > I could not get the emulation running without -nographic. Do you know why? > This is due to currently the VGA support is missing in the 64-bit U-Boot. > The documentation above is insufficient. Please, provide a minimum QEMU > command line which includes a CPU specification. > > I would prefer if you could specify two lines per bitness - one with kvm > and one without, e.g. I doubt -enable-kvm works with U-Boot. > > qemu-system-x86_64 -bios u-boot.rom -nographic -enable-kvm -cpu host > qemu-system-x86_64 -bios u-boot.rom -nographic -cpu core2duo > > qemu-system-i386 -bios u-boot.rom -nographic -enable-kvm -cpu host > qemu-system-i386 -bios u-boot.rom -nographic -cpu core2duo > Will add more info in v2. Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 3/4] x86: doc: Mention qemu-x86_64 support
On 10/11/2018 05:27 PM, Bin Meng wrote: > Hi Heinrich, > > On Thu, Oct 11, 2018 at 11:15 PM Heinrich Schuchardt > wrote: >> >> On 10/11/2018 03:53 AM, Bin Meng wrote: >>> Currently only 32-bit U-Boot for QEMU x86 is documented. Mention >>> the 64-bit support. >>> >>> Signed-off-by: Bin Meng >>> --- >>> >>> doc/README.x86 | 8 ++-- >>> 1 file changed, 6 insertions(+), 2 deletions(-) >>> >>> diff --git a/doc/README.x86 b/doc/README.x86 >>> index 8cc4672..ab48466 100644 >>> --- a/doc/README.x86 >>> +++ b/doc/README.x86 >>> @@ -32,7 +32,7 @@ are supported: >>> - Link (Chromebook Pixel) >>> - Minnowboard MAX >>> - Samus (Chromebook Pixel 2015) >>> - - QEMU x86 >>> + - QEMU x86 (32-bit & 64-bit) >>> >>> As for loading an OS, U-Boot supports directly booting a 32-bit or 64-bit >>> Linux kernel as part of a FIT image. It also supports a compressed zImage. >>> @@ -376,7 +376,9 @@ QEMU x86 target instructions for bare mode: >>> >>> To build u-boot.rom for QEMU x86 targets, just simply run >>> >>> -$ make qemu-x86_defconfig >>> +$ make qemu-x86_defconfig (for 32-bit) >>> +or >>> +$ make qemu-x86_64_defconfig (for 64-bit) >>> $ make all >> >> If your patch series creates a U-Boot usable with QEMU depends on the >> chosen CPU: >> >> This one seems to work: >> qemu-system-x86_64 -bios u-boot.rom -nographic -cpu core2duo >> >> This one fails (as expected): >> qemu-system-x86_64 -bios u-boot.rom --nographic -cpu pentium > > Pentium does not support 64-bit, so it is expected. In my testing I > always omit the '-cpu' so this is not a problem. But I can document > this. > >> >> I could not get the emulation running without -nographic. Do you know why? >> > > This is due to currently the VGA support is missing in the 64-bit U-Boot. > >> The documentation above is insufficient. Please, provide a minimum QEMU >> command line which includes a CPU specification. >> >> I would prefer if you could specify two lines per bitness - one with kvm >> and one without, e.g. > > I doubt -enable-kvm works with U-Boot. Why? It is just an instruction how QEMU should emulate the CPU. KVM does not require anything on the target software side. I have had no problem with KVM on the i386 target. Regards Heinrich > >> >> qemu-system-x86_64 -bios u-boot.rom -nographic -enable-kvm -cpu host >> qemu-system-x86_64 -bios u-boot.rom -nographic -cpu core2duo >> >> qemu-system-i386 -bios u-boot.rom -nographic -enable-kvm -cpu host >> qemu-system-i386 -bios u-boot.rom -nographic -cpu core2duo >> > > Will add more info in v2. > > Regards, > Bin > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 3/4] x86: doc: Mention qemu-x86_64 support
Hi Heinrich, On Thu, Oct 11, 2018 at 11:32 PM Heinrich Schuchardt wrote: > > On 10/11/2018 05:27 PM, Bin Meng wrote: > > Hi Heinrich, > > > > On Thu, Oct 11, 2018 at 11:15 PM Heinrich Schuchardt > > wrote: > >> > >> On 10/11/2018 03:53 AM, Bin Meng wrote: > >>> Currently only 32-bit U-Boot for QEMU x86 is documented. Mention > >>> the 64-bit support. > >>> > >>> Signed-off-by: Bin Meng > >>> --- > >>> > >>> doc/README.x86 | 8 ++-- > >>> 1 file changed, 6 insertions(+), 2 deletions(-) > >>> > >>> diff --git a/doc/README.x86 b/doc/README.x86 > >>> index 8cc4672..ab48466 100644 > >>> --- a/doc/README.x86 > >>> +++ b/doc/README.x86 > >>> @@ -32,7 +32,7 @@ are supported: > >>> - Link (Chromebook Pixel) > >>> - Minnowboard MAX > >>> - Samus (Chromebook Pixel 2015) > >>> - - QEMU x86 > >>> + - QEMU x86 (32-bit & 64-bit) > >>> > >>> As for loading an OS, U-Boot supports directly booting a 32-bit or 64-bit > >>> Linux kernel as part of a FIT image. It also supports a compressed > >>> zImage. > >>> @@ -376,7 +376,9 @@ QEMU x86 target instructions for bare mode: > >>> > >>> To build u-boot.rom for QEMU x86 targets, just simply run > >>> > >>> -$ make qemu-x86_defconfig > >>> +$ make qemu-x86_defconfig (for 32-bit) > >>> +or > >>> +$ make qemu-x86_64_defconfig (for 64-bit) > >>> $ make all > >> > >> If your patch series creates a U-Boot usable with QEMU depends on the > >> chosen CPU: > >> > >> This one seems to work: > >> qemu-system-x86_64 -bios u-boot.rom -nographic -cpu core2duo > >> > >> This one fails (as expected): > >> qemu-system-x86_64 -bios u-boot.rom --nographic -cpu pentium > > > > Pentium does not support 64-bit, so it is expected. In my testing I > > always omit the '-cpu' so this is not a problem. But I can document > > this. > > > >> > >> I could not get the emulation running without -nographic. Do you know why? > >> > > > > This is due to currently the VGA support is missing in the 64-bit U-Boot. > > > >> The documentation above is insufficient. Please, provide a minimum QEMU > >> command line which includes a CPU specification. > >> > >> I would prefer if you could specify two lines per bitness - one with kvm > >> and one without, e.g. > > > > I doubt -enable-kvm works with U-Boot. > > Why? It is just an instruction how QEMU should emulate the CPU. KVM does > not require anything on the target software side. > > I have had no problem with KVM on the i386 target. I suspect some drivers may have issues when working with KVM, eg: some memory barriers might be needed due to guest (U-Boot) and host (x86 machine) are speaking the same language. But I have never fully test this configuration. Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] ls1012afrwy:update ls1012afrwy env board variable
On 10/10/2018 11:40 PM, Pramod Kumar wrote: > ls1012afrwy and ls1012afrdm both boards are varinat of ls1012a based > SoC board. > By default board and board_name uboot env variables are set as > ls1012afrdm. > whenever board is detected as ls1012afrwy, uboot env > variables are upadted to ls1012afrwy if it set as ls1012afrdm. Please reformat your subject and commit message, as described as https://www.denx.de/wiki/view/U-Boot/Patches#Commit_message_conventions York ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 0/3] Add raw read support and use it in pxa3xx NAND driver
When using 2kiB-pages NAND chips requesting an 8-bit strength ECC, the layout used is a bit particular and it happens that the ECC engine tries to correct uncorrectable errors on empty pages, producing bitflips. To avoid such situation, raw read support is added to the pxa3xx_nand driver, and then used to re-read the page (in raw mode) upon uncorrectable error detection to know if there is an actual ECC mismatch or if the page is empty. This way we avoid seeing the bitflips created by the hardware ECC engine. Once this done, we can revert the hack that was done in the driver to enlarge the last spare area for this layout to 64B instead of 32B, breaking U-Boot/Linux compatibility and preventing the BootROM to boot from NAND. Thanks, Miquèl Miquel Raynal (3): mtd: nand: pxa3xx: add raw read support mtd: nand: pxa3xx: re-read a page in raw mode on uncorrectable error mtd: rawnand: pxa3xx: fix 2kiB pages with 8b strength chips layout drivers/mtd/nand/raw/pxa3xx_nand.c | 143 + 1 file changed, 124 insertions(+), 19 deletions(-) -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 2/3] mtd: nand: pxa3xx: re-read a page in raw mode on uncorrectable error
This only applies on BCH path.
When an empty page is read, it triggers an uncorrectable error. While
this is expected, the ECC engine might produce itself bitflips in the
read data under certain layouts. To overcome this situation, always
re-read the entire page in raw mode and check for the whole page to be
empty.
Also report the right number of bitflips if there are any.
Signed-off-by: Miquel Raynal
---
drivers/mtd/nand/raw/pxa3xx_nand.c | 27 +++
1 file changed, 23 insertions(+), 4 deletions(-)
diff --git a/drivers/mtd/nand/raw/pxa3xx_nand.c
b/drivers/mtd/nand/raw/pxa3xx_nand.c
index 454597355b..492485b1d0 100644
--- a/drivers/mtd/nand/raw/pxa3xx_nand.c
+++ b/drivers/mtd/nand/raw/pxa3xx_nand.c
@@ -1237,6 +1237,7 @@ static int pxa3xx_nand_read_page_hwecc(struct mtd_info
*mtd,
{
struct pxa3xx_nand_host *host = nand_get_controller_data(chip);
struct pxa3xx_nand_info *info = host->info_data;
+ int bf;
chip->read_buf(mtd, buf, mtd->writesize);
chip->read_buf(mtd, chip->oob_poi, mtd->oobsize);
@@ -1244,12 +1245,30 @@ static int pxa3xx_nand_read_page_hwecc(struct mtd_info
*mtd,
if (info->retcode == ERR_CORERR && info->use_ecc) {
mtd->ecc_stats.corrected += info->ecc_err_cnt;
- } else if (info->retcode == ERR_UNCORERR) {
+ } else if (info->retcode == ERR_UNCORERR && info->ecc_bch) {
/*
-* for blank page (all 0xff), HW will calculate its ECC as
-* 0, which is different from the ECC information within
-* OOB, ignore such uncorrectable errors
+* Empty pages will trigger uncorrectable errors. Re-read the
+* entire page in raw mode and check for bits not being "1".
+* If there are more than the supported strength, then it means
+* this is an actual uncorrectable error.
*/
+ chip->ecc.read_page_raw(mtd, chip, buf, oob_required, page);
+ bf = nand_check_erased_ecc_chunk(buf, mtd->writesize,
+chip->oob_poi, mtd->oobsize,
+NULL, 0, chip->ecc.strength);
+ if (bf < 0) {
+ mtd->ecc_stats.failed++;
+ } else if (bf) {
+ mtd->ecc_stats.corrected += bf;
+ info->max_bitflips = max_t(unsigned int,
+ info->max_bitflips, bf);
+ info->retcode = ERR_CORERR;
+ } else {
+ info->retcode = ERR_NONE;
+ }
+
+ } else if (info->retcode == ERR_UNCORERR && !info->ecc_bch) {
+ /* Raw read is not supported with Hamming ECC engine */
if (is_buf_blank(buf, mtd->writesize))
info->retcode = ERR_NONE;
else
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/3] mtd: nand: pxa3xx: add raw read support
Raw read support is added by editing a few code sections:
->handle_data_pio() includes the ECC bytes that are not consumed
anymore by the ECC engine.
->prepare_set_command() is changed so that the ECC bytes are
requested as part of the data I/O length.
->drain_fifo() shall also avoid checking the R/B pin too often
when in raw mode.
->read_page_raw()/->read_oob_raw() are written from scratch.
Signed-off-by: Miquel Raynal
---
drivers/mtd/nand/raw/pxa3xx_nand.c | 98 --
1 file changed, 92 insertions(+), 6 deletions(-)
diff --git a/drivers/mtd/nand/raw/pxa3xx_nand.c
b/drivers/mtd/nand/raw/pxa3xx_nand.c
index 4c783f1e1e..454597355b 100644
--- a/drivers/mtd/nand/raw/pxa3xx_nand.c
+++ b/drivers/mtd/nand/raw/pxa3xx_nand.c
@@ -195,6 +195,7 @@ struct pxa3xx_nand_info {
int cs;
int use_ecc;/* use HW ECC ? */
+ int force_raw; /* prevent use_ecc to be set */
int ecc_bch;/* using BCH ECC? */
int use_spare; /* use spare ? */
int need_wait;
@@ -579,7 +580,7 @@ static void disable_int(struct pxa3xx_nand_info *info,
uint32_t int_mask)
static void drain_fifo(struct pxa3xx_nand_info *info, void *data, int len)
{
- if (info->ecc_bch) {
+ if (info->ecc_bch && !info->force_raw) {
u32 ts;
/*
@@ -612,12 +613,22 @@ static void drain_fifo(struct pxa3xx_nand_info *info,
void *data, int len)
static void handle_data_pio(struct pxa3xx_nand_info *info)
{
+ int data_len = info->step_chunk_size;
+
+ /*
+* In raw mode, include the spare area and the ECC bytes that are not
+* consumed by the controller in the data section. Do not reorganize
+* here, do it in the ->read_page_raw() handler instead.
+*/
+ if (info->force_raw)
+ data_len += info->step_spare_size + info->ecc_size;
+
switch (info->state) {
case STATE_PIO_WRITING:
if (info->step_chunk_size)
writesl(info->mmio_base + NDDB,
info->data_buff + info->data_buff_pos,
- DIV_ROUND_UP(info->step_chunk_size, 4));
+ DIV_ROUND_UP(data_len, 4));
if (info->step_spare_size)
writesl(info->mmio_base + NDDB,
@@ -628,7 +639,10 @@ static void handle_data_pio(struct pxa3xx_nand_info *info)
if (info->step_chunk_size)
drain_fifo(info,
info->data_buff + info->data_buff_pos,
- DIV_ROUND_UP(info->step_chunk_size, 4));
+ DIV_ROUND_UP(data_len, 4));
+
+ if (info->force_raw)
+ break;
if (info->step_spare_size)
drain_fifo(info,
@@ -642,7 +656,7 @@ static void handle_data_pio(struct pxa3xx_nand_info *info)
}
/* Update buffer pointers for multi-page read/write */
- info->data_buff_pos += info->step_chunk_size;
+ info->data_buff_pos += data_len;
info->oob_buff_pos += info->step_spare_size;
}
@@ -796,7 +810,8 @@ static void prepare_start_command(struct pxa3xx_nand_info
*info, int command)
case NAND_CMD_READ0:
case NAND_CMD_READOOB:
case NAND_CMD_PAGEPROG:
- info->use_ecc = 1;
+ if (!info->force_raw)
+ info->use_ecc = 1;
break;
case NAND_CMD_PARAM:
info->use_spare = 0;
@@ -866,7 +881,13 @@ static int prepare_set_command(struct pxa3xx_nand_info
*info, int command,
* which is either naked-read or last-read according to the
* state.
*/
- if (mtd->writesize == info->chunk_size) {
+ if (info->force_raw) {
+ info->ndcb0 |= NDCB0_DBC | (NAND_CMD_READSTART << 8) |
+ NDCB0_LEN_OVRD |
+ NDCB0_EXT_CMD_TYPE(ext_cmd_type);
+ info->ndcb3 = info->step_chunk_size +
+ info->step_spare_size + info->ecc_size;
+ } else if (mtd->writesize == info->chunk_size) {
info->ndcb0 |= NDCB0_DBC | (NAND_CMD_READSTART << 8);
} else if (mtd->writesize > info->chunk_size) {
info->ndcb0 |= NDCB0_DBC | (NAND_CMD_READSTART << 8)
@@ -1238,6 +1259,69 @@ static int pxa3xx_nand_read_page_hwecc(struct mtd_info
*mtd,
return info->max_bitflips;
}
+static int pxa3xx_nand_read_page_raw(struct mtd_info *mtd,
+struct nand_chip *chip, uint8_t *buf,
+i
[U-Boot] [PATCH 3/3] mtd: rawnand: pxa3xx: fix 2kiB pages with 8b strength chips layout
The initial layout for such NAND chips was the following:
++
| 1024 (data) | 30 (ECC) | 1024 (data) | 30 (ECC) | 32 (free OOB) | 30 (ECC) |
++
This layout has a weakness: reading empty pages trigger ECC errors
(this is expected), but the hardware ECC engine tries to correct the
data anyway and creates itself bitflips, hence bitflips are detected
in erased pages while actually there are none in the NAND chip.
Two solutions have been found at the same time. One was to enlarge the
free OOB area to 64 bytes, changing the layout to be:
++
| 1024 (data) | 30 (ECC) | 1024 (data) | 30 (ECC) | 64 (free OOB) | 30 (ECC) |
++
^^
The very big drawbacks of this solution are:
1/ It prevents booting from NAND.
2/ The current Linux driver (marvell_nand) does not have such problem
because it already re-reads possible empty pages in raw mode before
checking for bitflips. Using different layouts in U-Boot and Linux
would simply not work.
As this driver does support raw reads now and uses it to check for
empty pages, let's forget about this broken hack and return to the
initial layout with only 32 free OOB bytes.
Fixes: ac56a3b30c ("mtd: nand: pxa3xx: add support for 2KB 8-bit flash")
Signed-off-by: Miquel Raynal
---
drivers/mtd/nand/raw/pxa3xx_nand.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/mtd/nand/raw/pxa3xx_nand.c
b/drivers/mtd/nand/raw/pxa3xx_nand.c
index 492485b1d0..4d2712df4c 100644
--- a/drivers/mtd/nand/raw/pxa3xx_nand.c
+++ b/drivers/mtd/nand/raw/pxa3xx_nand.c
@@ -327,14 +327,14 @@ static struct nand_ecclayout ecc_layout_2KB_bch4bit = {
static struct nand_ecclayout ecc_layout_2KB_bch8bit = {
.eccbytes = 64,
.eccpos = {
- 64, 65, 66, 67, 68, 69, 70, 71,
- 72, 73, 74, 75, 76, 77, 78, 79,
- 80, 81, 82, 83, 84, 85, 86, 87,
- 88, 89, 90, 91, 92, 93, 94, 95,
- 96, 97, 98, 99, 100, 101, 102, 103,
- 104, 105, 106, 107, 108, 109, 110, 111,
- 112, 113, 114, 115, 116, 117, 118, 119,
- 120, 121, 122, 123, 124, 125, 126, 127},
+ 32, 33, 34, 35, 36, 37, 38, 39,
+ 40, 41, 42, 43, 44, 45, 46, 47,
+ 48, 49, 50, 51, 52, 53, 54, 55,
+ 56, 57, 58, 59, 60, 61, 62, 63,
+ 64, 65, 66, 67, 68, 69, 70, 71,
+ 72, 73, 74, 75, 76, 77, 78, 79,
+ 80, 81, 82, 83, 84, 85, 86, 87,
+ 88, 89, 90, 91, 92, 93, 94, 95},
.oobfree = { {1, 4}, {6, 26} }
};
@@ -1591,7 +1591,7 @@ static int pxa_ecc_init(struct pxa3xx_nand_info *info,
info->chunk_size = 1024;
info->spare_size = 0;
info->last_chunk_size = 1024;
- info->last_spare_size = 64;
+ info->last_spare_size = 32;
info->ecc_size = 32;
ecc->mode = NAND_ECC_HW;
ecc->size = info->chunk_size;
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] i2c: Fix pca953x endianess issue, commit daa75b34828d45b7c1d63009188d45f4a32d06ba
On Thu, 2018-10-11 at 16:11 +0200, Dirk Eibach wrote: > > Hello, > > we have a 16 bit value here, so we have to define whether bit0(containin the > information for IO0.0) is in the first or the second byte. Since the PCA9555 > does this encoding little endian, the conversion is allright. > You used it as some number but this is really just a bunch I/O pins. I haven't seen any endian conversion in the kernel driver, have you? This is a bigger question than this driver really, so: Does IO pins have an endian? Jocke > Cheers > Dirk > Am Do., 11. Okt. 2018 um 07:42 Uhr schrieb Heiko Schocher : > > > > Hello Joakim, > > > > Am 10.10.2018 um 19:34 schrieb Joakim Tjernlund: > > > This commit broke our pca953x usage(on ppc). > > > > > > I wonder why gpio pins here has an endian, its not a number. > > > If there must be an endian connected with this, should it not > > > be a cpu_to_be16 instead, which will retain compatibility ? > > > > Hmm.. good question, I think you are right. May dirk can do a test? > > I have no pca953x with 16bit for doing a test. > > > > bye, > > Heiko > > -- > > DENX Software Engineering GmbH, Managing Director: Wolfgang Denk > > HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany > > Phone: +49-8142-66989-52 Fax: +49-8142-66989-80 Email: h...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/4] dm: adc: add uclass's mask and conversion helpers
Add two functions to ADC uclass's:
- adc_raw_to_uV() to ease ADC raw value conversion to microvolts
- adc_channel_mask() to get channels on consumer side
Signed-off-by: Fabrice Gasnier
---
drivers/adc/adc-uclass.c | 37 +
include/adc.h| 21 +
2 files changed, 58 insertions(+)
diff --git a/drivers/adc/adc-uclass.c b/drivers/adc/adc-uclass.c
index 738c1ea..0a492eb 100644
--- a/drivers/adc/adc-uclass.c
+++ b/drivers/adc/adc-uclass.c
@@ -6,6 +6,7 @@
#include
#include
+#include
#include
#include
#include
@@ -77,6 +78,18 @@ int adc_data_mask(struct udevice *dev, unsigned int
*data_mask)
return 0;
}
+int adc_channel_mask(struct udevice *dev, unsigned int *channel_mask)
+{
+ struct adc_uclass_platdata *uc_pdata = dev_get_uclass_platdata(dev);
+
+ if (!uc_pdata)
+ return -ENOSYS;
+
+ *channel_mask = uc_pdata->channel_mask;
+
+ return 0;
+}
+
int adc_stop(struct udevice *dev)
{
const struct adc_ops *ops = dev_get_driver_ops(dev);
@@ -329,6 +342,30 @@ int adc_vss_value(struct udevice *dev, int *uV)
return 0;
}
+int adc_raw_to_uV(struct udevice *dev, unsigned int raw, int *uV)
+{
+ unsigned int data_mask;
+ int ret, val, vref;
+ u64 raw64 = raw;
+
+ ret = adc_vdd_value(dev, &vref);
+ if (ret)
+ return ret;
+
+ if (!adc_vss_value(dev, &val))
+ vref -= val;
+
+ ret = adc_data_mask(dev, &data_mask);
+ if (ret)
+ return ret;
+
+ raw64 *= vref;
+ do_div(raw64, data_mask);
+ *uV = raw64;
+
+ return 0;
+}
+
static int adc_vdd_platdata_set(struct udevice *dev)
{
struct adc_uclass_platdata *uc_pdata = dev_get_uclass_platdata(dev);
diff --git a/include/adc.h b/include/adc.h
index d04c9c4..5841dfb 100644
--- a/include/adc.h
+++ b/include/adc.h
@@ -219,6 +219,17 @@ int adc_channels_data(struct udevice *dev, unsigned int
channel_mask,
int adc_data_mask(struct udevice *dev, unsigned int *data_mask);
/**
+ * adc_channel_mask() - get channel mask for given ADC device
+ *
+ * This can be used if adc uclass platform data is filled.
+ *
+ * @dev: ADC device to check
+ * @channel_mask: pointer to the returned channel bitmask
+ * @return: 0 if OK, -ve on error
+ */
+int adc_channel_mask(struct udevice *dev, unsigned int *channel_mask);
+
+/**
* adc_channel_single_shot() - get output data of conversion for the ADC
* device's channel. This function searches for the device with the given name,
* starts the given channel conversion and returns the output data.
@@ -284,4 +295,14 @@ int adc_vss_value(struct udevice *dev, int *uV);
*/
int adc_stop(struct udevice *dev);
+/**
+ * adc_raw_to_uV() - converts raw value to microvolts for given ADC device.
+ *
+ * @dev: ADC device used from conversion
+ * @raw: raw value to convert
+ * @uV: converted value in microvolts
+ * @return: 0 on success or -ve on error
+ */
+int adc_raw_to_uV(struct udevice *dev, unsigned int raw, int *uV);
+
#endif
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 2/4] cmd: adc: add info on channel mask
Enhance adc info command to report also the channel mask.
Signed-off-by: Fabrice Gasnier
---
cmd/adc.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/cmd/adc.c b/cmd/adc.c
index c8857ed..39f61c1 100644
--- a/cmd/adc.c
+++ b/cmd/adc.c
@@ -35,7 +35,7 @@ static int do_adc_info(cmd_tbl_t *cmdtp, int flag, int argc,
char *const argv[])
{
struct udevice *dev;
- unsigned int data_mask;
+ unsigned int data_mask, ch_mask;
int ret, vss, vdd;
if (argc < 2)
@@ -49,6 +49,10 @@ static int do_adc_info(cmd_tbl_t *cmdtp, int flag, int argc,
printf("ADC Device '%s' :\n", argv[1]);
+ ret = adc_channel_mask(dev, &ch_mask);
+ if (!ret)
+ printf("channel mask: %x\n", ch_mask);
+
ret = adc_data_mask(dev, &data_mask);
if (!ret)
printf("data mask: %x\n", data_mask);
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 0/4] Add adc uclass's channel mask and conversion helpers and enhance adc cmd
This series adds ADC uclass's helpers to - retrieve the ADC device available channels - ease conversions to standard unit (µV) - enhance 'adc' command to print information on available ADC channels - enhance 'adc' command to print conversion result both as raw and µV - enhance 'adc' command to scan once several or all channels Fabrice Gasnier (4): dm: adc: add uclass's mask and conversion helpers cmd: adc: add info on channel mask cmd: adc: print single conversion also in uV cmd: adc: add an option to scan some or all available channels cmd/adc.c| 70 +--- drivers/adc/adc-uclass.c | 37 + include/adc.h| 21 +++ 3 files changed, 124 insertions(+), 4 deletions(-) -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 4/4] cmd: adc: add an option to scan some or all available channels
Add new option to 'adc' command to do a single scan of:
- some channel(s), using mask argument
- all channels available on an ADC device (when optional mask is omitted).
Signed-off-by: Fabrice Gasnier
---
cmd/adc.c | 55 ++-
1 file changed, 54 insertions(+), 1 deletion(-)
diff --git a/cmd/adc.c b/cmd/adc.c
index 7360a96..2d635ac 100644
--- a/cmd/adc.c
+++ b/cmd/adc.c
@@ -95,10 +95,62 @@ static int do_adc_single(cmd_tbl_t *cmdtp, int flag, int
argc,
return CMD_RET_SUCCESS;
}
+static int do_adc_scan(cmd_tbl_t *cmdtp, int flag, int argc,
+ char *const argv[])
+{
+ struct adc_channel ch[ADC_MAX_CHANNEL];
+ struct udevice *dev;
+ unsigned int ch_mask;
+ int i, chan, ret, uV;
+
+ if (argc < 2)
+ return CMD_RET_USAGE;
+
+ ret = uclass_get_device_by_name(UCLASS_ADC, argv[1], &dev);
+ if (ret) {
+ pr_err("Can't get the ADC %s: %d\n", argv[1], ret);
+ return CMD_RET_FAILURE;
+ }
+
+ switch (argc) {
+ case 3:
+ ch_mask = simple_strtoul(argv[2], NULL, 0);
+ if (ch_mask)
+ break;
+ case 2:
+ ret = adc_channel_mask(dev, &ch_mask);
+ if (ret) {
+ pr_err("Can't get mask for %s: %d\n", dev->name, ret);
+ return CMD_RET_FAILURE;
+ }
+ break;
+ }
+
+ ret = adc_channels_single_shot(dev->name, ch_mask, ch);
+ if (ret) {
+ pr_err("Can't get single shot for %s (chans mask: 0x%x): %d\n",
+ dev->name, ch_mask, ret);
+ return CMD_RET_FAILURE;
+ }
+
+ for (chan = 0, i = 0; chan < ADC_MAX_CHANNEL; chan++) {
+ if (!(ch_mask & ADC_CHANNEL(chan)))
+ continue;
+ if (!adc_raw_to_uV(dev, ch[i].data, &uV))
+ printf("[%02d]: %u, %d uV\n", ch[i].id, ch[i].data, uV);
+ else
+ printf("[%02d]: %u\n", ch[i].id, ch[i].data);
+ i++;
+ }
+
+ return CMD_RET_SUCCESS;
+}
+
static cmd_tbl_t cmd_adc_sub[] = {
U_BOOT_CMD_MKENT(list, 1, 1, do_adc_list, "", ""),
U_BOOT_CMD_MKENT(info, 2, 1, do_adc_info, "", ""),
U_BOOT_CMD_MKENT(single, 3, 1, do_adc_single, "", ""),
+ U_BOOT_CMD_MKENT(scan, 3, 1, do_adc_scan, "", ""),
};
static int do_adc(cmd_tbl_t *cmdtp, int flag, int argc,
@@ -124,6 +176,7 @@ static int do_adc(cmd_tbl_t *cmdtp, int flag, int argc,
static char adc_help_text[] =
"list - list ADC devices\n"
"adc info - Get ADC device info\n"
- "adc single - Get Single data of ADC device channel";
+ "adc single - Get Single data of ADC device channel\n"
+ "adc scan [channel mask] - Scan all [or masked] ADC channels";
U_BOOT_CMD(adc, 4, 1, do_adc, "ADC sub-system", adc_help_text);
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 3/4] cmd: adc: print single conversion also in uV
Use newly introduced adc_raw_to_uV() API to print conversion result
both as raw value and micro-volts by default.
Signed-off-by: Fabrice Gasnier
---
cmd/adc.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/cmd/adc.c b/cmd/adc.c
index 39f61c1..7360a96 100644
--- a/cmd/adc.c
+++ b/cmd/adc.c
@@ -71,8 +71,9 @@ static int do_adc_info(cmd_tbl_t *cmdtp, int flag, int argc,
static int do_adc_single(cmd_tbl_t *cmdtp, int flag, int argc,
char *const argv[])
{
+ struct udevice *dev;
unsigned int data;
- int ret;
+ int ret, uV;
if (argc < 3)
return CMD_RET_USAGE;
@@ -85,7 +86,11 @@ static int do_adc_single(cmd_tbl_t *cmdtp, int flag, int
argc,
return CMD_RET_FAILURE;
}
- printf("%u\n", data);
+ ret = uclass_get_device_by_name(UCLASS_ADC, argv[1], &dev);
+ if (!ret && !adc_raw_to_uV(dev, data, &uV))
+ printf("%u, %d uV\n", data, uV);
+ else
+ printf("%u\n", data);
return CMD_RET_SUCCESS;
}
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/3] serial: bcm6858: add serial support
This driver add the support of serial on bcm6858. It's based on serial for bcm6345. Signed-off-by: Philippe Reynes --- drivers/serial/Kconfig | 6 + drivers/serial/Makefile | 1 + drivers/serial/serial_bcm6858.c | 300 3 files changed, 307 insertions(+) create mode 100644 drivers/serial/serial_bcm6858.c diff --git a/drivers/serial/Kconfig b/drivers/serial/Kconfig index 5fa2725..4d094c3 100644 --- a/drivers/serial/Kconfig +++ b/drivers/serial/Kconfig @@ -479,6 +479,12 @@ config BCM6345_SERIAL help Select this to enable UART on BCM6345 SoCs. +config BCM6858_SERIAL + bool "Support for BCM6858 UART" + depends on DM_SERIAL && ARCH_BCM6858 + help + Select this to enable UART on BCM6358 SoCs. + config FSL_LINFLEXUART bool "Freescale Linflex UART support" depends on DM_SERIAL diff --git a/drivers/serial/Makefile b/drivers/serial/Makefile index 03dc29e..a48458f 100644 --- a/drivers/serial/Makefile +++ b/drivers/serial/Makefile @@ -35,6 +35,7 @@ obj-$(CONFIG_AR933X_UART) += serial_ar933x.o obj-$(CONFIG_ARM_DCC) += arm_dcc.o obj-$(CONFIG_ATMEL_USART) += atmel_usart.o obj-$(CONFIG_BCM6345_SERIAL) += serial_bcm6345.o +obj-$(CONFIG_BCM6858_SERIAL) += serial_bcm6858.o obj-$(CONFIG_EFI_APP) += serial_efi.o obj-$(CONFIG_LPC32XX_HSUART) += lpc32xx_hsuart.o obj-$(CONFIG_MCFUART) += mcfuart.o diff --git a/drivers/serial/serial_bcm6858.c b/drivers/serial/serial_bcm6858.c new file mode 100644 index 000..8aa3705 --- /dev/null +++ b/drivers/serial/serial_bcm6858.c @@ -0,0 +1,300 @@ +// SPDX-License-Identifier: GPL-2.0+ +/* + * Copyright (C) 2018 Philippe Reynes + * + * Derived from linux/drivers/tty/serial/bcm63xx_uart.c: + * Copyright (C) 2008 Maxime Bizon + * Derived from linux/drivers/tty/serial/serial_bcm6345.c + * Copyright (C) 2017 Álvaro Fernández Rojas + */ + +#include +#include +#include +#include +#include +#include +#include + +/* UART Control register */ +#define UART_CTL_REG 0x0 +#define UART_CTL_RXTIMEOUT_MASK0x1f +#define UART_CTL_RXTIMEOUT_5 0x5 +#define UART_CTL_RSTRXFIFO_SHIFT 6 +#define UART_CTL_RSTRXFIFO_MASK(1 << UART_CTL_RSTRXFIFO_SHIFT) +#define UART_CTL_RSTTXFIFO_SHIFT 7 +#define UART_CTL_RSTTXFIFO_MASK(1 << UART_CTL_RSTTXFIFO_SHIFT) +#define UART_CTL_STOPBITS_SHIFT8 +#define UART_CTL_STOPBITS_MASK (0xf << UART_CTL_STOPBITS_SHIFT) +#define UART_CTL_STOPBITS_1(0x7 << UART_CTL_STOPBITS_SHIFT) +#define UART_CTL_BITSPERSYM_SHIFT 12 +#define UART_CTL_BITSPERSYM_MASK (0x3 << UART_CTL_BITSPERSYM_SHIFT) +#define UART_CTL_BITSPERSYM_8 (0x3 << UART_CTL_BITSPERSYM_SHIFT) +#define UART_CTL_XMITBRK_SHIFT 14 +#define UART_CTL_XMITBRK_MASK (1 << UART_CTL_XMITBRK_SHIFT) +#define UART_CTL_RSVD_SHIFT15 +#define UART_CTL_RSVD_MASK (1 << UART_CTL_RSVD_SHIFT) +#define UART_CTL_RXPAREVEN_SHIFT 16 +#define UART_CTL_RXPAREVEN_MASK(1 << UART_CTL_RXPAREVEN_SHIFT) +#define UART_CTL_RXPAREN_SHIFT 17 +#define UART_CTL_RXPAREN_MASK (1 << UART_CTL_RXPAREN_SHIFT) +#define UART_CTL_TXPAREVEN_SHIFT 18 +#define UART_CTL_TXPAREVEN_MASK(1 << UART_CTL_TXPAREVEN_SHIFT) +#define UART_CTL_TXPAREN_SHIFT 19 +#define UART_CTL_TXPAREN_MASK (1 << UART_CTL_TXPAREN_SHIFT) +#define UART_CTL_LOOPBACK_SHIFT20 +#define UART_CTL_LOOPBACK_MASK (1 << UART_CTL_LOOPBACK_SHIFT) +#define UART_CTL_RXEN_SHIFT21 +#define UART_CTL_RXEN_MASK (1 << UART_CTL_RXEN_SHIFT) +#define UART_CTL_TXEN_SHIFT22 +#define UART_CTL_TXEN_MASK (1 << UART_CTL_TXEN_SHIFT) +#define UART_CTL_BRGEN_SHIFT 23 +#define UART_CTL_BRGEN_MASK(1 << UART_CTL_BRGEN_SHIFT) + +/* UART Baudword register */ +#define UART_BAUD_REG 0x4 + +/* UART FIFO Config register */ +#define UART_FIFO_CFG_REG 0x8 +#define UART_FIFO_CFG_RX_SHIFT 8 +#define UART_FIFO_CFG_RX_MASK (0xf << UART_FIFO_CFG_RX_SHIFT) +#define UART_FIFO_CFG_RX_4 (0x4 << UART_FIFO_CFG_RX_SHIFT) +#define UART_FIFO_CFG_TX_SHIFT 12 +#define UART_FIFO_CFG_TX_MASK (0xf << UART_FIFO_CFG_TX_SHIFT) +#define UART_FIFO_CFG_TX_4 (0x4 << UART_FIFO_CFG_TX_SHIFT) + +/* UART Interrupt register */ +#define UART_IR_REG0x10 +#define UART_IR_STAT(x)(1 << (x)) +#define UART_IR_TXEMPTY5 +#define UART_IR_RXOVER 7 +#define UART_IR_RXNOTEMPTY 11 + +/* UART FIFO register */ +#define UART_FIFO_REG 0x14 +#define UART_FIFO_VALID_MASK 0xff +#define UART_FIFO_FRAMEERR_SHIFT 8 +#define UART_FIFO_FRAMEERR_MASK(1 << UART_FIFO_FRAMEERR_SHIFT) +#de
[U-Boot] [PATCH 3/3] bcm968580xref: add initial support
This add the initial support of the broadcom reference
board bcm968580xref with a bcm6858 SoC.
This board has 512 MB of ram, 256 MB of flash (nand),
2 usb port, 1 uart, 4 ethernet ports (LAN), 1 ethernet port (WAN).
Signed-off-by: Philippe Reynes
---
arch/arm/dts/bcm968580xref.dts | 31 ++
board/broadcom/bcm968580xref/Kconfig | 17
board/broadcom/bcm968580xref/MAINTAINERS | 6 +++
board/broadcom/bcm968580xref/Makefile| 3 ++
board/broadcom/bcm968580xref/bcm968580xref.c | 61
configs/bcm968580_ram_defconfig | 36
include/configs/broadcom_bcm968580xref.h | 36
7 files changed, 190 insertions(+)
create mode 100644 arch/arm/dts/bcm968580xref.dts
create mode 100644 board/broadcom/bcm968580xref/Kconfig
create mode 100644 board/broadcom/bcm968580xref/MAINTAINERS
create mode 100644 board/broadcom/bcm968580xref/Makefile
create mode 100644 board/broadcom/bcm968580xref/bcm968580xref.c
create mode 100644 configs/bcm968580_ram_defconfig
create mode 100644 include/configs/broadcom_bcm968580xref.h
diff --git a/arch/arm/dts/bcm968580xref.dts b/arch/arm/dts/bcm968580xref.dts
new file mode 100644
index 000..0c59f94
--- /dev/null
+++ b/arch/arm/dts/bcm968580xref.dts
@@ -0,0 +1,31 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2018 Philippe Reynes
+ */
+
+/dts-v1/;
+
+#include "bcm6858.dtsi"
+
+/ {
+ model = "Broadcom bcm68580xref";
+ compatible = "broadcom,bcm68580xref", "brcm,bcm6858";
+
+ aliases {
+ serial0 = &uart0;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+
+ memory {
+ device_type = "memory";
+ reg = <0x0 0x0 0x0 0x2000>;
+ };
+};
+
+&uart0 {
+ u-boot,dm-pre-reloc;
+ status = "okay";
+};
diff --git a/board/broadcom/bcm968580xref/Kconfig
b/board/broadcom/bcm968580xref/Kconfig
new file mode 100644
index 000..b573036
--- /dev/null
+++ b/board/broadcom/bcm968580xref/Kconfig
@@ -0,0 +1,17 @@
+if ARCH_BCM6858
+
+config SYS_VENDOR
+ default "broadcom"
+
+config SYS_BOARD
+ default "bcm968580xref"
+
+config SYS_CONFIG_NAME
+ default "broadcom_bcm968580xref"
+
+endif
+
+config TARGET_BCM968580XREF
+ bool "Support Broadcom bcm968580xref"
+ depends on ARCH_BCM6858
+ select ARM64
diff --git a/board/broadcom/bcm968580xref/MAINTAINERS
b/board/broadcom/bcm968580xref/MAINTAINERS
new file mode 100644
index 000..3e4691a
--- /dev/null
+++ b/board/broadcom/bcm968580xref/MAINTAINERS
@@ -0,0 +1,6 @@
+BROADCOM BCM968580XREF
+M: Philippe Reynes
+S: Maintained
+F: board/broadcom/bcm968580xref/
+F: include/configs/broadcom_bcm968580xref.h
+F: configs/bcm9686580xref_ram_defconfig
diff --git a/board/broadcom/bcm968580xref/Makefile
b/board/broadcom/bcm968580xref/Makefile
new file mode 100644
index 000..5cd393b
--- /dev/null
+++ b/board/broadcom/bcm968580xref/Makefile
@@ -0,0 +1,3 @@
+# SPDX-License-Identifier: GPL-2.0+
+
+obj-y += bcm968580xref.o
diff --git a/board/broadcom/bcm968580xref/bcm968580xref.c
b/board/broadcom/bcm968580xref/bcm968580xref.c
new file mode 100644
index 000..2e547f5
--- /dev/null
+++ b/board/broadcom/bcm968580xref/bcm968580xref.c
@@ -0,0 +1,61 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2018 Philippe Reynes
+ */
+
+#include
+#include
+#include
+
+#ifdef CONFIG_ARM64
+#include
+
+static struct mm_region broadcom_bcm968580xref_mem_map[] = {
+ {
+ /* RAM */
+ .virt = 0xUL,
+ .phys = 0xUL,
+ .size = 8UL * SZ_1G,
+ .attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL) |
+PTE_BLOCK_INNER_SHARE
+ }, {
+ /* SoC */
+ .virt = 0x8000UL,
+ .phys = 0x8000UL,
+ .size = 0xff8000UL,
+ .attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
+PTE_BLOCK_NON_SHARE |
+PTE_BLOCK_PXN | PTE_BLOCK_UXN
+ }, {
+ /* List terminator */
+ 0,
+ }
+};
+
+struct mm_region *mem_map = broadcom_bcm968580xref_mem_map;
+#endif
+
+int board_init(void)
+{
+ return 0;
+}
+
+int dram_init(void)
+{
+ if (fdtdec_setup_mem_size_base() != 0)
+ printf("fdtdec_setup_mem_size_base() has failed\n");
+
+ return 0;
+}
+
+int dram_init_banksize(void)
+{
+ fdtdec_setup_memory_banksize();
+
+ return 0;
+}
+
+int print_cpuinfo(void)
+{
+ return 0;
+}
diff --git a/configs/bcm968580_ram_defconfig b/configs/bcm968580_ram_defconfig
new file mode 100644
index 000..abe90ee
--- /dev/null
+++ b/configs/bcm968580_ram_defconfig
@@ -0,0 +1,36 @@
+CONFIG_ARM=y
+CONFIG_ARCH_BCM6858=y
+CONFIG_SYS_TEXT_BASE=0x1000
+CONFIG_SYS_MALLOC_F_LEN=0x8000
+CONFIG_SPL_SYS_MALLOC_F_LEN
[U-Boot] [PATCH 2/3] bcm6858: add initial support
This add the initial support of the broadcom bcm6858 SoC family,
only the cpu, dram and uart are supported.
Signed-off-by: Philippe Reynes
---
arch/arm/Kconfig | 7
arch/arm/dts/bcm6858.dtsi | 85 +++
2 files changed, 92 insertions(+)
create mode 100644 arch/arm/dts/bcm6858.dtsi
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index ccf2a84..99c1711 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -538,6 +538,12 @@ config ARCH_BCM283X
imply CMD_DM
imply FAT_WRITE
+config ARCH_BCM6858
+ bool "Broadcom BCM6858 family"
+ select DM
+ select OF_CONTROL
+ imply CMD_DM
+
config TARGET_VEXPRESS_CA15_TC2
bool "Support vexpress_ca15_tc2"
select CPU_V7A
@@ -1468,6 +1474,7 @@ source "board/armltd/vexpress/Kconfig"
source "board/armltd/vexpress64/Kconfig"
source "board/broadcom/bcm23550_w1d/Kconfig"
source "board/broadcom/bcm28155_ap/Kconfig"
+source "board/broadcom/bcm968580xref/Kconfig"
source "board/broadcom/bcmcygnus/Kconfig"
source "board/broadcom/bcmnsp/Kconfig"
source "board/broadcom/bcmns2/Kconfig"
diff --git a/arch/arm/dts/bcm6858.dtsi b/arch/arm/dts/bcm6858.dtsi
new file mode 100644
index 000..9869d72
--- /dev/null
+++ b/arch/arm/dts/bcm6858.dtsi
@@ -0,0 +1,85 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2018 Philippe Reynes
+ */
+
+#include "skeleton64.dtsi"
+
+/ {
+ compatible = "brcm,bcm6858";
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ cpus {
+ #address-cells = <2>;
+ #size-cells = <0>;
+ u-boot,dm-pre-reloc;
+
+ cpu0: cpu@0 {
+ compatible = "arm,cortex-a53", "arm,armv8";
+ device_type = "cpu";
+ reg = <0x0 0x0>;
+ next-level-cache = <&l2>;
+ u-boot,dm-pre-reloc;
+ };
+
+ cpu1: cpu@1 {
+ compatible = "arm,cortex-a53", "arm,armv8";
+ device_type = "cpu";
+ reg = <0x0 0x1>;
+ next-level-cache = <&l2>;
+ u-boot,dm-pre-reloc;
+ };
+
+ cpu2: cpu@2 {
+ compatible = "arm,cortex-a53", "arm,armv8";
+ device_type = "cpu";
+ reg = <0x0 0x2>;
+ next-level-cache = <&l2>;
+ u-boot,dm-pre-reloc;
+ };
+
+ cpu3: cpu@3 {
+ compatible = "arm,cortex-a53", "arm,armv8";
+ device_type = "cpu";
+ reg = <0x0 0x3>;
+ next-level-cache = <&l2>;
+ u-boot,dm-pre-reloc;
+ };
+
+ l2: l2-cache0 {
+ compatible = "cache";
+ u-boot,dm-pre-reloc;
+ };
+ };
+
+ clocks {
+ compatible = "simple-bus";
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+ u-boot,dm-pre-reloc;
+
+ periph_osc: periph-osc {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <2>;
+ u-boot,dm-pre-reloc;
+ };
+ };
+
+ ubus {
+ compatible = "simple-bus";
+ #address-cells = <2>;
+ #size-cells = <2>;
+ u-boot,dm-pre-reloc;
+
+ uart0: serial@ff800640 {
+ compatible = "brcm,bcm6858-uart";
+ reg = <0x0 0xff800640 0x0 0x18>;
+ clocks = <&periph_osc>;
+
+ status = "disabled";
+ };
+ };
+};
--
2.7.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/4] x86: Ensure no instruction sets of MMX/SSE are generated in 64-bit build
On 10/11/2018 03:53 AM, Bin Meng wrote: > With the '-march=core2' fix, it seems that we have some luck that > the 64-bit U-Boot boots again. However if we examine the disassembly > codes there are still SSE instructions elsewhere which means passing > cpu type to GCC is not enough to prevent it from generating these > instructions. A simple test case is doing a 'bootefi selftest' from > the U-Boot shell and it leads to a reset too. I can confirm that an unexpected reset patch occurs without the patch. > > The 'bootefi selftest' reset is even seen with the image created by > the relative older GCC 5.4.0, the one shipped by Ubuntu 16.04. > > To make sure no MMX/SSE instruction sets are generated, tell GCC not > to do this. Note AVX is out of the question as CORE2 is old enough > to support AVX yet. > > Signed-off-by: Bin Meng > --- > > arch/x86/config.mk | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/arch/x86/config.mk b/arch/x86/config.mk > index 576501e..8151e47 100644 > --- a/arch/x86/config.mk > +++ b/arch/x86/config.mk > @@ -24,6 +24,7 @@ ifeq ($(IS_32BIT),y) > PLATFORM_CPPFLAGS += -march=i386 -m32 > else > PLATFORM_CPPFLAGS += $(if $(CONFIG_SPL_BUILD),,-fpic) -fno-common > -march=core2 -m64 > +PLATFORM_CPPFLAGS += -mno-mmx -mno-sse According to https://wiki.osdev.org/SSE SSE has to be initialized. Otherwise SSE instructions lead to an undefined instruction exception. Is it this initialization that we lack? If this is your motivation please, state it in the commit message. I think this patch could be squashed with the prior one. Heinrich > endif > > PLATFORM_RELFLAGS += -fdata-sections -ffunction-sections -fvisibility=hidden > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot,11/45] rtc: Allow use of RTC in SPL and TPL
On 10/01/2018 08:22 PM, Simon Glass wrote:
> Add Kconfig options so that the RTC can be used in SPL and TPL. This is
> helpful for accessing the contents of CMOS RAM, for example.
>
> Signed-off-by: Simon Glass
> Signed-off-by: Simon Glass
> ---
Hello Simon,
with this patch x86_64 does not boot anymore:
$ qemu-system-x86_64 -bios u-boot.rom -nographic --enable-kvm --cpu host
### ERROR ### Please RESET the board ###
I am currently testing Bin's patch series:
https://patchwork.ozlabs.org/project/uboot/list/?series=70127
[U-Boot,1/4] x86: Specify -march=core2 to build 64-bit U-Boot proper
>
> drivers/rtc/Kconfig | 18 ++
> drivers/rtc/Makefile | 2 +-
> drivers/rtc/rtc-uclass.c | 1 +
> 3 files changed, 20 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
> index 97cf7d84dfa..bcc01b135e5 100644
> --- a/drivers/rtc/Kconfig
> +++ b/drivers/rtc/Kconfig
> @@ -13,6 +13,24 @@ config DM_RTC
> drivers to perform the actual functions. See rtc.h for a
> description of the API.
>
> +config SPL_DM_RTC
> + bool "Enable Driver Model for RTC drivers in SPL"
> + depends on SPL_DM
> + help
> + Enable drver model for real-time-clock drivers. The RTC uclass
> + then provides the rtc_get()/rtc_set() interface, delegating to
> + drivers to perform the actual functions. See rtc.h for a
> + description of the API.
> +
> +config TPL_DM_RTC
> + bool "Enable Driver Model for RTC drivers in TPL"
> + depends on TPL_DM
> + help
> + Enable drver model for real-time-clock drivers. The RTC uclass
> + then provides the rtc_get()/rtc_set() interface, delegating to
> + drivers to perform the actual functions. See rtc.h for a
> + description of the API.
> +
> config RTC_PCF2127
> bool "Enable PCF2127 driver"
> depends on DM_RTC
> diff --git a/drivers/rtc/Makefile b/drivers/rtc/Makefile
> index 513e3ffc079..1724602f1cb 100644
> --- a/drivers/rtc/Makefile
> +++ b/drivers/rtc/Makefile
> @@ -4,7 +4,7 @@
> # Wolfgang Denk, DENX Software Engineering, w...@denx.de.
> #ccflags-y += -DDEBUG
>
> -obj-$(CONFIG_DM_RTC) += rtc-uclass.o
> +obj-$(CONFIG_$(SPL_TPL_)DM_RTC) += rtc-uclass.o
This is the line to be reverted.
Best regards
Heinrich
>
> obj-$(CONFIG_RTC_AT91SAM9_RTT) += at91sam9_rtt.o
> obj-y += date.o
> diff --git a/drivers/rtc/rtc-uclass.c b/drivers/rtc/rtc-uclass.c
> index c676f0ff359..a0a238aedda 100644
> --- a/drivers/rtc/rtc-uclass.c
> +++ b/drivers/rtc/rtc-uclass.c
> @@ -122,4 +122,5 @@ int rtc_write32(struct udevice *dev, unsigned int reg,
> u32 value)
> UCLASS_DRIVER(rtc) = {
> .name = "rtc",
> .id = UCLASS_RTC,
> + .post_bind = dm_scan_fdt_dev,
> };
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] Pull request: u-boot-net.git master
Hi Tom, The few checkpatch alerts were checked to be exceptions. All passed travis. Thanks! The following changes since commit 0a60a81ba3860946551cb79aa6486aa076e357f3: Kconfig: sandbox: enable cmd_avb and dependencies (2018-10-07 13:34:19 -0400) are available in the git repository at: git://git.denx.de/u-boot-net.git master for you to fetch changes up to 1a048cd65645338069d591108031fa4ebe96d53f: driver: net: fsl-mc: Add support of multiple phys for dpmac (2018-10-10 12:45:28 -0500) Bin Meng (7): linux/mii.h: Sync with Linux kernel v4.17 linux/mdio.h: Sync with Linux kernel v4.17 linux/compat.h: Add netdev_### log macros net: pch_gbe: Make probe/remove static linux/if_ether.h: Initial import from Linux kernel v4.17 net.h: Include linux/if_ether.h to avoid duplication linux/if_ether.h: Add VLAN related macros Duncan Hare (1): net: Consolidate UDP header functions Janine Hagemann (3): net: phy: ti: Add lane swapping support in the DP83867 TI's PHY driver net: phy: ti: Recover from "port mirroring" N/A MODE4 net: phy: ti: Add binding for the CLK_OUT pin muxing Joe Hershberger (10): net: sandbox: Move disabled flag into priv struct net: sandbox: Refactor sandbox send function net: sandbox: Make the fake eth driver response configurable net: sandbox: Share the priv structure with tests net: sandbox: Allow fake eth to handle more than 1 packet response net: Add an accessor to know if waiting for ARP net: sandbox: Add a priv ptr for tests to use test: eth: Add a test for ARP requests test: eth: Add a test for the target being pinged net: Don't overwrite waiting packets with asynchronous replies Pankaj Bansal (6): driver: net: fsl-mc: modify the label name driver: net: fsl-mc: remove unused strcture elements driver: net: fsl-mc: fix error handing in init_phy driver: net: fsl-mc: Modify the dpmac link detection method driver: net: fsl-mc: initialize dpmac irrespective of phy driver: net: fsl-mc: Add support of multiple phys for dpmac Priyanka Jain (1): phy: Add 25G_AUI, XLAUI, CAUI2, CAUI4 related macros arch/sandbox/include/asm/eth.h | 93 +++ board/Synology/ds414/cmd_syno.c | 1 - board/freescale/ls1088a/eth_ls1088aqds.c| 18 +- board/freescale/ls1088a/eth_ls1088ardb.c| 21 +- board/freescale/ls2080aqds/eth.c| 26 +- board/freescale/ls2080ardb/eth_ls2080rdb.c | 24 +- doc/device-tree-bindings/net/ti,dp83867.txt | 8 + drivers/net/dc2114x.c | 1 - drivers/net/eepro100.c | 2 - drivers/net/fsl-mc/mc.c | 6 +- drivers/net/ldpaa_eth/ldpaa_eth.c | 171 +++- drivers/net/ldpaa_eth/ldpaa_eth.h | 1 - drivers/net/ldpaa_eth/ldpaa_wriop.c | 69 +++-- drivers/net/mvneta.c| 8 - drivers/net/mvpp2.c | 13 - drivers/net/natsemi.c | 1 - drivers/net/ns8382x.c | 1 - drivers/net/pch_gbe.c | 4 +- drivers/net/phy/ti.c| 93 ++- drivers/net/rtl8139.c | 4 - drivers/net/rtl8169.c | 4 - drivers/net/sandbox.c | 417 +--- drivers/usb/eth/lan7x.h | 2 +- drivers/usb/gadget/ether.c | 9 +- drivers/usb/gadget/rndis.c | 6 - include/dt-bindings/net/ti-dp83867.h| 15 + include/fsl-mc/ldpaa_wriop.h| 46 +-- include/linux/compat.h | 19 ++ include/linux/if_ether.h| 178 include/linux/mdio.h| 34 ++- include/linux/mii.h | 126 + include/net.h | 16 +- include/phy_interface.h | 8 + include/usb_ether.h | 10 - net/arp.c | 20 +- net/arp.h | 1 + net/net.c | 43 ++- net/ping.c | 14 +- test/dm/eth.c | 170 39 files changed, 1294 insertions(+), 409 deletions(-) create mode 100644 include/linux/if_ether.h Thanks! -Joe ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] linux/mdio.h: Sync with Linux kernel v4.17
Hi Bin, https://patchwork.ozlabs.org/patch/949573/ was applied to http://git.denx.de/?p=u-boot/u-boot-net.git Thanks! -Joe ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] linux/compat.h: Add netdev_### log macros
Hi Bin, https://patchwork.ozlabs.org/patch/949577/ was applied to http://git.denx.de/?p=u-boot/u-boot-net.git Thanks! -Joe ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] linux/mii.h: Sync with Linux kernel v4.17
Hi Bin, https://patchwork.ozlabs.org/patch/949572/ was applied to http://git.denx.de/?p=u-boot/u-boot-net.git Thanks! -Joe ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] net.h: Include linux/if_ether.h to avoid duplication
Hi Bin, https://patchwork.ozlabs.org/patch/951500/ was applied to http://git.denx.de/?p=u-boot/u-boot-net.git Thanks! -Joe ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] phy: Add 25G_AUI, XLAUI, CAUI2, CAUI4 related macros
Hi Priyanka, https://patchwork.ozlabs.org/patch/962408/ was applied to http://git.denx.de/?p=u-boot/u-boot-net.git Thanks! -Joe ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] net: phy: ti: Recover from "port mirroring" N/A MODE4
Hi Janine, https://patchwork.ozlabs.org/patch/962746/ was applied to http://git.denx.de/?p=u-boot/u-boot-net.git Thanks! -Joe ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] net: sandbox: Share the priv structure with tests
Hi Joe, https://patchwork.ozlabs.org/patch/975409/ was applied to http://git.denx.de/?p=u-boot/u-boot-net.git Thanks! -Joe ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] net: sandbox: Add a priv ptr for tests to use
Hi Joe, https://patchwork.ozlabs.org/patch/975419/ was applied to http://git.denx.de/?p=u-boot/u-boot-net.git Thanks! -Joe ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] net: phy: ti: Add lane swapping support in the DP83867 TI's PHY driver
Hi Janine, https://patchwork.ozlabs.org/patch/962741/ was applied to http://git.denx.de/?p=u-boot/u-boot-net.git Thanks! -Joe ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] net: Consolidate UDP header functions
Hi Duncan, https://patchwork.ozlabs.org/patch/934006/ was applied to http://git.denx.de/?p=u-boot/u-boot-net.git Thanks! -Joe ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] linux/if_ether.h: Initial import from Linux kernel v4.17
Hi Bin, https://patchwork.ozlabs.org/patch/951499/ was applied to http://git.denx.de/?p=u-boot/u-boot-net.git Thanks! -Joe ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] net: phy: ti: Add binding for the CLK_OUT pin muxing
Hi Janine, https://patchwork.ozlabs.org/patch/962743/ was applied to http://git.denx.de/?p=u-boot/u-boot-net.git Thanks! -Joe ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] net: pch_gbe: Make probe/remove static
Hi Bin, https://patchwork.ozlabs.org/patch/950525/ was applied to http://git.denx.de/?p=u-boot/u-boot-net.git Thanks! -Joe ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] test: eth: Add a test for the target being pinged
Hi Joe, https://patchwork.ozlabs.org/patch/975410/ was applied to http://git.denx.de/?p=u-boot/u-boot-net.git Thanks! -Joe ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] net: sandbox: Move disabled flag into priv struct
Hi Joe, https://patchwork.ozlabs.org/patch/975411/ was applied to http://git.denx.de/?p=u-boot/u-boot-net.git Thanks! -Joe ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] linux/if_ether.h: Add VLAN related macros
Hi Bin, https://patchwork.ozlabs.org/patch/951501/ was applied to http://git.denx.de/?p=u-boot/u-boot-net.git Thanks! -Joe ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] net: Add an accessor to know if waiting for ARP
Hi Joe, https://patchwork.ozlabs.org/patch/975417/ was applied to http://git.denx.de/?p=u-boot/u-boot-net.git Thanks! -Joe ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] net: sandbox: Refactor sandbox send function
Hi Joe, https://patchwork.ozlabs.org/patch/975414/ was applied to http://git.denx.de/?p=u-boot/u-boot-net.git Thanks! -Joe ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] net: sandbox: Allow fake eth to handle more than 1 packet response
Hi Joe, https://patchwork.ozlabs.org/patch/975413/ was applied to http://git.denx.de/?p=u-boot/u-boot-net.git Thanks! -Joe ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] net: sandbox: Make the fake eth driver response configurable
Hi Joe, https://patchwork.ozlabs.org/patch/975408/ was applied to http://git.denx.de/?p=u-boot/u-boot-net.git Thanks! -Joe ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
