coreboot

coreboot@coreboot.org

6 participants
39707 discussions

brun_mtd
by Xavier Pegenaute 22 May '03

22 May '03

Hello, In the script of src/util/mtd/burn_mtd there are these lines .. - dd conv=notrunc conv=sync bs=65536 if=${linux} of=vmlinux.bin.gz.block With this we if exist we don't trunc and fix the size of vmlinux.bin.gz.block, if it's more smaller than 65536 we put 0 until this size. - dd conv=notrunc conv=sync bs=63k if=${linuxbios} of=linuxbios.block The same but with 63k. - dd conv=notrunc if=docipl of=/dev/mtd0 We write without trunc /dev/mtd0 with the source of docipl. - dd conv=notrunc if=docipl of=/dev/mtd0 seek=1 The same but this time we skip 1 block of "bs" (i supose that we can remind the value of bs in the last line, then sizeof(docipl) ). - dd conv=notrunc if=linuxbios.block of=/dev/mtd0 seek=2 Without trunc we write linuxbios.block to mtd, skipping 2 times the last size (sizeof(docipl) ). - dd conv=notrunc if=vmlinux.bin.gz.block of=/dev/mtd0 seek=128 Now without trunc write vmlinux skipping 128 times the size of linuxbios.block. My questions, are: Why we write two times docipl ? And why we skip 128 times the size of linuxbios.block ? (i supose that i'm wrong, any one can help me with these) Thanks a lot for your patience. Xavi.

3 5

Passes RAM test, but hangs at jumping to RAM
by SONE Takeshi 22 May '03

22 May '03

What could be a problem when it passes RAM test but hangs immediately after jumping to RAM? I'm developing a new raminit code and this happens only with a particular installation of DIMM. DIMM itself is not bad, it works when move to another slot, or another slot is filled with another DIMM. Award BIOS runs just fine with this DIMM installation. LinuxBIOS-1.0.0 Thu May 15 07:27:04 JST 2003 starting... Enabled first bank of RAM: 0x10000000 bytes Testing SDRAM : 00000000-0009ffff SDRAM fill: 0009ffff SDRAM verify: 0009ffff Done. Testing SDRAM : 00100000-01000000 SDRAM fill: 01000000 SDRAM verify: 01000000 Done. Copying LinuxBIOS to ram. Jumping to LinuxBIOS. (hangs up here) -- Takeshi

5 10

AMD Sledge Hammer
by Andrew Ip 21 May '03

21 May '03

Does anyone know what is the statue of AMD Hammer? I have seen it in freebios2, but would like to know how far it is from being stable? Thanks. -Andrew -- Andrew Ip Email: aip(a)cwlinux.com Tel: (852) 2542 2046 Fax: (852) 2542 2036 Mobile: (852) 9201 9866 Cwlinux Limited Unit 202B 2/F Lai Cheong Factory Building, 479-479A Castle Peak Road, Lai Chi Kok, Kowloon, Hong Kong. Tel: (852)2542 2046 Fax: (852)2542 2036 For public pgp key, please obtain it from http://www.keyserver.net/en.

3 2

ADLO
by Xavier Pegenaute 21 May '03

21 May '03

Hi, i want to try with ADLO, but at the moment i can't find MS7308E, i think that may be i can find this motherboard MS7308ET, but use a different chipset SIS630ET any one tryed with this one ? Thanks. Xavi.

2 2

Geode Video Xfree86 and VSA
by Bari Ari 21 May '03

21 May '03

Anyone know the current status of running XFree86 on the Geodes? I'm currently looking at working on getting the VSA running on the Geodes as a BLOB. Anyone else started on this yet? --Bari

2 3

Re: debugger
by jarcher＠pobox.com 21 May '03

21 May '03

I'm going to look at doing that over the next week or so. Jordan At 10:17 AM 5/21/2003 +0800, ollie lho wrote: >On Fri, 2003-05-16 at 22:27, ron minnich wrote: > > On Thu, 15 May 2003, jarcher wrote: > > > > > It might be helpful in debugging the stuff that get loaded after the > core > > > BIOS runs. > > > > I mostly saw it as a useful learning tool for people trying to follow the > > code. > >Can we make the gdb stub reuseable as linuxbios_table or ELF loader >stuff ? In this way, both LinuxBIOS and the payload (BLOB ?) can be >debugged. > >-- >ollie lho <ollie(a)sis.com.tw>

1 0

VIA Eden BIOS interchangeable?
by Rene Caspari 21 May '03

21 May '03

Hi, i want to buy a VIA Epia V5000 Motherboard. Do you know wether i can use this board to install another BIOS-Chip and finally install Linuxbios? Thx, rene -- /* Ich hab mein Leben lang gehorcht. (Stengel über Mielke) */ /* http://www.reca.ahrcas.net */ /* remove 'spam': reca@'spam'ahrcas.net */

2 1

How to get technical information?
by Peter Busser 20 May '03

20 May '03

Hi! I'm sorry if this is a FAQ... How does one get technical information from chipset manufacturers? I have searched the SiS and VIA web sites and found no documentation or pointers to documentation whatsoever. Or am I simply not looking well enough? Groetjes, Peter Busser

4 4

getpir utility for creation of irq tables.c doubt ?
by dkotian3＠vsnl.net 20 May '03

20 May '03

Hi, My lspci O/P is as below, which seems to have 6 slots, 4 on bus 0 and 2 on bus 1. I hope this interpretation is correct. ****lspci O/P***** 00:00.0 Host bridge: Intel Corporation 82810E GMCH [Graphics Memory Controller Hub] (rev 03) 00:01.0 VGA compatible controller: Intel Corporation 82810E CGC [Chipset Graphics Controller] (rev 03) 00:1e.0 PCI bridge: Intel Corporation 82801AA 82810 PCI Bridge (rev 02) 00:1f.0 ISA bridge: Intel Corporation 82801AA 82810 Chipset ISA Bridge (LPC) (rev 02) 00:1f.1 IDE interface: Intel Corporation 82801AA 82810 Chipset IDE (rev 02) 00:1f.2 USB Controller: Intel Corporation 82801AA 82810 Chipset USB (rev 02) 00:1f.3 SMBus: Intel Corporation 82801AA 82810 Chipset SMBus (rev 02) 01:04.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139 (rev 10) 01:05.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139 (rev 10) ****lspci O/P***** And the irq_tables.c O/P after getpir is as below : ****getpir O/P***** /* 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 , wich BIOS sets up Documentation at : http://www.microsoft.com/hwdev/busbios/PCIIRQ.HTM */ #include <arch/pirq_routing.h> const struct irq_routing_table intel_irq_routing_table = { PIRQ_SIGNATURE, /* u32 signature */ PIRQ_VERSION, /* u16 version */ 32+16*4, /* there can be total 4 devices on the bus */ 0, /* Where the interrupt router lies (bus) */ 0xf8, /* Where the interrupt router lies (dev) */ 0x1c00, /* IRQs devoted exclusively to PCI usage */ 0x8086, /* Vendor */ 0x7000, /* Device */ 0, /* Crap (miniport) */ { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, /* u8 rfu[11] */ 0xa9, /* u8 checksum , this hase to set to some value that would give 0 after the sum of all bytes for this structure (including checksum) */ { {0,0x80, {{0x61, 0xdeb8}, {0x62, 0xdeb8}, {0x63, 0xdeb8}, {0x60, 0xdeb8}}, 0x2, 0}, {0,0x8, {{0x60, 0xdeb8}, {0x61, 0xdeb8}, {0x62, 0xdeb8}, {0x63, 0xdeb8}}, 0, 0}, {0,0xf9, {{0x60, 0xdeb8}, {0x61, 0xdeb8}, {0x62, 0xdeb8}, {0x63, 0xdeb8}}, 0, 0}, {0x40,0, {{0, 0}, {0, 0}, {0, 0}, {0, 0}}, 0, 0}, } }; ****getpir O/P***** It does not seem to list the details of the bus 1 for ethernet controller. Any suggestions. Regards Deepak

4 5

Re: config language
by jarcher＠pobox.com 20 May '03

20 May '03

The meaning may be just as clear. But I would argue that it's not as easy for the eye to read. And "altimus/mpc7500" is closer to the environment you are actually trying to debug. It's an include file at the path altimus/mpc7500. Jordan At 10:45 AM 5/20/2003 -0400, Bob Drzyzgula wrote: >On Tue, May 20, 2003 at 07:56:59AM -0600, Greg Watson wrote: > > > > Hi Bob, > > > > The config language does lend itself to XML, (and it was my first > > thought when Ron suggested a new languge) but I would recommend > > against it for a couple of reasons. The first is that the language > > needs to serve the dual purpose of specifying *and documenting* a > > particular configuration. XML is great for the former, but is almost > > impossible to read easily, particularly for people not used to > > working with it. Sure, you could then add something that converts the > > XML into a more readable document, but then what is a simple idea is > > now becoming very complicated. Secondly, and more importantly, is > > that it would mean that LB relies on the existence of an extremely > > complex external component, that is out of the control of the LB > > community (be it pyRXP, libXML, or whatever). Arguably this is > > already the case, since the configuration process uses python, but if > > we adopt a new configuration language then the parser can be included > > as part of the distribution - making it effectively self-contained. > > So in my view the limitations of using XML outweigh any advantages > > that might be obtained. > > > > Regards, > > > > Greg > >Greg, > >Y'know, it's *OK* to say "I just don't like it". :-) >I know if Ron & y'all don't *want* to do it it won't >get done, which is, again, *OK*. :-) > >But understanding that I don't seriously expect this >to happen in LB, I do sort of want to respin a >couple of your points... > >It's interesting what you say about documentation, because >one of the oft-cited primary advantages of XML is that >it is self-documenting. Perhaps it takes some getting used >to but in the end the meaning of: > > <pmc vendor="altimus" model="mpc7500"> > >has got to be at least as clear as > > pmc altimus/mpc7500 > >even if it is a bit more longer. > >Beyond this, the formal specification for an XML document >is in the DTD (or schema): an overt, external data file >that all code can reference. With a config file of the >sort that LB has had thus far, the real specification is >embedded in the parser source code, perhaps supplemented >by usage notes. Thus it is fairly easy for disconnects to >occur not only between the implmentation and the user's >understanding thereof, but between the written, external >documentation and the implementation. > >The reliance on an external library is, I would think, >something of a red herring. As you point out, there are >myriad external libraries that are being relied upon. A >yacc/lex implementation relies on the implementation of >yacc & lex and all the lexical arcania that come with >them. Ron suggested YAPP, which relies on the YAPP >project. In the case of PyRXP, that whole thing is GPL'd, >so if the project wanted, a version of PyRXP could be >frozen into the LB CVS tree. Granted, that could mean >fixing it if it turns out to be broken, but that's a >separate issue from the one you cited, and is probably not >a significantly greater a risk than exists with many >other parser generators that could be chosen. > >The one other thing I'll add is that, while existing LB >developers may not be well-versed in XML, the fact is that, >industry-wide, XML literacy is growing if not exploding. In >the long term, finding people who understand and can work >with XML will be no harder, and probably easier, than >finding people who can program in C. A custom configuration >language, and the code to implement it, will be novel to >everyone who encounters it, now and forever. > >Just my $0.02. > >--Bob >_______________________________________________ >Linuxbios mailing list >Linuxbios(a)clustermatic.org >http://www.clustermatic.org/mailman/listinfo/linuxbios

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot