[Arm-dev] Gigabyte MP30-AR0

Sat Mar 5 11:57:11 UTC 2016
Gordan Bobic <gordan at redsleeve.org>

On 05/03/16 11:22, Richard W.M. Jones wrote:
> On Sat, Mar 05, 2016 at 11:12:00AM +0000, Michael Howard wrote:
>> On 05/03/2016 11:06, Richard W.M. Jones wrote:
>>> On Sat, Mar 05, 2016 at 10:26:25AM +0700, Phong Vo wrote:
>>>> There should be no issue of replacing U-boot in SPI nor with the mp30ar0
>>>> Tianocore version.
>>>> But you need to use the mp30ar0_tianocore_media.img I provide, not the one
>>>> supplied
>>>> with the Mustang board. It was likely the person burn the wrong BIOS on
>>>> the board!
>>>>
>>>> You can burn the Tianocore image from U-boot using TFTP. Please check and
>>>> setup your U-boot
>>>> variables:
>>>>
>>>> media_addr_r=0x4001000000
>>>> media_img=mp30ar0_tianocore_media.img
>>>> spi_load=tftp ${media_addr_r} ${user_dir}/${media_img}
>>>> spi_update=sf probe 0; sf erase 0x0 ${filesize}; sf write ${media_addr_r}
>>>> 0x0 ${filesize}
>>>>
>>>> # run spi_load   <== Make sure it is successful
>>>> # run spi_update
>>>> # reset
>>>>
>>>> If there is any issue, it's still recoverable using SD card.
>>> As a warning to anyone else, that bricked mine.
>>>
>> Since your post yesterday? Did u-boot chainload UEFI ok prior to
>> attempting the permanent change?
>
> Chainloading UEFI worked (albeit tedious and slow and requiring a
> network connection).

Can you not chainload off local media? For example, a FAT partition is 
needed for UEFI anyway, so is there a good reason it isn't possible to 
put the UEFI image onto that partition (or any other partition that 
u-boot can read) and chain load it from there? If so, I am struggling to 
think of a reason why anybody would want to be booting UEFI straight 
from the ROM instead of u-boot. I might save a couple of seconds off the 
boot time, but u-boot is far more flexible and powerful than UEFI.

> I wanted to permanently get rid of u-boot because I want to see if we
> can turn these boards into real (SBSA/SBBR) server hardware that can
> run RHEL.

Would putting UEFI image for chainloading onto the SD card not fulfill 
this requirement without the loss of flexibility incurred by losing the 
1st stage u-boot loader?

> I'm just going through the SD card recovery procedure now -- section
> 2.7 of the Software Reference Guide.  Will report back ...

I hope it works out, please let us know.

Gordan