Re: [U-Boot] arm: omap: configs: various: Remove references to OMAP34XX_UARTx

2018-08-25 Thread Tom Rini 
On Sat, Aug 25, 2018 at 10:44:28PM +0300, Grazvydas Ignotas wrote:
> On Sat, Aug 25, 2018 at 7:22 PM, Tom Rini  wrote:
> > On Sat, Aug 25, 2018 at 06:58:19PM +0300, Grazvydas Ignotas wrote:
> >> On Mon, Aug 20, 2018 at 8:43 PM, Tom Rini  wrote:
> >> > On Mon, Aug 20, 2018 at 07:45:16AM -0500, Adam Ford wrote:
> >> >> On Mon, Aug 20, 2018 at 6:21 AM Tom Rini  wrote:
> >> >> >
> >> >> > On Tue, Aug 07, 2018 at 07:28:11AM -0500, Adam Ford wrote:
> >> >> >
> >> >> Wasn't there a requirement that we need to move all boards to support
> >> >> CONFIG_DM at one point?
> >> >
> >> > Yes, things should get moved to DM.  So, adding the omap3_pandora listed
> >> > maintainer to the email.
> >>
> >> I'm sorry I haven't been following u-boot development for some years,
> >> what exactly needs to be done here?
> >> I've tried enabling CONFIG_DM_SERIAL, but then the board only prints
> >> some garbage and resets. Without changes current u-boot built from git
> >> boots fine.
> >>
> >> Note that the device is old and only pre- device tree kernels are
> >> shipped and officially supported. However the mainline kernel still
> >> has incomplete board support (including device tree) for those wanting
> >> to use it.
> >
> > So over in U-Boot, we're moving towards the point where having some
> > device tree that describes the board will be a lot easier than not in
> > terms of continuing to support the board.  So, there's a few ways to
> > look at things:
> > - If you take a look at 0d43fded20e3 you can see how omap3_evm was
> >   updated to use DM_SERIAL and a bunch of other modern things.
> > - You can also just say that it's time to retire omap3_pandora from
> >   mainline U-Boot and that v2018.09 (or v2018.11, but I don't want to
> >   wait too long) is the last release with support for the platform.
> > - See if there's anyone else you know that would like to pick up and
> >   maintain the board and make the kind of changes that were made to
> >   omap3_evm.
> 
> Thanks for the info. I've sent a patch, I hope it is sufficient.

Works for me, thanks!

-- 
Tom


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

Re: [U-Boot] u-boot 2018.07/2018.09 'data abort' kernel start failure with GCC 8.2.0 on sun8i (H3)

2018-08-25 Thread Auston Stewart 
I wanted to update the list with the latest findings from the Sunxi Linux
community regarding the data abort when loading the kernel. Although early
testing implicated recent GCC, more focused testing has identified binutils
2.31 as the culprit and a specific commit causing the u-boot regression. I
apologize that I had not sufficiently isolated the various components of my
toolchain in earlier testing. Details are below, with credit for in-depth
analysis going to Jernek Skrabec and Chen-yu Tsai:


08:33  <
jernej> wens: this fixes PSCI U-Boot issue: http://sprunge.us/h0hK1k
08:33  <
jernej> why exactly, I don't know
08:34  <
jernej> I just noticed that ld from binutils-2.30 aligned secure section to
0x1000
08:34  <
jernej> but ld from binutils-2.31.1 does not (which seems to be correct
behaviour)
08:34  <
jernej> so imo, it's U-Boot issue
08:35  <
jernej> wens: can you confirm that above patch solves the issue?
09:45  <
jernej> apritzel: you wrote U-Boot PSCI code, right?
09:46  <
jernej> I think code in some cases uses absolute addresses
09:46  <
jernej> which shouldn't right?
09:55  Gerwin_J_
is now known as Gerwin_J
11:14  <
jernej> wens: it looks like if "CONSTANT(COMMONPAGESIZE)" in
arch/arm/cpu/armv7/u-boot.lds is replaced with "0x1000"
11:14  <
jernej> everything works
11:15  <
jernej> so, maybe binutils bug nevertheless?
11:30  <
jernej> wens: offending commit:
https://github.com/bminor/binutils-gdb/commit/702d167134149f420ea3bcbc194d63a2653a0c27#diff-b1d17b73566e43abd1a12620ae7b0052

11:31  <
jernej>
https://github.com/bminor/binutils-gdb/commit/702d167134149f420ea3bcbc194d63a2653a0c27

11:31  <
jernej> if it is reverted, U-Boot works
12:54  <
jernej> they changed a place where config.commonpagesize is set
12:54  <
jernej> I think that is the issue
12:54  <
jernej> I already filled a bug to binutils bugzilla
12:54  <
jernej> let's see what they think
13:23  
the result is __secure_start is completely not aligned (except for 4 byte
alignment of course)
13:25  
neither are the interrupt vectors for secure mode
13:25  
and there's also a gap between __secure_start and the interrupt vectors

On Tue, Aug 21, 2018 at 3:42 PM Auston Stewart 
wrote:

> Apologies! I just realized I had my SD cards mixed up. 2018.05 compiled
> with GCC 8.2.0 isn't working either, although I just see a 'resetting'
> message rather than the full dump. The 2018.05 installation I saw booting
> successfully was compiled using earlier GCC.
>
> On Tue, Aug 21, 2018 at 3:17 PM Auston Stewart 
> wrote:
>
>> I tested another configuration to further isolate the issue:
>>
>> u-boot 2018.05 / nanopi_neo_defconfig / GCC 8.2.0 + Linux 4.17.14 / GCC
>> 8.2.0 = works
>>
>> So something introduced between 2018.05 GA and 2018.07 GA associated with
>> Sunxi H3 configs is rubbing GCC 8.2.0 the wrong way.
>>
>> On Tue, Aug 21, 2018 at 1:41 PM Heinrich Schuchardt 
>> wrote:
>>
>>> CC: ARM SUNXI maintainers
>>>
>>> On 08/22/2018 01:31 AM, Heinrich Schuchardt wrote:
>>> > On 08/22/2018 01:05 AM, Auston Stewart wrote:
>>> >> Greetings,
>>> >>
>>> >>   As others have reported
>>> >> (https://lists.denx.de/pipermail/u-boot/2018-July/334126.html), a
>>> 'data
>>> >> abort' occurs when attempting to load the kernel with recent u-boot
>>> >> compiled with recent GCC on Allwinner (Sunxi) H3 boards. I ran into
>>> this
>>> >> issue when performing a bootstrap of Shedbuilt GNU/Linux with upstream
>>> >> GCC 8.20, glibc 2.28 and binutils 2.31.1 on a Nano Pi Neo 512M board.
>>> >>   I brought up this issue in IRC and did some debugging

Re: [U-Boot] arm: omap: configs: various: Remove references to OMAP34XX_UARTx

2018-08-25 Thread Grazvydas Ignotas 
On Sat, Aug 25, 2018 at 7:22 PM, Tom Rini  wrote:
> On Sat, Aug 25, 2018 at 06:58:19PM +0300, Grazvydas Ignotas wrote:
>> On Mon, Aug 20, 2018 at 8:43 PM, Tom Rini  wrote:
>> > On Mon, Aug 20, 2018 at 07:45:16AM -0500, Adam Ford wrote:
>> >> On Mon, Aug 20, 2018 at 6:21 AM Tom Rini  wrote:
>> >> >
>> >> > On Tue, Aug 07, 2018 at 07:28:11AM -0500, Adam Ford wrote:
>> >> >
>> >> Wasn't there a requirement that we need to move all boards to support
>> >> CONFIG_DM at one point?
>> >
>> > Yes, things should get moved to DM.  So, adding the omap3_pandora listed
>> > maintainer to the email.
>>
>> I'm sorry I haven't been following u-boot development for some years,
>> what exactly needs to be done here?
>> I've tried enabling CONFIG_DM_SERIAL, but then the board only prints
>> some garbage and resets. Without changes current u-boot built from git
>> boots fine.
>>
>> Note that the device is old and only pre- device tree kernels are
>> shipped and officially supported. However the mainline kernel still
>> has incomplete board support (including device tree) for those wanting
>> to use it.
>
> So over in U-Boot, we're moving towards the point where having some
> device tree that describes the board will be a lot easier than not in
> terms of continuing to support the board.  So, there's a few ways to
> look at things:
> - If you take a look at 0d43fded20e3 you can see how omap3_evm was
>   updated to use DM_SERIAL and a bunch of other modern things.
> - You can also just say that it's time to retire omap3_pandora from
>   mainline U-Boot and that v2018.09 (or v2018.11, but I don't want to
>   wait too long) is the last release with support for the platform.
> - See if there's anyone else you know that would like to pick up and
>   maintain the board and make the kind of changes that were made to
>   omap3_evm.

Thanks for the info. I've sent a patch, I hope it is sufficient.

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

[U-Boot] [PATCH] omap3: pandora: Enable DM_SERIAL

2018-08-25 Thread Grazvydas Ignotas 
This patch enables DM_SERIAL for the pandora board. Verified that
the default kernel can still be booted with this.

Signed-off-by: Grazvydas Ignotas 
---
 board/pandora/pandora.c | 14 ++
 configs/omap3_pandora_defconfig |  4 +++-
 include/configs/omap3_pandora.h | 17 -
 3 files changed, 17 insertions(+), 18 deletions(-)

diff --git a/board/pandora/pandora.c b/board/pandora/pandora.c
index 4f91dc3bee..a9aae7951d 100644
--- a/board/pandora/pandora.c
+++ b/board/pandora/pandora.c
@@ -13,6 +13,8 @@
  * Texas Instruments, 
  */
 #include 
+#include 
+#include 
 #include 
 #include 
 #include 
@@ -33,6 +35,18 @@ DECLARE_GLOBAL_DATA_PTR;
 #define GPIO_IO_PWRDNZ (1 << 6)
 #define PBIASLITEVMODE1(1 << 8)
 
+static const struct ns16550_platdata pandora_serial = {
+   .base = OMAP34XX_UART3,
+   .reg_shift = 2,
+   .clock = V_NS16550_CLK,
+   .fcr = UART_FCR_DEFVAL,
+};
+
+U_BOOT_DEVICE(pandora_uart) = {
+   "ns16550_serial",
+   _serial
+};
+
 /*
  * Routine: board_init
  * Description: Early hardware init.
diff --git a/configs/omap3_pandora_defconfig b/configs/omap3_pandora_defconfig
index 6dce53834d..c2b4a4f0d2 100644
--- a/configs/omap3_pandora_defconfig
+++ b/configs/omap3_pandora_defconfig
@@ -1,6 +1,7 @@
 CONFIG_ARM=y
 CONFIG_ARCH_OMAP2PLUS=y
 CONFIG_SYS_TEXT_BASE=0x80008000
+CONFIG_SYS_MALLOC_F_LEN=0x2000
 CONFIG_TARGET_OMAP3_PANDORA=y
 CONFIG_DISTRO_DEFAULTS=y
 CONFIG_NR_DRAM_BANKS=2
@@ -25,11 +26,12 @@ CONFIG_MTDIDS_DEFAULT="nand0=omap2-nand.0"
 
CONFIG_MTDPARTS_DEFAULT="mtdparts=omap2-nand.0:512k(xloader),1920k(uboot),128k(uboot-env),10m(boot),-(rootfs)"
 CONFIG_CMD_UBI=y
 CONFIG_ENV_IS_IN_NAND=y
+CONFIG_DM=y
 CONFIG_TWL4030_LED=y
 CONFIG_MMC_OMAP_HS=y
 CONFIG_NAND=y
 CONFIG_SYS_NAND_BUSWIDTH_16BIT=y
-CONFIG_CONS_INDEX=3
+CONFIG_DM_SERIAL=y
 CONFIG_SYS_NS16550=y
 CONFIG_SPI=y
 CONFIG_OMAP3_SPI=y
diff --git a/include/configs/omap3_pandora.h b/include/configs/omap3_pandora.h
index 5a82cbee71..82c66c4b8c 100644
--- a/include/configs/omap3_pandora.h
+++ b/include/configs/omap3_pandora.h
@@ -19,23 +19,6 @@
 
 #define CONFIG_SYS_DEVICE_NULLDEV  1
 
-/*
- * Hardware drivers
- */
-
-/* TWL4030 LED */
-
-/*
- * NS16550 Configuration
- */
-#undef CONFIG_SYS_NS16550_CLK
-#define CONFIG_SYS_NS16550_SERIAL
-#define CONFIG_SYS_NS16550_REG_SIZE(-4)
-#define CONFIG_SYS_NS16550_CLK V_NS16550_CLK
-#define CONFIG_SYS_NS16550_COM3OMAP34XX_UART3
-
-/* commands to include */
-
 /*
  * Board NAND Info.
  */
-- 
2.17.1

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

[U-Boot] [PATCH] mtd: spi: Add DM support to SH QSPI driver

2018-08-25 Thread Marek Vasut 
Add DM support to the SH QSPI driver while retaining non-DM support.
The later is required as this driver is used in SPL which has a size
limitation of 16 kiB.

Signed-off-by: Marek Vasut 
Cc: Nobuhiro Iwamatsu 
---
 drivers/spi/sh_qspi.c | 215 +++---
 1 file changed, 150 insertions(+), 65 deletions(-)

diff --git a/drivers/spi/sh_qspi.c b/drivers/spi/sh_qspi.c
index e9123e2c39..64dfd748d6 100644
--- a/drivers/spi/sh_qspi.c
+++ b/drivers/spi/sh_qspi.c
@@ -67,15 +67,12 @@ struct sh_qspi_regs {
 };
 
 struct sh_qspi_slave {
+#ifndef CONFIG_DM_SPI
struct spi_slaveslave;
+#endif
struct sh_qspi_regs *regs;
 };
 
-static inline struct sh_qspi_slave *to_sh_qspi(struct spi_slave *slave)
-{
-   return container_of(slave, struct sh_qspi_slave, slave);
-}
-
 static void sh_qspi_init(struct sh_qspi_slave *ss)
 {
/* QSPI initialize */
@@ -119,15 +116,8 @@ static void sh_qspi_init(struct sh_qspi_slave *ss)
setbits_8(>regs->spcr, SPCR_SPE);
 }
 
-int spi_cs_is_valid(unsigned int bus, unsigned int cs)
-{
-   return 1;
-}
-
-void spi_cs_activate(struct spi_slave *slave)
+static void sh_qspi_cs_activate(struct sh_qspi_slave *ss)
 {
-   struct sh_qspi_slave *ss = to_sh_qspi(slave);
-
/* Set master mode only */
writeb(SPCR_MSTR, >regs->spcr);
 
@@ -147,61 +137,15 @@ void spi_cs_activate(struct spi_slave *slave)
setbits_8(>regs->spcr, SPCR_SPE);
 }
 
-void spi_cs_deactivate(struct spi_slave *slave)
+static void sh_qspi_cs_deactivate(struct sh_qspi_slave *ss)
 {
-   struct sh_qspi_slave *ss = to_sh_qspi(slave);
-
/* Disable SPI Function */
clrbits_8(>regs->spcr, SPCR_SPE);
 }
 
-void spi_init(void)
-{
-   /* nothing to do */
-}
-
-struct spi_slave *spi_setup_slave(unsigned int bus, unsigned int cs,
-   unsigned int max_hz, unsigned int mode)
-{
-   struct sh_qspi_slave *ss;
-
-   if (!spi_cs_is_valid(bus, cs))
-   return NULL;
-
-   ss = spi_alloc_slave(struct sh_qspi_slave, bus, cs);
-   if (!ss) {
-   printf("SPI_error: Fail to allocate sh_qspi_slave\n");
-   return NULL;
-   }
-
-   ss->regs = (struct sh_qspi_regs *)SH_QSPI_BASE;
-
-   /* Init SH QSPI */
-   sh_qspi_init(ss);
-
-   return >slave;
-}
-
-void spi_free_slave(struct spi_slave *slave)
+static int sh_qspi_xfer_common(struct sh_qspi_slave *ss, unsigned int bitlen,
+  const void *dout, void *din, unsigned long flags)
 {
-   struct sh_qspi_slave *spi = to_sh_qspi(slave);
-
-   free(spi);
-}
-
-int spi_claim_bus(struct spi_slave *slave)
-{
-   return 0;
-}
-
-void spi_release_bus(struct spi_slave *slave)
-{
-}
-
-int spi_xfer(struct spi_slave *slave, unsigned int bitlen, const void *dout,
-void *din, unsigned long flags)
-{
-   struct sh_qspi_slave *ss = to_sh_qspi(slave);
u32 nbyte, chunk;
int i, ret = 0;
u8 dtdata = 0, drdata;
@@ -210,7 +154,7 @@ int spi_xfer(struct spi_slave *slave, unsigned int bitlen, 
const void *dout,
 
if (dout == NULL && din == NULL) {
if (flags & SPI_XFER_END)
-   spi_cs_deactivate(slave);
+   sh_qspi_cs_deactivate(ss);
return 0;
}
 
@@ -222,7 +166,7 @@ int spi_xfer(struct spi_slave *slave, unsigned int bitlen, 
const void *dout,
nbyte = bitlen / 8;
 
if (flags & SPI_XFER_BEGIN) {
-   spi_cs_activate(slave);
+   sh_qspi_cs_activate(ss);
 
/* Set 1048576 byte */
writel(0x10, spbmul0);
@@ -273,7 +217,148 @@ int spi_xfer(struct spi_slave *slave, unsigned int 
bitlen, const void *dout,
}
 
if (flags & SPI_XFER_END)
-   spi_cs_deactivate(slave);
+   sh_qspi_cs_deactivate(ss);
 
return ret;
 }
+
+#ifndef CONFIG_DM_SPI
+static inline struct sh_qspi_slave *to_sh_qspi(struct spi_slave *slave)
+{
+   return container_of(slave, struct sh_qspi_slave, slave);
+}
+
+int spi_cs_is_valid(unsigned int bus, unsigned int cs)
+{
+   return 1;
+}
+
+void spi_cs_activate(struct spi_slave *slave)
+{
+   struct sh_qspi_slave *ss = to_sh_qspi(slave);
+
+   sh_qspi_cs_activate(ss);
+}
+
+void spi_cs_deactivate(struct spi_slave *slave)
+{
+   struct sh_qspi_slave *ss = to_sh_qspi(slave);
+
+   sh_qspi_cs_deactivate(ss);
+}
+
+void spi_init(void)
+{
+   /* nothing to do */
+}
+
+struct spi_slave *spi_setup_slave(unsigned int bus, unsigned int cs,
+   unsigned int max_hz, unsigned int mode)
+{
+   struct sh_qspi_slave *ss;
+
+   if (!spi_cs_is_valid(bus, cs))
+   return NULL;
+
+   ss = spi_alloc_slave(struct sh_qspi_slave, bus, cs);
+   if (!ss) {
+   printf("SPI_error: Fail to allocate sh_qspi_slave\n");
+   return NULL;
+   }
+
+   ss->regs = (struct

Re: [U-Boot] arm: omap: configs: various: Remove references to OMAP34XX_UARTx

2018-08-25 Thread Tom Rini 
On Sat, Aug 25, 2018 at 06:58:19PM +0300, Grazvydas Ignotas wrote:
> On Mon, Aug 20, 2018 at 8:43 PM, Tom Rini  wrote:
> > On Mon, Aug 20, 2018 at 07:45:16AM -0500, Adam Ford wrote:
> >> On Mon, Aug 20, 2018 at 6:21 AM Tom Rini  wrote:
> >> >
> >> > On Tue, Aug 07, 2018 at 07:28:11AM -0500, Adam Ford wrote:
> >> >
> >> > > Two boards include a reference to ti_omap3_common.h which
> >> > > points the UART driver to OMAP34XX_UARTx so the extra define
> >> > > should be unnecessary.
> >> > >
> >> > > Signed-off-by: Adam Ford 
> >> > > ---
> >> > >  include/configs/omap3_evm.h | 1 -
> >> > >  include/configs/omap3_pandora.h | 1 -
> >> > >  2 files changed, 2 deletions(-)
> >> > >
> >> > > diff --git a/include/configs/omap3_evm.h b/include/configs/omap3_evm.h
> >> > > index 34418309cb..779087a949 100644
> >> > > --- a/include/configs/omap3_evm.h
> >> > > +++ b/include/configs/omap3_evm.h
> >> > > @@ -34,7 +34,6 @@
> >> > >  #define CONFIG_REVISION_TAG
> >> > >
> >> > >  /* Override OMAP3 serial console configuration */
> >> > > -#define CONFIG_SYS_NS16550_COM1 OMAP34XX_UART1
> >> > >
> >> > >  /* NAND */
> >> > >  #if defined(CONFIG_NAND)
> >> > > diff --git a/include/configs/omap3_pandora.h 
> >> > > b/include/configs/omap3_pandora.h
> >> > > index 68e1d6f82d..1fc40e05ff 100644
> >> > > --- a/include/configs/omap3_pandora.h
> >> > > +++ b/include/configs/omap3_pandora.h
> >> > > @@ -36,7 +36,6 @@
> >> > >  #define CONFIG_SYS_NS16550_SERIAL
> >> > >  #define CONFIG_SYS_NS16550_REG_SIZE  (-4)
> >> > >  #define CONFIG_SYS_NS16550_CLK   V_NS16550_CLK
> >> > > -#define CONFIG_SYS_NS16550_COM3  OMAP34XX_UART3
> >> > >
> >> > >  /* commands to include */
> >> >
> >> > This results in:
> >> > +(omap3_pandora) ../drivers/serial/serial_ns16550.c:31:2: error: #error 
> >> > "Console port 3 defined but not configured."
> >> > +(omap3_pandora)  #error "Console port 3 defined but not configured."
> >> > +(omap3_pandora)   ^
> >> > +(omap3_pandora) make[2]: *** [../scripts/Makefile.build:279: 
> >> > drivers/serial/serial_ns16550.o] Error 1
> >> > +(omap3_pandora) make[1]: *** [Makefile:1373: drivers/serial] Error 2
> >>
> >> argh.  I made the assumption that people who include ti_omap3_common.h
> >> migrated to DM.
> >>  I could go back and modify ti_omap3_common.h to wrap
> >> the  CONFIG_SYS_NS16550_COMx entries under #if !defined(DM_SERIAL)
> >> instead of CONFIG_SPL_BUILD
> >>
> >> Do you have an opinion?  I may not get back to this before I leave on
> >> my trip, but I can take a look again in 2 weeks when I return.
> >>
> >> Wasn't there a requirement that we need to move all boards to support
> >> CONFIG_DM at one point?
> >
> > Yes, things should get moved to DM.  So, adding the omap3_pandora listed
> > maintainer to the email.
> 
> I'm sorry I haven't been following u-boot development for some years,
> what exactly needs to be done here?
> I've tried enabling CONFIG_DM_SERIAL, but then the board only prints
> some garbage and resets. Without changes current u-boot built from git
> boots fine.
> 
> Note that the device is old and only pre- device tree kernels are
> shipped and officially supported. However the mainline kernel still
> has incomplete board support (including device tree) for those wanting
> to use it.

So over in U-Boot, we're moving towards the point where having some
device tree that describes the board will be a lot easier than not in
terms of continuing to support the board.  So, there's a few ways to
look at things:
- If you take a look at 0d43fded20e3 you can see how omap3_evm was
  updated to use DM_SERIAL and a bunch of other modern things.
- You can also just say that it's time to retire omap3_pandora from
  mainline U-Boot and that v2018.09 (or v2018.11, but I don't want to
  wait too long) is the last release with support for the platform.
- See if there's anyone else you know that would like to pick up and
  maintain the board and make the kind of changes that were made to
  omap3_evm.

-- 
Tom


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

Re: [U-Boot] arm: omap: configs: various: Remove references to OMAP34XX_UARTx

2018-08-25 Thread Grazvydas Ignotas 
On Mon, Aug 20, 2018 at 8:43 PM, Tom Rini  wrote:
> On Mon, Aug 20, 2018 at 07:45:16AM -0500, Adam Ford wrote:
>> On Mon, Aug 20, 2018 at 6:21 AM Tom Rini  wrote:
>> >
>> > On Tue, Aug 07, 2018 at 07:28:11AM -0500, Adam Ford wrote:
>> >
>> > > Two boards include a reference to ti_omap3_common.h which
>> > > points the UART driver to OMAP34XX_UARTx so the extra define
>> > > should be unnecessary.
>> > >
>> > > Signed-off-by: Adam Ford 
>> > > ---
>> > >  include/configs/omap3_evm.h | 1 -
>> > >  include/configs/omap3_pandora.h | 1 -
>> > >  2 files changed, 2 deletions(-)
>> > >
>> > > diff --git a/include/configs/omap3_evm.h b/include/configs/omap3_evm.h
>> > > index 34418309cb..779087a949 100644
>> > > --- a/include/configs/omap3_evm.h
>> > > +++ b/include/configs/omap3_evm.h
>> > > @@ -34,7 +34,6 @@
>> > >  #define CONFIG_REVISION_TAG
>> > >
>> > >  /* Override OMAP3 serial console configuration */
>> > > -#define CONFIG_SYS_NS16550_COM1 OMAP34XX_UART1
>> > >
>> > >  /* NAND */
>> > >  #if defined(CONFIG_NAND)
>> > > diff --git a/include/configs/omap3_pandora.h 
>> > > b/include/configs/omap3_pandora.h
>> > > index 68e1d6f82d..1fc40e05ff 100644
>> > > --- a/include/configs/omap3_pandora.h
>> > > +++ b/include/configs/omap3_pandora.h
>> > > @@ -36,7 +36,6 @@
>> > >  #define CONFIG_SYS_NS16550_SERIAL
>> > >  #define CONFIG_SYS_NS16550_REG_SIZE  (-4)
>> > >  #define CONFIG_SYS_NS16550_CLK   V_NS16550_CLK
>> > > -#define CONFIG_SYS_NS16550_COM3  OMAP34XX_UART3
>> > >
>> > >  /* commands to include */
>> >
>> > This results in:
>> > +(omap3_pandora) ../drivers/serial/serial_ns16550.c:31:2: error: #error 
>> > "Console port 3 defined but not configured."
>> > +(omap3_pandora)  #error "Console port 3 defined but not configured."
>> > +(omap3_pandora)   ^
>> > +(omap3_pandora) make[2]: *** [../scripts/Makefile.build:279: 
>> > drivers/serial/serial_ns16550.o] Error 1
>> > +(omap3_pandora) make[1]: *** [Makefile:1373: drivers/serial] Error 2
>>
>> argh.  I made the assumption that people who include ti_omap3_common.h
>> migrated to DM.
>>  I could go back and modify ti_omap3_common.h to wrap
>> the  CONFIG_SYS_NS16550_COMx entries under #if !defined(DM_SERIAL)
>> instead of CONFIG_SPL_BUILD
>>
>> Do you have an opinion?  I may not get back to this before I leave on
>> my trip, but I can take a look again in 2 weeks when I return.
>>
>> Wasn't there a requirement that we need to move all boards to support
>> CONFIG_DM at one point?
>
> Yes, things should get moved to DM.  So, adding the omap3_pandora listed
> maintainer to the email.

I'm sorry I haven't been following u-boot development for some years,
what exactly needs to be done here?
I've tried enabling CONFIG_DM_SERIAL, but then the board only prints
some garbage and resets. Without changes current u-boot built from git
boots fine.

Note that the device is old and only pre- device tree kernels are
shipped and officially supported. However the mainline kernel still
has incomplete board support (including device tree) for those wanting
to use it.

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

Re: [U-Boot] Pull request: u-boot-sunxi/master

2018-08-25 Thread Tom Rini 
On Fri, Aug 24, 2018 at 02:20:51PM +0530, Jagan Teki wrote:

> Hi Tom,
> 
> Please pull this PR.
> 
> thanks,
> Jagan.
> 
> The following changes since commit b71d9e8b3805305ea4116733f515061710ad7081:
> 
>   Merge branch 'master' of git://git.denx.de/u-boot-sunxi (2018-08-20 
> 13:41:56 -0400)
> 
> are available in the Git repository at:
> 
>   git://git.denx.de/u-boot-sunxi.git master
> 
> for you to fetch changes up to 12069bd0466a87015dd40bb25c6b2571ee5f0851:
> 
>   usb: musb-new: Call musb_platform_exit from musb_stop (2018-08-23 17:31:24 
> +0530)
> 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [PULL] u-boot-usb/master

2018-08-25 Thread Tom Rini 
On Fri, Aug 24, 2018 at 08:21:46PM +0200, Marek Vasut wrote:

> The following changes since commit 9f8cf76be256a83643ee05de6cffaeb452ed0931:
> 
>   Convert CONFIG_SYS_I2C_DAVINCI to Kconfig (2018-08-17 15:43:38 -0400)
> 
> are available in the Git repository at:
> 
>   git://git.denx.de/u-boot-usb.git master
> 
> for you to fetch changes up to 49c752c93a785b9bad9d3fbbd52a76bec003eac5:
> 
>   cmd: Add bind/unbind commands to bind a device to a driver from the
> command line (2018-08-21 16:21:37 +0200)
> 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [PULL] u-boot-socfpga/master

2018-08-25 Thread Tom Rini 
On Fri, Aug 24, 2018 at 08:25:33PM +0200, Marek Vasut wrote:

> The following changes since commit 2418734ed429058b396d2aeb6b91f875cdc8e4ce:
> 
>   Merge branch 'master' of git://git.denx.de/u-boot-tegra (2018-08-22
> 22:36:08 -0400)
> 
> are available in the Git repository at:
> 
>   git://git.denx.de/u-boot-socfpga.git master
> 
> for you to fetch changes up to a029f540c54c39847c329fc70b1b2e0ab6dedbcd:
> 
>   ARM: dts: socfpga: Add missing NAND reset (2018-08-24 12:05:21 +0200)
> 

Applied to u-boot/master, thanks!

-- 
Tom


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