Patchwork use Kconfig for both options on Lippert boards

SMC_CONFIG is needed before the device tree is ready and some people
would rather not have mainboard settings like sio_gp1x_config in the
device tree anyway.  So found a nice united home for both in Kconfig,
where users can change them without having to mess around in the C code.

Signed-off-by: Jens Rottmann <JRottmann@LiPPERTEmbedded.de>
---

Patrick, BTW, what happened to your patch which made the struct
mainboard_config work again? I don't remember it getting committed. I
don't use it mainly because SMC_CONFIG is needed early and I perfer not
scattering 2 options in different places, but I _do_ think the mainboard
logic is a kind of device and might be part (root??) of the tree. So
IMHO your patch which reenables this is a very good thing to have!

Cheers,
Jens

Jens Rottmann wrote:
> +++ src/mainboard/lippert/roadrunner-lx/Kconfig	(working copy)
..
> +config ONBOARD_UARTS_RS485
> +	bool "Switch on-board serial ports to RS485"
> +	default n
> +	help
> +	  If selected, both on-board serial ports will operate in RS485 mode
> +	  instead of RS232.

Maybe make that one option per port instead, with choices "RS232" and
"RS485", since the code allows it very easily. Maybe also make an
(expert?) option to disable the LED?


//Peter

On Tue, Aug 31, 2010 at 6:30 AM, Jens Rottmann
<JRottmann@lippertembedded.de> wrote:
> SMC_CONFIG is needed before the device tree is ready and some people
> would rather not have mainboard settings like sio_gp1x_config in the
> device tree anyway.  So found a nice united home for both in Kconfig,
> where users can change them without having to mess around in the C code.
>
> Signed-off-by: Jens Rottmann <JRottmann@LiPPERTEmbedded.de>
Acked-by: Myles Watson <mylesgw@gmail.com>

Thanks,
Myles

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

On Tue, Aug 31, 2010 at 11:09 AM, Myles Watson <mylesgw@gmail.com> wrote:
> On Tue, Aug 31, 2010 at 6:30 AM, Jens Rottmann
> <JRottmann@lippertembedded.de> wrote:
>> SMC_CONFIG is needed before the device tree is ready and some people
>> would rather not have mainboard settings like sio_gp1x_config in the
>> device tree anyway.  So found a nice united home for both in Kconfig,
>> where users can change them without having to mess around in the C code.
>>
>> Signed-off-by: Jens Rottmann <JRottmann@LiPPERTEmbedded.de>
> Acked-by: Myles Watson <mylesgw@gmail.com>
Rev 5760.

Thanks,
Myles

Jens Rottmann wrote:
> > Maybe make that one option per port instead,
> 
> I had considered this but decided against it.

Oh well.


> It is simply not feasible to make _everything_ configurable,

I'm not sure I agree about feasible. I agree it's not worthwhile
though. You know your customers best, but from my experience with
embedded customers, more configurability is better. :)


> one has to draw a line somewhere.

Yes of course.


> 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.

I guess you already know that PCI interrupts are locked to whatever
the VSA blob configures for the virtualized devices. I do agree about
disabling and I/O and interrupts as far as possible..


> making sure that a certain bit pattern is written as early as
> possible to the LPT data port

This is a good point. It could make sense to have hooks already in
the bootblock.


> you'd have to start with devicetree.cb,

I know. This is one part of coreboot "infrastructure" that I think
needs some improvement. A first step would be interrupt routing.

It might also be nice to make it a little easier to use devicetree.cb
from the coreboot code.


> > Maybe also make an (expert?) option to disable the LED?
> 
> The '1' I write to it makes sure it's initally off.

That makes sense. Thanks for clarifying.


//Peter

Peter Stuge wrote:
> Jens Rottmann wrote:
>>> Maybe make that one option per port instead,
>> I had considered this but decided against it.
> Oh well.
>
>
>> It is simply not feasible to make _everything_ configurable,
> I'm not sure I agree about feasible. I agree it's not worthwhile
> though. You know your customers best, but from my experience with
> embedded customers, more configurability is better. :)
>
It also changes the code from "do the minimal effort for hardware init"
to "parse a lot of different options and make sure all possible
combinations make sense and work".

I'm not saying we shouldn't. I'm just saying it'll be a shift in
principles. (And a lot of effort if done right)

>> you'd have to start with devicetree.cb,
> I know. This is one part of coreboot "infrastructure" that I think
> needs some improvement. A first step would be interrupt routing.
>
> It might also be nice to make it a little easier to use devicetree.cb
> from the coreboot code.

Now that we have a good grip on the device tree and sconfig is
increasingly stable, we should discuss how to get the routing into our
device tree. Suggestions?

Some brainstorming:
- every device that has an APIC needs to have IRQ routing information.
Every bridge, even?
- what about 8259? Virtual Wire?
- We need to represent the IO apics in the device tree so we can walk
the system for dynamic boot time table creation.
- any of the i945 ports would be an easy initial target, as they have
i945_pci_irqs.asl, ich7_pci_irqs.asl, irq_tables.c and mptable.c in
separate files, so they could be replaced easily by something auto
generated. *.asl could (at least for now) be created from the device
tree at compile time.
- A good first start (and relatively easy, since its only refactoring)
would also be to factor out interrupt routing from the K8/Fam10 boards
into separate files, and move their acpi code to the north/southbridge
like it's done on i945/ich7. Any takers?

Stefan