coreboot July 2008

coreboot@coreboot.org

58 participants
214 discussions

r696 - coreboot-v3/southbridge/amd/cs5536
by svn＠coreboot.org 15 Jul '08

15 Jul '08

Author: mjones Date: 2008-07-15 01:04:48 +0200 (Tue, 15 Jul 2008) New Revision: 696 Modified: coreboot-v3/southbridge/amd/cs5536/cs5536.c Log: There was a programming error which made most USB port4 setup wrong. This patch uses byte pointer and the MMIO read and write functions. Signed-off-by: Marc Jones <marc.jones(a)amd.com> Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006(a)gmx.net> Acked-by: Stefan Reinauer <stepan(a)coresystems.de> Modified: coreboot-v3/southbridge/amd/cs5536/cs5536.c =================================================================== --- coreboot-v3/southbridge/amd/cs5536/cs5536.c 2008-07-12 12:03:55 UTC (rev 695) +++ coreboot-v3/southbridge/amd/cs5536/cs5536.c 2008-07-14 23:04:48 UTC (rev 696) @@ -393,18 +393,18 @@ } /* the /sizeof(u32) is to convert byte offsets into u32 offsets */ -#define HCCPARAMS (0x08/sizeof(u32)) -#define IPREG04 (0xA0/sizeof(u32)) +#define HCCPARAMS 0x08 +#define IPREG04 0xA0 #define USB_HCCPW_SET (1 << 1) #define UOCCAP 0x00 -#define APU_SET (1 << 15) -#define UOCMUX (0x04/sizeof(u32)) +#define APU_SET (1 << 15) +#define UOCMUX 0x04 #define PMUX_HOST 0x02 #define PMUX_DEVICE 0x03 #define PUEN_SET (1 << 2) -#define UDCDEVCTL (0x404/sizeof(u32)) +#define UDCDEVCTL 0x404 #define UDC_SD_SET (1 << 10) -#define UOCCTL (0x0C/sizeof(u32)) +#define UOCCTL 0x0C #define PADEN_SET (1 << 7) /** @@ -414,7 +414,7 @@ */ static void enable_USB_port4(struct southbridge_amd_cs5536_dts_config *sb) { - u32 *bar; + u8 *bar; struct msr msr; struct device *ehci_dev, *otg_dev, *udc_dev; @@ -429,41 +429,42 @@ /* Write to clear diag register. */ wrmsr(USB2_SB_GLD_MSR_DIAG, rdmsr(USB2_SB_GLD_MSR_DIAG)); - bar = (u32 *) pci_read_config32(ehci_dev, PCI_BASE_ADDRESS_0); + bar = (u8 *) pci_read_config32(ehci_dev, PCI_BASE_ADDRESS_0); /* Make HCCPARAMS writable. */ - *(bar + IPREG04) |= USB_HCCPW_SET; + writel(readl(bar + IPREG04) | USB_HCCPW_SET, bar + IPREG04); /* EECP=50h, IST=01h, ASPC=1 */ - *(bar + HCCPARAMS) = 0x00005012; + writel(0x00005012, bar + HCCPARAMS); } otg_dev = dev_find_pci_device(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_CS5536_OTG, 0); if (otg_dev) { - bar = (u32 *) pci_read_config32(otg_dev, PCI_BASE_ADDRESS_0); + bar = (u8 *) pci_read_config32(otg_dev, PCI_BASE_ADDRESS_0); - printk(BIOS_DEBUG, "UOCMUX is %x\n", *(bar + UOCMUX)); + printk(BIOS_DEBUG, "UOCMUX is %x\n", readl(bar + UOCMUX)); - *(bar + UOCMUX) &= PUEN_SET; + writel(readl(bar + UOCMUX) & PUEN_SET, bar + UOCMUX); /* Host or Device? */ if (sb->enable_USBP4_device) - *(bar + UOCMUX) |= PMUX_DEVICE; + writel(readl(bar + UOCMUX) | PMUX_DEVICE, bar + UOCMUX); else - *(bar + UOCMUX) |= PMUX_HOST; + writel(readl(bar + UOCMUX) | PMUX_HOST, bar + UOCMUX); /* Overcurrent configuration */ - printk(BIOS_DEBUG, "UOCCAP is %x\n", *(bar + UOCCAP)); + printk(BIOS_DEBUG, "UOCCAP is %x\n", readl(bar + UOCCAP)); if (sb->enable_USBP4_overcurrent) - *(bar + UOCCAP) |= sb->enable_USBP4_overcurrent; + writel(readl(bar + UOCCAP) + | sb->enable_USBP4_overcurrent, bar + UOCCAP); /* power control. see comment in the dts for these bits */ if (sb->pph) { - *(bar + UOCCAP) &= ~0xff; - *(bar + UOCCAP) |= sb->pph; + writel((readl(bar + UOCCAP) + & ~0xff) | sb->pph, bar + UOCCAP); } - printk(BIOS_DEBUG, "UOCCAP is %x\n", *(bar + UOCCAP)); - printk(BIOS_DEBUG, "UOCMUX is %x\n", *(bar + UOCMUX)); + printk(BIOS_DEBUG, "UOCCAP is %x\n", readl(bar + UOCCAP)); + printk(BIOS_DEBUG, "UOCMUX is %x\n", readl(bar + UOCMUX)); } @@ -477,15 +478,16 @@ */ if (sb->enable_USBP4_device) { if (udc_dev) { - bar = (u32 *)pci_read_config32(udc_dev, PCI_BASE_ADDRESS_0); - *(bar + UDCDEVCTL) |= UDC_SD_SET; + bar = (u8 *)pci_read_config32(udc_dev, PCI_BASE_ADDRESS_0); + writel(readl(bar + UDCDEVCTL) | UDC_SD_SET, + bar + UDCDEVCTL); } if (otg_dev) { - bar = (u32 *)pci_read_config32(otg_dev, PCI_BASE_ADDRESS_0); - *(bar + UOCCTL) |= PADEN_SET; - *(bar + UOCCAP) |= APU_SET; - printk(BIOS_DEBUG, "UOCCTL is %x\n", *(bar + UOCCTL)); + bar = (u8 *)pci_read_config32(otg_dev, PCI_BASE_ADDRESS_0); + writel(readl(bar + UOCCTL) | PADEN_SET, bar + UOCCTL); + writel(readl(bar + UOCCAP) | APU_SET, bar + UOCCAP); + printk(BIOS_DEBUG, "UOCCTL is %x\n", readl(bar + UOCCTL)); } }

1 0

Re: [coreboot] SeaBIOS VGA ROM
by Kevin O'Connor 15 Jul '08

15 Jul '08

Hi Tom, I'm cc'ing the mailing list. On Sun, Jul 13, 2008 at 11:59:59AM -0400, Tom Sylla wrote: > Along the way, you have mentioned that SeaBIOS should run the VGA ROM > instead of coreboot. How do I build my ROM to make that happen? My VGA > is integrated, so I usually prepend the ROM, and coreboot runs it. How > will SeaBIOS find it? I think coreboot should load the option roms into ram. There is no standard way to do this in coreboot-v2. What other platforms seem to do is hardcode certain addresses in the C code and then just memcpy them from flash to ram. On my via, I hacked the code so that it still copies the vga option rom, but does not run it. However, it should be possible to setup a standard in coreboot-v3. Each rom could go in a LAR file and coreboot could copy them. For example, we could define a directory "/optionroms/" and each file could automatically be uncompressed and copied. -Kevin

3 3

C Programming
by Star Liu 15 Jul '08

15 Jul '08

I hope I'm not posting to the wrong place, if so, please remind me :) I'm making some practice on C programming, so that I can get into the linux world. Here is a simple code 129 char comment[1025]; 130 cgiFormString("comment", comment, 1025); 131 if(strcasestr(comment, "</xmp")!=NULL) { fprintf(cgiOut, "</xmp is not allowed"); return; } when i compile, there is a warning: gcc -o LeaveMessage LeaveMessage.c cgic.c LeaveMessage.c: In function 'LeaveMessage': LeaveMessage.c:131: warning: comparison between pointer and integer but i found in http://www.gnu.org/software/libc/manual/html_node/Search-Functions.html#Sea… — Function: char * strcasestr (const char *haystack, const char *needle) So i don't know why i got this warning, what's the correct way to deal with it? thanks! -- Regards! Star Shanghai, China

3 4

Re: [coreboot] freedos on OLPC - question
by Kevin O'Connor 14 Jul '08

14 Jul '08

On Mon, Jul 14, 2008 at 03:14:15PM -0400, Guylhem Aznar wrote: > > I'm not sure if you're looking to run natively or via an emulator. If > > you're looking to run natively then I imagine it may require some > > effort to get it up and running. If you're looking to run via an > > emulator, then it should just work. > > I would prefer running freedos under an emulator for now, so it may be > easier to test some applications before deploying them on OLPCs. > > >From what I've read, I think I need to type: > qemu -L build -hda somefreedos.image Yes. > May I ask you a current build/bios.bin ? (the net connection here is > not good at the moment - I can't download everything I need and I > don't see precompiled binaries of seabios+coreboot) http://linuxtogo.org/~kevin/SeaBIOS/bios.bin-0.2.3 > BTW - there will be a problem for running natively freedos ol the OLPC > - the openfirmware used in the OLPC lacks VESA support, and lacks many > dos interruption support. There is a new openfirmware v2 that's > supposed to bring some of these missing features for the upcoming > windows XP support on the OLPC, but I know very little about it. It should be possible to get a VGA driver - the coreboot folks are booting on the OLPC today. Seabios adds all the "dos interrupts" - so it shouldn't need anything from openfirmware. You will want the PIR and ACPI tables - hopefully the next openfirmware will have that. > If you are interested about such issues and wish to work on these > issues, I suggest you read the dev.laptop.org wiki about insyde bios, > linuxbios and openfirmware. I don't think I know such issues well > enough to provide you with a decent sum up of the current situation. Linuxbios is now called coreboot. -Kevin

1 0

Re: [coreboot] freedos on OLPC - question
by Kevin O'Connor 14 Jul '08

14 Jul '08

Hi Guylhem, I'm CC'ing the coreboot mailing list as they seem to know a bit about OLPC and I know very little. On Mon, Jul 14, 2008 at 12:01:21PM -0400, Guylhem Aznar wrote: > Hello > > I saw you where porting Boch bios to Gcc, and you had an active > repository on http://git.linuxtogo.org/?p=kevin/legacybios.git > > What is the status ? It seems very active. Is it in alpha state ? It's active now, but I am still pretty much the only code contributor. (Though, I welcome any additional contributors.) There has been a name change - I now call it "SeaBIOS". I'd say it is in a near release state for use with emulators (qemu or bochs). It's in an early beta stage for use on real hardware (with coreboot). I am able to boot my via epia-m with coreboot+seabios and run freedos. > I would like to know in order to try to run Freedos on the OLPC > (www.laptop.org) for some legacy applications that could be usefull > for children in Brasil. > > I have an OLPC, and I can do some C, so I may give a hand if you could > point me to documentation. > If Freedos could somehow work reliably enough, I would be happy to > test and package it for the OLPC. I'm not sure if you're looking to run natively or via an emulator. If you're looking to run natively then I imagine it may require some effort to get it up and running. If you're looking to run via an emulator, then it should just work. Hope this helps, -Kevin > > Thanks > Guylhem > > -- > Dr Guylhem Aznar, MD PhD

1 0

Re: [coreboot] how could i get the hexadecimal content in memory at address FFFF0000-FFFFFFF0?
by owens＠netptc.net 14 Jul '08

14 Jul '08

> > > >---- Original Message ---- >From: minxinjianxin(a)gmail.com >To: coreboot(a)coreboot.org, debian-user(a)lists.debian.org, >debian-chinese-gb(a)lists.debian.org >Subject: RE: how could i get the hexadecimal content in memory at >address FFFF0000-FFFFFFF0? >Date: Mon, 14 Jul 2008 16:02:42 +0800 > >>I know from cpu manual that when machine starts, it executes >>instruction at FFFFFFF0, and then execute some code at >>FFFF0000-FFFFFFF0, i hope i can get these machine code directly from >>my memory, any tool to help me display the hexadecimal or binary >>content? >> >>thanks! >>-- >>Regards! >>Star >>Shanghai, China The hex values are the "usual" output of any low-level debugger. Google for Linux debugger and take your pick Larry >> >> >>-- >>To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org >>with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.d >ebian.org >> >> >>

1 0

Re: [coreboot] NEOWARE EON 4000S
by Uwe Hermann 14 Jul '08

14 Jul '08

Hi, On Sun, Jul 13, 2008 at 07:13:02PM +0200, Hannes Hegewald wrote: > My console for the serial port was already set up correctly and worked > with the factory bios. I also see the nice white background with the tux > in the corner. OK, that's good. > As I already told you, the boot process hangs for a while > at this point (with coreboot): > > [...] > NET: Registered protocol family 1 > NET: Registered protocol family 17 > Using IPI No-Shortcut mode > kjournald starting. Commit interval 5 seconds > EXT3-fs: mounted filesystem with ordered data mode. > VFS: Mounted root (ext3 filesystem) readonly. > Freeing unused kernel memory: 208k freed > > #### HERE #### > > 8139too Fast Ethernet driver 0.9.28 > PCI: Found IRQ 5 for device 0000:00:0f.0 > IRQ routing conflict for 0000:00:0f.0, have irq 4, want irq 5 This might be an (IRQ) problem, see below. > eth0: RealTek RTL8139 at 0xc485a000, 00:e0:c5:6e:55:93, IRQ 4 > usbcore: registered new interface driver usbfs > usbcore: registered new interface driver hub > usbcore: registered new device driver usb > 8139cp: 10/100 PCI Ethernet driver v1.3 (Mar 22, 2004) > PCI: Found IRQ 3 for device 0000:00:13.0 > IRQ routing conflict for 0000:00:13.0, have irq 7, want irq 3 Ditto. > ohci_hcd 0000:00:13.0: OHCI Host Controller > ohci_hcd 0000:00:13.0: new USB bus registered, assigned bus number 1 > ohci_hcd 0000:00:13.0: irq 7, io mem 0xfebfd000 > usb usb1: configuration #1 chosen from 1 choice > hub 1-0:1.0: USB hub found > hub 1-0:1.0: 2 ports detected > usb 1-1: new low speed USB device using ohci_hcd and address 2 > usb 1-1: configuration #1 chosen from 1 choice > usbcore: registered new interface driver hiddev > input: HID 062a:0000 as /class/input/input0 > input: USB HID v1.10 Mouse [HID 062a:0000] on usb-0000:00:13.0-1 > usbcore: registered new interface driver usbhid > drivers/hid/usbhid/hid-core.c: v2.6:USB HID core driver > usb 1-1: USB disconnect, address 2 > usb 1-2: new low speed USB device using ohci_hcd and address 3 > usb 1-2: configuration #1 chosen from 1 choice > input: HID 062a:0000 as /class/input/input1 > input: USB HID v1.10 Mouse [HID 062a:0000] on usb-0000:00:13.0-2 > usb 1-2: USB disconnect, address 320080711 19:25:54 > > And in comparison to a normal bootlog, something is different: > [normal bootlog:] > > Freeing unused kernel memory: 208k freed > #### Thats the point where coreboot pauses ## > ## And now the foolowing two lines are missing with coreboot: > > INIT: version 2.86 booting > The system is coming up. Please wait. That's strange, probably even misleading. The actual reason for the hang is likely in some other place. My guess is that the IRQs are messed up. Can you try to boot the kernel with the 'irqpoll' option and see if that helps? Also, are you sure the irq_table.c in the patch is correct? I think it was generated with getpir on your 4000s? Anyway, sometimes even the tables of the proprietary BIOS are crap, so... > 8139too Fast Ethernet driver 0.9.28 > PCI: Assigned IRQ 11 for device 0000:00:0f.0 > eth0: RealTek RTL8139 at 0xc4854000, 00:e0:c5:6e:55:93, IRQ 11 > usbcore: registered new interface driver usbfs > usbcore: registered new interface driver hub > usbcore: registered new device driver usb > PCI: Assigned IRQ 15 for device 0000:00:13.0 > ohci_hcd 0000:00:13.0: OHCI Host Controller > ohci_hcd 0000:00:13.0: new USB bus registered, assigned bus number 1 > ohci_hcd 0000:00:13.0: irq 15, io mem 0xd8004000 > 8139cp: 10/100 PCI Ethernet driver v1.3 (Mar 22, 2004) > usb usb1: configuration #1 chosen from 1 choice > hub 1-0:1.0: USB hub found > hub 1-0:1.0: 2 ports detected > /dev/hda1: clean, 115552/541728 files, 638097/1054257 blocks > /sbin/fsck.xfs: XFS file system. > EXT3 FS on hda1, internal journal > XFS mounting filesystem hda2 > Adding 265064k swap on /dev/hda3. Priority:-1 extents:1 across:265064k > hostname: crux > font: default > keyboard: de-latin1 > INIT: Entering runlevel: 2 > starting services: sysklogd net fcron sshd samba led > > > CRUX (crux) (ttyS0) > > > Thanks for your help once more. > > Hannes Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org

1 0

why my program segmentation fault?
by Star Liu 14 Jul '08

14 Jul '08

I wrote a program to copy the memory content of FFFF0000-FFFFFFFF to a file, but it says "Segmentation fault", (i use AMD64 lenny, so the address is long), how could i fix it? thanks! #include <string.h> #include <stdio.h> void CopyMemoryToFile(char* FilePath, long StartAddress, long OffSet) { FILE* Memory; Memory=fopen (FilePath, "w"); if(Memory!=NULL) { void* Start; Start=StartAddress; fwrite(Start, 1, OffSet, Memory); } fclose(Memory); } int main (void) { CopyMemoryToFile("~/cgi-bin_d/Memory",0xFFFF0000,0xFFFF); return 0; } -- Regards! Star Shanghai, China

3 2

USB debug cables and emulation
by Carl-Daniel Hailfinger 14 Jul '08

14 Jul '08

Hi, I'm not officially back yet, but here's a question I don't want to forget: Are there any easily available USB debug cables? The NET20DC is very difficult to get in Europe. Can I emulate such a cable with the Geode USB target mode? Regards, Carl-Daniel

8 40

Re: [coreboot] NEOWARE EON 4000S
by Uwe Hermann 13 Jul '08

13 Jul '08

Hi, (please always CC the coreboot mailinglist, thanks!) On Sat, Jul 12, 2008 at 07:39:03PM +0200, Hannes Hegewald wrote: > Here are the logs, I hope you can figure out what the problem is. > > Greetings, Hannes > > > > coreboot-2.0.0.0Normal Fr 11. Jul 18:12:37 CEST 2008 starting... > Setting up default parameters for memory > Sizing memory > Probing for DIMM0 > Found DIMM0 > Page Size: 00002000 > Component Banks: 4 > Module Banks: 2 > DIMM size: 10000000 > Probing for DIMM1 > Found DIMM1 > Page Size: 00001000 > Component Banks: 4 > Module Banks: 1 > DIMM size: 04000000 > MC_BANK_CFG = 14205630 > Copying coreboot to RAM. > Jumping to coreboot. > coreboot-2.0.0.0Normal Fr 11. Jul 18:20:47 CEST 2008 booting... > end 572e4fee, start 0 > 32-bit delta 464 > calibrate_tsc 32-bit result is 464 > clocks_per_usec: 464 > Enumerating buses... > scan_static_bus for Root Device > northbridge.c:enable_dev() > DEVICE_PATH_PCI_DOMAIN > Finding PCI configuration type. > PCI: Using configuration type 1 > PCI_DOMAIN: 0000 enabled > PCI_DOMAIN: 0000 scanning... > PCI: pci_scan_bus for bus 00 > northbridge.c:enable_dev() > device path type 2 > PCI: 00:00.0 [1078/0001] ops > PCI: 00:00.0 [1078/0001] enabled > PCI: devfn 0x8, bad id 0xffffffff > PCI: devfn 0x10, bad id 0xffffffff > PCI: devfn 0x18, bad id 0xffffffff > PCI: devfn 0x20, bad id 0xffffffff > PCI: devfn 0x28, bad id 0xffffffff > PCI: devfn 0x30, bad id 0xffffffff > malloc Enter, size 1100, free_mem_ptr 0001a000 > malloc 0x0001a000 > PCI: 00:07.0 [10ec/8139] enabled > PCI: devfn 0x40, bad id 0xffffffff > PCI: devfn 0x48, bad id 0xffffffff > PCI: devfn 0x50, bad id 0xffffffff > PCI: devfn 0x58, bad id 0xffffffff > PCI: devfn 0x60, bad id 0xffffffff > PCI: devfn 0x68, bad id 0xffffffff > PCI: devfn 0x70, bad id 0xffffffff > PCI: 00:0f.0 [10ec/8139] enabled > PCI: devfn 0x80, bad id 0xffffffff > PCI: devfn 0x88, bad id 0xffffffff > PCI: 00:12.0 [1078/0100] bus ops > PCI: 00:12.0 [1078/0100] enabled > PCI: 00:12.1 [1078/0101] disabled > PCI: 00:12.2 [1078/0102] bus ops > PCI: 00:12.2 [1078/0102] enabled > PCI: 00:12.3 [1078/0103] enabled > PCI: 00:12.4 [1078/0104] ops > PCI: 00:12.4 [1078/0104] enabled > PCI: devfn 0x95, bad id 0xffffffff > PCI: devfn 0x96, bad id 0xffffffff > PCI: devfn 0x97, bad id 0xffffffff > PCI: 00:13.0 [0e11/a0f8] enabled > PCI: devfn 0xa0, bad id 0xffffffff > PCI: devfn 0xa8, bad id 0xffffffff > PCI: devfn 0xb0, bad id 0xffffffff > PCI: devfn 0xb8, bad id 0xffffffff > PCI: devfn 0xc0, bad id 0xffffffff > PCI: devfn 0xc8, bad id 0xffffffff > PCI: devfn 0xd0, bad id 0xffffffff > PCI: devfn 0xd8, bad id 0xffffffff > PCI: devfn 0xe0, bad id 0xffffffff > PCI: devfn 0xe8, bad id 0xffffffff > PCI: devfn 0xf0, bad id 0xffffffff > PCI: devfn 0xf8, bad id 0xffffffff > scan_static_bus for PCI: 00:12.0 > malloc Enter, size 1100, free_mem_ptr 0001a44c > malloc 0x0001a44c > PNP: 002e.0 disabled > PNP: 002e.1 enabled > PNP: 002e.2 enabled > PNP: 002e.e enabled > PNP: 002e.4 enabled > PNP: 002e.5 enabled > PNP: 002e.6 enabled > PNP: 002e.7 enabled > PNP: 002e.8 enabled > PNP: 002e.3 enabled > scan_static_bus for PCI: 00:12.0 done > scan_static_bus for PCI: 00:12.2 > scan_static_bus for PCI: 00:12.2 done > PCI: pci_scan_bus returning with max=000 > scan_static_bus for Root Device done > done > Allocating resources... > Reading resources... > Root Device compute_allocate_io: base: 00000400 size: 00000000 align: 0 gran: 0 > Root Device read_resources bus 0 link: 0 > northbridge.c:pci_domain_read_resources() > PCI_DOMAIN: 0000 read_resources bus 0 link: 0 > PCI_DOMAIN: 0000 read_resources bus 0 link: 0 done > Root Device read_resources bus 0 link: 0 done > PCI: 00:07.0 10 * [0x00000400 - 0x000004ff] io > PCI: 00:0f.0 10 * [0x00000800 - 0x000008ff] io > PCI: 00:12.2 20 * [0x00000c00 - 0x00000c7f] io > Root Device compute_allocate_io: base: 00000c80 size: 00000880 align: 8 gran: 0 done > Root Device compute_allocate_mem: base: 00000000 size: 00000000 align: 0 gran: 0 > Root Device read_resources bus 0 link: 0 > Root Device read_resources bus 0 link: 0 done > PCI: 00:12.4 10 * [0x00000000 - 0x00000fff] mem > PCI: 00:13.0 10 * [0x00001000 - 0x00001fff] mem > PCI: 00:07.0 14 * [0x00002000 - 0x000020ff] mem > PCI: 00:0f.0 14 * [0x00003000 - 0x000030ff] mem > PCI: 00:12.3 10 * [0x00004000 - 0x0000407f] mem > Root Device compute_allocate_mem: base: 00004080 size: 00004080 align: 12 gran: 0 done > Done reading resources. > Setting resources... > Root Device compute_allocate_io: base: 00001000 size: 00000880 align: 8 gran: 0 > Root Device read_resources bus 0 link: 0 > Root Device read_resources bus 0 link: 0 done > PCI: 00:07.0 10 * [0x00001000 - 0x000010ff] io > PCI: 00:0f.0 10 * [0x00001400 - 0x000014ff] io > PCI: 00:12.2 20 * [0x00001800 - 0x0000187f] io > Root Device compute_allocate_io: base: 00001880 size: 00000880 align: 8 gran: 0 done > Root Device compute_allocate_mem: base: febfb000 size: 00004080 align: 12 gran: 0 > Root Device read_resources bus 0 link: 0 > Root Device read_resources bus 0 link: 0 done > PCI: 00:12.4 10 * [0xfebfb000 - 0xfebfbfff] mem > PCI: 00:13.0 10 * [0xfebfc000 - 0xfebfcfff] mem > PCI: 00:07.0 14 * [0xfebfd000 - 0xfebfd0ff] mem > PCI: 00:0f.0 14 * [0xfebfe000 - 0xfebfe0ff] mem > PCI: 00:12.3 10 * [0xfebff000 - 0xfebff07f] mem > Root Device compute_allocate_mem: base: febff080 size: 00004080 align: 12 gran: 0 done > Root Device assign_resources, bus 0 link: 0 > BC_DRAM_TOP = 0x13dfffff > MC_GBASE_ADD = 0x0000027c > I would set ram size to 318 Mbytes Is this correct? I don't even know if the GX1 and/or the resp. coreboot code supports more than 256MB (probably yes). Still, can you try with 256MB or less and see if anything changes? > PCI_DOMAIN: 0000 assign_resources, bus 0 link: 0 > PCI: 00:07.0 10 <- [0x0000001000 - 0x00000010ff] size 0x00000100 gran 0x08 io > PCI: 00:07.0 14 <- [0x00febfd000 - 0x00febfd0ff] size 0x00000100 gran 0x08 mem > PCI: 00:0f.0 10 <- [0x0000001400 - 0x00000014ff] size 0x00000100 gran 0x08 io > PCI: 00:0f.0 14 <- [0x00febfe000 - 0x00febfe0ff] size 0x00000100 gran 0x08 mem > PCI: 00:12.2 20 <- [0x0000001800 - 0x000000187f] size 0x00000080 gran 0x07 io > PCI: 00:12.3 10 <- [0x00febff000 - 0x00febff07f] size 0x00000080 gran 0x07 mem > PCI: 00:12.4 10 <- [0x00febfb000 - 0x00febfbfff] size 0x00001000 gran 0x0c mem > PCI: 00:13.0 10 <- [0x00febfc000 - 0x00febfcfff] size 0x00001000 gran 0x0c mem > PCI_DOMAIN: 0000 assign_resources, bus 0 link: 0 > Root Device assign_resources, bus 0 link: 0 > Done setting resources. > Done allocating resources. > Enabling resources... > PCI: 00:00.0 cmd <- 07 > PCI: 00:07.0 cmd <- 03 > PCI: 00:0f.0 subsystem <- 00/00 > PCI: 00:0f.0 cmd <- 03 > PCI: 00:12.0 cmd <- 0f > PNP: 002e.e missing enable_resources > PCI: 00:12.2 cmd <- 01 > PCI: 00:12.3 subsystem <- 00/00 > PCI: 00:12.3 cmd <- 02 > PCI: 00:12.4 cmd <- 02 > PCI: 00:13.0 subsystem <- 00/00 > PCI: 00:13.0 cmd <- 02 > done. > Initializing devices... > Root Device init > PCI: 00:00.0 init > northbridge: northbridge_init() > Calling enable_cache() > PCI: 00:0f.0 init > PCI: 00:12.0 init > PNP: 002e.1 init > PNP: 002e.2 init > PNP: 002e.4 init > PNP: 002e.5 init > PNP: 002e.6 init > Keyboard init... > PNP: 002e.7 init > PNP: 002e.8 init > PCI: 00:12.2 init > Primary IDE interface enabled > Secondary IDE interface disabled > PCI: 00:12.3 init > PCI: 00:12.4 init > Setting up video mode 640x480 with 31500000 Hz clock > PCI: 00:13.0 init > PCI: 00:07.0 init > PNP: 002e.3 init > Devices initialized > Copying IRQ routing tables to 0xf0000...done. > Verifing copy of IRQ routing tables at 0xf0000...done > Checking IRQ routing table consistency... > check_pirq_routing_table() - irq_routing_table located at: 0x000f0000 > done. > PIR Entry 0 Dev/Fn: 7 Slot: 1 > INT: A link: 2 bitmap: deb8 IRQ: 3 > INT: B link: 3 bitmap: deb8 IRQ: 4 > INT: C link: 4 bitmap: deb8 IRQ: 5 > INT: D link: 1 bitmap: deb8 IRQ: 7 > Assigning IRQ 3 to 0:7.0 > Readback = 3 > pci_level_irq: current ints are 0x0 > pci_level_irq: try to set ints 0x8 > PIR Entry 1 Dev/Fn: F Slot: 2 > INT: A link: 3 bitmap: deb8 IRQ: 4 > INT: B link: 4 bitmap: deb8 IRQ: 5 > INT: C link: 1 bitmap: deb8 IRQ: 7 > INT: D link: 2 bitmap: deb8 IRQ: 3 > Assigning IRQ 4 to 0:f.0 > Readback = 4 > pci_level_irq: current ints are 0x8 > pci_level_irq: try to set ints 0x18 > PIR Entry 2 Dev/Fn: 13 Slot: 0 > INT: A link: 1 bitmap: deb8 IRQ: 7 > INT: B link: 0 bitmap: deb8 not routed > INT: C link: 0 bitmap: deb8 not routed > INT: D link: 0 bitmap: deb8 not routed > Assigning IRQ 7 to 0:13.0 > Readback = 7 > pci_level_irq: current ints are 0x18 > pci_level_irq: try to set ints 0x98 > PIRQ1: 7 > PIRQ2: 3 > PIRQ3: 4 > PIRQ4: 5 > Moving GDT to 0x500...ok > Adjust low_table_end from 0x00000530 to 0x00001000 > Adjust rom_table_end from 0x000f0400 to 0x00100000 > Wrote coreboot table at: 00000530 - 00000748 checksum 4a30 > > Welcome to elfboot, the open sourced starter. > January 2002, Eric Biederman. > Version 1.3 > > rom_stream: 0xfffc0000 - 0xfffcffff > Found ELF candidate at offset 0 > header_offset is 0 > Try to load at offset 0x0 > malloc Enter, size 32, free_mem_ptr 0001a898 > malloc 0x0001a898 > New segment addr 0x100000 size 0x33ae0 offset 0xc0 filesize 0xa648 > (cleaned up) New segment addr 0x100000 size 0x33ae0 offset 0xc0 filesize 0xa648 > lb: [0x0000000000004000, 0x000000000001e000) > malloc Enter, size 32, free_mem_ptr 0001a8b8 > malloc 0x0001a8b8 > New segment addr 0x133ae0 size 0x48 offset 0xa720 filesize 0x48 > (cleaned up) New segment addr 0x133ae0 size 0x48 offset 0xa720 filesize 0x48 > lb: [0x0000000000004000, 0x000000000001e000) > Dropping non PT_LOAD segment > Dropping non PT_LOAD segment > Loading Segment: addr: 0x0000000000100000 memsz: 0x0000000000033ae0 filesz: 0x000000000000a648 > [ 0x0000000000100000, 000000000010a648, 0x0000000000133ae0) <- 00000000000000c0 > Clearing Segment: addr: 0x000000000010a648 memsz: 0x0000000000029498 > Loading Segment: addr: 0x0000000000133ae0 memsz: 0x0000000000000048 filesz: 0x0000000000000048 > [ 0x0000000000133ae0, 0000000000133b28, 0x0000000000133b28) <- 000000000000a720 > Loaded segments > verified segments > closed down stream > Jumping to boot code at 0x10854c > entry = 0x0010854c > lb_start = 0x00004000 > lb_size = 0x0001a000 > adjust = 0x13de2000 > buffer = 0x13dcc000 > elf_boot_notes = 0x00014140 > adjusted_boot_notes = 0x13df6140 > FILO version 0.5.5 (root@zendeb) Fri Jul 11 18:19:27 CEST 2008 > boot: hda1:/boot/vmlinuz root=/dev/hda1 console=tty0 console=ttyS0,9600 11500 200 > hda: LBA 80GB: MAXTOR 6L080J4 > Mounted EXT2 filesystem > Found Linux version 2.6.24.4 (root@crux) #2 SMP Fri May 23 11:56:57 CEST 2008 bzImage. > Loading kernel... ok > Jumping to entry point... > Linux version 2.6.24.4 (root@crux) (gcc version 4.2.4 (CRUX)) #2 SMP Fri May 23 11:56:57 CEST 2008 > BIOS-provided physical RAM map: > BIOS-e820: 0000000000001000 - 00000000000a0000 (usable) > BIOS-e820: 0000000000100000 - 0000000013e00000 (usable) > 318MB LOWMEM available. > Zone PFN ranges: > DMA 0 -> 4096 > Normal 4096 -> 81408 > Movable zone start PFN for each node > early_node_map[1] active PFN ranges > 0: 0 -> 81408 > DMI not present or invalid. > Allocating PCI resources starting at 20000000 (gap: 13e00000:ec200000) > Built 1 zonelists in Zone order, mobility grouping on. Total pages: 80772 > Kernel command line: root=/dev/hda1 console=tty0 console=ttyS0,115200 > No local APIC present or hardware disabled > Initializing CPU#0 > PID hash table entries: 2048 (order: 11, 8192 bytes) > Detected 300.689 MHz processor. > Console: colour dummy device 80x25 > console [tty0] enabled > console [ttyS0] enabled > Dentry cache hash table entries: 65536 (order: 6, 262144 bytes) > Inode-cache hash table entries: 32768 (order: 5, 131072 bytes) > Memory: 317888k/325632k available (2644k kernel code, 7288k reserved, 888k data, 208k init, 0k highmem) > virtual kernel memory layout: > fixmap : 0xfffb5000 - 0xfffff000 ( 296 kB) > vmalloc : 0xd4800000 - 0xfffb3000 ( 695 MB) > lowmem : 0xc0000000 - 0xd3e00000 ( 318 MB) > .init : 0xc047a000 - 0xc04ae000 ( 208 kB) > .data : 0xc03950d0 - 0xc04732f4 ( 888 kB) > .text : 0xc0100000 - 0xc03950d0 (2644 kB) > Checking if this processor honours the WP bit even in supervisor mode... Ok. > Calibrating delay using timer specific routine.. 603.82 BogoMIPS (lpj=1207651) > Mount-cache hash table entries: 512 > Working around Cyrix MediaGX virtual DMA bugs. > Enable Memory-Write-back mode on Cyrix/NSC processor. > Enable Memory access reorder on Cyrix/NSC processor. > Enable Incrementor on Cyrix/NSC processor. > Compat vDSO mapped to ffffe000. > Checking 'hlt' instruction... OK. > SMP alternatives: switching to UP code > Freeing SMP alternatives: 14k freed > ACPI: Core revision 20070126 > ACPI Exception (tbxface-0629): AE_NO_ACPI_TABLES, While loading namespace from ACPI tables [20070126] > ACPI: Unable to load the System Description Tables > CPU0: NSC Geode(TM) Integrated Processor by National Semi stepping 02 > SMP motherboard not detected. > Local APIC not detected. Using dummy APIC emulation. > Brought up 1 CPUs > net_namespace: 64 bytes > NET: Registered protocol family 16 > EISA bus registered > PCI: Using configuration type 1 > Setting up standard PCI resources > ACPI: Interpreter disabled. > Linux Plug and Play Support v0.97 (c) Adam Belay > pnp: PnP ACPI: disabled > SCSI subsystem initialized > PCI: Probing PCI hardware > PCI: Using IRQ router NatSemi [1078/0100] at 0000:00:12.0 > Time: tsc clocksource has been installed. > NET: Registered protocol family 2 > IP route cache hash table entries: 4096 (order: 2, 16384 bytes) > TCP established hash table entries: 16384 (order: 5, 131072 bytes) > TCP bind hash table entries: 16384 (order: 5, 131072 bytes) > TCP: Hash tables configured (established 16384 bind 16384) > TCP reno registered > microcode: CPU0 not a capable Intel processor > IA-32 Microcode Update Driver: v1.14a <tigran(a)aivazian.fsnet.co.uk> > JFS: nTxBlock = 2484, nTxLock = 19873 > SGI XFS with ACLs, security attributes, realtime, large block numbers, no debug enabled > SGI XFS Quota Management subsystem > io scheduler noop registered > io scheduler deadline registered (default) > PCI: Fixup for MediaGX/Geode Slave Disconnect Boundary (0x41=0x10) > isapnp: Scanning for PnP cards... > isapnp: No Plug & Play device found > Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing enabled > serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A > serial8250: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A > RAMDISK driver initialized: 16 RAM disks of 8192K size 1024 blocksize > loop: module loaded > Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2 > ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx > CS5530: IDE controller (0x1078:0x0102 rev 0x00) at PCI slot 0000:00:12.2 > CS5530: not 100% native mode: will probe irqs later > ide0: BM-DMA at 0x1800-0x1807, BIOS settings: hda:pio, hdb:pio > ide1: BM-DMA at 0x1808-0x180f, BIOS settings: hdc:pio, hdd:pio > Clocksource tsc unstable (delta = -212020323 ns) > Time: pit clocksource has been installed. > hda: MAXTOR 6L080J4, ATA DISK drive > hda: UDMA/33 mode selected > ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 > hda: max request size: 128KiB > hda: 156355584 sectors (80054 MB) w/1819KiB Cache, CHS=65535/16/63 > hda: cache flushes supported > hda: hda1 hda2 hda3 > Driver 'sd' needs updating - please use bus_type methods > Driver 'sr' needs updating - please use bus_type methods > Fusion MPT base driver 3.04.06 > Copyright (c) 1999-2007 LSI Corporation > Fusion MPT SPI Host driver 3.04.06 > PNP: No PS/2 controller found. Probing ports directly. > serio: i8042 KBD port at 0x60,0x64 irq 1 > mice: PS/2 mouse device common for all mice > EISA: Probing bus 0 at eisa.0 > Cannot allocate resource for EISA slot 1 > EISA: Detected 0 cards. > TCP cubic registered > NET: Registered protocol family 1 > NET: Registered protocol family 17 > Using IPI No-Shortcut mode > kjournald starting. Commit interval 5 seconds > EXT3-fs: mounted filesystem with ordered data mode. > VFS: Mounted root (ext3 filesystem) readonly. > Freeing unused kernel memory: 208k freed > 8139too Fast Ethernet driver 0.9.28 > PCI: Found IRQ 7 for device 0000:00:07.0 > IRQ routing conflict for 0000:00:07.0, have irq 3, want irq 7 > eth0: RealTek RTL8139 at 0xd4984000, 00:c0:26:86:ca:7d, IRQ 3 > PCI: Found IRQ 5 for device 0000:00:0f.0 > IRQ routing conflict for 0000:00:0f.0, have irq 4, want irq 5 > eth1: RealTek RTL8139 at 0xd4986000, 00:e0:c5:6e:55:93, IRQ 4 > 8139cp: 10/100 PCI Ethernet driver v1.3 (Mar 22, 2004) > usbcore: registered new interface driver usbfs > usbcore: registered new interface driver hub > usbcore: registered new device driver usb > PCI: Found IRQ 3 for device 0000:00:13.0 > IRQ routing conflict for 0000:00:13.0, have irq 7, want irq 3 > ohci_hcd 0000:00:13.0: OHCI Host Controller > ohci_hcd 0000:00:13.0: new USB bus registered, assigned bus number 1 > ohci_hcd 0000:00:13.0: irq 7, io mem 0xfebfc000 > usb usb1: configuration #1 chosen from 1 choice > hub 1-0:1.0: USB hub found > hub 1-0:1.0: 2 ports detected Is this where the process hangs? Both coreboot and Linux seems to have run fine, I cannot spot any serious problems. What do you see on the screen? A white background with a small penguin in the corner? If yes, that's fine (you won't see anything more on VGA). As for serial: Have you enabled a console for serial so you can login? Edit /etc/inittab and add something like: T0:23:respawn:/sbin/getty -L ttyS0 115200 vt100 then run 'init q' and reboot with coreboot. HTH, Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org

1 0

← Newer
1
...
9
10
11
12
13
14
15
...
22
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot July 2008