board: add support for ARC AXS101 and AXS103 Software Development Platforms

The AXS10x Platform consists of a DesignWare AXC001 CPU
Card (with ARC 770D core) in case of AXS101 or AXC003 CPU Card
(typically with ARC HS38 core) in case of AXS103 mounted on an
ARC Software Development Platform Mainboard with DesignWare peripherals:
 * SD/MMC contoller
 * Gigabit network contoller
 * Serial ports (8250-compatible)
 * USB 2.0
 * SPI
 * I2C

It also houses HDMI output for external monitor connection.

For stand-alone usage of the board (with only keyboard, mouse and montor
attached) kernel console and getty made available on tty0 as well as on
serial port (ttyS3).

Note there're 2 prerequisites:
 [1] u-boot: 2015.07 - fix creation of .config
     http://patchwork.ozlabs.org/patch/502558/

 [2] binutils: fix buildng of Linux kernel for ARCv2 ISA
     http://patchwork.ozlabs.org/patch/503550/

Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
 board/synopsys/axs10x/fs-overlay/etc/inittab | 41 ++++++++++++++++++++++++++++
 configs/snps_axs101_defconfig                | 13 +++++++++
 configs/snps_axs103_defconfig                | 14 ++++++++++
 3 files changed, 68 insertions(+)
 create mode 100644 board/synopsys/axs10x/fs-overlay/etc/inittab
 create mode 100644 configs/snps_axs101_defconfig
 create mode 100644 configs/snps_axs103_defconfig

Alexey,

On Tue,  4 Aug 2015 15:00:14 +0300, Alexey Brodkin wrote:

> diff --git a/board/synopsys/axs10x/fs-overlay/etc/inittab b/board/synopsys/axs10x/fs-overlay/etc/inittab
> new file mode 100644
> index 0000000..de3d6e8
> --- /dev/null
> +++ b/board/synopsys/axs10x/fs-overlay/etc/inittab
> @@ -0,0 +1,41 @@
> +# /etc/inittab
> +#
> +# Copyright (C) 2001 Erik Andersen <andersen@codepoet.org>
> +#
> +# Note: BusyBox init doesn't support runlevels.  The runlevels field is
> +# completely ignored by BusyBox init. If you want runlevels, use
> +# sysvinit.
> +#
> +# Format for each entry: <id>:<runlevels>:<action>:<process>
> +#
> +# id        == tty to run on, or empty for /dev/console
> +# runlevels == ignored
> +# action    == one of sysinit, respawn, askfirst, wait, and once
> +# process   == program to run
> +
> +# Startup the system
> +null::sysinit:/bin/mount -t proc proc /proc
> +null::sysinit:/bin/mkdir -p /dev/pts
> +null::sysinit:/bin/mkdir -p /dev/shm
> +null::sysinit:/bin/mount -a
> +null::sysinit:/bin/hostname -F /etc/hostname
> +# now run any rc scripts
> +::sysinit:/etc/init.d/rcS
> +
> +# Start an "askfirst" shell on the console (whatever that may be)
> +#::askfirst:-/bin/sh # ASKFIRST_SHELL

Why?

> +
> +# /sbin/getty invocations for selected ttys
> +tty0::respawn:/sbin/getty 115200 tty0
> +
> +# Put a getty on the serial port
> +console::respawn:/sbin/getty -L console 0 vt100

It's a bit annoying to have a custom inittab just for this, but I agree
that this is the only solution with today's Buildroot.


> diff --git a/configs/snps_axs101_defconfig b/configs/snps_axs101_defconfig
> new file mode 100644
> index 0000000..6af4ac3
> --- /dev/null
> +++ b/configs/snps_axs101_defconfig
> @@ -0,0 +1,13 @@
> +BR2_arcle=y
> +BR2_TARGET_GENERIC_HOSTNAME="axs101"
> +BR2_TARGET_GENERIC_ISSUE="Welcome to the ARC Software Development Platform"
> +BR2_SYSTEM_DHCP="eth0"
> +BR2_ROOTFS_OVERLAY="board/synopsys/axs10x/fs-overlay"
> +BR2_LINUX_KERNEL=y
> +BR2_LINUX_KERNEL_CUSTOM_VERSION=y
> +BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="4.2-rc5"
> +BR2_LINUX_KERNEL_DEFCONFIG="axs101"

Please force the version of the kernel headers, so that they match the
kernel being built.

> +BR2_TARGET_ROOTFS_INITRAMFS=y
> +BR2_TARGET_UBOOT=y
> +BR2_TARGET_UBOOT_BUILD_SYSTEM_KCONFIG=y
> +BR2_TARGET_UBOOT_BOARD_DEFCONFIG="axs101"
> diff --git a/configs/snps_axs103_defconfig b/configs/snps_axs103_defconfig
> new file mode 100644
> index 0000000..40e4fac
> --- /dev/null
> +++ b/configs/snps_axs103_defconfig
> @@ -0,0 +1,14 @@
> +BR2_arcle=y
> +BR2_archs38=y
> +BR2_TARGET_GENERIC_HOSTNAME="axs103"
> +BR2_TARGET_GENERIC_ISSUE="Welcome to the ARC Software Development Platform"
> +BR2_SYSTEM_DHCP="eth0"
> +BR2_ROOTFS_OVERLAY="board/synopsys/axs10x/fs-overlay"
> +BR2_LINUX_KERNEL=y
> +BR2_LINUX_KERNEL_CUSTOM_VERSION=y
> +BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="4.2-rc5"

Ditto.

See other defconfigs, they are doing:

# Lock to 4.1 headers to avoid breaking with newer kernels
BR2_KERNEL_HEADERS_VERSION=y
BR2_DEFAULT_KERNEL_VERSION="4.1"
BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_4_1=y

# Kernel
BR2_LINUX_KERNEL=y
BR2_LINUX_KERNEL_CUSTOM_VERSION=y
BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="4.1"
BR2_LINUX_KERNEL_DEFCONFIG="vexpress"

Thanks!

Thomas

Hi Thomas,

On Tue, 2015-08-04 at 14:57 +0200, Thomas Petazzoni wrote:
> Alexey,
> 
> On Tue,  4 Aug 2015 15:00:14 +0300, Alexey Brodkin wrote:
> 
> > diff --git a/board/synopsys/axs10x/fs-overlay/etc/inittab b/board/synopsys/axs10x/fs-overlay/etc/inittab
> > new file mode 100644
> > index 0000000..de3d6e8
> > --- /dev/null
> > +++ b/board/synopsys/axs10x/fs-overlay/etc/inittab
> > @@ -0,0 +1,41 @@
> > +# /etc/inittab
> > +#
> > +# Copyright (C) 2001 Erik Andersen <andersen@codepoet.org>
> > +#
> > +# Note: BusyBox init doesn't support runlevels.  The runlevels field is
> > +# completely ignored by BusyBox init. If you want runlevels, use
> > +# sysvinit.
> > +#
> > +# Format for each entry: <id>:<runlevels>:<action>:<process>
> > +#
> > +# id        == tty to run on, or empty for /dev/console
> > +# runlevels == ignored
> > +# action    == one of sysinit, respawn, askfirst, wait, and once
> > +# process   == program to run
> > +
> > +# Startup the system
> > +null::sysinit:/bin/mount -t proc proc /proc
> > +null::sysinit:/bin/mkdir -p /dev/pts
> > +null::sysinit:/bin/mkdir -p /dev/shm
> > +null::sysinit:/bin/mount -a
> > +null::sysinit:/bin/hostname -F /etc/hostname
> > +# now run any rc scripts
> > +::sysinit:/etc/init.d/rcS
> > +
> > +# Start an "askfirst" shell on the console (whatever that may be)
> > +#::askfirst:-/bin/sh # ASKFIRST_SHELL
> 
> Why?

Opps dummy copy-paste from Busybox's example.
Please pardon that silly thing.

> > +
> > +# /sbin/getty invocations for selected ttys
> > +tty0::respawn:/sbin/getty 115200 tty0
> > +
> > +# Put a getty on the serial port
> > +console::respawn:/sbin/getty -L console 0 vt100
> 
> It's a bit annoying to have a custom inittab just for this, but I agree
> that this is the only solution with today's Buildroot.

Agree, that's a long-standing problem and if I'm not mistaken you guys
advise to go for fs overlay if that kind of "feature" is required.

That said I'm not happy with that solution but having no other way I have to swallow

> > diff --git a/configs/snps_axs101_defconfig b/configs/snps_axs101_defconfig
> > new file mode 100644
> > index 0000000..6af4ac3
> > --- /dev/null
> > +++ b/configs/snps_axs101_defconfig
> > @@ -0,0 +1,13 @@
> > +BR2_arcle=y
> > +BR2_TARGET_GENERIC_HOSTNAME="axs101"
> > +BR2_TARGET_GENERIC_ISSUE="Welcome to the ARC Software Development Platform"
> > +BR2_SYSTEM_DHCP="eth0"
> > +BR2_ROOTFS_OVERLAY="board/synopsys/axs10x/fs-overlay"
> > +BR2_LINUX_KERNEL=y
> > +BR2_LINUX_KERNEL_CUSTOM_VERSION=y
> > +BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="4.2-rc5"
> > +BR2_LINUX_KERNEL_DEFCONFIG="axs101"
> 
> Please force the version of the kernel headers, so that they match the
> kernel being built.

Well you see the problem here is we do need yet to be released Linux v4.2
because that's where both boards are finally exist.

So once v4.2 is released (in a couple of weeks now) and Buildroot is updated
I would assume v4.2 headers will become default version, right?
So then we're golden and there's no need to update these defconfigs.

As for kernel version itself as of today I HAVE TO specify custom version
(v4.2-rc5) just to have sources with our boards supported. In case of Buildroot
that means these defconfigs will be build successfully.

Still once v4.2 gets released (and I think it will happen well between some
Buildroots RCs) I will send an update that will effectively remove 
----->8-----
BR2_LINUX_KERNEL_CUSTOM_VERSION=y
BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="4.2-rc5"
----->8-----

So that's a question to you if you prefer to have headers pointing to 4.2-rc5
with right now:
----->8-----
BR2_KERNEL_HEADERS_VERSION=y
BR2_DEFAULT_KERNEL_VERSION="4.2-rc5"
----->8-----

or we're OK to have defconfigs as they are today (because everything builds
anyways with headers from 4.1) and have less clean-up on v4.2 release.

-Alexey

Dear Alexey Brodkin,

On Tue, 4 Aug 2015 13:17:06 +0000, Alexey Brodkin wrote:

> Opps dummy copy-paste from Busybox's example.
> Please pardon that silly thing.

No problem.

> Agree, that's a long-standing problem and if I'm not mistaken you guys
> advise to go for fs overlay if that kind of "feature" is required.
> 
> That said I'm not happy with that solution but having no other way I have to swallow

Yes, no problem with that.

> > Please force the version of the kernel headers, so that they match the
> > kernel being built.
> 
> Well you see the problem here is we do need yet to be released Linux v4.2
> because that's where both boards are finally exist.
> 
> So once v4.2 is released (in a couple of weeks now) and Buildroot is updated
> I would assume v4.2 headers will become default version, right?
> So then we're golden and there's no need to update these defconfigs.

You're wrong. After 4.2 becomes the default version, 4.3 will become
the default version. And then your defconfigs are broken.

So you *must* specify a custom kernel headers version. Just use 4.1,
this is good enough for a 4.2-rc kernel.

> As for kernel version itself as of today I HAVE TO specify custom version
> (v4.2-rc5) just to have sources with our boards supported. In case of Buildroot
> that means these defconfigs will be build successfully.
> 
> Still once v4.2 gets released (and I think it will happen well between some
> Buildroots RCs) I will send an update that will effectively remove 
> ----->8-----
> BR2_LINUX_KERNEL_CUSTOM_VERSION=y
> BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="4.2-rc5"
> ----->8-----

No, you will certainly *not* send such an update, because doing this is
wrong. 4.2 might be the default version for a while, but then it will
be 4.3, and you will not have tested this.

All defconfigs *must* use a fixed version of the kernel headers, kernel
and bootloader, so that we are relatively sure that they will continue
to build and boot even if we change the default kernel headers, kernel
or bootloader versions.

Please look at all other defconfigs. The qemu_* defconfigs are good
examples of doing things right since they are nicely maintained by
Gustavo.

Best regards,

Thomas

Hi Thomas,

On Tue, 2015-08-04 at 15:24 +0200, Thomas Petazzoni wrote:
> Dear Alexey Brodkin,

> > > Please force the version of the kernel headers, so that they match the
> > > kernel being built.
> > 
> > Well you see the problem here is we do need yet to be released Linux v4.2
> > because that's where both boards are finally exist.
> > 
> > So once v4.2 is released (in a couple of weeks now) and Buildroot is updated
> > I would assume v4.2 headers will become default version, right?
> > So then we're golden and there's no need to update these defconfigs.
> 
> You're wrong. After 4.2 becomes the default version, 4.3 will become
> the default version. And then your defconfigs are broken.

Hw, I do understand your concern with implicitly specified version of
kernel/headers but what I meant if I use "make savedefconfig" it eliminates
versions if they match today's defaults.

For example if today I select
--------->8---------
BR2_LINUX_KERNEL_VERSION="4.1.3"
BR2_DEFAULT_KERNEL_HEADERS="4.1.3"
--------->8---------

Then defconfig generated by "make savedefconfig" will be:
--------->8---------
BR2_arcle=y
BR2_TARGET_GENERIC_HOSTNAME="axs101"
BR2_TARGET_GENERIC_ISSUE="Welcome to the ARC Software Development Platform"
BR2_SYSTEM_DHCP="eth0"
BR2_ROOTFS_OVERLAY="board/synopsys/axs10x/fs-overlay"
BR2_LINUX_KERNEL=y
BR2_LINUX_KERNEL_DEFCONFIG="axs101"
BR2_TARGET_ROOTFS_INITRAMFS=y
BR2_TARGET_UBOOT=y
BR2_TARGET_UBOOT_BUILD_SYSTEM_KCONFIG=y
BR2_TARGET_UBOOT_BOARD_DEFCONFIG="axs101"
--------->8---------

Note there's no version of kernel/headers.

So now if I understood you correctly you propose to insert:
--------->8---------
BR2_LINUX_KERNEL_CUSTOM_VERSION=y
BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="4.2-rc5"
BR2_DEFAULT_KERNEL_HEADERS="4.1.3"
--------->8---------

in defconfigs today and later once v4.2 is released change defconfigs
like that:
--------->8---------
BR2_LINUX_KERNEL_VERSION="4.2.0"
BR2_DEFAULT_KERNEL_HEADERS="4.2.0"
--------->8---------

Right?

-Alexey

Alexey,

On Tue, 4 Aug 2015 13:37:04 +0000, Alexey Brodkin wrote:

> Hw, I do understand your concern with implicitly specified version of
> kernel/headers but what I meant if I use "make savedefconfig" it eliminates
> versions if they match today's defaults.

Not if you explicitly specify "custom version", i.e if you do:

	Kernel Headers (Manually specified Linux version)  ---> 
	(4.1) linux version

Then you get:

BR2_KERNEL_HEADERS_VERSION=y
BR2_DEFAULT_KERNEL_VERSION="4.1"

which is what we want.


> So now if I understood you correctly you propose to insert:
> --------->8---------
> BR2_LINUX_KERNEL_CUSTOM_VERSION=y
> BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="4.2-rc5"

Yes for kernel version.

> BR2_DEFAULT_KERNEL_HEADERS="4.1.3"

But no for kernel headers: see above what you should do.

Again, please look at qemu_*_defconfig, they do the right thing:

# Lock to 4.1 headers to avoid breaking with newer kernels
BR2_KERNEL_HEADERS_VERSION=y
BR2_DEFAULT_KERNEL_VERSION="4.1"
BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_4_1=y

# Kernel
BR2_LINUX_KERNEL=y
BR2_LINUX_KERNEL_CUSTOM_VERSION=y
BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="4.1"
BR2_LINUX_KERNEL_DEFCONFIG="vexpress"

Best regards,

Thomas

Hi Thomas,

On Tue, 2015-08-04 at 15:55 +0200, Thomas Petazzoni wrote:
> Alexey,
> 
> On Tue, 4 Aug 2015 13:37:04 +0000, Alexey Brodkin wrote:
> 
> > Hw, I do understand your concern with implicitly specified version of
> > kernel/headers but what I meant if I use "make savedefconfig" it eliminates
> > versions if they match today's defaults.
> 
> Not if you explicitly specify "custom version", i.e if you do:
> 
> 	Kernel Headers (Manually specified Linux version)  ---> 
> 	(4.1) linux version
> 
> Then you get:
> 
> BR2_KERNEL_HEADERS_VERSION=y
> BR2_DEFAULT_KERNEL_VERSION="4.1"
> 
> which is what we want.
> 
> 
> > So now if I understood you correctly you propose to insert:
> > --------->8---------
> > BR2_LINUX_KERNEL_CUSTOM_VERSION=y
> > BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="4.2-rc5"
> 
> Yes for kernel version.
> 
> > BR2_DEFAULT_KERNEL_HEADERS="4.1.3"
> 
> But no for kernel headers: see above what you should do.
> 
> Again, please look at qemu_*_defconfig, they do the right thing:
> 
> # Lock to 4.1 headers to avoid breaking with newer kernels
> BR2_KERNEL_HEADERS_VERSION=y
> BR2_DEFAULT_KERNEL_VERSION="4.1"
> BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_4_1=y
> 
> # Kernel
> BR2_LINUX_KERNEL=y
> BR2_LINUX_KERNEL_CUSTOM_VERSION=y
> BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="4.1"
> BR2_LINUX_KERNEL_DEFCONFIG="vexpress"

Ok I understood and already modified my defconfigs so they look
similar to qemu ones. Lesson learned.

Re-spin is on its way.

Thanks,
Alexey