Adding CAR support to v2

[ron minnich]

This is the beginning of CAR support for v2 for qemu. It is done in
such a way that few changes are required and, more the the point,
romcc-based qemu targets keep working and remain the default for now.

It builds on but substantially improves the v3 model, a most important
point being that there are *no* included code files in .c or .S.

The .S code is from v3, however.

This is working and boots to linux in both car and non-car versions.

Note that I use the name 'rom.c' instead of the awkward 'cache_as_ram_auto.c'.

Some work remains. We need to have a standard rom main as we do in v3
(we call it stage0/1 in v3). But this is a good start IMHO.

comments from the patch:
Note that the current non-CAR implementation is the default and
continues to work (tested FILO boot to Linux
on both CAR and non-CAR).

Index: src/mainboard/emulation/qemu-x86/Config.lb
Change this to be sensitive to USE_DCACHE_RAM. All settings etc. that
depend on this variable are grouped
in one if, and the other parts (romcc etc.) are in the else. This
change is a model of how we should be able to do
other motherboards.

Index: src/mainboard/emulation/qemu-x86/Options.lb
add needed options.

Index: src/mainboard/emulation/qemu-x86/failover.c
remove code inclusion from this not-yet-used file.

Index: src/mainboard/emulation/qemu-x86/rom.c
This is the entry point for the rom-based code. Called stage1.c in v3.

Index: src/lib/Config.lb
change initobject to a .o from a .c; this fixed a build problem.

Index: src/pc80/serial.c
make uart_init non-static.

Index: src/pc80/Config.lb
add initobject

Index: src/arch/i386/init/entry.S
Entry point. Unify a bunch of files that were fiddly lttle includes. From v3.

Index: src/arch/i386/init/ldscript.ld
new file. The goal is to hang all init changes for CAR here, to
minimize other changes to any
other ldscript. Besides, putting this in init makes sense; entry and
car are manage init.

Index: src/arch/i386/init/car.S
generic i386 car code from v3.

Index: src/arch/i386/init/ldscript_fallback_cbfs.lb
Fix what looks like a bug: this was not including the init.text section.

Index: targets/emulation/qemu-x86/Config.lb
push up the console loglevel. qemu is for debugging so we might as well
get all the debugging we can.

Index: targets/emulation/qemu-x86/Config-car.lb
For CAR bullds.

Signed-off-by: Ronald G. minnich

ron

[Carl-Daniel Hailfinger]

On 15.06.2009 17:45, ron minnich wrote:
> This is the beginning of CAR support for v2 for qemu. It is done in
> such a way that few changes are required and, more the the point,
> romcc-based qemu targets keep working and remain the default for now.

THIS IS SOOOO AWESOME!
> It builds on but substantially improves the v3 model, a most important
> point being that there are *no* included code files in .c or .S.

I like this change and should forward port it to v3. That would ease
copying of the CAR code for other architectures.
> The .S code is from v3, however.

Excellent.
> This is working and boots to linux in both car and non-car versions.
>
> Note that I use the name 'rom.c' instead of the awkward 'cache_as_ram_auto.c'.
>
> Some work remains. We need to have a standard rom main as we do in v3
> (we call it stage0/1 in v3). But this is a good start IMHO.

Yes. Merge now, rename later.
> comments from the patch:
> Note that the current non-CAR implementation is the default and
> continues to work (tested FILO boot to Linux
> on both CAR and non-CAR).
>
> Index: src/mainboard/emulation/qemu-x86/Config.lb
> Change this to be sensitive to USE_DCACHE_RAM. All settings etc. that
> depend on this variable are grouped
> in one if, and the other parts (romcc etc.) are in the else. This
> change is a model of how we should be able to do
> other motherboards.

I think some include refactoring is due for those files anyway, but I
can handle your changes manually. (My statement about this is to be
considered as "comment", not "review".)
> Index: src/mainboard/emulation/qemu-x86/Options.lb
> add needed options.
>
> Index: src/mainboard/emulation/qemu-x86/failover.c
> remove code inclusion from this not-yet-used file.
>
> Index: src/mainboard/emulation/qemu-x86/rom.c
> This is the entry point for the rom-based code. Called stage1.c in v3.

It would be great if rom.c could eventually become a copy of stage1.c in v3.
> Index: src/lib/Config.lb
> change initobject to a .o from a .c; this fixed a build problem.
>
> Index: src/pc80/serial.c
> make uart_init non-static.
>
> Index: src/pc80/Config.lb
> add initobject
>
> Index: src/arch/i386/init/entry.S
> Entry point. Unify a bunch of files that were fiddly lttle includes. From v3.
>
> Index: src/arch/i386/init/ldscript.ld
> new file. The goal is to hang all init changes for CAR here, to
> minimize other changes to any
> other ldscript. Besides, putting this in init makes sense; entry and
> car are manage init.
>
> Index: src/arch/i386/init/car.S
> generic i386 car code from v3.
>
> Index: src/arch/i386/init/ldscript_fallback_cbfs.lb
> Fix what looks like a bug: this was not including the init.text section.
>
> Index: targets/emulation/qemu-x86/Config.lb
> push up the console loglevel. qemu is for debugging so we might as well
> get all the debugging we can.
>
> Index: targets/emulation/qemu-x86/Config-car.lb
> For CAR bullds.
>
> Signed-off-by: Ronald G. minnich

Unless I misread something, you could kill everything except an empty
main() {} in src/mainboard/emulation/qemu-x86/failover.c. Feel free to
postpone that, though.
> --- src/mainboard/emulation/qemu-x86/rom.c	(revision 0)
> +++ src/mainboard/emulation/qemu-x86/rom.c	(revision 0)
> @@ -0,0 +1,30 @@
> +void main(void)
> +{
> int i;
> void uart_init(void);
> void (*v)();

What is v()? Please use a name which has a chance to be understood.
> outb(5, 0x80);
> uart_init();
> v = cbfs_load_stage("fallback/coreboot_ram");
> v();

Same here. Searching for one-byte identifiers is hard.
> +}

All of the issues I brought up can be fixed in a followup patch. I want
this in ASAP.

Acked-by: Carl-Daniel Hailfinger

Regards,
Carl-Daniel

[ron minnich]

Committed revision 4357.

I changed the name v to start_address.

OK, next steps. We need what we have in v3 stage1 code, which is a
call to the CAR code, then a jmp to the CAR disable code, then a jmp
to the code that loads the RAM stages. I'll work on that. It will be
in arch/i386/init, guess I'll call it rombootstrap.c.

The hope here is that we end up with a general pattern and process for
cleaning up and moving to a more comprehensible CAR setup with the v3
improvements part of the picture.

Fixing up includes is a good idea.

I think we ought to not bring over the v3 stage numbering. I've gotten
very mixed reactions to the stage1 etc. naming. It seemed like a good
idea but in the end it did not seem that essential.

thanks

ron

[Myles Watson]

> The hope here is that we end up with a general pattern and process for
> cleaning up and moving to a more comprehensible CAR setup with the v3
> improvements part of the picture.

Since this is the way we'd like all boards to go, I suggest making it the
default.  It's nice that the romcc path still works, but it shouldn't be the
default if we're moving away from it.

Thanks,
Myles

[ron minnich]

On Tue, Jun 16, 2009 at 8:33 AM, Myles Watson wrote:
> > The hope here is that we end up with a general pattern and process for
> > cleaning up and moving to a more comprehensible CAR setup with the v3
> > improvements part of the picture.
>
> Since this is the way we'd like all boards to go, I suggest making it the
> default.  It's nice that the romcc path still works, but it shouldn't be the
> default if we're moving away from it.

That's the next step, don't worry. I want to make sure to keep people happy :-)

ron

[Joseph Smith]

On Tue, 16 Jun 2009 08:35:10 -0700, ron minnich  wrote:
> On Tue, Jun 16, 2009 at 8:33 AM, Myles Watson wrote:
> > > The hope here is that we end up with a general pattern and process for
> > > cleaning up and moving to a more comprehensible CAR setup with the v3
> > > improvements part of the picture.
> >
> > Since this is the way we'd like all boards to go, I suggest making it
>
> the
> > default.  It's nice that the romcc path still works, but it shouldn't
>
> be the
> > default if we're moving away from it.
>
> That's the next step, don't worry. I want to make sure to keep people
> happy :-)

I would be very very happy to see CAR on my boards so if you need a real
hardware target to do some lab rat testing, let me know :-)

[ron minnich]

what's your board again?

we can work together on this. It would be the same procedure I
followed for qemu so we always have a working romcc version as we make
the
conversion.

ron

[Joseph Smith]

On Tue, 16 Jun 2009 10:44:41 -0700, ron minnich  wrote:
> what's your board again?
>
> we can work together on this. It would be the same procedure I
> followed for qemu so we always have a working romcc version as we make
> the
> conversion.

OK, It is the Thomson IP1000 and/or RCA RM4100. What's the first step?

[ron minnich]

take a look at how I changed src/mainboard/blah blah/qemu/Config.lb

See the if USE_DCACHE_RAM.

basically you want to bundle up any romcc/auto.c etc. settings under
the else in that conditional.

ron

[Carl-Daniel Hailfinger]

On 16.06.2009 17:24, ron minnich wrote:
> Committed revision 4357.
>
> I changed the name v to start_address.

Thanks!
> OK, next steps. We need what we have in v3 stage1 code, which is a
> call to the CAR code, then a jmp to the CAR disable code, then a jmp
> to the code that loads the RAM stages. I'll work on that. It will be
> in arch/i386/init, guess I'll call it rombootstrap.c.

Can't we just reuse the v3 code here with slight adaptations from LAR to
CBFS?
> The hope here is that we end up with a general pattern and process for
> cleaning up and moving to a more comprehensible CAR setup with the v3
> improvements part of the picture.
>
> Fixing up includes is a good idea.

Indeed.
> I think we ought to not bring over the v3 stage numbering. I've gotten
> very mixed reactions to the stage1 etc. naming. It seemed like a good
> idea but in the end it did not seem that essential.

I'd really like to bring over stage naming from v3 to v2 (but I
personally don't care that much about phase numbering, although numbers
make it easy to find out execution order). Please let me explain why.
I consider myself to be a coreboot developer with some knowledge of the
codebase. However, although I have been looking at v2 code for over 2
years, I still have not figured out the code flow in v2 whereas v3 has
really easy to follow code flow for stage1, initram and initial stage2.
Granted, #include in stage0 was not really such a good idea in v3, but
you fixed that part when porting to v2.

Sure, there are a lot of people who understand the v2 code easily, but
for me the numbering in v3 was a lifesaver.

Just my two cents.

Regards,
Carl-Daniel

[Peter Stuge]

ron minnich wrote:
> I think we ought to not bring over the v3 stage numbering.
> I've gotten very mixed reactions to the stage1 etc. naming.
> It seemed like a good idea but in the end it did not seem that
> essential.

It really helps me too in understanding the code. And it helps
explaining the code flow to new people.

Numbers are not critical, but I liked them as a way to not have to
deal with finding perfect names for every single function.

I'd like to have either great names for all functions and good
consistent structure, or some kind of numbering scheme.

I was never crazy about the phases, one dimension seems like it could
be enough, but I think this is less important.

//Peter

[Myles Watson]

On Thu, Jun 18, 2009 at 2:06 PM, Peter Stuge  wrote:
> ron minnich wrote:
> > I think we ought to not bring over the v3 stage numbering.
> > I've gotten very mixed reactions to the stage1 etc. naming.
> > It seemed like a good idea but in the end it did not seem that
> > essential.
>
> It really helps me too in understanding the code. And it helps
> explaining the code flow to new people.
>
> Numbers are not critical, but I liked them as a way to not have to
> deal with finding perfect names for every single function.
>
> I'd like to have either great names for all functions and good
> consistent structure, or some kind of numbering scheme.

I'd be happy with having the functions ordered correctly in the structures
as a first step.

In other words, if .init always came last, that would help.

// from src/include/device/device.h:

struct device_operations {
    void (*read_resources)(device_t dev);
    void (*set_resources)(device_t dev);
    void (*enable_resources)(device_t dev);
    void (*init)(device_t dev);
    unsigned int (*scan_bus)(device_t bus, unsigned int max);
    void (*enable)(device_t dev);
    void (*set_link)(device_t dev, unsigned int link);
    void (*reset_bus)(struct bus *bus);
    const struct pci_operations *ops_pci;
    const struct smbus_bus_operations *ops_smbus_bus;
    const struct pci_bus_operations *ops_pci_bus;
};

It's hard to tell from there that the order is:
1. Enable
2. Scan bus
3. Read resources
4. Set resources
5. Enable resources
6. Init

( I could have gotten something wrong there.)

I admit I don't know what
1. set_link
2. reset_bus

are good for or when they're called.  This seems like the place to document
it, though.

Thanks,
Myles