coreboot October 2013

coreboot@coreboot.org

32 participants
72 discussions

Re: [coreboot] Implementing or not implementing hacks for the OS (was: Change in coreboot[master]: ck804: hide IOAPIC base address in PCI_BASE_ADDRESS_1)
by David Hubbard 14 Oct '13

14 Oct '13

Hi all, On Sun, Oct 13, 2013 at 2:03 PM, ron minnich <rminnich(a)gmail.com> wrote: > Paul, you missed part of the picture. Suppose we have a different > kernel, which does not have the same bug as Linux has,and that, > further, depends on that register being visible? We can't know that > such OSes exist, but we do not know that they do not. We'd have to at > the very least test some of them. We've always tried to avoid being > Linux-centric in coreboot and for the most part have succeeded. > Further, hidden registers create their own problems. > > This problem has no clear solution. I've always felt that in all > cases, we should err on the side of opening up the hardware, and not > hiding registers. > > ron > I checked with Paul briefly on IRC, I think we may be missing something obvious here. IOAPIC support is pretty fundamental; maybe the ck804 brokenness is fixable? (I'm willing to dig in a little deeper and find out what's going on here.) If so then there would be no need to make a special case for it in coreboot, right? David

1 0

Trying to support Attro G5G100-P board
by Christoph Grenz 13 Oct '13

13 Oct '13

Hello, I'm currently experimenting with an Attro G5G100-P industrial board. According to the documentation the chipset is an Intel i915GM with an Intel 82801FBM southbridge (which flashrom shows as ICH6-M). Inteltool only shows: Northbridge: 8086:2590 (unknown) Southbridge: 8086:2641 (unknown) Is the chipset supported (or could it be supported by modifying existing code)? The main superio is a W83627HG-AW, which is already supported. The board seems to have a second superio which manages the four RS232 ports. I couldn't yet identify this chip. The config mode init sequence is 0x67,0x67 at 0x2e and the config mode registers 20-26 contain 02 08 03 19 34 01 00. Does anybody know something about this second superio chip? I couldn't find anything about this chip and as I don't know how it may look like, I can't even locate it on the board. Thanks, Christoph

3 2

Implementing or not implementing hacks for the OS (was: Change in coreboot[master]: ck804: hide IOAPIC base address in PCI_BASE_ADDRESS_1)
by Paul Menzel 13 Oct '13

13 Oct '13

Dear coreboot folks, Ron, let’s bring this up on the list for broader audience and easier discussion by email. Jonathan’s patch set »ck804: hide IOAPIC base address in PCI_BASE_ADDRESS_1« [1] does the following. Linux unhelpfully "fixes" the value in PCI_BASE_ADDRESS_1 when it is 0xfec00000 (that is, outside the range of bus 0 address space). This causes IOAPIC interrupts to fail to work under Linux. This issue was originally unnoticed by me when testing as sanity checking such as this is not done by NetBSD. Hiding the IOAPIC BAR is done by the OEM BIOS on the ck804 boards I've checked. The question raised by Ron is, if such hacks should be implemented in coreboot or not. Am Sonntag, den 13.10.2013, 13:55 -0400 schrieb ron minnich: > "do as the original BIOS does" is an ok rule if the BIOS is clearly > right and we are wrong. In this case, Linux is presumably covering for > a broken BIOS, but doing it badly. We've seen this before. Yes, let's > confront the LKML; some of them read this least and they're usually > pretty reasonable (not always :). But let's thoroughly document what's > going on. I'm not comfortable with doing a hack like this for one > kernel. It's never been a good idea (we've confronted this issue more > than once in 14 years). Before we know it we'll be asked to put in > gross hacks for Windows too. Even if Linux gets fixed, what do we do with distributions with older Linux kernels which do not have that fix on current installation media for example? In my opinion it is undesirable to tell people you cannot use that stable distribution because the Linux kernel has a bug. Build your own Linux kernel. The same applies for Microsoft Windows. And there you might even not get it fixed at all. (I do not know, if this particular problem actually exists in Microsoft Windows.) In the end, we want that everything that boots with the vendor BIOS also boots with coreboot, won’t we? Staying compatible with certain hacks the vendor BIOS does is therefore unavoidable. One alternative would be to add a Kconfig option to enable such hacks. No idea if this is doable or not. In the end Jonathan’s fix seems pretty minimal for the benefit we get. Thanks, Paul [1] http://review.coreboot.org/#/c/3963/

2 1

Re: [coreboot] [coreboot-gerrit] New patch to review for coreboot: 0f2066f AMD AGESA boards: Kconfig: Do not set `DRIVERS_PS2_KEYBOARD`
by ron minnich 13 Oct '13

13 Oct '13

Hey Paul, one last thought here. Is it possible that some of these platforms support PS2 keyboards and some don't? Would that explain why some have Y and some have N? ron On Sun, Oct 13, 2013 at 12:26 AM, Paul Menzel <gerrit(a)coreboot.org> wrote: > Paul Menzel (paulepanter(a)users.sourceforge.net) just uploaded a new patch set to gerrit, which you can find at http://review.coreboot.org/3966 > > -gerrit > > commit 0f2066f68fa406505fd1346ce096801e800da981 > Author: Paul Menzel <paulepanter(a)users.sourceforge.net> > Date: Sun Oct 13 09:15:24 2013 +0200 > > AMD AGESA boards: Kconfig: Do not set `DRIVERS_PS2_KEYBOARD` > > The Kconfig option `DRIVERS_PS2_KEYBOARD`, controlling if the > PS/2 keyboard should be initialized or not, should only be > selected by the user as it depends on if the selected payload > is able to initialize the keyboard or not. > > So remove that option from the mainboard’s Kconfig with the > following commmand. > > $ git grep -l DRIVERS_PS2_KEYBOARD src/mainboard | xargs sed -i '/DRIVERS_PS2_KEYBOARD/,+3d' > > Change-Id: Iafff465daf522d9bd1127c3098dff093920d4db6 > Signed-off-by: Paul Menzel <paulepanter(a)users.sourceforge.net> > --- > src/mainboard/amd/dinar/Kconfig | 4 ---- > src/mainboard/amd/inagua/Kconfig | 4 ---- > src/mainboard/amd/persimmon/Kconfig | 4 ---- > src/mainboard/amd/south_station/Kconfig | 4 ---- > src/mainboard/amd/torpedo/Kconfig | 4 ---- > src/mainboard/amd/union_station/Kconfig | 4 ---- > src/mainboard/asrock/e350m1/Kconfig | 4 ---- > src/mainboard/lippert/frontrunner-af/Kconfig | 4 ---- > src/mainboard/lippert/toucan-af/Kconfig | 4 ---- > src/mainboard/supermicro/h8qgi/Kconfig | 4 ---- > src/mainboard/supermicro/h8scm/Kconfig | 4 ---- > src/mainboard/tyan/s8226/Kconfig | 4 ---- > 12 files changed, 48 deletions(-) > > diff --git a/src/mainboard/amd/dinar/Kconfig b/src/mainboard/amd/dinar/Kconfig > index 441357b..8441d44 100644 > --- a/src/mainboard/amd/dinar/Kconfig > +++ b/src/mainboard/amd/dinar/Kconfig > @@ -88,10 +88,6 @@ config SIO_PORT > hex > default 0x2e > > -config DRIVERS_PS2_KEYBOARD > - bool > - default y > - > config ONBOARD_VGA_IS_PRIMARY > bool > default y > diff --git a/src/mainboard/amd/inagua/Kconfig b/src/mainboard/amd/inagua/Kconfig > index cf868fe..5101b19 100644 > --- a/src/mainboard/amd/inagua/Kconfig > +++ b/src/mainboard/amd/inagua/Kconfig > @@ -90,10 +90,6 @@ config SIO_PORT > hex > default 0x2e > > -config DRIVERS_PS2_KEYBOARD > - bool > - default y > - > config ONBOARD_VGA_IS_PRIMARY > bool > default y > diff --git a/src/mainboard/amd/persimmon/Kconfig b/src/mainboard/amd/persimmon/Kconfig > index 5781a25..02af942 100644 > --- a/src/mainboard/amd/persimmon/Kconfig > +++ b/src/mainboard/amd/persimmon/Kconfig > @@ -111,8 +111,4 @@ config SB800_AHCI_ROM > bool > default n > > -config DRIVERS_PS2_KEYBOARD > - bool > - default n > - > endif # BOARD_AMD_PERSIMMON > diff --git a/src/mainboard/amd/south_station/Kconfig b/src/mainboard/amd/south_station/Kconfig > index 81d631f..c05295e 100644 > --- a/src/mainboard/amd/south_station/Kconfig > +++ b/src/mainboard/amd/south_station/Kconfig > @@ -105,9 +105,5 @@ config VGA_BIOS_ID > string > default "1002,9806" > > -config DRIVERS_PS2_KEYBOARD > - bool > - default n > - > endif # BOARD_AMD_SOUTHSTATION > > diff --git a/src/mainboard/amd/torpedo/Kconfig b/src/mainboard/amd/torpedo/Kconfig > index cfcf3cb..a426301 100644 > --- a/src/mainboard/amd/torpedo/Kconfig > +++ b/src/mainboard/amd/torpedo/Kconfig > @@ -150,10 +150,6 @@ config XHC_BIOS_ID > depends on XHC_BIOS > default "1022,7812" > > -config DRIVERS_PS2_KEYBOARD > - bool > - default y > - > config CONSOLE_POST > bool > depends on !NO_POST > diff --git a/src/mainboard/amd/union_station/Kconfig b/src/mainboard/amd/union_station/Kconfig > index 848fd36..735e84d 100644 > --- a/src/mainboard/amd/union_station/Kconfig > +++ b/src/mainboard/amd/union_station/Kconfig > @@ -104,9 +104,5 @@ config VGA_BIOS_ID > string > default "1002,9802" > > -config DRIVERS_PS2_KEYBOARD > - bool > - default n > - > endif # BOARD_AMD_UNIONSTATION > > diff --git a/src/mainboard/asrock/e350m1/Kconfig b/src/mainboard/asrock/e350m1/Kconfig > index 026deeb..b905624 100644 > --- a/src/mainboard/asrock/e350m1/Kconfig > +++ b/src/mainboard/asrock/e350m1/Kconfig > @@ -98,9 +98,5 @@ config VGA_BIOS_ID > string > default "1002,9802" > > -config DRIVERS_PS2_KEYBOARD > - bool > - default n > - > endif # BOARD_ASROCK_E350M1 > > diff --git a/src/mainboard/lippert/frontrunner-af/Kconfig b/src/mainboard/lippert/frontrunner-af/Kconfig > index 945d9cb..903b154 100644 > --- a/src/mainboard/lippert/frontrunner-af/Kconfig > +++ b/src/mainboard/lippert/frontrunner-af/Kconfig > @@ -115,8 +115,4 @@ config SB800_AHCI_ROM > bool > default n > > -config DRIVERS_PS2_KEYBOARD > - bool > - default n > - > endif # BOARD_LIPPERT_FRONTRUNNER_AF > diff --git a/src/mainboard/lippert/toucan-af/Kconfig b/src/mainboard/lippert/toucan-af/Kconfig > index be016fb..c2d4d73 100644 > --- a/src/mainboard/lippert/toucan-af/Kconfig > +++ b/src/mainboard/lippert/toucan-af/Kconfig > @@ -117,8 +117,4 @@ config SB800_AHCI_ROM > bool > default n > > -config DRIVERS_PS2_KEYBOARD > - bool > - default n > - > endif # BOARD_LIPPERT_TOUCAN_AF > diff --git a/src/mainboard/supermicro/h8qgi/Kconfig b/src/mainboard/supermicro/h8qgi/Kconfig > index 5ee9a19..f965b58 100644 > --- a/src/mainboard/supermicro/h8qgi/Kconfig > +++ b/src/mainboard/supermicro/h8qgi/Kconfig > @@ -89,10 +89,6 @@ config SIO_PORT > though UARTs are on the NUVOTON BMC, port 0x164E > PS2 keyboard and mouse are on SUPERIO_WINBOND_W83627DHG, port 0x2E > > -config DRIVERS_PS2_KEYBOARD > - bool > - default y > - > config ONBOARD_VGA_IS_PRIMARY > bool > default y > diff --git a/src/mainboard/supermicro/h8scm/Kconfig b/src/mainboard/supermicro/h8scm/Kconfig > index a7f40be..969fae1 100644 > --- a/src/mainboard/supermicro/h8scm/Kconfig > +++ b/src/mainboard/supermicro/h8scm/Kconfig > @@ -92,10 +92,6 @@ config SIO_PORT > though UARTs are on the NUVOTON BMC, port 0x164E > PS2 keyboard and mouse are on SUPERIO_WINBOND_W83627DHG, port 0x2E > > -config DRIVERS_PS2_KEYBOARD > - bool > - default y > - > config ONBOARD_VGA_IS_PRIMARY > bool > default y > diff --git a/src/mainboard/tyan/s8226/Kconfig b/src/mainboard/tyan/s8226/Kconfig > index 68ce152..ded2620 100644 > --- a/src/mainboard/tyan/s8226/Kconfig > +++ b/src/mainboard/tyan/s8226/Kconfig > @@ -85,10 +85,6 @@ config SIO_PORT > though UARTs are on the NUVOTON BMC, port 0x164E > PS2 keyboard and mouse are on SUPERIO_WINBOND_W83627DHG, port 0x2E > > -config DRIVERS_PS2_KEYBOARD > - bool > - default y > - > config ONBOARD_VGA_IS_PRIMARY > bool > default y > > -- > coreboot-gerrit mailing list: coreboot-gerrit(a)coreboot.org > http://www.coreboot.org/mailman/listinfo/coreboot-gerrit

1 0

Fwd: embed linux in UEFI?
by Eugen Leitl 10 Oct '13

10 Oct '13

-------- Original Message -------- Subject: embed linux in UEFI? Date: Wed, 9 Oct 2013 11:48:35 -0700 From: Mike Hodgin <mikeserv(a)gmail.com> To: linux-efi(a)vger.kernel.org Hey all, I should first say that I'm not much of a programmer or expert in any special way, and that I'm aware that there are probably perfectly obvious technical reasons which elude me that prohibit and/or obviate some or all of my notions. That said, if any one of you could take the time to describe what it is I don't understand in way that I might I would be very grateful. Personally, I've always thought that the coreboot guys had it right and that Linux in one form or another is really the ideal replacement for BIOS. As I understand it, pretty much since the advent of plug'n'play the OS's have been doing the majority of its work anyway. In a video I watched once coreboot's Ron mentioned that Linux did require BIOS for hardware intialization routines, especially where embedded controllers and ACPI is concerned, but that once power was confirmed Linux (and most others) just took the reins. Probably that's an overly-simplistic description, but that's what I took away from it. Unfortunately due to undocumented proprietary board and BIOS designs coreboot is apparently very difficult to implement. This was especially true when BIOS was BIOS and all its routines were stored in a flash module averaging 512kb or so. The work involved in reverse-engineering an undocumented system written in assembly often specifically designed to protect trade secrets and which necessarily already incorporated any and all possible hacks and compression methods possible just to make it fit in the first place boggles my mind, especially when a single failure can so often be your only chance. I'm astounded they ever made any headway at all, much less acheived compatibility with the more than 100 boards listed on their site. But most of us are nowhere near as capable, nor so motivated, and 100 or more compatible boards or none at all makes little difference if our hardware is not included among them, as is the case for most. But lately I've noticed some interesting goings-on in the UEFI world that indicate a sort of compromise might be possible and so I thought I'd run it by you guys just to find out how off-base I really am. Some of the hackintosh guys have apparently managed to insert their own .DXE driver modules in several system ROMs and for at least one board have installed their own tailored bootloader enabling them to boot OSX on their own PC hardware masked with custom DSDTs directly from UEFI. Some others regularly update their own firmware option ROMs in system flash beyond any board manufacturer support. I found one script that scans an image file for possibly upgradeable modules, installs them as necessary, recompresses and/or recompiles as appropriate, and leaves the user with a flashable image file - all automatically. It seems to me that most of these happenings can be attributed to a few core factors: Firstly, where UEFI is concerned there are three main players: AMI's Aptio, Pheonix's I-forget-the-name, and Intel's Tiano-based images. Of course this was the case before as well, but then board vendors were a lot more likely to modify their ROMs in any number of ways that were little-understood. I'm a bit unclear on this, but I strongly suspect that both AMI and Pheonix lean heavily on Intel's Tiano codebase because of their "opensource" EDK2, even if the irony that it requires a base system such as coreboot just to operate is a little ridiculous. Anyway, with fewer sources the system has become more approachably understandable from a broader standpoint than did BIOS's more specialized days. Adding to that approachability is the move from assembly to a c codebase. I vaguely grasp that it's actually some kind of c specialization or perverse at least in some way, but I can't put my finger on exactly what that means. In any case, it's not machine language. C's adoption alone inflated ROM images many-fold, not to mention whatever other so-called value-added UEFI services might require. This has necessarily lead to the average consumer UEFI board incorporating system flash chips of 4mbs and more just to contain it. I also attribute the change from real- to protected-mode boots to the c migration, though I'm very fuzzy on technicalities. Whereas before BIOS hacking could offer rewards like a .5mb NOR or 64kb of addressable memory, UEFI seems to bring much more to the table in that respect. Owing perhaps a great deal to larger flash chips, board vendors seem to be following the UEFI spec in large part and are conveniently rolling their applicable drivers and configuration images into UEFI modules. Many of them do so with common toolkits provided them by the likes of AMI and Intel. Whether or not any or all of them is very good at it is beside the point; what most interests me about this is that this actually very frequently is described with words such as "common," "toolkit," and "module." I say all of this knowing that obviously anyone on the other end of this email is likely very well aware of these things and much more besides; I only wish to summarize my understanding in case I've got something wrong and someone can help me to understand it better. As I was reading through the various forum threads and about hackintosh UEFI mods and similar that I mentioned before I came to suspect that customizing my own UEFI firmware might be within my reach. The hackintosh mods specifically seem to have mostly been made possible by some curious guy with no special understanding plugging away with a few (very possibly illicitly acquired) vendor drag-and-drop tools in a trial-and-error sort of way until he achieved the results he wanted, all the while allowing his Gigabyte UEFI DualBIOS chips to restore itself themselves as necessary when he fucked it up. The self-updating UEFI script is apparently hosted and maintained by the kind of person you'd expect on a forum; when I asked him about the hows and whys he was unclear and knew only that it worked to upgrade his Intel RAID and did so for everyone else as far as he knew and that was enough. I read through all of this and I thought, "Hey, I'm that guy. Two of my boards have buggy UEFI ROMs that haven't seen an update in a year; I have a DualBIOS backup; ; I can illicitly acquire software if need be; I can fuck things up, too!" As I said before, I'm not a programmer; I just tinker. I follow step-by-step instructions to root my android phones and pride myself on 20-lines of shell-script that I'll sweat over for an hour until finally my zsh prompt reliably presents me with a frowny-face following a non-zero exit code. And I think I can roll linux in my system rom. Obviously the system initialization stuff is well beyond my reach, but I expect some success at least in an attempt at adding a small, kexec-capable, EFI-stub kernel to flash. Some inspection reveals that my Gigabyte board in particular has 700kb to spare even now, and that's before I replace the full 1mb shell module it mysteriously incorporates without providing any discernible means to load. Likely there are other driver modules as well that I have either no need for at boot (such as the option ROM for the flaky consumer-grade RAID controller my board advertises), or even that the vendor shipped bundled because it could in the available storage but that are only applicable to options offered on other similar boards. I know there can be an issue with some UEFI implementations when available storage trickles close to nothing, but I should be able plan for the free 32kb or 64kb necessary to avoid that. And of course there's always DualBIOS. So finally I'm down to the questions (if you've read this far I applaud you for your perseverence in the face of boredom and thank you for your super-human tolerance). Mostly I'd like to know what I've got wrong so far? I feel like I shouldn't be alone in considering this possibility but no amount of googling has surfaced reports of similar experiments. Though iPXE forums occasionally discuss installing a UEFI version of their loader they seem to indicate it should be done to the option ROM of a PCI card as per usual. This mailing list comes close with the recent lengthy back-and-forths about kexec and UEFI possibly mapping over the kernel after exit-boot-services is called, but neither that thread or any other I've discovered mentions in-ROM installation. I assume I must have overlooked something very obvious for it not to have seriously crossed the minds of others. Also, if it were possible, what should I consider? (Other than the real and present danger of bricking my board, of course.) Would I need to incorporate a block and/or filesystem driver for the flash chip or would UEFI's call of the kernel in flash fully map it to memory and obviate that requirement? I've noticed UEFI has this nasty habit of byte-coding anything and everything I do in the EFI shell; a "dh > fs0:\handledump" for instance is perfectly human-readable in its shell but after boot requires a decompile. Is this signifcant? I imagine a small kernel incorporating only the barest of necessities for IP boot and/or to find and mount a disk loaded as a UEFI driver that could then either pick up capabilities as made available by an initramfs image offered on its new mount or kexec completely into another kernel. I think it can work, do you? Have you advice? Admonishment? Ridicule? I welcome all input. -Mike -- To unsubscribe from this list: send the line "unsubscribe linux-efi" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5

1 0

The OS of open source solution
by Stojsavljevic, Zoran 09 Oct '13

09 Oct '13

Hello Coreboot, Today I have decided to change strategy, and instead to include GRUB2 as payload, to my 'stick and ropes' crippled Coreboot POC from December 2012... To add rather SeaBIOS. Here is the pointer to what I did: http://www.coreboot.org/SeaBIOS#Linux And I almost succeeded to boot to HDD, but when it jumped to it, it stalled (end of serial log)! I added both VGA and serial support to SeaBIOS, but two things happened: [1] VGA INT 0x15 does NOT (still) respond and... [2] Unable to lock ram - bridge not found Log pytty(2).txt is attached to this email, and end of the log shown/imported at the end of this email. Please, please, any tips, tricks, observations, advices? _______ PCI: Using 00:02.0 for primary VGA WARNING - Unable to allocate resource at wrmsr_smp:31! WARNING - Unable to allocate resource at wrmsr_smp:31! WARNING - Unable to allocate resource at wrmsr_smp:31! Found 1 cpu(s) max supported 1 cpu(s) MP table addr=0x000f0c00 MPC table addr=0x000f0c10 size=280 SMBIOS ptr=0x000f0be0 table=0x000f0ad0 size=263 XHCI init on dev 00:14.0: regs @ 0xfe820000, 8 ports, 32 slots XHCI protocol USB 2.00, 4 ports (offset 1) XHCI protocol USB 3.00, 4 ports (offset 5) XHCI extcap 0xc1 @ fe828040 XHCI extcap 0xc0 @ fe828070 XHCI extcap 0x1 @ fe828330 EHCI init on dev 00:1a.0 (regs=0xfe837020) EHCI init on dev 00:1d.0 (regs=0xfe838020) Found 0 lpt ports Found 1 serial ports AHCI controller at 1f.2, iobase fe839000, irq 255 Scan for VGA option rom Scan for option roms Press F12 for boot menu. XHCI no devices found PS2 keyboard initialized USB keyboard initialized Initialized USB HUB (1 ports used) Initialized USB HUB (0 ports used) Searching bootorder for: /pci@i0cf8/*@1f,2/drive@0/disk@0 AHCI/0: registering: "AHCI/0: ST3400633AS ATA-7 Hard-Disk (372 GiBytes)" All threads complete. Searching bootorder for: HALT drive 0x000f0a60: PCHS=16383/16/63 translation=lba LCHS=1024/255/63 s=781422768 Space available for UMB: c0000-ee000, f0000-f0a60 Returned 57344 bytes of ZoneHigh e820 map has 6 items: 0: 0000000000000000 - 000000000009fc00 = 1 RAM 1: 000000000009fc00 - 00000000000a0000 = 2 RESERVED 2: 00000000000f0000 - 0000000000100000 = 2 RESERVED 3: 0000000000100000 - 00000000afffe000 = 1 RAM 4: 00000000afffe000 - 00000000b0000000 = 2 RESERVED 5: 00000000fffc0000 - 0000000100000000 = 2 RESERVED Unable to lock ram - bridge not found enter handle_19: NULL Booting from Hard Disk... Booting from 0000:7c00 Thank you, Zoran _______ Most of The Time you should be "intel inside" to be capable to think "out of the box". Intel GmbH Dornacher Strasse 1 85622 Feldkirchen/Muenchen, Deutschland Sitz der Gesellschaft: Feldkirchen bei Muenchen Geschaeftsfuehrer: Christian Lamprechter, Hannes Schwaderer, Douglas Lusk Registergericht: Muenchen HRB 47456 Ust.-IdNr./VAT Registration No.: DE129385895 Citibank Frankfurt a.M. (BLZ 502 109 00) 600119052

1 0

Re: [coreboot] The OS of open source solution
by Stojsavljevic, Zoran 09 Oct '13

09 Oct '13

Hello Tank, I am doing in my own ways this placement, trying to do things using sticks and ropes. I'll try few things (got few new ideas while being on short break) next few days, and see where this goes... Not too much time for that. :-( And I am also interested how did you get incorporated IVB FSP into Coreboot? Does somebody (3rd party) makes specific framework for you (for Byosoft), or you are on your own, like me? ;-) Thank you, Zoran _______ Most of The Time you should be "intel inside" to be capable to think "out of the box". -----Original Message----- From: ron minnich [mailto:rminnich@gmail.com] Sent: Wednesday, October 09, 2013 8:02 AM To: jstkf2012(a)126.com Cc: Stojsavljevic, Zoran; David Hendricks; coreboot Subject: Re: Re: [coreboot] The OS of open source solution well, we are all interested in how to incorporate fsp into coreboot. And you have an FSP binary. It seems to me we have a place to start. ron On Tue, Oct 8, 2013 at 10:02 PM, jstkf2012(a)126.com <jstkf2012(a)126.com> wrote: > Hi Ron, > I am sorry , I am just a freshman in CoreBoot. > Do you interest in how to incorporate the Fsp into Coreboot?But the > source code and the mechanism is not writed and created by myself. > > Thanks, > Tank > From: ron minnich > Date: 2013-10-09 10:07 > To: jstkf2012(a)126.com > CC: Stojsavljevic, Zoran; David Hendricks; coreboot > Subject: Re: Re: [coreboot] The OS of open source solution On Tue, Oct > 8, 2013 at 6:20 PM, jstkf2012(a)126.com <jstkf2012(a)126.com> wrote: >> Hi Ron >> >> I doesn't not drop fsp in to replace the mrc binary. > > We are very interested in what you are doing and if we can help in > some way, please let us know. > > Thanks! > > ron Intel GmbH Dornacher Strasse 1 85622 Feldkirchen/Muenchen, Deutschland Sitz der Gesellschaft: Feldkirchen bei Muenchen Geschaeftsfuehrer: Christian Lamprechter, Hannes Schwaderer, Douglas Lusk Registergericht: Muenchen HRB 47456 Ust.-IdNr./VAT Registration No.: DE129385895 Citibank Frankfurt a.M. (BLZ 502 109 00) 600119052

1 0

Re: [coreboot] The OS of open source solution
by jstkf2012＠126.com 09 Oct '13

09 Oct '13

Hi Ron, I am sorry , I am just a freshman in CoreBoot. Do you interest in how to incorporate the Fsp into Coreboot?But the source code and the mechanism is not writed and created by myself. Thanks, Tank From: ron minnich Date: 2013-10-09 10:07 To: jstkf2012(a)126.com CC: Stojsavljevic, Zoran; David Hendricks; coreboot Subject: Re: Re: [coreboot] The OS of open source solution On Tue, Oct 8, 2013 at 6:20 PM, jstkf2012(a)126.com <jstkf2012(a)126.com> wrote: > Hi Ron > > I doesn't not drop fsp in to replace the mrc binary. We are very interested in what you are doing and if we can help in some way, please let us know. Thanks! ron

2 1

Re: [coreboot] VIA C7 on BCom Winnet P680 - L1/L2 cache very slow
by Corey Osgood 09 Oct '13

09 Oct '13

Thanks, I'll give it a shot! Thanks, Corey

1 0

Re: [coreboot] The OS of open source solution
by jstkf2012＠126.com 09 Oct '13

09 Oct '13

Hi Ron I doesn't not drop fsp in to replace the mrc binary. I said that it just like Bios's MRC . Intel's Fsp may load Microcode , do memory init and so on.... Thanks, TankTang From: ron minnich Date: 2013-10-09 00:44 To: jstkf2012(a)126.com CC: Stojsavljevic, Zoran; David Hendricks; coreboot Subject: Re: [coreboot] The OS of open source solution tank, you can not drop fsp in to replace the mrc binary. Won't work. FSP is a binary blob with a defined API. Or, maybe, you're already using that API? thanks ron

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot October 2013