On 23/03/2017, Arthur Heymans wrote:
>> I tried again, this time with SeaBIOS instead of GRUB2 as the primary
>> payload, and with CoreInfo as a secondary payload. As above, I
>> selected "Use native graphics initialization" under "Devices" within
>> `make nconfig`. (See
On Fri, Mar 24, 2017 at 2:15 AM, Berj K Chilingirian wrote:
> Hi,
>
> I was hoping to get some advice/guidance on how to disable the automatic
> refresh of the DRAM during the ROM stage of coreboot.
>
> I am booting an ASUS F2A85-M motherboard with a AMD A6-5400k processor
>
Berj K Chilingirian wrote:
> I was hoping to get some advice/guidance on how to disable the
> automatic refresh of the DRAM during the ROM stage of coreboot.
Reset the memory controller, or the entire platform.
Or, if you find no software solution, maybe you can use a fast FET or
logic gate on
Hi,
I was hoping to get some advice/guidance on how to disable the automatic
refresh of the DRAM during the ROM stage of coreboot.
I am booting an ASUS F2A85-M motherboard with a AMD A6-5400k processor (Trinity
core) using coreboot. The processor is initialized via the AGESA bootstrap
we've been using that. The minnowmax image is just weird. There is a Volume
nested in a Volume nested in a Volume ...
On Thu, Mar 23, 2017 at 2:40 PM Martin Roth wrote:
> I think you want ifdtool -n
>
> -n | --newlayout update regions using a flashrom layout
> file
>
I think you want ifdtool -n
-n | --newlayout update regions using a flashrom layout file
Martin
On Thu, Mar 23, 2017 at 3:03 PM, ron minnich wrote:
> the minnowmax has nested firmware volumes. We'd like to rearrange things now
> that the wonderful mecleaner has
the minnowmax has nested firmware volumes. We'd like to rearrange things
now that the wonderful mecleaner has freed up 3 meg :-)
anybody know of a tool that would let us do this rearrangement?
--
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot
the network is fine.
ron
On Thu, Mar 23, 2017 at 11:02 AM ron minnich wrote:
> I'll do that, thanks!
>
> On Thu, Mar 23, 2017 at 11:01 AM Patrick Georgi
> wrote:
>
> Ron, thanks for the report. Did you also check if the ethernet port is
> still
I'll do that, thanks!
On Thu, Mar 23, 2017 at 11:01 AM Patrick Georgi wrote:
> Ron, thanks for the report. Did you also check if the ethernet port is
> still functional?
>
> 2017-03-23 18:55 GMT+01:00 ron minnich :
> > just an FYI, I was not sure where
Ron, thanks for the report. Did you also check if the ethernet port is
still functional?
2017-03-23 18:55 GMT+01:00 ron minnich :
> just an FYI, I was not sure where else to tell people. But the mecleaner
> works!
>
> what a neat tool :-)
>
> --
> coreboot mailing list:
just an FYI, I was not sure where else to tell people. But the mecleaner
works!
what a neat tool :-)
--
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot
Hi Kory,
I'm not sure what the proprietary software is, but you're going to
want to use flashrom or a hardware flash tool instead of the
proprietary software to flash the ROM.
https://www.flashrom.org/Flashrom
And just since it always needs to be said:
You need to make sure you have a backup
Hi
>
> I tried again, this time with SeaBIOS instead of GRUB2 as the primary
> payload, and with CoreInfo as a secondary payload. As above, I
> selected "Use native graphics initialization" under "Devices" within
> `make nconfig`. (See attached .config .)
>
> The result was the same as above: the
Hi everyone,
I tried to flash Fujitsu D2990-A1 Board with winbound ROM with coreboot and
a coreinfo payload.
No probleme in compiling and adding the blobs.
But when I use the proprietary software with FreeDOS to flash the Bios I
have this error :
Error - No Board Information found in update file
Hello Peter,
You answered to Gailu instead of me, I do not object, just The Opposite!
I'll just add my thoughts to your reply (in *RED*).
Zoran
___
On Thu, Mar 23, 2017 at 2:46 PM, Peter Stuge wrote:
> Zoran Stojsavljevic wrote:
> > since BSW (including APL-I, former
Zoran Stojsavljevic wrote:
> since BSW (including APL-I, former BXT-I), there is ONLY USB 3.0 xHCI root
> hub.
It's too bad that EHCI has been removed.
The xHCI register model is broken in that it requires dedicated
hardware (registers) for each connected USB device, and Intel's xHCI
Hi Zoran,
Thanks for the detailed inputs. You are right we were using EHCI in BYT and
we used it with grub2 without any issue. If I understood it correctly the
usb 2.0 card I was planning to use over pcie is not going to work as we
can't mix with usb3.0 root hub, so not worth even trying that
On 22/03/2017, Sam Kuper wrote:
> On 22/03/2017, Sam Kuper wrote:
>> On 22/03/2017, Nico Huber wrote:
>>> Easiest option seems to be to select CONFIG_MAINBOARD_DO_NATIVE_VGA_INIT
>>
> Based on your suggestion above, I kept everything
> Current UEFI payload uses an generic emulated variable driver provided in
EDK2 MdeModulePkg.
Thank you for that info, Maurice. Was looking for this (right entry point)
for very long time! :-)
Zoran
On Thu, Mar 23, 2017 at 1:56 AM, Ma, Maurice wrote:
> Hi, Sibi,
>
>
>
>
Am 23.03.2017 08:10 schrieb "Matt DeVillier" :
that seems like the kind of functionality it would make sense to handle in
an abstracted way (perhaps using libpayload?)
How about importing flashrom for this purpose? It has drivers for pretty
much everything under the sun
Maurice,
that seems like the kind of functionality it would make sense to handle in
an abstracted way (perhaps using libpayload?) and let coreboot handle the
board-specific flash interface. Has anyone looked into that kind of
approach? This is something that's actually been on my to-do list for
Hi, Sibi,
Yes, UEFI payload follows the same way as standard UEFI FW on boot order
handling. You will have to enable a NVRAM variable driver in order to
maintain the boot options and order.
Current UEFI payload uses an generic emulated variable driver provided in EDK2
MdeModulePkg. With
22 matches
Mail list logo