BCM2836 (Raspberry Pi 2) port

Signed-off-by Eric Anholt <[email protected]>

---
 Documentation/devicetree/bindings/arm/bcm2836.txt | 10 ++++++++++

This is not hooked up to anything yet, but it means that our later 2836-specific changes will be more obvious. The bcm2836-rpi-2-b.dts actually comes from bcm2835-rpi-2-b-plus, which apparently is the closest.

 arch/arm/boot/dts/bcm2836-rpi-2-b.dts | 30 +++++++++++++++++++++
 arch/arm/boot/dts/bcm2836-rpi.dtsi    | 51 +++++++++++++++++++++++++++++++++++
 arch/arm/boot/dts/bcm2836.dtsi        | 31 +++++++++++++++++++++

The bus address for peripherals comes from the platform.h diff between 2708 and 2709, and the CPU's DT definition is based on the 2709 DT.

arch/arm/mach-bcm/board_bcm2835.c +7 -0

+static struct map_desc bcm2836_io_map __initdata = {
+       .virtual = BCM2835_PERIPH_VIRT,
+       .pfn = __phys_to_pfn(BCM2836_PERIPH_PHYS),
+       .length = BCM2835_PERIPH_SIZE,
+       .type = MT_DEVICE
+};
+

Quoted 13 lines · On Tuesday 21 April 2015 11:09:52 Eric Anholt wrote:

arch/arm/mach-bcm/board_bcm2835.c +10 -1

+static struct map_desc bcm2836_io_map __initdata = {
+       .virtual = BCM2835_PERIPH_VIRT,
+       .pfn = __phys_to_pfn(BCM2836_PERIPH_PHYS),
+       .length = BCM2835_PERIPH_SIZE,
+       .type = MT_DEVICE
+};
+
 static void __init bcm2835_map_io(void)
 {
-       iotable_init(&io_map, 1);
+       iotable_init(&bcm2835_io_map, 1);
+}
+

arch/arm/mach-bcm/board_bcm2835.c static void bcm2835_power_off(void) · line 119

Quoted 5 lines

arch/arm/mach-bcm/board_bcm2835.c +3 -0

+static void __init bcm2836_map_io(void)
+{
+       iotable_init(&bcm2836_io_map, 1);
 }

Can you explain what this is needed for? Most platform ports don't do this any more.

Quoted 14 lines · Arnd Bergmann

Quoted 13 lines · On Tuesday 21 April 2015 11:09:52 Eric Anholt wrote:

arch/arm/mach-bcm/board_bcm2835.c +10 -1

+static struct map_desc bcm2836_io_map __initdata = {
+       .virtual = BCM2835_PERIPH_VIRT,
+       .pfn = __phys_to_pfn(BCM2836_PERIPH_PHYS),
+       .length = BCM2835_PERIPH_SIZE,
+       .type = MT_DEVICE
+};
+
 static void __init bcm2835_map_io(void)
 {
-       iotable_init(&io_map, 1);
+       iotable_init(&bcm2835_io_map, 1);
+}
+

Quoted 8 lines

arch/arm/mach-bcm/board_bcm2835.c static void bcm2835_power_off(void) · line 119

Quoted 5 lines

arch/arm/mach-bcm/board_bcm2835.c +3 -0

+static void __init bcm2836_map_io(void)
+{
+       iotable_init(&bcm2836_io_map, 1);
 }

Can you explain what this is needed for? Most platform ports don't do this any more.

Nope, I can't! I'm not sure what the bcm2835 side of it does, and I was just replicating that for 2836.

Should it be removed from 2835, too?

Quoted 25 lines · On Tuesday 21 April 2015 13:37:13 Eric Anholt wrote:

Quoted 22 lines · Arnd Bergmann

Quoted 8 lines · On Tuesday 21 April 2015 11:09:52 Eric Anholt wrote:

arch/arm/mach-bcm/board_bcm2835.c +7 -0

+static struct map_desc bcm2836_io_map __initdata = {
+       .virtual = BCM2835_PERIPH_VIRT,
+       .pfn = __phys_to_pfn(BCM2836_PERIPH_PHYS),
+       .length = BCM2835_PERIPH_SIZE,
+       .type = MT_DEVICE
+};
+

arch/arm/mach-bcm/board_bcm2835.c static void bcm2835_power_off(void) · line 119

Quoted 10 lines

arch/arm/mach-bcm/board_bcm2835.c +6 -1

 static void __init bcm2835_map_io(void)
 {
-       iotable_init(&io_map, 1);
+       iotable_init(&bcm2835_io_map, 1);
+}
+
+static void __init bcm2836_map_io(void)
+{
+       iotable_init(&bcm2836_io_map, 1);
 }

Can you explain what this is needed for? Most platform ports don't do this any more.

Quoted 5 lines

Nope, I can't! I'm not sure what the bcm2835 side of it does, and I was just replicating that for 2836.

Should it be removed from 2835, too?

Hard to know. Does anything reference BCM2835_PERIPH_VIRT? Does it work if you remove it?

Quoted 2 lines

Hard to know. Does anything reference BCM2835_PERIPH_VIRT? Does it work if you remove it?

Well, that's clear enough. It dies early with:

Uncompressing Linux... done, booting the kernel.

[    0.000000] Booting Linux on physical CPU 0xf00
[    0.000000] Initializing cgroup subsys cpu
[    0.000000] Initializing cgroup subsys cpuacct
[    0.000000] Linux version 4.0.0-rc1-v7+ (anholt at eliezer) (gcc version 4.9.2 ( 4.9.2-10) ) #487 SMP PREEMPT Tue Apr 21 15:58:29 PDT 2015
[    0.000000] CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=10c5387d
[    0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
[    0.000000] Machine model: Raspberry Pi 2 Model B+
[    0.000000] bootconsole [earlycon0] enabled
[    0.000000] cma: Reserved 64 MiB at 0x37000000
[    0.000000] Memory policy: Data cache writealloc

(hung)

The only thing I see using this 0xf0000000 range is DEBUG_BCM2836's serial stuff, though.

arch/arm/mach-bcm/Kconfig +0 -5

@@ -116,17 +122,19 @@ config ARCH_BCM283X
 config ARCH_BCM2835
        bool "Broadcom BCM2835 family" if ARCH_MULTI_V6
        select ARCH_BCM283X
-       select ARCH_REQUIRE_GPIOLIB
-       select ARM_AMBA
        select ARM_ERRATA_411920
        select ARM_TIMER_SP804
-       select CLKSRC_OF
-       select PINCTRL
-       select PINCTRL_BCM2835
        help

Quoted 12 lines · On Tuesday 21 April 2015 11:09:54 Eric Anholt wrote:

arch/arm/mach-bcm/Kconfig +0 -5

@@ -116,17 +122,19 @@ config ARCH_BCM283X
 config ARCH_BCM2835
        bool "Broadcom BCM2835 family" if ARCH_MULTI_V6
        select ARCH_BCM283X
-       select ARCH_REQUIRE_GPIOLIB
-       select ARM_AMBA
        select ARM_ERRATA_411920
        select ARM_TIMER_SP804
-       select CLKSRC_OF
-       select PINCTRL
-       select PINCTRL_BCM2835
        help

arch/arm/mach-bcm/Kconfig config ARCH_BCM283X · line 137

Quoted 10 lines

arch/arm/mach-bcm/Kconfig +7 -0

          This enables support for the Broadcom BCM2835 SoC. This SoC is
          used in the Raspberry Pi and Roku 2 devices.
 
+config ARCH_BCM2836
+       bool "Broadcom BCM2836 family" if ARCH_MULTI_V7
+       select ARCH_BCM283X
+       help
+         This enables support for the Broadcom BCM2836 SoC. This SoC is
+         used in the Raspberry Pi 2
+

The description for the first one says "Broadcom BCM2835 family", and I guess they are both in the same family. How about leaving the CONFIG_BCM2835 symbol to mean one of them, and just duplicating the DEBUG_LL symbols?

You could do something like

config ARCH_BCM2835
bool "Broadcom BCM2835 family" if ARCH_MULTI_V6 || ARCH_MULTI_V7 select ARCH_BCM283X
select ARCH_REQUIRE_GPIOLIB
select ARM_AMBA
select ARM_ERRATA_411920 if ARCH_MULTI_V6
select ARM_TIMER_SP804 if ARCH_MULTI_V6
select CLKSRC_OF
select PINCTRL
select PINCTRL_BCM2835
help
This enables support for the Broadcom BCM2835 and BCM2836 SoCs. These SoCs is used in the Raspberry Pi and Roku 2 devices.

That should make it less confusing to the user, because they don't have to know which specific SoC they are building for, other than enabling the right architecture level.

Quoted 30 lines · Arnd Bergmann

Quoted 9 lines · On Tuesday 21 April 2015 11:09:54 Eric Anholt wrote:

(quoted diff) +0 -0

@@ -116,17 +122,19 @@ config ARCH_BCM283X config ARCH_BCM2835 

bool "Broadcom BCM2835 family" if ARCH_MULTI_V6 select
ARCH_BCM283X - select ARCH_REQUIRE_GPIOLIB - select
ARM_AMBA select ARM_ERRATA_411920 select ARM_TIMER_SP804 -
select CLKSRC_OF - select PINCTRL - select
PINCTRL_BCM2835 help This enables support for the Broadcom BCM2835 SoC. This SoC is used in the Raspberry Pi and Roku 2 devices.

Quoted 4 lines

+config ARCH_BCM2836 + bool "Broadcom BCM2836 family" if
ARCH_MULTI_V7 + select ARCH_BCM283X + help +
This enables support for the Broadcom BCM2836 SoC. This SoC is
+ used in the Raspberry Pi 2 +

The description for the first one says "Broadcom BCM2835 family", and I guess they are both in the same family. How about leaving the CONFIG_BCM2835 symbol to mean one of them, and just duplicating the DEBUG_LL symbols?

You could do something like

config ARCH_BCM2835 bool "Broadcom BCM2835 family" if ARCH_MULTI_V6 || ARCH_MULTI_V7 select ARCH_BCM283X select ARCH_REQUIRE_GPIOLIB select ARM_AMBA select ARM_ERRATA_411920 if ARCH_MULTI_V6 select ARM_TIMER_SP804 if ARCH_MULTI_V6 select CLKSRC_OF select PINCTRL select PINCTRL_BCM2835 help This enables support for the Broadcom BCM2835 and BCM2836 SoCs. These SoCs is used in the Raspberry Pi and Roku 2 devices.

Quoted 3 lines

That should make it less confusing to the user, because they don't have to know which specific SoC they are building for, other than enabling the right architecture level.

Seems reasonable to me. What do the 2835 maintainers think?

Quoted 1 line · Eric Anholt

MAINTAINERS +0 -0

MAINTAINERS T: git git://git.kernel.org/pub/scm/linux/kernel/git/rpi/linux-rpi.git · line 2136

Quoted 6 lines

MAINTAINERS +6 -0

+BROADCOM BCM2836 ARM ARCHITECTURE
+M:	Eric Anholt <[email protected]>
+L:	linux-rpi-kernel at lists.infradead.org (moderated for non-subscribers)
+T:	git git://git.kernel.org/pub/scm/linux/kernel/git/rpi/linux-rpi.git
+S:	Maintained
+N:	bcm2836

I'm tempted to suggest just adding this to the existing bcm2835 entry, since they're almost the same SoC.

We were previously relying on the fixed clock registration in clk-bcm2835, but there doesn't seem to be any real reason to not just define it in the DT (and for the 2836 port, I would have needed to change the clock's physical address in clk-bcm2835.c). Also, because we weren't registering the apb_pclk in clk-bcm2835 as a clock device, we were picking up the uart clock node as apb_pclk by accident.

Quoted 6 lines · Eric Anholt

We were previously relying on the fixed clock registration in clk-bcm2835, but there doesn't seem to be any real reason to not just define it in the DT (and for the 2836 port, I would have needed to change the clock's physical address in clk-bcm2835.c). Also, because we weren't registering the apb_pclk in clk-bcm2835 as a clock device, we were picking up the uart clock node as apb_pclk by accident.

Doesn't the following do just that?

clk = clk_register_fixed_rate(NULL, "apb_pclk", NULL, CLK_IS_ROOT,

                              126000000);

Anyway, with this patch, shouldn't we fix drivers/clk/clk-bcm2835.c not to register clocks that match those that are added to DT in this patch? Actually, to maintain DT ABI (new kernels working with old or new DT), we probably need to keep the code in clk-bcm2835.c, but make it conditional upon whether there's a clock node in the DT file.

Quoted 9 lines · Stephen Warren

Quoted 7 lines · Eric Anholt

We were previously relying on the fixed clock registration in clk-bcm2835, but there doesn't seem to be any real reason to not just define it in the DT (and for the 2836 port, I would have needed to change the clock's physical address in clk-bcm2835.c). Also, because we weren't registering the apb_pclk in clk-bcm2835 as a clock device, we were picking up the uart clock node as apb_pclk by accident.

Quoted 4 lines

Doesn't the following do just that?

clk = clk_register_fixed_rate(NULL, "apb_pclk", NULL, CLK_IS_ROOT, 126000000);

Nope! You also need the clk_register_clkdev for the type of lookup being done by APB to find it.

Quoted 6 lines

Anyway, with this patch, shouldn't we fix drivers/clk/clk-bcm2835.c not to register clocks that match those that are added to DT in this patch? Actually, to maintain DT ABI (new kernels working with old or new DT), we probably need to keep the code in clk-bcm2835.c, but make it conditional upon whether there's a clock node in the DT file.

Yeah, I hadn't modified the .c code because of DT ABI

This is my first submission of a Raspberry Pi 2 port. It can be found at https://github.com/anholt/linux/tree/bcm2836

I'm using the 2835 interrupt controller support, without adding the checks for ARM local interrupts first. That means no support for IPIs (and thus no SMP), no PMU events, and no local timer (I'm using the same 2835 peripheral one).

It supports a similar featureset to Pi 1 at this point. Serial and SD cards work. Just one CPU supported. USB (ethernet) works if you use U-Boot, or my mailbox series
(https://github.com/anholt/linux/tree/bcm2836-mbox).

Hit any key to stop autoboot: 0
U-Boot> setenv fdt_high fffffff
U-Boot> boot
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:1...
Found /extlinux/extlinux.conf
Retrieving file: /extlinux/extlinux.conf
reading /extlinux/extlinux.conf
429 bytes read in 18 ms (22.5 KiB/s)
Boot menu
1: Default kernel
2: Backup kernel
Enter choice: 1
1: Default kernel
Retrieving file: /extlinux/../zImage
reading /extlinux/../zImage
3467376 bytes read in 1996 ms (1.7 MiB/s)
append: earlyprintk loglevel=8 console=ttyAMA0 console=tty1 verbose rootwait root=/dev/mmcblk0p2 rw Retrieving file: /extlinux/../bcm2836-rpi-2-b.dtb
reading /extlinux/../bcm2836-rpi-2-b.dtb LLLiiinnnuuuxxx.........

OOOuuuttt ooofff mmmeeemmmooorrryyy wwwhhhiiillleee aaallllllooocccaaatttiiinnnggg ooouuutttpppuuuttt bbbuuuffffffeeerrr

-- System halted4572 bytes read in 33 ms (134.8 KiB/s)
Kernel image @ 0x1000000 [ 0x000000 - 0x34e870 ] ## Flattened Device Tree blob at 02000000
Booting using the fdt blob at 0x2000000 Loading Device Tree to 0fffb000, end 0ffff1db ... OK

Starting kernel ...

Quoted 8 lines · Eric Anholt

This is my first submission of a Raspberry Pi 2 port. It can be found at https://github.com/anholt/linux/tree/bcm2836

I'm using the 2835 interrupt controller support, without adding the checks for ARM local interrupts first. That means no support for IPIs (and thus no SMP), no PMU events, and no local timer (I'm using the same 2835 peripheral one).

Quoted 4 lines

It supports a similar featureset to Pi 1 at this point. Serial and SD cards work. Just one CPU supported. USB (ethernet) works if you use U-Boot, or my mailbox series
(https://github.com/anholt/linux/tree/bcm2836-mbox).

I can't quite get this to work. I think what's happening is that U-Boot is over-writing the location of the code/data that the CPU1..3 pin loop uses. Do you know what that address is so I can confirm that?

I suspect this because when I load the kernel/DT in U-Boot, or when I jump to the kernel to boot it, I see lots of extra duplicated characters on the UART, like all 4 CPUs are booting Linux. For example:

Quoted 18 lines · Stephen Warren

Quoted 8 lines · Eric Anholt

This is my first submission of a Raspberry Pi 2 port. It can be found at https://github.com/anholt/linux/tree/bcm2836

I'm using the 2835 interrupt controller support, without adding the checks for ARM local interrupts first. That means no support for IPIs (and thus no SMP), no PMU events, and no local timer (I'm using the same 2835 peripheral one).

Quoted 4 lines

It supports a similar featureset to Pi 1 at this point. Serial and SD cards work. Just one CPU supported. USB (ethernet) works if you use U-Boot, or my mailbox series
(https://github.com/anholt/linux/tree/bcm2836-mbox).

I can't quite get this to work. I think what's happening is that U-Boot is over-writing the location of the code/data that the CPU1..3 pin loop uses. Do you know what that address is so I can confirm that?

Quoted 3 lines

I suspect this because when I load the kernel/DT in U-Boot, or when I jump to the kernel to boot it, I see lots of extra duplicated characters on the UART, like all 4 CPUs are booting Linux. For example:

Oops, I was just extrapolating that U-Boot would work. I've quit using it because of the extra configuration work (particularly the compiled text files for the boot scripts).

I haven't looked into how SMP works, because I don't have the interrupt support necessary yet (bcm2836-irq branch for hacks in that direction).

And in further testing, the USB is actually not working and I'm not sure what gave me the idea that it was.

http://git.denx.de/?p=u-boot.git;a=commit;h=79340db7f1f676b8eb5911f4993ebedf27009c0b

http://git.denx.de/?p=u-boot.git;a=commit;h=5c0beb5c58c86d2a6d12dee6330dc85554de5c60

http://git.denx.de/?p=u-boot.git;a=commit;h=122426d46e31391480c4b83b1003e4feca24d491

Quoted 20 lines · Eric Anholt

Quoted 18 lines · Stephen Warren

Quoted 8 lines · Eric Anholt

This is my first submission of a Raspberry Pi 2 port. It can be found at https://github.com/anholt/linux/tree/bcm2836

I'm using the 2835 interrupt controller support, without adding the checks for ARM local interrupts first. That means no support for IPIs (and thus no SMP), no PMU events, and no local timer (I'm using the same 2835 peripheral one).

Quoted 4 lines

It supports a similar featureset to Pi 1 at this point. Serial and SD cards work. Just one CPU supported. USB (ethernet) works if you use U-Boot, or my mailbox series
(https://github.com/anholt/linux/tree/bcm2836-mbox).

I can't quite get this to work. I think what's happening is that U-Boot is over-writing the location of the code/data that the CPU1..3 pin loop uses. Do you know what that address is so I can confirm that?

Quoted 7 lines

Quoted 3 lines

I suspect this because when I load the kernel/DT in U-Boot, or when I jump to the kernel to boot it, I see lots of extra duplicated characters on the UART, like all 4 CPUs are booting Linux. For example:

Oops, I was just extrapolating that U-Boot would work. I've quit using it because of the extra configuration work (particularly the compiled text files for the boot scripts).

You don't need any compiled text files if you create an extlinux.conf rather than a boot.scr. extlinux.conf is plain text.

To boot without U-Boot: Could you say what's in your config.txt? I assume I can just copy the kernel zImage as kernel.img, and the DTB from the kernel build tree without renaming it?

Quoted 2 lines

Hit any key to stop autoboot: 0
U-Boot> setenv fdt_high fffffff

On Thursday 23 April 2015, 22:25:08 wrote Stephen Warren:

Quoted 2 lines

Quoted 2 lines

Hit any key to stop autoboot: 0
U-Boot> setenv fdt_high fffffff

Any specific reason to set fdt_high to fffffff?

Quoted 5 lines

On Thursday 23 April 2015, 22:25:08 wrote Stephen Warren:

Quoted 2 lines

Quoted 2 lines

Hit any key to stop autoboot: 0
U-Boot> setenv fdt_high fffffff

Any specific reason to set fdt_high to fffffff?

Yes, it prevents U-Boot's annoying habit of moving the DTB from where it was loaded to some other place. This was especially important in this case since I was trying to find out exactly which piece of RAM being over-written caused the issues I was seeing.

On Monday 11 May 2015, 20:36:40 wrote Stephen Warren:

Quoted 5 lines · Alexander Stein

Quoted 4 lines

On Thursday 23 April 2015, 22:25:08 wrote Stephen Warren:

Quoted 2 lines

Quoted 2 lines

Hit any key to stop autoboot: 0
U-Boot> setenv fdt_high fffffff

Quoted 6 lines

Quoted 1 line

Any specific reason to set fdt_high to fffffff?

Yes, it prevents U-Boot's annoying habit of moving the DTB from where it was loaded to some other place. This was especially important in this case since I was trying to find out exactly which piece of RAM being over-written caused the issues I was seeing.

Shouldn't this then be part of the default raspberry (2 only?) environment?

Quoted 13 lines · Alexander Stein

On Monday 11 May 2015, 20:36:40 wrote Stephen Warren:

Quoted 11 lines · Alexander Stein

Quoted 5 lines

On Thursday 23 April 2015, 22:25:08 wrote Stephen Warren:

Quoted 2 lines

Quoted 2 lines

Hit any key to stop autoboot: 0
U-Boot> setenv fdt_high fffffff

Any specific reason to set fdt_high to fffffff?

Yes, it prevents U-Boot's annoying habit of moving the DTB from where it was loaded to some other place. This was especially important in this case since I was trying to find out exactly which piece of RAM being over-written caused the issues I was seeing.

Quoted 1 line

Shouldn't this then be part of the default raspberry (2 only?) environment?

Eventually yes. So far, nobody seems to know which areas of RAM are off-limits (presumably since the RAM is used as a CPU1..3 pen), so I was experimenting to try and find that out.

Quoted 14 lines · Stephen Warren

Quoted 13 lines · Alexander Stein

On Monday 11 May 2015, 20:36:40 wrote Stephen Warren:

Quoted 11 lines · Alexander Stein

Quoted 5 lines

On Thursday 23 April 2015, 22:25:08 wrote Stephen Warren:

Quoted 2 lines

Quoted 2 lines

Hit any key to stop autoboot: 0
U-Boot> setenv fdt_high fffffff

Any specific reason to set fdt_high to fffffff?

Yes, it prevents U-Boot's annoying habit of moving the DTB from where it was loaded to some other place. This was especially important in this case since I was trying to find out exactly which piece of RAM being over-written caused the issues I was seeing.

Quoted 5 lines

Quoted 1 line

Shouldn't this then be part of the default raspberry (2 only?) environment?

Eventually yes. So far, nobody seems to know which areas of RAM are off-limits (presumably since the RAM is used as a CPU1..3 pen), so I was experimenting to try and find that out.

If I'm reading this right, the CPU1-3 pen is in the bottom 8k of memory (actually much less than 8k).

Quoted 16 lines · Eric Anholt

Quoted 14 lines · Stephen Warren

Quoted 13 lines · Alexander Stein

On Monday 11 May 2015, 20:36:40 wrote Stephen Warren:

Quoted 11 lines · Alexander Stein

Quoted 5 lines

On Thursday 23 April 2015, 22:25:08 wrote Stephen Warren:

Quoted 2 lines

Quoted 2 lines

Hit any key to stop autoboot: 0
U-Boot> setenv fdt_high fffffff

Any specific reason to set fdt_high to fffffff?

Yes, it prevents U-Boot's annoying habit of moving the DTB from where it was loaded to some other place. This was especially important in this case since I was trying to find out exactly which piece of RAM being over-written caused the issues I was seeing.

Quoted 8 lines

Quoted 5 lines

Quoted 1 line

Shouldn't this then be part of the default raspberry (2 only?) environment?

Eventually yes. So far, nobody seems to know which areas of RAM are off-limits (presumably since the RAM is used as a CPU1..3 pen), so I was experimenting to try and find that out.

If I'm reading this right, the CPU1-3 pen is in the bottom 8k of memory (actually much less than 8k).

Hmm. I wondered if that was the case. I don't think anything I was doing in U-Boot /should/ touch those pages, but there have been bugs before where some pointer was left at NULL, and some DM (U-Boot Device Model) code ended up putting structures in page 0 by mistake. Perhaps something like that has resurfaced. I'll try to find time to diff page 0 before/after various U-Boot operations, and see if it's getting modified...

Quoted 26 lines · Stephen Warren

Quoted 16 lines · Eric Anholt

Quoted 14 lines · Stephen Warren

Quoted 13 lines · Alexander Stein

On Monday 11 May 2015, 20:36:40 wrote Stephen Warren:

Quoted 11 lines · Alexander Stein

Quoted 5 lines

On Thursday 23 April 2015, 22:25:08 wrote Stephen Warren:

Quoted 2 lines

Quoted 2 lines

Hit any key to stop autoboot: 0
U-Boot> setenv fdt_high fffffff

Any specific reason to set fdt_high to fffffff?

Yes, it prevents U-Boot's annoying habit of moving the DTB from where it was loaded to some other place. This was especially important in this case since I was trying to find out exactly which piece of RAM being over-written caused the issues I was seeing.

Quoted 8 lines

Quoted 5 lines

Quoted 1 line

Shouldn't this then be part of the default raspberry (2 only?) environment?

Eventually yes. So far, nobody seems to know which areas of RAM are off-limits (presumably since the RAM is used as a CPU1..3 pen), so I was experimenting to try and find that out.

If I'm reading this right, the CPU1-3 pen is in the bottom 8k of memory (actually much less than 8k).

Quoted 6 lines

Hmm. I wondered if that was the case. I don't think anything I was doing in U-Boot /should/ touch those pages, but there have been bugs before where some pointer was left at NULL, and some DM (U-Boot Device Model) code ended up putting structures in page 0 by mistake. Perhaps something like that has resurfaced. I'll try to find time to diff page 0 before/after various U-Boot operations, and see if it's getting modified...

How about on the Linux side? What's reserving that memory for us, if anything?

Weird things happen if I put "ARM: bcm2836: Add a DT binding
for the ARM local registers." and "ARM: bcm2835: Use a syscon regmap to set up timer frequency." before the SMP support in the bcm2836-smp tree (init crashes).

Quoted 35 lines · Eric Anholt

Quoted 26 lines · Stephen Warren

Quoted 16 lines · Eric Anholt

Quoted 14 lines · Stephen Warren

Quoted 13 lines · Alexander Stein

On Monday 11 May 2015, 20:36:40 wrote Stephen Warren:

Quoted 11 lines · Alexander Stein

Quoted 5 lines

On Thursday 23 April 2015, 22:25:08 wrote Stephen Warren:

Quoted 2 lines

Quoted 2 lines

Hit any key to stop autoboot: 0
U-Boot> setenv fdt_high fffffff

Any specific reason to set fdt_high to fffffff?

Yes, it prevents U-Boot's annoying habit of moving the DTB from where it was loaded to some other place. This was especially important in this case since I was trying to find out exactly which piece of RAM being over-written caused the issues I was seeing.

Quoted 8 lines

Quoted 5 lines

Quoted 1 line

Shouldn't this then be part of the default raspberry (2 only?) environment?

Eventually yes. So far, nobody seems to know which areas of RAM are off-limits (presumably since the RAM is used as a CPU1..3 pen), so I was experimenting to try and find that out.

If I'm reading this right, the CPU1-3 pen is in the bottom 8k of memory (actually much less than 8k).

Quoted 6 lines

Hmm. I wondered if that was the case. I don't think anything I was doing in U-Boot /should/ touch those pages, but there have been bugs before where some pointer was left at NULL, and some DM (U-Boot Device Model) code ended up putting structures in page 0 by mistake. Perhaps something like that has resurfaced. I'll try to find time to diff page 0 before/after various U-Boot operations, and see if it's getting modified...

Quoted 2 lines

How about on the Linux side? What's reserving that memory for us, if anything?

Likely nothing at present. I was starting to see what looked like SMP-pen-related issues just in U-Boot, before even attempting to boot a kernel at all. So, I didn't put any though into how to communicate this to the kernel.

Quoted 4 lines

Weird things happen if I put "ARM: bcm2836: Add a DT binding
for the ARM local registers." and "ARM: bcm2835: Use a syscon regmap to set up timer frequency." before the SMP support in the bcm2836-smp tree (init crashes).

This issue would probably explain that; if the kernel just happens to allocate a physical page of RAM that overlaps the SMP pen memory.

A /memreserve/ in the DT would probably solve this. Adjusting the content of the /memory/reg property to remove the SMP pen would likely work too.

Is there no way to disable CPU1..n other than using an SMP pen in memory? If the CPUs simply weren't executing anything at all, but could be unblocked/powered-up/... later, that'd simplify life.

This is my first submission of a Raspberry Pi 2 port. It can be found at https://github.com/anholt/linux/tree/bcm2836

I'm using the 2835 interrupt controller support, without adding the checks for ARM local interrupts first. That means no support for IPIs (and thus no SMP), no PMU events, and no local timer (I'm using the same 2835 peripheral one).

It supports a similar featureset to Pi 1 at this point. Serial and SD cards work. Just one CPU supported. USB (ethernet) works if you use U-Boot, or my mailbox series
(https://github.com/anholt/linux/tree/bcm2836-mbox).

Quoted 8 lines

This is my first submission of a Raspberry Pi 2 port. It can be found at https://github.com/anholt/linux/tree/bcm2836

I'm using the 2835 interrupt controller support, without adding the checks for ARM local interrupts first. That means no support for IPIs (and thus no SMP), no PMU events, and no local timer (I'm using the same 2835 peripheral one).

Quoted 4 lines

It supports a similar featureset to Pi 1 at this point. Serial and SD cards work. Just one CPU supported. USB (ethernet) works if you use U-Boot, or my mailbox series
(https://github.com/anholt/linux/tree/bcm2836-mbox).

Tested-by Stephen Warren <[email protected]>

I applied the patches on top of korg's linux-rpi.git for-rpi-next, resolved the io_map conflicts, and tested without U-Boot.

Quoted 8 lines · Eric Anholt

This is my first submission of a Raspberry Pi 2 port. It can be found at https://github.com/anholt/linux/tree/bcm2836

I'm using the 2835 interrupt controller support, without adding the checks for ARM local interrupts first. That means no support for IPIs (and thus no SMP), no PMU events, and no local timer (I'm using the same 2835 peripheral one).

Quoted 4 lines

It supports a similar featureset to Pi 1 at this point. Serial and SD cards work. Just one CPU supported. USB (ethernet) works if you use U-Boot, or my mailbox series
(https://github.com/anholt/linux/tree/bcm2836-mbox).

Tested-by Stephen Warren <[email protected]>

I applied the patches on top of korg's linux-rpi.git for-rpi-next, resolved the io_map conflicts, and tested without U-Boot.

I'll try to work out why it doesn't work with U-Boot. I can't immediately see anything in /proc/device-tree that indicates the RPi firmware is modifying the DT that's passed to the kernel to exclude any CPU1..3 spin tables, so either the kernel isn't hitting those purely by luck, or I'm guessing wrong re: the issue with U-Boot.

From 2835, and have it just call into 2835 for GPU IRQ handling?

2836 SMP is now booting on my branch. Big thanks to Andrea Merello for doing most of the work on it. Not-cleaned-up series is available at:

https://github.com/anholt/linux/tree/bcm2836-smp

There's a bunch of stuff in here I'm not sure about:

How do we like the way I'm inheriting 2835 stuff with the includes now? (It's been a lot less merging work than my initial post had been, but the /delete-node/ lines for 2386's changes are gross).

How do people feel about putting the 2386 local IRQ handling in the 2835 irqchip code? Do we like the code sharing for GPU IRQs, or would we rather have a separate driver? Could we separate the 2836 local irqs From 2835, and have it just call into 2835 for GPU IRQ handling?

Where do people think the arch timer frequency initialization should go (commit "ARM: BCM2835: Set up the local timer frequency on 2836.")? On 2709 it's in init_time(), but I hear we've been trying to move away from these hooks.

Is there a sensible way to share our mapping of the local regs between the driver and platform bits that need to access them? (see arch/arm/mach-bcm/bcm2836_platsmp.c for what we're doing currently)