* NOR memory driver fail with MMU enabled @ 2013-02-06 11:01 Alexander Shiyan 2013-02-06 12:11 ` Sascha Hauer 0 siblings, 1 reply; 5+ messages in thread From: Alexander Shiyan @ 2013-02-06 11:01 UTC (permalink / raw) To: barebox 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: NOR memory driver fail with MMU enabled 2013-02-06 11:01 NOR memory driver fail with MMU enabled Alexander Shiyan @ 2013-02-06 12:11 ` Sascha Hauer 2013-02-06 13:13 ` Re[2]: " Alexander Shiyan 2013-02-07 9:26 ` Alexander Shiyan 0 siblings, 2 replies; 5+ messages in thread From: Sascha Hauer @ 2013-02-06 12:11 UTC (permalink / raw) To: Alexander Shiyan; +Cc: barebox 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re[2]: NOR memory driver fail with MMU enabled 2013-02-06 12:11 ` Sascha Hauer @ 2013-02-06 13:13 ` Alexander Shiyan 2013-02-07 9:26 ` Alexander Shiyan 1 sibling, 0 replies; 5+ messages in thread From: Alexander Shiyan @ 2013-02-06 13:13 UTC (permalink / raw) To: Sascha Hauer; +Cc: barebox ... > > 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re[2]: NOR memory driver fail with MMU enabled 2013-02-06 12:11 ` Sascha Hauer 2013-02-06 13:13 ` Re[2]: " Alexander Shiyan @ 2013-02-07 9:26 ` Alexander Shiyan 2013-02-07 10:02 ` Sascha Hauer 1 sibling, 1 reply; 5+ messages in thread From: Alexander Shiyan @ 2013-02-07 9:26 UTC (permalink / raw) To: Sascha Hauer; +Cc: barebox 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: NOR memory driver fail with MMU enabled 2013-02-07 9:26 ` Alexander Shiyan @ 2013-02-07 10:02 ` Sascha Hauer 0 siblings, 0 replies; 5+ messages in thread From: Sascha Hauer @ 2013-02-07 10:02 UTC (permalink / raw) To: Alexander Shiyan; +Cc: barebox 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2013-02-07 10:02 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2013-02-06 11:01 NOR memory driver fail with MMU enabled Alexander Shiyan 2013-02-06 12:11 ` Sascha Hauer 2013-02-06 13:13 ` Re[2]: " Alexander Shiyan 2013-02-07 9:26 ` Alexander Shiyan 2013-02-07 10:02 ` Sascha Hauer
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox