[U-Boot] [PATCH] arm64: versal: Remove SPL_DM_SEQ_ALIAS for platforms which have no SPL
It is defconfig synchronization caused by commit a074667d5203
("Kconfig: Varios: Fix more SPL, TPL dependencies").
These platforms are not enabling SPL that's why SPL symbols shouldn't be
the part of defconfig.
Signed-off-by: Michal Simek
---
configs/xilinx_versal_mini_emmc0_defconfig | 1 -
configs/xilinx_versal_mini_emmc1_defconfig | 1 -
configs/xilinx_versal_virt_defconfig | 1 -
3 files changed, 3 deletions(-)
diff --git a/configs/xilinx_versal_mini_emmc0_defconfig
b/configs/xilinx_versal_mini_emmc0_defconfig
index 60c368c7661c..440035f53bbc 100644
--- a/configs/xilinx_versal_mini_emmc0_defconfig
+++ b/configs/xilinx_versal_mini_emmc0_defconfig
@@ -47,7 +47,6 @@ CONFIG_DEFAULT_DEVICE_TREE="versal-mini-emmc0"
# CONFIG_NET is not set
# CONFIG_DM_WARN is not set
# CONFIG_DM_DEVICE_REMOVE is not set
-CONFIG_SPL_DM_SEQ_ALIAS=y
CONFIG_MMC_SDHCI=y
CONFIG_MMC_SDHCI_ZYNQ=y
# CONFIG_EFI_LOADER is not set
diff --git a/configs/xilinx_versal_mini_emmc1_defconfig
b/configs/xilinx_versal_mini_emmc1_defconfig
index cbbf75fe42aa..07ec6ebd664b 100644
--- a/configs/xilinx_versal_mini_emmc1_defconfig
+++ b/configs/xilinx_versal_mini_emmc1_defconfig
@@ -47,7 +47,6 @@ CONFIG_DEFAULT_DEVICE_TREE="versal-mini-emmc1"
# CONFIG_NET is not set
# CONFIG_DM_WARN is not set
# CONFIG_DM_DEVICE_REMOVE is not set
-CONFIG_SPL_DM_SEQ_ALIAS=y
CONFIG_MMC_SDHCI=y
CONFIG_MMC_SDHCI_ZYNQ=y
# CONFIG_EFI_LOADER is not set
diff --git a/configs/xilinx_versal_virt_defconfig
b/configs/xilinx_versal_virt_defconfig
index 3ce6c031ad88..3b07545ac4af 100644
--- a/configs/xilinx_versal_virt_defconfig
+++ b/configs/xilinx_versal_virt_defconfig
@@ -44,7 +44,6 @@ CONFIG_OF_BOARD=y
CONFIG_NET_RANDOM_ETHADDR=y
CONFIG_IP_DEFRAG=y
CONFIG_TFTP_BLOCKSIZE=4096
-CONFIG_SPL_DM_SEQ_ALIAS=y
CONFIG_DM_GPIO=y
CONFIG_DM_I2C=y
CONFIG_SYS_I2C_CADENCE=y
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] arm64: zynqmp: Define default SPL_TEXT_BASE address in Kconfig
Define default address via Kconfig. There is no need to change this address
for most of the boards but it is also possible. This one line save a lot of
lines in defconfigs that's why make sense to do it.
The similar change has been done by commit 9340d8fe8beb
("sunxi: move CONFIG_SPL_TEXT_BASE from *_defconfig to Kconfig")
Signed-off-by: Michal Simek
---
common/spl/Kconfig | 1 +
configs/avnet_ultra96_rev1_defconfig | 1 -
configs/avnet_ultrazedev_cc_v1_0_ultrazedev_som_v1_0_defconfig | 1 -
configs/xilinx_zynqmp_mini_emmc0_defconfig | 1 -
configs/xilinx_zynqmp_mini_emmc1_defconfig | 1 -
configs/xilinx_zynqmp_mini_qspi_defconfig | 1 -
configs/xilinx_zynqmp_zc1232_revA_defconfig| 1 -
configs/xilinx_zynqmp_zc1254_revA_defconfig| 1 -
configs/xilinx_zynqmp_zc1751_xm015_dc1_defconfig | 1 -
configs/xilinx_zynqmp_zc1751_xm016_dc2_defconfig | 1 -
configs/xilinx_zynqmp_zc1751_xm017_dc3_defconfig | 1 -
configs/xilinx_zynqmp_zc1751_xm018_dc4_defconfig | 1 -
configs/xilinx_zynqmp_zc1751_xm019_dc5_defconfig | 1 -
configs/xilinx_zynqmp_zcu100_revC_defconfig| 1 -
configs/xilinx_zynqmp_zcu102_rev1_0_defconfig | 1 -
configs/xilinx_zynqmp_zcu102_revA_defconfig| 1 -
configs/xilinx_zynqmp_zcu102_revB_defconfig| 1 -
configs/xilinx_zynqmp_zcu104_revA_defconfig| 1 -
configs/xilinx_zynqmp_zcu104_revC_defconfig| 1 -
configs/xilinx_zynqmp_zcu106_revA_defconfig| 1 -
configs/xilinx_zynqmp_zcu111_revA_defconfig| 1 -
configs/xilinx_zynqmp_zcu1275_revA_defconfig | 1 -
configs/xilinx_zynqmp_zcu1275_revB_defconfig | 1 -
23 files changed, 1 insertion(+), 22 deletions(-)
diff --git a/common/spl/Kconfig b/common/spl/Kconfig
index f467eca2be72..59a7b200891f 100644
--- a/common/spl/Kconfig
+++ b/common/spl/Kconfig
@@ -138,6 +138,7 @@ config SPL_TEXT_BASE
default 0x10060 if MACH_SUN50I || MACH_SUN50I_H5 || MACH_SUN9I
default 0x20060 if MACH_SUN50I_H6
default 0x00060 if ARCH_SUNXI
+ default 0xfffc if ARCH_ZYNQMP
default 0x0
help
The address in memory that SPL will be running from.
diff --git a/configs/avnet_ultra96_rev1_defconfig
b/configs/avnet_ultra96_rev1_defconfig
index b504332ff006..924153081149 100644
--- a/configs/avnet_ultra96_rev1_defconfig
+++ b/configs/avnet_ultra96_rev1_defconfig
@@ -13,7 +13,6 @@ CONFIG_FIT=y
CONFIG_FIT_VERBOSE=y
CONFIG_SPL_LOAD_FIT=y
# CONFIG_DISPLAY_CPUINFO is not set
-CONFIG_SPL_TEXT_BASE=0xfffc
CONFIG_SPL_OS_BOOT=y
CONFIG_SPL_RAM_SUPPORT=y
CONFIG_SPL_RAM_DEVICE=y
diff --git a/configs/avnet_ultrazedev_cc_v1_0_ultrazedev_som_v1_0_defconfig
b/configs/avnet_ultrazedev_cc_v1_0_ultrazedev_som_v1_0_defconfig
index b326231b6829..f463318565ff 100644
--- a/configs/avnet_ultrazedev_cc_v1_0_ultrazedev_som_v1_0_defconfig
+++ b/configs/avnet_ultrazedev_cc_v1_0_ultrazedev_som_v1_0_defconfig
@@ -15,7 +15,6 @@ CONFIG_FIT_VERBOSE=y
CONFIG_SPL_LOAD_FIT=y
CONFIG_BOOTDELAY=0
# CONFIG_DISPLAY_CPUINFO is not set
-CONFIG_SPL_TEXT_BASE=0xfffc
CONFIG_SPL_OS_BOOT=y
CONFIG_SYS_PROMPT="ZynqMP> "
CONFIG_CMD_MEMTEST=y
diff --git a/configs/xilinx_zynqmp_mini_emmc0_defconfig
b/configs/xilinx_zynqmp_mini_emmc0_defconfig
index 0faa3326132d..b4162abdd715 100644
--- a/configs/xilinx_zynqmp_mini_emmc0_defconfig
+++ b/configs/xilinx_zynqmp_mini_emmc0_defconfig
@@ -12,7 +12,6 @@ CONFIG_SUPPORT_RAW_INITRD=y
# CONFIG_BOARD_LATE_INIT is not set
# CONFIG_DISPLAY_CPUINFO is not set
CONFIG_BOARD_EARLY_INIT_R=y
-CONFIG_SPL_TEXT_BASE=0xfffc
# CONFIG_CMDLINE_EDITING is not set
# CONFIG_AUTO_COMPLETE is not set
CONFIG_SYS_PROMPT="ZynqMP> "
diff --git a/configs/xilinx_zynqmp_mini_emmc1_defconfig
b/configs/xilinx_zynqmp_mini_emmc1_defconfig
index 867d2e5d9cee..76d5aa6c713b 100644
--- a/configs/xilinx_zynqmp_mini_emmc1_defconfig
+++ b/configs/xilinx_zynqmp_mini_emmc1_defconfig
@@ -12,7 +12,6 @@ CONFIG_SUPPORT_RAW_INITRD=y
# CONFIG_BOARD_LATE_INIT is not set
# CONFIG_DISPLAY_CPUINFO is not set
CONFIG_BOARD_EARLY_INIT_R=y
-CONFIG_SPL_TEXT_BASE=0xfffc
# CONFIG_CMDLINE_EDITING is not set
# CONFIG_AUTO_COMPLETE is not set
CONFIG_SYS_PROMPT="ZynqMP> "
diff --git a/configs/xilinx_zynqmp_mini_qspi_defconfig
b/configs/xilinx_zynqmp_mini_qspi_defconfig
index b0bc84d55eca..a20534a488ca 100644
--- a/configs/xilinx_zynqmp_mini_qspi_defconfig
+++ b/configs/xilinx_zynqmp_mini_qspi_defconfig
@@ -14,7 +14,6 @@ CONFIG_ZYNQMP_NO_DDR=y
# CONFIG_LEGACY_IMAGE_FORMAT is not set
# CONFIG_BOARD_LATE_INIT is not set
# CONFIG_DISPLAY_CPUINFO is not set
-CONFIG_SPL_TEXT_BASE=0xfffc
# CONFIG_CMDLINE_EDITING is not set
# CONFIG_AU
Re: [U-Boot] Add support for imxrt
Hi Giulio, On 10/09/19 20:32, Giulio Benetti wrote: > Hello everybody, > > I would like to port imxrt to u-boot and I would like to ask you: > - do you have the interest on upstreaming it? > if yes: > I've seen how they've dealt with 'stm32' and 'stm32mp' that is similar > to 'imxrt' and 'imx'. So should follow the same criterias for porting? I > mean adding the new folder 'mach-imxrt'? Agree - we should follow the same schema. Regards, Stefano > > Also, do I find some of you in IRC sometimes? > > Thanks in advance > Best regards -- = DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] efi_loader: device_path: support Sandbox's "host" devices
Heinrich,
Apologies for having not replied.
On Fri, Aug 23, 2019 at 08:09:45PM +0200, Heinrich Schuchardt wrote:
> On 8/23/19 1:34 AM, AKASHI Takahiro wrote:
> >On Thu, Aug 22, 2019 at 08:19:24PM +0200, Heinrich Schuchardt wrote:
> >>On 8/22/19 10:54 AM, AKASHI Takahiro wrote:
> >>>Sandbox's "host" devices are currently described as UCLASS_ROOT udevice
> >>>with DEV_IF_HOST block device. As the current implementation of
> >>>efi_device_path doesn't support such a type, any "host" device
> >>>on sandbox cannot be seen as a distinct object.
> >>>
> >>>For example,
> >>> => host bind 0 /foo/disk.img
> >>>
> >>> => efi devices
> >>> Scanning disk host0...
> >>> Found 1 disks
> >>> Device Device Path
> >>>
> >>> 15c19970 /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)
> >>> 15c19d70 /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)
> >>>
> >>> => efi dh
> >>> Handle Protocols
> >>>
> >>> 15c19970 Device Path, Device Path To Text, Device Path
> >>> Utilities, Unicode Collation 2, HII String, HII Database, HII Config
> >>> Routing
> >>> 15c19ba0 Driver Binding
> >>> 15c19c10 Simple Text Output
> >>> 15c19c80 Simple Text Input, Simple Text Input Ex
> >>> 15c19d70 Block IO, Device Path, Simple File System
> >>>
> >>>As you can see here, efi_root (0x15c19970) and host0 device
> >>>(0x15c19d70) has the same representation of device path.
> >>>
> >>>This is not only inconvenient, but also confusing since two different
> >>>efi objects are associated with the same device path and
> >>>efi_dp_find_obj() will possibly return a wrong result.
> >>>
> >>>Solution:
> >>>Each "host" device should be given an additional device path node
> >>>of Logical Unit Number(LUN) to make it distinguishable. The result
> >>>would be:
> >>> Device Device Path
> >>>
> >>> 15c19970 /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)
> >>> 15c19d70 /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/LUN(0)
> >>>
> >>>Signed-off-by: AKASHI Takahiro
> >>>---
> >>> lib/efi_loader/efi_device_path.c | 22 ++
> >>> 1 file changed, 22 insertions(+)
> >>>
> >>>diff --git a/lib/efi_loader/efi_device_path.c
> >>>b/lib/efi_loader/efi_device_path.c
> >>>index eeeb80683607..565bb6888fe1 100644
> >>>--- a/lib/efi_loader/efi_device_path.c
> >>>+++ b/lib/efi_loader/efi_device_path.c
> >>>@@ -12,6 +12,7 @@
> >>> #include
> >>> #include
> >>> #include
> >>>+#include
> >>> #include
> >>>
> >>> /* template END node: */
> >>>@@ -422,6 +423,10 @@ static unsigned dp_size(struct udevice *dev)
> >>>
> >>> switch (dev->driver->id) {
> >>> case UCLASS_ROOT:
> >>>+#ifdef CONFIG_SANDBOX
> >>>+ /* stop traversing parents at this point: */
> >>>+ return sizeof(ROOT) + sizeof(struct efi_device_path_lun);
> >>>+#endif
> >>> case UCLASS_SIMPLE_BUS:
> >>> /* stop traversing parents at this point: */
> >>> return sizeof(ROOT);
> >>>@@ -505,6 +510,23 @@ static void *dp_fill(void *buf, struct udevice *dev)
> >>> #ifdef CONFIG_BLK
> >>> case UCLASS_BLK:
> >>> switch (dev->parent->uclass->uc_drv->id) {
> >>>+#ifdef CONFIG_SANDBOX
> >>>+ case UCLASS_ROOT: {
> >>>+ /* stop traversing parents at this point: */
> >>>+ struct efi_device_path_vendor *vdp = buf;
> >>>+ struct efi_device_path_lun *dp;
> >>>+ struct host_block_dev *host_dev = dev_get_platdata(dev);
> >>>+ struct blk_desc *desc = dev_get_uclass_platdata(dev);
> >>>+
> >>>+ *vdp++ = ROOT;
> >>>+ dp = (struct efi_device_path_lun *)vdp;
> >>>+ dp->dp.type = DEVICE_PATH_TYPE_MESSAGING_DEVICE;
> >>>+ dp->dp.sub_type = DEVICE_PATH_SUB_TYPE_MSG_LUN;
> >>>+ dp->dp.length = sizeof(*dp);
> >>>+ dp->logical_unit_number = desc->devnum;
> >>>+ return ++dp;
> >>>+ }
> >>>+#endif
> >>> #ifdef CONFIG_IDE
> >>> case UCLASS_IDE: {
> >>> struct efi_device_path_atapi *dp =
> >>>
> >>
> >>Hello Takahiro,
> >>
> >>thank you for pointing out that currently we generate the same device
> >>path twice. This for sure is something we need to fix.
> >>
> >>In the table below you will find the device tree for
> >>
> >>./u-boot -d arch/sandbox/dts/test.dtb
> >>
> >>In the device tree I see exactly one root node. I see no device called
> >>host0.
> >
> >"Host0" or whatever other host device is a pseudo device which will
> >be dynamically created, like other hot-pluggable devices, by "host bind"
> >command on sandbox U-Boot. So it won't appear in device tree.
> >
> >-Takahiro Akashi
>
> Thank you for the explanation.
>
> The host device is shown in the device tree
Re: [U-Boot] [PATCH] clk: sifive: Fix ethernet regression on HiFive Unleashed
On Wed, Sep 11, 2019 at 7:28 AM Bin Meng wrote: > > Hi Marcus, > > On Tue, Sep 10, 2019 at 11:53 PM Marcus Comstedt wrote: > > > > > > Hi Bin, > > > > Bin Meng writes: > > > > > So 4.14 definitely was an out-of-tree kernel > > > > Everything before 5.2 was out-of-tree. > > > > > > > No one can guarantee an out-of-tree implementation will be > > > keeping compatible after it's accepted in-tree. > > > > Reviewers/maintainers can guarantee compatibility with existing > > hardware and DT by not instisting on breaking changes. > > > > It's not really about keeping in-tree and out-of-tree compatible with > > each other, but about keeping both of them compatible with the actual > > hardware and DT of the system the OS is supposed to run on. > > > > Per my understanding kernel reviewers/maintainers want to have a clean > implementation from the start. That's why it's being done this way. > > > > > > Reviewers/maintainers > > > may have different view from the author on what's the best > > > > A reviewer/maintainer could for example have the view that a certain > > register in a piece of hardware should really be two registers with > > the bits divided between them based on some logical partitioning. And > > they might be right. But the hardware is what it is, and if they > > insist that the driver access two different registers the driver will > > not work the hardware. You'll have a nice driver that works on > > nothing (at least until the vendor makes a new spin of the hardware > > with the two registers). > > The original hardware vendor's DT may be written in a way that > violates the DT specs. Hence I believe it's really hard to keep the > comparability for both. > > For this specific FU540 ethernet, what you did in this patch does not > completely bring back the compatibility. Things were changed a lot in > the upstream kernel. > > For example, the U-Boot GEM GXL-MGMT driver was needed to work with SiFive's > DT > https://lists.denx.de/pipermail/u-boot/2019-May/369577.html > > But later, it was dropped due to kernel mainline DT > reviewers/maintainers thought it was a misuse of clock node and the > GXL-MGMT module should be part of the GEM spec. > https://lists.denx.de/pipermail/u-boot/2019-June/373306.html > > > > > My opinion is that the DT should be treated the same way. It is part > > of the hardware (sort of the "metadata" for the hardware). Sure you > > can have some idea of how things could be expressed better and add > > support for that, but you need to also keep compat with the actual > > hardware platform that the driver is there to interface against, > > otherwise the driver won't work. > > > > While I agree with you to some extent that, that's now how things are > done with current kernel practice. Sorry for the slow response... The DT bindings for most of the Linux drivers accepted upstream have changed in a backward in-compatible way for SiFive Unleashed. The Linux clock driver implementation also changed quite a bit. Most of the recent U-Boot changes for SiFive Unleashed were to sync-up DT bindings followed by U-Boot drivers with SiFive Unleashed drivers accepted in Linux. The built-in DTB passed by FSBL to OpenSBI + U-Boot is totally out-of-date. Going forward SiFive folks will use upstreamed Linux DT bindings for newer platforms so it made sense to update U-Boot drivers. The root of the problem is delay in freezing DT bindings by SOC vendors. I think the SOC vendors should get DT bindings reviewed very early before sending patches to Linux or U-Boot. The Linux kernel is still a central place for all DT bindings documentation across architectures. May be things would be different if DT bindings documentation was maintained as separate project ??? For now, we can insist SOC vendors to get DT bindings reviewed/froozen in LKML before sending U-Boot driver patches. Suggestions ?? Regards, Anup > > Regards, > Bin > ___ > 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] efi_loader: disk: install file system protocol to a whole disk
Heinrich,
On Fri, Aug 23, 2019 at 09:04:21AM +0900, AKASHI Takahiro wrote:
> On Thu, Aug 22, 2019 at 12:52:41PM +0200, Heinrich Schuchardt wrote:
> > On 8/22/19 11:11 AM, Mark Kettenis wrote:
> > >>From: AKASHI Takahiro
> > >>Date: Thu, 22 Aug 2019 17:06:25 +0900
> > >>
> > >>Currently, a whole disk without any partitions is not associated
> > >>with EFI_SIMPLE_FILE_SYSTEM_PROTOCOL. So even if it houses FAT
> > >>file system, there is a chance that we may not be able to access
> > >>it, particularly, when accesses are to be attempted after searching
> > >>that protocol against a device handle.
> > >>
> > >>With this patch, EFI_SIMPLE_FILE_SYSTEM_PROTOCOL is installed
> > >>to such a disk if part_get_info() shows there is not partition
> > >>table installed on it.
> > >
> > >Do other UEFI implementations support this?
> >
> > What use cases exist that come without partition table?
>
> I didn't find any *explicit* description in UEFI specification
> that mandates that any block device should have a partition table.
> It may be mandatory for boot(able) disks, but for others?
>
> > You can create an MBR with partition table that is a valid start of a
> > file system.
>
> Obviously we can do that, but if this is not a mandatory requirement,
> we'd better support no-partitioned cases.
Any further comments?
-Takahiro Akashi
>
> > So you should first check if a partition table exists. Only if none
> > exists you can test for a possible file system.
>
> I don't get your point. Are you saying that we should support a file system
> for a disk only if it has a file system?
> This is not true even for existing partitions as FILE_SYSTEM PROTOCOL
> is always installed to every partition whether or not it really
> houses a file system under the current implementation.
>
> Thanks,
> -Takahiro Akashi
>
>
> > Best regards
> >
> > Heinrich
> >
> > >
> > >>Signed-off-by: AKASHI Takahiro
> > >>---
> > >> lib/efi_loader/efi_disk.c | 4 +++-
> > >> 1 file changed, 3 insertions(+), 1 deletion(-)
> > >>
> > >>diff --git a/lib/efi_loader/efi_disk.c b/lib/efi_loader/efi_disk.c
> > >>index 7a6b06821a47..548fe667e6f8 100644
> > >>--- a/lib/efi_loader/efi_disk.c
> > >>+++ b/lib/efi_loader/efi_disk.c
> > >>@@ -239,6 +239,7 @@ static efi_status_t efi_disk_add_dev(
> > >> struct efi_disk_obj **disk)
> > >> {
> > >> struct efi_disk_obj *diskobj;
> > >>+ disk_partition_t info;
> > >> efi_status_t ret;
> > >>
> > >> /* Don't add empty devices */
> > >>@@ -270,7 +271,8 @@ static efi_status_t efi_disk_add_dev(
> > >> diskobj->dp);
> > >> if (ret != EFI_SUCCESS)
> > >> return ret;
> > >>- if (part >= 1) {
> > >>+ /* partitions or whole disk without partitions */
> > >>+ if (part >= 1 || part_get_info(desc, part, &info)) {
> > >> diskobj->volume = efi_simple_file_system(desc, part,
> > >> diskobj->dp);
> > >> ret = efi_add_protocol(&diskobj->header,
> > >>--
> > >>2.21.0
> > >>
> > >>___
> > >>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] efi_loader: LoadOptions (bootargs)
Heinrich, On Fri, Aug 23, 2019 at 08:42:27AM +0900, AKASHI Takahiro wrote: > On Thu, Aug 22, 2019 at 07:53:46PM +0200, Heinrich Schuchardt wrote: > > On 8/22/19 11:03 AM, AKASHI Takahiro wrote: > > >Heinrich, > > > > > >I'm now wondering whether LoadedImage's LoadOptions, which comes > > >from "bootargs" variable, should contain a command(application) name > > >as a first argument or not. > > > > > >When I tried some efi application (efitools), I found that it expected > > >so. For example, efitools' UpdateVars.efi takes > > > Usage: UpdateVars.efi: [-g guid] [-a] [-e] [-b] var file > > > > > >and I had to passed arguments by specifying "foo db DB.auth" for > > >"bootargs" where foo makes no sense. > > > > > >What do you think about this issue? > > > > Do you relate to > > https://git.kernel.org/pub/scm/linux/kernel/git/jejb/efitools.git? > > Yes. > > > This style of parsing LoadOptions is defined by the EFI shell. See > > function ParseCommandLineToArgs() in > > ShellPkg/Application/Shell/ShellParametersProtocol.c. > > So do you mean that Shell.efi is responsible for adding a command name > to LoadOptions (or bootargs) as a first parameter or that LoadOptions > is solely for Shell environment? > > If so, should we do the same thing at bootefi? Any comment? -Takahiro Akashi > > If UpdateVars.efi would work differently it could not be launched via > > the shell. > > Well, I'm trying to run UpdateVars.efi in a standalone way > by invoking it directly from bootefi/bootmgr and it obviously fails > due to this issue. > > Thanks, > -Takashiro Akashi > > > > Best regards > > > > Heinrich ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 0/3] Support distro boot in pico-imx7d BL33 case
> -Original Message- > From: Jun Nie > Sent: 2019年9月9日 21:47 > To: Peng Fan > Cc: Stefano Babic ; Fabio Estevam ; > Otavio Salvador ; Vanessa Maegima > ; Bryan O'Donoghue > ; U-Boot Mailing List > Subject: Re: [PATCH 0/3] Support distro boot in pico-imx7d BL33 case > > Peng Fan 于2019年9月3日周二 上午9:39写道： > > > > Hi Jun, > > > > > Subject: Re: [PATCH 0/3] Support distro boot in pico-imx7d BL33 case > > > > > > Jun Nie 于2019年8月8日周四 下午12:04写道： > > > > > > > > Jun Nie 于2019年7月16日周二 下午3:43写 > 道： > > > > > > > > > > Support distro boot in pico-imx7d BL33 case with changing the > > > > > enviroment variables. While the other two patches are for > > > > > polishing clock code and for feature enablement. > > > > > > > > > > Jun Nie (3): > > > > > pico-imx7d: add config to enable CAAM > > > > > pico-imx7d: Support distro boot for FIT image case > > > > > pico-imx7d: polish uart clock id definition > > > > > > > > > > arch/arm/include/asm/arch-mx7/clock.h | 18 + > > > > > configs/pico-imx7d_bl33_defconfig | 1 + > > > > > include/configs/pico-imx7d.h | 37 > > > +++ > > > > > 3 files changed, 13 insertions(+), 43 deletions(-) > > > > > > > > > > -- > > > > > > > > Hi Vanessa, > > > > > > > > Do you have any comments on these 3 patches? Or we can merge it > now? > > > Thanks! > > > > > > > > Best Regards > > > > Jun > > > > > > Hi, > > > > > > Does anyone has comments on these patches? Maybe we can merge them > > > as no comments for a long time. Thanks! > > > > I could merge this patchset into nxp-imx and send pull request to > > Stefano, if you are fine with that. > > > > Regards, > > Peng. > > Peng, > > It is appreciated to help on this. Any comments from Stefan? Thanks! CI build failed: https://travis-ci.org/MrVan/u-boot/jobs/583445551 I need drop your patchset. Thanks, Peng. > > Regards, > Jun > > > > > > > > Regards, > > > Jun ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [EXT] Re: [PATCH 1/6] spi: fsl_qspi: Fix DDR mode setting for latest iMX platforms
Hi Ashish, Hi Frieder, On 09.09.19 10:10, Schrempf Frieder wrote: Hi Ashish, On 27.08.19 11:56, Ashish Kumar wrote: -Original Message- From: Schrempf Frieder Sent: Wednesday, August 14, 2019 5:41 PM To: Ashish Kumar ; Ye Li ; ja...@amarulasolutions.com Cc: Fabio Estevam ; u-boot@lists.denx.de; dl- uboot-imx Subject: Re: [EXT] Re: [U-Boot] [PATCH 1/6] spi: fsl_qspi: Fix DDR mode setting for latest iMX platforms Caution: EXT Email Sorry, I hit the "Send" button too early ;) On 14.08.19 14:07, Frieder Schrempf wrote: Hi Ashish, On 14.08.19 14:02, Ashish Kumar wrote: -Original Message- From: U-Boot On Behalf Of Schrempf Frieder Sent: Wednesday, August 14, 2019 5:07 PM To: Ye Li ; ja...@amarulasolutions.com Cc: Fabio Estevam ; u-boot@lists.denx.de; dl- uboot-imx Subject: [EXT] Re: [U-Boot] [PATCH 1/6] spi: fsl_qspi: Fix DDR mode setting for latest iMX platforms Caution: EXT Email Hi Ye, On 14.08.19 12:08, Ye Li wrote: On latest iMX platforms like iMX7D/iMX6UL/iMX8MQ, the QSPI controller is updated to have TDH field in FLSHCR register. According to reference manual, this TDH must be set to 1 when DDR_EN is set. Otherwise, the TX DDR delay logic won't be enabled. This is actually an issue I have experienced myself. But in our case this behavior only happened on i.MX6ULL not on i.MX6UL. Either the QSPI controller hardware or the BootROM code changed when moving from UL to ULL. For details see: [1]. Another issue in DDR mode is the MCR register will be overwritten in every read/write/erase operation. This causes DDR_EN been cleared while TDH=1, then no clk2x output for TX data shift and all operations will fail. The best way to fix all of these things (also the ones in the other patches) would be to fix them in Linux and port the driver from Linux to U- Boot. Actually I've already done most of the porting [2], Hello Frieder, I had tested your porting and it was not functional on u-boot. I found that only erase, read up to TX/RX buf size is working or something like that. Also ip and AHB mode cannot be used at time in code. Previously only IP mode was used in u-boot, Since endianness across different QSPI-IP(ls1012, ls1043, ls1021 big endian), (ls1088,ls2088 little endian) is not consistent on various silicon's. I am not sure if Yogesh who worked with you on Linux porting gave you this information about endianness inconsistency. Ok, thanks for your feedback. The endianness for the different SoCs can be handled by the device data. Does this work correctly in Linux, or does the Linux driver need fixes? Please suggest way forward. How to correct this issue? The first thigh would be to make sure the Linux driver works for all platforms and then do the porting to U-Boot. I will be out of office for 10 days. After that I can try to work on this, but I need support and testing for other platforms. I only have i.MX6UL/ULL. Hi Frieder, I have found some break though after porting to 2019.10 and few modification in driver code, I will update in a weeks' time. Please do not invest time on this. If I need some help I will update. Thanks for your work. Do you already have some news? Can you share your results? I'm most likely currently running in similar issues on tests with the i.MX6ULL EVK. QSPI does not work reliably. So before digging deeper into the QSPI driver, I wanted to check on the status of any updates in the driver. Is there anything available that I could use for testing already? Thanks, Stefan ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [v3, 3/4] mmc: fsl_esdhc: rename fsl_esdhc_init to fsl_esdhc_get_cfg
For non-DM code, below functions had similar names.
- fsl_esdhc_initialize
- fsl_esdhc_mmc_init
- fsl_esdhc_init
However fsl_esdhc_init was mainly used to get cfg. So rename it
to fsl_esdhc_get_cfg. Fix up bus-width capability handling, and
drop controller initialization because it will be re-initialized
in later esdhc_init_common for DM or esdhc_init for non-DM when use
it.
Signed-off-by: Yangbo Lu
---
Changes for v2:
- Rebased.
Changes for v3:
- None.
---
drivers/mmc/fsl_esdhc.c | 68 -
1 file changed, 11 insertions(+), 57 deletions(-)
diff --git a/drivers/mmc/fsl_esdhc.c b/drivers/mmc/fsl_esdhc.c
index 3b079f1..03a7e89 100644
--- a/drivers/mmc/fsl_esdhc.c
+++ b/drivers/mmc/fsl_esdhc.c
@@ -25,14 +25,6 @@
DECLARE_GLOBAL_DATA_PTR;
-#define ESDHC_IRQ_EN_BITS (IRQSTATEN_CC | IRQSTATEN_TC | \
- IRQSTATEN_DINT | IRQSTATEN_BWR | \
- IRQSTATEN_BRR | IRQSTATEN_CINT | \
- IRQSTATEN_CTOE | IRQSTATEN_CCE | \
- IRQSTATEN_CEBE | IRQSTATEN_CIE | \
- IRQSTATEN_DTOE | IRQSTATEN_DCE | \
- IRQSTATEN_DEBE)
-
struct fsl_esdhc {
uintdsaddr; /* SDMA system address register */
uintblkattr;/* Block attributes register */
@@ -651,57 +643,25 @@ static int esdhc_getcd_common(struct fsl_esdhc_priv *priv)
return timeout > 0;
}
-static int esdhc_reset(struct fsl_esdhc *regs)
-{
- ulong start;
-
- /* reset the controller */
- esdhc_setbits32(®s->sysctl, SYSCTL_RSTA);
-
- /* hardware clears the bit when it is done */
- start = get_timer(0);
- while ((esdhc_read32(®s->sysctl) & SYSCTL_RSTA)) {
- if (get_timer(start) > 100) {
- printf("MMC/SD: Reset never completed.\n");
- return -ETIMEDOUT;
- }
- }
-
- return 0;
-}
-
#if !CONFIG_IS_ENABLED(DM_MMC)
static const struct mmc_ops esdhc_ops;
#endif
-static int fsl_esdhc_init(struct fsl_esdhc_priv *priv,
- struct fsl_esdhc_plat *plat)
+static int fsl_esdhc_get_cfg(struct fsl_esdhc_priv *priv,
+struct fsl_esdhc_plat *plat)
{
+ struct fsl_esdhc *regs = priv->esdhc_regs;
+ u32 caps, voltage_caps = 0;
struct mmc_config *cfg;
- struct fsl_esdhc *regs;
- u32 caps, voltage_caps;
- int ret;
if (!priv)
return -EINVAL;
- regs = priv->esdhc_regs;
-
- /* First reset the eSDHC controller */
- ret = esdhc_reset(regs);
- if (ret)
- return ret;
-
- esdhc_setbits32(®s->sysctl, SYSCTL_PEREN | SYSCTL_HCKEN |
- SYSCTL_IPGEN | SYSCTL_CKEN);
-
- writel(ESDHC_IRQ_EN_BITS, ®s->irqstaten);
cfg = &plat->cfg;
#ifndef CONFIG_DM_MMC
memset(cfg, '\0', sizeof(*cfg));
#endif
- voltage_caps = 0;
caps = esdhc_read32(®s->hostcapblt);
#ifdef CONFIG_SYS_FSL_ERRATUM_ESDHC135
@@ -739,18 +699,10 @@ static int fsl_esdhc_init(struct fsl_esdhc_priv *priv,
else if (priv->bus_width == 4)
cfg->host_caps = MMC_MODE_4BIT;
- cfg->host_caps = MMC_MODE_4BIT | MMC_MODE_8BIT;
#ifdef CONFIG_SYS_FSL_ESDHC_HAS_DDR_MODE
cfg->host_caps |= MMC_MODE_DDR_52MHz;
#endif
- if (priv->bus_width > 0) {
- if (priv->bus_width < 8)
- cfg->host_caps &= ~MMC_MODE_8BIT;
- if (priv->bus_width < 4)
- cfg->host_caps &= ~MMC_MODE_4BIT;
- }
-
if (caps & HOSTCAPBLT2_HSS)
cfg->host_caps |= MMC_MODE_HS_52MHz | MMC_MODE_HS;
@@ -761,7 +713,6 @@ static int fsl_esdhc_init(struct fsl_esdhc_priv *priv,
cfg->f_min = 40;
cfg->f_max = min(priv->sdhc_clk, (u32)2);
-
cfg->b_max = CONFIG_SYS_MMC_MAX_BLK_COUNT;
return 0;
@@ -884,7 +835,10 @@ static int fsl_esdhc_cfg_to_priv(struct fsl_esdhc_cfg *cfg,
return -EINVAL;
priv->esdhc_regs = (struct fsl_esdhc *)(unsigned long)(cfg->esdhc_base);
- priv->bus_width = cfg->max_bus_width;
+ if (cfg->max_bus_width)
+ priv->bus_width = cfg->max_bus_width;
+ else
+ priv->bus_width = 4;
priv->sdhc_clk = cfg->sdhc_clk;
priv->wp_enable = cfg->wp_enable;
@@ -919,7 +873,7 @@ int fsl_esdhc_initialize(bd_t *bis, struct fsl_esdhc_cfg
*cfg)
return ret;
}
- ret = fsl_esdhc_init(priv, plat);
+ ret = fsl_esdhc_get_cfg(priv, plat);
if (ret) {
debug("%s init failure\n", __func__);
free(plat);
@@ -1014,9 +968,9 @@ static int fsl_esdhc_probe(struct udevice *dev)
}
}
- ret = fsl_esdhc_init(priv, plat);
+
[U-Boot] [v3, 4/4] mmc: fsl_esdhc: drop i.MX DDR mode code
A previous patch below adding DDR mode support was actually for i.MX platforms. Now i.MX eSDHC driver is fsl_esdhc_imx.c. For QorIQ eSDHC, it uses different process for DDR mode. Let's drop DDR support code for i.MX in fsl_esdhc driver. 0e1bf61 mmc: fsl_esdhc: Add support for DDR mode Signed-off-by: Yangbo Lu --- Changes for v3: - Added this patch. --- drivers/mmc/fsl_esdhc.c | 9 ++--- 1 file changed, 2 insertions(+), 7 deletions(-) diff --git a/drivers/mmc/fsl_esdhc.c b/drivers/mmc/fsl_esdhc.c index 03a7e89..322046b 100644 --- a/drivers/mmc/fsl_esdhc.c +++ b/drivers/mmc/fsl_esdhc.c @@ -504,17 +504,16 @@ static void esdhc_set_clock(struct fsl_esdhc_priv *priv, struct mmc *mmc, struct fsl_esdhc *regs = priv->esdhc_regs; int div = 1; int pre_div = 2; - int ddr_pre_div = mmc->ddr_mode ? 2 : 1; int sdhc_clk = priv->sdhc_clk; uint clk; if (clock < mmc->cfg->f_min) clock = mmc->cfg->f_min; - while (sdhc_clk / (16 * pre_div * ddr_pre_div) > clock && pre_div < 256) + while (sdhc_clk / (16 * pre_div) > clock && pre_div < 256) pre_div *= 2; - while (sdhc_clk / (div * pre_div * ddr_pre_div) > clock && div < 16) + while (sdhc_clk / (div * pre_div) > clock && div < 16) div++; pre_div >>= 1; @@ -699,10 +698,6 @@ static int fsl_esdhc_get_cfg(struct fsl_esdhc_priv *priv, else if (priv->bus_width == 4) cfg->host_caps = MMC_MODE_4BIT; -#ifdef CONFIG_SYS_FSL_ESDHC_HAS_DDR_MODE - cfg->host_caps |= MMC_MODE_DDR_52MHz; -#endif - if (caps & HOSTCAPBLT2_HSS) cfg->host_caps |= MMC_MODE_HS_52MHz | MMC_MODE_HS; -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [v3, 2/4] mmc: fsl_esdhc: clean up code
This patch is just to clean up code. There were not changes on function.
Signed-off-by: Yangbo Lu
---
Changes for v2:
- Involved esdhc_ops in non-DM conditional build.
Changes for v3:
- None.
---
drivers/mmc/fsl_esdhc.c | 286
include/fsl_esdhc.h | 203 --
2 files changed, 238 insertions(+), 251 deletions(-)
diff --git a/drivers/mmc/fsl_esdhc.c b/drivers/mmc/fsl_esdhc.c
index ff5565c..3b079f1 100644
--- a/drivers/mmc/fsl_esdhc.c
+++ b/drivers/mmc/fsl_esdhc.c
@@ -25,12 +25,13 @@
DECLARE_GLOBAL_DATA_PTR;
-#define SDHCI_IRQ_EN_BITS (IRQSTATEN_CC | IRQSTATEN_TC | \
- IRQSTATEN_CINT | \
- IRQSTATEN_CTOE | IRQSTATEN_CCE | IRQSTATEN_CEBE
| \
- IRQSTATEN_CIE | IRQSTATEN_DTOE | IRQSTATEN_DCE
| \
- IRQSTATEN_DEBE | IRQSTATEN_BRR | IRQSTATEN_BWR
| \
- IRQSTATEN_DINT)
+#define ESDHC_IRQ_EN_BITS (IRQSTATEN_CC | IRQSTATEN_TC | \
+ IRQSTATEN_DINT | IRQSTATEN_BWR | \
+ IRQSTATEN_BRR | IRQSTATEN_CINT | \
+ IRQSTATEN_CTOE | IRQSTATEN_CCE | \
+ IRQSTATEN_CEBE | IRQSTATEN_CIE | \
+ IRQSTATEN_DTOE | IRQSTATEN_DCE | \
+ IRQSTATEN_DEBE)
struct fsl_esdhc {
uintdsaddr; /* SDMA system address register */
@@ -76,16 +77,15 @@ struct fsl_esdhc_plat {
* struct fsl_esdhc_priv
*
* @esdhc_regs: registers of the sdhc controller
- * @sdhc_clk: Current clk of the sdhc controller
+ * @sdhc_clk: reference clk of the sdhc controller
+ * @per_clk: peripheral clock
+ * @clock: target clock
* @bus_width: bus width, 1bit, 4bit or 8bit
- * @cfg: mmc config
* @mmc: mmc
* Following is used when Driver Model is enabled for MMC
* @dev: pointer for the device
* @non_removable: 0: removable; 1: non-removable
* @wp_enable: 1: enable checking wp; 0: no check
- * @cd_gpio: gpio for card detection
- * @wp_gpio: gpio for write protection
*/
struct fsl_esdhc_priv {
struct fsl_esdhc *esdhc_regs;
@@ -102,7 +102,7 @@ struct fsl_esdhc_priv {
};
/* Return the XFERTYP flags for a given command and data packet */
-static uint esdhc_xfertyp(struct mmc_cmd *cmd, struct mmc_data *data)
+static uint esdhc_setup_xfertyp(struct mmc_cmd *cmd, struct mmc_data *data)
{
uint xfertyp = 0;
@@ -310,9 +310,9 @@ static int esdhc_setup_data(struct fsl_esdhc_priv *priv,
struct mmc *mmc,
return 0;
}
-static void check_and_invalidate_dcache_range
- (struct mmc_cmd *cmd,
-struct mmc_data *data) {
+static void esdhc_invalidate_dcache_range(struct mmc_cmd *cmd,
+ struct mmc_data *data)
+{
unsigned start = 0;
unsigned end = 0;
unsigned size = roundup(ARCH_DMA_MINALIGN,
@@ -377,11 +377,11 @@ static int esdhc_send_cmd_common(struct fsl_esdhc_priv
*priv, struct mmc *mmc,
return err;
if (data->flags & MMC_DATA_READ)
- check_and_invalidate_dcache_range(cmd, data);
+ esdhc_invalidate_dcache_range(cmd, data);
}
/* Figure out the transfer arguments */
- xfertyp = esdhc_xfertyp(cmd, data);
+ xfertyp = esdhc_setup_xfertyp(cmd, data);
/* Mask all irqs */
esdhc_write32(®s->irqsigen, 0);
@@ -479,7 +479,7 @@ static int esdhc_send_cmd_common(struct fsl_esdhc_priv
*priv, struct mmc *mmc,
* speculative pre-fetching etc.
*/
if (data->flags & MMC_DATA_READ) {
- check_and_invalidate_dcache_range(cmd, data);
+ esdhc_invalidate_dcache_range(cmd, data);
}
#endif
}
@@ -506,7 +506,8 @@ out:
return err;
}
-static void set_sysctl(struct fsl_esdhc_priv *priv, struct mmc *mmc, uint
clock)
+static void esdhc_set_clock(struct fsl_esdhc_priv *priv, struct mmc *mmc,
+ uint clock)
{
struct fsl_esdhc *regs = priv->esdhc_regs;
int div = 1;
@@ -581,7 +582,7 @@ static int esdhc_set_ios_common(struct fsl_esdhc_priv
*priv, struct mmc *mmc)
#endif
/* Set the clock speed */
if (priv->clock != mmc->clock)
- set_sysctl(priv, mmc, mmc->clock);
+ esdhc_set_clock(priv, mmc, mmc->clock);
/* Set the bus width */
esdhc_clrbits32(®s->proctl, PROCTL_DTW_4 | PROCTL_DTW_8);
@@ -670,41 +671,7 @@ static int esdhc_reset(struct fsl_esdhc *regs)
}
#if !CONFIG_IS_ENABLED(DM_MMC)
-static int esdhc_getcd(struct mmc *mmc)
-{
- struct fsl_esdhc_priv *priv = mmc->priv;
-
- return esdhc_getcd_common(priv);
-}
-
-static int esdhc_init(struct mmc *mmc)
-{
- struc
[U-Boot] [v3, 1/4] mmc: fsl_esdhc: make BLK as hard requirement of DM_MMC
Current fsl_esdhc driver had support DM_MMC with BLK enabled.
Since BLK will be hard requirement of DM_MMC, let's do this
now in fsl_esdhc driver. Don't keep BLK conditioanl compiling.
Signed-off-by: Yangbo Lu
---
Changes for v2:
- None.
Changes for v3:
- None.
---
drivers/mmc/fsl_esdhc.c | 35 +--
1 file changed, 1 insertion(+), 34 deletions(-)
diff --git a/drivers/mmc/fsl_esdhc.c b/drivers/mmc/fsl_esdhc.c
index 0731847..ff5565c 100644
--- a/drivers/mmc/fsl_esdhc.c
+++ b/drivers/mmc/fsl_esdhc.c
@@ -23,10 +23,6 @@
#include
#include
-#if !CONFIG_IS_ENABLED(BLK)
-#include "mmc_private.h"
-#endif
-
DECLARE_GLOBAL_DATA_PTR;
#define SDHCI_IRQ_EN_BITS (IRQSTATEN_CC | IRQSTATEN_TC | \
@@ -35,7 +31,6 @@ DECLARE_GLOBAL_DATA_PTR;
IRQSTATEN_CIE | IRQSTATEN_DTOE | IRQSTATEN_DCE
| \
IRQSTATEN_DEBE | IRQSTATEN_BRR | IRQSTATEN_BWR
| \
IRQSTATEN_DINT)
-#define ESDHC_DRIVER_STAGE_VALUE 0x
struct fsl_esdhc {
uintdsaddr; /* SDMA system address register */
@@ -98,7 +93,7 @@ struct fsl_esdhc_priv {
struct clk per_clk;
unsigned int clock;
unsigned int bus_width;
-#if !CONFIG_IS_ENABLED(BLK)
+#if !CONFIG_IS_ENABLED(DM_MMC)
struct mmc *mmc;
#endif
struct udevice *dev;
@@ -961,9 +956,6 @@ static int fsl_esdhc_probe(struct udevice *dev)
fdt_addr_t addr;
unsigned int val;
struct mmc *mmc;
-#if !CONFIG_IS_ENABLED(BLK)
- struct blk_desc *bdesc;
-#endif
int ret;
addr = dev_read_addr(dev);
@@ -1027,32 +1019,12 @@ static int fsl_esdhc_probe(struct udevice *dev)
mmc = &plat->mmc;
mmc->cfg = &plat->cfg;
mmc->dev = dev;
-#if !CONFIG_IS_ENABLED(BLK)
- mmc->priv = priv;
-
- /* Setup dsr related values */
- mmc->dsr_imp = 0;
- mmc->dsr = ESDHC_DRIVER_STAGE_VALUE;
- /* Setup the universal parts of the block interface just once */
- bdesc = mmc_get_blk_desc(mmc);
- bdesc->if_type = IF_TYPE_MMC;
- bdesc->removable = 1;
- bdesc->devnum = mmc_get_next_devnum();
- bdesc->block_read = mmc_bread;
- bdesc->block_write = mmc_bwrite;
- bdesc->block_erase = mmc_berase;
-
- /* setup initial part type */
- bdesc->part_type = mmc->cfg->part_type;
- mmc_list_add(mmc);
-#endif
upriv->mmc = mmc;
return esdhc_init_common(priv, mmc);
}
-#if CONFIG_IS_ENABLED(DM_MMC)
static int fsl_esdhc_get_cd(struct udevice *dev)
{
struct fsl_esdhc_priv *priv = dev_get_priv(dev);
@@ -1082,30 +1054,25 @@ static const struct dm_mmc_ops fsl_esdhc_ops = {
.send_cmd = fsl_esdhc_send_cmd,
.set_ios= fsl_esdhc_set_ios,
};
-#endif
static const struct udevice_id fsl_esdhc_ids[] = {
{ .compatible = "fsl,esdhc", },
{ /* sentinel */ }
};
-#if CONFIG_IS_ENABLED(BLK)
static int fsl_esdhc_bind(struct udevice *dev)
{
struct fsl_esdhc_plat *plat = dev_get_platdata(dev);
return mmc_bind(dev, &plat->mmc, &plat->cfg);
}
-#endif
U_BOOT_DRIVER(fsl_esdhc) = {
.name = "fsl-esdhc-mmc",
.id = UCLASS_MMC,
.of_match = fsl_esdhc_ids,
.ops= &fsl_esdhc_ops,
-#if CONFIG_IS_ENABLED(BLK)
.bind = fsl_esdhc_bind,
-#endif
.probe = fsl_esdhc_probe,
.platdata_auto_alloc_size = sizeof(struct fsl_esdhc_plat),
.priv_auto_alloc_size = sizeof(struct fsl_esdhc_priv),
--
2.7.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [v3, 0/4] mmc: fsl_esdhc: clean up code
This patch-set is to clean up fsl_esdhc code. Changes for v2: - Involved esdhc_ops in non-DM conditional build. Changes for v3: - Added a patch to drop i.MX DDR mode code. Yangbo Lu (4): mmc: fsl_esdhc: make BLK as hard requirement of DM_MMC mmc: fsl_esdhc: clean up code mmc: fsl_esdhc: rename fsl_esdhc_init to fsl_esdhc_get_cfg mmc: fsl_esdhc: drop i.MX DDR mode code drivers/mmc/fsl_esdhc.c | 378 +++- include/fsl_esdhc.h | 203 -- 2 files changed, 242 insertions(+), 339 deletions(-) -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] clk: sifive: Fix ethernet regression on HiFive Unleashed
Hi Marcus, On Tue, Sep 10, 2019 at 11:53 PM Marcus Comstedt wrote: > > > Hi Bin, > > Bin Meng writes: > > > So 4.14 definitely was an out-of-tree kernel > > Everything before 5.2 was out-of-tree. > > > > No one can guarantee an out-of-tree implementation will be > > keeping compatible after it's accepted in-tree. > > Reviewers/maintainers can guarantee compatibility with existing > hardware and DT by not instisting on breaking changes. > > It's not really about keeping in-tree and out-of-tree compatible with > each other, but about keeping both of them compatible with the actual > hardware and DT of the system the OS is supposed to run on. > Per my understanding kernel reviewers/maintainers want to have a clean implementation from the start. That's why it's being done this way. > > > Reviewers/maintainers > > may have different view from the author on what's the best > > A reviewer/maintainer could for example have the view that a certain > register in a piece of hardware should really be two registers with > the bits divided between them based on some logical partitioning. And > they might be right. But the hardware is what it is, and if they > insist that the driver access two different registers the driver will > not work the hardware. You'll have a nice driver that works on > nothing (at least until the vendor makes a new spin of the hardware > with the two registers). The original hardware vendor's DT may be written in a way that violates the DT specs. Hence I believe it's really hard to keep the comparability for both. For this specific FU540 ethernet, what you did in this patch does not completely bring back the compatibility. Things were changed a lot in the upstream kernel. For example, the U-Boot GEM GXL-MGMT driver was needed to work with SiFive's DT https://lists.denx.de/pipermail/u-boot/2019-May/369577.html But later, it was dropped due to kernel mainline DT reviewers/maintainers thought it was a misuse of clock node and the GXL-MGMT module should be part of the GEM spec. https://lists.denx.de/pipermail/u-boot/2019-June/373306.html > > My opinion is that the DT should be treated the same way. It is part > of the hardware (sort of the "metadata" for the hardware). Sure you > can have some idea of how things could be expressed better and add > support for that, but you need to also keep compat with the actual > hardware platform that the driver is there to interface against, > otherwise the driver won't work. > While I agree with you to some extent that, that's now how things are done with current kernel practice. Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v4 0/1] imx: support i.MX8QM ROM 7720 a1 board
> Subject: Re: [PATCH v4 0/1] imx: support i.MX8QM ROM 7720 a1 board > > On 10/09/19, Peng Fan wrote: > > > Subject: [PATCH v4 0/1] imx: support i.MX8QM ROM 7720 a1 board > > > > > > Hello list, > > > > > > need some information howto avoid the imx-mkimage repo and create > > > full boostream directly from u-boot with all the binary blobs. > > > > Try the diff, and see whether it helps. > > diff --git a/arch/arm/mach-imx/Makefile b/arch/arm/mach-imx/Makefile > > index 08ee52edbf..4d0f0970df 100644 > > --- a/arch/arm/mach-imx/Makefile > > +++ b/arch/arm/mach-imx/Makefile > > @@ -159,10 +159,8 @@ MKIMAGEFLAGS_flash.bin = -n > spl/u-boot-spl.cfgout > > -T $(IMAGE_TYPE) -e 0x10 > > flash.bin: MKIMAGEOUTPUT = flash.log > > > > flash.bin: spl/u-boot-spl.bin u-boot.itb FORCE -ifeq > > ($(SPL_DEPFILE_EXISTS),0) > > $(call if_changed,mkimage) > > endif > > -endif > > > > else > > MKIMAGEFLAGS_SPL = -n $(filter-out $(PLUGIN).bin $< $(PHONY),$^) \ > > You are right, with that proposal and some minor fixes in my patch I can build > an full bootstream with all the needed binary blobs. So I can drop > imx-mkimage now. Great. This is a bug in the dependency file check. -Peng > > Thank you, > > Oliver ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 5/5] imx: add i.MX6ULZ board
> Subject: Re: [U-Boot] [PATCH v2 5/5] imx: add i.MX6ULZ board > > Hi Peng, > Hi Fabio, > > On 06.09.19 09:43, Peng Fan wrote: > >> Subject: Re: [U-Boot] [PATCH v2 5/5] imx: add i.MX6ULZ board > >> > >> Hi Stefan, > >> > >> On Thu, Sep 5, 2019 at 5:59 AM Stefan Roese wrote: > >> > >>> a) > >>> Why is SPL not used in the mainline i.MX6ULL/ULZ port? The i.MX6UL > >>> (14x14) does use SPL. > >> > >> Yes, I think it could SPL as well. Maybe Peng can comment. > > > > NXP vendor tree not support SPL, so when I upstream the code, SPL was > > not included. > > I see. Thanks for the update here. I might work on SPL support, if this seems > necessary for my custom i.MX6ULZ board. > > I do have another question though. I'm currently testing QSPI booting on the > i.MX6ULL EVK. And this does not work 100% reliably. Sometimes the board > boots after programming of the IMX image to 0x1000 in QSPI NOR to the > U-Boot prompt. And sometimes I see no output at all. I do have the QSPI > binary programmed at 0x400. BTW, these binaries boot all just fine when > booted via the "imx_usb" loader. Only when booted directly from QSPI (DIP > switches) it fails sometimes. > > Is this a known problem? I not heard such issue from our internal test. > > Do you have a reference U-Boot binary for QSPI booting for the i.MX6ULL EVK? > Best would be including the QSPI header (offset 0x400). Have you ever tried mfgtool? I do not have such image. Regards, Peng. > > Thanks, > Stefan ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] FDT placement in OpenSBI + U-Boot + Linux kernel issue for RISC-V
On Tue, Sep 10, 2019 at 09:59:38AM +, Atish Patra wrote:
> On Mon, 2019-09-09 at 13:22 +0300, David Abdurachmanov wrote:
> > On Mon, Sep 9, 2019 at 8:05 AM Anup Patel wrote:
> > > Hi,
> > >
> > > I think keeping FDT placement in-sync between U-Boot and OpenSBI
> > > across platforms is going to be painful.
> > >
> > > I suggest that for all platforms U-Boot explicitly load FDT from
> > > somewhere
> > > so:
> > > 1. U-Boot ${fdt_addr_r} default value will be recommended location
> > > of FDT
> > > 2. U-Boot ${fdtcontroladdr} will always point to copy of FDT passed
> > > by OpenSBI
> > > 3. To forward FDT passed by OpenSBI to Linux, U-Boot users can
> > > always explicitly
> > > copy FDT from ${fdtcontroladdr} to ${fdt_addr_r} using U-Boot copy
> > > command
> > >
> > > I also suspect that in-future for certain platforms FDT passed to
> > > U-Boot and
> > > FDT passed to Linux might be little different due to U-Boot
> > > specific changes
> > > in DTS.
> > >
> > > Thoughts ??
> >
> > Do not forget PXE and EXTLINUX boot options. These options must
> > always be able to override DTB from previous stages. See below what
> > PXE/EXT use. For Fedora/RISCV we end up in scenario #2 and thus
> > fdt_addr needs to be set if DTB is coming from somewhere in the
> > firmware.
> > This is why we had CONFIG_PREBOOT to set it.
> >
> > [..]
> > * Scenario 1: If fdt_addr_r specified and "fdt" label is defined in
> > * pxe file, retrieve fdt blob from server. Pass fdt_addr_r to bootm,
> > * and adjust argc appropriately.
> > *
> > * Scenario 2: If there is an fdt_addr specified, pass it along to
> > * bootm, and adjust argc appropriately.
> > *
>
> How about if we do this in PREBOOT ?
>
> 1. copy fdt from fdtcontroladdr to fdt_addr_r
> 2. setenv fdt_addr $fdt_addr_r
>
> In this way, U-Boot will not have any direct dependancies on OpenSBI.
> As long as U-Boot is configured with a fdt_addr_r, it should work. It
> will be still valid for loading fdt from tftp server to fdt_addr_r as
> well.
Since, arg, it looks like we're already seeing some of the original
mistakes from ARM land (fdt address in a bad place and getting stomped
by ...), lets take a look at how this is being handled today there and
mirror it? We should for example pick the fdt-in-memory location such
that we have enough room between it and the maximum kernel + bss, round
up and place it there. Then round up again for an overly large fdt to
say that's where ramdisk should go. 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] ARM: mxs: spl_boot.c: make early_delay more robust
[Adding Marek]
On Tue, Sep 10, 2019 at 5:32 AM Rasmus Villemoes
wrote:
>
> It's true that booting normally doesn't take long enough for the
> register to roll (which actually happens in a little over an hour, not
> just a few seconds). However, the counter starts at power-on, and if
> the board is held in reset to be booted over USB, one actually risks
> hitting wrap-around during boot, which can both result in too short
> delays (if the "st += delay" calculation makes st small) and
> theoretically also unbound delays (if st ends up being UINT_MAX and
> one just misses sampling digctl_microseconds at that point).
>
> It doesn't take more code to DTRT, and once bitten, twice shy.
>
> Signed-off-by: Rasmus Villemoes
> ---
> arch/arm/cpu/arm926ejs/mxs/spl_boot.c | 7 ++-
> 1 file changed, 2 insertions(+), 5 deletions(-)
>
> diff --git a/arch/arm/cpu/arm926ejs/mxs/spl_boot.c
> b/arch/arm/cpu/arm926ejs/mxs/spl_boot.c
> index cb361ac65c..336266fe82 100644
> --- a/arch/arm/cpu/arm926ejs/mxs/spl_boot.c
> +++ b/arch/arm/cpu/arm926ejs/mxs/spl_boot.c
> @@ -24,9 +24,7 @@ static bd_t bdata __section(".data");
>
> /*
> * This delay function is intended to be used only in early stage of boot,
> where
> - * clock are not set up yet. The timer used here is reset on every boot and
> - * takes a few seconds to roll. The boot doesn't take that long, so to keep
> the
> - * code simple, it doesn't take rolling into consideration.
> + * clock are not set up yet.
> */
> void early_delay(int delay)
> {
> @@ -34,8 +32,7 @@ void early_delay(int delay)
> (struct mxs_digctl_regs *)MXS_DIGCTL_BASE;
>
> uint32_t st = readl(&digctl_regs->hw_digctl_microseconds);
> - st += delay;
> - while (st > readl(&digctl_regs->hw_digctl_microseconds))
> + while (readl(&digctl_regs->hw_digctl_microseconds) - st <= delay)
> ;
Looks reasonable for me.
Thanks
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Add support for imxrt
Hi Giulio, On Tue, Sep 10, 2019 at 3:32 PM Giulio Benetti wrote: > > Hello everybody, > > I would like to port imxrt to u-boot and I would like to ask you: > - do you have the interest on upstreaming it? > if yes: > I've seen how they've dealt with 'stm32' and 'stm32mp' that is similar > to 'imxrt' and 'imx'. So should follow the same criterias for porting? I > mean adding the new folder 'mach-imxrt'? Yes, please submit the patches to the U-Boot list for review. Thanks ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Please pull u-boot-x86
On Tue, Sep 10, 2019 at 08:35:30PM +0800, Bin Meng wrote: > Hi Tom, > > This PR includes the following x86 changes for v2019.10: > - Tangier ACPI table fixes > - Support getting high memory size on QEMU x86 > - Show UEFI images involved in crash for x86 > - EFI loader conventional memory map fix > > The following changes since commit c705fc3b40b88bfbf465448643c91da71426df2f: > > arm: ti: Add missing "=" from previous fix (2019-09-09 10:55:45 -0400) > > are available in the git repository at: > > https://gitlab.denx.de/u-boot/custodians/u-boot-x86 > > for you to fetch changes up to dd4faa964f0741c314b4f1c09f27c07aedc5cdf0: > > x86: tangier: Use spaces over TABs in ASL code (2019-09-10 16:19:03 +0800) > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PULL u-boot] Please pull u-boot-amlogic-20190910
On Tue, Sep 10, 2019 at 01:28:01PM +0200, Neil Armstrong wrote: > Hi Tom, > > This PR simply adds support for dis_u2_susphy_quirk in the xhci-dwc3 driver > to fix boot when > a device is plugged only in the OTG capable port for libretech-ac and > libretech-cc. > > Bin acked me for pushing this fix through my tree. > > The CI job is at > https://gitlab.denx.de/u-boot/custodians/u-boot-amlogic/pipelines/642 > > Thanks, > Neil > > The following changes since commit c705fc3b40b88bfbf465448643c91da71426df2f: > > arm: ti: Add missing "=" from previous fix (2019-09-09 10:55:45 -0400) > > are available in the Git repository at: > > https://gitlab.denx.de/u-boot/custodians/u-boot-amlogic.git > tags/u-boot-amlogic-20190910 > > for you to fetch changes up to b35b8076828d1059c1fcc648ed8c8210ebe6a3dd: > > usb: xhci-dwc3: Add support for dis_u2_susphy_quirk (2019-09-10 10:00:53 > +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 2/2] spi-nor: spi-nor-ids: Disable SPI_NOR_4B_OPCODES for n25q512* and n25q256*
Vignesh Raghavendra schrieb am Di., 10. Sep. 2019, 19:07:
> Not all variants of n25q256* and n25q512* support 4 Byte stateless
> addressing opcodes and there is no easy way to discover at runtime
> whether the flash supports this feature or not.
> Therefore don't set SPI_NOR_4B_OPCODES for these flashes.
>
I have one of those that supports 4 Byte opposes and would be glad if I
could use them. Is there any chance of flagging the devicetree or something
that enables them?
Regards,
Simon
> Signed-off-by: Vignesh Raghavendra
> For n25q512ax3:
> Tested-by: Eugeniy Paltsev
> ---
> drivers/mtd/spi/spi-nor-ids.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/mtd/spi/spi-nor-ids.c b/drivers/mtd/spi/spi-nor-ids.c
> index f32a6c7d464b..5a7fe07c8309 100644
> --- a/drivers/mtd/spi/spi-nor-ids.c
> +++ b/drivers/mtd/spi/spi-nor-ids.c
> @@ -161,10 +161,10 @@ const struct flash_info spi_nor_ids[] = {
> { INFO("n25q064a",0x20bb17, 0, 64 * 1024, 128, SECT_4K |
> SPI_NOR_QUAD_READ) },
> { INFO("n25q128a11", 0x20bb18, 0, 64 * 1024, 256, SECT_4K |
> SPI_NOR_QUAD_READ) },
> { INFO("n25q128a13", 0x20ba18, 0, 64 * 1024, 256, SECT_4K |
> SPI_NOR_QUAD_READ) },
> - { INFO("n25q256a",0x20ba19, 0, 64 * 1024, 512, SECT_4K |
> SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_4B_OPCODES) },
> + { INFO("n25q256a",0x20ba19, 0, 64 * 1024, 512, SECT_4K |
> SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
> { INFO("n25q256ax1", 0x20bb19, 0, 64 * 1024, 512, SECT_4K |
> SPI_NOR_QUAD_READ | SPI_NOR_4B_OPCODES) },
> - { INFO("mt25qu512a (n25q512a)",0x20bb20, 0, 64 * 1024, 1024,
> SECT_4K | USE_FSR | SPI_NOR_QUAD_READ | SPI_NOR_4B_OPCODES) },
> - { INFO("n25q512ax3", 0x20ba20, 0, 64 * 1024, 1024, SECT_4K |
> USE_FSR | SPI_NOR_QUAD_READ | SPI_NOR_4B_OPCODES) },
> + { INFO("mt25qu512a (n25q512a)",0x20bb20, 0, 64 * 1024, 1024,
> SECT_4K | USE_FSR | SPI_NOR_QUAD_READ) },
> + { INFO("n25q512ax3", 0x20ba20, 0, 64 * 1024, 1024, SECT_4K |
> USE_FSR | SPI_NOR_QUAD_READ) },
> { INFO("n25q00", 0x20ba21, 0, 64 * 1024, 2048, SECT_4K |
> USE_FSR | SPI_NOR_QUAD_READ | NO_CHIP_ERASE) },
> { INFO("n25q00a", 0x20bb21, 0, 64 * 1024, 2048, SECT_4K |
> USE_FSR | SPI_NOR_QUAD_READ | NO_CHIP_ERASE) },
> { INFO("mt25qu02g", 0x20bb22, 0, 64 * 1024, 4096, SECT_4K |
> USE_FSR | SPI_NOR_QUAD_READ | NO_CHIP_ERASE) },
> --
> 2.23.0
>
> ___
> 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 0/2] arm64: dts: sun50i: Add support for A64 OLinuXino (with eMMC)
On 06/09/19 9:05 pm, Jagan Teki wrote: > On Fri, Aug 23, 2019 at 1:56 AM Sunil Mohan Adapa wrote: >> >> This is a follow up a patch that didn't create a separate dts: >> https://lists.denx.de/pipermail/u-boot/2019-July/379109.html >> >> A64 OLinuXino board from Olimex has three variants with onboard eMMC: >> A64-OLinuXino-1Ge16GW, A64-OLinuXino-1Ge4GW and A64-OLinuXino-2Ge8G-IND. In >> addition, there are two variants without eMMC. One without eMMC and one with >> SPI >> flash. This suggests the need for separate device tree for the three eMMC >> variants. >> >> The Linux kernel upstream has chosen to create and use a separate device tree >> for the eMMC variants instead of adding eMMC support existing device tree. >> These >> changes to Linux kernel are queued for Linux 5.4. >> >> https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux.git/commit/?h=sunxi/dt-for-5.4&id=02bb66b347ff8115f53948f86b884e008ba385b9 >> >> This patch has been tested on A64-OLinuXino-1Ge16GW and is based on Linux >> device-tree. >> >> Changes: >> >> v2: Separate device tree for emmc models. >> >> Sunil Mohan Adapa (2): >> arm64: dts: sun50i: Add support for A64 OLinuXino (with eMMC) >> configs: sun50i: Add support for Olimex A64-Olinuxino-eMMC > > Please squash and send it as single patch, all look fine to me. > > Reviewed-by: Jagan Teki > Thank you for reviewing the patch. I have posted v3 with the two patches squashed. -- Sunil signature.asc Description: OpenPGP digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v3] arm64: dts: sun50i: Add support for A64 OLinuXino (with eMMC)
A64 OLinuXino board from Olimex has three variants with onboard eMMC:
A64-OLinuXino-1Ge16GW, A64-OLinuXino-1Ge4GW and A64-OLinuXino-2Ge8G-IND. In
addition, there are two variants without eMMC. One without eMMC and one with SPI
flash. This suggests the need for separate device tree for the three eMMC
variants.
The Linux kernel upstream has chosen to create and use a separate device tree
for the eMMC variants instead of adding eMMC support existing device tree. These
changes to Linux kernel are queued for Linux 5.4.
https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux.git/commit/?h=sunxi/dt-for-5.4&id=02bb66b347ff8115f53948f86b884e008ba385b9
This patch has been tested on A64-OLinuXino-1Ge16GW and is based on Linux
device-tree and a64-olinuxino_defconfig.
changes:
v3: Squash two separate patches into a single one.
v2: Separate device tree for emmc models.
Signed-off-by: Sunil Mohan Adapa
Reviewed-by: Jagan Teki
---
arch/arm/dts/Makefile | 1 +
arch/arm/dts/sun50i-a64-olinuxino-emmc.dts | 23 ++
board/sunxi/MAINTAINERS| 5 +
configs/a64-olinuxino-emmc_defconfig | 17
4 files changed, 46 insertions(+)
create mode 100644 arch/arm/dts/sun50i-a64-olinuxino-emmc.dts
create mode 100644 configs/a64-olinuxino-emmc_defconfig
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 05ff624c07..d28906a63b 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -530,6 +530,7 @@ dtb-$(CONFIG_MACH_SUN50I) += \
sun50i-a64-nanopi-a64.dtb \
sun50i-a64-oceanic-5205-5inmfd.dtb \
sun50i-a64-olinuxino.dtb \
+ sun50i-a64-olinuxino-emmc.dtb \
sun50i-a64-orangepi-win.dtb \
sun50i-a64-pine64-lts.dtb \
sun50i-a64-pine64-plus.dtb \
diff --git a/arch/arm/dts/sun50i-a64-olinuxino-emmc.dts
b/arch/arm/dts/sun50i-a64-olinuxino-emmc.dts
new file mode 100644
index 00..96ab0227e8
--- /dev/null
+++ b/arch/arm/dts/sun50i-a64-olinuxino-emmc.dts
@@ -0,0 +1,23 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (C) 2018 Martin Ayotte
+ * Copyright (C) 2019 Sunil Mohan Adapa
+ */
+
+#include "sun50i-a64-olinuxino.dts"
+
+/ {
+ model = "Olimex A64-Olinuxino-eMMC";
+ compatible = "olimex,a64-olinuxino-emmc", "allwinner,sun50i-a64";
+};
+
+&mmc2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&mmc2_pins>;
+ vmmc-supply = <®_dcdc1>;
+ vqmmc-supply = <®_dcdc1>;
+ bus-width = <8>;
+ non-removable;
+ cap-mmc-hw-reset;
+ status = "okay";
+};
diff --git a/board/sunxi/MAINTAINERS b/board/sunxi/MAINTAINERS
index c7e9d3eda0..442ff3d9cd 100644
--- a/board/sunxi/MAINTAINERS
+++ b/board/sunxi/MAINTAINERS
@@ -106,6 +106,11 @@ M: Jagan Teki
S: Maintained
F: configs/a64-olinuxino_defconfig
+A64-OLINUXINO-EMMC BOARD
+M: Sunil Mohan Adapa
+S: Maintained
+F: configs/a64-olinuxino-emmc_defconfig
+
A80 OPTIMUS BOARD
M: Chen-Yu Tsai
S: Maintained
diff --git a/configs/a64-olinuxino-emmc_defconfig
b/configs/a64-olinuxino-emmc_defconfig
new file mode 100644
index 00..56153e38a7
--- /dev/null
+++ b/configs/a64-olinuxino-emmc_defconfig
@@ -0,0 +1,17 @@
+CONFIG_ARM=y
+CONFIG_ARCH_SUNXI=y
+CONFIG_NR_DRAM_BANKS=1
+CONFIG_SPL=y
+CONFIG_MACH_SUN50I=y
+CONFIG_RESERVE_ALLWINNER_BOOT0_HEADER=y
+CONFIG_MMC_SUNXI_SLOT_EXTRA=2
+# CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
+CONFIG_USE_PREBOOT=y
+# CONFIG_CMD_FLASH is not set
+# CONFIG_SPL_DOS_PARTITION is not set
+# CONFIG_SPL_EFI_PARTITION is not set
+CONFIG_DEFAULT_DEVICE_TREE="sun50i-a64-olinuxino-emmc"
+CONFIG_SUN8I_EMAC=y
+CONFIG_USB_EHCI_HCD=y
+CONFIG_USB_OHCI_HCD=y
+CONFIG_SYS_USB_EVENT_POLL_VIA_INT_QUEUE=y
--
2.20.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 2/2] spi-nor: spi-nor-ids: Disable SPI_NOR_4B_OPCODES for n25q512* and n25q256*
Not all variants of n25q256* and n25q512* support 4 Byte stateless
addressing opcodes and there is no easy way to discover at runtime
whether the flash supports this feature or not.
Therefore don't set SPI_NOR_4B_OPCODES for these flashes.
Signed-off-by: Vignesh Raghavendra
For n25q512ax3:
Tested-by: Eugeniy Paltsev
---
drivers/mtd/spi/spi-nor-ids.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/mtd/spi/spi-nor-ids.c b/drivers/mtd/spi/spi-nor-ids.c
index f32a6c7d464b..5a7fe07c8309 100644
--- a/drivers/mtd/spi/spi-nor-ids.c
+++ b/drivers/mtd/spi/spi-nor-ids.c
@@ -161,10 +161,10 @@ const struct flash_info spi_nor_ids[] = {
{ INFO("n25q064a",0x20bb17, 0, 64 * 1024, 128, SECT_4K |
SPI_NOR_QUAD_READ) },
{ INFO("n25q128a11", 0x20bb18, 0, 64 * 1024, 256, SECT_4K |
SPI_NOR_QUAD_READ) },
{ INFO("n25q128a13", 0x20ba18, 0, 64 * 1024, 256, SECT_4K |
SPI_NOR_QUAD_READ) },
- { INFO("n25q256a",0x20ba19, 0, 64 * 1024, 512, SECT_4K |
SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_4B_OPCODES) },
+ { INFO("n25q256a",0x20ba19, 0, 64 * 1024, 512, SECT_4K |
SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
{ INFO("n25q256ax1", 0x20bb19, 0, 64 * 1024, 512, SECT_4K |
SPI_NOR_QUAD_READ | SPI_NOR_4B_OPCODES) },
- { INFO("mt25qu512a (n25q512a)",0x20bb20, 0, 64 * 1024, 1024,
SECT_4K | USE_FSR | SPI_NOR_QUAD_READ | SPI_NOR_4B_OPCODES) },
- { INFO("n25q512ax3", 0x20ba20, 0, 64 * 1024, 1024, SECT_4K | USE_FSR |
SPI_NOR_QUAD_READ | SPI_NOR_4B_OPCODES) },
+ { INFO("mt25qu512a (n25q512a)",0x20bb20, 0, 64 * 1024, 1024,
SECT_4K | USE_FSR | SPI_NOR_QUAD_READ) },
+ { INFO("n25q512ax3", 0x20ba20, 0, 64 * 1024, 1024, SECT_4K | USE_FSR |
SPI_NOR_QUAD_READ) },
{ INFO("n25q00", 0x20ba21, 0, 64 * 1024, 2048, SECT_4K | USE_FSR |
SPI_NOR_QUAD_READ | NO_CHIP_ERASE) },
{ INFO("n25q00a", 0x20bb21, 0, 64 * 1024, 2048, SECT_4K | USE_FSR |
SPI_NOR_QUAD_READ | NO_CHIP_ERASE) },
{ INFO("mt25qu02g", 0x20bb22, 0, 64 * 1024, 4096, SECT_4K | USE_FSR |
SPI_NOR_QUAD_READ | NO_CHIP_ERASE) },
--
2.23.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/2] spi-nor: spi-nor-ids: Merge "n25q512a" and "mt25qu512a" entries
mt25qu512a is just a rebranded name for n25q512a. All the 6 bytes of JEDEC
ID bytes are same for mt25qu512a and n25q512a.
Commit 8385520f2931 ("mtd: spi: Add flash property for Micron mt25qu512a")
added new entry for mt25qu512a before n25q512a entry. So on older boards
with n25q512a "sf probe" now shows flash name as mt25qu512a. This creates
confusion with users who used to seeing n25q512a and are not aware of
the fact that both flashes are the same. Therefore fix this by renaming
name to "mt25qu512a (n25q512a)" so as to make it clear that flash
detected may be either of them.
With that we can have single entry for n25q512a and mt25qu512a.
Signed-off-by: Vignesh Raghavendra
---
drivers/mtd/spi/spi-nor-ids.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/mtd/spi/spi-nor-ids.c b/drivers/mtd/spi/spi-nor-ids.c
index a3920ba520e0..f32a6c7d464b 100644
--- a/drivers/mtd/spi/spi-nor-ids.c
+++ b/drivers/mtd/spi/spi-nor-ids.c
@@ -163,9 +163,7 @@ const struct flash_info spi_nor_ids[] = {
{ INFO("n25q128a13", 0x20ba18, 0, 64 * 1024, 256, SECT_4K |
SPI_NOR_QUAD_READ) },
{ INFO("n25q256a",0x20ba19, 0, 64 * 1024, 512, SECT_4K |
SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_4B_OPCODES) },
{ INFO("n25q256ax1", 0x20bb19, 0, 64 * 1024, 512, SECT_4K |
SPI_NOR_QUAD_READ | SPI_NOR_4B_OPCODES) },
- { INFO6("mt25qu512a", 0x20bb20, 0x104400, 64 * 1024, 1024,
-SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_4B_OPCODES) },
- { INFO("n25q512a",0x20bb20, 0, 64 * 1024, 1024, SECT_4K | USE_FSR |
SPI_NOR_QUAD_READ | SPI_NOR_4B_OPCODES) },
+ { INFO("mt25qu512a (n25q512a)",0x20bb20, 0, 64 * 1024, 1024,
SECT_4K | USE_FSR | SPI_NOR_QUAD_READ | SPI_NOR_4B_OPCODES) },
{ INFO("n25q512ax3", 0x20ba20, 0, 64 * 1024, 1024, SECT_4K | USE_FSR |
SPI_NOR_QUAD_READ | SPI_NOR_4B_OPCODES) },
{ INFO("n25q00", 0x20ba21, 0, 64 * 1024, 2048, SECT_4K | USE_FSR |
SPI_NOR_QUAD_READ | NO_CHIP_ERASE) },
{ INFO("n25q00a", 0x20bb21, 0, 64 * 1024, 2048, SECT_4K | USE_FSR |
SPI_NOR_QUAD_READ | NO_CHIP_ERASE) },
--
2.23.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] env: Add CONFIG_ENV_SUPPORT
Dear Patrick, In message <9c7801afb8c94c638933cf33746ae...@sfhdag6node3.st.com> you wrote: > > And I agree the name seens not perfect. > > > > - CONFIG_SPL_ENV_SUPPORT for SPL > > > - CONFIG_TPL_ENV_SUPPORT for TPL > > These pre-existing name are defined in common/spl/Kconfig > > With the same issue (env/common.o env/env.o are always compiled for SPL/TPL > so it is alo bad names) Correct. > > So please reconsider this whole implementation, and make sure that only a > > single > > macro ise used everywhere to enable these features. > > But, if I use the same CONFIG for the 3 binary SPL,TPL and U-Boot, > l increase the size of TPL/SPL for all the platforms when these > additional features are not needed. Either the U-Boot environment makes use of these features, then they have to be enabled, and exactly the same way in SPL, TPL and U-Boot proper. Or you don't need them, then they can be disabled, but again in a consistent way in SPL, TPL, and U-Boot proper. It is not acceptable to have for example .flags support in U-Boot, but not is SPL. If you cannot affort the size in SPL (and need environment there at all), then you cannot have it in U-Boot either. Yes, this is sad, but anything else would break the implementation of these features, and given that they are often used to implement some level of protection or security, introduce massive security issues. So if SPL size is critical, you can try do not access the environment at all and omit _all_ of the environment code there; or you can try to arrange for a read-only implementation (omitting at least the code needed for "env save" including write routines to storage). But you CANNOT omit the extensions if these are present in U-Boot proper. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Die Scheu vor Verantwortung ist die Krankheit unserer Zeit. -- Otto von Bismarck ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] clk: sifive: Fix ethernet regression on HiFive Unleashed
Hi Bin, Bin Meng writes: > So 4.14 definitely was an out-of-tree kernel Everything before 5.2 was out-of-tree. > No one can guarantee an out-of-tree implementation will be > keeping compatible after it's accepted in-tree. Reviewers/maintainers can guarantee compatibility with existing hardware and DT by not instisting on breaking changes. It's not really about keeping in-tree and out-of-tree compatible with each other, but about keeping both of them compatible with the actual hardware and DT of the system the OS is supposed to run on. > Reviewers/maintainers > may have different view from the author on what's the best A reviewer/maintainer could for example have the view that a certain register in a piece of hardware should really be two registers with the bits divided between them based on some logical partitioning. And they might be right. But the hardware is what it is, and if they insist that the driver access two different registers the driver will not work the hardware. You'll have a nice driver that works on nothing (at least until the vendor makes a new spin of the hardware with the two registers). My opinion is that the DT should be treated the same way. It is part of the hardware (sort of the "metadata" for the hardware). Sure you can have some idea of how things could be expressed better and add support for that, but you need to also keep compat with the actual hardware platform that the driver is there to interface against, otherwise the driver won't work. // Marcus ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [U-BOOT PATCH v1 2/2] configs: fu540: enable gpio driver
Enable the DM based GPIO driver for FU540-C000 SoC. Signed-off-by: Sagar Shrikant Kadam --- board/sifive/fu540/Kconfig | 3 +++ 1 file changed, 3 insertions(+) diff --git a/board/sifive/fu540/Kconfig b/board/sifive/fu540/Kconfig index 5d65080..5ca2147 100644 --- a/board/sifive/fu540/Kconfig +++ b/board/sifive/fu540/Kconfig @@ -44,6 +44,9 @@ config BOARD_SPECIFIC_OPTIONS # dummy imply MMC_SPI imply MMC_BROKEN_CD imply CMD_MMC + imply DM_GPIO + imply SIFIVE_GPIO + imply CMD_GPIO imply SMP endif -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [U-BOOT PATCH v1 1/2] gpio: fu540: add support for DM based gpio driver for FU540-SoC
This patch adds a DM based driver model for gpio controller present in
FU540-C000 SoC on HiFive Unleashed A00 board. This SoC has one GPIO
bank and 16 GPIO lines in total, out of which GPIO0 to GPIO9 and
GPIO15 are routed to the J1 header on the board.
This implementation is ported from linux based gpio driver submitted
for review by Wesley W. Terpstra and/or Atish Patra
(many thanks !!). The linux driver can be referred
here [1]
[1]: https://lkml.org/lkml/2018/10/9/1103
Signed-off-by: Sagar Shrikant Kadam
---
arch/riscv/include/asm/arch-generic/gpio.h | 35 +++
arch/riscv/include/asm/gpio.h | 6 ++
drivers/gpio/Kconfig | 8 ++
drivers/gpio/Makefile | 1 +
drivers/gpio/sifive-gpio.c | 143 +
5 files changed, 193 insertions(+)
create mode 100644 arch/riscv/include/asm/arch-generic/gpio.h
create mode 100644 arch/riscv/include/asm/gpio.h
create mode 100644 drivers/gpio/sifive-gpio.c
diff --git a/arch/riscv/include/asm/arch-generic/gpio.h
b/arch/riscv/include/asm/arch-generic/gpio.h
new file mode 100644
index 000..7287298
--- /dev/null
+++ b/arch/riscv/include/asm/arch-generic/gpio.h
@@ -0,0 +1,35 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * Copyright (C) 2019 SiFive, Inc.
+ */
+
+#ifndef _GPIO_FU540_H
+#define _GPIO_FU540_H
+
+#define GPIO_INPUT_VAL 0x00
+#define GPIO_INPUT_EN 0x04
+#define GPIO_OUTPUT_EN 0x08
+#define GPIO_OUTPUT_VAL0x0C
+#define GPIO_RISE_IE 0x18
+#define GPIO_RISE_IP 0x1C
+#define GPIO_FALL_IE 0x20
+#define GPIO_FALL_IP 0x24
+#define GPIO_HIGH_IE 0x28
+#define GPIO_HIGH_IP 0x2C
+#define GPIO_LOW_IE0x30
+#define GPIO_LOW_IP0x34
+#define GPIO_OUTPUT_XOR0x40
+
+#define NR_GPIOS 16
+
+enum gpio_state {
+ LOW,
+ HIGH
+};
+
+/* Details about a GPIO bank */
+struct fu540_gpio_platdata {
+ void *base; /* address of registers in physical memory */
+};
+
+#endif /* _GPIO_FU540_H */
diff --git a/arch/riscv/include/asm/gpio.h b/arch/riscv/include/asm/gpio.h
new file mode 100644
index 000..008d756
--- /dev/null
+++ b/arch/riscv/include/asm/gpio.h
@@ -0,0 +1,6 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * Copyright 2018 SiFive, Inc.
+ */
+
+#include
diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index f2dabb5..ec48f26 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -285,6 +285,14 @@ config STM32_GPIO
usable on many stm32 families like stm32f4/f7/h7 and stm32mp1.
Tested on STM32F7.
+config SIFIVE_GPIO
+ bool "SiFive FU540 GPIO driver"
+ depends on DM_GPIO
+ help
+ Device model driver for GPIO controller present in FU540 SoC. This
+ driver enables GPIO interface on HiFive Unleashed A00 board a board
+ from SiFive Inc. having FU540-C000 SoC.
+
config MVEBU_GPIO
bool "Marvell MVEBU GPIO driver"
depends on DM_GPIO && ARCH_MVEBU
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index 4a8aa0f..ccc49e2 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -61,3 +61,4 @@ obj-$(CONFIG_$(SPL_)PCF8575_GPIO) += pcf8575_gpio.o
obj-$(CONFIG_PM8916_GPIO) += pm8916_gpio.o
obj-$(CONFIG_MT7621_GPIO) += mt7621_gpio.o
obj-$(CONFIG_MSCC_SGPIO) += mscc_sgpio.o
+obj-$(CONFIG_SIFIVE_GPIO) += sifive-gpio.o
diff --git a/drivers/gpio/sifive-gpio.c b/drivers/gpio/sifive-gpio.c
new file mode 100644
index 000..4bf8acf
--- /dev/null
+++ b/drivers/gpio/sifive-gpio.c
@@ -0,0 +1,143 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * SiFive GPIO driver
+ *
+ * Copyright (C) 2019 SiFive, Inc.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+static int fu540_gpio_probe(struct udevice *dev)
+{
+ struct gpio_dev_priv *uc_priv = dev_get_uclass_priv(dev);
+
+ uc_priv->bank_name = dev->name;
+
+ /*
+* Use the gpio count mentioned in device tree,
+* if not specified in dt, set NR_GPIOS as default
+*/
+ uc_priv->gpio_count = dev_read_u32_default(dev, "ngpios", NR_GPIOS);
+
+ return 0;
+}
+
+static void fu540_update_gpio_reg(void *bptr, u32 offset, bool value)
+{
+ void __iomem *ptr = (void __iomem *)bptr;
+
+ u32 bit = BIT(offset);
+ u32 old = readl(ptr);
+
+ if (value)
+ writel(old | bit, ptr);
+ else
+ writel(old & ~bit, ptr);
+}
+
+static int fu540_gpio_direction_input(struct udevice *dev, u32 offset)
+{
+ struct fu540_gpio_platdata *plat = dev_get_platdata(dev);
+ struct gpio_dev_priv *uc_priv = dev_get_uclass_priv(dev);
+
+ if (offset > uc_priv->gpio_count)
+ return -EINVAL;
+
+ /* Configure GPIO direction as input */
+ fu540_update_gpio_reg(plat->base + GPIO_INPUT_EN, offset, true);
+ fu540_update_gpio_reg(plat->base + GPIO_OUTPUT_EN, offset, false);
+
+ return 0;
+}
+
+static int fu540_g
[U-Boot] [U-BOOT PATCH v1 0/2] add gpio support for HiFive Unleashed A00 board.
U-Boot currently is missing GPIO support for FU540-C000 SoC which is mounted on HiFive Unleashed A00 board. This patch is intended to add DM based GPIO controller driver in order to access GPIO pins within the SoC using GPIO command in U-Boot. More details on the GPIO controller within the SoC can be found at[1] The driver is based above master branch of u-boot-riscv.git and provides a method to configure Input/Output mode of the GPIO pin along with an option to set or clear state of the GPIO pin. The patch is available in dev/sagark/gpio_v3 branch here[2]. GPIO device node added to the mainline bound device tree for HiFive Unleashed is available in dev/sagark/mlv5.3-rc5 branch of repo here[3]. This implementation is ported from linux driver submitted for review at [4]. More details of GPIO pin routing on J1 header is available in schematic document[5] [1] https://static.dev.sifive.com/FU540-C000-v1.0.pdf [2] https://github.com/sagsifive/u-boot [3] https://github.com/sagsifive/riscv-linux-hifive/ [4] https://lkml.org/lkml/2018/10/9/1103 [5] https://static.dev.sifive.com/dev-kits/hifive-unleashed/hifive-unleashed-a00-schematics.pdf Driver Testing: #Set GPIO1 high. =>gpio set 1 Can be confirmed by probing pin No #24 on J1 Header or memory dump of gpio register space viz: #md 0x1006 #Set GPIO1 low =>gpio clear 0 #Toggle GPIO1 =>gpio toggle 1 #Toggle value of GPIO1 =>gpio toggle 1 #Toggle value of GPIO1 #Configure pin as input =>gpio input 3 #Configure gpio line 3 as input. #Error check =>gpio set 16 #Not a valid GPIO number for FU540-C000 GPIO: '16' not found Command 'gpio' failed: Error -22 Patch history: v1: -Set gpio_count either from the device tree or with a MACRO if ngpio's property is not mentioned in device node. -Check if gpio number passed from the command line is within the valid range. Incorporated review comment from Bin Meng -Renamed driver from fu540-gpio to sifive-gpio -Include a proper header file -Use dev->name as bank_name. v0: Base version Sagar Shrikant Kadam (2): gpio: fu540: add support for DM based gpio driver for FU540-SoC configs: fu540: enable gpio driver arch/riscv/include/asm/arch-generic/gpio.h | 35 +++ arch/riscv/include/asm/gpio.h | 6 ++ board/sifive/fu540/Kconfig | 3 + drivers/gpio/Kconfig | 8 ++ drivers/gpio/Makefile | 1 + drivers/gpio/sifive-gpio.c | 143 + 6 files changed, 196 insertions(+) create mode 100644 arch/riscv/include/asm/arch-generic/gpio.h create mode 100644 arch/riscv/include/asm/gpio.h create mode 100644 drivers/gpio/sifive-gpio.c -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] clk: sifive: Fix ethernet regression on HiFive Unleashed
Hi Marcus, On Tue, Sep 10, 2019 at 4:52 AM Marcus Comstedt wrote: > > > Hi Bin, > > Bin Meng writes: > > >> Yes, but in which Linux? This whole thing started because U-Boot will > > > > The latest Linux kernel v5.3. > > Thanks. I'll try it later. As if to prove my point, the one from > 5.2.11 (which is the Linux version I'm currently running) did not work > (I got MMC but no ethernet)... Maybe Anup could chime in for various SiFive kernel driver upstream history. My memory was that before all these drivers were upstreamed, we were using SiFive's out-of-tree kernel and drivers. > > > > I checked kernel 4.14 and found it did not ship the SiFive Unleased > > board DTS in the kernel tree. Are you sure it's 4.14? > > It's the one shipped with the H5U, which I'm pretty sure ran Linux > 4.14 at the time (as part of the "Freedom U SDK") since 4.15 was not > out yet. It looks like SiFive never added the DTS to their own Linux > tree (https://github.com/sifive/riscv-linux). > So 4.14 definitely was an out-of-tree kernel since I did not see the SiFive DTS in the mainline kernel. For the DTS it was passed all the way from FSBL to BBL to kernel. > > > I don't think Linux is to be blamed for this case. They have a policy > > to maintain the the backward compatibility for the DT land. The issue > > what you were facing here is an out of tree DTB (the vendors') is > > incompatible with the kernel's. Once the kernel accepts a DTS, > > bringing in any out-of-tree DT with changes reviewed to in-tree, > > future compatibility will be assured. > > Isn't the reason that the DTS accepted by the kernel is different from > the out-of-tree vendor one that the review process caused changes in > the DTS then? It seems unlikely that the vendor (SiFive) would > deliberately submit an incompatible DTS for inclusion... Well, that's the normal upstream process we have to live with. It's nothing to do with whether that's a DT change, or a feature design change. No one can guarantee an out-of-tree implementation will be keeping compatible after it's accepted in-tree. Reviewers/maintainers may have different view from the author on what's the best to be included in the kernel mainline and this may require the author to change the implementation and break something ... Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] env: Add CONFIG_ENV_SUPPORT
On Tue, Sep 10, 2019 at 11:01:18AM +, Patrick DELAUNAY wrote:
> Hi,
>
> > From: Wolfgang Denk
> > Sent: samedi 7 septembre 2019 13:52
> >
> > Dear Patrick,
> >
> > In message <1567530547-14331-1-git-send-email-patrick.delau...@st.com> you
> > wrote:
> > > Add a new flag CONFIG_ENV_SUPPORT to compile all the environment
> > > features in U-Boot (attributes, callbacks and flags). It is the
> > > equivalent of the 2 existing flags
> >
> > I think this is a bda name, as it is misleading. It sounds as if it is
> > used to enable
> > the support of environment vaiables at all, which it does not - instead it
> > only
> > enables / disables a few specific extended features. This must be
> > reflected in the
> > name.
>
> Yes, I use the name than SPL/TPL to use the macro CONFIG_IS_ENABLED(...)
>
> And I agree the name seens not perfect.
>
> > > - CONFIG_SPL_ENV_SUPPORT for SPL
> > > - CONFIG_TPL_ENV_SUPPORT for TPL
>
> These pre-existing name are defined in common/spl/Kconfig
>
> With the same issue (env/common.o env/env.o are always compiled for SPL/TPL
> so it is alo bad names)
>
> > This scares me. Why are there different settings for SPL, TPL and U-Boot
> > proper? This looks conceptually broken to me - if a system is configured
> > to use a
> > specific set of environment features and extensions, then the exact same
> > settings
> > must be use in all of SPL, TPL and U-Boot proper.
> >
> > I understand that it may be desirable for example to reduce the size of the
> > SPL by
> > omitting some environment extensions, but provide these in U-Boot proper,
> > but
> > this is broken and dangerous. For example, U-Boot flags are often used to
> > enforce a certain level of security (say, by making environment variables
> > read-
> > only or such).
>
> I agree, that scare me also.
> For me also ENV_SUPPORT should be always enable for U-Boot.
>
> My preferred proposal was only to solve the regression introduced by my
> initial patch and
> always set change_ok for U-Boot proper (when CONFIG_SPL_BUILD is not defined):
>
> struct hsearch_data env_htab = {
> - #if CONFIG_IS_ENABLED(ENV_SUPPORT)
> -/* defined in flags.c, only compile with ENV_SUPPORT */
> +#if !defined(CONFIG_SPL_BUILD) || CONFIG_IS_ENABLED(ENV_SUPPORT)
> +/* defined in flags.c, only compile with ENV_SUPPORT for SPL / TPL */
> .change_ok = env_flags_validate,
> #endif
> };
>
> http://u-boot.10912.n7.nabble.com/U-Boot-Environment-flags-broken-for-U-Boot-tt382673.html#a382688
>
> The same test is already done in:
>
> drivers/reset/reset-socfpga.c:47:#if !defined(CONFIG_SPL_BUILD) ||
> CONFIG_IS_ENABLED(ENV_SUPPORT)
> drivers/input/input.c:656:#if !defined(CONFIG_SPL_BUILD) ||
> CONFIG_IS_ENABLED(ENV_SUPPORT)
>
> > The same level of handling and protection must also be maintained in SPL and
> > TPL.
>
> if I understood correctly the proposed dependency is :
> TPL ENV_SUPPORT select SPL_ENV_SUPPORT
> SPL ENV_SUPPORT select ENV_SUPPORT
>
> > So please reconsider this whole implementation, and make sure that only a
> > single
> > macro ise used everywhere to enable these features.
>
> But, if I use the same CONFIG for the 3 binary SPL,TPL and U-Boot,
> l increase the size of TPL/SPL for all the platforms when these additional
> features are not needed.
>
> And I am not the sure of the correct dependency for ENV between binary.
>
> Heiko what is you feedback on Wolfgang remarks
>
> Do you think that I need to come back to the first/simple proposal ?
My two cents is that I would like to see a regression fix "soon" and for
this release, and some corrections / updates to names, what is/isn't
possible to enable (keeping in mind what is desirable to allow) for the
next release. Thanks all!
--
Tom
signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] U-Boot: Environment flags broken for U-Boot
On Tue, Sep 10, 2019 at 7:54 AM Tom Rini wrote: > > On Tue, Sep 10, 2019 at 10:29:04AM +0200, Wolfgang Denk wrote: > > Dear Tom, > > > > In message <20190909210130.GU6927@bill-the-cat> you wrote: > > > > > > On Wed, Sep 04, 2019 at 01:30:02PM -0500, Joe Hershberger wrote: > > ... > > > > I would gladly volunteer for this role if Wolfgang would co-maintain > > > > to keep me in line. He seems to have an uncanny ability to keep all > > > > the cases in his head. > > > > > > Wolfgang, what do you say? It's certainly an area we could use a > > > custodian in. > > > > I would be happy if someone takes care of this - thanks, Hoe for > > volunteering! > > > > As for co-maintaining: for the last 7 years my available time has > > always been considerably smaller than my interest in U-Boot, and it > > would be not realistic to believe this would be changing any time > > soon, sic! > > > > Yes, I'm willing, but I cant guarrantee any bandwidth nor response > > times. I can just try... > > OK, thanks guys. If I know who to poke when they aren't on CC, I can > refrain from pulling things that haven't been checked out yet. Can one > of you please post a patch to update MAINTAINERS to grab env/ tools/env/ > and the env include files so get_maintainers.pl will know too? Thanks! Sure... I'll send a patch later today. -Joe ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v4 0/1] imx: support i.MX8QM ROM 7720 a1 board
On 10/09/19, Peng Fan wrote: > > Subject: [PATCH v4 0/1] imx: support i.MX8QM ROM 7720 a1 board > > > > Hello list, > > > > need some information howto avoid the imx-mkimage repo and create full > > boostream directly from u-boot with all the binary blobs. > > Try the diff, and see whether it helps. > diff --git a/arch/arm/mach-imx/Makefile b/arch/arm/mach-imx/Makefile > index 08ee52edbf..4d0f0970df 100644 > --- a/arch/arm/mach-imx/Makefile > +++ b/arch/arm/mach-imx/Makefile > @@ -159,10 +159,8 @@ MKIMAGEFLAGS_flash.bin = -n spl/u-boot-spl.cfgout -T > $(IMAGE_TYPE) -e 0x10 > flash.bin: MKIMAGEOUTPUT = flash.log > > flash.bin: spl/u-boot-spl.bin u-boot.itb FORCE > -ifeq ($(SPL_DEPFILE_EXISTS),0) > $(call if_changed,mkimage) > endif > -endif > > else > MKIMAGEFLAGS_SPL = -n $(filter-out $(PLUGIN).bin $< $(PHONY),$^) \ You are right, with that proposal and some minor fixes in my patch I can build an full bootstream with all the needed binary blobs. So I can drop imx-mkimage now. Thank you, Oliver ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] U-Boot: Environment flags broken for U-Boot
On Tue, Sep 10, 2019 at 10:29:04AM +0200, Wolfgang Denk wrote: > Dear Tom, > > In message <20190909210130.GU6927@bill-the-cat> you wrote: > > > > On Wed, Sep 04, 2019 at 01:30:02PM -0500, Joe Hershberger wrote: > ... > > > I would gladly volunteer for this role if Wolfgang would co-maintain > > > to keep me in line. He seems to have an uncanny ability to keep all > > > the cases in his head. > > > > Wolfgang, what do you say? It's certainly an area we could use a > > custodian in. > > I would be happy if someone takes care of this - thanks, Hoe for > volunteering! > > As for co-maintaining: for the last 7 years my available time has > always been considerably smaller than my interest in U-Boot, and it > would be not realistic to believe this would be changing any time > soon, sic! > > Yes, I'm willing, but I cant guarrantee any bandwidth nor response > times. I can just try... OK, thanks guys. If I know who to poke when they aren't on CC, I can refrain from pulling things that haven't been checked out yet. Can one of you please post a patch to update MAINTAINERS to grab env/ tools/env/ and the env include files so get_maintainers.pl will know too? 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] Please pull u-boot-x86
Hi Tom, This PR includes the following x86 changes for v2019.10: - Tangier ACPI table fixes - Support getting high memory size on QEMU x86 - Show UEFI images involved in crash for x86 - EFI loader conventional memory map fix The following changes since commit c705fc3b40b88bfbf465448643c91da71426df2f: arm: ti: Add missing "=" from previous fix (2019-09-09 10:55:45 -0400) are available in the git repository at: https://gitlab.denx.de/u-boot/custodians/u-boot-x86 for you to fetch changes up to dd4faa964f0741c314b4f1c09f27c07aedc5cdf0: x86: tangier: Use spaces over TABs in ASL code (2019-09-10 16:19:03 +0800) Andy Shevchenko (6): tools: Add ifwitool to .gitignore x86: acpi: Slightly reduce binary size of ACPI tables for Tangier x86: acpi: Annotate struct acpi_table_header with __packed x86: tangier: Reserve PCI ECAM in motherboard resources x86: tangier: Fix off-by-one error when preparing CSRT x86: tangier: Use spaces over TABs in ASL code Bin Meng (4): x86: Drop weak version board_get_usable_ram_top() x86: qemu: Extract getting memory size to a separate routine x86: qemu: Support getting high memory size x86: qemu: Report high memory in the E820 table Heinrich Schuchardt (1): x86: show UEFI images involved in crash Park, Aiden (2): doc: slimbootloader: Update Linux booting steps on QEMU x86: efi_loader: Use efi_add_conventional_memory_map() arch/x86/cpu/i386/interrupt.c | 14 ++ arch/x86/cpu/qemu/dram.c| 36 arch/x86/cpu/qemu/e820.c| 59 --- arch/x86/cpu/tangier/acpi.c | 5 +++-- arch/x86/include/asm/acpi_table.h | 2 +- arch/x86/include/asm/arch-qemu/qemu.h | 18 ++ arch/x86/include/asm/arch-tangier/acpi/platform.asl | 3 ++- arch/x86/include/asm/arch-tangier/acpi/southcluster.asl | 47 --- arch/x86/include/asm/arch-tangier/iomap.h | 10 ++ arch/x86/lib/e820.c | 17 ++--- arch/x86/lib/init_helpers.c | 6 -- doc/board/intel/slimbootloader.rst | 22 ++ tools/.gitignore| 1 + 13 files changed, 189 insertions(+), 51 deletions(-) create mode 100644 arch/x86/include/asm/arch-tangier/iomap.h Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 5/5] imx: add i.MX6ULZ board
Hi Peng, Hi Fabio, On 06.09.19 09:43, Peng Fan wrote: Subject: Re: [U-Boot] [PATCH v2 5/5] imx: add i.MX6ULZ board Hi Stefan, On Thu, Sep 5, 2019 at 5:59 AM Stefan Roese wrote: a) Why is SPL not used in the mainline i.MX6ULL/ULZ port? The i.MX6UL (14x14) does use SPL. Yes, I think it could SPL as well. Maybe Peng can comment. NXP vendor tree not support SPL, so when I upstream the code, SPL was not included. I see. Thanks for the update here. I might work on SPL support, if this seems necessary for my custom i.MX6ULZ board. I do have another question though. I'm currently testing QSPI booting on the i.MX6ULL EVK. And this does not work 100% reliably. Sometimes the board boots after programming of the IMX image to 0x1000 in QSPI NOR to the U-Boot prompt. And sometimes I see no output at all. I do have the QSPI binary programmed at 0x400. BTW, these binaries boot all just fine when booted via the "imx_usb" loader. Only when booted directly from QSPI (DIP switches) it fails sometimes. Is this a known problem? Do you have a reference U-Boot binary for QSPI booting for the i.MX6ULL EVK? Best would be including the QSPI header (offset 0x400). Thanks, Stefan ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Regressions in MTD / SPI FLASH
Hi Eugeniy, One more request: I am trying to find a better way to identify parts that don't support 4byte addressing. Could you enable CONFIG_SPI_FLASH_SFDP_SUPPORT and also enable debug prints in spi_mem_exec_op() (in drivers/spi/spi-mem.c like before) and provide logs? Just logs of "sf probe" should be sufficient. Regards Vignesh On 10/09/19 5:24 PM, Vignesh Raghavendra wrote: > > > On 10/09/19 5:11 PM, Eugeniy Paltsev wrote: >> Hi Vignesh, >> >> that patch helps - both erase and write works fine. >> > > Thanks for testing! I will cleanup the patches and send formal patches > to the list with your tested by. > > Regards > Vignesh > >> For n25q512ax3: >> Tested-by: "Eugeniy Paltsev " >> >> --- >> Eugeniy Paltsev >> >> >> >> From: Vignesh Raghavendra >> Sent: Tuesday, September 10, 2019 08:07 >> To: Eugeniy Paltsev; Jagan Teki >> Cc: u-boot@lists.denx.de; uboot-snps-...@synopsys.com; Alexey Brodkin; >> tr...@konsulko.com >> Subject: Re: Regressions in MTD / SPI FLASH >> >> Hi, >> >> On 10/09/19 12:18 AM, Eugeniy Paltsev wrote: >>> Hi! >>> Comments are inlined: >>> On 04/09/19 11:37 PM, Eugeniy Paltsev wrote: > We faced with regressions caused by > commit c4e8862308d4 (mtd: spi: Switch to new SPI NOR framework) > This switch was performed by removing entire u-boot spi-flash > core implementation and copying it from another project. > However the switch is performed without proper testing and > investigations about fixes/improvements were made in u-boot > spi-flash core. This results in regressions. > Apologies for the trouble... As stated in cover letter, this change was necessary as U-Boot SPI flash stack at that time did not features such as 4 byte addressing, SFDP parsing, SPI controllers with MMIO interfaces etc. Also there was need to move to SPI MEM framework to support both SPI NAND and SPI NOR flashes using a single SPI controller drivers. I have to disagree on the part that there was no proper testing... As evident from mailing list archives, patch series was reviewed by multiple reviewers and tested on their platforms as well... Unfortunately its impossible to get all boards owners to test it. >>> >>> I'm not talking about getting all customers board and testing changes on >>> them. >>> It could be done another way - i.e. like it is done for u-boot driver-model >>> migration: >>> by introducing the option for choosing which stack will be used and allow >>> customers >>> to switch the flash IC they use to new stack until some deadline. >>> >> >> I did start off with this. But maintaining two stacks is too cumbersome >> and adds to code size (which is a big factor for SPL stage) >> >> > One of regression we faced with is related to SST26 flash series which > is used on HSDK board. The cause is that SST26 protection ops > implementation was dropped. The fix of this regression is send > as a patch in this series. > I retained most U-Boot specific code as is (like support for BANK address registers, restriction in transfer sizes) but I somehow overlooked this part. Sorry for that > However there are another regressions. I.E: we also faced with broken > SPI flash on another SNPS boards - AXS101 and AXS103. They use different > flash IC (n25q512ax3) and I didn't investigate the cause yet. > Could you provide more details here: What exactly fails? Is the detected correctly? Does reads work fine? Is Erase or Write broken? >>> >>> It seems to me that something is wrong with protection ops. >>> The erase and write finish without errors however nothing actually happens. >>> >> >> I doubt so, because if the blocks were protected, erase/write would have >> failed >> and Read status/Read flag status register should have reported error values. >> Anyways, I guess I found a wrt how 4 Byte addressing is handled wrt n25q512* >> series. >> >> Could you try with below patch helps[1]? >> If not please provide logs similar what you have provide now. >> >> If below patch does not help, then please try enabling CONFIG_SPI_FLASH_BAR >> and see if that helps. >> >> [1] >> >> ---8<- >> >> From 1de4c447cd4b2590c98f9ceccf8ed32029b42d36 Mon Sep 17 00:00:00 2001 >> From: Vignesh Raghavendra >> Date: Tue, 10 Sep 2019 10:25:17 +0530 >> Subject: [TST PATCH] mtd: spi: spi-nor-ids: Disable SPI_NOR_4B_OPCODES >> >> Not all variants of n25q256* and n25q512* support 4 Byte stateless >> addressing and there is no easy way to discover this at runtime. >> Therefore don't set SPI_NOR_4B_OPCODES for these flashes >> >> Signed-off-by: Vignesh Raghavendra >> --- >> drivers/mtd/spi/spi-nor-ids.c | 10 -- >> 1 file changed, 4 insertions(+), 6 deletions(-) >> >> diff --git a/drivers/mtd/spi/spi-nor-ids.c b/drivers/mtd/spi/spi-nor-ids.c >> index a3920ba520e0..66ac3256e8f5 100644 >> --- a/drivers/mtd/sp
Re: [U-Boot] Regressions in MTD / SPI FLASH
On 10/09/19 5:11 PM, Eugeniy Paltsev wrote:
> Hi Vignesh,
>
> that patch helps - both erase and write works fine.
>
Thanks for testing! I will cleanup the patches and send formal patches
to the list with your tested by.
Regards
Vignesh
> For n25q512ax3:
> Tested-by: "Eugeniy Paltsev "
>
> ---
> Eugeniy Paltsev
>
>
>
> From: Vignesh Raghavendra
> Sent: Tuesday, September 10, 2019 08:07
> To: Eugeniy Paltsev; Jagan Teki
> Cc: u-boot@lists.denx.de; uboot-snps-...@synopsys.com; Alexey Brodkin;
> tr...@konsulko.com
> Subject: Re: Regressions in MTD / SPI FLASH
>
> Hi,
>
> On 10/09/19 12:18 AM, Eugeniy Paltsev wrote:
>> Hi!
>> Comments are inlined:
>>
>>> On 04/09/19 11:37 PM, Eugeniy Paltsev wrote:
We faced with regressions caused by
commit c4e8862308d4 (mtd: spi: Switch to new SPI NOR framework)
This switch was performed by removing entire u-boot spi-flash
core implementation and copying it from another project.
However the switch is performed without proper testing and
investigations about fixes/improvements were made in u-boot
spi-flash core. This results in regressions.
>>>
>>> Apologies for the trouble...
>>> As stated in cover letter, this change was necessary as U-Boot SPI flash
>>> stack at that time did not features such as 4 byte addressing, SFDP
>>> parsing, SPI controllers with MMIO interfaces etc. Also there was need
>>> to move to SPI MEM framework to support both SPI NAND and SPI NOR
>>> flashes using a single SPI controller drivers.
>>> I have to disagree on the part that there was no proper testing... As
>>> evident from mailing list archives, patch series was reviewed by
>>> multiple reviewers and tested on their platforms as well...
>>> Unfortunately its impossible to get all boards owners to test it.
>>
>> I'm not talking about getting all customers board and testing changes on
>> them.
>> It could be done another way - i.e. like it is done for u-boot driver-model
>> migration:
>> by introducing the option for choosing which stack will be used and allow
>> customers
>> to switch the flash IC they use to new stack until some deadline.
>>
>
> I did start off with this. But maintaining two stacks is too cumbersome
> and adds to code size (which is a big factor for SPL stage)
>
>
One of regression we faced with is related to SST26 flash series which
is used on HSDK board. The cause is that SST26 protection ops
implementation was dropped. The fix of this regression is send
as a patch in this series.
>>>
>>> I retained most U-Boot specific code as is (like support for BANK
>>> address registers, restriction in transfer sizes) but I somehow
>>> overlooked this part. Sorry for that
>>>
However there are another regressions. I.E: we also faced with broken
SPI flash on another SNPS boards - AXS101 and AXS103. They use different
flash IC (n25q512ax3) and I didn't investigate the cause yet.
>>>
>>> Could you provide more details here:
>>> What exactly fails? Is the detected correctly? Does reads work fine? Is
>>> Erase or Write broken?
>>
>> It seems to me that something is wrong with protection ops.
>> The erase and write finish without errors however nothing actually happens.
>>
>
> I doubt so, because if the blocks were protected, erase/write would have
> failed
> and Read status/Read flag status register should have reported error values.
> Anyways, I guess I found a wrt how 4 Byte addressing is handled wrt n25q512*
> series.
>
> Could you try with below patch helps[1]?
> If not please provide logs similar what you have provide now.
>
> If below patch does not help, then please try enabling CONFIG_SPI_FLASH_BAR
> and see if that helps.
>
> [1]
>
> ---8<-
>
> From 1de4c447cd4b2590c98f9ceccf8ed32029b42d36 Mon Sep 17 00:00:00 2001
> From: Vignesh Raghavendra
> Date: Tue, 10 Sep 2019 10:25:17 +0530
> Subject: [TST PATCH] mtd: spi: spi-nor-ids: Disable SPI_NOR_4B_OPCODES
>
> Not all variants of n25q256* and n25q512* support 4 Byte stateless
> addressing and there is no easy way to discover this at runtime.
> Therefore don't set SPI_NOR_4B_OPCODES for these flashes
>
> Signed-off-by: Vignesh Raghavendra
> ---
> drivers/mtd/spi/spi-nor-ids.c | 10 --
> 1 file changed, 4 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/mtd/spi/spi-nor-ids.c b/drivers/mtd/spi/spi-nor-ids.c
> index a3920ba520e0..66ac3256e8f5 100644
> --- a/drivers/mtd/spi/spi-nor-ids.c
> +++ b/drivers/mtd/spi/spi-nor-ids.c
> @@ -161,12 +161,10 @@ const struct flash_info spi_nor_ids[] = {
> { INFO("n25q064a",0x20bb17, 0, 64 * 1024, 128, SECT_4K |
> SPI_NOR_QUAD_READ) },
> { INFO("n25q128a11", 0x20bb18, 0, 64 * 1024, 256, SECT_4K |
> SPI_NOR_QUAD_READ) },
> { INFO("n25q128a13", 0x20ba18, 0, 64 * 1024, 256, SECT_4K |
> SPI_NOR_QUAD_READ) },
> - { INFO("n25q256a",0x20ba19, 0, 64 * 1024, 512, SECT_4K |
> SPI_NOR_DUAL_READ
Re: [U-Boot] Regressions in MTD / SPI FLASH
Hi Vignesh,
that patch helps - both erase and write works fine.
For n25q512ax3:
Tested-by: "Eugeniy Paltsev "
---
Eugeniy Paltsev
From: Vignesh Raghavendra
Sent: Tuesday, September 10, 2019 08:07
To: Eugeniy Paltsev; Jagan Teki
Cc: u-boot@lists.denx.de; uboot-snps-...@synopsys.com; Alexey Brodkin;
tr...@konsulko.com
Subject: Re: Regressions in MTD / SPI FLASH
Hi,
On 10/09/19 12:18 AM, Eugeniy Paltsev wrote:
> Hi!
> Comments are inlined:
>
>> On 04/09/19 11:37 PM, Eugeniy Paltsev wrote:
>>> We faced with regressions caused by
>>> commit c4e8862308d4 (mtd: spi: Switch to new SPI NOR framework)
>>> This switch was performed by removing entire u-boot spi-flash
>>> core implementation and copying it from another project.
>>> However the switch is performed without proper testing and
>>> investigations about fixes/improvements were made in u-boot
>>> spi-flash core. This results in regressions.
>>>
>>
>> Apologies for the trouble...
>> As stated in cover letter, this change was necessary as U-Boot SPI flash
>> stack at that time did not features such as 4 byte addressing, SFDP
>> parsing, SPI controllers with MMIO interfaces etc. Also there was need
>> to move to SPI MEM framework to support both SPI NAND and SPI NOR
>> flashes using a single SPI controller drivers.
>> I have to disagree on the part that there was no proper testing... As
>> evident from mailing list archives, patch series was reviewed by
>> multiple reviewers and tested on their platforms as well...
>> Unfortunately its impossible to get all boards owners to test it.
>
> I'm not talking about getting all customers board and testing changes on them.
> It could be done another way - i.e. like it is done for u-boot driver-model
> migration:
> by introducing the option for choosing which stack will be used and allow
> customers
> to switch the flash IC they use to new stack until some deadline.
>
I did start off with this. But maintaining two stacks is too cumbersome
and adds to code size (which is a big factor for SPL stage)
>>> One of regression we faced with is related to SST26 flash series which
>>> is used on HSDK board. The cause is that SST26 protection ops
>>> implementation was dropped. The fix of this regression is send
>>> as a patch in this series.
>>>
>>
>> I retained most U-Boot specific code as is (like support for BANK
>> address registers, restriction in transfer sizes) but I somehow
>> overlooked this part. Sorry for that
>>
>>> However there are another regressions. I.E: we also faced with broken
>>> SPI flash on another SNPS boards - AXS101 and AXS103. They use different
>>> flash IC (n25q512ax3) and I didn't investigate the cause yet.
>>>
>>
>> Could you provide more details here:
>> What exactly fails? Is the detected correctly? Does reads work fine? Is
>> Erase or Write broken?
>
> It seems to me that something is wrong with protection ops.
> The erase and write finish without errors however nothing actually happens.
>
I doubt so, because if the blocks were protected, erase/write would have failed
and Read status/Read flag status register should have reported error values.
Anyways, I guess I found a wrt how 4 Byte addressing is handled wrt n25q512*
series.
Could you try with below patch helps[1]?
If not please provide logs similar what you have provide now.
If below patch does not help, then please try enabling CONFIG_SPI_FLASH_BAR and
see if that helps.
[1]
---8<-
From 1de4c447cd4b2590c98f9ceccf8ed32029b42d36 Mon Sep 17 00:00:00 2001
From: Vignesh Raghavendra
Date: Tue, 10 Sep 2019 10:25:17 +0530
Subject: [TST PATCH] mtd: spi: spi-nor-ids: Disable SPI_NOR_4B_OPCODES
Not all variants of n25q256* and n25q512* support 4 Byte stateless
addressing and there is no easy way to discover this at runtime.
Therefore don't set SPI_NOR_4B_OPCODES for these flashes
Signed-off-by: Vignesh Raghavendra
---
drivers/mtd/spi/spi-nor-ids.c | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/drivers/mtd/spi/spi-nor-ids.c b/drivers/mtd/spi/spi-nor-ids.c
index a3920ba520e0..66ac3256e8f5 100644
--- a/drivers/mtd/spi/spi-nor-ids.c
+++ b/drivers/mtd/spi/spi-nor-ids.c
@@ -161,12 +161,10 @@ const struct flash_info spi_nor_ids[] = {
{ INFO("n25q064a",0x20bb17, 0, 64 * 1024, 128, SECT_4K |
SPI_NOR_QUAD_READ) },
{ INFO("n25q128a11", 0x20bb18, 0, 64 * 1024, 256, SECT_4K |
SPI_NOR_QUAD_READ) },
{ INFO("n25q128a13", 0x20ba18, 0, 64 * 1024, 256, SECT_4K |
SPI_NOR_QUAD_READ) },
- { INFO("n25q256a",0x20ba19, 0, 64 * 1024, 512, SECT_4K |
SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_4B_OPCODES) },
- { INFO("n25q256ax1", 0x20bb19, 0, 64 * 1024, 512, SECT_4K |
SPI_NOR_QUAD_READ | SPI_NOR_4B_OPCODES) },
- { INFO6("mt25qu512a", 0x20bb20, 0x104400, 64 * 1024, 1024,
-SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_4B_OPCODES) },
- { INFO("n25q512a",0x20bb20, 0, 64 * 1024, 1024, SE
Re: [U-Boot] [PATCH v2] regulator: fixed: Modify enable-active-high behavior
Hi,
It's a gentle reminder to not forgot this patch.
Thanks
Patrice
On 8/26/19 1:50 PM, Patrice Chotard wrote:
> Regulator should not be enabled at probe time if regulator-boot-on
> property is not in the dt node.
>
> "enable-active-high" property is only used to indicate the GPIO
> polarity.
>
> See kernel documentation :
> - Documentation/devicetree/bindings/regulator/fixed-regulator.yaml
> - Documentation/devicetree/bindings/regulator/gpio-regulator.yaml
>
> Signed-off-by: Christophe Kerello
> Signed-off-by: Patrice Chotard
> ---
>
> Changes in v2:
> - fix build issue
>
> drivers/power/regulator/regulator_common.c | 7 ++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/power/regulator/regulator_common.c
> b/drivers/power/regulator/regulator_common.c
> index 3dabbe2a85..2041086567 100644
> --- a/drivers/power/regulator/regulator_common.c
> +++ b/drivers/power/regulator/regulator_common.c
> @@ -12,10 +12,15 @@ int regulator_common_ofdata_to_platdata(struct udevice
> *dev,
> struct regulator_common_platdata *dev_pdata, const char
> *enable_gpio_name)
> {
> struct gpio_desc *gpio;
> + struct dm_regulator_uclass_platdata *uc_pdata;
> int flags = GPIOD_IS_OUT;
> int ret;
>
> - if (dev_read_bool(dev, "enable-active-high"))
> + uc_pdata = dev_get_uclass_platdata(dev);
> +
> + if (!dev_read_bool(dev, "enable-active-high"))
> + flags |= GPIOD_ACTIVE_LOW;
> + if (uc_pdata->boot_on)
> flags |= GPIOD_IS_OUT_ACTIVE;
>
> /* Get optional enable GPIO desc */
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] regulator: fixed: Modify enable-active-high behavior
Sorry it's not the correct patch version. I will send the reminder on the correct one (v2). Patrice On 9/10/19 11:54 AM, Patrice CHOTARD wrote: > Hi, > > It's a gentle reminder to not forgot this patch > > Thanks > > Patrice > > On 7/25/19 9:12 AM, Patrice Chotard wrote: >> Regulator should not be enabled at probe time if regulator-boot-on >> property is not in the dt node. >> >> "enable-active-high" property is only used to indicate the GPIO >> polarity. >> >> See kernel documentation : >> - Documentation/devicetree/bindings/regulator/fixed-regulator.yaml >> - Documentation/devicetree/bindings/regulator/gpio-regulator.yaml >> >> Signed-off-by: Christophe Kerello >> Signed-off-by: Patrice Chotard >> --- >> >> drivers/power/regulator/regulator_common.c | 4 +++- >> 1 file changed, 3 insertions(+), 1 deletion(-) >> >> diff --git a/drivers/power/regulator/regulator_common.c >> b/drivers/power/regulator/regulator_common.c >> index 3dabbe2a85..2e8a083c75 100644 >> --- a/drivers/power/regulator/regulator_common.c >> +++ b/drivers/power/regulator/regulator_common.c >> @@ -15,7 +15,9 @@ int regulator_common_ofdata_to_platdata(struct udevice >> *dev, >> int flags = GPIOD_IS_OUT; >> int ret; >> >> -if (dev_read_bool(dev, "enable-active-high")) >> +if (!dev_read_bool(dev, "enable-active-high")) >> +flags |= GPIOD_ACTIVE_LOW; >> +if (uc_pdata->boot_on) >> flags |= GPIOD_IS_OUT_ACTIVE; >> >> /* Get optional enable GPIO desc */ ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PULL u-boot] Please pull u-boot-amlogic-20190910
Hi Tom, This PR simply adds support for dis_u2_susphy_quirk in the xhci-dwc3 driver to fix boot when a device is plugged only in the OTG capable port for libretech-ac and libretech-cc. Bin acked me for pushing this fix through my tree. The CI job is at https://gitlab.denx.de/u-boot/custodians/u-boot-amlogic/pipelines/642 Thanks, Neil The following changes since commit c705fc3b40b88bfbf465448643c91da71426df2f: arm: ti: Add missing "=" from previous fix (2019-09-09 10:55:45 -0400) are available in the Git repository at: https://gitlab.denx.de/u-boot/custodians/u-boot-amlogic.git tags/u-boot-amlogic-20190910 for you to fetch changes up to b35b8076828d1059c1fcc648ed8c8210ebe6a3dd: usb: xhci-dwc3: Add support for dis_u2_susphy_quirk (2019-09-10 10:00:53 +0200) - Add support for dis_u2_susphy_quirk in the xhci-dwc3 driver to fix boot when a device is plugged only in the OTG capable port for libretech-ac and libretech-cc Neil Armstrong (1): usb: xhci-dwc3: Add support for dis_u2_susphy_quirk drivers/usb/host/xhci-dwc3.c | 3 +++ 1 file changed, 3 insertions(+) ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v4] imx: Add support for i.MX28 based XEA board
From: Mans Rullgard
This patch introduces support for i.MX28 based XEA board.
This board supports DM/DTS in U-Boot proper as well as DM aware drivers
in SPL (u-boot.sb).
More detailed information regarding usage of it can be found in
./board/liebherr/xea/README file.
U-Boot SPL 2019.10-rc1-00233-g6aa549f05c (Aug 12 2019 - 09:23:36 +0200)
Trying to boot from MMC1
MMC0: Command 8 timeout (status 0xf0344020)
mmc_load_image_raw_sector: mmc block read error
U-Boot 2019.10-rc1-00233-g6aa549f05c (Aug 12 2019 - 09:23:36 +0200)
CPU: Freescale i.MX28 rev1.2 at 454 MHz
BOOT: SSP SPI #3, master, 3V3 NOR
Model: Liebherr (LWE) XEA i.MX28 Board
DRAM: 128 MiB
MMC: MXS MMC: 0
Loading Environment from SPI Flash... SF: Detected n25q128a13 with page size
256 Bytes, erase size 64 KiB, total 16 MiB
OK
In:serial
Out: serial
Err: serial
Net:
Warning: ethernet@800f (eth0) using random MAC address - ce:e1:9e:46:f3:a2
eth0: ethernet@800f
Hit any key to stop autoboot: 0
Signed-off-by: Mans Rullgard
Signed-off-by: Lukasz Majewski
---
Changes in v4:
- Remove non needed imx28_xea_defconfig defines after introducing
SPL_DM_SPI
- Update dependencies list after introducing SPL_DM_SPI
- Fix problem with 'mtd' command
Changes in v3:
- Use Kconfig defined option (CONFIG_FS_EXT4) instead of the one defined
in xea.h
- Use Kconfig defined option (CONFIG_SYS_SPI_U_BOOT_OFFS) instead of the one
defined in xea.h
- Provide correct SDPX header for xea.h
Changes in v2:
- Adjust config to match dependent patches
- Increase malloc size to allow booting the board with GPIO DM/DTS support
- Add support for GPIO driver in SPL (with DM + OF_PLATDATA)
- Adjust spl_xea.c to support bootmode pins
- Add patches to set in Kconfig default boot HW partition for eMMC
Dependencies:
- Patch to introduce SPL_DM_SPI Kconfig option:
https://patchwork.ozlabs.org/patch/1159655/
- Fixes/conversion for i.MX28 spi, emmc and gpio (the whole series 1-7):
https://patchwork.ozlabs.org/cover/1158255/
Applied on top of -master branch:
SHA1: c705fc3b40b88bfbf465448643c91da71426df2f
---
arch/arm/dts/Makefile | 3 +
arch/arm/dts/imx28-xea-u-boot.dtsi | 46 ++
arch/arm/dts/imx28-xea.dts | 110 ++
arch/arm/mach-imx/mxs/Kconfig | 4 +
board/liebherr/xea/Kconfig | 24 +++
board/liebherr/xea/MAINTAINERS | 6 +
board/liebherr/xea/Makefile| 12 ++
board/liebherr/xea/README | 63
board/liebherr/xea/spl_xea.c | 303 +
board/liebherr/xea/xea.c | 152 +++
configs/imx28_xea_defconfig| 108 +
include/configs/xea.h | 196
12 files changed, 1027 insertions(+)
create mode 100644 arch/arm/dts/imx28-xea-u-boot.dtsi
create mode 100644 arch/arm/dts/imx28-xea.dts
create mode 100644 board/liebherr/xea/Kconfig
create mode 100644 board/liebherr/xea/MAINTAINERS
create mode 100644 board/liebherr/xea/Makefile
create mode 100644 board/liebherr/xea/README
create mode 100644 board/liebherr/xea/spl_xea.c
create mode 100644 board/liebherr/xea/xea.c
create mode 100644 configs/imx28_xea_defconfig
create mode 100644 include/configs/xea.h
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index aac1b83d49..82a0379c13 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -547,6 +547,9 @@ dtb-$(CONFIG_VF610) += vf500-colibri.dtb \
vf610-pcm052.dtb \
vf610-bk4r1.dtb
+dtb-$(CONFIG_MX28) += \
+ imx28-xea.dtb
+
dtb-$(CONFIG_MX53) += imx53-cx9020.dtb \
imx53-kp.dtb \
imx53-m53menlo.dtb
diff --git a/arch/arm/dts/imx28-xea-u-boot.dtsi
b/arch/arm/dts/imx28-xea-u-boot.dtsi
new file mode 100644
index 00..cc2ced5d2d
--- /dev/null
+++ b/arch/arm/dts/imx28-xea-u-boot.dtsi
@@ -0,0 +1,46 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright 2019
+ * Lukasz Majewski, DENX Software Engineering, lu...@denx.de
+ *
+ * SPDX-License-Identifier: GPL-2.0+ or X11
+ */
+
+/*
+ * The minimal augmentation DTS U-Boot file to allow eMMC driver
+ * configuration in SPL for falcon boot.
+ */
+#include "imx28-u-boot.dtsi"
+/ {
+ apb@8000 {
+ u-boot,dm-spl;
+
+ apbh@8000 {
+ u-boot,dm-spl;
+ };
+
+ apbx@8004 {
+ u-boot,dm-spl;
+ };
+ };
+};
+
+&clks {
+ u-boot,dm-spl;
+};
+
+&gpio0 {
+ u-boot,dm-spl;
+};
+
+&pinctrl {
+ u-boot,dm-spl;
+};
+
+&ssp0 {
+ u-boot,dm-spl;
+};
+
+&ssp3 {
+ u-boot,dm-spl;
+};
diff --git a/arch/arm/dts/imx28-xea.dts b/arch/arm/dts/imx28-xea.dts
new file mode 100644
index 00..5de6774c5a
--- /dev/null
+++ b/arch/arm/dts/imx28-xea.dts
@@ -0,0 +1,110 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright 2019
+ * Lukasz Majewski, DENX Software Engineering, lu...@denx.de
+ *
+ * SPDX-License-Identifier:
Re: [U-Boot] [PATCH] env: Add CONFIG_ENV_SUPPORT
Hi,
> From: Wolfgang Denk
> Sent: samedi 7 septembre 2019 13:52
>
> Dear Patrick,
>
> In message <1567530547-14331-1-git-send-email-patrick.delau...@st.com> you
> wrote:
> > Add a new flag CONFIG_ENV_SUPPORT to compile all the environment
> > features in U-Boot (attributes, callbacks and flags). It is the
> > equivalent of the 2 existing flags
>
> I think this is a bda name, as it is misleading. It sounds as if it is used
> to enable
> the support of environment vaiables at all, which it does not - instead it
> only
> enables / disables a few specific extended features. This must be reflected
> in the
> name.
Yes, I use the name than SPL/TPL to use the macro CONFIG_IS_ENABLED(...)
And I agree the name seens not perfect.
> > - CONFIG_SPL_ENV_SUPPORT for SPL
> > - CONFIG_TPL_ENV_SUPPORT for TPL
These pre-existing name are defined in common/spl/Kconfig
With the same issue (env/common.o env/env.o are always compiled for SPL/TPL
so it is alo bad names)
> This scares me. Why are there different settings for SPL, TPL and U-Boot
> proper? This looks conceptually broken to me - if a system is configured to
> use a
> specific set of environment features and extensions, then the exact same
> settings
> must be use in all of SPL, TPL and U-Boot proper.
>
> I understand that it may be desirable for example to reduce the size of the
> SPL by
> omitting some environment extensions, but provide these in U-Boot proper, but
> this is broken and dangerous. For example, U-Boot flags are often used to
> enforce a certain level of security (say, by making environment variables
> read-
> only or such).
I agree, that scare me also.
For me also ENV_SUPPORT should be always enable for U-Boot.
My preferred proposal was only to solve the regression introduced by my initial
patch and
always set change_ok for U-Boot proper (when CONFIG_SPL_BUILD is not defined):
struct hsearch_data env_htab = {
- #if CONFIG_IS_ENABLED(ENV_SUPPORT)
-/* defined in flags.c, only compile with ENV_SUPPORT */
+#if !defined(CONFIG_SPL_BUILD) || CONFIG_IS_ENABLED(ENV_SUPPORT)
+/* defined in flags.c, only compile with ENV_SUPPORT for SPL / TPL */
.change_ok = env_flags_validate,
#endif
};
http://u-boot.10912.n7.nabble.com/U-Boot-Environment-flags-broken-for-U-Boot-tt382673.html#a382688
The same test is already done in:
drivers/reset/reset-socfpga.c:47:#if !defined(CONFIG_SPL_BUILD) ||
CONFIG_IS_ENABLED(ENV_SUPPORT)
drivers/input/input.c:656:#if !defined(CONFIG_SPL_BUILD) ||
CONFIG_IS_ENABLED(ENV_SUPPORT)
> The same level of handling and protection must also be maintained in SPL and
> TPL.
if I understood correctly the proposed dependency is :
TPL ENV_SUPPORT select SPL_ENV_SUPPORT
SPL ENV_SUPPORT select ENV_SUPPORT
> So please reconsider this whole implementation, and make sure that only a
> single
> macro ise used everywhere to enable these features.
But, if I use the same CONFIG for the 3 binary SPL,TPL and U-Boot,
l increase the size of TPL/SPL for all the platforms when these additional
features are not needed.
And I am not the sure of the correct dependency for ENV between binary.
Heiko what is you feedback on Wolfgang remarks
Do you think that I need to come back to the first/simple proposal ?
>
> Best regards,
>
> Wolfgang Denk
>
> --
Best regards
Patrick Delaunay
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 7/8] power: pmic: rk817: support rk817 pmic
From: Joseph Chen
The RK817 is a Power Management IC (PMIC) for multimedia
and handheld devices. They contains the following components:
- Regulators(4*BUCKs, 1* BOOST, 9*LDOs, 1*SWITCH)
- RTC
- Clocking
Signed-off-by: Joseph Chen
Signed-off-by: Elaine Zhang
---
drivers/power/pmic/rk8xx.c | 100 +++--
drivers/power/regulator/rk8xx.c | 189 +++-
include/power/rk8xx_pmic.h | 31 +++
3 files changed, 308 insertions(+), 12 deletions(-)
diff --git a/drivers/power/pmic/rk8xx.c b/drivers/power/pmic/rk8xx.c
index df2056913ced..0ec6cb31d706 100644
--- a/drivers/power/pmic/rk8xx.c
+++ b/drivers/power/pmic/rk8xx.c
@@ -10,6 +10,13 @@
#include
#include
+static struct reg_data rk817_init_reg[] = {
+/* enable the under-voltage protection,
+ * the under-voltage protection will shutdown the LDO3 and reset the PMIC
+ */
+ { RK817_BUCK4_CMIN, 0x60, 0x60},
+};
+
static const struct pmic_child_info pmic_children_info[] = {
{ .prefix = "DCDC_REG", .driver = "rk8xx_buck"},
{ .prefix = "LDO_REG", .driver = "rk8xx_ldo"},
@@ -52,16 +59,22 @@ static int rk8xx_read(struct udevice *dev, uint reg,
uint8_t *buff, int len)
static int rk8xx_shutdown(struct udevice *dev)
{
struct rk8xx_priv *priv = dev_get_priv(dev);
- u8 val, dev_off;
+ u8 val, dev_off, devctrl_reg;
int ret = 0;
switch (priv->variant) {
case RK808_ID:
+ devctrl_reg = REG_DEVCTRL;
dev_off = BIT(3);
break;
case RK805_ID:
case RK816_ID:
case RK818_ID:
+ devctrl_reg = REG_DEVCTRL;
+ dev_off = BIT(0);
+ break;
+ case RK817_ID:
+ devctrl_reg = RK817_REG_SYS_CFG3;
dev_off = BIT(0);
break;
default:
@@ -69,18 +82,18 @@ static int rk8xx_shutdown(struct udevice *dev)
return -EINVAL;
}
- ret = dm_i2c_read(dev, REG_DEVCTRL, &val, 1);
+ ret = dm_i2c_read(dev, devctrl_reg, &val, 1);
if (ret) {
printf("read error from device: %p register: %#x!",
- dev, REG_DEVCTRL);
+ dev, devctrl_reg);
return ret;
}
val |= dev_off;
- ret = dm_i2c_write(dev, REG_DEVCTRL, &val, 1);
+ ret = dm_i2c_write(dev, devctrl_reg, &val, 1);
if (ret) {
printf("write error to device: %p register: %#x!",
- dev, REG_DEVCTRL);
+ dev, devctrl_reg);
return ret;
}
@@ -114,13 +127,83 @@ static int rk8xx_bind(struct udevice *dev)
static int rk8xx_probe(struct udevice *dev)
{
struct rk8xx_priv *priv = dev_get_priv(dev);
- uint8_t msb, lsb;
+ struct reg_data *init_data = NULL;
+ int init_data_num = 0;
+ int ret = 0, i, show_variant;
+ u8 msb, lsb, id_msb, id_lsb;
+ u8 on_source = 0, off_source = 0;
+ u8 power_en0, power_en1, power_en2, power_en3;
+ u8 value;
/* read Chip variant */
- rk8xx_read(dev, ID_MSB, &msb, 1);
- rk8xx_read(dev, ID_LSB, &lsb, 1);
+ if (device_is_compatible(dev, "rockchip,rk817")) {
+ id_msb = RK817_ID_MSB;
+ id_lsb = RK817_ID_LSB;
+ } else {
+ id_msb = ID_MSB;
+ id_lsb = ID_LSB;
+ }
+
+ ret = rk8xx_read(dev, id_msb, &msb, 1);
+ if (ret)
+ return ret;
+ ret = rk8xx_read(dev, id_lsb, &lsb, 1);
+ if (ret)
+ return ret;
priv->variant = ((msb << 8) | lsb) & RK8XX_ID_MSK;
+ show_variant = priv->variant;
+ switch (priv->variant) {
+ case RK808_ID:
+ show_variant = 0x808; /* RK808 hardware ID is 0 */
+ break;
+ case RK805_ID:
+ case RK816_ID:
+ case RK818_ID:
+ on_source = RK8XX_ON_SOURCE;
+ off_source = RK8XX_OFF_SOURCE;
+ break;
+ case RK817_ID:
+ on_source = RK817_ON_SOURCE;
+ off_source = RK817_OFF_SOURCE;
+ init_data = rk817_init_reg;
+ init_data_num = ARRAY_SIZE(rk817_init_reg);
+ power_en0 = pmic_reg_read(dev, RK817_POWER_EN0);
+ power_en1 = pmic_reg_read(dev, RK817_POWER_EN1);
+ power_en2 = pmic_reg_read(dev, RK817_POWER_EN2);
+ power_en3 = pmic_reg_read(dev, RK817_POWER_EN3);
+
+ value = (power_en0 & 0x0f) | ((power_en1 & 0x0f) << 4);
+ pmic_reg_write(dev, RK817_POWER_EN_SAVE0, value);
+ value = (power_en2 & 0x0f) | ((power_en3 & 0x0f) << 4);
+ pmic_reg_write(dev, RK817_POWER_EN_SAVE1, value);
+ break;
+ default:
+ printf("Unknown PMIC: RK%x!!\n", priv->variant);
+ return -EINVAL;
+ }
+
+ f
[U-Boot] [PATCH v2 6/8] power: pmic: rk8xx: add pmic_shutdown() implement
From: Joseph Chen
Signed-off-by: Joseph Chen
Signed-off-by: Elaine Zhang
---
drivers/power/pmic/rk8xx.c | 39 +++
1 file changed, 39 insertions(+)
diff --git a/drivers/power/pmic/rk8xx.c b/drivers/power/pmic/rk8xx.c
index 00c8a2e091d8..df2056913ced 100644
--- a/drivers/power/pmic/rk8xx.c
+++ b/drivers/power/pmic/rk8xx.c
@@ -49,6 +49,44 @@ static int rk8xx_read(struct udevice *dev, uint reg, uint8_t
*buff, int len)
return 0;
}
+static int rk8xx_shutdown(struct udevice *dev)
+{
+ struct rk8xx_priv *priv = dev_get_priv(dev);
+ u8 val, dev_off;
+ int ret = 0;
+
+ switch (priv->variant) {
+ case RK808_ID:
+ dev_off = BIT(3);
+ break;
+ case RK805_ID:
+ case RK816_ID:
+ case RK818_ID:
+ dev_off = BIT(0);
+ break;
+ default:
+ printf("Unknown PMIC: RK%x\n", priv->variant);
+ return -EINVAL;
+ }
+
+ ret = dm_i2c_read(dev, REG_DEVCTRL, &val, 1);
+ if (ret) {
+ printf("read error from device: %p register: %#x!",
+ dev, REG_DEVCTRL);
+ return ret;
+ }
+
+ val |= dev_off;
+ ret = dm_i2c_write(dev, REG_DEVCTRL, &val, 1);
+ if (ret) {
+ printf("write error to device: %p register: %#x!",
+ dev, REG_DEVCTRL);
+ return ret;
+ }
+
+ return 0;
+}
+
#if CONFIG_IS_ENABLED(PMIC_CHILDREN)
static int rk8xx_bind(struct udevice *dev)
{
@@ -91,6 +129,7 @@ static struct dm_pmic_ops rk8xx_ops = {
.reg_count = rk8xx_reg_count,
.read = rk8xx_read,
.write = rk8xx_write,
+ .shutdown = rk8xx_shutdown,
};
static const struct udevice_id rk8xx_ids[] = {
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 8/8] power: pmic: rk809: support rk809 pmic
From: Joseph Chen
The RK809 is a Power Management IC (PMIC) for multimedia
and handheld devices. They contains the following components:
- Regulators(5*BUCKs, 9*LDOs, 2*SWITCHs)
- RTC
- Clocking
Signed-off-by: Joseph Chen
Signed-off-by: Elaine Zhang
---
drivers/power/pmic/rk8xx.c | 6 +++-
drivers/power/regulator/rk8xx.c | 70 -
include/power/rk8xx_pmic.h | 1 +
3 files changed, 75 insertions(+), 2 deletions(-)
diff --git a/drivers/power/pmic/rk8xx.c b/drivers/power/pmic/rk8xx.c
index 0ec6cb31d706..3e256377079a 100644
--- a/drivers/power/pmic/rk8xx.c
+++ b/drivers/power/pmic/rk8xx.c
@@ -73,6 +73,7 @@ static int rk8xx_shutdown(struct udevice *dev)
devctrl_reg = REG_DEVCTRL;
dev_off = BIT(0);
break;
+ case RK809_ID:
case RK817_ID:
devctrl_reg = RK817_REG_SYS_CFG3;
dev_off = BIT(0);
@@ -136,7 +137,8 @@ static int rk8xx_probe(struct udevice *dev)
u8 value;
/* read Chip variant */
- if (device_is_compatible(dev, "rockchip,rk817")) {
+ if (device_is_compatible(dev, "rockchip,rk817") ||
+ device_is_compatible(dev, "rockchip,rk809")) {
id_msb = RK817_ID_MSB;
id_lsb = RK817_ID_LSB;
} else {
@@ -163,6 +165,7 @@ static int rk8xx_probe(struct udevice *dev)
on_source = RK8XX_ON_SOURCE;
off_source = RK8XX_OFF_SOURCE;
break;
+ case RK809_ID:
case RK817_ID:
on_source = RK817_ON_SOURCE;
off_source = RK817_OFF_SOURCE;
@@ -218,6 +221,7 @@ static struct dm_pmic_ops rk8xx_ops = {
static const struct udevice_id rk8xx_ids[] = {
{ .compatible = "rockchip,rk805" },
{ .compatible = "rockchip,rk808" },
+ { .compatible = "rockchip,rk809" },
{ .compatible = "rockchip,rk816" },
{ .compatible = "rockchip,rk817" },
{ .compatible = "rockchip,rk818" },
diff --git a/drivers/power/regulator/rk8xx.c b/drivers/power/regulator/rk8xx.c
index 3c4a18b0f0c7..194086c6d240 100644
--- a/drivers/power/regulator/rk8xx.c
+++ b/drivers/power/regulator/rk8xx.c
@@ -27,6 +27,10 @@
#define RK808_BUCK4_VSEL_MASK 0xf
#define RK808_LDO_VSEL_MASK0x1f
+/* RK809 BUCK5 */
+#define RK809_BUCK5_CONFIG(n) (0xde + (n) * 1)
+#define RK809_BUCK5_VSEL_MASK 0x07
+
/* RK817 BUCK */
#define RK817_BUCK_ON_VSEL(n) (0xbb + 3 * (n - 1))
#define RK817_BUCK_SLP_VSEL(n) (0xbc + 3 * (n - 1))
@@ -59,6 +63,7 @@
#define RK805_RAMP_RATE_6MV_PER_US (1 << RK805_RAMP_RATE_OFFSET)
#define RK805_RAMP_RATE_12_5MV_PER_US (2 << RK805_RAMP_RATE_OFFSET)
#define RK805_RAMP_RATE_25MV_PER_US(3 << RK805_RAMP_RATE_OFFSET)
+
#define RK808_RAMP_RATE_OFFSET 3
#define RK808_RAMP_RATE_MASK (3 << RK808_RAMP_RATE_OFFSET)
#define RK808_RAMP_RATE_2MV_PER_US (0 << RK808_RAMP_RATE_OFFSET)
@@ -105,6 +110,14 @@ static const struct rk8xx_reg_info rk816_buck[] = {
{ 80, 10, REG_BUCK4_ON_VSEL, REG_BUCK4_SLP_VSEL,
REG_BUCK4_CONFIG, RK818_BUCK4_VSEL_MASK, },
};
+static const struct rk8xx_reg_info rk809_buck5[] = {
+ /* buck 5 */
+ { 150, 0, RK809_BUCK5_CONFIG(0), RK809_BUCK5_CONFIG(1), NA,
RK809_BUCK5_VSEL_MASK, 0x00, },
+ { 180, 20, RK809_BUCK5_CONFIG(0), RK809_BUCK5_CONFIG(1), NA,
RK809_BUCK5_VSEL_MASK, 0x01, },
+ { 280, 20, RK809_BUCK5_CONFIG(0), RK809_BUCK5_CONFIG(1), NA,
RK809_BUCK5_VSEL_MASK, 0x04, },
+ { 330, 30, RK809_BUCK5_CONFIG(0), RK809_BUCK5_CONFIG(1), NA,
RK809_BUCK5_VSEL_MASK, 0x06, },
+};
+
static const struct rk8xx_reg_info rk817_buck[] = {
/* buck 1 */
{ 50, 12500, RK817_BUCK_ON_VSEL(1), RK817_BUCK_SLP_VSEL(1),
RK817_BUCK_CONFIG(1), RK817_BUCK_VSEL_MASK, 0x00, },
@@ -223,6 +236,7 @@ static const struct rk8xx_reg_info *get_buck_reg(struct
udevice *pmic,
return &rk816_buck[num + 4];
}
+ case RK809_ID:
case RK817_ID:
switch (num) {
case 0 ... 2:
@@ -239,6 +253,16 @@ static const struct rk8xx_reg_info *get_buck_reg(struct
udevice *pmic,
return &rk817_buck[num * 3 + 1];
else
return &rk817_buck[num * 3 + 2];
+ /* BUCK5 for RK809 */
+ default:
+ if (uvolt < 180)
+ return &rk809_buck5[0];
+ else if (uvolt < 280)
+ return &rk809_buck5[1];
+ else if (uvolt < 330)
+ return &rk809_buck5[2];
+ else
+ return &rk809_buck5[3];
}
case RK818_ID:
return &rk818_buck[num];
@@ -308,6 +332,7 @@ st
Re: [U-Boot] [PATCH v1 6/7] mmc: fsl_esdhc: Add emmc hs200 support
Yinbo,
Priyanka is the maintainer now for NXP platforms.
York
> On Sep 9, 2019, at 20:10, Yinbo Zhu wrote:
>
> Hi York Sun,
>
> Could you help me merge that series patch to uboot upstream tree.
>
> Regards,
> Yinbo Zhu
> Original Message-
> From: Peng Fan
> Sent: 2019年8月28日 9:04
> To: Yinbo Zhu ; York Sun ;
> u-boot@lists.denx.de
> Cc: Jiafei Pan ; Yinbo Zhu ; Xiaobo
> Xie
> Subject: RE: [U-Boot] [PATCH v1 6/7] mmc: fsl_esdhc: Add emmc hs200 support
>
>> Subject: [U-Boot] [PATCH v1 6/7] mmc: fsl_esdhc: Add emmc hs200
>> support
>>
>> Add eMMC hs200 mode support for increasing ls1028/ls1012/lx2160 eMMC
>> work performance, but without tuning procedure which will cause mmc
>> doesn't work. and this should be TODO work.
>>
>> Signed-off-by: Yinbo Zhu
>
> Acked-by: Peng Fan
>
>> ---
>> drivers/mmc/fsl_esdhc.c | 34 +++---
>> include/fsl_esdhc.h | 4
>> 2 files changed, 23 insertions(+), 15 deletions(-)
>>
>> diff --git a/drivers/mmc/fsl_esdhc.c b/drivers/mmc/fsl_esdhc.c index
>> 07318472a7..28d2312ef7 100644
>> --- a/drivers/mmc/fsl_esdhc.c
>> +++ b/drivers/mmc/fsl_esdhc.c
>> @@ -395,10 +395,6 @@ static int esdhc_send_cmd_common(struct
>> fsl_esdhc_priv *priv, struct mmc *mmc,
>>esdhc_write32(®s->cmdarg, cmd->cmdarg);
>>esdhc_write32(®s->xfertyp, xfertyp);
>>
>> -if ((cmd->cmdidx == MMC_CMD_SEND_TUNING_BLOCK) ||
>> -(cmd->cmdidx == MMC_CMD_SEND_TUNING_BLOCK_HS200))
>> -flags = IRQSTAT_BRR;
>> -
>>/* Wait for the command to complete */
>>start = get_timer(0);
>>while (!(esdhc_read32(®s->irqstat) & flags)) { @@ -458,12 +454,6
>> @@ static int esdhc_send_cmd_common(struct fsl_esdhc_priv *priv,
>> struct mmc *mmc, #ifdef CONFIG_SYS_FSL_ESDHC_USE_PIO
>>esdhc_pio_read_write(priv, data);
>> #else
>> -flags = DATA_COMPLETE;
>> -if ((cmd->cmdidx == MMC_CMD_SEND_TUNING_BLOCK) ||
>> -(cmd->cmdidx == MMC_CMD_SEND_TUNING_BLOCK_HS200))
>> {
>> -flags = IRQSTAT_BRR;
>> -}
>> -
>>do {
>>irqstat = esdhc_read32(®s->irqstat);
>>
>> @@ -476,7 +466,7 @@ static int esdhc_send_cmd_common(struct
>> fsl_esdhc_priv *priv, struct mmc *mmc,
>>err = -ECOMM;
>>goto out;
>>}
>> -} while ((irqstat & flags) != flags);
>> +} while ((irqstat & DATA_COMPLETE) != DATA_COMPLETE);
>>
>>/*
>> * Need invalidate the dcache here again to avoid any @@ -517,7
>> +507,9 @@ static void set_sysctl(struct fsl_esdhc_priv *priv, struct
>> +mmc
>> *mmc, uint clock)
>>int div = 1;
>>int pre_div = 2;
>>int ddr_pre_div = mmc->ddr_mode ? 2 : 1;
>> -int sdhc_clk = priv->sdhc_clk;
>> +unsigned int sdhc_clk = priv->sdhc_clk;
>> +u32 time_out;
>> +u32 value;
>>uint clk;
>>
>>if (clock < mmc->cfg->f_min)
>> @@ -538,11 +530,18 @@ static void set_sysctl(struct fsl_esdhc_priv
>> *priv, struct mmc *mmc, uint clock)
>>
>>esdhc_clrsetbits32(®s->sysctl, SYSCTL_CLOCK_MASK, clk);
>>
>> -udelay(1);
>> +time_out = 20;
>> +value = PRSSTAT_SDSTB;
>> +while (!(esdhc_read32(®s->prsstat) & value)) {
>> +if (time_out == 0) {
>> +printf("fsl_esdhc: Internal clock never stabilised.\n");
>> +break;
>> +}
>> +time_out--;
>> +mdelay(1);
>> +}
>>
>>esdhc_setbits32(®s->sysctl, SYSCTL_PEREN | SYSCTL_CKEN);
>> -
>> -priv->clock = clock;
>> }
>>
>> #ifdef CONFIG_FSL_ESDHC_USE_PERIPHERAL_CLK
>> @@ -1024,6 +1023,8 @@ static int fsl_esdhc_probe(struct udevice *dev)
>>return ret;
>>}
>>
>> +mmc_of_parse(dev, &plat->cfg);
>> +
>>mmc = &plat->mmc;
>>mmc->cfg = &plat->cfg;
>>mmc->dev = dev;
>> @@ -1081,6 +1082,9 @@ static const struct dm_mmc_ops fsl_esdhc_ops = {
>>.get_cd= fsl_esdhc_get_cd,
>>.send_cmd= fsl_esdhc_send_cmd,
>>.set_ios= fsl_esdhc_set_ios,
>> +#ifdef MMC_SUPPORTS_TUNING
>> +.execute_tuning = fsl_esdhc_execute_tuning, #endif
>> };
>> #endif
>>
>> diff --git a/include/fsl_esdhc.h b/include/fsl_esdhc.h index
>> 7d7e946ab3..3f496b4cea 100644
>> --- a/include/fsl_esdhc.h
>> +++ b/include/fsl_esdhc.h
>> @@ -205,6 +205,10 @@ struct fsl_esdhc_cfg { int
>> fsl_esdhc_mmc_init(bd_t *bis); int fsl_esdhc_initialize(bd_t *bis,
>> struct fsl_esdhc_cfg *cfg); void fdt_fixup_esdhc(void *blob, bd_t
>> *bd);
>> +#ifdef MMC_SUPPORTS_TUNING
>> +static inline int fsl_esdhc_execute_tuning(struct udevice *dev,
>> +uint32_t opcode) {return 0; }
>> +#endif
>> #else
>> static inline int fsl_esdhc_mmc_init(bd_t *bis) { return -ENOSYS; }
>> static inline void fdt_fixup_esdhc(void *blob, bd_t *bd) {}
>> --
>> 2.17.1
>>
>> ___
>> U-Boot mailing list
>> U-Boot@lists.denx.de
>> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flist
>> s.d enx.de%2Flistinfo%2Fu-boot&data=02%7C01%7CPeng.Fan%40nxp
[U-Boot] [PATCH v2 5/8] dm: pmic: add pmic_shutdown() interface
From: Joseph Chen
Signed-off-by: Joseph Chen
Signed-off-by: Elaine Zhang
---
drivers/power/pmic/pmic-uclass.c | 11 +++
include/power/pmic.h | 9 +
2 files changed, 20 insertions(+)
diff --git a/drivers/power/pmic/pmic-uclass.c b/drivers/power/pmic/pmic-uclass.c
index db68c766f5d7..28cfe0c987a2 100644
--- a/drivers/power/pmic/pmic-uclass.c
+++ b/drivers/power/pmic/pmic-uclass.c
@@ -191,6 +191,17 @@ static int pmic_pre_probe(struct udevice *dev)
return 0;
}
+
+int pmic_shutdown(struct udevice *dev)
+{
+ const struct dm_pmic_ops *ops = dev_get_driver_ops(dev);
+
+ if (!ops || !ops->shutdown)
+ return -ENOSYS;
+
+ return ops->shutdown(dev);
+}
+
UCLASS_DRIVER(pmic) = {
.id = UCLASS_PMIC,
.name = "pmic",
diff --git a/include/power/pmic.h b/include/power/pmic.h
index be9de6b4de7e..231195e5ea85 100644
--- a/include/power/pmic.h
+++ b/include/power/pmic.h
@@ -164,6 +164,7 @@ struct dm_pmic_ops {
int (*read)(struct udevice *dev, uint reg, uint8_t *buffer, int len);
int (*write)(struct udevice *dev, uint reg, const uint8_t *buffer,
int len);
+ int (*shutdown)(struct udevice *dev);
};
/**
@@ -306,6 +307,14 @@ struct uc_pmic_priv {
uint trans_len;
};
+/**
+ * pmic_shutdown() - power off supplies of PMIC
+ *
+ * @dev: PMIC device to update
+ * @return 0 on success or negative value of errno.
+ */
+int pmic_shutdown(struct udevice *dev);
+
#endif /* CONFIG_DM_PMIC */
#ifdef CONFIG_POWER
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 4/8] power: pmic: rk805: support rk805 pmic
The RK805 are a Power Management IC (PMIC) for multimedia
and handheld devices. They contains the following components:
- Regulators(4*BUCKs, 3*LDOs)
- RTC
- Clocking
Signed-off-by: Elaine Zhang
---
drivers/power/pmic/rk8xx.c | 1 +
drivers/power/regulator/rk8xx.c | 17 +
include/power/rk8xx_pmic.h | 1 +
3 files changed, 19 insertions(+)
diff --git a/drivers/power/pmic/rk8xx.c b/drivers/power/pmic/rk8xx.c
index 1900de9d1cdb..00c8a2e091d8 100644
--- a/drivers/power/pmic/rk8xx.c
+++ b/drivers/power/pmic/rk8xx.c
@@ -94,6 +94,7 @@ static struct dm_pmic_ops rk8xx_ops = {
};
static const struct udevice_id rk8xx_ids[] = {
+ { .compatible = "rockchip,rk805" },
{ .compatible = "rockchip,rk808" },
{ .compatible = "rockchip,rk816" },
{ .compatible = "rockchip,rk818" },
diff --git a/drivers/power/regulator/rk8xx.c b/drivers/power/regulator/rk8xx.c
index 3188d3c6350d..e9d83635988b 100644
--- a/drivers/power/regulator/rk8xx.c
+++ b/drivers/power/regulator/rk8xx.c
@@ -38,7 +38,14 @@
/*
* Ramp delay
*/
+#define RK805_RAMP_RATE_OFFSET 3
+#define RK805_RAMP_RATE_MASK (3 << RK805_RAMP_RATE_OFFSET)
+#define RK805_RAMP_RATE_3MV_PER_US (0 << RK805_RAMP_RATE_OFFSET)
+#define RK805_RAMP_RATE_6MV_PER_US (1 << RK805_RAMP_RATE_OFFSET)
+#define RK805_RAMP_RATE_12_5MV_PER_US (2 << RK805_RAMP_RATE_OFFSET)
+#define RK805_RAMP_RATE_25MV_PER_US(3 << RK805_RAMP_RATE_OFFSET)
#define RK808_RAMP_RATE_OFFSET 3
+
#define RK808_RAMP_RATE_MASK (3 << RK808_RAMP_RATE_OFFSET)
#define RK808_RAMP_RATE_2MV_PER_US (0 << RK808_RAMP_RATE_OFFSET)
#define RK808_RAMP_RATE_4MV_PER_US (1 << RK808_RAMP_RATE_OFFSET)
@@ -131,6 +138,7 @@ static const struct rk8xx_reg_info *get_buck_reg(struct
udevice *pmic,
struct rk8xx_priv *priv = dev_get_priv(pmic);
switch (priv->variant) {
+ case RK805_ID:
case RK816_ID:
switch (num) {
case 0:
@@ -185,6 +193,7 @@ static int _buck_set_enable(struct udevice *pmic, int buck,
bool enable)
struct rk8xx_priv *priv = dev_get_priv(pmic);
switch (priv->variant) {
+ case RK805_ID:
case RK816_ID:
if (buck >= 4) {
buck -= 4;
@@ -246,6 +255,7 @@ static int _buck_get_enable(struct udevice *pmic, int buck)
int ret = 0;
switch (priv->variant) {
+ case RK805_ID:
case RK816_ID:
if (buck >= 4) {
mask = 1 << (buck - 4);
@@ -277,6 +287,7 @@ static int _buck_set_suspend_enable(struct udevice *pmic,
int buck, bool enable)
struct rk8xx_priv *priv = dev_get_priv(pmic);
switch (priv->variant) {
+ case RK805_ID:
case RK816_ID:
mask = 1 << buck;
ret = pmic_clrsetbits(pmic, RK816_REG_DCDC_SLP_EN, mask,
@@ -302,6 +313,7 @@ static int _buck_get_suspend_enable(struct udevice *pmic,
int buck)
uint mask;
switch (priv->variant) {
+ case RK805_ID:
case RK816_ID:
mask = 1 << buck;
val = pmic_reg_read(pmic, RK816_REG_DCDC_SLP_EN);
@@ -330,6 +342,7 @@ static const struct rk8xx_reg_info *get_ldo_reg(struct
udevice *pmic,
struct rk8xx_priv *priv = dev_get_priv(pmic);
switch (priv->variant) {
+ case RK805_ID:
case RK816_ID:
return &rk816_ldo[num];
case RK818_ID:
@@ -346,6 +359,7 @@ static int _ldo_get_enable(struct udevice *pmic, int ldo)
int ret = 0;
switch (priv->variant) {
+ case RK805_ID:
case RK816_ID:
if (ldo >= 4) {
mask = 1 << (ldo - 4);
@@ -378,6 +392,7 @@ static int _ldo_set_enable(struct udevice *pmic, int ldo,
bool enable)
int ret = 0;
switch (priv->variant) {
+ case RK805_ID:
case RK816_ID:
if (ldo >= 4) {
ldo -= 4;
@@ -410,6 +425,7 @@ static int _ldo_set_suspend_enable(struct udevice *pmic,
int ldo, bool enable)
int ret = 0;
switch (priv->variant) {
+ case RK805_ID:
case RK816_ID:
mask = 1 << ldo;
ret = pmic_clrsetbits(pmic, RK816_REG_LDO_SLP_EN, mask,
@@ -433,6 +449,7 @@ static int _ldo_get_suspend_enable(struct udevice *pmic,
int ldo)
uint mask;
switch (priv->variant) {
+ case RK805_ID:
case RK816_ID:
mask = 1 << ldo;
val = pmic_reg_read(pmic, RK816_REG_LDO_SLP_EN);
diff --git a/include/power/rk8xx_pmic.h b/include/power/rk8xx_pmic.h
index 44e8d687dfba..7784c2a5e473 100644
--- a/include/power/rk8xx_pmic.h
+++ b/include/power/rk8xx_pmic.h
@@ -179,6 +179,7 @@ enum {
};
enum {
+ RK805_ID = 0x8050,
RK808_ID = 0x,
RK816_ID = 0x8160,
RK818_ID = 0x8180,
--
1.9.1
___
U-Boot
[U-Boot] [PATCH v2 3/8] power: pmic: rk816: support rk816 pmic
The RK816 is a Power Management IC (PMIC) for multimedia
and handheld devices. They contains the following components:
- Regulators(4*BUCKs, 1*BOOST, 6*LDOs, 1*SWITCH)
- RTC
- Clocking
Signed-off-by: Elaine Zhang
---
drivers/power/pmic/rk8xx.c | 1 +
drivers/power/regulator/rk8xx.c | 130 ++--
include/power/rk8xx_pmic.h | 11 +++-
3 files changed, 136 insertions(+), 6 deletions(-)
diff --git a/drivers/power/pmic/rk8xx.c b/drivers/power/pmic/rk8xx.c
index 25c339ab12cc..1900de9d1cdb 100644
--- a/drivers/power/pmic/rk8xx.c
+++ b/drivers/power/pmic/rk8xx.c
@@ -95,6 +95,7 @@ static struct dm_pmic_ops rk8xx_ops = {
static const struct udevice_id rk8xx_ids[] = {
{ .compatible = "rockchip,rk808" },
+ { .compatible = "rockchip,rk816" },
{ .compatible = "rockchip,rk818" },
{ }
};
diff --git a/drivers/power/regulator/rk8xx.c b/drivers/power/regulator/rk8xx.c
index ef83f66c8b6e..3188d3c6350d 100644
--- a/drivers/power/regulator/rk8xx.c
+++ b/drivers/power/regulator/rk8xx.c
@@ -62,6 +62,21 @@ static const struct rk8xx_reg_info rk808_buck[] = {
{ 180, 10, REG_BUCK4_ON_VSEL, REG_BUCK4_SLP_VSEL,
REG_BUCK4_CONFIG, RK808_BUCK4_VSEL_MASK, },
};
+static const struct rk8xx_reg_info rk816_buck[] = {
+ /* buck 1 */
+ { 712500, 12500, REG_BUCK1_ON_VSEL, REG_BUCK1_SLP_VSEL,
REG_BUCK1_CONFIG, RK818_BUCK_VSEL_MASK, 0x00, },
+ { 180, 20, REG_BUCK1_ON_VSEL, REG_BUCK1_SLP_VSEL,
REG_BUCK1_CONFIG, RK818_BUCK_VSEL_MASK, 0x3c, },
+ { 230, 0, REG_BUCK1_ON_VSEL, REG_BUCK1_SLP_VSEL,
REG_BUCK1_CONFIG, RK818_BUCK_VSEL_MASK, 0x3f, },
+ /* buck 2 */
+ { 712500, 12500, REG_BUCK2_ON_VSEL, REG_BUCK2_SLP_VSEL,
REG_BUCK2_CONFIG, RK818_BUCK_VSEL_MASK, 0x00, },
+ { 180, 20, REG_BUCK2_ON_VSEL, REG_BUCK2_SLP_VSEL,
REG_BUCK2_CONFIG, RK818_BUCK_VSEL_MASK, 0x3c, },
+ { 230, 0, REG_BUCK2_ON_VSEL, REG_BUCK2_SLP_VSEL,
REG_BUCK2_CONFIG, RK818_BUCK_VSEL_MASK, 0x3f, },
+ /* buck 3 */
+ { 712500, 12500, NA,NA,
REG_BUCK3_CONFIG, RK818_BUCK_VSEL_MASK, },
+ /* buck 4 */
+ { 80, 10, REG_BUCK4_ON_VSEL, REG_BUCK4_SLP_VSEL,
REG_BUCK4_CONFIG, RK818_BUCK4_VSEL_MASK, },
+};
+
static const struct rk8xx_reg_info rk818_buck[] = {
{ 712500, 12500, REG_BUCK1_ON_VSEL, REG_BUCK1_SLP_VSEL,
REG_BUCK1_CONFIG, RK818_BUCK_VSEL_MASK, },
{ 712500, 12500, REG_BUCK2_ON_VSEL, REG_BUCK2_SLP_VSEL,
REG_BUCK2_CONFIG, RK818_BUCK_VSEL_MASK, },
@@ -81,6 +96,15 @@ static const struct rk8xx_reg_info rk808_ldo[] = {
{ 180, 10, REG_LDO8_ON_VSEL, REG_LDO8_SLP_VSEL, NA,
RK808_LDO_VSEL_MASK, },
};
+static const struct rk8xx_reg_info rk816_ldo[] = {
+ { 80, 10, REG_LDO1_ON_VSEL, REG_LDO1_SLP_VSEL, NA,
RK818_LDO_VSEL_MASK, },
+ { 80, 10, REG_LDO2_ON_VSEL, REG_LDO2_SLP_VSEL, NA,
RK818_LDO_VSEL_MASK, },
+ { 80, 10, REG_LDO3_ON_VSEL, REG_LDO3_SLP_VSEL, NA,
RK818_LDO_VSEL_MASK, },
+ { 80, 10, REG_LDO4_ON_VSEL, REG_LDO4_SLP_VSEL, NA,
RK818_LDO_VSEL_MASK, },
+ { 80, 10, REG_LDO5_ON_VSEL, REG_LDO5_SLP_VSEL, NA,
RK818_LDO_VSEL_MASK, },
+ { 80, 10, REG_LDO6_ON_VSEL, REG_LDO6_SLP_VSEL, NA,
RK818_LDO_VSEL_MASK, },
+};
+
static const struct rk8xx_reg_info rk818_ldo[] = {
{ 180, 10, REG_LDO1_ON_VSEL, REG_LDO1_SLP_VSEL, NA,
RK818_LDO_VSEL_MASK, },
{ 180, 10, REG_LDO2_ON_VSEL, REG_LDO2_SLP_VSEL, NA,
RK818_LDO_VSEL_MASK, },
@@ -105,7 +129,21 @@ static const struct rk8xx_reg_info *get_buck_reg(struct
udevice *pmic,
int num, int uvolt)
{
struct rk8xx_priv *priv = dev_get_priv(pmic);
+
switch (priv->variant) {
+ case RK816_ID:
+ switch (num) {
+ case 0:
+ case 1:
+ if (uvolt <= 145)
+ return &rk816_buck[num * 3 + 0];
+ else if (uvolt <= 220)
+ return &rk816_buck[num * 3 + 1];
+ else
+ return &rk816_buck[num * 3 + 2];
+ default:
+ return &rk816_buck[num + 4];
+ }
case RK818_ID:
return &rk818_buck[num];
default:
@@ -116,11 +154,13 @@ static const struct rk8xx_reg_info *get_buck_reg(struct
udevice *pmic,
static int _buck_set_value(struct udevice *pmic, int buck, int uvolt)
{
const struct rk8xx_reg_info *info = get_buck_reg(pmic, buck, uvolt);
+ struct rk8xx_priv *priv = dev_get_priv(pmic);
int mask = info->vsel_mask;
int val;
if (info->vsel_reg == NA)
return -ENOSYS;
+
if (info->step_uv == 0) /* Fixed voltage */
val = info->min_sel;
else
@@ -129,
[U-Boot] [PATCH] configs: rockpro64-rk3399: Enable CONFIG_MISC_INIT_R and ROCKCHIP_EFUSE
This enables reading the cpuid from e-fuse, and deriving a static MAC address from it. Without this, the ethernet interface on the rockpro64 can't be used to boot. Signed-off-by: Hugh Cole-Baker Cc: Philipp Tomsich --- configs/rockpro64-rk3399_defconfig | 3 +++ 1 file changed, 3 insertions(+) diff --git a/configs/rockpro64-rk3399_defconfig b/configs/rockpro64-rk3399_defconfig index 40ebad5abb..22b8bc503b 100644 --- a/configs/rockpro64-rk3399_defconfig +++ b/configs/rockpro64-rk3399_defconfig @@ -9,6 +9,7 @@ CONFIG_DEBUG_UART_BASE=0xFF1A CONFIG_DEBUG_UART_CLOCK=2400 CONFIG_DEBUG_UART=y CONFIG_DEFAULT_FDT_FILE="rockchip/rk3399-rockpro64.dtb" +CONFIG_MISC_INIT_R=y # CONFIG_DISPLAY_CPUINFO is not set CONFIG_DISPLAY_BOARDINFO_LATE=y # CONFIG_SPL_RAW_IMAGE_SUPPORT is not set @@ -28,6 +29,8 @@ CONFIG_OF_SPL_REMOVE_PROPS="pinctrl-0 pinctrl-names clock-names interrupt-parent CONFIG_ENV_IS_IN_MMC=y CONFIG_ROCKCHIP_GPIO=y CONFIG_SYS_I2C_ROCKCHIP=y +CONFIG_MISC=y +CONFIG_ROCKCHIP_EFUSE=y CONFIG_MMC_DW=y CONFIG_MMC_DW_ROCKCHIP=y CONFIG_MMC_SDHCI=y -- 2.17.2 (Apple Git-113) ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 2/8] power: regulator: rk8xx: update the driver for rk808 and rk818
In order to adapt the following pmics, make the interface more compatible.
Support buck and ldo suspend voltage setting and getting.
Supprot buck and ldo suspend enable/disable setting and getting.
Signed-off-by: Elaine Zhang
---
drivers/power/regulator/rk8xx.c | 547 ++--
1 file changed, 465 insertions(+), 82 deletions(-)
diff --git a/drivers/power/regulator/rk8xx.c b/drivers/power/regulator/rk8xx.c
index aa4f3a161c47..ef83f66c8b6e 100644
--- a/drivers/power/regulator/rk8xx.c
+++ b/drivers/power/regulator/rk8xx.c
@@ -19,6 +19,9 @@
#define ENABLE_DRIVER
#endif
+/* Not used or exisit register and configure */
+#define NA -1
+
/* Field Definitions */
#define RK808_BUCK_VSEL_MASK 0x3f
#define RK808_BUCK4_VSEL_MASK 0xf
@@ -32,49 +35,61 @@
#define RK818_USB_ILIM_SEL_MASK0x0f
#define RK818_USB_CHG_SD_VSEL_MASK 0x70
+/*
+ * Ramp delay
+ */
+#define RK808_RAMP_RATE_OFFSET 3
+#define RK808_RAMP_RATE_MASK (3 << RK808_RAMP_RATE_OFFSET)
+#define RK808_RAMP_RATE_2MV_PER_US (0 << RK808_RAMP_RATE_OFFSET)
+#define RK808_RAMP_RATE_4MV_PER_US (1 << RK808_RAMP_RATE_OFFSET)
+#define RK808_RAMP_RATE_6MV_PER_US (2 << RK808_RAMP_RATE_OFFSET)
+#define RK808_RAMP_RATE_10MV_PER_US(3 << RK808_RAMP_RATE_OFFSET)
struct rk8xx_reg_info {
uint min_uv;
uint step_uv;
- s8 vsel_reg;
+ u8 vsel_reg;
+ u8 vsel_sleep_reg;
+ u8 config_reg;
u8 vsel_mask;
+ u8 min_sel;
};
static const struct rk8xx_reg_info rk808_buck[] = {
- { 712500, 12500, REG_BUCK1_ON_VSEL, RK808_BUCK_VSEL_MASK, },
- { 712500, 12500, REG_BUCK2_ON_VSEL, RK808_BUCK_VSEL_MASK, },
- { 712500, 12500, -1, RK808_BUCK_VSEL_MASK, },
- { 180, 10, REG_BUCK4_ON_VSEL, RK808_BUCK4_VSEL_MASK, },
+ { 712500, 12500, REG_BUCK1_ON_VSEL, REG_BUCK1_SLP_VSEL,
REG_BUCK1_CONFIG, RK808_BUCK_VSEL_MASK, },
+ { 712500, 12500, REG_BUCK2_ON_VSEL, REG_BUCK2_SLP_VSEL,
REG_BUCK2_CONFIG, RK808_BUCK_VSEL_MASK, },
+ { 712500, 12500, NA,NA,
REG_BUCK3_CONFIG, RK808_BUCK_VSEL_MASK, },
+ { 180, 10, REG_BUCK4_ON_VSEL, REG_BUCK4_SLP_VSEL,
REG_BUCK4_CONFIG, RK808_BUCK4_VSEL_MASK, },
};
static const struct rk8xx_reg_info rk818_buck[] = {
- { 712500, 12500, REG_BUCK1_ON_VSEL, RK818_BUCK_VSEL_MASK, },
- { 712500, 12500, REG_BUCK2_ON_VSEL, RK818_BUCK_VSEL_MASK, },
- { 712500, 12500, -1, RK818_BUCK_VSEL_MASK, },
- { 180, 10, REG_BUCK4_ON_VSEL, RK818_BUCK4_VSEL_MASK, },
+ { 712500, 12500, REG_BUCK1_ON_VSEL, REG_BUCK1_SLP_VSEL,
REG_BUCK1_CONFIG, RK818_BUCK_VSEL_MASK, },
+ { 712500, 12500, REG_BUCK2_ON_VSEL, REG_BUCK2_SLP_VSEL,
REG_BUCK2_CONFIG, RK818_BUCK_VSEL_MASK, },
+ { 712500, 12500, NA,NA,
REG_BUCK3_CONFIG, RK818_BUCK_VSEL_MASK, },
+ { 180, 10, REG_BUCK4_ON_VSEL, REG_BUCK4_SLP_VSEL,
REG_BUCK4_CONFIG, RK818_BUCK4_VSEL_MASK, },
};
#ifdef ENABLE_DRIVER
static const struct rk8xx_reg_info rk808_ldo[] = {
- { 180, 10, REG_LDO1_ON_VSEL, RK808_LDO_VSEL_MASK, },
- { 180, 10, REG_LDO2_ON_VSEL, RK808_LDO_VSEL_MASK, },
- { 80, 10, REG_LDO3_ON_VSEL, RK808_BUCK4_VSEL_MASK, },
- { 180, 10, REG_LDO4_ON_VSEL, RK808_LDO_VSEL_MASK, },
- { 180, 10, REG_LDO5_ON_VSEL, RK808_LDO_VSEL_MASK, },
- { 80, 10, REG_LDO6_ON_VSEL, RK808_LDO_VSEL_MASK, },
- { 80, 10, REG_LDO7_ON_VSEL, RK808_LDO_VSEL_MASK, },
- { 180, 10, REG_LDO8_ON_VSEL, RK808_LDO_VSEL_MASK, },
+ { 180, 10, REG_LDO1_ON_VSEL, REG_LDO1_SLP_VSEL, NA,
RK808_LDO_VSEL_MASK, },
+ { 180, 10, REG_LDO2_ON_VSEL, REG_LDO2_SLP_VSEL, NA,
RK808_LDO_VSEL_MASK, },
+ { 80, 10, REG_LDO3_ON_VSEL, REG_LDO3_SLP_VSEL, NA,
RK808_BUCK4_VSEL_MASK, },
+ { 180, 10, REG_LDO4_ON_VSEL, REG_LDO4_SLP_VSEL, NA,
RK808_LDO_VSEL_MASK, },
+ { 180, 10, REG_LDO5_ON_VSEL, REG_LDO5_SLP_VSEL, NA,
RK808_LDO_VSEL_MASK, },
+ { 80, 10, REG_LDO6_ON_VSEL, REG_LDO6_SLP_VSEL, NA,
RK808_LDO_VSEL_MASK, },
+ { 80, 10, REG_LDO7_ON_VSEL, REG_LDO7_SLP_VSEL, NA,
RK808_LDO_VSEL_MASK, },
+ { 180, 10, REG_LDO8_ON_VSEL, REG_LDO8_SLP_VSEL, NA,
RK808_LDO_VSEL_MASK, },
};
static const struct rk8xx_reg_info rk818_ldo[] = {
- { 180, 10, REG_LDO1_ON_VSEL, RK818_LDO_VSEL_MASK, },
- { 180, 10, REG_LDO2_ON_VSEL, RK818_LDO_VSEL_MASK, },
- { 80, 10, REG_LDO3_ON_VSEL, RK818_LDO3_ON_VSEL_MASK, },
- { 180, 10, REG_LDO4_ON_VSEL, RK818_LDO_VSEL_MASK, },
- { 180, 10, REG_LDO5_ON_VSEL, RK818_LDO_VSEL_MASK, },
- { 80, 10, REG_LDO6_ON_VSEL, RK818_LDO_VSEL_MASK, },
- { 80, 10, REG_LDO7_ON_VSEL, RK818_LDO_VSEL_MASK, },
- { 180
[U-Boot] [PATCH v2 0/8] power: pmic: support more PMIC
Support more PMIC and improve compatibility between pmics. Change in V2: [PATCH v2 1/8]: Add regulator suspend volatge and en/disable test. [PATCH v2 2/8]: Split the [PATCH v1 2/7], rk808 and rk818 updates. [PATCH v2 3/8]: Split the [PATCH v1 2/7], support rk816 pmic and update commit message. [PATCH v2 4/8]: Update commit message. [PATCH v2 5/8]: No change. [PATCH v2 6/8]: No change. [PATCH v2 7/8]: Remove rk809 keywords and update commit message. [PATCH v2 8/8]: Update commit message. Elaine Zhang (3): power: regulator: rk8xx: update the driver for rk808 and rk818 power: pmic: rk816: support rk816 pmic power: pmic: rk805: support rk805 pmic Joseph Chen (5): dm: regulator: support regulator more state dm: pmic: add pmic_shutdown() interface power: pmic: rk8xx: add pmic_shutdown() implement power: pmic: rk817: support rk817 pmic power: pmic: rk809: support rk809 pmic drivers/power/pmic/pmic-uclass.c | 11 + drivers/power/pmic/rk8xx.c | 135 - drivers/power/regulator/regulator-uclass.c | 67 ++ drivers/power/regulator/rk8xx.c| 939 ++--- include/power/pmic.h | 9 + include/power/regulator.h | 42 ++ include/power/rk8xx_pmic.h | 42 ++ test/dm/regulator.c| 46 ++ 8 files changed, 1203 insertions(+), 88 deletions(-) -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 1/8] dm: regulator: support regulator more state
From: Joseph Chen
support parse regulator standard property:
regulator-off-in-suspend;
regulator-init-microvolt;
regulator-suspend-microvolt:
regulator_get_suspend_enable
regulator_set_suspend_enable
regulator_get_suspend_value
regulator_set_suspend_value
Signed-off-by: Joseph Chen
Signed-off-by: Elaine Zhang
---
drivers/power/regulator/regulator-uclass.c | 67 ++
include/power/regulator.h | 42 +++
test/dm/regulator.c| 46
3 files changed, 155 insertions(+)
diff --git a/drivers/power/regulator/regulator-uclass.c
b/drivers/power/regulator/regulator-uclass.c
index 76be95bcd159..972a5b210c3c 100644
--- a/drivers/power/regulator/regulator-uclass.c
+++ b/drivers/power/regulator/regulator-uclass.c
@@ -77,6 +77,33 @@ int regulator_set_value(struct udevice *dev, int uV)
return ret;
}
+int regulator_set_suspend_value(struct udevice *dev, int uV)
+{
+ const struct dm_regulator_ops *ops = dev_get_driver_ops(dev);
+ struct dm_regulator_uclass_platdata *uc_pdata;
+
+ uc_pdata = dev_get_uclass_platdata(dev);
+ if (uc_pdata->min_uV != -ENODATA && uV < uc_pdata->min_uV)
+ return -EINVAL;
+ if (uc_pdata->max_uV != -ENODATA && uV > uc_pdata->max_uV)
+ return -EINVAL;
+
+ if (!ops || !ops->set_suspend_value)
+ return -ENOSYS;
+
+ return ops->set_suspend_value(dev, uV);
+}
+
+int regulator_get_suspend_value(struct udevice *dev)
+{
+ const struct dm_regulator_ops *ops = dev_get_driver_ops(dev);
+
+ if (!ops || !ops->get_suspend_value)
+ return -ENOSYS;
+
+ return ops->get_suspend_value(dev);
+}
+
/*
* To be called with at most caution as there is no check
* before setting the actual voltage value.
@@ -170,6 +197,26 @@ int regulator_set_enable_if_allowed(struct udevice *dev,
bool enable)
return ret;
}
+int regulator_set_suspend_enable(struct udevice *dev, bool enable)
+{
+ const struct dm_regulator_ops *ops = dev_get_driver_ops(dev);
+
+ if (!ops || !ops->set_suspend_enable)
+ return -ENOSYS;
+
+ return ops->set_suspend_enable(dev, enable);
+}
+
+int regulator_get_suspend_enable(struct udevice *dev)
+{
+ const struct dm_regulator_ops *ops = dev_get_driver_ops(dev);
+
+ if (!ops || !ops->get_suspend_enable)
+ return -ENOSYS;
+
+ return ops->get_suspend_enable(dev);
+}
+
int regulator_get_mode(struct udevice *dev)
{
const struct dm_regulator_ops *ops = dev_get_driver_ops(dev);
@@ -235,6 +282,11 @@ int regulator_autoset(struct udevice *dev)
int ret = 0;
uc_pdata = dev_get_uclass_platdata(dev);
+
+ ret = regulator_set_suspend_enable(dev, uc_pdata->suspend_on);
+ if (!ret && uc_pdata->suspend_on)
+ ret = regulator_set_suspend_value(dev, uc_pdata->suspend_uV);
+
if (!uc_pdata->always_on && !uc_pdata->boot_on)
return -EMEDIUMTYPE;
@@ -243,6 +295,8 @@ int regulator_autoset(struct udevice *dev)
if (uc_pdata->flags & REGULATOR_FLAG_AUTOSET_UV)
ret = regulator_set_value(dev, uc_pdata->min_uV);
+ if (uc_pdata->init_uV > 0)
+ ret = regulator_set_value(dev, uc_pdata->init_uV);
if (!ret && (uc_pdata->flags & REGULATOR_FLAG_AUTOSET_UA))
ret = regulator_set_current(dev, uc_pdata->min_uA);
@@ -363,6 +417,7 @@ static int regulator_post_bind(struct udevice *dev)
static int regulator_pre_probe(struct udevice *dev)
{
struct dm_regulator_uclass_platdata *uc_pdata;
+ ofnode node;
uc_pdata = dev_get_uclass_platdata(dev);
if (!uc_pdata)
@@ -373,6 +428,8 @@ static int regulator_pre_probe(struct udevice *dev)
-ENODATA);
uc_pdata->max_uV = dev_read_u32_default(dev, "regulator-max-microvolt",
-ENODATA);
+ uc_pdata->init_uV = dev_read_u32_default(dev,
"regulator-init-microvolt",
+ -ENODATA);
uc_pdata->min_uA = dev_read_u32_default(dev, "regulator-min-microamp",
-ENODATA);
uc_pdata->max_uA = dev_read_u32_default(dev, "regulator-max-microamp",
@@ -382,6 +439,16 @@ static int regulator_pre_probe(struct udevice *dev)
uc_pdata->ramp_delay = dev_read_u32_default(dev, "regulator-ramp-delay",
0);
+ node = dev_read_subnode(dev, "regulator-state-mem");
+ if (ofnode_valid(node)) {
+ uc_pdata->suspend_on = !ofnode_read_bool(node,
"regulator-off-in-suspend");
+ if (ofnode_read_u32(node, "regulator-suspend-microvolt",
&uc_pdata->suspend_uV))
+ uc_pdata->suspend_uV = uc_pdata->max_uA;
+ } else {
+ uc_pdata->su
Re: [U-Boot] [PATCH v3 0/3] spi: Split CONFIG_DM_SPI* to CONFIG_{SPL_TPL}DM_SPI*
Hi Frieder,
> On Mon, 9 Sep 2019 11:11:50 +
> Schrempf Frieder wrote:
>
> > Hi Lukasz,
> >
> > On 05.09.19 20:09, Tom Rini wrote:
> > > On Thu, Sep 05, 2019 at 12:16:36AM +0200, Lukasz Majewski wrote:
> > >
> > >> This patch series introduces new SPL and TPL specific Kconfig
> > >> entries for DM_SPI* options. Such change allows using the spi
> > >> driver in SPL/TPL or U-Boot proper.
> > >>
> > >> First two patches - related to ls10{42}* NXP soc fix some issues
> > >> with defining the DM_SPI* defines in .h file instead of
> > >> Kconfig.
> > >>
> > >> This series doesn't introduce build breaks, but board maintainers
> > >> are kindly asked to check if their boards still boots.
> > >>
> > >> Buildman setup for binary size regression checking:
> > >>
> > >> ./tools/buildman/buildman.py -b HEAD --count=4 ls1043
> > >> --output-dir=../BUILD/ --force-build -CveE
> > >> ./tools/buildman/buildman.py -b HEAD --count=4 ls1043
> > >> --output-dir=../BUILD/ -Ssdel
> > >
> > > So you did fix the ls1043 problems but ls1046 is still a problem.
> > >
> >
> > I was trying to clean up this config mess some weeks ago. I
> > stumbled over the same issues (size deltas below) when I tested
> > with buildman and finally gave up on it. This was my testing branch
> > for reference: [1].
> >
> > Thanks for your work and I hope you/we can get this sorted out
> > somehow...
>
> For now I've only posted the patch to introduce SPL_DM_SPI in Kconig:
> https://patchwork.ozlabs.org/patch/1159655/
However, I've looked on your patchset and IMHO this work could be
divided (as doing it at once is not feasible).
For example the CONFIG_SPI_FLASH_MTD could be converted to
(SPL_TPL_)SPI_FLASH_MTD and then one could use
#if CONFIG_IS_ENABLED(SPI_FLASH_MTD) in drivers/mtd/spi/sf_probe.c (as
it is only used there).
Then we could avoid situations where code is added as you remove it
here [1]:
https://github.com/fschrempf/u-boot/commit/b6489fb5928c2b41d7e4cb39933f078659b4f10e#diff-9d3e174d033b8b9c9d380a22a81600aaL136
What I'm afraid though, is that split of SPI_FLASH_MTD will require
adding unwillingly SPL_(TPL_)SPI_FLASH_MTD to all boards which already
define it (and only drop ones, which use in .h file pattern as
[1]).
Frieder, would you be able to work on this topic any time soon?
>
> >
> > Regards,
> > Frieder
> >
> > [1]:
> > https://github.com/fschrempf/u-boot/commits/non_dm_spi_flash_in_spl
> >
> > > There's also changes in (add 'B' to the buildman flags above for
> > > this info):
> > > x86: (for 26/26 boards) spl/u-boot-spl:all -31.6
> > > spl/u-boot-spl:data -11.4 spl/u-boot-spl:rodata -6.3
> > > spl/u-boot-spl:text -13.9 qemu-x86_64: spl/u-boot-spl:all -821
> > > spl/u-boot-spl:data -296 spl/u-boot-spl:rodata -164
> > > spl/u-boot-spl:text -361 spl-u-boot-spl: add: 0/-10, grow: 0/0
> > > bytes: 0/-657 (-657) function
> > > old new delta spi_flash_post_bind 3
> > > - -3 dev_get_parent_priv 11 -
> > > -11 spi_post_probe 35 -
> > > -35 spi_child_post_bind 37 - -37
> > > spi_child_pre_probe 46 - -46
> > > _u_boot_list_2_driver_2_spi_generic_drv 68 - -68
> > > _u_boot_list_2_uclass_2_spi_nor 76 - -76
> > > _u_boot_list_2_uclass_2_spi_generic 76 - -76
> > > _u_boot_list_2_uclass_2_spi 76 - -76
> > > spi_slave_ofdata_to_platdata 229 --229
> > > arm: (for 688/688 boards) all -19.6 bss -4.5 rodata -2.2
> > > spl/u-boot-spl:all -12.2 spl/u-boot-spl:bss -1.1
> > > spl/u-boot-spl:data -1.9 spl/u-boot-spl:rodata -2.0
> > > spl/u-boot-spl:text -7.2 text -12.9 uniphier_v7: bss -8 rodata
> > > +8 opos6uldev : bss -8 rodata +8 uniphier_ld4_sld8: bss -8
> > > rodata +8 da850evm : spl/u-boot-spl:all -614
> > > spl/u-boot-spl:data -144 spl/u-boot-spl:rodata -150
> > > spl/u-boot-spl:text -320 spl-u-boot-spl: add: 2/-15, grow: 2/0
> > > bytes: 112/-574 (-462) function
> > > old new delta spi_flash_probe 38
> > > 82 +44 spi_setup_slave -
> > > 42 +42 spl_spi_load_image 124 144
> > > +20 spi_free_slave - 6
> > > +6 spi_flash_std_remove 4 - -4
> > > spi_flash_post_bind 4 - -4
> > > spi_flash_cmd_get_sw_write_prot 8 - -8
> > > aeabi_uidivmod_from_thumb8 - -8
> > > spi_flash_std_get_sw_write_prot 18 - -18
> > > spi_flash_read_dm 20 - -20
> > > __aeabi_uidivmod24 - -24
> > > __aeabi_idivmod 24 - -24
> > > spi_flash_std_write
Re: [U-Boot] FDT placement in OpenSBI + U-Boot + Linux kernel issue for RISC-V
On Mon, 2019-09-09 at 13:22 +0300, David Abdurachmanov wrote:
> On Mon, Sep 9, 2019 at 8:05 AM Anup Patel wrote:
> > Hi,
> >
> > I think keeping FDT placement in-sync between U-Boot and OpenSBI
> > across platforms is going to be painful.
> >
> > I suggest that for all platforms U-Boot explicitly load FDT from
> > somewhere
> > so:
> > 1. U-Boot ${fdt_addr_r} default value will be recommended location
> > of FDT
> > 2. U-Boot ${fdtcontroladdr} will always point to copy of FDT passed
> > by OpenSBI
> > 3. To forward FDT passed by OpenSBI to Linux, U-Boot users can
> > always explicitly
> > copy FDT from ${fdtcontroladdr} to ${fdt_addr_r} using U-Boot copy
> > command
> >
> > I also suspect that in-future for certain platforms FDT passed to
> > U-Boot and
> > FDT passed to Linux might be little different due to U-Boot
> > specific changes
> > in DTS.
> >
> > Thoughts ??
>
> Do not forget PXE and EXTLINUX boot options. These options must
> always be able to override DTB from previous stages. See below what
> PXE/EXT use. For Fedora/RISCV we end up in scenario #2 and thus
> fdt_addr needs to be set if DTB is coming from somewhere in the
> firmware.
> This is why we had CONFIG_PREBOOT to set it.
>
> [..]
> * Scenario 1: If fdt_addr_r specified and "fdt" label is defined in
> * pxe file, retrieve fdt blob from server. Pass fdt_addr_r to bootm,
> * and adjust argc appropriately.
> *
> * Scenario 2: If there is an fdt_addr specified, pass it along to
> * bootm, and adjust argc appropriately.
> *
How about if we do this in PREBOOT ?
1. copy fdt from fdtcontroladdr to fdt_addr_r
2. setenv fdt_addr $fdt_addr_r
In this way, U-Boot will not have any direct dependancies on OpenSBI.
As long as U-Boot is configured with a fdt_addr_r, it should work. It
will be still valid for loading fdt from tftp server to fdt_addr_r as
well.
> * Scenario 3: fdt blob is not available.
> [..]
>
> david
>
> > Regards,
> > Anup
> >
> > > -Original Message-
> > > From: Atish Patra
> > > Sent: Sunday, September 8, 2019 5:40 PM
> > > To: david.abdurachma...@sifive.com; Alistair Francis
> > > ; Anup Patel
> > > Cc: u-boot@lists.denx.de; open...@lists.infradead.org
> > > Subject: FDT placement in OpenSBI + U-Boot + Linux kernel issue
> > > for RISC-V
> > >
> > > Hi All,
> > >
> > > I noticed following issues around U-Boot fdt location in
> > > Unleashed and Qemu
> > > virt machine.
> > >
> > > OpenSBI copies the FDT to following addresses for respective
> > > platforms
> > >
> > > Qemu: 0x8220
> > > Unleashed:0x8800
> > >
> > >
> > > As CONFIG_PRIOR_STAGE is set for both platforms, fdt is first
> > > copied to
> > > gd->fdt_blob and then gets relocated to a different address(gd-
> > > > new_fdt) in function reloc_fdt.
> > >
> > > As a result, FDT is present at two locations.
> > >
> > > 1. 0x8800(Unleashed)/0x8220(Qemu) : OpenSBI copied FDT to
> > > this
> > > address.
> > > 2. gd->new_fdt: U-Boot relocated the fdt to this address.
> > > fdtcontroladdr will also point to this address.
> > >
> > > However, commit ac12c6190927 (riscv: set CONFIG_SYS_BOOTM_LEN to
> > > SZ_64M) in U-boot changed Qemu config so that fdt_addr_r points
> > > to
> > > 0x8800 which is wrong as nobody copies fdt to above address
> > > in Qemu.
> > > Also, 5.3-rc+ kernels overwrite the address pointed by
> > > fdtcontroladdr.
> > >
> > > As a result, fdtcontroladdr won't work on any platform and
> > > fdt_addr_r will
> > > work only for Unleashed but not for Qemu.
> > >
> > > I am not sure what should be the ideal solution to avoid these
> > > kind of fdt
> > > placement issues in future. Here are the few possible ones.
> > >
> > > 1. Change the FDT_JUMP_ADDR in OpenSBI to 0x8800(RAM+128MB)
> > > for
> > > Qemu as well. This won't work as Qemu copies initrd to that
> > > address. I guess
> > > best next option is to copy to 0x8400(RAM+64MB) and U-boot
> > > config for
> > > Qemu accordingly.
> > >
> > > 2. Change fdt_addr_r to 0x8220 in Qemu. Update documentation
> > > to use
> > > fdt only from fdt_addr_r not fdtcontroladdr.
> > >
> > > @david: What was the reason behind changing it for Qemu ?
> > >
> > > 3. Fix gd->new_fdt computation. This may affect every board which
> > > is not a
> > > very good idea either.
> > >
> > > 4. Mandate loading fdt only from tftp or sdcard which is the
> > > safest option and
> > > will avoid these kind of complications. However, I think a
> > > default booting
> > > method without tftp server should at least work. Let me know if
> > > that is not a
> > > sane request. In that case, we should update documentation to
> > > clearly say
> > > that only tftpboot or sdcard loading method works.
> > >
> > >
> > > --
> > > Regards,
> > > Atish
> > ___
> > opensbi mailing list
> > open...@lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/opensbi
--
Regards,
Atish
_
Re: [U-Boot] [PATCH] regulator: fixed: Modify enable-active-high behavior
Hi, It's a gentle reminder to not forgot this patch Thanks Patrice On 7/25/19 9:12 AM, Patrice Chotard wrote: > Regulator should not be enabled at probe time if regulator-boot-on > property is not in the dt node. > > "enable-active-high" property is only used to indicate the GPIO > polarity. > > See kernel documentation : > - Documentation/devicetree/bindings/regulator/fixed-regulator.yaml > - Documentation/devicetree/bindings/regulator/gpio-regulator.yaml > > Signed-off-by: Christophe Kerello > Signed-off-by: Patrice Chotard > --- > > drivers/power/regulator/regulator_common.c | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/drivers/power/regulator/regulator_common.c > b/drivers/power/regulator/regulator_common.c > index 3dabbe2a85..2e8a083c75 100644 > --- a/drivers/power/regulator/regulator_common.c > +++ b/drivers/power/regulator/regulator_common.c > @@ -15,7 +15,9 @@ int regulator_common_ofdata_to_platdata(struct udevice *dev, > int flags = GPIOD_IS_OUT; > int ret; > > - if (dev_read_bool(dev, "enable-active-high")) > + if (!dev_read_bool(dev, "enable-active-high")) > + flags |= GPIOD_ACTIVE_LOW; > + if (uc_pdata->boot_on) > flags |= GPIOD_IS_OUT_ACTIVE; > > /* Get optional enable GPIO desc */ ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 2/2] ARM: asm/io.h: remove redundant #if !defined(readb) block
readb is unconditionally defined earlier in io.h, so there's no point
checking whether it's undefined.
Signed-off-by: Rasmus Villemoes
---
arch/arm/include/asm/io.h | 15 ---
1 file changed, 15 deletions(-)
diff --git a/arch/arm/include/asm/io.h b/arch/arm/include/asm/io.h
index 78b183d42f..723f3cf497 100644
--- a/arch/arm/include/asm/io.h
+++ b/arch/arm/include/asm/io.h
@@ -319,21 +319,6 @@ extern void __readwrite_bug(const char *fn);
#define memcpy_fromio(a, b, c) memcpy((a), (void *)(b), (c))
#define memcpy_toio(a, b, c) memcpy((void *)(a), (b), (c))
-#if !defined(readb)
-
-#define readb(addr)(__readwrite_bug("readb"),0)
-#define readw(addr)(__readwrite_bug("readw"),0)
-#define readl(addr)(__readwrite_bug("readl"),0)
-#define writeb(v,addr) __readwrite_bug("writeb")
-#define writew(v,addr) __readwrite_bug("writew")
-#define writel(v,addr) __readwrite_bug("writel")
-
-#define eth_io_copy_and_sum(a,b,c,d) __readwrite_bug("eth_io_copy_and_sum")
-
-#define check_signature(io,sig,len)(0)
-
-#endif
-
/*
* If this architecture has ISA IO, then define the isa_read/isa_write
* macros.
--
2.20.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/2] ARM: asm/io.h: kill off confusing #ifdef __mem_pci block
No ARM board seems to define __mem_pci - and if it did, one would get tons of
./arch/arm/include/asm/io.h:307:0: warning: "readl" redefined
warnings, because readl and friends are unconditionally defined
earlier in io.h. Moreover, the redefinitions lack the memory barriers
that the first definitions have. So I'm guessing this is practically
dead code.
Signed-off-by: Rasmus Villemoes
---
arch/arm/include/asm/io.h | 41 ---
1 file changed, 41 deletions(-)
diff --git a/arch/arm/include/asm/io.h b/arch/arm/include/asm/io.h
index e6d27b69f9..78b183d42f 100644
--- a/arch/arm/include/asm/io.h
+++ b/arch/arm/include/asm/io.h
@@ -315,46 +315,6 @@ extern void _memset_io(unsigned long, int, size_t);
extern void __readwrite_bug(const char *fn);
-/*
- * If this architecture has PCI memory IO, then define the read/write
- * macros. These should only be used with the cookie passed from
- * ioremap.
- */
-#ifdef __mem_pci
-
-#define readb(c) ({ unsigned int __v = __raw_readb(__mem_pci(c)); __v; })
-#define readw(c) ({ unsigned int __v = le16_to_cpu(__raw_readw(__mem_pci(c)));
__v; })
-#define readl(c) ({ unsigned int __v = le32_to_cpu(__raw_readl(__mem_pci(c)));
__v; })
-
-#define writeb(v,c)__raw_writeb(v,__mem_pci(c))
-#define writew(v,c)__raw_writew(cpu_to_le16(v),__mem_pci(c))
-#define writel(v,c)__raw_writel(cpu_to_le32(v),__mem_pci(c))
-
-#define memset_io(c,v,l) _memset_io(__mem_pci(c),(v),(l))
-#define memcpy_fromio(a,c,l) _memcpy_fromio((a),__mem_pci(c),(l))
-#define memcpy_toio(c,a,l) _memcpy_toio(__mem_pci(c),(a),(l))
-
-#define eth_io_copy_and_sum(s,c,l,b) \
- eth_copy_and_sum((s),__mem_pci(c),(l),(b))
-
-static inline int
-check_signature(unsigned long io_addr, const unsigned char *signature,
- int length)
-{
- int retval = 0;
- do {
- if (readb(io_addr) != *signature)
- goto out;
- io_addr++;
- signature++;
- length--;
- } while (length);
- retval = 1;
-out:
- return retval;
-}
-
-#else
#define memset_io(a, b, c) memset((void *)(a), (b), (c))
#define memcpy_fromio(a, b, c) memcpy((a), (void *)(b), (c))
#define memcpy_toio(a, b, c) memcpy((void *)(a), (b), (c))
@@ -373,7 +333,6 @@ out:
#define check_signature(io,sig,len)(0)
#endif
-#endif /* __mem_pci */
/*
* If this architecture has ISA IO, then define the isa_read/isa_write
--
2.20.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 3/4] arm: socfpga: Convert system manager from struct to defines
Convert system manager for Gen5, Arria 10 and Stratix 10 from struct
to defines.
No functional change.
Signed-off-by: Ley Foon Tan
---
v2:
- Change to use writel(), readl() and etc.
- Get base address from DT.
- Add prefix to defines.
---
arch/arm/mach-socfpga/clock_manager_s10.c | 4 +-
.../include/mach/system_manager.h | 2 +
.../include/mach/system_manager_arria10.h | 94 +++--
.../include/mach/system_manager_gen5.h| 123 +++-
.../include/mach/system_manager_s10.h | 184 +++---
arch/arm/mach-socfpga/mailbox_s10.c | 6 +-
arch/arm/mach-socfpga/misc.c | 5 +
arch/arm/mach-socfpga/misc_arria10.c | 9 +-
arch/arm/mach-socfpga/misc_gen5.c | 22 ++-
arch/arm/mach-socfpga/misc_s10.c | 9 +-
arch/arm/mach-socfpga/reset_manager_arria10.c | 24 +--
arch/arm/mach-socfpga/reset_manager_gen5.c| 7 +-
arch/arm/mach-socfpga/reset_manager_s10.c | 18 +-
arch/arm/mach-socfpga/scan_manager.c | 6 +-
arch/arm/mach-socfpga/spl_a10.c | 5 +-
arch/arm/mach-socfpga/spl_gen5.c | 11 +-
arch/arm/mach-socfpga/spl_s10.c | 12 +-
arch/arm/mach-socfpga/system_manager_gen5.c | 38 ++--
arch/arm/mach-socfpga/system_manager_s10.c| 39 ++--
arch/arm/mach-socfpga/wrap_pll_config_s10.c | 11 +-
drivers/ddr/altera/sdram_gen5.c | 10 +-
drivers/ddr/altera/sdram_s10.c| 6 +-
drivers/fpga/socfpga_arria10.c| 7 +-
drivers/fpga/socfpga_gen5.c | 4 +-
drivers/mmc/socfpga_dw_mmc.c | 6 +-
25 files changed, 240 insertions(+), 422 deletions(-)
diff --git a/arch/arm/mach-socfpga/clock_manager_s10.c
b/arch/arm/mach-socfpga/clock_manager_s10.c
index 3ba2a00c02..6cbf07ac6f 100644
--- a/arch/arm/mach-socfpga/clock_manager_s10.c
+++ b/arch/arm/mach-socfpga/clock_manager_s10.c
@@ -14,8 +14,6 @@ DECLARE_GLOBAL_DATA_PTR;
static const struct socfpga_clock_manager *clock_manager_base =
(struct socfpga_clock_manager *)SOCFPGA_CLKMGR_ADDRESS;
-static const struct socfpga_system_manager *sysmgr_regs =
- (struct socfpga_system_manager *)SOCFPGA_SYSMGR_ADDRESS;
/*
* function to write the bypass register which requires a poll of the
@@ -351,7 +349,7 @@ unsigned int cm_get_l4_sp_clk_hz(void)
unsigned int cm_get_qspi_controller_clk_hz(void)
{
- return readl(&sysmgr_regs->boot_scratch_cold0);
+ return readl(socfpga_sysmgr_base + SYSMGR_S10_BOOT_SCRATCH_COLD0);
}
unsigned int cm_get_spi_controller_clk_hz(void)
diff --git a/arch/arm/mach-socfpga/include/mach/system_manager.h
b/arch/arm/mach-socfpga/include/mach/system_manager.h
index 7e76df74b7..803305eb35 100644
--- a/arch/arm/mach-socfpga/include/mach/system_manager.h
+++ b/arch/arm/mach-socfpga/include/mach/system_manager.h
@@ -6,6 +6,8 @@
#ifndef _SYSTEM_MANAGER_H_
#define _SYSTEM_MANAGER_H_
+extern phys_addr_t socfpga_sysmgr_base;
+
#if defined(CONFIG_TARGET_SOCFPGA_STRATIX10)
#include
#else
diff --git a/arch/arm/mach-socfpga/include/mach/system_manager_arria10.h
b/arch/arm/mach-socfpga/include/mach/system_manager_arria10.h
index 14052b957c..1a45c0f134 100644
--- a/arch/arm/mach-socfpga/include/mach/system_manager_arria10.h
+++ b/arch/arm/mach-socfpga/include/mach/system_manager_arria10.h
@@ -6,73 +6,33 @@
#ifndef _SYSTEM_MANAGER_ARRIA10_H_
#define _SYSTEM_MANAGER_ARRIA10_H_
-struct socfpga_system_manager {
- u32 siliconid1;
- u32 siliconid2;
- u32 wddbg;
- u32 bootinfo;
- u32 mpu_ctrl_l2_ecc;
- u32 _pad_0x14_0x1f[3];
- u32 dma;
- u32 dma_periph;
- u32 sdmmcgrp_ctrl;
- u32 sdmmc_l3master;
- u32 nand_bootstrap;
- u32 nand_l3master;
- u32 usb0_l3master;
- u32 usb1_l3master;
- u32 emac_global;
- u32 emac[3];
- u32 _pad_0x50_0x5f[4];
- u32 fpgaintf_en_global;
- u32 fpgaintf_en_0;
- u32 fpgaintf_en_1;
- u32 fpgaintf_en_2;
- u32 fpgaintf_en_3;
- u32 _pad_0x74_0x7f[3];
- u32 noc_addr_remap_value;
- u32 noc_addr_remap_set;
- u32 noc_addr_remap_clear;
- u32 _pad_0x8c_0x8f;
- u32 ecc_intmask_value;
- u32 ecc_intmask_set;
- u32 ecc_intmask_clr;
- u32 ecc_intstatus_serr;
- u32 ecc_intstatus_derr;
- u32 mpu_status_l2_ecc;
- u32 mpu_clear_l2_ecc;
- u32 mpu_status_l1_parity;
- u32 mpu_clear_l1_parity;
- u32 mpu_set_l1_parity;
- u32 _pad_0xb8_0xbf[2];
- u32 noc_timeout;
- u32 noc_idlereq_set;
- u32 noc_idlereq_clr;
- u32 noc_idlereq_value;
- u32 noc_idleack;
- u32 noc_idlestatus;
- u32 fpga2soc_ctrl;
- u32 _pad_0xdc_0xff[9];
- u32 tsmc_tsel_0;
- u32 tsmc_tsel_1;
- u32 tsmc_tsel_2;
- u32 tsmc_tsel_3;
- u32 _pad_0x
[U-Boot] [PATCH v2 2/4] arm: socfpga: Convert reset manager from struct to defines
Convert reset manager for Gen5, Arria 10 and Stratix 10 from struct
to defines.
No functional change.
Signed-off-by: Ley Foon Tan
---
v2:
- Get base address from DT
- Change to use writel(), readl(), setbits_le32() and clrbits_le32().
- Add prefix to defines.
---
arch/arm/mach-socfpga/include/mach/misc.h | 1 +
.../mach-socfpga/include/mach/reset_manager.h | 2 +
.../include/mach/reset_manager_arria10.h | 43 -
.../include/mach/reset_manager_gen5.h | 22 -
.../include/mach/reset_manager_s10.h | 33 ++---
arch/arm/mach-socfpga/misc.c | 32 +
arch/arm/mach-socfpga/misc_gen5.c | 7 ++-
arch/arm/mach-socfpga/reset_manager_arria10.c | 47 ++-
arch/arm/mach-socfpga/reset_manager_gen5.c| 28 +--
arch/arm/mach-socfpga/reset_manager_s10.c | 34 +++---
arch/arm/mach-socfpga/spl_a10.c | 7 ++-
arch/arm/mach-socfpga/spl_gen5.c | 12 ++---
arch/arm/mach-socfpga/spl_s10.c | 12 +++--
drivers/sysreset/sysreset_socfpga.c | 6 +--
14 files changed, 137 insertions(+), 149 deletions(-)
diff --git a/arch/arm/mach-socfpga/include/mach/misc.h
b/arch/arm/mach-socfpga/include/mach/misc.h
index 27d0b6a370..a29b049742 100644
--- a/arch/arm/mach-socfpga/include/mach/misc.h
+++ b/arch/arm/mach-socfpga/include/mach/misc.h
@@ -41,5 +41,6 @@ void socfpga_sdram_remap_zero(void);
void do_bridge_reset(int enable, unsigned int mask);
void socfpga_pl310_clear(void);
+void socfpga_get_manager_addr(void);
#endif /* _MISC_H_ */
diff --git a/arch/arm/mach-socfpga/include/mach/reset_manager.h
b/arch/arm/mach-socfpga/include/mach/reset_manager.h
index 6ad037e325..a5b6931350 100644
--- a/arch/arm/mach-socfpga/include/mach/reset_manager.h
+++ b/arch/arm/mach-socfpga/include/mach/reset_manager.h
@@ -6,6 +6,8 @@
#ifndef _RESET_MANAGER_H_
#define _RESET_MANAGER_H_
+extern phys_addr_t socfpga_rstmgr_base;
+
void reset_cpu(ulong addr);
void socfpga_per_reset(u32 reset, int set);
diff --git a/arch/arm/mach-socfpga/include/mach/reset_manager_arria10.h
b/arch/arm/mach-socfpga/include/mach/reset_manager_arria10.h
index 6623ebee65..41169aa677 100644
--- a/arch/arm/mach-socfpga/include/mach/reset_manager_arria10.h
+++ b/arch/arm/mach-socfpga/include/mach/reset_manager_arria10.h
@@ -14,40 +14,15 @@ int socfpga_reset_deassert_bridges_handoff(void);
void socfpga_reset_deassert_osc1wd0(void);
int socfpga_bridges_reset(void);
-struct socfpga_reset_manager {
- u32 stat;
- u32 ramstat;
- u32 miscstat;
- u32 ctrl;
- u32 hdsken;
- u32 hdskreq;
- u32 hdskack;
- u32 counts;
- u32 mpumodrst;
- u32 per0modrst;
- u32 per1modrst;
- u32 brgmodrst;
- u32 sysmodrst;
- u32 coldmodrst;
- u32 nrstmodrst;
- u32 dbgmodrst;
- u32 mpuwarmmask;
- u32 per0warmmask;
- u32 per1warmmask;
- u32 brgwarmmask;
- u32 syswarmmask;
- u32 nrstwarmmask;
- u32 l3warmmask;
- u32 tststa;
- u32 tstscratch;
- u32 hdsktimeout;
- u32 hmcintr;
- u32 hmcintren;
- u32 hmcintrens;
- u32 hmcintrenr;
- u32 hmcgpout;
- u32 hmcgpin;
-};
+#define RSTMGR_A10_STATUS 0
+#define RSTMGR_A10_CTRL0xc
+#define RSTMGR_A10_MPUMODRST 0x20
+#define RSTMGR_A10_PER0MODRST 0x24
+#define RSTMGR_A10_PER1MODRST 0x28
+#define RSTMGR_A10_BRGMODRST 0x2c
+#define RSTMGR_A10_SYSMODRST 0x30
+
+#define RSTMGR_CTRLRSTMGR_A10_CTRL
/*
* SocFPGA Arria10 reset IDs, bank mapping is as follows:
diff --git a/arch/arm/mach-socfpga/include/mach/reset_manager_gen5.h
b/arch/arm/mach-socfpga/include/mach/reset_manager_gen5.h
index f4dcb14623..e51ebfd08f 100644
--- a/arch/arm/mach-socfpga/include/mach/reset_manager_gen5.h
+++ b/arch/arm/mach-socfpga/include/mach/reset_manager_gen5.h
@@ -11,19 +11,15 @@
void socfpga_bridges_set_handoff_regs(bool h2f, bool lwh2f, bool f2h);
void socfpga_bridges_reset(int enable);
-struct socfpga_reset_manager {
- u32 status;
- u32 ctrl;
- u32 counts;
- u32 padding1;
- u32 mpu_mod_reset;
- u32 per_mod_reset;
- u32 per2_mod_reset;
- u32 brg_mod_reset;
- u32 misc_mod_reset;
- u32 padding2[12];
- u32 tstscratch;
-};
+#define RSTMGR_GEN5_STATUS 0
+#define RSTMGR_GEN5_CTRL 4
+#define RSTMGR_GEN5_MPUMODRST 0x10
+#define RSTMGR_GEN5_PERMODRST 0x14
+#define RSTMGR_GEN5_PER2MODRST 0x18
+#define RSTMGR_GEN5_BRGMODRST 0x1c
+#define RSTMGR_GEN5_MISCMODRST 0x20
+
+#define RSTMGR_CTRLRSTMGR_GEN5_CTRL
/*
* SocFPGA Cyclone V/Arria V reset IDs, bank mapping is as follows:
diff --git a/arch/arm/mach-socfpga/inclu
[U-Boot] [PATCH v2 4/4] arm: socfpga: Convert clock manager from struct to defines
Convert clock manager for Gen5, Arria 10 and Stratix 10 from struct
to defines.
No functional change.
Signed-off-by: Ley Foon Tan
---
v2:
- Change to use writel(), readl() and etc.
- Get base address from DT.
- Add prefix to defines.
---
arch/arm/mach-socfpga/clock_manager.c | 12 +-
arch/arm/mach-socfpga/clock_manager_arria10.c | 156 +++--
arch/arm/mach-socfpga/clock_manager_gen5.c| 199 +
arch/arm/mach-socfpga/clock_manager_s10.c | 206 ++
.../mach-socfpga/include/mach/clock_manager.h | 2 +
.../include/mach/clock_manager_arria10.h | 133 +--
.../include/mach/clock_manager_gen5.h | 112 --
.../include/mach/clock_manager_s10.h | 115 --
arch/arm/mach-socfpga/misc.c | 5 +
drivers/mmc/socfpga_dw_mmc.c | 11 +-
10 files changed, 476 insertions(+), 475 deletions(-)
diff --git a/arch/arm/mach-socfpga/clock_manager.c
b/arch/arm/mach-socfpga/clock_manager.c
index 9f3c643df8..09857dc37b 100644
--- a/arch/arm/mach-socfpga/clock_manager.c
+++ b/arch/arm/mach-socfpga/clock_manager.c
@@ -10,18 +10,15 @@
DECLARE_GLOBAL_DATA_PTR;
-static const struct socfpga_clock_manager *clock_manager_base =
- (struct socfpga_clock_manager *)SOCFPGA_CLKMGR_ADDRESS;
-
void cm_wait_for_lock(u32 mask)
{
u32 inter_val;
u32 retry = 0;
do {
#if defined(CONFIG_TARGET_SOCFPGA_GEN5)
- inter_val = readl(&clock_manager_base->inter) & mask;
+ inter_val = readl(socfpga_clkmgr_base + CLKMGR_INTER) & mask;
#else
- inter_val = readl(&clock_manager_base->stat) & mask;
+ inter_val = readl(socfpga_clkmgr_base + CLKMGR_STAT) & mask;
#endif
/* Wait for stable lock */
if (inter_val == mask)
@@ -36,8 +33,9 @@ void cm_wait_for_lock(u32 mask)
/* function to poll in the fsm busy bit */
int cm_wait_for_fsm(void)
{
- return wait_for_bit_le32(&clock_manager_base->stat,
-CLKMGR_STAT_BUSY, false, 2, false);
+ return wait_for_bit_le32((const void *)(socfpga_clkmgr_base +
+CLKMGR_STAT), CLKMGR_STAT_BUSY, false, 2,
+false);
}
int set_cpu_clk_info(void)
diff --git a/arch/arm/mach-socfpga/clock_manager_arria10.c
b/arch/arm/mach-socfpga/clock_manager_arria10.c
index 334a79fd9c..33aebd4f47 100644
--- a/arch/arm/mach-socfpga/clock_manager_arria10.c
+++ b/arch/arm/mach-socfpga/clock_manager_arria10.c
@@ -231,9 +231,6 @@ static int of_get_clk_cfg(const void *blob, struct
mainpll_cfg *main_cfg,
return 0;
}
-static const struct socfpga_clock_manager *clock_manager_base =
- (struct socfpga_clock_manager *)SOCFPGA_CLKMGR_ADDRESS;
-
/* calculate the intended main VCO frequency based on handoff */
static unsigned int cm_calc_handoff_main_vco_clk_hz
(struct mainpll_cfg *main_cfg)
@@ -551,12 +548,13 @@ static void cm_pll_ramp_main(struct mainpll_cfg *main_cfg,
writel((main_cfg->vco1_denom <<
CLKMGR_MAINPLL_VCO1_DENOM_LSB) |
cm_calc_safe_pll_numer(0, main_cfg, per_cfg, clk_hz),
- &clock_manager_base->main_pll.vco1);
+ socfpga_clkmgr_base + CLKMGR_A10_MAINPLL_VCO1);
mdelay(1);
cm_wait_for_lock(LOCKED_MASK);
}
writel((main_cfg->vco1_denom << CLKMGR_MAINPLL_VCO1_DENOM_LSB) |
- main_cfg->vco1_numer, &clock_manager_base->main_pll.vco1);
+ main_cfg->vco1_numer,
+ socfpga_clkmgr_base + CLKMGR_A10_MAINPLL_VCO1);
mdelay(1);
cm_wait_for_lock(LOCKED_MASK);
}
@@ -579,14 +577,17 @@ static void cm_pll_ramp_periph(struct mainpll_cfg
*main_cfg,
/* execute the ramping here */
for (clk_hz = pll_ramp_periph_hz + clk_incr_hz;
clk_hz < clk_final_hz; clk_hz += clk_incr_hz) {
- writel((per_cfg->vco1_denom << CLKMGR_PERPLL_VCO1_DENOM_LSB) |
- cm_calc_safe_pll_numer(1, main_cfg, per_cfg, clk_hz),
- &clock_manager_base->per_pll.vco1);
+ writel((per_cfg->vco1_denom <<
+ CLKMGR_PERPLL_VCO1_DENOM_LSB) |
+ cm_calc_safe_pll_numer(1, main_cfg, per_cfg,
+clk_hz),
+ socfpga_clkmgr_base + CLKMGR_A10_PERPLL_VCO1);
mdelay(1);
cm_wait_for_lock(LOCKED_MASK);
}
writel((per_cfg->vco1_denom << CLKMGR_PERPLL_VCO1_DENOM_LSB) |
- per_cfg->vco1_numer, &clock_manager_base->per_pll.vco1);
+ per_cfg->vco1_numer,
+ socfpga_clkmgr_base + CLKMGR_A10_PERPLL_VCO1);
mdelay(1);
cm_wait_for_lock(LOCKED_MASK);
}
@@ -638,16 +6
[U-Boot] [PATCH v2 1/4] arm: dts: socfpga: Add u-boot, dm-pre-reloc for sysmgr and clkmgr nodes
Add u-boot,dm-pre-reloc for sysmgr and clkmgr nodes to use it in SPL.
In preparation to get base address from DT.
Signed-off-by: Ley Foon Tan
---
arch/arm/dts/socfpga-common-u-boot.dtsi | 8
arch/arm/dts/socfpga.dtsi| 2 +-
arch/arm/dts/socfpga_arria10.dtsi| 2 +-
arch/arm/dts/socfpga_arria10_socdk.dtsi | 8
arch/arm/dts/socfpga_stratix10.dtsi | 2 +-
arch/arm/dts/socfpga_stratix10_socdk-u-boot.dtsi | 8
6 files changed, 27 insertions(+), 3 deletions(-)
diff --git a/arch/arm/dts/socfpga-common-u-boot.dtsi
b/arch/arm/dts/socfpga-common-u-boot.dtsi
index 322c858c4b..d55460755f 100644
--- a/arch/arm/dts/socfpga-common-u-boot.dtsi
+++ b/arch/arm/dts/socfpga-common-u-boot.dtsi
@@ -10,6 +10,10 @@
};
};
+&clkmgr {
+ u-boot,dm-pre-reloc;
+};
+
&rst {
u-boot,dm-pre-reloc;
};
@@ -17,3 +21,7 @@
&sdr {
u-boot,dm-pre-reloc;
};
+
+&sysmgr {
+ u-boot,dm-pre-reloc;
+};
diff --git a/arch/arm/dts/socfpga.dtsi b/arch/arm/dts/socfpga.dtsi
index 51a6a51b53..eda558f2fe 100644
--- a/arch/arm/dts/socfpga.dtsi
+++ b/arch/arm/dts/socfpga.dtsi
@@ -114,7 +114,7 @@
status = "disabled";
};
- clkmgr@ffd04000 {
+ clkmgr: clkmgr@ffd04000 {
compatible = "altr,clk-mgr";
reg = <0xffd04000 0x1000>;
diff --git a/arch/arm/dts/socfpga_arria10.dtsi
b/arch/arm/dts/socfpga_arria10.dtsi
index c11a5c0cc1..cc529bcd11 100644
--- a/arch/arm/dts/socfpga_arria10.dtsi
+++ b/arch/arm/dts/socfpga_arria10.dtsi
@@ -96,7 +96,7 @@
fpga-mgr = <&fpga_mgr>;
};
- clkmgr@ffd04000 {
+ clkmgr: clkmgr@ffd04000 {
compatible = "altr,clk-mgr";
reg = <0xffd04000 0x1000>;
u-boot,dm-pre-reloc;
diff --git a/arch/arm/dts/socfpga_arria10_socdk.dtsi
b/arch/arm/dts/socfpga_arria10_socdk.dtsi
index 6e5578d7bd..ef10708ee8 100644
--- a/arch/arm/dts/socfpga_arria10_socdk.dtsi
+++ b/arch/arm/dts/socfpga_arria10_socdk.dtsi
@@ -180,3 +180,11 @@
&l4_sp_clk {
u-boot,dm-pre-reloc;
};
+
+&clkmgr {
+ u-boot,dm-pre-reloc;
+};
+
+&sysmgr {
+ u-boot,dm-pre-reloc;
+};
diff --git a/arch/arm/dts/socfpga_stratix10.dtsi
b/arch/arm/dts/socfpga_stratix10.dtsi
index bd68a78a37..91f4e27ef5 100755
--- a/arch/arm/dts/socfpga_stratix10.dtsi
+++ b/arch/arm/dts/socfpga_stratix10.dtsi
@@ -82,7 +82,7 @@
ranges = <0 0 0 0x>;
u-boot,dm-pre-reloc;
- clkmgr@ffd1000 {
+ clkmgr: clkmgr@ffd1000 {
compatible = "altr,clk-mgr";
reg = <0xffd1 0x1000>;
};
diff --git a/arch/arm/dts/socfpga_stratix10_socdk-u-boot.dtsi
b/arch/arm/dts/socfpga_stratix10_socdk-u-boot.dtsi
index e1cfb522bf..38855aecd7 100755
--- a/arch/arm/dts/socfpga_stratix10_socdk-u-boot.dtsi
+++ b/arch/arm/dts/socfpga_stratix10_socdk-u-boot.dtsi
@@ -11,6 +11,10 @@
};
};
+&clkmgr {
+ u-boot,dm-pre-reloc;
+};
+
&qspi {
status = "okay";
u-boot,dm-pre-reloc;
@@ -23,3 +27,7 @@
spi-rx-bus-width = <4>;
u-boot,dm-pre-reloc;
};
+
+&sysmgr {
+ u-boot,dm-pre-reloc;
+};
--
2.19.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 0/4] arm: socfpga: Convert drivers from struct to defines
This is 2nd version of patchset to convert reset, system and clock manager drivers to use #define instead of struct. Tested on Cyclone 5, Arria 10 and Stratix 10 devices. Patch 1 is new one, patch 2 to 4 have changes. Main changes in this version are: - Get base address from DT - Change to use writel(), readl(), setbits_le32() and clrbits_le32(). - Add prefix to defines. - Add "u-boot,dm-pre-reloc" to clock and system manager nodes. History: v1: https://patchwork.ozlabs.org/cover/1149731/ Ley Foon Tan (4): arm: dts: socfpga: Add u-boot,dm-pre-reloc for sysmgr and clkmgr nodes arm: socfpga: Convert reset manager from struct to defines arm: socfpga: Convert system manager from struct to defines arm: socfpga: Convert clock manager from struct to defines arch/arm/dts/socfpga-common-u-boot.dtsi | 8 + arch/arm/dts/socfpga.dtsi | 2 +- arch/arm/dts/socfpga_arria10.dtsi | 2 +- arch/arm/dts/socfpga_arria10_socdk.dtsi | 8 + arch/arm/dts/socfpga_stratix10.dtsi | 2 +- .../dts/socfpga_stratix10_socdk-u-boot.dtsi | 8 + arch/arm/mach-socfpga/clock_manager.c | 12 +- arch/arm/mach-socfpga/clock_manager_arria10.c | 156 +++-- arch/arm/mach-socfpga/clock_manager_gen5.c| 199 + arch/arm/mach-socfpga/clock_manager_s10.c | 210 ++ .../mach-socfpga/include/mach/clock_manager.h | 2 + .../include/mach/clock_manager_arria10.h | 133 +-- .../include/mach/clock_manager_gen5.h | 112 -- .../include/mach/clock_manager_s10.h | 115 -- arch/arm/mach-socfpga/include/mach/misc.h | 1 + .../mach-socfpga/include/mach/reset_manager.h | 2 + .../include/mach/reset_manager_arria10.h | 43 +--- .../include/mach/reset_manager_gen5.h | 22 +- .../include/mach/reset_manager_s10.h | 33 +-- .../include/mach/system_manager.h | 2 + .../include/mach/system_manager_arria10.h | 94 +++- .../include/mach/system_manager_gen5.h| 123 ++ .../include/mach/system_manager_s10.h | 184 ++- arch/arm/mach-socfpga/mailbox_s10.c | 6 +- arch/arm/mach-socfpga/misc.c | 42 arch/arm/mach-socfpga/misc_arria10.c | 9 +- arch/arm/mach-socfpga/misc_gen5.c | 29 +-- arch/arm/mach-socfpga/misc_s10.c | 9 +- arch/arm/mach-socfpga/reset_manager_arria10.c | 71 +++--- arch/arm/mach-socfpga/reset_manager_gen5.c| 35 ++- arch/arm/mach-socfpga/reset_manager_s10.c | 52 +++-- arch/arm/mach-socfpga/scan_manager.c | 6 +- arch/arm/mach-socfpga/spl_a10.c | 12 +- arch/arm/mach-socfpga/spl_gen5.c | 23 +- arch/arm/mach-socfpga/spl_s10.c | 24 +- arch/arm/mach-socfpga/system_manager_gen5.c | 38 ++-- arch/arm/mach-socfpga/system_manager_s10.c| 39 ++-- arch/arm/mach-socfpga/wrap_pll_config_s10.c | 11 +- drivers/ddr/altera/sdram_gen5.c | 10 +- drivers/ddr/altera/sdram_s10.c| 6 +- drivers/fpga/socfpga_arria10.c| 7 +- drivers/fpga/socfpga_gen5.c | 4 +- drivers/mmc/socfpga_dw_mmc.c | 17 +- drivers/sysreset/sysreset_socfpga.c | 6 +- 44 files changed, 880 insertions(+), 1049 deletions(-) -- 2.19.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] ARM: mxs: spl_boot.c: make early_delay more robust
It's true that booting normally doesn't take long enough for the
register to roll (which actually happens in a little over an hour, not
just a few seconds). However, the counter starts at power-on, and if
the board is held in reset to be booted over USB, one actually risks
hitting wrap-around during boot, which can both result in too short
delays (if the "st += delay" calculation makes st small) and
theoretically also unbound delays (if st ends up being UINT_MAX and
one just misses sampling digctl_microseconds at that point).
It doesn't take more code to DTRT, and once bitten, twice shy.
Signed-off-by: Rasmus Villemoes
---
arch/arm/cpu/arm926ejs/mxs/spl_boot.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/arch/arm/cpu/arm926ejs/mxs/spl_boot.c
b/arch/arm/cpu/arm926ejs/mxs/spl_boot.c
index cb361ac65c..336266fe82 100644
--- a/arch/arm/cpu/arm926ejs/mxs/spl_boot.c
+++ b/arch/arm/cpu/arm926ejs/mxs/spl_boot.c
@@ -24,9 +24,7 @@ static bd_t bdata __section(".data");
/*
* This delay function is intended to be used only in early stage of boot,
where
- * clock are not set up yet. The timer used here is reset on every boot and
- * takes a few seconds to roll. The boot doesn't take that long, so to keep the
- * code simple, it doesn't take rolling into consideration.
+ * clock are not set up yet.
*/
void early_delay(int delay)
{
@@ -34,8 +32,7 @@ void early_delay(int delay)
(struct mxs_digctl_regs *)MXS_DIGCTL_BASE;
uint32_t st = readl(&digctl_regs->hw_digctl_microseconds);
- st += delay;
- while (st > readl(&digctl_regs->hw_digctl_microseconds))
+ while (readl(&digctl_regs->hw_digctl_microseconds) - st <= delay)
;
}
--
2.20.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] U-Boot: Environment flags broken for U-Boot
Dear Tom, In message <20190909210130.GU6927@bill-the-cat> you wrote: > > On Wed, Sep 04, 2019 at 01:30:02PM -0500, Joe Hershberger wrote: ... > > I would gladly volunteer for this role if Wolfgang would co-maintain > > to keep me in line. He seems to have an uncanny ability to keep all > > the cases in his head. > > Wolfgang, what do you say? It's certainly an area we could use a > custodian in. I would be happy if someone takes care of this - thanks, Hoe for volunteering! As for co-maintaining: for the last 7 years my available time has always been considerably smaller than my interest in U-Boot, and it would be not realistic to believe this would be changing any time soon, sic! Yes, I'm willing, but I cant guarrantee any bandwidth nor response times. I can just try... Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Business is like a wheelbarrow. Nothing ever happens until you start pushing. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v1 4/4] x86: tangier: Use spaces over TABs in ASL code
On Tue, Sep 10, 2019 at 4:14 PM Bin Meng wrote: > > On Thu, Aug 29, 2019 at 10:04 PM Andy Shevchenko > wrote: > > > > For sake of consistency use spaces over TABs in ASL code. > > > > Signed-off-by: Andy Shevchenko > > --- > > .../asm/arch-tangier/acpi/southcluster.asl| 26 +-- > > 1 file changed, 13 insertions(+), 13 deletions(-) > > > > Reviewed-by: Bin Meng applied to u-boot-x86, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RFC][PATCH] bootcount: add support to customize bootcount variable name
Dear Philippe, In message <992029351.2212296.1568047262683.javamail.zim...@softathome.com> you wrote: > > I have severals layers in my boot chain, and I want to use bootcount > in severals layers to manage boot issues. If severals layers use the > same variable name (bootcount) and a boot issue happen, I can't find > the layer that fails. I can't understand your problem description, sorry. > So I propose to "customize" the bootcount variable name. This makes no sense to me. > As it is "unique", I can't chain severals bootcount. > That's why I propose an option to customize the bootcount name variable. But that's the actual situation: there is only one boot count. Please keep in mind that this variable holds the number of boot attepmts since the last power-on that failed to successfully reach a specific "confirmation point" in your application (that, which is considered a complete, successfull boot of the whole system). For this single task there can be only a single counter, or? > I know that it's a "corner case" and that you could prefer to avoid > adding another option, that's why I've proposed this option as a RFC. I do not see any practical use yet... Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de READ THIS BEFORE OPENING PACKAGE: According to Certain Suggested Ver- sions of the Grand Unified Theory, the Primary Particles Constituting this Product May Decay to Nothingness Within the Next Four Hundred Million Years. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v1 3/4] x86: tangier: Fix off-by-one error when preparing CSRT
On Tue, Sep 10, 2019 at 4:14 PM Bin Meng wrote:
>
> On Thu, Aug 29, 2019 at 10:04 PM Andy Shevchenko
> wrote:
> >
> > Intel iDMA 32-bit controller has 17 bits for the maximum block size value.
> > Due to nature of the binary number representation the maximum value is
> > 2^17 - 1. The original code misses the latter part in equation.
> >
> > Fixes: 5e99fde34a77 ("x86: tangier: Populate CSRT for shared DMA
> > controller")
> > Signed-off-by: Andy Shevchenko
> > ---
> > arch/x86/cpu/tangier/acpi.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
>
> Reviewed-by: Bin Meng
applied to u-boot-x86, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [v2, 0/3] mmc: fsl_esdhc: clean up code
Hi Peng, Any comments on this patch-set? Thanks a lot. Best regards, Yangbo Lu > -Original Message- > From: Yangbo Lu > Sent: Friday, September 6, 2019 2:05 PM > To: u-boot@lists.denx.de; Peng Fan > Cc: Y.b. Lu > Subject: [v2, 0/3] mmc: fsl_esdhc: clean up code > > This patch-set is to clean up fsl_esdhc code. > > Changes for v2: > - Involved esdhc_ops in non-DM conditional build. > > Yangbo Lu (3): > mmc: fsl_esdhc: make BLK as hard requirement of DM_MMC > mmc: fsl_esdhc: clean up code > mmc: fsl_esdhc: rename fsl_esdhc_init to fsl_esdhc_get_cfg > > drivers/mmc/fsl_esdhc.c | 369 > +++- > include/fsl_esdhc.h | 203 -- > 2 files changed, 240 insertions(+), 332 deletions(-) > > -- > 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v1 2/4] x86: tangier: Reserve PCI ECAM in motherboard resources
On Tue, Sep 10, 2019 at 4:14 PM Bin Meng wrote:
>
> On Thu, Aug 29, 2019 at 10:04 PM Andy Shevchenko
> wrote:
> >
> > Per PCI firmware specification the ACPI has to reserve the memory
> > which is defined as PCI ECAM.
> >
> > Fixes: 39665beed6f7 ("x86: tangier: Enable ACPI support for Intel Tangier")
> > Signed-off-by: Andy Shevchenko
> > ---
> > arch/x86/cpu/tangier/acpi.c | 3 ++-
> > .../include/asm/arch-tangier/acpi/platform.asl | 1 +
> > .../asm/arch-tangier/acpi/southcluster.asl | 17 +
> > arch/x86/include/asm/arch-tangier/iomap.h | 10 ++
> > 4 files changed, 30 insertions(+), 1 deletion(-)
> > create mode 100644 arch/x86/include/asm/arch-tangier/iomap.h
> >
>
> Reviewed-by: Bin Meng
applied to u-boot-x86, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v1 1/4] x86: acpi: Annotate struct acpi_table_header with __packed
On Tue, Sep 10, 2019 at 4:14 PM Bin Meng wrote: > > Hi Andy, > > On Thu, Aug 29, 2019 at 10:29 PM Andy Shevchenko > wrote: > > > > On Thu, Aug 29, 2019 at 5:13 PM Bin Meng wrote: > > > > > > Hi Andy, > > > > > > On Thu, Aug 29, 2019 at 10:04 PM Andy Shevchenko > > > wrote: > > > > > > > > GCC starts complaining about possible pointer misalignment of pointers > > > > to the > > > > > > Which GCC version? > > > > gcc (Debian 9.2.1-4) 9.2.1 20190821 > > Copyright (C) 2019 Free Software Foundation, Inc. > > > > I will add such information in the commit message when applying. > Reviewed-by: Bin Meng > applied to u-boot-x86, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v1 4/4] x86: tangier: Use spaces over TABs in ASL code
On Thu, Aug 29, 2019 at 10:04 PM Andy Shevchenko wrote: > > For sake of consistency use spaces over TABs in ASL code. > > Signed-off-by: Andy Shevchenko > --- > .../asm/arch-tangier/acpi/southcluster.asl| 26 +-- > 1 file changed, 13 insertions(+), 13 deletions(-) > Reviewed-by: Bin Meng ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v1 2/4] x86: tangier: Reserve PCI ECAM in motherboard resources
On Thu, Aug 29, 2019 at 10:04 PM Andy Shevchenko
wrote:
>
> Per PCI firmware specification the ACPI has to reserve the memory
> which is defined as PCI ECAM.
>
> Fixes: 39665beed6f7 ("x86: tangier: Enable ACPI support for Intel Tangier")
> Signed-off-by: Andy Shevchenko
> ---
> arch/x86/cpu/tangier/acpi.c | 3 ++-
> .../include/asm/arch-tangier/acpi/platform.asl | 1 +
> .../asm/arch-tangier/acpi/southcluster.asl | 17 +
> arch/x86/include/asm/arch-tangier/iomap.h | 10 ++
> 4 files changed, 30 insertions(+), 1 deletion(-)
> create mode 100644 arch/x86/include/asm/arch-tangier/iomap.h
>
Reviewed-by: Bin Meng
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v1 3/4] x86: tangier: Fix off-by-one error when preparing CSRT
On Thu, Aug 29, 2019 at 10:04 PM Andy Shevchenko
wrote:
>
> Intel iDMA 32-bit controller has 17 bits for the maximum block size value.
> Due to nature of the binary number representation the maximum value is
> 2^17 - 1. The original code misses the latter part in equation.
>
> Fixes: 5e99fde34a77 ("x86: tangier: Populate CSRT for shared DMA controller")
> Signed-off-by: Andy Shevchenko
> ---
> arch/x86/cpu/tangier/acpi.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
Reviewed-by: Bin Meng
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v1 1/4] x86: acpi: Annotate struct acpi_table_header with __packed
Hi Andy, On Thu, Aug 29, 2019 at 10:29 PM Andy Shevchenko wrote: > > On Thu, Aug 29, 2019 at 5:13 PM Bin Meng wrote: > > > > Hi Andy, > > > > On Thu, Aug 29, 2019 at 10:04 PM Andy Shevchenko > > wrote: > > > > > > GCC starts complaining about possible pointer misalignment of pointers to > > > the > > > > Which GCC version? > > gcc (Debian 9.2.1-4) 9.2.1 20190821 > Copyright (C) 2019 Free Software Foundation, Inc. > I will add such information in the commit message when applying. Reviewed-by: Bin Meng Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] Convert CONFIG_SYS_FSL_ESDHC_HAS_DDR_MODE to Kconfig
Hi, > -Original Message- > From: Peng Fan > Sent: Tuesday, September 10, 2019 9:29 AM > To: Sébastien Szymanski ; > u-boot@lists.denx.de; Y.b. Lu > Cc: Fabio Estevam ; Otavio Salvador > > Subject: RE: [PATCH 1/2] Convert CONFIG_SYS_FSL_ESDHC_HAS_DDR_MODE > to Kconfig > > +Y.b > > > -Original Message- > > From: Sébastien Szymanski > > Sent: 2019年9月9日 14:36 > > To: Peng Fan ; u-boot@lists.denx.de > > Cc: Fabio Estevam ; Otavio Salvador > > > > Subject: Re: [PATCH 1/2] Convert CONFIG_SYS_FSL_ESDHC_HAS_DDR_MODE > to > > Kconfig > > > > Hello, > > > > On 9/9/19 3:59 AM, Peng Fan wrote: > > >> Subject: [PATCH 1/2] Convert CONFIG_SYS_FSL_ESDHC_HAS_DDR_MODE > > to > > >> Kconfig > > >> > > >> This converts the following to Kconfig: > > >> > > >> CONFIG_SYS_FSL_ESDHC_HAS_DDR_MODE > > >> > > >> Signed-off-by: Sébastien Szymanski > > > > >> --- > > >> configs/warp7_defconfig | 1 + > > >> configs/warp_defconfig | 1 + > > >> drivers/mmc/Kconfig | 6 ++ > > >> include/configs/warp.h | 1 - > > >> include/configs/warp7.h | 1 - > > >> scripts/config_whitelist.txt | 1 - > > >> 6 files changed, 8 insertions(+), 3 deletions(-) > > >> > > >> diff --git a/configs/warp7_defconfig b/configs/warp7_defconfig > > >> index > > >> a022454976..9a167d2c43 100644 > > >> --- a/configs/warp7_defconfig > > >> +++ b/configs/warp7_defconfig > > >> @@ -40,6 +40,7 @@ CONFIG_DM_I2C=y > > >> CONFIG_DM_MMC=y > > >> CONFIG_SUPPORT_EMMC_BOOT=y > > >> CONFIG_FSL_USDHC=y > > >> +CONFIG_SYS_FSL_ESDHC_HAS_DDR_MODE=y > > >> CONFIG_PINCTRL=y > > >> CONFIG_PINCTRL_IMX7=y > > >> CONFIG_DM_PMIC=y > > >> diff --git a/configs/warp_defconfig b/configs/warp_defconfig index > > >> 7a6ea6f8c6..d719dc779a 100644 > > >> --- a/configs/warp_defconfig > > >> +++ b/configs/warp_defconfig > > >> @@ -31,6 +31,7 @@ CONFIG_ENV_IS_IN_MMC=y > > CONFIG_DFU_MMC=y > > >> CONFIG_SUPPORT_EMMC_BOOT=y CONFIG_FSL_USDHC=y > > >> +CONFIG_SYS_FSL_ESDHC_HAS_DDR_MODE=y > > >> CONFIG_USB=y > > >> CONFIG_USB_STORAGE=y > > >> CONFIG_USB_GADGET=y > > >> diff --git a/drivers/mmc/Kconfig b/drivers/mmc/Kconfig index > > >> 0ccb1ea701..f61b17b86b 100644 > > >> --- a/drivers/mmc/Kconfig > > >> +++ b/drivers/mmc/Kconfig > > >> @@ -701,6 +701,12 @@ config FSL_USDHC > > >> help > > >>This enables the Ultra Secured Digital Host Controller > > >> enhancements > > >> > > >> +config SYS_FSL_ESDHC_HAS_DDR_MODE > > >> +depends on FSL_ESDHC || FSL_ESDHC_IMX > > > > > > Please drop FSL_ESDHC. > > > > Why ? SYS_FSL_ESDHC_HAS_DDR_MODE is used in fsl_esdhc.c too. > > Y.b, is this currently used by fsl_esdhc.c? [Y.b. Lu] Yes. This was introduced before fsl_esdhc_imx.c was split out. The patch introducing it was as below. 0e1bf61 mmc: fsl_esdhc: Add support for DDR mode This was for i.mx eSDHC actually. I should remove SYS_FSL_ESDHC_HAS_DDR_MODE for fsl_esdhc.c. Although fsl_esdhc supports DDR52, the RCW (reset configure words) for SoC and FPGA should be configured accordingly (for SDHC_CLK_SYNC_OUT/IN signals) to support it. So let me send a patch to remove it. You can feel free to add it in your new version patch too. BTW, I think "mmc-ddr-1_8v" dts property is a good idea instead of config option. Thanks. > > Thanks, > Peng. > > > > > Regards, > > > > > > > > Regards, > > > Peng. > > > > > >> +bool "Enable Dual Data Rate support" > > >> +help > > >> + This enables Dual Data Rate support (DDR52) > > >> + > > >> endmenu > > >> > > >> config SYS_FSL_ERRATUM_ESDHC111 > > >> diff --git a/include/configs/warp.h b/include/configs/warp.h index > > >> 5345f5314d..a00c535b50 100644 > > >> --- a/include/configs/warp.h > > >> +++ b/include/configs/warp.h > > >> @@ -22,7 +22,6 @@ > > >> > > >> /* MMC Configs */ > > >> #define CONFIG_SYS_FSL_ESDHC_ADDR USDHC2_BASE_ADDR > > >> -#define CONFIG_SYS_FSL_ESDHC_HAS_DDR_MODE > > >> > > >> /* Watchdog */ > > >> #define CONFIG_WATCHDOG_TIMEOUT_MSECS 3 /* 30s */ diff > > --git > > >> a/include/configs/warp7.h b/include/configs/warp7.h index > > >> 73541fe176..aa259cd9ef 100644 > > >> --- a/include/configs/warp7.h > > >> +++ b/include/configs/warp7.h > > >> @@ -18,7 +18,6 @@ > > >> > > >> /* MMC Config*/ > > >> #define CONFIG_SYS_FSL_ESDHC_ADDR USDHC3_BASE_ADDR > > >> -#define CONFIG_SYS_FSL_ESDHC_HAS_DDR_MODE > > >> #define CONFIG_SYS_MMC_IMG_LOAD_PART1 > > >> > > >> /* Switch on SERIAL_TAG */ > > >> diff --git a/scripts/config_whitelist.txt > > >> b/scripts/config_whitelist.txt index b18eab1707..49c041b59e 100644 > > >> --- a/scripts/config_whitelist.txt > > >> +++ b/scripts/config_whitelist.txt > > >> @@ -2555,7 +2555,6 @@ CONFIG_SYS_FSL_ERRATUM_A_004934 > > >> CONFIG_SYS_FSL_ESDHC_ADDR CONFIG_SYS_FSL_ESDHC_BE > > >> CONFIG_SYS_FSL_ESDHC_BROKEN_TIMEOUT > > >> -CONFIG_SYS_FSL_ESDHC_HAS_DDR_MODE > > >> CONFIG_SYS_FSL_ESDHC_LE > > >> CONFIG_SYS_FSL_ESDHC_NUM > > >> CONFIG_SYS_FSL_ESDHC_P1010_BROKEN_SDCLK > > >>
Re: [U-Boot] [PATCH] usb: xhci-dwc3: Add support for dis_u2_susphy_quirk
Hi Neil,
On Tue, Sep 10, 2019 at 3:58 PM Neil Armstrong wrote:
>
> Hi Bin, Marek,
>
> On 10/09/2019 03:56, Bin Meng wrote:
> > On Tue, Sep 10, 2019 at 2:52 AM Neil Armstrong
> > wrote:
> >>
> >> This quirk is necessary for the Amlogic GXL SoCs otherwise the
> >> Port 2 PHY doesn't get out of suspend and U-Boot resets the board after:
> >>
> >> XHCI timeout on event type 33... cannot recover.
> >> BUG: failure at drivers/usb/host/xhci-ring.c:474/xhci_wait_for_event()!
> >> BUG!
> >>
> >> This quirk is also handled in the dwc3 core code, but until the
> >> xhci-dwc3 driver uses the dwc3 core, the quirk must be handled here
> >> to fix USB support on the Amlogic libretech-cc and libretech-ac board
> >> when a device is only plugged in the OTG port.
> >>
> >> Cc: Yuri Frolov
> >> Cc: Bin Meng
> >> Fixes: dc9cdf859e ("usb: dwc3: Add DWC3 controller driver support")
> >> Signed-off-by: Neil Armstrong
> >> ---
> >> drivers/usb/host/xhci-dwc3.c | 3 +++
> >> 1 file changed, 3 insertions(+)
> >>
> >
> > Thanks for your efforts tracing this down!
> >
> > Reviewed-by: Bin Meng
> >
>
> Should I take it into my amlogic tree or you'll handle it ?
>
I think you can take it via your tree. Thanks!
Regards,
Bin
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] usb: xhci-dwc3: Add support for dis_u2_susphy_quirk
Hi Bin, Marek,
On 10/09/2019 03:56, Bin Meng wrote:
> On Tue, Sep 10, 2019 at 2:52 AM Neil Armstrong
> wrote:
>>
>> This quirk is necessary for the Amlogic GXL SoCs otherwise the
>> Port 2 PHY doesn't get out of suspend and U-Boot resets the board after:
>>
>> XHCI timeout on event type 33... cannot recover.
>> BUG: failure at drivers/usb/host/xhci-ring.c:474/xhci_wait_for_event()!
>> BUG!
>>
>> This quirk is also handled in the dwc3 core code, but until the
>> xhci-dwc3 driver uses the dwc3 core, the quirk must be handled here
>> to fix USB support on the Amlogic libretech-cc and libretech-ac board
>> when a device is only plugged in the OTG port.
>>
>> Cc: Yuri Frolov
>> Cc: Bin Meng
>> Fixes: dc9cdf859e ("usb: dwc3: Add DWC3 controller driver support")
>> Signed-off-by: Neil Armstrong
>> ---
>> drivers/usb/host/xhci-dwc3.c | 3 +++
>> 1 file changed, 3 insertions(+)
>>
>
> Thanks for your efforts tracing this down!
>
> Reviewed-by: Bin Meng
>
Should I take it into my amlogic tree or you'll handle it ?
Thanks,
Neil
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 2/2] x86: efi_loader: Use efi_add_conventional_memory_map()
Thanks Bin! > -Original Message- > From: Bin Meng [mailto:bmeng...@gmail.com] > Sent: Monday, September 9, 2019 11:31 PM > To: Park, Aiden > Cc: Heinrich Schuchardt ; Alexander Graf > ; u-boot@lists.denx.de > Subject: Re: [PATCH v3 2/2] x86: efi_loader: Use > efi_add_conventional_memory_map() > > On Wed, Sep 4, 2019 at 1:43 AM Park, Aiden wrote: > > > > Use efi_add_conventional_memory_map() to configure EFI conventional > > memory properly with ram_top value. This will give 32bit mode U-Boot > > proper > > nits: 32-bit > > > conventional memory regions even if e820 has a entry which is greater > > than > > nits: an entry > > > 32bit address space. > > 32-bit > > > > > Signed-off-by: Aiden Park > > --- > > Changes in v3: > > * Split a single commit to two relevant commits > > > > Changes in v2: > > * Add efi_add_conventional_memory_map() for common code re-use > > > > arch/x86/lib/e820.c | 17 ++--- > > 1 file changed, 14 insertions(+), 3 deletions(-) > > > > Fixed the above nits, and > > applied to u-boot-x86, thanks! Best Regards, Aiden ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
