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
> || ALPHA_EB64P || ALPHA_PC164 || ALPHA_TAKARA || ALPHA_EB164 || ALPHA_ALCOR
> || ALPHA_MIATA || ALPHA_LX164 || ALPHA_SX164 || ALPHA_NAUTILUS ||
> ALPHA_NONAME
> --------------------------------------------------------------------------
>
> 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;
#endif
#ifndef alpha_using_qemu
/* Similarly, look for QEMU. */
alpha_using_qemu = strstr((const char *)hwrpb->ssn, "QEMU") != 0;
#endif
...
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: