ARM, MMU and IO space mapping
robert.jarzmik at free.fr
Mon Nov 28 12:43:06 EST 2011
Sascha Hauer <s.hauer at 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
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
- 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
=> 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
>> 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 :)
More information about the barebox