On 1/11/08, Peter Stuge <[EMAIL PROTECTED]> wrote:
> Linux make help does not seem to have a target that combines
> oldconfig and defconfig in the desired way. :\
FWIW, Red Hat patches the kernel to achieve this:
# This patch adds a "make nonint_oldconfig" which is non-interactive and
# also give
On 1/10/08, Marc Karasek <[EMAIL PROTECTED]> wrote:
> So with the -gt change is this patch ok to go?
>
> I will have some more time (maybe) next week to track down further the
> id.lds problem.
I would prefer to see id.lds left as is, with the workaround code
perhaps included in a comment or #if 0
On 1/6/08, Feng, Libo <[EMAIL PROTECTED]> wrote:
> In PCI, the IDSEL pin defines the device number. But in PCIe, there is no
> such pin, how is the device number defined?
"Each PCI Express Link is equivalent to a logical PCI bus. In other
words, each Link is assigned a bus number by the bus enumer
On 1/7/08, Myles Watson <[EMAIL PROTECTED]> wrote:
> Sorry to be picky, but it seems like this breaks if they mention
> build-id more than once in the help in the future. I think >0 would
> be better than ==1.
Using grep instead of awk would address this issue, and is a bit
simpler (see attached)
On 1/4/08, Marc Karasek <[EMAIL PROTECTED]> wrote:
> I made a test script and ran it and it sets build_id = 1 properly. I
> have also included this script.
The problem is that on Planet Bourne, zero means true and nonzero means false.
--Ed
--
linuxbios mailing list
linuxbios@linuxbios.org
http
On 1/4/08, Marc Karasek <[EMAIL PROTECTED]> wrote:
> Ed sorry for the duplicate, but I only originally replied to you.
>
> I will take a look at it. When I ran it it did add the option on my
> system. The only question I had was for an older ld version would it
> behave properly.
Try running t
On 1/3/08, Marc Karasek <[EMAIL PROTECTED]> wrote:
> Here is the patch with the ld option check as well.
>
> I had to make a few changes to Ron's original patch. One of the problems
> was that CFLAGS was being set as a := in the Makefile and was overwriting
> the += that was in Makefile.settings.
Err...
Signed-off-by: Ed Swierk <[EMAIL PROTECTED]>
On 12/27/07, Ed Swierk <[EMAIL PROTECTED]> wrote:
> Here is an updated patch against the latest snapshot. I fixed a bunch
> of bugs and verified that SATA, PCI slot, and PCI Express (port A)
> slot are working.
--
l
On 12/27/07, Carl-Daniel Hailfinger <[EMAIL PROTECTED]> wrote:
> It seems that your code still depends on ROMCC. Do you see any chance to
> switch to CAR for initialization? I have some CAR fixes pending for
> Intel chips which should fix some problems of that code.
The CAR stuff is still a bit of
Here is another attempt that does not rely on the --build-id option,
incorporating Marc's workaround in src/arch/i386/lib/id.lds for the
.id allocation issue.
--Ed
linuxbios-ld-build-id.patch
Description: Binary data
--
linuxbios mailing list
linuxbios@linuxbios.org
http://www.linuxbios.org/mai
On 12/7/07, Uwe Hermann <[EMAIL PROTECTED]> wrote:
> We should make sure this doesn't break any other distros / compiler
> versions. Do all reasonably new gcc/ld versions know about '--build-id'?
The Fedora Core 6 version of ld (2.17.50.0.6-5.fc6) doesn't support
it. Not sure if that qualifies as
On 12/3/07, Marc Karasek <[EMAIL PROTECTED]> wrote:
> Looks to me like the none option does not turn it off but only clears
> any prior options set on the command line.
If you look at the ld command line (by adding -v to the gcc command
line) you will see that gcc adds the --build-id option. So
--
On 12/3/07, Marc Karasek <[EMAIL PROTECTED]> wrote:
> So this does not look like a ld problem, but an added feature to ld is
> causing us grief. If anyone can figure out how to turn this option off,
> that may fix all of this without any patches... :-)
Passing -Wl,--build-id=none to gcc turns off
On 12/3/07, Jordan Crouse <[EMAIL PROTECTED]> wrote:
> Can we get a Signed-off-by: line for this patch? It seems sane enough to
> me.
Signed-off-by: Ed Swierk <[EMAIL PROTECTED]>
linuxbios-ld-build-id.patch
Description: Binary data
--
linuxbios mailing list
linuxbios@
On 12/3/07, Marc Karasek <[EMAIL PROTECTED]> wrote:
> Thanks for the patch.
>
> Tried it and it still crashes, but at least now it gives more info. I will
> look into this from this end and see what is happening.
I'm stuck on the same problem here (on Fedora 8), so please share any
discoveries.
On 11/30/07, Marc Karasek <[EMAIL PROTECTED]> wrote:
> When I try to compile v2 with a filo.elf payload I get the :
>
> collect2: ld terminated with signal 11 [Segmentation fault]
>
> Error
The attached patch works around a crash from GNU ld version
2.17.50.0.18-1 20070731.
--Ed
linuxbios-ld-bu
I'm having trouble building emulation/qemu-i386 in the latest
LinuxBIOSv2 snapshot on Fedora 8 (GNU ld version 2.17.50.0.18-1
20070731, gcc version 4.1.2 20070925 (Red Hat 4.1.2-33).
First, ld segfaults unless I apply the attached patch. That one was
fun to figure out :-)
Now, ld is unable to fin
I have an RD1-PMC4 (4 Mbit FWH/LPC) BIOS Savior that I no longer need.
I would be happy to ship it to anyone who can find a use for it for
LinuxBIOS work.
--Ed
--
linuxbios mailing list
linuxbios@linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios
Signed-off-by: Ed Swierk <[EMAIL PROTECTED]>
--Ed
linuxbios-300-flashrom-bug.patch
Description: Binary data
--
linuxbios mailing list
linuxbios@linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios
On 8/12/07, Stefan Reinauer <[EMAIL PROTECTED]> wrote:
> Or remove the restore? The code only restores for the case that there is
> no 28sf040 anyways...?
Makes sense to me :-)
--Ed
--
linuxbios mailing list
linuxbios@linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios
We've been using flashrom quite successfully for months to program an
SST49LF160C chip, but today we came across one flash image that
flashrom kept failing to verify after writing it.
When we dumped the contents of the flash after the verify, we saw that
one byte at offset 0x1e was getting cha
On 8/1/07, Carl-Daniel Hailfinger <[EMAIL PROTECTED]> wrote:
> Hi,
>
> > static int enable_flash_mcp55(struct pci_dev *dev, char *name)
> > {
> > unsigned char old, new, byte;
> > unsigned short word;
> >
> > /* Set the 4MB enable bit bit */
> wrong comment, probably copy-pa
I couldn't get the 016C to work on an LPC board (nVidia MCP55). The 160C works
fine.
--Ed
- Original Message -
From: "Jeremy Jackson" <[EMAIL PROTECTED]>
To: linuxbios@linuxbios.org
Sent: Tuesday, May 15, 2007 8:26:42 PM (GMT-0800) America/Los_Angeles
Subject: [LinuxBIOS] are SST49LF016
On Monday 14 May 2007 10:20:10 ron minnich wrote:
> one interesting thing: the BIOS costs are one reason that x86 has had
> trouble getting acceptance in the embedded space, i am told (by
> embedded systems vendors).
Another problem is that there's no x86 hardware to be accepted, at least in
cert
On 3/20/07, Lu, Yinghai <[EMAIL PROTECTED]> wrote:
> Only Opteron supports ECC.
I hope that's not true, otherwise AMD needs to change their datasheet
for the Athlon 64 X2:
http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/33425.pdf
> About mem training
> 0: BSP will train m
I'm able to boot Linux just fine on my MCP55-based board with non-ECC
memory, but when I install ECC DIMMs I get a Machine Check Exception
from Linux about half the time:
CPU 0: Machine Check Exception: 0004
Bank 4: f6302001d8080813 at 021fbd60
Kernel panic - not syncing:
On 3/19/07, Ward Vandewege <[EMAIL PROTECTED]> wrote:
> Awesome - that works just fine for the M57SLI-S4. Still a lot of warnings,
> but the code builds, and it boots the system just fine!
That's good enough for me!
Signed-off-by: Ed Swierk <[EMAIL PROTECTED]>
--Ed
--
On 3/19/07, Ward Vandewege <[EMAIL PROTECTED]> wrote:
> Same here - I'd like to start working from the mainline tree. Uwe or Stefan,
> any thoughts on what's still missing? I know it's the USB debug stuff, but
> there
> seem to be some other problems too - I just tried disabling the USB debug
> fu
Is there a patch with the remaining bits of Yinghai's MCP55 patch? I'm
bringing up an MCP55 board and this would be a good opportunity to try
to get the code working.
--Ed
--
linuxbios mailing list
linuxbios@linuxbios.org
http://www.openbios.org/mailman/listinfo/linuxbios
After staring at the code for a while I realized that I wasn't mapping
the GPIO registers into IO space properly. (I'm still using the ck804
code with a bunch of hacks, as I haven't had time to integrate the
mcp55 support, but there are indeed some important differences :-)
I changed ck804_early_s
On 3/13/07, Peter Stuge <[EMAIL PROTECTED]> wrote:
> Let a logic analyzer trigger on special read sequences on a suitable
> bus.
So far we're just using a scope with too few channels; a logic
analyzer would be pretty useful. Our plan for tomorrow is to write
special values on the LPC bus, as they
I'm trying to get LinuxBIOS booting on a custom board with a Socket
AM2 Athlon and an MCP55. There is no SuperIO; instead, we're using the
MCP55's internal serial UART. A couple of the MCP55's GPIO pins are
hooked up to LEDs.
I have had no luck getting either the serial port or the LEDs to work,
t
Can someone ack this patch if it looks okay?
--Ed
-- Forwarded message --
From: Ed Swierk <[EMAIL PROTECTED]>
Date: Feb 14, 2007 10:41 AM
Subject: [PATCH] Additional MCP55 LPC PCI IDs for flashrom
To: LinuxBIOS
The attached patch adds additional PCI IDs for MCP55 LPC d
On 2/28/07, Ward Vandewege <[EMAIL PROTECTED]> wrote:
> So, you've verified that the image that flashrom reads matches what you can
> download from the manufacturers website (extracted)?
>
> Flashrom doesn't crash or anything here, and it might just *write* fine (not
> tested yet), but reading give
0367
> for the MCP55.
>
> I also saw a patch from Ed Swierk a couple of weeks ago, which added a whole
> bunch of PCI ids for the MCP55 (among which the 0x0360), but was never
> applied to the tree.
>
> Can someone who knows the MCP55 have a look at the enable_flash_mcp55
&g
d to add #include to superio.c to get it to compile.
The modified patch is attached.
Signed-off-by: Ed Swierk <[EMAIL PROTECTED]>
--Ed
Index: LinuxBIOSv2-2520/src/superio/ite/it8716f/it8716f_early_init.c
===
--- /dev/null
+++ Linux
On 2/16/07, Stefan Reinauer <[EMAIL PROTECTED]> wrote:
> I would generally say this is not a problem in LinuxBIOS but in the
> distribution. If building binaries using pciutils requires additional
> packages, they should be required by pciutils-devel.
I don't think we can blame Fedora--the flashro
On 2/15/07, Ed Swierk <[EMAIL PROTECTED]> wrote:
> OK, but as I said, the patches haven't received any testing, so I'm
> not asserting that they work.
I should add that the patch may well break mainboards that are
currently working, so caveat emptor.
On the other hand
Currently the flashrom Makefile tries to detect whether pciutils-devel
is installed, but the test also fails if zlib-devel is missing. This
patch changes the error message accordingly.
Signed-off-by: Ed Swierk <[EMAIL PROTECTED]>
--Ed
Index: LinuxBIOSv2-2552/util/flashrom/Ma
The attached patch adds additional PCI IDs for MCP55 LPC devices to
flashrom. 0x0360 is needed to support the DFI LANParty NF590SLI, and I
am deducing the others based on pci_ids.h in the Linux kernel. Perhaps
Yinghai can confirm that these are correct.
Signed-off-by: Ed Swierk <[EMAIL PROTEC
Here's a fix for the one warning we can all agree is a bug. We can
deal with the other issues separately.
Signed-off-by: Ed Swierk <[EMAIL PROTECTED]>
--Ed
Index: LinuxBIOSv2-2540/src/northbridge/amd/amdk8/
On 2/1/07, Carl-Daniel Hailfinger <[EMAIL PROTECTED]> wrote:
> The code says something different.
>
> static void delayx(uint8_t value) {
> int i;
> for(i=0;i<0x8000;i++) {
> outb(value, 0x80);
> }
> }
>
> The value is the POST code and has nothing to do with
On 2/1/07, Carl-Daniel Hailfinger <[EMAIL PROTECTED]> wrote:
> Hmmm. You know that the signedness of char is not defined?
Yes, but if functions like strlen() take a char *, then shouldn't the
parameter be signed rather than unsigned?
> Besides that, we definitely should enable -fno-strict-aliasin
_dqs.c are potential bugs.
gcc 4.1.x is famously paranoid about certain things, and some of its
warnings can only be considered compiler bugs, so I ignored those. The
minor warnings I fixed are mainly improper int/pointer casts and
unused variables.
Signed-off-by: Ed Swierk <[EMAIL PROTECTED]
On 1/31/07, Uwe Hermann <[EMAIL PROTECTED]> wrote:
I think you mean
Oops. Here's the same patch.
Signed-off-by: Ed Swierk <[EMAIL PROTECTED]>
--Ed
Index: LinuxBIOSv2-2539/src/include/device/pci_ids.h
===
---
On 1/31/07, Stefan Reinauer <[EMAIL PROTECTED]> wrote:
It's in. please go ahead.
Cool. Can you apply this patch next? It adds the MCP55 PCI IDs
(without which the southbridge code won't compile), and breaks an
unnecessary dependency on the usbdebug code.
Acked-by: Ed Swierk &
On 1/31/07, Uwe Hermann <[EMAIL PROTECTED]> wrote:
> Ping? Can anybody point out problems with the patch or ACK it? I believe
> it's ready to be committed now.
I'll give it a try today.
--Ed
--
linuxbios mailing list
linuxbios@linuxbios.org
http://www.openbios.org/mailman/listinfo/linuxbios
On 1/20/07, Uwe Hermann <[EMAIL PROTECTED]> wrote:
> great work Yinghai! Thanks a lot!
Yes, it's great to see some code finally getting released. My own code
is still stuck somewhere in nVidia legal limbo, but it's mainly a
subset of Yinghai's except for the particular mainboard (DFI LANParty)
sup
I googled around and read a bit about the OpenFirmware device tree,
but I'm still a bit clueless.
Can you briefly summarize the purpose of the OpenFirmware device tree?
How does/would Linux use the information in the tree? Does it replace
or supplement things like the MP table, IRQ routing table,
I hate to behave like a marketing droid, but sometimes this is the
only way to get attention:
Could anyone who is interested in running LinuxBIOS on an nVidia MCP55
(nForce 570/590) or other recent nVidia chipset please contact me with
the name of your organization and the contact name and email a
On 12/18/06, Carl-Daniel Hailfinger <[EMAIL PROTECTED]> wrote:
> Great! When will the code be released?
Well, we're now up to 2 different implementations of support for
nVidia MCP55 chipsets (Yinghai's and mine), both of which await the
blessing of nVidia's legal department, because they were deve
Has there been any effort in getting flashrom to work with the
SST49LF008C, SST49LF016C or SST49LF160C parts?
I'm no expert on flash programming, but the datasheets seem to
indicate that the programming mode currently used in sst_fwhub.c is
not supported on these chips (the SST49LF040B datasheet c
A few weeks ago I came across a set of books from MindShare, Inc. that
proved to be absolute lifesavers during my latest round of LinuxBIOS
hacking. It takes some careful reading to extract the bits that are
relevant to BIOS programming, but they go a long way towards
demystifying PCI device config
My latest attempt at MCP55 support can be found at
http://www-cs-students.stanford.edu/~eswierk/misc/linuxbios-dfi-lp_ut_nf590.patch
.
So far it's only been tested on the DFI LANParty UT NF590 motherboard,
booting Linux 2.6.19.
It obviously needs quite a bit of work, including:
- generalizing th
On 12/13/06, Ed Swierk <[EMAIL PROTECTED]> wrote:
> Now, after Linux says "Write protecting the kernel read-only data", it
> just hangs; the next thing it should do is run init.
Never mind; turns out my mptable was broken and timers weren't wired up.
USB and Ethernet a
On 12/12/06, Lu, Yinghai <[EMAIL PROTECTED]> wrote:
> You need to use 64 bit kernel if you enable pref64 in LinuxBIOS.
CONFIG_PCI_64BIT_PREF_MEM is 0, so it's not clear to me why Linux is
seeing the PCI_PREF_RANGE_TYPE_64 bit set in the configuration
registers of those bridges.
Perhaps the pref64
On 12/12/06, Lu, Yinghai <[EMAIL PROTECTED]> wrote:
> If still has problem
> 1.
> #make the SB HT chain on bus 0, default is not (0)
> #default SB_HT_CHAIN_ON_BUS0=1
> 2.
> Power off your target for a while. You may drive it nuts.
The patch didn't help, but commenting out SB_HT_CHAIN_ON_BUS0 did.
On 11/29/06, Lu, Yinghai <[EMAIL PROTECTED]> wrote:
> Too late.
Translation: LinuxBIOS cannot access the serial port on a PCI card
until late in the boot process, after initializing and scanning the
PCI bus. Only a serial port integrated into the mainboard chipset can
be initialized early enough t
On 11/28/06, Daniel Drake <[EMAIL PROTECTED]> wrote:
> I'm trying to get a RD1-PMC4 BIOS savior, but am having trouble finding
> places with it in stock. I even tried contacting the manufacturer and
> ordering one from Taiwan, but they don't have any available. They
> redirected us to various resel
On 11/19/06, Peter Stuge <[EMAIL PROTECTED]> wrote:
> Indeed. I'd like to also add the PCI ids though. Can anyone with
> such a board help?
The PCI ID for the MCP55 EHCI USB controller is 10de:036b; I've added
this to the EHCI Debug Port page.
As for motherboards, the DFI LANPARTY UT NF590 SLI-M2
On 10/24/06, yhlu <[EMAIL PROTECTED]> wrote:
> You will lose the revision history to the dir and files.
That's true if the patch were applied as is. I will split it into a
patch plus a sequence of svn move operations so that revision history
is preserved.
--Ed
--
linuxbios mailing list
linuxbio
I understand a number of folks besides me are working on porting
LinuxBIOS to mainboards based on the nVidia MCP55 chipset.
I thought I would post the work I've done so far on the DFI LANParty
UT NF590 mainboard in the hope that our efforts could merge sooner
rather than later:
http://www-cs-stud
On 10/7/06, Segher Boessenkool <[EMAIL PROTECTED]> wrote:
This table isn't needed, a UART stream is so slow that you can
just as well open-code the CRC algorithm and lose nothing (except
for 512 bytes of table :-) )
Good point. This patch replaces the table-driven CRC-16 implementation
with a c
Here's a new patch, hopefully addressing most of the feedback received so far.
I'm not thrilled with the amount of overlap between rom_stream.c and
serial_stream.c, but I tried to clean things up a bit in the latter.
If folks are happy with the changes, I can apply them to rom_stream.c
in another
The attached patch adds a new option, CONFIG_XMODEM_ROM_STREAM, that
allows LinuxBIOS to download its payload from the console via the
XMODEM file transfer protocol.
This is handy if you want to try out a payload that's too big to fit
into ROM, and you haven't yet gotten IDE or USB devices to wor
I'm working on porting LinuxBIOS to an AM2+MCP55-based mainboard (DFI
LANParty UT NF590) using the latest AMD Rev F and MCP55 southbridge
code from svn.
I replaced most of the CK804 PCI device IDs with their MCP55
counterparts, and put the following in my mainboard Config.lb:
chip northbridge/am
On 10/5/06, Lu, Yinghai <[EMAIL PROTECTED]> wrote:
> Then you should modify Config.lb in targets dir.
Can you be a bit more specific? It's not clear to me what is currently broken.
--Ed
--
linuxbios mailing list
linuxbios@linuxbios.org
http://www.openbios.org/mailman/listinfo/linuxbios
On 10/5/06, Lu, Yinghai <[EMAIL PROTECTED]> wrote:
> http://www.openbios.org/viewcvs/trunk/LinuxBIOSv2/src/mainboard/emulatio
> n/qemu-i386/Config.lb?r1=2127&r2=2402
>
> Ron modified.
That was a patch I submitted a few weeks back. As I said in the
accompanying email, I couldn't figure out the purp
Does "rev F" include the AM2-socket Athlon 64 X2?
I take it Serengeti refers to some internal AMD mainboard?
Thanks,
--Ed
--
linuxbios mailing list
linuxbios@linuxbios.org
http://www.openbios.org/mailman/listinfo/linuxbios
Hello,
I'm about to start getting LinuxBIOS to work on an nVidia MCP55-based
mainboard, and wonder whether other folks have already began work on
this chipset.
I haven't managed to get hold of any nVidia specs yet. Any clues how
to enable the serial port on the MCP55? Will it require some SMBus
d
On 9/17/06, Ramanathan <[EMAIL PROTECTED]> wrote:
> While trying to invoke qemu with the options as in the tutorial, again it
> fails.
>
>
>
> [EMAIL PROTECTED] ~]# qemu -L ~ -hda disk.img -nographic
> (qemu) Could not open '/dev/kqemu' - QEMU acceleration layer not activated
> qemu: could not lo
I've updated the qemu tutorial at
http://linuxbios.org/index.php/QEMU_Build_Tutorial .
I skipped over the steps I use to generate an initramfs with busybox
and kexec, instead pointing readers to kboot and OLPC buildrom. I can
write up my process if people think it wouldn't be redundant.
--Ed
--
On 9/13/06, Stefan Reinauer <[EMAIL PROTECTED]> wrote:
> Yes, please!
I'm happy to update the page directly if someone provides me with a
login. Otherwise I can email a diff, but I'm not sure what format to
use--raw HTML?
--Ed
--
linuxbios mailing list
linuxbios@linuxbios.org
http://www.openbio
On 9/12/06, ron minnich <[EMAIL PROTECTED]> wrote:
> Ed, could you give us a quick howto on the qemu stuff. I would like to use
> it to debug some new uncompress code.
Sure, I will write something up. I can even add it to the existing
QEMU_Build_Tutorial page if you'd like.
--Ed
--
linuxbios ma
The attached patch changes the qemu northbridge.c to read the RAM size
from the i440 PCI bridge configuration registers. This is mostly a
copy-and-paste from the i440bx northbridge.c.
Unfortunately the current version of qemu does not set these
registers, but I have patched qemu so that it emulat
The existing irq_tables.c for the qemu target seems to have been
generated for an old version of qemu, and isn't getting used in any
case. This causes Linux 2.6.17 to fail to detect IRQs for the Ethernet
and USB devices.
The attached patch updates irq_tables.c against the latest qemu
(0.8.2), and
Currently the qemu target is configured to always use a fallback
image, and the size of the image is hardcoded to 128KB.
The attached patch allows changing the image size by setting ROM_SIZE
in the target Config.lb.
It removes all the fallback-related stuff from the qemu mainboard
Config.lb, sin
On 9/12/06, Richard Smith <[EMAIL PROTECTED]> wrote:
> What does Qemu do when the BIOS attempts to write to that area?
> Normally this range of memory is write protected.
Good question--I was scratching my head over this chunk of code in
qemu yesterday:
/* map the last 128KB of the BIOS i
Hello,
I'm having some trouble getting Linux to recognize Ethernet and USB
devices when booting with LinuxBIOS on qemu 0.8.2.
During boot I see messages like:
ne2k-pci.c:v1.03 9/22/2003 D. Becker/P. Gortmaker
http://www.scyld.com/network/ne2k-pci.html
PCI: No IRQ known for interrupt pin A of d
On 9/5/06, Roman Kononov <[EMAIL PROTECTED]> wrote:
> Maybe this will help:
> http://sourceforge.net/mailarchive/forum.php?thread_id=10216054&forum_id=48022
Bingo! Works like a charm. Thanks!
--Ed
--
linuxbios mailing list
linuxbios@linuxbios.org
http://www.openbios.org/mailman/listinfo/linuxbi
On 9/5/06, Ronald G Minnich wrote:
> no, but this is qemu ... can't you grow qemu emulated flash?
Yes, but we plan to eventually run on actual hardware and would prefer
to keep the qemu environment as close to the real thing as possible.
--Ed
--
linuxbios mailing list
linuxbios@linuxbios.org
h
On 9/4/06, Ed Swierk <[EMAIL PROTECTED]> wrote:
> I would love to use Linux as my boot loader, but is it possible to
> cram LinuxBIOS plus a kernel and initrd into a puny 256 kByte EEPROM?
Correction: we're using a 1 MByte EEPROM, which I notice is the same
size specified fo
On 9/4/06, ron minnich <[EMAIL PROTECTED]> wrote:
> your problem right now is with filo. Can you try an older one? OR, better
> yet: if you want to work with me and make linux your boot loader, a la OLPC,
> that would be better: no filo at all! (not that I don't like FILO, it's
> wonderful, but Lin
Hello,
I'm trying to boot Linux on qemu (0.8.2) with LinuxBIOSv2 (svn 2394)
and FILO (0.5). I built filo.elf, ran buildtarget emulation/qemu-i386,
changed Config.lb to use filo.elf as the payload, and built LinuxBIOS.
I then copied the resulting qemu-bios.rom to bios.bin, and started
qemu with the
84 matches
Mail list logo
