Re: [coreboot] Port80 isn't working (ASUS P8B75-V) (Konstantin Novikov)

2017-06-04 Thread Константин
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

2017-06-04 Thread ron minnich
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

[coreboot] make crossgcc-i386 : ubsan.c error (with fix!) for GCC

2017-06-04 Thread qma ster
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

2017-06-04 Thread ron minnich
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

2017-06-04 Thread Daniel Kulesz via coreboot
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

2017-06-04 Thread Arthur Heymans
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

2017-06-04 Thread Michal Widlok
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

2017-06-04 Thread Paul Menzel
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