* local_irq_enable() problem... @ 2004-01-20 5:34 Etsushi Kato 2004-01-20 10:03 ` Geert Uytterhoeven 0 siblings, 1 reply; 7+ messages in thread From: Etsushi Kato @ 2004-01-20 5:34 UTC (permalink / raw) To: linuxppc-dev Hi, I just started porting Linux 2.6 for nubus powermac. I've applied most of 2.4 nubus patch to 2.6.1-rc2, and kernel compiles fine now. But in the early booting of kernel, it hangs while doing local_irq_enable() just after profile_init() in start_kernel() of init/main.c. How can I debug kernel in this situation? printk() is working, and boot messages are shown with serial connection until "Console: colour dummy device 80x25". Maybe it is related arch/ppc/kernel/head.S and entry.S ?? Thanks in advance, -- Etsushi Kato ekato@ees.hokudai.ac.jp ** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/ ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: local_irq_enable() problem... 2004-01-20 5:34 local_irq_enable() problem Etsushi Kato @ 2004-01-20 10:03 ` Geert Uytterhoeven 2004-01-20 13:34 ` Etsushi Kato 2004-01-20 13:49 ` Sven Luther 0 siblings, 2 replies; 7+ messages in thread From: Geert Uytterhoeven @ 2004-01-20 10:03 UTC (permalink / raw) To: Etsushi Kato; +Cc: Linux/PPC Development On Tue, 20 Jan 2004, Etsushi Kato wrote: > I just started porting Linux 2.6 for nubus powermac. I've applied most > of 2.4 nubus patch to 2.6.1-rc2, and kernel compiles fine now. But in > the early booting of kernel, it hangs while doing local_irq_enable() > just after profile_init() in start_kernel() of init/main.c. > > How can I debug kernel in this situation? printk() is working, and > boot messages are shown with serial connection until "Console: colour > dummy device 80x25". Did you pass `console=ttyS0'? If all else fails, add a call to your serial print routine in kernel/printk.c:printk(), right after the va_end. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds ** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/ ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: local_irq_enable() problem... 2004-01-20 10:03 ` Geert Uytterhoeven @ 2004-01-20 13:34 ` Etsushi Kato 2004-01-20 15:55 ` Hollis Blanchard 2004-01-20 13:49 ` Sven Luther 1 sibling, 1 reply; 7+ messages in thread From: Etsushi Kato @ 2004-01-20 13:34 UTC (permalink / raw) To: Geert Uytterhoeven; +Cc: Linux/PPC Development On Tue, Jan 20, 2004 at 11:03:41AM +0100, Geert Uytterhoeven <geert@linux-m68k.org> wrote: > On Tue, 20 Jan 2004, Etsushi Kato wrote: > > I just started porting Linux 2.6 for nubus powermac. I've applied most > > of 2.4 nubus patch to 2.6.1-rc2, and kernel compiles fine now. But in > > the early booting of kernel, it hangs while doing local_irq_enable() > > just after profile_init() in start_kernel() of init/main.c. > > > > How can I debug kernel in this situation? printk() is working, and > > boot messages are shown with serial connection until "Console: colour > > dummy device 80x25". > > Did you pass `console=ttyS0'? Yup. I set up 'console=ttyS0,38400n8 console=tty0' as a cmdline option. In the early boot sequence, 2.6 kernel freezes just after showing 'arch_exit' on the screen, and 'Console: colour dummy device 80x25' on the serial console. Even if I put printk() right after local_irq_enable() in init/main.c, this debug print won't show up. So it seems something causes kernel hang while enabling MSR_EE bit, but I can't figure out how to detect... Does anyone have a clue? > If all else fails, add a call to your serial print routine in > kernel/printk.c:printk(), right after the va_end. OK. Thanks. -- Etsushi Kato ekato@ees.hokudai.ac.jp ** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/ ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: local_irq_enable() problem... 2004-01-20 13:34 ` Etsushi Kato @ 2004-01-20 15:55 ` Hollis Blanchard 2004-01-21 9:51 ` Etsushi Kato 0 siblings, 1 reply; 7+ messages in thread From: Hollis Blanchard @ 2004-01-20 15:55 UTC (permalink / raw) To: Etsushi Kato; +Cc: Linux/PPC Development On Jan 20, 2004, at 7:34 AM, Etsushi Kato wrote: > > In the early boot sequence, 2.6 kernel freezes just after showing > 'arch_exit' on the screen, and 'Console: colour dummy device 80x25' on > the serial console. Even if I put printk() right after > local_irq_enable() in init/main.c, this debug print won't show up. So > it seems something causes kernel hang while enabling MSR_EE bit, but I > can't figure out how to detect... Does anyone have a clue? Perhaps you have an irq that won't shut up? Or maybe a problem returning from an exception handler (I'm assuming you have your own head.S). -- Hollis Blanchard IBM Linux Technology Center ** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/ ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: local_irq_enable() problem... 2004-01-20 15:55 ` Hollis Blanchard @ 2004-01-21 9:51 ` Etsushi Kato 2004-01-22 1:01 ` Paul Mackerras 0 siblings, 1 reply; 7+ messages in thread From: Etsushi Kato @ 2004-01-21 9:51 UTC (permalink / raw) To: Hollis Blanchard; +Cc: Linux/PPC Development Hi, Thank you for your comment. On 2004.1.21, at 12:55 AM, Hollis Blanchard wrote: > On Jan 20, 2004, at 7:34 AM, Etsushi Kato wrote: >> >> In the early boot sequence, 2.6 kernel freezes just after showing >> 'arch_exit' on the screen, and 'Console: colour dummy device 80x25' on >> the serial console. Even if I put printk() right after >> local_irq_enable() in init/main.c, this debug print won't show up. So >> it seems something causes kernel hang while enabling MSR_EE bit, but I >> can't figure out how to detect... Does anyone have a clue? > > Perhaps you have an irq that won't shut up? I think it should be OK since I've ported all the nubus-pmac specific setup code which works fine on Linux 2.4.24. > Or maybe a problem > returning from an exception handler (I'm assuming you have your own > head.S). Yes, I use slightly modified version of head.S based on Takashi Oe's 2.4 nubus patch (see attached diff below). Is there any way to check whether exception handling code is working correctly? Register usage in head.S and entry.S seems to be changed from 2.4, so perhaps I missed porting some part. But I'm not yet fully understanding PPC asm code and memory address mapping... (on nubus-pmac, KERNELBASE is 0xc0000000, KERNLOAD_OFFSET is created and set as 0x200000, and KERNELLOAD is 0xc0200000). Thanks, -- Etsushi Kato ekato@ees.hokudai.ac.jp diff -Nru a/arch/ppc/kernel/head.S b/arch/ppc/kernel/head.S --- a/arch/ppc/kernel/head.S Wed Jan 21 18:34:35 2004 +++ b/arch/ppc/kernel/head.S Wed Jan 21 18:34:35 2004 @@ -173,11 +173,13 @@ bl mmu_off __after_mmu_off: #ifndef CONFIG_POWER4 +#ifndef CONFIG_NBPMAC bl clear_bats +#endif /* !CONFIG_NBPMAC */ bl flush_tlbs bl initial_bats -#if !defined(CONFIG_APUS) && defined(CONFIG_BOOTX_TEXT) +#if !defined(CONFIG_APUS) && defined(CONFIG_BOOTX_TEXT) && !defined(CONFIG_NBPMAC) bl setup_disp_bat #endif #else /* CONFIG_POWER4 */ @@ -192,8 +194,10 @@ li r24,0 /* cpu# */ bl call_setup_cpu /* Call setup_cpu for this CPU */ #ifdef CONFIG_6xx +#ifndef CONFIG_NBPMAC bl reloc_offset bl init_idle_6xx +#endif /* !CONFIG_NBPMAC */ #endif /* CONFIG_6xx */ #ifdef CONFIG_POWER4 bl reloc_offset @@ -201,7 +205,7 @@ #endif /* CONFIG_POWER4 */ -#ifndef CONFIG_APUS +#if !defined(CONFIG_APUS) && !defined(CONFIG_NBPMAC) /* * We need to run with _start at physical address 0. * On CHRP, we are loaded at 0x10000 since OF on CHRP uses @@ -215,7 +219,7 @@ addis r4,r3,KERNELBASE@h /* current address of _start */ cmpwi 0,r4,0 /* are we already running at 0? */ bne relocate_kernel -#endif /* CONFIG_APUS */ +#endif /* !CONFIG_APUS && !CONFIG_NBPMAC */ /* * we now have the 1st 16M of ram mapped with the bats. * prep needs the mmu to be turned on here, but pmac already has it on. @@ -411,7 +415,16 @@ bne 1f /* if not, try to put a PTE */ mfspr r4,DAR /* into the hash table */ rlwinm r3,r10,32-15,21,21 /* DSISR_STORE -> _PAGE_RW */ +#ifndef CONFIG_NBPMAC bl hash_page +#else /* !CONFIG_NBPMAC */ + /* relative addressing can't be used here */ + lis r2,hash_page@h + ori r2,r2,hash_page@l + tophys(r2,r2) + mtspr LR,r2 + blrl +#endif /* !CONFIG_NBPMAC */ 1: stw r10,_DSISR(r11) mr r5,r10 mfspr r4,DAR @@ -438,7 +451,16 @@ beq 1f /* if so, try to put a PTE */ li r3,0 /* into the hash table */ mr r4,r12 /* SRR0 is fault address */ +#ifndef CONFIG_NBPMAC bl hash_page +#else /* !CONFIG_NBPMAC */ + /* relative addressing can't be used here */ + lis r2,hash_page@h + ori r2,r2,hash_page@l + tophys(r2,r2) + mtspr LR,r2 + blrl +#endif /* !CONFIG_NBPMAC */ 1: addi r3,r1,STACK_FRAME_OVERHEAD mr r4,r12 mr r5,r9 @@ -1229,8 +1251,10 @@ bl identify_cpu bl call_setup_cpu /* Call setup_cpu for this CPU */ #ifdef CONFIG_6xx +#ifndef CONFIG_NBPMAC lis r3,-KERNELBASE@h bl init_idle_6xx +#endif /* !CONFIG_NBPMAC */ #endif /* CONFIG_6xx */ #ifdef CONFIG_POWER4 lis r3,-KERNELBASE@h @@ -1390,6 +1414,15 @@ bl copy_and_flush /* copy the first 0x4000 bytes */ #endif /* CONFIG_APUS */ +#ifdef CONFIG_NBPMAC + /* Copy exception vector to phys 0x0 */ + lis r4,(KERNELBASE+KERNLOAD_OFFSET)@h + lis r3,KERNELBASE@h /* Copy to phys 0x00000000 */ + li r5,0x4000 /* # bytes of memory to copy */ + li r6,0 + bl copy_and_flush /* copy the first 0x4000 bytes */ +#endif /* CONFIG_NBPMAC */ + /* * Go back to running unmapped so we can load up new values * for SDR1 (hash table pointer) and the segment registers @@ -1559,12 +1592,24 @@ bne 4f ori r11,r11,4 /* set up BAT registers for 601 */ li r8,0x7f /* valid, block length = 8MB */ - oris r9,r11,0x800000@h /* set up BAT reg for 2nd 8M */ - oris r10,r8,0x800000@h /* set up BAT reg for 2nd 8M */ mtspr IBAT0U,r11 /* N.B. 601 has valid bit in */ mtspr IBAT0L,r8 /* lower BAT register */ +#ifdef CONFIG_NBPMAC + lis r10,-KERNELBASE@h + addis r9,r10,nbpmac_2nd_mem_chank@ha + addi r9,r9,nbpmac_2nd_mem_chank@l + lwz r10,0(r9) + or r9,r11,r10 /* set up BAT reg for 2nd mem region */ + or r10,r8,r10 /* set up BAT reg for 2nd mem region */ mtspr IBAT1U,r9 mtspr IBAT1L,r10 + sync +#else /* CONFIG_NBPMAC */ + oris r9,r11,0x800000@h /* set up BAT reg for 2nd 8M */ + oris r10,r8,0x800000@h /* set up BAT reg for 2nd 8M */ + mtspr IBAT1U,r9 + mtspr IBAT1L,r10 +#endif isync blr #endif /* CONFIG_PPC64BRIDGE */ @@ -1594,6 +1639,22 @@ blr #if !defined(CONFIG_APUS) && defined(CONFIG_BOOTX_TEXT) +#define setup_misc_bat(n, dbat, ibat) \ + addis r8,r3,ibat@ha; \ + addi r8,r8,ibat@l; \ + lwz r11,0(r8); \ + lwz r8,4(r8); \ + mtibatl n,r8; \ + mtibatu n,r11; \ + cmpi 0,r9,1; \ + beq 1f; \ + addis r8,r3,dbat@ha; \ + addi r8,r8,dbat@l; \ + lwz r11,0(r8); \ + lwz r8,4(r8); \ + mtdbatl n,r8; \ + mtdbatu n,r11; \ +1: setup_disp_bat: /* * setup the display bat prepared for us in prom.c @@ -1601,21 +1662,50 @@ mflr r8 bl reloc_offset mtlr r8 - addis r8,r3,disp_BAT@ha - addi r8,r8,disp_BAT@l - lwz r11,0(r8) - lwz r8,4(r8) mfspr r9,PVR - rlwinm r9,r9,16,16,31 /* r9 = 1 for 601, 4 for 604 */ - cmpi 0,r9,1 - beq 1f - mtspr DBAT3L,r8 - mtspr DBAT3U,r11 - blr -1: mtspr IBAT3L,r8 - mtspr IBAT3U,r11 + rlwinm r9,r9,16,16,31 + setup_misc_bat(3, disp_DBAT, disp_IBAT) blr +#ifdef CONFIG_NBPMAC +/* + * For some reasons, kernel dies if it accesses I/O region or AV card's + * frame buffer region when MMU is off. Do minimal MMU setup before + * continuing if booted from BootX. With Apple booter, MMU is on. + * Use BAT 3 to map current frame buffer, BAT 0 for logic board memory. + * FB base address and size used are from bat_fb_base and bat_fb_size. + */ +_GLOBAL(nubus_early_mmu_setup) + mfmsr r6 + andi. r6,r6,MSR_DR /* MMU enabled? */ + bnelr /* if apple booter, we are set */ + mflr r6 + bl clear_bats + bl reloc_offset + mfspr r9,PVR /* get cpu type */ + rlwinm r9,r9,16,16,31 + cmpi 0,r9,1 + bne 9f + addis r4,r3,disp_IBAT@ha /* get BATU value setup by prom.c */ + lwz r4,disp_IBAT@l(r4) + cmpi 0,r4,0 /* if BATU = 0, don't use BAT3 */ + beq 2f + b 3f +9: addis r4,r3,disp_DBAT@ha /* get BATU value setup by prom.c */ + lwz r4,disp_DBAT@l(r4) + cmpi 0,r4,0 /* if BATU = 0, don't use BAT3 */ + beq 2f +3: setup_misc_bat(3, disp_DBAT, disp_IBAT) +2: setup_misc_bat(0, kern_BAT0, kern_BAT0) + setup_misc_bat(1, kern_BAT1, kern_BAT1) + /* turn on MMU */ + mfmsr r3 + ori r3,r3,(MSR_DR|MSR_IR)@l + mtspr SRR0,r6 + mtspr SRR1,r3 + SYNC + rfi +#endif /* CONFIG_NBPMAC */ #endif /* !defined(CONFIG_APUS) && defined(CONFIG_BOOTX_TEXT) */ #else /* CONFIG_POWER4 */ ** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/ ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: local_irq_enable() problem... 2004-01-21 9:51 ` Etsushi Kato @ 2004-01-22 1:01 ` Paul Mackerras 0 siblings, 0 replies; 7+ messages in thread From: Paul Mackerras @ 2004-01-22 1:01 UTC (permalink / raw) To: Etsushi Kato; +Cc: Hollis Blanchard, Linux/PPC Development Etsushi Kato writes: > Is there any way to check whether exception handling code is working > correctly? Register usage in head.S and entry.S seems to be changed > from 2.4, so perhaps I missed porting some part. Yes - the main difference is that we now don't save all the registers on the common interrupt/exception entries. We only save the volatile registers, since the C code saves and restores all the nonvolatile registers. We do this for external interrupt, decrementer and system call, at least. Other exception entries that are likely to result in sending a signal to the current process save all the registers. Paul. ** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/ ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: local_irq_enable() problem... 2004-01-20 10:03 ` Geert Uytterhoeven 2004-01-20 13:34 ` Etsushi Kato @ 2004-01-20 13:49 ` Sven Luther 1 sibling, 0 replies; 7+ messages in thread From: Sven Luther @ 2004-01-20 13:49 UTC (permalink / raw) To: Geert Uytterhoeven; +Cc: Etsushi Kato, Linux/PPC Development On Tue, Jan 20, 2004 at 11:03:41AM +0100, Geert Uytterhoeven wrote: > > On Tue, 20 Jan 2004, Etsushi Kato wrote: > > I just started porting Linux 2.6 for nubus powermac. I've applied most > > of 2.4 nubus patch to 2.6.1-rc2, and kernel compiles fine now. But in > > the early booting of kernel, it hangs while doing local_irq_enable() > > just after profile_init() in start_kernel() of init/main.c. > > > > How can I debug kernel in this situation? printk() is working, and > > boot messages are shown with serial connection until "Console: colour > > dummy device 80x25". > > Did you pass `console=ttyS0'? Is it not console=ttyS01 ? Friendly, Sven Luther ** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/ ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2004-01-22 1:01 UTC | newest] Thread overview: 7+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2004-01-20 5:34 local_irq_enable() problem Etsushi Kato 2004-01-20 10:03 ` Geert Uytterhoeven 2004-01-20 13:34 ` Etsushi Kato 2004-01-20 15:55 ` Hollis Blanchard 2004-01-21 9:51 ` Etsushi Kato 2004-01-22 1:01 ` Paul Mackerras 2004-01-20 13:49 ` Sven Luther
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).