Microblaze: build kernel with device tree
PATCH 4/5 Microblaze: build kernel with device tree
Device Tree and SimpleImage will be handled in buildroot in the future. Until then, this patch is needed.
--- linux/Config.in | 8 ++++++++ linux/linux.mk | 16 ++++++++++++++++ 2 files changed, 24 insertions(+), 0 deletions(-)
linux/Config.in +8 -0
@@ -120,6 +120,14 @@ config BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE help Path to the kernel configuration file +config BR2_LINUX_KERNEL_DTS_FILE + string "Device Tree dts file location" + depends on BR2_microblaze + help + Path from where the dts file has to be copied + The final "custom target" name depends on the + dts file name: + <name>.dts --> simpleImage.<name> # # Binary format #
linux/linux.mk +16 -0
@@ -117,6 +117,18 @@ endef LINUX_POST_PATCH_HOOKS += LINUX_APPLY_PATCHES +ifeq ($(KERNEL_ARCH),microblaze) +# on microblaze, we always want mkimage +LINUX_DEPENDENCIES+=host-uboot-tools + +define LINUX_COPY_DTS + if test -f "$(BR2_LINUX_KERNEL_DTS_FILE)" ; then \ + cp $(BR2_LINUX_KERNEL_DTS_FILE) $(@D)/arch/microblaze/boot/dts ; \ + else \ + echo "Cannot copy dts file!" ; \ + fi +endef +endif ifeq ($(BR2_LINUX_KERNEL_USE_DEFCONFIG),y) KERNEL_SOURCE_CONFIG = $(KERNEL_ARCH_PATH)/configs/$(call qstrip,$(BR2_LINUX_KERNEL_DEFCONFIG))_defconfig
@@ -131,6 +143,8 @@ define LINUX_CONFIGURE_CMDS $(if $(BR2_ARM_EABI), $(call KCONFIG_ENABLE_OPT,CONFIG_AEABI,$(@D)/.config), $(call KCONFIG_DISABLE_OPT,CONFIG_AEABI,$(@D)/.config)) + $(if $(BR2_microblaze), + $(call LINUX_COPY_DTS)) # As the kernel gets compiled before root filesystems are # built, we create a fake cpio file. It'll be # replaced later by the real cpio archive, and the kernel will be
@@ -215,6 +229,8 @@ $(LINUX_DIR)/.stamp_initramfs_rebuilt: $(LINUX_DIR)/.stamp_target_installed $(LI $(TARGET_MAKE_ENV) $(MAKE) $(LINUX_MAKE_FLAGS) -C $(@D) $(LINUX_IMAGE_NAME) # Copy the kernel image to its final destination cp $(LINUX_IMAGE_PATH) $(BINARIES_DIR) + # If there is a .ub file copy it to the final destination + test -f $(LINUX_IMAGE_PATH).ub && cp $(LINUX_IMAGE_PATH).ub $(BINARIES_DIR) $(Q)touch $@ # The initramfs building code must make sure this target gets called
Signature · 9 lines
1.7.0.4 -- reLinux - Stephan Hoffmann Am Schmidtgrund 124 50765 K?ln Tel. +49.221.95595-19 Fax: -64 www.reLinux.de sho at reLinux.de
PATCH 4/5 Microblaze: build kernel with device tree
Hello,
Le Sun, 11 Mar 2012 17:50:17 +0100,
Stephan Hoffmann <[email protected]> a ?crit :
Quoted 4 lines
Device Tree and SimpleImage will be handled in buildroot in the future. Until then, this patch is needed.
Signed-off-by Stephan Hoffmann <[email protected]>
I am not yet familiar with how the device tree blob is generated, but I don't like the fact that this patch is Microblaze specific. Other architectures such as ARM or PowerPC have device tree support, and I think the build procedure of the device tree blob is the same regardless of the architecture.
linux/Config.in config BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE · line 125
Quoted 3 lines
linux/Config.in +3
-0+config BR2_LINUX_KERNEL_DTS_FILE + string "Device Tree dts file location" + depends on BR2_microblaze
or ARM or PowerPC
linux/Config.in config BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE · line 130
Quoted 5 lines
linux/Config.in +5
-0+ help + Path from where the dts file has to be copied + The final "custom target" name depends on the + dts file name: + <name>.dts --> simpleImage.<name>
This option should allow to set either a dts file that is outside the kernel tree, or a dts file that is inside the kernel tree. Or maybe we need two different options.
linux/linux.mk endef · line 122
Quoted 3 lines
linux/linux.mk +3
-0+ifeq ($(KERNEL_ARCH),microblaze) +# on microblaze, we always want mkimage +LINUX_DEPENDENCIES+=host-uboot-tools
Can't you create a new kernel image type (along BR2_LINUX_KERNEL_UIMAGE, BR2_LINUX_KERNEL_BZIMAGE, BR2_LINUX_KERNEL_ZIMAGE, etc.) which would add this dependency?
linux/linux.mk endef · line 131
Quoted 8 lines
linux/linux.mk +8
-0+define LINUX_COPY_DTS + if test -f "$(BR2_LINUX_KERNEL_DTS_FILE)" ; then \ + cp $(BR2_LINUX_KERNEL_DTS_FILE) $(@D)/arch/microblaze/boot/dts ; \ + else \ + echo "Cannot copy dts file!" ; \ + fi +endef +endif
The macro should probably bail out with an exit 1 if it fails. Also the macro shouldn't be microblaze specific. Shouldn't we be calling the Device Tree Compiler directly instead?
linux/linux.mk define LINUX_CONFIGURE_CMDS · line 147
Quoted 8 lines
ifeq ($(BR2_LINUX_KERNEL_USE_DEFCONFIG),y)
KERNEL_SOURCE_CONFIG= $(KERNEL_ARCH_PATH)/configs/$(call qstrip,$(BR2_LINUX_KERNEL_DEFCONFIG))_defconfiglinux/linux.mk +2
-0@@ -131,6 +143,8 @@ define LINUX_CONFIGURE_CMDS $(if $(BR2_ARM_EABI), $(call KCONFIG_ENABLE_OPT,CONFIG_AEABI,$(@D)/.config), $(call KCONFIG_DISABLE_OPT,CONFIG_AEABI,$(@D)/.config)) + $(if $(BR2_microblaze), + $(call LINUX_COPY_DTS))
The if is not needed, the LINUX_COPY_DTS is already defined conditionally.
linux/linux.mk $(LINUX_DIR)/.stamp_initramfs_rebuilt: $(LINUX_DIR)/.stamp_target_installed $(LI · line 233
Quoted 9 lines
linux/linux.mk +2
-0# As the kernel gets compiled before root filesystems are # built, we create a fake cpio file. It'll be # replaced later by the real cpio archive, and the kernel will be@@ -215,6 +229,8 @@ $(LINUX_DIR)/.stamp_initramfs_rebuilt: $(LINUX_DIR)/.stamp_target_installed $(LI $(TARGET_MAKE_ENV) $(MAKE) $(LINUX_MAKE_FLAGS) -C $(@D) $(LINUX_IMAGE_NAME) # Copy the kernel image to its final destination cp $(LINUX_IMAGE_PATH) $(BINARIES_DIR) + # If there is a .ub file copy it to the final destination + test -f $(LINUX_IMAGE_PATH).ub && cp $(LINUX_IMAGE_PATH).ub $(BINARIES_DIR)
What is this .ub file?
In other words: I agree with the goal of support the device tree in the kernel build process, but I'm not yet satisfied with this current proposal. Can we try to improve this?
Best regards,
Thomas
Signature · 4 lines
Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com
PATCH 4/5 Microblaze: build kernel with device tree
Quoted 10 lines · On Monday 12 March 2012 23:10:55 Thomas Petazzoni wrote:
Quoted 4 lines
Device Tree and SimpleImage will be handled in buildroot in the future. Until then, this patch is needed.
Signed-off-by Stephan Hoffmann <[email protected]>I am not yet familiar with how the device tree blob is generated, but I don't like the fact that this patch is Microblaze specific. Other architectures such as ARM or PowerPC have device tree support, and I think the build procedure of the device tree blob is the same regardless of the architecture.
I fully agree that we should have DTS support in buildroot. However:
- Stephan doesn't see how to do it, and
- for microblaze, the kernel source provides slightly different targets than for arm/powerpc.
If I understand correctly, for microblaze, you *have* to use a
simpleImage, which is a uImage with a DTB subimage. In other words, unless we have some kind of DTS support in buildroot, we can't support microblaze.
Since nobody seems to be stepping up to add generic DTS support, that
means microblaze is blocked. That, I think, is stupid. If we have working patches for microblaze now, why not accept them? We can always add DTS support later and refactor the microblaze-specific stuff away. In fact, this microblaze-specific stuff makes it easier to add generic DTS support, because you already get a defconfig that uses it and that you can use for testing.
That said, your other comments are still valid and this patch is not yet
ready for inclusion.
Regards,
Arnout
Signature · 6 lines
Arnout Vandecappelle arnout at mind be Senior Embedded Software Architect +32-16-286540 Essensium/Mind http://www.mind.be G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle GPG fingerprint: 7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F
PATCH 4/5 Microblaze: build kernel with device tree
They way I'm using this now is, with the patches I sent to the list:
1.- Configure buildroot to make a .cpio filesystem 2.- Manually copy the DTS file under output/build/linux-3.2.6/arch/microblaze/boot/dts/lx9.dts 3.- Under kernel configuration, set CONFIG_BLK_DEV_INITRD=y and CONFIG_INITRAMFS_SOURCE=../../images/rootfs.cpio
4.- Under buildroot configuration, set BR2_LINUX_KERNEL_IMAGE_TARGET_NAME=simpleImage.lx9
After this, I can make and I get a full working system under output/build/linux-3.2.6/arch/micr oblaze/boot/simpleImage.lx9
My understanding of this is the following:
Current patches allow filesystem development for microblaze, including kernel. The only thing it does not provide is the ability to generate a merged filesystem+kernel, ability which isn't available for any other arch. In my opinion, current patches could be applied for next release.
On the other hand, for addional steps are required to get to a simpleImage
Step 1 is dependant on the desired image, (maybe you want a gzip'ed or bzip2'ed filesystem). This has implications on the kernel configuration, since it needs to be able to decompress a gzip image or a cpio filesystem (CONFIG_RD_GZIP, CONFIG_RD_BZIP2 and others). This can be solved with the appropiate buildroot defconfig that is consistent with the kernel defconfig.
Step 2 requires a BR2_DTS_FILE config option. This may trigger a simple cp BR2_DTS_FILE $(kernel_dir)/arch/$(ARCH)/boot/dts/$(BR2_DTS_FILE). I think some of the patches recently sent already do this.
Step 3 can also be taken care of the same way as Step 1.
Step 4 could also be taken care by the defconfig.
Maybe this is the easiest way to implement DTS support into buildroot, but depends heavily on existing defconfigs.
So, what should be the next step?
Regards,
2012/3/14 Arnout Vandecappelle <[email protected]>
Quoted 8 lines
Since nobody seems to be stepping up to add generic DTS support, that
means microblaze is blocked. That, I think, is stupid. If we have working patches for microblaze now, why not accept them? We can always add DTS support later and refactor the microblaze-specific stuff away. In fact, this microblaze-specific stuff makes it easier to add generic DTS support, because you already get a defconfig that uses it and that you can use for testing.
Signature · 4 lines
?lvaro G?mez Machado -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20120314/e8a0cbfc/attachment.html>
PATCH 4/5 Microblaze: build kernel with device tree
Hello Alvaro, hello all!
Am 14.03.2012 17:41, schrieb Alvaro Gamez:
Quoted 10 lines
They way I'm using this now is, with the patches I sent to the list:
1.- Configure buildroot to make a .cpio filesystem 2.- Manually copy the DTS file under
output/build/linux-3.2.6/arch/microblaze/boot/dts/lx9.dts3.- Under kernel configuration, setCONFIG_BLK_DEV_INITRD=yandCONFIG_INITRAMFS_SOURCE=../../images/rootfs.cpio
4.- Under buildroot configuration, set BR2_LINUX_KERNEL_IMAGE_TARGET_NAME=simpleImage.lx9
In fact my original patch builds a complete embedded Linux system including the rootfs as initrd within the kernel image. No manual steps are needed when the settings in the defconfig-file and the dts and kernel defconfig from the boards directory are used.
Quoted 11 lines
After this, I can make and I get a full working system under output/build/linux-3.2.6/arch/micr oblaze/boot/simpleImage.lx9
My understanding of this is the following:
Current patches allow filesystem development for microblaze, including kernel. The only thing it does not provide is the ability to generate a merged filesystem+kernel, ability which isn't available for any other arch. In my opinion, current patches could be applied for next release.
I think so, too.
Quoted 1 line · Arnout
- Stephan doesn't see how to do it, and
Regarding the Devicetree and simpleimage topics I do not have the time to figure that out. At least, there are some comments on my original implementation, too. I did not address these, because it works for me and they will become obsolete when generic dts support becomes available.
Quoted 5 lines
We can
always add DTS support later and refactor the microblaze-specific stuff away. In fact, this microblaze-specific stuff makes it easier to add generic DTS support, because you already get a defconfig that uses it and that you can use for testing.
I think that would be a goor solution!
Quoted 10 lines · Alvaro
On the other hand, for addional steps are required to get to a simpleImage
Step 1 is dependant on the desired image, (maybe you want a gzip'ed or bzip2'ed filesystem). This has implications on the kernel configuration, since it needs to be able to decompress a gzip image or a cpio filesystem (
CONFIG_RD_GZIP,CONFIG_RD_BZIP2and others). This can be solved with the appropiate buildroot defconfig that is consistent with the kernel defconfig.
Quoted 4 lines
Step 2 requires a
BR2_DTS_FILEconfig option. This may trigger a simple cpBR2_DTS_FILE$(kernel_dir)/arch/$(ARCH)/boot/dts/$(BR2_DTS_FILE). I think some of the patches recently sent already do this.
Yes, my old patch does and there was another patch doing this.
What I think is also important, but can be addressed seperatelly:
- Building the toolchain from Source
- Building the boot loader
- Accessing the Flash on the Microboard from Bootloader and Linux
Quoted 2 lines
So, what should be the next step?
I can put the patches that I have (the one fixing the toolchain download got lost somewhere) together, rebase them to the current HEAD and resend them on the weekend. I already squashed the three patches concerning toolchain download into one (but that removed Alvaro's entry as Author, which I don't like) and renamed the board directory to lower case. I can also add useful help texts for the architecture selection, but maybe Alvaro wants to do this himself.
So I think we have 4 patches:
Alvaro: Microblaze: added architecture support for both big endian and low endian
Alvaro: Microblaze: added external toolchain from Xilinx
Stephan: Microblaze: build kernel with device tree
Stephan: Microblaze: added defconfig for Avnet S6LX9 Microboard
Kind regards
Stephan
Signature · 8 lines
reLinux - Stephan Hoffmann Am Schmidtgrund 124 50765 K?ln Tel. +49.221.95595-19 Fax: -64 www.reLinux.de sho at reLinux.de -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20120315/6a82c841/attachment.html>
PATCH 4/5 Microblaze: build kernel with device tree
Hi!
To recap a bit more...
I think we can be applying the set of patches that fully work and provide some independent utility without conflicting with future plans. So, I would say we could apply at least the following four patches:
* Alvaro: Microblaze: added architecture support for both big endian and low endian
* Alvaro: Microblaze: added external toolchain from Xilinx
* This also needs "DOWNLOAD: change $1=DIRECTORY_URL, $2=FILE_NAME to $1=FULL_FILE_URL, $2=FILE_NAME", signed-off also by Peter Korsgaard and Arnout Vandecappelle, also Acked-by Arnout.
In fact, I would call for this patch to be applied as soon as possible, so as to set the recently added packages to use the newer DOWNLOAD interface and avoid a future refactor of already existing packages.
* Stephan: Microblaze: added defconfig for Avnet S6LX9 Microboard
On the other hand, this patch
Stephan: Microblaze: build kernel with device tree
This patch could very well be used, but I am not sure if this should be directly applied. Maybe it's not a good idea to have an specific patch for Microblaze's device tree and maybe we should wait to have a generic one? Maybe we can talk a little about DTS support and decide how to implement that.
2012/3/15 Stephan Hoffmann <[email protected]> wrote
Quoted 7 lines
What I think is also important, but can be addressed seperatelly:
- Building the toolchain from Source
- Building the boot loader
- Accessing the Flash on the Microboard from Bootloader and Linux
This would totally be great. I've tried to build the toolchain and faced the same problem as you, Stephan. I still haven't tried anything with the bootloader nor the flash.
Quoted 7 lines
So, what should be the next step?
I can put the patches that I have (the one fixing the toolchain download got lost somewhere) together, rebase them to the current HEAD and resend them on the weekend.
I already squashed the three patches concerning toolchain download into one
Quoted 2 lines
(but that removed Alvaro's entry as Author, which I don't like)
I think the patches I refered to before should be enough to allow the toolchain download. At least, they work for me. They were both ack'ed by Arnout, so I thought they were tested and good to go. However, if we manage to build the toolchain from the source, then we won't need it? In either case, the second one (download) is useful by itself.
* Alvaro: Microblaze: added external toolchain from Xilinx
* This also needs "DOWNLOAD: change $1=DIRECTORY_URL, $2=FILE_NAME to $1=FULL_FILE_URL, $2=FILE_NAME"
Quoted 8 lines
and renamed the board directory to lower case.
I can also add useful help texts for the architecture selection, but maybe Alvaro wants to do this himself.
Kind regards
Quoted 1 line
If you want, I can take care of this, and maybe add some texts to the other architectures. Better have them late than never.
Regards,
Signature · 4 lines
?lvaro G?mez Machado -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20120315/411797e9/attachment.html>
PATCH 4/5 Microblaze: build kernel with device tree
In reply to Stephan HoffmannHi again
2012/3/15 Stephan Hoffmann <[email protected]>
Quoted 9 lines
So, what should be the next step?
I can put the patches that I have (the one fixing the toolchain download got lost somewhere) together, rebase them to the current HEAD and resend them on the weekend. I already squashed the three patches concerning toolchain download into one (but that removed Alvaro's entry as Author, which I don't like) and renamed the board directory to lower case. I can also add useful help texts for the architecture selection, but maybe Alvaro wants to do this himself.
Ok, I'm sending right now a set of three patches rebased to HEAD:
* DOWNLOAD: change $1=DIRECTORY_URL, $2=FILE_NAME to $1=FULL_FILE_URL, $2=FILE_NAME
This one is needed to be applied before the third one, since this patch allows downloading of files from awkward paths (such as the one from Xilinx' git).
This patch, specifically has really nothing to do with Microblaze support in itself. I think this can really be applied even if the other patches aren't applied. This is in itself an improvement over existing code.
* Microblaze: added architecture support for both big endian and low endian This one simply adds microblaze architecture with a little bit more descriptive names. I think they are good in the sense that someone who is developing for Microblaze will know for sure if it's using the AXI interface or not.
* Microblaze: added external toolchain from Xilinx
Simply does what it says. This needs the first patch of the set to work.
2012/3/14 Arnout Vandecappelle <[email protected]>
Quoted 5 lines
If I understand correctly, for microblaze, you *have* to use a
simpleImage, which is a uImage with a DTB subimage. In other words, unless we have some kind of DTS support in buildroot, we can't support microblaze.
Quoted 8 lines
Since nobody seems to be stepping up to add generic DTS support, that
means microblaze is blocked. That, I think, is stupid. If we have working patches for microblaze now, why not accept them? We can always add DTS support later and refactor the microblaze-specific stuff away. In fact, this microblaze-specific stuff makes it easier to add generic DTS support, because you already get a defconfig that uses it and that you can use for testing.
I mostly agree with you. As I said, I this patches are good enough and consistent with themselves. They allow to build a root filesystem able to run on Microblaze. Since there is a high variety of boot methods and boards, I think this can be applied regardless of future patches.
I do not think we should wait for a generic DTS support to accept this patches nor this one from Stephan, which I think could also be applied. *Stephan: Microblaze: added defconfig for Avnet S6LX9 Microboard
While we work on the DTS support, we have the temporal patch also from Stephan
* Stephan: Microblaze: build kernel with device tree
We can work from this patch to get the generic DTS support. Maybe we should talk a little about how we want to get it done and unlock this wanted feature.
Kind regards,
Signature · 4 lines
?lvaro G?mez Machado -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20120316/8c77c60e/attachment.html>