Hallo Piotr:
> I don't understand why you are bringing this issue again. We have already > [...] Thanks for your help. There are a few issues left, but it looks like we're almost there. We have talked about the following problems before too, but I think they have not been fixed yet (or at least fully clarified): 1) An "#ifdef CYGHWR_DCACHE_SIZE" or similar fix is needed in order to prevent compilation errors when the Instruction or Data Caches are turned off in the Redboot configuration. 2) The code accesses SPR_MACLO and SPR_MACHI whether the CPU implements a MAC unit or not. This causes exceptions in my current OR10 implementation, and I wouldn't want to turn such exceptions off, as they have helped me several times to find other software problems. Possible ways to fix this are a new Redboot configuration (your favoured option if I remembered well), or a runtime check (there is a CPU config SPR). 3) There is no easy way to turn off optimisation in order to help debugging. In my automated test suite, I'd like to build without optimisations (with -O0 insted of -O2), in order to get better crash dumps if a test fails. Changing this option in an automated manner is difficult, as the tool would need to specify not only "-g -O0", but the rest of the flags too, which get derived from other configuration options. You can do this manually with the configuration menu, but the orbuild framework cannot use such interactive menu applications easily. Therefore, if orbuild replaces the settings, any then any future changes to the other flags (like -fno-rtti) will be overwritten. This is a nice-to-have feature that would help me save effort. The best way would be to separate such optional compiler and linker settings from the other required settings, that is, some separate USER_COMPILATION_FLAGS or GCC_OPTIMISATION_FLAGS config settings. We need to pass those to the linker too, for example, when using Link-Time Optimisation (LTO). I think that's it, everything else is working fine on my PC, at least what I've tried with Redboot. Thanks, rdiez _______________________________________________ OpenRISC mailing list [email protected] http://lists.openrisc.net/listinfo/openrisc
