Re: [U-Boot] [PATCH v1 03/11] include: kernel.h: include printk.h
On Sat, Oct 12, 2019 at 01:47:06PM +0200, Heinrich Schuchardt wrote: > On 10/11/19 9:41 AM, AKASHI Takahiro wrote: > >Adding "printk.h" will help improve portability from linux kernel > >code (in my case, lib/asn1_decoder.c). > > > >Signed-off-by: AKASHI Takahiro > >--- > > include/linux/kernel.h | 2 ++ > > 1 file changed, 2 insertions(+) > > > >diff --git a/include/linux/kernel.h b/include/linux/kernel.h > >index a85c15d8dc28..919d12bdf89c 100644 > >--- a/include/linux/kernel.h > >+++ b/include/linux/kernel.h > >@@ -2,7 +2,9 @@ > > #define _LINUX_KERNEL_H > > > > > >+#include /* for printf utilities */ > > Kernel code has no vsprintf.h. Linux's lib/asn1_decoder.c has not a > single print statement. So why are you inserting vsprintf.h here? I don't remember why I mentioned to asn1_decoder.c here, but When this statement is removed from kernel.h, some files cannot be compiled. The fact is that sprintf() is used in time.h without including any related headers. (There are still bunch of *missing headers* issues in U-Boot.) I will add one more patch against time.h here. Thanks, -Takahiro Akashi > > #include > >+#include > > Linux include/linux/kernel.h also includes printk.h. OK. > > Best regards > > Heinrich > > > > #define USHRT_MAX ((u16)(~0U)) > > #define SHRT_MAX ((s16)(USHRT_MAX>>1)) > > > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v1 02/11] include: time.h: define time64_t
On 10/17/19 7:39 AM, AKASHI Takahiro wrote:
On Sat, Oct 12, 2019 at 01:40:32PM +0200, Heinrich Schuchardt wrote:
On 10/11/19 9:41 AM, AKASHI Takahiro wrote:
Adding time64_t definition will help improve portability of linux kernel
code (in my case, lib/crypto/x509_cert_parser.c).
Signed-off-by: AKASHI Takahiro
---
include/linux/time.h | 24
1 file changed, 24 insertions(+)
diff --git a/include/linux/time.h b/include/linux/time.h
index b8d298eb4d68..6186985856d7 100644
--- a/include/linux/time.h
+++ b/include/linux/time.h
@@ -150,4 +150,28 @@ _DEFUN (ctime_r, (tim_p, result),
return asctime_r (localtime_r (tim_p, ), result);
}
+/* from /kernel/time/time.c */
+typedef __s64 time64_t;
Wouldn't we want to put these definitions into a file
include/linux/time64.h?
Obviously, there is no problem at following your suggestion, but
I hesitate to do so as it adds only one line header file.
Moreover, mktime64(), which is the only reason for this patch,
is also declared in "linux/time.h" even in linux code.
# Please note that "linux/time64.h" is mainly for timespec64 helper
functions, which are never used in U-Boot.
So I'd like to leave as it is. I think that we can re-visit this issue
in the future when other definitions in time64.h are required.
+
+inline time64_t mktime64(const unsigned int year0, const unsigned int mon0,
+const unsigned int day, const unsigned int hour,
+const unsigned int min, const unsigned int sec)
Where is the function description?
The Linux kernel does not make this function an inline function. Why
should we inline it in U-Boot?
+{
+ unsigned int mon = mon0, year = year0;
+
+ /* 1..12 -> 11,12,1..10 */
+ mon -= 2;
+ if (0 >= (int)mon) {
+ mon += 12; /* Puts Feb last since it has leap day */
+ year -= 1;
+ }
+
+ return time64_t)
+ (year / 4 - year / 100 + year / 400 + 367 * mon / 12 + day) +
+ year * 365 - 719499
+ ) * 24 + hour /* now have hours - midnight tomorrow handled here */
+ ) * 60 + min /* now have minutes */
+ ) * 60 + sec; /* finally seconds */
This code is duplicate to rtc_mktime().
Duplication could be avoided by letting rtc_mktime() call mktime64().
Okay, but as an inline function in this case.
Inline use in two places adds more bytes to the binary. U-Boot should
stay as small as possible.
Best regards
Heinrich
In addition, drivers/rtc/date.c will be moved to lib/ for general use
with CONFIG_LIB_DATE.
Thanks,
-Takahiro Akashi
Best regards
Heinrich
+}
+
#endif
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v1 02/11] include: time.h: define time64_t
On Sat, Oct 12, 2019 at 01:40:32PM +0200, Heinrich Schuchardt wrote:
> On 10/11/19 9:41 AM, AKASHI Takahiro wrote:
> >Adding time64_t definition will help improve portability of linux kernel
> >code (in my case, lib/crypto/x509_cert_parser.c).
> >
> >Signed-off-by: AKASHI Takahiro
> >---
> > include/linux/time.h | 24
> > 1 file changed, 24 insertions(+)
> >
> >diff --git a/include/linux/time.h b/include/linux/time.h
> >index b8d298eb4d68..6186985856d7 100644
> >--- a/include/linux/time.h
> >+++ b/include/linux/time.h
> >@@ -150,4 +150,28 @@ _DEFUN (ctime_r, (tim_p, result),
> > return asctime_r (localtime_r (tim_p, ), result);
> > }
> >
> >+/* from /kernel/time/time.c */
> >+typedef __s64 time64_t;
>
> Wouldn't we want to put these definitions into a file
> include/linux/time64.h?
Obviously, there is no problem at following your suggestion, but
I hesitate to do so as it adds only one line header file.
Moreover, mktime64(), which is the only reason for this patch,
is also declared in "linux/time.h" even in linux code.
# Please note that "linux/time64.h" is mainly for timespec64 helper
functions, which are never used in U-Boot.
So I'd like to leave as it is. I think that we can re-visit this issue
in the future when other definitions in time64.h are required.
> >+
> >+inline time64_t mktime64(const unsigned int year0, const unsigned int mon0,
> >+ const unsigned int day, const unsigned int hour,
> >+ const unsigned int min, const unsigned int sec)
>
>
> Where is the function description?
>
> The Linux kernel does not make this function an inline function. Why
> should we inline it in U-Boot?
>
> >+{
> >+unsigned int mon = mon0, year = year0;
> >+
> >+/* 1..12 -> 11,12,1..10 */
> >+mon -= 2;
> >+if (0 >= (int)mon) {
> >+mon += 12; /* Puts Feb last since it has leap day */
> >+year -= 1;
> >+}
> >+
> >+return time64_t)
> >+ (year / 4 - year / 100 + year / 400 + 367 * mon / 12 + day) +
> >+ year * 365 - 719499
> >+ ) * 24 + hour /* now have hours - midnight tomorrow handled here */
> >+ ) * 60 + min /* now have minutes */
> >+) * 60 + sec; /* finally seconds */
>
> This code is duplicate to rtc_mktime().
>
> Duplication could be avoided by letting rtc_mktime() call mktime64().
Okay, but as an inline function in this case.
In addition, drivers/rtc/date.c will be moved to lib/ for general use
with CONFIG_LIB_DATE.
Thanks,
-Takahiro Akashi
> Best regards
>
> Heinrich
>
> >+}
> >+
> > #endif
> >
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2] mtd: spi: Kconfig: Imply SPI_FLASH if DM_SPI_FLASH
On 16/10/19 9:28 PM, Jagan Teki wrote: > DM_SPI_FLASH should require spi flash interface code for dm > version, so select SPI_FLASH core by default if any board > enabled DM_SPI_FLASH. > > This overcome the explicit enablement of CONFIG_SPI_FLASH on > respective boards when DM_SPI_FLASH being used. > > Cc: Vignesh R > Signed-off-by: Jagan Teki > --- Acked-by: Vignesh Raghavendra > Changes for v2: > - use imply than select > > drivers/mtd/spi/Kconfig | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/mtd/spi/Kconfig b/drivers/mtd/spi/Kconfig > index a0cfc623c6..681dc9 100644 > --- a/drivers/mtd/spi/Kconfig > +++ b/drivers/mtd/spi/Kconfig > @@ -3,6 +3,7 @@ menu "SPI Flash Support" > config DM_SPI_FLASH > bool "Enable Driver Model for SPI flash" > depends on DM && DM_SPI > + imply SPI_FLASH > help > Enable driver model for SPI flash. This SPI flash interface > (spi_flash_probe(), spi_flash_write(), etc.) is then > -- Regards Vignesh ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] cmd: sf: Mark it default if DM_SPI_FLASH enabled
Hi Jagan, On 16/10/19 9:25 PM, Jagan Teki wrote: > If DM_SPI_FLASH enabled that means it is using sf command > for flash interface to access. > > SPI_FLASH can be used via sf command and board/driver > functions to call spi flash ops, so mark it default only > for DM_SPI_FLASH. > > This would prevent explicit adding of CONFIG_CMD_SF when > DM_SPI_FLASH being enabled. > > Cc: Tom Rini > Cc: Vignesh Raghavendra > Signed-off-by: Jagan Teki > --- Acked-by: Vignesh Raghavendra > cmd/Kconfig | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/cmd/Kconfig b/cmd/Kconfig > index 07060c63a7..c45286cc20 100644 > --- a/cmd/Kconfig > +++ b/cmd/Kconfig > @@ -1168,6 +1168,7 @@ config CMD_SDRAM > config CMD_SF > bool "sf" > depends on DM_SPI_FLASH || SPI_FLASH > + default y if DM_SPI_FLASH > help > SPI Flash support > > -- Regards Vignesh ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] arm: dts: k3-am65: Add R5F ranges in interconnect nodes
From: Suman Anna Add the address spaces for the R5F cores in MCU domain to the ranges property of the cbass_mcu interconnect node so that the addresses within the R5F nodes can be translated properly by the relevant OF address API. Signed-off-by: Suman Anna Signed-off-by: Lokesh Vutla --- - Missed sending this as part of previous rproc series. Thanks Suman for pointing it out. arch/arm/dts/k3-am65.dtsi | 4 1 file changed, 4 insertions(+) diff --git a/arch/arm/dts/k3-am65.dtsi b/arch/arm/dts/k3-am65.dtsi index a1467a4dd4..3ead944640 100644 --- a/arch/arm/dts/k3-am65.dtsi +++ b/arch/arm/dts/k3-am65.dtsi @@ -74,6 +74,8 @@ <0x00 0x2838 0x00 0x2838 0x00 0x0388>, <0x00 0x4020 0x00 0x4020 0x00 0x00900100>, <0x00 0x40f0 0x00 0x40f0 0x00 0x0002>, +<0x00 0x4100 0x00 0x4100 0x00 0x0002>, +<0x00 0x4140 0x00 0x4140 0x00 0x0002>, <0x00 0x4204 0x00 0x4204 0x00 0x03ac2400>, <0x00 0x4510 0x00 0x4510 0x00 0x00c24000>, <0x00 0x4600 0x00 0x4600 0x00 0x0020>, @@ -86,6 +88,8 @@ ranges = <0x00 0x2838 0x00 0x2838 0x00 0x0388>, /* MCU NAVSS*/ <0x00 0x4020 0x00 0x4020 0x00 0x00900100>, /* First peripheral window */ <0x00 0x40f0 0x00 0x40f0 0x00 0x0002>, /* CTRL_MMR0 */ +<0x00 0x4100 0x00 0x4100 0x00 0x0002>, /* MCU R5F Core0 */ +<0x00 0x4140 0x00 0x4140 0x00 0x0002>, /* MCU R5F Core1 */ <0x00 0x4204 0x00 0x4204 0x00 0x03ac2400>, /* WKUP */ <0x00 0x4510 0x00 0x4510 0x00 0x00c24000>, /* MMRs, remaining NAVSS */ <0x00 0x4600 0x00 0x4600 0x00 0x0020>, /* CPSW */ -- 2.23.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v1 01/11] linux_compat: add kmemdup()
On Sat, Oct 12, 2019 at 01:22:15PM +0200, Heinrich Schuchardt wrote:
> On 10/11/19 9:41 AM, AKASHI Takahiro wrote:
> >Adding kmemdup() will help improve portability from linux kernel
> >code (in my case, lib/crypto/x509_cert_parser.c and pkcs7_parser.c).
> >
> >Signed-off-by: AKASHI Takahiro
> >---
> > include/linux/compat.h | 4 ++--
> > lib/linux_compat.c | 11 +++
> > 2 files changed, 13 insertions(+), 2 deletions(-)
> >
> >diff --git a/include/linux/compat.h b/include/linux/compat.h
> >index d0f51baab407..d23ef50454ce 100644
> >--- a/include/linux/compat.h
> >+++ b/include/linux/compat.h
> >@@ -117,6 +117,8 @@ static inline void kmem_cache_destroy(struct kmem_cache
> >*cachep)
> > free(cachep);
> > }
> >
> >+void *kmemdup(const void *src, size_t size, int flags);
>
> kememdup() is already implemented in fs/ubifs/ubifs.c and used both in
> drivers/mtd/ and in fs/ubifs/.
Good catch, I haven't noticed that.
ubifs.c is a very bad place for that function.
# drivers/mtd/mtd*.c doesn't use it as relevant code is guarded by
"#ifndef __UBOOT__" though.
> Why would you want to use a different signature than both the Linux
> kernel and current U-Boot?
>
> >+
> > #define DECLARE_WAITQUEUE(...) do { } while (0)
> > #define add_wait_queue(...)do { } while (0)
> > #define remove_wait_queue(...) do { } while (0)
> >@@ -346,8 +348,6 @@ struct writeback_control {
> > unsigned for_sync:1;/* sync(2) WB_SYNC_ALL writeback */
> > };
> >
> >-void *kmemdup(const void *src, size_t len, gfp_t gfp);
> >-
> > typedef int irqreturn_t;
> >
> > struct timer_list {};
> >diff --git a/lib/linux_compat.c b/lib/linux_compat.c
> >index 6373b4451eb3..dd1e5b3c2087 100644
> >--- a/lib/linux_compat.c
> >+++ b/lib/linux_compat.c
> >@@ -40,3 +40,14 @@ void *kmem_cache_alloc(struct kmem_cache *obj, int flag)
> > {
> > return malloc_cache_aligned(obj->sz);
> > }
> >+
> >+void *kmemdup(const void *src, size_t size, int flags)
> >+{
>
> You should not duplicate the implementation in the UBI filesystem.
> Instead move the existing implementation to a place that can be linked
> in your future work.
Okay, I'll remove it from ubifs.c.
Thanks,
-Takahiro Akashi
> Best regards
>
> Heinrich
>
> >+void *p;
> >+
> >+p = kmalloc(size, flags);
> >+if (p)
> >+memcpy(p, src, size);
> >+
> >+return p;
> >+}
> >
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] nvme: add more cache flushes
Hi Patrick, On Wed, Oct 16, 2019 at 11:35 PM Patrick Wildt wrote: > > On Wed, Oct 16, 2019 at 06:11:23PM +0800, Bin Meng wrote: > > On Mon, Oct 14, 2019 at 7:11 PM Patrick Wildt wrote: > > > > > > On an i.MX8MQ our nvme driver doesn't completely work since we are > > > missing a few cache flushes. One is the prp list, which is an extra > > > buffer that we need to flush before handing it to the hardware. Also > > > the block read/write operations needs more cache flushes on this SoC. > > > > > > Signed-off-by: Patrick Wildt > > > --- > > > drivers/nvme/nvme.c | 15 +-- > > > 1 file changed, 9 insertions(+), 6 deletions(-) > > > > > > diff --git a/drivers/nvme/nvme.c b/drivers/nvme/nvme.c > > > index 2444e0270f..69d5e3eedc 100644 > > > --- a/drivers/nvme/nvme.c > > > +++ b/drivers/nvme/nvme.c > > > @@ -123,6 +123,9 @@ static int nvme_setup_prps(struct nvme_dev *dev, u64 > > > *prp2, > > > } > > > *prp2 = (ulong)dev->prp_pool; > > > > > > + flush_dcache_range((ulong)dev->prp_pool, (ulong)dev->prp_pool + > > > + dev->prp_entry_num * sizeof(u64)); > > > + > > > return 0; > > > } > > > > > > @@ -717,9 +720,10 @@ static ulong nvme_blk_rw(struct udevice *udev, > > > lbaint_t blknr, > > > u16 lbas = 1 << (dev->max_transfer_shift - ns->lba_shift); > > > u64 total_lbas = blkcnt; > > > > > > - if (!read) > > > - flush_dcache_range((unsigned long)buffer, > > > - (unsigned long)buffer + total_len); > > > + flush_dcache_range((unsigned long)buffer, > > > + (unsigned long)buffer + total_len); > > > > Why we need this for read? > > I'm no processor engineer, but I have read (and "seen") the following > on ARMs. If I'm wrong. please correct me. > > Since the buffer is usually allocated cache-aligned on the stack, > it is very possible that this buffer was previously still used > as it's supposed to be used: as stack. Thus, the caches can still > be filled, and are not yet evicted/flushed to memory. Now it is > possible that between the DMA access from the device and our cache > invalidation, the CPU cache writes back its contents to memory, > overwriting whatever the NVMe just gave us. OK, this makes sense. So if we allocate the buffer from the heap, we should only care about flush on write, right? Can you test this? > > > > + invalidate_dcache_range((unsigned long)buffer, > > > + (unsigned long)buffer + total_len); > > > > > > c.rw.opcode = read ? nvme_cmd_read : nvme_cmd_write; > > > c.rw.flags = 0; > > > @@ -755,9 +759,8 @@ static ulong nvme_blk_rw(struct udevice *udev, > > > lbaint_t blknr, > > > buffer += lbas << ns->lba_shift; > > > } > > > > > > - if (read) > > > - invalidate_dcache_range((unsigned long)buffer, > > > - (unsigned long)buffer + > > > total_len); > > > + invalidate_dcache_range((unsigned long)buffer, > > > + (unsigned long)buffer + total_len); > > > > Why we need this for write? > > That's a good point. After the transaction, if it was a read then > we need to invalidate it, as we might have speculatively read it. > On a write, we don't care about its contents. I will test it w/o > this chunk and report back. > Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 5/5] doc: Add documentation for how to build U-Boot host tools
Hi Tom, On Thu, Oct 17, 2019 at 2:20 AM Tom Rini wrote: > > On Wed, Oct 16, 2019 at 09:27:25AM -0700, Bin Meng wrote: > > > This adds a reST document for how to build U-Boot host tools, > > including information for both Linux and Windows. > > > > Signed-off-by: Bin Meng > > So here's where I think things get interesting. Off the top of my head, > I think we can use the free GitLab.com-provided hosts of which there are > Windows-based ones (we would need to do some labeling of jobs so that > most things only run on our Linux hosts but one job runs on the Windows > infra). I'm less sure we can do such a matrix with Travis. But is > there some way we could get this Windows tool build into CI and thus > keep it from breaking in the future? Thanks! Yes, I would like to have GitLab CI to do the Windows build for us. However I did not find the free GitLab.com-provided hosts. Any hints? Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [EXT] Re: Issues with driver binding and probing
Hi Aaron,
On Wed, 16 Oct 2019 at 11:56, Aaron Williams wrote:
>
> Hi Simon,
>
> On Friday, October 11, 2019 4:42:55 PM PDT Simon Glass wrote:
> > Hi Aaron,
> >
> > On Wed, 25 Sep 2019 at 22:08, Aaron Williams wrote:
> > > Hi Simon,
> > >
> > > On Wednesday, September 25, 2019 8:40:48 PM PDT Bin Meng wrote:
> > > > External Email
> > > >
> > > > --
> > > > +Simon
> > > >
> > > > Hi Aaron,
> > > >
> > > > On Thu, Sep 26, 2019 at 11:10 AM Aaron Williams
> > >
> > > wrote:
> > > > > Hi all,
> > > > >
> > > > > I have an issue where I have a nexus driver and a sub serial driver on
> > > > > top
> > > > > of it. The base nexus driver is getting bound and probed properly,
> > > > > however the serial drivers (pci-console) below it are not.
> > > > >
> > > > > My device tree looks something like this:
> > > > > pci-console-nexus@0x0300 {
> > > > >
> > > > > /* Remote PCI console buffer location */
> > > > > compatible = "marvell,pci-console-nexus";
> > > >
> > > > Is this a PCI controller node?
> > >
> > > No, actually it points to a location in memory which is shared by a PCI
> > > host with the software. It is a software only structure with no actual
> > > hardware behind it. We use this as a serial console across the PCI bus,
> > > but it's just shared memory. There is a nexus device then multiple
> > > consoles underneath it. U-Boot will initialize the data structures (if
> > > needed) and claim one of the consoles while it is use. The data
> > > structures may or may not already be initialized by earlier bootloaders
> > > or the ATF. The ATF may also claim one of the consoles.
> >
> > What uclass is this node? Does that uclass have a post_bind method
> > that calls dm_scan_fdt_dev()?
> >
> > > > > status = "okay";
> > > > > #address-cells = <2>;
> > > > > #size-cells = <1>;
> > > > > skip-init;
> > > > > num-consoles = <8>;
> > > > > reg = <0 0x0300 0 0x4>;
> > > > > ranges = <0 0 0 0x3000100 0x4000>,
> > > > >
> > > > > <1 0 0 0x3004100 0x4000>,
> > > > > <2 0 0 0x3008100 0x4000>,
> > > > > <3 0 0 0x300c100 0x4000>,
> > > > > <4 0 0 0x3010100 0x4000>,
> > > > > <5 0 0 0x3014100 0x4000>,
> > > > > <6 0 0 0x3018100 0x4000>,
> > > > > <7 0 0 0x301c100 0x4000>;
> > > > >
> > > > > console@0 {
> > > > >
> > > > > compatible = "marvell,pci-console";
> > > >
> > > > If this is a PCI device, it can be handled by the PCI codes.
> > > >
> > > > > status = "okay";
> > > > > reg = <0 0 0x4000>;
> > > > > tx-buffer-size = <0x2f80>;
> > > > > rx-buffer-size = <0x1000>;
> > > > >
> > > > > };
> > > > >
> > > > > ...
> > > > >
> > > > > console@7 {
> > > > >
> > > > > compatible = "marvell,pci-console";
> > > > > status = "okay";
> > > > > reg = <7 0 0x4000>;
> > > > > tx-buffer-size = <0x2f80>;
> > > > > rx-buffer-size = <0x1000>;
> > > > >
> > > > > };
> > > > >
> > > > > };
> > > > >
> > > > > When U-Boot binds the drivers it sees and binds pci-console-nexus but
> > > > > it
> > > > > never even attempts to go any deeper in the device tree. Both drivers
> > > > > are
> > > > > used. The nexus datastructure is a shared resouce that can be used by
> > > > > ATF.
> > > > >
> > > > > I added a bind function in the nexus driver that basically does:
> > > > > dev_for_each_subnode(node, parent) {
> > > > >
> > > > > ret = device_bind_driver_to_node(parent, DRIVER_NAME,
> > > > >
> > > > > ofnode_get_name(node), node,
> > > > > );
> > > > >
> > > > > get_uclass(UCLASS_SERIAL, );
> > > > > dev->uclass = uic;
> > > > >
> > > > > }
> > > > >
> > > > > With this I see the consoles in the dm tree and uclass list, but the
> > > > > sequences don't seem to be getting set.
> > > > >
> > > > > What I notice when I type dm uclass is:
> > > > > uclass 60: serial
> > > > > - * serial@87e02800 @ 7fbeb3360, seq 0, (req 0)
> > > > > - serial@87e02900 @ 7fbeb3430, seq -1, (req 1)
> > > > > - console@0 @ 7fbeb3660
> > > > > - console@1 @ 7fbeb3780
> > > > > - console@2 @ 7fbeb38a0
> > > > > - console@3 @ 7fbeb39c0
> > > > > - console@4 @ 7fbeb3ae0
> > > > > - console@5 @ 7fbeb3c00
> > > > > - console@6 @ 7fbeb3d20
> > > > > - console@7 @ 7fbeb3e40
> > > > > - * pci-bootcmd@0x03fff000
Re: [U-Boot] [PATCH v3 1/8] dm: regulator: support regulator more state
Hi Elaine, On Thu, 19 Sep 2019 at 02:08, Elaine Zhang wrote: > > 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 Is there a change log? > --- > doc/device-tree-bindings/regulator/regulator.txt | 27 + > drivers/power/regulator/regulator-uclass.c | 70 > > include/power/regulator.h| 64 ++ > test/dm/regulator.c | 46 > 4 files changed, 207 insertions(+) Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] nvme: flush dcache on both r/w, and the prp list
It's possible that the data cache for the buffer still holds data to be flushed to memory, since the buffer was probably used as stack before. Thus we need to make sure to flush it also on reads, since it's possible that the cache is automatically flused to memory after the NVMe DMA transfer happened, thus overwriting the NVMe transfer's data. Also add a missing dcache flush for the prp list. Signed-off-by: Patrick Wildt --- drivers/nvme/nvme.c | 8 +--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/drivers/nvme/nvme.c b/drivers/nvme/nvme.c index dee92b613d..f915817aaa 100644 --- a/drivers/nvme/nvme.c +++ b/drivers/nvme/nvme.c @@ -123,6 +123,9 @@ static int nvme_setup_prps(struct nvme_dev *dev, u64 *prp2, } *prp2 = (ulong)dev->prp_pool; + flush_dcache_range((ulong)dev->prp_pool, (ulong)dev->prp_pool + + dev->prp_entry_num * sizeof(u64)); + return 0; } @@ -717,9 +720,8 @@ static ulong nvme_blk_rw(struct udevice *udev, lbaint_t blknr, u16 lbas = 1 << (dev->max_transfer_shift - ns->lba_shift); u64 total_lbas = blkcnt; - if (!read) - flush_dcache_range((unsigned long)buffer, - (unsigned long)buffer + total_len); + flush_dcache_range((unsigned long)buffer, + (unsigned long)buffer + total_len); c.rw.opcode = read ? nvme_cmd_read : nvme_cmd_write; c.rw.flags = 0; -- 2.23.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] ARM: bcm283x: Set memory map at run-time
On 16.10.19 18:50, Matthias Brugger wrote:
On 27/09/2019 12:14, Alexander Graf wrote:
On 27.09.19 11:00, matthias@kernel.org wrote:
From: Matthias Brugger
For bcm283x based on arm64 we also have to change the mm_region.
Add assign this in mach_cpu_init() so we can create now one binary
for RPi3 and RPi4.
Signed-off-by: Matthias Brugger
---
arch/arm/mach-bcm283x/init.c | 65 +--
board/raspberrypi/rpi/lowlevel_init.S | 6 +++
board/raspberrypi/rpi/rpi.c | 45 ---
3 files changed, 67 insertions(+), 49 deletions(-)
diff --git a/arch/arm/mach-bcm283x/init.c b/arch/arm/mach-bcm283x/init.c
index 214e1078eb..f6c2946922 100644
--- a/arch/arm/mach-bcm283x/init.c
+++ b/arch/arm/mach-bcm283x/init.c
@@ -8,16 +8,68 @@
#include
#include
+#ifdef CONFIG_ARM64
+#include
+#endif
#define PDATA_BCM2835 0
#define PDATA_BCM2836 1
#define PDATA_BCM2837 2
-#define PDATA_BCM2838 3
+#define PDATA_BCM2711 3
What is this change?
Wrong patch, I will fix this in v2.
extern unsigned long rpi_bcm283x_base;
+#ifdef CONFIG_ARM64
+extern struct mm_region *mem_map;
+
+static struct mm_region bcm283x_mem_map[] = {
+ {
+ .virt = 0xUL,
+ .phys = 0xUL,
+ .size = 0x3f00UL,
+ .attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL) |
+ PTE_BLOCK_INNER_SHARE
+ }, {
+ .virt = 0x3f00UL,
+ .phys = 0x3f00UL,
+ .size = 0x0100UL,
+ .attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
+ PTE_BLOCK_NON_SHARE |
+ PTE_BLOCK_PXN | PTE_BLOCK_UXN
+ }, {
+ /* List terminator */
+ 0,
+ }
+};
+
+static struct mm_region bcm2711_mem_map[] = {
+ {
+ .virt = 0xUL,
+ .phys = 0xUL,
+ .size = 0xfe00UL,
+ .attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL) |
+ PTE_BLOCK_INNER_SHARE
+ }, {
+ .virt = 0xfe00UL,
+ .phys = 0xfe00UL,
+ .size = 0x0180UL,
+ .attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
+ PTE_BLOCK_NON_SHARE |
+ PTE_BLOCK_PXN | PTE_BLOCK_UXN
+ }, {
+ /* List terminator */
+ 0,
+ }
+};
+#else
+struct mm_region {
+ /* dummy struct */
+};
+#endif
+
struct bcm283x_pdata {
unsigned long io_base;
+ struct mm_region *m_map;
};
struct bcm283x_pdata pdata_bcm283x[] = {
@@ -30,9 +82,11 @@ struct bcm283x_pdata pdata_bcm283x[] = {
#ifdef CONFIG_ARM64
[PDATA_BCM2837] = {
.io_base = 0x3f00,
+ .m_map = bcm283x_mem_map,
},
- [PDATA_BCM2838] = {
+ [PDATA_BCM2711] = {
.io_base = 0xfe00,
+ .m_map = bcm2711_mem_map
},
#endif
};
@@ -45,8 +99,8 @@ static const struct udevice_id board_ids[] = {
{ .compatible = "brcm,bcm2835", .data = PDATA_BCM2835},
{ .compatible = "brcm,bcm2836", .data = PDATA_BCM2836},
{ .compatible = "brcm,bcm2837", .data = PDATA_BCM2837},
- { .compatible = "brcm,bcm2838", .data = PDATA_BCM2838},
- { .compatible = "brcm,bcm2711", .data = PDATA_BCM2838},
+ { .compatible = "brcm,bcm2838", .data = PDATA_BCM2711},
+ { .compatible = "brcm,bcm2711", .data = PDATA_BCM2711},
{ },
};
@@ -72,6 +126,9 @@ int mach_cpu_init(void)
if (!ret) {
pdat = pdata_bcm283x[of_match->data];
rpi_bcm283x_base = pdat.io_base;
+#ifdef CONFIG_ARM64
+ mem_map = pdat.m_map;
+#endif
break;
}
diff --git a/board/raspberrypi/rpi/lowlevel_init.S
b/board/raspberrypi/rpi/lowlevel_init.S
index fcb99ebef7..9786a5a4b3 100644
--- a/board/raspberrypi/rpi/lowlevel_init.S
+++ b/board/raspberrypi/rpi/lowlevel_init.S
@@ -23,6 +23,12 @@ fw_dtb_pointer:
.word 0x0
#endif
+#ifdef CONFIG_ARM64
+.global mem_map
+mem_map:
+ .dword 0x0
+#endif
Why does this live in .S?
It took me some time but now I think I understand what happens.
rpi_bcm283x_base and mem_map are assigned in mach_cpu_init. My understanding is
that for this function holds the same as for board_init_f (from Readme):
- BSS is not available, so you cannot use global/static variables, only stack
variables and global_data
If we put the declaration of both variables in a source file, it will be put
into .bss and we won't be able to boot.
The whole low_level.S lives in text_rest, so if I add __attribute__ ((section
(".text"))) to the declaration of the variables in, let's say, init.c I get a
compiler warning but U-Boot works as expected.
Why not just force put it in ".data"? In fact, it might be as simple as
extern struct mm_region *mem_map = bcm283x_mem_map;
which should already move it right into .data. Then you only need to
special the RPi4 (and above).
Alex
So my question is now, how to proceed. I could add them in the global_data arch
struct. That would work for fine for rpi_bcm283x_base but would need to
Re: [U-Boot] [PATCH 5/5] doc: Add documentation for how to build U-Boot host tools
On Wed, Oct 16, 2019 at 09:27:25AM -0700, Bin Meng wrote: > This adds a reST document for how to build U-Boot host tools, > including information for both Linux and Windows. > > Signed-off-by: Bin Meng So here's where I think things get interesting. Off the top of my head, I think we can use the free GitLab.com-provided hosts of which there are Windows-based ones (we would need to do some labeling of jobs so that most things only run on our Linux hosts but one job runs on the Windows infra). I'm less sure we can do such a matrix with Travis. But is there some way we could get this Windows tool build into CI and thus keep it from breaking in the future? 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] lib: time: Add microsecond timer
On 10/16/19 7:51 PM, Eugeniu Rosca wrote: > On Wed, Oct 16, 2019 at 07:43:09PM +0200, Eugeniu Rosca wrote: >> On Wed, Oct 16, 2019 at 07:26:44PM +0200, Marek Vasut wrote: >>> On 10/16/19 7:11 PM, Eugeniu Rosca wrote: On Tue, Oct 15, 2019 at 10:43:41PM +0200, Marek Vasut wrote: > Add get_timer_us(), which is useful e.g. when we need higher > precision timestamps. FWIW, I agree with Simon that bootstage [1] can be an awesome tool for profiling and boot time measurements. With a bit of instrumentation and host-side scripting, it allows to produce accurate bootcharts like [2]. [1] https://patchwork.ozlabs.org/patch/1177393/#2281091 [2] https://i.ibb.co/mG6Xc1p/2019-10-16-190251.png >>> >>> I don't need that though, I really only need to know how long the code >>> spent between two points in code. >> >> It can be accomplished in N ways. A quick and dirty way to use >> "bootstage" would be to add below instrumentation: >> >> --8<-- >> bootstage_mark_name(BOOTSTAGE_ID_ALLOC, "count/time from here"); >> /* >> * my-precious-code >> */ >> bootstage_mark_name(BOOTSTAGE_ID_ALLOC, "duration of my-precious-code"); >> --8<-- >> >> It's likely orthogonal to what's being proposed in your patch. > > Bottom line is "bootstage" already makes use of timer_get_boot_us(), so > it's not entirely clear to me why another us-resolution timer API would > be needed. Because the new API is actually aligned with the old one. I don't need the machinery behind the bootstage either. -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [EXT] Re: Issues with driver binding and probing
Hi Simon,
On Friday, October 11, 2019 4:42:55 PM PDT Simon Glass wrote:
> Hi Aaron,
>
> On Wed, 25 Sep 2019 at 22:08, Aaron Williams wrote:
> > Hi Simon,
> >
> > On Wednesday, September 25, 2019 8:40:48 PM PDT Bin Meng wrote:
> > > External Email
> > >
> > > --
> > > +Simon
> > >
> > > Hi Aaron,
> > >
> > > On Thu, Sep 26, 2019 at 11:10 AM Aaron Williams
> >
> > wrote:
> > > > Hi all,
> > > >
> > > > I have an issue where I have a nexus driver and a sub serial driver on
> > > > top
> > > > of it. The base nexus driver is getting bound and probed properly,
> > > > however the serial drivers (pci-console) below it are not.
> > > >
> > > > My device tree looks something like this:
> > > > pci-console-nexus@0x0300 {
> > > >
> > > > /* Remote PCI console buffer location */
> > > > compatible = "marvell,pci-console-nexus";
> > >
> > > Is this a PCI controller node?
> >
> > No, actually it points to a location in memory which is shared by a PCI
> > host with the software. It is a software only structure with no actual
> > hardware behind it. We use this as a serial console across the PCI bus,
> > but it's just shared memory. There is a nexus device then multiple
> > consoles underneath it. U-Boot will initialize the data structures (if
> > needed) and claim one of the consoles while it is use. The data
> > structures may or may not already be initialized by earlier bootloaders
> > or the ATF. The ATF may also claim one of the consoles.
>
> What uclass is this node? Does that uclass have a post_bind method
> that calls dm_scan_fdt_dev()?
>
> > > > status = "okay";
> > > > #address-cells = <2>;
> > > > #size-cells = <1>;
> > > > skip-init;
> > > > num-consoles = <8>;
> > > > reg = <0 0x0300 0 0x4>;
> > > > ranges = <0 0 0 0x3000100 0x4000>,
> > > >
> > > > <1 0 0 0x3004100 0x4000>,
> > > > <2 0 0 0x3008100 0x4000>,
> > > > <3 0 0 0x300c100 0x4000>,
> > > > <4 0 0 0x3010100 0x4000>,
> > > > <5 0 0 0x3014100 0x4000>,
> > > > <6 0 0 0x3018100 0x4000>,
> > > > <7 0 0 0x301c100 0x4000>;
> > > >
> > > > console@0 {
> > > >
> > > > compatible = "marvell,pci-console";
> > >
> > > If this is a PCI device, it can be handled by the PCI codes.
> > >
> > > > status = "okay";
> > > > reg = <0 0 0x4000>;
> > > > tx-buffer-size = <0x2f80>;
> > > > rx-buffer-size = <0x1000>;
> > > >
> > > > };
> > > >
> > > > ...
> > > >
> > > > console@7 {
> > > >
> > > > compatible = "marvell,pci-console";
> > > > status = "okay";
> > > > reg = <7 0 0x4000>;
> > > > tx-buffer-size = <0x2f80>;
> > > > rx-buffer-size = <0x1000>;
> > > >
> > > > };
> > > >
> > > > };
> > > >
> > > > When U-Boot binds the drivers it sees and binds pci-console-nexus but
> > > > it
> > > > never even attempts to go any deeper in the device tree. Both drivers
> > > > are
> > > > used. The nexus datastructure is a shared resouce that can be used by
> > > > ATF.
> > > >
> > > > I added a bind function in the nexus driver that basically does:
> > > > dev_for_each_subnode(node, parent) {
> > > >
> > > > ret = device_bind_driver_to_node(parent, DRIVER_NAME,
> > > >
> > > > ofnode_get_name(node), node,
> > > > );
> > > >
> > > > get_uclass(UCLASS_SERIAL, );
> > > > dev->uclass = uic;
> > > >
> > > > }
> > > >
> > > > With this I see the consoles in the dm tree and uclass list, but the
> > > > sequences don't seem to be getting set.
> > > >
> > > > What I notice when I type dm uclass is:
> > > > uclass 60: serial
> > > > - * serial@87e02800 @ 7fbeb3360, seq 0, (req 0)
> > > > - serial@87e02900 @ 7fbeb3430, seq -1, (req 1)
> > > > - console@0 @ 7fbeb3660
> > > > - console@1 @ 7fbeb3780
> > > > - console@2 @ 7fbeb38a0
> > > > - console@3 @ 7fbeb39c0
> > > > - console@4 @ 7fbeb3ae0
> > > > - console@5 @ 7fbeb3c00
> > > > - console@6 @ 7fbeb3d20
> > > > - console@7 @ 7fbeb3e40
> > > > - * pci-bootcmd@0x03fff000 @ 7fbeb3f60, seq 1, (req -1)
> > > >
> > > > Does anyone have any ideas on how I should properly handle this? It
> > > >
Re: [U-Boot] [PATCH] lib: time: Add microsecond timer
On Wed, Oct 16, 2019 at 07:43:09PM +0200, Eugeniu Rosca wrote: > On Wed, Oct 16, 2019 at 07:26:44PM +0200, Marek Vasut wrote: > > On 10/16/19 7:11 PM, Eugeniu Rosca wrote: > > > On Tue, Oct 15, 2019 at 10:43:41PM +0200, Marek Vasut wrote: > > >> Add get_timer_us(), which is useful e.g. when we need higher > > >> precision timestamps. > > > > > > FWIW, I agree with Simon that bootstage [1] can be an awesome tool for > > > profiling and boot time measurements. With a bit of instrumentation and > > > host-side scripting, it allows to produce accurate bootcharts like [2]. > > > > > > [1] https://patchwork.ozlabs.org/patch/1177393/#2281091 > > > [2] https://i.ibb.co/mG6Xc1p/2019-10-16-190251.png > > > > I don't need that though, I really only need to know how long the code > > spent between two points in code. > > It can be accomplished in N ways. A quick and dirty way to use > "bootstage" would be to add below instrumentation: > > --8<-- > bootstage_mark_name(BOOTSTAGE_ID_ALLOC, "count/time from here"); > /* > * my-precious-code > */ > bootstage_mark_name(BOOTSTAGE_ID_ALLOC, "duration of my-precious-code"); > --8<-- > > It's likely orthogonal to what's being proposed in your patch. Bottom line is "bootstage" already makes use of timer_get_boot_us(), so it's not entirely clear to me why another us-resolution timer API would be needed. -- Best Regards, Eugeniu ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] lib: time: Add microsecond timer
On Wed, Oct 16, 2019 at 07:26:44PM +0200, Marek Vasut wrote: > On 10/16/19 7:11 PM, Eugeniu Rosca wrote: > > On Tue, Oct 15, 2019 at 10:43:41PM +0200, Marek Vasut wrote: > >> Add get_timer_us(), which is useful e.g. when we need higher > >> precision timestamps. > > > > FWIW, I agree with Simon that bootstage [1] can be an awesome tool for > > profiling and boot time measurements. With a bit of instrumentation and > > host-side scripting, it allows to produce accurate bootcharts like [2]. > > > > [1] https://patchwork.ozlabs.org/patch/1177393/#2281091 > > [2] https://i.ibb.co/mG6Xc1p/2019-10-16-190251.png > > I don't need that though, I really only need to know how long the code > spent between two points in code. It can be accomplished in N ways. A quick and dirty way to use "bootstage" would be to add below instrumentation: --8<-- bootstage_mark_name(BOOTSTAGE_ID_ALLOC, "count/time from here"); /* * my-precious-code */ bootstage_mark_name(BOOTSTAGE_ID_ALLOC, "duration of my-precious-code"); --8<-- It's likely orthogonal to what's being proposed in your patch. -- Best Regards, Eugeniu ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] lib: time: Add microsecond timer
On 10/16/19 7:11 PM, Eugeniu Rosca wrote: > On Tue, Oct 15, 2019 at 10:43:41PM +0200, Marek Vasut wrote: >> Add get_timer_us(), which is useful e.g. when we need higher >> precision timestamps. > > FWIW, I agree with Simon that bootstage [1] can be an awesome tool for > profiling and boot time measurements. With a bit of instrumentation and > host-side scripting, it allows to produce accurate bootcharts like [2]. > > [1] https://patchwork.ozlabs.org/patch/1177393/#2281091 > [2] https://i.ibb.co/mG6Xc1p/2019-10-16-190251.png I don't need that though, I really only need to know how long the code spent between two points in code. -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] lib: time: Add microsecond timer
On Tue, Oct 15, 2019 at 10:43:41PM +0200, Marek Vasut wrote: > Add get_timer_us(), which is useful e.g. when we need higher > precision timestamps. > > Signed-off-by: Marek Vasut > Cc: Tom Rini > Cc: Simon Glass FWIW, I agree with Simon that bootstage [1] can be an awesome tool for profiling and boot time measurements. With a bit of instrumentation and host-side scripting, it allows to produce accurate bootcharts like [2]. [1] https://patchwork.ozlabs.org/patch/1177393/#2281091 [2] https://i.ibb.co/mG6Xc1p/2019-10-16-190251.png -- Best Regards, Eugeniu ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] imx: spl: inject 'u-boot, spl-boot-device' for next-stage
This implements the 'spl_perform_fixups' hook for i.MX-based
boards and injects the /chosen/u-boot,spl-boot-device with a string
representation corresponding to the boot device used.
The intended usage is for the full U-Boot stage to evaluate this in
scripts and then adapt its boot-order as needed.
This change is heavily based on commit e5f2ecc75001
("rockchip: rk3399: inject 'u-boot, spl-boot-device' for next-stage")
A string representation of the boot device was chosen
here (as opposed to an ofpath in the rockchip commit),
so as to make this less hardware dependent.
Signed-off-by: André Draszik
Cc: Stefano Babic
Cc: Fabio Estevam
Cc: "NXP i.MX U-Boot Team"
Cc: Albert Aribaud
---
arch/arm/mach-imx/spl.c | 49 +
1 file changed, 49 insertions(+)
diff --git a/arch/arm/mach-imx/spl.c b/arch/arm/mach-imx/spl.c
index f025c4b301..42ca719cd8 100644
--- a/arch/arm/mach-imx/spl.c
+++ b/arch/arm/mach-imx/spl.c
@@ -176,6 +176,55 @@ u32 spl_boot_device(void)
}
#endif /* CONFIG_MX7 || CONFIG_IMX8M || CONFIG_IMX8 */
+static const char *imx_decode_boot_device(u32 boot_device)
+{
+ int i;
+ static const struct {
+ u32 boot_device;
+ const char *ofpath;
+ } spl_boot_devices_tbl[] = {
+ { BOOT_DEVICE_MMC1, "mmc1" },
+ { BOOT_DEVICE_MMC2, "mmc2" },
+ { BOOT_DEVICE_SPI, "spi" },
+ { BOOT_DEVICE_NAND, "nand" },
+ };
+
+ for (i = 0; i < ARRAY_SIZE(spl_boot_devices_tbl); ++i)
+ if (spl_boot_devices_tbl[i].boot_device == boot_device)
+ return spl_boot_devices_tbl[i].ofpath;
+
+ return NULL;
+}
+
+void spl_perform_fixups(struct spl_image_info *spl_image)
+{
+ void *blob = spl_image->fdt_addr;
+ const char *boot_ofpath;
+ int chosen;
+
+ /*
+* Inject the ofpath of the device the full U-Boot (or Linux in
+* Falcon-mode) was booted from into the FDT, if a FDT has been
+* loaded at the same time.
+*/
+ if (!blob)
+ return;
+ boot_ofpath = imx_decode_boot_device(spl_image->boot_device);
+ if (!boot_ofpath) {
+ pr_err("%s: could not map boot_device to ofpath\n", __func__);
+ return;
+ }
+
+ chosen = fdt_find_or_add_subnode(blob, 0, "chosen");
+ if (chosen < 0) {
+ pr_err("%s: could not find/create '/chosen'\n", __func__);
+ return;
+ }
+ fdt_setprop_string(blob, chosen,
+ "u-boot,spl-boot-device", boot_ofpath);
+}
+
+
#ifdef CONFIG_SPL_USB_GADGET
int g_dnl_bind_fixup(struct usb_device_descriptor *dev, const char *name)
{
--
2.23.0.rc1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] lib: time: Add microsecond timer
On 10/16/19 6:58 PM, Simon Glass wrote:
[...]
>>> Have you tried bootstage?
>>
>> What for ? I need to debug the EHCI driver performance across the EHCI
>> driver and USB storage implementation. Bootstage is not helpful here.
>
> It can track the time spent in particular parts of the code,
> accumulating it over multiple calls, etc. E.g. how much is FS, how
> much is driver, how much is waiting for replies...
And how much overhead does it add compared to calling get_timer{,_us}()
directly ? It was about uSecs in this case, so this was the best approach.
--
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] lib: time: Add microsecond timer
Hi Marek, On Wed, 16 Oct 2019 at 10:55, Marek Vasut wrote: > > On 10/16/19 6:54 PM, Simon Glass wrote: > > Hi Marek, > > Hello Simon, > > > On Wed, 16 Oct 2019 at 10:44, Marek Vasut wrote: > >> > >> On 10/16/19 6:40 PM, Simon Glass wrote: > >>> Hi Marek, > >> > >> Hi, > >> > >>> On Wed, 16 Oct 2019 at 02:55, Marek Vasut wrote: > > On 10/16/19 3:30 AM, Simon Glass wrote: > > Hi Marek, > > Hi, > > > On Tue, 15 Oct 2019 at 14:43, Marek Vasut wrote: > >> > >> Add get_timer_us(), which is useful e.g. when we need higher > >> precision timestamps. > > > > Can we use timer_get_us()? It seems confusing to have two. > > Nope, that one doesn't have the range (unsigned long vs. u64) and also > doesn't behave the same way as old get_timer(). I wanted something which > is similar, just for uS instead of mS. > >>> > >>> Can you add comments to your patch to indicate what is going on any > >>> why to use this? > >>> > >>> Bootstage uses ulong which is enough for about an hour. How long is > >>> U-Boot running? > >> > >> It can run as long as anyone needs. > >> > >>> If you are using differential times, presumably for timeouts, then > >>> there seems to be little reason to need u64. > >> > >> I use it for logging timestamps during profiling, e.g. of the EHCI driver. > > > > Have you tried bootstage? > > What for ? I need to debug the EHCI driver performance across the EHCI > driver and USB storage implementation. Bootstage is not helpful here. It can track the time spent in particular parts of the code, accumulating it over multiple calls, etc. E.g. how much is FS, how much is driver, how much is waiting for replies... Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] lib: time: Add microsecond timer
On 10/16/19 6:54 PM, Simon Glass wrote: > Hi Marek, Hello Simon, > On Wed, 16 Oct 2019 at 10:44, Marek Vasut wrote: >> >> On 10/16/19 6:40 PM, Simon Glass wrote: >>> Hi Marek, >> >> Hi, >> >>> On Wed, 16 Oct 2019 at 02:55, Marek Vasut wrote: On 10/16/19 3:30 AM, Simon Glass wrote: > Hi Marek, Hi, > On Tue, 15 Oct 2019 at 14:43, Marek Vasut wrote: >> >> Add get_timer_us(), which is useful e.g. when we need higher >> precision timestamps. > > Can we use timer_get_us()? It seems confusing to have two. Nope, that one doesn't have the range (unsigned long vs. u64) and also doesn't behave the same way as old get_timer(). I wanted something which is similar, just for uS instead of mS. >>> >>> Can you add comments to your patch to indicate what is going on any >>> why to use this? >>> >>> Bootstage uses ulong which is enough for about an hour. How long is >>> U-Boot running? >> >> It can run as long as anyone needs. >> >>> If you are using differential times, presumably for timeouts, then >>> there seems to be little reason to need u64. >> >> I use it for logging timestamps during profiling, e.g. of the EHCI driver. > > Have you tried bootstage? What for ? I need to debug the EHCI driver performance across the EHCI driver and USB storage implementation. Bootstage is not helpful here. -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] lib: time: Add microsecond timer
Hi Marek, On Wed, 16 Oct 2019 at 10:44, Marek Vasut wrote: > > On 10/16/19 6:40 PM, Simon Glass wrote: > > Hi Marek, > > Hi, > > > On Wed, 16 Oct 2019 at 02:55, Marek Vasut wrote: > >> > >> On 10/16/19 3:30 AM, Simon Glass wrote: > >>> Hi Marek, > >> > >> Hi, > >> > >>> On Tue, 15 Oct 2019 at 14:43, Marek Vasut wrote: > > Add get_timer_us(), which is useful e.g. when we need higher > precision timestamps. > >>> > >>> Can we use timer_get_us()? It seems confusing to have two. > >> > >> Nope, that one doesn't have the range (unsigned long vs. u64) and also > >> doesn't behave the same way as old get_timer(). I wanted something which > >> is similar, just for uS instead of mS. > > > > Can you add comments to your patch to indicate what is going on any > > why to use this? > > > > Bootstage uses ulong which is enough for about an hour. How long is > > U-Boot running? > > It can run as long as anyone needs. > > > If you are using differential times, presumably for timeouts, then > > there seems to be little reason to need u64. > > I use it for logging timestamps during profiling, e.g. of the EHCI driver. Have you tried bootstage? Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] ARM: bcm283x: Set memory map at run-time
On 27/09/2019 12:14, Alexander Graf wrote:
>
> On 27.09.19 11:00, matthias@kernel.org wrote:
>> From: Matthias Brugger
>>
>> For bcm283x based on arm64 we also have to change the mm_region.
>> Add assign this in mach_cpu_init() so we can create now one binary
>> for RPi3 and RPi4.
>>
>> Signed-off-by: Matthias Brugger
>>
>> ---
>>
>> arch/arm/mach-bcm283x/init.c | 65 +--
>> board/raspberrypi/rpi/lowlevel_init.S | 6 +++
>> board/raspberrypi/rpi/rpi.c | 45 ---
>> 3 files changed, 67 insertions(+), 49 deletions(-)
>>
>> diff --git a/arch/arm/mach-bcm283x/init.c b/arch/arm/mach-bcm283x/init.c
>> index 214e1078eb..f6c2946922 100644
>> --- a/arch/arm/mach-bcm283x/init.c
>> +++ b/arch/arm/mach-bcm283x/init.c
>> @@ -8,16 +8,68 @@
>> #include
>> #include
>> +#ifdef CONFIG_ARM64
>> +#include
>> +#endif
>> #define PDATA_BCM2835 0
>> #define PDATA_BCM2836 1
>> #define PDATA_BCM2837 2
>> -#define PDATA_BCM2838 3
>> +#define PDATA_BCM2711 3
>
>
> What is this change?
>
Wrong patch, I will fix this in v2.
>
>> extern unsigned long rpi_bcm283x_base;
>> +#ifdef CONFIG_ARM64
>> +extern struct mm_region *mem_map;
>> +
>> +static struct mm_region bcm283x_mem_map[] = {
>> + {
>> + .virt = 0xUL,
>> + .phys = 0xUL,
>> + .size = 0x3f00UL,
>> + .attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL) |
>> + PTE_BLOCK_INNER_SHARE
>> + }, {
>> + .virt = 0x3f00UL,
>> + .phys = 0x3f00UL,
>> + .size = 0x0100UL,
>> + .attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
>> + PTE_BLOCK_NON_SHARE |
>> + PTE_BLOCK_PXN | PTE_BLOCK_UXN
>> + }, {
>> + /* List terminator */
>> + 0,
>> + }
>> +};
>> +
>> +static struct mm_region bcm2711_mem_map[] = {
>> + {
>> + .virt = 0xUL,
>> + .phys = 0xUL,
>> + .size = 0xfe00UL,
>> + .attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL) |
>> + PTE_BLOCK_INNER_SHARE
>> + }, {
>> + .virt = 0xfe00UL,
>> + .phys = 0xfe00UL,
>> + .size = 0x0180UL,
>> + .attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
>> + PTE_BLOCK_NON_SHARE |
>> + PTE_BLOCK_PXN | PTE_BLOCK_UXN
>> + }, {
>> + /* List terminator */
>> + 0,
>> + }
>> +};
>> +#else
>> +struct mm_region {
>> + /* dummy struct */
>> +};
>> +#endif
>> +
>> struct bcm283x_pdata {
>> unsigned long io_base;
>> + struct mm_region *m_map;
>> };
>> struct bcm283x_pdata pdata_bcm283x[] = {
>> @@ -30,9 +82,11 @@ struct bcm283x_pdata pdata_bcm283x[] = {
>> #ifdef CONFIG_ARM64
>> [PDATA_BCM2837] = {
>> .io_base = 0x3f00,
>> + .m_map = bcm283x_mem_map,
>> },
>> - [PDATA_BCM2838] = {
>> + [PDATA_BCM2711] = {
>> .io_base = 0xfe00,
>> + .m_map = bcm2711_mem_map
>> },
>> #endif
>> };
>> @@ -45,8 +99,8 @@ static const struct udevice_id board_ids[] = {
>> { .compatible = "brcm,bcm2835", .data = PDATA_BCM2835},
>> { .compatible = "brcm,bcm2836", .data = PDATA_BCM2836},
>> { .compatible = "brcm,bcm2837", .data = PDATA_BCM2837},
>> - { .compatible = "brcm,bcm2838", .data = PDATA_BCM2838},
>> - { .compatible = "brcm,bcm2711", .data = PDATA_BCM2838},
>> + { .compatible = "brcm,bcm2838", .data = PDATA_BCM2711},
>> + { .compatible = "brcm,bcm2711", .data = PDATA_BCM2711},
>> { },
>> };
>> @@ -72,6 +126,9 @@ int mach_cpu_init(void)
>> if (!ret) {
>> pdat = pdata_bcm283x[of_match->data];
>> rpi_bcm283x_base = pdat.io_base;
>> +#ifdef CONFIG_ARM64
>> + mem_map = pdat.m_map;
>> +#endif
>> break;
>> }
>> diff --git a/board/raspberrypi/rpi/lowlevel_init.S
>> b/board/raspberrypi/rpi/lowlevel_init.S
>> index fcb99ebef7..9786a5a4b3 100644
>> --- a/board/raspberrypi/rpi/lowlevel_init.S
>> +++ b/board/raspberrypi/rpi/lowlevel_init.S
>> @@ -23,6 +23,12 @@ fw_dtb_pointer:
>> .word 0x0
>> #endif
>> +#ifdef CONFIG_ARM64
>> +.global mem_map
>> +mem_map:
>> + .dword 0x0
>> +#endif
>
>
> Why does this live in .S?
>
It took me some time but now I think I understand what happens.
rpi_bcm283x_base and mem_map are assigned in mach_cpu_init. My understanding is
that for this function holds the same as for board_init_f (from Readme):
- BSS is not available, so you cannot use global/static variables, only stack
variables and global_data
If we put the declaration of both variables in a source file, it will be put
into .bss and we won't be able to boot.
The whole low_level.S lives in text_rest, so if I add __attribute__ ((section
(".text"))) to the declaration of the variables in, let's say, init.c I get a
compiler warning but U-Boot works as expected.
So my question is now, how to proceed. I could add them in the
Re: [U-Boot] [PATCH] lib: time: Add microsecond timer
On 10/16/19 6:40 PM, Simon Glass wrote: > Hi Marek, Hi, > On Wed, 16 Oct 2019 at 02:55, Marek Vasut wrote: >> >> On 10/16/19 3:30 AM, Simon Glass wrote: >>> Hi Marek, >> >> Hi, >> >>> On Tue, 15 Oct 2019 at 14:43, Marek Vasut wrote: Add get_timer_us(), which is useful e.g. when we need higher precision timestamps. >>> >>> Can we use timer_get_us()? It seems confusing to have two. >> >> Nope, that one doesn't have the range (unsigned long vs. u64) and also >> doesn't behave the same way as old get_timer(). I wanted something which >> is similar, just for uS instead of mS. > > Can you add comments to your patch to indicate what is going on any > why to use this? > > Bootstage uses ulong which is enough for about an hour. How long is > U-Boot running? It can run as long as anyone needs. > If you are using differential times, presumably for timeouts, then > there seems to be little reason to need u64. I use it for logging timestamps during profiling, e.g. of the EHCI driver. -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 14/38] spi: Add support for memory-mapped flash
Hi Vignesh,
On Wed, 16 Oct 2019 at 04:28, Vignesh Raghavendra wrote:
>
> Hi Simon,
>
> On 12/10/19 10:03 AM, Bin Meng wrote:
> > Hi Simon,
> >
> > On Sat, Oct 12, 2019 at 11:08 AM Simon Glass wrote:
> >>
> >> Hi Bin,
> >>
> >> On Wed, 9 Oct 2019 at 07:55, Bin Meng wrote:
> >>>
> >>> Hi Simon,
> >>>
> >>> On Wed, Sep 25, 2019 at 10:12 PM Simon Glass wrote:
>
> On x86 platforms the SPI flash can be mapped into memory so that the
> contents can be read with normal memory accesses.
>
> Add a new SPI flash method to find the location of the SPI flash in
> memory. This differs from the existing device-tree "memory-map" mechanism
> in that the location can be discovered at run-time.
>
>
> Whats is the usecase? Why can't spi_flash_read() be used instead?
> Flash + Controller driver can underneath take care of using memory
> mapped mode to read data from flash right while making sure that access
> is within valid window?
This used to be implemented but is not supported anymore. I think we
should wait until the DM SPI flash migration is complete before trying
again.
Also it is not just reading. The data is used in-place in some cases,
so we do want to know the map region.
>
> Signed-off-by: Simon Glass
> ---
>
> Changes in v2: None
>
> drivers/mtd/spi/sandbox_direct.c | 11 +++
> drivers/mtd/spi/sf-uclass.c | 11 +++
> include/spi_flash.h | 27 +++
> test/dm/sf.c | 9 +
> 4 files changed, 58 insertions(+)
>
> diff --git a/drivers/mtd/spi/sandbox_direct.c
> b/drivers/mtd/spi/sandbox_direct.c
> index 43d8907710c..fb515edcb7c 100644
> --- a/drivers/mtd/spi/sandbox_direct.c
> +++ b/drivers/mtd/spi/sandbox_direct.c
> @@ -68,6 +68,16 @@ static int sandbox_direct_get_sw_write_prot(struct
> udevice *dev)
> return priv->write_prot++ ? 1 : 0;
> }
>
> +static int sandbox_direct_get_mmap(struct udevice *dev, ulong
> *map_basep,
> + size_t *map_sizep, u32 *offsetp)
> +{
> + *map_basep = 0x1000;
> + *map_sizep = 0x2000;
> + *offsetp = 0x100;
> +
> + return 0;
> +}
> +
> static int sandbox_direct_probe(struct udevice *dev)
> {
> struct sandbox_direct_priv *priv = dev_get_priv(dev);
> @@ -82,6 +92,7 @@ static struct dm_spi_flash_ops sandbox_direct_ops = {
> .write = sandbox_direct_write,
> .erase = sandbox_direct_erase,
> .get_sw_write_prot = sandbox_direct_get_sw_write_prot,
> + .get_mmap = sandbox_direct_get_mmap,
> };
>
> static const struct udevice_id sandbox_direct_ids[] = {
> diff --git a/drivers/mtd/spi/sf-uclass.c b/drivers/mtd/spi/sf-uclass.c
> index 719a2fd23ae..127ec7e7aa6 100644
> --- a/drivers/mtd/spi/sf-uclass.c
> +++ b/drivers/mtd/spi/sf-uclass.c
> @@ -28,6 +28,17 @@ int spi_flash_erase_dm(struct udevice *dev, u32
> offset, size_t len)
> return log_ret(sf_get_ops(dev)->erase(dev, offset, len));
> }
>
> +int spi_flash_get_mmap(struct udevice *dev, ulong *map_basep, size_t
> *map_sizep,
> + u32 *offsetp)
> +{
> + struct dm_spi_flash_ops *ops = sf_get_ops(dev);
> +
> + if (!ops->get_mmap)
> + return -ENOSYS;
> +
> + return ops->get_mmap(dev, map_basep, map_sizep, offsetp);
> +}
> +
> int spl_flash_get_sw_write_prot(struct udevice *dev)
> {
> struct dm_spi_flash_ops *ops = sf_get_ops(dev);
> diff --git a/include/spi_flash.h b/include/spi_flash.h
> index 55b4721813a..840189e22c7 100644
> --- a/include/spi_flash.h
> +++ b/include/spi_flash.h
> @@ -47,6 +47,19 @@ struct dm_spi_flash_ops {
> * other -ve value on error
> */
> int (*get_sw_write_prot)(struct udevice *dev);
> +
> + /**
> +* get_mmap() - Get memory-mapped SPI
> +*
> +* @dev:SPI flash device
> +* @map_basep: Returns base memory address for mapped SPI
> +* @map_sizep: Returns size of mapped SPI
> +* @offsetp:Returns start offset of SPI flash where the map
> works
> +* correctly (offsets before this are not visible)
> +* @return 0 if OK, -EFAULT if memory mapping is not available
> +*/
> >>>
> >>> I feel odd to add such an op to the flash op, as memory address is not
> >>> determined by the flash itself, but the SPI flash controller. We
> >>> probably should add the op to the SPI flash controller instead.
> >>
> >> So do you think this should be added to UCLASS_SPI?
> >
> > Yes, I think so.
Re: [U-Boot] [PATCH 1/1] sunxi: Fix pll1 clock calculation
On Fri, Sep 6, 2019 at 11:51 PM Jagan Teki wrote: > > On Wed, Jul 31, 2019 at 6:46 PM Stefan Mavrodiev wrote: > > > > clock_sun6i.c is used for sun6i, sun8i and sun50i SoC families. > > PLL1 clock sets the default system clock, defined as: > > sun6i: 100800 > > sun8i: 100800 > > sun50i: 81600 > > > > With the current calculation, m = 2 and k = 3. Solving for n, > > this results 28. Solving back: > > (24MHz * 28 * 3) / 2 = 1008MHz > > > > However if the requested clock is 816, n is 22.66 rounded > > to 22, which results: > > (24MHz * 28 * 3) / 2 = 792MHz > > > > Changing k to 4 satisfies both system clocks: > > (24E6 * 21 * 4) / 2 = 1008MHz > > (24E6 * 17 * 4) / 2 = 816MHz > > > > Signed-off-by: Stefan Mavrodiev > > --- > > Acked-by: Jagan Teki Applied to u-boot-sunxi/master ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] lib: time: Add microsecond timer
Hi Marek, On Wed, 16 Oct 2019 at 02:55, Marek Vasut wrote: > > On 10/16/19 3:30 AM, Simon Glass wrote: > > Hi Marek, > > Hi, > > > On Tue, 15 Oct 2019 at 14:43, Marek Vasut wrote: > >> > >> Add get_timer_us(), which is useful e.g. when we need higher > >> precision timestamps. > > > > Can we use timer_get_us()? It seems confusing to have two. > > Nope, that one doesn't have the range (unsigned long vs. u64) and also > doesn't behave the same way as old get_timer(). I wanted something which > is similar, just for uS instead of mS. Can you add comments to your patch to indicate what is going on any why to use this? Bootstage uses ulong which is enough for about an hour. How long is U-Boot running? If you are using differential times, presumably for timeouts, then there seems to be little reason to need u64. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3] arm64: dts: sun50i: Add support for A64 OLinuXino (with eMMC)
On Wed, Sep 11, 2019 at 12:14 AM Sunil Mohan Adapa wrote: > > A64 OLinuXino board from Olimex has three variants with onboard eMMC: > A64-OLinuXino-1Ge16GW, A64-OLinuXino-1Ge4GW and A64-OLinuXino-2Ge8G-IND. In > addition, there are two variants without eMMC. One without eMMC and one with > SPI > flash. This suggests the need for separate device tree for the three eMMC > variants. > > The Linux kernel upstream has chosen to create and use a separate device tree > for the eMMC variants instead of adding eMMC support existing device tree. > These > changes to Linux kernel are queued for Linux 5.4. > > https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux.git/commit/?h=sunxi/dt-for-5.4=02bb66b347ff8115f53948f86b884e008ba385b9 Updated as per checkpatch.pl and Applied to u-boot-sunxi/master ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/3] stm32mp1: configs: Add CONFIG_SPL_SPI_FLASH_MTD
On Sat, Sep 14, 2019 at 4:18 AM Schrempf Frieder wrote: > > From: Frieder Schrempf > > As SPI_FLASH_MTD is used in SPL and U-Boot proper, we enable both, > now that a separate option for SPL was introduced. > > Signed-off-by: Frieder Schrempf > --- > configs/stm32mp15_basic_defconfig | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/configs/stm32mp15_basic_defconfig > b/configs/stm32mp15_basic_defconfig > index 09785b5dc1..390319657f 100644 > --- a/configs/stm32mp15_basic_defconfig > +++ b/configs/stm32mp15_basic_defconfig > @@ -7,10 +7,10 @@ CONFIG_TARGET_STM32MP1=y > CONFIG_SPL_SPI_FLASH_SUPPORT=y > CONFIG_SPL_SPI_SUPPORT=y > # CONFIG_ARMV7_VIRT is not set > +CONFIG_SPL_TEXT_BASE=0x2FFC2500 > CONFIG_DISTRO_DEFAULTS=y > CONFIG_FIT=y > CONFIG_BOOTCOMMAND="run bootcmd_stm32mp" > -CONFIG_SPL_TEXT_BASE=0x2FFC2500 Unrelated change wrt to commit message? ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] [ADD] Bananapi P2 Zero Support
On Sat, Oct 5, 2019 at 6:32 PM BornGreedy wrote: > > Adding support for Sinovoip Bananapi P2 Zero with eMMC and Ethernet feature. > --- Missing and Linux commit details and S-o-b ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 4/5] linux/types.h: Surround 'struct ustat' with __linux__
'struct ustat' uses linux-specific typedefs to declare its memebers:
__kernel_daddr_t and __kernel_ino_t. It is currently not used by any
U-Boot codes, but when we build U-Boot tools for other platform like
Windows, this becomes a problem.
Let's surround it with __linux__.
Signed-off-by: Bin Meng
---
include/linux/types.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/linux/types.h b/include/linux/types.h
index cc6f7cb..51cb284 100644
--- a/include/linux/types.h
+++ b/include/linux/types.h
@@ -151,12 +151,14 @@ typedef __u32 __bitwise __wsum;
typedef unsigned __bitwise__ gfp_t;
+#ifdef __linux__
struct ustat {
__kernel_daddr_tf_tfree;
__kernel_ino_t f_tinode;
charf_fname[6];
charf_fpack[6];
};
+#endif
#define DECLARE_BITMAP(name, bits) \
unsigned long name[BITS_TO_LONGS(bits)]
--
2.7.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 5/5] doc: Add documentation for how to build U-Boot host tools
This adds a reST document for how to build U-Boot host tools, including information for both Linux and Windows. Signed-off-by: Bin Meng --- doc/build/index.rst | 9 + doc/build/tools.rst | 47 +++ doc/index.rst | 11 +++ 3 files changed, 67 insertions(+) create mode 100644 doc/build/index.rst create mode 100644 doc/build/tools.rst diff --git a/doc/build/index.rst b/doc/build/index.rst new file mode 100644 index 000..e4e3411 --- /dev/null +++ b/doc/build/index.rst @@ -0,0 +1,9 @@ +.. SPDX-License-Identifier: GPL-2.0+ + +Build U-Boot + + +.. toctree:: + :maxdepth: 2 + + tools diff --git a/doc/build/tools.rst b/doc/build/tools.rst new file mode 100644 index 000..c06f915 --- /dev/null +++ b/doc/build/tools.rst @@ -0,0 +1,47 @@ +.. SPDX-License-Identifier: GPL-2.0+ +.. sectionauthor:: Bin Meng + +Host tools +== + +Building tools for Linux + + +To allow distributions to distribute all possible tools in a generic way, +avoiding the need of specific tools building for each machine, a tools only +defconfig file is provided. + +Using this, we can build the tools by doing:: + + $ make tools-only_defconfig + $ make tools-only + +Building tools for Windows +-- +If you wish to generate Windows versions of the utilities in the tools directory +you can use MSYS2, a software distro and building platform for Windows. + +Download the MSYS2 installer from https://www.msys2.org. Make sure you have +installed all required packages below in order to build these host tools:: + + * gcc (9.1.0) + * make (4.2.1) + * bison (3.4.2) + * diffutils (3.7) + * openssl-devel (1.1.1.d) + +Note the version numbers in these parentheses above are the package versions +at the time being when writing this document. The MSYS2 installer tested is +http://repo.msys2.org/distrib/x86_64/msys2-x86_64-20190524.exe. + +There are 3 MSYS subsystems installed: MSYS2, MinGW32 and MinGW64. Each +subsystem provides an environment to build Windows applications. The MSYS2 +environment is for building POSIX compliant software on Windows using an +emulation layer. The MinGW32/64 subsystems are for building native Windows +applications using a linux toolchain (gcc, bash, etc), targeting respectively +32 and 64 bit Windows. + +Launch the MSYS2 shell of the MSYS2 environment, and do the following:: + + $ make tools-only_defconfig + $ make tools-only NO_SDL=1 diff --git a/doc/index.rst b/doc/index.rst index 458f0d2..206a045 100644 --- a/doc/index.rst +++ b/doc/index.rst @@ -15,6 +15,17 @@ if you want to help out. .. toctree:: :maxdepth: 2 +User-oriented documentation +--- + +The following manuals are written for *users* of the U-Boot - those who are +trying to get it to work optimally on a given system. + +.. toctree:: + :maxdepth: 2 + + build/index + Unified Extensible Firmware (UEFI) -- -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 3/5] tools: zynqmpbif: Use compiler builtin instead of linux-specific __swab32
__swab32() is a Linux specific macro defined in linux/swab.h. Let's
use the compiler equivalent builtin function __builtin_bswap32() for
better portability.
Signed-off-by: Bin Meng
---
tools/zynqmpbif.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/zynqmpbif.c b/tools/zynqmpbif.c
index 8c47107..82ce0ac 100644
--- a/tools/zynqmpbif.c
+++ b/tools/zynqmpbif.c
@@ -517,7 +517,7 @@ static int bif_add_bit(struct bif_entry *bf)
debug("Bitstream Length: 0x%x\n", bitlen);
for (i = 0; i < bitlen; i += sizeof(uint32_t)) {
uint32_t *bitbin32 = (uint32_t *)[i];
- *bitbin32 = __swab32(*bitbin32);
+ *bitbin32 = __builtin_bswap32(*bitbin32);
}
if (!bf->dest_dev)
--
2.7.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/5] tools: image.h: Use portable uint32_t instead of linux-specific __be32
__be32 has Linux kernel specific __attribute__((bitwise)) which is
not portable. Use uint32_t instead.
Signed-off-by: Bin Meng
---
include/image.h | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/include/image.h b/include/image.h
index c1065c0..f4d2aaf 100644
--- a/include/image.h
+++ b/include/image.h
@@ -319,13 +319,13 @@ enum {
* all data in network byte order (aka natural aka bigendian).
*/
typedef struct image_header {
- __be32 ih_magic; /* Image Header Magic Number*/
- __be32 ih_hcrc;/* Image Header CRC Checksum*/
- __be32 ih_time;/* Image Creation Timestamp */
- __be32 ih_size;/* Image Data Size */
- __be32 ih_load;/* Data Load Address */
- __be32 ih_ep; /* Entry Point Address */
- __be32 ih_dcrc;/* Image Data CRC Checksum */
+ uint32_tih_magic; /* Image Header Magic Number*/
+ uint32_tih_hcrc;/* Image Header CRC Checksum*/
+ uint32_tih_time;/* Image Creation Timestamp */
+ uint32_tih_size;/* Image Data Size */
+ uint32_tih_load;/* Data Load Address */
+ uint32_tih_ep; /* Entry Point Address */
+ uint32_tih_dcrc;/* Image Data CRC Checksum */
uint8_t ih_os; /* Operating System */
uint8_t ih_arch;/* CPU architecture */
uint8_t ih_type;/* Image Type */
--
2.7.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 2/5] tools: mtk_image.h: Use portable uintXX_t instead of linux-specific __leXX
__leXX has Linux kernel specific __attribute__((bitwise)) which is
not portable. Use corresponding uintXX_t instead.
Signed-off-by: Bin Meng
---
tools/mtk_image.h | 86 +++
1 file changed, 43 insertions(+), 43 deletions(-)
diff --git a/tools/mtk_image.h b/tools/mtk_image.h
index 0a9eab3..4e78b3d 100644
--- a/tools/mtk_image.h
+++ b/tools/mtk_image.h
@@ -9,14 +9,14 @@
#ifndef _MTK_IMAGE_H
#define _MTK_IMAGE_H
-/* Device header definitions */
+/* Device header definitions, all fields are little-endian */
/* Header for NOR/SD/eMMC */
union gen_boot_header {
struct {
char name[12];
- __le32 version;
- __le32 size;
+ uint32_t version;
+ uint32_t size;
};
uint8_t pad[0x200];
@@ -32,14 +32,14 @@ union nand_boot_header {
char name[12];
char version[4];
char id[8];
- __le16 ioif;
- __le16 pagesize;
- __le16 addrcycles;
- __le16 oobsize;
- __le16 pages_of_block;
- __le16 numblocks;
- __le16 writesize_shift;
- __le16 erasesize_shift;
+ uint16_t ioif;
+ uint16_t pagesize;
+ uint16_t addrcycles;
+ uint16_t oobsize;
+ uint16_t pages_of_block;
+ uint16_t numblocks;
+ uint16_t writesize_shift;
+ uint16_t erasesize_shift;
uint8_t dummy[60];
uint8_t ecc_parity[28];
};
@@ -54,14 +54,14 @@ union nand_boot_header {
/* BootROM layout header */
struct brom_layout_header {
char name[8];
- __le32 version;
- __le32 header_size;
- __le32 total_size;
- __le32 magic;
- __le32 type;
- __le32 header_size_2;
- __le32 total_size_2;
- __le32 unused;
+ uint32_t version;
+ uint32_t header_size;
+ uint32_t total_size;
+ uint32_t magic;
+ uint32_t type;
+ uint32_t header_size_2;
+ uint32_t total_size_2;
+ uint32_t unused;
};
#define BRLYT_NAME "BRLYT"
@@ -90,8 +90,8 @@ struct gen_device_header {
struct gfh_common_header {
uint8_t magic[3];
uint8_t version;
- __le16 size;
- __le16 type;
+ uint16_t size;
+ uint16_t type;
};
#define GFH_HEADER_MAGIC "MMM"
@@ -106,17 +106,17 @@ struct gfh_common_header {
struct gfh_file_info {
struct gfh_common_header gfh;
char name[12];
- __le32 unused;
- __le16 file_type;
+ uint32_t unused;
+ uint16_t file_type;
uint8_t flash_type;
uint8_t sig_type;
- __le32 load_addr;
- __le32 total_size;
- __le32 max_size;
- __le32 hdr_size;
- __le32 sig_size;
- __le32 jump_offset;
- __le32 processed;
+ uint32_t load_addr;
+ uint32_t total_size;
+ uint32_t max_size;
+ uint32_t hdr_size;
+ uint32_t sig_size;
+ uint32_t jump_offset;
+ uint32_t processed;
};
#define GFH_FILE_INFO_NAME "FILE_INFO"
@@ -129,16 +129,16 @@ struct gfh_file_info {
struct gfh_bl_info {
struct gfh_common_header gfh;
- __le32 attr;
+ uint32_t attr;
};
struct gfh_brom_cfg {
struct gfh_common_header gfh;
- __le32 cfg_bits;
- __le32 usbdl_by_auto_detect_timeout_ms;
+ uint32_t cfg_bits;
+ uint32_t usbdl_by_auto_detect_timeout_ms;
uint8_t unused[0x48];
- __le32 usbdl_by_kcol0_timeout_ms;
- __le32 usbdl_by_flag_timeout_ms;
+ uint32_t usbdl_by_kcol0_timeout_ms;
+ uint32_t usbdl_by_flag_timeout_ms;
uint32_t pad;
};
@@ -157,15 +157,15 @@ struct gfh_anti_clone {
uint8_t ac_b2k;
uint8_t ac_b2c;
uint16_t pad;
- __le32 ac_offset;
- __le32 ac_len;
+ uint32_t ac_offset;
+ uint32_t ac_len;
};
struct gfh_brom_sec_cfg {
struct gfh_common_header gfh;
- __le32 cfg_bits;
+ uint32_t cfg_bits;
char customer_name[0x20];
- __le32 pad;
+ uint32_t pad;
};
#define BROM_SEC_CFG_JTAG_EN 1
@@ -184,11 +184,11 @@ struct gfh_header {
union lk_hdr {
struct {
- __le32 magic;
- __le32 size;
+ uint32_t magic;
+ uint32_t size;
char name[32];
- __le32 loadaddr;
- __le32 mode;
+ uint32_t loadaddr;
+ uint32_t mode;
};
uint8_t data[512];
--
2.7.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 0/5] tools: Support building U-Boot host tools for Windows via MSYS2
Per current U-Boot README, building Windows versions of the utilities in the tools directory is done via the MinGW toolchain. But testing shows that it is broken and actually it must have been broken for quite a long time. Fixing MinGW build seems quite amount of work as developers of U-Boot normally work on Linux boxes hence codes written are mainly for Linux or POSIX OSes. We must investigate another way of building host tools for Windows, and now we have MSYS2, a software distro and building platform for Windows, to build POSIX compliant software on Windows using an emulation layer. This small series fixes several issues in current U-Boot tools codes, that only assume a Linux host is used. Cases are using standard C typedefs whenever possbile, or using compiler builtin functions to improve portability, etc. A reST document for how to build U-Boot host tools for both platforms is added. Bin Meng (5): tools: image.h: Use portable uint32_t instead of linux-specific __be32 tools: mtk_image.h: Use portable uintXX_t instead of linux-specific __leXX tools: zynqmpbif: Use compiler builtin instead of linux-specific __swab32 linux/types.h: Surround 'struct ustat' with __linux__ doc: Add documentation for how to build U-Boot host tools doc/build/index.rst | 9 ++ doc/build/tools.rst | 47 doc/index.rst | 11 +++ include/image.h | 14 - include/linux/types.h | 2 ++ tools/mtk_image.h | 86 +-- tools/zynqmpbif.c | 2 +- 7 files changed, 120 insertions(+), 51 deletions(-) create mode 100644 doc/build/index.rst create mode 100644 doc/build/tools.rst -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2] sunxi: H6: DRAM: Add support for half DQ
On Fri, Aug 23, 2019 at 10:54 PM Jernej Skrabec wrote: > > Half DQ configuration seems to be very rare for H6 based boards/STBs, > but exists nevertheless. Currently the only known product which needs > this support is Tanix TX6 mini. > > This commit adds support for half DQ configuration. Code was tested > for regressions on other configurations (OrangePi 3 1 GiB/LPDDR3, Tanix > TX6 4 GiB/DDR3) and none were found. > > Thanks to Icenowy Zheng for help with this code. > > Reviewed-by: Andre Przywara > Tested-by: thomas graichen > Signed-off-by: Jernej Skrabec > --- Applied to u-boot-sunxi/master ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 3/5] mtd: spi-nor: ids: Add is25wp256 chip
On Wed, Oct 16, 2019 at 8:28 PM Jagan Teki wrote: > > Add is25wp256, chip to spi-nor id table. > > Tested on SiFive FU540 board. > > Signed-off-by: Jagan Teki > Reviewed-by: Bin Meng > Tested-by: Bin Meng > --- Applied to u-boot-spi/master ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v3 3/3] configs: sopine-baseboard: Enable SPI-FLASH
SoPine has winbond SPI-FLASH, so enable the same in defconfig
and add aliases for spi0 in -u-boot.dtsi
Signed-off-by: Jagan Teki
---
Changes for v3:
- none
arch/arm/dts/sun50i-a64-sopine-baseboard-u-boot.dtsi | 12
configs/sopine_baseboard_defconfig | 1 +
2 files changed, 13 insertions(+)
create mode 100644 arch/arm/dts/sun50i-a64-sopine-baseboard-u-boot.dtsi
diff --git a/arch/arm/dts/sun50i-a64-sopine-baseboard-u-boot.dtsi
b/arch/arm/dts/sun50i-a64-sopine-baseboard-u-boot.dtsi
new file mode 100644
index 00..02b1ae046e
--- /dev/null
+++ b/arch/arm/dts/sun50i-a64-sopine-baseboard-u-boot.dtsi
@@ -0,0 +1,12 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2018 Jagan Teki
+ */
+
+#include "sunxi-u-boot.dtsi"
+
+/ {
+ aliases {
+ spi0 =
+ };
+};
diff --git a/configs/sopine_baseboard_defconfig
b/configs/sopine_baseboard_defconfig
index 5833234b63..c9123fd7ee 100644
--- a/configs/sopine_baseboard_defconfig
+++ b/configs/sopine_baseboard_defconfig
@@ -10,6 +10,7 @@ CONFIG_DRAM_ZQ=3881949
CONFIG_MMC0_CD_PIN=""
CONFIG_MMC_SUNXI_SLOT_EXTRA=2
CONFIG_SPL_SPI_SUNXI=y
+CONFIG_SPI_FLASH_WINBOND=y
# CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
CONFIG_USE_PREBOOT=y
CONFIG_SYS_SPI_U_BOOT_OFFS=0x8000
--
2.18.0.321.gffc6fa0e3
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v3 2/3] arm: sunxi: Enable SPI/SPI-FLASH support for A64
SPI is available in Allwinner A64 SoC, so enable it globally in Kconfig. - CONFIG_SPI - CONFIG_DM_SPI - CONFIG_DM_SPI_FLASH Signed-off-by: Jagan Teki --- Changes for v3: - Move to kconfig from defconfig arch/arm/mach-sunxi/Kconfig | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/arm/mach-sunxi/Kconfig b/arch/arm/mach-sunxi/Kconfig index b153c68acc..2d09be4639 100644 --- a/arch/arm/mach-sunxi/Kconfig +++ b/arch/arm/mach-sunxi/Kconfig @@ -275,7 +275,10 @@ config MACH_SUN9I config MACH_SUN50I bool "sun50i (Allwinner A64)" select ARM64 + select SPI select DM_I2C + select DM_SPI if SPI + select DM_SPI_FLASH select PHY_SUN4I_USB select SUN6I_PRCM select SUNXI_DE2 -- 2.18.0.321.gffc6fa0e3 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v3 1/3] spi: Kconfig: Enable SPI_SUNXI for SUNXI
SPI_SUNXI driver is fully dm-aware and the Allwinner architecture kconfig would have logic to enable the DM_SPI. So, select default spi sunxi driver for sunxi architecture. Signed-off-by: Jagan Teki --- Changes for v3: - none drivers/spi/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig index 0152dff74f..7be867d5b6 100644 --- a/drivers/spi/Kconfig +++ b/drivers/spi/Kconfig @@ -260,6 +260,7 @@ config SPI_SIFIVE config SPI_SUNXI bool "Allwinner SoC SPI controllers" + default ARCH_SUNXI help Enable the Allwinner SoC SPi controller driver. -- 2.18.0.321.gffc6fa0e3 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] watchdog: imx: Add DT ext-reset handling
On Wed, Oct 16, 2019 at 1:11 PM Robert Hancock wrote: > Any updates on this patch set? It is still outstanding in patchwork: > > https://patchwork.ozlabs.org/project/uboot/list/?series=123623 Series looks good. Not sure if you added Stefano on Cc. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] spi: Kconfig: Add help text
Add detailed help text for SPI support. Signed-off-by: Jagan Teki --- drivers/spi/Kconfig | 17 + 1 file changed, 17 insertions(+) diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig index b8ca2bdedd..0152dff74f 100644 --- a/drivers/spi/Kconfig +++ b/drivers/spi/Kconfig @@ -1,5 +1,22 @@ menuconfig SPI bool "SPI Support" + help + The "Serial Peripheral Interface" is a low level synchronous + protocol. Chips that support SPI can have data transfer rates + up to several tens of Mbit/sec. Chips are addressed with a + controller and a chipselect. Most SPI slaves don't support + dynamic device discovery; some are even write-only or read-only. + + SPI is widely used by microcontrollers to talk with sensors, + eeprom and flash memory, codecs and various other controller + chips, analog to digital (and d-to-a) converters, and more. + MMC and SD cards can be accessed using SPI protocol; and for + DataFlash cards used in MMC sockets, SPI must always be used. + + SPI is one of a family of similar protocols using a four wire + interface (select, clock, data in, data out) including Microwire + (half duplex), SSP, SSI, and PSP. This driver framework should + work with most such devices and controllers. if SPI -- 2.18.0.321.gffc6fa0e3 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] watchdog: imx: Add DT ext-reset handling
On 2019-08-07 2:28 a.m., Marek Vasut wrote: > On 8/6/19 8:49 PM, Robert Hancock wrote: >> On 2019-08-06 11:11 a.m., Marek Vasut wrote: >>> On 8/6/19 7:05 PM, Robert Hancock wrote: The Linux imx2_wdt driver uses a fsl,ext-reset-output boolean in the device tree to specify whether the board design should use the external reset instead of the internal reset. Use this boolean to determine which mode to use rather than using external reset unconditionally. For the legacy non-DM mode, the external reset is always used in order to maintain the previous behavior. Signed-off-by: Robert Hancock >>> >>> [...] >>> @@ -124,6 +129,8 @@ static int imx_wdt_probe(struct udevice *dev) if (!priv->base) return -ENOENT; + priv->ext_reset = dev_read_bool(dev, "fsl,ext-reset-output"); + >>> >>> Do we need a vendor-specific, undocumented, DT property ? >> >> It is documented in Linux in >> Documentation/devicetree/bindings/watchdog/fsl-imx-wdt.txt: >> >> - fsl,ext-reset-output: If present the watchdog device is configured to >> assert its external reset (WDOG_B) instead of issuing a software reset. >> >> I'm not aware of anything non-vendor-specific defined for this. > > Aha, then please ignore my comment, thanks for clarifying. Any updates on this patch set? It is still outstanding in patchwork: https://patchwork.ozlabs.org/project/uboot/list/?series=123623 -- Robert Hancock Senior Software Developer SED Systems, a division of Calian Ltd. Email: hanc...@sedsystems.ca ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2] mtd: spi: Kconfig: Imply SPI_FLASH if DM_SPI_FLASH
DM_SPI_FLASH should require spi flash interface code for dm version, so select SPI_FLASH core by default if any board enabled DM_SPI_FLASH. This overcome the explicit enablement of CONFIG_SPI_FLASH on respective boards when DM_SPI_FLASH being used. Cc: Vignesh R Signed-off-by: Jagan Teki --- Changes for v2: - use imply than select drivers/mtd/spi/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/mtd/spi/Kconfig b/drivers/mtd/spi/Kconfig index a0cfc623c6..681dc9 100644 --- a/drivers/mtd/spi/Kconfig +++ b/drivers/mtd/spi/Kconfig @@ -3,6 +3,7 @@ menu "SPI Flash Support" config DM_SPI_FLASH bool "Enable Driver Model for SPI flash" depends on DM && DM_SPI + imply SPI_FLASH help Enable driver model for SPI flash. This SPI flash interface (spi_flash_probe(), spi_flash_write(), etc.) is then -- 2.18.0.321.gffc6fa0e3 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] cmd: sf: Mark it default if DM_SPI_FLASH enabled
If DM_SPI_FLASH enabled that means it is using sf command for flash interface to access. SPI_FLASH can be used via sf command and board/driver functions to call spi flash ops, so mark it default only for DM_SPI_FLASH. This would prevent explicit adding of CONFIG_CMD_SF when DM_SPI_FLASH being enabled. Cc: Tom Rini Cc: Vignesh Raghavendra Signed-off-by: Jagan Teki --- cmd/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/cmd/Kconfig b/cmd/Kconfig index 07060c63a7..c45286cc20 100644 --- a/cmd/Kconfig +++ b/cmd/Kconfig @@ -1168,6 +1168,7 @@ config CMD_SDRAM config CMD_SF bool "sf" depends on DM_SPI_FLASH || SPI_FLASH + default y if DM_SPI_FLASH help SPI Flash support -- 2.18.0.321.gffc6fa0e3 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] nvme: add more cache flushes
On Wed, Oct 16, 2019 at 06:11:23PM +0800, Bin Meng wrote: > On Mon, Oct 14, 2019 at 7:11 PM Patrick Wildt wrote: > > > > On an i.MX8MQ our nvme driver doesn't completely work since we are > > missing a few cache flushes. One is the prp list, which is an extra > > buffer that we need to flush before handing it to the hardware. Also > > the block read/write operations needs more cache flushes on this SoC. > > > > Signed-off-by: Patrick Wildt > > --- > > drivers/nvme/nvme.c | 15 +-- > > 1 file changed, 9 insertions(+), 6 deletions(-) > > > > diff --git a/drivers/nvme/nvme.c b/drivers/nvme/nvme.c > > index 2444e0270f..69d5e3eedc 100644 > > --- a/drivers/nvme/nvme.c > > +++ b/drivers/nvme/nvme.c > > @@ -123,6 +123,9 @@ static int nvme_setup_prps(struct nvme_dev *dev, u64 > > *prp2, > > } > > *prp2 = (ulong)dev->prp_pool; > > > > + flush_dcache_range((ulong)dev->prp_pool, (ulong)dev->prp_pool + > > + dev->prp_entry_num * sizeof(u64)); > > + > > return 0; > > } > > > > @@ -717,9 +720,10 @@ static ulong nvme_blk_rw(struct udevice *udev, > > lbaint_t blknr, > > u16 lbas = 1 << (dev->max_transfer_shift - ns->lba_shift); > > u64 total_lbas = blkcnt; > > > > - if (!read) > > - flush_dcache_range((unsigned long)buffer, > > - (unsigned long)buffer + total_len); > > + flush_dcache_range((unsigned long)buffer, > > + (unsigned long)buffer + total_len); > > Why we need this for read? I'm no processor engineer, but I have read (and "seen") the following on ARMs. If I'm wrong. please correct me. Since the buffer is usually allocated cache-aligned on the stack, it is very possible that this buffer was previously still used as it's supposed to be used: as stack. Thus, the caches can still be filled, and are not yet evicted/flushed to memory. Now it is possible that between the DMA access from the device and our cache invalidation, the CPU cache writes back its contents to memory, overwriting whatever the NVMe just gave us. > > + invalidate_dcache_range((unsigned long)buffer, > > + (unsigned long)buffer + total_len); > > > > c.rw.opcode = read ? nvme_cmd_read : nvme_cmd_write; > > c.rw.flags = 0; > > @@ -755,9 +759,8 @@ static ulong nvme_blk_rw(struct udevice *udev, lbaint_t > > blknr, > > buffer += lbas << ns->lba_shift; > > } > > > > - if (read) > > - invalidate_dcache_range((unsigned long)buffer, > > - (unsigned long)buffer + total_len); > > + invalidate_dcache_range((unsigned long)buffer, > > + (unsigned long)buffer + total_len); > > Why we need this for write? That's a good point. After the transaction, if it was a read then we need to invalidate it, as we might have speculatively read it. On a write, we don't care about its contents. I will test it w/o this chunk and report back. Best regards, Patrick > > > > return (total_len - temp_len) >> desc->log2blksz; > > } > > -- > > Regards, > Bin ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 3/4] dm: spi: Check cs number before accessing slaves
Hi Bin,
On Mon, Sep 9, 2019 at 6:30 PM Bin Meng wrote:
>
> Add chip select number check in spi_find_chip_select().
>
> Signed-off-by: Bin Meng
>
> ---
>
> Changes in v2:
> - move the chip select number check to spi_find_chip_select()
>
> drivers/spi/spi-uclass.c | 45 ++---
> include/spi.h| 3 ++-
> 2 files changed, 28 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/spi/spi-uclass.c b/drivers/spi/spi-uclass.c
> index 24de0b5..cdeceb5 100644
> --- a/drivers/spi/spi-uclass.c
> +++ b/drivers/spi/spi-uclass.c
> @@ -179,7 +179,32 @@ int spi_chip_select(struct udevice *dev)
>
> int spi_find_chip_select(struct udevice *bus, int cs, struct udevice **devp)
> {
> + struct dm_spi_ops *ops;
> + struct spi_cs_info info;
> struct udevice *dev;
> + int ret;
> +
> + /*
> +* Ask the driver. For the moment we don't have CS info.
> +* When we do we could provide the driver with a helper function
> +* to figure out what chip selects are valid, or just handle the
> +* request.
> +*/
> + ops = spi_get_ops(bus);
> + if (ops->cs_info) {
> + ret = ops->cs_info(bus, cs, );
> + } else {
> + /*
> +* We could assume there is at least one valid chip select.
> +* The driver didn't care enough to tell us.
> +*/
> + ret = 0;
> + }
> +
> + if (ret) {
> + printf("Invalid cs %d (err=%d)\n", cs, ret);
> + return ret;
> + }
>
This is breaking 'sf probe' with associated bus and cs on SiFive.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] arm: dts: rk3399-roc-pc: Sync latest dts changes from Linux
Few important regulator power rails fixes are available in
linux-next, so sync them same.
Here is the last commit details:
commit <9f7f9b610e1b7d2dc86c543ab0dfcf781bd42326> ("arm64: dts:
rockchip: Fix roc-rk3399-pc regulator input rails")
Cc: Kever Yang
Cc: Levin Du
Signed-off-by: Jagan Teki
---
arch/arm/dts/rk3399-roc-pc.dts | 32
1 file changed, 16 insertions(+), 16 deletions(-)
diff --git a/arch/arm/dts/rk3399-roc-pc.dts b/arch/arm/dts/rk3399-roc-pc.dts
index 19f7732d72..257543d069 100644
--- a/arch/arm/dts/rk3399-roc-pc.dts
+++ b/arch/arm/dts/rk3399-roc-pc.dts
@@ -57,9 +57,9 @@
* should be placed inside mp8859, but not until mp8859 has
* its own dt-binding.
*/
- vcc12v_sys: mp8859-dcdc1 {
+ dc_12v: mp8859-dcdc1 {
compatible = "regulator-fixed";
- regulator-name = "vcc12v_sys";
+ regulator-name = "dc_12v";
regulator-always-on;
regulator-boot-on;
regulator-min-microvolt = <1200>;
@@ -85,7 +85,7 @@
regulator-boot-on;
regulator-min-microvolt = <330>;
regulator-max-microvolt = <330>;
- vin-supply = <_sys>;
+ vin-supply = <_sys>;
};
/* Actually 3 regulators (host0, 1, 2) controlled by the same gpio */
@@ -118,7 +118,7 @@
regulator-boot-on;
regulator-min-microvolt = <500>;
regulator-max-microvolt = <500>;
- vin-supply = <_sys>;
+ vin-supply = <_12v>;
};
vdd_log: vdd-log {
@@ -129,7 +129,7 @@
regulator-boot-on;
regulator-min-microvolt = <80>;
regulator-max-microvolt = <140>;
- vin-supply = <_sys>;
+ vin-supply = <_sys>;
};
};
@@ -202,16 +202,16 @@
rockchip,system-power-controller;
wakeup-source;
- vcc1-supply = <_sys>;
- vcc2-supply = <_sys>;
- vcc3-supply = <_sys>;
- vcc4-supply = <_sys>;
- vcc6-supply = <_sys>;
- vcc7-supply = <_sys>;
+ vcc1-supply = <_sys>;
+ vcc2-supply = <_sys>;
+ vcc3-supply = <_sys>;
+ vcc4-supply = <_sys>;
+ vcc6-supply = <_sys>;
+ vcc7-supply = <_sys>;
vcc8-supply = <_sys>;
- vcc9-supply = <_sys>;
- vcc10-supply = <_sys>;
- vcc11-supply = <_sys>;
+ vcc9-supply = <_sys>;
+ vcc10-supply = <_sys>;
+ vcc11-supply = <_sys>;
vcc12-supply = <_sys>;
vddio-supply = <_pmu>;
@@ -385,7 +385,7 @@
regulator-ramp-delay = <1000>;
regulator-always-on;
regulator-boot-on;
- vin-supply = <_sys>;
+ vin-supply = <_sys>;
regulator-state-mem {
regulator-off-in-suspend;
@@ -404,7 +404,7 @@
regulator-ramp-delay = <1000>;
regulator-always-on;
regulator-boot-on;
- vin-supply = <_sys>;
+ vin-supply = <_sys>;
regulator-state-mem {
regulator-off-in-suspend;
--
2.18.0.321.gffc6fa0e3
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 1/5] riscv: dts: Add hifive-unleashed-a00 dts from Linux
Sync the hifive-unleashed-a00 dts from Linux with
below commit details:
commit <2993c9b04e616df0848b655d7202a707a70fc876> ("riscv: dts: HiFive
Unleashed: add default chosen/stdout-path")
Idea is to periodically sync the dts from Linux instead of
tweaking internal changes one after another, so better not
add any intermediate changes in between. This would help to
maintain the dts files easy and meaningful since we are
reusing device tree files from Linux.
Signed-off-by: Jagan Teki
---
arch/riscv/dts/Makefile | 1 +
arch/riscv/dts/fu540-c000.dtsi | 251
arch/riscv/dts/hifive-unleashed-a00.dts | 96 +
3 files changed, 348 insertions(+)
create mode 100644 arch/riscv/dts/fu540-c000.dtsi
create mode 100644 arch/riscv/dts/hifive-unleashed-a00.dts
diff --git a/arch/riscv/dts/Makefile b/arch/riscv/dts/Makefile
index f9cd606a9a..4f30e6936f 100644
--- a/arch/riscv/dts/Makefile
+++ b/arch/riscv/dts/Makefile
@@ -1,6 +1,7 @@
# SPDX-License-Identifier: GPL-2.0+
dtb-$(CONFIG_TARGET_AX25_AE350) += ae350_32.dtb ae350_64.dtb
+dtb-$(CONFIG_TARGET_SIFIVE_FU540) += hifive-unleashed-a00.dtb
targets += $(dtb-y)
diff --git a/arch/riscv/dts/fu540-c000.dtsi b/arch/riscv/dts/fu540-c000.dtsi
new file mode 100644
index 00..afa43c7ea3
--- /dev/null
+++ b/arch/riscv/dts/fu540-c000.dtsi
@@ -0,0 +1,251 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+/* Copyright (c) 2018-2019 SiFive, Inc */
+
+/dts-v1/;
+
+#include
+
+/ {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ compatible = "sifive,fu540-c000", "sifive,fu540";
+
+ aliases {
+ serial0 =
+ serial1 =
+ ethernet0 =
+ };
+
+ chosen {
+ };
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ cpu0: cpu@0 {
+ compatible = "sifive,e51", "sifive,rocket0", "riscv";
+ device_type = "cpu";
+ i-cache-block-size = <64>;
+ i-cache-sets = <128>;
+ i-cache-size = <16384>;
+ reg = <0>;
+ riscv,isa = "rv64imac";
+ status = "disabled";
+ cpu0_intc: interrupt-controller {
+ #interrupt-cells = <1>;
+ compatible = "riscv,cpu-intc";
+ interrupt-controller;
+ };
+ };
+ cpu1: cpu@1 {
+ compatible = "sifive,u54-mc", "sifive,rocket0", "riscv";
+ d-cache-block-size = <64>;
+ d-cache-sets = <64>;
+ d-cache-size = <32768>;
+ d-tlb-sets = <1>;
+ d-tlb-size = <32>;
+ device_type = "cpu";
+ i-cache-block-size = <64>;
+ i-cache-sets = <64>;
+ i-cache-size = <32768>;
+ i-tlb-sets = <1>;
+ i-tlb-size = <32>;
+ mmu-type = "riscv,sv39";
+ reg = <1>;
+ riscv,isa = "rv64imafdc";
+ tlb-split;
+ cpu1_intc: interrupt-controller {
+ #interrupt-cells = <1>;
+ compatible = "riscv,cpu-intc";
+ interrupt-controller;
+ };
+ };
+ cpu2: cpu@2 {
+ compatible = "sifive,u54-mc", "sifive,rocket0", "riscv";
+ d-cache-block-size = <64>;
+ d-cache-sets = <64>;
+ d-cache-size = <32768>;
+ d-tlb-sets = <1>;
+ d-tlb-size = <32>;
+ device_type = "cpu";
+ i-cache-block-size = <64>;
+ i-cache-sets = <64>;
+ i-cache-size = <32768>;
+ i-tlb-sets = <1>;
+ i-tlb-size = <32>;
+ mmu-type = "riscv,sv39";
+ reg = <2>;
+ riscv,isa = "rv64imafdc";
+ tlb-split;
+ cpu2_intc: interrupt-controller {
+ #interrupt-cells = <1>;
+ compatible = "riscv,cpu-intc";
+ interrupt-controller;
+ };
+ };
+ cpu3: cpu@3 {
+ compatible = "sifive,u54-mc", "sifive,rocket0", "riscv";
+ d-cache-block-size = <64>;
+ d-cache-sets = <64>;
+ d-cache-size = <32768>;
+ d-tlb-sets = <1>;
+
[U-Boot] [PATCH v2 4/5] riscv: dts: hifive-unleashed-a00: Add -u-boot.dtsi
Add u-boot specific dts file for hifive-unleashed-a00, this
would help to add u-boot specific properties and other node
changes without touching the base dts(i) files which are easy
to sync from Linux.
Added spi2 alias for qspi2 as an initial u-boot specific
property change.
spi probing in current dm model is very much rely on aliases
numbering. even though the qspi2 can't comes under any associated
spi nor flash it would require to specify the same to make proper
binding happen for other spi slaves.
Signed-off-by: Jagan Teki
---
arch/riscv/dts/hifive-unleashed-a00-u-boot.dtsi | 10 ++
1 file changed, 10 insertions(+)
create mode 100644 arch/riscv/dts/hifive-unleashed-a00-u-boot.dtsi
diff --git a/arch/riscv/dts/hifive-unleashed-a00-u-boot.dtsi
b/arch/riscv/dts/hifive-unleashed-a00-u-boot.dtsi
new file mode 100644
index 00..25ec8265a5
--- /dev/null
+++ b/arch/riscv/dts/hifive-unleashed-a00-u-boot.dtsi
@@ -0,0 +1,10 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2019 Jagan Teki
+ */
+
+/ {
+ aliases {
+ spi2 =
+ };
+};
--
2.18.0.321.gffc6fa0e3
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 2/5] sifive: fu540: Enable OF_SEPARATE
Use dts support from U-Boot via OF_SEPARATE instead of depending from opensbi. This would help to make the necessary changes in drivers and devicetrees in uboot tree itself. this feature would also be helpful to not pass dtb during opensbi builds. Signed-off-by: Jagan Teki --- configs/sifive_fu540_defconfig | 3 ++- doc/board/sifive/fu540.rst | 2 +- 2 files changed, 3 insertions(+), 2 deletions(-) diff --git a/configs/sifive_fu540_defconfig b/configs/sifive_fu540_defconfig index 48865e5f11..979d0a0418 100644 --- a/configs/sifive_fu540_defconfig +++ b/configs/sifive_fu540_defconfig @@ -6,6 +6,7 @@ CONFIG_RISCV_SMODE=y CONFIG_DISTRO_DEFAULTS=y CONFIG_FIT=y CONFIG_MISC_INIT_R=y +CONFIG_DEFAULT_DEVICE_TREE="hifive-unleashed-a00" CONFIG_DISPLAY_CPUINFO=y CONFIG_DISPLAY_BOARDINFO=y -CONFIG_OF_PRIOR_STAGE=y +CONFIG_OF_SEPARATE=y diff --git a/doc/board/sifive/fu540.rst b/doc/board/sifive/fu540.rst index 7807f5b2c1..91b94ee06f 100644 --- a/doc/board/sifive/fu540.rst +++ b/doc/board/sifive/fu540.rst @@ -58,7 +58,7 @@ firmware. We need to compile OpenSBI with below command: .. code-block:: none -make PLATFORM=sifive/fu540 FW_PAYLOAD_PATH= FW_PAYLOAD_FDT_PATH= +make PLATFORM=sifive/fu540 FW_PAYLOAD_PATH= (Note: Prefer hifive-unleashed-a00.dtb from Linux-5.3 or higher) (Note: Linux-5.2 is also fine but it does not have ethernet DT node) -- 2.18.0.321.gffc6fa0e3 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 5/5] sifive: fu540: Enable spi-nor flash support
HiFive Unleashed A00 support is25wp256 spi-nor flash,
So enable the same and add test result log for future
reference.
Tested on SiFive FU540 board.
Signed-off-by: Jagan Teki
Reviewed-by: Bin Meng
Tested-by: Bin Meng
---
.../dts/hifive-unleashed-a00-u-boot.dtsi | 1 +
board/sifive/fu540/Kconfig| 3 +++
doc/board/sifive/fu540.rst| 19 +++
3 files changed, 23 insertions(+)
diff --git a/arch/riscv/dts/hifive-unleashed-a00-u-boot.dtsi
b/arch/riscv/dts/hifive-unleashed-a00-u-boot.dtsi
index 25ec8265a5..d7a64134db 100644
--- a/arch/riscv/dts/hifive-unleashed-a00-u-boot.dtsi
+++ b/arch/riscv/dts/hifive-unleashed-a00-u-boot.dtsi
@@ -5,6 +5,7 @@
/ {
aliases {
+ spi0 =
spi2 =
};
};
diff --git a/board/sifive/fu540/Kconfig b/board/sifive/fu540/Kconfig
index 5d65080429..c5a1bca03c 100644
--- a/board/sifive/fu540/Kconfig
+++ b/board/sifive/fu540/Kconfig
@@ -26,6 +26,7 @@ config BOARD_SPECIFIC_OPTIONS # dummy
imply CMD_FS_GENERIC
imply CMD_NET
imply CMD_PING
+ imply CMD_SF
imply CLK_SIFIVE
imply CLK_SIFIVE_FU540_PRCI
imply DOS_PARTITION
@@ -40,6 +41,8 @@ config BOARD_SPECIFIC_OPTIONS # dummy
imply SIFIVE_SERIAL
imply SPI
imply SPI_SIFIVE
+ imply SPI_FLASH
+ imply SPI_FLASH_ISSI
imply MMC
imply MMC_SPI
imply MMC_BROKEN_CD
diff --git a/doc/board/sifive/fu540.rst b/doc/board/sifive/fu540.rst
index 91b94ee06f..2e70cad02e 100644
--- a/doc/board/sifive/fu540.rst
+++ b/doc/board/sifive/fu540.rst
@@ -366,3 +366,22 @@ load uImage.
Please press Enter to activate this console.
/ #
+
+Sample spi nor flash test
+-
+
+.. code-block:: none
+
+ => sf probe 0:2
+ SF: Detected is25wp256 with page size 256 Bytes, erase size 4 KiB, total 32
MiB
+ => sf erase 0x100 0x10
+ SF: 1048576 bytes @ 0x100 Erased: OK
+ => mw.b 0xc000 0xaa 0x10
+ => sf write 0xc000 0x100 0x10
+ device 0 offset 0x100, size 0x10
+ SF: 1048576 bytes @ 0x100 Written: OK
+ => sf read 0xf000 0x100 0x10
+ device 0 offset 0x100, size 0x10
+ SF: 1048576 bytes @ 0x100 Read: OK
+ => cmp.b 0xf000 0xc000 0x10
+ Total of 1048576 byte(s) were the same
--
2.18.0.321.gffc6fa0e3
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 3/5] mtd: spi-nor: ids: Add is25wp256 chip
Add is25wp256, chip to spi-nor id table.
Tested on SiFive FU540 board.
Signed-off-by: Jagan Teki
Reviewed-by: Bin Meng
Tested-by: Bin Meng
---
drivers/mtd/spi/spi-nor-ids.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/mtd/spi/spi-nor-ids.c b/drivers/mtd/spi/spi-nor-ids.c
index 6996c0a286..04db986561 100644
--- a/drivers/mtd/spi/spi-nor-ids.c
+++ b/drivers/mtd/spi/spi-nor-ids.c
@@ -128,6 +128,8 @@ const struct flash_info spi_nor_ids[] = {
SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
{ INFO("is25wp128", 0x9d7018, 0, 64 * 1024, 256,
SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
+ { INFO("is25wp256", 0x9d7019, 0, 64 * 1024, 512,
+ SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
#endif
#ifdef CONFIG_SPI_FLASH_MACRONIX /* MACRONIX */
/* Macronix */
--
2.18.0.321.gffc6fa0e3
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 0/5] riscv: sifive/fu540: Enable SPI-NOR support
This is v2 patchset, enable SPI-NOR flash on SiFive hifive-unleashed-a00 board, here is v1 [1]. Changes for v2: - use latest sifive commit from linux-next - fix typos in commit message - rebased on master patch 0001 - 02: support devicetree patch 0003: add is25wp256 chip patch 0004 - 05: enable spi-nor flash All tested in Sifive fuse540 hifive-unleashed-a00 board. [1] https://patchwork.ozlabs.org/cover/1168959/ Any inputs? Jagan. Jagan Teki (5): riscv: dts: Add hifive-unleashed-a00 dts from Linux sifive: fu540: Enable OF_SEPARATE mtd: spi-nor: ids: Add is25wp256 chip riscv: dts: hifive-unleashed-a00: Add -u-boot.dtsi sifive: fu540: Enable spi-nor flash support arch/riscv/dts/Makefile | 1 + arch/riscv/dts/fu540-c000.dtsi| 251 ++ .../dts/hifive-unleashed-a00-u-boot.dtsi | 11 + arch/riscv/dts/hifive-unleashed-a00.dts | 96 +++ board/sifive/fu540/Kconfig| 3 + configs/sifive_fu540_defconfig| 3 +- doc/board/sifive/fu540.rst| 21 +- drivers/mtd/spi/spi-nor-ids.c | 2 + 8 files changed, 386 insertions(+), 2 deletions(-) create mode 100644 arch/riscv/dts/fu540-c000.dtsi create mode 100644 arch/riscv/dts/hifive-unleashed-a00-u-boot.dtsi create mode 100644 arch/riscv/dts/hifive-unleashed-a00.dts -- 2.18.0.321.gffc6fa0e3 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] pico-imx7d: polish uart clock id definition
Stefano Babic 于2019年10月13日周日 下午9:35写道：
>
> Hi Jun,
>
> I am just trying to check if some patch was silently lost, I found yours:
>
> On 16/07/19 09:42, Jun Nie wrote:
> > Polish uart clock id definition. Default IMX7 UART ID is UART1
> > as original parameter in imx_get_uartclk().
> >
> > Signed-off-by: Jun Nie
> > ---
> > arch/arm/include/asm/arch-mx7/clock.h | 18 +-
> > 1 file changed, 1 insertion(+), 17 deletions(-)
> >
> > diff --git a/arch/arm/include/asm/arch-mx7/clock.h
> > b/arch/arm/include/asm/arch-mx7/clock.h
> > index 1d07fde..a8e6097 100644
> > --- a/arch/arm/include/asm/arch-mx7/clock.h
> > +++ b/arch/arm/include/asm/arch-mx7/clock.h
> > @@ -175,23 +175,7 @@ enum clk_root_index {
> > CLK_ROOT_MAX,
> > };
> >
> > -#if (CONFIG_CONS_INDEX == 0)
> > -#define UART_CLK_ROOT UART1_CLK_ROOT
> > -#elif (CONFIG_CONS_INDEX == 1)
> > -#define UART_CLK_ROOT UART2_CLK_ROOT
> > -#elif (CONFIG_CONS_INDEX == 2)
> > -#define UART_CLK_ROOT UART3_CLK_ROOT
> > -#elif (CONFIG_CONS_INDEX == 3)
> > -#define UART_CLK_ROOT UART4_CLK_ROOT
> > -#elif (CONFIG_CONS_INDEX == 4)
> > -#define UART_CLK_ROOT UART5_CLK_ROOT
> > -#elif (CONFIG_CONS_INDEX == 5)
> > -#define UART_CLK_ROOT UART6_CLK_ROOT
> > -#elif (CONFIG_CONS_INDEX == 6)
> > -#define UART_CLK_ROOT UART7_CLK_ROOT
> > -#else
> > -#error "Invalid IMX UART ID for serial console is defined"
> > -#endif
> > +#define UART_CLK_ROOT (UART1_CLK_ROOT + CONFIG_CONS_INDEX)
> >
> > struct clk_root_setting {
> > enum clk_root_index root;
> >
>
> It looks ok but CONFIG_CONS_INDEX *must* be set, else it breaks boards.
> Patch breaks at least the colibri boards.
>
> Best regards,
> Stefano
Thanks for finding the bug! I will test more boards in next round.
This patch is an independent optimization patch to other patches. So I
will sumit next version later.
Regards,
Jun
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 4/4] test: dm: spi: Fix sandbox dm_test_spi_find()
On Mon, Sep 9, 2019 at 6:30 PM Bin Meng wrote: > > Per sandbox_cs_info(), sandbox spi controller only supports chip > select 0. Current test case tries to locate devices on chip select > 1, and any call to spi_get_bus_and_cs() or spi_cs_info() with cs > number 1 should not return 0. > > This updates the test case to handle it correctly. > > Signed-off-by: Bin Meng > > --- > > Changes in v2: > - new patch to fix sandbox dm_test_spi_find() > > test/dm/spi.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/test/dm/spi.c b/test/dm/spi.c > index ffd789c..8e417ac 100644 > --- a/test/dm/spi.c > +++ b/test/dm/spi.c > @@ -77,10 +77,10 @@ static int dm_test_spi_find(struct unit_test_state *uts) > /* We should be able to add something to another chip select */ > ut_assertok(sandbox_sf_bind_emul(state, busnum, cs_b, bus, node, > "name")); > - ut_assertok(spi_get_bus_and_cs(busnum, cs_b, speed, mode, > + ut_asserteq(-EINVAL, spi_get_bus_and_cs(busnum, cs_b, speed, mode, >"spi_flash_std", "name", , > )); > - ut_assertok(spi_cs_info(bus, cs_b, )); > - ut_asserteq_ptr(info.dev, slave->dev); > + ut_asserteq(-EINVAL, spi_cs_info(bus, cs_b, )); > + ut_asserteq_ptr(NULL, info.dev); I assume you ran the sandbox test for this, if yes Reviewed-by: Jagan Teki ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 3/4] dm: spi: Check cs number before accessing slaves
On Mon, Sep 9, 2019 at 6:30 PM Bin Meng wrote: > > Add chip select number check in spi_find_chip_select(). Since we discussed the cs check to common call in spi_find_chip_select. Would you please add some more commit description. > > Signed-off-by: Bin Meng > > --- Tested-by: Jagan Teki # SoPine ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] virtio: pci: use correct type in virtio_pci_bind()
On Wed, Oct 16, 2019 at 6:59 PM Heinrich Schuchardt wrote: > > For printing as %u we should use an unsigned int. > > Signed-off-by: Heinrich Schuchardt > --- > drivers/virtio/virtio_pci_legacy.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 v2 1/4] dm: spi: Return 0 if driver does not implement ops->cs_info
On Mon, Sep 9, 2019 at 6:30 PM Bin Meng wrote: > > If an SPI controller driver does not implement ops->cs_info, that > probably means any chip select number could be valid, hence let's > return 0 for spi_cs_info(). > > Signed-off-by: Bin Meng > Reviewed-by: Jagan Teki > > --- Applied to u-boot-spi/master ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/3] ARM: imx: Fix bmode detection from grp10
Hi Claudius,
On Wed, Oct 16, 2019 at 10:28 AM Claudius Heine wrote:
>
> imx6_is_bmode_from_gpr10 always returns false, because
> IMX6_SRC_GPR10_BMODE is 1<<28 and gets casted to u8 on return.
>
> Instead cast them to a boolean value before return of the function.
>
> Signed-off-by: Claudius Heine
> ---
> arch/arm/include/asm/mach-imx/sys_proto.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/include/asm/mach-imx/sys_proto.h
> b/arch/arm/include/asm/mach-imx/sys_proto.h
> index 96530e563e..b6105d0798 100644
> --- a/arch/arm/include/asm/mach-imx/sys_proto.h
> +++ b/arch/arm/include/asm/mach-imx/sys_proto.h
> @@ -91,7 +91,7 @@ enum imx6_bmode {
>
> static inline u8 imx6_is_bmode_from_gpr10(void)
Would it make more sense to convert imx6_is_bmode_from_gpr10() to
return bool instead of u8?
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 36/37] dm: pmic: add da9063 PMIC driver and regulators
Hi Robert, On 16/10/2019 13:11, Robert Beckett wrote: Huh, I had not seen that. Martin's versions looks more complete than mine, so I would say go with that one. Martin: any objections to including your patches in here? I dont mind pushing it through and handling any review comments etc. I am keen to get get this upstreamed. No that's fine by me. It would be good to get them upstream. Regards, Martin ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 36/37] dm: pmic: add da9063 PMIC driver and regulators
On Wed, 2019-10-16 at 07:24 +, Schrempf Frieder wrote:
> Hi Robert,
>
> On 15.10.19 17:53, Robert Beckett wrote:
> > Add DM driver to support Dialog DA9063.
> > Currently it support binding regulator children.
> >
> > Signed-off-by: Robert Beckett
>
> I also have a board with DA9063 and was looking for support in U-
> Boot. I
> found patches from Martin Fuzzey [1] and pulled them in almost as is
> and
> found them to work just fine.
>
> Unfortunately I didn't have time to resend them yet, but you can
> find
> the rebased patches here: [2].
>
> On a first glance your implementation looks different, so it seems
> you
> didn't use Martin's patches. Though the resulting features probably
> will
> be similar.
>
> I only had a very quick look and one difference seems to be that
> your
> regulator implementation supports the AUTO and SYNC mode, while
> Martin's
> version supports AUTO, SYNC and SLEEP. There might be other
> differences.
>
> What do you think? Which version would be better?
(+cc Martin Fuzzey)
Huh, I had not seen that.
Martin's versions looks more complete than mine, so I would say go with
that one.
Martin: any objections to including your patches in here? I dont mind
pushing it through and handling any review comments etc. I am keen to
get get this upstreamed.
>
> Also find a few comments below, though I didn't do a full review,
> yet.
>
> Thanks,
> Frieder
>
> [1] https://patchwork.ozlabs.org/cover/979346/
> [2] https://github.com/fschrempf/u-boot/commits/da9063
>
> > ---
> > drivers/power/pmic/Kconfig | 8 +
> > drivers/power/pmic/Makefile | 1 +
> > drivers/power/pmic/da9063.c | 270 ++
> > drivers/power/regulator/Kconfig | 7 +
> > drivers/power/regulator/Makefile | 1 +
> > drivers/power/regulator/da9063.c | 320
> > +++
> > include/power/da9063_pmic.h | 303
> > +
> > 7 files changed, 910 insertions(+)
> > create mode 100644 drivers/power/pmic/da9063.c
> > create mode 100644 drivers/power/regulator/da9063.c
> > create mode 100644 include/power/da9063_pmic.h
> >
> > diff --git a/drivers/power/pmic/Kconfig
> > b/drivers/power/pmic/Kconfig
> > index 586772fdec..6dd7b1bf76 100644
> > --- a/drivers/power/pmic/Kconfig
> > +++ b/drivers/power/pmic/Kconfig
> > @@ -267,3 +267,11 @@ config SPL_PMIC_LP87565
> > help
> > The LP87565 is a PMIC containing a bunch of SMPS.
> > This driver binds the pmic children in SPL.
> > +
> > +config DM_PMIC_DA9063
> > + bool "Enable support for Dialog DA9063 PMIC"
> > + depends on DM_PMIC && (DM_I2C || DM_SPI)
> > + help
> > + The DA9063 is a PMIC providing 6 BUCK converters and 11 LDO
> > regulators.
> > + It can be accessed via I2C or SPI.
> > + This driver binds the pmic children.
> > diff --git a/drivers/power/pmic/Makefile
> > b/drivers/power/pmic/Makefile
> > index 888dbb2857..9be9d5d9a0 100644
> > --- a/drivers/power/pmic/Makefile
> > +++ b/drivers/power/pmic/Makefile
> > @@ -25,6 +25,7 @@ obj-$(CONFIG_$(SPL_)PMIC_PALMAS) += palmas.o
> > obj-$(CONFIG_$(SPL_)PMIC_LP873X) += lp873x.o
> > obj-$(CONFIG_$(SPL_)PMIC_LP87565) += lp87565.o
> > obj-$(CONFIG_PMIC_STPMIC1) += stpmic1.o
> > +obj-$(CONFIG_DM_PMIC_DA9063) += da9063.o
>
> It would be good to be able to enable the driver for U-Boot proper
> and
> SPL separately. So this should be CONFIG_$(SPL_)DM_PMIC_DA9063.
>
> >
> > obj-$(CONFIG_POWER_LTC3676) += pmic_ltc3676.o
> > obj-$(CONFIG_POWER_MAX77696) += pmic_max77696.o
> > diff --git a/drivers/power/pmic/da9063.c
> > b/drivers/power/pmic/da9063.c
> > new file mode 100644
> > index 00..81a7803b09
> > --- /dev/null
> > +++ b/drivers/power/pmic/da9063.c
> > @@ -0,0 +1,270 @@
> > +// SPDX-License-Identifier: GPL-2.0+
> > +/*
> > + * (C) Copyright 2019 Collabora
> > + * (C) Copyright 2019 GE
> > + */
> > +
> > +#define DEBUG 1
>
> This should not be here.
>
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +static const struct pmic_child_info pmic_children_info[] = {
> > + { .prefix = "bcore", .driver = DA9063_BUCK_DRIVER },
> > + { .prefix = "bpro", .driver = DA9063_BUCK_DRIVER },
> > + { .prefix = "bmem", .driver = DA9063_BUCK_DRIVER },
> > + { .prefix = "bio", .driver = DA9063_BUCK_DRIVER },
> > + { .prefix = "bperi", .driver = DA9063_BUCK_DRIVER },
> > + { .prefix = "ldo", .driver = DA9063_LDO_DRIVER },
> > + { },
> > +};
> > +
> > +static int da9063_reg_count(struct udevice *dev)
> > +{
> > + return DA9063_NUM_OF_REGS;
> > +}
> > +
> > +#if defined(CONFIG_DM_I2C)
> > +static int da9063_i2c_read(struct udevice *dev, uint reg, uint8_t
> > *buff,
> > + int len)
> > +{
> > + int ret;
> > +
> > + /* only support single reg accesses */
> > + if (len != 1)
> > + return -EINVAL;
> > +
> > + ret =
[U-Boot] [PATCH 1/1] virtio: pci: use correct type in virtio_pci_bind()
For printing as %u we should use an unsigned int.
Signed-off-by: Heinrich Schuchardt
---
drivers/virtio/virtio_pci_legacy.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/virtio/virtio_pci_legacy.c
b/drivers/virtio/virtio_pci_legacy.c
index 08764ee6f2..202e5ab1d3 100644
--- a/drivers/virtio/virtio_pci_legacy.c
+++ b/drivers/virtio/virtio_pci_legacy.c
@@ -277,7 +277,7 @@ static int virtio_pci_notify(struct udevice *udev, struct
virtqueue *vq)
static int virtio_pci_bind(struct udevice *udev)
{
- static int num_devs;
+ static unsigned int num_devs;
char name[20];
/* Create a unique device name for PCI type devices */
--
2.23.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 6/9] mpc85xx, socrates: disable VIDEO
Hello Priyanka Jain, Am 16.10.2019 um 12:47 schrieb Priyanka Jain: -Original Message- From: Heiko Schocher Sent: Wednesday, October 16, 2019 4:11 PM To: Priyanka Jain Cc: U-Boot Mailing List Subject: Re: [U-Boot] [PATCH v2 6/9] mpc85xx, socrates: disable VIDEO Hello Priyanka Jain, Am 16.10.2019 um 09:20 schrieb Heiko Schocher: Hello Priyanka Jain, Am 16.10.2019 um 08:56 schrieb Priyanka Jain: -Original Message- From: U-Boot On Behalf Of Heiko Schocher Sent: Wednesday, October 16, 2019 9:26 AM To: U-Boot Mailing List Subject: [U-Boot] [PATCH v2 6/9] mpc85xx, socrates: disable VIDEO disable video, as not really needed longer. I see the video driver code is getting removed by this patch. Please explain why video driver was required earlier and not now? I did not the original port of the board, but I think it was used for a splash image. Nowadays the customer mentioned he do not need any video support in U-Boot. Answer from the customer: Video support was only experimental at the beginning of the project, video chips haven't been assembled for release versions of socrates at any time. Should I add this info into the commit message? Yes, that will be helpful Added to commit message, but waiting for more comments to this series. bye, Heiko -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-52 Fax: +49-8142-66989-80 Email: h...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 6/9] mpc85xx, socrates: disable VIDEO
>-Original Message- >From: Heiko Schocher >Sent: Wednesday, October 16, 2019 4:11 PM >To: Priyanka Jain >Cc: U-Boot Mailing List >Subject: Re: [U-Boot] [PATCH v2 6/9] mpc85xx, socrates: disable VIDEO > >Hello Priyanka Jain, > >Am 16.10.2019 um 09:20 schrieb Heiko Schocher: >> Hello Priyanka Jain, >> >> Am 16.10.2019 um 08:56 schrieb Priyanka Jain: >>> -Original Message- From: U-Boot On Behalf Of Heiko Schocher Sent: Wednesday, October 16, 2019 9:26 AM To: U-Boot Mailing List Subject: [U-Boot] [PATCH v2 6/9] mpc85xx, socrates: disable VIDEO disable video, as not really needed longer. >>> I see the video driver code is getting removed by this patch. >>> Please explain why video driver was required earlier and not now? >> >> I did not the original port of the board, but I think it was used for >> a splash image. Nowadays the customer mentioned he do not need any >> video support in U-Boot. > >Answer from the customer: >Video support was only experimental at the beginning of the project, video >chips haven't been assembled for release versions of socrates at any time. > >Should I add this info into the commit message? Yes, that will be helpful --priyankajain > >bye, >Heiko >-- >DENX Software Engineering GmbH, Managing Director: Wolfgang Denk >HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany >Phone: +49-8142-66989-52 Fax: +49-8142-66989-80 Email: h...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 6/9] mpc85xx, socrates: disable VIDEO
Hello Priyanka Jain, Am 16.10.2019 um 09:20 schrieb Heiko Schocher: Hello Priyanka Jain, Am 16.10.2019 um 08:56 schrieb Priyanka Jain: -Original Message- From: U-Boot On Behalf Of Heiko Schocher Sent: Wednesday, October 16, 2019 9:26 AM To: U-Boot Mailing List Subject: [U-Boot] [PATCH v2 6/9] mpc85xx, socrates: disable VIDEO disable video, as not really needed longer. I see the video driver code is getting removed by this patch. Please explain why video driver was required earlier and not now? I did not the original port of the board, but I think it was used for a splash image. Nowadays the customer mentioned he do not need any video support in U-Boot. Answer from the customer: Video support was only experimental at the beginning of the project, video chips haven't been assembled for release versions of socrates at any time. Should I add this info into the commit message? bye, Heiko -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-52 Fax: +49-8142-66989-80 Email: h...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v3 2/2] ARM: dts: imx6ull-colibri: pre-reloc for uart pinmux modes
From: Igor Opaniuk
Add u-boot,dm-pre-reloc properties for uart pinmux configuration
nodes, which enables UART as early as possible (before relocation).
Without this we miss almost the half of output (U-boot version,
CPU defails, Reset cause, DRAM details etc.).
Fixes: cd69e8ef9b ("colibri-imx6ull: migrate pinctrl and regulators to dtb/dm")
Reviewed-by: Oleksandr Suvorov
Reviewed-by: Fabio Estevam
Signed-off-by: Igor Opaniuk
---
arch/arm/dts/imx6ull-colibri-u-boot.dtsi | 8
1 file changed, 8 insertions(+)
diff --git a/arch/arm/dts/imx6ull-colibri-u-boot.dtsi
b/arch/arm/dts/imx6ull-colibri-u-boot.dtsi
index e81ac8cb27..531cdcc4da 100644
--- a/arch/arm/dts/imx6ull-colibri-u-boot.dtsi
+++ b/arch/arm/dts/imx6ull-colibri-u-boot.dtsi
@@ -2,3 +2,11 @@
/*
* Copyright 2019 Toradex AG
*/
+
+_uart1 {
+ u-boot,dm-pre-reloc;
+};
+
+_uart1_ctrl1 {
+ u-boot,dm-pre-reloc;
+};
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v3 1/2] ARM: dts: imx6ull-colibri: change hierarchy of DTS files
From: Igor Opaniuk
Introduce imx6ull-colibri-u-boot.dtsi for u-boot specific properties to
keep original imx6ull-colibri.dts in sync with Linux.
Move all contents of imx6ull-colibri.dts to imx6ull-colibri.dtsi +
additionally fix checkpatch warnings.
Reviewed-by: Oleksandr Suvorov
Reviewed-by: Fabio Estevam
Signed-off-by: Igor Opaniuk
---
arch/arm/dts/imx6ull-colibri-u-boot.dtsi | 4 +
arch/arm/dts/imx6ull-colibri.dts | 628 +
arch/arm/dts/imx6ull-colibri.dtsi | 633 ++
board/toradex/colibri-imx6ull/MAINTAINERS | 2 +
4 files changed, 641 insertions(+), 626 deletions(-)
create mode 100644 arch/arm/dts/imx6ull-colibri-u-boot.dtsi
create mode 100644 arch/arm/dts/imx6ull-colibri.dtsi
diff --git a/arch/arm/dts/imx6ull-colibri-u-boot.dtsi
b/arch/arm/dts/imx6ull-colibri-u-boot.dtsi
new file mode 100644
index 00..e81ac8cb27
--- /dev/null
+++ b/arch/arm/dts/imx6ull-colibri-u-boot.dtsi
@@ -0,0 +1,4 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright 2019 Toradex AG
+ */
diff --git a/arch/arm/dts/imx6ull-colibri.dts b/arch/arm/dts/imx6ull-colibri.dts
index 262205ac5e..15338a1ae3 100644
--- a/arch/arm/dts/imx6ull-colibri.dts
+++ b/arch/arm/dts/imx6ull-colibri.dts
@@ -3,634 +3,10 @@
* Copyright 2018-2019 Toradex AG
*/
-/dts-v1/;
-#include
-#include "imx6ull.dtsi"
+#include "imx6ull-colibri.dtsi"
+#include "imx6ull-colibri-u-boot.dtsi"
/ {
model = "Toradex Colibri iMX6ULL";
compatible = "toradex,colibri-imx6ull", "fsl,imx6ull";
-
- aliases {
- u-boot,dm-pre-reloc;
- mmc0 =
- usb0 = /* required for ums */
- display0 =
- };
-
- chosen {
- stdout-path =
- };
-
- reg_module_3v3: regulator-module-3v3 {
- compatible = "regulator-fixed";
- regulator-always-on;
- regulator-name = "+V3.3";
- regulator-min-microvolt = <330>;
- regulator-max-microvolt = <330>;
- };
-
- reg_module_3v3_avdd: regulator-module-3v3-avdd {
- compatible = "regulator-fixed";
- regulator-always-on;
- regulator-name = "+V3.3_AVDD_AUDIO";
- regulator-min-microvolt = <330>;
- regulator-max-microvolt = <330>;
- };
-
- reg_5v0: regulator-5v0 {
- compatible = "regulator-fixed";
- regulator-name = "5V";
- regulator-min-microvolt = <500>;
- regulator-max-microvolt = <500>;
- };
-
- reg_sd1_vmmc: regulator-sd1-vmmc {
- compatible = "regulator-gpio";
- gpio = < 9 GPIO_ACTIVE_HIGH>;
- pinctrl-names = "default";
- pinctrl-0 = <_snvs_reg_sd>;
- regulator-always-on;
- regulator-name = "+V3.3_1.8_SD";
- regulator-min-microvolt = <180>;
- regulator-max-microvolt = <330>;
- states = <180 0x1 330 0x0>;
- vin-supply = <_module_3v3>;
- };
-
- reg_usbh_vbus: regulator-usbh-vbus {
- compatible = "regulator-fixed";
- pinctrl-names = "default";
- pinctrl-0 = <_usbh_reg>;
- regulator-name = "VCC_USB[1-4]";
- regulator-min-microvolt = <500>;
- regulator-max-microvolt = <500>;
- gpio = < 2 GPIO_ACTIVE_LOW>; /* USBH_PEN */
- vin-supply = <_5v0>;
- };
-};
-
- {
- num-channels = <10>;
- vref-supply = <_module_3v3_avdd>;
-};
-
-/* Colibri SPI */
- {
- cs-gpios = < 26 GPIO_ACTIVE_HIGH>;
- pinctrl-names = "default";
- pinctrl-0 = <_ecspi1 _ecspi1_cs>;
-};
-
-/* Ethernet */
- {
- pinctrl-names = "default";
- pinctrl-0 = <_enet2>;
- phy-mode = "rmii";
- phy-handle = <>;
- status = "okay";
-
- mdio {
- #address-cells = <1>;
- #size-cells = <0>;
-
- ethphy1: ethernet-phy@2 {
- compatible = "ethernet-phy-ieee802.3-c22";
- max-speed = <100>;
- reg = <2>;
- };
- };
-};
-
-/* NAND */
- {
- pinctrl-names = "default";
- pinctrl-0 = <_gpmi_nand>;
- nand-on-flash-bbt;
- nand-ecc-mode = "hw";
- nand-ecc-strength = <8>;
- nand-ecc-step-size = <512>;
- status = "okay";
-};
-
-/*
- * I2C3_SDA/SCL on SODIMM 194/196 (e.g. RTC on carrier board)
- */
- {
- pinctrl-names = "default", "gpio";
- pinctrl-0 = <_i2c1>;
- pinctrl-1 = <_i2c1_gpio>;
- sda-gpios = < 29 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
- scl-gpios = < 28 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
- status = "okay";
-};
-
-/*
- * PWR_I2C: power I2C to audio codec, PMIC, temperature sensor and
- * touch screen controller
[U-Boot] [PATCH v3 0/2] imx6ull: Fix missing initial output from UART
For Colibri iMX6ULL we have to set pinmux for uart configuration ASAP
(ideally before relocation) to get serial console working. Without this
we miss almost the half of output (U-boot version, CPU defails,
Reset cause, DRAM details etc.).
To achieve this we need to force pinctrl-mx6 to get probed before
relocation (is already applied) and add u-boot,dm-pre-reloc properties to
uart pinmux configuration nodes. Setting pinmux configuration for UART
before was done in board_early_init_f().
Igor Opaniuk (2):
ARM: dts: imx6ull-colibri: change hierarchy of DTS files
ARM: dts: imx6ull-colibri: pre-reloc for uart pinmux modes
v3:
- Applied R-b tags [Fabio Estevam], [Oleksandr Suvorov].
- Rebased on the latest u-boot-imx/master.
- Excluded from patch series c115cd154c("pinctrl: nxp:
DM_FLAG_PRE_RELOC by default") as it was already applied by Stefano
(https://patchwork.ozlabs.org/patch/1136382/).
v2:
- Addressed comments [Fabio Estevam].
arch/arm/dts/imx6ull-colibri-u-boot.dtsi | 12 +
arch/arm/dts/imx6ull-colibri.dts | 628 +
arch/arm/dts/imx6ull-colibri.dtsi | 633 ++
board/toradex/colibri-imx6ull/MAINTAINERS | 2 +
4 files changed, 649 insertions(+), 626 deletions(-)
create mode 100644 arch/arm/dts/imx6ull-colibri-u-boot.dtsi
create mode 100644 arch/arm/dts/imx6ull-colibri.dtsi
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 14/38] spi: Add support for memory-mapped flash
Hi Simon,
On 12/10/19 10:03 AM, Bin Meng wrote:
> Hi Simon,
>
> On Sat, Oct 12, 2019 at 11:08 AM Simon Glass wrote:
>>
>> Hi Bin,
>>
>> On Wed, 9 Oct 2019 at 07:55, Bin Meng wrote:
>>>
>>> Hi Simon,
>>>
>>> On Wed, Sep 25, 2019 at 10:12 PM Simon Glass wrote:
On x86 platforms the SPI flash can be mapped into memory so that the
contents can be read with normal memory accesses.
Add a new SPI flash method to find the location of the SPI flash in
memory. This differs from the existing device-tree "memory-map" mechanism
in that the location can be discovered at run-time.
Whats is the usecase? Why can't spi_flash_read() be used instead?
Flash + Controller driver can underneath take care of using memory
mapped mode to read data from flash right while making sure that access
is within valid window?
Signed-off-by: Simon Glass
---
Changes in v2: None
drivers/mtd/spi/sandbox_direct.c | 11 +++
drivers/mtd/spi/sf-uclass.c | 11 +++
include/spi_flash.h | 27 +++
test/dm/sf.c | 9 +
4 files changed, 58 insertions(+)
diff --git a/drivers/mtd/spi/sandbox_direct.c
b/drivers/mtd/spi/sandbox_direct.c
index 43d8907710c..fb515edcb7c 100644
--- a/drivers/mtd/spi/sandbox_direct.c
+++ b/drivers/mtd/spi/sandbox_direct.c
@@ -68,6 +68,16 @@ static int sandbox_direct_get_sw_write_prot(struct
udevice *dev)
return priv->write_prot++ ? 1 : 0;
}
+static int sandbox_direct_get_mmap(struct udevice *dev, ulong *map_basep,
+ size_t *map_sizep, u32 *offsetp)
+{
+ *map_basep = 0x1000;
+ *map_sizep = 0x2000;
+ *offsetp = 0x100;
+
+ return 0;
+}
+
static int sandbox_direct_probe(struct udevice *dev)
{
struct sandbox_direct_priv *priv = dev_get_priv(dev);
@@ -82,6 +92,7 @@ static struct dm_spi_flash_ops sandbox_direct_ops = {
.write = sandbox_direct_write,
.erase = sandbox_direct_erase,
.get_sw_write_prot = sandbox_direct_get_sw_write_prot,
+ .get_mmap = sandbox_direct_get_mmap,
};
static const struct udevice_id sandbox_direct_ids[] = {
diff --git a/drivers/mtd/spi/sf-uclass.c b/drivers/mtd/spi/sf-uclass.c
index 719a2fd23ae..127ec7e7aa6 100644
--- a/drivers/mtd/spi/sf-uclass.c
+++ b/drivers/mtd/spi/sf-uclass.c
@@ -28,6 +28,17 @@ int spi_flash_erase_dm(struct udevice *dev, u32 offset,
size_t len)
return log_ret(sf_get_ops(dev)->erase(dev, offset, len));
}
+int spi_flash_get_mmap(struct udevice *dev, ulong *map_basep, size_t
*map_sizep,
+ u32 *offsetp)
+{
+ struct dm_spi_flash_ops *ops = sf_get_ops(dev);
+
+ if (!ops->get_mmap)
+ return -ENOSYS;
+
+ return ops->get_mmap(dev, map_basep, map_sizep, offsetp);
+}
+
int spl_flash_get_sw_write_prot(struct udevice *dev)
{
struct dm_spi_flash_ops *ops = sf_get_ops(dev);
diff --git a/include/spi_flash.h b/include/spi_flash.h
index 55b4721813a..840189e22c7 100644
--- a/include/spi_flash.h
+++ b/include/spi_flash.h
@@ -47,6 +47,19 @@ struct dm_spi_flash_ops {
* other -ve value on error
*/
int (*get_sw_write_prot)(struct udevice *dev);
+
+ /**
+* get_mmap() - Get memory-mapped SPI
+*
+* @dev:SPI flash device
+* @map_basep: Returns base memory address for mapped SPI
+* @map_sizep: Returns size of mapped SPI
+* @offsetp:Returns start offset of SPI flash where the map
works
+* correctly (offsets before this are not visible)
+* @return 0 if OK, -EFAULT if memory mapping is not available
+*/
>>>
>>> I feel odd to add such an op to the flash op, as memory address is not
>>> determined by the flash itself, but the SPI flash controller. We
>>> probably should add the op to the SPI flash controller instead.
>>
>> So do you think this should be added to UCLASS_SPI?
>
> Yes, I think so. Jagan, what's your recommendation?
>
>>
>> As it stands we don't actually use that uclass with this SPI flash
>> driver - it implements the SPI_FLASH interface directly.
>>
>> But given that I'm going to try to use the same ich.c driver this
>> should be easy enough.
>>
>> I've just found the weird mem_ops argument within struct dm_spi_ops...oh
>> dear.
>>
>
> The mem_ops was added by Vignesh. I believe that was derived from the
> Linux kernel.
>
Some SPI controllers provide interfaces to work with any type of SPI
flashes like SPI NOR, SPI NAND, SPI SRAM etc. They may
[U-Boot] [PATCH 10/10] imx8mm: evk: enable bd71837 pmic
Enable bd71837 pmic for i.MX8MM EVK board, need to set voltage for
DRAM and linux suspend voltage requirement.
Signed-off-by: Peng Fan
---
arch/arm/dts/imx8mm-evk-u-boot.dtsi | 20 ++
board/freescale/imx8mm_evk/spl.c| 41 +
configs/imx8mm_evk_defconfig| 5 -
3 files changed, 65 insertions(+), 1 deletion(-)
diff --git a/arch/arm/dts/imx8mm-evk-u-boot.dtsi
b/arch/arm/dts/imx8mm-evk-u-boot.dtsi
index 8d61597e0c..16093f2067 100644
--- a/arch/arm/dts/imx8mm-evk-u-boot.dtsi
+++ b/arch/arm/dts/imx8mm-evk-u-boot.dtsi
@@ -90,3 +90,23 @@
{
u-boot,dm-spl;
};
+
+ {
+ u-boot,dm-spl;
+};
+
+&{/soc@0/bus@3080/i2c@30a2/pmic@4b} {
+ u-boot,dm-spl;
+};
+
+&{/soc@0/bus@3080/i2c@30a2/pmic@4b/regulators} {
+ u-boot,dm-spl;
+};
+
+_i2c1 {
+ u-boot,dm-spl;
+};
+
+_pmic {
+ u-boot,dm-spl;
+};
diff --git a/board/freescale/imx8mm_evk/spl.c b/board/freescale/imx8mm_evk/spl.c
index 2a5fb27a73..2d08f9a563 100644
--- a/board/freescale/imx8mm_evk/spl.c
+++ b/board/freescale/imx8mm_evk/spl.c
@@ -18,6 +18,9 @@
#include
#include
+#include
+#include
+
DECLARE_GLOBAL_DATA_PTR;
int spl_board_boot_device(enum boot_device boot_dev_spl)
@@ -79,6 +82,42 @@ int board_early_init_f(void)
return 0;
}
+int power_init_board(void)
+{
+ struct udevice *dev;
+ int ret;
+
+ ret = pmic_get("pmic@4b", );
+ if (ret == -ENODEV) {
+ puts("No pmic\n");
+ return 0;
+ }
+ if (ret != 0)
+ return ret;
+
+ /* decrease RESET key long push time from the default 10s to 10ms */
+ pmic_reg_write(dev, BD718XX_PWRONCONFIG1, 0x0);
+
+ /* unlock the PMIC regs */
+ pmic_reg_write(dev, BD718XX_REGLOCK, 0x1);
+
+ /* increase VDD_SOC to typical value 0.85v before first DRAM access */
+ pmic_reg_write(dev, BD718XX_BUCK1_VOLT_RUN, 0x0f);
+
+ /* increase VDD_DRAM to 0.975v for 3Ghz DDR */
+ pmic_reg_write(dev, BD718XX_1ST_NODVS_BUCK_VOLT, 0x83);
+
+#ifndef CONFIG_IMX8M_LPDDR4
+ /* increase NVCC_DRAM_1V2 to 1.2v for DDR4 */
+ pmic_reg_write(dev, BD718XX_4TH_NODVS_BUCK_VOLT, 0x28);
+#endif
+
+ /* lock the PMIC regs */
+ pmic_reg_write(dev, BD718XX_REGLOCK, 0x11);
+
+ return 0;
+}
+
void board_init_f(ulong dummy)
{
struct udevice *dev;
@@ -113,6 +152,8 @@ void board_init_f(ulong dummy)
enable_tzc380();
+ power_init_board();
+
/* DDR initialization */
spl_dram_init();
diff --git a/configs/imx8mm_evk_defconfig b/configs/imx8mm_evk_defconfig
index a934363277..4cbc62fd8f 100644
--- a/configs/imx8mm_evk_defconfig
+++ b/configs/imx8mm_evk_defconfig
@@ -12,6 +12,7 @@ CONFIG_SPL_MMC_SUPPORT=y
CONFIG_SPL_SERIAL_SUPPORT=y
CONFIG_SPL_DRIVERS_MISC_SUPPORT=y
CONFIG_SPL=y
+CONFIG_SPL_TEXT_BASE=0x7E1000
CONFIG_FIT=y
CONFIG_FIT_EXTERNAL_OFFSET=0x3000
CONFIG_SPL_LOAD_FIT=y
@@ -20,10 +21,10 @@ CONFIG_OF_SYSTEM_SETUP=y
CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=arch/arm/mach-imx/imx8m/imximage-8mm-lpddr4.cfg"
CONFIG_DEFAULT_FDT_FILE="fsl-imx8mm-evk.dtb"
CONFIG_BOARD_LATE_INIT=y
-CONFIG_SPL_TEXT_BASE=0x7E1000
CONFIG_SPL_BOARD_INIT=y
CONFIG_SPL_SEPARATE_BSS=y
CONFIG_SPL_I2C_SUPPORT=y
+CONFIG_SPL_POWER_SUPPORT=y
CONFIG_HUSH_PARSER=y
CONFIG_SYS_PROMPT="u-boot=> "
# CONFIG_CMD_EXPORTENV is not set
@@ -65,6 +66,8 @@ CONFIG_DM_ETH=y
CONFIG_PINCTRL=y
CONFIG_SPL_PINCTRL=y
CONFIG_PINCTRL_IMX8M=y
+CONFIG_DM_PMIC=y
+CONFIG_SPL_DM_PMIC_BD71837=y
CONFIG_DM_REGULATOR=y
CONFIG_DM_REGULATOR_FIXED=y
CONFIG_DM_REGULATOR_GPIO=y
--
2.16.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 07/10] pmic: bd71837: drop DEBUG macro
Drop DEBUG macro definition which is used for debug purpose. Signed-off-by: Peng Fan --- drivers/power/pmic/bd71837.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/power/pmic/bd71837.c b/drivers/power/pmic/bd71837.c index e292d42a8c..2e04298273 100644 --- a/drivers/power/pmic/bd71837.c +++ b/drivers/power/pmic/bd71837.c @@ -3,8 +3,6 @@ * Copyright 2018 NXP */ -#define DEBUG - #include #include #include -- 2.16.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 08/10] power: pmic: Kconfig: add CONFIG_SPL_DM_PMIC_BD71837
Add CONFIG_SPL_DM_PMIC_BD71837 to make this driver could be used in SPL stage Signed-off-by: Peng Fan --- drivers/power/pmic/Kconfig | 8 1 file changed, 8 insertions(+) diff --git a/drivers/power/pmic/Kconfig b/drivers/power/pmic/Kconfig index 586772fdec..4718dc700c 100644 --- a/drivers/power/pmic/Kconfig +++ b/drivers/power/pmic/Kconfig @@ -55,6 +55,14 @@ config DM_PMIC_BD71837 This config enables implementation of driver-model pmic uclass features for PMIC BD71837. The driver implements read/write operations. +config SPL_DM_PMIC_BD71837 + bool "Enable Driver Model for PMIC BD71837 in SPL stage" + depends on DM_PMIC + help + This config enables implementation of driver-model pmic uclass + features for PMIC BD71837. The driver implements read/write + operations. + config DM_PMIC_FAN53555 bool "Enable support for OnSemi FAN53555" depends on DM_PMIC && DM_REGULATOR && DM_I2C -- 2.16.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 09/10] imx8m: evk: spl: probe clk in spl early stage
We are going to add i2c pmic support before dram could be used.
So we need enable clk driver earlier, so use spl_early_init
and move clock controller probe eariler to board_init_f.
Signed-off-by: Peng Fan
---
board/freescale/imx8mm_evk/spl.c | 22 +++---
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/board/freescale/imx8mm_evk/spl.c b/board/freescale/imx8mm_evk/spl.c
index 043b5f4342..2a5fb27a73 100644
--- a/board/freescale/imx8mm_evk/spl.c
+++ b/board/freescale/imx8mm_evk/spl.c
@@ -41,16 +41,7 @@ void spl_dram_init(void)
void spl_board_init(void)
{
- struct udevice *dev;
- int ret;
-
puts("Normal Boot\n");
-
- ret = uclass_get_device_by_name(UCLASS_CLK,
- "clock-controller@3038",
- );
- if (ret < 0)
- printf("Failed to find clock node. Check device tree\n");
}
#ifdef CONFIG_SPL_LOAD_FIT
@@ -90,6 +81,7 @@ int board_early_init_f(void)
void board_init_f(ulong dummy)
{
+ struct udevice *dev;
int ret;
arch_cpu_init();
@@ -105,9 +97,17 @@ void board_init_f(ulong dummy)
/* Clear the BSS. */
memset(__bss_start, 0, __bss_end - __bss_start);
- ret = spl_init();
+ ret = spl_early_init();
if (ret) {
- debug("spl_init() failed: %d\n", ret);
+ debug("spl_early_init() failed: %d\n", ret);
+ hang();
+ }
+
+ ret = uclass_get_device_by_name(UCLASS_CLK,
+ "clock-controller@3038",
+ );
+ if (ret < 0) {
+ printf("Failed to find clock node. Check device tree\n");
hang();
}
--
2.16.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 06/10] arm: dts: imx8mm: sync dts from Linux Kernel
Sync dts for i.MX8MM from Linux Kernel 5.4.0-rc1
Signed-off-by: Peng Fan
---
arch/arm/dts/imx8mm-evk-u-boot.dtsi | 2 +-
arch/arm/dts/imx8mm-evk.dts | 285 +++-
arch/arm/dts/imx8mm.dtsi| 222 ++--
3 files changed, 459 insertions(+), 50 deletions(-)
diff --git a/arch/arm/dts/imx8mm-evk-u-boot.dtsi
b/arch/arm/dts/imx8mm-evk-u-boot.dtsi
index 1095d36e31..8d61597e0c 100644
--- a/arch/arm/dts/imx8mm-evk-u-boot.dtsi
+++ b/arch/arm/dts/imx8mm-evk-u-boot.dtsi
@@ -3,7 +3,7 @@
* Copyright 2019 NXP
*/
-&{/soc} {
+&{/soc@0} {
u-boot,dm-pre-reloc;
u-boot,dm-spl;
};
diff --git a/arch/arm/dts/imx8mm-evk.dts b/arch/arm/dts/imx8mm-evk.dts
index 1e8b10a965..faefb7182a 100644
--- a/arch/arm/dts/imx8mm-evk.dts
+++ b/arch/arm/dts/imx8mm-evk.dts
@@ -5,6 +5,7 @@
/dts-v1/;
+#include
#include "imx8mm.dtsi"
/ {
@@ -37,6 +38,41 @@
gpio = < 19 GPIO_ACTIVE_HIGH>;
enable-active-high;
};
+
+ wm8524: audio-codec {
+ #sound-dai-cells = <0>;
+ compatible = "wlf,wm8524";
+ pinctrl-names = "default";
+ pinctrl-0 = <_gpio_wlf>;
+ wlf,mute-gpios = < 21 GPIO_ACTIVE_LOW>;
+ };
+
+ sound-wm8524 {
+ compatible = "simple-audio-card";
+ simple-audio-card,name = "wm8524-audio";
+ simple-audio-card,format = "i2s";
+ simple-audio-card,frame-master = <>;
+ simple-audio-card,bitclock-master = <>;
+ simple-audio-card,widgets =
+ "Line", "Left Line Out Jack",
+ "Line", "Right Line Out Jack";
+ simple-audio-card,routing =
+ "Left Line Out Jack", "LINEVOUTL",
+ "Right Line Out Jack", "LINEVOUTR";
+
+ cpudai: simple-audio-card,cpu {
+ sound-dai = <>;
+ };
+
+ simple-audio-card,codec {
+ sound-dai = <>;
+ clocks = < IMX8MM_CLK_SAI3_ROOT>;
+ };
+ };
+};
+
+_0 {
+ cpu-supply = <_reg>;
};
{
@@ -54,19 +90,208 @@
ethphy0: ethernet-phy@0 {
compatible = "ethernet-phy-ieee802.3-c22";
reg = <0>;
- at803x,led-act-blind-workaround;
- at803x,eee-okay;
- at803x,vddio-1p8v;
};
};
};
+ {
+ clock-frequency = <40>;
+ pinctrl-names = "default";
+ pinctrl-0 = <_i2c1>;
+ status = "okay";
+
+ pmic@4b {
+ compatible = "rohm,bd71847";
+ reg = <0x4b>;
+ pinctrl-0 = <_pmic>;
+ interrupt-parent = <>;
+ interrupts = <3 GPIO_ACTIVE_LOW>;
+ rohm,reset-snvs-powered;
+
+ regulators {
+ buck1_reg: BUCK1 {
+ regulator-name = "BUCK1";
+ regulator-min-microvolt = <70>;
+ regulator-max-microvolt = <130>;
+ regulator-boot-on;
+ regulator-always-on;
+ regulator-ramp-delay = <1250>;
+ };
+
+ buck2_reg: BUCK2 {
+ regulator-name = "BUCK2";
+ regulator-min-microvolt = <70>;
+ regulator-max-microvolt = <130>;
+ regulator-boot-on;
+ regulator-always-on;
+ regulator-ramp-delay = <1250>;
+ rohm,dvs-run-voltage = <100>;
+ rohm,dvs-idle-voltage = <90>;
+ };
+
+ buck3_reg: BUCK3 {
+ // BUCK5 in datasheet
+ regulator-name = "BUCK3";
+ regulator-min-microvolt = <70>;
+ regulator-max-microvolt = <135>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ buck4_reg: BUCK4 {
+ // BUCK6 in datasheet
+ regulator-name = "BUCK4";
+ regulator-min-microvolt = <300>;
+ regulator-max-microvolt = <330>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ buck5_reg: BUCK5 {
+ // BUCK7 in datasheet
+ regulator-name =
[U-Boot] [PATCH 03/10] imx: imx8mq: add init_nand_clk
Add init_nand_clk to enable gpmi nand clock. Since i.MX8MQ not use CCF,
so we still use legacy mode to configure the clock.
Signed-off-by: Peng Fan
---
arch/arm/include/asm/arch-imx8m/clock_imx8mq.h | 2 ++
arch/arm/mach-imx/imx8m/clock_imx8mq.c | 9 +
2 files changed, 11 insertions(+)
diff --git a/arch/arm/include/asm/arch-imx8m/clock_imx8mq.h
b/arch/arm/include/asm/arch-imx8m/clock_imx8mq.h
index 9fa9eb2687..38a6f5966b 100644
--- a/arch/arm/include/asm/arch-imx8m/clock_imx8mq.h
+++ b/arch/arm/include/asm/arch-imx8m/clock_imx8mq.h
@@ -421,4 +421,6 @@ enum frac_pll_out_val {
FRAC_PLL_OUT_1000M,
FRAC_PLL_OUT_1600M,
};
+
+void init_nand_clk(void);
#endif
diff --git a/arch/arm/mach-imx/imx8m/clock_imx8mq.c
b/arch/arm/mach-imx/imx8m/clock_imx8mq.c
index 04903510f0..2db5bde211 100644
--- a/arch/arm/mach-imx/imx8m/clock_imx8mq.c
+++ b/arch/arm/mach-imx/imx8m/clock_imx8mq.c
@@ -393,6 +393,15 @@ void init_usb_clk(void)
}
}
+void init_nand_clk(void)
+{
+ clock_enable(CCGR_RAWNAND, 0);
+ clock_set_target_val(NAND_CLK_ROOT,
+CLK_ROOT_ON | CLK_ROOT_SOURCE_SEL(3) |
+CLK_ROOT_POST_DIV(CLK_ROOT_POST_DIV4));
+ clock_enable(CCGR_RAWNAND, 1);
+}
+
void init_uart_clk(u32 index)
{
/* Set uart clock root 25M OSC */
--
2.16.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 04/10] imx: spl: implement spl_boot_mode for i.MX7/8/8M
It will be easy to separate SD/EMMC when booting in SPL stage, then
no need to bother which device is BOOT_DEVICE_MMC1/2.
Signed-off-by: Peng Fan
---
arch/arm/mach-imx/spl.c | 29 +
1 file changed, 29 insertions(+)
diff --git a/arch/arm/mach-imx/spl.c b/arch/arm/mach-imx/spl.c
index f4a4617baf..dde1635a9d 100644
--- a/arch/arm/mach-imx/spl.c
+++ b/arch/arm/mach-imx/spl.c
@@ -189,6 +189,34 @@ int g_dnl_bind_fixup(struct usb_device_descriptor *dev,
const char *name)
/* called from spl_mmc to see type of boot mode for storage (RAW or FAT) */
u32 spl_boot_mode(const u32 boot_device)
{
+#if defined(CONFIG_MX7) || defined(CONFIG_IMX8M) || defined(CONFIG_IMX8)
+ switch (get_boot_device()) {
+ /* for MMC return either RAW or FAT mode */
+ case SD1_BOOT:
+ case SD2_BOOT:
+ case SD3_BOOT:
+#if defined(CONFIG_SPL_FAT_SUPPORT)
+ return MMCSD_MODE_FS;
+#else
+ return MMCSD_MODE_RAW;
+#endif
+ break;
+ case MMC1_BOOT:
+ case MMC2_BOOT:
+ case MMC3_BOOT:
+#if defined(CONFIG_SPL_FAT_SUPPORT)
+ return MMCSD_MODE_FS;
+#elif defined(CONFIG_SUPPORT_EMMC_BOOT)
+ return MMCSD_MODE_EMMCBOOT;
+#else
+ return MMCSD_MODE_RAW;
+#endif
+ break;
+ default:
+ puts("spl: ERROR: unsupported device\n");
+ hang();
+ }
+#else
/*
* When CONFIG_SPL_FORCE_MMC_BOOT is defined the 'boot_device' is used
* unconditionally to decide about device to use for booting.
@@ -217,6 +245,7 @@ u32 spl_boot_mode(const u32 boot_device)
puts("spl: ERROR: unsupported device\n");
hang();
}
+#endif
}
#endif
--
2.16.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 05/10] dt-bindings: import usb pd
Import usb pd bindings from Linux 5.4.0-rc1. This file will be included by imx8mm-evk.dts. Signed-off-by: Peng Fan --- include/dt-bindings/usb/pd.h | 88 1 file changed, 88 insertions(+) create mode 100644 include/dt-bindings/usb/pd.h diff --git a/include/dt-bindings/usb/pd.h b/include/dt-bindings/usb/pd.h new file mode 100644 index 00..985f2bbd4d --- /dev/null +++ b/include/dt-bindings/usb/pd.h @@ -0,0 +1,88 @@ +/* SPDX-License-Identifier: GPL-2.0 */ +#ifndef __DT_POWER_DELIVERY_H +#define __DT_POWER_DELIVERY_H + +/* Power delivery Power Data Object definitions */ +#define PDO_TYPE_FIXED 0 +#define PDO_TYPE_BATT 1 +#define PDO_TYPE_VAR 2 +#define PDO_TYPE_APDO 3 + +#define PDO_TYPE_SHIFT 30 +#define PDO_TYPE_MASK 0x3 + +#define PDO_TYPE(t)((t) << PDO_TYPE_SHIFT) + +#define PDO_VOLT_MASK 0x3ff +#define PDO_CURR_MASK 0x3ff +#define PDO_PWR_MASK 0x3ff + +#define PDO_FIXED_DUAL_ROLE(1 << 29) /* Power role swap supported */ +#define PDO_FIXED_SUSPEND (1 << 28) /* USB Suspend supported (Source) */ +#define PDO_FIXED_HIGHER_CAP (1 << 28) /* Requires more than vSafe5V (Sink) */ +#define PDO_FIXED_EXTPOWER (1 << 27) /* Externally powered */ +#define PDO_FIXED_USB_COMM (1 << 26) /* USB communications capable */ +#define PDO_FIXED_DATA_SWAP(1 << 25) /* Data role swap supported */ +#define PDO_FIXED_VOLT_SHIFT 10 /* 50mV units */ +#define PDO_FIXED_CURR_SHIFT 0 /* 10mA units */ + +#define PDO_FIXED_VOLT(mv) mv) / 50) & PDO_VOLT_MASK) << PDO_FIXED_VOLT_SHIFT) +#define PDO_FIXED_CURR(ma) ma) / 10) & PDO_CURR_MASK) << PDO_FIXED_CURR_SHIFT) + +#define PDO_FIXED(mv, ma, flags) \ + (PDO_TYPE(PDO_TYPE_FIXED) | (flags) | \ +PDO_FIXED_VOLT(mv) | PDO_FIXED_CURR(ma)) + +#define VSAFE5V 5000 /* mv units */ + +#define PDO_BATT_MAX_VOLT_SHIFT20 /* 50mV units */ +#define PDO_BATT_MIN_VOLT_SHIFT10 /* 50mV units */ +#define PDO_BATT_MAX_PWR_SHIFT 0 /* 250mW units */ + +#define PDO_BATT_MIN_VOLT(mv) mv) / 50) & PDO_VOLT_MASK) << PDO_BATT_MIN_VOLT_SHIFT) +#define PDO_BATT_MAX_VOLT(mv) mv) / 50) & PDO_VOLT_MASK) << PDO_BATT_MAX_VOLT_SHIFT) +#define PDO_BATT_MAX_POWER(mw) mw) / 250) & PDO_PWR_MASK) << PDO_BATT_MAX_PWR_SHIFT) + +#define PDO_BATT(min_mv, max_mv, max_mw) \ + (PDO_TYPE(PDO_TYPE_BATT) | PDO_BATT_MIN_VOLT(min_mv) | \ +PDO_BATT_MAX_VOLT(max_mv) | PDO_BATT_MAX_POWER(max_mw)) + +#define PDO_VAR_MAX_VOLT_SHIFT 20 /* 50mV units */ +#define PDO_VAR_MIN_VOLT_SHIFT 10 /* 50mV units */ +#define PDO_VAR_MAX_CURR_SHIFT 0 /* 10mA units */ + +#define PDO_VAR_MIN_VOLT(mv) mv) / 50) & PDO_VOLT_MASK) << PDO_VAR_MIN_VOLT_SHIFT) +#define PDO_VAR_MAX_VOLT(mv) mv) / 50) & PDO_VOLT_MASK) << PDO_VAR_MAX_VOLT_SHIFT) +#define PDO_VAR_MAX_CURR(ma) ma) / 10) & PDO_CURR_MASK) << PDO_VAR_MAX_CURR_SHIFT) + +#define PDO_VAR(min_mv, max_mv, max_ma)\ + (PDO_TYPE(PDO_TYPE_VAR) | PDO_VAR_MIN_VOLT(min_mv) |\ +PDO_VAR_MAX_VOLT(max_mv) | PDO_VAR_MAX_CURR(max_ma)) + +#define APDO_TYPE_PPS 0 + +#define PDO_APDO_TYPE_SHIFT28 /* Only valid value currently is 0x0 - PPS */ +#define PDO_APDO_TYPE_MASK 0x3 + +#define PDO_APDO_TYPE(t) ((t) << PDO_APDO_TYPE_SHIFT) + +#define PDO_PPS_APDO_MAX_VOLT_SHIFT17 /* 100mV units */ +#define PDO_PPS_APDO_MIN_VOLT_SHIFT8 /* 100mV units */ +#define PDO_PPS_APDO_MAX_CURR_SHIFT0 /* 50mA units */ + +#define PDO_PPS_APDO_VOLT_MASK 0xff +#define PDO_PPS_APDO_CURR_MASK 0x7f + +#define PDO_PPS_APDO_MIN_VOLT(mv) \ + mv) / 100) & PDO_PPS_APDO_VOLT_MASK) << PDO_PPS_APDO_MIN_VOLT_SHIFT) +#define PDO_PPS_APDO_MAX_VOLT(mv) \ + mv) / 100) & PDO_PPS_APDO_VOLT_MASK) << PDO_PPS_APDO_MAX_VOLT_SHIFT) +#define PDO_PPS_APDO_MAX_CURR(ma) \ + ma) / 50) & PDO_PPS_APDO_CURR_MASK) << PDO_PPS_APDO_MAX_CURR_SHIFT) + +#define PDO_PPS_APDO(min_mv, max_mv, max_ma) \ + (PDO_TYPE(PDO_TYPE_APDO) | PDO_APDO_TYPE(APDO_TYPE_PPS) | \ +PDO_PPS_APDO_MIN_VOLT(min_mv) | PDO_PPS_APDO_MAX_VOLT(max_mv) | \ +PDO_PPS_APDO_MAX_CURR(max_ma)) + + #endif /* __DT_POWER_DELIVERY_H */ -- 2.16.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 02/10] imx8m: clock: improve irq response latency
Improve the IRQ response latency by setting GIC root clock source to sys_pll2_200m from osc. Signed-off-by: Peng Fan --- arch/arm/mach-imx/imx8m/clock_imx8mq.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/arch/arm/mach-imx/imx8m/clock_imx8mq.c b/arch/arm/mach-imx/imx8m/clock_imx8mq.c index 5c3f780127..04903510f0 100644 --- a/arch/arm/mach-imx/imx8m/clock_imx8mq.c +++ b/arch/arm/mach-imx/imx8m/clock_imx8mq.c @@ -806,6 +806,12 @@ int clock_init(void) clock_enable(CCGR_TSENSOR, 1); clock_enable(CCGR_OCOTP, 1); + /* config GIC ROOT to sys_pll2_200m */ + clock_enable(CCGR_GIC, 0); + clock_set_target_val(GIC_CLK_ROOT, +CLK_ROOT_ON | CLK_ROOT_SOURCE_SEL(1)); + clock_enable(CCGR_GIC, 1); + return 0; } #endif -- 2.16.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 01/10] imx8m: imx8mq: get chip rev for B1 revision
The i.MX8MQ B1 uses OCOTP_HW_OCOTP_READ_FUSE_DATA register for chip id.
It returns a magic number 0xff0055aa. update get_cpu_rev to support it,
and enable ocotp clock to access ocotp.
Signed-off-by: Peng Fan
---
arch/arm/mach-imx/imx8m/clock_imx8mq.c | 1 +
arch/arm/mach-imx/imx8m/soc.c | 21 ++---
2 files changed, 15 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mach-imx/imx8m/clock_imx8mq.c
b/arch/arm/mach-imx/imx8m/clock_imx8mq.c
index feecdb50f6..5c3f780127 100644
--- a/arch/arm/mach-imx/imx8m/clock_imx8mq.c
+++ b/arch/arm/mach-imx/imx8m/clock_imx8mq.c
@@ -804,6 +804,7 @@ int clock_init(void)
init_wdog_clk();
clock_enable(CCGR_TSENSOR, 1);
+ clock_enable(CCGR_OCOTP, 1);
return 0;
}
diff --git a/arch/arm/mach-imx/imx8m/soc.c b/arch/arm/mach-imx/imx8m/soc.c
index 3e73ca3cca..9a203e4736 100644
--- a/arch/arm/mach-imx/imx8m/soc.c
+++ b/arch/arm/mach-imx/imx8m/soc.c
@@ -204,14 +204,21 @@ u32 get_cpu_rev(void)
} else {
if (reg == CHIP_REV_1_0) {
/*
-* For B0 chip, the DIGPROG is not updated, still TO1.0.
-* we have to check ROM version further
+* For B0 chip, the DIGPROG is not updated,
+* it is still TO1.0. we have to check ROM
+* version or OCOTP_READ_FUSE_DATA.
+* 0xff0055aa is magic number for B1.
*/
- rom_version = readl((void __iomem *)ROM_VERSION_A0);
- if (rom_version != CHIP_REV_1_0) {
- rom_version = readl((void __iomem
*)ROM_VERSION_B0);
- if (rom_version >= CHIP_REV_2_0)
- reg = CHIP_REV_2_0;
+ if (readl((void __iomem *)(OCOTP_BASE_ADDR + 0x40)) ==
0xff0055aa) {
+ reg = CHIP_REV_2_1;
+ } else {
+ rom_version =
+ readl((void __iomem *)ROM_VERSION_A0);
+ if (rom_version != CHIP_REV_1_0) {
+ rom_version = readl((void __iomem
*)ROM_VERSION_B0);
+ if (rom_version == CHIP_REV_2_0)
+ reg = CHIP_REV_2_0;
+ }
}
}
}
--
2.16.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 00/10] Enable i.MX8MM EVK BD71837 pmic
This patch is to enable BD71837 pmic for i.MX8MM EVK. Two i.MX8MQ patches are also included. Peng Fan (10): imx8m: imx8mq: get chip rev for B1 revision imx8m: clock: improve irq response latency imx: imx8mq: add init_nand_clk imx: spl: implement spl_boot_mode for i.MX7/8/8M dt-bindings: import usb pd arm: dts: imx8mm: sync dts from Linux Kernel pmic: bd71837: drop DEBUG macro power: pmic: Kconfig: add CONFIG_SPL_DM_PMIC_BD71837 imx8m: evk: spl: probe clk in spl early stage imx8mm: evk: enable bd71837 pmic arch/arm/dts/imx8mm-evk-u-boot.dtsi| 22 +- arch/arm/dts/imx8mm-evk.dts| 285 - arch/arm/dts/imx8mm.dtsi | 222 +++ arch/arm/include/asm/arch-imx8m/clock_imx8mq.h | 2 + arch/arm/mach-imx/imx8m/clock_imx8mq.c | 16 ++ arch/arm/mach-imx/imx8m/soc.c | 21 +- arch/arm/mach-imx/spl.c| 29 +++ board/freescale/imx8mm_evk/spl.c | 63 +- configs/imx8mm_evk_defconfig | 5 +- drivers/power/pmic/Kconfig | 8 + drivers/power/pmic/bd71837.c | 2 - include/dt-bindings/usb/pd.h | 88 12 files changed, 692 insertions(+), 71 deletions(-) create mode 100644 include/dt-bindings/usb/pd.h -- 2.16.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/4] dm: spi: Return 0 if driver does not implement ops->cs_info
On Sun, Sep 29, 2019 at 1:34 PM Bin Meng wrote: > > Hi Jagan, > > On Mon, Sep 9, 2019 at 9:00 PM Bin Meng wrote: > > > > If an SPI controller driver does not implement ops->cs_info, that > > probably means any chip select number could be valid, hence let's > > return 0 for spi_cs_info(). > > > > Signed-off-by: Bin Meng > > Reviewed-by: Jagan Teki > > > > --- > > > > Changes in v2: > > - update spi-howto.rst to reflect the code changes > > > > doc/driver-model/spi-howto.rst | 4 ++-- > > drivers/spi/spi-uclass.c | 7 +++ > > 2 files changed, 5 insertions(+), 6 deletions(-) > > > > Ping for this series? Sorry, been in vacations. will try to give an update on this. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2] nvme: use page-aligned buffer for identify command
On Wed, Oct 16, 2019 at 2:42 PM Patrick Wildt wrote: > > Change the stack-allocated buffer for the identification command > to explicitly allocate page-aligned buffers. Even though the spec > seems to allow having admin queue commands on non page-aligned > buffers, it seems to not be possible on my i.MX8MQ board with a > a Silicon Power P34A80. Since all of the NVMe drivers I have seen > always do admin commands on a page-aligned buffer, which does work > on my system, it makes sense for us to do that as well. > > Signed-off-by: Patrick Wildt > --- > Changes for v2: >- use dev->page_size instead of hardcoded value > > drivers/nvme/nvme.c | 24 ++-- > 1 file changed, 18 insertions(+), 6 deletions(-) > Reviewed-by: Bin Meng ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2] pci: layerscape: remove multiple definitions of SVR
SVR values for various nxp SOCs are defined in asm/arch/soc.h
we can use these values in any peripheral driver.
we need not to redefine these values in peripheral driver, as this
becomes difficult to manage (add or change new values)
Signed-off-by: Pankaj Bansal
---
Notes:
V2:
- fixed compilation errors in LS1021A based targets by adding SVR checking
for layerscape series SOCs under LAYERSCAPE Macro.
[Dependencies]
- https://patchwork.ozlabs.org/patch/1177732/
drivers/pci/pcie_layerscape.c | 18 --
drivers/pci/pcie_layerscape.h | 9 +
drivers/pci/pcie_layerscape_fixup.c | 16 ++--
3 files changed, 23 insertions(+), 20 deletions(-)
diff --git a/drivers/pci/pcie_layerscape.c b/drivers/pci/pcie_layerscape.c
index 5ad7c28773..12357127a8 100644
--- a/drivers/pci/pcie_layerscape.c
+++ b/drivers/pci/pcie_layerscape.c
@@ -1,6 +1,6 @@
// SPDX-License-Identifier: GPL-2.0+
/*
- * Copyright 2017 NXP
+ * Copyright 2017, 2019 NXP
* Copyright 2014-2015 Freescale Semiconductor, Inc.
* Layerscape PCIe driver
*/
@@ -15,6 +15,7 @@
#if defined(CONFIG_FSL_LSCH2) || defined(CONFIG_FSL_LSCH3) || \
defined(CONFIG_ARM)
#include
+#include
#endif
#include "pcie_layerscape.h"
@@ -56,7 +57,7 @@ static int ls_pcie_ltssm(struct ls_pcie *pcie)
uint svr;
svr = get_svr();
- if (((svr >> SVR_VAR_PER_SHIFT) & SVR_LS102XA_MASK) == SVR_LS102XA) {
+ if ((SVR_DEV(svr) & SVR_LS102XA_MASK) == SVR_LS102XA) {
state = ctrl_readl(pcie, LS1021_PEXMSCPORTSR(pcie->idx));
state = (state >> LS1021_LTSSM_STATE_SHIFT) & LTSSM_STATE_MASK;
} else {
@@ -149,7 +150,7 @@ static void ls_pcie_setup_atu(struct ls_pcie *pcie)
uint svr;
svr = get_svr();
- if (((svr >> SVR_VAR_PER_SHIFT) & SVR_LS102XA_MASK) == SVR_LS102XA) {
+ if ((SVR_DEV(svr) & SVR_LS102XA_MASK) == SVR_LS102XA) {
offset = LS1021_PCIE_SPACE_OFFSET +
LS1021_PCIE_SPACE_SIZE * pcie->idx;
}
@@ -172,7 +173,8 @@ static void ls_pcie_setup_atu(struct ls_pcie *pcie)
idx = PCIE_ATU_REGION_INDEX1 + 1;
/* Fix the pcie memory map for LS2088A series SoCs */
- svr = (svr >> SVR_VAR_PER_SHIFT) & 0xFE;
+#if defined(CONFIG_FSL_LAYERSCAPE)
+ svr = SVR_SOC_VER(svr);
if (svr == SVR_LS2088A || svr == SVR_LS2084A ||
svr == SVR_LS2048A || svr == SVR_LS2044A ||
svr == SVR_LS2081A || svr == SVR_LS2041A) {
@@ -192,6 +194,7 @@ static void ls_pcie_setup_atu(struct ls_pcie *pcie)
LS2088A_PCIE1_PHYS_ADDR +
LS2088A_PCIE_PHYS_SIZE * pcie->idx;
}
+#endif /* CONFIG_FSL_LAYERSCAPE */
if (io)
/* ATU : OUTBOUND : IO */
@@ -446,9 +449,7 @@ static int ls_pcie_probe(struct udevice *dev)
const void *fdt = gd->fdt_blob;
int node = dev_of_offset(dev);
u16 link_sta;
- uint svr;
int ret;
- fdt_size_t cfg_size;
pcie->bus = dev;
@@ -501,6 +502,10 @@ static int ls_pcie_probe(struct udevice *dev)
return ret;
}
+#if defined(CONFIG_FSL_LAYERSCAPE)
+ uint svr;
+ fdt_size_t cfg_size;
+
/*
* Fix the pcie memory map address and PF control registers address
* for LS2088A series SoCs
@@ -516,6 +521,7 @@ static int ls_pcie_probe(struct udevice *dev)
pcie->cfg_res.end = pcie->cfg_res.start + cfg_size;
pcie->ctrl = pcie->lut + 0x4;
}
+#endif /* CONFIG_FSL_LAYERSCAPE */
pcie->cfg0 = map_physmem(pcie->cfg_res.start,
fdt_resource_size(>cfg_res),
diff --git a/drivers/pci/pcie_layerscape.h b/drivers/pci/pcie_layerscape.h
index ddfbba6538..9a19993568 100644
--- a/drivers/pci/pcie_layerscape.h
+++ b/drivers/pci/pcie_layerscape.h
@@ -1,6 +1,6 @@
/* SPDX-License-Identifier: GPL-2.0+ */
/*
- * Copyright 2017 NXP
+ * Copyright 2017, 2019 NXP
* Copyright 2014-2015 Freescale Semiconductor, Inc.
* Layerscape PCIe driver
*/
@@ -111,14 +111,7 @@
#define PCIE_CS2_OFFSET0x1000 /* For PCIe without SR-IOV */
#define SVR_LS102XA0
-#define SVR_VAR_PER_SHIFT 8
#define SVR_LS102XA_MASK 0x700
-#define SVR_LS2088A0x870900
-#define SVR_LS2084A0x870910
-#define SVR_LS2048A0x870920
-#define SVR_LS2044A0x870930
-#define SVR_LS2081A0x870918
-#define SVR_LS2041A0x870914
/* LS1021a PCIE space */
#define LS1021_PCIE_SPACE_OFFSET 0x40ULL
diff --git a/drivers/pci/pcie_layerscape_fixup.c
b/drivers/pci/pcie_layerscape_fixup.c
index 089e031724..ea8c330c07 100644
--- a/drivers/pci/pcie_layerscape_fixup.c
+++ b/drivers/pci/pcie_layerscape_fixup.c
@@ -1,6 +1,6 @@
// SPDX-License-Identifier: GPL-2.0+
/*
- * Copyright 2017 NXP
+ *
Re: [U-Boot] [PATCH] nvme: add more cache flushes
On Mon, Oct 14, 2019 at 7:11 PM Patrick Wildt wrote: > > On an i.MX8MQ our nvme driver doesn't completely work since we are > missing a few cache flushes. One is the prp list, which is an extra > buffer that we need to flush before handing it to the hardware. Also > the block read/write operations needs more cache flushes on this SoC. > > Signed-off-by: Patrick Wildt > --- > drivers/nvme/nvme.c | 15 +-- > 1 file changed, 9 insertions(+), 6 deletions(-) > > diff --git a/drivers/nvme/nvme.c b/drivers/nvme/nvme.c > index 2444e0270f..69d5e3eedc 100644 > --- a/drivers/nvme/nvme.c > +++ b/drivers/nvme/nvme.c > @@ -123,6 +123,9 @@ static int nvme_setup_prps(struct nvme_dev *dev, u64 > *prp2, > } > *prp2 = (ulong)dev->prp_pool; > > + flush_dcache_range((ulong)dev->prp_pool, (ulong)dev->prp_pool + > + dev->prp_entry_num * sizeof(u64)); > + > return 0; > } > > @@ -717,9 +720,10 @@ static ulong nvme_blk_rw(struct udevice *udev, lbaint_t > blknr, > u16 lbas = 1 << (dev->max_transfer_shift - ns->lba_shift); > u64 total_lbas = blkcnt; > > - if (!read) > - flush_dcache_range((unsigned long)buffer, > - (unsigned long)buffer + total_len); > + flush_dcache_range((unsigned long)buffer, > + (unsigned long)buffer + total_len); Why we need this for read? > + invalidate_dcache_range((unsigned long)buffer, > + (unsigned long)buffer + total_len); > > c.rw.opcode = read ? nvme_cmd_read : nvme_cmd_write; > c.rw.flags = 0; > @@ -755,9 +759,8 @@ static ulong nvme_blk_rw(struct udevice *udev, lbaint_t > blknr, > buffer += lbas << ns->lba_shift; > } > > - if (read) > - invalidate_dcache_range((unsigned long)buffer, > - (unsigned long)buffer + total_len); > + invalidate_dcache_range((unsigned long)buffer, > + (unsigned long)buffer + total_len); Why we need this for write? > > return (total_len - temp_len) >> desc->log2blksz; > } > -- Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] arm: freescale: ls102xa: add helper Macro to get the SVR
32 bit System Version Register (SVR) in NXP SOCs contains information about SOC such as: 1. SOC type (bits 8 - 31) 2. SOC Major Revision (bits 4 - 7) 3. SOC Minor Revision (bits 0 - 3) This Macro (SVR_DEV) strips the Major and Minor revision info, so that SOC can be correctly identified. This Macro is borrowed from Macro defined in arch/arm/include/asm/arch-fsl-layerscape/soc.h Additinally this file doesn't contain any valid license. Therefore, add GPLv2+ license in the file. same as arch/arm/include/asm/arch-fsl-layerscape/soc.h Signed-off-by: Pankaj Bansal --- arch/arm/include/asm/arch-ls102xa/soc.h | 6 ++ 1 file changed, 6 insertions(+) diff --git a/arch/arm/include/asm/arch-ls102xa/soc.h b/arch/arm/include/asm/arch-ls102xa/soc.h index e69de29bb2..672f126bba 100644 --- a/arch/arm/include/asm/arch-ls102xa/soc.h +++ b/arch/arm/include/asm/arch-ls102xa/soc.h @@ -0,0 +1,6 @@ +/* SPDX-License-Identifier: GPL-2.0+ */ +/* + * Copyright 2019 NXP + */ +#define SVR_DEV(svr) ((svr) >> 8) + -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] cmd: avb: Support A/B slots
Hi Sam,
On Fri, Aug 9, 2019 at 3:38 PM Sam Protsenko wrote:
>
> Add optional parameter to 'avb verify' sub-command, so that user is able
> to specify which slot to use, in case when user's partitions are
> slotted. If that parameter is omitted, the behavior of 'avb verify' will
> be the same as before, so user API is content.
>
> Signed-off-by: Sam Protsenko
> ---
> cmd/avb.c | 13 +
> 1 file changed, 9 insertions(+), 4 deletions(-)
>
> diff --git a/cmd/avb.c b/cmd/avb.c
> index 3f6fd763a0..d1942d6605 100644
> --- a/cmd/avb.c
> +++ b/cmd/avb.c
> @@ -235,6 +235,7 @@ int do_avb_verify_part(cmd_tbl_t *cmdtp, int flag,
> AvbSlotVerifyData *out_data;
> char *cmdline;
> char *extra_args;
> + char *slot_suffix = "";
>
> bool unlocked = false;
> int res = CMD_RET_FAILURE;
> @@ -244,9 +245,12 @@ int do_avb_verify_part(cmd_tbl_t *cmdtp, int flag,
> return CMD_RET_FAILURE;
> }
>
> - if (argc != 1)
> + if (argc < 1 || argc > 2)
> return CMD_RET_USAGE;
>
> + if (argc == 2)
> + slot_suffix = argv[1];
> +
> printf("## Android Verified Boot 2.0 version %s\n",
>avb_version_string());
>
> @@ -259,7 +263,7 @@ int do_avb_verify_part(cmd_tbl_t *cmdtp, int flag,
> slot_result =
> avb_slot_verify(avb_ops,
> requested_partitions,
> - "",
> + slot_suffix,
> unlocked,
>
> AVB_HASHTREE_ERROR_MODE_RESTART_AND_INVALIDATE,
> _data);
> @@ -419,7 +423,7 @@ static cmd_tbl_t cmd_avb[] = {
> U_BOOT_CMD_MKENT(read_part, 5, 0, do_avb_read_part, "", ""),
> U_BOOT_CMD_MKENT(read_part_hex, 4, 0, do_avb_read_part_hex, "", ""),
> U_BOOT_CMD_MKENT(write_part, 5, 0, do_avb_write_part, "", ""),
> - U_BOOT_CMD_MKENT(verify, 1, 0, do_avb_verify_part, "", ""),
> + U_BOOT_CMD_MKENT(verify, 2, 0, do_avb_verify_part, "", ""),
> #ifdef CONFIG_OPTEE_TA_AVB
> U_BOOT_CMD_MKENT(read_pvalue, 3, 0, do_avb_read_pvalue, "", ""),
> U_BOOT_CMD_MKENT(write_pvalue, 3, 0, do_avb_write_pvalue, "", ""),
> @@ -462,6 +466,7 @@ U_BOOT_CMD(
> "avb read_pvalue - read a persistent value \n"
> "avb write_pvalue - write a persistent value \n"
> #endif
> - "avb verify - run verification process using hash data\n"
> + "avb verify [slot_suffix] - run verification process using hash
> data\n"
> "from vbmeta structure\n"
> + "[slot_suffix] - _a, _b, etc (if vbmeta partition is slotted)\n"
> );
> --
> 2.20.1
>
Please don't forget to also adjust AVB documentation [1]
(command usage/extend section "ENABLE ON YOUR BOARD", adding
information about AVB+AB setups)
Apart from that,
Reviewed-by: Igor Opaniuk
Thanks!
[1] doc/android/avb2.txt
--
Best regards - Freundliche Grüsse - Meilleures salutations
Igor Opaniuk
mailto: igor.opan...@gmail.com
skype: igor.opanyuk
+380 (93) 836 40 67
http://ua.linkedin.com/in/iopaniuk
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 6/6] powerpc: t4240: dts: Added Sata DT nodes
This patch is to add sata node for T4240 platform
Signed-off-by: Peng Ma
---
arch/powerpc/dts/t4240.dtsi | 9 +
1 file changed, 9 insertions(+)
diff --git a/arch/powerpc/dts/t4240.dtsi b/arch/powerpc/dts/t4240.dtsi
index fc34974..3bda2fa 100644
--- a/arch/powerpc/dts/t4240.dtsi
+++ b/arch/powerpc/dts/t4240.dtsi
@@ -98,6 +98,15 @@
device_type = "open-pic";
clock-frequency = <0x0>;
};
+
+ sata: sata@22 {
+ compatible = "fsl,pq-sata-v2";
+ reg = <0x22 0x1000>;
+ interrupts = <68 0x2 0 0>;
+ sata-offset = <0x1000>;
+ sata-number = <2>;
+ sata-fpdma = <0>;
+ };
};
pcie@ffe24 {
--
2.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/6] powerpc: p2041: dts: Added Sata DT nodes
This patch is to add sata node for P2041 platform
Signed-off-by: Peng Ma
---
arch/powerpc/dts/p2041.dtsi | 9 +
1 file changed, 9 insertions(+)
diff --git a/arch/powerpc/dts/p2041.dtsi b/arch/powerpc/dts/p2041.dtsi
index 55f7adc..239439d 100644
--- a/arch/powerpc/dts/p2041.dtsi
+++ b/arch/powerpc/dts/p2041.dtsi
@@ -59,6 +59,15 @@
device_type = "open-pic";
clock-frequency = <0x0>;
};
+
+ sata: sata@22 {
+ compatible = "fsl,pq-sata-v2";
+ reg = <0x22 0x1000>;
+ interrupts = <68 0x2 0 0>;
+ sata-offset = <0x1000>;
+ sata-number = <2>;
+ sata-fpdma = <0>;
+ };
};
pcie@ffe20 {
--
2.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 4/6] powerpc: t102x: dts: Added Sata DT nodes
This patch is to add sata node for T102x platform
Signed-off-by: Peng Ma
---
arch/powerpc/dts/t102x.dtsi | 9 +
1 file changed, 9 insertions(+)
diff --git a/arch/powerpc/dts/t102x.dtsi b/arch/powerpc/dts/t102x.dtsi
index c49fd21..7d3f7c5 100644
--- a/arch/powerpc/dts/t102x.dtsi
+++ b/arch/powerpc/dts/t102x.dtsi
@@ -48,6 +48,15 @@
device_type = "open-pic";
clock-frequency = <0x0>;
};
+
+ sata: sata@22 {
+ compatible = "fsl,pq-sata-v2";
+ reg = <0x22 0x1000>;
+ interrupts = <68 0x2 0 0>;
+ sata-offset = <0x1000>;
+ sata-number = <2>;
+ sata-fpdma = <0>;
+ };
};
pcie@ffe24 {
--
2.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 5/6] powerpc: t104x: dts: Added Sata DT nodes
This patch is to add sata node for T104x platform
Signed-off-by: Peng Ma
---
arch/powerpc/dts/t104x.dtsi | 9 +
1 file changed, 9 insertions(+)
diff --git a/arch/powerpc/dts/t104x.dtsi b/arch/powerpc/dts/t104x.dtsi
index 5998967..fe6cc3c 100644
--- a/arch/powerpc/dts/t104x.dtsi
+++ b/arch/powerpc/dts/t104x.dtsi
@@ -58,6 +58,15 @@
device_type = "open-pic";
clock-frequency = <0x0>;
};
+
+ sata: sata@22 {
+ compatible = "fsl,pq-sata-v2";
+ reg = <0x22 0x1000>;
+ interrupts = <68 0x2 0 0>;
+ sata-offset = <0x1000>;
+ sata-number = <2>;
+ sata-fpdma = <0>;
+ };
};
pcie@ffe24 {
--
2.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 3/6] powerpc: p5040: dts: Added Sata DT nodes
This patch is to add sata node for P5040 platform
Signed-off-by: Peng Ma
---
arch/powerpc/dts/p5040.dtsi | 9 +
1 file changed, 9 insertions(+)
diff --git a/arch/powerpc/dts/p5040.dtsi b/arch/powerpc/dts/p5040.dtsi
index 8ab123d..7b8218a 100644
--- a/arch/powerpc/dts/p5040.dtsi
+++ b/arch/powerpc/dts/p5040.dtsi
@@ -58,6 +58,15 @@
device_type = "open-pic";
clock-frequency = <0x0>;
};
+
+ sata: sata@22 {
+ compatible = "fsl,pq-sata-v2";
+ reg = <0x22 0x1000>;
+ interrupts = <68 0x2 0 0>;
+ sata-offset = <0x1000>;
+ sata-number = <2>;
+ sata-fpdma = <0>;
+ };
};
pcie@ffe20 {
--
2.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 2/6] powerpc: p3041: dts: Added Sata DT nodes
This patch is to add sata node for P3041 platform
Signed-off-by: Peng Ma
---
arch/powerpc/dts/p3041.dtsi | 9 +
1 file changed, 9 insertions(+)
diff --git a/arch/powerpc/dts/p3041.dtsi b/arch/powerpc/dts/p3041.dtsi
index 197896d..23bde81 100644
--- a/arch/powerpc/dts/p3041.dtsi
+++ b/arch/powerpc/dts/p3041.dtsi
@@ -59,6 +59,15 @@
device_type = "open-pic";
clock-frequency = <0x0>;
};
+
+ sata: sata@22 {
+ compatible = "fsl,pq-sata-v2";
+ reg = <0x22 0x1000>;
+ interrupts = <68 0x2 0 0>;
+ sata-offset = <0x1000>;
+ sata-number = <2>;
+ sata-fpdma = <0>;
+ };
};
pcie@ffe20 {
--
2.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2] cmd: avb: Fix requested partitions list
Hi Sam,
On Thu, Aug 15, 2019 at 8:49 PM Sam Protsenko
wrote:
>
> The requested_partitions[] array should contain only boot partitions.
> Usually it's only 'boot' partition, as can be seen in [1]. Also, seems
> like the requested_partitions[] are only used when there is no 'vbmeta'
> partition [2], which is not a regular use-case.
>
> Make requested_partitions[] contain only 'boot' partition as it was
> supposed to be, and also make that array to be a local in
> do_avb_verify_part() function, as nobody else needs that.
>
> [1]
> https://android.googlesource.com/platform/external/avb/+/5fbb42a189aa/test/avb_slot_verify_unittest.cc#108
> [2]
> https://android.googlesource.com/platform/external/avb/+/5fbb42a189aa/libavb/avb_slot_verify.c#1461
>
> Signed-off-by: Sam Protsenko
> ---
> Changes in v2:
> - fix links in commit message (suggested by Eugeniu Rosca)
>
> cmd/avb.c | 6 +-
> 1 file changed, 1 insertion(+), 5 deletions(-)
>
> diff --git a/cmd/avb.c b/cmd/avb.c
> index a8a95034ca..a4de5c40a2 100644
> --- a/cmd/avb.c
> +++ b/cmd/avb.c
> @@ -15,11 +15,6 @@
> #define AVB_BOOTARGS "avb_bootargs"
> static struct AvbOps *avb_ops;
>
> -static const char * const requested_partitions[] = {"boot",
> -"system",
> -"vendor",
> -NULL};
> -
> int do_avb_init(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
> {
> unsigned long mmc_dev;
> @@ -232,6 +227,7 @@ int do_avb_get_uuid(cmd_tbl_t *cmdtp, int flag,
> int do_avb_verify_part(cmd_tbl_t *cmdtp, int flag,
>int argc, char *const argv[])
> {
> + const char * const requested_partitions[] = {"boot", NULL};
> AvbSlotVerifyResult slot_result;
> AvbSlotVerifyData *out_data;
> char *cmdline;
> --
> 2.23.0.rc1
>
Reviewed-by: Igor Opaniuk
--
Best regards - Freundliche Grüsse - Meilleures salutations
Igor Opaniuk
mailto: igor.opan...@gmail.com
skype: igor.opanyuk
+380 (93) 836 40 67
http://ua.linkedin.com/in/iopaniuk
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] libavb: Update libavb to current AOSP master
Hi Sam,
On Thu, Aug 15, 2019 at 11:04 PM Sam Protsenko
wrote:
>
> Update libavb to commit 5fbb42a189aa in AOSP/master, because new version
> has support for super partition [1], which we need for implementing
> Android dynamic partitions. All changes from previous patches for libavb
> in U-Boot are accounted for in this commit:
> - commit ecc6f6bea6a2 ("libavb: Handle wrong hashtree_error_mode in
> avb_append_options()")
> - commit 897a1d947e7e ("libavb: Update SPDX tag style")
> - commit d8f9d2af96b3 ("avb2.0: add Android Verified Boot 2.0 library")
>
> Tested on X15:
>
> ## Android Verified Boot 2.0 version 1.1.0
> read_is_device_unlocked not supported yet
> read_rollback_index not supported yet
> read_is_device_unlocked not supported yet
> Verification passed successfully
> AVB verification OK.
>
> Unit test passes:
>
> $ ./test/py/test.py --bd sandbox --build -k test_avb
>
> test/py/tests/test_android/test_avb.py ss..s.
>
> [1]
> https://android.googlesource.com/platform/external/avb/+/49936b4c0109411fdd38bd4ba3a32a01c40439a9
>
> Signed-off-by: Sam Protsenko
> ---
> lib/libavb/avb_cmdline.c | 52 ++-
> lib/libavb/avb_cmdline.h | 4 +-
> lib/libavb/avb_descriptor.c| 11 +-
> lib/libavb/avb_ops.h | 41 ++-
> lib/libavb/avb_sha.h | 12 +-
> lib/libavb/avb_sha256.c| 36 +-
> lib/libavb/avb_sha512.c| 22 +-
> lib/libavb/avb_slot_verify.c | 652 +
> lib/libavb/avb_slot_verify.h | 59 ++-
> lib/libavb/avb_sysdeps.h | 8 +
> lib/libavb/avb_sysdeps_posix.c | 16 +-
> lib/libavb/avb_vbmeta_image.c | 11 +-
> 12 files changed, 710 insertions(+), 214 deletions(-)
>
> diff --git a/lib/libavb/avb_cmdline.c b/lib/libavb/avb_cmdline.c
> index d246699272..cb5b98e423 100644
> --- a/lib/libavb/avb_cmdline.c
> +++ b/lib/libavb/avb_cmdline.c
> @@ -39,6 +39,14 @@ char* avb_sub_cmdline(AvbOps* ops,
> char part_name[AVB_PART_NAME_MAX_SIZE];
> char guid_buf[37];
>
> +/* Don't attempt to query the partition guid unless its search string is
> + * present in the command line. Note: the original cmdline is used here,
> + * not the replaced one. See b/116010959.
> + */
> +if (avb_strstr(cmdline, replace_str[n]) == NULL) {
> + continue;
> +}
> +
> if (!avb_str_concat(part_name,
> sizeof part_name,
> part_name_str[n],
> @@ -70,7 +78,15 @@ char* avb_sub_cmdline(AvbOps* ops,
> }
>}
>
> - avb_assert(ret != NULL);
> + /* It's possible there is no _PARTUUID for replacement above.
> + * Duplicate cmdline to ret for additional substitutions below.
> + */
> + if (ret == NULL) {
> +ret = avb_strdup(cmdline);
> +if (ret == NULL) {
> + goto fail;
> +}
> + }
>
>/* Replace any additional substitutions. */
>if (additional_substitutions != NULL) {
> @@ -198,21 +214,27 @@ static int cmdline_append_hex(AvbSlotVerifyData*
> slot_data,
>
> AvbSlotVerifyResult avb_append_options(
> AvbOps* ops,
> +AvbSlotVerifyFlags flags,
> AvbSlotVerifyData* slot_data,
> AvbVBMetaImageHeader* toplevel_vbmeta,
> AvbAlgorithmType algorithm_type,
> -AvbHashtreeErrorMode hashtree_error_mode) {
> +AvbHashtreeErrorMode hashtree_error_mode,
> +AvbHashtreeErrorMode resolved_hashtree_error_mode) {
>AvbSlotVerifyResult ret;
>const char* verity_mode;
>bool is_device_unlocked;
>AvbIOResult io_ret;
>
> - /* Add androidboot.vbmeta.device option. */
> - if (!cmdline_append_option(slot_data,
> - "androidboot.vbmeta.device",
> - "PARTUUID=$(ANDROID_VBMETA_PARTUUID)")) {
> -ret = AVB_SLOT_VERIFY_RESULT_ERROR_OOM;
> -goto out;
> + /* Add androidboot.vbmeta.device option... except if not using a vbmeta
> + * partition since it doesn't make sense in that case.
> + */
> + if (!(flags & AVB_SLOT_VERIFY_FLAGS_NO_VBMETA_PARTITION)) {
> +if (!cmdline_append_option(slot_data,
> + "androidboot.vbmeta.device",
> + "PARTUUID=$(ANDROID_VBMETA_PARTUUID)")) {
> + ret = AVB_SLOT_VERIFY_RESULT_ERROR_OOM;
> + goto out;
> +}
>}
>
>/* Add androidboot.vbmeta.avb_version option. */
> @@ -304,7 +326,7 @@ AvbSlotVerifyResult avb_append_options(
> const char* dm_verity_mode;
> char* new_ret;
>
> -switch (hashtree_error_mode) {
> +switch (resolved_hashtree_error_mode) {
>case AVB_HASHTREE_ERROR_MODE_RESTART_AND_INVALIDATE:
> if (!cmdline_append_option(
> slot_data, "androidboot.vbmeta.invalidate_on_error", "yes"))
> {
> @@ -331,6 +353,11 @@ AvbSlotVerifyResult avb_append_options(
> verity_mode = "logging";
> dm_verity_mode = "ignore_corruption";
> break;
> + case
Re: [U-Boot] [PATCH v1 5/5] colibri_t30: disable rs232 serial transceiver forceoff pins
Hi Marcel,
On Thu, Sep 12, 2019 at 12:15 PM Marcel Ziswiler wrote:
>
> From: Marcel Ziswiler
>
> Use gpio_early_init_uart() function to disable RS232 serial transceiver
> ForceOFF# pins on Iris.
>
> Signed-off-by: Marcel Ziswiler
>
> ---
>
> board/toradex/colibri_t30/colibri_t30.c | 11 +++
> 1 file changed, 11 insertions(+)
>
> diff --git a/board/toradex/colibri_t30/colibri_t30.c
> b/board/toradex/colibri_t30/colibri_t30.c
> index b6b00e3860..eb53fa6126 100644
> --- a/board/toradex/colibri_t30/colibri_t30.c
> +++ b/board/toradex/colibri_t30/colibri_t30.c
> @@ -55,6 +55,17 @@ void pinmux_init(void)
>ARRAY_SIZE(colibri_t30_padctrl));
> }
>
> +/*
> + * Disable RS232 serial transceiver ForceOFF# pins on Iris
> + */
> +void gpio_early_init_uart(void)
> +{
> + gpio_request(TEGRA_GPIO(X, 6), "Force OFF# X13");
> + gpio_direction_output(TEGRA_GPIO(X, 6), 1);
> + gpio_request(TEGRA_GPIO(X, 7), "Force OFF# X14");
> + gpio_direction_output(TEGRA_GPIO(X, 7), 1);
> +}
> +
> /*
> * Enable AX88772B USB to LAN controller
> */
> --
> 2.21.0
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot
What not to handle this in the dts instead?
--
Best regards - Freundliche Grüsse - Meilleures salutations
Igor Opaniuk
mailto: igor.opan...@gmail.com
skype: igor.opanyuk
+380 (93) 836 40 67
http://ua.linkedin.com/in/iopaniuk
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
