Hello all,
Having recently followed some of the old discussions regarding a coreboot panic-room (eg. [1], [2]), I have been wondering whether it would be possible to produce a universal panic-room/recovery console implementation on x86, i.e. one that does not necessarily rely on code that is mainboard specific, but is instead able to perform Super I/O and UART detection and init, in a generic fashion (a bit like superiotool or sensors-detect).
The main reason for not wanting to go the mainboard-specific route is that there are a lot of motherboards out there where coreboot support is unavailable, especially recent ones, and providing those with at least some form of panic-room support may help with seeing coreboot implemented. The ability to transfer a bare-metal flashrom, SerialICE, or any other kind of payload to CAR (or to RAM, if a platform specific RAM init payload has previously been transferred and run from CAR), through Y-modem, would probably open a few new avenues for coreboot development.
This is why I am presenting a Proof of Concept, which I call UBRX, of a near-universal yet *safe* method for detecting and providing a panic-room type serial console, aimed at being included in an x86 BIOS bootblock. My hope is that, should you be interested in such a concept, it could become the base of the coreboot panic-room implementation.
Obviously, the focus of this exercise has to do with the safety of the detection, as, if the code that is going to be included in a bona fide BIOS bootblock, emphasis must be placed on making sure that no damage or unwanted stress of any kind, will be incurred on the hardware, even when run at every boot. While this may at first seem like an unreconcilable goal with blanket detection, I believe it is actually possible to solve the problem in a satisfactory way. Thus I hope you can take a look at the proposed solution and decide for yourself if you see technical merit in it. For some insight on how detection can be performed in a manner that is deemed safe, I am also pasting the the 'Detection Primer' section from the UBRX readme at the end of this e-mail.
Now, the other claim of the solution that is likely to raise an eyebrow, is of course universality. As you can reasonably expect from knowledge of the various quirks of the Super I/O & early console detection that coreboot implements, there exist cases where a blanket generic detection does not apply easily. Plus, mostly because this is a PoC, I added some limitations on my own. So currently "universality" comes with the following restrictions:
* The motherboard must have a physical serial port, provided by a Super I/O chip. Console over USB-RS232 adapters is not supported. * Only 16650 compliant UARTs are supported. * Only AMD and Intel x86 CPUs are supported. No VIA, no Transmeta. * The CPU must support the MMX instruction set (Intel Pentium MMX or later, AMD K6 or later) as we use MMX in lieu of stack. * Only Super I/O chipsets conforming to the ISA PnP specifications, and starting in PnP mode on reset are supported (except WMware compatible) * Some non widespread PnP Super I/O chips with complex config mode (eg. IT8671) have voluntarily been dropped. * Powering up of Super I/O Logical Devices is not currently conducted. We currently assert that UART LDs are powered up by default. * With regards to Super I/O chips that require extra configuration from the Southbridge for LPC bus access, only Intel ICH# (any version that requires it) and AMD SB6x0-SB9x0 are supported.
Even with these limitations (most of which could be addressed), I have reason to think that the vast majority of post 2000 PC systems should find their Super I/O and UART properly detected, hence the claim. The big unknown at the moment has to do with nVidia chipsets, since non-NDA datasheets are unavailable for those. The other unknown is whether the current AMD implementation actually works, as I don't have an AMD system to test against. I tested UBRX on 2 Intel platforms (that coreboot does not support), and found that everything ran as expected: one was with a PIII system sporting a 440BX chipset and a W83977TF and the other was a dual core ICH8 with a W83627DHG.
Therefore, I would greatly appreciate if people interested could have a look, possibly test the current PoC, and give their thoughts. The current code and downloads for UBRX can be obtained from visiting: http://code.google.com/p/akeo/
If you want to have a look at the main source, you can also do so at: http://code.google.com/p/akeo/source/browse/ubrx/bios.S It is pure x86 assembly, but please see point #3 at the end of this e-mail with regards to that.
If you have a GNU compiler that can produce x86 code (either on Linux or Windows - 32 or 64 bit doesn't matter), you should easily be able to produce a BIOS ROM you can flash. See the README for instructions. You can also try with a VMware image, if you don't want to run on actual hardware first: just copy the (default) 512 KB bios.rom generated to your VMware install and add a 'bios440.filename = "bios.rom"' line to your .vmx
Once you have an UBRX BIOS running, just set up a NULL-modem cable connection (if using VMware on Windows, you can use com0com to setup a virtual one), set your terminal to 115200 8N1, no hardware handshake, and boot the first machine while maintain the space key pressed in the console. If the detection process worked, you will enter the 'panic-room' console, which currently is limited to just an 'ubrx>' prompt and a serial repeater.
Right now, I am especially interested in tests being conducted on AMD hardware to confirm that the AMD LCP/SouthBridge init works. Again, you should be able to test UBRX even if your platform is not supported by coreboot, provided of course that you can reflash your BIOS through external means afterwards (SPI, parallel programmer, etc.).
Also, while I have reasons to believe that, as far as providing a console is concerned, doing so in a generic/universal fashion on x86 shouldn't be a problem, one of the questions I have is whether the same can apply for CAR init. I'm new to coreboot and a lot of the romstage.c sources I see seem to perform their own Cache As RAM init. On the other hand [3] seems to indicate that CAR init does not necessarily need to be mainboard specific. Do you see a CAR init as a feature that can be achieved in a generic panic-room (even if it may require provision of a few platform/CPU specific parameters through the serial console)? Or are you aware of major issues that would prevent doing so. I'd say that once we have CAR as well as Y-modem transfer of code to CAR, for execution, the game is pretty much won as far as a panic-room implementation is concerned. Thus, if we can a implement both a generic console detection as well as a generic CAR, we're done.
Finally, I'm just going to point out a few items that may be seen as as valid reasons to dismiss UBRX upfront, whereas I don't believe these should really matter: 1. I am aware that there exists a GSoC project for the panic-room [4] but I think this does not touch on the provision of a serial console (yet?). Even then, separate efforts can of course always be merged, which is also why I am producing a PoC rather than a full implementation, and stopping there for the time being. 2. The current license for UBRX is GPLv3 or later (my preference). If you really believe that this will be an issue, I am open to discussion. 3. The source is pure x86 assembly (what's more using Intel syntax rather than the GNU default AT&T), and I have to agree that this will be harder to maintain than say a C source that could be compiled with ROM_CC. On the other hand, the code is intended to be generic, so it does not require duplication/changes for each motherboard and, more importantly, I believe anything that is meant to be part of a semi-permanent bootblock must focus on optimization and size, even if it means a drawback in maintainability, hence the choice of assembly. The current detection process takes less than 2K, which could be optimized further, and leaves enough room for CAR, Y-modem and console functionality in an 8K bootblock. I am doubtful that ROM_CC could include everything we need in 8K.
Comments? Questions? Shoot away...
Regards,
/Pete
[1] http://thread.gmane.org/gmane.linux.bios/25740/focus=26022 [2] http://www.coreboot.org/pipermail/coreboot/2010-February/thread.html#55950 [3] http://www.coreboot.org/data/yhlu/cache_as_ram_lb_09142006.pdf [4] http://blogs.coreboot.org/blog/2011/05/09/gsoc-project-coreboot-panic-room-d...
---------------------------------------------------------------------- Detection primer:
The paragraphs below highlight the generic Super I/O and 16550 UART detection process as performed by UBRX. We believe that this process is safe to be executed at every boot, irrespective of the hardware and without side effects.
The 2 main components UBRX needs to detect are: 1. a potential PnP Super I/O candidate. 2. a potential 16650 UART Logical Device (LD) on the Super I/O chip.
As we start with absolutely no knowledge of the hardware, and must avoid writing data at random, since doing so can damage the hardware, our detection process has been designed with safety in mind from the ground up, by ensuring that write operations were limited to the bare minimum, and only executed after we had some assurance that the destination for the write would match the expectation. Below is a detailed description of how we ensure that our generic detection process is as innocuous to the hardware as possible.
1. The Super I/O chip is accessed through the LPC bus, which is not always accessible after reset, so we may have to enable LPC/SuperIO access first. Currently we only support Intel ICH# (all versions) and AMD SB6x0-9x0. The detection and initialisation of the chipset for LPC access is safe, since it is PCI based, and the PCI VID:PID of the South Bridge can be read beforehand to unconditionally identify a supported chip before we proceed with LPC initiation. You will notice that we use a blanket LPC initialization, as we don't distinguish between versions of the SouthBridge (eg: ICH6 is initialized the same as ICH9), but this is the result of a *thorough* review of all the Intel ICH# and AMD SBxx0 datasheets, to confirm that LPC init could indeed be factorized. Even for the chips that don't require LPC initialization (such as Intel ICH5 or earlier) and for which we do send the LPC initialization command, we have confirmed from the datasheet that we can simply let the PCI transaction fail as no register conflict in the destination config space. As such our LPC bus access initialization is deemed safe.
2. With the LPC bus accessible, we must probe a few common Super I/O ports. Currently, these are 0x2E, 0x4E, 0x370, 0x3f0, as well as their +1 data port. The last two I/O ports are commonly assigned to Tape and FDC so we expect any chip there to withstand unintended writes (plus these can be disabled through the bios.S build options). But even then, the extra checks we apply to the 0x2E and 0x4E ports ensure safe access. With regards to 0x2E and 0x4E, these are more problematic as a non PnP Super I/Os are expected to reside there on older machines, and unchecked write access (such as trying to configure PnP access on a non PnP aware chip) could very well have unintended consequences. To alleviate this problem we: a) always keep a copy of the original value at base and base+1 b) perform PnP enter conf (write to base only) and attempt to read the Super I/O ID (at base +1). If the id is either 0x00 of 0xff, we consider that the address is not one of a PnP Super I/O chip and restore the base data => only the base register will have been accessed, then restored. c) attempt to write 8 LDN values, read them back and check that at least 2 of them stick, indicating that the potential PnP Super I/O chip has at least 2 LDs. If this isn't the case, we also restore the content from base+1 and declare the PnP access to have failed. At most, since we are only writing LDNs, this modifies the 3 lowest bits of base +1. Considering that both superiotool and sensors-detect have let user perform similar Super I/O probing (without the extra restore step), and we are not aware of problems, as well as the fact that any recent PC from our targeted audience would have a Super I/O running in PnP mode at either 0x2e or 0x4e, we consider this approach safe to be executed at every boot.
3. Even with a possible PnP Super I/O chip accessible (and with the current PoC assertion that the UART LD we want to access is powered up by default on reset), we do not have any knowledge of the LDN of the potential UART. With other LDNs being set up for GPIO or hardware monitoring or control, trying to access each LDN as an UART, without exerting any form of caution, is not a viable option. To alleviate this issue, we perform an extensive yet non intrusive detection of a 16550 UART LD by first making sure, through read-only accesses, that the registers match the reset value of a 16550 compliant unit. Then, we try to flip the furthest 'safe' bit in the I/O range (register 7, bit 6, with backup), to eliminate any LD that has less than 7 registers. Then we check a significant unflippable bit from the 16550 register range (which we also restore in case of failure), and finish our testing with a complete UART loopback test. In all, we perform no less than 16 tests to confirm that an LD is indeed a 16550 UART, with more than 30 bits being tested in read-only mode, before we even start trying to flip a single bit. As such, we seem this form of detection both safe and conclusive. At the moment, we test up to 32 LDNs per potential PnP Super I/O for UART access. The 16550 tests are heavily documented in bios.S/check_16550.
Only once we have successfully identified a 16650 UART do we attempt to fully configure it and read the console request key. If multiple UARTs have been identified, these will be checked in sequence, meaning that any serial port available on the motherboard can be used for console access. ----------------------------------------------------------------------
Am Montag, 11. Juli 2011 19:02:03, Pete Batard schrieb:
Comments? Questions? Shoot away...
My main concern is that SuperIO and serial is going away completely ("legacy-free hardware"). When using PCI based boards (eg. extension stuff) we need to poke holes into the northbridge (and/or southbridge) to get access to them (ie. no generic solution either).
We might be better off with widely available USB2 and USB3 debug port tools and software support (and even that requires _some_ chipset specific setup to make the chipset react to it).
Patrick
On 2011.07.11 18:43, Patrick Georgi wrote:
My main concern is that SuperIO and serial is going away completely ("legacy-free hardware").
Alas, yes, native RS232 seems to be on the way out these days. Still (but I'm obviously biased here) we can support most of the non legacy-free hardware with less than 2 KB of code, so why not go for it? Requiring people to acquire hardware that duplicates a functionality they already have, and which we can support without too much effort, doesn't seem like the best approach to me. I'm also wondering how much real-estate a minimal xHCI stack will take in a panic-room bootblock.
But part of the reason I posted is also to find out what the current coreboot plans with regards to the panic-room implementation are, especially as there is a GSoC project for it. Has the set of feature, and how they should be implemented, already been agreed on, or is it still open for discussion?
Regards,
/Pete
Pete Batard wrote:
a minimal xHCI stack
Note needs DMA, except for EHCI Debug Port, which needs a special device.
//Peter
On Tue, 12 Jul 2011 02:03:46 +0200, Peter Stuge wrote:
Pete Batard wrote:
a minimal xHCI stack
Note needs DMA, except for EHCI Debug Port, which needs a special device.
EHCI requires a special device and no DMA (but debug port support in the EHCI controller).
xHCI requires no special device: if the optional debug port feature is provided, everything is inside the controller. However, xHCI potentially requires memory to be around for DMA: there's another optional feature to have the controller provide enough memory in MMIO range to do xHCI debug without RAM.
Now I suppose the question is, if there's a PCIe xHCI controller with both debug port and MMIO-as-RAM features for a reasonable price? If so, all we'd need is a bit of bus poking to make xHCI debug useful for us.
Patrick
But part of the reason I posted is also to find out what the current coreboot plans with regards to the panic-room implementation are, especially as there is a GSoC project for it. Has the set of feature, and how they should be implemented, already been agreed on, or is it still open for discussion?
Hi Pete,
currently my plan is to run flashrom out of cache (in romstage), transfer rom image over console (serial, maybe later ne2k) in small chunks like ~256 bytes so that cache_as_ram.inc would require less changes. Haven't thought about usb debugport, since even this is quite hard task for me.
Thanks, Tadas
Hi Tadas,
On 2011.07.12 02:42, Tadas Slotkus wrote:
currently my plan is to run flashrom out of cache (in romstage), transfer rom image over console (serial, maybe later ne2k) in small chunks like ~256 bytes so that cache_as_ram.inc would require less changes.
That sounds good (and quite a lot of work!). If you manage to produce a flashrom that can run in CAR for romstage, I'm pretty sure it could easily be reused for flashrom in a CAR payload for panic-room.
By the way, if you need a Y-modem implementation in C, for serial transfers, I can provide one, as I had to implement such a feature on another project (which was actually a panic-room payload, but for Realtek SoCs).
It is available here: http://code.google.com/p/xtreamerdev/source/browse/trunk/rtdsr/ymodem.c (complete source package: http://xtreamerdev.googlecode.com/files/rtdsr_0.6_src.tar.gz)
The license is GPLv3, but I'm open to relicensing that specific part of the code (as well as the .h) to GPLv2.1 or later if needed, as I was the only contributor on that project and everything reused was either GPLv2.1 or later, or public domain.
Haven't thought about usb debugport, since even this is quite hard task for me.
I think a lot of people will be happy if you just complete the flashrom goal. I'm definitely one of them.
Regards,
/Pete
On Tue, 12 Jul 2011 00:40:17 +0100, Pete Batard wrote:
I'm also wondering how much real-estate a minimal xHCI stack will take in a panic-room bootblock.
xHCI debug port doesn't require an xHCI stack (though it needs some memory to work on in the background). Like the EHCI debug port, it's a bunch of MMIO registers to work with that provide a bidirectional serial pipe.
Patrick
Pete Batard wrote:
]... ]Right now, I am especially interested in tests being conducted on AMD ]hardware to confirm that the AMD LCP/SouthBridge init works. Again, you ]should be able to test UBRX even if your platform is not supported by ]coreboot, provided of course that you can reflash your BIOS through ]external means afterwards (SPI, parallel programmer, etc.).
Hello Pete,
This is an important subject because recovery is one of the few major features of a commercial BIOS that coreboot+SeaBIOS lacks. I tried the sample on ASRock E350M1 and it did not work. One reason is needed LPC clock initialization (http://permalink.gmane.org/gmane.linux.bios/67229). Another problem is the one mentioned in the release notes about cases where the serial port pins default to gpio use and must be configured for serial port use. I believe this will be the situation with Nuvoton NCT6776F.
I spent a few minutes debugging with AMD simnow but was unable to get it to work there. Maybe some additional port 80 codes that mark algorithm milestones would simplify debug.
Thanks, Scott
On Mon, 11 Jul 2011 20:38:29 -0500, Scott Duplichan wrote:
This is an important subject because recovery is one of the few major features of a commercial BIOS that coreboot+SeaBIOS lacks. I tried the sample on ASRock E350M1 and it did not work. One reason is needed LPC
"Panic Room" features won't be too useful for flash recovery. With partial flash updates and the fallback/normal bootblock it should be possible to build a recoverable update mechanism.
Patrick
On 2011.07.12 07:05, Patrick Georgi wrote:
"Panic Room" features won't be too useful for flash recovery. With partial flash updates and the fallback/normal bootblock it should be possible to build a recoverable update mechanism.
I'd tend to agree that, if you already have coreboot working, fallback is likely to be good enough.
On the other hand, for all the platforms that do not have coreboot yet, a panic-room could be quite useful...
Regards,
/Pete
Hi Scott. Thanks a lot for testing!
On 2011.07.12 02:38, Scott Duplichan wrote:
I tried the sample on ASRock E350M1 and it did not work. One reason is needed LPC clock initialization (http://permalink.gmane.org/gmane.linux.bios/67229).
OK.
I'm obviously a bit nervous about changing a clock frequency that defaults to 14 MHz to 48 MHz, even temporarily, if it is done on every boot, unless we first have insurance that devices connected there support 48 MHz. From looking at the SB800 datasheet, p232 [1], 2 clock lines are provided, so I'm not seeing much of a guarantee that a 48 MHz Super I/O chip is always connected to Clk1...
So I see two possibilities: 1. Add code to identify the motherboard to confirm that the device connected to Clk1/Clk2 supports 48 MHz before we increase the frequency (and decide which Clk should be used) 2. Let the device run at 14 MHz and try to support a 14 MHz mode of operation
#1 looks quite difficult to achieve while keeping a small footprint, so I'd rather go the #2 route, even if that results in the serial port being initialized at a lower nonstandard baudrate. The first thing we can do once we have panic-room access is set the clock to 48 MHz and continue with panic-room operations at 115200.
However, looking at the NCT6776F datasheet for instance, it appears that the SuperI/O is only meant to support 24 and 48 MHz clock frequencies, and I'm guessing the LPC timings from a chip strapped into thinking it runs at 48 while actually running at 14 will be messed up, so that may not be that great an idea...
Another problem is the one mentioned in the release notes about cases where the serial port pins default to gpio use and must be configured for serial port use. I believe this will be the situation with Nuvoton NCT6776F.
That's a good point. From what I can see, the NCT6776F doesn't actually seem to use a dual GPIO/UART, but other Super I/O might. Depending on how widespread these chips are, we might want to detect those. Right now, with UBRX is still in a PoC state, I'd rather avoid introducing special cases. At least, I don't believe is should be needed for testing the E350M1 as it uses a W83627HF.
I spent a few minutes debugging with AMD simnow but was unable to get it to work there. Maybe some additional port 80 codes that mark algorithm milestones would simplify debug.
I can do that, but you have to understand that, if we identify what looks like a PnP Super I/O, we test up to 32 possible LDs in sequence. If an LD is not identified as an UART, we just move on to the next one, so, unless you have a port 80 card with a buffer, I'd need to add a 1 second delay or something each time we fail to identify an LD as an UART, for the user to be notified, and the whole boot process would then take about half a minute (or more, if other PnP Super I/O candidates are identified at other bases).
I'll see what I can do, but if you know your Super I/O base as well as the LDN for the UART you want to use, you can modify the code to only test those, and report the error. Or you can just wait, as I'll update UBRX soon, to make is easier to test only a specific UART LDN and Super I/O base and add extra debug, to facilitate troubleshooting.
Regards,
/Pete
On 2011.07.12 02:38, Scott Duplichan wrote:
I tried the sample on ASRock E350M1 and it did not work. One reason is needed LPC clock initialization (http://permalink.gmane.org/gmane.linux.bios/67229).
Hi Scott,
With my apologies for the delay, I have just pushed an updated version of ubrx to svn. It includes SB8x0 48 MHz Clk1 init, the ability to provide of SIO base, type and UART LDN, as well as additional DIAG codes to help with the troubleshooting.
If you want to give it a try again, you can fetch it from: svn checkout http://akeo.googlecode.com/svn/ubrx ubrx or just update if you already checked out.
The options of interest to you should be at the top of bios.S. First of all, you will need to enable SB800_48MHZ_INIT (set it to 1) for your platform.
I will also invite you to uncomment and set the SUPERIO_BASE/UART_LDN/TYPE values according to your board, as well as disable VMWARE_SUPPORT, so that we can get relevant diagnostic values. Note that not all checks are disabled, when providing base/type/LDN, especially the full 16550 check still occurs. However, the extra POST codes should tell us which test is failing.
As you may also see from the code, the MMIO mapping for the Misc. Register is done using address 0008_0000h as a base (page 8000h), which I would expect to be and not mapped to anything else after reset in real mode, but that you can try to change if you see 0xFE as a POST code. If you can't get past the 0xFE POST code, that means there's either a bug or a design issue with my current MMIO mapping for SB8x0.
Any testing you can perform will be much appreciated!
Regards,
/Pete
Pete Batard wrote:
]Hi Scott, ] ]With my apologies for the delay, I have just pushed an updated version ]of ubrx to svn. It includes SB8x0 48 MHz Clk1 init, the ability to ]provide of SIO base, type and UART LDN, as well as additional DIAG codes ]to help with the troubleshooting. ] ]If you want to give it a try again, you can fetch it from: ] svn checkout http://akeo.googlecode.com/svn/ubrx ubrx ]or just update if you already checked out.
Hello Pete,
Thanks for the clock code. It works on asrock e350m1 with the attached patch.
Thanks, Scott
On 2011.07.15 03:35, Scott Duplichan wrote:
Thanks for the clock code. It works on asrock e350m1 with the attached patch.
Wow, great!
Thanks a lot for testing it. Did you also try full autodetection, or did you just try forced base/type/ldn?
Regards,
/Pete
Also, if it's not too much to ask and if the code works without FORCE_PANIC, I wouldn't mind finding out where it breaks if not using the 48 MHz init (using forced base/type/ldn).
I have now committed your patch to svn. Will still need to figure out what the best approach might be with regards to 48 MHz SIO init. But thanks again for fixing my silly mistakes.
Regards,
/Pete
Pete Batard wrote:
]Also, if it's not too much to ask and if the code works without ]FORCE_PANIC, I wouldn't mind finding out where it breaks if not using ]the 48 MHz init (using forced base/type/ldn). ] ]I have now committed your patch to svn. Will still need to figure out ]what the best approach might be with regards to 48 MHz SIO init.
Hello Pete,
I do not have that board setup at the moment so I cannot try it without FORCE_PANIC. It seems like a baud rate change could substitute for the LPC clock frequency programming, but so far that does not work as expected.
I have an AMD SB900 board with Nuvoton NCT6776F. To make the serial port work on this board, two pieces of non-generic code are needed.
1) SIO com1 pins default to GPIO and must switched to serial port use: // logical device 2 (UART A) defaults to base 3f8, irq 4, enabled // all that is needed for early serial is to switch some dual function // pins from gpio use (default) to serial port use. Clearing cr2a bit 7 // does this. u8 reg8; pnp_enter_ext_func_mode(dev); reg8 = pnp_read_config(dev, 0x2a); reg8 &= ~(1 << 7); pnp_write_config(dev, 0x2a, reg8); pnp_exit_ext_func_mode(dev);
2) LPC clock frequency programming and enable: static void sb900_clocks(void) { u8 reg8; u32 reg32; volatile u32 *acpi_mmio28 = (void *) (0xFED80000 + 0xE00 + 0x28); volatile u32 *acpi_mmio40 = (void *) (0xFED80000 + 0xE00 + 0x40);
// Program AcpiMmioEn to enable MMIO access to ClkDrvSth2, MiscClkCntrl registers outb(0x24, 0xCD6); reg8 = inb(0xCD7); reg8 |= 1; reg8 &= ~(1 << 1); outb(reg8, 0xCD7);
// Program ClkDrvSth2 OSCOUT1_CLK_sel for 48 MHz (default is 14 MHz) reg32 = *acpi_mmio28; reg32 &= ~(7 << 16); reg32 |= 2 << 16; *acpi_mmio28 = reg32;
// Program MiscClkCntrl OSCOUT1_Clk_OutputEn to zero to enable LPC clock reg32 = *acpi_mmio40; reg32 &= ~(1 << 2); // Auxiliary Clock1, OSCOUT1 clock output enable *acpi_mmio40 = reg32; }
Thanks, Scott
Hi Scott,
On 2011.07.18 04:14, Scott Duplichan wrote:
I do not have that board setup at the moment so I cannot try it without FORCE_PANIC. It seems like a baud rate change could substitute for the LPC clock frequency programming, but so far that does not work as expected.
OK. One way I see to autodetect the 48MHz or other frequencies, while not endangering a board would be to only attempt higher frequencies if the CMOS has been reset.
If we detect successful panic entry then, we store the working SB frequency to the CMOS and use it on subsequent boots. If not, we also update the CMOS, but to indicate not to try higher frequencies any more.
So I think we should have an acceptable and safe solution for generic SB800/SB900 clock detection. And of course, we could store the last successful SIO base/type/LDN in CMOS as well to bypass autodetection.
Since we're still at the PoC stage, I'll probably stick to using build options for a while, so that people willing to test do not have to reset their CMOS content.
Of course, if we can just get UART (and SIO) communication working at the default lower frequency, and have some confidence that it should work for other SIOs, which is a big "if", that would be preferred. I can probably set UBRX to try for few extra lower clock divisors on the 16550, to compensate for the lower clock.
I have an AMD SB900 board with Nuvoton NCT6776F. To make the serial port work on this board, two pieces of non-generic code are needed.
- SIO com1 pins default to GPIO and must switched to serial port use:
// logical device 2 (UART A) defaults to base 3f8, irq 4, enabled // all that is needed for early serial is to switch some dual function // pins from gpio use (default) to serial port use. Clearing cr2a bit 7 // does this. u8 reg8; pnp_enter_ext_func_mode(dev); reg8 = pnp_read_config(dev, 0x2a); reg8&= ~(1<< 7); pnp_write_config(dev, 0x2a, reg8); pnp_exit_ext_func_mode(dev);
Thanks for the info. Obviously, any SIO that sees its UARTs disabled by default will require a special case, so we will have to figure out whether they are widespread.
As long as it is limited to specific extra PnP SIO init and there aren't too many chips, A data section using a match on the chip ID should do and should offer something that can easily be updated for other chips. That's how I'm going to implement it for the NCT6776F.
- LPC clock frequency programming and enable:
This does not look that different from SB800, so it shouldn't be too difficult to factor in. The new register at address 28 didn't exist on the SB800. Is there a public SB900 datasheet were it is documented? So far, I haven't been able to locate one?
At any rate, many thanks for the info: this is exactly the kind of data I was looking for and it will give me more food for thought.
I'll try to update UBRX to work against your SB900/NCT6776F, if you want to test it on that platform. This may take a few days.
Regards,
/Pete
On 2011.07.18 04:14, Scott Duplichan wrote:
I have an AMD SB900 board with Nuvoton NCT6776F. To make the serial port work on this board, two pieces of non-generic code are needed.
As promised, I have now updated UBRX to support SB900 boards and NCT6776F SIOs.
As for the SB800, the SB900 init is currently not enabled by default and must be selected with a build option. It is also very much untested. While adding SB900 support, I also found a bug with regards to the SB800 init, where DS was used instead of ES, which leaves me quite surprised the previous 48 MHz init actually worked at all...
With regards to the NCT6776F extra init, it is handled enirely from a data section, currently residing in bios.S, which goes something like this:
special_init: # WinBond W83977TF (example) # .word 0xffff # PnP chip ID mask # .word 0x9773 # PnP chip ID (big endian format: [0x20][0x21]) # .byte 0x22 # PnP register index # .byte 0xfe # AND mask to apply (clear bits - here, clear bit 0) # .byte 0x30 # OR value to apply (set bits - here, set bits 4&5) # .byte 0xff # end of section # The Nuvoton NCT6776F defaults with Serial A & B disabled => enable them .word 0xffff .word 0xc333 # NCT6776F chip ID .byte 0x2a # Multi Function Selection register .byte 0x1f # bit 7, 6 & 5 cleared => Serial A & B enabled .byte 0x00 .byte 0xff # end of section special_init_end:
I believe this approach should make it easy enough to add other PnP SIO special inits. The big question of course is how many of those will be required...
Finally, to make UBRX a bit more interesting as a panic room, I have added a "RISC" script mode to the console, aimed at being used primarily for CAR setup. It offers the following commands [1]:
? - dump accumulator: Display the current value of EAX in hexascii (32 bit). $ <hex value> - assign immediate: Assign an immediate 32 bit hexascii value to EAX. Leading zeroes can be omitted. a/b/c/d - move accumulator to register: Move the current value of EAX into CR0/EBX/ECX/EDX respectively. A/B/C/D - move register to accumulator: Move the current value of CR0/EBX/ECX/EDX into EAX. p/q/r - output to port Move AL(byte)/AX(word)/EAX(longword) to the port indexed by DX. P/Q/R - input from port Move the current byte/word/longword value of the port indexed by DX to AL/AX/EAX respectively. x/y/z - move accumulator to memory Move AL(byte)/AX(word)/EAX(longword) to the 32 bit memory location indexed by EDX. X/Y/Z - move from memory to accumulator Move the byte/word/longword value of the 32 bit memory location indexed by EDX into AL/AX/EAX respectively. # - cpuid Issue the CPUID instruction. The current values of EAX will be used for the index. The returned values can be accessed in EAX/EBX/ECX/EDX. ! - invd Invalidate (flush) internal cache m - write to MSR Write the 64 bit value from EDX:EAX into the Model Specific Register indexed by ECX. M - read from MSR Read the 64 bit value from the Model Specific Register indexed by ECX into EDX:EAX. . - exit script mode and return to main prompt.
Theoretically, the above instructions should provide everything needed for CAR setup. And with a jump call ('r' from the main prompt) that uses the last EAX/EBX from script mode as CS:IP/SS:SP, one may actually be able to use the current script mode to transfer and run a complete binary from CAR, though, it is likely to be very impractical right now, especially with no handshaking in place for pasting scripts.
However if you want to poke around ports or memory prior to init, this early _alpha_ of UBRX may be of help.
To obtain the latest version, visit http://code.google.com/p/akeo/ As usual, test reports and/or comments will be much appreciated, regardless of the x86 hardware being used.
Regards,
/Pete
On 07/11/11 18:02, Pete Batard wrote:
Comments? Questions? Shoot away...
Instead of attempting (and failing) to achieve universal support I would rather see a framework that could easily be configured with the appropriate SIO support and allow for board specific configuration if necessary. This should remove a lot of the complexity that gives very little advantage in trying for universal support. coreboot is built as hardware specific and I see no reason why the panic room support should not be the same. Choosing the SIO support to configure for the panic room can be easily done from the output of superiotool. Additionally if it was done in such a way that the serial transport could be easily replaced by USB debug instead then we could really have something that would be useful for new boards.
Andrew
On 2011.07.12 07:15, Andrew Goodbody wrote:
Instead of attempting (and failing) to achieve universal support
I'll start with the aside, that if "failing" means instantly supporting more than 90% of Intel based motherboards produced in the last 10 years (if you have an ICH# or a 440BX controller, you should be good, as you only have one clock for Super I/O, that isn't programmable), as well as a large chunk of AMD motherboards (once the SB clock programming issue is solved, which I'm pretty sure can be done), then I wonder how the rate of support that coreboot has with regards to motherboards produced in the last few years would qualify... Please do not misconstrue this as criticism of coreboot, as it isn't. It's just that, if I were to start coreboot development, I sure wouldn't mind if someone else had already sorted some kind of bare metal console access for my platform, even if that applied "only" to 3/4th of all x86 motherboards produced in the last 10 years...
I would rather see a framework that could easily be configured with the appropriate SIO support and allow for board specific configuration if necessary. This should remove a lot of the complexity that gives very little advantage in trying for universal support. coreboot is built as hardware specific and I see no reason why the panic room support should not be the same.
I guess we have different definition of a panic-room then. From my dealings with Realtek SoCs, the way I see a panic-room is something that is as hardware agnostic as possible. In the ideal case, the panic-room is implemented ondie directly on a CPU that has an UART unit, and therefore with no possible knowledge of the hardware surrounding it. Such knowledge is to be provided by the user. This is what the RTD1283 provides for instance (8KB bootblock, with console and Y-modem upload in CPU ROM), and it is extremely powerful. The panic-room is then intended as a means for users to perform hardware initialization such as RAM or Flash access, as well as any other task they might fathom. Hence, this is the implementation of a panic-room I have been trying to follow, as it is the one that is most versatile and helpful to users IMO.
Choosing the SIO support to configure for the panic room can be easily done from the output of superiotool.
Provided superiotool knows about the chip, which may not be the case yet. If Nuvoton introduces a new chip tomorrow, for which we haven't seen a datasheet yet, I'm pretty sure UBRX will work just fine. Superiotool, not so much... Also picking a coreboot BIOS from one machine and soldering it into another, with the expectation that even if the motherboards have nothing in common but the flash they use, panic-room access will be available, can have its advantages, be it only for ghetto-style budget-constrained tinkerers.
Additionally if it was done in such a way that the serial transport could be easily replaced by USB debug instead then we could really have something that would be useful for new boards.
Well, depending how much space EHCI/xHCI USB support would take, I don't see why UBRX wouldn't be able to provide both. But right now, considering that there is still an awful lot of modern yet legacy based systems out there that could benefit from coreboot support, concentrating on native UART doesn't seem like a bad idea.
Regards,
/Pete
Sorry but my replies are having problems getting to the list. Greylisting is not supported by the company mail system.
On 07/12/11 18:42, Pete Batard wrote:
On 2011.07.12 07:15, Andrew Goodbody wrote:
Instead of attempting (and failing) to achieve universal support
I'll start with the aside, that if "failing" means instantly supporting more than 90% of Intel based motherboards produced in the last 10 years
Yes, universal means everything. If you do not support everything then it is not universal. The use of universal sets false expectations.
...
I would rather see a framework that could easily be configured with the appropriate SIO support and allow for board specific configuration if necessary. This should remove a lot of the complexity that gives very little advantage in trying for universal support. coreboot is built as hardware specific and I see no reason why the panic room support should not be the same.
I guess we have different definition of a panic-room then. From my dealings with Realtek SoCs, the way I see a panic-room is something that is as hardware agnostic as possible. In the ideal case, the panic-room is implemented ondie directly on a CPU that has an UART unit, and therefore with no possible knowledge of the hardware surrounding it. Such knowledge is to be provided by the user. This is what the RTD1283 provides for instance (8KB bootblock, with console and Y-modem upload in CPU ROM), and it is extremely powerful. The panic-room is then intended as a means for users to perform hardware initialization such as RAM or Flash access, as well as any other task they might fathom. Hence, this is the implementation of a panic-room I have been trying to follow, as it is the one that is most versatile and helpful to users IMO.
Yes we see different priorities for a panic room, but I think you misunderstood how much knowledge of the platform I was suggesting needed to be configured. You would choose the SIO/UART support, possibly specifying IO to use. The board specific configuration, if needed, was only for setting GPIOs etc in order to get the RS232 port working or configuring programmable clocks. That's all. To me a panic room should be as simple and bullet proof as possible and if that means pre-configuring the build then so be it. Being 'hardware agnostic' helps in putting it on a new platform, assuming that platform conforms to the restrictions, but it does not help in actual operation of the panic room. So to me that would be an unnecessary complication. Your example of a panic room ondie with a UART is not hardware agnostic at all, you have pre-knowledge of the critical elements for establishing a console. I was not suggesting building in knowledge of anything more than how to reach and configure the UART in order to establish a console, so we both agree that more complex operations would require interaction with the user.
Choosing the SIO support to configure for the panic room can be easily done from the output of superiotool.
Provided superiotool knows about the chip, which may not be the case yet. If Nuvoton introduces a new chip tomorrow, for which we haven't seen a datasheet yet, I'm pretty sure UBRX will work just fine.
OK, well how about the SIO support from UBRX being one of the SIO modules that can be chosen. My main concern is allowing a simple method of getting panic room support to work on boards that do not meet your restrictions.
Superiotool, not so much... Also picking a coreboot BIOS from one machine and soldering it into another, with the expectation that even if the motherboards have nothing in common but the flash they use, panic-room access will be available, can have its advantages, be it only for ghetto-style budget-constrained tinkerers.
Shudders! Do we really want to encourage that?
Additionally if it was done in such a way that the serial transport could be easily replaced by USB debug instead then we could really have something that would be useful for new boards.
Well, depending how much space EHCI/xHCI USB support would take, I don't see why UBRX wouldn't be able to provide both. But right now, considering that there is still an awful lot of modern yet legacy based systems out there that could benefit from coreboot support, concentrating on native UART doesn't seem like a bad idea.
All I was asking was that the design allowed for an alternate transport with minimum disruption. I did not suggest abandoning the work for UARTs.
Cheers, Andrew
Regards,
/Pete
On 2011.07.13 12:03, Andrew Goodbody wrote:
I'll start with the aside, that if "failing" means instantly supporting more than 90% of Intel based motherboards produced in the last 10 years
Yes, universal means everything. If you do not support everything then it is not universal. The use of universal sets false expectations.
In that case, "unlimited broadband" means truly unlimited, and fair expectations are not supposed to be applied to the claim. I guess if you would prefer an asterisk after the Universal in UBRX, with a "Terms and Conditions apply", this can be arranged... ;)
This being said, the 90% with regards to Intel chipsets applies to the *PoC* (guesstimate obviously, but I think I'm probably pessimistic when only those weird ITE init and non PnP Super I/Os are expected to fail detection, which I doubt many of the ICH motherboard from the last 10 years would have). The final version could be a lot closer to the 100% mark, especially if we attempt detect both native UART and USB 3.0 debug, as legacy free hardware, which I suppose is expected to have PCI-E, would just need an xHCI PCI-E card we can detect to get going.
I also don't think the idea of dropping support for non PnP SIO chips detracts from the claim of Universality(*) that much. A comparison would be to claim that Windows software released in 2011 does not actually qualify as being "Windows compatible" or put Windows on the box if it doesn't support Windows 98 (And, just like Windows software comes with a "minimum system requirements", our Readme comes with about the same thing in the form of current UBRX limitations). My understanding is that most manufacturers would have switched to PnP SIOs around '98 as well, so the Windows 98 comparison seems appropriate.
Finally, please remember that this is only a PoC, which is expected to be incomplete or, gasp, have bugs (still working on it). Most of the limitations or problems currently applying, can either be lifted or worked around one way or another. However, there is only so much I can test so yes, in its current instance, U(*)BRX does fall short of its established goal of Universality(*). However, I'm not seeing a major reason why it couldn't get there, hence the claim.
At least I am hoping that it is OK to come to this list, with something that is still incomplete, to see if there is interest, and not being requested to come back with a solution that is feature complete and spotless.
Yes we see different priorities for a panic room, but I think you misunderstood how much knowledge of the platform I was suggesting needed to be configured.
OK, that's probably fair.
To me a panic room should be as simple and bullet proof as possible and if that means pre-configuring the build then so be it.
The problem I have with pre-configured is you need to have prior knowledge. So in effect, your panic room would be restricted to only platforms that coreboot already supports, which, to mirror your "unnecessary complication" below, I would see as an "unnecessary limitation".
Being 'hardware agnostic' helps in putting it on a new platform, assuming that platform conforms to the restrictions, but it does not help in actual operation of the panic room. So to me that would be an unnecessary complication. Your example of a panic room ondie with a UART is not hardware agnostic at all, you have pre-knowledge of the critical elements for establishing a console.
Call me confrontational, but I am going to dispute the "not hardware agnostic at all".
If AMD and Intel agreed tomorrow to provide an UART ondie, accessed in the same fashion, on all of their future x86 chips, should we consider that this knowledge should be out of bounds? Or how about FPUs? Older x86 CPUs did not have an FPU unit ondie. Should we then consider that a program that just uses the FPU, since it has been for about the past 20 years, and no external hardware, can not be considered hardware agnostic and should have performed FPU detection?
To me there is such thing as internal hardware, which is 100% fair game to use as soon as it is introduced, as, in the worst case scenario, it can easily be detected from the public CPU specs, and external hardware, which, and this is the critical point, may include elements that have not even been designed yet. So I would say that a panic room ondie with an UART, if all CPUs from the same line have this feature, is hardware agnostic. But then again, whether hardware agnosticism applies to a CPU that is irrelevant to coreboot doesn't bring much to the discussion.
OK, well how about the SIO support from UBRX being one of the SIO modules that can be chosen. My main concern is allowing a simple method of getting panic room support to work on boards that do not meet your restrictions.
That's one of my concerns too.
As I indicated above, I am not planning to spend much time on getting non PnP SIOs, or PnP SIOs that require some weird init to be supported by UBRX.
This being said, UBRX does support the VMWare virtual SIO, which is not PnP, and I think your idea about trying to be modular in UBRX is a good one. I can probably create a separate module for the VMWare non PnP SIO, which could be used as a template for other SIOs that people want to see supported, and that may not be detected in UBRX main. Such modules could then be selected and included conditionally at buildtime. But I do see the need for blanket detection being the main focus, if we can easily perform it and it avoids being limited to only what we know.
With this, unconditional universality may actually apply to UBRX after all (though some may claim that if everything isn't supported at the same time, it's still not universal)... ;)
Superiotool, not so much... Also picking a coreboot BIOS from one machine and soldering it into another, with the expectation that even if the motherboards have nothing in common but the flash they use, panic-room access will be available, can have its advantages, be it only for ghetto-style budget-constrained tinkerers.
Shudders! Do we really want to encourage that?
I most certainly see some merit in that for the following reasons: One is the consideration that people who may have a lot of time on their end may not be the ones with the highest means of income, and coreboot could probably use people with a time on their hand to support new motherboards. The second reason is that there are an awful lot of proprietary systems out there with soldered (non SPI) flash chips (Dell, Compaq, etc...), that could really benefit from coreboot. Past their prime, these systems can be obtained fairly cheaply, from corporate sales, etc., and therefore are a good target for coreboot development. However, when the first step of coreboot development is to install a BIOS socket as well as get an external flasher, this is likely to put potential contributors off. On the other hand, while there is obviously a risk that the U(*)BRX panic-room may not work, there's a good chance that it will and thus provide developers with both the possibility to explore their hardware and test a coreboot development payload.
So I guess the question is: do we want a panic-room that only applies to systems that coreboot already support? Or do we want it to also be used as a tool for the adding of new systems. If only the former, then U(*)BRX is likely an overkill. But even a panic-room seems a bit of an overkill to me, as all you probably want from it is flash recovery...
Regards,
/Pete
(*) Terms and Conditions apply
On 07/13/11 22:25, Pete Batard wrote:
On 2011.07.13 12:03, Andrew Goodbody wrote:
I'll start with the aside, that if "failing" means instantly supporting more than 90% of Intel based motherboards produced in the last 10 years
Yes, universal means everything. If you do not support everything then it is not universal. The use of universal sets false expectations.
In that case, "unlimited broadband" means truly unlimited, and fair expectations are not supposed to be applied to the claim.
But that is the point. Your support is not universal and unlimited broadband is not unlimited and should not be described as such. I object to the use of an absolute description to refer to something that is not absolute.
I guess if you would prefer an asterisk after the Universal in UBRX, with a "Terms and Conditions apply", this can be arranged... ;)
I would prefer it not be described as universal at all.
This being said, the 90% with regards to Intel chipsets applies to the *PoC* (guesstimate obviously, but I think I'm probably pessimistic when only those weird ITE init and non PnP Super I/Os are expected to fail detection, which I doubt many of the ICH motherboard from the last 10 years would have). The final version could be a lot closer to the 100% mark, especially if we attempt detect both native UART and USB 3.0 debug, as legacy free hardware, which I suppose is expected to have PCI-E, would just need an xHCI PCI-E card we can detect to get going.
I will not argue over made up statistics.
...
Nor will I argue a strawman.
Finally, please remember that this is only a PoC, which is expected to be incomplete or, gasp, have bugs (still working on it). Most of the limitations or problems currently applying, can either be lifted or worked around one way or another. However, there is only so much I can test so yes, in its current instance, U(*)BRX does fall short of its established goal of Universality(*). However, I'm not seeing a major reason why it couldn't get there, hence the claim.
And so increase complexity and reducing reliability.
At least I am hoping that it is OK to come to this list, with something that is still incomplete, to see if there is interest, and not being requested to come back with a solution that is feature complete and spotless.
!!! Of course you are welcome to come to this list with incomplete ideas. I was trying to work with you to improve it. I object to your claim of universal support, not your aim of supporting as much as possible. I do not want your description to set up false expectations. I see no request in that to go away until your support is complete and spotless. That comes only from your desire to make your idea live up to the description you chose.
Yes we see different priorities for a panic room, but I think you misunderstood how much knowledge of the platform I was suggesting needed to be configured.
OK, that's probably fair.
To me a panic room should be as simple and bullet proof as possible and if that means pre-configuring the build then so be it.
The problem I have with pre-configured is you need to have prior knowledge. So in effect, your panic room would be restricted to only platforms that coreboot already supports, which, to mirror your "unnecessary complication" below, I would see as an "unnecessary limitation".
Not at all. The pre-knowledge of the hardware required is just how to get to the UART. It is very, very far from requiring existing coreboot support. You do not need to know how to set up memory, you do not need to know how the interrupts are configured, you do not need to know what PCI/PCIe devices there are, etc. etc. which are all things needed for coreboot. So no you are not limited to platforms that coreboot already supports.
Being 'hardware agnostic' helps in putting it on a new platform, assuming that platform conforms to the restrictions, but it does not help in actual operation of the panic room. So to me that would be an unnecessary complication. Your example of a panic room ondie with a UART is not hardware agnostic at all, you have pre-knowledge of the critical elements for establishing a console.
Call me confrontational, but I am going to dispute the "not hardware agnostic at all".
If AMD and Intel agreed tomorrow to provide an UART ondie, accessed in the same fashion, on all of their future x86 chips, should we consider that this knowledge should be out of bounds? Or how about FPUs? Older x86 CPUs did not have an FPU unit ondie. Should we then consider that a program that just uses the FPU, since it has been for about the past 20 years, and no external hardware, can not be considered hardware agnostic and should have performed FPU detection?
To me there is such thing as internal hardware, which is 100% fair game to use as soon as it is introduced, as, in the worst case scenario, it can easily be detected from the public CPU specs, and external hardware, which, and this is the critical point, may include elements that have not even been designed yet. So I would say that a panic room ondie with an UART, if all CPUs from the same line have this feature, is hardware agnostic. But then again, whether hardware agnosticism applies to a CPU that is irrelevant to coreboot doesn't bring much to the discussion.
You are confrontational and you are arguing points that I do not hold and this I think is due to a misunderstanding of 'hardware agnostic'.
All I was saying is that use of internal hardware implies pre-knowledge of that hardware and that is included into the build. My suggestion of being able to configure the use of a different SIO or allowing easy insertion of motherboard specific GPIO settings is on the same level of pre-knowledge as is required to use internal hardware. I never suggested that any knowledge was out of bounds. I was suggesting being able to build knowledge into a specific build of the panic room in order to reduce complexity and so get closer to your aim of universal support.
OK, well how about the SIO support from UBRX being one of the SIO modules that can be chosen. My main concern is allowing a simple method of getting panic room support to work on boards that do not meet your restrictions.
That's one of my concerns too.
As I indicated above, I am not planning to spend much time on getting non PnP SIOs, or PnP SIOs that require some weird init to be supported by UBRX.
I did not ask for support for these to be implemented by you, merely a framework that would allow them to be supported without having to make in depth changes to the core support.
This being said, UBRX does support the VMWare virtual SIO, which is not PnP, and I think your idea about trying to be modular in UBRX is a good one. I can probably create a separate module for the VMWare non PnP SIO, which could be used as a template for other SIOs that people want to see supported, and that may not be detected in UBRX main. Such modules could then be selected and included conditionally at buildtime.
I think we may even both be able to agree that this is a good idea.
But I do see the need for blanket detection being the main focus, if we can easily perform it and it avoids being limited to only what we know.
Yes, but not at the cost of excessive complexity and reduced reliability.
With this, unconditional universality may actually apply to UBRX after all (though some may claim that if everything isn't supported at the same time, it's still not universal)... ;)
Superiotool, not so much... Also picking a coreboot BIOS from one machine and soldering it into another, with the expectation that even if the motherboards have nothing in common but the flash they use, panic-room access will be available, can have its advantages, be it only for ghetto-style budget-constrained tinkerers.
Shudders! Do we really want to encourage that?
I most certainly see some merit in that for the following reasons: One is the consideration that people who may have a lot of time on their end may not be the ones with the highest means of income, and coreboot could probably use people with a time on their hand to support new motherboards. The second reason is that there are an awful lot of proprietary systems out there with soldered (non SPI) flash chips (Dell, Compaq, etc...), that could really benefit from coreboot. Past their prime, these systems can be obtained fairly cheaply, from corporate sales, etc., and therefore are a good target for coreboot development. However, when the first step of coreboot development is to install a BIOS socket as well as get an external flasher, this is likely to put potential contributors off. On the other hand, while there is obviously a risk that the U(*)BRX panic-room may not work, there's a good chance that it will and thus provide developers with both the possibility to explore their hardware and test a coreboot development payload.
Well your plan requires two motherboards plus a development system. The first with an existing coreboot image with working panic room. The second using a compatible BIOS flash chip. You start by removing the BIOS chip, containing the coreboot image with panic room, from a working board, rendering it useless. Then you swap in that BIOS flash chip onto the second board and hope that the panic room still works and will give you a console accessible from your development system. What if it does not work? You have no way forward.
However if you allow the soldering of a socket (the same soldering skill needed as swapping a chip) you can do the following. One motherboard can act as your development system and as your flashing tool by doing a hot flash for the other. You do not need an existing coreboot support for either and you are not left with a useless motherboard. The cost of two sockets should be a lot less than another motherboard and no external flasher is needed.
So I guess the question is: do we want a panic-room that only applies to systems that coreboot already support? Or do we want it to also be used as a tool for the adding of new systems.
You guess wrong. The question is how much complexity do we want for little or no discernible gain? Of course using it for new systems would be a good thing and my suggestions in no way prevent that.
Andrew
On 2011.07.14 11:59, Andrew Goodbody wrote:
I object to the use of an absolute description to refer to something that is not absolute.
I would prefer it not be described as universal at all.
Point taken.
Believe me, I'd really like to keep you happy and change the U to something like "Useful" instead of "Universal" (though I guess even "Useful" could not be used in the absolute, since people may say UBRX isn't useful to them), and I almost went ahead with that... But on second thoughts, I really don't see why UBRX should lack the punch that both USB or U-boot have, through their use of "Universal", especially when our aspirations are exactly the same (the choice of the UBRX acronym was partially inspired by U-boot).
Arguably, the Universal in USB does not apply to the protocol itself, since a protocol is of course universal between all entities that that speak it (RS232 is universal too), so the scope of Universal in USB has to be with regards of its intended reach, just as is the case with U-boot. And clearly both USB and U-boot are abusing the Universal in their name then, since I don't see how they too can qualify as absolute universal (unless one acquires the right to use universal only once they are successful enough).
If you want to say it's a misnomer or abuse, you are of course technically correct, so I'm not going to dispute that. But I wouldn't mind having people be drawn to a project because they see that its aspiration is to provide something that is as universal as can be, just like USB and U-boot, than a project whose name is factually correct, but which may leave newcomers with some doubt about what its intended target reach is.
If people want a specific target supported, that UBRX does not support, then, resources permitting (and provided there is interest in UBRX, which remains to be seen), I'll do my best to get it supported. I'm currently not aware of any board that we shouldn't technically be able to support: Unless they are crazy fast, we should be able to disable watchdogs from automating the upload of a panic-room payload, so we are unlikely to need a special case for that. Dual BIOS is more of an issue, but the main problem is that we don't have data on Dual BIOS, and nobody seems to have reverse engineered much of it. So the only big unknown I have is with regards to the powering up of LDs, as well as any extra chipset initialization, such as the 48 MHz clock init from SB800, that I may have missed. Thus, the target of being universal is more likely to be constrained by resources than by technical feasibility.
If U-boot can use Universal, I think I'm going to follow suit, while agreeing with you that the Universal from UBRX is unlikely to ever be absolute.
Finally, please remember that this is only a PoC, which is expected to be incomplete or, gasp, have bugs (still working on it). Most of the limitations or problems currently applying, can either be lifted or worked around one way or another. However, there is only so much I can test so yes, in its current instance, U(*)BRX does fall short of its established goal of Universality(*). However, I'm not seeing a major reason why it couldn't get there, hence the claim.
And so increase complexity and reducing reliability.
Or prevent misconfiguration errors, ensure that most of the code (since much of it would be common/factorized) has been tested by a greater number of people, and increase reliability and reach.
I was suggesting being able to build knowledge into a specific build of the panic room in order to reduce complexity and so get closer to your aim of universal support.
OK. There actually is some of that in the latest version.
But I do see the need for blanket detection being the main focus, if we can easily perform it and it avoids being limited to only what we know.
Yes, but not at the cost of excessive complexity and reduced reliability.
I'm not seeing the reliability being reduced that much. The more universal something is to use (i.e. the less configuration is required) the greater the reach and thus the greater testing and reliability. I could talk about USB/HID vs PS/2 for reliability, for low bandwidth devices (keyboards/mice) but you'll likely dismiss this as a straw man.
I'm also assuming that you anticipate a series of special cases, when talking about "excessive complexity", where, on the other hand, I anticipate factorization, since I have seen a good chunk of it already (unless I misread the datasheet, the intel ICH/SIO init, for all ICHs, factorizes amazingly well).
And while I'm talking about factorization, since I went through most of the early_serial.c sources from coreboot, it looks like much of the code there could be factorized. Or at least some harmonization could benefit some of the SIO inits. I would even venture to say that, from not duplicating/factorizing existing tried and tested code, there likely exists reduced reliability in the coreboot early_serial sources.
Well your plan requires two motherboards plus a development system.
Not at all.
Only one motherboard and a development system, which is what most people would have. I talked earlier about picking one chip from one system to put it onto another, but that was in a different scope.
Use flashrom to flash the BIOS, with only an UBRX bootblock, and you (should) now have access to a panic-room, which you can use to explore the hardware, test a section of your dev BIOS, reflash, etc, provided the relevant panic-room payloads are available, which isn't UBRX's scope...
Total investment: one null-modem cable. Especially, no need for a second motherboard, a second flash ROM or even a flash socket. And with USB 2.0 debug cables being $95 a piece (at least USB 3.0 should be better in that aspect), even if coreboot decides on an EHCI/xHCI USB debug only route for its panic-room, UBRX would still have the economical edge for most boards.
What if it does not work? You have no way forward.
If it does not work, then, and only then, you unsolder the chip, invest in an external programmer (or second mobo), and add a socket... which is what coreboot development, for the boards we are talking about, currently requires.
But at least, you have been given a fair chance to avoid having to do any of that...
Regards,
/Pete
-
Andrew Goodbody -
Patrick Georgi -
Pete Batard -
Peter Stuge -
Scott Duplichan -
Tadas Slotkus