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

Re: PALO issue



Hi Frank,

On 07.12.18 19:42, Frank Scheiner wrote:
> some time ago I noticed a minor issue with palo (confirmed with v2.0
> but maybe already existing in earlier versions) and finally find the
> time to report it:
> 
> When booting a rp3440 and interacting with IPL or booting a 712/80
> with `bo [...] isl` an then waiting at the palo prompt for a few
> minutes or so before actually changing parts of the kernel command
> line and boot (with `b`) or just boot, the boot process seems to hang
> for minutes before the machine is reset instead of booting the actual
> kernel.
> 
> Example (rp3440):
> ```
> [...]
> Main Menu: Enter command or menu > bo
> Interact with IPL (Y, N, or Cancel)?> y
> 
> Booting...
> Boot IO Dependent Code (IODC) revision 4
> 
> 
> HARD Booted.
> palo ipl 2.00 http://www.parisc-linux.org - Mon, 01 Jan 2018 21:07:58 +0100
> 
> Boot image contains:
>     0/vmlinux64 3937664(0) bytes @ 0xc000
>     0/ramdisk 4347450 bytes @ 0x3cd800
> 
> Information: No console specified on kernel command line. This is normal.
> PALO will choose the console currently used by firmware (serial).
> WARNING: Found rp34x0 machine. Older Linux kernel may need console=ttyS1.
> Current command line:
> 0/vmlinux HOME=/ root=/dev/ram initrd=0/ramdisk TERM=vt102 console=ttyS0
>  0: 0/vmlinux
>  1: HOME=/
>  2: root=/dev/ram
>  3: initrd=0/ramdisk
>  4: TERM=vt102
>  5: console=ttyS0
> 
> <#>    edit the numbered field
> 'b'    boot with this command line
> 'r'    restore command line
> 'l'    list dir
> 'x'    reset and reboot machine
> ? 0
> <waited a few minutes before changing `0` to `b`>
> ? b
> 
> Command line for kernel: 'HOME=/ root=/dev/ram TERM=vt102 console=ttyS0 palo_kernel=0/vmlinux'
> Selected kernel: /vmlinux from partition 0
> Selected ramdisk: /ramdisk from partition 0
> Warning: kernel name doesn't end with 32 or 64 -- Guessing... Choosing 64-bit kernel
> <multiple minutes in between without any outpout>
> pdc_iodc_bootin() died during seekread
> 
> Resetting machine.
> ```
> 
> The following should actually happen after issuing `b`:
> ```
> [...]
> Command line for kernel: 'HOME=/ root=/dev/ram TERM=vt102 console=ttyS0 palo_kernel=0/vmlinux'
> Selected kernel: /vmlinux from partition 0
> Selected ramdisk: /ramdisk from partition 0
> Warning: kernel name doesn't end with 32 or 64 -- Guessing... Choosing 64-bit kernel
> ELF64 executable
> 
> Entry 000e0000 first 000e0000 n 2
> Segment 0 load 000e0000 size 1080 mediaptr 0x1000
> Segment 1 load 01300000 size 3922892 mediaptr 0x2000
> Loading ramdisk 4347450 bytes @ 3fbc9000...
> Branching to kernel entry point 0x000e0000.  If this is the last
> message you see, you may need to switch your console.  This is
> a common symptom -- search the FAQ and mailing list at parisc-linux.org
> 
> Uncompressing ...
> Booting kernel ...
> [    0.000000] Linux version 4.16.0-2-parisc64-smp (debian-kernel@lists.debian.org) (gcc version 7.3.0 (GCC)) #1 SMP Debian 4.16.12-1 (2018-05-27)
> [...]
> ```
> 
> Output and result are practically the same on the 712/80.
> 
> As said earlier, it's no big problem, but one shouldn't leave for making a tea or so when planning to interact with IPL. :-)

I think this can happen e.g. if you boot from Network via TFTP.

First the firmware IODC opens network connection and asks the tftpboot server
to provide the file. The first part of the file has the palo boot code which
is then executed.
When palo has started, it rewinds the file to the start and reloads the first
sectors to get the offsets for vmlinux and ramdisk.
After that it jumps to the loop which interacts with the user until he pressed "b"
to continue booting.

If you wait a few minutes until you continue booting, I assume
the tftpboot server (and the parisc box) will kill the network 
connection in the meantime. That's the reason why you see:
 
> <multiple minutes in between without any outpout>
> pdc_iodc_bootin() died during seekread

seekread() is the rewind-function and pdc_iodc_bootin() is the palo 
function which reads in the bytes.

So, I don't think there is much in palo what can be done about that.
 
Have you seen this issue when booting from hard disc too?

Helge


Reply to: