One of the guys on TI E2E who's team is looking into this issue for their custom board, noted some things from the console log on TI E2E. I've pasted that here. I'm not sure if this rings a bell to anyone or provides additional insight as to DDR3 timing, etc.
" . . My colleague went back through the logs (interns are great resources!). Here's what he found. We seem to have two failure modes. I went through the log files of 5 failures that display “Unable to handle kernel paging request” error message. The system first displays the message PC is at n_tty_receive_buf_common+0x7c/0xa60 and then sometimes it also displays PC is at kthread_data+0x10/0x18 at the same startup after few lines and sometimes it just displays the message PC is at n_tty_receive_buf_common+0x7c/0xa60 Here is what I can see form the log files, sometimes the system displays unable to hande kernel paging request at 00002248 and also at ffffffec, whenever the address is 00002248 – the PC is at n_tty and when the address is ffffffec – the PC is at kthread. The pgd is always at pgd = c0003000 in case of both the error messages. *pgd is different for both the cases but same for all the failures. *pgd=80000080004003 *pgd=80000080007003 . . . " On Friday, March 23, 2018 at 10:26:21 AM UTC-5, Jeff Andich wrote: > > Thanks Robert! > > Will try to keep everyone updated on here or reference developments on the > "parallel" E2E thread. > > Regards, jeff > > > > On Friday, March 23, 2018 at 9:40:13 AM UTC-5, RobertCNelson wrote: >> >> On Fri, Mar 23, 2018 at 9:30 AM, Jeff Andich <jeff....@gmail.com> wrote: >> > Hey Robert, >> > >> > The EEPROM is mostly board ID, serial number, and Ethernet MAC >> addresses >> > right? There isn't anything which is DRAM-specific in EEPROM, right? >> > >> > My understanding is the EEPROM contains the board ID which u-boot-spl >> and >> > u-boot use to customize the configurations for each specific board... >> I >> > understand that most of the board-specific changes are contained in the >> > board.c file, but I'm wondering if there are other critical >> configurations >> > in the /arch/arm/mach-omap2 directory. I also added some >> configurations for >> > our custom board type to the Kconfig in the mach-omap2 directory. This >> > looks to be menu options for a makemenuconfig GUI like for the kernel?? >> > >> > >> > Have asked the TI folks on the above-referenced E2E post if there's a >> DDR3 >> > test tool which can be run for an extended test. >> > >> > The guy on E2E who's having a similar issue, implied that his firmware >> > engineers already tuned the IO Delays. Maybe it's something else?? >> > >> > I wonder who the people are who actually derive the IO delays (e.g. the >> > GDELAY equtions) and tune them for boards like the BB-X15.. How does >> that >> > process work?? Maybe that's in TI's SPRAC44 ap note.. I still wonder, >> how >> > do you know when you've hit the sweet spot in terms of the optimum >> values?? >> > >> > This doesn't appear to happen very frequently, but it's probably >> prudent to >> > get a handle on what makes it crop up.. >> >> We got our magic numbers directly from TI.. >> >> Thus, i'm not sure how they were generated... >> >> Regards, >> >> -- >> Robert Nelson >> https://rcn-ee.com/ >> > -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/05c2076e-0be5-4f76-8c13-928749833475%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
