Hi Bruce,
On 01/25/12 20:49, bruce_leon...@selinc.com wrote:
.
.
.
Thanks for the reply. Yes I did find spidev_fdx.c and in fact copied it
for my tests. I still see SPICLK active only during the time the 8308 is
sending data (read cmd + address). Nothing happens with the clock after
that
On 01/25/12 01:11, bruce_leon...@selinc.com wrote:
Good afternoon,
I'm using the 3.0.3 kernel running on an MPC8308 and am trying to
interface to a Cypress CY14B256Q2A non-volatile RAM via SPI. I've got the
SPI infrastructure, the Freescale SPI driver (drivers/spi/spi_fsl_spi.c),
and spidev
On 01/17/12 23:09, Scott Wood wrote:
...
If CPU is stuck in sleep, JTAG will send HRESET or SRESET (i'm nor sure
which one it is) and u-boot is needed to reconfigure CPU and DDR2 SDRAM
ctrl.
Why is a reset needed in order to examine physical memory?
Because CPU is stuck in sleep and I
On 01/16/12 21:22, Scott Wood wrote:
On 01/13/2012 08:13 AM, Norbert van Bolhuis wrote:
I dumped SIPNR/SIMSR and uart IIR/EIR (since console triggers wake-up)
but they do not change just before entering standby (via
mpc6xx_enter_standby
which omits setting MSR_POW). uart IRQ is always enabled
On 01/06/12 22:03, Scott Wood wrote:
On 01/06/2012 07:53 AM, Norbert van Bolhuis wrote:
On 01/05/12 19:22, Scott Wood wrote:
On 01/05/2012 09:58 AM, Norbert van Bolhuis wrote:
thanks for your response.
not setting MSR_POW gives same result.
OK, so you're not getting an interrupt
On 01/05/12 19:22, Scott Wood wrote:
On 01/05/2012 09:58 AM, Norbert van Bolhuis wrote:
thanks for your response.
not setting MSR_POW gives same result.
OK, so you're not getting an interrupt regardless of low-power state.
Check whether the interrupt is getting masked during standby
On 01/04/12 22:08, Scott Wood wrote:
...
It's been a while since I've touched this, but IIRC the PMC events are
mainly important for deep sleep, and for normal sleep (standby) you can
wake from any interrupt other than core interrupts like timebase. I'm
not sure to what extent setting
after entering:
echo standby /sys/power/state
I'm unable to wake up the MPC8313 (on our custom designed
MPC8313 board).
I need it to wake up through GPIO IRQ.
I cause multiple GPIO interrupts (all properly handled by an isr),
but the MPC8313 does not wake up.
How should one wake up via
Joakim Tjernlund wrote:
I can't make out what is causing this hang every now an then:
INFO: task snmpd:398 blocked for more than 120 seconds.
My problem with that 'error' message is that there is no way
for a driver to disable it on a per-process basis.
We have some processes whose 'normal
Currently an external edge triggered IRQ0 gives 2 problems.
It gives a sense error (edge sense not supported on internal interrupts)
and it isn't acked.
This patch takes into account IRQ0 can be internal or external and fixes
both issues.
Signed-off-by: Norbert van Bolhuis nvbolh...@aimvalley.nl
reading a bogus address in u-boot gives:
= md 0x8800
8800:Machine check in kernel mode.
Caused by (from msr): regs 0ff0ec28 Unknown values in msr
NIP: 111C XER: 205F LR: 0FFDB104 REGS: 0ff0ec28 TRAP: 0200 DAR:
MSR: 1000 EE: 0 PR: 0 FP: 0 ME: 1 IR/DR: 00
GPR00:
Hi Felix,
do you have CONFIG_NO_HZ defined ?
I've seen similar problems with powerpc + CONFIG_NO_HZ. In my case the low-level
do_write_buffer (cfi_cmdset_0002.c) timed out too early. See
http://lkml.org/lkml/2009/9/3/84
Maybe in your case it's the do_erase_chip timing out too early.
---
Thanks for the answers!
libSegFault.so seems to do what I want. I'll replace
sysctl -w kernel.print-fatal-signals=1
with
export LD_PRELOAD=/lib/libSegFault.so
since it better suits my needs.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
Afaik the kernel only shows the stack backtrace of the kernel stack
(of a task).
I wonder if there would be anything wrong with letting it show
the user task stack backtrace in certain cases.
Read the rest to see what I mean.
If kernel.print-fatal-signals has been enabled a crashing
you have to do it via your bootloader (u-boot) which sets up
the DDR memory controller.
Linux (already) assumes memory is available.
Are you sure linux kernel is changing DDR_SDRAM_CFG ?
When our linux-2.6.28 kernel is up, it's still 0xc308 when I read
physical address 0xe0002110.
Btw. We
Hi Frank,
Yes, it's 0xC310 for 16 bit. I showed the 32bit value.
Yes, to go to 16 bit bus-width (1 DDR(2) device), this is the only
change needed in u-boot, assuming you have 2 DDR(2) devices (like 8313E-RDB)
which together provide 16+16 = 32bit bus-width.
Since, surprisingly, the 16 bit
Hi Leon,
I doubt if there are working designs for this.
In u-boot the watchdog (if enabled with CONFIG_WATCHDOG) is normally
strobed in the decrementer interrupt routine (timer_interrupt). So
I guess there's not a big chance it triggers a reset.
It is possible to configure the WD to issue a
Hi Leon,
...
Most designs do not care about the watchdog, or only pet in their
non-critical paths... That's not what the watchdog is for.
Also, I don't care about u-boot.
I care about a design where the Flash NOR could be in write mode at
any time when the watchdog triggers, when the hardware
Hi Daniel,
Ethos driver... hmm. sounds familiar!
(good to hear that it is still used in active development)
About your question.
Since almost 2 years (kernel 2.6.22 from july 2007) the rule is that you can't
directly map a hardware irq number because the powerpc kernel keeps a
mapping between
I hate open ends, so for those interested.
I made a small change in u-boot and kernel and it works now.
btw. it makes a huge performance difference. The kernel boots
much slower and my user-space calculation now runs in 44 secs
(no data-cache) instead of 2.8 secs (with data-cache).
in u-boot
I'd like to understand the implications of this bug.
Obviously applications using the futex system can be affected, but
does anybody know whether GNU software packages suffer from this problem.
I mean glibc (nptl) uses futexes, so does gdb and gcc. will this bug hurt
them ?
Paul Mackerras
Hi Eric,
I have the same board and same problem. It's just an incompatibility between the
DTB and u-boot.
Recent u-boots (and without a doubt also your u-boot 1.3.3) expect aliases
in the DTB, these ones I guess:
.
.
aliases {
ethernet0 = enet0;
ethernet1
Hi Eric,
So it never ever booted properly ?
Hmm, it certainly looks like your distributor (or whoever you got the
MPC8313E-RDB
from) lend it out and got a messed up board back. Or maybe they messed it up
themselfes.
Go complain and send it back.
indeed, rev 2.x is better (much less TSEC
We have 2 MPC8313E-RDB REVA4 boards.
u-boot always fails to uncompress certain compressed files.
Either the board will hang or a checkstop occurs.
The problem occurs on both our MPC8313E-RDB REVA4 boards.
Probably memory is overwritten at the end of RAM (where
u-boot is relocated to). When
I'm preparing the latest (2.6.28-rc7) linux kernel for an MPC8313 based project
that's about to start.
Things seems to work great with the base 2.6.28-rc7 kernel. On our MPC8313E-RDB
the kernel boots without problems, ethernet (with eTSEC2/eth1) works and even
eTSEC1/eth0 has a 1gbit link. Most
Nowadays, do many (PowerPC) embedded devices already risk omitting
NOR flash and use a NAND device solely for booting and storing images ?
I'm talking about systems with 10 years life-cycle (so no
MP3-players nor medical systems but somewhere in between).
We have a MPC8313E-RDB and I know
Thanks for the answer, but that's not it.
I checked the jiffies variable, it increases about 250 times
per second.
So the (mpc83xx_defconfig) kernel perception (#define CONFIG_HZ 250) is OK.
It must be something else, I still think 83.20 BogoMIPS
can't be correct for a MPC8313 running at 333
ok, so it depends on the decrementer frequency
(which is 4166 on my system).
Btw. the main oscillator on my board is not 83.3 mhz,
it's 66 mhz as well.
Hmmm. so by using the decrementer for the clock tick/irqs
(which perfectly makes sense) the bogoMIPS value is
nonsense now. That's a pity,
28 matches
Mail list logo
