MMU issues with AM335X and 14.05

[Bob Stewart]

Hi,

I've been casually using Genode on a TI Beaglebone SoC for about a year 
now. One of the first issues I had was that virtualized memory 
management wouldn't work at all. This I eventually traced to memory 
attributes in TLB entries. The Am335X processors expects cacheability to be:
Inner -- Write-thru, No Write Allocate
Outer -- Write-back, Write Allocate.

So, based on the info in the ARM Architecture Ref Manual for the Arm_v7 
(pp 1368), I set the attributes in memory_region_attr (Genode 13.08) to :

     if(Arm::Page_flags::D::get(flags))
         return Tex::bits(0) | C::bits(0) | B::bits(1);
//        return Tex::bits(2) | C::bits(0) | B::bits(0);

     if(Arm::Page_flags::C::get(flags))
         return Tex::bits(5) | C::bits(1) | B::bits(0);
//        return Tex::bits(5) | C::bits(0) | B::bits(1);

     return Tex::bits(6) | C::bits(1) | B::bits(0);

MMU worked fine after this change, until 14.05 came along. When 14.05 
was released I attempted to migrate to it and made the needed changes 
for the extensive changes needed for MP. I used the above memory 
attribute settings (now in translation_table.h), but another MMU issue 
occurred and the kernel would not complete initialization. I decided to 
stay with 14.02 as I was working with a uni-processor system anyway and 
I wanted to complete porting of some linux drivers.

I went back to the 14.05 issues today and found I could get the kernel 
initialization to complete successfully if I reverted the S bit to 
"unshared" in the memory attributes in a Section entry create. Prior to 
14.05 this bit was set to "unshared" and was presumably changed in 14.05 
to allow for multiple processors accessing the same memory regions.

It's unclear to me why this behaviour occurred but it is possibly due to 
the specific implementation of the Arm_v7 architecture on this 
particular processor. Or is there something I'm missing in the 
implementation of multiple processors in Genode?

In addition, after completing kernel initialization, core's "main" 
function is entered, the info message for creating local services shows 
up, a translation for the top of RAM (0x80000000) is created, then the 
message "failed to communicate thread event" occurs and init is never 
called. Any thoughts on why that message is appearing would be 
appreciated. It appears to be coming from initialization of the root 
interfaces.

Thanks,

     Bob Stewart