[PATCH] ARM: AM335x: Beaglebone: Fix memory setup for Beaglebone black

[PATCH] ARM: AM335x: Beaglebone: Fix memory setup for Beaglebone black

[Philipp Zabel]

From: Philipp Zabel <philipp.zabel@gmail.com>

Commit 0d6392de4ad824a6553c0e3e3e18edef689a7c85 introduced a stripped
down device tree used for both white and black Beaglebone variants
that included the 256 MiB memory node from am335x-bone-common.dtsi.
This leads to the following error in the MLO:

    mmu: Critical Error: Can't request SDRAM region for ttb at 9fff4000

This patch removes the (for the Beaglebone black) invalid memory size
from the common device tree and instead registers the memory bank
manually in the board file.

Signed-off-by: Philipp Zabel <philipp.zabel@gmail.com>
---
 arch/arm/boards/beaglebone/board.c   | 17 +++++++++++++++++
 arch/arm/dts/am335x-bone-common.dtsi |  5 -----
 2 files changed, 17 insertions(+), 5 deletions(-)

diff --git a/arch/arm/boards/beaglebone/board.c b/arch/arm/boards/beaglebone/board.c
index 993d05b..3042189 100644
--- a/arch/arm/boards/beaglebone/board.c
+++ b/arch/arm/boards/beaglebone/board.c
@@ -51,6 +51,23 @@ static int beaglebone_coredevice_init(void)
 }
 coredevice_initcall(beaglebone_coredevice_init);
 
+static int beaglebone_mem_init(void)
+{
+	uint32_t sdram_size;
+
+	if (!of_machine_is_compatible("ti,am335x-bone"))
+		return 0;
+
+	if (is_beaglebone_black())
+		sdram_size = SZ_512M;
+	else
+		sdram_size = SZ_256M;
+
+	arm_add_mem_device("ram0", 0x80000000, sdram_size);
+	return 0;
+}
+mem_initcall(beaglebone_mem_init);
+
 static int beaglebone_devices_init(void)
 {
 	int black;
diff --git a/arch/arm/dts/am335x-bone-common.dtsi b/arch/arm/dts/am335x-bone-common.dtsi
index 00271c4..4cf7fdb 100644
--- a/arch/arm/dts/am335x-bone-common.dtsi
+++ b/arch/arm/dts/am335x-bone-common.dtsi
@@ -17,11 +17,6 @@
 		};
 	};
 
-	memory {
-		device_type = "memory";
-		reg = <0x80000000 0x10000000>; /* 256 MB */
-	};
-
 	leds {
 		pinctrl-names = "default";
 		pinctrl-0 = <&user_leds_s0>;
-- 
2.0.0


_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: [PATCH] ARM: AM335x: Beaglebone: Fix memory setup for Beaglebone black

[Antony Pavlov]

On Mon, 16 Jun 2014 17:13:54 +0200
Philipp Zabel <p.zabel@pengutronix.de> wrote:

Question to Sascha.

Can we preserve the 'memory' dts record in situations like this?

Is it possible just alter dts in early init code?
Or something else?

> From: Philipp Zabel <philipp.zabel@gmail.com>
> 
> Commit 0d6392de4ad824a6553c0e3e3e18edef689a7c85 introduced a stripped
> down device tree used for both white and black Beaglebone variants
> that included the 256 MiB memory node from am335x-bone-common.dtsi.
> This leads to the following error in the MLO:
> 
>     mmu: Critical Error: Can't request SDRAM region for ttb at 9fff4000
> 
> This patch removes the (for the Beaglebone black) invalid memory size
> from the common device tree and instead registers the memory bank
> manually in the board file.
> 
> Signed-off-by: Philipp Zabel <philipp.zabel@gmail.com>
> ---
>  arch/arm/boards/beaglebone/board.c   | 17 +++++++++++++++++
>  arch/arm/dts/am335x-bone-common.dtsi |  5 -----
>  2 files changed, 17 insertions(+), 5 deletions(-)
> 
> diff --git a/arch/arm/boards/beaglebone/board.c b/arch/arm/boards/beaglebone/board.c
> index 993d05b..3042189 100644
> --- a/arch/arm/boards/beaglebone/board.c
> +++ b/arch/arm/boards/beaglebone/board.c
> @@ -51,6 +51,23 @@ static int beaglebone_coredevice_init(void)
>  }
>  coredevice_initcall(beaglebone_coredevice_init);
>  
> +static int beaglebone_mem_init(void)
> +{
> +	uint32_t sdram_size;
> +
> +	if (!of_machine_is_compatible("ti,am335x-bone"))
> +		return 0;
> +
> +	if (is_beaglebone_black())
> +		sdram_size = SZ_512M;
> +	else
> +		sdram_size = SZ_256M;
> +
> +	arm_add_mem_device("ram0", 0x80000000, sdram_size);
> +	return 0;
> +}
> +mem_initcall(beaglebone_mem_init);
> +
>  static int beaglebone_devices_init(void)
>  {
>  	int black;
> diff --git a/arch/arm/dts/am335x-bone-common.dtsi b/arch/arm/dts/am335x-bone-common.dtsi
> index 00271c4..4cf7fdb 100644
> --- a/arch/arm/dts/am335x-bone-common.dtsi
> +++ b/arch/arm/dts/am335x-bone-common.dtsi
> @@ -17,11 +17,6 @@
>  		};
>  	};
>  
> -	memory {
> -		device_type = "memory";
> -		reg = <0x80000000 0x10000000>; /* 256 MB */
> -	};
> -
>  	leds {
>  		pinctrl-names = "default";
>  		pinctrl-0 = <&user_leds_s0>;
> -- 
> 2.0.0
> 
> 
> _______________________________________________
> barebox mailing list
> barebox@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/barebox


-- 
-- 
Best regards,
  Antony Pavlov

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: [PATCH] ARM: AM335x: Beaglebone: Fix memory setup for Beaglebone black

[Sascha Hauer]

Hi Antony,

On Mon, Jun 16, 2014 at 09:08:59PM +0400, Antony Pavlov wrote:
> On Mon, 16 Jun 2014 17:13:54 +0200
> Philipp Zabel <p.zabel@pengutronix.de> wrote:
> 
> Question to Sascha.
> 
> Can we preserve the 'memory' dts record in situations like this?
> 
> Is it possible just alter dts in early init code?
> Or something else?

For what do you want to preserve it? barebox never uses the memory node
directly to pass it to the kernel. The barebox memory banks are
initialized from the code and from the dts. When starting Linux the
memory node is (re)populated with the barebox memory banks

I may misunderstand what you are trying to archieve.

Sascha


-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: [PATCH] ARM: AM335x: Beaglebone: Fix memory setup for Beaglebone black

[Antony Pavlov]

On Mon, 16 Jun 2014 23:35:13 +0200
Sascha Hauer <s.hauer@pengutronix.de> wrote:

> Hi Antony,
> 
> On Mon, Jun 16, 2014 at 09:08:59PM +0400, Antony Pavlov wrote:
> > On Mon, 16 Jun 2014 17:13:54 +0200
> > Philipp Zabel <p.zabel@pengutronix.de> wrote:
> > 
> > Question to Sascha.
> > 
> > Can we preserve the 'memory' dts record in situations like this?
> > 
> > Is it possible just alter dts in early init code?
> > Or something else?
> 
> For what do you want to preserve it? barebox never uses the memory node
> directly to pass it to the kernel. The barebox memory banks are
> initialized from the code and from the dts. When starting Linux the
> memory node is (re)populated with the barebox memory banks
> 
> I may misunderstand what you are trying to archieve.

Imagine a family of boards. The RAM size can vary from board to board
(for simplicity suppose that all over conditions are the same).
Suppose I have a reliable RAM size detection routine and I want to run
just the same barebox image on different boards.
I want to run dts enabled Linux on all boards.

How can I handle this situation correctly?

Also note that on MIPS boards barebox uses no more than 256 MiB of RAM
(even if a board has more than 256 MiB of RAM). It's a measure to make
mips barebox simplier.
I want to pass information on all available RAM to linux via dts.
Can you describe reasonable barebox behaviour in this situation please?

-- 
Best regards,
  Antony Pavlov

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: [PATCH] ARM: AM335x: Beaglebone: Fix memory setup for Beaglebone black

[Sascha Hauer]

On Tue, Jun 17, 2014 at 09:35:17AM +0400, Antony Pavlov wrote:
> On Mon, 16 Jun 2014 23:35:13 +0200
> Sascha Hauer <s.hauer@pengutronix.de> wrote:
> 
> > Hi Antony,
> > 
> > On Mon, Jun 16, 2014 at 09:08:59PM +0400, Antony Pavlov wrote:
> > > On Mon, 16 Jun 2014 17:13:54 +0200
> > > Philipp Zabel <p.zabel@pengutronix.de> wrote:
> > > 
> > > Question to Sascha.
> > > 
> > > Can we preserve the 'memory' dts record in situations like this?
> > > 
> > > Is it possible just alter dts in early init code?
> > > Or something else?
> > 
> > For what do you want to preserve it? barebox never uses the memory node
> > directly to pass it to the kernel. The barebox memory banks are
> > initialized from the code and from the dts. When starting Linux the
> > memory node is (re)populated with the barebox memory banks
> > 
> > I may misunderstand what you are trying to archieve.
> 
> Imagine a family of boards. The RAM size can vary from board to board
> (for simplicity suppose that all over conditions are the same).
> Suppose I have a reliable RAM size detection routine and I want to run
> just the same barebox image on different boards.
> I want to run dts enabled Linux on all boards.

In this case don't specify the memory size in the devicetree. In a
mem_initcall detect the actual RAM size you have and call
arm_add_mem_device() accordingly. That's all. The rest will be handled
automatically. See of_memory_fixup(), this will iterate over the memory
banks and set the memory node to the correct values.

> 
> How can I handle this situation correctly?
> 
> Also note that on MIPS boards barebox uses no more than 256 MiB of RAM
> (even if a board has more than 256 MiB of RAM). It's a measure to make
> mips barebox simplier.
> I want to pass information on all available RAM to linux via dts.
> Can you describe reasonable barebox behaviour in this situation please?

Hmm, not easy. I assumed barebox knows all available memory. What
prevents you from registering all memory? I remember MIPS has a cached
mapping of the SDRAM. Is this the reason?

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: [PATCH] ARM: AM335x: Beaglebone: Fix memory setup for Beaglebone black

[Sascha Hauer]

On Mon, Jun 16, 2014 at 05:13:54PM +0200, Philipp Zabel wrote:
> From: Philipp Zabel <philipp.zabel@gmail.com>
> 
> Commit 0d6392de4ad824a6553c0e3e3e18edef689a7c85 introduced a stripped
> down device tree used for both white and black Beaglebone variants
> that included the 256 MiB memory node from am335x-bone-common.dtsi.
> This leads to the following error in the MLO:
> 
>     mmu: Critical Error: Can't request SDRAM region for ttb at 9fff4000
> 
> This patch removes the (for the Beaglebone black) invalid memory size
> from the common device tree and instead registers the memory bank
> manually in the board file.
> 
> Signed-off-by: Philipp Zabel <philipp.zabel@gmail.com>

Applied, thanks

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: [PATCH] ARM: AM335x: Beaglebone: Fix memory setup for Beaglebone black

[Antony Pavlov]

On Tue, 17 Jun 2014 20:30:40 +0200
Sascha Hauer <s.hauer@pengutronix.de> wrote:

> On Tue, Jun 17, 2014 at 09:35:17AM +0400, Antony Pavlov wrote:
> > On Mon, 16 Jun 2014 23:35:13 +0200
> > Sascha Hauer <s.hauer@pengutronix.de> wrote:
> > 
> > > Hi Antony,
> > > 
> > > On Mon, Jun 16, 2014 at 09:08:59PM +0400, Antony Pavlov wrote:
> > > > On Mon, 16 Jun 2014 17:13:54 +0200
> > > > Philipp Zabel <p.zabel@pengutronix.de> wrote:
> > > > 
> > > > Question to Sascha.
> > > > 
> > > > Can we preserve the 'memory' dts record in situations like this?
> > > > 
> > > > Is it possible just alter dts in early init code?
> > > > Or something else?
> > > 
> > > For what do you want to preserve it? barebox never uses the memory node
> > > directly to pass it to the kernel. The barebox memory banks are
> > > initialized from the code and from the dts. When starting Linux the
> > > memory node is (re)populated with the barebox memory banks
> > > 
> > > I may misunderstand what you are trying to archieve.
> > 
> > Imagine a family of boards. The RAM size can vary from board to board
> > (for simplicity suppose that all over conditions are the same).
> > Suppose I have a reliable RAM size detection routine and I want to run
> > just the same barebox image on different boards.
> > I want to run dts enabled Linux on all boards.
> 
> In this case don't specify the memory size in the devicetree. In a
> mem_initcall detect the actual RAM size you have and call
> arm_add_mem_device() accordingly. That's all. The rest will be handled
> automatically. See of_memory_fixup(), this will iterate over the memory
> banks and set the memory node to the correct values.
> 
> > 
> > How can I handle this situation correctly?
> > 
> > Also note that on MIPS boards barebox uses no more than 256 MiB of RAM
> > (even if a board has more than 256 MiB of RAM). It's a measure to make
> > mips barebox simplier.
> > I want to pass information on all available RAM to linux via dts.
> > Can you describe reasonable barebox behaviour in this situation please?
> 
> Hmm, not easy. I assumed barebox knows all available memory. What
> prevents you from registering all memory? I remember MIPS has a cached
> mapping of the SDRAM. Is this the reason?

But MIPS32 has 4 GB virtual address space.
There are two 512 MiB windows in this VIRTUAL space for direct cached (kseg0)
and uncached (kseg1) access to the first 512 MiB of PHYSICAL space.
As a rule the first 256 MiB piece of PHYSICAL spaces used for RAM and the second
256 MiB piece is used for i/o devices.
So if you use only kseg0 and kseg1 to memory access you can't use more than 256 MiB of RAM.
You can access rest of RAM using another windows (kseg2 and kuseg),
but this windows use MMU.

I don't want to add MMU bussiness to barebox --- 256 MiB of RAM is more than enough.
Of course barebox can know all available memory (even if barebox use only 256 MiB of RAM).

The real problem with mips barebox device tree code is that it operates with VIRTUAL addresses
for memory ranges representation, but linux device tree uses PHYSICAL addresses.

It is my fault and I have to fix it.

-- 
Best regards,
  Antony Pavlov

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox