[LEDE-DEV] Handling the image generation process on ARC770

Alexandru Gagniuc alex.g at adaptrum.com
Fri Jul 21 09:53:24 PDT 2017


Hello,

I am looking to write some rules to generate images on an SOC we're 
trying to port over.

I need a vmlinux-initramfs ELF file with DWARF debugging information. 
This is useful because it goes straight to gdb and can be loaded over 
JTAG. I can write the following rule:

define Device/adaptrum-device
	KERNEL_SUFFIX := .elf
	KERNEL := kernel-bin | patch-dtb
	KERNEL_INITRAMFS_NAME = vmlinux-initramfs.debug
	KERNEL_SUFFIX := .elf
	DEVICE_PROFILE := adaptrum
	DEVICE_DTS := adaptrum_device_dts
endef

Now, I need a uImage with initramfs that can be loaded from u-boot. This 
is useful, since we don't yet have any working drivers for the 
underlying storage media. At this point, I can write the following rule:

define Device/adaptrum-device
	KERNEL_SUFFIX := -uImage
	KERNEL := kernel-bin | patch-dtb | uImage none
	KERNEL_NAME := vmlinux
	KERNEL_ENTRY := $(call kernel_ep,$(KDIR)/$$(KERNEL_INITRAMFS_NAME).elf)
	KERNEL_INITRAMFS_NAME := vmlinux-initramfs
	KERNEL_INITRAMFS := kernel-bin | patch-dtb | uImage none
	DEVICE_DTS := adaptrum_device_fpga
	DEVICE_PROFILE := adaptrum
endef

Because the two rules now need a different KERNEL_INITRAMFS_NAME, we 
can't really put them in one rule. It seems illogical to define two 
devices to generate different images for the same device.

But wait! there's more!! Now I also need a uImage without an initramfs. 
Because arc decided to put .init.ramfs before the entry point, we need 
to change the entry point too:

	KERNEL_ENTRY := $(call kernel_ep,$(KDIR)/$$(KERNEL_NAME).elf)

That's fine, but now the initramfs-uImage no longer works. As a result, 
if I want a kernel ELF, kernel initramfs elf, uImage, and initramfs 
uImage, I really need three different "define Device/"

I'm assuming that's not how the buildsystem was designed. Is there any 
sensible way of putting these rules together into a single 'define Device/'?

Alex



More information about the Lede-dev mailing list