On 19/02/16 21:29, Michael Howard wrote:
On 19/02/2016 20:20, Gordan Bobic wrote:
On 19/02/16 17:18, Michael Howard wrote:
On 19/02/2016 15:53, Gordan Bobic wrote:
On 2016-02-19 15:44, Michael Howard wrote:
On 19/02/2016 11:07, Gordan Bobic wrote:
<SNIP>
comes with OpenLinux built-in, with a 3.12
(3.12.0-mp30ar0_sw_1.18.04)
kernel which doesn't appear to be vanilla mainline. They also
provide
a Ubuntu image which uses the same kernel. The kernel is full
fat, no
external modules and I guess has firmware blobs built in as
CONFIG_FIRMWARE_IN_KERNEL=y and there is no /lib/firmware/.
Here's what I just heard back on the CentOS list:
https://lists.centos.org/pipermail/arm-dev/2016-February/001620.html
Have you tried it with the latest image?
Hi Gordon,
I'll give the latest image a go later and let you know how I get on,
I'm not sure whether I used the latest or not.
Thanks, looking forward to it. :)
I got a not very helpful reply or two from Gigabyte, quote;
"As mentioned, because we can only guarantee Linux to work fine with
this server motherboard, we cannot guarantee other operating system
work properly with it. As to the source code, since Linux is a open
source operating system, you can find the information online
individually.
Meanwhile, if you install other operating system, since we do not have
related utilities / firmware / BIOS for the operating system, it may
cause some problem while operating the system."
I had basically asked if I could have access to the kernel code they
used, any patches and if any binary blobs were used.
Right, so you know the kernel version in use. Is the .config provided
(either separately or via /proc/config.gz)? If so, you could always get
the clean kernel from kernel.org, apply the .config build it, and see
if it works.
I tried the latest kernel, it builds, using the config.gz form /proc as
a base, but I just get the old 'uncompressing kernel' (or similar) and
then nothing routine :) I've checked both outputs just in case. Only
had the single attempt though as I've been busy. I'll give the the 3
series kernel a go too.
How are you loading the kernel? Is the working kernel a uImage or
zImage? Is it being booted using boot or zboot command? If it is a
uImage, have you prepared the new kernel using mkimage?
The u-boot that comes with the board does not have bootz support. The
image(s) are prepared as uImage, using mkimage.
So it seems there is a step missing somewhere that is making booting the
kernel directly via u-boot fail. But UEFI supposedly works, and it can
be chain loaded from u-boot (so less risk of bricking the board by
burning untested UEFI straight into the flash):
https://lists.centos.org/pipermail/arm-dev/2016-February/001623.html
Does it work if you chainload Tianocore UEFI, then boot from there?
Gordan
_______________________________________________
users mailing list
[email protected]
https://lists.redsleeve.org/mailman/listinfo/users
