Versatile Express DT support

arch/arm/mach-vexpress/core.h +0 -3

@@ -1,6 +1,3 @@
-#define __MMIO_P2V(x)  (((x) & 0xfffff) | (((x) & 0x0f000000) >> 4) | 0xf8000000)
-#define MMIO_P2V(x)    ((void __iomem *)__MMIO_P2V(x))
-

Quoted 4 lines · Pawel Moll

arch/arm/mach-vexpress/core.h +0 -3

@@ -1,6 +1,3 @@
-#define __MMIO_P2V(x)  (((x) & 0xfffff) | (((x) & 0x0f000000) >> 4) | 0xf8000000)
-#define MMIO_P2V(x)    ((void __iomem *)__MMIO_P2V(x))
-

...

arch/arm/mach-vexpress/core.h struct amba_device name##_device = { \ · line 24

Quoted 8 lines

arch/arm/mach-vexpress/core.h +8 -0

+
+/* 2MB large area for motherboard's peripherals static mapping */
+#define V2M_PERIPH 0xf8000000
+#define V2M_PERIPH_P2V(offset) ((void __iomem *)(V2M_PERIPH | (offset)))
+
+/* Tile's peripherals static mappings should start here */
+#define V2T_PERIPH 0xf8200000
+#define V2T_PERIPH_P2V(offset) ((void __iomem *)(V2T_PERIPH | (offset)))

I think it would be even better if you could express the same with pointer arithmetic instead of the macro, like:

#define V2M_PERIPH ((void __iomem *)0xf8000000)
#define V2T_PERIPH ((void __iomem *)0xf8200000)

and then instead of

arch/arm/mach-vexpress/ct-ca9x4.c +2 -0

+       gic_init(0, 29, V2T_PERIPH_P2V(A9_MPCORE_GIC_DIST),
+                V2T_PERIPH_P2V(A9_MPCORE_GIC_CPU));

do

(quoted diff) +2 -0

+       gic_init(0, 29, V2T_PERIPH + A9_MPCORE_GIC_DIST,
+                V2T_PERIPH + A9_MPCORE_GIC_CPU);

and so on. This ends up being more readable IMHO because it means you don't have to know what the macro does.

Quoted 2 lines

and so on. This ends up being more readable IMHO because it means you don't have to know what the macro does.

I wouldn't mind that, it's just that the V2M_PERIPH is also used in the map_desc:

static struct map_desc v2m_io_desc[] __initdata = {
{
.virtual = V2M_PERIPH,

and as the .virtual is unsigned long I'd need a cast in one place or the other.

My best hope is that once Nico's "ioremap optimization" is pulled
(http://thread.gmane.org/gmane.linux.ports.arm.kernel/140974), I'll be able to replace the _P2V macros with ioremap()s.

Quoted 10 lines · Pawel Moll

Quoted 2 lines

and so on. This ends up being more readable IMHO because it means you don't have to know what the macro does.

I wouldn't mind that, it's just that the V2M_PERIPH is also used in the map_desc:

static struct map_desc v2m_io_desc[] __initdata = {
{
.virtual = V2M_PERIPH,

Quoted 2 lines

and as the .virtual is unsigned long I'd need a cast in one place or the other.

I have patches for other platforms to do the same conversion and add the cast here, but also plan to change the way that I/O mappings are done in the long run, you have to specify the virtual address as __iomem* instead of an integer anyway.

arch/arm/boot/dts/vexpress-v2m.dtsi line 186

Quoted 6 lines · Pawel Moll

arch/arm/boot/dts/vexpress-v2m.dtsi new file +6 -0

+                       compact-flash at 1a000 {
+                               compatible = "ata-generic";
+                               reg = <0x1a000 0x100
+                                      0x1a100 0xf00>;
+                               reg-shift = <2>;
+                       };

Shouldn't there also be a more specific "compatible" value, in case we have to detect this CF slot for some reason?

Is there actually no interrupt?

Quoted 8 lines · Arnd Bergmann

Quoted 6 lines · Pawel Moll

arch/arm/boot/dts/vexpress-v2m.dtsi new file +6 -0

+                       compact-flash at 1a000 {
+                               compatible = "ata-generic";
+                               reg = <0x1a000 0x100
+                                      0x1a100 0xf00>;
+                               reg-shift = <2>;
+                       };

Quoted 2 lines

Shouldn't there also be a more specific "compatible" value, in case we have to detect this CF slot for some reason?

It was the compatible-value-of-choice in "drivers/ata/pata_of_platform.c", unfortunately undocumented - as I have just realized - in the "Documentation/devicetree/bindings"...

Quoted 1 line

Is there actually no interrupt?

No, polling mode only. And yes, it works ;-)

Quoted 10 lines · Pawel Moll

Quoted 8 lines · Arnd Bergmann

Quoted 6 lines · Pawel Moll

arch/arm/boot/dts/vexpress-v2m.dtsi new file +6 -0

+                       compact-flash at 1a000 {
+                               compatible = "ata-generic";
+                               reg = <0x1a000 0x100
+                                      0x1a100 0xf00>;
+                               reg-shift = <2>;
+                       };

Quoted 6 lines

Quoted 2 lines

Shouldn't there also be a more specific "compatible" value, in case we have to detect this CF slot for some reason?

It was the compatible-value-of-choice in "drivers/ata/pata_of_platform.c", unfortunately undocumented - as I have just realized - in the "Documentation/devicetree/bindings"...

You should certainly *also* have "ata-generic" in there as the value that is used by the existing driver, but it usually makes sense to have a more specific value in addition, just as a precaution for the future, in case that the specific hardware is not entirely identical to all others and we have to do a separate workaround.

Ok, as the actual "interface hardware" is a custom design for VE, I'll make it:

        compatible = "arm,vexpress-cf", "ata-generic";

Does it make sense?

This patch provides hooks for DT-based tile machine implementations and adds Device Tree description for the motherboard.

Now that a person may fail to boot on a supported board simply due to failing to supply a device tree, it may be a good idea to have a more helpful panic message for that situation, perhaps something like the following.

If you don't think this fits in this series, I can always follow up later.

arch/arm/mach-vexpress/v2m.c +0 -0

index 6965f64..9dda482 100644
@@ -434,8 +434,11 @@ static void __init v2m_populate_ct_desc(void)
 			ct_desc = ct_descs[i];
 
 	if (!ct_desc)

Quoted 25 lines · Dave Martin

Now that a person may fail to boot on a supported board simply due to failing to supply a device tree, it may be a good idea to have a more helpful panic message for that situation, perhaps something like the following.

If you don't think this fits in this series, I can always follow up later.

arch/arm/mach-vexpress/v2m.c +5 -2

index 6965f64..9dda482 100644
@@ -434,8 +434,11 @@ static void __init v2m_populate_ct_desc(void)
 			ct_desc = ct_descs[i];
 
 	if (!ct_desc)
-		panic("vexpress: failed to populate core tile description "
-		      "for tile ID 0x%8x\n", current_tile_id);
+		panic("vexpress: this kernel does not support core tile ID "
+		      "0x%08x when booting via ATAGs.\n"
+		      "You may need a device tree blob or a different kernel "
+		      "to boot on this board.\n",
+		      current_tile_id);
 }
 

arch/arm/mach-vexpress/v2m.c static void __init v2m_populate_ct_desc(void) · line 444

Quoted 2 lines

arch/arm/mach-vexpress/v2m.c +0 -0

 static void __init v2m_map_io(void)

No, that's cool with me, will add that. Thanks!

arch/arm/mach-vexpress/v2m.c

Quoted 3 lines

arch/arm/mach-vexpress/v2m.c +3 -0

+		panic("vexpress: this kernel does not support core tile ID 0x%08x when booting via ATAGs.\n" 
+		      "You may need a device tree blob or a different kernel to boot on this board.\n",
+		      current_tile_id);

This patch provides hooks for DT-based tile machine implementations and adds Device Tree description for the motherboard.

Quoted 2 lines · Pawel Moll

This patch provides hooks for DT-based tile machine implementations and adds Device Tree description for the motherboard.

[...]

arch/arm/mach-vexpress/v2m.c MACHINE_START(VEXPRESS, "ARM-Versatile Express") · line 593

Quoted 5 lines

arch/arm/mach-vexpress/v2m.c +5 -0

+static struct of_dev_auxdata v2m_dt_auxdata_lookup[] __initdata = {
+	OF_DEV_AUXDATA("arm,vexpress-flash", V2M_NOR0, "physmap-flash",
+			&v2m_flash_data),
+	OF_DEV_AUXDATA("arm,primecell", V2M_MMCI, "mb:mmci", &v2m_mmci_data),
+	{}

Are we missing some AUXDATA here? I thought we had a lot more drivers which are not converted to OF, such as ambakmi and many more.

I notice some things explicitly failing, e.g.:

clcd-pl11x: probe of 10020000.clcd failed with error -22
clcd-pl11x: probe of 1001f000.clcd failed with error -22

...I haven't tracked down exactly what is going on here, yet.

This patch adds support for RS1 memory map based Versatile Express motherboard.

arch/arm/mach-vexpress/Kconfig +8 -0

+config ARCH_VEXPRESS_RS1
+	bool
+	select AUTO_ZRELADDR
+	select ARM_PATCH_PHYS_VIRT
+	help
+	  RS1 VE memory map (i.a. motherboard peripherals at
+	  0x1c000000, RAM at 0x80000000).
+
 endmenu

arch/arm/mach-vexpress/Makefile.boot +0 -0

index 8630b3d..05b77a5 100644

This results in a uImage which is a bit broken if using a normal u-Boot configured for vexpress-v2p-ca9, because the bootloader makes some memory map assumptions, and anyway we don't expect the kernel to work unless it's loaded at the start of RAM:

## Booting kernel from Legacy Image at 62000400 ...

   Image Name:   Linux-3.2.0-rc3+
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    2464984 Bytes = 2.4 MiB

Load Address: 80008000
Entry Point: 80008000
Verifying Checksum ... OK
## Loading init Ramdisk from Legacy Image at 80ffffc0 ...
Image Name:

   Image Type:   ARM Linux RAMDisk Image (uncompressed)
   Data Size:    2216523 Bytes = 2.1 MiB
   Load Address: 81000000
   Entry Point:  81000000
   Verifying Checksum ... OK

## Flattened Device Tree blob at 80ffc000
Booting using the fdt blob at 0x80ffc000 Loading Kernel Image ... OK
OK
Loading Ramdisk to 7fcd3000, end 7fef024b ... OK Loading Device Tree to 7fcce000, end 7fcd2779 ... OK

Starting kernel ...

Uncompressing Linux... done, booting the kernel.
Booting Linux on physical CPU 0
Initializing cgroup subsys cpuset
Linux version 3.2.0-rc3+ (davem at e103592) (gcc version 4.5.2 (Ubuntu/Linaro 4.5.2-8ubuntu3) ) #12 SMP Wed Nov 30 15:10:19 GMT 2011
CPU: ARMv7 Processor [410fc091] revision 1 (ARMv7), cr=10c53c7d
CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
Machine: ARM Versatile Express, model: V2P-CA9
bootconsole [earlycon0] enabled
Ignoring RAM at 60000000-7fffffff (vmalloc region overlap).
Ignoring RAM at 60000000-9fffffff (vmalloc region overlap).
INITRD: 0x7fcd3000+0x0021d24b is not a memory region - disabling initrd
Memory policy: ECC disabled, Data cache writeall
Cheers
---Dave

oc

<HANG>

If I strip the uImage and rebuild it with -a 0x60008000 -e 0x60008000 and no other changes, that's sufficient to give me a fully booting kernel. I can also boot a single image on v2p-ca9 both with and without a dtb in this configuration.

I'm using a Linaro u-Boot from a couple of releses ago; it's possible things have changed since.

Do you know of any specific u-Boot version which shouldn't have these problems?

Was the hard-coded uImage load address/entry point problem ever fixed? (It totally defeats loading a single uImage on multiple board variants.)

Quoted 46 lines · Dave Martin

This results in a uImage which is a bit broken if using a normal u-Boot configured for vexpress-v2p-ca9, because the bootloader makes some memory map assumptions, and anyway we don't expect the kernel to work unless it's loaded at the start of RAM:

## Booting kernel from Legacy Image at 62000400 ...

   Image Name:   Linux-3.2.0-rc3+
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    2464984 Bytes = 2.4 MiB

Load Address: 80008000
Entry Point: 80008000
Verifying Checksum ... OK
## Loading init Ramdisk from Legacy Image at 80ffffc0 ...
Image Name:

   Image Type:   ARM Linux RAMDisk Image (uncompressed)
   Data Size:    2216523 Bytes = 2.1 MiB
   Load Address: 81000000
   Entry Point:  81000000
   Verifying Checksum ... OK

## Flattened Device Tree blob at 80ffc000
Booting using the fdt blob at 0x80ffc000 Loading Kernel Image ... OK
OK
Loading Ramdisk to 7fcd3000, end 7fef024b ... OK Loading Device Tree to 7fcce000, end 7fcd2779 ... OK

Starting kernel ...

Uncompressing Linux... done, booting the kernel.
Booting Linux on physical CPU 0
Initializing cgroup subsys cpuset
Linux version 3.2.0-rc3+ (davem at e103592) (gcc version 4.5.2 (Ubuntu/Linaro 4.5.2-8ubuntu3) ) #12 SMP Wed Nov 30 15:10:19 GMT 2011
CPU: ARMv7 Processor [410fc091] revision 1 (ARMv7), cr=10c53c7d
CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
Machine: ARM Versatile Express, model: V2P-CA9
bootconsole [earlycon0] enabled
Ignoring RAM at 60000000-7fffffff (vmalloc region overlap).
Ignoring RAM at 60000000-9fffffff (vmalloc region overlap).
INITRD: 0x7fcd3000+0x0021d24b is not a memory region - disabling initrd
Memory policy: ECC disabled, Data cache writeall
Cheers
---Dave

Quoted 3 lines

oc

<HANG>

Yes, this is known problem with U-boot. Could you try again with "mem=512M" parameter?

Quoted 11 lines

If I strip the uImage and rebuild it with -a 0x60008000 -e 0x60008000 and no other changes, that's sufficient to give me a fully booting kernel. I can also boot a single image on v2p-ca9 both with and without a dtb in this configuration.

I'm using a Linaro u-Boot from a couple of releses ago; it's possible things have changed since.

Do you know of any specific u-Boot version which shouldn't have these problems?

Quoted 2 lines

Was the hard-coded uImage load address/entry point problem ever fixed? (It totally defeats loading a single uImage on multiple board variants.)

I simply don't use U-boot at all, what solves the problem "systematically" ;-) I wonder if it was possible to override the load/entry address in the runtime?

It would be nice to know what's going on here, but I'm reasonably convinced that we're just booting the kernel in a silly way here, and U-Boot really needs to be fixed to avoid the fixed-load-address limitation.

Quoted 9 lines · Pawel Moll

Quoted 5 lines · Dave Martin

This results in a uImage which is a bit broken if using a normal u-Boot configured for vexpress-v2p-ca9, because the bootloader makes some memory map assumptions, and anyway we don't expect the kernel to work unless it's loaded at the start of RAM:

Yes, this is known problem with U-boot. Could you try again with "mem=512M" parameter?

U-Boot's built-in assumption about using addresses around 0x7f000000 to relocate the dtb and initrd are clearly a problem here, though if that was the only problem, the kernel would have booted further than this...

It would be nice to know what's going on here, but I'm reasonably convinced that we're just booting the kernel in a silly way here, and U-Boot really needs to be fixed to avoid the fixed-load-address limitation.

Quoted 6 lines

Quoted 2 lines

Was the hard-coded uImage load address/entry point problem ever fixed? (It totally defeats loading a single uImage on multiple board variants.)

I simply don't use U-boot at all, what solves the problem "systematically" ;-) I wonder if it was possible to override the load/entry address in the runtime?

I believe not, but there have been some discussions about loading to a default "start of RAM" location if the uImage's load address/entry point are zero, or having some header flag to indicate this.

I don't know about the implementation status of this, though.

annoying. If nothing moves I might just go ahead with those changes and simply rip the uImage make target out of the kernel as well. Maybe the inconvenience will be a sufficient incentive for people to lobby proper u-Boot support. And it is not like if the u-Boot patches didn't exist

Quoted 5 lines

annoying. If nothing moves I might just go ahead with those changes and simply rip the uImage make target out of the kernel as well. Maybe the inconvenience will be a sufficient incentive for people to lobby proper u-Boot support. And it is not like if the u-Boot patches didn't exist

Oh, dear. Any pointers to the discussions on the u-boot side?

Quoted 4 lines · Nicolas Pitre

annoying. If nothing moves I might just go ahead with those changes and simply rip the uImage make target out of the kernel as well. Maybe the inconvenience will be a sufficient incentive for people to lobby proper u-Boot support. And it is not like if the u-Boot patches didn't exist

Oh, dear. Any pointers to the discussions on the u-boot side?

Quoted 8 lines · Mark Brown

Quoted 4 lines · Nicolas Pitre

annoying. If nothing moves I might just go ahead with those changes and simply rip the uImage make target out of the kernel as well. Maybe the inconvenience will be a sufficient incentive for people to lobby proper u-Boot support. And it is not like if the u-Boot patches didn't exist

Oh, dear. Any pointers to the discussions on the u-boot side?

Certainly. Many different threads actually. Here's a few:

http://news.gmane.org/group/gmane.comp.boot-loaders.u-boot/thread=114981

http://news.gmane.org/group/gmane.comp.boot-loaders.u-boot/thread=115774

And this is not the first time this issue has come up:

http://news.gmane.org/group/gmane.comp.boot-loaders.u-boot/thread=83824

http://news.gmane.org/group/gmane.linux.ports.arm.kernel/thread=81546/force_load=t/focus=84138

Yet more u-Boot woes:

http://news.gmane.org/group/gmane.linux.ports.arm.kernel/thread=53973

I'm sure there are others, but that's what I've quickly dug out.

Quoted 23 lines · Nicolas Pitre

Quoted 8 lines · Mark Brown

Quoted 4 lines · Nicolas Pitre

annoying. If nothing moves I might just go ahead with those changes and simply rip the uImage make target out of the kernel as well. Maybe the inconvenience will be a sufficient incentive for people to lobby proper u-Boot support. And it is not like if the u-Boot patches didn't exist

Oh, dear. Any pointers to the discussions on the u-boot side?

Certainly. Many different threads actually. Here's a few:

http://news.gmane.org/group/gmane.comp.boot-loaders.u-boot/thread=114981

http://news.gmane.org/group/gmane.comp.boot-loaders.u-boot/thread=115774

And this is not the first time this issue has come up:

http://news.gmane.org/group/gmane.comp.boot-loaders.u-boot/thread=83824

http://news.gmane.org/group/gmane.linux.ports.arm.kernel/thread=81546/force_load=t/focus=84138

Quoted 5 lines

Yet more u-Boot woes:

http://news.gmane.org/group/gmane.linux.ports.arm.kernel/thread=53973

I'm sure there are others, but that's what I've quickly dug out.

So why are we still supporting uboot in the mainline kernel on ARM?

Quoted 1 line · Mark Brown

Oh, dear. Any pointers to the discussions on the u-boot side?

Certainly. Many different threads actually. Here's a few:

Quoted 5 lines · Nicolas Pitre

Quoted 1 line · Mark Brown

Oh, dear. Any pointers to the discussions on the u-boot side?

Certainly. Many different threads actually. Here's a few:

OK, thanks - I see Stephen just followed up and Wolfgang seems moderately happy so hopefully there will be some progress. It also occurs to me that there's at least Qi also using uImages, hopefully other bootloaders are going to be easier to deal with (or already cope).

Quoted 11 lines · Nicolas Pitre

Quoted 5 lines · Mark Brown

Quoted 2 lines

Oh, dear. Any pointers to the discussions on the u-boot side?

Certainly. Many different threads actually. Here's a few:

OK, thanks - I see Stephen just followed up and Wolfgang seems moderately happy so hopefully there will be some progress. It also occurs to me that there's at least Qi also using uImages, hopefully other bootloaders are going to be easier to deal with (or already cope).

If Stephen's patches are heading for merge, that's great.

If this feature remains blocked though, could we support Wolfgang's preference for start-of-RAM-relative load and entry address?

Dave Martin wrote at Thursday, December 01, 2011 5:14 AM:

Quoted 13 lines · Mark Brown

Quoted 11 lines · Nicolas Pitre

Quoted 5 lines · Mark Brown

Quoted 2 lines

Oh, dear. Any pointers to the discussions on the u-boot side?

Certainly. Many different threads actually. Here's a few:

OK, thanks - I see Stephen just followed up and Wolfgang seems moderately happy so hopefully there will be some progress. It also occurs to me that there's at least Qi also using uImages, hopefully other bootloaders are going to be easier to deal with (or already cope).

Quoted 4 lines

If Stephen's patches are heading for merge, that's great.

If this feature remains blocked though, could we support Wolfgang's preference for start-of-RAM-relative load and entry address?

It looks like my change is progressing to being checked in:

http://lists.denx.de/pipermail/u-boot/2011-December/111865.html

Stephen Warren wrote at Thursday, December 01, 2011 9:20 AM:

Quoted 13 lines

Dave Martin wrote at Thursday, December 01, 2011 5:14 AM:

Quoted 12 lines · Mark Brown

Quoted 10 lines · Nicolas Pitre

Quoted 4 lines · Mark Brown

Quoted 1 line

Oh, dear. Any pointers to the discussions on the u-boot side?

Certainly. Many different threads actually. Here's a few:

OK, thanks - I see Stephen just followed up and Wolfgang seems moderately happy so hopefully there will be some progress. It also occurs to me that there's at least Qi also using uImages, hopefully other bootloaders are going to be easier to deal with (or already cope).

Quoted 8 lines

Quoted 4 lines

If Stephen's patches are heading for merge, that's great.

If this feature remains blocked though, could we support Wolfgang's preference for start-of-RAM-relative load and entry address?

It looks like my change is progressing to being checked in:

http://lists.denx.de/pipermail/u-boot/2011-December/111865.html

For the record, the changes are now in U-Boot master:

d510859 image: Don't detect XIP images as overlapping. b9b50e8 image: Implement IH_TYPE_KERNEL_NOLOAD

I should also note that Marek Vasut posted some patches to implement a bootz command in U-Boot. This turned out to be much less invasive than I originally thought, so once those patches are finalized, uImage might be irrelevant except for initrds (U-Boot already accepts a raw FDT without uImage wrapping for bootm and hence bootz).

http://www.mail-archive.com/u-boot at lists.denx.de/msg69287.html

Stephen Warren wrote at Thursday, December 01, 2011 9:20 AM:

Quoted 14 lines

Dave Martin wrote at Thursday, December 01, 2011 5:14 AM:

Quoted 13 lines · Mark Brown

Quoted 11 lines · Nicolas Pitre

Quoted 5 lines · Mark Brown

Quoted 2 lines

Oh, dear. Any pointers to the discussions on the u-boot side?

Certainly. Many different threads actually. Here's a few:

OK, thanks - I see Stephen just followed up and Wolfgang seems moderately happy so hopefully there will be some progress. It also occurs to me that there's at least Qi also using uImages, hopefully other bootloaders are going to be easier to deal with (or already cope).

Quoted 8 lines

Quoted 4 lines

If Stephen's patches are heading for merge, that's great.

If this feature remains blocked though, could we support Wolfgang's preference for start-of-RAM-relative load and entry address?

It looks like my change is progressing to being checked in:

http://lists.denx.de/pipermail/u-boot/2011-December/111865.html

For the record, the changes are now in U-Boot master:

d510859 image: Don't detect XIP images as overlapping. b9b50e8 image: Implement IH_TYPE_KERNEL_NOLOAD

I should also note that Marek Vasut posted some patches to implement a bootz command in U-Boot. This turned out to be much less invasive than I originally thought, so once those patches are finalized, uImage might be irrelevant except for initrds (U-Boot already accepts a raw FDT without uImage wrapping for bootm and hence bootz).

http://www.mail-archive.com/u-boot at lists.denx.de/msg69287.html

For the record, the changes are now in U-Boot master:

d510859 image: Don't detect XIP images as overlapping. b9b50e8 image: Implement IH_TYPE_KERNEL_NOLOAD

I should also note that Marek Vasut posted some patches to implement a bootz command in U-Boot. This turned out to be much less invasive than I originally thought, so once those patches are finalized, uImage might be irrelevant except for initrds (U-Boot already accepts a raw FDT without uImage wrapping for bootm and hence bootz).

http://www.mail-archive.com/u-boot at lists.denx.de/msg69287.html

Quoted 4 lines

For the record, the changes are now in U-Boot master:

d510859 image: Don't detect XIP images as overlapping. b9b50e8 image: Implement IH_TYPE_KERNEL_NOLOAD

Yay! Thank you Stephen for driving this to a successful resolution.

Of course, boards won't be updated to the latest u-boot right away

, nor
will the enhanced mkimage tool be commonly available.

Quoted 8 lines

I should also note that Marek Vasut posted some patches to implement a bootz command in U-Boot. This turned out to be much less invasive than I originally thought, so once those patches are finalized, uImage might be irrelevant except for initrds (U-Boot already accepts a raw FDT without uImage wrapping for bootm and hence bootz).

http://www.mail-archive.com/u-boot at lists.denx.de/msg69287.html

Excellent!

Nicolas

Quoted 5 lines · Nicolas Pitre

Quoted 1 line · Mark Brown

Oh, dear. Any pointers to the discussions on the u-boot side?

Certainly. Many different threads actually. Here's a few:

OK, thanks - I see Stephen just followed up and Wolfgang seems moderately happy so hopefully there will be some progress. It also occurs to me that there's at least Qi also using uImages, hopefully other bootloaders are going to be easier to deal with (or already cope).

This patch adds Device Trees for ARM Ltd. CoreTile Express A5x2 and CoreTile Express A9x4 used with V2M motherboard and an initial implementation of the DT machine support (this code is separate from the current core tile code).

Signed-off-by Pawel Moll <[email protected]>

---
 arch/arm/boot/dts/vexpress-v2p-ca5s.dts |  131 ++++++++++++++++++++++++++++
 arch/arm/boot/dts/vexpress-v2p-ca9.dts  |  145 +++++++++++++++++++++++++++++++
 arch/arm/mach-vexpress/Kconfig          |   23 +++++
 arch/arm/mach-vexpress/Makefile         |    1 +
 arch/arm/mach-vexpress/v2p-ca5s_ca9.c   |  115 ++++++++++++++++++++++++
 5 files changed, 415 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm/boot/dts/vexpress-v2p-ca5s.dts
 create mode 100644 arch/arm/boot/dts/vexpress-v2p-ca9.dts
 create mode 100644 arch/arm/mach-vexpress/v2p-ca5s_ca9.c

arch/arm/boot/dts/vexpress-v2p-ca5s.dts new file +131 -0

new file mode 100644
index 0000000..e63c251
@@ -0,0 +1,131 @@
+/*
+ * ARM Ltd. Versatile Express
+ *
+ * CoreTile Express A5x2
+ * Cortex-A5 MPCore (V2P-CA5s)
+ *
+ * HBI-0225B
+ */
+
+/dts-v1/;
+
+/include/ "skeleton.dtsi"
+
+/ {
+	model = "V2P-CA5s";
+	arm,hbi = <0x225>;
+	compatible = "arm,vexpress-v2p-ca5s";
+	interrupt-parent = <&gic>;
+
+	aliases {
+		serial0 = &v2m_serial0;
+		serial1 = &v2m_serial1;
+		serial2 = &v2m_serial2;
+		serial3 = &v2m_serial3;
+		i2c0 = &v2m_i2c_dvi;
+		i2c1 = &v2m_i2c_pcie;
+	};
+
+	memory at 80000000 {
+		device_type = "memory";
+		reg = <0x80000000 0x40000000>;
+	};
+
+	hdlcd at 2a110000 {
+		compatible = "arm,hdlcd";
+		reg = <0x2a110000 0x1000>;
+		interrupts = <0 85 4>;
+	};
+
+	memory-controller at 2a150000 {
+		compatible = "arm,pl341", "arm,primecell";
+		reg = <0x2a150000 0x1000>;
+	};
+
+	memory-controller at 2a190000 {
+		compatible = "arm,pl354", "arm,primecell";
+		reg = <0x2a190000 0x1000>;
+		interrupts = <0 86 4>,
+			     <0 87 4>;
+	};
+
+	gic: interrupt-controller at 2c001000 {
+		compatible = "arm,cortex-a9-gic";
+		#interrupt-cells = <3>;
+		#address-cells = <0>;
+		interrupt-controller;
+		reg = <0x2c001000 0x1000>,
+		      <0x2c000100 0x100>;
+	};
+
+	L2: cache-controller at 2c0f0000 {
+		compatible = "arm,pl310-cache";
+		reg = <0x2c0f0000 0x1000>;
+		interrupts = <0 84 4>;
+		cache-level = <2>;
+		arm,data-latency = <0>;
+		arm,tag-latency = <0>;
+	};
+
+	pmu {
+		compatible = "arm,cortex-a9-pmu";
+		interrupts = <0 68 4>,
+			     <0 69 4>;
+	};
+
+	motherboard {
+		ranges = <0 0 0x08000000 0x04000000>,
+			 <1 0 0x14000000 0x04000000>,
+			 <2 0 0x18000000 0x04000000>,
+			 <3 0 0x1c000000 0x04000000>,
+			 <4 0 0x0c000000 0x04000000>,
+			 <5 0 0x10000000 0x04000000>;
+
+		interrupt-map-mask = <0 0 63>;
+		interrupt-map = <0 0  0 &gic 0  0 4>,
+				<0 0  1 &gic 0  1 4>,
+				<0 0  2 &gic 0  2 4>,
+				<0 0  3 &gic 0  3 4>,
+				<0 0  4 &gic 0  4 4>,
+				<0 0  5 &gic 0  5 4>,
+				<0 0  6 &gic 0  6 4>,
+				<0 0  7 &gic 0  7 4>,
+				<0 0  8 &gic 0  8 4>,
+				<0 0  9 &gic 0  9 4>,
+				<0 0 10 &gic 0 10 4>,
+				<0 0 11 &gic 0 11 4>,
+				<0 0 12 &gic 0 12 4>,
+				<0 0 13 &gic 0 13 4>,
+				<0 0 14 &gic 0 14 4>,
+				<0 0 15 &gic 0 15 4>,
+				<0 0 16 &gic 0 16 4>,
+				<0 0 17 &gic 0 17 4>,
+				<0 0 18 &gic 0 18 4>,
+				<0 0 19 &gic 0 19 4>,
+				<0 0 20 &gic 0 20 4>,
+				<0 0 21 &gic 0 21 4>,
+				<0 0 22 &gic 0 22 4>,
+				<0 0 23 &gic 0 23 4>,
+				<0 0 24 &gic 0 24 4>,
+				<0 0 25 &gic 0 25 4>,
+				<0 0 26 &gic 0 26 4>,
+				<0 0 27 &gic 0 27 4>,
+				<0 0 28 &gic 0 28 4>,
+				<0 0 29 &gic 0 29 4>,
+				<0 0 30 &gic 0 30 4>,
+				<0 0 31 &gic 0 31 4>,
+				<0 0 32 &gic 0 32 4>,
+				<0 0 33 &gic 0 33 4>,
+				<0 0 34 &gic 0 34 4>,
+				<0 0 35 &gic 0 35 4>,
+				<0 0 36 &gic 0 36 4>,
+				<0 0 37 &gic 0 37 4>,
+				<0 0 38 &gic 0 38 4>,
+				<0 0 39 &gic 0 39 4>,
+				<0 0 40 &gic 0 40 4>,
+				<0 0 41 &gic 0 41 4>,
+				<0 0 42 &gic 0 42 4>;
+	};
+};
+
+/include/ "vexpress-v2m-rs1.dtsi"

arch/arm/boot/dts/vexpress-v2p-ca9.dts new file +145 -0

new file mode 100644
index 0000000..c51fe09
@@ -0,0 +1,145 @@
+/*
+ * ARM Ltd. Versatile Express
+ *
+ * CoreTile Express A9x4
+ * Cortex-A9 MPCore (V2P-CA9)
+ *
+ * HBI-0191B
+ */
+
+/dts-v1/;
+
+/include/ "skeleton.dtsi"
+
+/ {
+	model = "V2P-CA9";
+	arm,hbi = <0x191>;
+	compatible = "arm,vexpress-v2p-ca9";
+	interrupt-parent = <&gic>;
+
+	aliases {
+		serial0 = &v2m_serial0;
+		serial1 = &v2m_serial1;
+		serial2 = &v2m_serial2;
+		serial3 = &v2m_serial3;
+		i2c0 = &v2m_i2c_dvi;
+		i2c1 = &v2m_i2c_pcie;
+	};
+
+	memory at 60000000 {
+		device_type = "memory";
+		reg = <0x60000000 0x40000000>;
+	};
+
+	clcd at 10020000 {
+		compatible = "arm,pl111", "arm,primecell";
+		reg = <0x10020000 0x1000>;
+		interrupts = <0 44 4>;
+	};
+
+	memory-controller at 100e0000 {
+		compatible = "arm,pl341", "arm,primecell";
+		reg = <0x100e0000 0x1000>;
+	};
+
+	memory-controller at 100e1000 {
+		compatible = "arm,pl354", "arm,primecell";
+		reg = <0x100e1000 0x1000>;
+		interrupts = <0 45 4>,
+			     <0 46 4>;
+	};
+
+	timer at 100e4000 {
+		compatible = "arm,sp804", "arm,primecell";
+		reg = <0x100e4000 0x1000>;
+		interrupts = <0 48 4>,
+			     <0 49 4>;
+	};
+
+	watchdog at 100e5000 {
+		compatible = "arm,sp805", "arm,primecell";
+		reg = <0x100e5000 0x1000>;
+		interrupts = <0 51 4>;
+	};
+
+	gic: interrupt-controller at 1e001000 {
+		compatible = "arm,cortex-a9-gic";
+		#interrupt-cells = <3>;
+		#address-cells = <0>;
+		interrupt-controller;
+		reg = <0x1e001000 0x1000>,
+		      <0x1e000100 0x100>;
+	};
+
+	L2: cache-controller at 1e00a000 {
+		compatible = "arm,pl310-cache";
+		reg = <0x1e00a000 0x1000>;
+		interrupts = <0 43 4>;
+		cache-level = <2>;
+		arm,data-latency = <0>;
+		arm,tag-latency = <0>;
+	};
+
+	pmu {
+		compatible = "arm,cortex-a9-pmu";
+		interrupts = <0 60 4>,
+			     <0 61 4>,
+			     <0 62 4>,
+			     <0 63 4>;
+	};
+
+	motherboard {
+		ranges = <0 0 0x40000000 0x04000000>,
+			 <1 0 0x44000000 0x04000000>,
+			 <2 0 0x48000000 0x04000000>,
+			 <3 0 0x4c000000 0x04000000>,
+			 <7 0 0x10000000 0x00020000>;
+
+		interrupt-map-mask = <0 0 63>;
+		interrupt-map = <0 0  0 &gic 0  0 4>,
+				<0 0  1 &gic 0  1 4>,
+				<0 0  2 &gic 0  2 4>,
+				<0 0  3 &gic 0  3 4>,
+				<0 0  4 &gic 0  4 4>,
+				<0 0  5 &gic 0  5 4>,
+				<0 0  6 &gic 0  6 4>,
+				<0 0  7 &gic 0  7 4>,
+				<0 0  8 &gic 0  8 4>,
+				<0 0  9 &gic 0  9 4>,
+				<0 0 10 &gic 0 10 4>,
+				<0 0 11 &gic 0 11 4>,
+				<0 0 12 &gic 0 12 4>,
+				<0 0 13 &gic 0 13 4>,
+				<0 0 14 &gic 0 14 4>,
+				<0 0 15 &gic 0 15 4>,
+				<0 0 16 &gic 0 16 4>,
+				<0 0 17 &gic 0 17 4>,
+				<0 0 18 &gic 0 18 4>,
+				<0 0 19 &gic 0 19 4>,
+				<0 0 20 &gic 0 20 4>,
+				<0 0 21 &gic 0 21 4>,
+				<0 0 22 &gic 0 22 4>,
+				<0 0 23 &gic 0 23 4>,
+				<0 0 24 &gic 0 24 4>,
+				<0 0 25 &gic 0 25 4>,
+				<0 0 26 &gic 0 26 4>,
+				<0 0 27 &gic 0 27 4>,
+				<0 0 28 &gic 0 28 4>,
+				<0 0 29 &gic 0 29 4>,
+				<0 0 30 &gic 0 30 4>,
+				<0 0 31 &gic 0 31 4>,
+				<0 0 32 &gic 0 32 4>,
+				<0 0 33 &gic 0 33 4>,
+				<0 0 34 &gic 0 34 4>,
+				<0 0 35 &gic 0 35 4>,
+				<0 0 36 &gic 0 36 4>,
+				<0 0 37 &gic 0 37 4>,
+				<0 0 38 &gic 0 38 4>,
+				<0 0 39 &gic 0 39 4>,
+				<0 0 40 &gic 0 40 4>,
+				<0 0 41 &gic 0 41 4>,
+				<0 0 42 &gic 0 42 4>;
+	};
+};
+
+/include/ "vexpress-v2m.dtsi"

arch/arm/mach-vexpress/Kconfig +0 -0

index 2180888..9eb8161 100644
@@ -23,4 +23,27 @@ config ARCH_VEXPRESS_RS1
 	  RS1 VE memory map (i.a. motherboard peripherals at
 	  0x1c000000, RAM at 0x80000000).

Note that select PL310_ERRATA_753970 if CACHE_PL310 also needs to be propagated to ARCH_VEXPRESS_CA9X4. Maybe we should have a common symbol which selects/depends on the common stuff instead of duplicating it for every coretile -- they will tend to get out of sync.

Quoted 4 lines · Dave Martin

Note that select PL310_ERRATA_753970 if CACHE_PL310 also needs to be propagated to ARCH_VEXPRESS_CA9X4. Maybe we should have a common symbol which selects/depends on the common stuff instead of duplicating it for every coretile -- they will tend to get out of sync.

How about that?

8<-------------------------------------------------------------- menu "Versatile Express platform type"
depends on ARCH_VEXPRESS

config ARCH_VEXPRESS_CORTEX_A5_A9

	bool
	select ARM_ERRATA_720789
	select ARM_ERRATA_751472
	select ARM_GIC
	select CPU_V7
	select HAVE_L2X0_L2CC
	select PL310_ERRATA_753970 if CACHE_PL310
	help
	  VE platforms based on Cortex-A5 or Cortex-A9 processors.

That will work, but we should make it clear that this option does not provide board support all by itself, maybe:

"Provides common dependencies for VE platforms based on Cortex-A5 or Cortex-A9 processors. In order to build a working kernel, you must also enable one or more core tile support options."

Quoted 6 lines · Dave Martin

That will work, but we should make it clear that this option does not provide board support all by itself, maybe:

"Provides common dependencies for VE platforms based on Cortex-A5 or Cortex-A9 processors. In order to build a working kernel, you must also enable one or more core tile support options."

Actually, the longer I think about it the more it seems that this code doesn't support a particular tile, but rather a particular processor... After all _exactly_ the same code will work with any SMM based on FPGA Logic Tile (V2F-2XV6), even if it was very different from the coretile, eg. A9 with RS1 memory map. In such case making it compatible with V2P-CA9 would be logically wrong...

I have an idea of spinning the compatible values again to get something like that:

compatible = "arm,vexpress-v2p-ca5s", "arm,vexpress-cortex_a5"; compatible = "arm,vexpress-v2p-ca9", "arm,vexpress-cortex_a9"; compatible = "arm,vexpress-v2p-ca15", "arm,vexpress-cortex_a15";

Quoted 6 lines

I have an idea of spinning the compatible values again to get something like that:

compatible = "arm,vexpress-v2p-ca5s", "arm,vexpress-cortex_a5"; compatible = "arm,vexpress-v2p-ca9", "arm,vexpress-cortex_a9"; compatible = "arm,vexpress-v2p-ca15", "arm,vexpress-cortex_a15";

The trouble is, node { compatible = x } means "node is an x", not "node has an x".

So, we should be careful do document what e.g. arm,vexpress-cortex_a5 actually means. It doesn't mean Cortex-A5, but instead it represents a whole jumble of characteristics which we expect to be common to all vexpress-based A5 platforms.

It feels that in practice arm,vexpress-cortex_a5 actually means exactly the same thing as arm,vexpress-v2p-ca5s. Are you sure these two are really independent? (In other words, do we expect multiple different vexpress variants based on A5, and so on?)

Quoted 9 lines · Dave Martin

Quoted 6 lines

I have an idea of spinning the compatible values again to get something like that:

compatible = "arm,vexpress-v2p-ca5s", "arm,vexpress-cortex_a5"; compatible = "arm,vexpress-v2p-ca9", "arm,vexpress-cortex_a9"; compatible = "arm,vexpress-v2p-ca15", "arm,vexpress-cortex_a15";

The trouble is, node { compatible = x } means "node is an x", not "node has an x".

Yes...

Quoted 4 lines

So, we should be careful do document what e.g. arm,vexpress-cortex_a5 actually means. It doesn't mean Cortex-A5, but instead it represents a whole jumble of characteristics which we expect to be common to all vexpress-based A5 platforms.

... so I'd translate it as "is a Versatile Express platform based on Cortex-A5 processor" and document it as such. As I said - patches tomorrow.

Quoted 4 lines

It feels that in practice arm,vexpress-cortex_a5 actually means exactly the same thing as arm,vexpress-v2p-ca5s. Are you sure these two are really independent? (In other words, do we expect multiple different vexpress variants based on A5, and so on?)

The examples for A5 I can quota are two different SMMs I used (one on a "small", second one on a "large" FPGA board), but they were very similar to the A5 core tile - so similar that you could (probably) use the core tile DTB to drive them. The A9 SMM with RS1 memory map I've mentioned is much more interesting case - A9 platform but nothing like original A9 core tile... Also the A15 looks interesting as we will most likely get the same tiles (as in: PCB) with different processors (as in: different silicon). This will be fun :-)

Hi All,

Another, hopefully close to the final, version of the series...

Changes from v2:

* new patch adding ENDPROC at the end of arch/arm/plat-versatile/headsmp.S and removing use of BSYM() realview and vexpress platform SMP calls

* updated binding documentation according to Dave's comments

* changed motherboard labels prefix from mb_ to v2m_ (to be consistent across code and DT files)

* reworked v2m timer initialization (again) so no #ifdefs are required in non-DT code

* renamed (to vendor- and platform-specific "arm,v2m-timer") and moved (to vexpress-v2m*.dtsi files) timer DT alias, as it is actually motherboard specific and the tile DTS shouldn't have to care; documentation updated accordingly

Tested on V2P-CA9 with ATAGs and DT and on V2P-CA5s with DT.

Previous version has been also tested by Ryan Harkin and provisionally acked by Rob Herring.

Thanks for all your help, especially to Dave for his continuous support!

I'm trying to build... what tree are you basing on?

With v3.2-rc3 or next, I get OF header failures like the following:

arch/arm/kernel/devtree.c: In function ?arm_dt_memblock_reserve?:
arch/arm/kernel/devtree.c:41:7: error: ?initial_boot_params? undeclared (first use in this function) arch/arm/kernel/devtree.c:41:7: note: each undeclared identifier is reported only once for each function it appears in

Quoted 1 line · Dave Martin

I'm trying to build... what tree are you basing on?

v3.2-rc3:

$ git log --oneline HEAD...v3.2-rc3~
3b9df1e ARM: vexpress: DT-based support for CoreTiles Express A5x2 and A9x4
5a1c565 ARM: vexpress: Initial RS1 memory map support
9355e8a ARM: vexpress: Add DT support in v2m
0529bd6 ARM: vexpress: Get rid of MMIO_P2V
68118cc ARM: versatile: Add missing ENDPROC to headsmp.S
caca6a0 Linux 3.2-rc3

Quoted 5 lines

With v3.2-rc3 or next, I get OF header failures like the following:

arch/arm/kernel/devtree.c: In function ?arm_dt_memblock_reserve?:
arch/arm/kernel/devtree.c:41:7: error: ?initial_boot_params? undeclared (first use in this function) arch/arm/kernel/devtree.c:41:7: note: each undeclared identifier is reported only once for each function it appears in

[...]

Can you send me your config, please?

Attached. It's just vexpress_defconfig, plus ARCH_VEXPRESS_V2P_CA5S_CA9=y

Quoted 1 line · Dave Martin

Attached. It's just vexpress_defconfig, plus ARCH_VEXPRESS_V2P_CA5S_CA9=y

Could you try that?

8<----------------------------------------------

arch/arm/mach-vexpress/Kconfig +1 -1

index 9eb8161..ded66d0 100644
@@ -11,7 +11,7 @@ config ARCH_VEXPRESS_CA9X4
 
 config ARCH_VEXPRESS_DT
        bool
-       select OF
+       select USE_OF
        help
          VE platform *requiring* Flattened Device Tree to boot.

8<----------------------------------------------

The OF is an effect of the USE_OF, not the other way round, sorry about the mistake.

Of course I could go the "classic way" and make the ARCH_VEXPRESS_V2P_CA5S_CA9 dependant on the OF, but this means that the DT-powered tile would be invisible till one enables USE_OF. Any opinions?

Your suggestion fixes it -- I suggest we keep the config this way round; this means that OF gets turned on when enabling a coretile which requires it, and those coretiles are offered as choices even before OF is turned on. That feels like a sensible behaviour for the config.

While we're about this, building of the applicable dtbs is not currently enabled.

Can we add this, so that "make dtbs" works?

arch/arm/mach-vexpress/Makefile.boot +0 -0

index 05b77a5..b89ffde 100644

Hi All,

Another, hopefully close to the final, version of the series...