Hi, I work on adding information about the console to the lbtable, so that the payload can parse it to figure out where it might find a user.
Right now, I only store TTYS0_BASE (that config variable) in a special lbtable record (LB_TAG_SERIAL) and let the payload assume it should use the serial port. Before I go on, I have a couple of questions: - Do we want to store more information than coreboot itself uses? (eg. serial ports that aren't used, but known to exist) - if so, what kind of information: io ports, irqs, memory areas, ... - how should this information be mapped to devices? - our own naming scheme (serial0, ...) - adopting an existing one (com1, ttyS0, cua0, ..) - How flexible should the console routing be? - multiple target consoles - multiple targets of the same type (eg. both COM1 and COM2) I don't want to design a too flexible system (that no-one uses and is only partially implemented by payloads), but I don't want to force payloads to adapt to an ever-changing interface either. I also don't want to work on this and scrap everything on pre-commit time, because the consensus is that the design sucks, which is why I ask for opinions. :-) Once this is settled, I'll implement it for lbv2 and lbv3 and add support to the various utilities (lxbios and whoever else dumps the table). Regards, Patrick -- coreboot mailing list [email protected] http://www.coreboot.org/mailman/listinfo/coreboot
