[coreboot] Re: Abandoned add asus p2-99 board patches

[Branden Waldner]

On 9/21/19, Nico Huber  wrote:
>
> If nobody resurrects these changes, can you please squash the
> commits? If you remove the Change-Id from the commit message,
> a new should be generated and you could push it to Gerrit as
> a new change.
>
I managed to squash the commits and resubmit the change, but it
needs review(ers) again and I'm not sure if it's okay to just re-add
the same people as the previous commits.

I also didn't end up submitting it with a proper sign-off, so that needs
to be fixed yet as well.

Branden
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] HP Elitebook 8540w

[Dane Medic]

Hi,

is anyone working on porting HP Elitebook 8540w?
Reading on wikipedia , it has
different (older) chipset than those elitebooks already ported,
so this might add more work I'm guessing.

Have a nice day everyone!
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: [BUG] nonexisting function current_time_from

[Kyösti Mälkki]

On Sun, Sep 22, 2019 at 7:56 PM Petr Cvek  wrote:
>
> Enabling X86EMU_DEBUG_TIMINGS config option will cause the compilation to 
> fail with:
>

Not a big surprise, see [1].

> In file included from src/device/oprom/yabel/debug.h:48,
>  from src/device/oprom/yabel/biosemu.c:39:
> src/device/oprom/yabel/biosemu.c: In function 'biosemu':
> src/device/oprom/yabel/debug.h:103:66: error: implicit declaration of 
> function 'current_time_from' [-Werror=implicit-function-declaration]
>   103 | #define DEBUG_PRINTF_CS_IP(_x...) DEBUG_PRINTF("[%08lx]%x:%x ", 
> (current_time_from()).microseconds, M.x86.R_CS, M.x86.R_IP); 
> DEBUG_PRINTF(_x);
>
> It seems there isn't current_time_from() defined anywhere.

See [2] that removed it in 2015, might be a quite clean revert to bring it back.

[1] https://review.coreboot.org/c/coreboot/+/34201
[2] https://review.coreboot.org/c/coreboot/+/8896/

Kyösti
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] [BUG, RFC] mb/kontron/986lcd-m: missing gameport base destroys enumeration

[Petr Cvek]

I'm not sure, but it seems that missing definition of gameport for 986lcd-m in 
src/mainboard/kontron/986lcd-m/devicetree.cb can cause PNP autodetection for 
superIO to compute a wrong IO limit, which later causes 
wrong/missing/incompatible IO port resource allocations, so some devices won't 
work (0x60/0x64 PS/2, PCIe GPU, OHCI, uart console) or the boot freezes. Some 
of the logs:

Done reading resources.
Setting resources...
!! Resource didn't fit !!
   aligned base 1000 size 1000 limit 2e7
   1fff needs to be <= 2e7 (limit)
   PCI: 00:1c.0 1c *  [0x0 - 0xfff] io
!! Resource didn't fit !!
   aligned base 1000 size 1000 limit 2e7
   1fff needs to be <= 2e7 (limit)
   PCI: 00:1c.1 1c *  [0x1000 - 0x1fff] io
!! Resource didn't fit !!
   aligned base 1000 size 1000 limit 2e7
   1fff needs to be <= 2e7 (limit)
   PCI: 00:1c.2 1c *  [0x2000 - 0x2fff] io
!! Resource didn't fit !!
   aligned base 400 size 10 limit 2e7
   40f needs to be <= 2e7 (limit)
   PCI: 00:1f.2 20 *  [0x3080 - 0x308f] io
!! Resource didn't fit !!
...
ERROR: PCI: 00:02.0 14 io size: 0x08 not assigned
...
ERROR: PCI: 00:1f.2 10 io size: 0x08 not assigned
ERROR: PCI: 00:1f.2 14 io size: 0x04 not assigned
ERROR: PCI: 00:1f.2 18 io size: 0x08 not assigned
ERROR: PCI: 00:1f.2 1c io size: 0x04 not assigned
ERROR: PCI: 00:1f.2 20 io size: 0x10 not assigned
...
PCI: 00:1b.0 subsystem <- 8086/27d8
PCI: 00:1b.0 cmd <- 102
PCI: 00:1c.0 bridge ctrl <- 0003
PCI: 00:1c.0 subsystem <- 8086/27d0
PCI: 00:1c.0 cmd <- 107
PCI: 00:1c.1 brids70c01mcu0PeC: 0
dV0i8s0immicrocode: upd10a0y0025 x00CPU physiaB 0 0 e k
MTRR cheaeu60zeAttemfWaiting for 1st Sot AP: slot 1 apic_L0ecl0zsax a
aInitiNntt kac:oIG0 Ua dUrSGSGL Ct0C07fintel_vga_int15_h
VGA Option ROM wa7..Azalia0Azalia: codkAbCiPCI: 00:1c.0 init finished in 222 
usecs

After enabling SPEW I've found a weird limit values:
PCI: 00:1f.1 18 *  [0x50b8 - 0x50bf] io
PCI: 00:1f.2 10 *  [0x50c0 - 0x50c7] io
PCI: 00:1f.2 18 *  [0x50c8 - 0x50cf] io
PCI: 00:1f.1 14 *  [0x50d0 - 0x50d3] io
PCI: 00:1f.1 1c *  [0x50d4 - 0x50d7] io
PCI: 00:1f.2 14 *  [0x50d8 - 0x50db] io
PCI: 00:1f.2 1c *  [0x50dc - 0x50df] io
PNP: 002e.7 60 *  [0x50e0 - 0x50e0] io
DOMAIN:  io: base: 50e1 size: 40e1 align: 12 gran: 0 limit: 7ff done

"PNP: 002e.7 60" is that undefined gameport base. It seems the autodetection 
(IMO defined as IORESOURCE_FIXED) forces DOMAIN resources to have limit = 
0x7ff, which is not enough for anything. The value later applies to the whole 
domain (all PCI):

Setting resources...
DOMAIN:  io: base:1000 size:40e1 align:12 gran:0 limit:7ff

and the original warnings:

!! Resource didn't fit !!
   aligned base 1000 size 1000 limit 7ff
   1fff needs to be <= 7ff (limit)
   PCI: 00:01.0 1c *  [0x1000 - 0x1fff] io
PCI: 00:01.0 1c *  [0x1000 - 0x1fff] io
PCI: 00:01.0 1c *  [0x1000 - 0x1fff] io
!! Resource didn't fit !!
   aligned base 1000 size 1000 limit 7ff
   1fff needs to be <= 7ff (limit)
   PCI: 00:1c.0 1c *  [0x2000 - 0x2fff] io
PCI: 00:1c.0 1c *  [0x2000 - 0x2fff] io

Setting the base in devicetree.cb:

device pnp 2e.7 on  # GPIO1, GAME, MIDI
  io 0x60 = 0x220#gameport?
  io 0x62 = 0x330
  irq 0x70 = 9
end

fixes it. But the problem is there is no gameport routed on the board, so this 
allocation is overkill. Maybe the whole logical device could be disabled. Is 
there MIDI and GPIO port 1/5 routed anywhere? I'm not sure if PNP autodetection 
could be changed to ignore undefined PNP (it is global function).

Petr Cvek
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] [PATCH] mb/kontron/986lcd-m: Enable PCIe port 4

[petrcvekcz]

From: Petr Cvek 

PCIe port 4 is used for miniPCIe slot (wifi). Should be enabled.

Signed-off-by: Petr Cvek 
---
 src/mainboard/kontron/986lcd-m/devicetree.cb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/mainboard/kontron/986lcd-m/devicetree.cb 
b/src/mainboard/kontron/986lcd-m/devicetree.cb
index 5db7551d12..9f3655c7e0 100644
--- a/src/mainboard/kontron/986lcd-m/devicetree.cb
+++ b/src/mainboard/kontron/986lcd-m/devicetree.cb
@@ -43,7 +43,7 @@ chip northbridge/intel/i945
device pci 1c.0 on end # PCIe
device pci 1c.1 on end # PCIe
device pci 1c.2 on end # PCIe
-   device pci 1c.3 off end # PCIe port 4
+   device pci 1c.3 on end # PCIe port 4, miniPCIe
device pci 1c.4 off end # PCIe port 5
device pci 1c.5 off end # PCIe port 6
device pci 1d.0 on end # USB UHCI
-- 
2.23.0
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] [BUG] nonexisting function current_time_from

[Petr Cvek]

Enabling X86EMU_DEBUG_TIMINGS config option will cause the compilation to fail 
with:

In file included from src/device/oprom/yabel/debug.h:48,
 from src/device/oprom/yabel/biosemu.c:39:
src/device/oprom/yabel/biosemu.c: In function 'biosemu':
src/device/oprom/yabel/debug.h:103:66: error: implicit declaration of function 
'current_time_from' [-Werror=implicit-function-declaration]
  103 | #define DEBUG_PRINTF_CS_IP(_x...) DEBUG_PRINTF("[%08lx]%x:%x ", 
(current_time_from()).microseconds, M.x86.R_CS, M.x86.R_IP); 
DEBUG_PRINTF(_x);

It seems there isn't current_time_from() defined anywhere.

Petr Cvek
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: What are splitted / several flash ROMs about?

[Peter Stuge]

Philipp Stanner wrote:
> Platforms like the x230 have two flash ROMs which are virtually treated
> as a single one.
..
>1. What the heck is the meaning of this? Why do vendors buy and solder
>   two small chips (even worse, on the x230, one with 8M and one with
>   4M) instead of a single big one? Is this cheaper?

As was already mentioned it may actually be. Another factor is that 16M
flash chips were available only some time later than 8M flash chips.
And finally I would say that sourcing can be a significant factor;
It can be a lot easier to source 1x each of two parts with different
parameters, than 2x of a single part with particular parameters.


//Peter
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org