Re: [coreboot] set for a raid system
Dear Milton, Am Mittwoch, den 11.03.2015, 17:12 -0700 schrieb Milton Krutt: Hi, can anyone suggest me a motherboard that is suitable to set up a small backup server, say 10TB, using some flavour of RAID (and running coreboot of course) ? so, software RAID is fine too? As you wrote small, I suggest the ASRock E350M1 [1] or the Jetway NF81-T56N-LF [2]. If I’m right, the chipset can also set up a RAID, but you need the AHCI firmware for it (see `SB800_AHCI_ROM`). Though in the end that’s also just a software RAID, so you can use, for example, Linux’ mdraid right away. Thanks, Paul [1] http://www.coreboot.org/Board:asrock/e350m1 [2] http://www.coreboot.org/Board:jetway/nf81-t56n-lf signature.asc Description: This is a digitally signed message part -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Plans for upcoming Broadwell Thinkpads
Hi, On 06.02.2015 21:43, Zaolin wrote: let's say goodbye to all Intel notebooks produced by OEM's which are not Google ( Chromebooks ). Maybe the haswell/broadwell notebooks of Lenovo without U/Y processor can be used ( Thinkpad tXX xXX ). It depends if they are supporting Intel Boot Guard on the southbridge... If I managed to find a VAR (value added reseller) who sells HP business laptops without Boot Guard, would there be interest in this group to buy a few machines? Regards, Carl-Daniel -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [Mohon Peak] Console output on external UARTs behind PCIe
Hello, More on this topic. Kyösti, as required, here are the info. - I'm able to boot a Linux OS with (internal) uart1 from Atom. - I'm also to boot the Linux with following command-line : kernel /boot/vmlinuz-2.6.32-xx-dhs3 root=/dev/sda2 console=uart8250,mmio,0xdf601000,115200n8 panic=5. The kernel logs are then sent to the external UART, as soon as the serial driver is loaded.. So far so good... Here are the lspci information from a Mohon Peak. [root@mohon_peak ~]# lspci -t -[:00]-+-00.0 +-01.0-[01]00.0 +-03.0-[02-06]00.0-[03-06]--+-04.0-[04]-- | +-05.0-[05]--+-00.0 | |\-00.1 | \-08.0-[06]-- +-0e.0 +-0f.0 +-13.0 +-14.0 +-14.1 +-16.0 +-17.0 +-18.0 +-1f.0 \-1f.3 [root@mohon_peak ~]# [root@mohon_peak ~]# lspci -vv -d 1415:c158 01:00.0 Serial controller: Oxford Semiconductor Ltd OXPCIe952 Dual 16C950 UART (prog-if 02 [16550]) Subsystem: Oxford Semiconductor Ltd OXPCIe952 Dual 16C950 UART Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- INTx- Interrupt: pin A routed to IRQ 16 Region 0: Memory at df60 (32-bit, non-prefetchable) [size=16K] Region 1: Memory at df20 (32-bit, non-prefetchable) [size=2M] Region 2: Memory at df40 (32-bit, non-prefetchable) [size=2M] Capabilities: [40] Power Management version 3 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=55mA PME(D0-,D1+,D2+,D3hot+,D3cold+) Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME- Capabilities: [70] Express (v1) Endpoint, MSI 00 DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s 128ns, L1 2us ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset- DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported- RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop- MaxPayload 128 bytes, MaxReadReq 512 bytes DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend- LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1, Latency L0 unlimited, L1 unlimited ClockPM+ Surprise- LLActRep- BwNot- LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk+ ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt- LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt- Capabilities: [b0] MSI-X: Enable- Count=16 Masked- Vector table: BAR=1 offset=001b3000 PBA: BAR=1 offset=001b2000 Capabilities: [100 v1] Device Serial Number 00-30-e0-11-11-00-01-50 Capabilities: [110 v1] Power Budgeting ? Kernel driver in use: serial [root@mohon_peak ~]# [root@mohon_peak ~]# dmesg | grep tty serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A serial8250: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A ttyS2: detected caps 0700 should be 0100 :01:00.0: ttyS2 at MMIO 0xdf601000 (irq = 16) is a 16C950/954 ttyS3: detected caps 0700 should be 0100 :01:00.0: ttyS3 at MMIO 0xdf601200 (irq = 16) is a 16C950/954 [root@mohon_peak ~]# Kyösti, I agree with you concerning the A9h post code. IMHO, I think it is issued by the Intel FSP. BTW, compiler complains about a mismatch argument type on read8() and write8() in ./src/drivers/uart/uart8250mem.c src/drivers/uart/uart8250mem.c: In function 'uart8250_read': src/drivers/uart/uart8250mem.c:39:2: error: passing argument 1 of 'read8' makes pointer from integer without a cast [-Werror] return read8((uintptr_t) (base + reg)); ^ In file included from src/drivers/uart/uart8250mem.c:21:0: src/arch/x86/include/arch/io.h:145:54: note: expected 'const volatile void *' but argument is of type 'unsigned int' static inline __attribute__((always_inline)) uint8_t read8(const volatile void *addr) ^ src/drivers/uart/uart8250mem.c: In function 'uart8250_write': src/drivers/uart/uart8250mem.c:45:2: error: passing argument 1 of 'write8' makes pointer from integer without a cast [-Werror] write8((uintptr_t) (base + reg), data); ^ In file included from src/drivers/uart/uart8250mem.c:21:0: src/arch/x86/include/arch/io.h:160:51: note: expected 'volatile void *' but argument is of type 'unsigned int' static inline __attribute__((always_inline)) void write8(volatile void *addr, uint8_t value) ^ cc1: all warnings being treated as errors make: *** [build/drivers/uart/uart8250mem.romstage.o]
Re: [coreboot] [Mohon Peak] Console output on external UARTs behind PCIe
On Thu, 2015-03-12 at 10:02 +0100, Patrick Agrain wrote: Hello, More on this topic. Kyösti, as required, here are the info. - I'm able to boot a Linux OS with (internal) uart1 from Atom. - I'm also to boot the Linux with following command-line : kernel /boot/vmlinuz-2.6.32-xx-dhs3 root=/dev/sda2 console=uart8250,mmio,0xdf601000,115200n8 panic=5. The kernel logs are then sent to the external UART, as soon as the serial driver is loaded.. So far so good... Ok, just checking. I need to correct my previous statement in that I do not know anyone (yet) using OxPCIe with the specific intel chipset you have there, but an older one. It is possible those PCI-e root ports are not yet initialized/trained when we attempt the PCI ID detection for the UART card. Here are the lspci information from a Mohon Peak. [root@mohon_peak ~]# lspci -t -[:00]-+-00.0 +-01.0-[01]00.0 +-03.0-[02-06]00.0-[03-06]--+-04.0-[04]-- | +-05.0-[05]--+-00.0 | |\-00.1 | \-08.0-[06]-- +-0e.0 +-0f.0 +-13.0 +-14.0 +-14.1 +-16.0 +-17.0 +-18.0 +-1f.0 \-1f.3 [root@mohon_peak ~]# [root@mohon_peak ~]# lspci -vv -d 1415:c158 01:00.0 Serial controller: Oxford Semiconductor Ltd OXPCIe952 Dual 16C950 UART (prog-if 02 [16550]) Subsystem: Oxford Semiconductor Ltd OXPCIe952 Dual 16C950 UART Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- INTx- Interrupt: pin A routed to IRQ 16 Region 0: Memory at df60 (32-bit, non-prefetchable) [size=16K] Region 1: Memory at df20 (32-bit, non-prefetchable) [size=2M] Region 2: Memory at df40 (32-bit, non-prefetchable) [size=2M] Capabilities: [40] Power Management version 3 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=55mA PME(D0-,D1+,D2+,D3hot+,D3cold+) Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME- Capabilities: [70] Express (v1) Endpoint, MSI 00 DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s 128ns, L1 2us ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset- DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported- RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop- MaxPayload 128 bytes, MaxReadReq 512 bytes DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend- LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1, Latency L0 unlimited, L1 unlimited ClockPM+ Surprise- LLActRep- BwNot- LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk+ ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt- LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt- Capabilities: [b0] MSI-X: Enable- Count=16 Masked- Vector table: BAR=1 offset=001b3000 PBA: BAR=1 offset=001b2000 Capabilities: [100 v1] Device Serial Number 00-30-e0-11-11-00-01-50 Capabilities: [110 v1] Power Budgeting ? Kernel driver in use: serial I think EARLY_PCI parameters are fine if you also assigned MMIO_BASE with 0xdf00. [root@mohon_peak ~]# [root@mohon_peak ~]# dmesg | grep tty serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A serial8250: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A ttyS2: detected caps 0700 should be 0100 :01:00.0: ttyS2 at MMIO 0xdf601000 (irq = 16) is a 16C950/954 ttyS3: detected caps 0700 should be 0100 :01:00.0: ttyS3 at MMIO 0xdf601200 (irq = 16) is a 16C950/954 [root@mohon_peak ~]# Kyösti, I agree with you concerning the A9h post code. IMHO, I think it is issued by the Intel FSP. BTW, compiler complains about a mismatch argument type on read8() and write8() in ./src/drivers/uart/uart8250mem.c Ah.. there is a recent regression with source. With complain like that it will not build you a new firmware binary at all, so it makes me wonder what you were actually testing before. Here is quick (but untested) fix for the build problem: http://review.coreboot.org/#/c/8660/ For a test run, I would need to disassemble a samsung/lumpy that I know OxPCIe works well with. That won't happen for at least a week. Kyösti -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] questions about google/samus
On Friday, March 13, 2015 12:42:38 AM ron minnich wrote: On Thu, Mar 12, 2015 at 3:48 PM Paul Menzel paulepan...@users.sourceforge.net wrote: As this is an Intel device [1] and I am waiting for an AMD based laptop, I’d say no. ;-) I'm not sure AMD improves the situation much any more, and in some ways a non-chromeos laptop has lots of other problems. On your AMD laptop, the EC will be a binary blob. If you're not worried about that, you should be. Sadly, I don't think AMD understands what a Chromebook is. ron -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] x60 and macbook21 builds fail
On Thursday, March 12, 2015 10:35:23 PM Mono wrote: is it just me? trying to build coreboot for a X60 motherboard or a macbook21 fails with tons of the following error: src/northbridge/intel/i945/gma.c: In function 'gtt_setup': src/northbridge/intel/i945/gma.c:72:10: error: passing argument 1 of 'write32' makes pointer from integer without a cast [-Werror] write32(mmiobase + GFX_FLSH_CNTL, 0); ^ Yeah. I broke that one. write32() takes a void * (as opposed to long int), so you'll have to pass it void pointers, In file included from src/include/device/pci.h:23:0, from src/northbridge/intel/i945/gma.c:24: src/arch/x86/include/arch/io.h:170:51: note: expected 'volatile void *' but argument is of type 'unsigned int' static inline __attribute__((always_inline)) void write32(volatile void *addr, uint32_t value) ^ src/northbridge/intel/i945/gma.c:74:10: error: passing argument 1 of 'write32' makes pointer from integer without a cast [-Werror] write32(mmiobase + PGETBL_CTL, PGETBL_save); I figured this error occurs since commit bde6d309 (x86: Change MMIO addr in readN(addr)/writeN(addr, val) to pointer). I don't know how to fix it though or did I configured any wrong? Any help is much appreciated. You can make mmiobase a uint8_t * then you can use the same pointer arithmetic as before. Alex greets Mono -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] set for a raid system
On Thursday, March 12, 2015 05:55:56 AM Milton Krutt wrote: Thanks Paul. so, software RAID is fine too? What about hardware based ones? Just do mdraid with linux. Alex -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] coreboot meeting this summer!
Hey folks! the coreboot meeting in Prague last year was a great success, and I suggest that we have a get together this year. To alternate between continents, I would like to organize a coreboot project meeting in San Jose, California this summer. I have talked to a few people, and it seems that end of June could be a good time frame for this. If you are interested in joining this summer, if you have ideas, or concerns, please contact me, so we can get the planning started as soon as possible and make this happen. Let me know what you think. Thanks, Stefan -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] coreboot meeting this summer!
Stefan Reinauer wrote: I would like to organize a coreboot project meeting in San Jose, California this summer. .. If you are interested in joining this summer, if you have ideas, or concerns, please contact me I think many individual contributors can't afford cross continent travel. Even if funding would be available I think travel to the US is unattractive for very many. //Peter -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] x60 and macbook21 builds fail
is it just me? trying to build coreboot for a X60 motherboard or a macbook21 fails with tons of the following error: src/northbridge/intel/i945/gma.c: In function 'gtt_setup': src/northbridge/intel/i945/gma.c:72:10: error: passing argument 1 of 'write32' makes pointer from integer without a cast [-Werror] write32(mmiobase + GFX_FLSH_CNTL, 0); ^ In file included from src/include/device/pci.h:23:0, from src/northbridge/intel/i945/gma.c:24: src/arch/x86/include/arch/io.h:170:51: note: expected 'volatile void *' but argument is of type 'unsigned int' static inline __attribute__((always_inline)) void write32(volatile void *addr, uint32_t value) ^ src/northbridge/intel/i945/gma.c:74:10: error: passing argument 1 of 'write32' makes pointer from integer without a cast [-Werror] write32(mmiobase + PGETBL_CTL, PGETBL_save); I figured this error occurs since commit bde6d309 (x86: Change MMIO addr in readN(addr)/writeN(addr, val) to pointer). I don't know how to fix it though or did I configured any wrong? Any help is much appreciated. greets Mono -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] coreboot meeting this summer!
I think it would be pretty cool. I think we should try it. On Thu, Mar 12, 2015 at 1:09 PM Carl-Daniel Hailfinger c-d.hailfinger.devel.2...@gmx.net wrote: On 12.03.2015 19:55, ron minnich wrote: Given all the high-tech ability in this group, I wonder if a joint, transglobal, meeting using gvc from san jose to whereever would work :-) Now that sounds like a really neat plan. GVC is Google Video Conference? That said, I was silently working on securing rooms (lab+lecture hall) for a coreboot conference at Bonn-Rhein-Sieg university near Bonn, Germany sometime during this summer/fall. So far it looks like we might be able to get such rooms for free and accommodation at reasonable prices. Plus, Cologne Cathedral is close to the venue. We could try to combine both approaches from a timing perspective and have the European end of the video conference at the venue I'd organize, and get the American end set up in San Jose. I'd have to check how the timing works, though. Thoughts? Regards, Carl-Daniel -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] Tianocore boot fails, [GSoc] CBFS support in tiano - discussion (C Ganesh Sundar)
Hi! I tried booting ELILO (disk.img - in gpt), ubuntu windows 8(iso) on QEMU but wasn't successful. I am able to boot into serial uefi shell only(a blank fully black screen). I tried std vga ROM in QEMU too but no result. Any comments/help would be grateful. Below is the serial output: Booting EFI DVD/CDROM BlockSize : 2048 LastBlock : 1E9AF3 BlockSize : 2048 LastBlock : 7 BlockSize : 2048 LastBlock : 1E9539 PlatformBdsBootFail Boot Failed. EFI DVD/CDROM Memory Previous CurrentNext TypePages Pages Pages == 0A0004 0002 0004 090008 0002 0008 000004 0004 060065 0051 0065 050030 002D 0030 030180 0170 0180 040F00 07C2 0F00 Booting EFI Internal Shell InstallProtocolInterface: 5B1B31A1-9562-11D2-8E3F-00A0C969723B 78064A8 Loading driver at 0x6B0E000 EntryPoint=0x6B0E240 Shell.efi -- I want to try creating CBFS support in tianocore by writing a UEFI DXE Driver. Since the ROM's address will be known, raw access of memory corresponding to the ROM could be done and parsing functions provided. For CBFS located elsewhere a base address could be provided as an argument. Existing cbfstool's code could be used. I would like to know if this is a correct approach. Thanking You! Ganesh -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] coreboot meeting this summer!
On 12.03.2015 19:55, ron minnich wrote: Given all the high-tech ability in this group, I wonder if a joint, transglobal, meeting using gvc from san jose to whereever would work :-) Now that sounds like a really neat plan. GVC is Google Video Conference? That said, I was silently working on securing rooms (lab+lecture hall) for a coreboot conference at Bonn-Rhein-Sieg university near Bonn, Germany sometime during this summer/fall. So far it looks like we might be able to get such rooms for free and accommodation at reasonable prices. Plus, Cologne Cathedral is close to the venue. We could try to combine both approaches from a timing perspective and have the European end of the video conference at the venue I'd organize, and get the American end set up in San Jose. I'd have to check how the timing works, though. Thoughts? Regards, Carl-Daniel -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] coreboot meeting this summer!
Given all the high-tech ability in this group, I wonder if a joint, transglobal, meeting using gvc from san jose to whereever would work :-) ron -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] questions about google/samus
Hi Anthony, * Anthony Martin al...@pbrane.org [150312 23:27]: - Does it use the usual depthcharge payload with an internal write-protect switch for flashing the firmware? There's no boot guard shenanigans going on, correct? That is correct. Like all Chrome OS devices, Samus (Pixel2) uses the SPI flash's hardware write protect mechanism for a portion of the firmware (AKA RO firmware, root of trust). There are currently no plans to use boot guard in Chrome OS devices, as it does not provide the same level of protection as the existing security mechanism, but has a larger impact on using Chrome OS machines as hackable devices. - It looks like the gigabit ethernet device is disabled in the device tree but are there pins or pads on the board to get to it? There are no pads for GBit ethernet. As with most mobile devices, board space is too rare to leave unused things on there (even if you were willing to destroy the case to break it out) - Can someone describe the keyboard in comparison to, say, an older Macbook Pro, a Thinkpad X230 or X240, and the Toshiba Chromebook 2? What is the key travel distance like? I'm not a keyboard expert, but I prefer the keyboard over my old MacBook Air. - Is the display panel IPS or TN? 12.85-inch high resolution IPS (2560 x 1700, at 239 PPI) 400 nit, 3:2 aspect ratio - Is the SSD soldered to the board? Yes. - Could this be the coreboot laptop we've all been waiting for? :) I am biased on that topic, but it is the nicest coreboot laptop I have worked on, so far. Two USB Type C ports, open source EC and USB PD MCU firmware, and 12h battery life are my personal favorites. Stefan -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] questions about google/samus
Hi, I have a few questions about the samus device and I figure this is the best place to ask. - Does it use the usual depthcharge payload with an internal write-protect switch for flashing the firmware? There's no boot guard shenanigans going on, correct? - It looks like the gigabit ethernet device is disabled in the device tree but are there pins or pads on the board to get to it? - Can someone describe the keyboard in comparison to, say, an older Macbook Pro, a Thinkpad X230 or X240, and the Toshiba Chromebook 2? What is the key travel distance like? - Is the display panel IPS or TN? - Is the SSD soldered to the board? - Could this be the coreboot laptop we've all been waiting for? :) Thanks, Anthony -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] questions about google/samus
Dear Anthony, Am Donnerstag, den 12.03.2015, 15:27 -0700 schrieb Anthony Martin: I have a few questions about the samus device and I figure this is the best place to ask. a link to that device would be nice for those not knowing the development names by heart. if BOARD_GOOGLE_SAMUS config BOARD_SPECIFIC_OPTIONS # dummy def_bool y select SOC_INTEL_BROADWELL select BOARD_ROMSIZE_KB_8192 select EC_GOOGLE_CHROMEEC select EC_SOFTWARE_SYNC select VIRTUAL_DEV_SWITCH […] […] - Could this be the coreboot laptop we've all been waiting for? :) As this is an Intel device [1] and I am waiting for an AMD based laptop, I’d say no. ;-) Thanks, Paul [1] http://www.coreboot.org/Binary_situation signature.asc Description: This is a digitally signed message part -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
