Re: FSL SPI driver question
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 when the NvRAM is ready to send data. Bruce ok, then I don't know. I doubt this is a spidev or FSP SPI driver problem though. Questions like: Could it be a HW problem ? Is the correct SPI mode used ? Does it work in u-boot ? Come to mind in a situation like this. Norbert. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: FSL SPI driver question
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 built into the kernel and everything on the user space/kernel side appears to be working correctly (at least when I try to read the NvRAM's config register all the right places in the kernel get hit and I see the SPI signals active with an o-scope). I think what I'm hitting is a lack of understanding/documentation on the SPI controller in the 8308. To read data from the NvRAM, the Master (the 8308 in this case) needs to clock out a byte long read command, two bytes of address, and then clock in the data from the NvRAM. However, I never get any data back. I think the problem is that (direct quote from the 8308 reference manual) SPICLK is a gated clock, active only during data transfers. So once the read command and address are sent, the 8308 considers the data transfer complete and gates off SPICLK. Without SPICLK, the NvRAM has no way to clock out it's data. I think it's ready to, it just can't. So the question is, how do I use spidev (or any other means) to get the 8308 SPI controller to keep SPICLK active so that the output data from the NvRAM gets clocked out to the 8308? Thanks. Bruce Did you see Documentation/spi/spidev_fdx.c:do_msg ? it perform a full-duplex (actually half-duplex) 1 byte transfer. In your case you need a transfer that outputs 3 bytes (read cmd + address) and inputs 1? byte. If you do it this way I would expect the SPICLK to be active during the 2nd part of the transfer (whenever the CPU reads the data from SPI client). hth. --- NvBolhuis ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Cannot wake-up from standby with MPC8313
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 use the CPU to dump the physical memory (which contains the log entries made just before CPU got stuck). SDRAM contents (for physical memory unknown to u-boot and linux) seems to survive such a soft-reset. And all register and device state is as Linux left it? Probably not, but at least the physical memory contents seems to survive the soft-reset. It looks like an interupt does occur, but do_IRQ seems to be stuck in ppc_md.get_irq=ipic_get_irq where it reads SIVCR. Stuck as in the load never completes, or as in ipic_get_irq() gets called repeatedly? If the latter, what value is it reading out? Is the interrupt pending in SIPNR at this point? I think I was wrong. I enabled tracing do_IRQ just a little bit too soon (in suspend_enter). The interrupt I saw was probably one that occured just before CPU entered sleep (mpc6xx_enter_standby). Right now I see no external interrupt happening, so that brings us back where we were before: I'm not getting an interrupt regardless of low-power state. So now my main question is: how can JTAG and/or any other external signal cause this ? I can't help you with the hardware side of it, other than to say that it sounds similar to an issue we had on early revs of mpc8313erdb. Could you make sure that TRST (JTAG Test Reset) is not being asserted except while PORESET is asserted? If that's not it, I'm wondering what the relevant difference is on the software side to differentiate the case where you go through all the motions but don't set MSR[POW] from the case where you don't try to suspend at all (just take the interrupt during normal execution). Are you sure that you're making it to mpc6xx_enter_standby, and that it's not hanging on a PMC register access? Another weird thing I noticed is that whenever I dump CPU memmap (which starts at 0xe000) under linux it always crashes with a check stop when it is displaying somewhere at 0xe800-0xe0001000 If I connect our JTAG debugger it never crashes and dumping CPU memmap always works. Is it 0xebXX? A hang when accessing the PMC registers is what I saw with the mpc8313erdb bug. -Scott Yes this is it! You mentioned mpc8313erdb bug before, I guess you had to mention it twice before I looked at mpc8313erdb bug description. The mpc8313erdb bug is described as follows: 3.5 Power management control (PMC) registers cannot be accessed? The PMC registers range from IMMR + 0x0B00 to IMMR + 0x0BFF. When this area is accessed in u-boot, the RDB hangs up. It appears that the PMC block is related to the JTAG interface; TRST must not be pulled down for normal operation of the PMC block. Possible workarounds are as follows: • Attach a debugger to drive TRST high during normal operation. • Remove the pull-down resistor (R37) for TRST. Although this tested on some RDBs without any problem, it violates the hardware specification. If it does not work on your RDB, use another workaround. I guess this is an MPC8313 problem rather than an MPC8313E-RDB problem ? and I would expect it to be mentioned in MPC8313E Errata (which isn't the case). Anyway, thanks a lot for all help! --- NvBolhuis ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Cannot wake-up from standby with MPC8313
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, unmasked and not pending. I tried to log to physical memory to see what's going on whenever the board fails to wake-up. (I can examine physical memory after CPU is stuck in sleep, by connecting a JTAG debugger, start u-boot and stop after DDR2 SDRAM ctrl is re-configured) Are you sure this isn't going to disturb anything? Why does U-Boot need to be involved, and the SDRAM reconfigured? 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. SDRAM contents (for physical memory unknown to u-boot and linux) seems to survive such a soft-reset. It looks like an interupt does occur, but do_IRQ seems to be stuck in ppc_md.get_irq=ipic_get_irq where it reads SIVCR. Stuck as in the load never completes, or as in ipic_get_irq() gets called repeatedly? If the latter, what value is it reading out? Is the interrupt pending in SIPNR at this point? I think I was wrong. I enabled tracing do_IRQ just a little bit too soon (in suspend_enter). The interrupt I saw was probably one that occured just before CPU entered sleep (mpc6xx_enter_standby). Right now I see no external interrupt happening, so that brings us back where we were before: I'm not getting an interrupt regardless of low-power state. So now my main question is: how can JTAG and/or any other external signal cause this ? Another weird thing I noticed is that whenever I dump CPU memmap (which starts at 0xe000) under linux it always crashes with a check stop when it is displaying somewhere at 0xe800-0xe0001000 If I connect our JTAG debugger it never crashes and dumping CPU memmap always works. --- NvBolhuis ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Cannot wake-up from standby with MPC8313
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 regardless of low-power state. Check whether the interrupt is getting masked during standby preparation. Does the interrupt handler run when you're not trying to enter standby? The GPIO/UART interrupt nor the PMC interrupt are being masked during standby preperation. The GPIO/UART interrupt works fine in operational mode. The PMC interrupt I do not know, is it possible to to get PMC interrupt without going to standby or deep-sleep ? The PMC interrupt is mainly of interest when running as a PCI agent, to be notified when the host changed the desired suspend state in config space. What changes from operational mode to the test where you omit setting MSR_POW? Try dumping SIPNR/SIMSR and GPIER/GPIMR/GPDAT at various points. 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, unmasked and not pending. I tried to log to physical memory to see what's going on whenever the board fails to wake-up. (I can examine physical memory after CPU is stuck in sleep, by connecting a JTAG debugger, start u-boot and stop after DDR2 SDRAM ctrl is re-configured) It looks like an interupt does occur, but do_IRQ seems to be stuck in ppc_md.get_irq=ipic_get_irq where it reads SIVCR. I have no idea why, any more suggestions ? --- NvBolhuis ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Cannot wake-up from standby with MPC8313
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 preparation. Does the interrupt handler run when you're not trying to enter standby? The GPIO/UART interrupt nor the PMC interrupt are being masked during standby preperation. The GPIO/UART interrupt works fine in operational mode. The PMC interrupt I do not know, is it possible to to get PMC interrupt without going to standby or deep-sleep ? In anyway there is no PMC interrupt for NAP mode (if kernel.powersave-nap=1). if I set kernel.powersave-nap=1 it works fine, What is it? Do you mean that powersave-nap doesn't break things, or that standby works when you specify that? I mean powersave-nap itself seems to work and does not break things. so apparently NAP/DOZE mode does work (if CPU is idle). This saves almost no power though. Standby mode saves about 300-500 mW. The problem could well be our board though, today I learned it does work by connecting an (inactive) JTAG debugger. Also, on another board it always works. You mean connecting a JTAG but not doing anything with it made wake-from-standby work? There was a bug like that on early revisions of the mpc8313erdb board -- though in that case if you had a bad board the system would hang whenever you access any PMC register. I'm not sure what the mechanism of failure was; IIRC the fix was adding a resistor. yes, connecting a JTAG but not doing anything with it makes wake-from-standby work. I don't know what's wrong with (some of) our boards... it looks like external interrupts are blocked and/or core stays in reset.. I doubt there's a SW PMC race/deadlock that causes this. --- NvBolhuis ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Cannot wake-up from standby with MPC8313
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 PMCCR[SLPEN] affects this -- I don't see where the documentation says what system low power state means. I would be surprised if GPIO were affected, though, since it's supported as a wakeup source even in deep sleep. I think I was able to wake from standby on a UART interrupt even with SLPEN set. Are you sure the GPIO block is asserting an interrupt, and that it hasn't been masked during the preparation for standby? What happens if you modify mpc6xx_enter_standby() to not actually set MSR_POW? thanks for your response. not setting MSR_POW gives same result. if I set kernel.powersave-nap=1 it works fine, so apparently NAP/DOZE mode does work (if CPU is idle). This saves almost no power though. Standby mode saves about 300-500 mW. The problem could well be our board though, today I learned it does work by connecting an (inactive) JTAG debugger. Also, on another board it always works. And indeed wake-up occurs through GPIO interrupt or UART interrupt (key press on console). --- NvBolhuis ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Cannot wake-up from standby with MPC8313
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 GPGIO IRQ ?
I'm using v2.6.29 and I wonder whether this is related to
our custom 8313 board and/or v2.6.29 and/or missing kernel
patches or maybe this never worked ?
Also, I do not understand line 220 of arch/powerpc/platforms/83xx/suspend.c
219 } else {
220 out_be32(pmc_regs-mask, PMCER_PMCI);
221
222 mpc6xx_enter_standby();
How can wake up ever work if TSEC/GPIO/TIMER/etc.. wake up events
are disabled ?
changing this into out_be32(pmc_regs-mask, PMCER_PMCI|PMCER_GPIO);
gives same result.
MPC8313 is in PCI HOST mode and here's a relevant part
of the DTS:
pmc: power@b00 {
compatible = fsl,mpc8313-pmc, fsl,mpc8349-pmc;
reg = 0xb00 0x100 0xa00 0x100;
interrupts = 80 8;
interrupt-parent = ipic;
fsl,mpc8313-wakeup-timer = gtm1;
/* Remove this (or change to okay) if you have
* a REVA3 or later board, if you apply one of the
* workarounds listed in section 8.5 of the board
* manual, o if you are adapting this device treeSE=
* to a different board.
*/
status = okay;
};
gtm1: timer@500 {
compatible = fsl,mpc8313-gtm, fsl,gtm;
reg = 0x500 0x100;
interrupts = 90 8 78 8 84 8 72 8;
interrupt-parent = ipic;
};
Any help/advice/answer is more than welcome.
---
NvBolhuis
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: INFO: task snmpd:398 blocked for more than 120 seconds.
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 state' is to sleep uninterruptibly in the kernel. Shutdown is handled by an explicit request (not by sending a signal). The processes could be kernel worker threads (except that is is ~impossible to handle them exiting from a loadble kernel module) so are actually children of a daemon sat inside an ioctl() request that never terminates! However, on the face of it, your case does look as though the mutex is fubar'ed. Might be worth (somehow) dumping the mutex state. ehh, it is locked, isn't it? How to find who locked it and forgot to release it? You could add show_state to check_hung_task It worked for me while solving some (application) task hangups. --- N. van Bolhuis. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc/ipic: support external edge triggered IRQ0
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
---
arch/powerpc/sysdev/ipic.c |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/sysdev/ipic.c b/arch/powerpc/sysdev/ipic.c
index cb7689c..3201db1 100644
--- a/arch/powerpc/sysdev/ipic.c
+++ b/arch/powerpc/sysdev/ipic.c
@@ -316,6 +316,7 @@ static struct ipic_info ipic_info[] = {
.prio_mask = 7,
},
[48] = {
+ .ack= IPIC_SEPNR,
.mask = IPIC_SEMSR,
.prio = IPIC_SMPRR_A,
.force = IPIC_SEFCR,
@@ -619,7 +620,9 @@ static int ipic_set_irq_type(unsigned int virq, unsigned
int flow_type)
return -EINVAL;
}
/* ipic supports only edge mode on external interrupts */
- if ((flow_type IRQ_TYPE_EDGE_FALLING) !ipic_info[src].ack) {
+ if ((flow_type IRQ_TYPE_EDGE_FALLING)
+ ((src != IPIC_IRQ_EXT0 !ipic_info[src].ack) ||
+(src == IPIC_IRQ_EXT0 (ipic_read(ipic-regs, IPIC_SEMSR)
SEMSR_SIRQ0 {
printk(KERN_ERR ipic: edge sense not supported on internal
interrupts\n);
return -EINVAL;
--
1.5.2.2
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
bus error exception handler not working
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: 0FFDB104 0FF0ED18 0FF0EF48 0FFE9DAC 0002 0010 0030 GPR08: 0001 0020 0009 0FF0E828 1001910C 0FFF9000 0FFE9E10 GPR16: 0FFE9DAC 0FFEADF8 0FFEADF0 0FFEDCE4 48024028 882B 8800 8800 GPR24: 0FF0ED20 0040 0004 0FF0ED20 0004 0FFFA650 8800 Call backtrace: 0FFDB104 0FFC67B4 0FFCF668 0FFCED70 0FFCEEE0 0FFD1AA8 0FFB5FF4 0FFB2644 machine check Resetting the board. U-Boot 2008.10 (Oct 16 2009 - 14:57:46) MPC83XX, version=0x00910161 Reset Status: Software Hard, External/Internal Soft, External/Internal Hard doing the same in linux kernel gives an immediate reboot (checkstop): # readmm 32 8800 1 U-Boot 2008.10 (Oct 16 2009 - 14:57:46) MPC83XX, version=0x00910161 Reset Status: Check Stop, External/Internal Soft, External/Internal Hard We're using an MPC8313E on a custom board (similar to MPC8313E-RDB) with U-Boot v2008.10 and linux 2.6.28. The problem is that the linux kernel exception handler (arch/powerpc/kernel/head_32.S) doesn't work. It looks like this: . = 0x200 0x200 mtspr SPRN_SPRG0,r10 mtspr SPRN_SPRG1,r11 mfcrr10 #define EXCEPTION_PROLOG_1 \ 0x20c mfspr r11,SPRN_SRR1; /* check whether user or kernel */ \ andi. r11,r11,MSR_PR; \ tophys(r11,r1); /* use tophys(r1) if kernel */ \ beq 1f; \ mfspr r11,SPRN_SPRG3; \ lwz r11,THREAD_INFO-THREAD(r11);\ addir11,r11,THREAD_SIZE;\ tophys(r11,r11);\ 1: subir11,r11,INT_FRAME_SIZE /* alloc exc. frame */ #define EXCEPTION_PROLOG_2 \ CLR_TOP32(r11); \ 0x230 stw r10,_CCR(r11); /* save registers */ \ stw r12,GPR12(r11); \ stw r9,GPR9(r11); \ mfspr r10,SPRN_SPRG0; \ stw r10,GPR10(r11); \ mfspr r12,SPRN_SPRG1; \ stw r12,GPR11(r11); \ mflrr10;\ stw r10,_LINK(r11); \ mfspr r12,SPRN_SRR0; \ mfspr r9,SPRN_SRR1; \ stw r1,GPR1(r11); \ stw r1,0(r11); \ tovirt(r1,r11); /* set new kernel sp */ \ li r10,MSR_KERNEL ~(MSR_IR|MSR_DR); /* can take exceptions */ \ MTMSRD(r10);/* (except for mach check in rtas) */ \ stw r0,GPR0(r11); \ lis r10,stack_frame_regs_mar...@ha; /* exception frame marker */ \ 0x278 addir10,r10,stack_frame_regs_mar...@l; \ stw r10,8(r11); \ SAVE_4GPRS(3, r11); \ SAVE_2GPRS(7, r11) 0x298 addir3,r1,STACK_FRAME_OVERHEAD EXC_XFER_STD(0x200, machine_check_exception) 0x29c li r10,trap ... bl machine_check_exception somehow machine_check_exception isn't reached. can anyone tell me why ? is there something wrong with EXCEPTION_PROLOG_1/EXCEPTION_PROLOG_2 ? ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: UBIFS problem on MPC8536DS
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. --- NvBolhuis. Felix Radensky wrote: Hi, I have a strange problem in linux-2.6.31 running on MPC8536DS board. It is 100% reproducible, by opening a 350MB tar file into ubifs volume on NAND flash, and starting erase of NOR flash partition right after that. If I don't start NOR erase, everything works fine. Also, If I run sync after tar, no problem occurs. The NOR flash is 32MB Spansion, NAND is 4GB Samsung. The error messages are as follows: UBI error: ubi_io_write: error -5 while writing 2048 bytes to PEB 5812:12288, written 0 bytes UBI warning: ubi_eba_write_leb: failed to write data to PEB 5812 UBI: recover PEB 5812, move data to PEB 19400 UBI error: ubi_io_read: error -74 while reading 512 bytes from PEB 5812:512, read 512 bytes UBI error: ubi_io_write: error -5 while writing 512 bytes to PEB 19400:512, written 0 bytes UBI warning: recover_peb: failed to write to PEB 19400 UBI: try again UBI: recover PEB 5812, move data to PEB 19401 UBI: run torture test for PEB 19400 UBI error: ubi_io_write: error -5 while writing 512 bytes to PEB 19401:512, written 0 bytes UBI warning: recover_peb: failed to write to PEB 19401 UBI: try again UBI: recover PEB 5812, move data to PEB 19402 UBI error: ubi_io_write: error -5 while writing 512 bytes to PEB 19402:512, written 0 bytes UBI warning: recover_peb: failed to write to PEB 19402 UBI: try again UBI: recover PEB 5812, move data to PEB 19403 UBI error: ubi_io_write: error -5 while writing 512 bytes to PEB 19403:512, written 0 bytes UBI warning: recover_peb: failed to write to PEB 19403 UBI warning: ubi_ro_mode: switch to read-only mode UBIFS error (pid 1149): ubifs_wbuf_write_nolock: cannot write 2522 bytes to LEB 389:10240, error -5 UBIFS warning (pid 1149): ubifs_ro_mode: switched to read-only mode, error -5 UBIFS error (pid 1149): do_writepage: cannot write page 0 of inode 30708, error -5 UBIFS error (pid 1149): make_reservation: cannot reserve 858 bytes in jhead 2, error -30 UBIFS error (pid 1149): do_writepage: cannot write page 2 of inode 29486, error -30 UBIFS error (pid 1149): make_reservation: cannot reserve 721 bytes in jhead 2, error -30 UBIFS error (pid 1149): do_writepage: cannot write page 1 of inode 30070, error -30 UBI error: ubi_io_write: error -5 while writing 2048 bytes to PEB 5022:88064, written 0 bytes UBI warning: ubi_eba_write_leb: failed to write data to PEB 5022 UBI: recover PEB 5022, move data to PEB 19404 UBI error: ubi_io_read: error -74 while reading 512 bytes from PEB 5022:512, read 512 bytes UBI error: ubi_io_write: read-only mode UBI warning: recover_peb: failed to write to PEB 19404 UBI: try again UBI: recover PEB 5022, move data to PEB 19405 UBI error: ubi_io_write: read-only mode UBI warning: recover_peb: failed to write to PEB 19405 UBI: try again UBI: recover PEB 5022, move data to PEB 19406 UBI error: ubi_io_write: read-only mode UBI warning: recover_peb: failed to write to PEB 19406 UBI: try again UBI: recover PEB 5022, move data to PEB 19407 UBI error: ubi_io_write: read-only mode UBI warning: recover_peb: failed to write to PEB 19407 UBIFS error (pid 1044): ubifs_wbuf_sync_nolock: cannot write 2048 bytes to LEB 788:86016 UBIFS error (pid 1044): ubifs_bg_wbufs_sync: cannot sync write-buffer, error -30 UBIFS warning (pid 1044): ubifs_ro_mode: switched to read-only mode, error -30 UBI error: ubi_io_write: error -5 while writing 2048 bytes to PEB 5817:26624, written 0 bytes UBI warning: ubi_eba_write_leb: failed to write data to PEB 5817 UBI: recover PEB 5817, move data to PEB 19408 UBI error: ubi_io_read: error -74 while reading 512 bytes from PEB 5817:512, read 512 bytes UBI error: ubi_io_write: read-only mode UBI warning: recover_peb: failed to write to PEB 19408 UBI: try again UBI: recover PEB 5817, move data to PEB 19409 UBI error: ubi_io_write: read-only mode UBI warning: recover_peb: failed to write to PEB 19409 UBI: try again UBI: recover PEB 5817, move data to PEB 19410 UBI error: ubi_io_write: read-only mode UBI warning: recover_peb: failed to write to PEB 19410 UBI: try again UBI: recover PEB 5817, move data to PEB 19411 UBI error: ubi_io_write: read-only mode UBI warning: recover_peb: failed to write to PEB 19411 UBIFS error (pid 1047): ubifs_wbuf_sync_nolock: cannot write 2048 bytes to LEB 385:24576 UBIFS error (pid 1047): ubifs_bg_wbufs_sync: cannot sync write-buffer, error -30 UBIFS error (pid 1149): make_reservation: cannot reserve 160 bytes in jhead 1, error -30 UBIFS error (pid 1149): ubifs_write_inode: can't write inode 30709, error -30 UBIFS error (pid 1149): make_reservation: cannot reserve 160 bytes in jhead 1, error -30 UBIFS error (pid 1149): ubifs_write_inode: can't write
Re: can the kernel show user task stack backtrace ?
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 https://lists.ozlabs.org/listinfo/linuxppc-dev
can the kernel show user task stack backtrace ?
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
application makes the kernel show this:
ca2/943: potentially unexpected fatal signal 11.
NIP: 144c LR: 1444 CTR:
REGS: ce73df50 TRAP: 0300 Not tainted (2.6.28)
MSR: d032 EE,PR,ME,IR,DR CR: 22000422 XER: 2000
DAR: d003, DSISR: 2200
TASK = ceb7a3e0[943] 'ca2' THREAD: ce73c000
GPR00: 000e bf963b30 48025450 000a 0ff0ac2c 22000422 0001 0ff5e6b0
GPR08: 0001 d003 1032 1001896c 0ffe9000
GPR16: 0ffca59c 1009b940 100a8b6a 100bf234 bfea22b8 100bf224
GPR24: 100bf008 1009b960 4801e858 4802dd34 4802e7e0 0ffec8d8 bf963b30
Call Trace:
Segmentation fault
#
It's a real pity the user task stack backtrace isn't shown.
We're dealing with some complex (3rd party) applications and I like to see a
user task stack backtrace.
(Of course the way to go here is to use a debugger (gdb) and
do a backtrace (with the coredump file).
However, debugging takes some time. Besides the info is there
it only needs to be shown. Often just this info is enough to
pinpoint the problem)
Obviously the arch/powerpc/kernel/process.c:show_stack function
isn't meant for doing this. It only shows the kernel stack.
Btw. this doesn't work in my case since validate_sp returns 0 (because
sp is assigned the user-space stack (bf963b30) while kernel stack starts at
ce73c000).
Though if it would work it isn't very usefull I guess since the crashing app
not enters kernel-mode (via sys-calls).
If I change arch/powerpc/kernel/process.c:show_stack (of kernel 2.6.28) like
this:
do {
#if 0
if (!validate_sp(sp, tsk, STACK_FRAME_OVERHEAD))
return;
#endif
.
.
.
} while ((count++ kstack_depth_to_print) (sp != 0));
the following is shown:
ca2/943: potentially unexpected fatal signal 11.
NIP: 144c LR: 1444 CTR: c001fd7c
REGS: ce73df50 TRAP: 0300 Not tainted (2.6.28)
MSR: f932 EE,PR,FP,ME,IR,DR CR: 22000422 XER: 2000
DAR: d003, DSISR: 2200
TASK = cf09b340[943] 'ca2' THREAD: ce73c000
GPR00: 000e bfd65b30 48025450 000a 0ff0ac2c 22000422 0001 0ff5e6b0
GPR08: 0001 d003 1032 1001896c 0ffe9000
GPR16: 0ffca59c 1009b940 100a8b6a 100bf234 bfb532b8 100bf224
GPR24: 100bf008 1009b960 4801e858 4802dd34 4802e7e0 0ffec8d8 bfd65b30
Call Trace:
[bfd65b30] [1444] 0x1444 (unreliable)
[bfd65b60] [1490] 0x1490
[bfd65b90] [14cc] 0x14cc
[bfd65ba0] [0feb39c8] 0xfeb39c8
[bfd65dd0] [0feb3ad4] 0xfeb3ad4
[bfd65de0] [] 0x00
Segmentation fault
#
which is what I want.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: How to set DDR data bus width to 16Bit
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 did some performance tests with 16 bit bus-width (DDR2 memory) and surprisingly performance was almost as good as 32 bit bus-width --- N. van Bolhuis. Frank Prepelica wrote: Hi all, Does anyone knows how to set the DDR data bus width to 16Bit in linux? I've found that option in U-Boot in the MPC8313ERDB_config file. (verfied with a memory dump of the CPU register (DDR_SDRAM_CFG) - the 16Bit DBW is set(10b) ). But after starting linux the value is set to 00b (=reseverd). We are using a customized MPC8313ERDB board. Thanks in advance Kind regards Frank Prepelica Software Design Engineer Ubidyne GmbH Lise-Meitner-Str.-14 89081 Ulm - Germany ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: AW: How to set DDR data bus width to 16Bit
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 application/u-boot performance was almost as good as 32 bit we even tested with I-cache and D-cache turned off. u-boot provides commands for this (which I didn't know, see some previous emails from me on this mailing-list). Also with I-cache and D-cache turned off the 16 bit bus-width performance was almost as good as 32 bit. So our conclusion was that the 16/32 bit DDR2 memory access is not the limiting factor when it comes to SW performance. Therefore we decided to go for 16 bit bus-width for a new/tiny 8313 based design. Please let me know your test results. I would expect you to conclude more or less the same. Best Regards, Norbert. Frank Prepelica wrote: 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. Hi Norbert, thank you for your fast reply! You are absolutly right! I made a silly mistake. I've read the value of the 0xe0002110 with a 8bit pointer. The value is actually 0xC310 which means the 16bit bus width is set. Just to be sure. Is this the only change (in the bootloader) I have to make that all data accesses are 16bit wide? Btw. We did some performance tests with 16 bit bus-width (DDR2 memory) and surprisingly performance was almost as good as 32 bit bus-width This is exactly our intention to test. Thanks for that hint. Very good to know! Thank you. Best regards Frank ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: MPC83xx watchdog reset board dead lock
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 machine check interrupt (i.s.o. HRESET). Maybe it's possible (or even done already) to put the flash into READ-mode from the isr ? --- N. van Bolhuis. Leon Woestenberg wrote: Hello, this is a hardware, even board issue, but I hope to find the right target audience here. In our MPC83xx design I would like to prevent dead lock in case where a field upgrade is performed, i.e. NOR Flash is erased or written, and the MPC83xx built-in hardware watchdog triggers. In u-boot the scenario can be easily reproduced by running this command (WARNING, erases some sectors!) on an MPC8313E-RDB: erase_wdg=mw.l 0xe204 0x1007 1;mw.w 0xe20e 0x556c 1;mw.w 0xe20e 0xaa39 1;erase 1:10-30 This sets up the watchdog to reset soonish, then starts erasing NOR sectors. Watchdog triggers and resets - Dead lock. Most MPC8xxx board designs I have seen suffer from this possible dead lock: - NOR Flash is put in erase mode or write mode - Hardware watchdog triggers - HRESET# is asserted by the processor, during which the configuration words are read from NOR Flash. Either HRESET# is not attached to NOR, NOR stays in erase/write mode and invalid words will be read - dead lock or either: HRESET# is attached to NOR reset, NOR is reset, but stays in reset as HRESET# stays asserted. We have been looking at several solutions hardware wise that reset the NOR flash on HRESET# going low, but the processors are stubborn, read the config words only once, than dead lock. I wonder if there are known-working designs for this. Regards, ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: MPC83xx watchdog reset board dead lock
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 is running critical software. No lifes in danger when it happens, only jobs, so no biggy :-) true, I was just looking from SW/u-boot perspective. Ideally the dead-lock is prevented on board/HW level. David has been helpful in thinking this through, but we followed-up offline, and we independently came up with the following design, so this must therefore work (disclaimer applies). Note, it DOES require a NOR flash that has a RY/BUSY# pin. Quoting David Hawkins, who gave a very clear explanation: --- How about using the RDY/BUSY# pin on the Flash in conjunction with PORESET#. If the flash is busy, then the processor gets PORESET#, otherwise, the HRESET# just does its normal thing. That way PORESET# only ever asserts when you have the combo of the Flash being busy and HRESET# asserting. ... If you have the Flash BUSY# signal, then this scheme works great, since using HRESET# low and BUSY# low to create a PORESET# source is only active until the Flash RESET# is asserted long enough for it to get out of the BUSY# state and back into read-array mode. --- Kudos to David. I'll be testing the design tomorrow on the reference board, I'll report results in this thread. Interesting. Looking forward to the results. --- N. van Bolhuis. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: MPC8272- Porting HDLC driver from 2.6.14 to 2.6.27- no_irq_chip error
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 hardware irq numbers and virtual irq numbers.
request_irq() expects a virtual irq number.
Here's some background info why the linux PowerPC kernel works this way:
The basic request_irq() function is generic, but the value of the
arguments (especially the number for the IRQ line) is architecture
specific in many ways. This is one difference between the i386 code
and the powerpc code inside Linux. Most i386 hardware is standard
PC hardware with very clearly defined interrupt sources. Because of
this, the mapping from the numeric IRQ value to a real hardware
interrupt source is defined pretty clearly.
(In fact, not even clearly anymore :-) IE, there are still some legacy
interrupts at fixed numbers but most things are remapped on x86 too
nowadays when using IO_APICs, the kernel obtains numbers from ACPI,
remaps them etc...)
The powerpc architecture code has to support almost arbitrarily complex
hardware, and the embedded world is the source of most of the complexity.
Because of this, the powerpc code has to dynamically allocate those numeric
IRQ sources and tie them to a specific hardware interrupt.
This is why there's a mapping between hardware irq numbers and virtual
irq numbers.
this is an example of how a simple 8313 Periodic Interval Timer (PIT) kernel
driver
registers for the PIT IRQ (Interrupt ID 65)
#define PIT_IRQ 65
virq = irq_create_mapping(NULL, PIT_IRQ);
set_irq_type(virq, IRQ_TYPE_LEVEL_LOW);
if(request_irq(virq, (irq_handler_t)timerEvent, 0, timer2, (void *)0)) {
printk(KERN_ERR request_irq() returned error for irq=%d virq=%d\n,
PIT_IRQ, virq);
}
All the above info comes from this mailing (and the linuxppc-embedd list)
though.
If you search these lists you'll find plenty of answers to similar questions.
---
N. van Bolhuis
AimValley
Daniel Ng wrote:
Hi,
I'm attempting to port our Ethos HDLC driver from 2.6.14 to 2.6.27, on
a MPC8272-based platform.
So far, the kernel crashes when the driver tries to open (see below).
It seems that the interrupt handler fails to register, with the
following condition in setup_irq() in manage.c:
desc-chip == no_irq_chip
I notice that the only place where desc-chip is assigned to anything
else besides no_irq_chip is in __set_irq_handler() in
kernel/irq/chip.c
In that file, __set_irq_handler() assigns desc-chip to
dummy_irq_chip, but this seems to be done for a special ARM-specific
case, according to the commenting:
/*
* Some ARM implementations install a handler for really dumb
* interrupt hardware without setting an irq_chip. This worked
* with the ARM no_irq_chip but the check in setup_irq would
* prevent us to setup the interrupt at all. Switch it to
* dummy_irq_chip for easy transition.
*/
Should I try to somehow call __set_irq_handler(), or should I be
looking elsewhere?
If I should be calling __set_irq_handler(), it seems the only relevant
function that calls this is cpm2_pic_host_map().
The only relevant functions which call cpm2_pic_host_map() are
irq_setup_virq() or irq_alloc_hosts() with the IRQ_HOST_MAP_LEGACY
parameter. IRQ_HOST_MAP_LEGACY seems to be irrelevant. Can someone
tell me what a virq is?
Cheers,
Daniel
Badness at c00224ec [verbose debug info unavailable]
NIP: c00224ec LR: c019b254 CTR: c01aa9f8
REGS: c1a49c70 TRAP: 0700 Not tainted (2.6.27.19-800-OS-03050107)
MSR: 00021032 ME,IR,DR CR: 22002022 XER:
TASK = c1bda400[306] 'pppd' THREAD: c1a48000
GPR00: 0001 c1a49d20 c1bda400 c0318880 c19c4d80 c1b92211
GPR08: 1032 c02cb240 22002022 fffe 01ff8000
GPR16: 10344020 0002 10049ac0 c194f800 8914 c18cd900 c18cd90c
GPR24: c1a49e48 9032 c1a48000 c02b5fdc 0002 c19c4d80 c1a48000 c1a48000
NIP [c00224ec] local_bh_enable+0x94/0xb4
LR [c019b254] dev_queue_xmit+0x108/0x580
Call Trace:
[c1a49d20] [c19c4d80] 0xc19c4d80 (unreliable)
[c1a49d30] [c019b254] dev_queue_xmit+0x108/0x580
[c1a49d50] [c016ac98] sppp_flush_xmit+0x20/0x44
[c1a49d60] [c016c0b4] sppp_open+0x80/0xac
[c1a49d80] [c016a104] ppp_open+0x70/0x98
--- Exception: bfd26bb0 at 0x8914
LR = 0xc1a49e90
[c1a49da0] [c01699e0] hdlc_open+0x3c/0x104 (unreliable)
[c1a49dc0] [c016cdd4] ethos_wan_genhdlc_open+0xb0/0xef8
[c1a49df0] [c019c490] dev_open+0xbc/0x120
[c1a49e00] [c019bbc8] dev_change_flags+0x8c/0x1d0
[c1a49e20] [c01e1678] devinet_ioctl+0x700/0x7ac
[c1a49e90] [c01e2538] inet_ioctl+0xcc/0xf8
[c1a49ea0] [c018b584] sock_ioctl+0x60/0x268
[c1a49ec0] [c0084ab0] vfs_ioctl+0x3c/0xc4
[c1a49ee0] [c0084bb8] do_vfs_ioctl+0x80/0x454
[c1a49f10] [c0084fcc] sys_ioctl+0x40/0x88
[c1a49f40] [c000f928] ret_from_syscall+0x0/0x38
--- Exception: c01 at 0x480af50c
LR =
Re: howto disable dcache (on a MPC8313)
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 the data-cache is initially used for data and stack. Once RAM is available and the u-boot relocation has been done the data cache can be disabled by clearing DCE in HID0. This must be done after flushing the cache. diff -C 5 -r1.3 start.S *** start.S 2 Apr 2009 10:36:46 - 1.3 --- start.S 8 May 2009 13:44:38 - *** *** 928,937 --- 928,949 5:dcbst 0,r4 add r4,r4,r6 cmplw r4,r5 blt 5b sync/* Wait for all dcbst to complete on bus */ + + /* disable data-cache (TEST) */ + mfspr r20, HID0 + li r21, HID0_DCE|HID0_DLOCK + andcr20, r20, r21 + ori r21, r20, HID0_DCFI + sync + mtspr HID0, r21 /* sets invalidate, clears enable and lock */ + sync + mtspr HID0, r20 /* clears invalidate */ + + mr r4,r3 6:icbi0,r4 add r4,r4,r6 cmplw r4,r5 blt 6b The linux kernel enables the cache through __setup_cpu_603 - setup_common_caches this function gets called from call_setup_cpu which has nothing to do with CONFIG_(HAVE_)OPROFILE. It's easy to modify this function not to set the HID0_DCE (without caring much about the assembly). diff -C 5 -r1.1.1.1 cpu_setup_6xx.S *** arch/powerpc/kernel/cpu_setup_6xx.S 5 Jan 2009 10:55:25 - 1.1.1.1 --- arch/powerpc/kernel/cpu_setup_6xx.S 8 May 2009 13:53:31 - *** *** 79,90 blr /* Enable caches for 603's, 604, 750 7400 */ setup_common_caches: mfspr r11,SPRN_HID0 ! andi. r0,r11,HID0_DCE ! ori r11,r11,HID0_ICE|HID0_DCE ori r8,r11,HID0_ICFI bne 1f /* don't invalidate the D-cache */ ori r8,r8,HID0_DCI /* unless it wasn't enabled */ 1:sync mtspr SPRN_HID0,r8/* enable and invalidate caches */ --- 79,90 blr /* Enable caches for 603's, 604, 750 7400 */ setup_common_caches: mfspr r11,SPRN_HID0 ! andi. r0,r11,(014) ! ori r11,r11,HID0_ICE|(014) ori r8,r11,HID0_ICFI bne 1f /* don't invalidate the D-cache */ ori r8,r8,HID0_DCI /* unless it wasn't enabled */ 1:sync mtspr SPRN_HID0,r8/* enable and invalidate caches */ ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Fix bug in __futex_atomic_op
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 wrote:
Richard Henderson pointed out that the powerpc __futex_atomic_op has a
bug: it will write the wrong value if the stwcx. fails and it has to
retry the lwarx/stwcx. loop, since 'oparg' will have been overwritten
by the result from the first time around the loop. This happens
because it uses the same register for 'oparg' (an input) as it uses
for the result.
This fixes it by using separate registers for 'oparg' and 'ret'.
Cc: sta...@kernel.org
Signed-off-by: Paul Mackerras pau...@samba.org
---
Can anyone see any reason why the FUTEX_OP_SET case can't just do a
__put_user?
diff --git a/arch/powerpc/include/asm/futex.h b/arch/powerpc/include/asm/futex.h
index 6d406c5..9696cc3 100644
--- a/arch/powerpc/include/asm/futex.h
+++ b/arch/powerpc/include/asm/futex.h
@@ -27,7 +27,7 @@
PPC_LONG 1b,4b,2b,4b\n \
.previous \
: =r (oldval), =r (ret) \
- : b (uaddr), i (-EFAULT), 1 (oparg) \
+ : b (uaddr), i (-EFAULT), r (oparg) \
: cr0, memory)
static inline int futex_atomic_op_inuser (int encoded_op, int __user *uaddr)
@@ -47,19 +47,19 @@ static inline int futex_atomic_op_inuser (int encoded_op,
int __user *uaddr)
switch (op) {
case FUTEX_OP_SET:
- __futex_atomic_op(, ret, oldval, uaddr, oparg);
+ __futex_atomic_op(mr %1,%4\n, ret, oldval, uaddr, oparg);
break;
case FUTEX_OP_ADD:
- __futex_atomic_op(add %1,%0,%1\n, ret, oldval, uaddr, oparg);
+ __futex_atomic_op(add %1,%0,%4\n, ret, oldval, uaddr, oparg);
break;
case FUTEX_OP_OR:
- __futex_atomic_op(or %1,%0,%1\n, ret, oldval, uaddr, oparg);
+ __futex_atomic_op(or %1,%0,%4\n, ret, oldval, uaddr, oparg);
break;
case FUTEX_OP_ANDN:
- __futex_atomic_op(andc %1,%0,%1\n, ret, oldval, uaddr, oparg);
+ __futex_atomic_op(andc %1,%0,%4\n, ret, oldval, uaddr, oparg);
break;
case FUTEX_OP_XOR:
- __futex_atomic_op(xor %1,%0,%1\n, ret, oldval, uaddr, oparg);
+ __futex_atomic_op(xor %1,%0,%4\n, ret, oldval, uaddr, oparg);
break;
default:
ret = -ENOSYS;
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Can not get new MPC8313e-RDB to boot as-shipped flash image
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 = enet1;
serial0 = serial0;
serial1 = serial1;
pci0 = pci0;
};
.
.
Not being able to find alias serial0 (in the DTB) causes this problem.
see u-boot/common/fdt_support.c:fdt_fixup_stdout
Older u-boots don't expect them. My REV A4 board was shipped with
U-Boot 1.1.6 (Aug 24 2007 - 13:10:12) MPC83XX (which obviously not expects
the aliases).
If I flash a new/custom u-boot (U-Boot 2008.10) the problem occurs.
I assume Freescale ships their REV A4 boards with a u-boot not expecting the
aliases.
I assume your u-boot 1.3.3 is not the one the board was shipped with,
are are you saying it is ?
---
N. van Bolhuis.
Eric Cottrell wrote:
Hello,
This is getting frustrating and I am beginning to think someone messed this
board up and returned it. I would think it would boot up the default flash
image out of the box with very little trouble.
Board is a MPC8313e-RDB Rev A4. I set the dip switches per the instructions,
S4 all off and S3 all on.
Uboot comes up but I can not boot either the default images in the flash or
images I built with ltib and tftped. I did not touch the flash. I get
WARNING: could not set linux,stdout-path FDT_ERR_NOTFOUND and ERROR: /chosen
node create failed - must RESET the board to recover. The board resets.
A friend has the same board but his U-Boot is Version 1.3.0 (Jun 19 2008 -
13:41:53) MPC83XX and some environment variables are different. I do not have
the BOOTCMD variable but entered it manually.
I tried searching for on a solution but it is confusing because if aliases are
needed why does the default dtb in the flash omit them?
This is what happens:
U-Boot 1.3.3 (Dec 8 2008 - 09:51:15) MPC83XX
Reset Status:
CPU: e300c3, MPC8313E, Rev: 1.0 at 333.333 MHz, CSB: 166.666 MHz
Board: Freescale MPC8313ERDB
I2C: ready
DRAM: 128 MB
FLASH: 8 MB
In:serial
Out: serial
Err: serial
Net: TSEC0, TSEC1 [PRIME]
= bootm fe10 fe30 fe70
## Booting kernel from Legacy Image at fe10 ...
Image Name: Linux-2.6.20
Created: 2007-08-24 14:59:01 UTC
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size:1722821 Bytes = 1.6 MB
Load Address:
Entry Point:
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
## Flattened Device Tree blob at fe70
Booting using the fdt blob at 0xfe70
## Loading init Ramdisk from Legacy Image at fe30 ...
Image Name: uboot ext2 ramdisk rootfs
Created: 2007-08-24 15:01:41 UTC
Image Type: PowerPC Linux RAMDisk Image (gzip compressed)
Data Size:2831355 Bytes = 2.7 MB
Load Address:
Entry Point:
Verifying Checksum ... OK
Loading Device Tree to 007fd000, end 007f ... OK
WARNING: could not set linux,stdout-path FDT_ERR_NOTFOUND.
ERROR: /chosen node create failed - must RESET the board to recover.
Resetting the board.
U-Boot 1.3.3 (Dec 8 2008 - 09:51:15) MPC83XX
Reset Status: Software Hard, External/Internal Soft, External/Internal Hard
CPU: e300c3, MPC8313E, Rev: 1.0 at 333.333 MHz, CSB: 166.666 MHz
Board: Freescale MPC8313ERDB
I2C: ready
DRAM: 128 MB
FLASH: 8 MB
In:serial
Out: serial
Err: serial
Net: TSEC0, TSEC1 [PRIME]
=
73 Eric
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Can not get new MPC8313e-RDB to boot as-shipped flash image
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 bugs). --- N. van Bolhuis. Eric Cottrell wrote: Hello, Thanks for the help. I will look into that. It is confusing as the latest ltib appears not to have the aliases. This is my first venture into Embedded Linux as our existing PowerPC products use PSOS. Most of my Linux experience is on the Intel PC platform. Yes, the 1.3.3 version was what was shipped with the board. The rootfs and kernel appear to be older. So I suspect someone upgraded the uBoot and ran into trouble. I am comparing this with the Rev B board we also got. I hope to return the Rev A4 and make the boards all Rev B because it has a later processor. The Rev B boards have 1.3.0 so it should need the aliases as well. Looking in the uBoot changelogs there are some nice additions and fixes for this board so I will look to dig more into uBoot and upgrade it. I hate to stumble out of the box. 73 Eric ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Nasty gunzip problem on MPC8313E-RDB
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 using a jtag debugger no problem occurs. The stock u-boot (shipped by Freescale) has the problem, any custom built u-boot (v2008.10 or v2009-rc3) also has the problem. I tested with u-boot.v2009-rc3 on another board (a PQ2FADS board). The problem doesn't occur on this board. I would like to find this problem and I could use all the help I can get. I'm a bit stuck at the moment. It's not the watchdog, nor the compiler toolchain. The watchdog is completely disabled anyway and other compiler toolchains (including the ones from Freescale) make no difference. I already tried to raise the u-boot malloc() area, it makes no difference either. when compressing using bzip2 (either --best or --fast) no problem occurs. The problem occurs only for gzip compressed files which have one or more dynamic codes blocks and a final fixed codes block. I made a very small one, it's attached. It's only 5802 bytes and md5sum = d5e5a4c95451d256520f1b2a7ace8fa5 Btw. mostly gzip compressed files have dynamic codes blocks only. This file is in fact a collection of random bytes compressed with gzip -9 and a u-boot header in front. If I load this file into RAM (with tftp) and try to uncompress it (by trying to bootm it) the problem always occurs. If anybody is willing to try this file on a MPC8313E-RDB and/or help me with this problem please reply. uImage Description: Binary data ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
some (MPC8313) Freescale patches not in latest kernel
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 other peripherals seems to work as well, I never really tried them though. However, the Freescale MPC8313 BSP (and http://www.bitshrine.org/gpp/) includes a few patches which I believe I need and/or are useful, for instance: linux-fsl-2.6.23-MPC8313ERDB-ETSEC27-errata-workaround.patch linux-fsl-2.6.23-MPC8313ERDB-IEEE-1588.patch linux-fsl-2.6.23-GIANFAR_PARAMETER_ADJUST.patch linux-fsl-2.6.23-GIANFAR_SKB_BUFFER_RECYCLING_SUPPORT.patch linux-fsl-2.6.23-GIANFAR_SKB_BUFFER_RECYCLING_SUPPORT-2.patch These patches are not in the latest (2.6.28-rc7) linux kernel nor in any of the powerpc devlopment trees (e.g. git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git) Of course users like me can simply check out the patches and apply them if needed for the project. Before I do that I would just like to understand why they're not in. They're not MPC8313(-RDB) specific and they seem very useful to me. Is it lack of time/importance ? ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
NAND only (no NOR)
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 booting from NAND is possible. U-boot seems to support it well, I assume it can read the kernel, ramdisk and dtb from NAND in memory and bootm this. However, having no NOR flash means: - NAND should be programmable via JTAG (BDI3000 doesn't support this, Lauterbach/trace32 does) - Critical software images (u-boot, kernel, dtb) stored on NAND, while there's no NAND 'scrubbing', etc.. Thoughts/comments are welcome. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: too few bogoMips on MPC8313E-RDB ?
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 MHz. Alessandro Rubini wrote: This is what a linux-2.6.x reports (for the MPC8313E running at 333 MHz): Calibrating delay loop... 83.20 BogoMIPS (lpj=166400) Which can't be correct. A MPC870 (running at 133 mhz) has ~ 131.07 BogoMIPS Actaully, one-instruction-per-clock leads to BogoMIPS = MHz. Your loop per jiffies value shows you make 332800 instructions per jiffy (a loop is two instructions: increment and jump). So most liker your timer tick runs at 1000 Hz but Linux is thinking it's at 250Hz (332800 * 250 = 83.20 millions). Of course it's only a benchmark figure. No, it's not a benchmark figure. It's the metric by which udelay() is calculated. So your udelays (and mdelays) will be 4 times shorter than required, and some hardware may be misbehaving as a result. Hope this help /alessandro, who however is not runing a powerPC these times ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: too few bogoMips on MPC8313E-RDB ?
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, but at least now I know/understand. Thanks to everybody for their answers. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
