[Arm-dev] Gigabyte MP30-AR0

Mon Feb 22 16:37:04 UTC 2016
Michael Howard <mike at dewberryfields.co.uk>


On 22/02/2016 15:36, Gordan Bobic wrote:
> On 2016-02-22 15:30, Michael Howard wrote:
>> On 22/02/2016 14:42, Gordan Bobic wrote:
>>> On 2016-02-22 14:26, Michael Howard wrote:
>>>> On 22/02/2016 11:50, Gordan Bobic wrote:
>>>>> It seems a little odd that the installer would put the kernel 
>>>>> somewhere
>>>>> other than the target installation disk. Having UEFI on-board I can
>>>>> understand, but shouldn't the boot sequence in this case be:
>>>>>
>>>>> 1) u-boot (on-board)
>>>>> 2) UEFI (wherever u-boot can fetch it from)
>>>>> 3) grub (off the UEFI FAT partition on the target disk)
>>>>> 4) Kernel (/boot partition)
>>>>>
>>>>> Is there a good reason for deviating from this?
>>>>>
>>>>
>>>> Ok, reinstalling the original u-boot resolves the onboard kernel
>>>> issue, that is, the board now boots to OpenLinux  again when no other
>>>> devices are attached.  So the 'Applied Micro Linux 3.12.0 (aarch64)'
>>>> kernel is part of their (Gigabyte's) u-boot image.
>>>
>>> Right, so now that UEFI is working, it seems the next thing to do
>>> is to get grub2 loading from UEFI. From there on it should be
>>> trivial to get a sensible kernel booting.
>>>
>>
>> Ok, some strangeness happening here. It seems it wasn't the centos
>> installer that caused the issue of the board not booting to OpenLinux
>> afterall. Having reinstalled u-boot and confirmed the board booted to
>> OpenLinux, I chainloaded UEFI once more (using the instructions from
>> Phong Vo) in order to try manually booting centos. I couldn't
>> immediately see how to do that so I reset the board and now back to
>> non booting board. Go figure.
>>
>>> I do find it baffling that the installer that requires UEFI would
>>> do something so fundamentally different in terms of configuring
>>> the boot process compared to the x86 method of doing it.
>>>
>>
>> I guess it doesn't afterall.
>>
>>> Hmm... I wonder... Did you create a 250MB FAT partition on the
>>> disk of type EF00 (GPT), for the UEFI boot loader part (the
>>> stuff that ends up in /boot/efi)?
>>
>> Well, this installer is completely new to me. At the opening screen of
>> the text install I had to select various aspects of the install before
>> it would let me proceed. One of which is the selection of the install
>> disc and how it should be partitioned. I changed from LVM to basic
>> partitioning and an efi partition was reported to have been created.
>> Once the install began, there was no requirement for further user
>> interaction.
>
> Hang on, you mean the installer in this case is text based anaconda,
> rather than GUI?
>

Yes, that's correct. The installer has problems with network also, in 
that it doesn't find a 'link up' on any port. Hence it won't start vnc 
installer either.

As mentioned, my accusation about the installer overwriting the onboard 
kernel was way off mark, although something (chainloading EFI?) does.

Anyway, the install does in fact succeed, which is great. I probably 
should have stuck with the LVM partitioning scheme but hey ho, I can re 
run things now that I know UEFI is working.

So, I have a minimal CentOS install with 4.2.0-0.21.el7.aarch64 kernel. 
Great start, thanks to all.

There is no networking so I need to get the installer to recognise the 
nics at install time.

Cheers,

-- 
Mike Howard