Like the Raspberry π SoC is based on a television tuner box. The vast majority of the die is related to the TV tuner functions that are completely undocumented. What techniques exist to explore undocumented physical hardware? Are we limited to reverse engineering code to find when and how these undocumented areas are used, or are there other fuzzing type techniques to find relationships between memory, flags, and potential byte instructions?
This is an abstract thought and generalization that potentially patches a hole in my understanding. There is no broader purpose in asking.
Along with the other excellent answers, both boards and chips may be designed general purpose, but often components are disabled in hardware or are unpopulated. Sometimes, a jumper needs to be applied, a trace re-routed, or a JTAG command sent to activate debug mode which allows physical access to parts of a board/chip that are gated by the JTAG controller.
So your best friends here beyond fuzzing and probing are searching for similar schematics, painstakingly testing all I/O with an oscilloscope, and taking an electron microscope to things to see what’s physically there.
Sometimes though, it’s as simple as thinking like the engineers who designed the component in the first place and asking yourself “If I were designing this, what shortcuts would I take, what would I want to debug / put in a test suite, and what would I make general purpose in order to cut costs on component placement and board reuse.
I did not know JTAG was used like this, I thought it was passive in functionality
Even for debugging jtag is quite active. It can essentially (depending on the soc or micro you’re working with) override the device and force it into specific conditions or change register values.
Very useful.