Re: FYI: Merge in progress...

YhLu  writes:
> Config.g still miss to add
>
> crt0.S: $(CRT0)
>         cp $< $@
> linuxbios.rom: linuxbios.strip buildrom
>         ./buildrom $< $@ $(PAYLOAD) $(ROM_IMAGE_SIZE) $(ROM_SECTION_SIZE)
>
> to the fallback/Makfile

Yep.  That is now fixed.

I am working through the changes necessary changes to the static device tree
now.

We are getting there.

Eric

FYI: Merge in progress...

The ARIMA HDAMA now boots, and everything looks like it is working properly.

Converting everything else still remains but we now have a working example
to look at.

We are down to one device tree instead of two.
And hardwaremain has been reduced to:

void hardwaremain(int boot_complete)
{
    /* the order here is a bit tricky. We don't want to do much of 
     * anything that uses config registers until after PciAllocateResources
     * since that function also figures out what kind of config strategy
     * to use (type 1 or type 2). 
     * so we turn on cache, then worry about PCI setup, then do other 
     * things, so that the other work can use the PciRead* and PciWrite*
     * functions. 
     */
    struct lb_memory *lb_mem;

post_code(0x80);

/* displayinit MUST PRECEDE ALL PRINTK! */
    console_init();
    
    post_code(0x39);
    printk_notice("LinuxBIOS-%s%s %s %s...\n", 
    	linuxbios_version, linuxbios_extra_version, linuxbios_build,
    	(boot_complete)?"rebooting":"booting");

post_code(0x40);

/* If we have already booted attempt a hard reboot */
    if (boot_complete) {
    	hard_reset();
    }

/* FIXME: Is there a better way to handle this? */
    init_timer();

/* pick how to scan the bus. This is first so we can get at memory size. */
    printk_info("Finding PCI configuration type.\n");
    pci_set_method();
    post_code(0x5f);
    dev_enumerate();
    post_code(0x66);
    /* Now do the real bus.
     * We round the total ram up a lot for thing like the SISFB, which 
     * shares high memory with the CPU. 
     */
    dev_configure();
    post_code(0x88);

dev_enable();

dev_initialize();
    post_code(0x89);

/* Now that we have collected all of our information
     * write our configuration tables.
     */
    lb_mem = write_tables();

#if CONFIG_FS_STREAM == 1
    filo(lb_mem);
#else
    elfboot(lb_mem);
#endif
}

There is more scrubbing on the horizon but so for things look good.

Eric

FYI: Merge in progress...

[Yinghai Lu]

So chip tree is merged into device tree.

I'm eager to convert my MB to use that.

Is there any problem for different inherent links in second K8?

Regards

YH

-----Original Message-----
From: Eric W. Biederman [mailto:[e-mail]] On Behalf Of Eric W.
Biederman
Sent: Saturday, October 16, 2004 2:20 AM
To: Ronald G. Minnich
Cc: YhLu; LinuxBIOS
Subject: Re: FYI: Merge in progress...

The ARIMA HDAMA now boots, and everything looks like it is working properly.

Converting everything else still remains but we now have a working example
to look at.

We are down to one device tree instead of two.
And hardwaremain has been reduced to:

void hardwaremain(int boot_complete)
{
    /* the order here is a bit tricky. We don't want to do much of 
     * anything that uses config registers until after
PciAllocateResources
     * since that function also figures out what kind of config strategy
     * to use (type 1 or type 2). 
     * so we turn on cache, then worry about PCI setup, then do other 
     * things, so that the other work can use the PciRead* and PciWrite*
     * functions. 
     */
    struct lb_memory *lb_mem;

post_code(0x80);

/* displayinit MUST PRECEDE ALL PRINTK! */
    console_init();
    
    post_code(0x39);
    printk_notice("LinuxBIOS-%s%s %s %s...\n", 
    	linuxbios_version, linuxbios_extra_version, linuxbios_build,
    	(boot_complete)?"rebooting":"booting");

post_code(0x40);

/* If we have already booted attempt a hard reboot */
    if (boot_complete) {
    	hard_reset();
    }

/* FIXME: Is there a better way to handle this? */
    init_timer();

/* pick how to scan the bus. This is first so we can get at memory
size. */
    printk_info("Finding PCI configuration type.\n");
    pci_set_method();
    post_code(0x5f);
    dev_enumerate();
    post_code(0x66);
    /* Now do the real bus.
     * We round the total ram up a lot for thing like the SISFB, which 
     * shares high memory with the CPU. 
     */
    dev_configure();
    post_code(0x88);

dev_enable();

dev_initialize();
    post_code(0x89);

/* Now that we have collected all of our information
     * write our configuration tables.
     */
    lb_mem = write_tables();

#if CONFIG_FS_STREAM == 1
    filo(lb_mem);
#else
    elfboot(lb_mem);
#endif
}

There is more scrubbing on the horizon but so for things look good.

Eric

FYI: Merge in progress...

[Ronald G. Minnich]

Yeah, well, how about this: here's how target config files look now:

# Sample config file for Motorola Sandpoint X3 Demo Board with
# the Arima HDAMA
# This will make a target directory of ./hdama

target hdama
mainboard arima/hdama

# Arima hdama
romimage "normal"
    option USE_FALLBACK_IMAGE=0
    option ROM_IMAGE_SIZE=0x10000
    option LINUXBIOS_EXTRA_VERSION=".0Normal"
    payload /usr/share/etherboot/5.2.1eb1-lnxi-lb/tg3--ide_disk.zelf
end

romimage "fallback" 
    option USE_FALLBACK_IMAGE=1
    option ROM_IMAGE_SIZE=0x10000
    option LINUXBIOS_EXTRA_VERSION=".0Fallback"
    payload /usr/share/etherboot/5.2.1eb1-lnxi-lb/tg3--ide_disk.zelf
end

buildrom ./linuxbios.rom ROM_SIZE "normal" "fallback"

A bit simpler eh?

ron

FYI: Merge in progress...

[Stefan Reinauer]

* Ronald G. Minnich  [041018 18:19]:
> Yeah, well, how about this: here's how target config files look now:

Really awesome! Now LinuxBIOS is not a step further, but a couple of
big jumps.
> target hdama
> mainboard arima/hdama
> romimage "normal"
>    option USE_FALLBACK_IMAGE=0
>    option ROM_IMAGE_SIZE=0x10000
>    option LINUXBIOS_EXTRA_VERSION=".0Normal"
>    payload /usr/share/etherboot/5.2.1eb1-lnxi-lb/tg3--ide_disk.zelf
> end
> romimage "fallback" 
>    option USE_FALLBACK_IMAGE=1
>    option ROM_IMAGE_SIZE=0x10000
>    option LINUXBIOS_EXTRA_VERSION=".0Fallback"
>    payload /usr/share/etherboot/5.2.1eb1-lnxi-lb/tg3--ide_disk.zelf
> end
> buildrom ./linuxbios.rom ROM_SIZE "normal" "fallback"

With such simple target config files, one could think about an autobuild
kind of thing, checking the status of all LinuxBIOS target builds
nightly. This would put immediate attention on changes that break
something. I hacked down attached little script, which creates output
similar to the following, leaving flashable images for each platform.

[..]
Processing mainboard amd solo (i386: ok)
  Creating config file... ok
  Creating builddir...FAILED!

Processing mainboard arima hdama (i386: ok)
  Creating config file... ok
  Creating builddir...ok
  Compiling image ..FAILED!
[..]
Processing mainboard embeddedplanet ep405pc (ppc: skipped, we're i386)
[..]

I attached a little script to do this. If someone likes it, I would
check it into freebios2/util/abuild and give it a try on base of the
linuxbios snapshots (http://www.linuxbios.org/snapshots/)

Ideas, hints, patches, flames welcome...

Stefan

FYI: Merge in progress...

[Ronald G. Minnich]

Please check that in Stefan, we have needed something like that for a long 
time. We need to finish up Greg Watson's work on cross compile flags etc. 
so we can do all builds in one place.

ron

FYI: Merge in progress...

[Ronald G. Minnich]

I ought to mention:

last week's efforts which result in this week's improvements were a joint 
project of Eric, Tom, and Jason (LNXI) and Ollie and me (LANL).

So thanks to them if you like what happened :-)

ron

FYI: Merge in progress...

[Li-Ta Lo]

On Sat, 2004-10-16 at 11:03, Yinghai Lu wrote:
> So chip tree is merged into device tree.
>
> I'm eager to convert my MB to use that.
>
> Is there any problem for different inherent links in second K8?

I am a little bit confused with that too. I think now the 'link' keyword
is not used anymore, the device enumeration code will put the 2nd 
northbridge on the right LDT accroding to the early HT enumertion.

Ollie

FYI: Merge in progress...

Li-Ta Lo  writes:
> On Sat, 2004-10-16 at 11:03, Yinghai Lu wrote:
> > So chip tree is merged into device tree.
> >
> > I'm eager to convert my MB to use that.
> >
> > Is there any problem for different inherent links in second K8?
>
> I am a little bit confused with that too. I think now the 'link' keyword
> is not used anymore, the device enumeration code will put the 2nd 
> northbridge on the right LDT accroding to the early HT enumertion.

Sorry, for not making this clearer.  Look at the generated static.c
if my following explanation does not clear things up.

The device tree from the HDAMA mainboard Config.lb is below:
The first time device pci 18.0 is mentioned that is link[0] in for the device.
The second time is link[1] the third time is link[2]...

And then the amdk8 code maps link[0] to LDT0 link[1] to LD[1 and link[2] to LDT2.

A similar condition exists for the phillips pca9545 i2c switch.
It only has one register but it has 4 downstream ports.

We may want to do something cleaner than just repeating the device once for
each ``link/bus'' but for now that works.

Eric

chip northbridge/amd/amdk8
    device pci_domain 0 on
    	device pci 18.0 on #  northbridge 
    		#  devices on link 0, link 0 == LDT 0 
    		chip southbridge/amd/amd8131
    			# the on/off keyword is mandatory
    			device pci 0.0 on end
    			device pci 0.1 on end
    			device pci 1.0 on end
    			device pci 1.1 on end
    		end
    		chip southbridge/amd/amd8111
    			# this "device pci 0.0" is the parent the next one
    			# PCI bridge
    			device pci 0.0 on
    				device pci 0.0 on end
    				device pci 0.1 on end
    				device pci 0.2 on end
    				device pci 1.0 off end
    			end
    			device pci 1.0 on
    				chip superio/NSC/pc87360
    					device	pnp 2e.0 off  # Floppy 
    						 io 0x60 = 0x3f0
    						irq 0x70 = 6
    						drq 0x74 = 2
    					end
    					device pnp 2e.1 off  # Parallel Port
    						 io 0x60 = 0x378
    						irq 0x70 = 7
    					end
    					device pnp 2e.2 off # Com 2
    						 io 0x60 = 0x2f8
    						irq 0x70 = 3
    					end
    					device pnp 2e.3 on  # Com 1
    						 io 0x60 = 0x3f8
    						irq 0x70 = 4
    					end
    					device pnp 2e.4 off end # SWC
    					device pnp 2e.5 off end # Mouse
    					device pnp 2e.6 on  # Keyboard
    						 io 0x60 = 0x60
    						 io 0x62 = 0x64
    						irq 0x70 = 1
    					end
    					device pnp 2e.7 off end # GPIO
    					device pnp 2e.8 off end # ACB
    					device pnp 2e.9 off end # FSCM
    					device pnp 2e.a off end # WDT  
    				end
    			end
    			device pci 1.1 on end
    			device pci 1.2 on end
    			device pci 1.3 on 
    				chip drivers/generic/generic
    					#phillips pca9545 smbus mux
    					device i2c 70 on 
    						# analog_devices adm1026	
    						chip drivers/generic/generic
    							device i2c 2c on end
    						end
    					end
    					device i2c 70 on end
    					device i2c 70 on end
    					device i2c 70 on end
    				end
    				chip drivers/generic/generic #dimm 0-0-0
    					device i2c 50 on end
    				end
    				chip drivers/generic/generic #dimm 0-0-1
    					device i2c 51 on end
    				end 
    				chip drivers/generic/generic #dimm 0-1-0
    					device i2c 52 on end
    				end 
    				chip drivers/generic/generic #dimm 0-1-1
    					device i2c 53 on end
    				end 
    				chip drivers/generic/generic #dimm 1-0-0
    					device i2c 54 on end 
    				end
    				chip drivers/generic/generic #dimm 1-0-1
    					device i2c 55 on end
    				end 
    				chip drivers/generic/generic #dimm 1-1-0
    					device i2c 56 on end
    				end 
    				chip drivers/generic/generic #dimm 1-1-1
    					device i2c 57 on end
    				end 
    			end
    			device pci 1.5 off end
    			device pci 1.6 on end
    		end
    	end #  device pci 18.0 
    	
    	device pci 18.0 on end # LDT1
    	device pci 18.0 on end # LDT2
    	device pci 18.1 on end
    	device pci 18.2 on end
    	device pci 18.3 on end

chip northbridge/amd/amdk8
    		device pci 19.0 on end
    		device pci 19.0 on end
    		device pci 19.0 on end
    		device pci 19.1 on end
    		device pci 19.2 on end
    		device pci 19.3 on end
    	end
    end 
    device apic_cluster 0 on
    	chip cpu/amd/socket_940
    		device apic 0 on end
    	end
    	chip cpu/amd/socket_940
    		device apic 1 on end
    	end
    end
end

FYI: Merge in progress...

[Li-Ta Lo]

On Mon, 2004-10-18 at 11:04, Eric W. Biederman wrote:
> Li-Ta Lo  writes:
> > On Sat, 2004-10-16 at 11:03, Yinghai Lu wrote:
> > > So chip tree is merged into device tree.
> > >
> > > I'm eager to convert my MB to use that.
> > >
> > > Is there any problem for different inherent links in second K8?
> >
> > I am a little bit confused with that too. I think now the 'link' keyword
> > is not used anymore, the device enumeration code will put the 2nd 
> > northbridge on the right LDT accroding to the early HT enumertion.
>
> Sorry, for not making this clearer.  Look at the generated static.c
> if my following explanation does not clear things up.
>
> The device tree from the HDAMA mainboard Config.lb is below:
> The first time device pci 18.0 is mentioned that is link[0] in for the device.
> The second time is link[1] the third time is link[2]...
>
> And then the amdk8 code maps link[0] to LDT0 link[1] to LD[1 and link[2] to LDT2.
>
> A similar condition exists for the phillips pca9545 i2c switch.
> It only has one register but it has 4 downstream ports.
>
> We may want to do something cleaner than just repeating the device once for
> each ``link/bus'' but for now that works.

I think YHLu's question is that the CPU0 and CPU1 are connected by LDT1 
one each side. So how do we say
    northbridge_18_0.link[0].something = northbridge_19_0
and
    northbridge_19_0.link[0].something = northbridge_18_0
in the config file ?

Or it will be set dynamically at run time ?

Ollie

FYI: Merge in progress...

Li-Ta Lo  writes:
> I think YHLu's question is that the CPU0 and CPU1 are connected by LDT1 
> one each side. So how do we say
>    northbridge_18_0.link[0].something = northbridge_19_0
> and
>    northbridge_19_0.link[0].something = northbridge_18_0
> in the config file ?
>
> Or it will be set dynamically at run time ?

So far the is still handled in auto.c like it always has been.
The dynamic code ignores coherent links.

While we have moved things around.  The functional part of the code
really has not changed.  We just skip the step of the old static
tree.

An interesting static is that static.c compiles to 35K but compresses
to about 500 bytes. :)

Eric

FYI: Merge in progress...

[Li-Ta Lo]

On Mon, 2004-10-18 at 13:08, Eric W. Biederman wrote:
> An interesting static is that static.c compiles to 35K but compresses
> to about 500 bytes. :)

This is exactly why I was proposing this change. We also got rid of
a lot of static -> dynamice code.

Ollie

FYI: Merge in progress...

[Ronald G. Minnich]

On Mon, 18 Oct 2004, Li-Ta Lo wrote:
> This is exactly why I was proposing this change. We also got rid of
> a lot of static -> dynamice code.

even cooler: there is no static code structure any more. What the config 
tool creates is a statically allocated set of device structs. The 
enumeration of static to dynamic is gone.

And so on, and so on, it's a huge improvement.

ron