ARM, MMU and IO space mapping

ARM, MMU and IO space mapping

[Robert Jarzmik]

Hi,

I was wandering in the MMU arm implementation and I'm wondering if anybody is
using it and accessing some IO mapped space.

My trouble is that mmu_init() only maps the RAM space (and with cacheable memory
type). For the PXA, I would need a non-cacheable non-bufferable memory type,
which could be allocated either :
 - through dev_request_mem_region(), which would be amended for the MMU case
 - or through a dedicated ioremap() function, which will be empty in no MMU case

The current issue I'm facing is that when I launch barebox with MMU enabled, the
UDC device doesn't work (I presume because the IO space is not mapped into the
MMU). This prevents me from using barebox in MMU context (and therefore I have
no D-Cache).

Would the evolution of dev_request_mem_region() be acceptable, or should I
consider another way ?

Cheers.

-- 
Robert

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

Re: ARM, MMU and IO space mapping

[Sascha Hauer]

On Thu, Nov 24, 2011 at 12:24:55PM +0100, Robert Jarzmik wrote:
> Hi,
> 
> I was wandering in the MMU arm implementation and I'm wondering if anybody is
> using it and accessing some IO mapped space.
> 
> My trouble is that mmu_init() only maps the RAM space (and with cacheable memory
> type). For the PXA, I would need a non-cacheable non-bufferable memory type,
> which could be allocated either :
>  - through dev_request_mem_region(), which would be amended for the MMU case
>  - or through a dedicated ioremap() function, which will be empty in no MMU case
> 
> The current issue I'm facing is that when I launch barebox with MMU enabled, the
> UDC device doesn't work (I presume because the IO space is not mapped into the
> MMU). This prevents me from using barebox in MMU context (and therefore I have
> no D-Cache).
> 
> Would the evolution of dev_request_mem_region() be acceptable, or should I
> consider another way ?

The generic arm code sets up a flat 1:1 noncached mapping. Then it
remaps the SDRAM cacheable/bufferable. So a normal driver can just
access the registers without worrying about ioremap() since they are
outside of the SDRAM. What you need in your udc driver is either
dma_alloc_coherent which allocates a chunk of SDRAM and remaps it
uncacheable/unbufferable or you have to sync manually using
dma_clean_range/dma_flush_range. See drivers/usb/gadget/fsl_udc.c or
drivers/net/fec_imx.c for examples.

I remember Marc had some trouble with the mmu/cache implementation on
PXA. I don't know the details though. Maybe you have to dig through
the manuals/kernel code to find out the differences between the normal
arm v5 and pxa.

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: ARM, MMU and IO space mapping

[Marc Kleine-Budde]

[-- Attachment #1.1: Type: text/plain, Size: 2265 bytes --]

On 11/24/2011 01:04 PM, Sascha Hauer wrote:
> On Thu, Nov 24, 2011 at 12:24:55PM +0100, Robert Jarzmik wrote:
>> Hi,
>>
>> I was wandering in the MMU arm implementation and I'm wondering if anybody is
>> using it and accessing some IO mapped space.
>>
>> My trouble is that mmu_init() only maps the RAM space (and with cacheable memory
>> type). For the PXA, I would need a non-cacheable non-bufferable memory type,
>> which could be allocated either :
>>  - through dev_request_mem_region(), which would be amended for the MMU case
>>  - or through a dedicated ioremap() function, which will be empty in no MMU case
>>
>> The current issue I'm facing is that when I launch barebox with MMU enabled, the
>> UDC device doesn't work (I presume because the IO space is not mapped into the
>> MMU). This prevents me from using barebox in MMU context (and therefore I have
>> no D-Cache).
>>
>> Would the evolution of dev_request_mem_region() be acceptable, or should I
>> consider another way ?
> 
> The generic arm code sets up a flat 1:1 noncached mapping. Then it
> remaps the SDRAM cacheable/bufferable. So a normal driver can just
> access the registers without worrying about ioremap() since they are
> outside of the SDRAM. What you need in your udc driver is either
> dma_alloc_coherent which allocates a chunk of SDRAM and remaps it
> uncacheable/unbufferable or you have to sync manually using
> dma_clean_range/dma_flush_range. See drivers/usb/gadget/fsl_udc.c or
> drivers/net/fec_imx.c for examples.
> 
> I remember Marc had some trouble with the mmu/cache implementation on
> PXA. I don't know the details though. Maybe you have to dig through
> the manuals/kernel code to find out the differences between the normal
> arm v5 and pxa.

I had some troubles with the cache setup, but it was before Sascha fixed
a problem with the v5 chache handling. IIRC loading the environment form
NOR sometimes failed with enabled caches.

cheers, Marc

-- 
Pengutronix e.K.                  | Marc Kleine-Budde           |
Industrial Linux Solutions        | Phone: +49-231-2826-924     |
Vertretung West/Dortmund          | Fax:   +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686  | http://www.pengutronix.de   |


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

[-- Attachment #2: Type: text/plain, Size: 149 bytes --]

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

Re: ARM, MMU and IO space mapping

[Robert Jarzmik]

Sascha Hauer <s.hauer@pengutronix.de> writes:
> I remember Marc had some trouble with the mmu/cache implementation on
> PXA. I don't know the details though. Maybe you have to dig through
> the manuals/kernel code to find out the differences between the normal
> arm v5 and pxa.

Ah, I know what happens now, and it's tricky.
First of all, you're right, there's a flat uncached mapping, I was misled by
the function name "create_section", without looking closely at it. I thought
it created the first section, not all the 4096 1MBytes section of a 4GB
address space.
It would deserve a "create_sections" name, in plural form.

Now, for the serial UDC not working, there comes the fun.
What's happening is that I'm using a default environment, with the init
script in [1]. This script has an error somewhere.
In barebox_startup(), we have :
   if (!stat("/env/bin/init", &s)) {
      run_command("source /env/bin/init", 0);

And here is the trickery:
 - in the NOMMU case, the run_command() returns, and the code continues to the
   eternal loop of run_shell(), which calls console.getc(), which calls
   poller(), which call the UDC poll method
   => the gadget does work
   => I have a console, hurray !

 - in the MMU case, the run_command() never returns, and the poller method is
   never called. I traced that with my leds.
   => the gadget does *not* work

So the problem was not the IO mapping, but a difference in run_command() between
MMU and non-MMU config. Moreover, in non-MMU case, once my console is connected,
I see a message :
> running /env/bin/init...
> syntax error
I the MMU case, as the gadget doesn't work, I'm blind, so I can't really tell
what is happening and which is the impact of MMU over run_command()...

Cheers.

--
Robert

[1] Script:
#!/bin/sh

#led orange 1

PATH=/env/bin
export PATH

. /env/config

while [ -z $toto ]; do
    led orange 1
    readline "Give me a word" word
    echo "I've got your $word"
done

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

Re: ARM, MMU and IO space mapping

[Marc Kleine-Budde]

[-- Attachment #1.1: Type: text/plain, Size: 2485 bytes --]

On 11/24/2011 09:09 PM, Robert Jarzmik wrote:
> Sascha Hauer <s.hauer@pengutronix.de> writes:
>> I remember Marc had some trouble with the mmu/cache implementation on
>> PXA. I don't know the details though. Maybe you have to dig through
>> the manuals/kernel code to find out the differences between the normal
>> arm v5 and pxa.
> 
> Ah, I know what happens now, and it's tricky.
> First of all, you're right, there's a flat uncached mapping, I was misled by
> the function name "create_section", without looking closely at it. I thought
> it created the first section, not all the 4096 1MBytes section of a 4GB
> address space.
> It would deserve a "create_sections" name, in plural form.
> 
> Now, for the serial UDC not working, there comes the fun.
> What's happening is that I'm using a default environment, with the init
> script in [1]. This script has an error somewhere.
> In barebox_startup(), we have :
>    if (!stat("/env/bin/init", &s)) {
>       run_command("source /env/bin/init", 0);
> 
> And here is the trickery:
>  - in the NOMMU case, the run_command() returns, and the code continues to the
>    eternal loop of run_shell(), which calls console.getc(), which calls
>    poller(), which call the UDC poll method
>    => the gadget does work
>    => I have a console, hurray !
> 
>  - in the MMU case, the run_command() never returns, and the poller method is
>    never called. I traced that with my leds.
>    => the gadget does *not* work
> 
> So the problem was not the IO mapping, but a difference in run_command() between
> MMU and non-MMU config. Moreover, in non-MMU case, once my console is connected,
> I see a message :
>> running /env/bin/init...
>> syntax error
> I the MMU case, as the gadget doesn't work, I'm blind, so I can't really tell
> what is happening and which is the impact of MMU over run_command()...

As I said in my other mail, we had problems with the MMU turned on.
There is one patch fiddeling with the armv5 vs armv4 cache code, but
this is all very fragile. As Sascha pointed out, someone should have a
look at the kernel and figure out what are the differences between armv5
and an pxa270.

cheers, Marc

-- 
Pengutronix e.K.                  | Marc Kleine-Budde           |
Industrial Linux Solutions        | Phone: +49-231-2826-924     |
Vertretung West/Dortmund          | Fax:   +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686  | http://www.pengutronix.de   |


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

[-- Attachment #2: Type: text/plain, Size: 149 bytes --]

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

Re: ARM, MMU and IO space mapping

[Sascha Hauer]

On Thu, Nov 24, 2011 at 09:09:38PM +0100, Robert Jarzmik wrote:
> Sascha Hauer <s.hauer@pengutronix.de> writes:
> > I remember Marc had some trouble with the mmu/cache implementation on
> > PXA. I don't know the details though. Maybe you have to dig through
> > the manuals/kernel code to find out the differences between the normal
> > arm v5 and pxa.
> 
> Ah, I know what happens now, and it's tricky.
> First of all, you're right, there's a flat uncached mapping, I was misled by
> the function name "create_section", without looking closely at it. I thought
> it created the first section, not all the 4096 1MBytes section of a 4GB
> address space.
> It would deserve a "create_sections" name, in plural form.

Agreed.

> 
> Now, for the serial UDC not working, there comes the fun.
> What's happening is that I'm using a default environment, with the init
> script in [1]. This script has an error somewhere.
> In barebox_startup(), we have :
>    if (!stat("/env/bin/init", &s)) {
>       run_command("source /env/bin/init", 0);
> 
> And here is the trickery:
>  - in the NOMMU case, the run_command() returns, and the code continues to the
>    eternal loop of run_shell(), which calls console.getc(), which calls
>    poller(), which call the UDC poll method
>    => the gadget does work
>    => I have a console, hurray !
> 
>  - in the MMU case, the run_command() never returns, and the poller method is
>    never called. I traced that with my leds.
>    => the gadget does *not* work
> 
> So the problem was not the IO mapping, but a difference in run_command() between
> MMU and non-MMU config. Moreover, in non-MMU case, once my console is connected,
> I see a message :
> > running /env/bin/init...
> > syntax error
> I the MMU case, as the gadget doesn't work, I'm blind, so I can't really tell
> what is happening and which is the impact of MMU over run_command()...

Hmmm...

I just made your patches work on my pcm027 board (If you haven't fixed
the serial driver already: now I have patches for this). Without MMU
everything is fine. With MMU I had to disable the zero page because
otherwise the cfi flash driver will bail out with a NULL pointer deref.
With this I noticed that when I start barebox from U-Boot that the
driver does not recognize the flash. The following code from
arch/arm/boot/compressed/head-xscale.S helped:

		@ Preserve r8/r7 i.e. kernel entry values

		@ Data cache might be active.
		@ Be sure to flush kernel binary out of the cache,
		@ whatever state it is, before it is turned off.
		@ This is done by fetching through currently executed
		@ memory to be sure we hit the same cache.
		bic	r2, pc, #0x1f
		add	r3, r2, #0x10000	@ 64 kb is quite enough...
1:		ldr	r0, [r2], #32
		teq	r2, r3
		bne	1b
		mcr	p15, 0, r0, c7, c10, 4	@ drain WB
		mcr	p15, 0, r0, c7, c7, 0	@ flush I & D caches

		@ disabling MMU and caches
		mrc	p15, 0, r0, c1, c0, 0	@ read control reg
		bic	r0, r0, #0x05		@ clear DC, MMU
		bic	r0, r0, #0x1000		@ clear Icache
		mcr	p15, 0, r0, c1, c0, 0

I don't know what's going on here.

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: ARM, MMU and IO space mapping

[Robert Jarzmik]

Sascha Hauer <s.hauer@pengutronix.de> writes:

> Hmmm...
>
> I just made your patches work on my pcm027 board (If you haven't fixed
> the serial driver already: now I have patches for this). Without MMU
> everything is fine. With MMU I had to disable the zero page because
> otherwise the cfi flash driver will bail out with a NULL pointer deref.
> With this I noticed that when I start barebox from U-Boot that the
> driver does not recognize the flash.

I don't understand how that works. As the zero page is remapped onto the vectors
memory, how can a driver access the NOR chip ?

My understanding is that barebox makes a flat 1:1 mapping, and then replaces
the first section with a 2 levels translation, where :
 - the first 4096 bytes are mapped onto the malloc'd vectors
 - the remaining 1MBytes-4096Bytes are still in a flat 1:1 mapping

If that is correct, you loose your ability to access address space 0x00000000 -
0x00001000. How can you use the CFI after that ?

And as a consequence, I'm a bit afraid that my disk-on-chip, having it's memory
mapped to 0x0 - 0x2000, will be difficult to convert ... I must think of a way
in there.

> 		@ Data cache might be active.
> 		@ Be sure to flush kernel binary out of the cache,
> 		@ whatever state it is, before it is turned off.
> 		@ This is done by fetching through currently executed
> 		@ memory to be sure we hit the same cache.
> 		bic	r2, pc, #0x1f
> 		add	r3, r2, #0x10000	@ 64 kb is quite enough...
> 1:		ldr	r0, [r2], #32
> 		teq	r2, r3
> 		bne	1b
> 		mcr	p15, 0, r0, c7, c10, 4	@ drain WB
> 		mcr	p15, 0, r0, c7, c7, 0	@ flush I & D caches
>
> 		@ disabling MMU and caches
> 		mrc	p15, 0, r0, c1, c0, 0	@ read control reg
> 		bic	r0, r0, #0x05		@ clear DC, MMU
> 		bic	r0, r0, #0x1000		@ clear Icache
> 		mcr	p15, 0, r0, c1, c0, 0
>
> I don't know what's going on here.

I don't know either. All I see is that the datacache is filled so that stale
values are flushed out, and then it's flushed again through normal coproc
operations.
Note that there's an erratum in the XScale series that says that turning off the
cache leaves "dirty bits" set, and reenabling it later might cause havoc. That
would be a good reason for UBoot the read the 64kb before turning off the MMU,
wouldn't it ?

Moreover, another erratum says that the "mcr" disabling the MMU should be in the
first word of a cache line. If not, the ARM core _could_ be hung depending on
timings ... Errata are such fun :)

-- 
Robert

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

Re: ARM, MMU and IO space mapping

[Sascha Hauer]

On Sun, Nov 27, 2011 at 11:30:48PM +0100, Robert Jarzmik wrote:
> Sascha Hauer <s.hauer@pengutronix.de> writes:
> 
> > Hmmm...
> >
> > I just made your patches work on my pcm027 board (If you haven't fixed
> > the serial driver already: now I have patches for this). Without MMU
> > everything is fine. With MMU I had to disable the zero page because
> > otherwise the cfi flash driver will bail out with a NULL pointer deref.
> > With this I noticed that when I start barebox from U-Boot that the
> > driver does not recognize the flash.
> 
> I don't understand how that works. As the zero page is remapped onto the vectors
> memory, how can a driver access the NOR chip ?
> 
> My understanding is that barebox makes a flat 1:1 mapping, and then replaces
> the first section with a 2 levels translation, where :
>  - the first 4096 bytes are mapped onto the malloc'd vectors
>  - the remaining 1MBytes-4096Bytes are still in a flat 1:1 mapping
> 
> If that is correct, you loose your ability to access address space 0x00000000 -
> 0x00001000. How can you use the CFI after that ?

That's why I had to disable this mapping. Most other SoCs do not have
flash on 0x0. The i.MX processors for example have their internal ROM
there.

> 
> And as a consequence, I'm a bit afraid that my disk-on-chip, having it's memory
> mapped to 0x0 - 0x2000, will be difficult to convert ... I must think of a way
> in there.

Your options are:

- Add some switch to disable the 0x0 mapping.
- Add ioremap support.

I think we should go for the former for now. Real ioremap support
requires more thinking about how we want to do it. Will all drivers have
to do it or only the cfi driver?

> 
> > 		@ Data cache might be active.
> > 		@ Be sure to flush kernel binary out of the cache,
> > 		@ whatever state it is, before it is turned off.
> > 		@ This is done by fetching through currently executed
> > 		@ memory to be sure we hit the same cache.
> > 		bic	r2, pc, #0x1f
> > 		add	r3, r2, #0x10000	@ 64 kb is quite enough...
> > 1:		ldr	r0, [r2], #32
> > 		teq	r2, r3
> > 		bne	1b
> > 		mcr	p15, 0, r0, c7, c10, 4	@ drain WB
> > 		mcr	p15, 0, r0, c7, c7, 0	@ flush I & D caches
> >
> > 		@ disabling MMU and caches
> > 		mrc	p15, 0, r0, c1, c0, 0	@ read control reg
> > 		bic	r0, r0, #0x05		@ clear DC, MMU
> > 		bic	r0, r0, #0x1000		@ clear Icache
> > 		mcr	p15, 0, r0, c1, c0, 0
> >
> > I don't know what's going on here.
> 
> I don't know either. All I see is that the datacache is filled so that stale
> values are flushed out, and then it's flushed again through normal coproc
> operations.
> Note that there's an erratum in the XScale series that says that turning off the
> cache leaves "dirty bits" set, and reenabling it later might cause havoc. That
> would be a good reason for UBoot the read the 64kb before turning off the MMU,
> wouldn't it ?

Yes, it would. Does your first stage loader use the MMU?

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: ARM, MMU and IO space mapping

[Robert Jarzmik]

Sascha Hauer <s.hauer@pengutronix.de> writes:

> That's why I had to disable this mapping. Most other SoCs do not have
> flash on 0x0. The i.MX processors for example have their internal ROM
> there.
Ah, I see.

>> And as a consequence, I'm a bit afraid that my disk-on-chip, having it's memory
>> mapped to 0x0 - 0x2000, will be difficult to convert ... I must think of a way
>> in there.
>
> Your options are:
>
> - Add some switch to disable the 0x0 mapping.
> - Add ioremap support.
>
> I think we should go for the former for now. Real ioremap support
> requires more thinking about how we want to do it. Will all drivers have
> to do it or only the cfi driver?
I think that only cfi and disk-on-chips drivers will have that problem, as being
mapped (from an memory bus address POV) to address 0 is bound to boot code,
which relies on some kind of memory (ROM, flash, ...).

And disabling 0x0 mapping will make the MMU booting quite fragile IMHO.
Consider the following example:
 - a flash/ROM is mapped at address 0 for booting the ARM SoC
 - as requested by ARM, the first words of the flash are the vectors, with the
 first one being the reset vector into a code that is supposed to run in a
 *non-MMU* context
 - the ARM core starts, and IPL is loaded
 - IPL loads SPL (barebox)
 - barebox remaps 0x0 to vectors at malloc'd 0xa0003f00 (former solution)
 - barebox switches into MMU on
 - a bug happens in barebox (urgh!!!) and the exception vector is triggered
 ===> here, the flash/ROM vector is used
 ===> this vectors assumes running from MMU-disabled environment
 - the code running in the IPL triggers an exception because it's in MMU
 environment
  => eternal cycle begins

I think either :
 - we implement ioremap
 - or we forbid (on ARM) MMU with board requiring 0x0 iomapped device

I would prefer a simple ioremap solution of the like:
 - a mach-XXX declares an adress-space for io-remapping (contiguous, section
 aligned and of size multiple of 1MBytes)
   => if not => MMU config is not possible
             => ioremap() gives back the flat physical address
   => if yes => MMU config is possible
             => ioremap() gives back an entry in io-remapping address space
 - ioremap() is embedded in dev_request_mem_region()

What do you think ?

>> I don't know either. All I see is that the datacache is filled so that stale
>> values are flushed out, and then it's flushed again through normal coproc
>> operations.
>> Note that there's an erratum in the XScale series that says that turning off the
>> cache leaves "dirty bits" set, and reenabling it later might cause havoc. That
>> would be a good reason for UBoot the read the 64kb before turning off the MMU,
>> wouldn't it ?
>
> Yes, it would. Does your first stage loader use the MMU?
Well, when barebox is stable enough for me, no.
For now, the answer will be yes, as barebox will be the TPL:
 - IPL load SPL, which is a proprietary bootloader
   => IPL runs in non-MMU mode
 - SPL loads the TPL (third program loader), which is barebox
   => SPL uses MMU
I need the IPL/SPL/TPL, as if there is any problem with barebox, the current SPL
is stable and will enable me to reflash the TPL (ie. barebox). I have no JTAG
access by now to my board, so I cannot afford loosing the security of the SPL.

When my barebox will be stable enough, and I'll be bold enough, I'll replace the
SPL with barebox :)

Cheers.

-- 
Robert

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

Re: ARM, MMU and IO space mapping

[Sascha Hauer]

On Mon, Nov 28, 2011 at 06:43:06PM +0100, Robert Jarzmik wrote:
> Sascha Hauer <s.hauer@pengutronix.de> writes:
> 
> > That's why I had to disable this mapping. Most other SoCs do not have
> > flash on 0x0. The i.MX processors for example have their internal ROM
> > there.
> Ah, I see.
> 
> >> And as a consequence, I'm a bit afraid that my disk-on-chip, having it's memory
> >> mapped to 0x0 - 0x2000, will be difficult to convert ... I must think of a way
> >> in there.
> >
> > Your options are:
> >
> > - Add some switch to disable the 0x0 mapping.
> > - Add ioremap support.
> >
> > I think we should go for the former for now. Real ioremap support
> > requires more thinking about how we want to do it. Will all drivers have
> > to do it or only the cfi driver?
> I think that only cfi and disk-on-chips drivers will have that problem, as being
> mapped (from an memory bus address POV) to address 0 is bound to boot code,
> which relies on some kind of memory (ROM, flash, ...).
> 
> And disabling 0x0 mapping will make the MMU booting quite fragile IMHO.
> Consider the following example:
>  - a flash/ROM is mapped at address 0 for booting the ARM SoC
>  - as requested by ARM, the first words of the flash are the vectors, with the
>  first one being the reset vector into a code that is supposed to run in a
>  *non-MMU* context
>  - the ARM core starts, and IPL is loaded
>  - IPL loads SPL (barebox)
>  - barebox remaps 0x0 to vectors at malloc'd 0xa0003f00 (former solution)
>  - barebox switches into MMU on
>  - a bug happens in barebox (urgh!!!) and the exception vector is triggered
>  ===> here, the flash/ROM vector is used
>  ===> this vectors assumes running from MMU-disabled environment
>  - the code running in the IPL triggers an exception because it's in MMU
>  environment
>   => eternal cycle begins

We use high vectors at 0xfff00000, so there won't be vectors at 0x0. the
0x0 mapping is only used to catch NULL pointer derefs.
That said, being able to catch NULL pointers is a very good thing,
especially when there is flash at 0x0 which might be accidently
overwritten by some code acting on NULL pointers.

> 
> I think either :
>  - we implement ioremap
>  - or we forbid (on ARM) MMU with board requiring 0x0 iomapped device
> 
> I would prefer a simple ioremap solution of the like:
>  - a mach-XXX declares an adress-space for io-remapping (contiguous, section
>  aligned and of size multiple of 1MBytes)
>    => if not => MMU config is not possible
>              => ioremap() gives back the flat physical address
>    => if yes => MMU config is possible
>              => ioremap() gives back an entry in io-remapping address space
>  - ioremap() is embedded in dev_request_mem_region()
> 
> What do you think ?

I think this problem is not MMU related. Without MMU we can't remap and
we can't catch NULL pointer derefs anyway.
With MMU we could just remap the flash in board code and pass the
remapped address as resource to the cfi driver. While I think the
cleanest solution would be to use ioremap in all drivers (and make
this a no-op on most boards) I don't think it's worth it at the moment.

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: ARM, MMU and IO space mapping

[Robert Jarzmik]

Sascha Hauer <s.hauer@pengutronix.de> writes:

> We use high vectors at 0xfff00000, so there won't be vectors at 0x0. the
> 0x0 mapping is only used to catch NULL pointer derefs.

> That said, being able to catch NULL pointers is a very good thing,
> especially when there is flash at 0x0 which might be accidently
> overwritten by some code acting on NULL pointers.
I don't know if it can be that easily overwritten, but catching NPE is always
good, it's true.

> With MMU we could just remap the flash in board code and pass the
> remapped address as resource to the cfi driver. While I think the
> cleanest solution would be to use ioremap in all drivers (and make
> this a no-op on most boards) I don't think it's worth it at the moment.
OK, remap in board, and input virtual mapping address into io ressource, simple
enough. OK, I'll try that.
That would require a function in arch/arm/cpu/mmu.c, to remap a physical address
range into a virtual one, wouldn't it ? Would you have a suggestion for the API
? As in map_io_section(u32 phys_addr, void *virt) ?

Cheers.

-- 
Robert

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

Re: ARM, MMU and IO space mapping

[Sascha Hauer]

On Wed, Nov 30, 2011 at 11:06:13PM +0100, Robert Jarzmik wrote:
> Sascha Hauer <s.hauer@pengutronix.de> writes:
> 
> > We use high vectors at 0xfff00000, so there won't be vectors at 0x0. the
> > 0x0 mapping is only used to catch NULL pointer derefs.
> 
> > That said, being able to catch NULL pointers is a very good thing,
> > especially when there is flash at 0x0 which might be accidently
> > overwritten by some code acting on NULL pointers.
> I don't know if it can be that easily overwritten, but catching NPE is always
> good, it's true.
> 
> > With MMU we could just remap the flash in board code and pass the
> > remapped address as resource to the cfi driver. While I think the
> > cleanest solution would be to use ioremap in all drivers (and make
> > this a no-op on most boards) I don't think it's worth it at the moment.
> OK, remap in board, and input virtual mapping address into io ressource, simple
> enough. OK, I'll try that.
> That would require a function in arch/arm/cpu/mmu.c, to remap a physical address
> range into a virtual one, wouldn't it ? Would you have a suggestion for the API
> ? As in map_io_section(u32 phys_addr, void *virt) ?

How about adding a size parameter ;)

Yes, this looks good enough for now.

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: ARM, MMU and IO space mapping

[Marc Kleine-Budde]

[-- Attachment #1.1: Type: text/plain, Size: 445 bytes --]

On 12/01/2011 03:26 PM, Sascha Hauer wrote:
>> ? As in map_io_section(u32 phys_addr, void *virt) ?
                          ^^^

make this an unsigned long

Marc
-- 
Pengutronix e.K.                  | Marc Kleine-Budde           |
Industrial Linux Solutions        | Phone: +49-231-2826-924     |
Vertretung West/Dortmund          | Fax:   +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686  | http://www.pengutronix.de   |


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

[-- Attachment #2: Type: text/plain, Size: 149 bytes --]

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

Re: ARM, MMU and IO space mapping

[Robert Jarzmik]

Sascha Hauer <s.hauer@pengutronix.de> writes:

>> That would require a function in arch/arm/cpu/mmu.c, to remap a physical address
>> range into a virtual one, wouldn't it ? Would you have a suggestion for the API
>> ? As in map_io_section(u32 phys_addr, void *virt) ?
>
> How about adding a size parameter ;)
Ok, then it would become "map_io_range(unsignend long phys_addr, void *virt)",
which is a little more complicated that the original map_io_section which
remapped only full 1M sections for simplicity.

But yeah, I can add that parameter :)

Cheers.

-- 
Robert

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