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] 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] [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- SERR-
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] Error 1
Hope it helps.
Best regards,
Patrick
On Wed, 2015-03-11 at 16:21 +0100, Patrick Agrain wrote:
/ Hello Kyösti,
/>/
/>/ I tried what you suggested below:
/>/
/>/ - Enabled EARLY_PCI_BRIDGE
/>/ - Set Bridge at D:1 F:0
/>/ - Enabled OXI PCIe952 and disabled SERIAL_PORT_ON_SUPERIO.
/>/ Reboot Mohon Peak CRB: failed. No output. POST code at 0xA9.
/>/
/
You also need to set EARLY_PCI_MMIO_BASE. If you cannot boot this board
to OS yet and run lspci command, try with 0xfef0 that should be
safely out of the way of other resources.
I don't think post 0xA9 originates from coreboot proper.
/ Will try to get further.
/>/ If anybody has an idea...
/
If by any means possible, boot your Mohon Peak board to OS, check your
serial terminal parameters and cables, and prepare the OS for logins
over serial line. Then return here with the lspci -vv output so we have
something to work with.
Kyösti
Le 11/03/2015 17:44, Patrick Agrain a écrit :
Hi,
More information on this.
The POST code sequence (as far I can see, but I'm not Steeve
Austin...) is:
40h -> 47h -> A9h
IMHO, we are parsing following code from
./src/southbridge/intel/fsp_rangeley/romstage.c
void main(FSP_INFO_HEADER *fsp_info_header)
{
uint32_t fd_mask = 0;
uint32_t func_dis = DEFAULT_PBASE + PBASE_FUNC_DIS;
/*
* Do not use the Serial Console before it is setup.
* This causes the I/O to clog and a side effect is
* that the reset button stops functioning. So
* instead just use outb so it doesn't output to the
* console when CONFIG_CONSOLE_POST.
*/
outb(0x40, 0x80);
/* Rangeley UART POR state is enabled */
console_init();
post_code(0x41);
/* Enable GP
Re: [coreboot] set for a raid system
Thanks Paul. > so, software RAID is fine too? What about hardware based ones? > 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. Which proprietary parts do [1] and [2] need to work? For instance, I saw that VGA works for the Jetaway, but the entry does not say if I need some proprietary firmware. (While for the ASrock seems quite obvious that I need the blob). Bye -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
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- > SERR- 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
[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
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] coreboot meeting this summer!
* Peter Stuge [150312 19:29]: > 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. I absolutely agree with you, Peter. Hence it is a good idea to have meetings on different continents, to open up to individual contributors that can't afford to travel to Europe or the US. Traditionally there were more meetings in Europe, so here's the opportunity to even things out a little bit. I hope that our European and Asian (and others!) parts of our community feel encouraged to organize meetings where we can engage face to face. Stefan -- 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!
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] 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
[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
Re: [coreboot] questions about google/samus
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. ron -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] questions about google/samus
Hi Anthony, * Anthony Martin [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
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
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
