coreboot May 2007

coreboot@coreboot.org

98 participants
436 discussions

[LinuxBIOS] Geode GX1 PCI, VGA and Sound configuration -- was Re: Televideo TC7020 successfully booted with LinuxBiosV2
by Kenji Noguchi 08 May '07

08 May '07

I changed the Subject. 2007/5/5, Peter Stuge <stuge-linuxbios(a)cdy.org>: > On Fri, May 04, 2007 at 11:04:45PM -0700, Kenji Noguchi wrote: > > //CS5530A > > pdev = dev_find_slot(0, (0x12 << 3) + 0); > > pci_write_config8(pdev, 0x5c, 0xab); > > pci_write_config8(pdev, 0x5d, 0x09); > > pci_assign_irqs(0, 0x13, usb_irq); > > pci_assign_irqs(0, 0x15, nic_irq); > > > > I couldn't find a code in LinuxBIOSv2 that does the same thing > > Where should I put these lines if such code does not exist, and > > mainboard.c is not a right place? > > I think this goes into the mainboard Config.lb, where the PCI devices > are listed. I still don't understand fully how LB initializes stuff, or what the scope of LB is in terms of PCI IRQ configuration. So please bare with my noob questions. 1) What is the name of the config options in the Config.lb for PCI IRQ# and IRQ sterring? 2) Where is the corresponding code that actually configures IRQ sterring for CS5530? 3) Or, can/should I leave the configuration part to a OS as long as irq_tables.c sets a proper irq_routing_table? I've read about people who booted LB with GX1 in the ML. Did they solely rely on the irq_routin_table? > > doesn't work: VGA, > > Not even with geodefb? I wasn't aware of the driver existed. I loaded the driver but the VGA is still not on. I will read documents of the driver. tv:~# modprobe gx1fb gx1fb 0000:00:12.4: 4096 Kibyte of video memory at 0x40800000 Console: switching to colour frame buffer device 80x30 fb0: GX1 frame buffer device > > Sound , > > There is a FreeBSD driver but that doesn't help you of course. See if > you can find a native CS5530 ALSA driver that does the same thing. It seems the same topic was discussed in the ML sometime back. Anyone still working on it? If not, I'll try to port the driver when I have more time. >> Reset(rebooting hangs the machine) > > Dunno about this one. CONFIG_X86_REBOOTFIXUPS=y in ther kernel config fixed the problem. Thanks, Kenji Noguchi

7 10

[LinuxBIOS] Preferred patch method
by Ceri Coburn 08 May '07

08 May '07

Hi Guys, Which is preferred by you guys when sending in patches? Single patch with various updates, or multiple patches for specific updates? C

2 1

[LinuxBIOS] r2640 build service
by LinuxBIOS information 08 May '07

08 May '07

Dear LinuxBIOS readers! This is the automated build check service of LinuxBIOS. The developer "rminnich" checked in revision 2640 to the LinuxBIOS source repository and caused the following changes: Change Log: New irq table, and a correct setting for the 5c register in the southbridge so that interrupts are routed correctly. With this patch, ethernet works quite well. Signed-off-by: Ronald G. Minnich <rminnich(a)gmail.com> Acked-by: Stefan Reinauer <stepan(a)coresystems.de> Build Log: Compilation of arima:hdama is still broken Compilation of artecgroup:dbe61 is still broken Compilation of ibm:e325 is still broken Compilation of ibm:e326 is still broken Compilation of iwill:dk8s2 is still broken Compilation of iwill:dk8x is still broken If something broke during this checkin please be a pain in rminnich's neck until the issue is fixed. If this issue is not fixed within 24h the revision will be backed out. Yours truely, LinuxBIOS automatic build system

1 0

[LinuxBIOS] r2640 - trunk/LinuxBIOSv2/src/mainboard/digitallogic/msm800sev
by svn＠openbios.org 08 May '07

08 May '07

Author: rminnich Date: 2007-05-08 18:04:36 +0200 (Tue, 08 May 2007) New Revision: 2640 Modified: trunk/LinuxBIOSv2/src/mainboard/digitallogic/msm800sev/irq_tables.c Log: New irq table, and a correct setting for the 5c register in the southbridge so that interrupts are routed correctly. With this patch, ethernet works quite well. Signed-off-by: Ronald G. Minnich <rminnich(a)gmail.com> Acked-by: Stefan Reinauer <stepan(a)coresystems.de> Modified: trunk/LinuxBIOSv2/src/mainboard/digitallogic/msm800sev/irq_tables.c =================================================================== --- trunk/LinuxBIOSv2/src/mainboard/digitallogic/msm800sev/irq_tables.c 2007-05-07 22:26:46 UTC (rev 2639) +++ trunk/LinuxBIOSv2/src/mainboard/digitallogic/msm800sev/irq_tables.c 2007-05-08 16:04:36 UTC (rev 2640) @@ -1,65 +1,3 @@ -#if 0 -/* This file was generated by getpir.c, do not modify! - (but if you do, please run checkpir on it to verify) - * Contains the IRQ Routing Table dumped directly from your memory, which BIOS sets up - * - * Documentation at : http://www.microsoft.com/hwdev/busbios/PCIIRQ.HTM -*/ - -#include <arch/pirq_routing.h> - -#define ID_SLOT_PCI_NET 1 // ThinCan ethernet -#define ID_SLOT_PCI_RSVD1 2 // reserved entry 1 -#define ID_SLOT_PCI_RSVD3 3 // reserved entry 2 -#define ID_SLOT_PCI_RSVD2 4 // reserved entry 3 -#define ID_EMBED_PCI 0xff // onboard PCI device - -// CS5535 PCI INT[A-D] Interrupt Routing lines. -#define NO_CONNECT 0 // not used -#define CS_PCI_INTA 1 // PCI INTA -#define CS_PCI_INTB 2 // PCI INTB -#define CS_PCI_INTC 3 // PCI INTC -#define CS_PCI_INTD 4 // PCI INTD - -// IRQ bitmap reference line FEDCBA9876543210 -// 0000110000100000b -#define PCI_IRQ 0xc20 // PCI allowed IRQs here - -const struct irq_routing_table intel_irq_routing_table = -{ - PIRQ_SIGNATURE, /* u32 signature */ - PIRQ_VERSION, /* u16 version */ - 32+16*6, /* there can be total 2 devices on the bus */ - 0x00, /* Where the interrupt router lies (bus) */ - (0x12<<3)|0x0, /* Where the interrupt router lies (dev) */ - 0x0800, /* IRQs devoted exclusively to PCI usage */ - 0x1022, /* Vendor */ - 0x208f, /* Device */ - 0x00000000, /* Crap (miniport) */ - { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, /* u8 rfu[11] */ - 0xdf, /* u8 checksum , this hase to set to some value that would give 0 after the sum of all bytes for this structure (including checksum) */ - { - /* bus, dev|fn, {link, bitmap}, {link, bitmap}, {link, bitmap}, {link, bitmap}, slot, rfu */ - // Geode GX3 Host Bridge and VGA Graphics - {0, 0x01<<3, {{CS_PCI_INTA, PCI_IRQ}, {NO_CONNECT, PCI_IRQ}, {NO_CONNECT, PCI_IRQ}, {NO_CONNECT, PCI_IRQ}}, ID_EMBED_PCI, 0x0}, - // Realtek RTL8100/8139 Network Controller - {0, 0x0d<<3, {{CS_PCI_INTB, PCI_IRQ}, {CS_PCI_INTC, PCI_IRQ}, {CS_PCI_INTD, PCI_IRQ}, {CS_PCI_INTA, PCI_IRQ}}, ID_SLOT_PCI_NET, 0x0}, - // Reserved for future extensions - {0, 0x0c<<3, {{CS_PCI_INTA, PCI_IRQ}, {CS_PCI_INTB, PCI_IRQ}, {CS_PCI_INTC, PCI_IRQ}, {CS_PCI_INTD, PCI_IRQ}}, ID_SLOT_PCI_RSVD1, 0x0}, - // Geode CS5535/CS5536 IO Companion: USB controllers, IDE, Audio. - {0, 0x0f<<3, {{CS_PCI_INTA, PCI_IRQ}, {CS_PCI_INTB, PCI_IRQ}, {CS_PCI_INTC, PCI_IRQ}, {CS_PCI_INTD, PCI_IRQ}}, ID_EMBED_PCI, 0x0}, - // Reserved for future extensions - {0, 0x0e<<3, {{CS_PCI_INTC, PCI_IRQ}, {CS_PCI_INTD, PCI_IRQ}, {CS_PCI_INTA, PCI_IRQ}, {CS_PCI_INTB, PCI_IRQ}}, ID_SLOT_PCI_RSVD2, 0x0}, - // Reserved for future extensions - {0, 0x0b<<3, {{CS_PCI_INTD, PCI_IRQ}, {CS_PCI_INTA, PCI_IRQ}, {CS_PCI_INTB, PCI_IRQ}, {CS_PCI_INTC, PCI_IRQ}}, ID_SLOT_PCI_RSVD3, 0x0} - } -}; - -unsigned long write_pirq_routing_table(unsigned long addr) -{ - return copy_pirq_routing_table(addr); -} -#endif /* * This file is part of the LinuxBIOS project. * @@ -104,31 +42,34 @@ #define L_PIRQD 4 /* Means Slot INTx# Connects To Chipset INTD# */ const struct irq_routing_table intel_irq_routing_table = { - PIRQ_SIGNATURE, /* u32 signature */ - PIRQ_VERSION, /* u16 version */ - 32+16*IRQ_SLOT_COUNT, /* there can be total 6 devices on the bus */ - 0x00, /* Where the interrupt router lies (bus) */ - (0x0F<<3)|0x0, /* Where the interrupt router lies (dev) */ - 0x00, /* IRQs devoted exclusively to PCI usage */ - 0x100B, /* Vendor */ - 0x002B, /* Device */ - 0, /* Crap (miniport) */ - { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, /* u8 rfu[11] */ - 0x00, /* u8 checksum , this has to set to some value that would give 0 after the sum of all bytes for this structure (including checksum) */ - { - /* If you change the number of entries, change the IRQ_SLOT_COUNT above! */ - /* bus, dev|fn, {link, bitmap}, {link, bitmap}, {link, bitmap}, {link, bitmap}, slot, rfu */ - {0x00,(0x01<<3)|0x0, {{L_PIRQA, M_PIRQA}, {0x00, 0x00}, {0x00, 0x00}, {0x00, 0x00}}, 0x0, 0x0}, /* cpu */ - {0x00,(0x0F<<3)|0x0, {{L_PIRQA, M_PIRQA}, {L_PIRQB, M_PIRQB}, {L_PIRQC, M_PIRQC}, {L_PIRQD, M_PIRQD}}, 0x0, 0x0}, /* chipset */ - {0x00,(0x0C<<3)|0x0, {{L_PIRQB, M_PIRQB}, {L_PIRQC, M_PIRQC}, {L_PIRQD, M_PIRQD}, {L_PIRQA, M_PIRQA}}, 0x1, 0x0}, /* slot1 */ - {0x00,(0x0D<<3)|0x0, {{L_PIRQC, M_PIRQC}, {L_PIRQD, M_PIRQD}, {L_PIRQA, M_PIRQA}, {L_PIRQB, M_PIRQB}}, 0x2, 0x0}, /* slot2 */ - {0x00,(0x0A<<3)|0x0, {{L_PIRQD, M_PIRQD}, {L_PIRQA, M_PIRQA}, {L_PIRQB, M_PIRQB}, {L_PIRQC, M_PIRQC}}, 0x3, 0x0}, /* slot3 */ - {0x00,(0x0B<<3)|0x0, {{L_PIRQA, M_PIRQA}, {L_PIRQB, M_PIRQB}, {L_PIRQC, M_PIRQC}, {L_PIRQD, M_PIRQD}}, 0x4, 0x0}, /* slot4 */ - } + PIRQ_SIGNATURE, /* u32 signature */ + PIRQ_VERSION, /* u16 version */ + 32+16*9, /* There can be total 9 devices on the bus */ + 0x00, /* Where the interrupt router lies (bus) */ + (0x0f<<3)|0x0, /* Where the interrupt router lies (dev) */ + 0, /* IRQs devoted exclusively to PCI usage */ + 0x100b, /* Vendor */ + 0x2b, /* Device */ + 0, /* Crap (miniport) */ + { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, /* u8 rfu[11] */ + 0xe, /* u8 checksum. This has to be set to some + value that would give 0 after the sum of all + bytes for this structure (including checksum) */ + { + /* bus, dev|fn, {link, bitmap}, {link, bitmap}, {link, bitmap}, {link, bitmap}, slot, rfu */ + {0x00,(0x01<<3)|0x0, {{0x01, 0x0400}, {0x00, 0x0000}, {0x00, 0x0000}, {0x00, 0x00000}}, 0x0, 0x0}, + {0x00,(0x0f<<3)|0x0, {{0x01, 0x0400}, {0x02, 0x0800}, {0x03, 0x0400}, {0x04, 0x00800}}, 0x0, 0x0}, + {0x00,(0x13<<3)|0x0, {{0x01, 0x0400}, {0x00, 0x0000}, {0x00, 0x0000}, {0x00, 0x00000}}, 0x0, 0x0}, + {0x00,(0x12<<3)|0x0, {{0x03, 0x0400}, {0x00, 0x0000}, {0x00, 0x0000}, {0x00, 0x00000}}, 0x0, 0x0}, + {0x00,(0x11<<3)|0x0, {{0x01, 0x0400}, {0x02, 0x0800}, {0x00, 0x0000}, {0x00, 0x00000}}, 0x0, 0x0}, + {0x00,(0x0a<<3)|0x0, {{0x01, 0x0400}, {0x02, 0x0800}, {0x03, 0x0400}, {0x04, 0x00800}}, 0x1, 0x0}, + {0x00,(0x0b<<3)|0x0, {{0x02, 0x0800}, {0x03, 0x0400}, {0x04, 0x0800}, {0x01, 0x00400}}, 0x2, 0x0}, + {0x00,(0x0c<<3)|0x0, {{0x03, 0x0400}, {0x04, 0x0800}, {0x01, 0x0400}, {0x02, 0x00800}}, 0x3, 0x0}, + {0x00,(0x0d<<3)|0x0, {{0x04, 0x0800}, {0x01, 0x0400}, {0x02, 0x0800}, {0x03, 0x00400}}, 0x4, 0x0}, + } }; - unsigned long write_pirq_routing_table(unsigned long addr){ int i, j, k, num_entries; unsigned int pirq[4]; @@ -140,7 +81,7 @@ /* Set up chipset IRQ steering */ pciAddr = 0x80000000 | (CHIPSET_DEV_NUM << 11) | 0x5C; - chipset_irq_map = (PIRQD << 12 | PIRQC << 8 | PIRQB << 4 | PIRQA); + chipset_irq_map = (11 << 12 | 10 << 8 | 11 << 4 | 10); printk_debug("%s(%08X, %04X)\n", __FUNCTION__, pciAddr, chipset_irq_map); outl(pciAddr & ~3, 0xCF8); outl(chipset_irq_map, 0xCFC); @@ -162,4 +103,5 @@ /* put the PIR table in memory and checksum */ return pirtable_end; -} \ No newline at end of file +} +

1 0

[LinuxBIOS] patch irq_tables.c for digital logic msm800sev
by ron minnich 08 May '07

08 May '07

Patch attached. It includes a new irq table, and a correct setting for the 5c register in the superio so that interrupts are routed correctly. With this patch, ethernet works quite well. Signed-off-by: Ronald G. Minnich <rminnich(a)gmail.com>

2 1

[LinuxBIOS] winflashrom architecture (Windows port of flashrom) -- looking for suggestions
by Darmawan Salihun 08 May '07

08 May '07

Hi all, I'm currently working on a windows port of the flashrom utility. I have been thinking about how it should be done. There are two paradigm that I'm thinking about as of now. I need your suggestions/critics, etc. ;-). Both of them based on the fact that this utility should be divided into user mode code and kernel mode code. 1. The kernel mode code a.k.a kernel mode device driver is as simple as possible and only provides "raw" functionality, i.e. capability to map the physical address space in which the BIOS chip is mapped into the requesting user mode code. This approach provides the user mode code similar to mmap() function in *NIX. The pros in this approach is there won't be much changes to the *NIX version of flashrom to adapt it to windows and it will be a little easier to develop because no need to load/unload the driver. The cons is if the user mode code went wrong, it can bring the whole system down. I've been experimenting with a minor tested version for this approach though. 2. The kernel mode driver implements the majority of the flashrom code and the usermode code is merely a "front-end" to the kernel mode device driver which provides all of the chip related logic. The pros in this approach is the code would probably much stable because the user mode code won't bring the system down as easily as the previous approach. The cons is it will very probably requires more work to port the *NIX version of flashrom to Windows with this approach and more over, I haven't been able to figure out how to do integrity-testing to the driver to ensure its stability :-(. Anyway, I'm also thinking about a quite "universal" interface between the user mode code and the kernel mode code. Perhaps a well defined interface that will work both in *NIX and Windows in the future will be needed or maybe I will try to provide an "evolution path" to such an interface. I really need suggestion in this area. --Darmawan

5 13

[LinuxBIOS] CAR for Geode GX1 / GX2
by Uwe Hermann 08 May '07

08 May '07

Hi, is anybody working on a Cache-as-RAM implementation for the GX1 and GX2? Or does the LX code work for those, too? If not, how much work would it be to port that code? Thanks, Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org

6 10

[LinuxBIOS] A very good idea
by MARTIN WOODHOUSE 08 May '07

08 May '07

Yestereday Jordan wrotee > On Thu, May 03, 2007 at 05:55:39PM -0400, Jim Gettys wrote: > > Mitch wrote a fast path resume from RAM for the OLPC Geode > > hardware. > > The fastest path is obviously attractive also in LinuxBIOS. > > > > Once you've done that, you find that you've done just about > > everything to initialize the hardware in the first place; so that > > code is now used both at boot time and at suspend from RAM time. > > This is an interesting observation. > > > Perhaps all chip init would best be written in some macro language? > (one specific for the task?) > How much intelligence is actually needed to abstract the hardware > enough for any system to be initialized? C is obviously not useful > for an embedded system that could just write a table of registers > into hardware. > > I guess it's the old code reuse idea. > > Perhaps I just reinvented OpenFirmware? And the v3 dts. ------------------ From Martin Too right. This is one of those ideas which is thrown off kind of light-heartedly but is actually crucual. (a) Of all the posts here, I'd guess that more than half (to my inexpert and untutored eye) are about initiialising this processor/RAM chunk/other piece of hardware or that one. (b) My young (12-year-old) friend is leaning to program in that variety of C that's around now, what's its name can't remember? but anyway, he's written < Hello Word > of course, and it starts with more than a page of <inits> before we get down to the couple of lines of code which actually put "Hello World" in a nice little box on the screen : (c) Even when I was writing in Borland C all those years ago, the same was true (only not quite as badly as it is now, since we didn't have a huge variety of components to deal with.). ------ So, yes, of course we should have a separate, small macro langage for initialising chunks of hardware, it would only take half an hour to learn it; and yes, every component manufacturer should agree on this same maro language and simply make available the necessary sequence of macros for every piece of hardware they make, so the prgram writers can just slam it into the front of any chunk of software they're constructing. I know that to somo extent this happens already, but I don't think it goes nearly far enough, to judge by the sequences of posts I see here discussing how to use one peice of hardware or another? ---- What should happen ---- it seems to my ancient mind --- is that the programmer should merely write a series of in a form such as : processor=xxxxx primaryRAM= yyyyy videochip=zzzzz etc etc --- and so forth, for whatever components are known to have the need to be handled, -- and the COMPILER then automatically inserts the necessary sequence(s) of macros known to be needed to "initialise" xxxxx, yyyyy and zzzzz, whatever they are? Could this not work? What are the possible snags? Of course everybody would have to agree upon, and learn, and then use, the same macro language, but I don't see that as insuperable? OK, it's another piece of stuff to learn, but we have to do that all the time, and this particular piece would save a whole lot of other learning. Maybe we should ask old Linus to put it together? Cheers, Martin

7 16

[LinuxBIOS] set fiv fail
by AlexHuang 08 May '07

08 May '07

Hi all, I got an error message from linuxbios as below: The CPU on my platform is Sempron. Why do I get “set fid failed for apicid =00” and how to solve this issue?? On the other hand, I got error message as follow: Ram2.00 No memory for this cpu I have no idea how to solve this issue. Can somebody give me a suggestion how to find the bug out?? Thanks for your help Alex LinuxBIOS-1.1.8_m57sli_Fallback 一 16:26:52 CST 2007 starting... *sysinfo range: [000cf000,000cf730) bsp_apicid=00 core0 started: started ap apicid: 01 SBLink=00 NC node|link=00 begin msr fid, vid 31061212060e0202 set fid failed for apicid =00 end msr fid, vid 31061206060e0202 mcp55_num:00 ht reset - SMBus controller enabled Ram1.00 Ram2.00 No memory for this cpu Ram3 No memory

4 6

[LinuxBIOS] Naming of target for IGEL Winnet III thin client
by Uwe Hermann 07 May '07

07 May '07

Hi, I'm working on supporting a new Geode GX1 target, and I'm not sure where to put it and how to name it. The device is an old IGEL WinNET III thin client (http://www.igel.com/), I've got mine from eBay for <= 30 bucks. The board seems to be called MB-5BLMP, but I don't know the "real" vendor, and I can't find a vendor name on the PCB itself. Possible values: - Aquarius Systems (ASI) http://www.memoryx.net/aqsymbmome7.html - BCom: http://www.andovercg.com/Desktop/BCom/BCom-Thin_Client-17497.shtml ASI is now BCom as far as I can tell, but I'm not sure. IGEL is probably sort of a "reseller", using the mainboard(s) produced by ASI/BCom(?) So, where should the code go? - src/mainboard/asi/5blmp - src/mainboard/bcom/5blmp - src/mainboard/igel/5blmp - any of the above but xxxx/mb-5blmp - any of the above but xxxx/mb_5blmp - src/mainboard/igel/winnet3 Other locations? Opinions? Do we categorize by vendor/mainboardname or vendor/productname (i.e., 5blmp vs. winnet3)? Thanks, Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org

3 2

← Newer
1
...
32
33
34
35
36
37
38
...
44
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 May 2007