On Sat, Aug 25, 2018 at 06:58:19PM +0300, Grazvydas Ignotas wrote:
On Mon, Aug 20, 2018 at 8:43 PM, Tom Rini trini@konsulko.com 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 trini@konsulko.com 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 aford173@gmail.com
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.