Peter wrote:
Maybe make that one option per port instead, with choices "RS232" and "RS485", since the code allows it very easily.
I had considered this but decided against it. I'd guess that, like, 96.3% of all users will want both ports speak the same protocol. In fact most will want RS232, RS485 is already very rare, but mixed operation must be really, really exotic.
It is simply not feasible to make _everything_ configurable, one has to draw a line somewhere. That's why I didn't add an option to turn off the Spread Spectrum in SMC_CONFIG, either. Before I would consider this, there are lots of settings which are _much_ more likely to get changed first.
Like disabling devices completely to save power, I/O resources and IRQs. Or moving PCI INT A-D or legacy devices to a different IRQ line. (Our boards still feature ISA, provided by an IT8888 PCI-to-ISA bridge.) These are the things our customers request all the time. And even though our standard BIOSes (Insyde and Phoenix) have all this in the normal BIOS Setup, we _still_ keep providing many customers with variants of our standard BIOSes - like one making sure that a certain bit pattern is written as early as possible to the LPT data port (3rd assembler instruction actually) and is kept until OS has finished booting. (The customer in question is (ab)using the LPT data pins as GPIOs to control pieces of hardware in a satellite - embedded customers are ... umm ... different.) There is no way you can make _everything_ user-configurable.
I agree that easy access to all knobs would be great, but for that you'd have to start with devicetree.cb, and allow a flag added to each setting saying "do autogenerate Kconfig entry for this option".
Maybe also make an (expert?) option to disable the LED?
It's a red LED for free use of the customer's application - like "new mail has arrived" or "satellite ran out of fuel". ;-) I think most customers rather change the LED at runtime than by reconfiguring coreboot. The '1' I write to it makes sure it's initally off.
Cheers, Jens