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