[coreboot] Re: Chainloading Windows from a Linux Payload
Hello! (Incidentally all of you are getting this because Google Mail delights in sending things out as reply-all.) I'm currently an observer in this set of circumstances but as it happens Stefan you are very right. My older laptop used a BIOS that was more suited to an earlier and even uglier release of Windows(!) and this one is using EFI and behaves strangely sometimes. Oh and I was able to run Windows 8 and Windows 8.1 for a while on the older one. Slowly of course but those versions ran. Let's see what does work.. - Gregg C Levine gregg.drw...@gmail.com "This signature fought the Time Wars, time and again." On Tue, Jun 11, 2019 at 6:53 PM Stefan Reinauer wrote: > > * ron minnich [190611 07:13]: > > if you boot windows 12 would you need tianocore? > > Need is a harsh word, but the simple answer to a simple question is yes, > you do. > > You can use SeaBIOS, but Windows does not officially support legacy BIOS > since at least Windows 7, so whatever works today might stop working > tomorrow. > > > > > On Mon, Jun 10, 2019 at 1:44 PM Nico Huber wrote: > > > > > > On 09.06.19 20:53, Matt B wrote: > > > > It is possible through u-root support for multiboot images [1] to > > > > chainload > > > > grub? > > > > > > Yes, I would think so. But in case we are still on topic: It won't > > > help you to boot Windows (unless you also implement UEFI services > > > in your LinuxBoot and use a UEFI GRUB). > > > > > > To chainload something for Windows I would currently go either one of > > > these ways: > > > > > > coreboot -> LinuxBoot -> SeaBIOS -> Windows loader > > > coreboot -> LinuxBoot -> tianocore -> Windows loader > > > > > > I think SeaBIOS already has an option to build a multiboot image. In > > > either case you could also (in theory) pack either into a bzImage and > > > feed that to kexec. > > > > > > Nico ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Chainloading Windows from a Linux Payload
* ron minnich [190611 07:13]: > if you boot windows 12 would you need tianocore? Need is a harsh word, but the simple answer to a simple question is yes, you do. You can use SeaBIOS, but Windows does not officially support legacy BIOS since at least Windows 7, so whatever works today might stop working tomorrow. > > On Mon, Jun 10, 2019 at 1:44 PM Nico Huber wrote: > > > > On 09.06.19 20:53, Matt B wrote: > > > It is possible through u-root support for multiboot images [1] to > > > chainload > > > grub? > > > > Yes, I would think so. But in case we are still on topic: It won't > > help you to boot Windows (unless you also implement UEFI services > > in your LinuxBoot and use a UEFI GRUB). > > > > To chainload something for Windows I would currently go either one of > > these ways: > > > > coreboot -> LinuxBoot -> SeaBIOS -> Windows loader > > coreboot -> LinuxBoot -> tianocore -> Windows loader > > > > I think SeaBIOS already has an option to build a multiboot image. In > > either case you could also (in theory) pack either into a bzImage and > > feed that to kexec. > > > > Nico > ___ > coreboot mailing list -- coreboot@coreboot.org > To unsubscribe send an email to coreboot-le...@coreboot.org ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: e820 memory map
And cbmem logs after updating coreboot firmware. After power-off and resume from hibernate (fail) 11.06.2019, 08:29, "Kyösti Mälkki" : > On Mon, Jun 10, 2019 at 11:22 PM Andrew A. I. wrote: >> Hello, Kyösti! >> cbmem log in attachment. >> I am rebooting and/or powering off after upgrading corboot firmware for >> verify. It doesn't help, as I remember. > > Logs from both a cold boot and hibernation resume would be needed for > comparison. > > But this pretty much sounds like the case of entering ACPI S4 from a > boot that did memory training and wrote MRC CACHE in SPI. This is the > known failing case described earlier. > > Kyösti > ___ > coreboot mailing list -- coreboot@coreboot.org > To unsubscribe send an email to coreboot-le...@coreboot.org<> <> ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: e820 memory map
cbmem log after cold boot (power off) and hibernate (success resume). Did MRC cache present (and used) in case of IvyBridge CPU and native memory init without FSP? 11.06.2019, 08:29, "Kyösti Mälkki" : > On Mon, Jun 10, 2019 at 11:22 PM Andrew A. I. wrote: >> Hello, Kyösti! >> cbmem log in attachment. >> I am rebooting and/or powering off after upgrading corboot firmware for >> verify. It doesn't help, as I remember. > > Logs from both a cold boot and hibernation resume would be needed for > comparison. > > But this pretty much sounds like the case of entering ACPI S4 from a > boot that did memory training and wrote MRC CACHE in SPI. This is the > known failing case described earlier. > > Kyösti > ___ > coreboot mailing list -- coreboot@coreboot.org > To unsubscribe send an email to coreboot-le...@coreboot.org<> <> ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Early kernel Panic linux 4.19 on ASUS KGPE-D16
It actually seems like that at the moment no kernel > 4.9 is able to boot this board. the only option that makes the kernel boot is apci=off (but this results in an unusable system) thinks i tried and all failed: acpi=oldboot Spectre etc mitigation off coreboot rom without microcode libreboot Am 11.06.19 um 09:49 schrieb Kinky Nekoboi: > also it seems like the kernel is build for SLUB > > # CONFIG_SLAB is not set > CONFIG_SLAB_MERGE_DEFAULT=y > CONFIG_SLAB_FREELIST_RANDOM=y > CONFIG_SLAB_FREELIST_HARDENED=y > lg@chi:~$ cat /boot/config-4.19.0-5-amd64 | grep -i slub > CONFIG_SLUB_DEBUG=y > # CONFIG_SLUB_MEMCG_SYSFS_ON is not set > CONFIG_SLUB=y > CONFIG_SLUB_CPU_PARTIAL=y > # CONFIG_SLUB_DEBUG_ON is not set > # CONFIG_SLUB_STATS is not set > > Am 11.06.19 um 06:52 schrieb Mike Banon: >> I see that it failed on "deactivate_slab". What if at the Linux kernel >> configuration you'd choose SLUB instead of SLAB, for example? And is >> this kernel working on the other computers? >> >> On Tue, Jun 11, 2019 at 1:43 AM Kinky Nekoboi >> wrote: >>> Just tested a Rom without microcode. Doesnt work eather. >>> >>> Am 11.06.19 um 00:24 schrieb Kinky Nekoboi: Yes microcode updates are included. Thats really interessting. I can try to build one without microcode ... but as i am using an Opteron 6380 i will need the microcode in some way. Am 11.06.19 um 00:19 schrieb Sean Lynn Rhone: > Any chance you included microcode updates? I noticed a little while > back on a KCMA-D8 that when I included microcode updates, Linux would > kernel panic early. I normally don't include microcode updates. > > On 6/10/2019 5:18 PM, Kinky Nekoboi wrote: >> Linked bugreports: >> >> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=930029 >> >> https://bugzilla.kernel.org/show_bug.cgi?id=203855 >> >> Kernel Output: >> >> Loading Linux 4.19.0-5-amd64 ...Loading Linux 4.19.0-5-amd64 .. >> >> . >> Loading initial ramdisk ...Loading initial ramdisk .. >> . >> [0.00] Linux version 4.19.0-5-amd64 >> (debian-ker...@lists.debian.org) (g) >> [0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-4.19.0-5-amd64 >> root=UUID=0 >> [0.00] random: get_random_u32 called from >> bsp_init_amd+0x20b/0x2b0 with0 >> [0.00] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating >> point reg' >> [0.00] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers' >> [0.00] x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers' >> [0.00] x86/fpu: xstate_offset[2]: 576, xstate_sizes[2]: 256 >> [0.00] x86/fpu: Enabled xstate features 0x7, context size is 832 >> bytes,. >> [0.00] BIOS-provided physical RAM map: >> [0.00] BIOS-e820: [mem 0x-0x0009fbff] >> usable >> [0.00] BIOS-e820: [mem 0x0009fc00-0x0009] >> reserved >> [0.00] BIOS-e820: [mem 0x000f-0x000f] >> reserved >> [0.00] BIOS-e820: [mem 0x0010-0xb7d97fff] >> usable >> [0.00] BIOS-e820: [mem 0xb7d98000-0xb7ff] >> reserved >> [0.00] BIOS-e820: [mem 0xb800-0xbfffafff] >> usable >> [0.00] BIOS-e820: [mem 0xbfffb000-0xcfff] >> reserved >> [0.00] BIOS-e820: [mem 0xfcf0-0xfcf03fff] >> reserved >> [0.00] BIOS-e820: [mem 0xfeb0-0xfeb00fff] >> reserved >> [0.00] BIOS-e820: [mem 0xfec0-0xfec00fff] >> reserved >> [0.00] BIOS-e820: [mem 0xfed0-0xfed00fff] >> reserved >> [0.00] BIOS-e820: [mem 0xfed4-0xfed44fff] >> reserved >> [0.00] BIOS-e820: [mem 0x0001-0x000437ff] >> usable >> [0.00] BIOS-e820: [mem 0x00043800-0x00043fff] >> reserved >> [0.00] bootconsole [earlyser0] enabled >> [0.00] NX (Execute Disable) protection: active >> [0.00] SMBIOS 2.7 present. >> [0.00] DMI: ASUS KGPE-D16/KGPE-D16, BIOS 4.9-1859-gf3510cbe36 >> 05/31/2019 >> [0.00] tsc: Fast TSC calibration using PIT >> [0.00] tsc: Detected 2500.121 MHz processor >> [0.010404] AGP: No AGP bridge found >> [0.013881] last_pfn = 0x438000 max_arch_pfn = 0x4 >> [0.021404] x86/PAT: Configuration [0-7]: WB WC UC- UC WB WP UC- >> WT >> Memory KASLR using RDTSC... >> [0.030856] last_pfn = 0xbfffb max_arch_pfn = 0x4 >> [0.042030] Using GB pages for direct mapping >> [0.046429] RAMDISK: [mem 0x3476f000-0x363aefff] >> [0.050877] ACPI: Early table checksum verification disabled
[coreboot] Re: How to enable the SMBus0 in coreboot for Intel Atom C2000?
Yes, most likely you are right! I could not completely fix the problem but was able to get around it. The problem arose when connecting an external video card to an PCI-E slot through riser. Without connecting the video card the SMBus0 (i2c-1 bus) works fine. I was able to experiments with IDT clock synthesizer (9VRS4420DKLFT). I turned on the 48 MHz clock for Nuvoton and finally saw it in Linux. Thanks for the help! While I am serving problems with interruptions and I’ll do the nuvoton configuration in coreboot. Best Regards, Dmitry Ponamorev ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: e820 memory map
In case it would have any meaning: https://mail.coreboot.org/pipermail/seabios/2018-November/012553.html My colleague discovered some inconsistence between coreboot tables and e820 in SeaBIOS. However the patch has been forgotten on the mailing list. Best regards, Michał On 11.06.2019 07:28, Kyösti Mälkki wrote: > On Mon, Jun 10, 2019 at 11:22 PM Andrew A. I. wrote: >> Hello, Kyösti! >> cbmem log in attachment. >> I am rebooting and/or powering off after upgrading corboot firmware for >> verify. It doesn't help, as I remember. >> > Logs from both a cold boot and hibernation resume would be needed for > comparison. > > But this pretty much sounds like the case of entering ACPI S4 from a > boot that did memory training and wrote MRC CACHE in SPI. This is the > known failing case described earlier. > > Kyösti > ___ > coreboot mailing list -- coreboot@coreboot.org > To unsubscribe send an email to coreboot-le...@coreboot.org -- Michał Żygowski Firmware Engineer http://3mdeb.com | @3mdeb_com ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Early kernel Panic linux 4.19 on ASUS KGPE-D16
also it seems like the kernel is build for SLUB # CONFIG_SLAB is not set CONFIG_SLAB_MERGE_DEFAULT=y CONFIG_SLAB_FREELIST_RANDOM=y CONFIG_SLAB_FREELIST_HARDENED=y lg@chi:~$ cat /boot/config-4.19.0-5-amd64 | grep -i slub CONFIG_SLUB_DEBUG=y # CONFIG_SLUB_MEMCG_SYSFS_ON is not set CONFIG_SLUB=y CONFIG_SLUB_CPU_PARTIAL=y # CONFIG_SLUB_DEBUG_ON is not set # CONFIG_SLUB_STATS is not set Am 11.06.19 um 06:52 schrieb Mike Banon: > I see that it failed on "deactivate_slab". What if at the Linux kernel > configuration you'd choose SLUB instead of SLAB, for example? And is > this kernel working on the other computers? > > On Tue, Jun 11, 2019 at 1:43 AM Kinky Nekoboi > wrote: >> Just tested a Rom without microcode. Doesnt work eather. >> >> Am 11.06.19 um 00:24 schrieb Kinky Nekoboi: >>> Yes microcode updates are included. >>> >>> Thats really interessting. >>> >>> I can try to build one without microcode ... but as i am using an >>> Opteron 6380 i will need the microcode in some way. >>> >>> >>> Am 11.06.19 um 00:19 schrieb Sean Lynn Rhone: Any chance you included microcode updates? I noticed a little while back on a KCMA-D8 that when I included microcode updates, Linux would kernel panic early. I normally don't include microcode updates. On 6/10/2019 5:18 PM, Kinky Nekoboi wrote: > Linked bugreports: > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=930029 > > https://bugzilla.kernel.org/show_bug.cgi?id=203855 > > Kernel Output: > > Loading Linux 4.19.0-5-amd64 ...Loading Linux 4.19.0-5-amd64 .. > > . > Loading initial ramdisk ...Loading initial ramdisk .. > . > [0.00] Linux version 4.19.0-5-amd64 > (debian-ker...@lists.debian.org) (g) > [0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-4.19.0-5-amd64 > root=UUID=0 > [0.00] random: get_random_u32 called from > bsp_init_amd+0x20b/0x2b0 with0 > [0.00] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating > point reg' > [0.00] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers' > [0.00] x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers' > [0.00] x86/fpu: xstate_offset[2]: 576, xstate_sizes[2]: 256 > [0.00] x86/fpu: Enabled xstate features 0x7, context size is 832 > bytes,. > [0.00] BIOS-provided physical RAM map: > [0.00] BIOS-e820: [mem 0x-0x0009fbff] > usable > [0.00] BIOS-e820: [mem 0x0009fc00-0x0009] > reserved > [0.00] BIOS-e820: [mem 0x000f-0x000f] > reserved > [0.00] BIOS-e820: [mem 0x0010-0xb7d97fff] > usable > [0.00] BIOS-e820: [mem 0xb7d98000-0xb7ff] > reserved > [0.00] BIOS-e820: [mem 0xb800-0xbfffafff] > usable > [0.00] BIOS-e820: [mem 0xbfffb000-0xcfff] > reserved > [0.00] BIOS-e820: [mem 0xfcf0-0xfcf03fff] > reserved > [0.00] BIOS-e820: [mem 0xfeb0-0xfeb00fff] > reserved > [0.00] BIOS-e820: [mem 0xfec0-0xfec00fff] > reserved > [0.00] BIOS-e820: [mem 0xfed0-0xfed00fff] > reserved > [0.00] BIOS-e820: [mem 0xfed4-0xfed44fff] > reserved > [0.00] BIOS-e820: [mem 0x0001-0x000437ff] > usable > [0.00] BIOS-e820: [mem 0x00043800-0x00043fff] > reserved > [0.00] bootconsole [earlyser0] enabled > [0.00] NX (Execute Disable) protection: active > [0.00] SMBIOS 2.7 present. > [0.00] DMI: ASUS KGPE-D16/KGPE-D16, BIOS 4.9-1859-gf3510cbe36 > 05/31/2019 > [0.00] tsc: Fast TSC calibration using PIT > [0.00] tsc: Detected 2500.121 MHz processor > [0.010404] AGP: No AGP bridge found > [0.013881] last_pfn = 0x438000 max_arch_pfn = 0x4 > [0.021404] x86/PAT: Configuration [0-7]: WB WC UC- UC WB WP UC- > WT > Memory KASLR using RDTSC... > [0.030856] last_pfn = 0xbfffb max_arch_pfn = 0x4 > [0.042030] Using GB pages for direct mapping > [0.046429] RAMDISK: [mem 0x3476f000-0x363aefff] > [0.050877] ACPI: Early table checksum verification disabled > [0.056563] ACPI: RSDP 0x000F6250 24 (v02 COREv4) > [0.062225] ACPI: XSDT 0xB7D990E0 74 (v01 COREv4 COREBOOT > 00) > [0.070720] ACPI: FACP 0xB7D9B9A0 F4 (v03 COREv4 COREBOOT > 00) > [0.079213] ACPI: DSDT 0xB7D99280 00271A (v02 COREv4 COREBOOT > 00) > [0.087704] ACPI: FACS 0xB7D99240 40 > [0.092298] ACPI: FACS 0xB7D99240 40
