boot process

[Rafał Jaworowski]

On 2009-02-28, at 17:45, Aleksey V Fedorov wrote:

> On Fri, 27 Feb 2009, Rafal Jaworowski wrote:
>
>> I quickly looked at the manual and noticed the 8548 has a different  
>> number of
>> local access windows than the default 8. Please try to set law_max  
>> to 10 in
>> ocpbus_probe().
>
> I make this changes:

So did adjusting the LAW number help with the hang your previously  
reported, or was it something else?

>>> Is it normal that "decrementer" frequency is 0 ?
>>
>> This isn't good, are you sure a proper value is given to  
>> decr_config()?
>
> Hmm. With decr_config(0) kernel is booted, but with actual CCB clock  
> 533000000 kernel silently hang somethere in kdb_init() or "data  
> storage interrupt" occured.

Please show the DSI trap details, preferrably with back trace from KDB  
(type 'tr' if it breaks into the debugger prompt).

You shouldn't use CCB clock directly. In current setup the decrementer  
is synchronized with Time Base, which  is updated every 8 CCB ticks,  
hence:

decr_config(bootinfo->bi_bus_clk / 8);

> setting up elf image... OK
> jumping to kernel code
> GDB: no debug ports present
> KDB: debugger backends: ddb
> KDB: current backend: ddb
> L1 D-cache enabled
> L1 I-cache enabled
> Copyright (c) 1992-2009 The FreeBSD Project.
> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993,  
> 1994
>        The Regents of the University of California. All rights  
> reserved.
> FreeBSD is a registered trademark of The FreeBSD Foundation.
> FreeBSD 8.0-CURRENT #13: Sat Feb 28 19:30:25 MSK 2009
>    root at servd.vsi.ru:/usr/obj/powerpc/usr/current/src/sys/MPC85XX
> Timecounter "decrementer" frequency 0 Hz quality 0

For example, one of my systems, with 330MHz CCB shows:

Timecounter "decrementer" frequency 41250000 Hz quality 0

> cpu0: Freescale e500v2 core revision 2.0
> cpu0: HID0 80000000<EMCP>
> real memory  = 520077312 (495 MB)
> Physical memory chunk(s):
> 0x01000000 - 0x1f713fff, 510738432 bytes (124692 pages)
> avail memory = 508682240 (485 MB)
> null: <null device, zero device>
> random: <entropy source, Software, Yarrow>
> nfslock: pseudo-device
> mem: <memory>
> nexus0: <MPC85xx Nexus device>
> ocpbus0: <On-Chip Peripherals bus> on nexus0
> ocpbus0: PORDEVSR=82b9ea67, PORDEVSR2=8f000079
> uart0: <Non-standard ns8250 class UART with FIFOs> iomem  
> 0xfef04500-0xfef0450f irq 58 on ocpbus0

The uart type recognized seems bogus, it should be a regular 16550:

uart0: <16550 or compatible> iomem 0xfef04500-0xfef0450f irq 58 on  
ocpbus0
uart0: [FILTER]
uart1: <16550 or compatible> iomem 0xfef04600-0xfef0460f irq 58 on  
ocpbus0
uart1: [FILTER]
uart1: console (115223,n,8,1)

> uart0: [FILTER]
> uart0: fast interrupt
> uart0: console (9600,n,8,1)

Is 9600 the real console speed? In your original Linux log there was  
115k value AFAIR.

I tend to think the source of these problems is misconfigured  
decrementer/time base on your system: among other things, the delay  
routine does not work properly and uart(4) probing and baud rate  
calculation code gets confused (of course, there will also be other  
serious problems if time counting does not work properly).

Rafal