board: add support for ARC AXS101 and AXS103 Software Development Platforms
PATCH 1/1 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/
--- 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
board/synopsys/axs10x/fs-overlay/etc/inittab new file +41 -0
@@ -0,0 +1,41 @@ +# /etc/inittab +# +# Copyright (C) 2001 Erik Andersen <[email protected]> +# +# 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 + +# /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 + +# Stuff to do for the 3-finger salute +::ctrlaltdel:/sbin/reboot + +# Stuff to do before rebooting +::shutdown:/etc/init.d/rcK +::shutdown:/sbin/swapoff -a +::shutdown:/bin/umount -a -r +
configs/snps_axs101_defconfig new file +13 -0
@@ -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" +BR2_TARGET_ROOTFS_INITRAMFS=y +BR2_TARGET_UBOOT=y +BR2_TARGET_UBOOT_BUILD_SYSTEM_KCONFIG=y +BR2_TARGET_UBOOT_BOARD_DEFCONFIG="axs101"
configs/snps_axs103_defconfig new file +14 -0
@@ -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" +BR2_LINUX_KERNEL_DEFCONFIG="axs103_smp" +BR2_TARGET_ROOTFS_INITRAMFS=y +BR2_TARGET_UBOOT=y +BR2_TARGET_UBOOT_BUILD_SYSTEM_KCONFIG=y +BR2_TARGET_UBOOT_BOARD_DEFCONFIG="axs103"
Signature · 1 line
2.4.3
PATCH 1/1 board: add support for ARC AXS101 and AXS103 Software Development Platforms
Alexey,
Quoted 22 lines · Alexey Brodkin
board/synopsys/axs10x/fs-overlay/etc/inittab new file +16
-0@@ -0,0 +1,41 @@ +# /etc/inittab +# +# Copyright (C) 2001 Erik Andersen <[email protected]> +# +# 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
board/synopsys/axs10x/fs-overlay/etc/inittab line 26
Quoted 10 lines
board/synopsys/axs10x/fs-overlay/etc/inittab new file +10
-0+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?
board/synopsys/axs10x/fs-overlay/etc/inittab line 32
Quoted 6 lines
board/synopsys/axs10x/fs-overlay/etc/inittab new file +6
-0+ +# /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.
Quoted 6 lines
configs/snps_axs101_defconfig new file +0
-0
configs/snps_axs101_defconfig line 9
Quoted 9 lines
configs/snps_axs101_defconfig new file +9
-0@@ -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.
Quoted 10 lines
configs/snps_axs101_defconfig new file +4
-0+BR2_TARGET_ROOTFS_INITRAMFS=y +BR2_TARGET_UBOOT=y +BR2_TARGET_UBOOT_BUILD_SYSTEM_KCONFIG=y +BR2_TARGET_UBOOT_BOARD_DEFCONFIG="axs101"configs/snps_axs103_defconfig new file +0
-0
configs/snps_axs103_defconfig line 9
Quoted 9 lines
configs/snps_axs103_defconfig new file +9
-0@@ -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
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com
PATCH 1/1 board: add support for ARC AXS101 and AXS103 Software Development Platforms
Hi Thomas,
Quoted 30 lines · Thomas Petazzoni
Alexey,
Quoted 26 lines · Alexey Brodkin
board/synopsys/axs10x/fs-overlay/etc/inittab new file +20
-0@@ -0,0 +1,41 @@ +# /etc/inittab +# +# Copyright (C) 2001 Erik Andersen <[email protected]> +# +# 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
Quoted 8 lines
board/synopsys/axs10x/fs-overlay/etc/inittab line 26
Quoted 6 lines
board/synopsys/axs10x/fs-overlay/etc/inittab new file +6
-0+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_SHELLWhy?
Opps dummy copy-paste from Busybox's example.
Please pardon that silly thing.
Quoted 9 lines
board/synopsys/axs10x/fs-overlay/etc/inittab line 32
Quoted 6 lines
board/synopsys/axs10x/fs-overlay/etc/inittab new file +6
-0+ +# /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 vt100It'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
Quoted 10 lines
Quoted 10 lines
configs/snps_axs101_defconfig new file +4
-0@@ -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"
Quoted 8 lines
configs/snps_axs101_defconfig line 9
Quoted 5 lines
configs/snps_axs101_defconfig new file +5
-0+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
PATCH 1/1 board: add support for ARC AXS101 and AXS103 Software Development Platforms
Dear Alexey Brodkin,
Quoted 2 lines · Alexey Brodkin
Opps dummy copy-paste from Busybox's example.
Please pardon that silly thing.
No problem.
Quoted 4 lines
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.
Quoted 9 lines
Quoted 2 lines
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.
Quoted 10 lines
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
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com
PATCH 1/1 board: add support for ARC AXS101 and AXS103 Software Development Platforms
Hi Thomas,
Quoted 8 lines · Thomas Petazzoni
Dear Alexey Brodkin,
Quoted 6 lines
Quoted 2 lines
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.
Quoted 6 lines
Quoted 3 lines
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
PATCH 1/1 board: add support for ARC AXS101 and AXS103 Software Development Platforms
Alexey,
Quoted 3 lines · Alexey Brodkin
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.
Quoted 4 lines
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.
Quoted 1 line
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
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com
PATCH 1/1 board: add support for ARC AXS101 and AXS103 Software Development Platforms
Hi Thomas,
Quoted 39 lines · Thomas Petazzoni
Alexey,
Quoted 3 lines · Alexey Brodkin
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 versionThen you get:
BR2_KERNEL_HEADERS_VERSION=y
BR2_DEFAULT_KERNEL_VERSION="4.1"which is what we want.
Quoted 4 lines
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.
Quoted 1 line
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
Quoted 5 lines
# 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