On 5/5/06, Thomas Petazzoni <thomas.petazzoni@xxxxxxxx> wrote:
Hi,
[ As nobody answered, let's have a try. ]
Le Wed, 3 May 2006 14:01:52 +0530,
"srinivas bakki" < srinivas.bakki@xxxxxxxxx> a écrit :
> somebody please help me understanding the following code. since
> this code is referenced from setup.c how does the compiler put in
> the physical address of the machine descriptor in r5 ? also this
> address i dont understand why it is metioned as physical !!!
First of all, you should have asked a more precise question, for
example by telling us which file of the kernel you are copying below.
(I've finally found that it's in arch/arm/kernel/head-common.S).
I'm not an expert, but here's what happen:
arch/arm/kernel/setup.c::setup_machine() calls lookup_machine_type(),
defined in arch/arm/kernel/head- common.S.
This lookup_machine_type() is basically a wrapper around
__lookup_machine_type() that allows this function to be called from a C
function by respecting the ARM C calling conventions.
The lookup_machine_type() wrapper transfers the contents of r0 to r1,
because the argument "nr" passed by the code in setup.c is stored in
r0, but the __lookup_machine_type() function waits for the machine
architecture number in r1.
Then, the __lookup_machine_type() functions does its job (for which I
can't help, as I'm not an ARM expert). Its job is to find a pointer to
a certain structure, which is returned in r5. Once it has completed its
job, control returns in lookup_machine_type(), which transfers the
contents of r5 to r0. This is because r5 contains the actual result of
the function, but the ARM C calling convention says that the return
value must be stored in r0.
Here is how it works between C and assembly. Now, if your question is
how does __lookup_machine_type() work, then I suggest you to read some
ARM architecture manual.
Sincerly,
Thomas
--
PETAZZONI Thomas - thomas.petazzoni@xxxxxxxx
http://{thomas,sos,kos}.enix.org - Jabber: thomas.petazzoni@xxxxxxxxx
http://{agenda,livret}dulibre.org - http://www.toulibre.org
Fingerprint : 0BE1 4CF3 CEA4 AC9D CC6E 1624 F653 CB30 98D3 F7A7
Thanks Thomas,
that was so kind of you . well to clearly tell you my problem i repeat the code below :
find my comments embedded in the code :
3: .long .
.long __arch_info_begin
.long __arch_info_end
.long __arch_info_begin
.long __arch_info_end
__lookup_machine_type:
adr r3, 3b
adr r3, 3b
### here we take the address of the arch.info structure. Then load ( ldmia )the contents at r3 (i.e arch_info structure) into r4,r5,r6 (3 words long) .
### now since this address pointing to the machine info.is already virtual why do we need to convert it to physical ?
ldmia r3, {r4, r5, r6}
sub r3, r3, r4 @ get offset between
virt&phys
add r5, r5, r3 @ convert virt
addresses to
add r6, r6, r3 @ physical address
space
rsb r3, r5, r6 @ number of machine
types
teq r3, #SIZEOF_MACHINE_DESC @ only one?
ldreq r1, [r5] @ if so do not bother
with r1
beq 2f @ ...and be happy.
1: ldr r3, [r5] @ get machine type
teq r3, r1 @ matches loader
number?
beq 2f @ found
add r5, r5, #SIZEOF_MACHINE_DESC @ next machine_desc
cmp r5, r6
blt 1b
mov r5, #0 @ unknown machine
2: mov pc, lr
### also when the assembly code is called from the C code in setup.c is it always defined by the compiler that the arguments would go in the same register always ? cause we expect the machine number in the r0 unconditionally !!! my guess is that they should be picked from the stack.
regards
Srinivas Bakki
