[Arm-dev] Gigabyte MP30-AR0

Fri Mar 11 13:11:29 UTC 2016
Michael Howard <mike at dewberryfields.co.uk>

On 11/03/2016 13:04, Gordan Bobic wrote:
> On 2016-03-11 12:58, Michael Howard wrote:
>> On 11/03/2016 10:38, Gordan Bobic wrote:
>>> On 2016-03-11 10:31, Michael Howard wrote:
>>>> On 10/03/2016 13:47, Gordan Bobic wrote:
>>>>> On 2016-03-10 13:39, Karanbir Singh wrote:
>>>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>>>> Hash: SHA1
>>>>>>
>>>>>> On 09/03/16 21:11, Jeremiah Rothschild wrote:
>>>>>>> On Fri, Mar 04, 2016 at 02:05:08PM +0000, Michael Howard wrote:
>>>>>>>> On 04/03/2016 11:47, Richard W.M. Jones wrote:
>>>>>>>>> On Sat, Feb 20, 2016 at 11:06:08AM +0700, Phong Vo wrote:
>>>>>>>>>> In theory, you just need to convert CentOS vmlinuz to uImage,
>>>>>>>>>> then do U-boot boot using the dtb and CentOS initrd.img; but
>>>>>>>>>> somehow it hangs on me. I'll need to dig into it further.
>>>>>>>>>>
>>>>>>>>>> I am not aware that it was shipped only with U-boot. If you
>>>>>>>>>> want to try with UEFI, take it from my dropbox
>>>>>>>>>>
>>>>>>>>>> https://dl.dropboxusercontent.com/u/20403943/mp30ar0_tianocore_bina 
>>>>>>>>>>
>>>>>> ries.tar.xz
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>> mp30ar0_tianocore_media.img: burn to SPI NOR if you want to 
>>>>>> replace U-bo
>>>>>> ot
>>>>>>>>>> permanently
>>>>>>>>> Has anyone tried this step ^^ (replacing u-boot permanently)?
>>>>>>>>>
>>>>>>>>> I'm not too keen to brick an $800 board.  Is it reversible?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> No, not tried it, don't see the point of risking it at the mo.
>>>>>>>> Somebody did brick their board
>>>>>>>> (https://lists.centos.org/pipermail/arm-dev/2016-February/001622.html 
>>>>>>>>
>>>>>> )
>>>>>>>>
>>>>>>>>
>>>>>> and for me, I just chainload tianocore from u-boot via tftp.
>>>>>>>
>>>>>>> Indeed - that was me! Fun times. I'm all up & running on CentOS 7.2
>>>>>>> now, though, thanks to the help of you fine folks on here.
>>>>>>>
>>>>>>> One thing I did change was to not boot via TFTP since I'd rather
>>>>>>> not have booting dependent on network availability. Instead I'm
>>>>>>> loading via SD. It was pretty straight forward but, in case anyone
>>>>>>> else is interested, I replaced the load_tianocore variable like so
>>>>>>> (assuming dev 0, part 1):
>>>>>>>
>>>>>>> setenv load_tianocore 'fatload mmc 0:1 0x82000000
>>>>>>> mp30ar0_tianocore_ubt.fd; fatload mmc 0:1 0x1d000000
>>>>>>> mp30ar0_tianocore_sec_ubt.fd'
>>>>>>>
>>>>>>> Stoked. Thanks again, guys!
>>>>>>
>>>>>> I was wondering if one of you guys might be willing to own/submit a
>>>>>> wiki page article around this board, howto get rolling with 
>>>>>> CentOS etc ?
>>>>>
>>>>> I was planning to do just that this weekend when I get mine up and
>>>>> running. :-)
>>>>>
>>>>> I am very much in favour of the way Jeremiah has his set up, though.
>>>>> Having u-boot as the stage 1 bootloade before TianoCore UEFI adds a
>>>>> lot more flexibility at the relatively trivial expense of adding a
>>>>> seconds or two to the boot time.
>>>>>
>>>>
>>>> 5 seconds only to be precise, at least on my board :)
>>>
>>> Is that because the interactive boot keypress timeout on u-boot
>>> defaults to 5 seconds? I ask because that is actually adjustable. :-)
>>>
>> :) no, that was just coincidence. I was actually referring to 5 secs
>> being the difference between tftp and mmc loading. I haven't burned
>> UEFI permanently.
>
> Oh, I see. I was always intending to have UEFI on MMC. I only ever
> use TFTP when setting up diskless machines with NFS root or for
> unbricking.
I'll be using mmc in this case too, despite it being a tad slower, as my 
stupid netgear switches don't not like LAG(Port Trunking) outside of an OS.

-- 
Mike Howard