Re: [coreboot] Port80 isn't working (ASUS P8B75-V) (Konstantin Novikov)
Hello, Peter! The mistake was found in the following part of the code (southbridge/intel/bd82x6x/bootblock.c): static void bootblock_southbridge_init(void) { store_initial_timestamp(); enable_spi_prefetch(); enable_port80_on_lpc(); set_spi_speed(); /* Enable upper 128bytes of CMOS */ RCBA32(RC) = (1 << 2); } This mistake was eliminated in the Haswell-code: static void map_rcba(void) { pci_devfn_t dev = PCI_DEV(0, 0x1f, 0); pci_write_config32(dev, RCBA, (uintptr_t)DEFAULT_RCBA | 1); } static void enable_port80_on_lpc(void) { /* Enable port 80 POST on LPC. */ u32 gcs = RCBA32(GCS); gcs = gcs & ~0x4; RCBA32(GCS) = gcs; } static void bootblock_southbridge_init(void) { store_initial_timestamp(); map_rcba(); enable_spi_prefetch(); #if CONFIG_POST_DEVICE_LPC enable_port80_on_lpc(); #endif set_spi_speed(); /* Enable upper 128bytes of CMOS */ RCBA32(RC) = (1 << 2); } After that all the post-codes are sended correctly. Also we have found he mistake in the part of the code for the memory-banks. In the code for SandyBridge/IvyBridge variables are assigned "hardly" while for the Haswell variables are defined dynamically: static void configure_mca(void) { msr_t msr; int i; msr.lo = msr.hi = 0; /* This should only be done on a cold boot */ for (i = 0; i < 7; i++) wrmsr(IA32_MC0_STATUS + (i * 4), msr); } Now I port ASUS P8B75-V motherboard. Everything is OK with using Intel Core i3, but with Intel Celeron G440 on the seventh iteration we have got a mistake because there is not the seventh memory bank there. With using Haswell-code our project runs correctly with both processors: static void configure_mca(void) { msr_t msr; int i; int num_banks; const unsigned int mcg_cap_msr = 0x179; msr = rdmsr(mcg_cap_msr); num_banks = msr.lo & 0xff; msr.lo = msr.hi = 0; /* This should only be done on a cold boot */ for (i = 0; i < num_banks; i++) wrmsr(IA32_MC0_STATUS + (i * 4), msr); } -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] minnowmax serial port cord
you saved my demo! On Sun, Jun 4, 2017 at 5:21 PM Marshall Dawson wrote: > Hey Ron, > I'll bring one. > > > On Sun, Jun 4, 2017 at 3:12 PM, ron minnich wrote: > >> I forgot to pack my minnowmax serial port cable, it's this one: >> >> http://elinux.org/Minnowboard:MinnowMax#6-Wire_Serial_Console >> >> My demo at the coreboot conf is gonna be boring without the cable, if >> someone can bring one that would be wonderful. >> >> thanks >> >> ron >> >> -- >> coreboot mailing list: coreboot@coreboot.org >> https://mail.coreboot.org/mailman/listinfo/coreboot >> > -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] minnowmax serial port cord
Hey Ron, I'll bring one. On Sun, Jun 4, 2017 at 3:12 PM, ron minnich wrote: > I forgot to pack my minnowmax serial port cable, it's this one: > > http://elinux.org/Minnowboard:MinnowMax#6-Wire_Serial_Console > > My demo at the coreboot conf is gonna be boring without the cable, if > someone can bring one that would be wonderful. > > thanks > > ron > > -- > coreboot mailing list: coreboot@coreboot.org > https://mail.coreboot.org/mailman/listinfo/coreboot > -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
[coreboot] make crossgcc-i386 : ubsan.c error (with fix!) for GCC
Good day! While building the coreboot's toolchain by using GCC 7.1.1 version, I am getting the following error: ubsan.c:1474:23: error: ISO C++ forbids comparison between pointer and integer [-fpermissive] || xloc.file == '\0' || xloc.file[0] == '\xff' The fix is very simple - just open ./util/crossgcc/gcc-6.3.0/gcc/ubsan.c and change || xloc.file == '\0' || xloc.file[0] == '\xff' to || xloc.file[0] == '\0' || xloc.file[0] == '\xff' Found this solution here - https://patchwork.openembedded.org/patch/138884/ . Would be great if you could somehow import it to your code Best regards, qmastery -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
[coreboot] minnowmax serial port cord
I forgot to pack my minnowmax serial port cable, it's this one: http://elinux.org/Minnowboard:MinnowMax#6-Wire_Serial_Console My demo at the coreboot conf is gonna be boring without the cable, if someone can bring one that would be wonderful. thanks ron -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
[coreboot] KGPE-D16: More power drain experiments with coreboot vs. vendor bios
Hi all, I did some more testing with the Opteron CPUs, and it seems there is some defect in coreboot as it does not report the state P5. I attached the output of "cpupower frequency-info" which I obtained on a 1x6220/64G configuration running coreboot and running the vendor bios. I also did some wattage measures using a new Brennenstuhl PM 231 watt meter for my whole system. It seems like coreboot still has some flaw in this regards, as I was able to reproduce the high power drain in idle with the 6220 processor as well. With the vendor bios: 2x6276, 128G => 90W idle, ~350W load 1x6276, 64G => 66W idle, 165W load 1x6220, 64G => 70W idle, 157W With coreboot: 1x6220, 64G => 101W idle, 165W load One thing I noticed is that when running coreboot the power state P5 seems absent, while it's present when running the vendor bios. Could this be the cause for the high power drain in idle? (even if I am not sure if the system enters these states at all). Please see the logs attached. If you compare the config of 1x6276 vs. 2x6276 it seems like there is just a difference of 24W in idle and I am sure the memory also draws some power. Therefore, I wonder how big the improvement could be by replacing the 6200-series CPUs by one of the power-optimized "warsaw" modules (6338P or 6370P). I could not find any figures about idle power consumption with these CPUs so I welcome any reports from others. I don't really need all that CPU power but I would really like to use all of my 128G memory - which is why I am looking for the most power efficient CPU for the KGPE-D16. Cheers, Daniel analyzing CPU 0: driver: acpi-cpufreq CPUs which run at the same hardware frequency: 0 CPUs which need to have their frequency coordinated by software: 0 maximum transition latency: 5.0 us hardware limits: 1.40 GHz - 3.00 GHz available frequency steps: 3.00 GHz, 2.60 GHz, 2.20 GHz, 1.80 GHz, 1.40 GHz available cpufreq governors: userspace powersave conservative ondemand performance schedutil current policy: frequency should be within 1.40 GHz and 3.00 GHz. The governor "ondemand" may decide which speed to use within this range. current CPU frequency: 1.40 GHz (asserted by call to hardware) boost state support: Supported: yes Active: yes Boost States: 2 Total States: 7 Pstate-Pb0: 3600MHz (boost state) Pstate-Pb1: 3300MHz (boost state) Pstate-P0: 3000MHz Pstate-P1: 2600MHz Pstate-P2: 2200MHz Pstate-P3: 1800MHz Pstate-P4: 1400MHz analyzing CPU 0: driver: acpi-cpufreq CPUs which run at the same hardware frequency: 0 CPUs which need to have their frequency coordinated by software: 0 maximum transition latency: 5.0 us hardware limits: 1.40 GHz - 3.00 GHz available frequency steps: 3.00 GHz, 2.60 GHz, 2.20 GHz, 1.80 GHz, 1.40 GHz available cpufreq governors: userspace powersave conservative ondemand performance schedutil current policy: frequency should be within 1.40 GHz and 3.00 GHz. The governor "ondemand" may decide which speed to use within this range. current CPU frequency: 1.40 GHz (asserted by call to hardware) boost state support: Supported: yes Active: yes Boost States: 2 Total States: 8 Pstate-Pb0: 3600MHz (boost state) Pstate-Pb1: 3300MHz (boost state) Pstate-P0: 3000MHz Pstate-P1: 2600MHz Pstate-P2: 2200MHz Pstate-P3: 1800MHz Pstate-P4: 1400MHz Pstate-P5: 500MHz -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] GM45 ich9deblob and intel ME question
Hi Michal Widlok writes: > Hello, > I know that libreboot completely remove intel ME from old boards based > on GM45 chipset (like lenovo T400), and recently I found that it is > possible to neutralize it on newer chipsets also: > https://github.com/corna/me_cleaner > Since some of my T400 laptops still running on original BIOS (mostly > because of external video card and battery management with tp_smapi), > I was thinking if it is possible to use ich9deblob to remove intel ME > from original bios image. I have a special connector added to the > laptops so reading/writing flash images is quick and easy now. I think having a different descriptor with no ME region works to some extend with vendor, YMMV. > The question is: Can I generate new descriptors with ich9deblob from > factory.rom (original bios image) and then add the descriptors with > "dd" to it just like to the libreboot image? Like: > flashrom -r factory.rom > ich9deblob There are some flaws in ich9deblob so I'd recommend taking a look at blobltool in util/blobtool. With blobtool you can generate a descriptor: blobltool ifd-x200.spec ifd-x200.set x200-descriptor Due to a current limitation of flashrom (patches are pending) you need a file of same size as your flash. so you need to pad x200-descriptor dd if=/dev/zero bs=1 count=8188k >> x200-descriptor (8188k is 8m - 4K, adapt accordingly to your flashsize) > dd if=deblobbed_descriptor.bin of=factory.rom bs=1 count=12k conv=notrunc > flashrom -w factory.rom > If you want to update only one region of flash (in this case descriptor) I highly recommend using flashrom layouts to do just that. Create a layout using ifdtool: ifdtool vendor_bios.rom -f vendor_layout Then only flash the descriptor region: flashrom -w x200-descriptor --layout vendor_layout --image fd > Thanks in advance, > Michael Widlok -- Arthur Heymans -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
[coreboot] GM45 ich9deblob and intel ME question
Hello, I know that libreboot completely remove intel ME from old boards based on GM45 chipset (like lenovo T400), and recently I found that it is possible to neutralize it on newer chipsets also: https://github.com/corna/me_cleaner Since some of my T400 laptops still running on original BIOS (mostly because of external video card and battery management with tp_smapi), I was thinking if it is possible to use ich9deblob to remove intel ME from original bios image. I have a special connector added to the laptops so reading/writing flash images is quick and easy now. The question is: Can I generate new descriptors with ich9deblob from factory.rom (original bios image) and then add the descriptors with "dd" to it just like to the libreboot image? Like: flashrom -r factory.rom ich9deblob dd if=deblobbed_descriptor.bin of=factory.rom bs=1 count=12k conv=notrunc flashrom -w factory.rom Thanks in advance, Michael Widlok -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Gerrit update to 2.14
Dear Patrick, Am Freitag, den 02.06.2017, 05:09 +0200 schrieb Patrick Georgi: > I just updated Gerrit to 2.14, which brings some notable and user-visible > changes that you might want to deal with: Thank you for doing the upgrade, and for informing the users with this message. > * Emails now ship with an HTML part. This can be disabled in your user > settings. Is it possible to disable this by default, and let users, wanting HTML mails, enable it explicitly? That be great. […] Kind regards, Paul signature.asc Description: This is a digitally signed message part -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot