You’re probably using the wrong source…“include/asm-generic/io.h” definitely exists. I can’t answer whether what you are doing is correct or not, but you can start with making sure you’re using the right source.
If you have the driver package (which produces the host side “Linux_for_Tegra/” subdirectory), then you will have the script “source_sync.sh”. I’m going to suggest doing this on the Jetson itself to avoid cross compile issues (you can switch to PC host cross compile if you’re sure the rest is correct). Copy “source_sync.sh” to some location on the Jetson you want to build from. I actually put it in “/usr/local/src/” (which also implies “sudo” is needed to operate there since it is owned by root…but then I’ve used “chown” to change it to owner “ubuntu” and no longer need sudo). My example uses “/usr/local/src/”, but it could be anywhere.
# From the host PC with the driver package...
scp source_sync.sh ubuntu@<your_jetson_IP_address>:~/Downloads
# From user ubuntu login on the Jetson...
sudo mkdir /usr/local/src
sudo chown ubuntu.ubuntu /usr/local/src
cp ~/Downloads/source_sync.sh /usr/local/src
chmod u+x source_sync.sh
./source_sync.sh -u tegra-l4t-r28.2
# You now have "sources/" subdirectory and kernel within that...
You could do the same thing from some other temporary location for testing first and then delete it, or you could use source_sync.sh from your PC in the same way. Regardless of where you run source_sync.sh from you will have this subdirectory content:
Using “/usr/local/src/” as my example you could add this in order to make “<asm-generic/io.h>” available (this would be one of the options to the “cc” or “gcc” command):
You might still be mixing things together which shouldn’t be mixed, but see where this takes you. Are you using some third party code not in the kernel tree? If so, do you know which kernel version that code was intended to run with (the Jetson is using a 4.4.x kernel)?
A comment on the topic, but a bit generic, is that some of the earlier kernels did not use the IOMMU for virtual addressing on PCIe. This meant that all of the earlier code would use physical addresses in many places where current code requires a mapping to virtual addresses. If the code previously in place tries to use an address which is a physical addres…which is in reality being remapped to a virtual address through the IOMMU…then you will crash and burn. Make sure any address you are looking at hasn’t been remapped to a virtual address while still attempting to use a physical address. Errors listed in “dmesg” after an attempt to read/write might offer a clue to this.