Gigabyte MP30-AR1 followup
Dear All,
I thought I should post a followup about this board. Sorry for
the bits that sound ranty, I have to share with someone!
Following Hector's advice I built a Debian kernel with his suggested
config changes (CONFIG_ACPI=y and CONFIG_ARM64_VA_BITS_48=y), and
set acpi=force on the kernel command line. My first attempt was
with 4.8.0-rc5 which didn't work, apparently something to do with
the initrd being truncated I think:
[ 0.000000] initrd not fully accessible via the linear mapping -- please check your bootloader ...
(snip lots)
[ 2.733880] List of all partitions:
[ 2.737362] No filesystem could mount root, tried:
(snip more)
[ 2.830824] ---[ end Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
A 4.7.2 kernel, however, did boot with the same configuration -
hurray! But it doesn't display a VGA console. For some reason the
Ubuntu 4.4.0 kernel does; I don't know what the difference is.
(Keyboard input works.)
Apart from that the other thing that isn't working is I2C. I think
I need to make this work in order to access temperature and fan
sensors. The board has a separate baseboard management controller
(BMC) chip and I think the sensors are connected to that, and accessible
from the main processor via IPMI over an I2C connection. Or maybe
not; there is also something called "SLIMpro" (which is not a diet
food, as Google thinks). I think this is another microcontroller
on the main processor chip, which also has an I2C connection, and
has something to do with power, clocks etc; it has its own kernel
driver. Or maybe the SLIMpro has a connection to the main processor
and the external I2C connection to the BMC goes via the SLIMpro.
Anyway neither works, and I spent a stupidly long time debugging
this... I'll skip the rant except to set two challenges for those
of you who think you're good at reading kernel code:
(1) What do you have to do to activate the pr_debug in
mbox_request_channel() in linux/drivers/mailbox/mailbox.c ?
(2) What does if (!dev->of_node) { return some_error; } imply?
Having worked out the answers, my conclusion is that this driver
does not have any chance of working with ACPI.
So... why was I using ACPI anyway? It turns out that this 4.7.2
kernel DOES work in device tree mode, i.e. without acpi=force on
the kernel command line. (At least, it seems to work equally as
well as in ACPI mode.) I was using ACPI because the CentOS kernel,
which did seem to work, was using ACPI, and because Hector mentioned
a bug in the device tree in the Gigabyte firmware. (Hector, do
you have any references regarding this bug?).
Anyway, in device tree mode the SLIMpro driver does seem to bind
to a device - but I still don't get any /dev/i2c devices. I
think I should, because some Gigabyte documentation talks about
using the bmc_info command from FreeIPMI, passing /dev/i2cN as
an argument to it. That's on the Linux that they supplied on the
flash along with U-Boot on the -AR0 version of the board. So I
thought I'd try to boot that; source and binaries are available.
It hasn't worked yet; firstly I had to convert the U-Boot format
uImage and uRamdisk to vmlinux and initrd files that GRUB would
understand; I tried to do that using dumpimage from u-boot-tools.
That fails to boot, but it could be due to the same "no VGA"
issue that I get with the Debian kernels (except that the serial
console also doesn't work, even earlycon). Or maybe dumpimage
hasn't done what I want, or maybe it doesn't like starting from
the EFI environment, or maybe something else. I also tried
with that kernel built from source (it's a presumably-patched
3.12) and it also entirely fails to start.
I'm a bit stuck now. I do want to get the thermal and fan stuff
to work because I've put the board in a 1U case and modified the
CPU fan to make that work sensibly, and I need to know if it's
going to melt. Also I no longer have access to the BMC's web
interface because I changed a setting from "dedicated network
port" to "shared network port", and the latter doesn't actually
seem to work on this board. So I'd like to be able to reset the
BMC's network settings, which I think should be possible using
the I2C IPMI connection.
One final comment - reboots are horribly slow, as the UEFI
implementation takes several minutes to start up. It would be
great if I could used kexec to bypass this wait. I found a bug
that Martin filed about this with a link to a patch, but that
didn't work and looks like it's still a work in progress. Is
anyone aware of any updates?
Thanks for reading!
Cheers, Phil.
Reply to: