[U-Boot,1/3] Revert "i.MX28: Enable additional DRAM address bits"

This reverts commit 69d26d09de1cb93e0a09ca71d9f0d41a66f0756a.

Apparently, this commit got mainline only because of OOT port and causes
breakage on board that is mainline. Revert.

Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Wolfgang Denk <wd@denx.de>
Cc: Detlev Zundel <dzu@denx.de>
Cc: Stefano Babic <sbabic@denx.de>
Cc: Fabio Estevam <festevam@gmail.com>
---
 arch/arm/cpu/arm926ejs/mx28/spl_mem_init.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Hi Marek,

> This reverts commit 69d26d09de1cb93e0a09ca71d9f0d41a66f0756a.
>
> Apparently, this commit got mainline only because of OOT port and causes
> breakage on board that is mainline. Revert.

To be honest, I don't understand what this patch or what the original
patch did, nor through what OOT port this hit mainline and what breakage
it causes on other boards.

So also I can read the sentence, I cannot make heads and tails of it.
Can you please write commit messages that people like me can make some
sense from?  I.e. answering the following questions would help me

- What does the original commit do? (its too late to change the original
  commit) 
- Why was the change made in the first place and for what OOT port?
- What breakage is caused on what boards?
- Why can we revert the change without any problems?

Thanks
  Detlev

Dear Detlev Zundel,

> Hi Marek,
> 
> > This reverts commit 69d26d09de1cb93e0a09ca71d9f0d41a66f0756a.
> > 
> > Apparently, this commit got mainline only because of OOT port and causes
> > breakage on board that is mainline. Revert.
> 
> To be honest, I don't understand what this patch or what the original
> patch did, nor through what OOT port this hit mainline and what breakage
> it causes on other boards.

It enabled some additional address bits on X board, allowing it to use full 
512MB of RAM. But because we don't have any other such configured board and X 
board isn't mainline, I reverted this patch. It caused trouble on new 256MB 
configuration of M28.

Once there'll be some module that needs different memory configuration (like X 
board) mainline, we'll add this here, but until then, I'd like to stick with 
common memory init.

> 
> So also I can read the sentence, I cannot make heads and tails of it.
> Can you please write commit messages that people like me can make some
> sense from?  I.e. answering the following questions would help me
> 
> - What does the original commit do? (its too late to change the original
>   commit)

Enabled additional address bits, to address full 512 MB of DRAM on the X board.

> - Why was the change made in the first place and for what OOT port?

Change of a DRAM configuration register that enabled additional address bit, at 
address 512MB of DRAM. Though this caused memory hole on our M28 module with 
256MB of DRAM, which _is_ mainline. X board is OOT and never will be mainlined I 
guess.

> - What breakage is caused on what boards?

See above.

> - Why can we revert the change without any problems?

Because we don't have any mainline port that used this feature.

> 
> Thanks
>   Detlev

Best regards,
Marek Vasut

Hi Marek,

[...]

>> - Why was the change made in the first place and for what OOT port?
>
> Change of a DRAM configuration register that enabled additional
> address bit, at address 512MB of DRAM. Though this caused memory hole
> on our M28 module with 256MB of DRAM, which _is_ mainline. X board is
> OOT and never will be mainlined I guess.

I still do not understand this fully.  What exactly is this "memory
hole" and why is it fatal?  As far as I can remember, there are always
some holes in the adress map, so why is this special?

Apart from that, I think most of these answers should go into the commit
message to understand what is happening.

Thanks in advance
  Detlev

Dear Detlev Zundel,

> Hi Marek,
> 
> [...]
> 
> >> - Why was the change made in the first place and for what OOT port?
> > 
> > Change of a DRAM configuration register that enabled additional
> > address bit, at address 512MB of DRAM. Though this caused memory hole
> > on our M28 module with 256MB of DRAM, which _is_ mainline. X board is
> > OOT and never will be mainlined I guess.
> 
> I still do not understand this fully.  What exactly is this "memory
> hole" and why is it fatal?  As far as I can remember, there are always
> some holes in the adress map, so why is this special?

No, this one created this layout on our 256 MB module:

[chunk of memory][<- same thing][chunk of memory][<- same thing]

so get_ram_size() didn't work with it and it actually overwrote part of the U-
Boot etc.

> 
> Apart from that, I think most of these answers should go into the commit
> message to understand what is happening.

Agreed

> Thanks in advance
>   Detlev

Best regards,
Marek Vasut

Hi Marek,

> Dear Detlev Zundel,
>
>> Hi Marek,
>> 
>> [...]
>> 
>> >> - Why was the change made in the first place and for what OOT port?
>> > 
>> > Change of a DRAM configuration register that enabled additional
>> > address bit, at address 512MB of DRAM. Though this caused memory hole
>> > on our M28 module with 256MB of DRAM, which _is_ mainline. X board is
>> > OOT and never will be mainlined I guess.
>> 
>> I still do not understand this fully.  What exactly is this "memory
>> hole" and why is it fatal?  As far as I can remember, there are always
>> some holes in the adress map, so why is this special?
>
> No, this one created this layout on our 256 MB module:
>
> [chunk of memory][<- same thing][chunk of memory][<- same thing]
>
> so get_ram_size() didn't work with it and it actually overwrote part
> of the U-
> Boot etc.

Ah, so it created what I would call a "memory mirroring" or "memory
aliasing", right?  Now I understand the problem, thanks.

Cheers
  Detlev