Hi PhilAlthough I had no idea about what's wrong, I looked in the functional errata (again), And I found what's attached (The doc I got from Internet was a protected PDF, that's why I had to use screen capture). Is this relevant? Or maybe you have already addressed this in the code (I can just read some simple C code)?
Regards Cloudy On 2012-6-26 5:59, Phil Sutter wrote:
Hi, On Tue, Jun 26, 2012 at 12:05:55AM +0800, cloudy.linux wrote:This time the machine can't finish the boot again and the console was flooded by the message like below:Oh well. I decided to drop that BUG_ON() again, since I saw it once being triggered while in interrupt context. But since the error is non-recovering anyway, I guess it may stay there as well.Also, I had to make some modifications to the arch/arm/mach-orion5x/common.c to let it compile successfully: 1 Add including of mv_dma.h 2 Add macro to define TARGET_SRAM as 9 (which is defined in addr-map.c, so I think the clean solution should be modify the addr-map.h? Anyway, as a quick solution the source finally got compiled)Hmm, yeah. Test-compiling for the platform one is writing code for is still a good idea. But it's even worse than that: according to the specs, for IDMA the SRAM target ID is 5, not 9 like it is for the CPU. Please apply the attached patch on top of the one I sent earlier, without your modifications (the necessary parts are contained in it). Also, I've added some log output to the decode window setter, so we see what's going on there. Anyway, thanks a lot for your help so far! I hope next try shows some progress at least. Greetings, Phil Phil Sutter Software Engineer
Attachment:
gl-cesa-110.PNG
Description: PNG image
