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

Re: Gigabyte MP30-AR1 followup



Hi Phil,

  Apologies for a late reply.

  Let me, at least try to explain what we got to...

  We have BMC 3.62 and update machine to 3.64 firmware version, then
updated ROM to different versions from mp30ar1.D05.RBU to current
mp30ar1.D7b.RBU. There should be a DT attached to those ROM updates,
which has not worked for me so far, but ACPI boot works for me in the
following cases:
  [] ACPI must enabled in kernel (CONFIG_ACPI=y)
  [] initramfs is allocated in the initial 32GB RAM address (as
described by [trying to find the link in linux Documentation folder,
but I cannot find it right now])
     - we accomplish that with CONFIG_ARM64_VA_BITS_48=y, however that
breaks the userland
     ( https://lists.linaro.org/pipermail/cross-distro/2016-September/000851.html
)
     ( https://lists.linaro.org/pipermail/cross-distro/2016-August/000838.html )
     - at the moment, while userland is fixed, Debian kernel carries a
workaround to limit VA_BITS really to 47 bit
     ( https://anonscm.debian.org/cgit/kernel/linux.git/commit/?id=2d327101d18359f2c9b0e01a5c8aa62e0c8b44a5
)

  I recommended passing acpi=force, so ACPI boot is tried at first,
then fallback to try DT if it fails. However, a colleague reported
machine boots without passing acpi=force.

  All of the above (related to Debian kernel) should be enabled in >=
4.8~rc8-1~exp1 binary packages (currently in experimental). (But we
are really testing with a local build of 4.7~rc7-1~exp1+local.2, from
which I built a local custom debian-installer). So far I got to see
installer bits in the console and ipmi serial (I have no VGA access as
this is a machine managed remotely).

  So far I think Peter (weasel) has managed to install one of the two
machines we have at Debian, he attempted on the second one, but failed
lacking the BMC & ROM firmware updates.

  I think if you could compare Debian and Ubuntu configs for the
things you have working in ubuntu but not in Debian  would be a first
step forward.

  In summary I hope I have clarified some doubts on your side,
eventually once said kernel gets into unstable/testing,
debian-installer should be usable on the MP30-AR1.


Regards

2016-09-29 18:09 GMT+02:00 Phil Endecott <spam_from_debian_arm@chezphil.org>:
> 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.
>
>



-- 
 Héctor Orón  -.. . -... .. .- -.   -.. . ...- . .-.. --- .--. . .-.


Reply to: