dfa1a4fbf9
signalled when the attribute address for the CF is 0 in the octeon sysinfo structure. In this mode, the DATA port is 16-bits, but the other ports are 8-bits, but on a 16-bit bus (so you have to access it a short at a time, but only believe the lower byte). See the code for more details on this slightly odd arrangement. I'm still not 100% happy with the abstractions here on many levels (starting with the globals for these settings, on down to no bus_space use, etc), but the driver had these problems before the change. Also, clean up the code a bit to make this support easier, and the code a bit easier to read. I tried to follow existing style, but may have missed a few spots. Add some comments. Fix probe/attach routine to return a proper error for the simulator. With this change, my EBH5200 eval board now recognizes the CF well enough to boot to the login prompt. Before it would say it never became ready. My CN3010-EVB-HS5 still boots properly. My older CN3860-based board won't load the 64-bit kernel, either before or after the change, and I didn't chase that down. |
||
---|---|---|
.. | ||
cryptocteon | ||
octe | ||
usb | ||
asm_octeon.S | ||
ciu.c | ||
cvmx_config.h | ||
files.octeon1 | ||
if_octm.c | ||
obio.c | ||
obiovar.h | ||
octeon_ds1337.c | ||
octeon_ebt3000_cf.c | ||
octeon_machdep.c | ||
octeon_mp.c | ||
octeon_nmi.S | ||
octeon_pcmap_regs.h | ||
octeon_rnd.c | ||
octeon_rtc.c | ||
octeon_wdog.c | ||
octopci_bus_space.c | ||
octopci.c | ||
octopcireg.h | ||
octopcivar.h | ||
std.octeon1 | ||
uart_bus_octeonusart.c | ||
uart_cpu_octeonusart.c | ||
uart_dev_oct16550.c |