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

Re: can't boot kernel 4.x on SX164

On Tue, Mar 01, 2016 at 03:51:57PM -0500, Alex Winbow wrote:
> On Fri, 26 Feb 2016, Michael Cree wrote:
> >>	Success with kernel 4.4.2, built entirely using the Debian package
> >>configuration options with only two changes: machinetype set from generic to
> >>SX164, and CONFIG_ALPHA_SRM=y.
> >>	Obviously I'm thinking that CONFIG_ALPHA_SRM may be highly significant
> >>here!
> >Yeah, I'm not convinced.  Looking at the kernel Kconfig description it
> >appears to me that CONFIG_ALPHA_SRM allows one to boot directly from SRM,
> >i.e., bypassing a bootloader such as aboot.  Looking at the kernel source
> >it appears to me that CONFIG_ALPHA_SRM is in effect enabled when building
> >a generic kernel.
> >I'll do some testing to see if we can narrow it down to whether it
> >is building for a generic kernel that's the problem, or whether it is
> >indeed the CONFIG_ALPHA_SRM option.
> Hi, Michael,
> 	I went to test this myself (setting system type to generic instead of
> setting ALPHA_SX164=y, and test for kernel start), and couldn't find
> CONFIG_ALPHA_SRM. It appears that setting is not exposed by kconfig *unless*
> you set a system type.
> 	Looking in the kernel source under arch/alpha/Kconfig, I see:
> --------------------------------------------------------------------------
> config ALPHA_SRM
>         bool "Use SRM as bootloader" if ALPHA_CABRIOLET || ALPHA_AVANTI_CH
> --------------------------------------------------------------------------
> 	Do you think this behavior is correct?

All the code in the kernel that uses CONFIG_ALPHA_SRM says ALPHA_SRM
or GENERIC, so as long as either ALPHA_GENERIC or ALPHA_SRM is true,
you get the result you want.

One difference though is that if you set CONFIG_ALPHA_SRM, then
there is a hardcoded #define of alpha_using_srm 1, whre as if you use
CONFIG_ALPHA_GENERIC, it calls a function at boot in setup_arch to try
to determine if it is booted from SRM:

#ifndef alpha_using_srm
        /* Assume that we've booted from SRM if we haven't booted from MILO.
           Detect the later by looking for "MILO" in the system serial nr.  */
        alpha_using_srm = strncmp((const char *)hwrpb->ssn, "MILO", 4) != 0;
#ifndef alpha_using_qemu
        /* Similarly, look for QEMU.  */
        alpha_using_qemu = strstr((const char *)hwrpb->ssn, "QEMU") != 0;

So if somehow that detection doesn't work, then you could get a
difference in behaviour between CONFIG_ALPHA_SRM and CONFIG_ALPHA_GENERIC.
Everything else appears to be identical.

Looking at the code above, it looks as if booting QEMU would result in
alpha_using_qemu = 1 and alpha_using_srm = 1, while booting real hardware
with MILO would give alpha_using_qemu = 0 and alpha_using_srm = 0 and real
hardware from SRM would give alpha_using_qemu = 0 and alpha_using_srm = 1.
I wonder if that could be a problem under QEMU.  A quick glance through
the places that care about those two variables don't appear to have any
issues, but I didn't check carefully.

Len Sorensen

Reply to: