mail archive of the barebox mailing list
 help / color / mirror / Atom feed
* imx53 memory detection
@ 2016-04-13  5:08 Jason Cobham
  2016-04-13  6:36 ` Sascha Hauer
  0 siblings, 1 reply; 4+ messages in thread
From: Jason Cobham @ 2016-04-13  5:08 UTC (permalink / raw)
  To: barebox

Support for Barebox on the Digi connectcore imx53 board stopped
working recently. I believe the memory detection never worked properly
to begin with. I've re-factored lowlevel.c to match similar mx53
boards, however the ram size is always detected incorrectly. I have a
reliable way of detecting the board memory size in device_initcall.

I've tried adding mem_initcall/arm_add_mem_device() however mmu
support causes a panic when enabled. without mmu support enabled, the
board boots with the correct memory size however I get an error,
"Cannot request SDRAM region for stack".

I've tried to use the freescale loco/qsb as a template since the digi
board is similar, but I don't see where it's memory size is defined. I
assume it's automatically detected.

If my board can't be automatically detected, what's a typical way to
setup memory on this type of board?

Thanks,
Jason

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

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: imx53 memory detection
  2016-04-13  5:08 imx53 memory detection Jason Cobham
@ 2016-04-13  6:36 ` Sascha Hauer
  2016-04-14  4:38   ` Jason Cobham
  0 siblings, 1 reply; 4+ messages in thread
From: Sascha Hauer @ 2016-04-13  6:36 UTC (permalink / raw)
  To: Jason Cobham; +Cc: barebox

Hi Jason,

On Tue, Apr 12, 2016 at 10:08:01PM -0700, Jason Cobham wrote:
> Support for Barebox on the Digi connectcore imx53 board stopped
> working recently. I believe the memory detection never worked properly
> to begin with. I've re-factored lowlevel.c to match similar mx53
> boards, however the ram size is always detected incorrectly.

So you replaced barebox_arm_entry with imx53_barebox_entry, right? What
memory size do you have and what size gets detected then?

> I have a
> reliable way of detecting the board memory size in device_initcall.
> 
> I've tried adding mem_initcall/arm_add_mem_device() however mmu
> support causes a panic when enabled. without mmu support enabled, the
> board boots with the correct memory size however I get an error,
> "Cannot request SDRAM region for stack".
> 
> I've tried to use the freescale loco/qsb as a template since the digi
> board is similar, but I don't see where it's memory size is defined. I
> assume it's automatically detected.

Yes, it's read back from the memory controller in arch/arm/mach-imx/esdctl.c.

The whole approach goes like this:

- The SDRAM controller is configured by board specific lowlevel code (or
  DCD data)
- barebox_arm_entry() is called with some memory passed to it. This can be
  the full memory of the board, but doesn't necessarily have to be. It
  is only the memory barebox will use for itself, stack, malloc area.
  imx53_barebox_entry() is a shortcut which reads back the SDRAM
  controller settings to automatically detect SDRAM size and which calls
  barebox_arm_entry() with the result.
- during mem_initcall the imx-esdctl driver is registered. This driver
  again reads back the SDRAM controller settings and registers memory
  banks according to the settings.
- Also during mem_initcall the memory areas specified in the device tree
  are registered.

If there are conflicts between the different banks then the first one
wins. If then the MMU code later detects that the SDRAM passed to
barebox_arm_entry() is actually bigger than the memory registered in the
memory banks it can have undesired results.


As a first step you should remove the /memory node in
arch/arm/dts/imx53-ccxmx53.dtsi. Since there are different possible
memory setups for this board it is wrong anyway. Then it would be
interesting what imx_esdctl_v4_add_mem() detects. I believe it should be
possible to fix it if it detects the wrong memory size.

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

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: imx53 memory detection
  2016-04-13  6:36 ` Sascha Hauer
@ 2016-04-14  4:38   ` Jason Cobham
  2016-04-14  6:54     ` Sascha Hauer
  0 siblings, 1 reply; 4+ messages in thread
From: Jason Cobham @ 2016-04-14  4:38 UTC (permalink / raw)
  To: Sascha Hauer; +Cc: barebox

Hi Sascha,

Thanks for the quick reply.

> So you replaced barebox_arm_entry with imx53_barebox_entry, right? What
> memory size do you have and what size gets detected then?

Yes, I used imx53_barebox_entry. I have two boards, 512MB/1G. In
further testing, I found the 512MB board was detected correctly, and
the 1G board was detected at 2G.

...

> As a first step you should remove the /memory node in
> arch/arm/dts/imx53-ccxmx53.dtsi. Since there are different possible
> memory setups for this board it is wrong anyway. Then it would be
> interesting what imx_esdctl_v4_add_mem() detects. I believe it should be
> possible to fix it if it detects the wrong memory size.

For the 1G board, I removed the memory node and looked into
imx_esdctl_v4_add_mem(). I found:
add_mem: cs0 base: 0x70000000 cs0 size: 0x40000000
add_mem: cs1 base: 0xb0000000 cs1 size: 0x40000000

Going further into it, I found in the imx_v4_sdram_size() read the
following from the esdctl registers:
ctlval:0xc4110000, esdmisc:0xc00016d0 which is set from the
appropriate flash-header file.

The ram populated on the 1G board is MT47H128M16 – 128 Meg x 16 (16
Meg x 16 x 8 banks).
Comparing the register setting against the datasheet for the ram chips
looks like there was a mistake in the row setting of the 1G
flash-header. After updating it to what I believe is correct setting:
(ctlval:0xc3110000, esdmisc:0xc00016d0), the memory is now detected
correctly.

Unless you see any Issue with my findings, I'll go with this fix.


Thanks,

Jason

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

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: imx53 memory detection
  2016-04-14  4:38   ` Jason Cobham
@ 2016-04-14  6:54     ` Sascha Hauer
  0 siblings, 0 replies; 4+ messages in thread
From: Sascha Hauer @ 2016-04-14  6:54 UTC (permalink / raw)
  To: Jason Cobham; +Cc: barebox

On Wed, Apr 13, 2016 at 09:38:35PM -0700, Jason Cobham wrote:
> Hi Sascha,
> 
> Thanks for the quick reply.
> 
> > So you replaced barebox_arm_entry with imx53_barebox_entry, right? What
> > memory size do you have and what size gets detected then?
> 
> Yes, I used imx53_barebox_entry. I have two boards, 512MB/1G. In
> further testing, I found the 512MB board was detected correctly, and
> the 1G board was detected at 2G.
> 
> ...
> 
> > As a first step you should remove the /memory node in
> > arch/arm/dts/imx53-ccxmx53.dtsi. Since there are different possible
> > memory setups for this board it is wrong anyway. Then it would be
> > interesting what imx_esdctl_v4_add_mem() detects. I believe it should be
> > possible to fix it if it detects the wrong memory size.
> 
> For the 1G board, I removed the memory node and looked into
> imx_esdctl_v4_add_mem(). I found:
> add_mem: cs0 base: 0x70000000 cs0 size: 0x40000000
> add_mem: cs1 base: 0xb0000000 cs1 size: 0x40000000
> 
> Going further into it, I found in the imx_v4_sdram_size() read the
> following from the esdctl registers:
> ctlval:0xc4110000, esdmisc:0xc00016d0 which is set from the
> appropriate flash-header file.
> 
> The ram populated on the 1G board is MT47H128M16 – 128 Meg x 16 (16
> Meg x 16 x 8 banks).
> Comparing the register setting against the datasheet for the ram chips
> looks like there was a mistake in the row setting of the 1G
> flash-header. After updating it to what I believe is correct setting:
> (ctlval:0xc3110000, esdmisc:0xc00016d0), the memory is now detected
> correctly.

So you say that the flash header sets up memory of twice the actual size
which then misleads the detection code? Then this is worth fixing, also
the /memory node should be removed. Care to send patches for this?

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

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2016-04-14  6:55 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-04-13  5:08 imx53 memory detection Jason Cobham
2016-04-13  6:36 ` Sascha Hauer
2016-04-14  4:38   ` Jason Cobham
2016-04-14  6:54     ` Sascha Hauer

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox