>25P05VP >ST 9520N 512 Kbit, serial Flash memory, 50 MHz SPI bus interface 512 Kbit = 64 Kbytes <- that should be the dump size, IMO… >(There is a circular divot in the bottom left corner of this chip. Is that normal?) If it’s small – it marks pin #1, I guess. AT25F1024 - 1 M-bit, SPI Bus Serial Flash 1 M-bit = 128 Kbytes <- that should be the dump size for Ericchak Ericchak, Please, correct if I’m mistaken I think it’s defective NIC still. Could you get a replacement?
I bought it off of ebay. It was allegedly, new, never used. It came in retail package and everything. I've emailed the seller to see if I can exchange/return. He has multiple listings for the same item, so I'm hoping an exchange would be possible at the very least. This is disappointing. I looked at the eeprom dump. It only appears to have dumped the small amount of data that was on screen when I chose to dump the file... not the full eeprom. I will try again, and see if I can get it to dump the full eeprom or if that is the true size. Edit: I looked around all the eeupdate options. some info from eeupdate: EEPROM Size: 64 words EEPROM Type: Microwire EEPROM Addressing: 6 bits image version: unversioned device id: 0000 vendor id: 0000 Again, I went to Raw eeprom option that displays the first 64 words. Then I went to the Raw eeprom extended entry, and it appears there is only the 64 words in the entire eeprom. The dump reflects the same. No clue why the eeprom would be so small. I then tried ibautil -defaultconfig, followed by ibautil -FE. It still states it is not supported.
I guess, EEPROM is where NIC config is stored (similar to CMOS on PC), including info weather PXE enabled or not. If somebody has NIC handy, he can dump EEPROM twice with PXE enabled and not. Should be only 1 byte changes (plus CRC?) But that byte might be different for different PXE ROM versions. Where are you anyway – I do have spare NIC. I hope it's not too expensive to mail it Please, do not replay here - PM me instead!
I checked in 501. Flash is set to enabled, and size is set to 128 Kbytes. I still get the same error that there is no supported Flash. This doesn't make any sense to me? Maybe it's a new hardware revision or something? Edit: So this is kind of interesting. I started messing around with that eeupdate 501 program. I decided to set the eeprom to disabled. After doing so - ibautil stated that flash was disabled. I then went back into eeupdate 501, and re-enabled the flash at 128k. Ibautil now stated "restart required" under flash type. After restarting, ibautil went back to "flash not supported". EEupdate501 confirmed that flash was enabled. If there is no flash, why can it disable/enable it? It's so weird. It seems like I can enable/disable the flash, but for some reason ibautil won't recognize it to flash it.
Wanna switch gears back. >Both the RSDT and XSDT are located in the F0000 memory region, which the Intel chipsets mark as read-only. So, the patch procedure runs, but it never actually changes the memory regions. I was wondering, notebook [un]docking operation - does it change both RSDT and XSDT or not?
I don't know too much about notebooks. I'm a big-case guy, but.. Hmm. Maybe, but I wouldn't ... think ... so. If they were in the F000 region, that would mean that they would have to be un-protected then re-protected, which seems like the hard way to do that. All the RSDT and XSDT do is hold a set of entry-pointers to all the lesser ACPI tables. I would think they'd just have all the relevant tables linked/created during BIOS boot, then only change the lesser tables, rather than the highest two. Plus, if they put the xSDT tables in high-address memory, they could change them without poking at the F000 protection registers in the northbridge/CPU(in the i5/i7 case). I believe the OS does the handling of dock/undock, rather than the BIOS. a best guess, -tij-
Code: XPS 420 Table NameOEMID&TableIDAddress LenthDescription Table (ACPI 2.0) RSD PTR DELL 000FEBF1 36Root System Desc.Pointer | |- RSDTDELL B9K 000FD032 68Root System Desc.Table 0x44 | | | 00 |- FACP DELL B9K 000FD146 116// 0x74 | 01 |- SSDT DELLst_ex FFF5DB88 172 | 02 |- BOOT DELL B9K 000FD340 40 | 03 |- MCFG DELL B9K 000FD368 62 | 04 |- HPET DELL B9K 000FD3A6 56 |* 05 |- SLIC DELL B9K 000FD3DE 374Software Licensing Desc.Table | 06 |- OSFR DELL B9K CFE55C00 124 | 07 |- APIC DELL B9K 000FD2AE 146 | |- XSDTDELL B9K 000FD09A 100Extended System Desc.Table | 00 |- FACP DELL B9K 000FD1BA 244 01 |- SSDT DELLst_ex FFF5DB88 172 02 |- APIC DELL B9K 000FD2AE 146 03 |- BOOT DELL B9K 000FD340 40 04 |- MCFG DELL B9K 000FD368 62 05 |- HPET DELL B9K 000FD3A6 56 06 |- OSFR DELL B9K CFE55C00 124 * 07 |- SLIC DELL B9K 000FD3DE 374Software Licensing Desc.Table Code: Latitude D430 Table NameOEMID&TableIDAddress LenthDescription Table (ACPI 1.0) RSD PTR DELL 000FC0E0 20Root System Desc.Pointer // 00-01-01.bin C0E0 | |- RSDTDELL M07 7F681A0E 68Root System Desc.Table // 54FD | 00 |- FACP DELL M07 7F682800 116 // 5541 01 |- HPET DELL M07 7F682F00 56 // 57A1 02 |- APIC DELL M07 7F683000 104 // 55B5 03 |- ASF! DELL M07 7F682C00 126 // 56E5 04 |- MCFG DELL M07 7F682FC0 62 // 5763 * 05 |- SLIC DELL M07 7F68309C 374Software Licensing Desc.Table // 57D9 06 |- TCPA DELL M07 7F683300 50 // 59FD 07 |- SSDT PmRefCpuPm 7F681A95 1244 For notebook, only RSD PTR in F0000 region, everything else is in 7F681A00 I guess, 7F681A00 is also read-only - any easy way to tell? >I believe the OS does the handling of dock/undock, rather than the BIOS. IMO, supposed to be OS <-> ACPI <-> dock/undock... Again, not sure if any any ACPI tables gets changed - can somebody test and upload RW-everything reports.
Right. ACPI generates an event, that the OS detects and then calls a function embedded in the ACPI tables to re-enumerate, I think. Well, good. That, at least, sounds like what I was talking about, with them avoiding the F000 range for dynamic tables. I think the 7xxxxxxx range should be non-read-only. A nice quick way to tell would be to load WindSLIC into that BIOS, since it should work on that memory range. Sounds like notebooks might be the better Dell candidates for WindSLIC-style mods, while the desktops can use super-static or something similar. -tij-
It's always been two chips in my experience, at least with the Intel NICs. Dell likes to do stuff its own unique way, but.. At least one [non-Dell, Server] motherboard I looked at had the EEPROM on the board as a discrete chip physically next to the embedded NIC chip. I'm assuming that's the usual case. The NIC doesn't know any EEPROM "address" in this case since the EEPROM is hard-wired directly to pins on the NIC chip, rather than anywhere else. -tij-
Ok... This's very logical/easiest way, but resource wasteful somewhat There is thread here, talking about loosing MAC address (i.e. set to all FF) after "wrong" AWARD BIOS flash on Dell Inspiron 530. How could happen if MAC is in EEPROM? Not sure if Inspiron 530 is Intel or Broadcom...
My Dell 200 had this problem before all ff, (530 is same as 200, board from foxconn), they use Intel. I use eeupdate -mac to recover the MAC address, that's the reason I found the eeupdate. (only 503 version of eeupdate can recover the onboard Intel)
>I use eeupdate -mac to recover the MAC address I.e. it does have separate EEPROM chip! Eric, I assume, Dell 200 is AWARD also. Did you you replace SATA ROM? Have you found a way to enable WoL? Sorry for offtopic, guys...