SFI systems support
Moderator: Moderator Team
SFI systems support
SFI (Simple Firmware Interface) is a firmware standard, used for some Intel Atom - based devices (x86 tablet PC and smartphones). It used on Moorestown and Medfield platforms, and may be some else.
SFI is like 'minimal ACPI', it uses its own SFI tables to describe hardware. SFI systems does not have legacy BIOS or UEFI.
Most of this devices was supplied with old Android and completely outdated and useless for now, with ReactOS they can become little more useful.
Anyone interested with adding SFI support to ReactOS? I have a lot info about it and can help with development, but solo development will take too much time.
SFI is like 'minimal ACPI', it uses its own SFI tables to describe hardware. SFI systems does not have legacy BIOS or UEFI.
Most of this devices was supplied with old Android and completely outdated and useless for now, with ReactOS they can become little more useful.
Anyone interested with adding SFI support to ReactOS? I have a lot info about it and can help with development, but solo development will take too much time.
- binarymaster
- Posts: 481
- Joined: Sun Nov 16, 2014 7:05 pm
- Location: Russia, Moscow
- Contact:
Re: SFI systems support
Not sure whether I'm interested with it or not, but it will be a lot more useful if you post all links to the documentation you have, and a list of particular hardware devices would be useful too, so one can start investigating it.
Also one more question, do these devices have a vendor-locked firmware? If yes, it will not be possible (or will be complicated) to run any other OS than preinstalled one.
Also one more question, do these devices have a vendor-locked firmware? If yes, it will not be possible (or will be complicated) to run any other OS than preinstalled one.
by Stas'M | https://github.com/binarymaster
-
- Developer
- Posts: 246
- Joined: Fri Dec 19, 2014 10:00 pm
Re: SFI systems support
This is something that would hardly benefit anyone, so it would be better off in your own fork.
- binarymaster
- Posts: 481
- Joined: Sun Nov 16, 2014 7:05 pm
- Location: Russia, Moscow
- Contact:
Re: SFI systems support
That would make sense also because our support for different platforms on the same CPU architecture is a bit hacky, and officially we are building only ISO images for the PC/AT platform right now.
Once we become more mature in this context (you probably know we're also trying to bring up support for OG Xbox and NEC PC-98 platforms), any changes from the forks might be upstreamed.
by Stas'M | https://github.com/binarymaster
Re: SFI systems support
Almost all info - from linux sources like this:
https://code.woboq.org/linux/linux/incl ... sfi.h.html
and reverse engineering.
Also i have SFI specification in pdf, but links is dead. I can attach it if need, but its content almost equal to sfi.h.
Some googling: OpenPeak, Cisco Cius, Motorola Razr i XT 890, Lenovo K900, Asus Tablet 810.
Not sure about all devices, but my device is locked. But it is old android, with root I can run anything via linux kexec API.binarymaster wrote: ↑Thu Aug 12, 2021 12:00 pm Also one more question, do these devices have a vendor-locked firmware?
- binarymaster
- Posts: 481
- Joined: Sun Nov 16, 2014 7:05 pm
- Location: Russia, Moscow
- Contact:
Re: SFI systems support
Ok I have created a wiki page for this:Xen wrote: ↑Thu Aug 12, 2021 6:12 pm Almost all info - from linux sources like this:
https://code.woboq.org/linux/linux/incl ... sfi.h.html
and reverse engineering.
Also i have SFI specification in pdf, but links is dead. I can attach it if need, but its content almost equal to sfi.h.
https://reactos.org/wiki/SFI
Not sure about these two devices:
- Asus Tablet 810 is based on Intel Atom Z2760 which belongs to Clover Trail platform.
- Lenovo K900 is based on Intel Atom Z2580 which belongs to Clover Trail+ platform.
Do these platforms implement SFI too? It's also notable Asus VivoTab TF810C has Windows 8 preinstalled (means Windows supports SFI devices?).
by Stas'M | https://github.com/binarymaster
Re: SFI systems support
Windows never supported SFI, it was only supported by Linux. Whether a platform uses SFI or UEFI/ACPI depends from vendor.binarymaster wrote: ↑Sun Aug 15, 2021 6:08 pm Do these platforms implement SFI too? It's also notable Asus VivoTab TF810C has Windows 8 preinstalled (means Windows supports SFI devices?).
Maybe that could be helpful too, at least for some devices: https://github.com/alef78/intel-ifwi-study
Re: SFI systems support
SFI basics:
Boot:
SFI systems uses NAND flash to store OS bootloader. First sector of the OS bootloader contains structure that describes its loading parameters - start address, size (any size - no 512 bytes limit), entry point, security signature.
FW loading and running OS bootloader in x32 protected flat mode (physical addresses equals to virtual), same as linux kexec.
You should be very careful with the bootloader - corrupting of the bootloader will brick device without easy recovery ways.
My device have another MMC flash to store main OS, also external SD card can be used to load OS.
Most important SFI tables:
Describes hardware resources and devices.
SYST table - root of the SFI tables. Contains links to other tables;
MMAP table - memory map. records equals to UEFI EFI_MEMORY_DESCRIPTOR;
CPUS table - enumerates processor cores. Each record contains local APIC ID of corresponding core.
APIC table - phys addr of the IO APIC. SFI system does not support legasy interrupt controller.
MTMR table - SFI timers. Each timer can be configuret to generate interrupts with specified period. SFI system does not support legacy or multimedia timer.
MRTC table - real time clock. SFI RTC registers equals to legacy CMOS RTC, but uses memory mapped access instead of IO ports.
SFI RTC can generate alarm interrupt but cant generate periodic interrupt. One of the MTMR timers should be used to generate 64 hz ints.
SPIB, I2CB - describes SPI and I2C devices.
XSDT table - equals to ACPI XSDT table, but contains only one MCFG record, that describes virtual PCI devices.
SFI system have only 2 real PCI devices (accessed via CF8 port) - 0:2:0 GMA600 video adapter and 0:0:0 PCI root. Unlike real PCI, MCFG table is just memory region, filled by FW with PCI-like records. Becouse of PCI bars does not contain size records, MCFG records using "Fixed Bars" extension to define its BARs sizes. Fixed bar can be any size, not only 2^x.
Any tips how to implement this?
Also SMBIOS table is present.
Boot:
SFI systems uses NAND flash to store OS bootloader. First sector of the OS bootloader contains structure that describes its loading parameters - start address, size (any size - no 512 bytes limit), entry point, security signature.
FW loading and running OS bootloader in x32 protected flat mode (physical addresses equals to virtual), same as linux kexec.
You should be very careful with the bootloader - corrupting of the bootloader will brick device without easy recovery ways.
My device have another MMC flash to store main OS, also external SD card can be used to load OS.
Most important SFI tables:
Describes hardware resources and devices.
SYST table - root of the SFI tables. Contains links to other tables;
MMAP table - memory map. records equals to UEFI EFI_MEMORY_DESCRIPTOR;
CPUS table - enumerates processor cores. Each record contains local APIC ID of corresponding core.
APIC table - phys addr of the IO APIC. SFI system does not support legasy interrupt controller.
MTMR table - SFI timers. Each timer can be configuret to generate interrupts with specified period. SFI system does not support legacy or multimedia timer.
MRTC table - real time clock. SFI RTC registers equals to legacy CMOS RTC, but uses memory mapped access instead of IO ports.
SFI RTC can generate alarm interrupt but cant generate periodic interrupt. One of the MTMR timers should be used to generate 64 hz ints.
SPIB, I2CB - describes SPI and I2C devices.
XSDT table - equals to ACPI XSDT table, but contains only one MCFG record, that describes virtual PCI devices.
SFI system have only 2 real PCI devices (accessed via CF8 port) - 0:2:0 GMA600 video adapter and 0:0:0 PCI root. Unlike real PCI, MCFG table is just memory region, filled by FW with PCI-like records. Becouse of PCI bars does not contain size records, MCFG records using "Fixed Bars" extension to define its BARs sizes. Fixed bar can be any size, not only 2^x.
Any tips how to implement this?
Also SMBIOS table is present.
- binarymaster
- Posts: 481
- Joined: Sun Nov 16, 2014 7:05 pm
- Location: Russia, Moscow
- Contact:
Re: SFI systems support
But does it mean if the platform uses UEFI and exposes both SFI and ACPI tables, it can boot Windows?
UPD: answering my own question. Yes, CloverTrail also uses SFI.binarymaster wrote: ↑Sun Aug 15, 2021 6:08 pm - Asus Tablet 810 is based on Intel Atom Z2760 which belongs to Clover Trail platform.
- Lenovo K900 is based on Intel Atom Z2580 which belongs to Clover Trail+ platform.
Do these platforms implement SFI too?
Source: https://community.intel.com/t5/Processo ... 862#M21116
by Stas'M | https://github.com/binarymaster
Re: SFI systems support
I think Windows would simply ignore SFI and work with ACPI (however I can't confirm as I don't have such device).binarymaster wrote: ↑Mon Aug 16, 2021 12:00 am But does it mean if the platform uses UEFI and exposes both SFI and ACPI tables, it can boot Windows?
- binarymaster
- Posts: 481
- Joined: Sun Nov 16, 2014 7:05 pm
- Location: Russia, Moscow
- Contact:
Re: SFI systems support
Thank you for the information, by the way feel free to update the wiki page I created for it.Xen wrote: ↑Sun Aug 15, 2021 11:21 pm SFI basics:
Boot:
SFI systems uses NAND flash to store OS bootloader. First sector of the OS bootloader contains structure that describes its loading parameters - start address, size (any size - no 512 bytes limit), entry point, security signature.
FW loading and running OS bootloader in x32 protected flat mode (physical addresses equals to virtual), same as linux kexec.
You should be very careful with the bootloader - corrupting of the bootloader will brick device without easy recovery ways.
My device have another MMC flash to store main OS, also external SD card can be used to load OS.
...
Also SMBIOS table is present.
You have to start with porting the FreeLoader.
Besides reading data from SFI tables, you will need the code routines for reading from storage, polling input devices, and drawing graphics on the screen. Also it would be hard to work without a serial debug port - you will have to implement support for it too, if we don't have any existing code for it. I think reading FreeLoader's platform-specific source code will answer most questions, and it's quite readable.
Feel free to ask any questions in our chat, there are several people who can answer these questions.
by Stas'M | https://github.com/binarymaster
Re: SFI systems support
Ofc Windows can just ignore SFI tables, if ACPI is exists, but they not. SFI platforms does not contain any tables except of SFI and SMBIOS.binarymaster wrote: ↑Mon Aug 16, 2021 12:00 am But does it mean if the platform uses UEFI and exposes both SFI and ACPI tables, it can boot Windows?
But there is some non-SFI devices, based on same chipset, as SFI - for example - moorestown and oaktrail platforms based on same SM35 chipset, but oaktrail is UEFI/ACPI platform and it can boot Windows natively.
I mean only "magic PCI" (CF8+MCFG) - how it can be implemented without modify of existing PCI drivers? As I wrote before, there is some UEFI/ACPI systems, based on same chipset as SFI (Fujitsu Q550 for example). How they did that magic without custom hal/pci drivers?
About video:
On SFI platforms VGA bios may not exists. For my research I made minimal graphics driver. Also there is some LEDs, that can be managed via SCU requests (only 2 ASM instructions to turn LED), I will post details later.
I looking for anyone, who have any device with GMA500/600 video with VGA BIOS, and can dump it.
SFI FW may be managed via MAX3111 (SPI to UART converter), but it may be hard to connect it.
From wiki:
On my platform, SFI XSDT table contains only MCFG table.ACPI support
SFI may expose full set of ACPI tables (via SFI XSDT table)
P.S. How to attach files here?
Last edited by Xen on Mon Aug 16, 2021 7:44 pm, edited 2 times in total.
- binarymaster
- Posts: 481
- Joined: Sun Nov 16, 2014 7:05 pm
- Location: Russia, Moscow
- Contact:
Re: SFI systems support
Windows pci.sys driver (as well as ReactOS pci.sys driver) relies on HAL, which is responsible to report information about PCI buses and devices to it (based either on PCI configuration space or MCFG table in this case).
HAL is also responsible for working with hardware timers, so it has to be implemented in it too.Xen wrote: ↑Sun Aug 15, 2021 11:21 pm SFI system does not support legacy or multimedia timer.
SFI RTC registers equals to legacy CMOS RTC, but uses memory mapped access instead of IO ports.
SFI RTC can generate alarm interrupt but cant generate periodic interrupt. One of the MTMR timers should be used to generate 64 hz ints.
So given that you don't need to modify pci.sys driver, you only need to build a HAL - of course you don't need to do it from scratch, you can base it on existing code.
Afaik ACPI tables also allow to override PCI bus devices - either restrict access to certain physical devices, or expose virtual devices that are not visible from PCI configuration space I/O ports.
I don't have a link to the corresponding ACPI documentation part that explicitly confirms this yet, but for example, when ReactOS is booted with legacy HAL, the HAL itself early enumerates PCI devices via CF8 port. And contrary to this, when it's booted with ACPI HAL, it does not perform this enumeration - you can see it for yourself by comparing debug logs.
So this corresponds to the "Minimal" ACPI tables case. What is your device by the way? It might be useful to get dmesg log from it.
Switch to full editor, there will be "Attachments" tab.
by Stas'M | https://github.com/binarymaster
Re: SFI systems support
About bootloader: SFI devices (at least my) using SD/MMC flash via PCI SD controller as main storage. I see at least 3 ways:
1 - add sdbus support to bootloader. As i know, there is no sdbus driver in ReactOS. WinXP ones should work, but not for bootloader. Also there is any restrictions about using public code from linux or EDK in ReactOS?
2 - make UEFI for SFI and use UEFI bootloader.
3 - boot via ramdisk, and then use existing WinXP drivers. Ramdisk boot is supported on WinXP, but it is supported on ReactOS too?
P.S. Noone else have any SFI device?
P.P.S. I still unable to find any "Attachments" tab.
1 - add sdbus support to bootloader. As i know, there is no sdbus driver in ReactOS. WinXP ones should work, but not for bootloader. Also there is any restrictions about using public code from linux or EDK in ReactOS?
2 - make UEFI for SFI and use UEFI bootloader.
3 - boot via ramdisk, and then use existing WinXP drivers. Ramdisk boot is supported on WinXP, but it is supported on ReactOS too?
P.S. Noone else have any SFI device?
P.P.S. I still unable to find any "Attachments" tab.
- EmuandCo
- Developer
- Posts: 4731
- Joined: Sun Nov 28, 2004 7:52 pm
- Location: Germany, Bavaria, Steinfeld
- Contact:
Re: SFI systems support
Likely because you are still in approval mode here.
ReactOS is still in alpha stage, meaning it is not feature-complete and is recommended only for evaluation and testing purposes.
If my post/reply offends or insults you, be sure that you know what sarcasm is...
If my post/reply offends or insults you, be sure that you know what sarcasm is...
Who is online
Users browsing this forum: Google [Bot] and 27 guests