August 2003 - coreboot - mail.coreboot.org

LINUXBIOS can boot any variety OS
by mount me Dec. 1, 2003

Dec. 1, 2003

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

2 2

hdd register and dma
by Felix Kloeckner Aug. 31, 2003

Aug. 31, 2003

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

2 1

Infrastructure status....
by ebiederman＠lnxi.com Aug. 30, 2003

Aug. 30, 2003

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

2 1

答复: AMD8111_DEV
by YhLu Aug. 30, 2003

Aug. 30, 2003

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

2 1

re: Unified setup...
by YhLu Aug. 29, 2003

Aug. 29, 2003

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

4 3

about VGA support in voyager2 board
by elife elife Aug. 29, 2003

Aug. 29, 2003

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

4 12

AMD8111_DEV
by Stefan Reinauer Aug. 28, 2003

Aug. 28, 2003

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

2 1

Re: Unified setup...
by YhLu Aug. 28, 2003

Aug. 28, 2003

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

1 0

Unified setup...
by Stefan Reinauer Aug. 28, 2003

Aug. 28, 2003

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

2 6

Re: about VGA support in voyager2 board
by elife elife Aug. 28, 2003

Aug. 28, 2003

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

1 0