KumiSystems/openwrtv3
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity
openwrtv3/target/linux/archs38/image/Makefile

85 lines
2.6 KiB
Makefile
Raw Normal View History

linux: add support of Synopsys ARCHS38-based boards This patch introduces support of new boards with ARC HS38 cores. ARC HS38 is a new generation of ARC cores which utilize ARCv2 ISA. As with ARC770 we're addind support for 2 boards for now: [1] Synopsys SDP board (AXS103) This is the same base-board as in AXS101 but with FPGA-based CPU-tile where ARCHs38 core is implemented. [2] nSIM Again this is the same simulation engine but configured for new instruction set and features of new CPU. Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com> Cc: Felix Fietkau <nbd@openwrt.org> Cc: Jo-Philipp Wich <jow@openwrt.org> Cc: Jonas Gorski <jogo@openwrt.org> SVN-Revision: 48740
2016-02-18 08:22:32 +00:00
#
# Copyright (C) 2016 OpenWrt.org
#
# This is free software, licensed under the GNU General Public License v2.
# See /LICENSE for more information.
#
include $(TOPDIR)/rules.mk
include $(INCLUDE_DIR)/image.mk
arc: Build uImage as well as vmlinux output files Initially for ARC we were building vmlinux images because it was both simpler and more convenient to debug Linux kernel in runt-time via JTAG. Now when base system works quite nice we may finally use U-Boot for loading the system image as well. Still we keep building vmlinux images as some of our boards are development boards and loading images with JTAG could be at some points very beneficial. Note for U-Boot header it's required to specify 2 values: * loading address * entry point (if it doesn't match loading address) and in case of ARC entry point (EP) not only differs from loading address but also changes from build to build due to initramfs being placed between loading address and text section. To accommodate that feature we have to calculate EP after vmlinux gets built and before call to mkimage. Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
2016-05-31 17:12:21 +00:00
# On ARC initramfs is put before entry point and so entry point moves
# in memory from build to built. Thus we need to extract EP from vmlinux
# every time before generation of uImage.
define Build/calculate-ep
archs38: Merge sd and ramfs subtargets in generic again As it turned out we may actually build both initramfs and SD-based images in one run with just a small tweak in existing image/Makefile and so we do here. We're back with one "generic" target for all ARC HS38-based bords. Kudos to John for his patience and very helpful tips! Signed-off-by: John Crispin <john@phrozen.org> Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com> Cc: Jo-Philipp Wich <jo@mein.io>
2016-08-19 10:58:36 +00:00
$(eval KERNEL_ENTRY=$(shell $(KERNEL_CROSS)readelf -h $(1) | grep "Entry point address" | grep -o 0x.*))
arc: Build uImage as well as vmlinux output files Initially for ARC we were building vmlinux images because it was both simpler and more convenient to debug Linux kernel in runt-time via JTAG. Now when base system works quite nice we may finally use U-Boot for loading the system image as well. Still we keep building vmlinux images as some of our boards are development boards and loading images with JTAG could be at some points very beneficial. Note for U-Boot header it's required to specify 2 values: * loading address * entry point (if it doesn't match loading address) and in case of ARC entry point (EP) not only differs from loading address but also changes from build to build due to initramfs being placed between loading address and text section. To accommodate that feature we have to calculate EP after vmlinux gets built and before call to mkimage. Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
2016-05-31 17:12:21 +00:00
endef
archs38: Introduce images for SD-cards Historically on ARC we started from initramfs-based images because: a) It was much easier to debug especially when toolchain and other components were changing quite dynamically b) It was our usual approach for embedded Linux But now with ARC port of Lede/OpenWRT getting more stable and mature we're ready for more real-life scenarios with FS permanently stored on SD-card. This essentially benefits from ability to setup devices that survive reboots with all settings and extra packages kept in place. Still we keep an ability to build images with initramfs. This allows us to use storage-less simulators for testing still. Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com> Cc: John Crispin <john@phrozen.org>
2016-08-16 11:49:20 +00:00
define Build/patch-dtb
$(STAGING_DIR_HOST)/bin/patch-dtb $@ $(DTS_DIR)/$(DEVICE_DTS).dtb
linux: add support of Synopsys ARCHS38-based boards This patch introduces support of new boards with ARC HS38 cores. ARC HS38 is a new generation of ARC cores which utilize ARCv2 ISA. As with ARC770 we're addind support for 2 boards for now: [1] Synopsys SDP board (AXS103) This is the same base-board as in AXS101 but with FPGA-based CPU-tile where ARCHs38 core is implemented. [2] nSIM Again this is the same simulation engine but configured for new instruction set and features of new CPU. Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com> Cc: Felix Fietkau <nbd@openwrt.org> Cc: Jo-Philipp Wich <jow@openwrt.org> Cc: Jonas Gorski <jogo@openwrt.org> SVN-Revision: 48740
2016-02-18 08:22:32 +00:00
endef
archs38: Introduce images for SD-cards Historically on ARC we started from initramfs-based images because: a) It was much easier to debug especially when toolchain and other components were changing quite dynamically b) It was our usual approach for embedded Linux But now with ARC port of Lede/OpenWRT getting more stable and mature we're ready for more real-life scenarios with FS permanently stored on SD-card. This essentially benefits from ability to setup devices that survive reboots with all settings and extra packages kept in place. Still we keep an ability to build images with initramfs. This allows us to use storage-less simulators for testing still. Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com> Cc: John Crispin <john@phrozen.org>
2016-08-16 11:49:20 +00:00
ifneq ($(CONFIG_TARGET_ROOTFS_INITRAMFS),)
# Root FS built-in
arc: Build uImage as well as vmlinux output files Initially for ARC we were building vmlinux images because it was both simpler and more convenient to debug Linux kernel in runt-time via JTAG. Now when base system works quite nice we may finally use U-Boot for loading the system image as well. Still we keep building vmlinux images as some of our boards are development boards and loading images with JTAG could be at some points very beneficial. Note for U-Boot header it's required to specify 2 values: * loading address * entry point (if it doesn't match loading address) and in case of ARC entry point (EP) not only differs from loading address but also changes from build to build due to initramfs being placed between loading address and text section. To accommodate that feature we have to calculate EP after vmlinux gets built and before call to mkimage. Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
2016-05-31 17:12:21 +00:00
define Device/vmlinux
archs38: Introduce images for SD-cards Historically on ARC we started from initramfs-based images because: a) It was much easier to debug especially when toolchain and other components were changing quite dynamically b) It was our usual approach for embedded Linux But now with ARC port of Lede/OpenWRT getting more stable and mature we're ready for more real-life scenarios with FS permanently stored on SD-card. This essentially benefits from ability to setup devices that survive reboots with all settings and extra packages kept in place. Still we keep an ability to build images with initramfs. This allows us to use storage-less simulators for testing still. Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com> Cc: John Crispin <john@phrozen.org>
2016-08-16 11:49:20 +00:00
KERNEL_SUFFIX := .elf
archs38: fix parallel build issue Signed-off-by: Felix Fietkau <nbd@nbd.name>
2017-01-11 10:17:13 +00:00
KERNEL := kernel-bin | patch-dtb
archs38: Introduce images for SD-cards Historically on ARC we started from initramfs-based images because: a) It was much easier to debug especially when toolchain and other components were changing quite dynamically b) It was our usual approach for embedded Linux But now with ARC port of Lede/OpenWRT getting more stable and mature we're ready for more real-life scenarios with FS permanently stored on SD-card. This essentially benefits from ability to setup devices that survive reboots with all settings and extra packages kept in place. Still we keep an ability to build images with initramfs. This allows us to use storage-less simulators for testing still. Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com> Cc: John Crispin <john@phrozen.org>
2016-08-16 11:49:20 +00:00
KERNEL_INITRAMFS_NAME = vmlinux-initramfs.elf
arc: Build uImage as well as vmlinux output files Initially for ARC we were building vmlinux images because it was both simpler and more convenient to debug Linux kernel in runt-time via JTAG. Now when base system works quite nice we may finally use U-Boot for loading the system image as well. Still we keep building vmlinux images as some of our boards are development boards and loading images with JTAG could be at some points very beneficial. Note for U-Boot header it's required to specify 2 values: * loading address * entry point (if it doesn't match loading address) and in case of ARC entry point (EP) not only differs from loading address but also changes from build to build due to initramfs being placed between loading address and text section. To accommodate that feature we have to calculate EP after vmlinux gets built and before call to mkimage. Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
2016-05-31 17:12:21 +00:00
endef
archs38: Reduce generalization As support of ARC HS38 in OpenWRT/Lede matures we don't need debug-only output binaries any longer, so purging vmlinux for AXS10x boards. As for uImage for nSIM it makes completely no sense because there's no way to run U-Boot on nSIM. So we remove add_archs38_XXX scripts making code more compact and cleaner. Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
2016-08-16 11:49:17 +00:00
define Device/nsim_hs
$(call Device/vmlinux)
DEVICE_PROFILE := nsim_hs
DEVICE_DTS := nsim_hs_idu
linux: add support of Synopsys ARCHS38-based boards This patch introduces support of new boards with ARC HS38 cores. ARC HS38 is a new generation of ARC cores which utilize ARCv2 ISA. As with ARC770 we're addind support for 2 boards for now: [1] Synopsys SDP board (AXS103) This is the same base-board as in AXS101 but with FPGA-based CPU-tile where ARCHs38 core is implemented. [2] nSIM Again this is the same simulation engine but configured for new instruction set and features of new CPU. Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com> Cc: Felix Fietkau <nbd@openwrt.org> Cc: Jo-Philipp Wich <jow@openwrt.org> Cc: Jonas Gorski <jogo@openwrt.org> SVN-Revision: 48740
2016-02-18 08:22:32 +00:00
endef
archs38: Reduce generalization As support of ARC HS38 in OpenWRT/Lede matures we don't need debug-only output binaries any longer, so purging vmlinux for AXS10x boards. As for uImage for nSIM it makes completely no sense because there's no way to run U-Boot on nSIM. So we remove add_archs38_XXX scripts making code more compact and cleaner. Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
2016-08-16 11:49:17 +00:00
TARGET_DEVICES += nsim_hs
archs38: Merge sd and ramfs subtargets in generic again As it turned out we may actually build both initramfs and SD-based images in one run with just a small tweak in existing image/Makefile and so we do here. We're back with one "generic" target for all ARC HS38-based bords. Kudos to John for his patience and very helpful tips! Signed-off-by: John Crispin <john@phrozen.org> Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com> Cc: Jo-Philipp Wich <jo@mein.io>
2016-08-19 10:58:36 +00:00
endif
archs38: Introduce images for SD-cards Historically on ARC we started from initramfs-based images because: a) It was much easier to debug especially when toolchain and other components were changing quite dynamically b) It was our usual approach for embedded Linux But now with ARC port of Lede/OpenWRT getting more stable and mature we're ready for more real-life scenarios with FS permanently stored on SD-card. This essentially benefits from ability to setup devices that survive reboots with all settings and extra packages kept in place. Still we keep an ability to build images with initramfs. This allows us to use storage-less simulators for testing still. Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com> Cc: John Crispin <john@phrozen.org>
2016-08-16 11:49:20 +00:00
# Root FS on SD-card
KERNEL_LOADADDR := 0x80000000
archs38: fix parallel build issue Signed-off-by: Felix Fietkau <nbd@nbd.name>
2017-01-11 10:17:13 +00:00
DEVICE_DTS_LIST:= axs103_idu nsim_hs_idu
archs38: Introduce images for SD-cards Historically on ARC we started from initramfs-based images because: a) It was much easier to debug especially when toolchain and other components were changing quite dynamically b) It was our usual approach for embedded Linux But now with ARC port of Lede/OpenWRT getting more stable and mature we're ready for more real-life scenarios with FS permanently stored on SD-card. This essentially benefits from ability to setup devices that survive reboots with all settings and extra packages kept in place. Still we keep an ability to build images with initramfs. This allows us to use storage-less simulators for testing still. Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com> Cc: John Crispin <john@phrozen.org>
2016-08-16 11:49:20 +00:00
FAT32_BLOCK_SIZE=1024
FAT32_BLOCKS=$(shell echo $$(($(CONFIG_AXS10X_SD_BOOT_PARTSIZE)*1024*1024/$(FAT32_BLOCK_SIZE))))
define Image/Build/SDCard
rm -f $(KDIR_TMP)/$(IMG_PREFIX)-$(PROFILE)-boot.img
tools: remove old mkdosfs symlink from dosfstools Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
2016-10-11 12:43:23 +00:00
mkfs.fat $(KDIR_TMP)/$(IMG_PREFIX)-$(PROFILE)-boot.img -C $(FAT32_BLOCKS)
archs38: Introduce images for SD-cards Historically on ARC we started from initramfs-based images because: a) It was much easier to debug especially when toolchain and other components were changing quite dynamically b) It was our usual approach for embedded Linux But now with ARC port of Lede/OpenWRT getting more stable and mature we're ready for more real-life scenarios with FS permanently stored on SD-card. This essentially benefits from ability to setup devices that survive reboots with all settings and extra packages kept in place. Still we keep an ability to build images with initramfs. This allows us to use storage-less simulators for testing still. Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com> Cc: John Crispin <john@phrozen.org>
2016-08-16 11:49:20 +00:00
mkimage -C none -A arc -T script -d uEnv.txt $(BIN_DIR)/uEnv.scr
mcopy -i $(KDIR_TMP)/$(IMG_PREFIX)-$(PROFILE)-boot.img $(BIN_DIR)/uEnv.scr ::boot.scr
mcopy -i $(KDIR_TMP)/$(IMG_PREFIX)-$(PROFILE)-boot.img $(DTS_DIR)/*.dtb ::
mcopy -i $(KDIR_TMP)/$(IMG_PREFIX)-$(PROFILE)-boot.img $(BIN_DIR)/$(IMG_PREFIX)-uImage ::uImage
./gen_axs10x_sdcard_img.sh \
$(BIN_DIR)/$(IMG_PREFIX)-$(PROFILE)-sdcard-vfat-$(1).img \
$(KDIR_TMP)/$(IMG_PREFIX)-$(PROFILE)-boot.img \
$(KDIR)/root.$(1) \
$(CONFIG_AXS10X_SD_BOOT_PARTSIZE) \
$(CONFIG_TARGET_ROOTFS_PARTSIZE)
ifneq ($(CONFIG_TARGET_IMAGES_GZIP),)
gzip -f9n $(BIN_DIR)/$(IMG_PREFIX)-$(PROFILE)-sdcard-vfat-$(1).img
endif
endef
define Image/BuildKernel
# Build unified uImage
archs38: Merge sd and ramfs subtargets in generic again As it turned out we may actually build both initramfs and SD-based images in one run with just a small tweak in existing image/Makefile and so we do here. We're back with one "generic" target for all ARC HS38-based bords. Kudos to John for his patience and very helpful tips! Signed-off-by: John Crispin <john@phrozen.org> Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com> Cc: Jo-Philipp Wich <jo@mein.io>
2016-08-19 10:58:36 +00:00
$(call Build/calculate-ep, $(KDIR)/vmlinux.elf)
archs38: Introduce images for SD-cards Historically on ARC we started from initramfs-based images because: a) It was much easier to debug especially when toolchain and other components were changing quite dynamically b) It was our usual approach for embedded Linux But now with ARC port of Lede/OpenWRT getting more stable and mature we're ready for more real-life scenarios with FS permanently stored on SD-card. This essentially benefits from ability to setup devices that survive reboots with all settings and extra packages kept in place. Still we keep an ability to build images with initramfs. This allows us to use storage-less simulators for testing still. Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com> Cc: John Crispin <john@phrozen.org>
2016-08-16 11:49:20 +00:00
$(call Image/BuildKernel/MkuImage, \
none, $(KERNEL_LOADADDR), $(KERNEL_ENTRY), \
$(KDIR)/vmlinux, \
$(BIN_DIR)/$(IMG_PREFIX)-uImage \
)
# Build .dtb for all boards we may run on
archs38: fix parallel build issue Signed-off-by: Felix Fietkau <nbd@nbd.name>
2017-01-11 10:17:13 +00:00
$(foreach dts,$(DEVICE_DTS_LIST),
$(call Image/BuildDTB,$(DTS_DIR)/$(dts).dts,$(DTS_DIR)/$(dts).dtb)
)
archs38: Introduce images for SD-cards Historically on ARC we started from initramfs-based images because: a) It was much easier to debug especially when toolchain and other components were changing quite dynamically b) It was our usual approach for embedded Linux But now with ARC port of Lede/OpenWRT getting more stable and mature we're ready for more real-life scenarios with FS permanently stored on SD-card. This essentially benefits from ability to setup devices that survive reboots with all settings and extra packages kept in place. Still we keep an ability to build images with initramfs. This allows us to use storage-less simulators for testing still. Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com> Cc: John Crispin <john@phrozen.org>
2016-08-16 11:49:20 +00:00
endef
define Image/Build
$(call Image/Build/$(1),$(1))
$(call Image/Build/SDCard,$(1))
dd if=$(KDIR)/root.$(1) of=$(BIN_DIR)/$(IMG_PREFIX)-root.$(1) bs=128k conv=sync
endef
linux: add support of Synopsys ARCHS38-based boards This patch introduces support of new boards with ARC HS38 cores. ARC HS38 is a new generation of ARC cores which utilize ARCv2 ISA. As with ARC770 we're addind support for 2 boards for now: [1] Synopsys SDP board (AXS103) This is the same base-board as in AXS101 but with FPGA-based CPU-tile where ARCHs38 core is implemented. [2] nSIM Again this is the same simulation engine but configured for new instruction set and features of new CPU. Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com> Cc: Felix Fietkau <nbd@openwrt.org> Cc: Jo-Philipp Wich <jow@openwrt.org> Cc: Jonas Gorski <jogo@openwrt.org> SVN-Revision: 48740
2016-02-18 08:22:32 +00:00
$(eval $(call BuildImage))
Reference in a new issue Copy permalink