This patch series adds support for Liebherr's BK3 board, being
a derivative of TS72XX design.
This patchset consists of following patches:
- ts72xx.[c|h] cosmetic cleanup/improvement
- Rewrite ts72xx.c to be reusable by bk3
- The Liebherr's BK3 board has been added with re-using code of
ts72xx.c (detalied list of changes can be found in patch 4/4)
This series applies on top of linux-next/master (next-20171211)
Lukasz Majewski (4):
ARM: ep93xx: ts72xx: Provide include guards for ts72xx.h file
ARM: ep93xx: ts72xx: Rewrite ts72xx_register_flash() to accept
parameters
ARM: ep93xx: ts72xx: cosmetic: Add some description to ts72xx code
ARM: ep93xx: ts72xx: Add support for BK3 board - ts72xx derivative
MAINTAINERS | 6 ++
arch/arm/mach-ep93xx/Kconfig | 7 ++
arch/arm/mach-ep93xx/ts72xx.c | 165 +++++++++++++++++++++++++++++++++++++++---
arch/arm/mach-ep93xx/ts72xx.h | 9 +++
arch/arm/tools/mach-types | 1 +
5 files changed, 176 insertions(+), 12 deletions(-)
--
2.11.0
This commit adds include file guards to ts72xx.h
Signed-off-by: Lukasz Majewski <[email protected]>
Acked-by: Alexander Sverdlin <[email protected]>
---
Changes for v2:
- None
Changes for v3:
- None
Changes for v4:
- None
Changes for v5:
- None
---
arch/arm/mach-ep93xx/ts72xx.h | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm/mach-ep93xx/ts72xx.h b/arch/arm/mach-ep93xx/ts72xx.h
index 8a3206a54b39..7b7490f10fa9 100644
--- a/arch/arm/mach-ep93xx/ts72xx.h
+++ b/arch/arm/mach-ep93xx/ts72xx.h
@@ -12,6 +12,9 @@
* febfd000 22800000 4K options register #2
*/
+#ifndef __TS72XX_H_
+#define __TS72XX_H_
+
#define TS72XX_MODEL_PHYS_BASE 0x22000000
#define TS72XX_MODEL_VIRT_BASE IOMEM(0xfebff000)
#define TS72XX_MODEL_SIZE 0x00001000
@@ -83,3 +86,4 @@ static inline int is_ts9420_installed(void)
TS72XX_OPTIONS2_TS9420);
}
#endif
+#endif /* __TS72XX_H_ */
--
2.11.0
The BK3 board is a derivative of the ts72xx reference design.
Signed-off-by: Lukasz Majewski <[email protected]>
---
Changes for v2:
- Place bk3 support code to the ts72xx.c file
Changes for v3:
- Add SD card support (via SPI) for BK3
- Remove definition of apb:i2s bus
- Remove board registration of CPLD WDT device
- Add I2S platform device to BK3
- Add MAINTAINERS entry for BK3 maintainer
Changes for v4:
- Adjust the code to be applicable on top of linux-next/master
Changes for v5:
- Combine map_io to be reused across all ts72xx boards
---
MAINTAINERS | 6 ++
arch/arm/mach-ep93xx/Kconfig | 7 +++
arch/arm/mach-ep93xx/ts72xx.c | 136 ++++++++++++++++++++++++++++++++++++++++++
arch/arm/mach-ep93xx/ts72xx.h | 5 ++
arch/arm/tools/mach-types | 1 +
5 files changed, 155 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 7d195739f892..17e1263b085d 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1258,6 +1258,12 @@ L: [email protected] (moderated for non-subscribers)
S: Supported
F: drivers/net/ethernet/cavium/thunder/
+ARM/CIRRUS LOGIC BK3 MACHINE SUPPORT
+M: Lukasz Majewski <[email protected]>
+L: [email protected] (moderated for non-subscribers)
+S: Maintained
+F: arch/arm/mach-ep93xx/ts72xx.c
+
ARM/CIRRUS LOGIC CLPS711X ARM ARCHITECTURE
M: Alexander Shiyan <[email protected]>
L: [email protected] (moderated for non-subscribers)
diff --git a/arch/arm/mach-ep93xx/Kconfig b/arch/arm/mach-ep93xx/Kconfig
index 61a75ca3684e..c095236d7ff8 100644
--- a/arch/arm/mach-ep93xx/Kconfig
+++ b/arch/arm/mach-ep93xx/Kconfig
@@ -21,6 +21,13 @@ config MACH_ADSSPHERE
Say 'Y' here if you want your kernel to support the ADS
Sphere board.
+config MACH_BK3
+ bool "Support Liebherr BK3.1"
+ select MACH_TS72XX
+ help
+ Say 'Y' here if you want your kernel to support the
+ Liebherr controller BK3.1.
+
config MACH_EDB93XX
bool
diff --git a/arch/arm/mach-ep93xx/ts72xx.c b/arch/arm/mach-ep93xx/ts72xx.c
index 17af9d834b51..c089a2a4fe30 100644
--- a/arch/arm/mach-ep93xx/ts72xx.c
+++ b/arch/arm/mach-ep93xx/ts72xx.c
@@ -19,10 +19,15 @@
#include <linux/mtd/rawnand.h>
#include <linux/mtd/partitions.h>
#include <linux/spi/spi.h>
+#include <linux/spi/flash.h>
+#include <linux/spi/mmc_spi.h>
+#include <linux/mmc/host.h>
#include <linux/platform_data/spi-ep93xx.h>
#include <mach/gpio-ep93xx.h>
#include <mach/hardware.h>
+#include <mach/irqs.h>
+#include <mach/gpio-ep93xx.h>
#include <asm/mach-types.h>
#include <asm/mach/map.h>
@@ -50,6 +55,11 @@ static struct map_desc ts72xx_io_desc[] __initdata = {
.pfn = __phys_to_pfn(TS72XX_OPTIONS2_PHYS_BASE),
.length = TS72XX_OPTIONS2_SIZE,
.type = MT_DEVICE,
+ }, {
+ .virtual = (unsigned long)TS72XX_CPLDVER_VIRT_BASE,
+ .pfn = __phys_to_pfn(TS72XX_CPLDVER_PHYS_BASE),
+ .length = TS72XX_CPLDVER_SIZE,
+ .type = MT_DEVICE,
}
};
@@ -212,6 +222,69 @@ static struct ep93xx_eth_data __initdata ts72xx_eth_data = {
};
/*************************************************************************
+ * SPI SD/MMC host
+ *************************************************************************/
+#define BK3_EN_SDCARD_PHYS_BASE 0x12400000
+#define BK3_EN_SDCARD_PWR 0x0
+#define BK3_DIS_SDCARD_PWR 0x0C
+static void bk3_mmc_spi_setpower(struct device *dev, unsigned int vdd)
+{
+ void __iomem *pwr_sd = ioremap(BK3_EN_SDCARD_PHYS_BASE, SZ_4K);
+
+ if (!pwr_sd) {
+ pr_err("Failed to enable SD card power!");
+ return;
+ }
+
+ pr_debug("%s: SD card pwr %s VDD:0x%x\n", __func__,
+ !!vdd ? "ON" : "OFF", vdd);
+
+ if (!!vdd)
+ __raw_writeb(BK3_EN_SDCARD_PWR, pwr_sd);
+ else
+ __raw_writeb(BK3_DIS_SDCARD_PWR, pwr_sd);
+
+ iounmap(pwr_sd);
+}
+
+static struct mmc_spi_platform_data bk3_spi_mmc_data = {
+ .detect_delay = 500,
+ .powerup_msecs = 100,
+ .ocr_mask = MMC_VDD_32_33 | MMC_VDD_33_34,
+ .caps = MMC_CAP_NONREMOVABLE,
+ .setpower = bk3_mmc_spi_setpower,
+};
+
+/*************************************************************************
+ * SPI Bus - SD card access
+ *************************************************************************/
+static struct spi_board_info bk3_spi_board_info[] __initdata = {
+ {
+ .modalias = "mmc_spi",
+ .platform_data = &bk3_spi_mmc_data,
+ .max_speed_hz = 7.4E6,
+ .bus_num = 0,
+ .chip_select = 0,
+ .mode = SPI_MODE_0,
+ },
+};
+
+/*
+ * This is a stub -> the FGPIO[3] pin is not connected on the schematic
+ * The all work is performed automatically by !SPI_FRAME (SFRM1) and
+ * goes through CPLD
+ */
+static int bk3_spi_chipselects[] __initdata = {
+ EP93XX_GPIO_LINE_F(3),
+};
+
+static struct ep93xx_spi_info bk3_spi_master __initdata = {
+ .chipselect = bk3_spi_chipselects,
+ .num_chipselect = ARRAY_SIZE(bk3_spi_chipselects),
+ .use_dma = 1,
+};
+
+/*************************************************************************
* TS72XX support code
*************************************************************************/
#if IS_ENABLED(CONFIG_FPGA_MGR_TS73XX)
@@ -285,3 +358,66 @@ MACHINE_START(TS72XX, "Technologic Systems TS-72xx SBC")
.init_late = ep93xx_init_late,
.restart = ep93xx_restart,
MACHINE_END
+
+/*************************************************************************
+ * EP93xx I2S audio peripheral handling
+ *************************************************************************/
+static struct resource ep93xx_i2s_resource[] = {
+ DEFINE_RES_MEM(EP93XX_I2S_PHYS_BASE, 0x100),
+ DEFINE_RES_IRQ_NAMED(IRQ_EP93XX_SAI, "spilink i2s slave"),
+};
+
+static struct platform_device ep93xx_i2s_device = {
+ .name = "ep93xx-spilink-i2s",
+ .id = -1,
+ .num_resources = ARRAY_SIZE(ep93xx_i2s_resource),
+ .resource = ep93xx_i2s_resource,
+};
+
+/*************************************************************************
+ * BK3 support code
+ *************************************************************************/
+static struct mtd_partition bk3_nand_parts[] = {
+ {
+ .name = "System",
+ .offset = 0x00000000,
+ .size = 0x01e00000,
+ }, {
+ .name = "Data",
+ .offset = 0x01e00000,
+ .size = 0x05f20000
+ }, {
+ .name = "RedBoot",
+ .offset = 0x07d20000,
+ .size = 0x002e0000,
+ .mask_flags = MTD_WRITEABLE, /* force RO */
+ },
+};
+
+static void __init bk3_init_machine(void)
+{
+ ep93xx_init_devices();
+
+ ts72xx_register_flash(bk3_nand_parts, ARRAY_SIZE(bk3_nand_parts),
+ EP93XX_CS6_PHYS_BASE);
+
+ ep93xx_register_eth(&ts72xx_eth_data, 1);
+
+ ep93xx_register_spi(&bk3_spi_master, bk3_spi_board_info,
+ ARRAY_SIZE(bk3_spi_board_info));
+
+ /* Configure ep93xx's I2S to use AC97 pins */
+ ep93xx_devcfg_set_bits(EP93XX_SYSCON_DEVCFG_I2SONAC97);
+ platform_device_register(&ep93xx_i2s_device);
+}
+
+MACHINE_START(BK3, "Liebherr controller BK3.1")
+ /* Maintainer: Lukasz Majewski <[email protected]> */
+ .atag_offset = 0x100,
+ .map_io = ts72xx_map_io,
+ .init_irq = ep93xx_init_irq,
+ .init_time = ep93xx_timer_init,
+ .init_machine = bk3_init_machine,
+ .init_late = ep93xx_init_late,
+ .restart = ep93xx_restart,
+MACHINE_END
diff --git a/arch/arm/mach-ep93xx/ts72xx.h b/arch/arm/mach-ep93xx/ts72xx.h
index 7b7490f10fa9..00b4941d29c9 100644
--- a/arch/arm/mach-ep93xx/ts72xx.h
+++ b/arch/arm/mach-ep93xx/ts72xx.h
@@ -10,6 +10,7 @@
* febff000 22000000 4K model number register (bits 0-2)
* febfe000 22400000 4K options register
* febfd000 22800000 4K options register #2
+ * febfc000 23400000 4K CPLD version register
*/
#ifndef __TS72XX_H_
@@ -42,6 +43,10 @@
#define TS72XX_OPTIONS2_TS9420 0x04
#define TS72XX_OPTIONS2_TS9420_BOOT 0x02
+#define TS72XX_CPLDVER_PHYS_BASE 0x23400000
+#define TS72XX_CPLDVER_VIRT_BASE IOMEM(0xfebfc000)
+#define TS72XX_CPLDVER_SIZE 0x00001000
+
#ifndef __ASSEMBLY__
static inline int ts72xx_model(void)
diff --git a/arch/arm/tools/mach-types b/arch/arm/tools/mach-types
index a9313b66f770..4eac94c1eb6f 100644
--- a/arch/arm/tools/mach-types
+++ b/arch/arm/tools/mach-types
@@ -345,6 +345,7 @@ mxlads MACH_MXLADS MXLADS 1851
linkstation_mini MACH_LINKSTATION_MINI LINKSTATION_MINI 1858
afeb9260 MACH_AFEB9260 AFEB9260 1859
imx27ipcam MACH_IMX27IPCAM IMX27IPCAM 1871
+bk3 MACH_BK3 BK3 1880
rd88f6183ap_ge MACH_RD88F6183AP_GE RD88F6183AP_GE 1894
realview_pba8 MACH_REALVIEW_PBA8 REALVIEW_PBA8 1897
realview_pbx MACH_REALVIEW_PBX REALVIEW_PBX 1901
--
2.11.0
This patch extends readability of ts72xx.c code.
Signed-off-by: Lukasz Majewski <[email protected]>
---
Changes for v2:
- New patch
Changes for v3:
- None
Changes to v4:
- Adjust the code to be applicable to linux-next/master
Changes for v5:
- None
---
arch/arm/mach-ep93xx/ts72xx.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/arch/arm/mach-ep93xx/ts72xx.c b/arch/arm/mach-ep93xx/ts72xx.c
index 141ae4c65a81..17af9d834b51 100644
--- a/arch/arm/mach-ep93xx/ts72xx.c
+++ b/arch/arm/mach-ep93xx/ts72xx.c
@@ -31,6 +31,9 @@
#include "soc.h"
#include "ts72xx.h"
+/*************************************************************************
+ * IO map
+ *************************************************************************/
static struct map_desc ts72xx_io_desc[] __initdata = {
{
.virtual = (unsigned long)TS72XX_MODEL_VIRT_BASE,
@@ -201,10 +204,16 @@ static struct platform_device ts72xx_wdt_device = {
.num_resources = ARRAY_SIZE(ts72xx_wdt_resources),
};
+/*************************************************************************
+ * ETH
+ *************************************************************************/
static struct ep93xx_eth_data __initdata ts72xx_eth_data = {
.phy_id = 1,
};
+/*************************************************************************
+ * TS72XX support code
+ *************************************************************************/
#if IS_ENABLED(CONFIG_FPGA_MGR_TS73XX)
/* Relative to EP93XX_CS1_PHYS_BASE */
--
2.11.0
This commit extend the ts72xx_register_flash() to accept passed parameters,
which makes it more reusable.
Now it is possible to accept ep93xx flash start address and partitions.
Signed-off-by: Lukasz Majewski <[email protected]>
Acked-by: Alexander Sverdlin <[email protected]>
---
Changes for v2:
- New patch
Changes for v3:
- None
Changes for v4:
- None
Changes for v5:
- None
---
arch/arm/mach-ep93xx/ts72xx.c | 20 ++++++++------------
1 file changed, 8 insertions(+), 12 deletions(-)
diff --git a/arch/arm/mach-ep93xx/ts72xx.c b/arch/arm/mach-ep93xx/ts72xx.c
index f386ebae0163..141ae4c65a81 100644
--- a/arch/arm/mach-ep93xx/ts72xx.c
+++ b/arch/arm/mach-ep93xx/ts72xx.c
@@ -123,8 +123,6 @@ static struct platform_nand_data ts72xx_nand_data = {
.nr_chips = 1,
.chip_offset = 0,
.chip_delay = 15,
- .partitions = ts72xx_nand_parts,
- .nr_partitions = ARRAY_SIZE(ts72xx_nand_parts),
},
.ctrl = {
.cmd_ctrl = ts72xx_nand_hwcontrol,
@@ -148,8 +146,8 @@ static struct platform_device ts72xx_nand_flash = {
.num_resources = ARRAY_SIZE(ts72xx_nand_resource),
};
-
-static void __init ts72xx_register_flash(void)
+void __init ts72xx_register_flash(struct mtd_partition *parts, int n,
+ resource_size_t start)
{
/*
* TS7200 has NOR flash all other TS72xx board have NAND flash.
@@ -157,16 +155,12 @@ static void __init ts72xx_register_flash(void)
if (board_is_ts7200()) {
ep93xx_register_flash(2, EP93XX_CS6_PHYS_BASE, SZ_16M);
} else {
- resource_size_t start;
-
- if (is_ts9420_installed())
- start = EP93XX_CS7_PHYS_BASE;
- else
- start = EP93XX_CS6_PHYS_BASE;
-
ts72xx_nand_resource[0].start = start;
ts72xx_nand_resource[0].end = start + SZ_16M - 1;
+ ts72xx_nand_data.chip.partitions = parts;
+ ts72xx_nand_data.chip.nr_partitions = n;
+
platform_device_register(&ts72xx_nand_flash);
}
}
@@ -257,7 +251,9 @@ static struct ep93xx_spi_info ts72xx_spi_info __initdata = {
static void __init ts72xx_init_machine(void)
{
ep93xx_init_devices();
- ts72xx_register_flash();
+ ts72xx_register_flash(ts72xx_nand_parts, ARRAY_SIZE(ts72xx_nand_parts),
+ is_ts9420_installed() ?
+ EP93XX_CS7_PHYS_BASE : EP93XX_CS6_PHYS_BASE);
platform_device_register(&ts72xx_rtc_device);
platform_device_register(&ts72xx_wdt_device);
--
2.11.0
On Monday, December 11, 2017 4:36 PM, Lukasz Majewski wrote:
> This patch series adds support for Liebherr's BK3 board, being a derivative of TS72XX design.
>
> This patchset consists of following patches:
>
> - ts72xx.[c|h] cosmetic cleanup/improvement
> - Rewrite ts72xx.c to be reusable by bk3
> - The Liebherr's BK3 board has been added with re-using code of
> ts72xx.c (detalied list of changes can be found in patch 4/4)
>
> This series applies on top of linux-next/master (next-20171211)
>
> Lukasz Majewski (4):
> ARM: ep93xx: ts72xx: Provide include guards for ts72xx.h file
> ARM: ep93xx: ts72xx: Rewrite ts72xx_register_flash() to accept
> parameters
> ARM: ep93xx: ts72xx: cosmetic: Add some description to ts72xx code
> ARM: ep93xx: ts72xx: Add support for BK3 board - ts72xx derivative
>
> MAINTAINERS | 6 ++
> arch/arm/mach-ep93xx/Kconfig | 7 ++
> arch/arm/mach-ep93xx/ts72xx.c | 165 +++++++++++++++++++++++++++++++++++++++---
> arch/arm/mach-ep93xx/ts72xx.h | 9 +++
> arch/arm/tools/mach-types | 1 +
> 5 files changed, 176 insertions(+), 12 deletions(-)
Looks good. Thanks!
Acked-by: H Hartley Sweeten <[email protected]>
On Tue, Dec 12, 2017 at 12:36 AM, Lukasz Majewski <[email protected]> wrote:
> This patch series adds support for Liebherr's BK3 board, being
> a derivative of TS72XX design.
All looks good.
Acked-by: Linus Walleij <[email protected]>
Out of curiosity: Liebherr is obviously doing heavy-duty industrial
control systems. Likewise Hartley is doing similar business over
at Vision Engravings.
Is the situation such that there is a whole bunch of industrial
systems out there, in active use and needing future upgrades,
that use the EP93xx?
Arnd has been nudging me to do DT conversion for EP93xx
so if there are many active industrial users of these
I should prioritize it, because these things have 20+ years
support cycles.
We also need to think about upholding support in GCC for
ARMv4(t) for the foreseeable future if there is a big web of
random deeply embedded systems out there that will need
updates.
Yours,
Linus Walleij
Hello Linus!
On Wed Dec 13 08:34:22 2017 Linus Walleij <[email protected]> wrote:
> On Tue, Dec 12, 2017 at 12:36 AM, Lukasz Majewski <[email protected]> wrote:
> Out of curiosity: Liebherr is obviously doing heavy-duty industrial
> control systems. Likewise Hartley is doing similar business over
> at Vision Engravings.
>
> Is the situation such that there is a whole bunch of industrial
> systems out there, in active use and needing future upgrades,
> that use the EP93xx?
That's definitely the case. I'm as well aware of several thousands of industrial devices which are expected to run 24/7 for the next 5 years at least. And they are updated from time to time.
> Arnd has been nudging me to do DT conversion for EP93xx
> so if there are many active industrial users of these
> I should prioritize it, because these things have 20+ years
> support cycles.
I'm not sure how important or necessary at all is to change anything in these legacy platforms.
> We also need to think about upholding support in GCC for
> ARMv4(t) for the foreseeable future if there is a big web of
> random deeply embedded systems out there that will need
> updates.
But we should definitely preserve at least what we have.
--
Alexander.
Hi Alexander, Linus
> Hello Linus!
>
> On Wed Dec 13 08:34:22 2017 Linus Walleij <[email protected]>
> wrote:
> > On Tue, Dec 12, 2017 at 12:36 AM, Lukasz Majewski <[email protected]>
> > wrote: Out of curiosity: Liebherr is obviously doing heavy-duty
> > industrial control systems. Likewise Hartley is doing similar
> > business over at Vision Engravings.
> >
> > Is the situation such that there is a whole bunch of industrial
> > systems out there, in active use and needing future upgrades,
> > that use the EP93xx?
>
> That's definitely the case. I'm as well aware of several thousands of
> industrial devices which are expected to run 24/7 for the next 5
> years at least. And they are updated from time to time.
I can agree with this statement.
>
> > Arnd has been nudging me to do DT conversion for EP93xx
> > so if there are many active industrial users of these
> > I should prioritize it, because these things have 20+ years
> > support cycles.
>
> I'm not sure how important or necessary at all is to change anything
> in these legacy platforms.
+1
>
> > We also need to think about upholding support in GCC for
> > ARMv4(t) for the foreseeable future if there is a big web of
> > random deeply embedded systems out there that will need
> > updates.
>
> But we should definitely preserve at least what we have.
I'm using OE to build toolchain (SDK). I can confirm that gcc 7.2 works
with it.
And yes, armv4 support shall be preserved in GCC ....
>
> --
> Alexander.
>
Best regards,
Lukasz Majewski
--
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: [email protected]
On Wed, Dec 13, 2017 at 9:26 AM, Alexander Sverdlin
<[email protected]> wrote:
> On Wed Dec 13 08:34:22 2017 Linus Walleij <[email protected]> wrote:
>> Arnd has been nudging me to do DT conversion for EP93xx
>> so if there are many active industrial users of these
>> I should prioritize it, because these things have 20+ years
>> support cycles.
>
> I'm not sure how important or necessary at all is to change anything in these legacy platforms.
I suspect that at several points in the next 5 to 10 years, we will remove
additional platforms or CPU types, as we tend to do when a platform
becomes a maintenance burden and is clearly not used by anyone.
It's hard to predict in advance what triggers the removal, but as the
number of platforms that are not using DT or ARCH_MULTIPLATFORM
goes down to a small number, there will be increased interested in either
removing or converting the remaining ones. This is not an immediate
danger at the moment, since we still have 14 platforms that are not
using ARCH_MULTIPLATFORM, and 23 that have remaining
board files, but you don't want to be the last user of the last platform
after the other ones are done ;-)
>> We also need to think about upholding support in GCC for
>> ARMv4(t) for the foreseeable future if there is a big web of
>> random deeply embedded systems out there that will need
>> updates.
>
> But we should definitely preserve at least what we have.
Plain ARMv4 (and earlier) support in gcc is already marked 'deprecated'
and will likely be gone in gcc-8 (it's still there as of last week). ARMv4T
is going to be around for a while, and you can even keep building for
ARMv4 using "-march=armv4t -marm" when linking with 'ld --fix-v4bx'.
Debian recently did a survey to find out whether there were still users
on ARMv4 or ARMv4T, and the result was that probably everyone is
on ARMv5E or ARMv6 for the ARM port (which is separate from the
ARMHF port that is ARMv7+). See also
https://lists.debian.org/debian-user/2017/11/msg00379.html
and let them know quickly if you use Debian stable releases and
plan to update to Debian 10 (Buster) in the future.
Arnd
Hi Arnd,
> On Wed, Dec 13, 2017 at 9:26 AM, Alexander Sverdlin
> <[email protected]> wrote:
> > On Wed Dec 13 08:34:22 2017 Linus Walleij
> > <[email protected]> wrote:
> >> Arnd has been nudging me to do DT conversion for EP93xx
> >> so if there are many active industrial users of these
> >> I should prioritize it, because these things have 20+ years
> >> support cycles.
> >
> > I'm not sure how important or necessary at all is to change
> > anything in these legacy platforms.
>
> I suspect that at several points in the next 5 to 10 years, we will
> remove additional platforms or CPU types, as we tend to do when a
> platform becomes a maintenance burden and is clearly not used by
> anyone.
I suppose that at least the last argument is not the case here :-).
>
> It's hard to predict in advance what triggers the removal, but as the
> number of platforms that are not using DT or ARCH_MULTIPLATFORM
> goes down to a small number, there will be increased interested in
> either removing or converting the remaining ones. This is not an
> immediate danger at the moment, since we still have 14 platforms that
> are not using ARCH_MULTIPLATFORM, and 23 that have remaining
> board files, but you don't want to be the last user of the last
> platform after the other ones are done ;-)
:-)
>
> >> We also need to think about upholding support in GCC for
> >> ARMv4(t) for the foreseeable future if there is a big web of
> >> random deeply embedded systems out there that will need
> >> updates.
> >
> > But we should definitely preserve at least what we have.
>
> Plain ARMv4 (and earlier) support in gcc is already marked
> 'deprecated' and will likely be gone in gcc-8 (it's still there as of
> last week). ARMv4T is going to be around for a while, and you can
> even keep building for ARMv4 using "-march=armv4t -marm" when linking
> with 'ld --fix-v4bx'.
I think that we shall start complaining on the gcc-devel mailing list
now.
I would be hard to wake up in 2 years time and realise that we don't
have a modern compiler.
>
> Debian recently did a survey to find out whether there were still
> users on ARMv4 or ARMv4T, and the result was that probably everyone is
> on ARMv5E or ARMv6 for the ARM port (which is separate from the
> ARMHF port that is ARMv7+). See also
> https://lists.debian.org/debian-user/2017/11/msg00379.html
> and let them know quickly if you use Debian stable releases and
> plan to update to Debian 10 (Buster) in the future.
>
> Arnd
Best regards,
Lukasz Majewski
--
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: [email protected]
On Sun, Dec 17, 2017 at 8:41 PM, Lukasz Majewski <[email protected]> wrote:
>> >> We also need to think about upholding support in GCC for
>> >> ARMv4(t) for the foreseeable future if there is a big web of
>> >> random deeply embedded systems out there that will need
>> >> updates.
>> >
>> > But we should definitely preserve at least what we have.
>>
>> Plain ARMv4 (and earlier) support in gcc is already marked
>> 'deprecated' and will likely be gone in gcc-8 (it's still there as of
>> last week). ARMv4T is going to be around for a while, and you can
>> even keep building for ARMv4 using "-march=armv4t -marm" when linking
>> with 'ld --fix-v4bx'.
>
> I think that we shall start complaining on the gcc-devel mailing list
> now.
>
> I would be hard to wake up in 2 years time and realise that we don't
> have a modern compiler.
What distro or build system are you using? It would also be helpful
to test whether the -march=armv4t/--fix-v4bx workaround produces
working binaries for you, in that case you could report to the gcc
developers that the removal of armv4 can continue but that
the --fix-v4bx option in ld needs to stay around.
Arnd
Hi Arnd,
> On Sun, Dec 17, 2017 at 8:41 PM, Lukasz Majewski <[email protected]>
> wrote:
> >> >> We also need to think about upholding support in GCC for
> >> >> ARMv4(t) for the foreseeable future if there is a big web of
> >> >> random deeply embedded systems out there that will need
> >> >> updates.
> >> >
> >> > But we should definitely preserve at least what we have.
> >>
> >> Plain ARMv4 (and earlier) support in gcc is already marked
> >> 'deprecated' and will likely be gone in gcc-8 (it's still there as
> >> of last week). ARMv4T is going to be around for a while, and you
> >> can even keep building for ARMv4 using "-march=armv4t -marm" when
> >> linking with 'ld --fix-v4bx'.
> >
> > I think that we shall start complaining on the gcc-devel mailing
> > list now.
> >
> > I would be hard to wake up in 2 years time and realise that we don't
> > have a modern compiler.
>
> What distro or build system are you using?
I'm using OE with the "include conf/machine/include/tune-arm920t.inc"
GCC 7.2 is working
> It would also be helpful
> to test whether the -march=armv4t/--fix-v4bx workaround produces
> working binaries for you, in that case you could report to the gcc
> developers that the removal of armv4 can continue but that
> the --fix-v4bx option in ld needs to stay around.
I may ask this issue on OE/Yocto mailing list as well....
Thanks for hint.
>
> Arnd
Best regards,
Lukasz Majewski
--
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: [email protected]
On Sun, Dec 17, 2017 at 10:28 PM, Lukasz Majewski <[email protected]> wrote:
> Hi Arnd,
>
>> On Sun, Dec 17, 2017 at 8:41 PM, Lukasz Majewski <[email protected]>
>> wrote:
>> >> >> We also need to think about upholding support in GCC for
>> >> >> ARMv4(t) for the foreseeable future if there is a big web of
>> >> >> random deeply embedded systems out there that will need
>> >> >> updates.
>> >> >
>> >> > But we should definitely preserve at least what we have.
>> >>
>> >> Plain ARMv4 (and earlier) support in gcc is already marked
>> >> 'deprecated' and will likely be gone in gcc-8 (it's still there as
>> >> of last week). ARMv4T is going to be around for a while, and you
>> >> can even keep building for ARMv4 using "-march=armv4t -marm" when
>> >> linking with 'ld --fix-v4bx'.
>> >
>> > I think that we shall start complaining on the gcc-devel mailing
>> > list now.
>> >
>> > I would be hard to wake up in 2 years time and realise that we don't
>> > have a modern compiler.
>>
>> What distro or build system are you using?
>
> I'm using OE with the "include conf/machine/include/tune-arm920t.inc"
>
> GCC 7.2 is working
Ah wait, this is still for ep93xx, which is always at least armv4t, right?
So it won't have a problem with the armv4 deprecation anyway, even
the older ep72xx/73xx were ARM720T based and don't have a problem.
I'm not entirely sure about their clps711x predecessors, which were some
earlier arm7 variant, but Linux doesn't support them any more anyway,
and the ARM710T would already be fine without --fix-v4bx.
>> It would also be helpful
>> to test whether the -march=armv4t/--fix-v4bx workaround produces
>> working binaries for you, in that case you could report to the gcc
>> developers that the removal of armv4 can continue but that
>> the --fix-v4bx option in ld needs to stay around.
>
> I may ask this issue on OE/Yocto mailing list as well....
To clarify, the only affected platforms are those based on either
DEC/Intel StrongARM or Faraday FA526, i.e. EBSA-110,
FootBridge, RPC, SA1100, Moxart and Gemini.
Arnd
Hi!
On Mon Dec 18 12:55:40 2017 Arnd Bergmann <[email protected]> wrote:
> > GCC 7.2 is working
>
> Ah wait, this is still for ep93xx, which is always at least armv4t,
> right? So it won't have a problem with the armv4 deprecation anyway, even
Correct.
--
Alex.
Hi Arnd,
> Hi!
>
> On Mon Dec 18 12:55:40 2017 Arnd Bergmann <[email protected]> wrote:
> > > GCC 7.2 is working
> >
> > Ah wait, this is still for ep93xx, which is always at least armv4t,
> > right? So it won't have a problem with the armv4 deprecation
> > anyway, even
>
> Correct.
Maybe a bit off topic :-)
Are there any more comments regarding this patch series? Are those
patches eligible for applying them to -next?
>
> --
> Alex.
Best regards,
Lukasz Majewski
--
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: [email protected]
On Tue, Dec 19, 2017 at 10:36 PM, Lukasz Majewski <[email protected]> wrote:
> Hi Arnd,
>
>> Hi!
>>
>> On Mon Dec 18 12:55:40 2017 Arnd Bergmann <[email protected]> wrote:
>> > > GCC 7.2 is working
>> >
>> > Ah wait, this is still for ep93xx, which is always at least armv4t,
>> > right? So it won't have a problem with the armv4 deprecation
>> > anyway, even
>>
>> Correct.
>
> Maybe a bit off topic :-)
>
> Are there any more comments regarding this patch series? Are those
> patches eligible for applying them to -next?
Alexander already sent a pull request, I just haven't pulled them. If there
are any other comments or additional patches, they should be done
on top of the first pull request, unless there is a major regression in
the original pull (which is unlikely).
Arnd
Hi Arnd,
> On Tue, Dec 19, 2017 at 10:36 PM, Lukasz Majewski <[email protected]>
> wrote:
> > Hi Arnd,
> >
> >> Hi!
> >>
> >> On Mon Dec 18 12:55:40 2017 Arnd Bergmann <[email protected]> wrote:
> >> > > GCC 7.2 is working
> >> >
> >> > Ah wait, this is still for ep93xx, which is always at least
> >> > armv4t, right? So it won't have a problem with the armv4
> >> > deprecation anyway, even
> >>
> >> Correct.
> >
> > Maybe a bit off topic :-)
> >
> > Are there any more comments regarding this patch series? Are those
> > patches eligible for applying them to -next?
>
> Alexander already sent a pull request, I just haven't pulled them. If
> there are any other comments or additional patches, they should be
> done on top of the first pull request, unless there is a major
> regression in the original pull (which is unlikely).
Thanks for reply.
>
> Arnd
Best regards,
Lukasz Majewski
--
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: [email protected]
On Wed, Dec 13, 2017 at 9:52 AM, Lukasz Majewski <[email protected]> wrote:
>> On Wed Dec 13 08:34:22 2017 Linus Walleij <[email protected]>
>> wrote:
>> > On Tue, Dec 12, 2017 at 12:36 AM, Lukasz Majewski <[email protected]>
>> > wrote: Out of curiosity: Liebherr is obviously doing heavy-duty
>> > industrial control systems. Likewise Hartley is doing similar
>> > business over at Vision Engravings.
>> >
>> > Is the situation such that there is a whole bunch of industrial
>> > systems out there, in active use and needing future upgrades,
>> > that use the EP93xx?
>>
>> That's definitely the case. I'm as well aware of several thousands of
>> industrial devices which are expected to run 24/7 for the next 5
>> years at least. And they are updated from time to time.
>
> I can agree with this statement.
OK I'm coloring this platform with a highlight for ARM32 maintenance.
>> > Arnd has been nudging me to do DT conversion for EP93xx
>> > so if there are many active industrial users of these
>> > I should prioritize it, because these things have 20+ years
>> > support cycles.
>>
>> I'm not sure how important or necessary at all is to change anything
>> in these legacy platforms.
>
> +1
That is an understandable conservative stance.
There is a fine line between "it works, don't touch it" and
"modernize the ARM32 ecosystem".
There is a point where supporting old board files will stand in
the way and cost a lot in maintenance (like moving drivers our
of arch/arm, or modernizing misc subsystems). Then moving the
platform over to device tree should be preferred.
> I'm using OE to build toolchain (SDK). I can confirm that gcc 7.2 works
> with it.
>
> And yes, armv4 support shall be preserved in GCC ....
Yes that is the same toochain I use.
Yours,
Linus Walleij
On Mon, Dec 18, 2017 at 12:55 PM, Arnd Bergmann <[email protected]> wrote:
> On Sun, Dec 17, 2017 at 10:28 PM, Lukasz Majewski <[email protected]> wrote:
>>> On Sun, Dec 17, 2017 at 8:41 PM, Lukasz Majewski <[email protected]>
>>> wrote:
>>> >> >> We also need to think about upholding support in GCC for
>>> >> >> ARMv4(t) for the foreseeable future if there is a big web of
>>> >> >> random deeply embedded systems out there that will need
>>> >> >> updates.
>>> >> >
>>> >> > But we should definitely preserve at least what we have.
>>> >>
>>> >> Plain ARMv4 (and earlier) support in gcc is already marked
>>> >> 'deprecated' and will likely be gone in gcc-8 (it's still there as
>>> >> of last week). ARMv4T is going to be around for a while, and you
>>> >> can even keep building for ARMv4 using "-march=armv4t -marm" when
>>> >> linking with 'ld --fix-v4bx'.
>>> >
>>> > I think that we shall start complaining on the gcc-devel mailing
>>> > list now.
>>> >
>>> > I would be hard to wake up in 2 years time and realise that we don't
>>> > have a modern compiler.
(...)
>>> It would also be helpful
>>> to test whether the -march=armv4t/--fix-v4bx workaround produces
>>> working binaries for you, in that case you could report to the gcc
>>> developers that the removal of armv4 can continue but that
>>> the --fix-v4bx option in ld needs to stay around.
>>
>> I may ask this issue on OE/Yocto mailing list as well....
>
> To clarify, the only affected platforms are those based on either
> DEC/Intel StrongARM or Faraday FA526, i.e. EBSA-110,
> FootBridge, RPC, SA1100, Moxart and Gemini.
It's a bit unfortunate since there are users and active contributors to
these architectures, I think the OE community is being missed out
just because they "are not Debian". :/
Even NetWinder.org is still up and kicking.
Some of it may be nostalgia and platform-hugging with regards to
SA110 and SA1100 systems, I am certainly aware of such tendencies
in myself. And I understand if GCC drops support for old systems
that only have a bunch of elderly gentlemen running it for the fun of it.
What really worries me is if there are widely deployed SA110,
SA1100, FA526 or similar embedded systems using plain ARMv4
and doing regular kernel builds and userspaces for them, in
items with 20+ years support cycles.
With reports in the media about things like nuclear powerplants running
unsupported versions of Windows NT or 95, I want to make sure
that we're not creating a similar situation somewhere for deeply
embedded Linux. Sadly these users mostly seem to come out
of the shadows after-the-fact.
My own experiments with an upgraded Gemini platform are mostly
related to the fact that home routers using this ARMv4 SoC are still
being sold and deployed, using a v2.6 kernel (contributing to the
world of botnets I suppose). The hardware-accelerated gigabit ethernet
on these routers for the home make them still fully usable despite the
ARMv4 core, but securitywise they are a nightmare.
Yours,
Linus Walleij
On Wed, Dec 20, 2017 at 1:33 PM, Linus Walleij <[email protected]> wrote:
> On Wed, Dec 13, 2017 at 9:52 AM, Lukasz Majewski <[email protected]> wrote:
>
> There is a point where supporting old board files will stand in
> the way and cost a lot in maintenance (like moving drivers our
> of arch/arm, or modernizing misc subsystems). Then moving the
> platform over to device tree should be preferred.
I'm generally more interested in the multiplatform conversion than
the DT conversion, and I think converting this one to multiplatform
isn't actually that hard, and doesn't have a significant risk for
regressions, the main work is to convert the clock handling.
Arnd
On Wed, Dec 20, 2017 at 1:48 PM, Linus Walleij <[email protected]> wrote:
> On Mon, Dec 18, 2017 at 12:55 PM, Arnd Bergmann <[email protected]> wrote:
>> On Sun, Dec 17, 2017 at 10:28 PM, Lukasz Majewski <[email protected]> wrote:
>>>> It would also be helpful
>>>> to test whether the -march=armv4t/--fix-v4bx workaround produces
>>>> working binaries for you, in that case you could report to the gcc
>>>> developers that the removal of armv4 can continue but that
>>>> the --fix-v4bx option in ld needs to stay around.
>>>
>>> I may ask this issue on OE/Yocto mailing list as well....
>>
>> To clarify, the only affected platforms are those based on either
>> DEC/Intel StrongARM or Faraday FA526, i.e. EBSA-110,
>> FootBridge, RPC, SA1100, Moxart and Gemini.
>
> It's a bit unfortunate since there are users and active contributors to
> these architectures, I think the OE community is being missed out
> just because they "are not Debian". :/
IIRC, OE already uses the --fix-v4bx workaround. I had an older patch
to do the same in the kernel, let me resend it now, so you can try it
and see if that works for you.
Arnd
Hi!
On Wed Dec 20 13:50:28 2017 Arnd Bergmann <[email protected]> wrote:
> I'm generally more interested in the multiplatform conversion than
> the DT conversion, and I think converting this one to multiplatform
> isn't actually that hard, and doesn't have a significant risk for
> regressions, the main work is to convert the clock handling.
If it will be still possible to build the binary kernel of the same size after the conversion, I'm in for testing, otherwise it will not fit into Flash any more...
--
Alex.
On Wed, Dec 20, 2017 at 2:00 PM, Alexander Sverdlin
<[email protected]> wrote:
> Hi!
>
> On Wed Dec 20 13:50:28 2017 Arnd Bergmann <[email protected]> wrote:
>> I'm generally more interested in the multiplatform conversion than
>> the DT conversion, and I think converting this one to multiplatform
>> isn't actually that hard, and doesn't have a significant risk for
>> regressions, the main work is to convert the clock handling.
>
> If it will be still possible to build the binary kernel of the same size after the
> conversion, I'm in for testing, otherwise it will not fit into Flash any more...
I think there is an increase in code size that comes mainly from the
common clock layer itself, plus a few bytes here and there. Obviously
the increase is much bigger if you actually enable multiple platforms.
Here is the size of the uncompressed vmlinux file with the current
clk implementation, compared to a build with a build containing the
common clk code but no clock driver, and the separate clock
implementation we have today:
text data bss dec hex filename
4752655 1036028 128260 5916943 5a490f build/tmp/vmlinux-old-clk
4780174 1040524 128284 5948982 5ac636 build/tmp/vmlinux-common-clk
2491 1700 0 4191 105f build/tmp/arch/arm/mach-ep93xx/clock.o
The difference would come to about 0.7% of the current image size,
I guess around 1% when the other changes are included. Is that within
the margins you have, or is this already critical?
Arnd
Hi Arnd,
> On Wed, Dec 20, 2017 at 1:33 PM, Linus Walleij
> <[email protected]> wrote:
> > On Wed, Dec 13, 2017 at 9:52 AM, Lukasz Majewski <[email protected]>
> > wrote:
>
> >
> > There is a point where supporting old board files will stand in
> > the way and cost a lot in maintenance (like moving drivers our
> > of arch/arm, or modernizing misc subsystems). Then moving the
> > platform over to device tree should be preferred.
>
> I'm generally more interested in the multiplatform conversion than
> the DT conversion, and I think converting this one to multiplatform
> isn't actually that hard, and doesn't have a significant risk for
> regressions, the main work is to convert the clock handling.
Maybe we need some kind of a schedule (or roadmap)?
>
> Arnd
Best regards,
Lukasz Majewski
--
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: [email protected]
Hi Linus,
> On Wed, Dec 13, 2017 at 9:52 AM, Lukasz Majewski <[email protected]>
> wrote:
> >> On Wed Dec 13 08:34:22 2017 Linus Walleij
> >> <[email protected]> wrote:
> >> > On Tue, Dec 12, 2017 at 12:36 AM, Lukasz Majewski <[email protected]>
> >> > wrote: Out of curiosity: Liebherr is obviously doing heavy-duty
> >> > industrial control systems. Likewise Hartley is doing similar
> >> > business over at Vision Engravings.
> >> >
> >> > Is the situation such that there is a whole bunch of industrial
> >> > systems out there, in active use and needing future upgrades,
> >> > that use the EP93xx?
> >>
> >> That's definitely the case. I'm as well aware of several thousands
> >> of industrial devices which are expected to run 24/7 for the next 5
> >> years at least. And they are updated from time to time.
> >
> > I can agree with this statement.
>
> OK I'm coloring this platform with a highlight for ARM32 maintenance.
>
> >> > Arnd has been nudging me to do DT conversion for EP93xx
> >> > so if there are many active industrial users of these
> >> > I should prioritize it, because these things have 20+ years
> >> > support cycles.
> >>
> >> I'm not sure how important or necessary at all is to change
> >> anything in these legacy platforms.
> >
> > +1
>
> That is an understandable conservative stance.
>
> There is a fine line between "it works, don't touch it" and
> "modernize the ARM32 ecosystem".
There may be a more pragmatic reason. If those boards are deployed
(widely) in the industry - there may be a problem with re-validation of
the SW.
>
> There is a point where supporting old board files will stand in
> the way and cost a lot in maintenance (like moving drivers our
> of arch/arm, or modernizing misc subsystems). Then moving the
> platform over to device tree should be preferred.
With my limited experience - those platforms have more similarities to
x86. Multiplatform may be the goal here....
>
> > I'm using OE to build toolchain (SDK). I can confirm that gcc 7.2
> > works with it.
> >
> > And yes, armv4 support shall be preserved in GCC ....
I should have be more peculiar - this is armv4t (arm920t)
>
> Yes that is the same toochain I use.
>
> Yours,
> Linus Walleij
Best regards,
Lukasz Majewski
--
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: [email protected]
Hi Arnd!
On Wed Dec 20 14:14:07 2017 Arnd Bergmann <[email protected]> wrote:
> > If it will be still possible to build the binary kernel of the same
> > size after the conversion, I'm in for testing, otherwise it will not
> > fit into Flash any more...
>
> I think there is an increase in code size that comes mainly from the
> common clock layer itself, plus a few bytes here and there. Obviously
> the increase is much bigger if you actually enable multiple platforms.
>
> Here is the size of the uncompressed vmlinux file with the current
> clk implementation, compared to a build with a build containing the
> common clk code but no clock driver, and the separate clock
> implementation we have today:
>
> text data bss dec hex filename
> 4752655 1036028 128260 5916943 5a490f build/tmp/vmlinux-old-clk
> 4780174 1040524 128284 5948982 5ac636 build/tmp/vmlinux-common-clk
> 2491 1700 0 4191 105f
> build/tmp/arch/arm/mach-ep93xx/clock.o
>
> The difference would come to about 0.7% of the current image size,
> I guess around 1% when the other changes are included. Is that within
> the margins you have, or is this already critical?
No, your numbers are promising, I was afraid of the increase of other orders of magnitude. So this should be fine.
Thanks for this info.
--
Alex.