Hi,

Jitendra Kumar Rai wrote:

We are porting Linux on a 32 bit RISC processor. I
have seen code of head.S for m68k and, am in the
process to rewrite the same for our architecture, but
having some queries in this regard. I need your help
in solving the queries.I have also gone through the
same code for i386.  Brief details of architecture
are:

It includes data & instruction caches, two independent
MMUs for data and instruction access. It uses a five
stage pipelined internal architecture to implement
single cycle execution.Programmers have to take care
of resource dependencies, and the effects of delayed
branching, while writing the assembly programs. For
multi cycle instructions, the pipeline is frozen for
the required number of cycles.

I don't mind explaining the m68k head.S code, but what exactly are your
porting problems? This way it might be easier to help you (and not only
by the few people who know the m68k code).

Q.1 : What is the purpose/meaning  of macro  #define
L(name), for example

#define L(name) .L/**/name

Symbols starting with ".L" are local symbols. For debugging they can be
made visible this way.

Q.2 : Could not understand the pc relative addressing
used. How can we get the same effective address by
writing syntax like this each time?
(while pc is changing always)

lea     %pc@(L(phys_kernel_start)),%a0

The kernel can be located anywhere in physical memory, this makes it
position independent.

Q.3 : Why are we doing like this:

 Save physical start address of kernel

        lea     %pc@(L(phys_kernel_start)),%a0
        lea     %pc@(SYMBOL_NAME(_stext)),%a1
        subl    #SYMBOL_NAME(_stext),%a1
        movel   %a1,%a0@

Can we do like this instead of the above:

        movel   %pc,%a0@

This would result in phys_kernel_start + random offset.

Q.4 : Why  are we doing like this:

.text
ENTRY(_stext)

        bras    1f      /* Jump over bootinfo version numbers */
        .....
        .....
1:      jra     SYMBOL_NAME(__start)

Can we do like this instead of the above:

.text
ENTRY(_stext)
        jra     SYMBOL_NAME(__start)

No, this would confuse the bootloader.

Q.5 : What is meant by
        (1) directve used:
        .chip 68040

        (2) %bc used in:
        cinva %bc

        (3) purpose of: ( in mmu_engage )
        jmp 1f:l

        (4) %pcr used in
        move %d0, %pcr

Some assembly instruction assemble into different opcodes (depending on
the cpu).

Q.6 : What is done by code written for
L(mmu_engage_cleanup)

Q.7 : What is the purpose of following instruction in
mmu_get_ptr_table_entry?

        andw    #-PTR_TABLE_SIZE,%d0

Q.8 : Why the mmu_temp_map is provided?

Q.9 : Inside mmu_engage:
        (1) Why the address comparison is made using 1b, like
this:

        lea     %pc@(1b),%a0
        movel   #1b,%a1
        /* Skip temp mappings if phys == virt */
        cmpl    %a0,%a1
        jeq     1f

         What is the significance of address 1b ?

        (2) Why mmu_temp_map is called 4 times? or otherwise
why temporary mapping is provided for two pages?

Q.10 : What is the purpose of long jmp in mmu_engege?

        jmp     1f:l
1:      nop

        Why there is only one NOP? ( there should be two nops
i.e. first for decode & second for fetch stage of the
pipeline )

Basically all this code prepares the jump from physical addressing to
virtual addressing. For this the code must shortly be visible at two
locations. To really understand this code you should first understand
the m68k mmu. This code is quite complex, because it has to work for
several configurations.

Q.11 : What are (exactly) the tasks, code in head.S is
supposed to perform?

Doing the basic cpu setup, so it can call into normal C code, which does
the remaining setup.

bye, Roman
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/