Enable MMU

[agraf]

Once my MMU force-enable patch set is in upstream U-Boot, you will need a patch similar to the one below to make your code work. I verified that it works - great job!

diff --git a/board/raspberrypi/rpi/rpi.c b/board/raspberrypi/rpi/rpi.c
index ee3b082..8770585 100644
--- a/board/raspberrypi/rpi/rpi.c
+++ b/board/raspberrypi/rpi/rpi.c
@@ -21,6 +21,30 @@

 DECLARE_GLOBAL_DATA_PTR;

+#ifdef CONFIG_ARM64
+#include <asm/armv8/mmu.h>
+
+static struct mm_region rpi_mem_map[] = {
+       {
+               .base = 0x0UL,
+               .size = 0x3f000000UL,
+               .attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL) |
+                        PTE_BLOCK_INNER_SHARE
+       }, {
+               .base = 0x3f000000UL,
+               .size = 0xc1000000UL,
+               .attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
+                        PTE_BLOCK_NON_SHARE |
+                        PTE_BLOCK_PXN | PTE_BLOCK_UXN
+       }, {
+               /* List terminator */
+               0,
+       }
+};
+
+struct mm_region *mem_map = rpi_mem_map;
+#endif
+
 static const struct bcm2835_gpio_platdata gpio_platdata = {
    .base = BCM2835_GPIO_BASE,
 };
diff --git a/drivers/video/bcm2835.c b/drivers/video/bcm2835.c
index bff1fcb..6c7d5f0 100644
--- a/drivers/video/bcm2835.c
+++ b/drivers/video/bcm2835.c
@@ -106,6 +106,10 @@ void lcd_ctrl_init(void *lcdbase)

    gd->fb_base = bus_to_phys(
        msg_setup->allocate_buffer.body.resp.fb_address);
+
+#ifdef CONFIG_ARM64
+   lcd_set_flush_dcache(1);
+#endif
 }

 void lcd_enable(void)
diff --git a/include/configs/rpi_3.h b/include/configs/rpi_3.h
index 255f749..010807c 100644
--- a/include/configs/rpi_3.h
+++ b/include/configs/rpi_3.h
@@ -10,7 +10,6 @@
 #define CONFIG_SKIP_LOWLEVEL_INIT
 #define CONFIG_BCM2836
 #define CONFIG_SYS_CACHELINE_SIZE      64
-#define CONFIG_SYS_DCACHE_OFF

 #include "rpi-common.h"

[agraf]

I guess according to https://github.com/raspberrypi/documentation/blob/master/hardware/raspberrypi/bcm2836/QA7_rev3.4.pdf the normal memory range should be up to 0x3e000000.

[zeldin]

Thanks for the heads up!

I guess according to https://github.com/raspberrypi/documentation/blob/master/hardware/raspberrypi/bcm2836/QA7_rev3.4.pdf the normal memory range should be up to 0x3e000000.

Yes, or maybe gd->ram_size could be used, thus removing the need for lcd_set_flush_dcache(1);?

[agraf]

That would work too. We'd probably want another patch adding a dcache set for the region nevertheless - the frame buffer is pretty slow when not accessed cached :).

But I can easily follow up with something like that later on. I'm trying to get the 32bit code cache enabled atm as well, so it'd fall out of that work anyway.

Can you please post your patch upstream?

[zeldin]

Sure. I'd like to verify that SMP is working first though. Right now my 64-bit kernel only activates one core, so I'm not quite convinced the other 3 are handled correctly...

[agraf]

You probably are running in EL3, so you need to provide psci interfaces to wake the others up.

Alex

Am 15.03.2016 um 09:26 schrieb Marcus Comstedt notifications@github.com:

Sure. I'd like to verify that SMP is working first though. Right now my 64-bit kernel only activates one core, so I'm not quite convinced the other 3 are handled correctly...

― You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: https://github.com/zeldin/u-boot-rpi3/issues/1#issuecomment-196714535

[zeldin]

I think lowlevel_init in start.S is supposed to switch the "slaves" to EL2. It's the stuff after that which seems a bit flaky, they are waiting on CPU_RELEASE_ADDR, but nothing writes to that address to release them...

[agraf]

That's the legacy spin release. Modern day systems should use psci. You can always implement a psci callback writing to the spin tables though.

I also think UP u-boot is worth upstreaming today - smp can easily follow next. No need to build Rome in one day.

Alex

Am 15.03.2016 um 10:21 schrieb Marcus Comstedt notifications@github.com:

I think lowlevel_init in start.S is supposed to switch the "slaves" to EL2. It's the stuff after that which seems a bit flaky, they are waiting on CPU_RELEASE_ADDR, but nothing writes to that address to release them...

― You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: https://github.com/zeldin/u-boot-rpi3/issues/1#issuecomment-196737143

[zeldin]

Hm, U-Boot seems to have an implementation of psci for armv7 only. Will need to ponder a bit on this.

[swarren]

The upstream kernel for (32-bit) RPi currently uses a custom scheme for SMP boot, using the SoC mailbox hardware. Before investigating PSCI it would be worth asking Eric Anholt and the ARM64 maintainers whether they want to continue with that for compatibility or switch to PSCI.

[agraf]

As far as I understood Catalin, he wanted to make sure every new system has PSCI support.

The nice thing about the AArch64 port is that we're running in EL3, so we actually have the chance to add PSCI support there - unlike on the 32bit versions.

But regardless, please don't sit on the patches :). Send them, collect feedback and do PSCI enablement in parallel.

[swarren]

I seriously doubt PSCI is possible, since IIUC the HW only supports booting all CPUs at once. That said, I don't know if CPU power-off/reset are mandatory operations in PSCI, or just CPU boot. More likely spin tables would be a better match. Judging by a quick read of the link you mentioned on IRC (https://lkml.org/lkml/2015/4/10/688) spin tables (while discouraged) are still acceptable.

I plan to start sending patches soon, but we should wait to find out whether the RPi Foundation is going to initialize the mini UART pinmux and baud rate or not, and what their story is re: mini UART vs. full UART for the console. It seems quite a messy story at present.