On Thu, 4 Oct 2001, Ian Thompson wrote:
> Helge,
>
> Thanks for your advice! It's brought up a couple of other question, if you
> don't mind:
>
> > The kernel can get to know - all you need is code that maps the
> > ROM address range into some available virtual address range.
> > Look at device driver code - they do such mapping for ROM and/or
> > memory-based io regions.
>
> I've seen the mapping of the single RAM address range, but I don't see where
> it is possible to add in another range for ROM. What functions should I
> look for that do this mapping?
>
> > Do that ROM code work when the MMU has remapped its adresses so it
> > appears at some adress completely different from the bus address? (only
> > if it contains relative jumps only - no absolute addresses.) Does
> > it work with 4G segments? Does it work at all in protected mode,
> > with all interrupts routed to the linux kernel instead of the bios?
> > Does this code expect to find something (data, device interfaces,
> > vga memory) at certain addresses? If so, this must be mapped too.
>
> I've run this code (in ROM) successfully before starting the kernel. I
> believe the cache is disabled, and interrupts are not needed (and are off).
> The code does not refer to anything within the kernel. I've tried turning
> off the MMU completely before branching, but this seems to hang the system.
> =(
>
> Any ideas of what I should look for to turn off, aside from just shutting
> down the MMU? If I map the ROM address range into a virtual addr range,
> won't I run into problems once I'm running the code, such as physical
> addresses being interpreted by virtual ones?
>
> btw, this is running on an XScale (strongARM).
>
> Thanks again,
> -ian
All kernel addresses, including "physical" addresses are virtual.
There is a PTE to map your specific memory area, on a page-by-page
basis, to a virtual address. You are normally accessing memory
using that virtual address (both code and data).
If you want to turn OFF the virtual addressing, you have to first
jump or call a procedure, that is properly relocated, somewhere
that the virtual and physical addresses are the same. The first
one megabyte is such a location. It is complex and has to be done
in the correct order or else you can't "get back".
A typical way, on an ix86, is to make a binary array from the code
you want to execute, relocated from an object file, to some offset
such as 0x1000.
You use ioremap() to create a virtual address from 0x1000. Then
you copy the relocated code, currently in some array, to the relocated
address (0x1000), using the cookie returned from ioremap(). Then you
disable interrupts on your local CPU via a spinlock, you make a long
(FAR) call to your relocated code. In the code, you can disable the paging
bit and set DS, ES to the page-table selector, which looks at linear
addressing. Now you can see and access everything as 32-bit linear
address-space. Careful, you can't allow interrupts and you can't use the
stack because neither it, nor the stack-selector has been set. You can
do "your" thing, with global memory then you restore the previous
selectors to DS and ES, re-enable paging, then do a FAR return.
The code after the return unlocks the spin-lock and you are
home free.
I any step isn't done correctly, you will crash the processor ;^).
This shows up as though you hit the reset switch.
# insmod module.o <SPLAT> <FLASH>
Award Modular BIOS V45pg Copyright(c) 1998 Award Software, Inc.
Memory test : 0011240 Ok
Pres DEL to enter SETUP
Cheers,
Dick Johnson
Penguin : Linux version 2.4.1 on an i686 machine (799.53 BogoMips).
I was going to compile a list of innovations that could be
attributed to Microsoft. Once I realized that Ctrl-Alt-Del
was handled in the BIOS, I found that there aren't any.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun Oct 07 2001 - 21:00:33 EST