date:20190309

Re: [U-Boot] changes in rk3288 code have made me unable to boot u-boot on veyron speedy

2019-03-09 Thread Heiko Stuebner

Am Samstag, 9. März 2019, 23:45:15 CET schrieb Marty E. Plummer:
> On Sat, Mar 09, 2019 at 05:43:24PM +0100, Heiko Stuebner wrote:
> > Hi Marty,
> > 
> > Am Samstag, 9. März 2019, 08:15:23 CET schrieb Marty E. Plummer:
> > > Was going to work on getting that usb->uart redirection code from the
> > > linux kernel into u-boot for rk3288, like we have for rk3188, but
> > > apparently there have been some changes which render 
> > > chromebook_speedy_defconfig
> > > unable to produce a bootable image. Guidance and suggestions welcome.
> > > 
> > > Current chromebook_speedy_defconfig results:
> > > U-Boot SPL 2019.04-rc3-03639-ge8e3f2d2d4 (Mar 09 2019 - 00:59:05 -0600)   
> > >
> > > Trying to boot from SPI
> > > SPI probe failed.
> > > SPL: failed to boot from all boot devices
> > > ### ERROR ### Please RESET the board ###
> > > 
> > > chromebook_speedy_defconfig with CONFIG_SPI_FLASH turned on (didn't get
> > > moved into the defconfig like the rest)
> > > U-Boot SPL 2019.04-rc3-03639-ge8e3f2d2d4 (Mar 09 2019 - 01:01:38 -0600)   
> > >
> > > Trying to boot from SPI
> > > initcall sequence 001511f4 failed at call 00101ad5 (err=-38)
> > > ### ERROR ### Please RESET the board ###
> > > 
> > > And enabling the full pinctrl driver and the needed libfdt stuff results
> > > in no output at all.
> > 
> > Maybe you could try the in flight patch from David first:
> > http://patchwork.ozlabs.org/patch/1040541/
> > 
> Are you meaning I should apply said patch to hopefully fix the no-output
> when i add the pinctrl driver?

exactly ... the completely new pinctrl driver seems to have a small error
on rk3288, that this patch is fixing ... supposedly a v2 is to come shortly.


> > In general I noticed in recent tries that rk3288 scrapes really narrow
> > at the 32kb limit of the sram, so possibly we'll need TPL on all rk3288
> > boards similar to what the rk3288-vyasa board already does now.
> > 
> Yeah I was eyeballing that as well since adding some features to speedy
> from jerry in an attempt to get around the issue made the spl image too
> large.

yep, everything is pretty narrow there. Right now I'm playing with getting
ATF to work[*] on rk3288 and this obviously needs real mmc and fit image
support and other boards like the phycore-rk3288 cannot even build an
spl image right now due to it needing more code to work.


Heiko

[*] ATF got armv7 support in 2017, so it's interesting if I can make it
handle smp via PSCI (and maybe things like deeper suspend)
and I learned so much about ARM assembler these last days :-D


___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] changes in rk3288 code have made me unable to boot u-boot on veyron speedy

2019-03-09 Thread Marty E. Plummer

On Sat, Mar 09, 2019 at 05:43:24PM +0100, Heiko Stuebner wrote:
> Hi Marty,
> 
> Am Samstag, 9. März 2019, 08:15:23 CET schrieb Marty E. Plummer:
> > Was going to work on getting that usb->uart redirection code from the
> > linux kernel into u-boot for rk3288, like we have for rk3188, but
> > apparently there have been some changes which render 
> > chromebook_speedy_defconfig
> > unable to produce a bootable image. Guidance and suggestions welcome.
> > 
> > Current chromebook_speedy_defconfig results:
> > U-Boot SPL 2019.04-rc3-03639-ge8e3f2d2d4 (Mar 09 2019 - 00:59:05 -0600) 
> >  
> > Trying to boot from SPI
> > SPI probe failed.
> > SPL: failed to boot from all boot devices
> > ### ERROR ### Please RESET the board ###
> > 
> > chromebook_speedy_defconfig with CONFIG_SPI_FLASH turned on (didn't get
> > moved into the defconfig like the rest)
> > U-Boot SPL 2019.04-rc3-03639-ge8e3f2d2d4 (Mar 09 2019 - 01:01:38 -0600) 
> >  
> > Trying to boot from SPI
> > initcall sequence 001511f4 failed at call 00101ad5 (err=-38)
> > ### ERROR ### Please RESET the board ###
> > 
> > And enabling the full pinctrl driver and the needed libfdt stuff results
> > in no output at all.
> 
> Maybe you could try the in flight patch from David first:
> http://patchwork.ozlabs.org/patch/1040541/
> 
Are you meaning I should apply said patch to hopefully fix the no-output
when i add the pinctrl driver?
> In general I noticed in recent tries that rk3288 scrapes really narrow
> at the 32kb limit of the sram, so possibly we'll need TPL on all rk3288
> boards similar to what the rk3288-vyasa board already does now.
> 
Yeah I was eyeballing that as well since adding some features to speedy
from jerry in an attempt to get around the issue made the spl image too
large.
> 
> Heiko
> 
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [RFC 0/9] Convert Pico-Pi i.MX7D to DM

2019-03-09 Thread Offouga Joris



> Le 28 févr. 2019 à 23:06, Offouga Joris  a écrit :
> 
> 
> 
>> Le 28 févr. 2019 à 21:38, Fabio Estevam  a écrit :
>> 
>> Hi Joris,
>> 
>>> On Sat, Feb 16, 2019 at 1:25 PM Fabio Estevam  wrote:
>>> 
>>> Just run a "git bisect" and the problem comes from:
>>> 
>>> commit 9e3c0174da842dd88f5feaffbf843ba332233897 (refs/bisect/bad)
>>> Author: Fabio Estevam 
>>> Date:   Tue Dec 11 16:40:38 2018 -0200
>>> 
>>>   pico-imx7d: Add LCD support
>>> 
>>>   Add support for the VXT VL050-8048NT-C01 panel connected through
>>>   the 24 bit parallel LCDIF interface.
>>> 
>>>   Signed-off-by: Fabio Estevam 
>>>   Signed-off-by: Otavio Salvador 
>>> 
>>> It used to work at some point as I could see the splashscreen logo in
>>> the screen.
>> 
>> Just a quick update: if I boot from eMMC I don't see this video
>> related hang. I only see the hang when I boot from USB.
> I do not have the screen connected when I do my tests and I disabled 
> CONFIG_VIDEO because it lacks the GPIOs for the screen in the current device 
> tree

Hi Fabio, 

I revert the commit about add lcd and on u-boot master and u-boot imx i have 
the u-boot is flashed correctly in usb and dfu. 

do you agree that I send the revert of the commit?

Best Regards, 
Joris
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH 1/2] ddr: socfpga: Clean up EMIF reset

2019-03-09 Thread Marek Vasut

The EMIF reset code can well use wait_for_bit_le32() instead of all that
convoluted polling code. Reduce the timeout from 100 seconds to 1 second,
since if the EMIF fails to reset itself in 1 second, it's unlikely longer
wait would help. Make sure to clear the EMIF reset request even if the
SEQ2CORE_INT_RESP_BIT isn't asserted.

Signed-off-by: Marek Vasut 
Cc: Chin Liang See 
Cc: Dinh Nguyen 
Cc: Simon Goldschmidt 
Cc: Tien Fong Chee 
---
 drivers/ddr/altera/sdram_arria10.c | 33 +++---
 1 file changed, 7 insertions(+), 26 deletions(-)

diff --git a/drivers/ddr/altera/sdram_arria10.c 
b/drivers/ddr/altera/sdram_arria10.c
index b450a1b1be..ff83c61002 100644
--- a/drivers/ddr/altera/sdram_arria10.c
+++ b/drivers/ddr/altera/sdram_arria10.c
@@ -108,28 +108,6 @@ static int is_sdram_cal_success(void)
return readl(&socfpga_ecc_hmc_base->ddrcalstat);
 }
 
-static unsigned char ddr_get_bit(u32 ereg, unsigned char bit)
-{
-   u32 reg = readl(ereg);
-
-   return (reg & BIT(bit)) ? 1 : 0;
-}
-
-static unsigned char ddr_wait_bit(u32 ereg, u32 bit,
-  u32 expected, u32 timeout_usec)
-{
-   u32 tmr;
-
-   for (tmr = 0; tmr < timeout_usec; tmr += 100) {
-   udelay(100);
-   WATCHDOG_RESET();
-   if (ddr_get_bit(ereg, bit) == expected)
-   return 0;
-   }
-
-   return 1;
-}
-
 static int emif_clear(void)
 {
writel(0, DDR_REG_CORE2SEQ);
@@ -162,13 +140,16 @@ static int emif_reset(void)
 
writel(CORE2SEQ_INT_REQ, DDR_REG_CORE2SEQ);
 
-   if (ddr_wait_bit(DDR_REG_SEQ2CORE, SEQ2CORE_INT_RESP_BIT, 0, 100)) {
+   ret = wait_for_bit_le32((u32 *)DDR_REG_SEQ2CORE,
+   SEQ2CORE_INT_RESP_BIT, false, 1000, false);
+   if (ret) {
debug("emif_reset failed to see interrupt acknowledge\n");
-   return -EPERM;
-   } else {
-   debug("emif_reset interrupt acknowledged\n");
+   emif_clear();
+   return ret;
}
 
+   mdelay(1);
+
ret = emif_clear();
if (ret) {
debug("emif_clear() failed\n");
-- 
2.20.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH 2/2] ddr: socfpga: Clean up ddr_setup()

2019-03-09 Thread Marek Vasut

Replace the current rather convoluted code using ad-hoc polling
mechanism with a more straightforward code. Use wait_for_bit_le32()
to poll the DDRCALSTAT register instead of local reimplementation.
It makes no sense to pull for 5 seconds before giving up and trying
to restart the EMIF, so instead wait 500 mSec for the calibration to
complete and if this fails, restart the EMIF and try again. Perform
this 32 times instead of 3 times as the original code did.

Signed-off-by: Marek Vasut 
Cc: Chin Liang See 
Cc: Dinh Nguyen 
Cc: Simon Goldschmidt 
Cc: Tien Fong Chee 
---
 drivers/ddr/altera/sdram_arria10.c | 43 +++---
 1 file changed, 15 insertions(+), 28 deletions(-)

diff --git a/drivers/ddr/altera/sdram_arria10.c 
b/drivers/ddr/altera/sdram_arria10.c
index ff83c61002..1777e7e1a5 100644
--- a/drivers/ddr/altera/sdram_arria10.c
+++ b/drivers/ddr/altera/sdram_arria10.c
@@ -102,12 +102,6 @@ static int match_ddr_conf(u32 ddr_conf)
return 0;
 }
 
-/* Check whether SDRAM is successfully Calibrated */
-static int is_sdram_cal_success(void)
-{
-   return readl(&socfpga_ecc_hmc_base->ddrcalstat);
-}
-
 static int emif_clear(void)
 {
writel(0, DDR_REG_CORE2SEQ);
@@ -167,30 +161,23 @@ static int emif_reset(void)
 
 static int ddr_setup(void)
 {
-   int i, j, ddr_setup_complete = 0;
-
-   /* Try 3 times to do a calibration */
-   for (i = 0; (i < 3) && !ddr_setup_complete; i++) {
-   WATCHDOG_RESET();
-
-   /* A delay to wait for calibration bit to set */
-   for (j = 0; (j < 10) && !ddr_setup_complete; j++) {
-   mdelay(500);
-   ddr_setup_complete = is_sdram_cal_success();
-   }
-
-   if (!ddr_setup_complete)
-   if (emif_reset())
-   puts("Error: Failed to reset EMIF\n");
+   int i, ret;
+
+   /* Try 32 times to do a calibration */
+   for (i = 0; i < 32; i++) {
+   mdelay(500);
+   ret = wait_for_bit_le32(&socfpga_ecc_hmc_base->ddrcalstat,
+   BIT(0), true, 500, false);
+   if (!ret)
+   return 0;
+
+   ret = emif_reset();
+   if (ret)
+   puts("Error: Failed to reset EMIF\n");
}
 
-   /* After 3 times trying calibration */
-   if (!ddr_setup_complete) {
-   puts("Error: Could Not Calibrate SDRAM\n");
-   return -EPERM;
-   }
-
-   return 0;
+   puts("Error: Could Not Calibrate SDRAM\n");
+   return -EPERM;
 }
 
 static int sdram_is_ecc_enabled(void)
-- 
2.20.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH V3] ddr: socfpga: Fix EMIF clear timeout

2019-03-09 Thread Simon Goldschmidt




On 09.03.2019 22:12, Marek Vasut wrote:

The current EMIF clear timeout handling code was applying bitwise
operations to signed data types and as it was, was extremely hard
to read. Replace it with simple wait_for_bit(). Expand the error
handling to make it more readable too.

This patch also changes the timeout for emif_clear() from 14 hours
to 1 second.

Signed-off-by: Marek Vasut 
Cc: Chin Liang See 
Cc: Dinh Nguyen 
Cc: Simon Goldschmidt 
Cc: Tien Fong Chee 


Reviewed-by: Simon Goldschmidt 


---
V2: Subject should read ddr: socfpga: , fix this
V3: Zap DDR_MAX_TRIES
---
  drivers/ddr/altera/sdram_arria10.c | 25 +++--
  1 file changed, 11 insertions(+), 14 deletions(-)

diff --git a/drivers/ddr/altera/sdram_arria10.c 
b/drivers/ddr/altera/sdram_arria10.c
index be5ce778e8..b450a1b1be 100644
--- a/drivers/ddr/altera/sdram_arria10.c
+++ b/drivers/ddr/altera/sdram_arria10.c
@@ -31,7 +31,6 @@ static u64 sdram_size_calc(void);
  #define DDR_REG_CORE2SEQ0xFFD05078
  #define DDR_READ_LATENCY_DELAY40
  #define DDR_SIZE_2GB_HEX  0x8000
-#define DDR_MAX_TRIES  0x0010
  
  #define IO48_MMR_DRAMSTS	0xFFCFA0EC

  #define IO48_MMR_NIOS2_RESERVE0   0xFFCFA110
@@ -133,22 +132,16 @@ static unsigned char ddr_wait_bit(u32 ereg, u32 bit,
  
  static int emif_clear(void)

  {
-   u32 i = DDR_MAX_TRIES;
-   u8 ret = 0;
-
writel(0, DDR_REG_CORE2SEQ);
  
-	do {

-   ret = !wait_for_bit_le32((u32 *)DDR_REG_SEQ2CORE,
-  SEQ2CORE_MASK, 1, 50, 0);
-   } while (ret && (--i > 0));
-
-   return !i;
+   return wait_for_bit_le32((u32 *)DDR_REG_SEQ2CORE,
+   SEQ2CORE_MASK, 0, 1000, 0);
  }
  
  static int emif_reset(void)

  {
u32 c2s, s2c;
+   int ret;
  
  	c2s = readl(DDR_REG_CORE2SEQ);

s2c = readl(DDR_REG_SEQ2CORE);
@@ -159,9 +152,12 @@ static int emif_reset(void)
 readl(IO48_MMR_NIOS2_RESERVE2),
 readl(IO48_MMR_DRAMSTS));
  
-	if ((s2c & SEQ2CORE_MASK) && emif_clear()) {

-   debug("failed emif_clear()\n");
-   return -EPERM;
+   if (s2c & SEQ2CORE_MASK) {
+   ret = emif_clear();
+   if (ret) {
+   debug("failed emif_clear()\n");
+   return -EPERM;
+   }
}
  
  	writel(CORE2SEQ_INT_REQ, DDR_REG_CORE2SEQ);

@@ -173,7 +169,8 @@ static int emif_reset(void)
debug("emif_reset interrupt acknowledged\n");
}
  
-	if (emif_clear()) {

+   ret = emif_clear();
+   if (ret) {
debug("emif_clear() failed\n");
return -EPERM;
}


___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH V3] ddr: socfpga: Fix EMIF clear timeout

2019-03-09 Thread Marek Vasut

The current EMIF clear timeout handling code was applying bitwise
operations to signed data types and as it was, was extremely hard
to read. Replace it with simple wait_for_bit(). Expand the error
handling to make it more readable too.

This patch also changes the timeout for emif_clear() from 14 hours
to 1 second.

Signed-off-by: Marek Vasut 
Cc: Chin Liang See 
Cc: Dinh Nguyen 
Cc: Simon Goldschmidt 
Cc: Tien Fong Chee 
---
V2: Subject should read ddr: socfpga: , fix this
V3: Zap DDR_MAX_TRIES
---
 drivers/ddr/altera/sdram_arria10.c | 25 +++--
 1 file changed, 11 insertions(+), 14 deletions(-)

diff --git a/drivers/ddr/altera/sdram_arria10.c 
b/drivers/ddr/altera/sdram_arria10.c
index be5ce778e8..b450a1b1be 100644
--- a/drivers/ddr/altera/sdram_arria10.c
+++ b/drivers/ddr/altera/sdram_arria10.c
@@ -31,7 +31,6 @@ static u64 sdram_size_calc(void);
 #define DDR_REG_CORE2SEQ0xFFD05078
 #define DDR_READ_LATENCY_DELAY 40
 #define DDR_SIZE_2GB_HEX   0x8000
-#define DDR_MAX_TRIES  0x0010
 
 #define IO48_MMR_DRAMSTS   0xFFCFA0EC
 #define IO48_MMR_NIOS2_RESERVE00xFFCFA110
@@ -133,22 +132,16 @@ static unsigned char ddr_wait_bit(u32 ereg, u32 bit,
 
 static int emif_clear(void)
 {
-   u32 i = DDR_MAX_TRIES;
-   u8 ret = 0;
-
writel(0, DDR_REG_CORE2SEQ);
 
-   do {
-   ret = !wait_for_bit_le32((u32 *)DDR_REG_SEQ2CORE,
-  SEQ2CORE_MASK, 1, 50, 0);
-   } while (ret && (--i > 0));
-
-   return !i;
+   return wait_for_bit_le32((u32 *)DDR_REG_SEQ2CORE,
+   SEQ2CORE_MASK, 0, 1000, 0);
 }
 
 static int emif_reset(void)
 {
u32 c2s, s2c;
+   int ret;
 
c2s = readl(DDR_REG_CORE2SEQ);
s2c = readl(DDR_REG_SEQ2CORE);
@@ -159,9 +152,12 @@ static int emif_reset(void)
 readl(IO48_MMR_NIOS2_RESERVE2),
 readl(IO48_MMR_DRAMSTS));
 
-   if ((s2c & SEQ2CORE_MASK) && emif_clear()) {
-   debug("failed emif_clear()\n");
-   return -EPERM;
+   if (s2c & SEQ2CORE_MASK) {
+   ret = emif_clear();
+   if (ret) {
+   debug("failed emif_clear()\n");
+   return -EPERM;
+   }
}
 
writel(CORE2SEQ_INT_REQ, DDR_REG_CORE2SEQ);
@@ -173,7 +169,8 @@ static int emif_reset(void)
debug("emif_reset interrupt acknowledged\n");
}
 
-   if (emif_clear()) {
+   ret = emif_clear();
+   if (ret) {
debug("emif_clear() failed\n");
return -EPERM;
}
-- 
2.20.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] Revert "Ensure device tree DTS is compiled"

2019-03-09 Thread Tom Rini

On Sun, Mar 10, 2019 at 01:07:48AM +0900, Masahiro Yamada wrote:
> Hi Tom,
> 
> 
> On Sat, Mar 9, 2019 at 8:04 AM Tom Rini  wrote:
> >
> > On Thu, Mar 07, 2019 at 11:13:52PM +0900, Masahiro Yamada wrote:
> >
> > > This reverts commit 27cb7300ffda7a3f1581f0f5a2d3bfe59b97ad67.
> > >
> > > I am not sure if I correctly understood the log of commit 27cb7300ffda
> > > ("Ensure device tree DTS is compiled"), but the code-diff looks like
> > > it was trying to solve the missed re-compilation when .dts was modified.
> > >
> > > Recently, commit 2737dfe096b6 ("kbuild: make arch-dtbs target PHONY")
> > > fixed the issue in a more correct and more complete way.
> > >
> > > Anyway, since the former commit, we see a clumsy log like this:
> > >
> > >   make[2]: 'arch/sandbox/dts/sandbox.dtb' is up to date
> > >
> > > So, let's revert it.
> > >
> > > Signed-off-by: Masahiro Yamada 
> >
> > This causes tons of breakage like:
> >arm:  +   rpi_0_w
> > +(rpi_0_w)
> > +(rpi_0_w) Device Tree Source is not correctly specified.
> > +(rpi_0_w) Please define 'CONFIG_DEFAULT_DEVICE_TREE'
> > +(rpi_0_w) or build with 'DEVICE_TREE=' argument
> > +(rpi_0_w) make[2]: *** [arch/arm/dts/bcm2835-rpi-zero-w.dtb] Error 1
> > +(rpi_0_w) make[1]: *** [dts] Error 2
> > +(rpi_0_w) make: *** [sub-make] Error 2
> >
> 
> 
> This is because arch/arm/dts/Makefile
> has no entry for bcm2835-rpi-zero-w.dtb.
> 
> 
> 
> 
> The following patch should fix the error
> 
> 
> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> index 2a040b2..5540f1b 100644
> --- a/arch/arm/dts/Makefile
> +++ b/arch/arm/dts/Makefile
> @@ -582,6 +582,7 @@ dtb-$(CONFIG_ARCH_BCM283X) += \
> bcm2835-rpi-b-plus.dtb \
> bcm2835-rpi-b-rev2.dtb \
> bcm2835-rpi-b.dtb \
> +   bcm2835-rpi-zero-w.dtb \
> bcm2836-rpi-2-b.dtb \
> bcm2837-rpi-3-b.dtb
> 
> 
> 
> 
> 
> The reverted commit was hiding the issue.
> 
> I believe DTB files should be explicitly associated
> with CONFIG option in Makefile.
> U-Boot used to work that way, and so does Linux.
> 
> 
> I do not know how may boards are broken now, but
> the right thing to do is to add dtb entries to Makefile,
> the revert the bad commit.

OK, that sounds good.  But it's a non-trivial number of boards to fix,
so it's a real series to be put on the TODO list then.  Thanks for
explaining!

-- 
Tom


signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v2] ARM: dts: rmobile: Zap redundant USB/SDHI nodes on M3N

2019-03-09 Thread Marek Vasut

On 3/9/19 2:04 PM, Eugeniu Rosca wrote:
> v2019.01 commit cbff9f80cedd ("ARM: dts: rmobile: Sync Gen3 DTs with
> Linux 4.19.6") made the sdhi/usb nodes available in r8a77965.dtsi.
> 
> Hence, remove the SDHI/USB nodes from r8a77965-u-boot.dtsi. This is
> equivalent to partially reverting below v2019.01 commits:
>  - f529bc551b6d ("ARM: dts: rmobile: Extract USB nodes on M3N")
>  - 830b94f76867 ("ARM: dts: rmobile: Extract SDHI nodes on M3N")
> 
> Duplicating the nodes from .dtsi to -u-boot.dtsi is obviously:
>  - not needed if no U-boot-specific changes are needed in those nodes.
>  - potentially dangerous/error-prone, since the duplicated properties
>override the properties originally defined in .dtsi. One
>possible consequence is that .dtsi is getting an update from
>Linux, while -u-boot.dtsi stays unchanged. In this situation,
>the obsolete property values from -u-boot.dtsi will take
>precedence masking some of the .dtsi updates, potentially
>leading to all kind of obscure issues.
> 
> Below is the dtdiff of r8a77965-salvator-x-u-boot.dtb (the only "user"
> of r8a77965-u-boot.dtsi) before and after the patch (slightly
> reformatted to avoid 'git am/apply' issues and to reduce the width).
> 
> What below output means is there is already a mismatch in some of
> SDHI/USB nodes between r8a77965.dtsi and r8a77965-u-boot.dtsi. Since no
> U-Boot customization is needed in SDHI/USB DT nodes, get rid of them in
> r8a77965-u-boot.dtsi.
> 
> $> dtdiff before-r8a77965-salvator-x-u-boot.dtb \
>after-r8a77965-salvator-x-u-boot.dtb
>  --- /dev/fd/63  2019-03-09 12:57:40.877963983 +0100
>  +++ /dev/fd/62  2019-03-09 12:57:40.877963983 +0100
>  @@ -1471,7 +1471,7 @@
> bus-width = <0x4>;
> cd-gpios = <0x51 0xc 0x1>;
> clocks = <0x6 0x1 0x13a>;
>  -  compatible = "renesas,sdhi-r8a77965";
>  +  compatible = "renesas,sdhi-r8a77965", "renesas,rcar-gen3-sdhi";
> interrupts = <0x0 0xa5 0x4>;
> max-frequency = <0xc65d400>;
> pinctrl-0 = <0x4d>;
>  @@ -1492,7 +1492,7 @@
> 
>   sd@ee12 {
> clocks = <0x6 0x1 0x139>;
>  -  compatible = "renesas,sdhi-r8a77965";
>  +  compatible = "renesas,sdhi-r8a77965", "renesas,rcar-gen3-sdhi";
> interrupts = <0x0 0xa6 0x4>;
> max-frequency = <0xbebc200>;
> power-domains = <0x1 0x20>;
>  @@ -1504,7 +1504,7 @@
>   sd@ee14 {
> bus-width = <0x8>;
> clocks = <0x6 0x1 0x138>;
>  -  compatible = "renesas,sdhi-r8a77965";
>  +  compatible = "renesas,sdhi-r8a77965", "renesas,rcar-gen3-sdhi";
> fixed-emmc-driver-type = <0x1>;
> interrupts = <0x0 0xa7 0x4>;
> max-frequency = <0xbebc200>;
>  @@ -1526,7 +1526,7 @@
> bus-width = <0x4>;
> cd-gpios = <0x5a 0xf 0x1>;
> clocks = <0x6 0x1 0x137>;
>  -  compatible = "renesas,sdhi-r8a77965";
>  +  compatible = "renesas,sdhi-r8a77965", "renesas,rcar-gen3-sdhi";
> interrupts = <0x0 0xa8 0x4>;
> max-frequency = <0xc65d400>;
> pinctrl-0 = <0x56>;
>  @@ -1868,14 +1868,14 @@
> 
>   usb-phy@ee0a0200 {
> #phy-cells = <0x0>;
>  -  clocks = <0x6 0x1 0x2be>;
>  +  clocks = <0x6 0x1 0x2bf>;
> compatible = "renesas,usb2-phy-r8a77965", 
> "renesas,rcar-gen3-usb2-phy";
> phandle = <0x47>;
> pinctrl-0 = <0x4c>;
> pinctrl-names = "default";
> power-domains = <0x1 0x20>;
> reg = <0x0 0xee0a0200 0x0 0x700>;
>  -  resets = <0x6 0x2be>;
>  +  resets = <0x6 0x2bf>;
> status = "okay";
>   };

Applied, thanks.

-- 
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] changes in rk3288 code have made me unable to boot u-boot on veyron speedy

2019-03-09 Thread Heiko Stuebner

Hi Marty,

Am Samstag, 9. März 2019, 08:15:23 CET schrieb Marty E. Plummer:
> Was going to work on getting that usb->uart redirection code from the
> linux kernel into u-boot for rk3288, like we have for rk3188, but
> apparently there have been some changes which render 
> chromebook_speedy_defconfig
> unable to produce a bootable image. Guidance and suggestions welcome.
> 
> Current chromebook_speedy_defconfig results:
> U-Boot SPL 2019.04-rc3-03639-ge8e3f2d2d4 (Mar 09 2019 - 00:59:05 -0600)   
>
> Trying to boot from SPI
> SPI probe failed.
> SPL: failed to boot from all boot devices
> ### ERROR ### Please RESET the board ###
> 
> chromebook_speedy_defconfig with CONFIG_SPI_FLASH turned on (didn't get
> moved into the defconfig like the rest)
> U-Boot SPL 2019.04-rc3-03639-ge8e3f2d2d4 (Mar 09 2019 - 01:01:38 -0600)   
>
> Trying to boot from SPI
> initcall sequence 001511f4 failed at call 00101ad5 (err=-38)
> ### ERROR ### Please RESET the board ###
> 
> And enabling the full pinctrl driver and the needed libfdt stuff results
> in no output at all.

Maybe you could try the in flight patch from David first:
http://patchwork.ozlabs.org/patch/1040541/

In general I noticed in recent tries that rk3288 scrapes really narrow
at the 32kb limit of the sram, so possibly we'll need TPL on all rk3288
boards similar to what the rk3288-vyasa board already does now.


Heiko


___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH] core: ofnode: Fix ASAN-reported stack-buffer-overflow in of_get_address

2019-03-09 Thread Eugeniu Rosca

v2019.04-rc3 sandbox U-Boot fails to boot when compiled with
 -fsanitize=address and linked against -lasan, reporting [1].

Git bisecting shows that the issue is contributed by v2019.01 commit
1678754f5e2c ("core: ofnode: Fix ofnode_get_addr_index function").

The root cause seems to be the mismatch between sizeof(u64) and
sizeof(fdt_size_t) on sandbox. Luckily, thanks to the fact that the
size argument of both of_get_address() and fdtdec_get_addr_size_fixed()
is optional, we can pass NULL in its place, avoiding the problem.

[1] Backtrace reported by ASAN (gcc 8.1.0):

$> ./u-boot -d arch/sandbox/dts/sandbox.dtb
[..]
=
==10998==ERROR: AddressSanitizer: stack-buffer-overflow on address 
0x7ffcc2331140 at pc 0x004eeeb0 bp 0x7ffcc2330f80 sp 0x7ffcc2330f70
WRITE of size 8 at 0x7ffcc2331140 thread T0
#0 0x4eeeaf in of_get_address drivers/core/of_addr.c:154
#1 0x4f7441 in ofnode_get_addr_index drivers/core/ofnode.c:263
#2 0x5b2a78 in sb_eth_ofdata_to_platdata drivers/net/sandbox.c:422
#3 0x4dccd8 in device_probe drivers/core/device.c:407
#4 0x753170 in eth_initialize net/eth-uclass.c:428
#5 0x47d9bf in initr_net common/board_r.c:557
#6 0x6bcfa7 in initcall_run_list lib/initcall.c:30
#7 0x47e1fe in board_init_r common/board_r.c:859
#8 0x4060e5 in main arch/sandbox/cpu/start.c:356
#9 0x7fb8d135482f in __libc_start_main 
(/lib/x86_64-linux-gnu/libc.so.6+0x2082f)
#10 0x40a3a8 in _start (/path/to/u-boot/u-boot+0x40a3a8)

Address 0x7ffcc2331140 is located in stack of thread T0 at offset 32 in frame
#0 0x4f72b8 in ofnode_get_addr_index drivers/core/ofnode.c:255

  This frame has 3 object(s):
[32, 36) 'size' <== Memory access at offset 32 partially overflows this 
variable
[96, 100) 'flags'
[160, 168) 'node'
HINT: this may be a false positive if your program uses some custom stack 
unwind mechanism or swapcontext
  (longjmp and C++ exceptions *are* supported)
SUMMARY: AddressSanitizer: stack-buffer-overflow drivers/core/of_addr.c:154 in 
of_get_address
Shadow bytes around the buggy address:
  0x10001845e1d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10001845e1e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10001845e1f0: 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1
  0x10001845e200: 04 f2 f2 f2 f2 f2 f2 f2 04 f2 f2 f2 f2 f2 f2 f2
  0x10001845e210: 04 f2 f2 f2 f3 f3 f3 f3 00 00 00 00 00 00 00 00
=>0x10001845e220: 00 00 00 00 f1 f1 f1 f1[04]f2 f2 f2 f2 f2 f2 f2
  0x10001845e230: 04 f2 f2 f2 f2 f2 f2 f2 00 f2 f2 f2 f3 f3 f3 f3
  0x10001845e240: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10001845e250: 00 00 00 00 f1 f1 f1 f1 00 00 f2 f2 f3 f3 f3 f3
  0x10001845e260: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1
  0x10001845e270: f1 f1 00 f2 f2 f2 f3 f3 f3 f3 00 00 00 00 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:   00
  Partially addressable: 01 02 03 04 05 06 07
  Heap left redzone:   fa
  Freed heap region:   fd
  Stack left redzone:  f1
  Stack mid redzone:   f2
  Stack right redzone: f3
  Stack after return:  f5
  Stack use after scope:   f8
  Global redzone:  f9
  Global init order:   f6
  Poisoned by user:f7
  Container overflow:  fc
  Array cookie:ac
  Intra object redzone:bb
  ASan internal:   fe
  Left alloca redzone: ca
  Right alloca redzone:cb
==10998==ABORTING

'To' list:
 git log --since=1year drivers/core/ofnode.c | grep "\-by: .*@" | \
 sed 's/.*-by: //' | sort | uniq -c | sort -rn
 10 Simon Glass 
  3 Mario Six 
  2 Martin Fuzzey 
  2 Marek Vasut 
  1 Tom Rini 
  1 Masahiro Yamada 
  1 Keerthy 
  1 Jens Wiklander 
  1 Bin Meng 

Fixes: 1678754f5e2c ("core: ofnode: Fix ofnode_get_addr_index function")
Signed-off-by: Eugeniu Rosca 
---
 drivers/core/ofnode.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/core/ofnode.c b/drivers/core/ofnode.c
index 0e584c12dc88..8bb5e22555f7 100644
--- a/drivers/core/ofnode.c
+++ b/drivers/core/ofnode.c
@@ -254,14 +254,13 @@ int ofnode_read_size(ofnode node, const char *propname)
 fdt_addr_t ofnode_get_addr_index(ofnode node, int index)
 {
int na, ns;
-   fdt_size_t size;
 
if (ofnode_is_np(node)) {
const __be32 *prop_val;
uint flags;
 
prop_val = of_get_address(ofnode_to_np(node), index,
- (u64 *)&size, &flags);
+ NULL, &flags);
if (!prop_val)
return FDT_ADDR_T_NONE;
 
@@ -278,7 +277,7 @@ fdt_addr_t ofnode_get_addr_index(ofnode node, int index)
ns = ofnode_read_simple_size_cells(ofnode_get_parent(node));
return fdtdec_get_addr_size_fixed(gd->fdt_blob,

Re: [U-Boot] Revert "Ensure device tree DTS is compiled"

2019-03-09 Thread Masahiro Yamada

Hi Tom,


On Sat, Mar 9, 2019 at 8:04 AM Tom Rini  wrote:
>
> On Thu, Mar 07, 2019 at 11:13:52PM +0900, Masahiro Yamada wrote:
>
> > This reverts commit 27cb7300ffda7a3f1581f0f5a2d3bfe59b97ad67.
> >
> > I am not sure if I correctly understood the log of commit 27cb7300ffda
> > ("Ensure device tree DTS is compiled"), but the code-diff looks like
> > it was trying to solve the missed re-compilation when .dts was modified.
> >
> > Recently, commit 2737dfe096b6 ("kbuild: make arch-dtbs target PHONY")
> > fixed the issue in a more correct and more complete way.
> >
> > Anyway, since the former commit, we see a clumsy log like this:
> >
> >   make[2]: 'arch/sandbox/dts/sandbox.dtb' is up to date
> >
> > So, let's revert it.
> >
> > Signed-off-by: Masahiro Yamada 
>
> This causes tons of breakage like:
>arm:  +   rpi_0_w
> +(rpi_0_w)
> +(rpi_0_w) Device Tree Source is not correctly specified.
> +(rpi_0_w) Please define 'CONFIG_DEFAULT_DEVICE_TREE'
> +(rpi_0_w) or build with 'DEVICE_TREE=' argument
> +(rpi_0_w) make[2]: *** [arch/arm/dts/bcm2835-rpi-zero-w.dtb] Error 1
> +(rpi_0_w) make[1]: *** [dts] Error 2
> +(rpi_0_w) make: *** [sub-make] Error 2
>


This is because arch/arm/dts/Makefile
has no entry for bcm2835-rpi-zero-w.dtb.




The following patch should fix the error


diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 2a040b2..5540f1b 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -582,6 +582,7 @@ dtb-$(CONFIG_ARCH_BCM283X) += \
bcm2835-rpi-b-plus.dtb \
bcm2835-rpi-b-rev2.dtb \
bcm2835-rpi-b.dtb \
+   bcm2835-rpi-zero-w.dtb \
bcm2836-rpi-2-b.dtb \
bcm2837-rpi-3-b.dtb





The reverted commit was hiding the issue.

I believe DTB files should be explicitly associated
with CONFIG option in Makefile.
U-Boot used to work that way, and so does Linux.


I do not know how may boards are broken now, but
the right thing to do is to add dtb entries to Makefile,
the revert the bad commit.




-- 
Best Regards
Masahiro Yamada
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] dts: force dtb recompilation

2019-03-09 Thread Masahiro Yamada

Hi Patrick,


On Wed, Mar 6, 2019 at 10:31 PM Patrick Delaunay
 wrote:
>
> The dependency for .dtb = .dts is not enough in dts Makefile,
> as the dts files are dts pre-proprocessed (include dtsi files,
> as specific *-u-boot.dtsi).
>
> For arm architecture, the dependency is correctly managed in
> makefile of arch/arm/dts with .cmd files, it is needed to
> execute make in this directory.
>
> Signed-off-by: Patrick Delaunay 
> ---
> Issue see on stm32mp1 board
>
> stm32mp157c-ed1.dts is included in stm32mp157c-ev1.dts
> and dependency is not correctly managed
> (ev1 is not recompiled when ed1 is modified)


Do you still see this issue?

I do not see the problem any more
because the following commit fixed it.

commit 2737dfe096b6c34654734a5a4dc5f4b4962c5617
Author: Stephen Warren 
Date:   Tue Feb 26 12:20:25 2019 -0700

kbuild: make arch-dtbs target PHONY


Could you test it on the latest git version?





>
>  dts/Makefile | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/dts/Makefile b/dts/Makefile
> index a7a6043..bcd611f 100644
> --- a/dts/Makefile
> +++ b/dts/Makefile
> @@ -17,7 +17,6 @@ ifneq ($(EXT_DTB),)
>  DTB := $(EXT_DTB)
>  else
>  DTB := $(ARCH_PATH)/$(DEVICE_TREE).dtb
> -dtb_depends += $(DTB:.dtb=.dts)
>  endif
>
>  $(obj)/dt-spl.dtb: $(DTB) $(objtree)/tools/fdtgrep FORCE
> @@ -28,7 +27,7 @@ $(obj)/dt.dtb: $(DTB) FORCE
>
>  targets += dt.dtb dt-spl.dtb
>
> -$(DTB): $(dtb_depends)
> +$(DTB): $(dtb_depends) FORCE
>  ifeq ($(EXT_DTB),)
> $(Q)$(MAKE) $(build)=$(ARCH_PATH) $@
>  endif
> --
> 2.7.4
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot



-- 
Best Regards
Masahiro Yamada
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] ARM: dts: rmobile: Zap redundant USB/SDHI nodes on M3N

2019-03-09 Thread Marek Vasut

On 3/9/19 2:21 PM, Eugeniu Rosca wrote:
> On Sat, Mar 09, 2019 at 01:53:30AM +0100, Marek Vasut wrote:
> [..]
>> Sounds good. Can you reword the patch and submit a V2 then ?
> 
> Submitted https://patchwork.ozlabs.org/patch/1053837/

Thanks, I'll review it ASAP

-- 
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] ARM: dts: rmobile: Zap redundant USB/SDHI nodes on M3N

2019-03-09 Thread Eugeniu Rosca

On Sat, Mar 09, 2019 at 01:53:30AM +0100, Marek Vasut wrote:
[..]
> Sounds good. Can you reword the patch and submit a V2 then ?

Submitted https://patchwork.ozlabs.org/patch/1053837/

Best regards,
Eugeniu.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v2] ARM: dts: rmobile: Zap redundant USB/SDHI nodes on M3N

2019-03-09 Thread Eugeniu Rosca

v2019.01 commit cbff9f80cedd ("ARM: dts: rmobile: Sync Gen3 DTs with
Linux 4.19.6") made the sdhi/usb nodes available in r8a77965.dtsi.

Hence, remove the SDHI/USB nodes from r8a77965-u-boot.dtsi. This is
equivalent to partially reverting below v2019.01 commits:
 - f529bc551b6d ("ARM: dts: rmobile: Extract USB nodes on M3N")
 - 830b94f76867 ("ARM: dts: rmobile: Extract SDHI nodes on M3N")

Duplicating the nodes from .dtsi to -u-boot.dtsi is obviously:
 - not needed if no U-boot-specific changes are needed in those nodes.
 - potentially dangerous/error-prone, since the duplicated properties
   override the properties originally defined in .dtsi. One
   possible consequence is that .dtsi is getting an update from
   Linux, while -u-boot.dtsi stays unchanged. In this situation,
   the obsolete property values from -u-boot.dtsi will take
   precedence masking some of the .dtsi updates, potentially
   leading to all kind of obscure issues.

Below is the dtdiff of r8a77965-salvator-x-u-boot.dtb (the only "user"
of r8a77965-u-boot.dtsi) before and after the patch (slightly
reformatted to avoid 'git am/apply' issues and to reduce the width).

What below output means is there is already a mismatch in some of
SDHI/USB nodes between r8a77965.dtsi and r8a77965-u-boot.dtsi. Since no
U-Boot customization is needed in SDHI/USB DT nodes, get rid of them in
r8a77965-u-boot.dtsi.

$> dtdiff before-r8a77965-salvator-x-u-boot.dtb \
   after-r8a77965-salvator-x-u-boot.dtb
 --- /dev/fd/63  2019-03-09 12:57:40.877963983 +0100
 +++ /dev/fd/62  2019-03-09 12:57:40.877963983 +0100
 @@ -1471,7 +1471,7 @@
bus-width = <0x4>;
cd-gpios = <0x51 0xc 0x1>;
clocks = <0x6 0x1 0x13a>;
 -  compatible = "renesas,sdhi-r8a77965";
 +  compatible = "renesas,sdhi-r8a77965", "renesas,rcar-gen3-sdhi";
interrupts = <0x0 0xa5 0x4>;
max-frequency = <0xc65d400>;
pinctrl-0 = <0x4d>;
 @@ -1492,7 +1492,7 @@

  sd@ee12 {
clocks = <0x6 0x1 0x139>;
 -  compatible = "renesas,sdhi-r8a77965";
 +  compatible = "renesas,sdhi-r8a77965", "renesas,rcar-gen3-sdhi";
interrupts = <0x0 0xa6 0x4>;
max-frequency = <0xbebc200>;
power-domains = <0x1 0x20>;
 @@ -1504,7 +1504,7 @@
  sd@ee14 {
bus-width = <0x8>;
clocks = <0x6 0x1 0x138>;
 -  compatible = "renesas,sdhi-r8a77965";
 +  compatible = "renesas,sdhi-r8a77965", "renesas,rcar-gen3-sdhi";
fixed-emmc-driver-type = <0x1>;
interrupts = <0x0 0xa7 0x4>;
max-frequency = <0xbebc200>;
 @@ -1526,7 +1526,7 @@
bus-width = <0x4>;
cd-gpios = <0x5a 0xf 0x1>;
clocks = <0x6 0x1 0x137>;
 -  compatible = "renesas,sdhi-r8a77965";
 +  compatible = "renesas,sdhi-r8a77965", "renesas,rcar-gen3-sdhi";
interrupts = <0x0 0xa8 0x4>;
max-frequency = <0xc65d400>;
pinctrl-0 = <0x56>;
 @@ -1868,14 +1868,14 @@

  usb-phy@ee0a0200 {
#phy-cells = <0x0>;
 -  clocks = <0x6 0x1 0x2be>;
 +  clocks = <0x6 0x1 0x2bf>;
compatible = "renesas,usb2-phy-r8a77965", "renesas,rcar-gen3-usb2-phy";
phandle = <0x47>;
pinctrl-0 = <0x4c>;
pinctrl-names = "default";
power-domains = <0x1 0x20>;
reg = <0x0 0xee0a0200 0x0 0x700>;
 -  resets = <0x6 0x2be>;
 +  resets = <0x6 0x2bf>;
status = "okay";
  };

Signed-off-by: Eugeniu Rosca 
---

v2:
 - no code change
 - reworked the description
---
 arch/arm/dts/r8a77965-u-boot.dtsi | 99 ---
 1 file changed, 99 deletions(-)

diff --git a/arch/arm/dts/r8a77965-u-boot.dtsi 
b/arch/arm/dts/r8a77965-u-boot.dtsi
index cbd29b3aed68..ca80ef8f29ee 100644
--- a/arch/arm/dts/r8a77965-u-boot.dtsi
+++ b/arch/arm/dts/r8a77965-u-boot.dtsi
@@ -19,103 +19,4 @@
bank-width = <2>;
status = "disabled";
};
-
-   sdhi0: sd@ee10 {
-   compatible = "renesas,sdhi-r8a77965";
-   reg = <0 0xee10 0 0x2000>;
-   interrupts = ;
-   clocks = <&cpg CPG_MOD 314>;
-   max-frequency = <2>;
-   power-domains = <&sysc 32>;
-   resets = <&cpg 314>;
-   status = "disabled";
-   };
-
-   sdhi1: sd@ee12 {
-   compatible = "renesas,sdhi-r8a77965";
-   reg = <0 0xee12 0 0x2000>;
-   interrupts = ;
-   clocks = <&cpg CPG_MOD 313>;
-   max-frequency = <2>;
-   power-domains = <&sysc 32>;
-   resets = <&cpg 313>;
-   status = "disabled";
-   };
-
-   sdhi2: sd@ee14 {
-   compatible = "renesas,sdhi-r8a77965";
-   reg = <0 0xee14 0 0x2000>;
-   interrupts = ;
-   clocks = <&cpg CPG_MOD 312>;
-   max-frequency = <2>;
-   power-domains = <&sysc 32>;
-   resets = <&cpg 312>;
-

Re: [U-Boot] changes in rk3288 code have made me unable to boot u-boot on veyron speedy

Re: [U-Boot] changes in rk3288 code have made me unable to boot u-boot on veyron speedy

Re: [U-Boot] [RFC 0/9] Convert Pico-Pi i.MX7D to DM

[U-Boot] [PATCH 1/2] ddr: socfpga: Clean up EMIF reset

[U-Boot] [PATCH 2/2] ddr: socfpga: Clean up ddr_setup()

Re: [U-Boot] [PATCH V3] ddr: socfpga: Fix EMIF clear timeout

[U-Boot] [PATCH V3] ddr: socfpga: Fix EMIF clear timeout

Re: [U-Boot] Revert "Ensure device tree DTS is compiled"

Re: [U-Boot] [PATCH v2] ARM: dts: rmobile: Zap redundant USB/SDHI nodes on M3N

Re: [U-Boot] changes in rk3288 code have made me unable to boot u-boot on veyron speedy

[U-Boot] [PATCH] core: ofnode: Fix ASAN-reported stack-buffer-overflow in of_get_address

Re: [U-Boot] Revert "Ensure device tree DTS is compiled"

Re: [U-Boot] [PATCH] dts: force dtb recompilation

Re: [U-Boot] [PATCH] ARM: dts: rmobile: Zap redundant USB/SDHI nodes on M3N

Re: [U-Boot] [PATCH] ARM: dts: rmobile: Zap redundant USB/SDHI nodes on M3N

[U-Boot] [PATCH v2] ARM: dts: rmobile: Zap redundant USB/SDHI nodes on M3N

16 matches

Site Navigation

Mail list logo

Footer information