On Mon, 17 Jan 2000, Niklaus Giger wrote: > I successfully managed to create vmlinux for the oak-IBM 403 > Evaluation Board.
Excellent! Based on the latest 2.3.39 code or the 2.3.39 plus my patches? > As our OAK-board does not work anymore (it is over 4 years old and out > of service) I tried to load the vmlinux using my vxworks boot-rom. I > got a memory access while trying to access 0xc0000008. The kernel shouldn't ever access 0xc0000008 during normal operation. The entry point from the boot loader (did try to boot vmlinux.img in arch/ppc/treeboot or vmlinux directly?) is at 0x00000000. Shortly thereafter, the MMU is enabled and code should start executing from 0xc0002100 (or in that approximate range). > Therefore I tried to change in linux/arch/ppc/Makefile the > KERNELLOAD =0xc0000000 > to > KERNELLOAD =0x10000 > as all my 4 MB RAM (known at boottime) is located at address 0. > After make clean vmlinux I was able to load vmlinux. You don't ever want to change KERNELLOAD or KERNELBASE, otherwise the virtual memory and MMU code will all break. > It load, but it does not start up. A hardware debugging session using > the JTAG-based SDS-debugger showed, that it crashed after very few > instruction at 0x10074 > > SDS-debugger deassembles: > 00010000: or r31,r3,r3 > 00010004: or r30,r4,r4 > 00010008: or r29,r5,r5 > 0001000C: or r28,r6,r6 > 00010010: or r27,r7,r7 > 00010014: addi r24,r0,0 > 00010018: addis r3,r0,0xC0000000 at HI > 0001001C: addis r3,r3,0x00000000 at HI > 00010020: addis r4,r3,0x40000000 at HI > 00010024: mfspr r7,PID > 00010028: addi r0,r0,0 > 0001002C: mtspr PID,r0 > 00010030: rlwinm r4,r4,0,0,21 > 00010034: ori r4,r4,0x304 > 00010038: rlwinm r3,r3,0,0,21 > 0001003C: ori r3,r3,0x3C0 > 00010040: illegal > 00010044: illegal > 00010048: isync > 0001004C: mtspr PID,r7 > 00010050: addis r4,r0,0xC0000000 at HI > 00010054: addis r0,r4,0x40000000 at HI > 00010058: mtspr EVPR,r0 > 0001005C: mfmsr r0 > 00010060: ori r0,r0,0x30 > 00010064: mtspr SRR1,r0 > 00010068: addis r0,r0,0x00010000 at HI > 0001006C: ori r0,r0,0x21C8 > 00010070: mtspr SRR0,r0 > 00010074: rfi The above code is from head_4xx.S and is the entry point from the boot loader. It basically sets up a TLB page mapping that is used when the kernel puts the processor into virtual mode after the 'rfi' you cited gets executed. > After the rfi at 0x10074. PC is at 0x121C8 (000121BC is abort:) The lower address of 0x21C8 is the assembly tag 'start_here' found in head_4xx.S (see above when I talked about 0xc0002100). This is where the real work to jump to the Linux kernel starts and it all is done in virtual mode. > It seems to me that my MMU is not yet correctly setup? I don't suspect that's the problem. At the very least, you should be able to successfully execute the kernel up through 'identify_machine' in the vicinity of virtual address 0xc00f8810. After that, there's some setup code that relies on information passed in from the Oak evaluation board (see main.c in arch/ppc/treeboot). > Could you please be so kind to describe your patchs (against 2.3.39) > and post them on your home page? Most of my changes are summarized in the "Recent Changes" subheading on that web page. Recently, most changes have been focused around the Ethernet controller. > I would also appreciate any hints how to disable the 16650-SCC (our > hardware does not have one) and how to uses the internal 403 (I have > the knowledge to program it). There's currently no code in the 4xx-based port which uses or assumes the 16650 serial controller found on the Oak board, so you shouldn't need to change a thing. As for the internal 403 serial port, I haven't yet coded in support for that yet. It's on the "to-do" list. Regards, Grant Erickson ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
