if your G505S does NOT have a discrete GPU (= LA-A092P board), please test this coreboot build
by Mike Banon
I almost completed refining the HJK's dGPU patches and discrete GPU is
still working at my G505S after these changes, but before submitting
the patches I would like to make sure that they are not breaking the
things for G505S without a discrete GPU. So if you have some free time
and ready to "unbrick" by the hardware flashing - although I hope the
things would go well ! - please help me by testing this coreboot build
at your G505S:
https://github.com/informer2016/shared_devfiles/blob/master/coreboot.rom
SHA256 sum of this image =
ab173394ba3ed57a73d1455a02f7d903a5f5c55a0ab5ba43b4c445e4eeeead20
Download this image, run sha256sum ./Downloads/coreboot.rom , and if
it is correct - please flash it by executing
sudo ./flashrom -p
internal:laptop=force_I_want_a_brick,amd_imc_force=yes -w
./coreboot.rom
- according to http://dangerousprototypes.com/docs/Lenovo_G505S_hacking
instructions -
then shutdown and try turning it on. It could take up to minute for
G505S to boot because of high debug level and USB debug enabled, so
wait patiently. After it reaches the SeaBIOS screen, press ESC and
choose your Linux USB or HDD to boot from - otherwise the
first-in-the-list floppy OS (MichalOS, btw it has a cool PLAYER .APP
-> Piano) will be booted by default.
If it could boot to Linux, clone the coreboot repository (if you
haven't already) and get the logs:
cd ./coreboot/util/cbmem
make
sudo ./cbmem -c > ./console.log
and also
sudo dmesg > ./kernel.log
Remove the private information from these logs (such as your MAC
addresses from kernel.log or USB model from console.log) and share
these logs with me - I would like to take a look to see that there
aren't any new angry messages. Also try S3 suspend (aka
"hibernation"), see if it could resume successfully to Linux and
report the results.
If it could not boot to Linux and you don't have a FT232H or another
debug dongle to capture the logs by USB, just tell me it didn't work
and unbrick by following the hardware flashing instructions. Then I'll
try to add more precautions...
17 minutes
Coreboot Self-Flashing Through Payload?
by Matt B
Hi,
I was helping a friend with a bios issue (we may have an involuntary
coreboot convert on our hands ;) ) and realized that a lot of BIOSs provide
a way for the BIOS to flash itself but Coreboot doesn't.
For Coreboot afaik the only two methods available are to flash with a
programmer or to flash internally from linux with iomem=relaxed. For most
proprietary BIOSs, you can boot a utility that knows what USB drives are
and flash from there.
What I'm thinking of trying, and would appreciate feedback on, is the idea
of making a Seabios floppy image specifically intended for flashing
Coreboot.
I figure this has a few advantages:
-It's OS-agnostic, meaning you can reflash the BIOS regardless of what you
boot into, or even if there's nothing to boot at all (without running to
grab some jumper cables)
-It means you don't have to fiddle with setting iomem=relaxed on your main
install and un-setting it when you're done (I don't fancy leaving it on all
the time)
-Some level of confidence that you can trust the flashing environment,
being as it's stripped down and purpose built, while also residing on the
flash itself
Might be a security advantage if flashing could be restricted to only this
pathway (and not say, through the main OS), but let's not get ahead of
ourselves.
I figure the easiest way would be to build a floppy image for seabios with
a kernel and a copy of busybox, with the bare essentials to find an image
on a usb drive and run flashrom. (maybe even a convenient shell script :P)
What I'm not sure on (not having built an install completely from scratch)
is what else those bare essentials might include.
Eventually something akin to (or included in?) LinuxBoot might be better,
integrating everything into a single payload and cutting out the dependency
on seabios.
-Matt
5 hours, 48 minutes
VBIOS/VBT in Coreboot
by Alex Feinman
In my Coreboot build I provide both VBIOS and VBT blobs via appropriate configuration items. The VBIOS blob contains expected signature at the top and VBT is valid as confirmed by running intelvbttool against it. The platform is slightly modified kblrvp (RVP3).
During the build I can see cbfstool reporting that both blobs were placed in the image:
To see the image's read-only sections as well, rerun with the -w option.
CBFSPRINT coreboot.rom
Name Offset Type Size Comp
cbfs master header 0x0 cbfs header 32 none
fallback/romstage 0x80 stage 41372 none
cpu_microcode_blob.bin 0xa280 microcode 98304 none
fallback/ramstage 0x22300 stage 90199 none
config 0x383c0 raw 1302 none
revision 0x38940 raw 612 none
spd.bin 0x38c00 spd 2048 none
--> vbt.bin 0x39440 raw 1168 LZMA (4608 decompressed)
cmos_layout.bin 0x39940 cmos_layout 904 none
(empty) 0x39d00 null 664 none
fspm.bin 0x39fc0 fsp 401408 none
(empty) 0x9c000 null 3992 none
fsps.bin 0x9cfc0 fsp 188416 none
--> pci8086,591e.rom 0xcb000 optionrom 65536 none
fallback/postcar 0xdb080 stage 16512 none
fallback/dsdt.aml 0xdf140 raw 19077 none
fallback/payload 0xe3c40 simple elf 1166029 none
(empty) 0x200780 null 997400 none
bootblock 0x2f3fc0 bootblock 49152 none
However, once the system boots, the VBIOS is not found at address 0xc0000 and VBT cannot be located either.
I need VBT to be accessible in order to specify the DP connector configuration for eDP. Suggestions are appreciated
12 hours, 17 minutes
[x86] Support for SIS 651 (Northbridge) + SIS 962 (Southbridge) ?
by Frederic Dumas
Hi !
Thanks to a face to face talk at FOSDEM 2019 in Brussels, with Philippe,
a German Coreboot speaker (and developer ? He knows better than me), I
was said that dropping a mail to the list and asking for possible
support of my desktop motherboard would not break your rules. So I do now.
We are dealing here with legacy Pentium IV hardware (circa 2004, ugh!)
Northbridge: SIS 651
http://www.cpu-upgrade.com/mb-SiS_(chipsets)/651.html
iGPU: SIS 315 (w/ SIS 301B) (unused, PCI GPU GT430 in use)
Southbridge: SIS 962
Processor: Pentium IV Northwood 3.06Ghz HT 512K L2 533MT/s FSB
http://www.cpu-upgrade.com/CPUs/Intel/Pentium_4/RK80532PE083512.html
I may provide more details, but I guess this is enough to check if I am
facing a wall, or if most of the work has been already done at tuning
Coreboot for firing up this kind of hardware.
Thank you !
Frederic
PS: I attached here below a lspci -v output.
--
Frédéric Dumas
f.dumas(a)ellis.siteparc.fr
00:00.0 Host bridge: Silicon Integrated Systems [SiS] 651 Host (rev 02)
Subsystem: ASUSTeK Computer Inc. Device 8081
Flags: bus master, medium devsel, latency 32
Memory at e5000000 (32-bit, non-prefetchable) [size=4M]
Capabilities: [c0] AGP version 2.0
Kernel driver in use: agpgart-sis
Kernel modules: sis_agp
00:01.0 PCI bridge: Silicon Integrated Systems [SiS] AGP Port (virtual
PCI-to-PCI bridge) (prog-if 00 [Normal decode])
Flags: bus master, fast devsel, latency 0
Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
Kernel modules: shpchp
00:02.0 ISA bridge: Silicon Integrated Systems [SiS] SiS962 [MuTIOL
Media IO] LPC Controller (rev 14)
Flags: bus master, medium devsel, latency 0
00:02.1 SMBus: Silicon Integrated Systems [SiS] SiS961/2/3 SMBus controller
Flags: medium devsel
I/O ports at e600 [size=32]
Kernel driver in use: sis96x_smbus
Kernel modules: i2c_sis96x
00:02.5 IDE interface: Silicon Integrated Systems [SiS] 5513 IDE
Controller (prog-if 80 [ISA Compatibility mode-only controller, supports
bus mastering])
Subsystem: ASUSTeK Computer Inc. Device 807a
Flags: bus master, medium devsel, latency 128, IRQ 16
[virtual] Memory at 000001f0 (32-bit, non-prefetchable) [size=8]
[virtual] Memory at 000003f0 (type 3, non-prefetchable)
[virtual] Memory at 00000170 (32-bit, non-prefetchable) [size=8]
[virtual] Memory at 00000370 (type 3, non-prefetchable)
I/O ports at b400 [size=16]
Kernel driver in use: pata_sis
Kernel modules: pata_acpi
00:02.7 Multimedia audio controller: Silicon Integrated Systems [SiS]
SiS7012 AC'97 Sound Controller (rev a0)
Subsystem: ASUSTeK Computer Inc. Device 8095
Flags: bus master, medium devsel, latency 32, IRQ 18
I/O ports at a400 [size=256]
I/O ports at a000 [size=128]
Capabilities: [48] Power Management version 2
Kernel driver in use: snd_intel8x0
Kernel modules: snd_intel8x0
00:03.0 USB controller: Silicon Integrated Systems [SiS] USB 1.1
Controller (rev 0f) (prog-if 10 [OHCI])
Subsystem: ASUSTeK Computer Inc. Device 807a
Flags: bus master, medium devsel, latency 32, IRQ 9
Memory at e4000000 (32-bit, non-prefetchable) [size=4K]
Kernel driver in use: ohci-pci
00:03.1 USB controller: Silicon Integrated Systems [SiS] USB 1.1
Controller (rev 0f) (prog-if 10 [OHCI])
Subsystem: ASUSTeK Computer Inc. Device 807a
Flags: bus master, medium devsel, latency 32, IRQ 21
Memory at e3800000 (32-bit, non-prefetchable) [size=4K]
Kernel driver in use: ohci-pci
00:03.2 USB controller: Silicon Integrated Systems [SiS] USB 1.1
Controller (rev 0f) (prog-if 10 [OHCI])
Subsystem: ASUSTeK Computer Inc. Device 807a
Flags: bus master, medium devsel, latency 32, IRQ 22
Memory at e3000000 (32-bit, non-prefetchable) [size=4K]
Kernel driver in use: ohci-pci
00:03.3 USB controller: Silicon Integrated Systems [SiS] USB 2.0
Controller (prog-if 20 [EHCI])
Subsystem: ASUSTeK Computer Inc. Device 807a
Flags: bus master, medium devsel, latency 32, IRQ 23
Memory at e2800000 (32-bit, non-prefetchable) [size=4K]
Capabilities: [50] Power Management version 2
Kernel driver in use: ehci-pci
00:0e.0 PCI bridge: PLX Technology, Inc. PEX8112 x1 Lane PCI
Express-to-PCI Bridge (rev aa) (prog-if 00 [Normal decode])
Flags: bus master, 66MHz, medium devsel, latency 32, IRQ 17
Bus: primary=00, secondary=02, subordinate=02, sec-latency=32
I/O behind bridge: 00009000-00009fff
Memory behind bridge: e0800000-e27fffff
Prefetchable memory behind bridge: e5f00000-f3efffff
Capabilities: [40] Power Management version 2
Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit+
Capabilities: [60] Express PCI/PCI-X to PCI-Express Bridge, MSI 00
Kernel modules: shpchp
00:0f.0 Ethernet controller: Broadcom Inc. and subsidiaries BCM4401
100Base-T (rev 01)
Subsystem: ASUSTeK Computer Inc. A7V8X motherboard
Flags: bus master, fast devsel, latency 32, IRQ 18
Memory at e0000000 (32-bit, non-prefetchable) [size=8K]
Capabilities: [40] Power Management version 2
Kernel driver in use: b44
Kernel modules: b44
00:10.0 CardBus bridge: ENE Technology Inc CB-710/2/4 Cardbus Controller
(rev 01)
Subsystem: ENE Technology Inc CB-710/2/4 Cardbus Controller
Flags: bus master, medium devsel, latency 168, IRQ 16
Memory at fe800000 (32-bit, non-prefetchable) [size=4K]
Bus: primary=00, secondary=03, subordinate=06, sec-latency=176
Memory window 0: 80000000-83ffffff (prefetchable)
Memory window 1: 84000000-87ffffff
I/O window 0: 00001000-000010ff
I/O window 1: 00001400-000014ff
16-bit legacy interface ports at 0001
Capabilities: [a0] Power Management version 1
Kernel driver in use: yenta_cardbus
Kernel modules: yenta_socket
00:10.1 FLASH memory: ENE Technology Inc CB710 Memory Card Reader Controller
Subsystem: ASUSTeK Computer Inc. Device 1724
Flags: medium devsel, IRQ 19
I/O ports at 8800 [size=128]
Capabilities: [a0] Power Management version 2
Kernel driver in use: cb710
Kernel modules: cb710
00:13.0 Multimedia video controller: Conexant Systems, Inc.
CX23880/1/2/3 PCI Video and Audio Decoder (rev 05)
Subsystem: Hauppauge computer works Inc. WinTV HVR-4000-HD
Flags: bus master, medium devsel, latency 32, IRQ 18
Memory at df000000 (32-bit, non-prefetchable) [size=16M]
Capabilities: [44] Vital Product Data
Capabilities: [4c] Power Management version 2
Kernel driver in use: cx8800
Kernel modules: cx8800
00:13.1 Multimedia controller: Conexant Systems, Inc. CX23880/1/2/3 PCI
Video and Audio Decoder [Audio Port] (rev 05)
Subsystem: Hauppauge computer works Inc. WinTV HVR-4000-HD
Flags: bus master, medium devsel, latency 32, IRQ 18
Memory at de000000 (32-bit, non-prefetchable) [size=16M]
Capabilities: [4c] Power Management version 2
Kernel driver in use: cx88_audio
Kernel modules: cx88_alsa
00:13.2 Multimedia controller: Conexant Systems, Inc. CX23880/1/2/3 PCI
Video and Audio Decoder [MPEG Port] (rev 05)
Subsystem: Hauppauge computer works Inc. WinTV HVR-4000-HD
Flags: bus master, medium devsel, latency 32, IRQ 18
Memory at dd000000 (32-bit, non-prefetchable) [size=16M]
Capabilities: [4c] Power Management version 2
Kernel driver in use: cx88-mpeg driver manager
Kernel modules: cx8802
00:13.4 Multimedia controller: Conexant Systems, Inc. CX23880/1/2/3 PCI
Video and Audio Decoder [IR Port] (rev 05)
Subsystem: Hauppauge computer works Inc. WinTV HVR-4000-HD
Flags: bus master, medium devsel, latency 32, IRQ 255
Memory at dc000000 (32-bit, non-prefetchable) [disabled] [size=16M]
Capabilities: [4c] Power Management version 2
02:00.0 VGA compatible controller: NVIDIA Corporation GF108 [GeForce GT
430] (rev a1) (prog-if 00 [VGA controller])
Subsystem: ZOTAC International (MCO) Ltd. Device 2200
Flags: bus master, fast devsel, latency 0, IRQ 24
Memory at e1000000 (32-bit, non-prefetchable) [size=16M]
Memory at e8000000 (64-bit, prefetchable) [size=128M]
Memory at e6000000 (64-bit, prefetchable) [size=32M]
I/O ports at 9800 [size=128]
Expansion ROM at 000c0000 [disabled] [size=128K]
Capabilities: [60] Power Management version 3
Capabilities: [68] MSI: Enable+ Count=1/1 Maskable- 64bit+
Capabilities: [78] Express Endpoint, MSI 00
Capabilities: [b4] Vendor Specific Information: Len=14 <?>
Kernel driver in use: nouveau
Kernel modules: nvidiafb, nouveau
02:00.1 Audio device: NVIDIA Corporation GF108 High Definition Audio
Controller (rev a1)
Subsystem: ZOTAC International (MCO) Ltd. Device 2200
Flags: bus master, fast devsel, latency 0, IRQ 18
Memory at e0800000 (32-bit, non-prefetchable) [size=16K]
Capabilities: [60] Power Management version 3
Capabilities: [68] MSI: Enable- Count=1/1 Maskable- 64bit+
Capabilities: [78] Express Endpoint, MSI 00
Kernel driver in use: snd_hda_intel
Kernel modules: snd_hda_intel
1 day, 11 hours
Refactor tianocore payload
by Patrick Rudolph
Hi folks!
With UEFI the defactor standard it seems reasonable to improve the
tianocore payload integration.
I'm having trouble to compile "stable" and "master" is totally broken
as packages have been removed.
Instead of the current approach of maintaining patches in our tree, I'd
like to use a repo that has those patches applied and is known to be
working.
A good candiate is [1], as it's maintained, has bug-fixes and features
upstream tianocore doesn't provide, and it's known to work with
coreboot out of the box.
Similar to seabios, we should use this repo without additional in-tree
patches to build a working payload.
Please tell me what you think about the proposed solution.
[1]: https://github.com/MrChromebox/edk2
--
Patrick Rudolph
9elements Agency GmbH, Kortumstraße 19-21, 44787 Bochum, Germany
Email: patrick.rudolph(a)9elements.com
Phone: +49 234 68 94 188
Sitz der Gesellschaft: Bochum
Handelsregister: Amtsgericht Bochum, HRB 17519
Geschäftsführung: Sebastian Deutsch, Daniel Hoelzgen
1 day, 17 hours
Random System Freezes
by Kinky Nekoboi
Anybody having FUN with random system Freezes with coreboot 4.9?
Experienced some in the Last days on.
my X220
and F2a85m board
both with Debian Buster/ +Cinnamon
best regards
2 days, 17 hours
hang in walkcbfs.S on skylake SP
by Jonathan Zhang
Hi, I am working on porting coreboot to Skylake SP and OCP Tiogapass
with FSP 2.0. I have a strange issue that I hope to get some wisdom.
The boot hangs when executing this line "sub %ecx, %ebx" in
src/arch/x86/walkcbfs.S; the post code showing up is 0xb1.
When I add a spinloop before this statement "sub %ecx, %ebx", the
postcode stays at 0x21, which means code execution till this point is
smooth.
My codebase is based on current tip of upstream code. In the .config
file, following are set (greping BOOTBLOCK):
CONFIG_C_ENV_BOOTBLOCK_SIZE=0x10000
CONFIG_BOOTBLOCK_CPU_INIT="soc/intel/fsp_skylake_fsp/bootblock/bootblock.c"
CONFIG_ARCH_BOOTBLOCK_X86_32=y
CONFIG_BOOTBLOCK_SIMPLE=y
CONFIG_BOOTBLOCK_SOURCE="bootblock_simple.c"
CONFIG_BOOTBLOCK_CONSOLE=y
CONFIG_C_ENVIRONMENT_BOOTBLOCK=y
Any pointer is appreciated. Let me know if you need any additional information.
Thank you,
Jonathan
3 days, 1 hour
4.9: FSP debug level (0-3)
by Zvi Vered
Helllo,
I'm porting core boot to a bay trail board.
I noticed that starting from version 4.9, I can set the debug level of FSP.
I downloaded FSP for Bay trail and used Intel's BCT to modify it.
But coreboot hangs after calling to the FSP binary.
How can I use the "FSP debug level" ?
Thank you,
Zvika
3 days, 12 hours
cleaning crossgcc tools
by galla rao
Hi All,
To pull cross compile tools in Coreboot the below command is run,
make crossgcc-i386 CPUS=6
Is there a step or a command to clean all the tools that got installed ?
Regards
Ranga
3 days, 21 hours
