LINUXBIOS can boot any variety OS
by mount me
Hi linuxbiosians,
Heard and Read that Windows 2000 can be booted using
Linuxbios. Keeeeeeen and Interested in entering
linuxbios. Could i get the list of OS's
booted using LINUXBIOS and a brief explanation
document along with it ? or links plz....
I am stilll looking for a motherboard in Chennai,INDIA
Has anyone tried linuxbios in CHENNAI,INDIA ?
need your support to start linuxbios with.
Regards,
karthik bala guru
________________________________________________________________________
Yahoo! India Promos: Win TVs, Bikes, DVD players & more!
Go to http://in.promos.yahoo.com
15 years, 7 months
hdd register and dma
by Felix Kloeckner
hello,
i am booting linuxbios from compatchflash and skip initialization of my additional hdd for faster booting
(using kernel-commandline-argument "hdc=none"). after the system is up I register the hdd using
#hdparm -R 0x170 0x376 15 /dev/hda
everything works fine, except after enabling the drive this way I can't put it into dma mode,
hdparm produces error like this:
# hdparm -d1 /dev/hdc
/dev/hdc:
setting using_dma to 1 (on)
HDIO_SET_DMA failed: Operation not permitted
using_dma = 0 (off)
I am using elitegroup/p6stp-fl, sis630, sis5513 as IDE-controller
any idea
ps.:
Bari Ari,
did you find any solution to your "ide-hotswap" problem, please let me know!
thanks
Felix Kloeckner
15 years, 10 months
Infrastructure status....
by ebiederman＠lnxi.com
I have been working on merging the static and dynamic device
trees, and I finally have a working version. The hard
part was that I was enumerating hypertransport first thing
and that was new code so any bug there and nothing looked like
it was working.
I have just a little bit more to finish up my initial superio
example and then I plan on committing the code.
I have had to extend the dynamic device tree in a couple of
ways to get this far.
Unless someone has some objects my plan is to tag the tree so it is
possible to look back and then commit everything.
There are lots of places where I am certain things can be done
better but the code is far enough along to be useful. Which
means it is now safe to put more eyes on the code and see how
things are going.
Eric
15 years, 10 months
答复: AMD8111_DEV
by YhLu
These three files seems should be removed and the AMD8111_DEV should be
removed too.
-----邮件原件-----
发件人: Stefan Reinauer [mailto:stepan@suse.de]
发送时间: 2003年8月28日 8:26
收件人: linuxbios(a)clustermatic.org
主题: AMD8111_DEV
Hi,
Looking at the config variable AMD8111_DEV I find quite some strange
things:
./mainboard/amd/solo/Config:option AMD8111_DEV=0x5
./mainboard/amd/solo/Config.lb:option AMD8111_DEV=0x3800
./mainboard/amd/quartet/Config:option AMD8111_DEV=0x5
./mainboard/tyan/s2880/Config:option AMD8111_DEV=0x5
./mainboard/tyan/s2880/Config.lb:uses AMD8111_DEV
./mainboard/tyan/s2882/Config:option AMD8111_DEV=0x5
./mainboard/tyan/s2882/Config.lb:uses AMD8111_DEV
./mainboard/tyan/s2885/Config:option AMD8111_DEV=0x5
./mainboard/tyan/s2885/Config.lb:uses AMD8111_DEV
./mainboard/arima/hdama/Config:option AMD8111_DEV=0x5
./mainboard/arima/hdama/Config.lb~:option AMD8111_DEV=0x3800
./mainboard/arima/hdama/Config.lb:uses AMD8111_DEV
It seems to be 5 in some places, and 0x3800 in some obsolete places,
which makes me think that in some config files it is assumed to be
shifted whereas in others it is assumed to contain an already shifted
value.
Same thing here:
./southbridge/amd/amd8111/cmos_boot_failover.inc: movl $(0x80000000 |
AMD8111_DEV | 0x40), %eax
./southbridge/amd/amd8111/amd8111_smbus.c:#define PM_DEVFN (AMD8111_DEVFN+3)
./southbridge/amd/amd8111/smbus.inc:#define PM_DEV_FN (AMD8111_DEV + 0x300)
This should be cleaned up. Any preferences for any variant?
Stefan
--
Architecture Team
SuSE Linux AG
_______________________________________________
Linuxbios mailing list
Linuxbios(a)clustermatic.org
http://www.clustermatic.org/mailman/listinfo/linuxbios
15 years, 10 months
re: Unified setup...
by YhLu
Stephan,
I have checked the AMD sheet, and you are right it will not change to
setting width and speed without reset or LDTSTOP_L.
In the pci_device.c, there is some code about HT.
I have removed the hardcode about width and speed and do some test, after I
checked the REG, and it seems width is set right but the speed is not right.
Maybe Eric need to check that part.
PS:
- PCI_ADDR(0, 0x18, 0, 0x94), 0xff0000ff, 0x00ff0000,
+ PCI_ADDR(0, 0x18, 0, 0x94), 0xff0000ff, 0x00050000,
[..]
- PCI_ADDR(0, 0x18, 0, 0xd4), 0xff0000ff, 0x00000000,
+ PCI_ADDR(0, 0x18, 0, 0xd4), 0xff0000ff, 0x00030000,
should be there. It defines the bus number behind the links. It will be used
when enumerating the non-coherent devices.
Regards
YH
-----邮件原件-----
发件人: Stefan Reinauer [mailto:stepan@suse.de]
发送时间: 2003年8月28日 7:40
收件人: linuxbios(a)clustermatic.org
主题: Re: Unified setup...
Hi again,
the coherent_ht.c changes are all to LYH's hardcodes to
coherent_ht_finalize(). These are there to setup link speed and width
on the cht nodes.
I remember tomz from LNXI was working on that on a higher level at pci
setup. Is that code complete by now? Are all bridges set up full speed?
Then we could just drop this code, which i would favour. Otherwise it
should walk into the motherboard specific code.
As far as I can see this code is noop anyways since speed changes need a
reset or LDTSTOP_L which is not asserted here. LYH, any comments?
--- coherent_ht.c 2003-08-14 11:11:10.000000000 +0200
+++ coherent_ht.1.c 2003-08-28 06:42:50.000000000 +0200
[..]
- PCI_ADDR(0, 0x18, 0, 0xc4), 0x88ff9c05, 0x770000d0,
+ PCI_ADDR(0, 0x18, 0, 0xc4), 0x88ff9c05, 0x11000020,
[..]
- PCI_ADDR(0, 0x18, 0, 0xc8), 0xfffff0ff, 0x00000000,
+ PCI_ADDR(0, 0x18, 0, 0xc8), 0xfffff0ff, 0x00000400,
[..]
- PCI_ADDR(0, 0x18, 0, 0x94), 0xff0000ff, 0x00ff0000,
+ PCI_ADDR(0, 0x18, 0, 0x94), 0xff0000ff, 0x00050000,
[..]
- PCI_ADDR(0, 0x18, 0, 0xd4), 0xff0000ff, 0x00000000,
+ PCI_ADDR(0, 0x18, 0, 0xd4), 0xff0000ff, 0x00030000,
Stefan
--
Architecture Team
SuSE Linux AG
_______________________________________________
Linuxbios mailing list
Linuxbios(a)clustermatic.org
http://www.clustermatic.org/mailman/listinfo/linuxbios
15 years, 10 months
about VGA support in voyager2 board
by elife elife
Hi,
I am trying to add VGA support in cocom voyager2 board. The VGA is found
but lb complain "biosint: Unsupport int #0x6" endlessly. I dumped the
original bios and found besides VGA BIOS I extracted, there is VSA driver.
Is VSA driver also needed to work with linuxbios and VGA BIOS? If so, Where
should I put it? And need I do more things to make it work?
Best Regards!
******** phoneix.bin BIOS component ********
No. Item-Name Original-Size Compressed-Size Original-File-Name
==============================================================================
0. System BIOS 20000h(128.00K) 12EECh(75.73K) original.tmp
1. XGROUP CODE 07340h(28.81K) 04D70h(19.36K) awardext.rom
2. EPA LOGO 0168Ch(5.64K) 002AAh(0.67K) AwardBmp.bmp
3. VGA ROM[1] 08000h(32.00K) 04229h(16.54K) gxivideo.208
4. PCI ROM[A] 0C800h(50.00K) 07536h(29.30K) RTSROM_M.LOM
5. VSA driver 20000h(128.00K) 09B2Fh(38.80K) GXM55306.BIN
6. LOGO BitMap 2583Ch(150.06K) 0474Bh(17.82K) n5535.bmp
---------------------------------------------------------------------
INSTALL REAL-MODE IDT
DO THE VGA BIOS
found VGA: vid=1078, did=104
0x55 0xaa 0x40 0xeb 0x4b 0x37 0x34 0x30 0x30 0xe9 0x4c 0x19 0x77 0xcc 0x56
0x49 biosint: # 0x6, eax 0x0 ebx 0x10 ecx 0x320 edx 0xaf8c
biosint: ebp 0x11498 esp 0xff6 edi 0xd4d4 esi 0xfffc0000
biosint: ip 0x3 cs 0x0 flags 0x46
biosint: Unsupport int #0x6
biosint: # 0x6, eax 0x0 ebx 0x10 ecx 0x320 edx 0xaf8c
biosint: ebp 0x11498 esp 0xff6 edi 0xd4d4 esi 0xfffc0000
biosint: ip 0x3 cs 0x0 flags 0x46
biosint: Unsupport int #0x6
biosint: # 0x6, eax 0x0 ebx 0x10 ecx 0x320 edx 0xaf8c
biosint: ebp 0x11498 esp 0xff6 edi 0xd4d4 esi 0xfffc0000
biosint: ip 0x3 cs 0x0 flags 0x46
biosint: Unsupport int #0x6
_________________________________________________________________
享用世界上最大的电子邮件系统― MSN Hotmail。 http://www.hotmail.com
15 years, 10 months
AMD8111_DEV
by Stefan Reinauer
Hi,
Looking at the config variable AMD8111_DEV I find quite some strange
things:
./mainboard/amd/solo/Config:option AMD8111_DEV=0x5
./mainboard/amd/solo/Config.lb:option AMD8111_DEV=0x3800
./mainboard/amd/quartet/Config:option AMD8111_DEV=0x5
./mainboard/tyan/s2880/Config:option AMD8111_DEV=0x5
./mainboard/tyan/s2880/Config.lb:uses AMD8111_DEV
./mainboard/tyan/s2882/Config:option AMD8111_DEV=0x5
./mainboard/tyan/s2882/Config.lb:uses AMD8111_DEV
./mainboard/tyan/s2885/Config:option AMD8111_DEV=0x5
./mainboard/tyan/s2885/Config.lb:uses AMD8111_DEV
./mainboard/arima/hdama/Config:option AMD8111_DEV=0x5
./mainboard/arima/hdama/Config.lb~:option AMD8111_DEV=0x3800
./mainboard/arima/hdama/Config.lb:uses AMD8111_DEV
It seems to be 5 in some places, and 0x3800 in some obsolete places,
which makes me think that in some config files it is assumed to be
shifted whereas in others it is assumed to contain an already shifted
value.
Same thing here:
./southbridge/amd/amd8111/cmos_boot_failover.inc: movl $(0x80000000 | AMD8111_DEV | 0x40), %eax
./southbridge/amd/amd8111/amd8111_smbus.c:#define PM_DEVFN (AMD8111_DEVFN+3)
./southbridge/amd/amd8111/smbus.inc:#define PM_DEV_FN (AMD8111_DEV + 0x300)
This should be cleaned up. Any preferences for any variant?
Stefan
--
Architecture Team
SuSE Linux AG
15 years, 10 months
Re: Unified setup...
by YhLu
Stephan,
All about the duplicate code are for the multilink etc. I think after Eric
and the code to enumerate the HT belongs to the CPU0. and make the static
links to work in chip.h and ... it will be eliminated. (auto.c and
pci_device.c and cpufixup.c may all need the static config processing code)
Regards
Yinghai Lu
-----邮件原件-----
发件人: Stefan Reinauer [mailto:stepan@suse.de]
发送时间: 2003年8月28日 6:34
收件人: linuxbios(a)clustermatic.org
主题: Unified setup...
Hi LYH, Ron and others,
I've been looking at the recent changes that went into the tree, and I
don't like the fact that a lot of code is duplicated. Is there some way
to unify this?
--- raminit.c 2003-08-28 14:43:39.000000000 +0200
+++ raminit.1.c 2003-08-28 06:42:50.000000000 +0200
[..]
- PCI_ADDR(0, 0x18, 1, 0xBC), 0x00000048, 0x00ffff00,
+ PCI_ADDR(0, 0x18, 1, 0xBC), 0x00000048, 0x00ffff20,
This changes the link id where the southbridge is connected.
We can get this information out of the configuration file since we
are able to describe a map of all CHT components.
On most machines the southbridge is probably connected to LDT0, but
having two files for this one setting seems inappropriate.
Ron, what is the easiest way of getting this information from the
config file?
LYH: To get this unified again, I added a resourcemap.c file to the
s2885 directory that contains the resource map of the 2885. In auto.c
this is used instead of the default.
- PCI_ADDR(0, 0x18, 1, 0xC4), 0xFE000FC8, 0x01fff000,
+ PCI_ADDR(0, 0x18, 1, 0xC4), 0xFE000FC8, 0x01fff020,
same as above.
- PCI_ADDR(0, 0x18, 1, 0xE0), 0x0000FC88, 0xff000003,
- PCI_ADDR(0, 0x18, 1, 0xE4), 0x0000FC88, 0x00000000,
+ PCI_ADDR(0, 0x18, 1, 0xE0), 0x0000FC88, 0x03000203,
+ PCI_ADDR(0, 0x18, 1, 0xE4), 0x0000FC88, 0x05040003,
These change the bus numbers and read/write enables. How can we write
these more general?
+/*
//BY LYH add IOMMU 64M APERTURE
PCI_ADDR(0, 0x18, 3, 0x94), 0xffff8000, 0x00000f70,
PCI_ADDR(0, 0x18, 3, 0x90), 0xffffff80, 0x00000002,
PCI_ADDR(0, 0x18, 3, 0x98), 0x0000000f, 0x00068300,
//BY LYH END
+*/
I added a configuration variable ENABLE_IOMMU and set it to 1 for all
existing boards except the s2885. It would be nice to have the size of
the aperture also selectable via the configuration file, or even better
during firmware run time.
I am scared that changes for special motherboards will contaminate the
source tree and make it hard for anyone to see what is actually going
on. If this happens in a source tree for a special motherboard, it does
not really matter, but I think it is a good goal to keep the generic
code clean and generic and make it even more generic in the places where
it's not sufficient.
I'll look into coherent_ht.1.c and see if this can be done more general
as well.
I commited the attached patch. Please comment.
Stefan
--
Architecture Team
SuSE Linux AG
15 years, 10 months
Unified setup...
by Stefan Reinauer
Hi LYH, Ron and others,
I've been looking at the recent changes that went into the tree, and I
don't like the fact that a lot of code is duplicated. Is there some way
to unify this?
--- raminit.c 2003-08-28 14:43:39.000000000 +0200
+++ raminit.1.c 2003-08-28 06:42:50.000000000 +0200
[..]
- PCI_ADDR(0, 0x18, 1, 0xBC), 0x00000048, 0x00ffff00,
+ PCI_ADDR(0, 0x18, 1, 0xBC), 0x00000048, 0x00ffff20,
This changes the link id where the southbridge is connected.
We can get this information out of the configuration file since we
are able to describe a map of all CHT components.
On most machines the southbridge is probably connected to LDT0, but
having two files for this one setting seems inappropriate.
Ron, what is the easiest way of getting this information from the
config file?
LYH: To get this unified again, I added a resourcemap.c file to the
s2885 directory that contains the resource map of the 2885. In auto.c
this is used instead of the default.
- PCI_ADDR(0, 0x18, 1, 0xC4), 0xFE000FC8, 0x01fff000,
+ PCI_ADDR(0, 0x18, 1, 0xC4), 0xFE000FC8, 0x01fff020,
same as above.
- PCI_ADDR(0, 0x18, 1, 0xE0), 0x0000FC88, 0xff000003,
- PCI_ADDR(0, 0x18, 1, 0xE4), 0x0000FC88, 0x00000000,
+ PCI_ADDR(0, 0x18, 1, 0xE0), 0x0000FC88, 0x03000203,
+ PCI_ADDR(0, 0x18, 1, 0xE4), 0x0000FC88, 0x05040003,
These change the bus numbers and read/write enables. How can we write
these more general?
+/*
//BY LYH add IOMMU 64M APERTURE
PCI_ADDR(0, 0x18, 3, 0x94), 0xffff8000, 0x00000f70,
PCI_ADDR(0, 0x18, 3, 0x90), 0xffffff80, 0x00000002,
PCI_ADDR(0, 0x18, 3, 0x98), 0x0000000f, 0x00068300,
//BY LYH END
+*/
I added a configuration variable ENABLE_IOMMU and set it to 1 for all
existing boards except the s2885. It would be nice to have the size of
the aperture also selectable via the configuration file, or even better
during firmware run time.
I am scared that changes for special motherboards will contaminate the
source tree and make it hard for anyone to see what is actually going
on. If this happens in a source tree for a special motherboard, it does
not really matter, but I think it is a good goal to keep the generic
code clean and generic and make it even more generic in the places where
it's not sufficient.
I'll look into coherent_ht.1.c and see if this can be done more general
as well.
I commited the attached patch. Please comment.
Stefan
--
Architecture Team
SuSE Linux AG
15 years, 10 months
Re: about VGA support in voyager2 board
by elife elife
Sorry for delayed reply. I will test it tomorrow.
Thanks all!
>From: ron minnich <rminnich(a)lanl.gov>
>To: SONE Takeshi <ts1(a)cma.co.jp>
>CC: elife elife <rimy2000(a)hotmail.com>, <linuxbios(a)clustermatic.org>
>Subject: Re: about VGA support in voyager2 board
>Date: Wed, 27 Aug 2003 08:14:47 -0600 (MDT)
>
>OK, would anyone like to test out my fixed vgabios with the devfn patch?
>
>I will look at moving the table to 0x1000. I actually think there was a
>reason I kept all this on page 0, but that reason probably no longer
>matters.
>
>ron
>
>
_________________________________________________________________
与联机的朋友进行交流，请使用 MSN Messenger: http://messenger.msn.com/cn
15 years, 10 months
