Hi Martin,
Martin Voss wrote:
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
Yes, I would say that is the same problem as that patch is designed
to fix.
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?
My gut feeling is "yes, no need to keep chasing". I am not aware of
any follow on problems after switching to the generic interrupts
framework in later kernels. But then again, it probably hasn't had
enough general testing yet - since it is not in a kernel in a
"normal" dist release yet.
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. :)
This particular problem (and a couple of others over the years) have
crept in for boards that don't have RAM at address 0. Mostly because
the older Freescale ColdFire dev boards all had 0 based RAM. As of the
5208EVB at least that changed.
Regards
Greg
------------------------------------------------------------------------
Greg Ungerer -- Chief Software Dude EMAIL: [EMAIL PROTECTED]
Secure Computing Corporation PHONE: +61 7 3435 2888
825 Stanley St, FAX: +61 7 3891 3630
Woolloongabba, QLD, 4102, Australia WEB: http://www.SnapGear.com
_______________________________________________
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
