Hi, When I first tried the 20070130 dist on our custom 5208 board everything worked perfectly except for CRC errors when writing to the FLASH. After a lot of testing I concluded that something inside the kernel performed an "illegal" read access to the FLASH adress range, therefore fooling the dq6 polling in the cfi_cmdset_0002.c. I have not spent more time on trying to configure the TDR, ABLR, ABHR to figure out where this access is done. However, I found one semi-dirty way of generating an break when the "illegal" access was made, and that was to hook the FLASH CS signal to the BKPT pin on the BDM-port on my board. With a simple 2-way switch and a couple of resistors I can boot up everything and start gdb (using the USB Multilink pod) and then flip the switch so I route the FLASH CS signal to BKPT instead of letting the BDM pod control BKPT. When I execute ifconfig (for instance) I get the following from gdb (running the entire kernel+rootfs from RAM, no FLASH accesses should occur):
(gdb) target remote | m68k-uclinux-sprite pe://USBMultilink/PE6011716 Remote debugging using | m68k-uclinux-sprite pe://USBMultilink/PE6011716 m68k-uclinux-sprite: Opening P&E USBMultilink port 1 (USB1 : USB-ML-CF Rev C (PE6011716)) m68k-uclinux-sprite: Missing config file; this may not work m68k-uclinux-sprite: Target reset 0x00000000 in ?? () (gdb) symbol-file /home/martin/uClinux-dist/linux-2.6.x/vmlinux Reading symbols from /home/martin/uClinux-dist/linux-2.6.x/vmlinux...done. (gdb) c Continuing. Program received signal SIGTRAP, Trace/breakpoint trap. 0x40028b00 in profile_tick (type=1) at kernel/profile.c:376 376 if (!user_mode(regs) && cpu_isset(smp_processor_id(), prof_cpu_mask)) (gdb) After some digging this looks very similar to http://mailman.uclinux.org/pipermail/uclinux-dev/2007-February/042053.ht ml After applying the patch from the thread above, I get a new break at: Program received signal SIGTRAP, Trace/breakpoint trap. 0x40022e9a in timer_interrupt (irq=68, dummy=0x0, regs=0xe4a0) at arch/m68knommu/kernel/time.c:54 54 update_process_times(user_mode(regs)); (gdb) I have worked quite a bit with the 20071107 patch, and with that patch applied everything seems to work very nicely. So, basically, should I stop chasing my tail any further, because I noted Greg has reworked a lot of the interrupt handling code since 20070130? It's worth noting that I have not seen any other strange issued with the 20070130 dist using the M520x setup. But I guess the issue will be present for everyone using a kernel version <= 2.6.19 on a 520x platform (at least), if no changes have been made. If I had not been using JFFS2 I guess I would not have noticed anything either. :) Best regards, Martin _______________________________________________ uClinux-dev mailing list [email protected] http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by [email protected] To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
