"You'd need to know the confidential information about the chips to write"
a free BIOS, Insyde Software's Joseph said. Right now, "that info is only
available on old hardware that nobody really cares about anymore."
garsh, didn't know that opterons are so obsolete. It's amazing how much
lack-of-clue there is out there masquerading as knowledge.
* Huang-Jen Wang <huangjen.wang(a)gmail.com> [050412 10:46]:
> Hi Stefan,
> The message as follow:
> setup_timers: CPU 2005 MHz
> pci_init: Scanning PCI: found 4 devices
> malloc_diag: alloc: 184 bytes (4 blocks), free: 16192 bytes (1 blocks)
> pci_init: 00:18.0 1022:1100 0600 00
> pci_init: 00:18.1 1022:1101 0600 00
> pci_init: 00:18.2 1022:1102 0600 00
> pci_init: 00:18.3 1022:1103 0600 00
> Press <Enter> for default boot, or <Esc> for boot prompt... timed out
> boot: hda2:/boot/vmlinuz root=/dev/hda2 console=tty0 console=ttyS0,115200
> malloc_diag: alloc: 264 bytes (5 blocks), free: 16112 bytes (1 blocks)
> malloc_diag: alloc: 280 bytes (6 blocks), free: 16096 bytes (1 blocks)
> file_open: dev=hda2, path=/boot/vmlinuz
> find_ide_controller: PCI IDE #0 not found
> IDE channel 0 not found
> devopen: failed to open ide
The IDE controller is not detected. Did you set PCI_BRUTE_SCAN = 1
in the filo config file?
I am busy doing a port of the Geode code to V2, and am running into
difficulty with the RAM sizing. The issue is not the RAM sizing itself, but
the behaviour of romcc.
I have not looked into romcc in any depth at all, but am guessing that my
problem results either from the declaration of too many variables or nesting
function calls too deeply.
Are there any guidelines as to variable usage and function call nesting, and
will romcc give any warning messages when all the registers are used up?
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.308 / Virus Database: 266.9.5 - Release Date: 07.04.2005
I'm considering a mainboard that has a via C3 cpu and uses a chipset
comprised of a via CLE266 and a via VT8235; it uses ddr266 and has
integrated via 2 channel audio, 10/100 lan and UniChrome vga (64M shared
mamory). I'm hoping that since this is almost identical to an epia-m board,
the epia linux bios should work "as is". Is that correct? If I got a
working image from someone, would the odds be good that it would work on
> Ramesh, I saw in one of your posts that you had
> mentioned willingness to
> start working on this - if you have started, maybe
> we could work together on
Definitely, I'd be happy to work with you on the V2
conversion. I haven't done anything on V2 yet. Maybe
I'll go do a V2 build sometime this weekend and get a
feel for how things are laid out there.
Show us what our next emoticon should look like. Join the fun.
I am trying to understand the "linka, linkb, linkc, linkd" part of this table. I understand the rest of the table, just not those pieces. Can someone give me a brief explanation? Thank you for your time.
Peter Van Echaute
Email: Peter.VanEchaute(a)bench.com <mailto:Peter.VanEchaute@bench.com>
On Thu, 31 Mar 2005, ramesh bios wrote:
> Well, I got things to work in the end by copying the
> standard bios's CR bit settings for the W83977AF.
> Regretably though, I have gained no understanding of
> why or how it's working. Amazingly, the standard bios
> sets CR30 on the W83977AF, ie: the RTC enable/disable
> bit to disabled. So the RTC appears to increment
> properly when that bit is disabled (which makes no
> sense to me at all, ie: disable the RTC and it ticks
> properly?). When that bit is enabled, and no other
> changes, the RTC has weird incrementation behavior.
> Almost seemed like random bits in mm:ss were changing.
> Also, I never understood why bytes in 0E-7F, the user
> ram changes during normal ticking of the clock. Oh
> well, it's working now so I guess I'll just push this
> mystery to the back of my mind. If anyone happens to
> understand this stuff, I'll sleep better once I've
> understood this.
> --- ramesh bios <ramesh_bios(a)yahoo.com> wrote:
>> I was looking through linuxbios' freebios (v1) code
>> and see the following:
>> then finally
>> I looked in 2.6.11's mc146818 code and I don't see
>> writing a checksum so I'm not certain it's valid to
>> check for a checksum on boot since stuff like
>> may/would have written to the cmos during normal
>> operation. Out of curiosity, how come there is a LB
>> checksum and then a PC checksum and then we write a
>> checksum at the end. Is it for legacy compatibility,
>> didn't find any mention of it in the mailing list
The @clustermatic.org mail address is not to be used anymore.
If anyone knows anything about the above question please put this in the
Here's another update of the glossary of acronyms I've found on this list
(and other's). Unfortunately it is quite hard (sometimes impossible) to
dig up information about the acronym/definition on the internet (I'm
planning to buy that book that someone recommended on this list) so some
info is marked with '???'. If anyone wants to update that feel free to do
so, it is much appreciated. I've attached a tar-ball containing the
original glossary, a diff, and the updated glossary to hopefully make it
easier (?) to update the wiki. Some info may or may not be relevant (I'm
on ivtv, v4l, mesa, xorg, gentoo-users, linux-from-scratch, unichrome,
opengfx amongst other mail-lists so I pick up a few things)...