Tao Liu | 1 Apr 03:33 2005
Picon

Re: [PATCH] small fixes

OK, thanks!

On Thu, 31 Mar 2005 09:40:53 -0800, yhlu <yinghailu <at> gmail.com> wrote:
> you need to use tla to get latest source code.
> 
> YH
>

_______________________________________________
LinuxBIOS mailing list
LinuxBIOS <at> openbios.org
http://www.openbios.org/mailman/listinfo/linuxbios

Tao Liu | 1 Apr 03:48 2005
Picon

Re: [PATCH 2/2] amd8111_nic: Set MAC address in linux bios

Our mainboard don't have the SEEPROM :(
I think have an individual SEEPROM for MAC is correct.

--
Liu Tao

On Thu, 31 Mar 2005 12:04:30 -0800, YhLu <YhLu <at> tyan.com> wrote:
> Should be in BIOS.because different MB use different MAC assigned in
> Factory.
> 
> But in MB design, it should use another SEEPROM to store that. So the BIOS
> or NIC get it.
> 
> YH
>

_______________________________________________
LinuxBIOS mailing list
LinuxBIOS <at> openbios.org
http://www.openbios.org/mailman/listinfo/linuxbios

John.Lee | 1 Apr 03:54 2005

Fw: RE: Could you help on Flash_and_burn?

, 您好!
   My board is intel 865pe amd lspci is:
	 lspci -tv
-[00]-+-00.0  Intel Corp. 82865G/PE/P DRAM Controller/Host-Hub Interface
      +-01.0-[01]----00.0  nVidia Corporation NV34 [GeForce FX 5200]
      +-1d.0  Intel Corp. 82801EB/ER (ICH5/ICH5R) USB UHCI #1
      +-1d.1  Intel Corp. 82801EB/ER (ICH5/ICH5R) USB UHCI #2
      +-1d.2  Intel Corp. 82801EB/ER (ICH5/ICH5R) USB UHCI #3
      +-1d.3  Intel Corp. 82801EB/ER (ICH5/ICH5R) USB UHCI #4
      +-1d.7  Intel Corp. 82801EB/ER (ICH5/ICH5R) USB2 EHCI Controller
      +-1e.0-[02]--+-0a.0  Lucent Microelectronics FW323
      |            \-0e.0  Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+
      +-1f.0  Intel Corp. 82801EB/ER (ICH5/ICH5R) LPC Bridge
      +-1f.1  Intel Corp. 82801EB/ER (ICH5/ICH5R) Ultra ATA 100 Storage Controller
      +-1f.2  Intel Corp. 82801EB (ICH5) Serial ATA 150 Storage Controller
      +-1f.3  Intel Corp. 82801EB/ER (ICH5/ICH5R) SMBus Controller
      \-1f.5  Intel Corp. 82801EB/ER (ICH5/ICH5R) AC'97 Audio Controller

lspci -vvxxx
0000:00:00.0 Host bridge: Intel Corp. 82865G/PE/P DRAM Controller/Host-Hub Interface (rev 02)
        Subsystem: Quantum Designs (H.K.) Inc: Unknown device 5728
        Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
        Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort+ >SERR- <PERR-
        Latency: 0
        Region 0: Memory at e8000000 (32-bit, prefetchable) [size=128M]
        Capabilities: [e4] #09 [2106]
        Capabilities: [a0] AGP version 3.0
                Status: RQ=32 Iso- ArqSz=2 Cal=2 SBA+ ITACoh- GART64- HTrans- 64bit- FW+ AGP3+ Rate=x4,x8
                Command: RQ=1 ArqSz=0 Cal=2 SBA+ AGP- GART64- 64bit- FW- Rate=<none>
00: 86 80 70 25 06 00 90 20 02 00 00 06 00 00 00 00
(Continue reading)

ramesh bios | 1 Apr 04:11 2005
Picon

RTC and linuxbios checksum versus pc checksum

I was looking through linuxbios' freebios (v1) code
and see the following:

rtc_checksum_valid(PC_CKS_RANGE_START,
                        PC_CKS_RANGE_END,PC_CKS_LOC);
then 
rtc_checksum_valid(LB_CKS_RANGE_START,
                        LB_CKS_RANGE_END,LB_CKS_LOC);
then finally
rtc_set_checksum(PC_CKS_RANGE_START,
                        PC_CKS_RANGE_END,PC_CKS_LOC);

I looked in 2.6.11's mc146818 code and I don't see it
writing a checksum so I'm not certain it's valid to
check for a checksum on boot since stuff like hwclock
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 PC
checksum at the end. Is it for legacy compatibility, I
didn't find any mention of it in the mailing list and
google. 

Thanks.

		
__________________________________ 
Do you Yahoo!? 
Make Yahoo! your home page 
http://www.yahoo.com/r/hs
_______________________________________________
(Continue reading)

YhLu | 1 Apr 05:02 2005

RE: RE: Could you help on Flash_and_burn?

So you need to add one entry in flash_enable.c

static FLASH_ENABLE enables[] = {
        {0x1039, 0x0630, "sis630", enable_flash_sis630},
        {0x8086, 0x2480, "E7500", enable_flash_e7500}, // should use SB name
---> add one entry to you device id
        {0x8086, 0x24d0, "ICH5ER", enable_flash_e7500},

        {0x8086, 0x24c0, "ICH4", enable_flash_ich4}, // this line is not
right
        {0x1106, 0x8231, "VT8231", enable_flash_vt8231},
        {0x1106, 0x3177, "VT8235", enable_flash_vt8235},
        {0x1078, 0x0100, "CS5530", enable_flash_cs5530},
        {0x100b, 0x0510, "SC1100", enable_flash_sc1100},
        {0x1039, 0x0008, "SIS5595", enable_flash_sis5595},
        {0x1022, 0x7468, "AMD8111", enable_flash_amd8111}, }; 

Also you need to check your MB if there is any jumper to disable the flash
write or boot block write protection.

Some MB even use GPIO to disable that. You need to enable that via GPIO in
SB or Superio.

YH
_______________________________________________
Linuxbios mailing list
Linuxbios <at> clustermatic.org
http://www.clustermatic.org/mailman/listinfo/linuxbios

(Continue reading)

ramesh bios | 1 Apr 09:35 2005
Picon

Re: RTC and linuxbios checksum versus pc checksum

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.

Thanks.

--- ramesh bios <ramesh_bios <at> yahoo.com> wrote:
> I was looking through linuxbios' freebios (v1) code
> and see the following:
> 
> rtc_checksum_valid(PC_CKS_RANGE_START,
>                        
> PC_CKS_RANGE_END,PC_CKS_LOC);
> then 
> rtc_checksum_valid(LB_CKS_RANGE_START,
>                        
(Continue reading)

Peter Karlsson | 1 Apr 11:16 2005
Picon
Picon

Re: RTC and linuxbios checksum versus pc checksum

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.
>
> Thanks.
>
> --- ramesh bios <ramesh_bios <at> yahoo.com> wrote:
>> I was looking through linuxbios' freebios (v1) code
>> and see the following:
>>
>> rtc_checksum_valid(PC_CKS_RANGE_START,
>>
>> PC_CKS_RANGE_END,PC_CKS_LOC);
>> then
(Continue reading)

Peter Karlsson | 1 Apr 11:29 2005
Picon
Picon

Glossary update...

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)...

Best regards

Peter K
Attachment (glossary.tar.gz): application/octet-stream, 6857 bytes
_______________________________________________
LinuxBIOS mailing list
LinuxBIOS <at> openbios.org
http://www.openbios.org/mailman/listinfo/linuxbios
Ronald G. Minnich | 1 Apr 16:56 2005

Re: Re: RTC and linuxbios checksum versus pc checksum


On Fri, 1 Apr 2005, Peter Karlsson wrote:

> 
> If anyone knows anything about the above question please put this in the
> wiki-faq...

I think it's another hardware bug, and I think the description as ramesh 
wrote it would be nice to have in the FAQ. One of these "set this bit, 
don't ask why" type situations. 

ron

_______________________________________________
LinuxBIOS mailing list
LinuxBIOS <at> openbios.org
http://www.openbios.org/mailman/listinfo/linuxbios

Richard Smith | 1 Apr 17:25 2005
Picon

Re: Re: RTC and linuxbios checksum versus pc checksum

>mystery to the back of my mind. If anyone happens to
>understand this stuff, I'll sleep better once I've
>understood this.

> I think it's another hardware bug, and I think the description as ramesh
> wrote it would be nice to have in the FAQ. One of these "set this bit,
> don't ask why" type situations.

Check for errata notes on the part.  Perhaps the polarity of the
enable/disable bit is flipped and incorrect in datasheet.

--

-- 
Richard A. Smith

_______________________________________________
LinuxBIOS mailing list
LinuxBIOS <at> openbios.org
http://www.openbios.org/mailman/listinfo/linuxbios


Gmane