RE: Regression detecting memory size on PPC440EPx
Mikhail Zolotaryov wrote: > Hi Mike, > > you wrote: > "Row address bits : 13 > DDR0_02 = 0x020C0E01 > DDR0_42 = 0x0006" > > Register values above define that memory has 14 row address bits. The > correct setting is (for CAS Latency = 3): > DDR0_42 = 0x0106 > > Best regards, > Mikhail Zolotaryov > Thank you! It was a bug in U-Boot (they were encoding that register incorrectly). I'll submit a patch to them. Mike ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: Regression detecting memory size on PPC440EPx
Valentine wrote: > AFAIK, u-boot just writes pre-defined values to the memory controller > registers. It doesn't do any chiptype/memsize detection. These values > are set for Sequoia and may not suite your board. So you probably need > to adjust the u-boot to make linux detect the memory size correctly. > > Thanks, > Val. In old versions of U-Boot that was true. Now there is definitely code that reads the SPD EEPROM and sets up the Denali controller appropriately. There could be some hardcoded value being written to the registers that is incorrect for the kernel - in fact that is my suspicion - but the values U-Boot itself is using for the size calculation must be correct. Mike PS: Is top posting customary on this list? I'm used to bottom posting; let me know if I'm doing it wrong. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: Regression detecting memory size on PPC440EPx
(top-posting corrected) Mikhail Zolotaryov wrote: > Mike Nuss wrote: >> There was a fix a while back called "Correct memory size calculation >> for Denali based boards" that corrected the data width detection in >> the 4xx bootwrapper. >> >> This seems to have had the unintended consequence of exposing another >> bug in the same code. I have a board very similar to Sequoia, except >> that it uses a DDR2 DIMM module. It uses a single 256MB DIMM. After >> upgrading to the latest kernel, which includes the previously >> mentioned fix, U-Boot works fine, but the kernel detects 512MB >> instead, and of course, the kernel panics. >> >> The error seems to be in the calculation of row bits. U-Boot's SPD >> detection says that the DIMM uses 13 bits, but I added some >> printf()s to the bootwrapper, and it is setting row to 14 instead. >> I'm not too clear on how this code works; it calculates the row bits >> by subtracting the row from max_row, and maybe max_row is wrong? > > Hi Mike, > > Address width calculation is based on the DDR-controller configuration > set by the bootloader. It would be helpful for further discussion if > you could send DDR0_00..DDR0_44 register values and memory > configuration used (no of banks, bank size, I/O width) to check > calculations. Thanks. > > P.S. Sequoia board also has DDR2 SDRAM from Micron. > > Best regards, > Mikhail Zolotaryov Thanks for your reply. Here is the dump from U-Boot during intialization with DEBUG turned on in the denali code: Register Dump: DDR0_00 = 0x190ADDR0_01 = 0x01FF DDR0_02 = 0x020C0E00DDR0_03 = 0x02030602 DDR0_04 = 0x0A020200DDR0_05 = 0x02020308 DDR0_06 = 0x0102C812DDR0_07 = 0x000D0100 DDR0_08 = 0x02C80001DDR0_09 = 0x00011D5F DDR0_10 = 0x0100DDR0_11 = 0x0022C800 DDR0_12 = 0x0003DDR0_14 = 0x DDR0_17 = 0x1900DDR0_18 = 0x19191919 DDR0_19 = 0x19191919DDR0_20 = 0x0B0B0B0B DDR0_21 = 0x0B0B0B0BDDR0_22 = 0x00267F0B DDR0_23 = 0xDDR0_24 = 0x01020001 DDR0_25 = 0x2041DDR0_26 = 0x2DB40514 DDR0_27 = 0x8236DDR0_28 = 0x DDR0_31 = 0xDDR0_32 = 0x DDR0_33 = 0xDDR0_34 = 0x DDR0_35 = 0xDDR0_36 = 0x DDR0_37 = 0xDDR0_38 = 0x DDR0_39 = 0xDDR0_40 = 0x DDR0_41 = 0xDDR0_42 = 0x0006 DDR0_43 = 0x030A0200DDR0_44 = 0x0003 dram_size = 268435456 Register Dump: DDR0_00 = 0x00C0190ADDR0_01 = 0x01FF DDR0_02 = 0x020C0E01DDR0_03 = 0x02030602 DDR0_04 = 0x0A020200DDR0_05 = 0x02020308 DDR0_06 = 0x0102C812DDR0_07 = 0x000D0100 DDR0_08 = 0x02C80001DDR0_09 = 0x00011D5E DDR0_10 = 0x0100DDR0_11 = 0x0022C800 DDR0_12 = 0x0003DDR0_14 = 0x DDR0_17 = 0x1E014800DDR0_18 = 0x1E1E1E1E DDR0_19 = 0x1E1E1E1EDDR0_20 = 0x0B0B0B0B DDR0_21 = 0x0B0B0B0BDDR0_22 = 0x00267E0B DDR0_23 = 0xDDR0_24 = 0x01020001 DDR0_25 = 0x2041DDR0_26 = 0x2DB40514 DDR0_27 = 0x8236DDR0_28 = 0x DDR0_31 = 0xDDR0_32 = 0x DDR0_33 = 0xDDR0_34 = 0x DDR0_35 = 0xDDR0_36 = 0x DDR0_37 = 0xDDR0_38 = 0x DDR0_39 = 0xDDR0_40 = 0x DDR0_41 = 0xDDR0_42 = 0x0006 DDR0_43 = 0x030A0200DDR0_44 = 0x0003 Zeroing SDRAM...Completed 256 MB (ECC not enabled, 333 MHz, CL3) Here is the memory configuration: SPD data revision1.2 Bytes used 0x80 Serial memory size 0x100 Memory type DDR2 Row address bits 13 Column address bits 10 Number of ranks 1 Module data width64 bits Interface signal levels SSTL 1.8 V SDRAM cycle time 3.0 ns SDRAM access time0.45 ns EDC configurationNone Self refresh, rate 7.8 us SDRAM width (primary)16 Burst length(s) 8 4 Number of banks 4 CAS latency(s) 5 4 3 Module attributes: 0 PLLs on DIMM Supports 50 ohm ODT Supports weak driver SDRAM cycle time (2nd highest CAS latency)3.75 ns SDRAM access from clock (2nd highest CAS latency) 0.45 ns SDRAM cycle time (3rd highest CAS latency)5.0 ns SDRAM access from clock (3rd highest CAS latency
Regression detecting memory size on PPC440EPx
There was a fix a while back called "Correct memory size calculation for Denali based boards" that corrected the data width detection in the 4xx bootwrapper. This seems to have had the unintended consequence of exposing another bug in the same code. I have a board very similar to Sequoia, except that it uses a DDR2 DIMM module. It uses a single 256MB DIMM. After upgrading to the latest kernel, which includes the previously mentioned fix, U-Boot works fine, but the kernel detects 512MB instead, and of course, the kernel panics. The error seems to be in the calculation of row bits. U-Boot's SPD detection says that the DIMM uses 13 bits, but I added some printf()s to the bootwrapper, and it is setting row to 14 instead. I'm not too clear on how this code works; it calculates the row bits by subtracting the row from max_row, and maybe max_row is wrong? It looks like the data width bug canceled out this bug before, since these values end up changing the memory size by a factor of 2 (in opposite directions). Could someone with a better understanding of this code take a look? Thanks, Mike ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Book-E watchdog driver questions
On Sep 25, 2007 1:18 PM, Mike Nuss <[EMAIL PROTECTED]> wrote: > > > Is there a reason that booke_wdt.c does not specify a MODULE_LICENSE? > > >> From the copyright notice at the top it appears to be GPL. As > > >> written, > > > it taints the kernel. > > > > Odd, no reason. I'll submit a patch for that. > > > > > Also, if I test out the driver by killing my process that's doing the > > > pinging, I get a kernel panic: > > > > Its been a while since i've tried this. I'll try it out and see what > > happens. The kernel panic was caused because TCR: WIE was set. This bit should not be set, because it causes the timer to generate an interrupt that the kernel does not handle. > > I also found that GETBOOTSTATUS returns 0 after the reboot. Looking at > the source code I found the comment "XXX: something is clearing TSR" - > I take that to mean that the register is being cleared by something > before the module tries to read it? In my case U-Boot may be clearing > that - I can take a look. It turns out that the status bits in TSR are undefined at poweron reset. Boards require external logic to detect POR - this is described in AMCC's app note for the WDT. Because of this, U-Boot clears TSR early on in the standard 4xx firmware (in start.S). To use TSR to detect a watchdog reset, U-Boot must be modified to check that logic and only clear the bits at POR. Those bits will be preserved until the kernel driver looks at them, or until the system is powered off. So the driver is correct here, but the comment should be updated to explain why the GETBOOTSTATUS value may not be meaningful - it requires additional hardware and firmware support. I can submit a patch for these issues if you like. Mike ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Using PVR value after boot?
I'm writing a module for the Security/KASUMI function on the PPC440EPx-S and PPC440GRx-S. This relies on checking the PVR value at runtime, which is done early on in the boot process. What would be the correct way to check which CPU is present during module initialization? Thanks, Mike ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Book-E watchdog driver questions
> > Is there a reason that booke_wdt.c does not specify a MODULE_LICENSE? > >> From the copyright notice at the top it appears to be GPL. As > >> written, > > it taints the kernel. > > Odd, no reason. I'll submit a patch for that. > > > Also, if I test out the driver by killing my process that's doing the > > pinging, I get a kernel panic: > > Its been a while since i've tried this. I'll try it out and see what > happens. I also found that GETBOOTSTATUS returns 0 after the reboot. Looking at the source code I found the comment "XXX: something is clearing TSR" - I take that to mean that the register is being cleared by something before the module tries to read it? In my case U-Boot may be clearing that - I can take a look. Mike ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Book-E watchdog driver questions
Hi, I have a PPC440EPx and I am testing out the builtin watchdog. I have a couple of questions: Is there a reason that booke_wdt.c does not specify a MODULE_LICENSE? >From the copyright notice at the top it appears to be GPL. As written, it taints the kernel. Also, if I test out the driver by killing my process that's doing the pinging, I get a kernel panic: Bad trap at PC: c0009268, MSR: 29000, vector=1022Tainted: P Oops: Exception in kernel mode, sig: 5 [#1] NIP: C0009268 LR: C00092C4 CTR: C002F6E4 REGS: c02d7f50 TRAP: 1022 Tainted: P(2.6.21-rc4-ts-1-ppc) MSR: 00029000 CR: 24D12582 XER: TASK = c02809d0[0] 'swapper' THREAD: c029c000 GPR00: C029DF90 C02809D0 C0008294 00072951 GPR08: 2D0F C02D9800 22044288 5196 0FFB2C00 0001 GPR16: 007FFF23 0080 007FFF00 0FFAE6A0 0001 GPR24: 007FFE70 C02D8000 C02D C02E C029C028 0010 C029C000 NIP [C0009268] cpu_idle+0x64/0xd0 LR [C00092C4] cpu_idle+0xc0/0xd0 Call Trace: [C029DF90] [C00092C4] cpu_idle+0xc0/0xd0 (unreliable) [C029DFB0] [C00012B4] rest_init+0x28/0x38 [C029DFC0] [C029E720] start_kernel+0x220/0x29c [C029DFF0] [C200] skpinv+0x1a8/0x1e4 Instruction dump: 3810 7d20e828 7d290378 7d20e92d 40a2fff4 801f0028 393c9800 700b0008 40820064 80090030 3bc00010 2f80 <419e0060> 7c00e828 7c00f078 7c00e92d Bad trap at PC: c0003408, MSR: 21000, vector=1022Tainted: P Oops: Exception in kernel mode, sig: 5 [#2] NIP: C0003408 LR: C0002100 CTR: REGS: c02d7f50 TRAP: 1022 Tainted: P(2.6.21-rc4-ts-1-ppc) MSR: 00021000 CR: 44D12522 XER: TASK = c02809d0[0] 'swapper' THREAD: c029c000 GPR00: 0800 C02D7DD0 C02809D0 C02D7DE0 0001 0001 4000 GPR08: C02D C0002100 00021002 C0003408 C0280B80 0FFB2C00 0001 GPR16: 007FFF23 0080 007FFF00 0FFAE6A0 0001 GPR24: 007FFE70 C02D8000 C02D C02E 0005 C02D7F50 NIP [C0003408] timer_interrupt+0x0/0x224 LR [C0002100] ret_from_except+0x0/0x18 Call Trace: Instruction dump: 7d0b4378 7d635b78 4e800020 3d20c02d 800950bc 7c1603a6 7d4c42e6 3d20c02e 3d60c02d 9149f384 914b50b4 4e800020 <7c0802a6> 9421ffc0 be810010 90010044 Kernel panic - not syncing: Attempted to kill the idle task! Rebooting in 180 seconds..Bad trap at PC: c00066b8, MSR: 21000, vector=1022Tainted: P Oops: Exception in kernel mode, sig: 5 [#3] NIP: C00066B8 LR: C0002100 CTR: 00033C76 REGS: c02d7f50 TRAP: 1022 Tainted: P(2.6.21-rc4-ts-1-ppc) MSR: 00021000 CR: 44D12588 XER: TASK = c02809d0[0] 'swapper' THREAD: c029c000 GPR00: 00182000 C02D7CF0 C02809D0 C02D7D00 0001 0001 0030 GPR08: C02DB2E4 C0002100 00021002 C00066B8 C0280B80 0FFB2C00 0001 GPR16: 007FFF23 0080 007FFF00 0FFAE6A0 0001 GPR24: 007FFE70 C02D8000 C02D 00487AB0 3311 C029 C02D NIP [C00066B8] do_IRQ+0x0/0xb8 LR [C0002100] ret_from_except+0x0/0x18 Call Trace: Instruction dump: 7fc3f378 388a 48073311 4bfffea0 3d20c024 38a97e9c 4b30 3c80c024 38847e84 7fc3f378 48073321 4b08 <7c0802a6> 9421fff0 90010014 bfc10008 Bad trap at PC: c00066b8, MSR: 21000, vector=1022Tainted: P Oops: Exception in kernel mode, sig: 5 [#4] NIP: C00066B8 LR: C0002100 CTR: REGS: c02d7f50 TRAP: 1022 Tainted: P(2.6.21-rc4-ts-1-ppc) MSR: 00021000 CR: 44D12522 XER: TASK = c02809d0[0] 'swapper' THREAD: c029c000 GPR00: C0002810 C02D7DD0 C02809D0 C02D7DE0 0001 0001 4000 GPR08: C02D C0002100 00021002 C00066B8 C0280B80 0FFB2C00 0001 GPR16: 007FFF23 0080 007FFF00 0FFAE6A0 0001 GPR24: 007FFE70 C02D8000 C02D 00487AB0 0005 C02D7F50 NIP [C00066B8] do_IRQ+0x0/0xb8 LR [C0002100] ret_from_except+0x0/0x18 Call Trace: Instruction dump: 7fc3f378 388a 48073311 4bfffea0 3d20c024 38a97e9c 4b30 3c80c024 38847e84 7fc3f378 48073321 4b08 <7c0802a6> 9421fff0 90010014 bfc10008 Bad trap at PC: c00066b8, MSR: 21000, vector=1022Tainted: P Oops: Exception in kernel mode, sig: 5 [#5] NIP: C00066B8 LR: C0002100 CTR: REGS: c02d7f50 TRAP: 1022 Tainted: P(2.6.21-rc4-ts-1-ppc) MSR: 00021000 CR: 44D12522 XER: TASK = c02809d0[0] 'swapper' THREAD: c029c000 GPR00: C0002810 C02D7DD0 C02809D0 C02D7DE0 0001 0001 4000 GPR08: C02D C0002100 00021002 C00066B8 C0280B80 0FFB2C00 0001 GPR16: 007FFF23 0080 007FFF00 0FFAE6A0 0001 GPR24: 007FFE70 C02D8000 C02D 00487AB0 0005 C02D7F50 NIP [C00066B8] do_IRQ+0x0/0xb8 LR [C0002100] ret_from_except+0x0/0x18 Call Trace: Instruction dump: 7fc3f378 388a 48073311 4bfffea0 3d20c024 38a97e9c 4b30 3c80c024 38847e84 7fc3f378 48073321 4b08 <7c0802a6> 9421fff0 90010014 bfc10008 This goes
