[Buildroot] [PATCH 4/5] Microblaze: build kernel with device tree

[Buildroot] [PATCH 4/5] Microblaze: build kernel with device tree

[Stephan Hoffmann]

Device Tree and SimpleImage will be handled in buildroot in the
future. Until then, this patch is needed.

Signed-off-by: Stephan Hoffmann <sho@relinux.de>

---
 linux/Config.in |    8 ++++++++
 linux/linux.mk  |   16 ++++++++++++++++
 2 files changed, 24 insertions(+), 0 deletions(-)

diff --git a/linux/Config.in b/linux/Config.in
index 26032fd..7d9f4fb 100644
--- a/linux/Config.in
+++ b/linux/Config.in
@@ -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
 #
diff --git a/linux/linux.mk b/linux/linux.mk
index ae236d4..ade867a 100644
--- a/linux/linux.mk
+++ b/linux/linux.mk
@@ -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
-- 
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

[Buildroot] [PATCH 4/5] Microblaze: build kernel with device tree

[Thomas Petazzoni]

Hello,

Le Sun, 11 Mar 2012 17:50:17 +0100,
Stephan Hoffmann <sho@relinux.de> a ?crit :

> Device Tree and SimpleImage will be handled in buildroot in the
> future. Until then, this patch is needed.
> 
> Signed-off-by: Stephan Hoffmann <sho@relinux.de>

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.

> +config BR2_LINUX_KERNEL_DTS_FILE
> +    string "Device Tree dts file location"
> +    depends on BR2_microblaze

 or ARM or PowerPC

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

> +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?


> +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?

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

The if is not needed, the LINUX_COPY_DTS is already defined
conditionally.

>  	# 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
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] [PATCH 4/5] Microblaze: build kernel with device tree

[Arnout Vandecappelle]

On Monday 12 March 2012 23:10:55 Thomas Petazzoni wrote:
> > Device Tree and SimpleImage will be handled in buildroot in the
> > future. Until then, this patch is needed.
> > 
> > Signed-off-by: Stephan Hoffmann <sho@relinux.de>
> 
> 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


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

[Buildroot] [PATCH 4/5] Microblaze: build kernel with device tree

[Alvaro Gamez]

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 <arnout@mind.be>

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



-- 
?lvaro G?mez Machado
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20120314/e8a0cbfc/attachment.html>

[Buildroot] [PATCH 4/5] Microblaze: build kernel with device tree

[Stephan Hoffmann]

Hello Alvaro, hello all!


Am 14.03.2012 17:41, schrieb Alvaro Gamez:
> 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.
> 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.

Arnout wrote:
> - 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.
> 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!

Alvaro wrote:
>
> 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.
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
>
> 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

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

[Buildroot] [PATCH 4/5] Microblaze: build kernel with device tree

[Alvaro Gamez]

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 <sho@relinux.de> wrote

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


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

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"


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


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,
-- 
?lvaro G?mez Machado
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20120315/411797e9/attachment.html>

[Buildroot] [PATCH 4/5] Microblaze: build kernel with device tree

[Alvaro Gamez]

Hi again

2012/3/15 Stephan Hoffmann <sho@relinux.de>

>  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 <arnout@mind.be>

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

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,

-- 
?lvaro G?mez Machado
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20120316/8c77c60e/attachment.html>