coreboot October 2003

coreboot@coreboot.org

52 participants
115 discussions

Patch for V2 new config
by Mark Wilkinson 02 Oct '03

02 Oct '03

Hi Ron, I started looking at building the Via/Epia with the v2, and noticed that your last snapshot said that the mainboard Config.lb should set the ROM_SIZE to 265K. Here's a little patch that lets the config python use 'default OPTION value' tag in the Mainboard Config.lb overriding the value set in config/Optins.lb (which has ROM_SIZE set to NONE) or should the command be 'default OPTION=<value>' in which case, alter the line for 'rule default<<C>>: ...' to read rule default<<C>>: DEFAULT ID EQ value {{ if(C): mbdefault(ID,value) }} Regards Mark Wilkinson. PS. Hope to burn a V2 epia bios tomorrow morning and test !!

5 16

ep405pc
by Greg Watson 02 Oct '03

02 Oct '03

I've started a port to the EmbeddedPlanet ep405pc board. This uses a PPC405GPr processor, which is sufficiently different to the Sandpoint 74xx to make it interesting. First step was to set up the source tree and sort out some of the PPC processor differences. First problem: I/O is memory mapped on the PPC, and I'd hardwired the PCI address range for the Sandpoint. This is now fixed, and I'm getting serial output. Second problem: PCI: Sanity check failed More later... Greg

1 0

v2 epia
by ron minnich 02 Oct '03

02 Oct '03

i can't set 0x4d0 and 0x4d1. these are the old interrupt router addresses. I'm looking but have not found the bits in the south/north that enable these functions -- anybody know? ron

1 0

V2 config tool
by ron minnich 02 Oct '03

02 Oct '03

Here's what I want for options. I want all options defined (that means the name of the option) in src/config/Options.lb For those options that can have reasonable project-wide defaults, i.e defaults that make sense across all mainboards and architectures, I want those defined options to have a reasonable default value set in Options.lb. Note that there are very few options that can have a default value set project-wide. CONFIG_COMPRESS is an option that can have a default project-wide value. ROM_SIZE is not an option that can have a default project-wide value. Let's call these global values. For those options that make sense for a single motherboard, and are required to have a fixed value for that motherboard, I want that option set in mainboard/<vendor>/<part>/Config.lb. CONFIG_SMBASE is such an option: it's a fixed attribute of the motherboard, and you don't want to let people set it to some bogus value. ROM_SIZE may or may not be such an option; on motherboards with pluggable ROMs different people use different size ROMs; on motherboards with soldered-on ROMs, the size is fixed. Therefore, some motherboard Config.lb files will set ROM_SIZE as a default, and others will set it as a fixed value via the option command. For those options that make sense for a single motherboard, and have a reasonable default value for that motherboard, I want that option set to a default value in mainboard/<vendor>/<part>/Config.lb. This default value can be over-ridden in the target mainboard file. ROM_SIZE is an example of such an option: there are usually reasonable default values but many motherboards allow this to be set as users change rom parts. The current tool supports this hierarchy. First, global (to the project) option definitions and default values are read in. Then, in the file targets/<vendor>/<part>/Config.lb, user settings are parsed. Finally, mainboard settings are read in. Conflicts in option settings will result in a fatal error. If the motherboard has set a default, but the user has already over-ridden that default value (as in ROM_SIZE), then the default is ignored. As explained earlier, however, the order of default and option is not that important; what's important is that variables can not be set-after-use. Comments? ron

1 0

V2 VIA EPIA
by ron minnich 02 Oct '03

02 Oct '03

OK, I've committed code that turns on shadow dram in F segment, so PIRQ will work; also committed what should be working SMBUS code in vt8231_early_smbus.c; now the fun begins. I could use advice on: - what SMBUS bytes we need to care about - what we should program the north with using those bytes. - how to do it. Which is to say, I think I know, but let's get this done in a speedy fashion. Momentum is on our side here. The EPIA will be a good demo platform. Why this sudden burst of EPIA work from me? Two reasons: - I want to encourage people to look at V2, so we need a demo system less complex than the K8 systems. - We are teaching a tutorial on linuxbios, bproc, etc. and will be doing it hands-on with a roomful of EPIAs, 2 or 3 per tutorial attendee. See: http://lacsi.lanl.gov/symposium/agenda.shtml Come if you want. You can see how we build clusters that boot in seconds. The software we're showing is the same stuff that is running on our 1024-node Pink cluster, and will run on our 1408-node K8 cluster. ron

6 17

read the source ron!
by ron minnich 02 Oct '03

02 Oct '03

in V1: void pci_assign_irqs(unsigned bus, unsigned slot, const unsigned char pIntAtoD[4]); static const unsigned char southbridgeIrqs[4] = { 11, 5, 10, 12 }; static const unsigned char enetIrqs[4] = { 11, 5, 10, 12 }; static const unsigned char slotIrqs[4] = { 5, 10, 12, 11 }; /* Our IDSEL mappings are as follows PCI slot is AD31 (device 15) (00:14.0) Southbridge is AD28 (device 12) (00:11.0) */ static void pci_routing_fixup(void) { struct pci_dev *dev; dev = pci_find_device(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_8231, 0); if (dev != NULL) { /* initialize PCI interupts - these assignments depend on the PCB routing of PINTA-D PINTA = IRQ11 PINTB = IRQ5 PINTC = IRQ10 PINTD = IRQ12 */ pci_write_config_byte(dev, 0x55, 0xb0); pci_write_config_byte(dev, 0x56, 0xa5); pci_write_config_byte(dev, 0x57, 0xc0); } // Standard southbridge components printk_info("setting southbridge\n"); pci_assign_irqs(0, 0x11, southbridgeIrqs); // Ethernet built into southbridge printk_info("setting ethernet\n"); pci_assign_irqs(0, 0x12, enetIrqs); // PCI slot printk_info("setting pci slot\n"); pci_assign_irqs(0, 0x14, slotIrqs); } ok, that explains it! ron

2 4

serial.{c,inc}
by Greg Watson 02 Oct '03

02 Oct '03

Does anyone know why we have serial.c and serial.inc files in the V2 pc80 directory, in addition to the console/uart8250_console.c and lib/uart8250.c files? Are they needed? Greg

2 1

messages on list out of order
by ron minnich 02 Oct '03

02 Oct '03

the machine doing the mail list went away last night, so there are some hiccups in the mail. Ignore them. ron

1 0

V2 EPIA PIRQ problem.
by ron minnich 02 Oct '03

02 Oct '03

HMM. We're running 2.4.22. pci-irq.c has this: { "VIA", PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C586_0, pirq_via_get, pirq_via_set }, { "VIA", PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C596, pirq_via_get, pirq_via_set }, { "VIA", PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C686, pirq_via_get, pirq_via_set }, no 8231 to be seen. So, what's up? did some clever committer just set the right IRQ in 0:12.0 and linux is not even setting IRQs? Inquiring minds want to know! How are EPIA interrupts getting set? Another example of why, I guess, we need to set interrupts in linuxbios, not in the kernel. The kernel is not always up to date. ron

1 0

V2 EPIA update
by ron minnich 02 Oct '03

02 Oct '03

The IRQ table is the same as in V1. LinuxBIOS claims it gets copied to the 0xf0000 address and that it is good. But ... linux still claims the no known irq for ... problem. ron

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot October 2003