Hello,
I have a Minnowboard Turbot (dual core E3826) and was only able to get it
up and running after finding microcode M0130679901 from patch 30679 (
https://www.intel.com/content/www/us/en/embedded/products/bay-trail/software-and-drivers.html
).
I was wondering if someone from Intel would mind a
The ASUS KGPE-D16 fails verification for branch master as of commit
ba973bd2de8bf91cc83431333519124bf0f1fd72
The following tests failed:
BOOT_FAILURE
Commits since last successful test:
ba973bd util/abuild: Set exit status on failure
6c1c9d5 Update vboot submodule to upstream master
8f1e1bd Upda
Hello,
im currently following the "Build_Howto" instructions for Coreboot for a
Lenovo X1 Carbon 1gen (3460) and do have a Question: Do ich have to
check "Use native Graphics init", and if not, which one is the correct
configuration?
Sorry for my horrible english,
cheers and greetings from Germany
you want to extract the refcode blob as so:
cbfstool shellball.rom extract -r BOOT_STUB -n fallback/refcode -f
refcode.elf -m x86
then add it into your build
On Mon, Jul 31, 2017 at 8:43 AM, Zheng Bao wrote:
> Thanks. That really helps.
>
>
> About the REFCODE_BLOB, the BLOB I extracted from b
if you count chromebooks as the majority of ports, which may be a fair
claim, no it's not.
On Mon, Jul 31, 2017 at 9:38 AM taii...@gmx.com wrote:
> I thought SMI/SMM was disabled in the majority of coreboot ports?
>
> --
> coreboot mailing list: coreboot@coreboot.org
> https://mail.coreboot.org/
I thought SMI/SMM was disabled in the majority of coreboot ports?
--
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot
Slide:
https://recon.cx/2017/montreal/resources/slides/RECON-MTL-2017-DiggingIntoTheCoreOfBoot.pdf
Speaking of attack surfaces reduction at runtime, this script might be
a workaround:
https://github.com/hardenedlinux/Debian-GNU-Linux-Profiles/blob/master/scripts/harbian_fw/fw_hardening_runtime.py
Thanks. That really helps.
About the REFCODE_BLOB, the BLOB I extracted from ball-rom is BIN, instead of
ELF which is required by current CBFS and rmodule in source. (And revision in
ball-rom is not in main tree of repository.)
Any idea to get REFCODE_BLOB?
Thanks.
Zheng
2017-07-31 14:46 GMT+02:00 Nico Huber :
> No idea about the kernel's requirements
Windows 7's kernel uses int10 calls for checking out various graphics
properties, even when booting with UEFI (and therefore GOP drivers
better put some int10 handler in the right place if they want to
continue to sup
On 31.07.2017 13:48, Philipp Stanner wrote:
> Well, many thanks.
>
> I didn't expect it to work that way. Would be interesting to know what
> Windows 7 needs BIOS calls for.
It seems to be their policy to have a boot loader (and probably kernel)
that can't work on its own. So Windows (including c
Well, many thanks.
I didn't expect it to work that way. Would be interesting to know what
Windows 7 needs BIOS calls for.
Any idea of traditional IBM-PC-Bios-calls are still available in
UEFI-Firmware?
On 31.07.2017 11:43, Patrick Georgi via coreboot wrote:
2017-07-31 10:52 GMT+02:00 Phil
Hi Zheng,
On 30.07.2017 16:13, Zheng Bao wrote:
> I have got the mrc.bin and mem init has got passed.
> Now the new problem is that it hangs at VGA init.
>
> static void igd_setup_panel(struct device *dev)
> {
> config_t *conf = dev->chip_info;
> u32 reg32;
>
> /* Setup Digital Port Hotplug */
2017-07-31 10:52 GMT+02:00 Philipp Stanner :
> 1. cb switches the CPU immediately to Protected Mode, yet Payloads like
> seaBIOS work in Real Mode. Does coreboot switch the CPU always back to RM
> before jumping to the payload?
No, payloads are started in pmode.
> 2. When CB switches to PM - who
Dear folks and techpriests,
the more I want to contribute and learn about low-level-code the less I
understand, it seems.
1. cb switches the CPU immediately to Protected Mode, yet Payloads like
seaBIOS work in Real Mode. Does coreboot switch the CPU always back
to RM before jumping to th
14 matches
Mail list logo