Build failing on MPC8541 #100
Comments
|
SSH access isn't working (yet) - get Alex to check his email. From the log that was mailed to me I see this: So either, you've got a bug in GCC - or you're pushing the machine too hard and it's run out of memory and gcc was the victim of the kernel killing stuff off to stay alive. |
|
I'd guess it was the latter, is there anyway to slow it down? I can give it to you now, ping me at [email protected] |
|
Sent it to your @IBM address :) |
|
It looks like you used; The j flag to make tells it the number of parallel compiles to run. Remove that flag entirely. |
|
Ah ha, yup that'd kill a single-core 1.5Ghz sure enough |
|
For reference (in case I need it in the future) http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=MPC8541E Programmer reference manual |
|
The build crashed creating the snapshot. This indicates there is some assembly code incompatibility. Next step, build with snapshot=off |
|
Well that took a long time to build.. I tried running the tests on it but it seemed things were very bad right away (lots of crashes). I then tried just running the d8 command: Not good. The machine doesn't appear to have gdb installed. So I installed it: "apt-get install gdb" (the dangers of giving me root :) So gdb says I'm crashing on the instruction with the arrow => of course, that's not believable - and causes me to remember that the instruction cache flush code is probably wrong for this platform. The size defaults to 128, when this platform is 64 I believe. The cache size is defined here: constants-ppc.h:const unsigned int kCacheLineSizeLog2 = 7; So I changed that to 6 to represent 64, and ran another build "nohup make ppc snapshot=off | tee log.txt" |
|
Hmm, still not happy. I think the cache line size is 32bytes based on this doc: http://cache.freescale.com/files/32bit/doc/data_sheet/MPC8541EEC.pdf Changed and trying again. I suspect once we get past these issues - we'll find this is very similar or identical to issue #99 - the good news is we've got remote access to the hardware, so it might get fixed faster. |
|
Ok, that worked. Now to test. |
|
Awesome :D On Fri, Dec 6, 2013 at 12:47 PM, Andrew Low [email protected]:
|
I haven't done a full test run, but looking at issue #99 I tried the above test and it crashed on this platform as well. Running under gdb we see The .long's in the code are worrying. They are instructions that this version of gdb doesn't want to disassemble for us - pointing out that they may not be supported. Manually decoding them gives us: 0xc8210000 lfd |
|
Interesting, indeed looks similar to gdb output from #99, could this be a possible blocker? |
|
Referring the the programming manual (assuming I'm looking at the correct one http://cache.freescale.com/files/32bit/doc/ref_manual/EREF_RM.pdf) - lfd is supported. We also didn't crash on that line, so it's probably ok. This just means gdb is lying to us a little bit. But I'm puzzled as it looks like fctiw is also implemented - but clearly we're crashing here. Ah - http://cache.freescale.com/files/32bit/doc/ref_manual/E500CORERM.pdf has a list of instructions NOT supported on the Book E processors (which this is one of them)
|
|
Some we don't use at all, but others are actually quite frequently used. This may be a bigger effort than I had hoped at the start. Some grepping around in the source is required here. The good news is that I think we've got a firm list of issues to look at. This is also concerning |
|
From the test log More evidence this is basically the same issue as #99 - I think we'll continue to track these independently just for clarity of the investigations. |
|
Hey Andrew, are those CRASHED tests included in the failed? that is, were there 9 tests that didn't crash? |
|
A little scripting and it seems that there are 283 locations in the code where we make use of the instructions that are not supported on the e500 based on table 3-2. Resolving this issue completely will require addressing each of these locations. |
|
@jpillora The test results should be interpreted like this: 8979 total number of tests A bit of math and we know 6954 passed -> 77% pass rate Of the ones that didn't work as expected |
|
Sure is a long list! How many missing instructions is that? |
|
Ah I see, so based on the types and number of missing instructions, do you have closer estimate of work required? |
|
FWIW - a bit more sifting of the data - there are 117 locations in the code that need to be changed to make this work (if we disable crankshaft). I'm providing this as a way to figure out the lower bound on the effort to bring this up on the e500 series. Of course, many of those 117 changes will be very similar - so we're not re-inventing the wheel each time as well. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
@andrewlow currently has SSH access to the hardware. Updates will go here :)
The text was updated successfully, but these errors were encountered: