[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Kernel does not boot on TT030

Am 06.04.19 um 16:32 schrieb Eero Tamminen:

On 8/30/18 8:31 AM, Stefan Niestegge wrote:
Ah, ok. We will try that.

Did you ever get kernel booting on TT?

Nope, sadly we didn't get it running at all on TT030 or Mega with PAK030
no matter what bootargs we tried.

I've now looked a bit into this with Hatari TT emulation.

"initcall_debug" doesn't give any output, but I've enabled the dummy
IRQ handler [1] and get constant warnings from it.  There's quite
a lot of them in few seconds:
$ grep unexpected tt-boot.log | sort | uniq -c
    1200 unexpected interrupt from 104
     212 unexpected interrupt from 112

Any idea what those interrupts are for?

FYI: When I enable profiler at start and invoke debugger after
a while, it gives me following kernel backtrace:
Finalizing costs for 12 non-returned functions:
- 0x46fba: console_unlock (return = 0x47932)
- 0x4781c: vprintk_emit (return = 0x47966)
- 0x4794a: vprintk_default (return = 0x4835c)
- 0x482e4: vprintk_func (return = 0x48016)
- 0x48004: printk (return = 0x585c)
- 0x5834: handle_badint (return = 0x29a0)
- 0x29a8: resume (return = 0x24b2d4)
- 0x24afd0: __schedule (return = 0x24b364)
- 0x24b31a: schedule (return = 0x24b3dc)
- 0x24b3d2: schedule_preempt_disabled (return = 0x24a07a)
- 0x24a008: rest_init (return = 0x318f64)
- 0x318f88: start_kernel (return = 0x318344)

Attached is dot callgraph [2] of the function call counts from
first instruction until above point.

Good tool to view it is XDot (from "xdot" package).  Red lines
in the graph show which functions get called most often.

(I thought call counts are for this case more interesting than
instruction or cycle counts.)

     - Eero

Thanks for looking into it again!


[1] $ grep IRQ .config

[2] Command line to get graph from the Hatari profiler readable
requires removing edges to generic low level functions:
$ hatari_profile.py -s -t -p -g -a System.map \
   --only-subroutines --no-intermediate --compact \
   --ignore-from __start,copy_process.isra.11.part.12 \
  --ignore-to memcpy,memset,memmove,memcmp,strlcpy,strlen,strchr,strncmp,kstrdup_const,mutex_lock,mutex_unlock,__mutex_init,__init_rwsem,__init_waitqueue_head,__ashldi3,__lshrdi3,__list_add_valid,__list_del_entry_valid,__alloc_percpu,d_alloc,__d_alloc,__kalloc,__kmalloc,kfree,new_slab,alloc_workqueue_attrs,kmem_cache_alloc,memblock_alloc_try_nid,kmem_cache_create,hwreg_present,__sw_hweight32,printk   profile.txt

Am 30.08.2018 um 00:34 schrieb Michael Schmitz:
Quick clarification - stram_pool is only required if the kernel gets
loaded to TT-RAM (no -s option).



On Wed, Aug 29, 2018 at 8:30 PM Michael Schmitz <schmitzmic@gmail.com> wrote:

Hi Stefan,

Am 29.08.2018 um 01:00 schrieb Finn Thain:
On Tue, 28 Aug 2018, Stefan Niestegge wrote:

the kernel does not start up and run the D-I from the initrd. A serial
terminal was connected to one TT, but all it received was "ABCDEJK".

If you have CONFIG_EARLYPRINTK=y then you can enable the early console. Try passing the kernel parameter 'earlyprintk'. That should cause kernel
messages to be sent to the same device(s) to which "ABCDEJK" was sent.

I have the following options set to direct console messages to the
serial port:

debug=ser console=tty

'debug=ser' uses the MFP Modem1 port on TT, the SCC Modem2 port on
Falcon. Use debug=ser2 if you want to force use of the SCC port on TT.
Messages appearing there mean the boot process has made it out of early
startup code which I'd expect for a TT.

No idea about any interactions with earlyprintk, sorry.

Option 'stram_pool=128k' might also be required to reserve ST-RAM for
use by drivers that can only address 24 bit (not sure if that's a
problem with the TT video driver).

Once you have console messages on the serial port, the option
'initcall_debug' may be useful to pinpoint where the boot hangs. My
guess would be during probing for optional stuff such as ROM port or
CT60 expansion network card hardware in atari_platform_init(), unless
your kernel contains commit 3f90f9ef2dda316d64e420d5d51ba369587ccc55
(m68k/mm: Adjust VM area to be unmapped by gap size for __iounmap())
that fixed ioremap/iounmap use on 030. Should be in from 4.17-rc6 on.

Reply to: