Skip to contentSkip to conversation

Microblaze: build kernel with device tree

PATCH New Stephan Hoffmann 4 participants 7 messages Mar 11, 2012 – Mar 16, 2012

lore
Share & tools
lore
#0 lore raw

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
index 26032fd..7d9f4fb 100644
@@ -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
index ae236d4..ade867a 100644
@@ -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
#1 lore raw

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.

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))_defconfig

linux/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
#2 lore raw

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.

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
#3 lore raw

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>
#4 lore raw

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.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

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_BZIP2 and 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_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.

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>
#5 lore raw

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>
#6 lore raw

PATCH 4/5 Microblaze: build kernel with device tree

In reply to Stephan Hoffmann

Hi 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>