I am working on RTL8139B controllers. As i have already talked about my friend, he is helping me alot. i will try both the flashing through BIOS and flashing by using certain hardwares like FPGA etc. i hope we can get it to work. one thing more my card is not same as the one in the link. this seems to be a new one while mine is really old. but both have same RealTek chip and a socket to place a ROM. I have got a ROM for it and i'll test it when i get back to home.
As far as i know only intel gives builtin ROM in its NICs. I never seen a card with prebuilt ROM. may be there are some but they would be expensive.
what is the exact model of compatible ROM for your card,how many kb does it handle and how much does it cost? I think this kind of ROM would fit on all the cheap NICs that have an empty slot for this add-on ROM chip
Since i have not tested it yet so i can't confirm you its functionality. But as soon as i successfuly mod it I will report to you. I'll also check its compatibilty for other NICs so it may become a one guide fits all scenario.
i have a spare ecs 865PE-A(V2.0) motherboard with "Realtek 8100C/8110 Family NIC" (that what i see in the nic driver) wanna test/kill my mobo? right now there is a modded bios with slic 2.1 on it but i can flash unmodded bios and then use your realtek nic mod i don't care if the ecs motherboard and the nic will die (i have a newer computer)
I burned the code into a 27c512 (EPROM) and inserted into a Realtec 8139 NIC. Did not work: Intel 975BX2 Mobo Dell 9150 DXP051 Mobo (The Intel would pass initial boot but hang while loading Windows XP and 7. The Dell would boot to Windows but SLIC was not detectable via Everest) Worked: Aopen AK73 Mobo (SLIC displayed using Everest) Both the Intel and Dell boards had heavily populated BIOS (ACPI tables and Option ROMS i.e. PXE and RAID). The Aopen had no options. SLIC Mod code probably needs more detail in locating available space. This is certainly an interesting concept and hope further work is done on it. I plan on ordering an Intel NIC and trying again. Will post results later this week. Edit: On the AOpen Mobo - The SLIC disappears after resume from Hibernation. This is a Windows XP machine so I don't know how this would affect Windows 7.
Yeah, that makes sense. That portion of the ACPI table is not being loaded back into RAM after hibernation. There are a lot of systems that have this same issue with loaders after hibernation, since a loader is doing just that, "loading" into RAM a SLIC. The NIC mod is basically doing the same thing, only at the hardware level, and since it is not coming from files on the drive there are no files to be detected or weird things like hundred meg partitions or other things. The NIC mod can just be system dependent though. Since the SLIC is loaded into memory before boot by the NIC, and it is not a "real" table like a BIOS mod would give. It's kind of hit or miss. Without customizing/correcting the memory locations of the SLIC for every machine that has this issue, there is no easy fix for this. And a location that works for one system may make another system crash or un-bootable. That's why the author of the ASM file chose a location that for the most part works with probably 75% to 85% of systems. I do not know on how feasible it would be to detect free locations to place a SLIC. I am guessing the only way this could be done is to make the script file detect this, and then write the ROM based on this. This would also make it MANDATORY that the ASM file be used to compile the custom rom on each person's own system (meaning everyone would HAVE to make their own) for the file to locate a clear spot for everyone who might use it.
That AOpen Mobo is fairly dated and has always exhibited strange behavior. It loses the SLIC only if a user is logged when it hibernates and then wakes. I really think this activation exploit deserves further examination .
Yes i have to do the same. Hence this does not remain a feasible solution for all since no one would buy a standalone Programmer, nor everyone is a professional in EEPROM programming, I have heard that there are some sockets with 32-pin capability, may be ATMEL at29c512 suits fit to them,
Brand new WindSLIC in development! I suspect it would work. Did you ever give it a go? BIG NEWS! I've been off in the lab for the past couple weeks, tearing apart the add_slic.asm and rebuilding it, bigger and meaner. I now have a new, more powerful, far scarier version, that I call WindSLICer, that will slic-mod an Intel DX48BT2 "Bonetrail" motherboard. The motherboard BIOS identifier is: BTX3810J.86A Right now the code is fairly alpha-quality (every new board I try it with requires changing something), but here's what it does differently: #1. Uses the chipset registers to de-write-protect important locations in memory that are (normally) write-protected by the BIOS. [This is why the Intel boards fail with the add_slic.asm version, I believe] #2. Instead of all this tomfoolery with squeezing a SLIC entry into the ACPI RSDT, it just de-protects the ACPI RSDP table (the "root" pointer table that points to the RSDT). #3. It hooks int15h,ax=e820 (the memory-allocation information interrupt that OSes use from the BIOS to determine which memory they may access) to reserve a 1K portion of high-address-space memory. .. with #1,#2,and #3 done, it then copies the RSDT to the new reserved spot, patches it there, and puts the desired SLIC right beside it, finally patching the RSDP to point to the all-new tables. The old tables stay dormant right where they were, so no worries about tearing them up [the old add_slic.asm loves to tear into the FACP table, but the code is kind of hard to decipher as to why it picks on that particular table]. The two big tricks that this routine has to deal with are: #1. It has to deprotect its own address space to allow it to update itself at boot. This requires finding the Intel datasheets that mention which PCI registers are needed to disable a particular chipset's RO protections. #2. It has to find and reserve a proper spot in high-address-space memory. So far, I've gotten it to do all those things, but the assembly has to be tweaked to understand different chipsets read/write protection mechanisms (Intel calls theirs the PAM0, PAM1, etc, registers (and they are different for each chipset, with some slight standarization lately). Does anyone know where to get that info for Nvidia chipsets or AMD chipsets? I haven't looked for AMD, but Nvidia is way too focused on graphics card development to have clear documentation for chipset registers on the main developer page. To do all this, I ended up writing: #1. a DOS acpi-dump utility (really, i modified a GPL one out of a part of the assembly code for the FDAPM dos ACPI-power-managment-util project) #2. a DOS int15h,ax=e820h memory map dumper. If you've booted Linux much, you've seen the "BIOS-e820:" lines in your boot/dmesg output. This program does the same thing in DOS. #3. some junk to let me do all this testing (and single-stepping (ouch!)) in the QEMU virtual machine environment using GDB (gnu debugger) [ewww.]. Keep on truckin, -tij-
Well it sounds like you've had your asskicker mode fully engaged! Sounds really exciting and promising! Too bad things are not more uniformly standardized across different chipsets. Guess that's just how it goes though. But I am glad you are making it so that more and more in the future can enjoy SLIC modded systems that before could not be done!