I just released FILO 0.4.
http://te.to/~ts1/filo/
It can boot distro CDs if you give a proper command line.
SuSE 8.2 LiveEval CD worked without a glitch, I enjoyed the
KDE desktop, OpenOffice, etc, from the CD on an EPIA booted
from LinuxBIOS.
Also added support for booting from BIOS flash, to boot an
alternative bootloader like Etherboot.
PCI support in IDE driver is also added (or recovered), but
the native PCI mode is not fully tested.
I tried to configure EPIA (V1) code to use native mode,
and the ports read something not 0xff, but the drive doesn't
respond to soft reset.
I don't know the bug is in FILO, LinuxBIOS, or the hardware.
I'll work on config file support next time.
Version 0.4 ts1 2003-10-15
* Support for ATAPI CD-ROM.
* ISO-9660 filesystem is taken from a GRUB patch by
Leonid Lisovskiy <lly(a)pisem.net>. The filesystem code was originally
written by Kousuke Takai <tak(a)kmc.gr.jp> for GRUB/98 project.
* Support for mounting boot disk image of El Torito bootable CD-ROM.
("hdc1" means the boot disk image of the CD-ROM at hdc.)
* Support for memory as device, raw device as image, and
user-specifiable device offset and length.
(eg. boot: mem@0xfffd0000,0x10000)
* PCI support in IDE driver. Now it by default uses PCI enumeration
to find the PCI IDE controller, and can use native PCI mode
if the controller is configured to this mode by BIOS.
To disable this, turn off SUPPORT_PCI.
* Fixed Linux loader to boot RedHat 9 kernel properly.
--
Takeshi
This is off-topic but I'm hoping someone here will know the answer.
In the linux kernel I need to make a module that will map the BOOTROM
of an RTL8139 based network card into PCI memory somewhere. I need to
write the pci config longword at offset 0x30 with the bus address. I can
arbitrarily pick one such as 0xd2000000 and the bootrom appears as expected,
but I don't want to step on anything else that might be using that memory
area. How can I allocate a block of memory in pci address space to know
where to safely map in the bootrom? Also I'll want to free the allocation
on module exit.
Apologies/thanks as the case may be.
-Dave
Eric,
When using nfsroot to put rootfs in NFS server, I need to set "root=/dev/nfs
nfsroot=.... ip=bootp" to use mkelfImage to produce one. Elf for boot.
Then If there is ip-mac pair in the dhcpd.conf. The kernel can not get the
IP address from the DHCP server.
The dhcp in busybox seems something simple dhcp....
I will try to use dhclient.
Regards
YH.
-----邮件原件-----
发件人: ebiederman(a)lnxi.com [mailto:ebiederman@lnxi.com]
发送时间: 2004年2月25日 18:49
收件人: LinuxBIOS
抄送: YhLu
主题: Re: IP get via Etherboot and IP get dhcpcd
Peter Stuge <stuge-linuxbios(a)cdy.org> writes:
> On Wed, Feb 25, 2004 at 05:10:44PM -0800, YhLu wrote:
> > Eric,
> >
> > I put the the dhcpcd in the initrd. After boot system with LinuxBIOS +
> > Etherboot + elf ( with the initrd). I found the IP got by Etherboot and
> > dhcpcd is different.
> >
> > I may only used fixed option in dhcpd.conf to make it get the same addr?
If you specify the mac address and a fixed ip address you should always get
the same IP.
> One explanation would be that Etherboot uses BOOTP while dhcpcd uses DHCP.
> Try making Etherboot speak DHCP as well.
>
> Otherwise maybe you can set up a fake dhcpcd-eth*.info file with the IP,
> but I doubt dhcpd will approve the request for that same address unless
> you use a really short lease time.
There are a couple of other possibilities.
dhcpcd is a broken client and can be fooled into thinking a reply to
another client is for itself as it does not verify the dhcp reply
it uses has the mac address it is requesting an ip address for.
dhclient works correctly and is strongly configurable. I think
busybox also includes a working dhcp client.
Etherboot filters dhcp replies looking for a filename so it will
have something to boot from. If you have 2 dhcp servers answering
you that could explain the difference.
packet sniffers like tcpdump and ethreal are your friends, as well
as log files in /var/log/
Eric
Eric,
I put the the dhcpcd in the initrd. After boot system with LinuxBIOS +
Etherboot + elf ( with the initrd). I found the IP got by Etherboot and
dhcpcd is different.
I may only used fixed option in dhcpd.conf to make it get the same addr?
Regards
Yinghai Lu
(Hoping this goes into the correct thread)
You are correct, romimage is what you need to burn.
About the ELF image thing--The payload is indeed an ELF image, and
LinuxBIOS uses "elfboot" to boot it. The payload can be a normal Linux
kernel made bootable by the mkelfImage utility (
ftp://ftp.lnxi.com/pub/mkelfImage/ ), a FILO image
( http://te.to/~ts1/filo/ ), or an Etherboot image (
http://sourceforge.net/projects/etherboot/ ). Perhaps someone more
experienced with this can explain in further detail.
>>It is flashable with any kind AWARD MS-DOS tool ?
You should probably try to use with Flash 'n Burn (Check
the original freebios tree) or Linux memory technology devices (MTD --
http://www.linux-mtd.infradead.org/ ). Sure beats booting off a FreeDOS
floppy!
I have a DFI AZ30-TL sitting in the corner, now collecting dust, that I
built for a little duron box in the recent past. The boards, even new,
are really cheap, and I was wondering if LinuxBIOS had enough support to
get ide booting (via cf adapter) and video to work on them. I want to
use this board for a car-based installation, so it (the board) being
cheap and maybe unreliable is no problem. :)
Here are the basics I beleive have been asked for in the past:
VIA® chipsets:
North bridge: VIA® KM266
South bridge: VIA® VT8235CD
It has normal 184-pin DDR sockets, shared ProSavage8(TM) video (which I
perceive to be a problem already..), generic PCI IDE, etc.
I'd attach the output of scanpci, but only kernels on the box have
grsecurity running on them and scanpci needs ioperm(). If it's needed, I
can get it, I'll just need to build a new kernel for the box.
DFI has its generic, non-detailed specs at
http://www.dfi.com.tw/Product/xx_product_spec_details_r_us.jsp?PRODUCT_ID=1…
I have some system hacking experience, but I'm mostly a generic
application developer, low level code is not entirely my forte.
Thanks,
Justin
