Hello People.
Ive been trying to understand how the P4080 starts up and what things need to be taken care of. Hence I am reading the u-boot source code as well as taking a look at the /arch/powerpc/ directory in the kernel (I am looking at 2.6.27 and 2.6.34 here)
Starting with 2.6.27. So now lets get started to give you all an idea of what am I looking at:
I know my post has been really long but I hope I have been clear and succinct in describing what my problem is.
Hoping for an answer.
Thanks in advance
1. Yes.
2. Look in arch/powerpc/kernel/cpu_setup_fsl_booke.S. What specific information are you looking for? You're correct, AN1809 is not for e500-based chips.
4. I belive allocatable is required for the section to be included in the target image as something that gets loaded to memory. It's normal for all code/data linker sections, and has nothing to do with the board's memory map or dynamic allocation.
5. Linux tries to not depend too much on what U-Boot has done, as it may change (or be something other than U-Boot). The power.org ePAPR document describes the interface between the bootloader and the OS (at least for core-related things, not assumptions about I/O state such as memory map initialization, SERDES, etc).
7. dcbzl will work regardless of the setting of DCBZ32. You do not need to set DCBZ32 first.
Oh, and most people are probably reading this board during normal working hours, so if you post Friday night/Saturday morning and don't see a response by Sunday, that doesn't mean we're ignoring you. :-)
Hi Scott.
Thanks for the replies. And yes I'm sorry for being, well, just say a little childish :smileyhappy:. Sometimes all you see are deadlines to meet..and one goes into this childlike mode
Nevertheless, as is always the case, the more you see the less you know, the more you find out as you go. Best immortalized by U2 in his 'City of Blinding lights'. On this note, ive got a few more questions coming up your way!!
And yes as for the reason im still stuck with 27 is because the higher ups want it that way,...and I bet you do know how difficult it is to talk to someone who has lost touch with technology since quite some time now..im sure you do :smileygrin:. Hence Im tagging along..and yes I do not think 27 is that primitive..ive seen people stuck with 2.4 eeven now :smileywink:
Regards.
1. If you look closely at that makefile fragment, you'll see that it's using := instead of the usual +=. So when you get to head-$(CONFIG_FSL_BOOKE) it replaces head-y rather than adding to it. head_32.S isn't really generic -- it's specifically for classic PPC chips and wouldn't work on booke.
2. ePAPR can be found here: ePAPR Version 1.1 | Power.org. I assume you're talking about the spin table stuff -- see section 5.5.
3. Make sure CONFIG_EARLY_PRINTK is enabled. If you still don't see your early output, use JTAG to dump the console buffer (to find the address, do "p &__log_buf" in gdb).
Hi Scott.
Im a bit late on this thread. Well other things you see. Nevertheless, Ive been reading the ePAPR which looks more like a document which describes the guidelines rather than a description of something existing. More like a POSIX document perhaps?
I also see many references to the term 'Client Program' all the time. Does this client program refer to the bootloader aka the first program to run when the chip is out of reset or does it refer to the program that will eventually run on the chip? Which could be anything from a bare-metal Kind of OS or a full fledged OS like Linux.
Now coming on to the actual document, section 5.3 in ePAPR talks of Initial Mapped Areas(IMA) areas which I believe are mapped by default to certain portions of the memory. Another reference to IMAs was found in the freescale powerpc programming environments manual section 7.3.1.1 called Predefined Physical Memory Locations . Do both these sections in these two documents refer to the same concept?
Here are the predefined physical memory locations
The freescale document says:
Four areas of the physical memory map have predefined uses. The first 256 bytes of physical memory (or if MSR[IP] = 1, the first 256 bytes of memory located at physical address 0xFFF0_0000) are assigned for arbitrary use by the operating system. The rest of that first page of physical memory defined by the vector base address (determined by MSR[IP]) is used for interrupt vectors or reserved for future interrupt vectors. So it means that when the process comes out of reset (which can be looked at as interrupt) it vectors into memory area 2 which can be either 0x0000_0100 or 0xFFF0_0100. Am I right here? If so, can this memory region be categorized as a Boot IMA as per the ePAPR document?
Now doing a quick scan of 0xFFF0_0000 under the arch/powerpc folder didn't quite turn up anything concrete:
$ grep -iwr 0xFFF00000 .
./boot/dcr.h:#define EBC_BXCR_BAS 0xfff00000
./boot/dts/mgsuvd.dts: ranges = <0 0xfff00000 0x00004000>;
./kernel/cputable.c: .pvr_mask = 0xfff00000,
./kernel/cputable.c: .pvr_mask = 0xfff00000,
./platforms/powermac/cache.S: * that we can read from ROM at physical address 0xfff00000.)
./platforms/powermac/pci.c: reg = ((region->start >> 16) & 0xfff0) | (region->end & 0xfff00000);
./sysdev/fsl_pci.c: rsrc_cfg.start = (rsrc_reg.start & 0xfff00000) + 0x8300;
./sysdev/fsl_pci.c: rsrc_cfg.start = (rsrc_reg.start & 0xfff00000) + 0x8380;
However as per the u-boot source code, the reset vector address is 0xFFFF_FFFC. They have a #define within u-boot.lds the loader script for the mpc85xx which explicitly defines the reset vector address to be 0xFFFF_FFFC. This address is not however not mentioned at all in the ePAPR. Ive tried looking into the programming references manual, the e500mc reference manual and the programmer's reference manual but to no avail. How did u-boot arrive at this address? The only reference I could find for this address is in section 6.6 of the e500mc reference manual which is for the TLB states after reset. Is there a memory map for the e500 family of processors that I could find somewhere in these manuals?
Secondly, I see in ePAPR in section 5.4 entitled CPU Entry points requirements that the initial register values must be as such:
However, when I see head_fsl_booke.S, I see the following comment:
/* As with the other PowerPC ports, it is expected that when code
* execution begins here, the following registers contain valid, yet
* optional, information:
*
* r3 - Board info structure pointer (DRAM, frequency, MAC address, etc.)
* r4 - Starting address of the init RAM disk
* r5 - Ending address of the init RAM disk
* r6 - Start of kernel command line string (e.g. "mem=128")
* r7 - End of kernel command line string
*
*/
Why is there such a discrepancy? The only thing common is the content of register r3. Since board info structure pointer and device tree image seem to be suggest the same thing. No?
Lastly there seems to be quite a few differences between the 'Programming Environments Manual' aka MPCFPE32B and the 'Programmers' Reference Manual (for the e500 family)' aka EREF_RM. The latter one is more specific and has been published at a later date (2011 vs 2005 for the former). Like for instance the programming manual defines such things as the segment registers; some of the MSR bits are different between the two - Former has IR and DR for instruction and data translation whereas the latter does not seem to have these bits and instead defines IS and DS. Im sort of confused here. Which one should I be referring to and why? Ive noticed that it is rather hard to find the right document for the right answer unlike MIPS but then it could just be a case of a rookie finding his way around. Like in the above example, depending on which one I refer to, many things change. In fact the entire address translation mechanism seems to be differently shown in these two documents. Your help would be really appreciated at this moment :smileycry:
Yes, ePAPR is a specification document, not documentation of particular software. When it says "client program" that means the program, such as Linux, that is being booted via the ePAPR boot mechanism. The software that does the loading, such as U-Boot, is the "boot program". The hardware itself is not an ePAPR loader and thus the document is not relevant to how U-Boot starts.
Ignore the Programming Environments Manual. That is for classic PPC chips such as mpc7xx or mpc83xx and it is not relevant to QorIQ.
Also ignore the comment in head_fsl_booke.S; that is describing the old way of booting that was used in arch/ppc, without a device tree.
Hi Scott.
Thanks for the replies. There were quite a few things I asked in that long post last time. So here I will post a few bulletted questions that are very directed and hope I will get what I am looking for. Let me start from the head_fsl_booke.S file. This file is apparently the first file where the control from the u-boot (or any other bootloader for that matter) gets transferred from. So here are a few questions I have about this file:
ignore the comment in head_fsl_booke.S; that is describing the old way of booting that was used in arch/ppc, without a device tree
if this is indeed the case, then the way things are interpreted by _start routine is of no consequence. The code snippet from this file saves the GPRs3 to 7 to GPRs31 to 27 respectively so that we can use these lower numbered registers for function linkage (as part of the stack frame), or so I think (please correct me if I am wrong here). Heres the code snippet below. As per this, the bootloader is still passing the parameters via registers (or so it seems). Or do we need to refer to a different file under arch/powerpc/boot directory? But a quick glance at that directory and some of the files informed me that the files there are for older u-boot versions which could NOT parse the device dree itself. cuboot.c within this directory clearly says so in the banner. Which again means that head_fsl_booke.S is indeed the correct way. I am all confused now :smileyconfused:
_ENTRY(_start); /* * Reserve a word at a fixed location to store the address * of abatron_pteptrs */ nop /* * Save parameters we are passed */
mr r31,r3 mr r30,r4 mr r29,r5 mr r28,r6 mr r27,r7 li r25,0 /* phys kernel start (low) */ li r24,0 /* CPU number */ li r23,0 /* phys kernel start (high) */
stwu r0,THREAD_SIZE-STACK_FRAME_OVERHEAD(r1)
struct thread_info { struct task_struct *task; /* main task structure */ struct exec_domain *exec_domain; /* execution domain */ int cpu; /* cpu we're on */ int preempt_count; /* 0 => preemptable,<0 => BUG */ struct restart_block restart_block; unsigned long local_flags; /* private flags for thread */
/* low level flags - has atomic operations done on it */ unsigned long flags ____cacheline_aligned_in_smp; }
* stack */
lis r1,init_thread_union@h
ori r1,r1,init_thread_union@l
li r0,0
stwu r0,THREAD_SIZE-STACK_FRAME_OVERHEAD(r1)
Regards.
Regarding formatting problems, I've seen issues myself and have reported them. It's weird -- I see proper formatting in one Firefox profile, but not in another. Not sure if what you're seeing is the same thing.
The bootloader is still passing things in registers, but not the way head_fsl_booke.S describes. It is described by ePAPR. The most important one is r3, which points to the device tree.
Yes, SPRN_SPRG_THREAD (a.k.a. SPRG3) points to the current thread_info struct on 32-bit. SPRG usage is documented in arch/powerpc/include/asm/reg.h. Yes, this is true regardless of whether it is a multi-threaded program. What was the question about process ID?
If by "export" you mean EXPORT_SYMBOL(), that's only relevant for modules. Inside the kernel image, anything that is not "static" is globally visible.
A thread_union has the stack at the top and the thread_info at the bottom. I'm not sure what you mean by "when I say the stack for a given process/thread/task in Linux, it is nothing but the thread_info structure". The "stack" field of the union isn't an unsigned long, it's an *array* of unsigned longs -- 8192 bytes worth (on 32-bit). Hopefully that answers the later confusion.
Hi Scott.
Thanks for the replies mate. Regarding 1, yep sp basically head-y is head_fsl_booke.S. Regarding 2, I will need to check it out esp if I would want to understand what u-boot and the early init code is actually doing. Regarding 3, yep ive done that and I am able to see some of the functions being invoked (in which ive added my own printks)
Now, first I am sorry for being a lil too late as I was on leave here and on vacation one tends to forget work. Secondly, to my surprise the management is now fine with using 2.6.34 so it means it makes things easier. I see that there is no ppc and powerpc directories but a single consolidated powerpc directory under arch. Good.
Now if you remember from the other thread with simbu, I was also interested in making my older code run on newer hardware. Hence I needed to set the DCBZ32 bit inside L1CSR0. I am doing that inside the cpu_setup_fsl_booke.S file when DCache is being set up. And ive replaced dcbz with dcbzl. I then check whether the bit has been set in the outer functions and voila..it is..however now my /sbin/init hangs..becomes dead fish..the kernel_execve part fails..it is not able to spawn the init process..ive checked my rootfs (which has been properly NFS mounted as per the console log) and there is indeed /sbin/init. On checking the net, ive come across people having this issue with xilinx's ppc405 and ppc440 'soft cores'. Now just abt anything could be wrong here...any particular directions I should be looking at..perhaps this weekend...??
This is getting off-topic for "Understanding P4080 startup sequence"... please put further discussion of DCBZ32 under the existing DCBZ32 thread, or create a new question. Definitely don't hijack unrelated year-old questions like here. :-)
You need to either tell userspace that it has a 32-byte cache line (vdso_init() is probably what you want to look at), or be selective in which processes you set DCBZ32 for.
HI Scott..
Thanks for the suggestion..I thought may be that'd crowd the space here...but i guess itll keep things cleaner..will do that soon
Note that setting DCBZ32 for all processes, even if you fix the VDSO data, may cause a performance decrease that isn't limited to the old code you're trying to be compatible with.
Hello Fellas and Ladies.
Could anyone please atleast shed some light on it?? :smileyplain: ...
Atleast something..You need not be a QorIQ guru but I guess if you've had your feet wet..atleast you could give me a few hints..