[coreboot] [coreboot - Other #539] (New) Add support to motherboard

[User Nick]

Issue #539 has been reported by User Nick.


Other #539: Add support to motherboard
https://ticket.coreboot.org/issues/539

* Author: User Nick
* Status: New
* Priority: Normal
* Category: board support
* Target version: none
* Start date: 2024-05-22

Hi

I'd like to get coreboot running in a motherboard that currently doesn't have 
support.

If some developer likes to get this done, I'm willing to provide the flashrom 
dumps gather the necessary data and do all the required testing.

Thank you all.



-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
https://ticket.coreboot.org/my/account
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

Re: [coreboot] T430s or T430 (Was: latest greatest thinkpad with coreboot)

[Nick]

I'm also very interested in this. I have three T430s' and one T510.

I may attempt to use autoport on one over Christmas break or if anyone
wants me to test their port, let me know.

-Nick



On Mon, Dec 5, 2016 at 10:55 AM, Klemens Nanni <k...@posteo.org> wrote:

> On Tue, Dec 06, 2016 at 02:40:46AM +0800, Pok Gu wrote:
>
>> Thanks all. I value all your concerns on freedom (not opensource) and
>> security and the feeling of having control.
>> Let's say down to earth. I just wondering are there any other cool things
>> (e.g., unlocking features) we can get. Because it seems the reason that
>> other projects (e.g., OpenWRT) is so popular is it unlock many features
>> along with the freedom/security once a router flash it.
>>
>
> Yes, you get rid of the PCI whitelist allowing you to use any wifi
> module (being supported by free drivers). You may also install more RAM
> depending on both board and RAM type.
>
> Please correct me if I'm wrong.
>
> /kl3
>
>
> --
> coreboot mailing list: coreboot@coreboot.org
> https://www.coreboot.org/mailman/listinfo/coreboot
>
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Multiple payloads support?

[Nick]

Bayou is not necessary - use SeaBIOS to run coreinfo.

*./build/cbfstool ./build/coreboot.rom add-payload -f
/gitrepo/coreboot/payloads/coreinfo/build/coreinfo.elf -n img/coreinfo.elf
-t payload*

On Sun, Mar 20, 2016 at 7:02 PM, ron minnich  wrote:

> it's a bit of work but I got it to build two years ago.
>
> ron
>
> On Sun, Mar 20, 2016 at 6:56 PM Zheng Bao  wrote:
>
>> But Bayou seems to be dead. It can not be built. The definition like
>> "struct LAR" goes nowhere.
>>
>>
>> Zheng
>> --
>> From: rminn...@gmail.com
>> Date: Sun, 20 Mar 2016 21:17:24 +
>> To: fishb...@hotmail.com; coreboot@coreboot.org;
>> stefan.reina...@coreboot.org
>> Subject: Re: [coreboot] Multiple payloads support?
>>
>>
>> It was done about 10 years ago and it was called bayou. Take a look in
>> the libpayload side.
>>
>> On Sat, Mar 19, 2016 at 11:30 PM Zheng Bao  wrote:
>>
>> Hi, all,
>> I am trying to integrate SeaBIOS and another payload(coreinfo, nvramcui)
>> into final image.
>>
>> After a quick code checking, current code in repo does not support
>> multiple payload, does it?
>>
>> I want to let Coreboot load and run nvramcui first. The user can decide
>> to change the
>> CMOS setting or not. If user want to save the setting, the system need to
>> reboot. If user wants
>> to give up the change, the system goes out of the nvramcui and goes into
>> SeaBIOS. Just like
>> other IBV's BIOS.
>>
>> Did anyone do this job before? Any suggestion?
>>
>> Zheng
>> --
>> coreboot mailing list: coreboot@coreboot.org
>> https://www.coreboot.org/mailman/listinfo/coreboot
>>
>>
>> -- coreboot mailing list: coreboot@coreboot.org
>> https://www.coreboot.org/mailman/listinfo/coreboot
>>
>
> --
> coreboot mailing list: coreboot@coreboot.org
> https://www.coreboot.org/mailman/listinfo/coreboot
>
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] Handling NMIs?

[Nick]

Hi guys,

Question - Does Coreboot have a facility for catching and handling NMIs?

Background: I have a problematic PCI bridge that throws a NMI when enabling
it. When this happens, firmware code stops executing. Otherwise, the bridge
works.

Simply disabling NMIs when enabling this particular device might cause a
miss of some other failure and seems like the wrong thing to do.

Any suggestions?

Thanks!

Nick
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] MCP-55 IOAPIC Strangeness

[Nick]

Hi guys,

I have an MCP-55 system with two IOAPICs:

IOAPIC 4 @ PCI 00:01.0
IOAPIC 5 @ PCI 40:01.0

The first strange thing I see is when IOAPIC 4 is initilized and it says:


   1. IOAPIC: Initializing IOAPIC at 0x



Does this seem strange to anyone that it's initializing at 0x?
Should I be seeing this at 0xfec0? (which is the address the registers
are mapped to under the vendor bios)

The next strange thing is when APIC 5 is initilized and spits out a bunch
of register values - I think this is expected, but IOAPIC 4 doesn't spit
out many register values? They are both MCP55 APICs.

The this irregular thing is when using the* find_resource *function to help
add IOAPIC 4 to MPTable. It fails with the error:


   1. PCI: 00:01.0 missing resource: 14


This works fine for APIC 5, though. They're the same device.

Here's a very truncated coreboot log: http://pastebin.com/JyJph1Ee

Any ideas?

-Nick
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] (no subject)

[Nick]

Sorry for not adding a subject to this thread - realized the second after I
hit send :)

I made some progress by manually adding IOAPIC #4 (assuming its address is
fixed) - Linux kernel does not panic anymore and some IRQ routing started
working, but there are still some issues.

I'm still wondering why the detection code used on other MCP-55 boards
fails.

On Wed, May 13, 2015 at 12:15 PM, Nick nochristrequi...@gmail.com wrote:

 Hi,

 I'm looking for a little advice (or steering in the right direction) in
 regards to IOAPICs and how Coreboot manages detection. I have two MCP-55
 chipsets just like the nVidia l1_2pvv board.

 When I boot Linux under the *vendor bios* with apic debugging enabled, I
 can see that I have two IOAPICs-

 [0.00] IOAPIC[0]: apic_id 4, version 17, address 0xfec0, GSI
 0-23
 [0.00] IOAPIC[1]: apic_id 5, version 17, address 0xb040, GSI
 24-47

 And, when I boot using Coreboot*,* I have only one-

 [0.00] IOAPIC[0]: apic_id 5, version 17, address 0xf434, GSI
 0-23

 Now, I'm sure this output is coming from the MP Table which Linux is
 reading back.

 In mptable.c a lot of the MCP-55 boards share this detection code for
 building the MP Table. Mine will only enter the if statement for bus_mcp55b.

 get_bus_conf();
 sbdn = sysconf.sbdn;
 m = sysconf.mb;


 dev = dev_find_slot(m-bus_mcp55, PCI_DEVFN(sbdn+ 0x1,0));
 if (dev) {
 res = find_resource(dev, PCI_BASE_ADDRESS_1);
 if (res)
 smp_write_ioapic(mc, m-apicid_mcp55, 0x11, res-base);


 if (m-bus_mcp55b) {
 dev = dev_find_slot(m-bus_mcp55b, PCI_DEVFN(m-sbdnb + 0x1,0));
 if (dev) {
 res = find_resource(dev, PCI_BASE_ADDRESS_1);
 if (res)
 smp_write_ioapic(mc, m-apicid_mcp55b, 0x11, res-base);

 So, my question is - what is responsible for detecting the IOAPICs? Is
 there some configuration somewhere which I may be missing? Any tips for
 where to look?

 Here's a full output from Coreboot and the Linux kernel(apic=debug
 show_lapic=all): *http://pastebin.com/PMVtt6hU
 http://pastebin.com/PMVtt6hU*

 Here's Linux kernel output from the vendor bios:* http://pastebin.com/VscyMxM2
 http://pastebin.com/VscyMxM2* (MPTable @ line 110.)

 Thanks in advance!

 -Nick



 --
 coreboot mailing list: coreboot@coreboot.org
 http://www.coreboot.org/mailman/listinfo/coreboot

-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] (no subject)

[Nick]

Hi,

I'm looking for a little advice (or steering in the right direction) in
regards to IOAPICs and how Coreboot manages detection. I have two MCP-55
chipsets just like the nVidia l1_2pvv board.

When I boot Linux under the *vendor bios* with apic debugging enabled, I
can see that I have two IOAPICs-

[0.00] IOAPIC[0]: apic_id 4, version 17, address 0xfec0, GSI
0-23
[0.00] IOAPIC[1]: apic_id 5, version 17, address 0xb040, GSI
24-47

And, when I boot using Coreboot*,* I have only one-

[0.00] IOAPIC[0]: apic_id 5, version 17, address 0xf434, GSI
0-23

Now, I'm sure this output is coming from the MP Table which Linux is
reading back.

In mptable.c a lot of the MCP-55 boards share this detection code for
building the MP Table. Mine will only enter the if statement for bus_mcp55b.

get_bus_conf();
sbdn = sysconf.sbdn;
m = sysconf.mb;


dev = dev_find_slot(m-bus_mcp55, PCI_DEVFN(sbdn+ 0x1,0));
if (dev) {
res = find_resource(dev, PCI_BASE_ADDRESS_1);
if (res)
smp_write_ioapic(mc, m-apicid_mcp55, 0x11, res-base);


if (m-bus_mcp55b) {
dev = dev_find_slot(m-bus_mcp55b, PCI_DEVFN(m-sbdnb + 0x1,0));
if (dev) {
res = find_resource(dev, PCI_BASE_ADDRESS_1);
if (res)
smp_write_ioapic(mc, m-apicid_mcp55b, 0x11, res-base);

So, my question is - what is responsible for detecting the IOAPICs? Is
there some configuration somewhere which I may be missing? Any tips for
where to look?

Here's a full output from Coreboot and the Linux kernel(apic=debug
show_lapic=all): *http://pastebin.com/PMVtt6hU
http://pastebin.com/PMVtt6hU*

Here's Linux kernel output from the vendor bios:* http://pastebin.com/VscyMxM2
http://pastebin.com/VscyMxM2* (MPTable @ line 110.)

Thanks in advance!

-Nick
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] Soft-Reset when enabling resources on Sun Ultra 40 M2

[Nick]

Hi,

I'm encountering a soft-reset when enabling resources. It occurs on the
same link / device each time - dev fun 6.0 on MCP55 - which is a PCI 33Mhz
bus connected to an on-board Firewire controller.

I added some text at the end of the loop to make sure it was crashing on
6.0 and not 6.1. It never loops after trying to enable 6.0.

Here's my console output: http://pastebin.com/15hVB9bu

Here's an image showing the various devices on this motherboard and their
PCI addresses: http://ibin.co/20n6DtSrgZSv

The board is a Sun Ultra 40 M2 which I'm trying to get working with
Coreboot.

Any ideas or suggestions would be appreciated as I'm sitting here
scratching my head wondering what to try next. :)

Thanks in advance!

-Nick
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] tyan s8226 status

[Nick Lewycky]

Nick Lewycky wrote:

What's the status of the Tyan s8226? There's a src/mainboard/tyan/s8226
directory in git coreboot, but no entry for s8226 under board status
pages. Does this mean that it's unsupported? Or conversely, is it known
to work?


Ping!

I didn't think this would be a hard question to answer. Presumably 
somebody had to check it in, and that person would know?


Nick

--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] tyan s8226 status

[Nick Lewycky]

What's the status of the Tyan s8226? There's a src/mainboard/tyan/s8226 
directory in git coreboot, but no entry for s8226 under board status 
pages. Does this mean that it's unsupported? Or conversely, is it known 
to work?


Nick

--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] Sun Ultra 40 M2 port - TrainDQSPos: MutualCSPassW[48] then reboot

[Nick]

Hello,

I'm working on a coreboot port to the Sun Ultra 40 M2. This is an MCP55
based dual socket Opteron system with two memory banks per node (four slots
each.)

It's currently in a dual dualcore configuration with 8GB of DDR2 memory,
two 2GB sticks per bank.

I'm using the Tyan s2912 mainboard definition as a base (not fam10.) I've
observed a couple different behaviours.

1) Upon cold boot, the system will sometimes (not always) reboot itself
approx every 2 seconds before getting to raminit - it always passes the
first stage of HT negotiation but (after the soft-reset) fails on the line
dev1 output ln_width1=0x (then resets without completing the value)
2) The system usually gets to raminit at least initially. Memory detection
goes very quickly until TrainDQSPos: MutualCSPassW[48] where it then
slows to a crawl. After this, issue 1 reoccurs over and over -
http://pastebin.com/aNUZf1Hr (issues 2, followed by issue 1)
3) When the system is booted to linux and the vendor code is (hot) swapped
for coreboot and warm rebooted initiated, the system will slowly move past
TrainDQSPos: MutualCSPassW[48] without rebooting (issues #2 is always
followed by a reboot) and has completed cache to ram, then rebooted. This
is the furthest it has gotten - http://pastebin.com/5vQPgWQn

Any advice would be greatly appreciated!

Regards,
Nick
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] SuperMicro h8dmr-i2 slowness in v4

[Nick Lemberger]

Hello,

I'm having some trouble with current releases of coreboot on a
Supermicro H8DMR-i2.

The initial problem, it takes about 2 minutes to show the:
coreboot-4.0-r5775 Fri Sep  3 14:55:01 CDT 2010 starting...
and equally as long after the warm reset.

The second, the system freezes at Clearning initial memory region: for
about a half hour before proceeding.  After that, everything works as
expected.

There has been some list chatter about a similar problem with the H8DME,
but that was based upon the H8DMR code so it's odd that it found it's
way here.  I've attached the full serial output if that's at all useful.

Vitals:
Vendor: Supermicro
MainBoard: H8DMR-i2
NorthVBridge: Fam10h
SouthBridge: NVIDIA MCP55
Super I/O: Winbond™ W83627EHG
CPU: AMD Opteron

Any suggestions are welcome, TIA,
Nicholas Lemberger

---snip---
coreboot-4.0-r5775 Fri Sep  3 14:55:01 CDT 2010 starting...

BSP Family_Model: 00100f23 
*sysinfo range: [000cc000,000cdfa0]
bsp_apicid = 00 
cpu_init_detectedx =  
microcode: equivalent rev id  = 0x1022, current patch id = 0x
microcode: rev id (1062) does not match this patch.
microcode: Not updated! Fix microcode_updates[] 
POST: 0x33
cpuSetAMDMSR  done
POST: 0x34
Enter amd_ht_init()
AMD_CB_EventNotify()
 event class: 05
 event: 1004
 data:  04  00  00  01 
AMD_CB_ManualBUIDSwapList()
AMD_CB_EventNotify()
 event class: 05
 event: 2006
 data:  04  00  02  ff 
Exit amd_ht_init()
POST: 0x35
cpuSetAMDPCI 00 done
cpuSetAMDPCI 01 done
Prep FID/VID Node:00 
  F3x80: e600a681 
  F3x84: a0e641e6 
  F3xD4: c3310f23 
  F3xD8: 03001b12 
  F3xDC: 542c 
Prep FID/VID Node:01 
  F3x80: e600a681 
  F3x84: a0e641e6 
  F3xD4: c3310f23 
  F3xD8: 03001b12 
  F3xDC: 542c 
setup_remote_node: 01 done
Start node 01 done.
POPSOSTT: :0 0xx3630

Co rcoer0 es0:t ar t--e-d :{   0A1PI
 sItD a=rt _04o thNeODrE_cIoD r=es (01) 
oOinREiIt Dn =o de00:} 0 0-- - c
:rmiesc:ro c03o de
 S etqarutiv aotlhenetr  creovre  id-  n o= de0ix1d0: 202,0  
ccurorreesnt:  0p3at
::i niidt  =n o0dex0: 10 0 PPPOO0cO0oSSSTrTT
  :es   m0:00ixxcx r0333o0300 c

o
 
 dSe   :ccctoooa reeetexx xv :::o  ti hd   --e -(r --1  0 c6{o{{
r 2 )AAAePP  Pd-IIICCCo eInIIDoDsDd===eni OcOR00d0:21 3m   
0NNaNtOO1O DDcDhEE EcII ItDDoD  r h=ei==s   s00: 0p 000   a0tC3CCO
OI  hRREEE.PII
--:-: -  e i:===crPPPOox231OOS}SSc3}}  T TTo7:d
x 0-00:sx t
 Na
   
cc 3330or00mmmiiitt
  
  
  c erudrr   oocccop dcaccooorraopoorddeeetd eeaeexxx:::d:p:: i! 
eece   Fqqiq--iuudu:ii---xi  v vv  {a{{ma*al O  
ilAceeAAeAPnPPrnnPtt ItIIoCCc  0C I1rIIorreeDseDDd  evv tv=a ==_  uii ri
 0d0pdd0t5e7 6d  a   d   N=Nt==N
2 2=22=02=D0*D0E xE[xExI1IA1I]1D 0D0DP0  2 
DtM, ,, 2c0s p0  0cc11tcu1Su uu 
aCCrerCOOttrOAeReeRReEEdMnEnnIttII
t-  D  DD  S*p pp=aa==R a At tt  00P0ccc hh2d h13} }  }o0 n3 i
ii-dd-es-d- -  -
r i-=-==
   n
t0
c0c00c00rfiexmmmi0i00itd_
_ s 5 r0ro0o00oi*cd c0c00o00ovAo0d0d00diPed e0e00:
  

nneetesmmmiiqaqtqiuacccuguieiiooov2vvtaaeccca loalldooddedpee
d eeneit:ctt*:: i  drrrArrree:eeePe  vv0  0iii4ii6ids
1)0  0   ( ( a(=11=r1= 0 00 t0e06066x2dx2x21)1)
 t ttt 02*2dd2d2o 2oo2,e,eA,e ss sP c c  c unu0unnroor7rortrttrsete e 
nmanmnmtatarta t t ttecpcpcpadhahaht t
hh cc
3000   i  iiisPsiisd d O d  p pSpaT==a=a tt:  t0ccc 00xxxhhh00x00...

0
0mm0m0i0
r   0ii0cc00c
ceccoo00oBoo0


  ogdiddmmmieiiene: c:cc:r  Fr roNoNNIoccocooDoVotott  dId deuuueDe:
:ppp: d M ddraarSraetetteRv eveev  0d dd!!iix!id   ddc 0 FFF
(i(0(ii1xx11x10   00060mmm662227iii)c))1ccrr r  
d0oododooxccoceoee2ooddsdss0eae e  nn_6_n_ouoou0up1tptth0h1 d 
mmaa4maatatt at0teteesscxcsch[[[h4h c ]]] tt0t   h

i
teetctctccc p p 0ppuupup3a aSSaSte
SD  cthAhAhAPOMMM...
M
 MM
nodededemSSiR iRiRc c 0c rrxr   o3dooddco9occoonon
eP: e
   :

avvavtit i iinnNTNnNoiiio:ott  0  ___ufxuuffiipi3ppdada

tiieddeedEddnd___ss!!!sd ttt   
FFFaaaFiiiIgggeexxxDe2nneeep0ppuuu1S1SSeee4t ttAAA0MxMMDDD4McMMSSS0RR0R   4c0   
d3ddooo n
m
 
 c
d_ipiinn5ni5iittt__n__fffuimiiddd:v0vviii1dd
  __ssstttaaagggeee222   aaapppiiiccciiiddd:::   000765


POST: 0x3b
fill_mem_ctrl()
POST: 0x3d
POST: 0x40
raminit_amdmct()
raminit_amdmct begin:
 Node: 00  base: 00  limit: 3ff  BottomIO: e0
 Node: 01  base: 420  limit: 81f  BottomIO: e0
 Copy dram map from Node 0 to Node 01 
raminit_amdmct end:
POST: 0x41
v_esp=000cbf38
testx = 5a5a5a5a
Copying data from cache to RAM -- switching to use RAM as stack... Done
testx = 5a5a5a5a
Disabling cache as ram now 
Clearing initial memory region: 




-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] Coreboot on the Asus P4PE

[Nick Stallman]

Hi

I just checked around a bit and saw that at least part of my motherboard is
supported by Coreboot but its not on any of the lists.

Its a Asus P4PE. A old Pentium 4 motherboard with a Intel 82845PE MCH
northbridge and a Intel 82801DA ICH 4 southbridge.

Attached is the output of various commands.

How much work is required to get Coreboot going on it and whats the likely
hood of borking it?
I've got two of these motherboards so killing one is ok but I do prefer them
working. :)

Thanks
Nick
localhost flashrom # ./flashrom -V
Calibrating delay loop... 512M loops per second. OK.
No coreboot table found.
Found chipset ICH4/ICH4-L, enabling flash write... OK.
Probing for Am29F040B, 512 KB
probe_29f040b: id1 0x0, id2 0xf8
Probing for Am29LV040B, 512 KB
probe_29f040b: id1 0x0, id2 0xf8
Probing for Am29F016D, 2048 KB
probe_29f040b: id1 0xff, id2 0xff
Probing for AE49F2008, 256 KB
probe_jedec: id1 0xbf, id2 0x60
Probing for At29C040A, 512 KB
probe_jedec: id1 0xbf, id2 0x60
Probing for At29C020, 256 KB
probe_jedec: id1 0xbf, id2 0x60
Probing for At49F002(N), 256 KB
probe_jedec: id1 0xbf, id2 0x60
Probing for At49F002(N)T, 256 KB
probe_jedec: id1 0xbf, id2 0x60
Probing for EN29F002(A)(N)T, 256 KB
probe_jedec: id1 0xbf, id2 0x60
Probing for EN29F002(A)(N)B, 256 KB
probe_jedec: id1 0xbf, id2 0x60
Probing for MBM29F400TC, 512 KB
probe_m29f400bt: id1 0x0, id2 0x0
Probing for MX29F002, 256 KB
probe_29f002: id1 0xbf, id2 0x60
Probing for MX25L4005, 512 KB
generic_spi_command called, but no SPI chipset detected
Probing for MX25L8005, 1024 KB
generic_spi_command called, but no SPI chipset detected
Probing for MX25L3205, 4096 KB
generic_spi_command called, but no SPI chipset detected
Probing for S25FL016A, 2048 KB
generic_spi_command called, but no SPI chipset detected
Probing for SST25VF040B, 512 KB
generic_spi_command called, but no SPI chipset detected
Probing for SST25VF016B, 2048 KB
generic_spi_command called, but no SPI chipset detected
Probing for SST29EE020A, 256 KB
probe_jedec: id1 0xbf, id2 0x60
Probing for SST28SF040A, 512 KB
probe_28sf040: id1 0x0, id2 0xf8
Probing for SST39SF010A, 128 KB
probe_jedec: id1 0xbf, id2 0x60
Probing for SST39SF020A, 256 KB
probe_jedec: id1 0xbf, id2 0x60
Probing for SST39SF040, 512 KB
probe_jedec: id1 0xbf, id2 0x60
Probing for SST39VF020, 256 KB
probe_jedec: id1 0xbf, id2 0x60
Probing for SST49LF040B, 512 KB
probe_jedec: id1 0xbf, id2 0x60
Probing for SST49LF040, 512 KB
probe_jedec: id1 0xbf, id2 0x60
Probing for SST49LF020A, 256 KB
probe_jedec: id1 0xbf, id2 0x60
Probing for SST49LF080A, 1024 KB
probe_jedec: id1 0xff, id2 0xff
Probing for SST49LF002A/B, 256 KB
probe_jedec: id1 0xbf, id2 0x60
Probing for SST49LF003A/B, 384 KB
probe_jedec: id1 0xbf, id2 0x60
Probing for SST49LF004A/B, 512 KB
probe_jedec: id1 0xbf, id2 0x60
SST49LF004A/B found at physical address 0xfff8.
Flash part is SST49LF004A/B (512 KB).
No operations were specified.
localhost superiotool # ./superiotool -d
superiotool r3064
Found ITE IT8708F (id=0x8708, rev=0x0) at 0x2e
Register dump:
idx 07 20 21 22 23 24 25 26  27 28 29 2a 2e 2f
val 02 87 08 00 00 00 00 00  1c f0 00 01 00 00
def NA 87 08 00 00 NA 3f 00  ff ff ff ff 00 00
LDN 0x00 (Floppy)
idx 30 60 61 70 74 f0 f1
val 01 03 f0 06 02 00 80
def 00 03 f0 06 02 00 00
LDN 0x01 (COM1)
idx 30 60 61 70 f0
val 01 03 f8 04 00
def 00 03 f8 04 00
LDN 0x02 (COM2)
idx 30 60 61 70 f0 f1 f2 f3
val 01 02 f8 03 00 50 01 7f
def 00 02 f8 03 00 50 00 7f
LDN 0x03 (Parallel port)
idx 30 60 61 62 63 64 65 70  74 f0
val 01 03 78 07 78 00 80 07  03 0b
def 00 03 78 07 78 00 80 07  03 03
LDN 0x04 (SWC)
idx e0 e1 e2 e3 e4 e5 e6 e7  f0 f1 f2 f3 f4 f5 f6
val e0 6f 00 00 00 00 00 00  80 80 31 00 80 00 00
def NA NA 00 00 00 00 00 00  00 00 00 00 00 NA NA
LDN 0x05 (Keyboard)
idx 30 60 61 62 63 70 71 f0
val 01 00 60 00 64 01 02 0c
def 01 00 60 00 64 01 02 00
LDN 0x06 (Mouse)
idx 30 70 71 f0
val 01 0c 02 00
def 00 0c 02 00
LDN 0x07 (GPIO)
idx 70 b0 b1 b2 b3 b4 b5 b8  b9 ba bb bc bd c0 c1 c2  c3 c4 c5 c8 c9 ca cb cc  
cd d0 d1 d2 d3 d4 d5 d6  d7 d8 d9 da db dc f0 f1  f2 f3 f4 f5 f6 f7 f8 f9  fa 
fb fc
val 00 00 00 00 00 00 00 00  00 00 01 00 00 00 00 1c  f0 00 01 00 00 1c f0 00  
01 00 00 00 00 00 00 00  00 00 00 00 00 00 ff 7f  7c 01 f0 0e 00 00 00 00  00 
1c 00
def 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  
00 00 00 00 00 00 00 00  NA NA NA NA NA NA 00 00  00 00 00 00 00 00 00 00  00 
NA 00
LDN 0x08 (Game port)
idx 30 60 61
val 01 02 00
def 00 02 01
LDN 0x09 (Consumer IR)
idx 30 60 61 70 f0
val 00 03 10 0b 06
def 00 03 10 0b 00
LDN 0x0a (MIDI port)
idx 30 60 61 70 f0
val 01 03 30 0a 40
def 00 03 00 0a 00
localhost ~ # lspci -nnvvvxxx
00:00.0 Host bridge [0600]: Intel Corporation 82845G/GL[Brookdale-G]/GE/PE DRAM 
Controller/Host-Hub Interface [8086:2560] (rev 02)
Subsystem: ASUSTeK Computer Inc. Unknown device [1043:80b2]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status