I don't get this patch - do we still need packages/kernel/serengeti_cheetah-kernel-x86_64.mk? kernel.inc does
all
the heavy lifting now. Or not?
My understanding is that packages/kernel/serengeti_cheetah-kernel-
x86_64.mk
sets the kernel version, url, config file, etc. kernel.inc builds the kernel you specified in the .mk file.
is there enough different about it that we need two files? I was planning on setting the configuration information in the platform configuration:
ifeq ($(CONFIG_TARGET_64BIT),y) KERNEL_VERSION=2.6.22.2
KERNEL_MK=$(PACKAGE_DIR)/kernel/serengeti_cheetah-kernel-x86_64.mk
So do you want to remove this line if you only want one .mk file? Do we want to make a new variable CONFIG_TINY that downloads the tiny patches for the KERNEL_VERSION we've selected? Once we go that far is there any reason to have board-specific .mk files for the kernel at all? That would be nice from my perspective (many of the boards can/do use the same kernel versions), but it is a major change.
Myles
KERNEL_CONFIG=$(PACKAGE_DIR)/kernel/conf/defconfig-serengeti_cheetah- x86_64 BUSYBOX_CONFIG=defconfig-serengeti_cheetah-x86_64 UCLIBC_VER=0.9.29 UCLIBC_CONFIG=defconfig-x86_64 else KERNEL_VERSION=2.6.20.2 KERNEL_CONFIG=$(PACKAGE_DIR)/kernel/conf/defconfig-serengeti_cheetah UCLIBC_VER=0.9.28 endif
That would save us having to have mutiple copies of the kernel make files for 32 and 64 bit. Is this bad?
Jordan
The other two files are Config.lb files depending on which payload you
want
to use.
Yes - those made sense to me.
Myles
Jordan
-- Jordan Crouse Systems Software Development Engineer Advanced Micro Devices, Inc.