[Arm-dev] Gigabyte MP30-AR0
Gordan Bobic
gordan at redsleeve.org
Sat Mar 5 11:57:11 UTC 2016
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
More information about the Arm-dev
mailing list