NOR memory driver fail with MMU enabled

NOR memory driver fail with MMU enabled

[Alexander Shiyan]

Hello.

I have a problem with NOR flash when enabling MMU.
Probably this happen due NOR start address is 0x0.
Should we a remap memory addresses same as we do it for kernel? 
Or can someone tell what could be the problem?
Tnanks!

...
register_device: cfi_flash0
xmalloc c0385f80 (size 592)
request_region ok: 0x00000000:0x01ffffff
xmalloc c03861d8 (size 36)
xmalloc c0386210 (size 4)
flash detect cfi
flash_write_cmd: c0385f80 0 0 => 00000000 0x00f0
flash_write_cmd: c0385f80 0 0 => 00000000 0x00ff
flash_write_cmd: c0385f80 0 55 => 00000055 0x0098
is= cmd 51(Q) addr 00000010 flash_write_cmd: c0385f80 0 555 => 00000555 0x0098
is= cmd 51(Q) addr 00000010 flash_write_cmd: c0385f80 0 0 => 00000000 0xf0f0
fw addr 00000000 val f0f0
unable to handle NULL pointer dereference at address 0x00000000
pc : [<c078932c>]    lr : [<c0789324>]
sp : c07ffe98  ip : c07ff9ae  fp : 00000000
r10: 00000000  r9 : 00000000  r8 : 00000000
r7 : 00000000  r6 : 00000000  r5 : 00000000  r4 : 0000f0f0
r3 : 00000000  r2 : c03804a0  r1 : 0000000a  r0 : 0000001a
Flags: nZCv  IRQs off  FIQs off  Mode SVC_32

no stack data available

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

Re: NOR memory driver fail with MMU enabled

[Sascha Hauer]

On Wed, Feb 06, 2013 at 03:01:38PM +0400, Alexander Shiyan wrote:
> Hello.
> 
> I have a problem with NOR flash when enabling MMU.
> Probably this happen due NOR start address is 0x0.
> Should we a remap memory addresses same as we do it for kernel? 
> Or can someone tell what could be the problem?

This is because the zero page is set to faulting so that you can
catch NULL pointer exceptions. You could disable this (see
vectors_init), but then you can't catch NULL pointer exceptions
anymore. So the best you can do is use map_io_sections and map
your flash to some free region, maybe like this:

map_io_sections(0x0, (void *)SZ_1M, SZ_32M);

Then register your flash flash with address 1M instead of 0x0.

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[2]: NOR memory driver fail with MMU enabled

[Alexander Shiyan]

...
> > I have a problem with NOR flash when enabling MMU.
> > Probably this happen due NOR start address is 0x0.
> > Should we a remap memory addresses same as we do it for kernel? 
> > Or can someone tell what could be the problem?
> 
> This is because the zero page is set to faulting so that you can
> catch NULL pointer exceptions. You could disable this (see
> vectors_init), but then you can't catch NULL pointer exceptions
> anymore. So the best you can do is use map_io_sections and map
> your flash to some free region, maybe like this:
> 
> map_io_sections(0x0, (void *)SZ_1M, SZ_32M);
> 
> Then register your flash flash with address 1M instead of 0x0.

Thanks Sascha, this has helped me.

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

Re[2]: NOR memory driver fail with MMU enabled

[Alexander Shiyan]

Hello.

> > I have a problem with NOR flash when enabling MMU.
> > Probably this happen due NOR start address is 0x0.
> > Should we a remap memory addresses same as we do it for kernel? 
> > Or can someone tell what could be the problem?
> 
> This is because the zero page is set to faulting so that you can
> catch NULL pointer exceptions. You could disable this (see
> vectors_init), but then you can't catch NULL pointer exceptions
> anymore. So the best you can do is use map_io_sections and map
> your flash to some free region, maybe like this:
> 
> map_io_sections(0x0, (void *)SZ_1M, SZ_32M);
> 
> Then register your flash flash with address 1M instead of 0x0.

So, this problem is gone. I found a next one MMU-related problem.
When I turn on option MMU_EARLY, barebox is entered to an endless
loop or die, I am not sure. Probably problem is in "create_sections"
procedure from mmu.c, since I tried to add some debug before this
procedure and we reach this mark, after this procedure we dead.
Can you get me a point for find a solution?
Below is a debug output with CONFIG_MMU_EARLY turned on.

barebox 2013.02.0-00235-g2de8827-dirty #25 Thu Feb 7 12:54:06 MSK 2013


Board: Cirrus Logic CLEP7212
initcall-> 0xc0788518
register_device: platform
initcall-> 0xc079c988
register_device: fs
initcall-> 0xc079e04c
initcall-> 0xc0794264
initcall-> 0xc079c958
xmalloc c0380008 (size 1024)
initcall-> 0xc079e170
initcall-> 0xc07886fc
register_driver: clps711x_serial
initcall-> 0xc079e004
xmalloc c0380410 (size 136)
register_device: clps711x_serial0
xmalloc c03804a0 (size 192)
register_device: cs0
xmalloc c0380568 (size 28)
xmalloc c03805a8 (size 28)
initcall-> 0xc078709c
register_device: global
initcall-> 0xc079dec4
xmalloc c03805e8 (size 24)
request_region ok: 0xc0000000:0xc1ffffff
xmalloc c0380608 (size 36)
xmalloc c0380640 (size 36)
xmalloc c0380678 (size 136)
register_device: mem0
initcall-> 0xc079fd24
request_region ok: 0xc07f4003:0xc07f8002
xmalloc c0380708 (size 36)
mmu: ttb: 0xc07f4003

(nothing more)

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

Re: NOR memory driver fail with MMU enabled

[Sascha Hauer]

On Thu, Feb 07, 2013 at 01:26:05PM +0400, Alexander Shiyan wrote:
> Hello.
> 
> > > I have a problem with NOR flash when enabling MMU.
> > > Probably this happen due NOR start address is 0x0.
> > > Should we a remap memory addresses same as we do it for kernel? 
> > > Or can someone tell what could be the problem?
> > 
> > This is because the zero page is set to faulting so that you can
> > catch NULL pointer exceptions. You could disable this (see
> > vectors_init), but then you can't catch NULL pointer exceptions
> > anymore. So the best you can do is use map_io_sections and map
> > your flash to some free region, maybe like this:
> > 
> > map_io_sections(0x0, (void *)SZ_1M, SZ_32M);
> > 
> > Then register your flash flash with address 1M instead of 0x0.
> 
> So, this problem is gone. I found a next one MMU-related problem.
> When I turn on option MMU_EARLY, barebox is entered to an endless
> loop or die, I am not sure. Probably problem is in "create_sections"
> procedure from mmu.c, since I tried to add some debug before this
> procedure and we reach this mark, after this procedure we dead.
> Can you get me a point for find a solution?
> Below is a debug output with CONFIG_MMU_EARLY turned on.
> 
> barebox 2013.02.0-00235-g2de8827-dirty #25 Thu Feb 7 12:54:06 MSK 2013
> 
> 
> Board: Cirrus Logic CLEP7212
> initcall-> 0xc0788518
> register_device: platform
> initcall-> 0xc079c988
> register_device: fs
> initcall-> 0xc079e04c
> initcall-> 0xc0794264
> initcall-> 0xc079c958
> xmalloc c0380008 (size 1024)
> initcall-> 0xc079e170
> initcall-> 0xc07886fc
> register_driver: clps711x_serial
> initcall-> 0xc079e004
> xmalloc c0380410 (size 136)
> register_device: clps711x_serial0
> xmalloc c03804a0 (size 192)
> register_device: cs0
> xmalloc c0380568 (size 28)
> xmalloc c03805a8 (size 28)
> initcall-> 0xc078709c
> register_device: global
> initcall-> 0xc079dec4
> xmalloc c03805e8 (size 24)
> request_region ok: 0xc0000000:0xc1ffffff
> xmalloc c0380608 (size 36)
> xmalloc c0380640 (size 36)
> xmalloc c0380678 (size 136)
> register_device: mem0
> initcall-> 0xc079fd24
> request_region ok: 0xc07f4003:0xc07f8002
> xmalloc c0380708 (size 36)
> mmu: ttb: 0xc07f4003

ttb shouldn't be unaligned. Whatever the reason for that is it won't
work. The ARM-ARM has this:

> Reading from CP15 register 2 returns the physical address of the
> currently active first-level translation table in bits[31:14] and an
> UNPREDICTABLE value in bits[13:0]. The CRm and opcode2 fields are
> ignored when reading CP15 register 2 and should be zero.  Writing to
> CP15 register 2 updates the physical address of the currently active
> first-level translation table from the value in bits[31:14] of the
> written value. Bits[13:0] must be written as zero or as a value
> previously read from bits[13:0] of this register. The CRm and opcode2
> fields are ignored when writing CP15 register 2 and should be zero.

It seems we have to mask out bits[13:0] from the ttb. Appearantly these
were zero on the boards I tested this.

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