Re: [U-Boot] [PATCH v5 0/7] usb: Add cadence USB3 gadget/host/phy driver
Hi Vignesh, > > Hi, > > On 28/08/19 7:52 PM, Sherry Sun wrote: > > Hi Vignesh, > [...] > >> I see that Cadence USB driver for Linux kernel is still under > >> development and DT compatible binding is supposed to be "cdns,usb3" > not "cdns,usb3-1.0.0". > >> See v11: > >> https://patch > >> > work.kernel.org%2Fpatch%2F4415%2F&data=02%7C01%7Csherry.s > >> > un%40nxp.com%7C97d431d6b569451ff8ac08d72bb5f883%7C686ea1d3bc2b > >> > 4c6fa92cd99c5c301635%7C0%7C0%7C637025932942549390&sdata=Jltlk > >> Te7SXTAQAKtF7HzOqY291upS67Eixeke9oXQ2w%3D&reserved=0 > >> Deviating from kernel binding will break sync'ing of DTs b/w kernel > >> and U- Boot. > >> > > > > Thanks for your reminder, I only noticed the DT compatible in v5 last time. > So I will change it to "cdns,usb3" in next version. > > > >> Also, why not sync the latest host/gadget driver patches from kernel as is? > >> That should help in borrowing bug fixes/features whenever Cadence > >> updates kernel driver in future. > > > > Since there are many differences between the cdns3 driver in uboot and > > kernel, such as in uboot, we didn't support host mode in cdns3 core.c, > > instead we add an > > xhci-imx8 driver as host driver. So the patches from kernel can't be applied > to this driver. > > > > I see that xhci-imx8.c is generic enough to be used with v11 upstream > cdns3/core.c and cdns3/host.c once IMX specific stuff is moved to top level > wrapper. > > I see you use a separate compatible for host driver which does not match > with kernel (as there is no separate node for host vs device). Moreover the dt > bindings listed in patch 1/7 lists non core registers as part of Cadence USB3 > controller node. > > Above issues make it impossible to sync Kernel DT nodes with U-Boot DT > nodes which is not acceptable for U-Boot. All non Cadence core registers and > configurations need to part of a separate wrapper driver that then binds to > appropriate host/device Cadence USB3 controller node based on dr_mode > property. E.g: see who dwc3 is modeled [3]: > Also see cdns-ti.c in the TI U-Boot branch [1] [2]) > > If there are more customization required for host driver cdns3/host.c we can > provide vendor specific hooks/callbacks to be called from cdns3/host.c > Current series is not usable on TI platform with Cadence USB3 IP at least in > host mode and would need core host driver to be ported from kernel. > > Keeping Linux kernel and U-Boot driver stack in sync has a big advantage for > you as well. It simplifies borrowing bug fixes and new features or functions > (especially in subsystems like USB where code is pretty large) > > BTW, I have a tree with v10 of Cadence USB3 kernel driver ported to U-Boot > here[1]. It is based on 2019.01 U-Boot but should apply as is on the latest > tree as well. (Tree is still missing USB3 PHY support and thus USB 3.0 > support) > and works on TI platform. I am waiting for bindings to be frozen in Linux > before posting to U-Boot list. > > Hopefully we can find a way to collaborate! I think your suggestions are reasonable, I agree that keep Linux kernel and U-Boot driver stack in sync is a good choice! So I will try to test your code[1] on i.MX8 platform later, if the common core part can work well, maybe you can post it to U-Boot list after the Linux cdns3 driver version is frozen. Best regards Sherry sun > > [1] git://git.ti.com/~vigneshr/ti-u-boot/vigneshr-ti-u-boot.git > branch: dfu > [2] > https://eur01.safelinks.protection.outlook.com/?url=http:%2F%2Fgit.ti.com% > 2Fcgit%2Fcgit.cgi%2F~vigneshr%2Fti-u-boot%2Fvigneshr-ti-u- > boot.git%2Ftree%2Farch%2Farm%2Fdts%2Fk3-j721e- > main.dtsi%3Fh%3Ddfu%23n430&data=02%7C01%7Csherry.sun%40nxp. > com%7C25c139bf8e6c4d6575ab08d72c996ba4%7C686ea1d3bc2b4c6fa92cd9 > 9c5c301635%7C0%7C0%7C637026909770138936&sdata=lj44%2BFC0AKi > cD%2BY81zHKhUl23DzxY4b%2Fu9fGstr3nOI%3D&reserved=0 > [3] > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Felixir. > bootlin.com%2Fu- > boot%2Flatest%2Fsource%2Fdrivers%2Fusb%2Fdwc3%2Fdwc3- > generic.c&data=02%7C01%7Csherry.sun%40nxp.com%7C25c139bf8e6c > 4d6575ab08d72c996ba4%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0 > %7C637026909770138936&sdata=mGur%2FVZFiUef5tblBuVPh3i86FQpe > yunPg15m%2Bwh1mk%3D&reserved=0 > > > > -- > Regards > Vignesh ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v1] usb: Guarantee alignment of the string descriptor
On Thu, Aug 29, 2019 at 10:46 PM Andy Shevchenko wrote: > > GCC 9.x starts complaining about potential misalignment of the pointer to the > array (in this case alignment=2) in the packed (alignment=1) structures. > > drivers/usb/gadget/composite.c:545:23: warning: taking address of packed > member of ‘struct usb_string_descriptor’ may result in an unaligned pointer > value [-Waddress-of-packed-member] > 545 |collect_langs(sp, s->wData); > > drivers/usb/gadget/composite.c:550:24: warning: taking address of packed > member of ‘struct usb_string_descriptor’ may result in an unaligned pointer > value [-Waddress-of-packed-member] > 550 | collect_langs(sp, s->wData); > > drivers/usb/gadget/composite.c:555:25: warning: taking address of packed > member of ‘struct usb_string_descriptor’ may result in an unaligned pointer > value [-Waddress-of-packed-member] > 555 | collect_langs(sp, s->wData); > > Define structure alignment to be 2 to guarantee alignment of its members. > > Signed-off-by: Andy Shevchenko > --- > include/linux/usb/ch9.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > Reviewed-by: Bin Meng ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v1] pci: add DM based mpc85xx driver
Hi Heiko, > -Original Message- > From: Heiko Schocher > Sent: 2019年8月30日 12:17 > To: Z.q. Hou > Cc: u-boot@lists.denx.de; Alexander Graf ; Andrew F. Davis > ; Xiaowei Bao ; Bin Meng > ; Eugen Hristev ; > Heinrich Schuchardt ; Horatiu Vultur > ; Krzysztof Kozlowski ; > Liviu Dudau ; Marek Vasut > ; Mario Six ; Michal Simek > ; Neil Armstrong ; > Prabhakar Kushwaha ; Ryder Lee > ; Simon Glass ; Stefan > Roese > Subject: Re: [PATCH v1] pci: add DM based mpc85xx driver > > Hello Z.q. Hou, > > Am 29.08.2019 um 10:11 schrieb Z.q. Hou: > > Hi Heiko, > > > >> -Original Message- > >> From: Heiko Schocher > >> Sent: 2019年7月16日 11:36 > >> To: u-boot@lists.denx.de > >> Cc: Heiko Schocher ; Alexander Graf ; > >> Andrew F. Davis ; Xiaowei Bao ; > Bin > >> Meng ; Eugen Hristev > >> ; Heinrich Schuchardt > >> ; Horatiu Vultur ; > >> Z.q. Hou ; Krzysztof Kozlowski > >> ; Liviu Dudau ; Marek > >> Vasut ; Mario Six ; > Michal > >> Simek ; Neil Armstrong > >> ; Prabhakar Kushwaha > >> ; Ryder Lee > ; > >> Simon Glass ; Stefan Roese > >> Subject: [PATCH v1] pci: add DM based mpc85xx driver > >> > >> add DM based PCI Configuration space access support for MPC85xx PCI > >> Bridge > > > > Seems you're converting the arch/powerpc/cpu/mpc85xx/pci.c to driver > > model, > > Yes, should have added this to commit message .. fixed. > > > but not every mpc85xx platform uses this driver, platforms mpc8536, > > 8544, > > 8548 and 8568 use the drivers/pci/fsl_pci_init.c, please take them into > account. > > Oh, wasn;t aware of this! ... I have no idea why there are 2 drivers and > where are the differences between them, nor I can test all the other > plattforms, so this seems difficult to me. > > Do you know, why there are 2 different drivers? I guess the mpc85xx/pci.c was added for the older platforms, which only integrated PCI controllers, it can't support the newer platforms, which integrated both PCI and PCIe controllers. So the fsl_pci_init.c was added. > > I made this new driver, because I work on DM support for the socrates board, > which is mpc8544 based ... !? > > May I rename this driver from pci_mpc85xx.c to pci_mpc85xx_dm.c and it > can be a base for DM support and others, who can test their changes, can > add the other variants? It's unnecessary to change the driver file name, I can help to verify on mpc8548, Let others add other mpc85xx PCI DM driver base on this. > > > Note: The platforms using arch/powerpc/cpu/mpc85xx/pci.c set up PCI > > LAWs in file arch/powerpc/cpu/mpc8xxx/law.c, while other platforms set > > up PCI LAWs in PCI driver. So I think you can move the PCI LAWs set-up > > into this DM PCI driver And remove the PCI entries from law.c. > > Yes good idea, add this in v2 for this driver. > > >> Signed-off-by: Heiko Schocher > >> > >> --- > >> Travis build, see: > >> https://travis > >> > -ci.org%2Fhsdenx%2Fu-boot-test%2Fbuilds%2F558855544&data=02%7 > >> > C01%7CZhiqiang.Hou%40nxp.com%7C231ac8975b2242ea5bfb08d7099eccc > >> > 8%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C63698844995746 > >> > 0734&sdata=lQcXtvh5a0G9r%2BFlXnnGQ5VgDYvcR%2FEGWpShJ324su > >> U%3D&reserved=0 > >> > >> MAINTAINERS | 5 ++ > >> drivers/pci/Kconfig | 7 ++ > >> drivers/pci/Makefile | 1 + > >> drivers/pci/pci_mpc85xx.c | 132 > >> ++ > >> 4 files changed, 145 insertions(+) > >> create mode 100644 drivers/pci/pci_mpc85xx.c > >> > >> diff --git a/MAINTAINERS b/MAINTAINERS index > e91684191f..01faa67a6d > >> 100644 > >> --- a/MAINTAINERS > >> +++ b/MAINTAINERS > >> @@ -639,6 +639,11 @@ S:Maintained > >> F: drivers/pci_endpoint/ > >> F: include/pci_ep.h > >> > >> +PCI MPC85xx > >> +M:Heiko Schocher > >> +S:Maintained > >> +F:drivers/pci/pci_mpc85xx.c > >> + > >> POWER > >> M: Jaehoon Chung > >> S: Maintained > >> diff --git a/drivers/pci/Kconfig b/drivers/pci/Kconfig index > >> 3fe38f7315..88db0067b4 100644 > >> --- a/drivers/pci/Kconfig > >> +++ b/drivers/pci/Kconfig > >> @@ -68,6 +68,13 @@ config PCIE_FSL > >> PowerPC MPC85xx, MPC86xx, B series, P series and T series > SoCs. > >> This driver does not support SRIO_PCIE_BOOT feature. > >> > >> +config PCI_MPC85XX > >> + bool "MPC85XX PowerPC PCI support" > >> + depends on DM_PCI > >> + help > >> +Say Y here if you want to enable PCI controller support on FSL > >> +PowerPC MPC85xx SoC. > >> + > >> config PCI_RCAR_GEN2 > >>bool "Renesas RCar Gen2 PCIe driver" > >>depends on DM_PCI > >> diff --git a/drivers/pci/Makefile b/drivers/pci/Makefile index > >> b5ebd50c85..929f119fb3 100644 > >> --- a/drivers/pci/Makefile > >> +++ b/drivers/pci/Makefile > >> @@ -19,6 +19,7 @@ obj-$(CONFIG_PCIE_ECAM_GENERIC) += > >> pcie_ecam_generic.o > >> obj-$(CONFIG_FSL_PCI_INIT) += fsl_pci_init.o > >> obj-$(CONFIG_PCI_INDIRECT_BRIDGE) += pci_indirect.o > >> obj-$(CONFIG_PCI_GT64120) += pci_gt64120.o > >> +obj-$
Re: [U-Boot] [PATCH 1/1] x86: efi_loader: Fix invalid address return from efi_alloc()
Hi Aiden,
On Fri, Aug 30, 2019 at 5:31 AM Park, Aiden wrote:
>
> Hi Heinrich and Bin,
>
> > -Original Message-
> > From: Heinrich Schuchardt [mailto:xypron.g...@gmx.de]
> > Sent: Wednesday, August 28, 2019 10:16 PM
> > To: Bin Meng ; Park, Aiden
> > Cc: Simon Glass ; u-boot@lists.denx.de; Alexander Graf
> >
> > Subject: Re: [PATCH 1/1] x86: efi_loader: Fix invalid address return from
> > efi_alloc()
> >
> > On 8/29/19 5:36 AM, Bin Meng wrote:
> > > +Heinrich,
> > >
> > > On Wed, Aug 28, 2019 at 2:35 AM Park, Aiden wrote:
> > >>
> > >> This issue can be seen on 32bit operation when one of E820_RAM type
> > >> entries is greater than 4GB memory space.
> > >>
> > >> The efi_alloc() finds a free memory in the conventional memory which
> > >> is greater than 4GB. But, it does type cast to 32bit address space
> > >> and eventually returns invalid address.
> > >>
> > >> Signed-off-by: Aiden Park
> > >> ---
> > >> arch/x86/lib/e820.c | 22 +-
> > >> 1 file changed, 21 insertions(+), 1 deletion(-)
> > >>
> > >> diff --git a/arch/x86/lib/e820.c b/arch/x86/lib/e820.c index
> > >> d6ae2c4e9d..3e93931231 100644
> > >> --- a/arch/x86/lib/e820.c
> > >> +++ b/arch/x86/lib/e820.c
> > >> @@ -41,11 +41,15 @@ void efi_add_known_memory(void)
> > >> {
> > >> struct e820_entry e820[E820MAX];
> > >> unsigned int i, num;
> > >> - u64 start, pages;
> > >> + u64 start, pages, ram_top;
> > >> int type;
> > >>
> > >> num = install_e820_map(ARRAY_SIZE(e820), e820);
> > >>
> > >> + ram_top = (u64)gd->ram_top & ~EFI_PAGE_MASK;
> > >> + if (!ram_top)
> > >
> > > So for the logic here to work, gd->ram_top is already zero in 32-bit,
> > > right? I was wondering how U-Boot could boot on such target?
> >
> > If in 32bit mode RAM addresses up to 2^32-1 are available, gd->ram_top is 0
> > due
> > to overflow.
> >
> > >
> > >> + ram_top = 0x1ULL;
> >
> > In this special case we correct the value to 4GB.
> >
> > >> +
> > >> for (i = 0; i < num; ++i) {
> > >> start = e820[i].addr;
> > >> pages = ALIGN(e820[i].size, EFI_PAGE_SIZE) >>
> > >> EFI_PAGE_SHIFT; @@ -70,6 +74,22 @@ void efi_add_known_memory(void)
> > >> }
> > >>
> > >> efi_add_memory_map(start, pages, type, false);
> > >> +
> > >> + if (type == EFI_CONVENTIONAL_MEMORY) {
> > >> + u64 end = start + (pages << EFI_PAGE_SHIFT);
> > >> +
> > >> + /* reserve the memory region greater than
> > >> ram_top */
> > >> + if (ram_top < start) {
> > >> + efi_add_memory_map(start, pages,
> > >> +
> > >> EFI_BOOT_SERVICES_DATA,
> > >> + true);
> > >
> > > Heinrich, could you please review the changes here?
> >
> > These lines are verbatim copies of what we have in
> > lib/efi_loader/efi_memory.c.
> > Function wise this is ok.
> >
> > But this creates code duplication. Most of what is in this loop and in the
> > loop in
> > lib/efi_loader/efi_memory.c (starting at /* Remove partial pages */) could
> > be
> > put into a separate common function.
> >
> > Aiden, do you want to give a try?
> >
> I have a quick question here. Do we really need to override
> efi_add_known_memory() in arch/x86/lib/e820.c?
> I think the original weak function would be okay for x86 arch as well.
>
Yep, I see the generic one provided by the EFI loader is using
gd->bd->bi_dram[i] to populate the EFI memory. The only handles
EFI_CONVENTIONAL_MEMORY, but for x86, it may have
EFI_ACPI_RECLAIM_MEMORY and EFI_ACPI_MEMORY_NVS which
gd->bd->bi_dram[i] does not distinguish normal memory usage and these
special ones. Hence I think we still need the x86 specific one.
But as Heinrich mentioned, there might be some room to refactor the
codes a little bit to share as much common parts as possible.
Regards,
Bin
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2] imx: support i.MX8QM ROM 7720 a1 board
On 30/08/19, Peng Fan wrote: > > Subject: [PATCH v2] imx: support i.MX8QM ROM 7720 a1 board > > > > Add i.MX8QM ROM 7720a1 board support > > > > Boot log as below: > > U-Boot 2019.07-1-g6c912ea4d4 (Aug 28 2019 - 13:01:45 +0200) > > > > CPU: NXP i.MX8QM RevB A53 at 1200 MHz > > > > Model: Advantech iMX8QM Qseven series > > Board: ROM-7720-A1 4GB > > Build: SCFW 65afe5f6 > > Boot: SD2 > > DRAM: 3.9 GiB > > MMC: FSL_SDHC: 0, FSL_SDHC: 1, FSL_SDHC: 2 > > Loading Environment from MMC... OK > > In:serial@5a06 > > Out: serial@5a06 > > Err: serial@5a06 > > Net: eth0: ethernet@5b04Could not get PHY for FEC1: addr 1 > > , eth-1: ethernet@5b05 > > Hit any key to stop autoboot: 0 > > > > Signed-off-by: Oliver Graute > > Cc: Stefano Babic > > Cc: Fabio Estevam > > Cc: Peng Fan > > Cc: Simon Glass > > Cc: Ye Li > > Cc: uboot-imx > > --- > > > > These changes are based on this vendor tree: > > Please use imx/master or upstream master branch for your development. ok I can apply the Patch on imx custodian tree. But I run into some wired linking errors. For the first there exist already a patch from Igor which is not applied in tree yet. https://lists.denx.de/pipermail/u-boot/2019-August/380468.html The next errors are multiple defintions of some functions: drivers/mmc/fsl_esdhc_imx.o: In function `fdt_fixup_esdhc': /home/graute/test/u-boot-imx/drivers/mmc/fsl_esdhc_imx.c:1382: multiple definition of `fdt_fixup_esdhc' drivers/mmc/fsl_esdhc.o:/home/graute/test/u-boot-imx/drivers/mmc/fsl_esdhc.c:932: first defined here drivers/mmc/fsl_esdhc_imx.o:/home/graute/test/u-boot-imx/drivers/mmc/fsl_esdhc_imx.c:1661: multiple definition of `_u_boot_list_2_driver_2_fsl_esdhc' drivers/mmc/fsl_esdhc.o:/home/graute/test/u-boot-imx/drivers/mmc/fsl_esdhc.c:1101: first defined here scripts/Makefile.build:355: recipe for target 'drivers/mmc/built-in.o' failed make[2]: *** [drivers/mmc/built-in.o] Error 1 scripts/Makefile.build:432: recipe for target 'drivers/mmc' failed make[1]: *** [drivers/mmc] Error 2 Makefile:1588: recipe for target 'drivers' failed make: *** [drivers] Error 2 Someone a clue howto fix these errors? Best Regards, Oliver ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2] imx: support i.MX8QM ROM 7720 a1 board
> Subject: Re: [PATCH v2] imx: support i.MX8QM ROM 7720 a1 board > > On 30/08/19, Peng Fan wrote: > > > Subject: [PATCH v2] imx: support i.MX8QM ROM 7720 a1 board > > > > > > Add i.MX8QM ROM 7720a1 board support > > > > > > Boot log as below: > > > U-Boot 2019.07-1-g6c912ea4d4 (Aug 28 2019 - 13:01:45 +0200) > > > > > > CPU: NXP i.MX8QM RevB A53 at 1200 MHz > > > > > > Model: Advantech iMX8QM Qseven series > > > Board: ROM-7720-A1 4GB > > > Build: SCFW 65afe5f6 > > > Boot: SD2 > > > DRAM: 3.9 GiB > > > MMC: FSL_SDHC: 0, FSL_SDHC: 1, FSL_SDHC: 2 > > > Loading Environment from MMC... OK > > > In:serial@5a06 > > > Out: serial@5a06 > > > Err: serial@5a06 > > > Net: eth0: ethernet@5b04Could not get PHY for FEC1: addr 1 > > > , eth-1: ethernet@5b05 > > > Hit any key to stop autoboot: 0 > > > > > > Signed-off-by: Oliver Graute > > > Cc: Stefano Babic > > > Cc: Fabio Estevam > > > Cc: Peng Fan > > > Cc: Simon Glass > > > Cc: Ye Li > > > Cc: uboot-imx > > > --- > > > > > > These changes are based on this vendor tree: > > > > Please use imx/master or upstream master branch for your development. > > ok I can apply the Patch on imx custodian tree. But I run into some wired > linking errors. For the first there exist already a patch from Igor which is > not > applied in tree yet. > > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.d > enx.de%2Fpipermail%2Fu-boot%2F2019-August%2F380468.html&data= > 02%7C01%7Cpeng.fan%40nxp.com%7Cdb77a2fa070947d5750f08d72d1f91c8 > %7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C1%7C637027485924189 > 364&sdata=5C0gakvz584z8HUpPfp1NZ4YhW9etYixErARrEQwr8s%3D&a > mp;reserved=0 > > The next errors are multiple defintions of some functions: > > drivers/mmc/fsl_esdhc_imx.o: In function `fdt_fixup_esdhc': > /home/graute/test/u-boot-imx/drivers/mmc/fsl_esdhc_imx.c:1382: multiple > definition of `fdt_fixup_esdhc' Please not enable FSL_ESDHC and FSL_ESDHC_IMX both. Only FSL_ESDHC_IMX is ok. Regards, Peng. > drivers/mmc/fsl_esdhc.o:/home/graute/test/u-boot-imx/drivers/mmc/fsl_es > dhc.c:932: first defined here > drivers/mmc/fsl_esdhc_imx.o:/home/graute/test/u-boot-imx/drivers/mmc/f > sl_esdhc_imx.c:1661: multiple definition of > `_u_boot_list_2_driver_2_fsl_esdhc' > drivers/mmc/fsl_esdhc.o:/home/graute/test/u-boot-imx/drivers/mmc/fsl_es > dhc.c:1101: first defined here > scripts/Makefile.build:355: recipe for target 'drivers/mmc/built-in.o' failed > make[2]: *** [drivers/mmc/built-in.o] Error 1 > scripts/Makefile.build:432: recipe for target 'drivers/mmc' failed > make[1]: *** [drivers/mmc] Error 2 > Makefile:1588: recipe for target 'drivers' failed > make: *** [drivers] Error 2 > > Someone a clue howto fix these errors? > > Best Regards, > > Oliver ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v4 2/4] USB: host: Add the USB3 host driver
On 28/08/2019 13:50, Sherry Sun wrote:
Hi Jean,
Hi Jean,
Hi Marek, Sherry,
we keep the cdns3 node for usb gadget driver, then add a usb host
node for
xhci-imx8 driver in *-uboot.dtsi. so here is no need to change
the host driver
compatible.
But the compatible in gadget driver should be changed later.
We should try avoiding ABI breaks in DT.
But the cdns3 usb gaget driver and host driver in different uclass
need two
dt nodes to bind with.
And the compatible of the two node cannot be same.
So for gadget driver, the compatible may use "cdns,usb3-1.0.0", for
host
driver, the compatible will use "cdns,usb3-1.0.0-host".
What do you think about it?
CCing Jean, since I think he did solve similar topic for his platform.
I've been OOO for a few weeks and didn't look at the whole series.
For this particular issue, the solution I used is to let the wrapper
do the binding job. The name of the driver to use is hard-coded in the
wrapper diver.
This is done in dwc3_glue_bind().
Thanks for your suggestions.
So if I want to use the cdns3 usb node as both usb gadget device and usb
host device, do you mean that I should make the cdns3 usb node as a usb
wrapper device, and create two subnodes in it.
I think we should not change the binding to adapt to out driver but keep
the bindings that exist in linux and adapt the u-boot driver
In the version used by our platform, there is a wrapper around the USB:
usbss0: cdns_usb@4104000 {
compatible = "ti,j721e-usb";
[]
usb0: usb@600 {
compatible = "cdns,usb3-1.0.1";
The driver selection (host or device) could be done by the wrapper when
it binds its children (same as the dwc3).
OR
The "cdns,usb3-1.0.1" could be a dumb driver the role of which would be
only to bind a new driver (host or device) based on "dr_mode". The
binding could be done using the same node, it doesn't have to be a subnode.
Maybe the second solution will be better, as it would work for platforms
that do not use a wrapper.
JJ
Then when binding the wrapper node, it will hard-coded the two subnodes
to different driver(gadge/host driver) according to the dr_mode property in
nodes.
Do you think I understand it right?
Best regards
Sherry sun
Best regards
Sherry sun
JJ
+ { }
+};
___
U-Boot mailing list
U-Boot@lists.denx.de
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.d
enx.de%2Flistinfo%2Fu-
boot&data=02%7C01%7Csherry.sun%40nxp.com%7C35f1d34da1ea4b7
670ba08d72b823e9a%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7
C637025710721487079&sdata=Nfk0qWtSViz60wJHAOr2m5tgIwTWjNwI
GrNOxDH6HC0%3D&reserved=0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2] imx: support i.MX8QM ROM 7720 a1 board
On 30/08/19, Peng Fan wrote: > > Subject: Re: [PATCH v2] imx: support i.MX8QM ROM 7720 a1 board > > > > On 30/08/19, Peng Fan wrote: > > > > Subject: [PATCH v2] imx: support i.MX8QM ROM 7720 a1 board > > > > > > > > Add i.MX8QM ROM 7720a1 board support > > > > > > > > Boot log as below: > > > > U-Boot 2019.07-1-g6c912ea4d4 (Aug 28 2019 - 13:01:45 +0200) > > > > > > > > CPU: NXP i.MX8QM RevB A53 at 1200 MHz > > > > > > > > Model: Advantech iMX8QM Qseven series > > > > Board: ROM-7720-A1 4GB > > > > Build: SCFW 65afe5f6 > > > > Boot: SD2 > > > > DRAM: 3.9 GiB > > > > MMC: FSL_SDHC: 0, FSL_SDHC: 1, FSL_SDHC: 2 > > > > Loading Environment from MMC... OK > > > > In:serial@5a06 > > > > Out: serial@5a06 > > > > Err: serial@5a06 > > > > Net: eth0: ethernet@5b04Could not get PHY for FEC1: addr 1 > > > > , eth-1: ethernet@5b05 > > > > Hit any key to stop autoboot: 0 > > > > > > > > Signed-off-by: Oliver Graute > > > > Cc: Stefano Babic > > > > Cc: Fabio Estevam > > > > Cc: Peng Fan > > > > Cc: Simon Glass > > > > Cc: Ye Li > > > > Cc: uboot-imx > > > > --- > > > > > > > > These changes are based on this vendor tree: > > > > > > Please use imx/master or upstream master branch for your development. > > > > ok I can apply the Patch on imx custodian tree. But I run into some wired > > linking errors. For the first there exist already a patch from Igor which > > is not > > applied in tree yet. > > > > > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.d > > enx.de%2Fpipermail%2Fu-boot%2F2019-August%2F380468.html&data= > > 02%7C01%7Cpeng.fan%40nxp.com%7Cdb77a2fa070947d5750f08d72d1f91c8 > > %7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C1%7C637027485924189 > > 364&sdata=5C0gakvz584z8HUpPfp1NZ4YhW9etYixErARrEQwr8s%3D&a > > mp;reserved=0 > > > > The next errors are multiple defintions of some functions: > > > > drivers/mmc/fsl_esdhc_imx.o: In function `fdt_fixup_esdhc': > > /home/graute/test/u-boot-imx/drivers/mmc/fsl_esdhc_imx.c:1382: multiple > > definition of `fdt_fixup_esdhc' > > Please not enable FSL_ESDHC and FSL_ESDHC_IMX both. Only FSL_ESDHC_IMX is > ok. thx for the fast reply. That hint worked. Best regards, Oliver ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] scrapyard: Delete this file and script
Dear Tom, In message <1567099239-28108-1-git-send-email-tr...@konsulko.com> you wrote: > The README.scrapyard file has been inconsistently updated. While well > intentioned, bad data is worse than no data, and in this case a pointer > to use the history that git provides. Remove the current content and > the script that would update it from time to time as well. Should we not also provide some hints how a user (which eventually limited experience in git) can actually find such information? I would appreciate if we could provide examples at least for the trivial case where is is looking for some specific board(s) well known to him; maybe also for searching for things like removal of a specific CPU (say, PPC405GP) or CPU falimy. And instead of removing the scripts/fill_scrapyard.py script, should we not rather modify it to generate a list of (all) removed boards - that would be really helpful, I think ? Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Nearly everyone is in favor of going to heaven but too many are hoping they'll live long enough to see an easing of the entrance requirements. Never appeal to a man's "better nature." he might not have one. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v3] imx: support i.MX8QM ROM 7720 a1 board
Add i.MX8QM ROM 7720a1 board support
Boot log as below:
U-Boot 2019.10-rc2-00283-g198673d9ab (Aug 30 2019 - 10:26:53 +0200)
CPU: NXP i.MX8QM RevB A53 at 1200 MHz
Model: Advantech iMX8QM Qseven series
Board: ROM-7720-A1 4GB
Build: SCFW 65afe5f6
Boot: SD2
DRAM: 3.9 GiB
MMC: FSL_SDHC: 0, FSL_SDHC: 1, FSL_SDHC: 2
Loading Environment from MMC... OK
In:serial@5a06
Out: serial@5a06
Err: serial@5a06
Net: eth0: ethernet@5b04Could not get PHY for FEC1: addr 1
, eth-1: ethernet@5b05
Hit any key to stop autoboot: 0
Signed-off-by: Oliver Graute
Cc: Stefano Babic
Cc: Fabio Estevam
Cc: Peng Fan
Cc: Simon Glass
Cc: Ye Li
Cc: uboot-imx
---
These changes are based on this vendor tree:
https://github.com/ADVANTECH-Corp/uboot-imx6.git
I adapted the files and compared them with code from similar imx8qm-mek board
Changes for v3:
- removed duplicate build_info
- removed CONFIG_FSL_ESDHC
Changes for v2:
- cleanup of u-boot environment
- set power mode SC_R_DC_0 for full boot of linux kernel
- enabled usdhc2
- enabled FEC defines
- updated README.md
- enabled readwrite for nfs rootfs
- removed include of environment header
arch/arm/dts/Makefile | 1 +
arch/arm/dts/imx8qm-rom7720-a1.dts| 373 ++
arch/arm/mach-imx/imx8/Kconfig| 7 +
arch/arm/mach-imx/mkimage_fit_atf.sh | 3 +
board/freescale/imx8qm_rom7720_a1/Kconfig | 14 +
board/freescale/imx8qm_rom7720_a1/MAINTAINERS | 6 +
board/freescale/imx8qm_rom7720_a1/Makefile| 11 +
board/freescale/imx8qm_rom7720_a1/README | 70
.../imx8qm_rom7720_a1/imx8qm_rom7720_a1.c | 168
.../freescale/imx8qm_rom7720_a1/imximage.cfg | 21 +
board/freescale/imx8qm_rom7720_a1/spl.c | 228 +++
configs/imx8qm_rom7720_a1_4G_defconfig| 82
include/configs/imx8qm_rom7720.h | 188 +
13 files changed, 1172 insertions(+)
create mode 100644 arch/arm/dts/imx8qm-rom7720-a1.dts
create mode 100644 board/freescale/imx8qm_rom7720_a1/Kconfig
create mode 100644 board/freescale/imx8qm_rom7720_a1/MAINTAINERS
create mode 100644 board/freescale/imx8qm_rom7720_a1/Makefile
create mode 100644 board/freescale/imx8qm_rom7720_a1/README
create mode 100644 board/freescale/imx8qm_rom7720_a1/imx8qm_rom7720_a1.c
create mode 100644 board/freescale/imx8qm_rom7720_a1/imximage.cfg
create mode 100644 board/freescale/imx8qm_rom7720_a1/spl.c
create mode 100644 configs/imx8qm_rom7720_a1_4G_defconfig
create mode 100644 include/configs/imx8qm_rom7720.h
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 0b314c12dd..67340f8a0c 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -635,6 +635,7 @@ dtb-$(CONFIG_ARCH_MX7ULP) += imx7ulp-evk.dtb
dtb-$(CONFIG_ARCH_IMX8) += \
fsl-imx8qm-apalis.dtb \
fsl-imx8qm-mek.dtb \
+ imx8qm-rom7720-a1.dtb \
fsl-imx8qxp-colibri.dtb \
fsl-imx8qxp-mek.dtb
diff --git a/arch/arm/dts/imx8qm-rom7720-a1.dts
b/arch/arm/dts/imx8qm-rom7720-a1.dts
new file mode 100644
index 00..5f9ac955ed
--- /dev/null
+++ b/arch/arm/dts/imx8qm-rom7720-a1.dts
@@ -0,0 +1,373 @@
+// SPDX-License-Identifier:GPL-2.0+
+/*
+ * Copyright (C) 2016 Freescale Semiconductor, Inc.
+ * Copyright 2017 NXP
+ */
+
+/dts-v1/;
+
+/* First 128KB is for PSCI ATF. */
+/memreserve/ 0x8000 0x0002;
+
+#include "fsl-imx8qm.dtsi"
+
+/ {
+ model = "Advantech iMX8QM Qseven series";
+ compatible = "fsl,imx8qm-mek", "fsl,imx8qm";
+
+ chosen {
+ bootargs = "console=ttyLP0,115200
earlycon=lpuart32,0x5a06,115200";
+ stdout-path = &lpuart0;
+ };
+
+ leds {
+ compatible = "gpio-leds";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_gpio_leds>;
+ user {
+ label = "heartbeat";
+ gpios = <&gpio2 15 0>;
+ default-state = "on";
+ linux,default-trigger = "heartbeat";
+ };
+ };
+
+ regulators {
+ compatible = "simple-bus";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ reg_usb_otg1_vbus: regulator@0 {
+ compatible = "regulator-fixed";
+ reg = <0>;
+ regulator-name = "usb_otg1_vbus";
+ regulator-min-microvolt = <500>;
+ regulator-max-microvolt = <500>;
+ gpio = <&gpio4 3 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
+
+ reg_usdhc2_vmmc: usdhc2_vmmc {
+ compatible = "regulator-fixed";
+ regulator-name = "sw-3p3-sd1";
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+
[U-Boot] [PATCH v3 0/1] imx: support i.MX8QM ROM 7720 a1 board
Hello list, I adpated the patch so that its working on latest imx custodian tree master. Best regards, Oliver Oliver Graute (1): imx: support i.MX8QM ROM 7720 a1 board arch/arm/dts/Makefile | 1 + arch/arm/dts/imx8qm-rom7720-a1.dts| 373 ++ arch/arm/mach-imx/imx8/Kconfig| 7 + arch/arm/mach-imx/mkimage_fit_atf.sh | 3 + board/freescale/imx8qm_rom7720_a1/Kconfig | 14 + board/freescale/imx8qm_rom7720_a1/MAINTAINERS | 6 + board/freescale/imx8qm_rom7720_a1/Makefile| 11 + board/freescale/imx8qm_rom7720_a1/README | 70 .../imx8qm_rom7720_a1/imx8qm_rom7720_a1.c | 168 .../freescale/imx8qm_rom7720_a1/imximage.cfg | 21 + board/freescale/imx8qm_rom7720_a1/spl.c | 228 +++ configs/imx8qm_rom7720_a1_4G_defconfig| 82 include/configs/imx8qm_rom7720.h | 188 + 13 files changed, 1172 insertions(+) create mode 100644 arch/arm/dts/imx8qm-rom7720-a1.dts create mode 100644 board/freescale/imx8qm_rom7720_a1/Kconfig create mode 100644 board/freescale/imx8qm_rom7720_a1/MAINTAINERS create mode 100644 board/freescale/imx8qm_rom7720_a1/Makefile create mode 100644 board/freescale/imx8qm_rom7720_a1/README create mode 100644 board/freescale/imx8qm_rom7720_a1/imx8qm_rom7720_a1.c create mode 100644 board/freescale/imx8qm_rom7720_a1/imximage.cfg create mode 100644 board/freescale/imx8qm_rom7720_a1/spl.c create mode 100644 configs/imx8qm_rom7720_a1_4G_defconfig create mode 100644 include/configs/imx8qm_rom7720.h -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH V2] mips: bmips: remove unneeded definitions
These are no longer needed.
Signed-off-by: Álvaro Fernández Rojas
---
v2: CONFIG_SYS_MONITOR_BASE is used for relocation and can't be removed
include/configs/bmips_common.h | 4
1 file changed, 4 deletions(-)
diff --git a/include/configs/bmips_common.h b/include/configs/bmips_common.h
index 788f4af70d..ca079fa2e2 100644
--- a/include/configs/bmips_common.h
+++ b/include/configs/bmips_common.h
@@ -14,10 +14,6 @@
#define CONFIG_SYS_BAUDRATE_TABLE { 9600, 19200, 38400, 57600, 115200, \
230400, 50, 150 }
-/* RAM */
-#define CONFIG_SYS_MEMTEST_START 0xa000
-#define CONFIG_SYS_MEMTEST_END 0xa200
-
/* Memory usage */
#define CONFIG_SYS_MAXARGS 24
#define CONFIG_SYS_MALLOC_LEN (2 * 1024 * 1024)
--
2.20.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] bmips: configs: switch to size definitions
Signed-off-by: Álvaro Fernández Rojas --- include/configs/bmips_bcm3380.h | 6 -- include/configs/bmips_bcm6318.h | 6 -- include/configs/bmips_bcm63268.h | 6 -- include/configs/bmips_bcm6328.h | 6 -- include/configs/bmips_bcm6338.h | 6 -- include/configs/bmips_bcm6348.h | 6 -- include/configs/bmips_bcm6358.h | 6 -- include/configs/bmips_bcm6362.h | 8 +--- include/configs/bmips_bcm6368.h | 6 -- include/configs/bmips_bcm6838.h | 6 -- include/configs/bmips_common.h | 11 --- include/configs/broadcom_bcm968380gerg.h | 2 +- include/configs/comtrend_ar5315u.h | 3 +-- include/configs/comtrend_ar5387un.h | 3 +-- include/configs/comtrend_ct5361.h| 3 +-- include/configs/comtrend_vr3032u.h | 3 +-- include/configs/comtrend_wap5813n.h | 3 +-- include/configs/huawei_hg556a.h | 3 +-- include/configs/netgear_cg3100d.h| 3 +-- include/configs/netgear_dgnd3700v2.h | 5 ++--- include/configs/sagem_f@st1704.h | 3 +-- include/configs/sfr_nb4_ser.h| 3 +-- 22 files changed, 61 insertions(+), 46 deletions(-) diff --git a/include/configs/bmips_bcm3380.h b/include/configs/bmips_bcm3380.h index e2f9e76a97..573ff3e401 100644 --- a/include/configs/bmips_bcm3380.h +++ b/include/configs/bmips_bcm3380.h @@ -6,6 +6,8 @@ #ifndef __CONFIG_BMIPS_BCM3380_H #define __CONFIG_BMIPS_BCM3380_H +#include + /* CPU */ #define CONFIG_SYS_MIPS_TIMER_FREQ 16650 @@ -13,11 +15,11 @@ #define CONFIG_SYS_SDRAM_BASE 0x8000 /* U-Boot */ -#define CONFIG_SYS_LOAD_ADDR CONFIG_SYS_SDRAM_BASE + 0x10 +#define CONFIG_SYS_LOAD_ADDR CONFIG_SYS_SDRAM_BASE + SZ_1M #if defined(CONFIG_BMIPS_BOOT_RAM) #define CONFIG_SKIP_LOWLEVEL_INIT -#define CONFIG_SYS_INIT_SP_OFFSET 0x2000 +#define CONFIG_SYS_INIT_SP_OFFSET SZ_8K #endif #endif /* __CONFIG_BMIPS_BCM3380_H */ diff --git a/include/configs/bmips_bcm6318.h b/include/configs/bmips_bcm6318.h index 476aa51af3..c7e7119aaf 100644 --- a/include/configs/bmips_bcm6318.h +++ b/include/configs/bmips_bcm6318.h @@ -6,6 +6,8 @@ #ifndef __CONFIG_BMIPS_BCM6318_H #define __CONFIG_BMIPS_BCM6318_H +#include + /* CPU */ #define CONFIG_SYS_MIPS_TIMER_FREQ 16650 @@ -20,11 +22,11 @@ #define CONFIG_USB_OHCI_NEW /* U-Boot */ -#define CONFIG_SYS_LOAD_ADDR CONFIG_SYS_SDRAM_BASE + 0x10 +#define CONFIG_SYS_LOAD_ADDR CONFIG_SYS_SDRAM_BASE + SZ_1M #if defined(CONFIG_BMIPS_BOOT_RAM) #define CONFIG_SKIP_LOWLEVEL_INIT -#define CONFIG_SYS_INIT_SP_OFFSET 0x2000 +#define CONFIG_SYS_INIT_SP_OFFSET SZ_8K #endif #endif /* __CONFIG_BMIPS_BCM6318_H */ diff --git a/include/configs/bmips_bcm63268.h b/include/configs/bmips_bcm63268.h index 1456b0ec47..45f26bb309 100644 --- a/include/configs/bmips_bcm63268.h +++ b/include/configs/bmips_bcm63268.h @@ -6,6 +6,8 @@ #ifndef __CONFIG_BMIPS_BCM63268_H #define __CONFIG_BMIPS_BCM63268_H +#include + /* CPU */ #define CONFIG_SYS_MIPS_TIMER_FREQ 2 @@ -20,11 +22,11 @@ #define CONFIG_USB_OHCI_NEW /* U-Boot */ -#define CONFIG_SYS_LOAD_ADDR CONFIG_SYS_SDRAM_BASE + 0x10 +#define CONFIG_SYS_LOAD_ADDR CONFIG_SYS_SDRAM_BASE + SZ_1M #if defined(CONFIG_BMIPS_BOOT_RAM) #define CONFIG_SKIP_LOWLEVEL_INIT -#define CONFIG_SYS_INIT_SP_OFFSET 0x2000 +#define CONFIG_SYS_INIT_SP_OFFSET SZ_8K #endif #endif /* __CONFIG_BMIPS_BCM63268_H */ diff --git a/include/configs/bmips_bcm6328.h b/include/configs/bmips_bcm6328.h index faf9abcc3e..8d59438785 100644 --- a/include/configs/bmips_bcm6328.h +++ b/include/configs/bmips_bcm6328.h @@ -6,6 +6,8 @@ #ifndef __CONFIG_BMIPS_BCM6328_H #define __CONFIG_BMIPS_BCM6328_H +#include + /* CPU */ #define CONFIG_SYS_MIPS_TIMER_FREQ 16000 @@ -20,11 +22,11 @@ #define CONFIG_USB_OHCI_NEW /* U-Boot */ -#define CONFIG_SYS_LOAD_ADDR CONFIG_SYS_SDRAM_BASE + 0x10 +#define CONFIG_SYS_LOAD_ADDR CONFIG_SYS_SDRAM_BASE + SZ_1M #if defined(CONFIG_BMIPS_BOOT_RAM) #define CONFIG_SKIP_LOWLEVEL_INIT -#define CONFIG_SYS_INIT_SP_OFFSET 0x2000 +#define CONFIG_SYS_INIT_SP_OFFSET SZ_8K #endif #endif /* __CONFIG_BMIPS_BCM6328_H */ diff --git a/include/configs/bmips_bcm6338.h b/include/configs/bmips_bcm6338.h index 83050c94a6..38dd9e3af3 100644 --- a/include/configs/bmips_bcm6338.h +++ b/include/configs/bmips_bcm6338.h @@ -6,6 +6,8 @@ #ifndef __CONFIG_BMIPS_BCM6338_H #define __CONFIG_BMIPS_BCM6338_H +#include + /* CPU */ #define CONFIG_SYS_MIPS_TIMER_FREQ 12000 @@ -13,11 +15,11 @@ #define CONFIG_SYS_SDRAM_BASE 0x8000 /* U-Boot */ -#define CONFIG_SYS_LOAD_ADDR CONFIG_SYS_SDRAM_BASE + 0x10 +#define CONFIG_SYS_LOAD_ADDR CONFIG_SYS_SDRAM_BASE + SZ_1M #if defined(CONFIG_B
Re: [U-Boot] [PATCH 02/25] remoteproc: ops: Add elf section size as input parameter to device_to_virt api
On 29/08/19 2:14 PM, Fabien DESSENNE wrote:
> Hi Lokesh
>
>
> On 28/08/2019 2:55 PM, Lokesh Vutla wrote:
>> Introduce a new parameter size that accepts elf section size to remoteproc
>> ops callback device_to_virt(). This can enforce more checks on the
>> elf section that is being loaded.
>
>
> It would be better to talk about "size" instead of "elf section size"
> since device_to_virt may deal with any memory region.
>
>
>> Signed-off-by: Lokesh Vutla
>> ---
>> drivers/remoteproc/rproc-elf-loader.c | 3 ++-
>> drivers/remoteproc/sandbox_testproc.c | 4 +++-
>> drivers/remoteproc/stm32_copro.c | 4 +++-
>> include/remoteproc.h | 3 ++-
>> 4 files changed, 10 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/remoteproc/rproc-elf-loader.c
>> b/drivers/remoteproc/rproc-elf-loader.c
>> index 67937a7595..7574ba3fb3 100644
>> --- a/drivers/remoteproc/rproc-elf-loader.c
>> +++ b/drivers/remoteproc/rproc-elf-loader.c
>> @@ -86,7 +86,8 @@ int rproc_elf32_load_image(struct udevice *dev, unsigned
>> long addr)
>> continue;
>>
>> if (ops->device_to_virt)
>> -dst = ops->device_to_virt(dev, (ulong)dst);
>> +dst = ops->device_to_virt(dev, (ulong)dst,
>> + phdr->p_memsz);
>>
>> dev_dbg(dev, "Loading phdr %i to 0x%p (%i bytes)\n",
>> i, dst, phdr->p_filesz);
>> diff --git a/drivers/remoteproc/sandbox_testproc.c
>> b/drivers/remoteproc/sandbox_testproc.c
>> index 5f35119ab7..0a8f7871e1 100644
>> --- a/drivers/remoteproc/sandbox_testproc.c
>> +++ b/drivers/remoteproc/sandbox_testproc.c
>> @@ -306,9 +306,11 @@ static int sandbox_testproc_ping(struct udevice *dev)
>>* sandbox_testproc_device_to_virt() - Convert device address to virtual
>> address
>>* @dev: device to operate upon
>>* @da:device address
>> + * @size: Size of the section
>
>
> Size of the memory region @da is pointing to
>
>
>>* @return converted virtual address
>>*/
>> -static void *sandbox_testproc_device_to_virt(struct udevice *dev, ulong da)
>> +static void *sandbox_testproc_device_to_virt(struct udevice *dev, ulong da,
>> + ulong size)
>> {
>> u64 paddr;
>>
>> diff --git a/drivers/remoteproc/stm32_copro.c
>> b/drivers/remoteproc/stm32_copro.c
>> index de3b9729f3..ff82313bca 100644
>> --- a/drivers/remoteproc/stm32_copro.c
>> +++ b/drivers/remoteproc/stm32_copro.c
>> @@ -107,9 +107,11 @@ static int stm32_copro_set_hold_boot(struct udevice
>> *dev, bool hold)
>>* stm32_copro_device_to_virt() - Convert device address to virtual address
>>* @dev: corresponding STM32 remote processor device
>>* @da:device address
>> + * @size: Size of the section
>>* @return converted virtual address
>>*/
>> -static void *stm32_copro_device_to_virt(struct udevice *dev, ulong da)
>> +static void *stm32_copro_device_to_virt(struct udevice *dev, ulong da,
>> +ulong size)
>> {
>
>
> I guess it would be better than this function also checks that the end
> address of the region is in the range of valid region
>
> Something like:
>
> end_addr = cpu_to_be32(da + size - 1) + check success of
> dev_translate_dma_address(dev, &end_addr);
Sure Ill fix in v2 but I cannot test stm32 coproc. Please make sure that v2 will
not break your platform.
Thanks and regards,
Lokesh
>
>
>> fdt32_t in_addr = cpu_to_be32(da);
>> u64 paddr;
>> diff --git a/include/remoteproc.h b/include/remoteproc.h
>> index 4987194905..81f616a1f9 100644
>> --- a/include/remoteproc.h
>> +++ b/include/remoteproc.h
>> @@ -122,9 +122,10 @@ struct dm_rproc_ops {
>> *
>> * @dev:Remote proc device
>> * @da: Device address
>> + * @size: Size of the section
>
>
> Size of the memory region @da is pointing to
>
>
>> * @return virtual address.
>> */
>> -void * (*device_to_virt)(struct udevice *dev, ulong da);
>> +void * (*device_to_virt)(struct udevice *dev, ulong da, ulong size);
>> };
>>
>> /* Accessor */
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] bmips: correct name characters
Signed-off-by: Álvaro Fernández Rojas --- arch/mips/dts/brcm,bcm6362.dtsi | 2 +- arch/mips/dts/netgear,dgnd3700v2.dts| 2 +- board/netgear/dgnd3700v2/MAINTAINERS| 2 +- board/netgear/dgnd3700v2/dgnd3700v2.c | 2 +- include/dt-bindings/clock/bcm6362-clock.h | 2 +- include/dt-bindings/power-domain/bcm6362-power-domain.h | 2 +- include/dt-bindings/reset/bcm6362-reset.h | 2 +- 7 files changed, 7 insertions(+), 7 deletions(-) diff --git a/arch/mips/dts/brcm,bcm6362.dtsi b/arch/mips/dts/brcm,bcm6362.dtsi index c77b80a4cc..8b2ed8abee 100644 --- a/arch/mips/dts/brcm,bcm6362.dtsi +++ b/arch/mips/dts/brcm,bcm6362.dtsi @@ -1,6 +1,6 @@ // SPDX-License-Identifier: GPL-2.0+ /* - * Copyright (C) 2018 Ãlvaro Fernández Rojas + * Copyright (C) 2018 Álvaro Fernández Rojas */ #include diff --git a/arch/mips/dts/netgear,dgnd3700v2.dts b/arch/mips/dts/netgear,dgnd3700v2.dts index 2b72491f0b..88fca647cd 100644 --- a/arch/mips/dts/netgear,dgnd3700v2.dts +++ b/arch/mips/dts/netgear,dgnd3700v2.dts @@ -1,6 +1,6 @@ // SPDX-License-Identifier: GPL-2.0+ /* - * Copyright (C) 2018 Ãlvaro Fernández Rojas + * Copyright (C) 2018 Álvaro Fernández Rojas */ /dts-v1/; diff --git a/board/netgear/dgnd3700v2/MAINTAINERS b/board/netgear/dgnd3700v2/MAINTAINERS index 998077b69b..aaa51c177e 100644 --- a/board/netgear/dgnd3700v2/MAINTAINERS +++ b/board/netgear/dgnd3700v2/MAINTAINERS @@ -1,5 +1,5 @@ NETGEAR DGND3700V2 BOARD -M: Ãlvaro Fernández Rojas +M: Álvaro Fernández Rojas S: Maintained F: board/netgear/dgnd3700v2/ F: include/configs/netgear_dgnd3700v2.h diff --git a/board/netgear/dgnd3700v2/dgnd3700v2.c b/board/netgear/dgnd3700v2/dgnd3700v2.c index f8fc70e28d..6840a21001 100644 --- a/board/netgear/dgnd3700v2/dgnd3700v2.c +++ b/board/netgear/dgnd3700v2/dgnd3700v2.c @@ -1,6 +1,6 @@ // SPDX-License-Identifier: GPL-2.0+ /* - * Copyright (C) 2018 Ãlvaro Fernández Rojas + * Copyright (C) 2018 Álvaro Fernández Rojas */ #include diff --git a/include/dt-bindings/clock/bcm6362-clock.h b/include/dt-bindings/clock/bcm6362-clock.h index fed04e6b5f..d3770c5049 100644 --- a/include/dt-bindings/clock/bcm6362-clock.h +++ b/include/dt-bindings/clock/bcm6362-clock.h @@ -1,6 +1,6 @@ /* SPDX-License-Identifier: GPL-2.0+ */ /* - * Copyright (C) 2018 Ãlvaro Fernández Rojas + * Copyright (C) 2018 Álvaro Fernández Rojas * * Derived from linux/arch/mips/include/asm/mach-bcm63xx/bcm63xx_regs.h */ diff --git a/include/dt-bindings/power-domain/bcm6362-power-domain.h b/include/dt-bindings/power-domain/bcm6362-power-domain.h index ddc123ea88..1a708a9ad2 100644 --- a/include/dt-bindings/power-domain/bcm6362-power-domain.h +++ b/include/dt-bindings/power-domain/bcm6362-power-domain.h @@ -1,6 +1,6 @@ /* SPDX-License-Identifier: GPL-2.0+ */ /* - * Copyright (C) 2018 Ãlvaro Fernández Rojas + * Copyright (C) 2018 Álvaro Fernández Rojas */ #ifndef __DT_BINDINGS_POWER_DOMAIN_BCM6362_H diff --git a/include/dt-bindings/reset/bcm6362-reset.h b/include/dt-bindings/reset/bcm6362-reset.h index 6e257ce78f..8202e49919 100644 --- a/include/dt-bindings/reset/bcm6362-reset.h +++ b/include/dt-bindings/reset/bcm6362-reset.h @@ -1,6 +1,6 @@ /* SPDX-License-Identifier: GPL-2.0+ */ /* - * Copyright (C) 2018 Ãlvaro Fernández Rojas + * Copyright (C) 2018 Álvaro Fernández Rojas * * Derived from linux/arch/mips/include/asm/mach-bcm63xx/bcm63xx_regs.h */ -- 2.20.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v4 2/4] USB: host: Add the USB3 host driver
Hi Jean,
>
>
> On 28/08/2019 13:50, Sherry Sun wrote:
> > Hi Jean,
> >
> >> Hi Jean,
> >>
> >>> Hi Marek, Sherry,
> >>>
> >>>
> >>> we keep the cdns3 node for usb gadget driver, then add a usb
> >>> host node for
> >>> xhci-imx8 driver in *-uboot.dtsi. so here is no need to change
> >>> the host driver
> >> compatible.
> >>> But the compatible in gadget driver should be changed later.
> >> We should try avoiding ABI breaks in DT.
> > But the cdns3 usb gaget driver and host driver in different uclass
> > need two
> >>> dt nodes to bind with.
> > And the compatible of the two node cannot be same.
> > So for gadget driver, the compatible may use "cdns,usb3-1.0.0",
> > for host
> >>> driver, the compatible will use "cdns,usb3-1.0.0-host".
> > What do you think about it?
> CCing Jean, since I think he did solve similar topic for his platform.
> >>> I've been OOO for a few weeks and didn't look at the whole series.
> >>>
> >>> For this particular issue, the solution I used is to let the wrapper
> >>> do the binding job. The name of the driver to use is hard-coded in
> >>> the
> >> wrapper diver.
> >>> This is done in dwc3_glue_bind().
> >> Thanks for your suggestions.
> >>
> >> So if I want to use the cdns3 usb node as both usb gadget device and
> >> usb host device, do you mean that I should make the cdns3 usb node as
> >> a usb wrapper device, and create two subnodes in it.
>
> I think we should not change the binding to adapt to out driver but keep the
> bindings that exist in linux and adapt the u-boot driver
>
> In the version used by our platform, there is a wrapper around the USB:
>
> usbss0: cdns_usb@4104000 {
> compatible = "ti,j721e-usb";
> []
> usb0: usb@600 {
> compatible = "cdns,usb3-1.0.1";
>
> The driver selection (host or device) could be done by the wrapper when it
> binds its children (same as the dwc3).
>
> OR
>
> The "cdns,usb3-1.0.1" could be a dumb driver the role of which would be
> only to bind a new driver (host or device) based on "dr_mode". The binding
> could be done using the same node, it doesn't have to be a subnode.
>
>
> Maybe the second solution will be better, as it would work for platforms that
> do not use a wrapper.
>
I just communicated with Vignesh Raghavendra , and he suggest
that I should keep this cdns3 driver under Linux kernel and U-Boot in sync. And
show me your downstream code with v10 of Cadence USB3 kernel driver ported to
U-Boot. So I decide to follow your way to deal with this issue.
But I want to ask another question:
The two solutions you gave before both make the usb node with compatible
"cdns,usb3-1.0.1" as a definite device (host or gadget) by its dr_mode
property. If I want use this usb device works as both host and gadget driver,
which means I want to change its status runtime, such as I want to use this usb
device to run both fastboot or usb start command, how can we deal with this? .
Best regards
Sherry sun
>
> JJ
>
> >> Then when binding the wrapper node, it will hard-coded the two
> subnodes
> >> to different driver(gadge/host driver) according to the dr_mode property
> in
> >> nodes.
> >>
> > Do you think I understand it right?
>
> >
> > Best regards
> > Sherry sun
> >
> >> Best regards
> >> Sherry sun
> >>
> >>> JJ
> >>>
> >>>
> >>>
> > + { }
> > +};
> >> ___
> >> U-Boot mailing list
> >> U-Boot@lists.denx.de
> >> https://lists.d
> >> enx.de%2Flistinfo%2Fu-
> >>
> boot&data=02%7C01%7Csherry.sun%40nxp.com%7C35f1d34da1ea4b7
> >>
> 670ba08d72b823e9a%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7
> >>
> C637025710721487079&sdata=Nfk0qWtSViz60wJHAOr2m5tgIwTWjNwI
> >> GrNOxDH6HC0%3D&reserved=0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] common/memsize: panic if maxsize is not power of two
The memory write and recover loop in get_ram_size() work correctly
only if maxsize is power of two, otherwise the function will return a
small size.
Signed-off-by: Iru Cai
---
common/memsize.c | 4
1 file changed, 4 insertions(+)
diff --git a/common/memsize.c b/common/memsize.c
index 13b0047786..f627149a05 100644
--- a/common/memsize.c
+++ b/common/memsize.c
@@ -33,6 +33,10 @@ long get_ram_size(long *base, long maxsize)
long size;
inti = 0;
+ if ((maxsize & (maxsize - 1)) != 0) {
+ panic("maxsize must be power of 2!");
+ }
+
for (cnt = (maxsize / sizeof(long)) >> 1; cnt > 0; cnt >>= 1) {
addr = base + cnt; /* pointer arith! */
sync();
--
2.23.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] Fix unreliable detection of DRAM size on Orange Pi 3
Hello,
On Fri, Aug 30, 2019 at 01:44:34AM +0100, André Przywara wrote:
> On 25/08/2019 15:41, Siarhei Siamashka wrote:
> > On Sat, 24 Aug 2019 22:07:43 +0200
> > Ondřej Jirman wrote:
>
> Hi,
>
> >> Hi Jagan,
> >>
> >> can you please apply this patch to the sunxi tree, so that it
> >> doesn't get lost.
> >>
> >> thank you,
> >>Ondrej
> >>
> >> On Mon, Jul 29, 2019 at 01:39:42AM +0200, megous hlavni wrote:
> >>> From: Ondrej Jirman
> >>>
> >>> Orange Pi 3 has 2 GiB of DRAM, that sometime get misdetected
> >>> as 4 GiB, due to false negative result from mctl_mem_matches()
> >>> when detecting number of column address bits. This leads to
> >>> u-boot detecting more address bits than there are and the
> >>> boot process hangs shortly after.
> >>>
> >>> In mctl_mem_matches() we need to wait for each write to finish,
> >>> separately. Without this, the check is not reliable for some
> >>> unknown reason, probably having to do with unpredictable memory
> >>> access ordering.
> >>>
> >>> Patch was made with help from André Przywara, who noticed that
> >>> my original idea about detection failing due to read-back from
> >>> cache without involving DRAM was false, because data cache is
> >>> still of at the time of the DRAM size autodetection.
> >>>
> >>> Signed-off-by: Ondrej Jirman
> >>> Cc: André Przywara
> >>> ---
> >>> arch/arm/mach-sunxi/dram_helpers.c | 1 +
> >>> 1 file changed, 1 insertion(+)
> >>>
> >>> diff --git a/arch/arm/mach-sunxi/dram_helpers.c
> >>> b/arch/arm/mach-sunxi/dram_helpers.c
> >>> index 239ab421a8..6dba448638 100644
> >>> --- a/arch/arm/mach-sunxi/dram_helpers.c
> >>> +++ b/arch/arm/mach-sunxi/dram_helpers.c
> >>> @@ -30,6 +30,7 @@ bool mctl_mem_matches(u32 offset)
> >>> {
> >>> /* Try to write different values to RAM at two addresses */
> >>> writel(0, CONFIG_SYS_SDRAM_BASE);
> >>> + dsb();
> >>> writel(0xaa55aa55, (ulong)CONFIG_SYS_SDRAM_BASE + offset);
> >>> dsb();
> >>> /* Check if the same value is actually observed when reading back */
> >>> --
> >
> > Hi!
> >
> > This looks like resurfacing of the old problem, which did not get a
> > complete fix back in 2016:
> >https://lists.denx.de/pipermail/u-boot/2016-April/251803.html
> >
> > Now the main question is whether the DSB instruction's barrier
> > magic is really required here or maybe it's just a timing issue.
>
> I think both:
> From the compiler's and the CPU's point of view these two stores look
> independent: they don't have any data dependency and go to different
> addresses. So both the compiler and the CPU are allowed to reorder these
> stores. However, we are after some non-obvious aliasing effect, so in
> fact there *is* a dependency between the two stores. So architecturally
> this barrier is definitely required, to notify everyone about this
> dependency (although I think a dmb(); might be sufficient here).
OTOH, let's visualize it:
CPU address DRAM address
---
[w ] SDRAM_BASE 0
[w aa55aa55] SDRAM_BASE + offset0
Both writes should end up at the same physical location in dram).
The following test checks that values that are read back are the same. They
should be the same in this specific case of Opi3 SBC. It doesn't check for any
specific value, so even if writes are re-ordered, the value that's read back
should still be the same.
Order of operations is:
writel(0, CONFIG_SYS_SDRAM_BASE);
writel(0xaa55aa55, (ulong)CONFIG_SYS_SDRAM_BASE + offset);
dsb();
readl(CONFIG_SYS_SDRAM_BASE)
readl((ulong)CONFIG_SYS_SDRAM_BASE + offset);
The CPU can only re-order either the writes or reads. But neither should matter.
Memory controller is a black box to me and that's where the issue probably
lies.
The only time this should fail and return different values when reading is if
the hardware does some shortcut/assumption, and reads will not go fully from
DRAM after the writes.
Anyway, I'm failing to reproduce this even without any patches, ATM.
regards,
o.
> So for the sake of this patch, we should take it. It is needed and
> apparently solves one issue, and I can't see any harm in it.
>
> Regardless of this I was wondering if in this situation (single in-order
> core running with MMU and caches off) this is the full story, as the CPU
> does not have a good reason to reorder.
>
> > Could you please experiment with this problem a little bit more?
> >
> > 1. What if you just move this second DSB instruction after the
> > second write and have two of them there? Does this also make
> > the problem disappear?
>
> I don't think two dsb()s next to each other will do anything useful. I
> would think the second dsb() would just be ignored, as the order is
> already preserved and all memory accesses have been completed:
> "A DSB is a memory barrier that ensures that memory accesses that occur
> before the DSB have completed before the completio
Re: [U-Boot] [PATCH] bmips: configs: switch to size definitions
Am 30.08.19 um 11:54 schrieb Álvaro Fernández Rojas: > Signed-off-by: Álvaro Fernández Rojas > --- > include/configs/bmips_bcm3380.h | 6 -- > include/configs/bmips_bcm6318.h | 6 -- > include/configs/bmips_bcm63268.h | 6 -- > include/configs/bmips_bcm6328.h | 6 -- > include/configs/bmips_bcm6338.h | 6 -- > include/configs/bmips_bcm6348.h | 6 -- > include/configs/bmips_bcm6358.h | 6 -- > include/configs/bmips_bcm6362.h | 8 +--- > include/configs/bmips_bcm6368.h | 6 -- > include/configs/bmips_bcm6838.h | 6 -- > include/configs/bmips_common.h | 11 --- > include/configs/broadcom_bcm968380gerg.h | 2 +- > include/configs/comtrend_ar5315u.h | 3 +-- > include/configs/comtrend_ar5387un.h | 3 +-- > include/configs/comtrend_ct5361.h| 3 +-- > include/configs/comtrend_vr3032u.h | 3 +-- > include/configs/comtrend_wap5813n.h | 3 +-- > include/configs/huawei_hg556a.h | 3 +-- > include/configs/netgear_cg3100d.h| 3 +-- > include/configs/netgear_dgnd3700v2.h | 5 ++--- > include/configs/sagem_f@st1704.h | 3 +-- > include/configs/sfr_nb4_ser.h| 3 +-- > 22 files changed, 61 insertions(+), 46 deletions(-) Reviewed-by: Daniel Schwierzeck -- - Daniel ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH V2] mips: bmips: remove unneeded definitions
Am 30.08.19 um 11:52 schrieb Álvaro Fernández Rojas: > These are no longer needed. > > Signed-off-by: Álvaro Fernández Rojas > --- > v2: CONFIG_SYS_MONITOR_BASE is used for relocation and can't be removed > > include/configs/bmips_common.h | 4 > 1 file changed, 4 deletions(-) > Reviewed-by: Daniel Schwierzeck -- - Daniel ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v4 2/4] USB: host: Add the USB3 host driver
On 30/08/19 3:36 PM, Sherry Sun wrote:
> Hi Jean,
>
>>
>>
>> On 28/08/2019 13:50, Sherry Sun wrote:
>>> Hi Jean,
>>>
Hi Jean,
> Hi Marek, Sherry,
>
>
> we keep the cdns3 node for usb gadget driver, then add a usb
> host node for
> xhci-imx8 driver in *-uboot.dtsi. so here is no need to change
> the host driver
compatible.
> But the compatible in gadget driver should be changed later.
We should try avoiding ABI breaks in DT.
>>> But the cdns3 usb gaget driver and host driver in different uclass
>>> need two
> dt nodes to bind with.
>>> And the compatible of the two node cannot be same.
>>> So for gadget driver, the compatible may use "cdns,usb3-1.0.0",
>>> for host
> driver, the compatible will use "cdns,usb3-1.0.0-host".
>>> What do you think about it?
>> CCing Jean, since I think he did solve similar topic for his platform.
> I've been OOO for a few weeks and didn't look at the whole series.
>
> For this particular issue, the solution I used is to let the wrapper
> do the binding job. The name of the driver to use is hard-coded in
> the
wrapper diver.
> This is done in dwc3_glue_bind().
Thanks for your suggestions.
So if I want to use the cdns3 usb node as both usb gadget device and
usb host device, do you mean that I should make the cdns3 usb node as
a usb wrapper device, and create two subnodes in it.
>>
>> I think we should not change the binding to adapt to out driver but keep the
>> bindings that exist in linux and adapt the u-boot driver
>>
>> In the version used by our platform, there is a wrapper around the USB:
>>
>> usbss0: cdns_usb@4104000 {
>> compatible = "ti,j721e-usb";
>> []
>> usb0: usb@600 {
>> compatible = "cdns,usb3-1.0.1";
>>
>> The driver selection (host or device) could be done by the wrapper when it
>> binds its children (same as the dwc3).
>>
>> OR
>>
>> The "cdns,usb3-1.0.1" could be a dumb driver the role of which would be
>> only to bind a new driver (host or device) based on "dr_mode". The binding
>> could be done using the same node, it doesn't have to be a subnode.
>>
>>
>> Maybe the second solution will be better, as it would work for platforms that
>> do not use a wrapper.
>>
>
> I just communicated with Vignesh Raghavendra , and he
> suggest that I should keep this cdns3 driver under Linux kernel and U-Boot in
> sync. And show me your downstream code with v10 of Cadence USB3 kernel
> driver ported to U-Boot. So I decide to follow your way to deal with this
> issue.
>
> But I want to ask another question:
> The two solutions you gave before both make the usb node with compatible
> "cdns,usb3-1.0.1" as a definite device (host or gadget) by its dr_mode
> property. If I want use this usb device works as both host and gadget driver,
> which means I want to change its status runtime, such as I want to use this
> usb device to run both fastboot or usb start command, how can we deal with
> this? .
>
AFAIK, U-Boot does not support runtime switching of USB port to host
from device and vice versa. This is the case for existing driver like
DWC3/MUSB etc.
Ideally we would need a role switch driver that unbinds and rebinds host
vs device driver as when required based on U-Boot cmd or via an API (if
required to be done during SPL stage etc).
Regards
Vignesh
> Best regards
> Sherry sun
>
>>
>> JJ
>>
Then when binding the wrapper node, it will hard-coded the two
>> subnodes
to different driver(gadge/host driver) according to the dr_mode property
>> in
nodes.
>>> Do you think I understand it right?
>>
>>>
>>> Best regards
>>> Sherry sun
>>>
Best regards
Sherry sun
> JJ
>
>
>
>>> + { }
>>> +};
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.d
enx.de%2Flistinfo%2Fu-
>> boot&data=02%7C01%7Csherry.sun%40nxp.com%7C35f1d34da1ea4b7
>> 670ba08d72b823e9a%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7
>> C637025710721487079&sdata=Nfk0qWtSViz60wJHAOr2m5tgIwTWjNwI
GrNOxDH6HC0%3D&reserved=0
--
Regards
Vignesh
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v1] apalis-tk1: use distroboot by default
On Wed, Aug 28, 2019 at 7:41 PM Igor Opaniuk wrote:
>
> From: Igor Opaniuk
>
> Use distro boot by default instead legacy wrappers.
>
> Signed-off-by: Igor Opaniuk
Reviewed-by: Oleksandr Suvorov
> ---
>
> configs/apalis-tk1_defconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/configs/apalis-tk1_defconfig b/configs/apalis-tk1_defconfig
> index be0554b150..bb36bb3870 100644
> --- a/configs/apalis-tk1_defconfig
> +++ b/configs/apalis-tk1_defconfig
> @@ -8,7 +8,7 @@ CONFIG_TARGET_APALIS_TK1=y
> CONFIG_FIT=y
> CONFIG_OF_SYSTEM_SETUP=y
> CONFIG_BOOTDELAY=1
> -CONFIG_BOOTCOMMAND="run emmcboot; setenv fdtfile
> ${soc}-${fdt-module}-${fdt_board}.dtb && run distro_bootcmd"
> +CONFIG_BOOTCOMMAND="setenv boot_file zImage; setenv fdtfile
> ${soc}-${fdt_module}-${fdt_board}.dtb && run distro_bootcmd"
> CONFIG_CONSOLE_MUX=y
> CONFIG_SYS_STDIO_DEREGISTER=y
> CONFIG_VERSION_VARIABLE=y
> --
> 2.17.1
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot
--
Best regards
Oleksandr Suvorov
cryo...@gmail.com
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/8] power: domain: meson-gx-pwrc: add G12A support
Add Amlogic G12A support for the gx-pwrc driver, aligned on the
Linux v5.2 driver.
Signed-off-by: Neil Armstrong
---
drivers/power/domain/meson-gx-pwrc-vpu.c | 155 +--
1 file changed, 145 insertions(+), 10 deletions(-)
diff --git a/drivers/power/domain/meson-gx-pwrc-vpu.c
b/drivers/power/domain/meson-gx-pwrc-vpu.c
index d631d3e6ff..f44e33bacb 100644
--- a/drivers/power/domain/meson-gx-pwrc-vpu.c
+++ b/drivers/power/domain/meson-gx-pwrc-vpu.c
@@ -14,6 +14,11 @@
#include
#include
+enum {
+ VPU_PWRC_COMPATIBLE_GX = 0,
+ VPU_PWRC_COMPATIBLE_G12A= 1,
+};
+
/* AO Offsets */
#define AO_RTI_GEN_PWR_SLEEP0 (0x3a << 2)
@@ -26,6 +31,7 @@
#define HHI_MEM_PD_REG0(0x40 << 2)
#define HHI_VPU_MEM_PD_REG0(0x41 << 2)
#define HHI_VPU_MEM_PD_REG1(0x42 << 2)
+#define HHI_VPU_MEM_PD_REG2(0x4d << 2)
struct meson_gx_pwrc_vpu_priv {
struct regmap *regmap_ao;
@@ -34,12 +40,12 @@ struct meson_gx_pwrc_vpu_priv {
struct clk_bulk clks;
};
-static int meson_gx_pwrc_vpu_request(struct power_domain *power_domain)
+static int meson_pwrc_vpu_request(struct power_domain *power_domain)
{
return 0;
}
-static int meson_gx_pwrc_vpu_free(struct power_domain *power_domain)
+static int meson_pwrc_vpu_free(struct power_domain *power_domain)
{
return 0;
}
@@ -91,6 +97,73 @@ static int meson_gx_pwrc_vpu_on(struct power_domain
*power_domain)
return 0;
}
+static int meson_g12a_pwrc_vpu_on(struct power_domain *power_domain)
+{
+ struct meson_gx_pwrc_vpu_priv *priv = dev_get_priv(power_domain->dev);
+ int i, ret;
+
+ regmap_update_bits(priv->regmap_ao, AO_RTI_GEN_PWR_SLEEP0,
+ GEN_PWR_VPU_HDMI, 0);
+ udelay(20);
+
+ /* Power Up Memories */
+ for (i = 0; i < 32; i += 2) {
+ regmap_update_bits(priv->regmap_hhi, HHI_VPU_MEM_PD_REG0,
+ 0x3 << i, 0);
+ udelay(5);
+ }
+
+ for (i = 0; i < 32; i += 2) {
+ regmap_update_bits(priv->regmap_hhi, HHI_VPU_MEM_PD_REG1,
+ 0x3 << i, 0);
+ udelay(5);
+ }
+
+ for (i = 0; i < 32; i += 2) {
+ regmap_update_bits(priv->regmap_hhi, HHI_VPU_MEM_PD_REG2,
+ 0x3 << i, 0);
+ udelay(5);
+ }
+
+ for (i = 8; i < 16; i++) {
+ regmap_update_bits(priv->regmap_hhi, HHI_MEM_PD_REG0,
+ BIT(i), 0);
+ udelay(5);
+ }
+ udelay(20);
+
+ ret = reset_assert_bulk(&priv->resets);
+ if (ret)
+ return ret;
+
+ regmap_update_bits(priv->regmap_ao, AO_RTI_GEN_PWR_SLEEP0,
+ GEN_PWR_VPU_HDMI_ISO, 0);
+
+ ret = reset_deassert_bulk(&priv->resets);
+ if (ret)
+ return ret;
+
+ ret = clk_enable_bulk(&priv->clks);
+ if (ret)
+ return ret;
+
+ return 0;
+}
+
+static int meson_pwrc_vpu_on(struct power_domain *power_domain)
+{
+ unsigned int compat = dev_get_driver_data(power_domain->dev);
+
+ switch (compat) {
+ case VPU_PWRC_COMPATIBLE_GX:
+ return meson_gx_pwrc_vpu_on(power_domain);
+ case VPU_PWRC_COMPATIBLE_G12A:
+ return meson_g12a_pwrc_vpu_on(power_domain);
+ }
+
+ return -EINVAL;
+}
+
static int meson_gx_pwrc_vpu_off(struct power_domain *power_domain)
{
struct meson_gx_pwrc_vpu_priv *priv = dev_get_priv(power_domain->dev);
@@ -127,8 +200,63 @@ static int meson_gx_pwrc_vpu_off(struct power_domain
*power_domain)
return 0;
}
-static int meson_gx_pwrc_vpu_of_xlate(struct power_domain *power_domain,
- struct ofnode_phandle_args *args)
+static int meson_g12a_pwrc_vpu_off(struct power_domain *power_domain)
+{
+ struct meson_gx_pwrc_vpu_priv *priv = dev_get_priv(power_domain->dev);
+ int i;
+
+ regmap_update_bits(priv->regmap_ao, AO_RTI_GEN_PWR_SLEEP0,
+ GEN_PWR_VPU_HDMI_ISO, GEN_PWR_VPU_HDMI_ISO);
+ udelay(20);
+
+ /* Power Down Memories */
+ for (i = 0; i < 32; i += 2) {
+ regmap_update_bits(priv->regmap_hhi, HHI_VPU_MEM_PD_REG0,
+ 0x3 << i, 0x3 << i);
+ udelay(5);
+ }
+ for (i = 0; i < 32; i += 2) {
+ regmap_update_bits(priv->regmap_hhi, HHI_VPU_MEM_PD_REG1,
+ 0x3 << i, 0x3 << i);
+ udelay(5);
+ }
+ for (i = 0; i < 32; i += 2) {
+ regmap_update_bits(priv->regmap_hhi, HHI_VPU_MEM_PD_REG2,
+ 0x3 << i, 0x3 << i);
+ udelay(5);
+ }
+ for (i = 8; i < 16; i++) {
+ regmap_update_bits(priv->regmap_hhi, HHI_MEM_PD_RE
[U-Boot] [PATCH 0/8] arm: meson: add Video support for G12A and SEI510 board
This patchset adds Amlogic G12A support for HDMI & Composite video output like the Amlogic GXBB/GXL/GXM, by syncing from the latest Linux VPU DRM driver. It also adds VPU/VAPB/HDMI Clock & VPU Power Domain support. Finally it adds the necessary config to show a logo from a fastboot flashed partition on the SEI510 board. U200 and Odroid-N2 config support will be added later. Neil Armstrong (8): power: domain: meson-gx-pwrc: add G12A support clk: meson: g12a: add support for VPU/HDMI clocks video: meson: remove power domain get video: meson: sync with linux drm-misc tree video: meson: add compatible for Amlogic G12A arm: meson: board-g12a: Setup VPU in fdt ARM: dts: meson-g12a: add U-Boot specific DT for graphics configs: sei510: enable Video Display support arch/arm/dts/meson-g12a-sei510-u-boot.dtsi| 7 + arch/arm/dts/meson-g12a-u-boot.dtsi | 29 + arch/arm/dts/meson-g12a-u200-u-boot.dtsi | 7 + arch/arm/dts/meson-g12b-odroid-n2-u-boot.dtsi | 7 + arch/arm/mach-meson/board-g12a.c | 5 + configs/sei510_defconfig | 11 + drivers/clk/meson/g12a.c | 620 +- drivers/power/domain/meson-gx-pwrc-vpu.c | 155 - drivers/video/meson/meson_dw_hdmi.c | 61 +- drivers/video/meson/meson_plane.c | 47 +- drivers/video/meson/meson_registers.h | 373 ++- drivers/video/meson/meson_vclk.c | 233 +-- drivers/video/meson/meson_venc.c | 169 - drivers/video/meson/meson_vpu.c | 11 +- drivers/video/meson/meson_vpu.h | 2 + drivers/video/meson/meson_vpu_init.c | 205 -- include/configs/sei510.h | 12 + 17 files changed, 1757 insertions(+), 197 deletions(-) create mode 100644 arch/arm/dts/meson-g12a-sei510-u-boot.dtsi create mode 100644 arch/arm/dts/meson-g12a-u-boot.dtsi create mode 100644 arch/arm/dts/meson-g12a-u200-u-boot.dtsi create mode 100644 arch/arm/dts/meson-g12b-odroid-n2-u-boot.dtsi -- 2.22.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 2/8] clk: meson: g12a: add support for VPU/HDMI clocks
Add necessary clock support to set up clock for the VPU and
HDMI support.
Signed-off-by: Neil Armstrong
---
drivers/clk/meson/g12a.c | 620 +--
1 file changed, 603 insertions(+), 17 deletions(-)
diff --git a/drivers/clk/meson/g12a.c b/drivers/clk/meson/g12a.c
index 43dac1aa37..c03738b6ca 100644
--- a/drivers/clk/meson/g12a.c
+++ b/drivers/clk/meson/g12a.c
@@ -14,16 +14,93 @@
#include
#include
#include
+#include
#include "clk_meson.h"
+/* This driver support only basic clock tree operations :
+ * - Can calculate clock frequency on a limited tree
+ * - Can Read muxes and basic dividers (0-based only)
+ * - Can enable/disable gates with limited propagation
+ * - Can reparent without propagation, only on muxes
+ * - Can set rates without reparenting
+ * This driver is adapted to what is actually supported by U-Boot
+ */
+
+/* Only the clocks ids we don't want to expose, such as the internal muxes
+ * and dividers of composite clocks, will remain defined here.
+ */
+#define CLKID_MPEG_SEL 8
+#define CLKID_MPEG_DIV 9
+#define CLKID_SD_EMMC_A_CLK0_SEL 63
+#define CLKID_SD_EMMC_A_CLK0_DIV 64
+#define CLKID_SD_EMMC_B_CLK0_SEL 65
+#define CLKID_SD_EMMC_B_CLK0_DIV 66
+#define CLKID_SD_EMMC_C_CLK0_SEL 67
+#define CLKID_SD_EMMC_C_CLK0_DIV 68
+#define CLKID_MPLL0_DIV69
+#define CLKID_MPLL1_DIV70
+#define CLKID_MPLL2_DIV71
+#define CLKID_MPLL3_DIV72
+#define CLKID_MPLL_PREDIV 73
+#define CLKID_FCLK_DIV2_DIV75
+#define CLKID_FCLK_DIV3_DIV76
+#define CLKID_FCLK_DIV4_DIV77
+#define CLKID_FCLK_DIV5_DIV78
+#define CLKID_FCLK_DIV7_DIV79
+#define CLKID_FCLK_DIV2P5_DIV 100
+#define CLKID_FIXED_PLL_DCO101
+#define CLKID_SYS_PLL_DCO 102
+#define CLKID_GP0_PLL_DCO 103
+#define CLKID_HIFI_PLL_DCO 104
+#define CLKID_VPU_0_DIV111
+#define CLKID_VPU_1_DIV114
+#define CLKID_VAPB_0_DIV 118
+#define CLKID_VAPB_1_DIV 121
+#define CLKID_HDMI_PLL_DCO 125
+#define CLKID_HDMI_PLL_OD 126
+#define CLKID_HDMI_PLL_OD2 127
+#define CLKID_VID_PLL_SEL 130
+#define CLKID_VID_PLL_DIV 131
+#define CLKID_VCLK_SEL 132
+#define CLKID_VCLK2_SEL133
+#define CLKID_VCLK_INPUT 134
+#define CLKID_VCLK2_INPUT 135
+#define CLKID_VCLK_DIV 136
+#define CLKID_VCLK2_DIV137
+#define CLKID_VCLK_DIV2_EN 140
+#define CLKID_VCLK_DIV4_EN 141
+#define CLKID_VCLK_DIV6_EN 142
+#define CLKID_VCLK_DIV12_EN143
+#define CLKID_VCLK2_DIV2_EN144
+#define CLKID_VCLK2_DIV4_EN145
+#define CLKID_VCLK2_DIV6_EN146
+#define CLKID_VCLK2_DIV12_EN 147
+#define CLKID_CTS_ENCI_SEL 158
+#define CLKID_CTS_ENCP_SEL 159
+#define CLKID_CTS_VDAC_SEL 160
+#define CLKID_HDMI_TX_SEL 161
+#define CLKID_HDMI_SEL 166
+#define CLKID_HDMI_DIV 167
+#define CLKID_MALI_0_DIV 170
+#define CLKID_MALI_1_DIV 173
+
+#define CLKID_XTAL 0x1000
+
#define XTAL_RATE 2400
struct meson_clk {
struct regmap *map;
};
+static ulong meson_div_get_rate(struct clk *clk, unsigned long id);
+static ulong meson_div_set_rate(struct clk *clk, unsigned long id, ulong rate,
+ ulong current_rate);
+static ulong meson_mux_set_parent(struct clk *clk, unsigned long id,
+ unsigned long parent_id);
+static ulong meson_mux_get_rate(struct clk *clk, unsigned long id);
static ulong meson_clk_set_rate_by_id(struct clk *clk, unsigned long id,
ulong rate, ulong current_rate);
+static ulong meson_mux_get_parent(struct clk *clk, unsigned long id);
static ulong meson_clk_get_rate_by_id(struct clk *clk, unsigned long id);
#define NUM_CLKS 178
@@ -39,40 +116,447 @@ static struct meson_gate gates[NUM_CLKS] = {
MESON_GATE(CLKID_ETH, HHI_GCLK_MPEG1, 3),
MESON_GATE(CLKID_UART1, HHI_GCLK_MPEG1, 16),
MESON_GATE(CLKID_USB, HHI_GCLK_MPEG1, 25),
+ MESON_GATE(CLKID_HTX_PCLK, HHI
[U-Boot] [PATCH 7/8] ARM: dts: meson-g12a: add U-Boot specific DT for graphics
Like the meson-gx support, add the U-Boot specific bits in DT
to support graphics on G12A SoCs.
Signed-off-by: Neil Armstrong
---
arch/arm/dts/meson-g12a-sei510-u-boot.dtsi| 7 +
arch/arm/dts/meson-g12a-u-boot.dtsi | 29 +++
arch/arm/dts/meson-g12a-u200-u-boot.dtsi | 7 +
arch/arm/dts/meson-g12b-odroid-n2-u-boot.dtsi | 7 +
4 files changed, 50 insertions(+)
create mode 100644 arch/arm/dts/meson-g12a-sei510-u-boot.dtsi
create mode 100644 arch/arm/dts/meson-g12a-u-boot.dtsi
create mode 100644 arch/arm/dts/meson-g12a-u200-u-boot.dtsi
create mode 100644 arch/arm/dts/meson-g12b-odroid-n2-u-boot.dtsi
diff --git a/arch/arm/dts/meson-g12a-sei510-u-boot.dtsi
b/arch/arm/dts/meson-g12a-sei510-u-boot.dtsi
new file mode 100644
index 00..fddffd628c
--- /dev/null
+++ b/arch/arm/dts/meson-g12a-sei510-u-boot.dtsi
@@ -0,0 +1,7 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2019 BayLibre, SAS.
+ * Author: Neil Armstrong
+ */
+
+#include "meson-g12a-u-boot.dtsi"
diff --git a/arch/arm/dts/meson-g12a-u-boot.dtsi
b/arch/arm/dts/meson-g12a-u-boot.dtsi
new file mode 100644
index 00..38fd3d3feb
--- /dev/null
+++ b/arch/arm/dts/meson-g12a-u-boot.dtsi
@@ -0,0 +1,29 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2019 BayLibre, SAS.
+ * Author: Maxime Jourdan
+ */
+
+/ {
+ soc {
+ u-boot,dm-pre-reloc;
+ };
+};
+
+&canvas {
+ status = "disabled";
+};
+
+&vpu {
+ reg = <0x0 0xff90 0x0 0x10>,
+ <0x0 0xff63c000 0x0 0x1000>,
+ <0x0 0xff638000 0x0 0x400>;
+ reg-names = "vpu", "hhi", "dmc";
+ u-boot,dm-pre-reloc;
+};
+
+&hdmi_tx {
+ reg = <0x0 0x0 0x0 0x1>,
+ <0x0 0x3c000 0x0 0x1000>;
+ reg-names = "hdmitx", "hhi";
+};
diff --git a/arch/arm/dts/meson-g12a-u200-u-boot.dtsi
b/arch/arm/dts/meson-g12a-u200-u-boot.dtsi
new file mode 100644
index 00..fddffd628c
--- /dev/null
+++ b/arch/arm/dts/meson-g12a-u200-u-boot.dtsi
@@ -0,0 +1,7 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2019 BayLibre, SAS.
+ * Author: Neil Armstrong
+ */
+
+#include "meson-g12a-u-boot.dtsi"
diff --git a/arch/arm/dts/meson-g12b-odroid-n2-u-boot.dtsi
b/arch/arm/dts/meson-g12b-odroid-n2-u-boot.dtsi
new file mode 100644
index 00..fddffd628c
--- /dev/null
+++ b/arch/arm/dts/meson-g12b-odroid-n2-u-boot.dtsi
@@ -0,0 +1,7 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2019 BayLibre, SAS.
+ * Author: Neil Armstrong
+ */
+
+#include "meson-g12a-u-boot.dtsi"
--
2.22.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 5/8] video: meson: add compatible for Amlogic G12A
Finally add the Amlogic G12A SoC compatible for the VPU driver.
Signed-off-by: Neil Armstrong
---
drivers/video/meson/meson_vpu.c | 1 +
drivers/video/meson/meson_vpu.h | 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/video/meson/meson_vpu.c b/drivers/video/meson/meson_vpu.c
index 34d35749eb..c3af9b013c 100644
--- a/drivers/video/meson/meson_vpu.c
+++ b/drivers/video/meson/meson_vpu.c
@@ -86,6 +86,7 @@ static const struct udevice_id meson_vpu_ids[] = {
{ .compatible = "amlogic,meson-gxbb-vpu", .data = VPU_COMPATIBLE_GXBB },
{ .compatible = "amlogic,meson-gxl-vpu", .data = VPU_COMPATIBLE_GXL },
{ .compatible = "amlogic,meson-gxm-vpu", .data = VPU_COMPATIBLE_GXM },
+ { .compatible = "amlogic,meson-g12a-vpu", .data = VPU_COMPATIBLE_G12A },
{ }
};
diff --git a/drivers/video/meson/meson_vpu.h b/drivers/video/meson/meson_vpu.h
index 3412dac052..0d9fddad2e 100644
--- a/drivers/video/meson/meson_vpu.h
+++ b/drivers/video/meson/meson_vpu.h
@@ -28,6 +28,7 @@ enum vpu_compatible {
VPU_COMPATIBLE_GXBB = 0,
VPU_COMPATIBLE_GXL = 1,
VPU_COMPATIBLE_GXM = 2,
+ VPU_COMPATIBLE_G12A = 3,
};
struct meson_vpu_priv {
--
2.22.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 3/8] video: meson: remove power domain get
Remove getting and enabling the node power domain since it's now handled
by the dm core directly.
Signed-off-by: Neil Armstrong
---
drivers/video/meson/meson_vpu.c | 10 --
1 file changed, 10 deletions(-)
diff --git a/drivers/video/meson/meson_vpu.c b/drivers/video/meson/meson_vpu.c
index 279401d597..34d35749eb 100644
--- a/drivers/video/meson/meson_vpu.c
+++ b/drivers/video/meson/meson_vpu.c
@@ -7,7 +7,6 @@
*/
#include "meson_vpu.h"
-#include
#include
#include
#include
@@ -93,7 +92,6 @@ static const struct udevice_id meson_vpu_ids[] = {
static int meson_vpu_probe(struct udevice *dev)
{
struct meson_vpu_priv *priv = dev_get_priv(dev);
- struct power_domain pd;
struct udevice *disp;
int ret;
@@ -115,14 +113,6 @@ static int meson_vpu_probe(struct udevice *dev)
if (!priv->dmc_base)
return -EINVAL;
- ret = power_domain_get(dev, &pd);
- if (ret)
- return ret;
-
- ret = power_domain_on(&pd);
- if (ret)
- return ret;
-
meson_vpu_init(dev);
/* probe the display */
--
2.22.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 8/8] configs: sei510: enable Video Display support
Add the necessary config options to support BMP display over HDMI,
and add a preboot command to load the BMP file from a predefined
eMMC partition.
Signed-off-by: Neil Armstrong
---
configs/sei510_defconfig | 11 +++
include/configs/sei510.h | 12
2 files changed, 23 insertions(+)
diff --git a/configs/sei510_defconfig b/configs/sei510_defconfig
index 5aea81d873..9eb205bc63 100644
--- a/configs/sei510_defconfig
+++ b/configs/sei510_defconfig
@@ -11,6 +11,9 @@ CONFIG_IDENT_STRING=" sei510"
# CONFIG_PSCI_RESET is not set
CONFIG_DEBUG_UART=y
CONFIG_OF_BOARD_SETUP=y
+CONFIG_USE_PREBOOT=y
+CONFIG_PREBOOT="run load_logo"
+# CONFIG_CONSOLE_MUX is not set
CONFIG_MISC_INIT_R=y
# CONFIG_DISPLAY_CPUINFO is not set
# CONFIG_CMD_BDI is not set
@@ -23,6 +26,7 @@ CONFIG_CMD_USB=y
CONFIG_CMD_USB_MASS_STORAGE=y
# CONFIG_CMD_SETEXPR is not set
CONFIG_CMD_REGULATOR=y
+CONFIG_CMD_BMP=y
CONFIG_OF_CONTROL=y
CONFIG_DEFAULT_DEVICE_TREE="meson-g12a-sei510"
CONFIG_ENV_IS_IN_MMC=y
@@ -33,6 +37,7 @@ CONFIG_FASTBOOT_FLASH=y
CONFIG_FASTBOOT_FLASH_MMC_DEV=2
CONFIG_FASTBOOT_CMD_OEM_FORMAT=y
CONFIG_DM_GPIO=y
+# CONFIG_INPUT is not set
CONFIG_DM_MMC=y
CONFIG_MMC_MESON_GX=y
CONFIG_PHY_ADDR_ENABLE=y
@@ -42,6 +47,12 @@ CONFIG_ETH_DESIGNWARE=y
CONFIG_MESON_G12A_USB_PHY=y
CONFIG_PINCTRL=y
CONFIG_PINCTRL_MESON_G12A=y
+CONFIG_POWER_DOMAIN=y
+CONFIG_MESON_GX_VPU_POWER_DOMAIN=y
+CONFIG_DM_VIDEO=y
+CONFIG_SYS_WHITE_ON_BLACK=y
+CONFIG_VIDEO_MESON=y
+CONFIG_VIDEO_DT_SIMPLEFB=y
CONFIG_DM_REGULATOR=y
CONFIG_DM_REGULATOR_FIXED=y
CONFIG_DM_RESET=y
diff --git a/include/configs/sei510.h b/include/configs/sei510.h
index 9957902250..5bf982cada 100644
--- a/include/configs/sei510.h
+++ b/include/configs/sei510.h
@@ -14,6 +14,7 @@
#define CONFIG_ENV_SIZE0x1
#define CONFIG_ENV_OFFSET (-0x1)
+#define LOGO_UUID "43a3305d-150f-4cc9-bd3b-38fca8693846;"
#define CACHE_UUID "99207ae6-5207-11e9-999e-6f77a3612069;"
#define SYSTEM_UUID "99f9b7ac-5207-11e9-8507-c3c037e393f3;"
#define VENDOR_UUID "9d082802-5207-11e9-954c-cbbce08ba108;"
@@ -23,6 +24,7 @@
#define PARTS_DEFAULT\
"uuid_disk=${uuid_gpt_disk};" \
"name=boot,size=64M,bootable,uuid=${uuid_gpt_boot};" \
+ "name=logo,size=2M,uuid=" LOGO_UUID \
"name=cache,size=256M,uuid=" CACHE_UUID \
"name=system,size=1536M,uuid=" SYSTEM_UUID \
"name=vendor,size=256M,uuid=" VENDOR_UUID\
@@ -113,12 +115,22 @@
func(RECOVERY, recovery, na) \
func(SYSTEM, system, na) \
+#define PREBOOT_LOAD_LOGO \
+ "mmc dev ${mmcdev};" \
+ "part start mmc ${mmcdev} ${logopart} boot_start;" \
+ "part size mmc ${mmcdev} ${logopart} boot_size;" \
+ "if mmc read ${loadaddr} ${boot_start} ${boot_size}; then " \
+ "bmp display ${loadaddr} m m;" \
+ "fi;"
+
#define CONFIG_EXTRA_ENV_SETTINGS \
"partitions=" PARTS_DEFAULT "\0" \
"mmcdev=2\0" \
"bootpart=1\0"\
+ "logopart=2\0"\
"gpio_recovery=88\0" \
"check_button=gpio input ${gpio_recovery};test $? -eq 0;\0" \
+ "load_logo=" PREBOOT_LOAD_LOGO "\0" \
"console=/dev/ttyAML0\0" \
"bootargs=no_console_suspend\0" \
"stdin=" STDIN_CFG "\0" \
--
2.22.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 6/8] arm: meson: board-g12a: Setup VPU in fdt
If VIDEO_MESON is enabled, we need to setup the fdt for the framebuffer. Call meson_vpu_rsv_fb() which reserves the framebuffer memory region for EFI, and sets up simple-framebuffer nodes if simplefb support is enabled. Signed-off-by: Neil Armstrong --- arch/arm/mach-meson/board-g12a.c | 5 + 1 file changed, 5 insertions(+) diff --git a/arch/arm/mach-meson/board-g12a.c b/arch/arm/mach-meson/board-g12a.c index 546b9f6039..24786df6cd 100644 --- a/arch/arm/mach-meson/board-g12a.c +++ b/arch/arm/mach-meson/board-g12a.c @@ -9,6 +9,7 @@ #include #include #include +#include #include #include #include @@ -57,6 +58,10 @@ void meson_init_reserved_memory(void *fdt) /* Add BL32 reserved zone */ if (bl32_start && bl32_size) meson_board_add_reserved_memory(fdt, bl32_start, bl32_size); + +#if defined(CONFIG_VIDEO_MESON) + meson_vpu_rsv_fb(fdt); +#endif } phys_size_t get_effective_memsize(void) -- 2.22.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 4/8] video: meson: sync with linux drm-misc tree
Synchronize the Amlogic Meson Video driver back with the latest
DRM misc tree, adding G12A platform support, from the latest commit:
528a25d040bc ("drm: meson: use match data to detect vpu compatibility")
The sync includes the following changes from Linux adapted to U-Boot:
- Add support for VIC alternate timings
- Switch PLL to 5.94GHz base for 297Mhz pixel clock
- Add registers for G12A SoC
- Add G12A Support for VPP setup
- Add G12A Support for VIU setup
- Add G12A support for OSD1 Plane
- Add G12A support for plane handling in CRTC driver
- Add G12A support for CVBS Encoder
- Add G12A Video Clock setup
- Add G12A support for the DW-HDMI Glue
- fix G12A HDMI PLL settings for 4K60 1000/1001 variations
- fix primary plane disabling
- fix G12A primary plane disabling
- mask value when writing bits relaxed
- crtc: drv: vpp: viu: venc: use proper macros instead of magic constants
- global clean-up
- add macro used to enable HDMI PLL
- venc: set the correct macrovision max amplitude value
Signed-off-by: Neil Armstrong
---
drivers/video/meson/meson_dw_hdmi.c | 61 -
drivers/video/meson/meson_plane.c | 47 +++-
drivers/video/meson/meson_registers.h | 373 +-
drivers/video/meson/meson_vclk.c | 233
drivers/video/meson/meson_venc.c | 169 +---
drivers/video/meson/meson_vpu.h | 1 +
drivers/video/meson/meson_vpu_init.c | 205 +++---
7 files changed, 929 insertions(+), 160 deletions(-)
diff --git a/drivers/video/meson/meson_dw_hdmi.c
b/drivers/video/meson/meson_dw_hdmi.c
index 9831d978fc..ae2e6288f3 100644
--- a/drivers/video/meson/meson_dw_hdmi.c
+++ b/drivers/video/meson/meson_dw_hdmi.c
@@ -24,6 +24,7 @@
#define HDMITX_TOP_ADDR_REG0x0
#define HDMITX_TOP_DATA_REG0x4
#define HDMITX_TOP_CTRL_REG0x8
+#define HDMITX_TOP_G12A_OFFSET 0x8000
/* Controller Communication Channel */
#define HDMITX_DWC_ADDR_REG0x10
@@ -37,6 +38,8 @@
#define HHI_HDMI_PHY_CNTL1 0x3a4 /* 0xe9 */
#define HHI_HDMI_PHY_CNTL2 0x3a8 /* 0xea */
#define HHI_HDMI_PHY_CNTL3 0x3ac /* 0xeb */
+#define HHI_HDMI_PHY_CNTL4 0x3b0 /* 0xec */
+#define HHI_HDMI_PHY_CNTL5 0x3b4 /* 0xed */
struct meson_dw_hdmi {
struct udevice *dev;
@@ -48,6 +51,7 @@ enum hdmi_compatible {
HDMI_COMPATIBLE_GXBB = 0,
HDMI_COMPATIBLE_GXL = 1,
HDMI_COMPATIBLE_GXM = 2,
+ HDMI_COMPATIBLE_G12A = 3,
};
static inline bool meson_hdmi_is_compatible(struct meson_dw_hdmi *priv,
@@ -60,8 +64,14 @@ static inline bool meson_hdmi_is_compatible(struct
meson_dw_hdmi *priv,
static unsigned int dw_hdmi_top_read(struct dw_hdmi *hdmi, unsigned int addr)
{
+ struct meson_dw_hdmi *priv = container_of(hdmi, struct meson_dw_hdmi,
+ hdmi);
unsigned int data;
+ if (meson_hdmi_is_compatible(priv, HDMI_COMPATIBLE_G12A))
+ return readl(hdmi->ioaddr +
+HDMITX_TOP_G12A_OFFSET + (addr << 2));
+
/* ADDR must be written twice */
writel(addr & 0x, hdmi->ioaddr + HDMITX_TOP_ADDR_REG);
writel(addr & 0x, hdmi->ioaddr + HDMITX_TOP_ADDR_REG);
@@ -76,6 +86,15 @@ static unsigned int dw_hdmi_top_read(struct dw_hdmi *hdmi,
unsigned int addr)
static inline void dw_hdmi_top_write(struct dw_hdmi *hdmi,
unsigned int addr, unsigned int data)
{
+ struct meson_dw_hdmi *priv = container_of(hdmi, struct meson_dw_hdmi,
+ hdmi);
+
+ if (meson_hdmi_is_compatible(priv, HDMI_COMPATIBLE_G12A)) {
+ writel(data, hdmi->ioaddr +
+ HDMITX_TOP_G12A_OFFSET + (addr << 2));
+ return;
+ }
+
/* ADDR must be written twice */
writel(addr & 0x, hdmi->ioaddr + HDMITX_TOP_ADDR_REG);
writel(addr & 0x, hdmi->ioaddr + HDMITX_TOP_ADDR_REG);
@@ -237,7 +256,7 @@ static void meson_dw_hdmi_phy_setup_mode(struct
meson_dw_hdmi *priv,
hhi_write(HHI_HDMI_PHY_CNTL0, 0x33604142);
hhi_write(HHI_HDMI_PHY_CNTL3, 0x0016315b);
}
- } else {
+ } else if (meson_hdmi_is_compatible(priv, HDMI_COMPATIBLE_GXBB)) {
if (pixel_clock >= 371250) {
/* 5.94Gbps, 3.7125Gbps */
hhi_write(HHI_HDMI_PHY_CNTL0, 0x33353245);
@@ -251,6 +270,23 @@ static void meson_dw_hdmi_phy_setup_mode(struct
meson_dw_hdmi *priv,
hhi_write(HHI_HDMI_PHY_CNTL0, 0x33632122);
hhi_write(HHI_HDMI_PHY_CNTL3, 0x2000115b);
}
+ } else if (meson_hdmi_is_compatible(priv, HDMI_COMPATIBLE_G12A)) {
+ if (pixel_clock >= 371250) {
+ /* 5.94Gbps, 3.7125Gbps */
+ hhi_write(HHI_HDMI_PHY_CNTL0, 0x37eb65c4);
+ hhi_write(HHI_HDMI_PHY_CNTL
Re: [U-Boot] [PATCH] pico-imx7d: Convert to DM_VIDEO
HI Peng,
I send v2 with your suggest
Best Regards,
Joris Offouga
Le 29/08/2019 à 11:35, Peng Fan a écrit :
Subject: [PATCH] pico-imx7d: Convert to DM_VIDEO
Please write something here.
And use x-u-boot.dtsi for uboot specific dts change.
Regards,
Peng.
Signed-off-by: Joris Offouga
---
arch/arm/dts/imx7d-pico.dtsi | 113
++-
board/technexion/pico-imx7d/pico-imx7d.c | 48 --
configs/pico-hobbit-imx7d_defconfig | 2 +-
configs/pico-imx7d_bl33_defconfig| 2 +-
configs/pico-imx7d_defconfig | 2 +-
configs/pico-pi-imx7d_defconfig | 2 +-
include/configs/pico-imx7d.h | 2 +-
7 files changed, 134 insertions(+), 37 deletions(-)
diff --git a/arch/arm/dts/imx7d-pico.dtsi b/arch/arm/dts/imx7d-pico.dtsi
index 7cd8be24c8..ac72baf347 100644
--- a/arch/arm/dts/imx7d-pico.dtsi
+++ b/arch/arm/dts/imx7d-pico.dtsi
@@ -11,6 +11,7 @@
aliases {
mmc0 = &usdhc3;
usb0 = &usbotg1;
+ display0 = &lcdif;
};
/* Will be filled by the bootloader */ @@ -75,6 +76,37 @@
clocks = <&clks IMX7D_CLKO2_ROOT_DIV>;
clock-names = "ext_clock";
};
+
+ backlight: backlight {
+ compatible = "pwm-backlight";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_backlight>;
+ pwms = <&pwm4 0 5 0>;
+ brightness-levels = <0 36 72 108 144 180 216 255>;
+ default-brightness-level = <6>;
+ status = "okay";
+ };
+
+ reg_lcd_3v3: regulator-lcd-3v3 {
+ compatible = "regulator-fixed";
+ regulator-name = "lcd-3v3";
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ gpio = <&gpio1 6 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
+
+ panel {
+ compatible = "vxt,vl050-8048nt-c01";
+ backlight = <&backlight>;
+ power-supply = <®_lcd_3v3>;
+
+ port {
+ panel_in: endpoint {
+ remote-endpoint = <&display_out>;
+ };
+ };
+ };
};
&clks {
@@ -98,7 +130,7 @@
<&clks IMX7D_ENET1_TIME_ROOT_CLK>;
assigned-clock-parents = <&clks IMX7D_PLL_ENET_MAIN_100M_CLK>;
assigned-clock-rates = <0>, <1>;
- phy-mode = "rgmii";
+ phy-mode = "rgmii-id";
phy-handle = <ðphy0>;
fsl,magic-packet;
phy-reset-gpios = <&gpio6 11 GPIO_ACTIVE_LOW>; @@ -236,6 +268,45
@@
};
};
+&lcdif {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_lcdif>;
+ status = "okay";
+ display = <&display0>;
+ u-boot,dm-pre-reloc;
+
+ port {
+ display_out: endpoint {
+ remote-endpoint = <&panel_in>;
+ };
+ };
+
+ display0: display {
+ bits-per-pixel = <16>;
+ bus-width = <24>;
+
+ display-timings {
+ native-mode = <&timing0>;
+ timing0: timing0 {
+ clock-frequency = <3326>;
+ hactive = <800>;
+ vactive = <480>;
+ hback-porch = <11>;
+ hfront-porch = <11>;
+ vback-porch = <12>;
+ vfront-porch = <11>;
+ hsync-len = <46>;
+ vsync-len = <210>;
+ hsync-active = <0>;
+ vsync-active = <0>;
+ de-active = <1>;
+ pixelclk-active = <1>;
+ interlaced = <0>;
+ };
+ };
+ };
+};
+
&sai1 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_sai1>;
@@ -356,6 +427,12 @@
};
&iomuxc {
+ pinctrl_backlight: backlight {
+ fsl,pins = <
+ MX7D_PAD_GPIO1_IO11__PWM4_OUT 0x0
+ >;
+ };
+
pinctrl_ecspi3: ecspi3grp {
fsl,pins = <
MX7D_PAD_I2C1_SCL__ECSPI3_MISO 0x2
@@ -420,6 +497,40 @@
>;
};
+ pinctrl_lcdif: lcdifgrp {
+ fsl,pins = <
+ MX7D_PAD_LCD_DATA00__LCD_DATA0 0x79
+ MX7D_PAD_LCD_DATA01__LCD_DATA1 0x79
+ MX7D_PAD_LCD_DATA02__LCD_DATA2 0x79
+ MX7D_PAD_LCD_DATA03__LCD_DATA3 0x79
+ MX7D_PAD_LCD_DATA04__LCD_DATA4 0x79
+ MX7D_PAD_LCD_DATA05__LCD
[U-Boot] USB failure on i.MX7 based module with v2019.07
Hi Marek, I have ported u-boot v2019.07 to our i.MX7 base custom board. When testing, I found that 'usb start' command results in board reset due to data abort exception. Our board has usbotg1, usbotg2 and usbh ports enabled. It works fine with older u-boot versions. I did some investigation and found that the reason is based on index calculation of USB ports introduced with your commit 501547cec1f7f0438cae388a104ff60f18576c01. Here, 'address' and 'size' parameters of the USB controller 'reg' property in the device tree is used to calculate USB port/index number. Because controller register spacing is 0x1 on i.MX7 and device tree 'size' entry is 0x200, this calculation results in 0, 128 and 256 as port numbers leading to driver crash later on. My first idea was to modify the device tree nodes and actually USB works fine on my board when setting the size parameter to 0x1. Thus I wanted to push this upstream , but after some discussion on linux-arm-kernel list (see https://patchwork.kernel.org/patch/11121805/), I think that this would be the wrong solution. So, do you have another idea how to fix this issue? Best regards, Thomas Thomas Schäfer SW Design Engineer Kontron - An S&T Company Heinrich-Barth-Straße 1-1a | 66115 Saarbrücken | Germany P: +49 681 95916 203 thomas.schae...@kontron.com Website | Blog | Twitter | LinkedIn | YouTube | Facebook Kontron Europe GmbH Die gesetzlichen Pflichtangaben finden Sie hier. Please find our mandatory legal statements here. Mit dem Öffnen dieses E-Mails stimmen Sie Kontrons Richtlinien zur elektronischen Kommunikation zu. By opening this email you are agreeing to Kontron's Electronic Communications Policy. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH V2 1/3] ARM: dts: pico-imx7d: Add u-boot.dtsi for uboot specific dts change
This commit introduce u-boot.dtsi
Signed-off-by: Joris Offouga
Suggested-by: Peng Fan
---
arch/arm/dts/imx7d-pico-u-boot.dtsi | 11 +++
arch/arm/dts/imx7d-pico.dtsi| 8 +---
2 files changed, 12 insertions(+), 7 deletions(-)
create mode 100644 arch/arm/dts/imx7d-pico-u-boot.dtsi
diff --git a/arch/arm/dts/imx7d-pico-u-boot.dtsi
b/arch/arm/dts/imx7d-pico-u-boot.dtsi
new file mode 100644
index 00..1bd7f4f102
--- /dev/null
+++ b/arch/arm/dts/imx7d-pico-u-boot.dtsi
@@ -0,0 +1,11 @@
+/{
+aliases {
+mmc0 = &usdhc3;
+usb0 = &usbotg1;
+};
+};
+
+&usbotg1 {
+ dr_mode = "peripheral";
+ };
+
diff --git a/arch/arm/dts/imx7d-pico.dtsi b/arch/arm/dts/imx7d-pico.dtsi
index 7cd8be24c8..33b308ac24 100644
--- a/arch/arm/dts/imx7d-pico.dtsi
+++ b/arch/arm/dts/imx7d-pico.dtsi
@@ -5,14 +5,9 @@
/dts-v1/;
#include "imx7d.dtsi"
-
+#include "imx7d-pico-u-boot.dtsi"
/ {
- aliases {
- mmc0 = &usdhc3;
- usb0 = &usbotg1;
- };
-
/* Will be filled by the bootloader */
memory@8000 {
device_type = "memory";
@@ -297,7 +292,6 @@
&usbotg1 {
vbus-supply = <®_usb_otg1_vbus>;
- dr_mode = "peripheral";
status = "okay";
};
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH V2 3/3] configs: pico-imx7d: Convert to DM_VIDEO
This commit convert all pico-imx7d to DM_VIDEO
Signed-off-by: Joris Offouga
---
arch/arm/dts/imx7d-pico-u-boot.dtsi | 113 +++
board/technexion/pico-imx7d/pico-imx7d.c | 48 --
configs/pico-hobbit-imx7d_defconfig | 2 +-
configs/pico-imx7d_bl33_defconfig| 2 +-
configs/pico-imx7d_defconfig | 2 +-
configs/pico-pi-imx7d_defconfig | 2 +-
include/configs/pico-imx7d.h | 2 +-
7 files changed, 135 insertions(+), 36 deletions(-)
diff --git a/arch/arm/dts/imx7d-pico-u-boot.dtsi
b/arch/arm/dts/imx7d-pico-u-boot.dtsi
index 1bd7f4f102..ef19de2b30 100644
--- a/arch/arm/dts/imx7d-pico-u-boot.dtsi
+++ b/arch/arm/dts/imx7d-pico-u-boot.dtsi
@@ -2,10 +2,123 @@
aliases {
mmc0 = &usdhc3;
usb0 = &usbotg1;
+display0 = &lcdif;
};
+
+ backlight: backlight {
+ compatible = "pwm-backlight";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_backlight>;
+ pwms = <&pwm4 0 5 0>;
+ brightness-levels = <0 36 72 108 144 180 216 255>;
+ default-brightness-level = <6>;
+ status = "okay";
+ };
+
+ reg_lcd_3v3: regulator-lcd-3v3 {
+ compatible = "regulator-fixed";
+ regulator-name = "lcd-3v3";
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ gpio = <&gpio1 6 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
+
+ panel {
+ compatible = "vxt,vl050-8048nt-c01";
+ backlight = <&backlight>;
+ power-supply = <®_lcd_3v3>;
+
+ port {
+ panel_in: endpoint {
+ remote-endpoint = <&display_out>;
+ };
+ };
+ };
};
&usbotg1 {
dr_mode = "peripheral";
};
+&lcdif {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_lcdif>;
+ status = "okay";
+ display = <&display0>;
+ u-boot,dm-pre-reloc;
+
+ port {
+ display_out: endpoint {
+ remote-endpoint = <&panel_in>;
+ };
+ };
+
+ display0: display {
+ bits-per-pixel = <16>;
+ bus-width = <24>;
+
+ display-timings {
+ native-mode = <&timing0>;
+ timing0: timing0 {
+ clock-frequency = <3326>;
+ hactive = <800>;
+ vactive = <480>;
+ hback-porch = <11>;
+ hfront-porch = <11>;
+ vback-porch = <12>;
+ vfront-porch = <11>;
+ hsync-len = <46>;
+ vsync-len = <210>;
+ hsync-active = <0>;
+ vsync-active = <0>;
+ de-active = <1>;
+ pixelclk-active = <1>;
+ interlaced = <0>;
+ };
+ };
+ };
+};
+
+&iomuxc {
+ pinctrl_backlight: backlight {
+ fsl,pins = <
+ MX7D_PAD_GPIO1_IO11__PWM4_OUT 0x0
+ >;
+ };
+
+ pinctrl_lcdif: lcdifgrp {
+ fsl,pins = <
+ MX7D_PAD_LCD_DATA00__LCD_DATA0 0x79
+ MX7D_PAD_LCD_DATA01__LCD_DATA1 0x79
+ MX7D_PAD_LCD_DATA02__LCD_DATA2 0x79
+ MX7D_PAD_LCD_DATA03__LCD_DATA3 0x79
+ MX7D_PAD_LCD_DATA04__LCD_DATA4 0x79
+ MX7D_PAD_LCD_DATA05__LCD_DATA5 0x79
+ MX7D_PAD_LCD_DATA06__LCD_DATA6 0x79
+ MX7D_PAD_LCD_DATA07__LCD_DATA7 0x79
+ MX7D_PAD_LCD_DATA08__LCD_DATA8 0x79
+ MX7D_PAD_LCD_DATA09__LCD_DATA9 0x79
+ MX7D_PAD_LCD_DATA10__LCD_DATA10 0x79
+ MX7D_PAD_LCD_DATA11__LCD_DATA11 0x79
+ MX7D_PAD_LCD_DATA12__LCD_DATA12 0x79
+ MX7D_PAD_LCD_DATA13__LCD_DATA13 0x79
+ MX7D_PAD_LCD_DATA14__LCD_DATA14 0x79
+ MX7D_PAD_LCD_DATA15__LCD_DATA15 0x79
+ MX7D_PAD_LCD_DATA16__LCD_DATA16 0x79
+ MX7D_PAD_LCD_DATA17__LCD_DATA17 0x79
+ MX7D_PAD_LCD_DATA18__LCD_DATA18 0x79
+ MX7D_PAD_LCD_DATA19__LCD_DATA19 0x79
+ MX7D_PAD_LCD_DATA20__LCD_DATA20 0x79
+
[U-Boot] [PATCH V2 2/3] ARM: dts: pico-imx7d: sync device tree with v5.3-rc6
Synchronize device tree with v5.3-rc6 label Signed-off-by: Joris Offouga --- arch/arm/dts/imx7d-pico.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/dts/imx7d-pico.dtsi b/arch/arm/dts/imx7d-pico.dtsi index 33b308ac24..57391fc052 100644 --- a/arch/arm/dts/imx7d-pico.dtsi +++ b/arch/arm/dts/imx7d-pico.dtsi @@ -93,7 +93,7 @@ <&clks IMX7D_ENET1_TIME_ROOT_CLK>; assigned-clock-parents = <&clks IMX7D_PLL_ENET_MAIN_100M_CLK>; assigned-clock-rates = <0>, <1>; - phy-mode = "rgmii"; + phy-mode = "rgmii-id"; phy-handle = <ðphy0>; fsl,magic-packet; phy-reset-gpios = <&gpio6 11 GPIO_ACTIVE_LOW>; -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] scrapyard: Delete this file and script
On Fri, Aug 30, 2019 at 11:03:22AM +0200, Wolfgang Denk wrote: > Dear Tom, > > In message <1567099239-28108-1-git-send-email-tr...@konsulko.com> you wrote: > > The README.scrapyard file has been inconsistently updated. While well > > intentioned, bad data is worse than no data, and in this case a pointer > > to use the history that git provides. Remove the current content and > > the script that would update it from time to time as well. > > Should we not also provide some hints how a user (which eventually > limited experience in git) can actually find such information? > > I would appreciate if we could provide examples at least for the > trivial case where is is looking for some specific board(s) well > known to him; maybe also for searching for things like removal of a > specific CPU (say, PPC405GP) or CPU falimy. An example of using git log -- removed/path/ isn't a bad idea. > And instead of removing the scripts/fill_scrapyard.py script, > should we not rather modify it to generate a list of (all) removed > boards - that would be really helpful, I think ? The problem is that it's a python 2 script. Python 2 is dead as of Jan 1, 2020 and distributions aren't going to be shipping an interpreter for it. So if we have some new tool for history digging, I'd rather see something new written. Personally when I need to dig through stuff I just do 'git log -p' and search. Even if it goes all the way back to the initial commit. -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: exynos5: Try to boot on mmc2 before mmc0/1
Hi, I got no feedback on this patch. Is there anything blocking it? Guillaume > -Original Message- > From: Guillaume GARDET > Sent: 24 July 2019 09:10 > To: u-boot@lists.denx.de > Cc: Guillaume Gardet ; Lukasz Majewski > ; Anand Moon ; Simon Glass > ; Minkyu Kang > Subject: [U-Boot] [PATCH] ARM: exynos5: Try to boot on mmc2 before > mmc0/1 > > As stated in commit a61a4a1db009e3e600258551a01b54c4f50ec103 with > DM_MMC, exynos boards now enumarates external SD/MMC slot as mmc2, > instead of mmc1 with legacy mode. Moving mmc2 before mmc1/0 restore > the previous behavior of trying external SD/MMC before internal slot. > > Signed-off-by: Guillaume GARDET > > Cc: Lukasz Majewski > Cc: Anand Moon > Cc: Simon Glass > Cc: Minkyu Kang > > --- > include/configs/exynos5-common.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/include/configs/exynos5-common.h b/include/configs/exynos5- > common.h > index 397bbf6d9d..e0a4d76d53 100644 > --- a/include/configs/exynos5-common.h > +++ b/include/configs/exynos5-common.h > @@ -128,9 +128,9 @@ > #define EXYNOS_IRAM_SECONDARY_BASE 0x02020018 > > #define BOOT_TARGET_DEVICES(func) \ > + func(MMC, mmc, 2) \ > func(MMC, mmc, 1) \ > func(MMC, mmc, 0) \ > - func(MMC, mmc, 2) \ > func(PXE, pxe, na) \ > func(DHCP, dhcp, na) > > -- > 2.22.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] mmc: dw_mmc: fix timeout calculate method
Hi Kever, [snip] > I think this tree does not including this patch, Peng drop it because of > this issue, > so you need to apply this patch in your branch to reproduce the problem. > I have send out V2 patch for this fix with only using 32bit variable Could you please refer me to the problematic patch so I may try it? -Alexey ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/8] ARM: bcm283x: Add BCM283x_BASE define
On 26/07/2019 14:43, Andrei Gherzan wrote: > Hi, > > On 26/07/2019 13.04, Alexander Graf wrote: >> >> >> On 26.07.19 13:55, Matthias Brugger wrote: >>> >>> >>> On 26/07/2019 13:16, Alexander Graf wrote: On 24.07.19 16:39, Andrei Gherzan wrote: > From: Matthias Brugger > > Devices of bcm283x have different base address, depending if they > are on > bcm2835 or bcm2836/7. Use BCM283x_BASE depending on the SoC you > want to > build and only add the offset in the header files. > > Signed-off-by: Matthias Brugger > Signed-off-by: Andrei Gherzan > --- > arch/arm/mach-bcm283x/Kconfig | 5 + > arch/arm/mach-bcm283x/include/mach/mbox.h | 6 +- > arch/arm/mach-bcm283x/include/mach/sdhci.h | 6 +- > arch/arm/mach-bcm283x/include/mach/timer.h | 6 +- > arch/arm/mach-bcm283x/include/mach/wdog.h | 6 +- > 5 files changed, 9 insertions(+), 20 deletions(-) > > diff --git a/arch/arm/mach-bcm283x/Kconfig > b/arch/arm/mach-bcm283x/Kconfig > index 3eb5a9a897..8e69914a83 100644 > --- a/arch/arm/mach-bcm283x/Kconfig > +++ b/arch/arm/mach-bcm283x/Kconfig > @@ -141,4 +141,9 @@ config SYS_SOC > config SYS_CONFIG_NAME > default "rpi" > +config BCM283x_BASE > + hex > + default "0x2000" if BCM2835 > + default "0x3f00" if BCM2836 || BCM2837 How hard would it be to make the base a global variable instead and just set it early on board init based on the FDT or maybe even CPU core revision registers? >>> >>> Might be possible. Candidates to implement this are >>> board_early_init_f or >>> misc_init_f, I think. >>> That would allow us to support RPi3 & 4 with the same U-Boot binary. >>> >>> Good point :) >> >> Yeah, then you only need to do the memory map dynamically as well and >> the rest should all be handled by DT :). Which again means you don't >> need a new config target at all! > I like that. It will bring a little confusion though when using a rpi3 > defconfig for rpi4. I guess we could just copy it. > I have a working POC of this feature, but it needs more time. I propose to merge RPi4 support now, so that it can get accepted for v2019.10. Afterwards we can implement a unified u-boot binary for RPi[34] and maybe even RPi[12] in the future. If nobody shouts I'll merge this series fixing the two comments I had. Please let me know if you disagree. Regards, Matthias ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: exynos5: Try to boot on mmc2 before mmc0/1
On Fri, Aug 30, 2019 at 4:20 PM Guillaume Gardet wrote: > > Hi, > > I got no feedback on this patch. Is there anything blocking it? > > Guillaume > > > > -Original Message- > > From: Guillaume GARDET > > Sent: 24 July 2019 09:10 > > To: u-boot@lists.denx.de > > Cc: Guillaume Gardet ; Lukasz Majewski > > ; Anand Moon ; Simon Glass > > ; Minkyu Kang > > Subject: [U-Boot] [PATCH] ARM: exynos5: Try to boot on mmc2 before > > mmc0/1 > > > > As stated in commit a61a4a1db009e3e600258551a01b54c4f50ec103 with > > DM_MMC, exynos boards now enumarates external SD/MMC slot as mmc2, > > instead of mmc1 with legacy mode. Moving mmc2 before mmc1/0 restore > > the previous behavior of trying external SD/MMC before internal slot. > > > > Signed-off-by: Guillaume GARDET Reviewed-by: Oleksandr Suvorov > > > > Cc: Lukasz Majewski > > Cc: Anand Moon > > Cc: Simon Glass > > Cc: Minkyu Kang > > > > --- > > include/configs/exynos5-common.h | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/include/configs/exynos5-common.h b/include/configs/exynos5- > > common.h > > index 397bbf6d9d..e0a4d76d53 100644 > > --- a/include/configs/exynos5-common.h > > +++ b/include/configs/exynos5-common.h > > @@ -128,9 +128,9 @@ > > #define EXYNOS_IRAM_SECONDARY_BASE 0x02020018 > > > > #define BOOT_TARGET_DEVICES(func) \ > > + func(MMC, mmc, 2) \ > > func(MMC, mmc, 1) \ > > func(MMC, mmc, 0) \ > > - func(MMC, mmc, 2) \ > > func(PXE, pxe, na) \ > > func(DHCP, dhcp, na) > > > > -- > > 2.22.0 > > ___ > U-Boot mailing list > U-Boot@lists.denx.de > https://lists.denx.de/listinfo/u-boot -- Best regards Oleksandr Suvorov cryo...@gmail.com ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] Fix unreliable detection of DRAM size on Orange Pi 3
On Fri, 30 Aug 2019 12:56:28 +0200
Ondřej Jirman wrote:
Hi Ondřej,
> Hello,
>
> On Fri, Aug 30, 2019 at 01:44:34AM +0100, André Przywara wrote:
> > On 25/08/2019 15:41, Siarhei Siamashka wrote:
> > > On Sat, 24 Aug 2019 22:07:43 +0200
> > > Ondřej Jirman wrote:
> >
> > Hi,
> >
> > >> Hi Jagan,
> > >>
> > >> can you please apply this patch to the sunxi tree, so that it
> > >> doesn't get lost.
> > >>
> > >> thank you,
> > >> Ondrej
> > >>
> > >> On Mon, Jul 29, 2019 at 01:39:42AM +0200, megous hlavni wrote:
> > >>> From: Ondrej Jirman
> > >>>
> > >>> Orange Pi 3 has 2 GiB of DRAM, that sometime get misdetected
> > >>> as 4 GiB, due to false negative result from mctl_mem_matches()
> > >>> when detecting number of column address bits. This leads to
> > >>> u-boot detecting more address bits than there are and the
> > >>> boot process hangs shortly after.
> > >>>
> > >>> In mctl_mem_matches() we need to wait for each write to finish,
> > >>> separately. Without this, the check is not reliable for some
> > >>> unknown reason, probably having to do with unpredictable memory
> > >>> access ordering.
> > >>>
> > >>> Patch was made with help from André Przywara, who noticed that
> > >>> my original idea about detection failing due to read-back from
> > >>> cache without involving DRAM was false, because data cache is
> > >>> still of at the time of the DRAM size autodetection.
> > >>>
> > >>> Signed-off-by: Ondrej Jirman
> > >>> Cc: André Przywara
> > >>> ---
> > >>> arch/arm/mach-sunxi/dram_helpers.c | 1 +
> > >>> 1 file changed, 1 insertion(+)
> > >>>
> > >>> diff --git a/arch/arm/mach-sunxi/dram_helpers.c
> > >>> b/arch/arm/mach-sunxi/dram_helpers.c
> > >>> index 239ab421a8..6dba448638 100644
> > >>> --- a/arch/arm/mach-sunxi/dram_helpers.c
> > >>> +++ b/arch/arm/mach-sunxi/dram_helpers.c
> > >>> @@ -30,6 +30,7 @@ bool mctl_mem_matches(u32 offset)
> > >>> {
> > >>> /* Try to write different values to RAM at two addresses */
> > >>> writel(0, CONFIG_SYS_SDRAM_BASE);
> > >>> + dsb();
> > >>> writel(0xaa55aa55, (ulong)CONFIG_SYS_SDRAM_BASE + offset);
> > >>> dsb();
> > >>> /* Check if the same value is actually observed when reading
> > >>> back */
> > >>> --
> > >
> > > Hi!
> > >
> > > This looks like resurfacing of the old problem, which did not get a
> > > complete fix back in 2016:
> > >https://lists.denx.de/pipermail/u-boot/2016-April/251803.html
> > >
> > > Now the main question is whether the DSB instruction's barrier
> > > magic is really required here or maybe it's just a timing issue.
> >
> > I think both:
> > From the compiler's and the CPU's point of view these two stores look
> > independent: they don't have any data dependency and go to different
> > addresses. So both the compiler and the CPU are allowed to reorder these
> > stores. However, we are after some non-obvious aliasing effect, so in
> > fact there *is* a dependency between the two stores. So architecturally
> > this barrier is definitely required, to notify everyone about this
> > dependency (although I think a dmb(); might be sufficient here).
>
> OTOH, let's visualize it:
>
> CPU address DRAM address
> ---
> [w ] SDRAM_BASE 0
> [w aa55aa55] SDRAM_BASE + offset0
>
> Both writes should end up at the same physical location in dram).
>
> The following test checks that values that are read back are the same. They
> should be the same in this specific case of Opi3 SBC. It doesn't check for any
> specific value, so even if writes are re-ordered, the value that's read back
> should still be the same.
Ah, right. I was actually staring at my modified code, where I try to detect
half DQ problems with some weird 3GB setup on the Eachlink H6 Mini. So I
explicitly check for and compare to the second value written, and expect this
write to have overwritten the first 0 write.
> Order of operations is:
>
> writel(0, CONFIG_SYS_SDRAM_BASE);
> writel(0xaa55aa55, (ulong)CONFIG_SYS_SDRAM_BASE + offset);
> dsb();
From all I can see this means at this point the two writes are "on the bus"
("completed" from the CPU's point of view).
> readl(CONFIG_SYS_SDRAM_BASE)
This should actually push the first write to the device, as a read following a
write to the same address requires the write to take effect first. Might still
end up in a write buffer in the DRAM controller, though.
> readl((ulong)CONFIG_SYS_SDRAM_BASE + offset);
>
> The CPU can only re-order either the writes or reads. But neither should
> matter.
Yes, true, for the existing code (which compares the two reads against each
other).
> Memory controller is a black box to me and that's where the issue probably
> lies.
Yes, the plot thickens. Maybe the DRAM controller buffers the write request(s),
as it waits for the page(s) to open in the chips, for instance. Now the reads
Re: [U-Boot] [PATCH 1/1] x86: efi_loader: Fix invalid address return from efi_alloc()
Hi Bin,
> -Original Message-
> From: Bin Meng [mailto:bmeng...@gmail.com]
> Sent: Friday, August 30, 2019 12:22 AM
> To: Park, Aiden
> Cc: Heinrich Schuchardt ; Simon Glass
> ; u-boot@lists.denx.de; Alexander Graf
>
> Subject: Re: [PATCH 1/1] x86: efi_loader: Fix invalid address return from
> efi_alloc()
>
> Hi Aiden,
>
> On Fri, Aug 30, 2019 at 5:31 AM Park, Aiden wrote:
> >
> > Hi Heinrich and Bin,
> >
> > > -Original Message-
> > > From: Heinrich Schuchardt [mailto:xypron.g...@gmx.de]
> > > Sent: Wednesday, August 28, 2019 10:16 PM
> > > To: Bin Meng ; Park, Aiden
> > >
> > > Cc: Simon Glass ; u-boot@lists.denx.de; Alexander
> > > Graf
> > > Subject: Re: [PATCH 1/1] x86: efi_loader: Fix invalid address return
> > > from
> > > efi_alloc()
> > >
> > > On 8/29/19 5:36 AM, Bin Meng wrote:
> > > > +Heinrich,
> > > >
> > > > On Wed, Aug 28, 2019 at 2:35 AM Park, Aiden
> wrote:
> > > >>
> > > >> This issue can be seen on 32bit operation when one of E820_RAM
> > > >> type entries is greater than 4GB memory space.
> > > >>
> > > >> The efi_alloc() finds a free memory in the conventional memory
> > > >> which is greater than 4GB. But, it does type cast to 32bit
> > > >> address space and eventually returns invalid address.
> > > >>
> > > >> Signed-off-by: Aiden Park
> > > >> ---
> > > >> arch/x86/lib/e820.c | 22 +-
> > > >> 1 file changed, 21 insertions(+), 1 deletion(-)
> > > >>
> > > >> diff --git a/arch/x86/lib/e820.c b/arch/x86/lib/e820.c index
> > > >> d6ae2c4e9d..3e93931231 100644
> > > >> --- a/arch/x86/lib/e820.c
> > > >> +++ b/arch/x86/lib/e820.c
> > > >> @@ -41,11 +41,15 @@ void efi_add_known_memory(void)
> > > >> {
> > > >> struct e820_entry e820[E820MAX];
> > > >> unsigned int i, num;
> > > >> - u64 start, pages;
> > > >> + u64 start, pages, ram_top;
> > > >> int type;
> > > >>
> > > >> num = install_e820_map(ARRAY_SIZE(e820), e820);
> > > >>
> > > >> + ram_top = (u64)gd->ram_top & ~EFI_PAGE_MASK;
> > > >> + if (!ram_top)
> > > >
> > > > So for the logic here to work, gd->ram_top is already zero in
> > > > 32-bit, right? I was wondering how U-Boot could boot on such target?
> > >
> > > If in 32bit mode RAM addresses up to 2^32-1 are available,
> > > gd->ram_top is 0 due to overflow.
> > >
> > > >
> > > >> + ram_top = 0x1ULL;
> > >
> > > In this special case we correct the value to 4GB.
> > >
> > > >> +
> > > >> for (i = 0; i < num; ++i) {
> > > >> start = e820[i].addr;
> > > >> pages = ALIGN(e820[i].size, EFI_PAGE_SIZE) >>
> > > >> EFI_PAGE_SHIFT; @@ -70,6 +74,22 @@ void
> efi_add_known_memory(void)
> > > >> }
> > > >>
> > > >> efi_add_memory_map(start, pages, type, false);
> > > >> +
> > > >> + if (type == EFI_CONVENTIONAL_MEMORY) {
> > > >> + u64 end = start + (pages <<
> > > >> + EFI_PAGE_SHIFT);
> > > >> +
> > > >> + /* reserve the memory region greater than
> > > >> ram_top */
> > > >> + if (ram_top < start) {
> > > >> + efi_add_memory_map(start, pages,
> > > >> +
> > > >> EFI_BOOT_SERVICES_DATA,
> > > >> + true);
> > > >
> > > > Heinrich, could you please review the changes here?
> > >
> > > These lines are verbatim copies of what we have in
> lib/efi_loader/efi_memory.c.
> > > Function wise this is ok.
> > >
> > > But this creates code duplication. Most of what is in this loop and
> > > in the loop in lib/efi_loader/efi_memory.c (starting at /* Remove
> > > partial pages */) could be put into a separate common function.
> > >
> > > Aiden, do you want to give a try?
> > >
> > I have a quick question here. Do we really need to override
> > efi_add_known_memory() in arch/x86/lib/e820.c?
> > I think the original weak function would be okay for x86 arch as well.
> >
>
> Yep, I see the generic one provided by the EFI loader is using
> gd->bd->bi_dram[i] to populate the EFI memory. The only handles
> EFI_CONVENTIONAL_MEMORY, but for x86, it may have
> EFI_ACPI_RECLAIM_MEMORY and EFI_ACPI_MEMORY_NVS which
> gd->bd->bi_dram[i] does not distinguish normal memory usage and these
> special ones. Hence I think we still need the x86 specific one.
>
Yeah Right. The regions can be corrupted as those can be reported as
conventional memory
even if efi_loader does not use those memory types. Thanks for clarification.
> But as Heinrich mentioned, there might be some room to refactor the codes
> a little bit to share as much common parts as possible.
>
Let me refactor the common part. Thanks.
> Regards,
> Bin
Best Regards,
Aiden
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] mx53loco: Fix U-Boot corruption after saving the environment
U-Boot binary has grown in such a way that it goes beyond the reserved area for the environment variables. Running "saveenv" causes U-Boot to hang because of this overlap. Fix this problem by increasing the CONFIG_ENV_OFFSET size. Also, in order to prevent this same problem in the future, use CONFIG_BOARD_SIZE_LIMIT, which will detect the overlap in build-time. CONFIG_BOARD_SIZE_LIMIT does not accept math expressions, so declare CONFIG_ENV_OFFSET with its direct value instead. Signed-off-by: Fabio Estevam --- include/configs/mx53loco.h | 14 -- 1 file changed, 12 insertions(+), 2 deletions(-) diff --git a/include/configs/mx53loco.h b/include/configs/mx53loco.h index b734b822dd..65a5993f61 100644 --- a/include/configs/mx53loco.h +++ b/include/configs/mx53loco.h @@ -163,8 +163,18 @@ #define CONFIG_SYS_INIT_SP_ADDR \ (CONFIG_SYS_INIT_RAM_ADDR + CONFIG_SYS_INIT_SP_OFFSET) -/* environment organization */ -#define CONFIG_ENV_OFFSET (6 * 64 * 1024) +/* Environment starts at 768k = 768 * 1024 = 786432 */ +#define CONFIG_ENV_OFFSET 786432 +/* + * Detect overlap between U-Boot image and environment area in build-time + * + * CONFIG_BOARD_SIZE_LIMIT = CONFIG_ENV_OFFSET - u-boot.imx offset + * CONFIG_BOARD_SIZE_LIMIT = 768k - 1k = 767k = 785408 + * + * Currently CONFIG_BOARD_SIZE_LIMIT does not handle expressions, so + * write the direct value here + */ +#define CONFIG_BOARD_SIZE_LIMIT785408 #define CONFIG_ENV_SIZE(8 * 1024) #define CONFIG_SYS_MMC_ENV_DEV 0 -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [BUG] include/net.h: warning: 'eth_is_on_demand_init' defined but not used
Hello Joe, compiling U-Boot creates dozens of warnings for include/net.h: CC arch/arm/lib/asm-offsets.s In file included from include/common.h:342, from lib/asm-offsets.c:14: include/net.h:689:28: warning: always_inline function might not be inlinable [-Wattributes] 689 | static __always_inline int eth_is_on_demand_init(void) |^ include/net.h:689:28: warning: 'eth_is_on_demand_init' defined but not used [-Wunused-function] HOSTCC scripts/dtc/srcpos.o In file included from include/common.h:342, from arch/arm/lib/asm-offsets.c:14: include/net.h:689:28: warning: always_inline function might not be inlinable [-Wattributes] 689 | static __always_inline int eth_is_on_demand_init(void) |^ include/net.h:689:28: warning: 'eth_is_on_demand_init' defined but not used [-Wunused-function] Software used for building U-Boot: U-Boot HEAD, rpi_3_b_plus_defconfig gcc (FreeBSD Ports Collection) 9.1.0 FreeBSD generic 13.0-CURRENT FreeBSD 13.0-CURRENT r351591 GENERIC arm64 Why should we create this function in every file that by chance includes net.h? The function is only used in drivers/net/netconsole.c and net/net.c. One solution would be to create a dedicated include that is only referenced in these two files. Best regards Heinrich ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v1] common: fix building image.c
On Tue, Aug 20, 2019 at 11:09 AM Igor Opaniuk wrote:
>
> From: Igor Opaniuk
>
> Wrap image_decomp() and all dependent functions with
> !ifdef(USE_HOSTCC) macro, as this function isn't used by
> any tool from /tools.
>
> Without this it leads to compilation issues (because of
> CONFIG_LZMA from newly added #include
> statement, which pulls all these definitions):
>
> In file included from tools/common/image.c:1:0:
> ./tools/../common/image.c: In function ‘image_decomp’:
> ./tools/../common/image.c:428:9: warning: implicit declaration of function
> ‘gunzip’; did you mean ‘munmap’? [-Wimplicit-function-declaration]
>ret = gunzip(load_buf, unc_len, image_buf, &image_len);
> ^~
> munmap
> ./tools/../common/image.c:450:3: error: unknown type name ‘SizeT’;
> did you mean ‘size_t’?
>SizeT lzma_len = unc_len;
>^
>size_t
> ./tools/../common/image.c:452:9: warning: implicit declaration of function
> ‘lzmaBuffToBuffDecompress’ [-Wimplicit-function-declaration]
>ret = lzmaBuffToBuffDecompress(load_buf, &lzma_len,
> ^~~~
> scripts/Makefile.host:114: recipe for target 'tools/common/image.o' failed
>
> Fixes: 2aa7f0fa51 ("habv4: tools: Avoid hardcoded CSF size for SPL target")
> Signed-off-by: Igor Opaniuk
> ---
>
> common/image-fit.c | 5 -
> common/image.c | 3 +--
> 2 files changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/common/image-fit.c b/common/image-fit.c
> index 5c63c769de..72b19f889b 100644
> --- a/common/image-fit.c
> +++ b/common/image-fit.c
> @@ -1728,6 +1728,7 @@ int fit_conf_get_prop_node(const void *fit, int noffset,
> return fit_conf_get_prop_node_index(fit, noffset, prop_name, 0);
> }
>
> +#ifndef USE_HOSTCC
> static int fit_image_select(const void *fit, int rd_noffset, int verify)
> {
> fit_image_print(fit, rd_noffset, " ");
> @@ -1743,6 +1744,7 @@ static int fit_image_select(const void *fit, int
> rd_noffset, int verify)
>
> return 0;
> }
> +#endif /* USE_HOSTCC */
This will cause the build to fail when FIT is enabled:
tools/common/bootm.o: In function `bootm_host_load_images':
bootm.c:(.text+0xb4): undefined reference to `fit_image_load'
bootm.c:(.text+0x132): undefined reference to `image_decomp'
collect2: error: ld returned 1 exit status
scripts/Makefile.host:106: recipe for target 'tools/dumpimage' failed
Guess it is better to isolate the other individual pieces instead.
Cheers,
--
Ricardo Salveti de Araujo
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] mx53loco: Fix U-Boot corruption after saving the environment
On Fri, Aug 30, 2019 at 01:58:29PM -0300, Fabio Estevam wrote: > U-Boot binary has grown in such a way that it goes beyond the reserved > area for the environment variables. > > Running "saveenv" causes U-Boot to hang because of this overlap. > > Fix this problem by increasing the CONFIG_ENV_OFFSET size. > > Also, in order to prevent this same problem in the future, use > CONFIG_BOARD_SIZE_LIMIT, which will detect the overlap in build-time. > > CONFIG_BOARD_SIZE_LIMIT does not accept math expressions, so declare > CONFIG_ENV_OFFSET with its direct value instead. > > Signed-off-by: Fabio Estevam Gah! Are there more i.mx platforms that are not setting BOARD_SIZE_LIMIT today? I assume there are, sadly. Can you audit and catch the rest of these likely problems, and add limits so we won't repeat this again. 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] scrapyard: Delete this file and script
Dear Tom, In message <20190830130330.GM26850@bill-the-cat> you wrote: > > > Should we not also provide some hints how a user (which eventually > > limited experience in git) can actually find such information? > > > > I would appreciate if we could provide examples at least for the > > trivial case where is is looking for some specific board(s) well > > known to him; maybe also for searching for things like removal of a > > specific CPU (say, PPC405GP) or CPU falimy. > > An example of using git log -- removed/path/ isn't a bad idea. Yes, please. > > And instead of removing the scripts/fill_scrapyard.py script, > > should we not rather modify it to generate a list of (all) removed > > boards - that would be really helpful, I think ? > > The problem is that it's a python 2 script. Python 2 is dead as of Jan > 1, 2020 and distributions aren't going to be shipping an interpreter for > it. So if we have some new tool for history digging, I'd rather see > something new written. Personally when I need to dig through stuff I > just do 'git log -p' and search. Even if it goes all the way back to > the initial commit. Then let's at least doument that - it's actually what I'm doing, too, but I always feel there should be better methds. This must have come up before, but I can't find anything... @all: ideas welcome ! Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Honest error is to be pitied, not ridiculed. -- Philip Earl of Chesterfield ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/2] arm: am437x: cm-t43: Add device tree, enable OF_CONTROL
From: Suniel Mahesh
Add device tree from Linux for driver model conversion
and enable OF_CONTROL. This will remove the following compile
warning:
==
Device Tree Source is not correctly specified.
Please define 'CONFIG_DEFAULT_DEVICE_TREE'
or build with 'DEVICE_TREE=' argument
===
Target was compile tested, build was clean.
Signed-off-by: Suniel Mahesh
---
arch/arm/dts/Makefile | 3 +-
arch/arm/dts/am437x-cm-t43.dts | 420 +
configs/cm_t43_defconfig | 2 +
3 files changed, 424 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/dts/am437x-cm-t43.dts
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index aac1b83..62da168 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -302,7 +302,8 @@ dtb-$(CONFIG_AM33XX) += \
dtb-$(CONFIG_AM43XX) += am437x-gp-evm.dtb am437x-sk-evm.dtb\
am43x-epos-evm.dtb \
am437x-idk-evm.dtb \
- am4372-generic.dtb
+ am4372-generic.dtb \
+ am437x-cm-t43.dtb
dtb-$(CONFIG_TARGET_AM3517_EVM) += am3517-evm.dtb
dtb-$(CONFIG_TI816X) += dm8168-evm.dtb
dtb-$(CONFIG_THUNDERX) += thunderx-88xx.dtb
diff --git a/arch/arm/dts/am437x-cm-t43.dts b/arch/arm/dts/am437x-cm-t43.dts
new file mode 100644
index 000..063113a
--- /dev/null
+++ b/arch/arm/dts/am437x-cm-t43.dts
@@ -0,0 +1,420 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (C) 2015 CompuLab, Ltd. - http://www.compulab.co.il/
+ */
+
+/dts-v1/;
+
+#include
+#include
+#include
+#include "am4372.dtsi"
+
+/ {
+ model = "CompuLab CM-T43";
+ compatible = "compulab,am437x-cm-t43", "ti,am4372", "ti,am43";
+
+ leds {
+ compatible = "gpio-leds";
+
+ ledb {
+ label = "cm-t43:green";
+ gpios = <&gpio0 24 GPIO_ACTIVE_HIGH>;
+ linux,default-trigger = "heartbeat";
+ };
+ };
+
+ vmmc_3v3: fixedregulator-v3_3 {
+ compatible = "regulator-fixed";
+ regulator-name = "vmmc_3v3";
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ regulator-always-on;
+ enable-active-high;
+ };
+};
+
+&am43xx_pinmux {
+ pinctrl-names = "default";
+ pinctrl-0 = <&cm_t43_led_pins>;
+
+ cm_t43_led_pins: cm_t43_led_pins {
+ pinctrl-single,pins = <
+ AM4372_IOPAD(0xa78, MUX_MODE7)
+ >;
+ };
+
+ i2c0_pins: i2c0_pins {
+ pinctrl-single,pins = <
+ AM4372_IOPAD(0x988, PIN_INPUT_PULLUP | SLEWCTRL_FAST |
MUX_MODE0) /* i2c0_sda.i2c0_sda */
+ AM4372_IOPAD(0x98c, PIN_INPUT_PULLUP | SLEWCTRL_FAST |
MUX_MODE0) /* i2c0_scl.i2c0_scl */
+ >;
+ };
+
+ emmc_pins: emmc_pins {
+ pinctrl-single,pins = <
+ AM4372_IOPAD(0x820, PIN_INPUT_PULLUP | MUX_MODE2) /*
gpmc_ad8.mmc1_dat0 */
+ AM4372_IOPAD(0x824, PIN_INPUT_PULLUP | MUX_MODE2) /*
gpmc_ad9.mmc1_dat1 */
+ AM4372_IOPAD(0x828, PIN_INPUT_PULLUP | MUX_MODE2) /*
gpmc_ad10.mmc1_dat2 */
+ AM4372_IOPAD(0x82c, PIN_INPUT_PULLUP | MUX_MODE2) /*
gpmc_ad11.mmc1_dat3 */
+ AM4372_IOPAD(0x830, PIN_INPUT_PULLUP | MUX_MODE2) /*
gpmc_ad12.mmc1_dat4 */
+ AM4372_IOPAD(0x834, PIN_INPUT_PULLUP | MUX_MODE2) /*
gpmc_ad13.mmc1_dat5 */
+ AM4372_IOPAD(0x838, PIN_INPUT_PULLUP | MUX_MODE2) /*
gpmc_ad14.mmc1_dat6 */
+ AM4372_IOPAD(0x83c, PIN_INPUT_PULLUP | MUX_MODE2) /*
gpmc_ad15.mmc1_dat7 */
+ AM4372_IOPAD(0x880, PIN_INPUT_PULLUP | MUX_MODE2) /*
gpmc_csn1.mmc1_clk */
+ AM4372_IOPAD(0x884, PIN_INPUT_PULLUP | MUX_MODE2) /*
gpmc_csn2.mmc1_cmd */
+ >;
+ };
+
+ spi0_pins: pinmux_spi0_pins {
+ pinctrl-single,pins = <
+ AM4372_IOPAD(0x950, PIN_INPUT | MUX_MODE0) /*
spi0_sclk.spi0_sclk */
+ AM4372_IOPAD(0x954, PIN_INPUT | MUX_MODE0) /*
spi0_d0.spi0_d0 */
+ AM4372_IOPAD(0x958, PIN_OUTPUT | MUX_MODE0) /*
spi0_d1.spi0_d1 */
+ AM4372_IOPAD(0x95C, PIN_OUTPUT | MUX_MODE0) /*
spi0_cs0.spi0_cs0 */
+ >;
+ };
+
+ nand_flash_x8: nand_flash_x8 {
+ pinctrl-single,pins = <
+ AM4372_IOPAD(0x800, PIN_INPUT | PULL_DISABLE |
MUX_MODE0)
+ AM4372_IOPAD(0x804, PIN_INPUT | PULL_DISABLE |
MUX_MODE0)
+ AM4372_IOPAD(0x808, PIN_INPUT | PULL_DISABLE |
MUX_MODE0)
+ AM4372_IOPAD(0x80c, PIN_INPUT | PULL_DISABLE |
MUX_MODE0)
+ AM4372_IOPAD(
[U-Boot] [PATCH 2/2] arm: am437x: cm-t43: Enable DM for MMC, USB, SPI, SPI_FLASH, enable BLK
From: Suniel Mahesh Enable driver model for USB, MMC, SPI and SPI_FLASH. Also enable BLK. This will remove the following compile warnings: = WARNING == This board does not use CONFIG_DM_MMC. Please update the board to use CONFIG_DM_MMC before the v2019.04 release. = WARNING == This board does not use CONFIG_DM_USB. Please update the board to use CONFIG_DM_USB before the v2019.07 release. = WARNING == This board does not use CONFIG_DM_SPI_FLASH. Please update the board to use CONFIG_SPI_FLASH before the v2019.07 release. Target was compile tested, build was clean. Signed-off-by: Suniel Mahesh --- configs/cm_t43_defconfig | 5 + 1 file changed, 5 insertions(+) diff --git a/configs/cm_t43_defconfig b/configs/cm_t43_defconfig index dbc0f7e..44d727f 100644 --- a/configs/cm_t43_defconfig +++ b/configs/cm_t43_defconfig @@ -54,9 +54,13 @@ CONFIG_ENV_IS_IN_SPI_FLASH=y CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG=y CONFIG_DM=y CONFIG_DM_GPIO=y +CONFIG_BLK=y +CONFIG_DM_MMC=y CONFIG_MMC_OMAP_HS=y CONFIG_NAND=y +CONFIG_DM_SPI=y CONFIG_SPI_FLASH=y +CONFIG_DM_SPI_FLASH=y CONFIG_SF_DEFAULT_SPEED=4800 CONFIG_SPI_FLASH_ATMEL=y CONFIG_SPI_FLASH_EON=y @@ -72,6 +76,7 @@ CONFIG_DM_SERIAL=y CONFIG_SPI=y CONFIG_OMAP3_SPI=y CONFIG_USB=y +CONFIG_DM_USB=y CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y CONFIG_OMAP_USB_PHY=y -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] Fix unreliable detection of DRAM size on Orange Pi 3
Hi André,
On Fri, Aug 30, 2019 at 05:19:02PM +0100, Andre Przywara wrote:
> > OTOH, let's visualize it:
> >
> > CPU address DRAM address
> > ---
> > [w ] SDRAM_BASE 0
> > [w aa55aa55] SDRAM_BASE + offset0
> >
> > Both writes should end up at the same physical location in dram).
> >
> > The following test checks that values that are read back are the same. They
> > should be the same in this specific case of Opi3 SBC. It doesn't check for
> > any
> > specific value, so even if writes are re-ordered, the value that's read back
> > should still be the same.
>
> Ah, right. I was actually staring at my modified code, where I try to detect
> half DQ problems with some weird 3GB setup on the Eachlink H6 Mini. So
> I explicitly check for and compare to the second value written, and expect
> this write to have overwritten the first 0 write.
>
> > Order of operations is:
> >
> > writel(0, CONFIG_SYS_SDRAM_BASE);
> > writel(0xaa55aa55, (ulong)CONFIG_SYS_SDRAM_BASE + offset);
> > dsb();
>
> From all I can see this means at this point the two writes are "on the bus"
> ("completed" from the CPU's point of view).
>
> > readl(CONFIG_SYS_SDRAM_BASE)
>
> This should actually push the first write to the device, as a read following
> a write to the same address requires the write to take effect first. Might
> still end up in a write buffer in the DRAM controller, though.
>
> > readl((ulong)CONFIG_SYS_SDRAM_BASE + offset);
> >
> > The CPU can only re-order either the writes or reads. But neither should
> > matter.
>
> Yes, true, for the existing code (which compares the two reads against each
> other).
>
> > Memory controller is a black box to me and that's where the issue probably
> > lies.
>
> Yes, the plot thickens. Maybe the DRAM controller buffers the write
> request(s), as it waits for the page(s) to open in the chips, for instance.
> Now the reads can be satisfied from this buffer, since the addresses match. No
> idea if it would break down the addresses into rows/cols/bank/rank already to
> detect the aliasing.
>
> > The only time this should fail and return different values when reading is
> > if
> > the hardware does some shortcut/assumption, and reads will not go fully from
> > DRAM after the writes.
>
> Sounds tempting, but with the caches and the MMU off (so treating everything
> as device memory) I don't see where this would happen. The only case I could
> imagine would be *in* the DRAM controller, as mentioned above.
Yes, that's what I meant.
> So in this case we would need to tell the DRAM controller to complete all
> outstanding requests (the two writes) first. Then issue the reads. As
> mentioned, sounds possible, but I have no clue how to do this. A slight hack
> would indeed be some delay loop, to give the DRAM controller time to fiddle
> the writes into the DRAM matrix.
> Or flood it with writes, then DSB to force this buffer to drain?
That's antoher interesting idea. :) Though we don't know the size of the buffer.
> > Anyway, I'm failing to reproduce this even without any patches, ATM.
>
> Mmmh, shame.
> Any changes in your setup you can think of? New power supply?
> Maybe we should indeed experiment with lower clocks? Did you run stability
> tests in Linux? To prove that the DRAM timing is actually solid?
I thought it might be temperature related, because now I'm using fan to cool
the board. But that turned out to be not it (I pre-heated the board, and
nothing).
No stability tests, but I've been compiling mesa repeatedly on the board
without a single obvious issue, I also push a lot of data through the board
to the USB connected SSD.
The kernel didn't panic unexpectedly yet. (serveral months)
I suspect that the DRAM timing is good.
I'm trying memterster now, and it looks good, too.
regards,
o.
> Cheers,
> Andre.
>
> > regards,
> > o.
> >
> > > So for the sake of this patch, we should take it. It is needed and
> > > apparently solves one issue, and I can't see any harm in it.
> > >
> > > Regardless of this I was wondering if in this situation (single in-order
> > > core running with MMU and caches off) this is the full story, as the CPU
> > > does not have a good reason to reorder.
> > >
> > > > Could you please experiment with this problem a little bit more?
> > > >
> > > > 1. What if you just move this second DSB instruction after the
> > > > second write and have two of them there? Does this also make
> > > > the problem disappear?
> > >
> > > I don't think two dsb()s next to each other will do anything useful. I
> > > would think the second dsb() would just be ignored, as the order is
> > > already preserved and all memory accesses have been completed:
> > > "A DSB is a memory barrier that ensures that memory accesses that occur
> > > before the DSB have completed before the completion of the DSB
> > > i
Re: [U-Boot] [PATCH] Revert "vexpress64: fvp dram: add DRAM configuration"
On Tue, Aug 27, 2019 at 12:56 PM Ryan Harkin wrote: > This reverts commit fc04b923541d984b1544056fd3bfa8129d4e5aac where the > FVP DRAM configuration was added. > > Signed-off-by: Ryan Harkin OK if we don't need it let it go: Acked-by: Linus Walleij Yours, Linus Walleij ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v4 2/4] USB: host: Add the USB3 host driver
Hi Vignesh,
>
>
>
> On 30/08/19 3:36 PM, Sherry Sun wrote:
> > Hi Jean,
> >
> >>
> >>
> >> On 28/08/2019 13:50, Sherry Sun wrote:
> >>> Hi Jean,
> >>>
> Hi Jean,
>
> > Hi Marek, Sherry,
> >
> >
> > we keep the cdns3 node for usb gadget driver, then add a usb
> > host node for
> > xhci-imx8 driver in *-uboot.dtsi. so here is no need to change
> > the host driver
> compatible.
> > But the compatible in gadget driver should be changed later.
> We should try avoiding ABI breaks in DT.
> >>> But the cdns3 usb gaget driver and host driver in different
> >>> uclass need two
> > dt nodes to bind with.
> >>> And the compatible of the two node cannot be same.
> >>> So for gadget driver, the compatible may use "cdns,usb3-1.0.0",
> >>> for host
> > driver, the compatible will use "cdns,usb3-1.0.0-host".
> >>> What do you think about it?
> >> CCing Jean, since I think he did solve similar topic for his platform.
> > I've been OOO for a few weeks and didn't look at the whole series.
> >
> > For this particular issue, the solution I used is to let the
> > wrapper do the binding job. The name of the driver to use is
> > hard-coded in the
> wrapper diver.
> > This is done in dwc3_glue_bind().
> Thanks for your suggestions.
>
> So if I want to use the cdns3 usb node as both usb gadget device
> and usb host device, do you mean that I should make the cdns3 usb
> node as a usb wrapper device, and create two subnodes in it.
> >>
> >> I think we should not change the binding to adapt to out driver but
> >> keep the bindings that exist in linux and adapt the u-boot driver
> >>
> >> In the version used by our platform, there is a wrapper around the USB:
> >>
> >> usbss0: cdns_usb@4104000 {
> >> compatible = "ti,j721e-usb";
> >> []
> >> usb0: usb@600 {
> >> compatible = "cdns,usb3-1.0.1";
> >>
> >> The driver selection (host or device) could be done by the wrapper
> >> when it binds its children (same as the dwc3).
> >>
> >> OR
> >>
> >> The "cdns,usb3-1.0.1" could be a dumb driver the role of which would
> >> be only to bind a new driver (host or device) based on "dr_mode". The
> >> binding could be done using the same node, it doesn't have to be a
> subnode.
> >>
> >>
> >> Maybe the second solution will be better, as it would work for
> >> platforms that do not use a wrapper.
> >>
> >
> > I just communicated with Vignesh Raghavendra , and he
> suggest that I should keep this cdns3 driver under Linux kernel and U-Boot in
> sync. And show me your downstream code with v10 of Cadence USB3 kernel
> driver ported to U-Boot. So I decide to follow your way to deal with this
> issue.
> >
> > But I want to ask another question:
> > The two solutions you gave before both make the usb node with
> compatible "cdns,usb3-1.0.1" as a definite device (host or gadget) by its
> dr_mode property. If I want use this usb device works as both host and
> gadget driver, which means I want to change its status runtime, such as I
> want to use this usb device to run both fastboot or usb start command, how
> can we deal with this? .
> >
>
> AFAIK, U-Boot does not support runtime switching of USB port to host from
> device and vice versa. This is the case for existing driver like DWC3/MUSB
> etc.
>
> Ideally we would need a role switch driver that unbinds and rebinds host vs
> device driver as when required based on U-Boot cmd or via an API (if
> required to be done during SPL stage etc).
I wonder if we can add two subnodes under the wrapper node as below, one bind
to usb gadget driver and another bind to usb host driver.
So if we want to use usb device, just call the gadget driver, and if want to
use usb host, just call the host driver. The driver will probe correspond node.
I'm not sure if it is feasible, what do you think about it?
usbss0: cdns_usb@4104000 {
compatible = "ti,j721e-usb";
[]
usb0: usb@601 { /* xhci reg address*/
compatible = "cdns,usb3-1.0.1";
dr_mode = "host";
[]
}
usb1: usb@602 { /* dev reg address*/
compatible = "cdns,usb3-1.0.1";
dr_mode = "peripheral";
[]
}
}
Best regards
Sherry sun
>
> Regards
> Vignesh
>
> > Best regards
> > Sherry sun
> >
> >>
> >> JJ
> >>
> Then when binding the wrapper node, it will hard-coded the two
> >> subnodes
> to different driver(gadge/host driver) according to the dr_mode
> property
> >> in
> nodes.
>
> >>> Do you think I understand it right?
> >>
> >>>
> >>> Best regards
> >>> Sherry sun
> >>>
> Best regards
> Sherry sun
>
> > JJ
> >
> >
> >
> >>> + { }
> >>> +};
> ___
> U-Boot mail
[U-Boot] [PATCH] dm: mmc_spi: Fix NULL pointer dereference in mmc_spi_bind()
The mmc_spi driver's priv is not available in its bind phase(). Use
platdata instead.
Fixes: 05e35d429745 ("mmc: mmc_spi: Re-write driver using DM framework")
Signed-off-by: Bin Meng
---
drivers/mmc/mmc_spi.c | 35 ---
1 file changed, 20 insertions(+), 15 deletions(-)
diff --git a/drivers/mmc/mmc_spi.c b/drivers/mmc/mmc_spi.c
index 350812a..c693fb2 100644
--- a/drivers/mmc/mmc_spi.c
+++ b/drivers/mmc/mmc_spi.c
@@ -58,12 +58,15 @@
#define READ_TIMEOUT 300 /* 1 sec */
#define WRITE_TIMEOUT 300 /* 1 sec */
-struct mmc_spi_priv {
- struct spi_slave *spi;
+struct mmc_spi_plat {
struct mmc_config cfg;
struct mmc mmc;
};
+struct mmc_spi_priv {
+ struct spi_slave *spi;
+};
+
static int mmc_spi_sendcmd(struct udevice *dev,
ushort cmdidx, u32 cmdarg, u32 resp_type,
u8 *resp, u32 resp_size,
@@ -370,6 +373,7 @@ done:
static int mmc_spi_probe(struct udevice *dev)
{
struct mmc_spi_priv *priv = dev_get_priv(dev);
+ struct mmc_spi_plat *plat = dev_get_platdata(dev);
struct mmc_uclass_priv *upriv = dev_get_uclass_priv(dev);
char *name;
@@ -385,28 +389,28 @@ static int mmc_spi_probe(struct udevice *dev)
return -ENOMEM;
sprintf(name, "%s:%s", dev->parent->name, dev->name);
- priv->cfg.name = name;
- priv->cfg.host_caps = MMC_MODE_SPI;
- priv->cfg.voltages = MMC_SPI_VOLTAGE;
- priv->cfg.f_min = MMC_SPI_MIN_CLOCK;
- priv->cfg.f_max = priv->spi->max_hz;
- priv->cfg.part_type = PART_TYPE_DOS;
- priv->cfg.b_max = CONFIG_SYS_MMC_MAX_BLK_COUNT;
+ plat->cfg.name = name;
+ plat->cfg.host_caps = MMC_MODE_SPI;
+ plat->cfg.voltages = MMC_SPI_VOLTAGE;
+ plat->cfg.f_min = MMC_SPI_MIN_CLOCK;
+ plat->cfg.f_max = priv->spi->max_hz;
+ plat->cfg.part_type = PART_TYPE_DOS;
+ plat->cfg.b_max = CONFIG_SYS_MMC_MAX_BLK_COUNT;
- priv->mmc.cfg = &priv->cfg;
- priv->mmc.priv = priv;
- priv->mmc.dev = dev;
+ plat->mmc.cfg = &plat->cfg;
+ plat->mmc.priv = priv;
+ plat->mmc.dev = dev;
- upriv->mmc = &priv->mmc;
+ upriv->mmc = &plat->mmc;
return 0;
}
static int mmc_spi_bind(struct udevice *dev)
{
- struct mmc_spi_priv *priv = dev_get_priv(dev);
+ struct mmc_spi_plat *plat = dev_get_platdata(dev);
- return mmc_bind(dev, &priv->mmc, &priv->cfg);
+ return mmc_bind(dev, &plat->mmc, &plat->cfg);
}
static const struct dm_mmc_ops mmc_spi_ops = {
@@ -426,5 +430,6 @@ U_BOOT_DRIVER(mmc_spi) = {
.ops = &mmc_spi_ops,
.probe = mmc_spi_probe,
.bind = mmc_spi_bind,
+ .platdata_auto_alloc_size = sizeof(struct mmc_spi_plat),
.priv_auto_alloc_size = sizeof(struct mmc_spi_priv),
};
--
2.7.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
