A road named NoNameUno

In the past I only used kernel apis to probe and use PCI related resources. The fun or the dumb part of it is that most of the stuff is done for you, and in most cases it is pretty routine to get those resources and use it... But currently, I was using pci scan and configuration probing to get some data out of it. Depending on the chipset, the information I get or the programmable interface I have to the chipset could be pretty raw and complicated. Usually these chipsets are quite powerful, having multiple processors and couple mega bytes of storage. This is mainly due to few convergence, in my case it was fiber channel and network interface together. In my case, I was probing for manufactures data, including 8 to 10 boot codes that are burned into EEPROM or NVRAM or Option ROM. PCI spec gives 256 bytes of CPI config space, and often vendors don't use all of it, so informations are missing, on top of it, the x (0x78) is not placed at the end of the space, instead it is placed somewhere in the middle. Any processing could just go read the whole space or stop at the end marker. But the main part is to read the PCIR(PCI ROM) structure to find what are the boot codes and their versions. Fun part is that PCI recommends that from base address, at 0x18 would have the PCIR pointer, and form their respective boot code image informations can be retrieved. But when option rom or nvram space is tight, it could no longer be true. Finding these offset is quite challenging, and UEFI diagnostic tools are quite handy. Once that was found the 4 bytes entity could be in big endian format or otherwise. So that requires yet another hack to find out if we need a byte swap or not. Well, it is no fun when I started, but once all the informations are found without using the flawed informations provided by the docs, it turns out to be fun!