My LPC-ISA bridge device ID is 0x790E, rev id 0x4A, it should be codenamed YangTze.
I'm trying to read the SPI ROM by programming SPIBAR, however, when I set the Command byte (SPIBAR + 0x0) to Read (0x3) / Fast Read (0xB) , the illegalAccess bit is automatically set by hardware, even though I haven't set the ExecuteOpCode bit, and once I try to set ExecuteOpCode bit, it is failed, and nothing get executed or returned in the FIFO queue ( SPIBAR+ 0x80 )
The illegalAccess bit is cleared when I set the Command Byte to other command code, for example, 0x9F, which read the JEDEC ID, and the data is returned in the FIFO queue ( SPIBAR + 0x80 )
I've also checked restricted command , there's all 0 but 6 (WR_EN) is restricted, so It shouldn't be affected by this.
Here is the dump of SPIBAR in my machine.
I have recently bumped into the same issue, also with Yangtze. From the SPIBAR dump you have attached I can clearly see that the SpiAccessMacRomEn (bit22) and SpiHostAccessRomEn (bit23) are cleared in the SpiCntrl0 register (SPIBAR + 0x00). If any of those two bits are cleared, all of the SPIRestrictedCmd (SPIBAR + 0x04/0x08) as well as SPI_CmdValue registers (SPIBAR + 0x10/0x14/0x18) are effective. Additionally, if SpiAccessMacRomEn is set, the software cannot access the lower 512KB of the SPI flash. That is why you cannot access the SPI flash, because the hardware detects an attempt of illegal access. If the SpiAccessMacRomEn (bit22) and SpiHostAccessRomEn (bit23) are cleared by the firmware/BIOS then you would have to patch/modify you BIOS, because these bits are clear-once and may be set to 1 only by a platform reset. If not cleared by BIOS, just keep these bits set and your SPI access software should work.