Hi, Yesterday I merged a couple of ARM fixes in mainline,2399. Some highlights are:
- OpenMoko Freerunner a.k.a. GTA02 works again after fixing a bug that has been present since the first HelenOS/arm32 port (invalidating pages from a unified TLB instead of the separate instruction and data TLBs on ARM920T). Interestingly, this bug became more likely to show with the introduction of kernel non-identity mappings a couple of years ago. Non-identity kernel mappings tend to stress the kernel a little more due to the increased mapping and allocator activity. Chances are that also the unofficial port to FriendlyARM mini2440 could now work too (because AFAICT it is basically the GTA02 turned evaluation board). I have one of these devices in front of me, but still did not find enough time to verify. - The introduction of RCU and CHT "broke" RaspberryPi support. When I investigated this, I noticed that the kernel spins infinitely in the atomic exchange built-in due to STREX always signalling failure. For some yet unknown reason, this was linked to the workaround of using the shared attribute for pages of normal memory because with non-shared pages the kernel would crash very early on. Because of this problem, ARMv6 represented an exception as it was the only ARM architecture which used shared pages (should be necessary only for SMP systems). I haven't figured out why STREX was failing when the page attribute was shared. In theory, with shared pages, the hardware should take care of some of the cache coherency issues itself. The connection to shared could have been only accidental or it had to do with the fact that RaspberryPi is a UP system and shared does not mean a thing to it. It is even possible that shared would be just fine after I fixed the problem with non-shared. See below. What helped to fix the non-shared case was invalidating the entire D-cache prior to enabling it in cpu_arch_init(). To me this makes sense, because so far we have only made sure to clean the D-cache, but never invalidated the clean and valid entries from it (on ARMv6-). This could have resulted in the disabled D-cache becoming increasingly incoherent with the main memory (think for example data on stack). The main memory would thus contain newer versions of the still valid, stale locations in the D-cache. A recipe for disaster when the D-cache gets re-enabled later. Btw, ARMv6 CPUs can have more levels of caches too, so a cache hierarchy is not ARMv7-specific. This is something to keep in mind. So far, HelenOS pretends ARMv6 has only L1 cache, except for the page walks which are set to use outer write-back non-shared normal memory. On a related note, it seems to me like we could turn I-cache on for RaspberryPi. - Finally I made the ARM port a little less ARMv7-centric. For example the cache-control operations are very different for ARMv6- and ARMv7, so it does not make much sense to treat ARMv6- caches as ARMv7, not only by using the same terminology, but also expecting the same behaviour. Well, if you feel like it, please comment, review and test. Jakub _______________________________________________ HelenOS-devel mailing list [email protected] http://lists.modry.cz/listinfo/helenos-devel
