| Message ID | 20160107180700.GN12777@atomide.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
Hi, On 7.01.2016 20:07, Tony Lindgren wrote: > > OK well at least that part of the bug is fixed then. > Yes, seems so >>> Also, do things now work reliably for you with CONFIG_OMAP_GPMC_DEBUG >>> enabled? Or does that also produce corruption after few reboots? I'll make further experiments as I am a bit lost what and when happens. What is for sure is that corruptions occurs immediately after boot without your patch and with CONFIG_OMAP_GPMC_DEBUG disabled. So maybe there is another problem in ubfs or mtd driver. >> >> CONFIG_OMAP_GPMC_DEBUG is disabled, shall I enable it? > > Yes please. Already did, every reflash and install of upstream kernel compatible SW takes me about 3 hours I'd rather spend on something else :). Though it seems that reboot issue happens no matter if CONFIG_OMAP_GPMC_DEBUG is enabled or not. > >> Where am I supposed to get the output from ^^^ if rootfs become corrupted? >> The problem appears after poweroff/restart when it is already too late to >> get the syslog. > > Hmm good point. Can you boot with root on MMC? So far no luck here > reproducing the corruption here with my fix applied. Will do, when we exhaust the other options. What I am afraid of, is that if I boot from mmc, I won't be able to reproduce the problem, as there will be no pressure on ubifs/mtd/onenand drivers. > >> BTW, did you compare all the GPMC registers with and without >> HWMOD_INIT_NO_RESET? > > Well the timings now for me both with and without GPMC reset are: > > cs0 GPMC_CS_CONFIG1: 0xfb001201 > cs0 GPMC_CS_CONFIG2: 0x00101000 > cs0 GPMC_CS_CONFIG3: 0x00020200 > cs0 GPMC_CS_CONFIG4: 0x10001003 > cs0 GPMC_CS_CONFIG5: 0x020f1313 > cs0 GPMC_CS_CONFIG6: 0x8f050000 > > These timings also match the current mainline timings without the > fix I posted when CONFIG_OMAP_GPMC_DEBUG is enabled. > > The nolo set timings I have are: > cs0 GPMC_CS_CONFIG1: 0xfb001201 > cs0 GPMC_CS_CONFIG2: 0x00101000 > cs0 GPMC_CS_CONFIG3: 0x00020200 > cs0 GPMC_CS_CONFIG4: 0x10001002 <- OEONTIME is still different in nolo > cs0 GPMC_CS_CONFIG5: 0x020f1313 > cs0 GPMC_CS_CONFIG6: 0x8f050000 > Same here > So there seems to be OEONTIME difference. Once the legacy boot is > gone, we can probably remove the OEONTIME calculations and rely > on the dts provide values as it seems that currently the dts value > is ignored in gpmc_calc_sync_read_timings(). > > To dump your nolo provided timings, you can add the following > line to gpmc_probe_onenand_child() before gpmc_onenand_init: > > gpmc_cs_show_timings(gpmc_onenand_data->cs, > "before gpmc_cs_program_settings"); > The problem is that between NOLO and kernel there is u-boot. And even if I am almost sure it doesn't touch onenand configs, I can't be absolutely sure. So those timings are not 100% reliable IMO, though close to that. > Note that will show the wrong GPMC default values after reset > unless you have CONFIG_OMAP_GPMC_DEBUG enabled. > > Then below is a better debug patch to dump out the values after > reset. Note that in that case the above "before" timings must > be ignored. > > Regards, > > Tony > > 8< -------------------- > --- a/arch/arm/mach-omap2/gpmc-onenand.c > +++ b/arch/arm/mach-omap2/gpmc-onenand.c > @@ -153,6 +153,8 @@ static int omap2_onenand_get_freq(struct omap_onenand_platform_data *cfg, > freq = 0; > } > > + gpmc_cs_show_timings(cs, "before gpmc_cs_program_settings"); > + > return freq; > } > > --- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c > +++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c > @@ -2150,8 +2150,7 @@ static struct omap_hwmod omap3xxx_gpmc_hwmod = { > .clkdm_name = "core_l3_clkdm", > .mpu_irqs = omap3xxx_gpmc_irqs, > .main_clk = "gpmc_fck", > - /* Skip reset for CONFIG_OMAP_GPMC_DEBUG for bootloader timings */ > - .flags = HWMOD_NO_IDLEST | DEBUG_OMAP_GPMC_HWMOD_FLAGS, > + .flags = HWMOD_NO_IDLEST, > }; > > /* > --- a/drivers/memory/omap-gpmc.c > +++ b/drivers/memory/omap-gpmc.c > @@ -1987,7 +1987,7 @@ static int gpmc_probe_generic_child(struct platform_device *pdev, > if (ret < 0) > goto err; > > - gpmc_cs_show_timings(cs, "before gpmc_cs_program_settings"); > + dev_info(&pdev->dev, "GPMC reset, not showing default timings\n"); > ret = gpmc_cs_program_settings(cs, &gpmc_s); > if (ret < 0) > goto err; > I'll play a bit more with printing the values with both CONFIG_OMAP_GPMC_DEBUG enabled and disabled and whatever I can think of, including dumping cs0 config from u-boot, nokia kernel and/or REing NOLO onenand init (already did that for N9 DDR timings, shouldn't be that hard for N900 GPMC). Will keep you informed on the progress. In the meanwhile I think your patch should make it as without it onenand is unusable. Thanks, Ivo -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
* Ivaylo Dimitrov <ivo.g.dimitrov.75@gmail.com> [160107 13:46]: > On 7.01.2016 20:07, Tony Lindgren wrote: > > >>>Also, do things now work reliably for you with CONFIG_OMAP_GPMC_DEBUG > >>>enabled? Or does that also produce corruption after few reboots? > > I'll make further experiments as I am a bit lost what and when happens. What > is for sure is that corruptions occurs immediately after boot without your > patch and with CONFIG_OMAP_GPMC_DEBUG disabled. So maybe there is another > problem in ubfs or mtd driver. Yes it seems there's some other issue too. Maybe you can run git bisect again and carry the fix along as an extra patch? > Already did, every reflash and install of upstream kernel compatible SW > takes me about 3 hours I'd rather spend on something else :). Though it > seems that reboot issue happens no matter if CONFIG_OMAP_GPMC_DEBUG is > enabled or not. OK then it really seems like we do have another bug lurking around. Maybe you can figure out an easier way to reproduce it? > The problem is that between NOLO and kernel there is u-boot. And even if I > am almost sure it doesn't touch onenand configs, I can't be absolutely sure. > So those timings are not 100% reliable IMO, though close to that. Hmm yes I'm only booting with u-boot here as my device sits in my rack. > I'll play a bit more with printing the values with both > CONFIG_OMAP_GPMC_DEBUG enabled and disabled and whatever I can think of, > including dumping cs0 config from u-boot, nokia kernel and/or REing NOLO > onenand init (already did that for N9 DDR timings, shouldn't be that hard > for N900 GPMC). Will keep you informed on the progress. In the meanwhile I > think your patch should make it as without it onenand is unusable. OK will push it out then. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi On 8.01.2016 04:26, Tony Lindgren wrote: > > Yes it seems there's some other issue too. Maybe you can run git bisect > again and carry the fix along as an extra patch? > No sane way to bisect, I don't really know what triggers the issue. Neither it is triggered regularly. It might happen on the first reboot or on the tenth, or ... And it looks like the problems happens sometimes on oops too. Not to say that it seems I should have fully booted userspace (so there is enough pressure on the ubi/mdt/nand subsystems), which is impossible with upstream without some n900 specific patches :( Maybe we can get some ideas on what and where to look from ubifs people? Though I don't know whom to cc, feel free to help :) My best bet aiui, is comparing what nokia omap1 kernel does vs upstream. Or looking at the commit log in ubi/mtd/onenand - who knows, I might get lucky once again the same way as with that phonet oops in __netif_receive_skb_core. > > OK then it really seems like we do have another bug lurking around. :nod: > Maybe you can figure out an easier way to reproduce it? > I doubt, but who knows. >> The problem is that between NOLO and kernel there is u-boot. And even if I >> am almost sure it doesn't touch onenand configs, I can't be absolutely sure. >> So those timings are not 100% reliable IMO, though close to that. > > Hmm yes I'm only booting with u-boot here as my device sits in my rack. > I booted the device via flasher with initrd from the so-called rescueos (https://n900.quitesimple.org/rescueOS/rescueOS-1.2/) - it provides shell with tons of useful tools if your device is in bootloop etc. CS0 registers were the same as with u-boot, so it is not that one. > > OK will push it out then. > Thanks, Ivo -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thursday 07 January 2016 18:26:20 Tony Lindgren wrote: > > The problem is that between NOLO and kernel there is u-boot. And even if I > > am almost sure it doesn't touch onenand configs, I can't be absolutely sure. > > So those timings are not 100% reliable IMO, though close to that. > > Hmm yes I'm only booting with u-boot here as my device sits in my rack. U-boot try to configure N900 device similar like (some older version of) linux kernel. So testing these bugs should be done also directly from NOLO without U-boot. Btw, if you have usb connection to your device in your rack, you can use 0xFFFF tool (open source) which can send kernel image to NOLO which will boot it without flashing NAND. https://github.com/pali/0xFFFF Original Nokia flasher-3.5 could support also serial connection (not only usb), but do not know. I have never used serial connector on my N900, so I do not know and this is reason why also 0xFFFF has no serial support...
On Friday 08 January 2016 07:13:58 Ivaylo Dimitrov wrote:
> And it looks like the problems happens sometimes on oops too.
In linux-n900 tree is enabled mtdoops driver which store oops to
specified MTD device. So maybe this access cause it?
* Pali Rohár <pali.rohar@gmail.com> [160107 23:57]: > On Thursday 07 January 2016 18:26:20 Tony Lindgren wrote: > > > The problem is that between NOLO and kernel there is u-boot. And even if I > > > am almost sure it doesn't touch onenand configs, I can't be absolutely sure. > > > So those timings are not 100% reliable IMO, though close to that. > > > > Hmm yes I'm only booting with u-boot here as my device sits in my rack. > > U-boot try to configure N900 device similar like (some older version of) > linux kernel. So testing these bugs should be done also directly from > NOLO without U-boot. OK > Btw, if you have usb connection to your device in your rack, you can use > 0xFFFF tool (open source) which can send kernel image to NOLO which will > boot it without flashing NAND. > > https://github.com/pali/0xFFFF > > Original Nokia flasher-3.5 could support also serial connection (not > only usb), but do not know. I have never used serial connector on my > N900, so I do not know and this is reason why also 0xFFFF has no serial > support... Yup I'm using 0xFFFF for loading images on 770 and n800 here. Well once I get my rack put together again over next few days.. Regards, TOny -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
* Ivaylo Dimitrov <ivo.g.dimitrov.75@gmail.com> [160107 21:14]: > Hi > > On 8.01.2016 04:26, Tony Lindgren wrote: > > > >Yes it seems there's some other issue too. Maybe you can run git bisect > >again and carry the fix along as an extra patch? > > No sane way to bisect, I don't really know what triggers the issue. Neither > it is triggered regularly. It might happen on the first reboot or on the > tenth, or ... And it looks like the problems happens sometimes on oops too. > Not to say that it seems I should have fully booted userspace (so there is > enough pressure on the ubi/mdt/nand subsystems), which is impossible with > upstream without some n900 specific patches :( Hmm OK. Can you check if disabling deeper idle states helps? Just set the UART timeouts to -1. You may also want to disable off mode with echo 0 > /sys/kernel/debug/pm_debug/enable_off_mode. If it happens during booting, chances are idle is not even hit though. > Maybe we can get some ideas on what and where to look from ubifs people? > Though I don't know whom to cc, feel free to help :) > > My best bet aiui, is comparing what nokia omap1 kernel does vs upstream. Or > looking at the commit log in ubi/mtd/onenand - who knows, I might get lucky > once again the same way as with that phonet oops in > __netif_receive_skb_core. Well maybe we now have error messages that actually make sense? > >OK then it really seems like we do have another bug lurking around. > > :nod: I've sent out the pull request and Arnd pulled the fix into arm-soc so we should have it merged for v4.4 FYI. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi, On 8.01.2016 09:59, Pali Rohár wrote: > On Friday 08 January 2016 07:13:58 Ivaylo Dimitrov wrote: >> And it looks like the problems happens sometimes on oops too. > > In linux-n900 tree is enabled mtdoops driver which store oops to > specified MTD device. So maybe this access cause it? > The key word here is "sometimes". i.e sometimes it hapens on normal reboot, sometimes it happens on oops. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Saturday 09 January 2016 02:23:26 Ivaylo Dimitrov wrote: > Hi, > > On 8.01.2016 09:59, Pali Rohár wrote: > >On Friday 08 January 2016 07:13:58 Ivaylo Dimitrov wrote: > >>And it looks like the problems happens sometimes on oops too. > > > >In linux-n900 tree is enabled mtdoops driver which store oops to > >specified MTD device. So maybe this access cause it? > > > > The key word here is "sometimes". i.e sometimes it hapens on normal reboot, > sometimes it happens on oops. So where is problem? In omap-gpmc? mtd? onenand? or ubifs? Or in different component? Do we know at least this?
Hi, On 21.01.2016 11:14, Pali Rohár wrote: > On Saturday 09 January 2016 02:23:26 Ivaylo Dimitrov wrote: >> Hi, >> >> On 8.01.2016 09:59, Pali Rohár wrote: >>> On Friday 08 January 2016 07:13:58 Ivaylo Dimitrov wrote: >>>> And it looks like the problems happens sometimes on oops too. >>> >>> In linux-n900 tree is enabled mtdoops driver which store oops to >>> specified MTD device. So maybe this access cause it? >>> >> >> The key word here is "sometimes". i.e sometimes it hapens on normal reboot, >> sometimes it happens on oops. > > So where is problem? In omap-gpmc? mtd? onenand? or ubifs? Or in > different component? Do we know at least this? > I think I made some progress on the issue, it seems I have to have *both* e7b11dc7b77bfce0a351230a5feeadc1d0bba997 (e7b11dc7b77bfce0a351230a5feeadc1d0bba997) reverted *and* HWMOD_INIT_NO_RESET restored in omap3xxx_gpmc_hwmod flags to have working onenand. Tony, shall I hardcode GPMC_CS_CONFIG4 OEONTIME to be the same as NOLO's or it does not make sense? Regards, Ivo -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
* Ivaylo Dimitrov <ivo.g.dimitrov.75@gmail.com> [160202 01:34]: > On 21.01.2016 11:14, Pali Rohár wrote: > >On Saturday 09 January 2016 02:23:26 Ivaylo Dimitrov wrote: > >>The key word here is "sometimes". i.e sometimes it hapens on normal reboot, > >>sometimes it happens on oops. > > > >So where is problem? In omap-gpmc? mtd? onenand? or ubifs? Or in > >different component? Do we know at least this? > > > > I think I made some progress on the issue, it seems I have to have *both* > e7b11dc7b77bfce0a351230a5feeadc1d0bba997 > (e7b11dc7b77bfce0a351230a5feeadc1d0bba997) reverted *and* > HWMOD_INIT_NO_RESET restored in omap3xxx_gpmc_hwmod flags to have working > onenand. That is strange. This is what I get with omap2plus_defconfig and omap-for-v4.5/fixes-rc1 after flashing the rootfs and booting kernel like you suggested on irc: # dmesg | grep -i -e ubi -e onenand [ 2.502899] omap2-onenand omap2-onenand: initializing on CS0, phys base 0x01000000, virtual base d0940000, freq 83 MHz [ 2.514373] OneNAND Manufacturer: Numonyx (0x20) [ 2.519287] Muxed OneNAND 256MB 1.8V 16-bit (0x40) [ 2.524444] OneNAND version = 0x0031 [ 2.671966] 6 ofpart partitions found on MTD device omap2-onenand [ 2.678436] Creating 6 MTD partitions on "omap2-onenand": [ 3.414764] ubi0: attaching mtd5 [ 3.668212] ubi0: scanning is finished [ 3.716552] ubi0: attached mtd5 (name "rootfs", size 251 MiB) [ 3.722839] ubi0: PEB size: 131072 bytes (128 KiB), LEB size: 129024 bytes [ 3.730194] ubi0: min./max. I/O unit sizes: 2048/2048, sub-page size 512 [ 3.737304] ubi0: VID header offset: 512 (aligned 512), data offset: 2048 [ 3.744537] ubi0: good PEBs: 2010, bad PEBs: 0, corrupted PEBs: 0 [ 3.751037] ubi0: user volume: 1, internal volumes: 1, max. volumes count: 128 [ 3.758697] ubi0: max/mean erase counter: 1/0, WL threshold: 4096, image sequence number: 0 [ 3.767578] ubi0: available PEBs: 0, total reserved PEBs: 2010, PEBs reserved for bad PEB handling: 40 [ 3.923980] ubi0: background thread "ubi_bgt0d" started, PID 85 [ 3.980529] UBIFS (ubi0:0): background thread "ubifs_bgt0_0" started, PID 87 [ 3.996337] UBIFS (ubi0:0): recovery needed [ 4.079925] UBIFS (ubi0:0): recovery completed [ 4.085876] UBIFS (ubi0:0): UBIFS: mounted UBI device 0, volume 0, name "rootfs" [ 4.093780] UBIFS (ubi0:0): LEB size: 129024 bytes (126 KiB), min./max. I/O unit sizes: 2048 bytes/2048 bytes [ 4.104339] UBIFS (ubi0:0): FS size: 252241920 bytes (240 MiB, 1955 LEBs), journal size 9033728 bytes (8 MiB, 71 LEBs) [ 4.115722] UBIFS (ubi0:0): reserved for root: 4190434 bytes (4092 KiB) [ 4.122772] UBIFS (ubi0:0): media format: w4/r0 (latest is w4/r0), UUID 8F30A88A-F605-4291-9927-00CF3A2AE119, small LPT model [ 4.136077] VFS: Mounted root (ubifs filesystem) on device 0:15. I copied over the modules to this rootfs too :) But in general onenand seems to behave for me. > Tony, shall I hardcode GPMC_CS_CONFIG4 OEONTIME to be the same as NOLO's or > it does not make sense? Not sure what is still wrong. But yeah some borderline GPMC timing differences could affect it. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
* Tony Lindgren <tony@atomide.com> [160202 15:40]: > * Ivaylo Dimitrov <ivo.g.dimitrov.75@gmail.com> [160202 01:34]: > > On 21.01.2016 11:14, Pali Rohár wrote: > > >On Saturday 09 January 2016 02:23:26 Ivaylo Dimitrov wrote: > > >>The key word here is "sometimes". i.e sometimes it hapens on normal reboot, > > >>sometimes it happens on oops. > > > > > >So where is problem? In omap-gpmc? mtd? onenand? or ubifs? Or in > > >different component? Do we know at least this? > > > > > > > I think I made some progress on the issue, it seems I have to have *both* > > e7b11dc7b77bfce0a351230a5feeadc1d0bba997 > > (e7b11dc7b77bfce0a351230a5feeadc1d0bba997) reverted *and* > > HWMOD_INIT_NO_RESET restored in omap3xxx_gpmc_hwmod flags to have working > > onenand. > > That is strange. This is what I get with omap2plus_defconfig and > omap-for-v4.5/fixes-rc1 after flashing the rootfs and booting kernel > like you suggested on irc: > > # dmesg | grep -i -e ubi -e onenand > [ 2.502899] omap2-onenand omap2-onenand: initializing on CS0, phys base 0x01000000, virtual base d0940000, freq 83 MHz > [ 2.514373] OneNAND Manufacturer: Numonyx (0x20) > [ 2.519287] Muxed OneNAND 256MB 1.8V 16-bit (0x40) > [ 2.524444] OneNAND version = 0x0031 > [ 2.671966] 6 ofpart partitions found on MTD device omap2-onenand > [ 2.678436] Creating 6 MTD partitions on "omap2-onenand": > [ 3.414764] ubi0: attaching mtd5 > [ 3.668212] ubi0: scanning is finished > [ 3.716552] ubi0: attached mtd5 (name "rootfs", size 251 MiB) > [ 3.722839] ubi0: PEB size: 131072 bytes (128 KiB), LEB size: 129024 bytes > [ 3.730194] ubi0: min./max. I/O unit sizes: 2048/2048, sub-page size 512 > [ 3.737304] ubi0: VID header offset: 512 (aligned 512), data offset: 2048 > [ 3.744537] ubi0: good PEBs: 2010, bad PEBs: 0, corrupted PEBs: 0 > [ 3.751037] ubi0: user volume: 1, internal volumes: 1, max. volumes count: 128 > [ 3.758697] ubi0: max/mean erase counter: 1/0, WL threshold: 4096, image sequence number: 0 > [ 3.767578] ubi0: available PEBs: 0, total reserved PEBs: 2010, PEBs reserved for bad PEB handling: 40 > [ 3.923980] ubi0: background thread "ubi_bgt0d" started, PID 85 > [ 3.980529] UBIFS (ubi0:0): background thread "ubifs_bgt0_0" started, PID 87 > [ 3.996337] UBIFS (ubi0:0): recovery needed > [ 4.079925] UBIFS (ubi0:0): recovery completed > [ 4.085876] UBIFS (ubi0:0): UBIFS: mounted UBI device 0, volume 0, name "rootfs" > [ 4.093780] UBIFS (ubi0:0): LEB size: 129024 bytes (126 KiB), min./max. I/O unit sizes: 2048 bytes/2048 bytes > [ 4.104339] UBIFS (ubi0:0): FS size: 252241920 bytes (240 MiB, 1955 LEBs), journal size 9033728 bytes (8 MiB, 71 LEBs) > [ 4.115722] UBIFS (ubi0:0): reserved for root: 4190434 bytes (4092 KiB) > [ 4.122772] UBIFS (ubi0:0): media format: w4/r0 (latest is w4/r0), UUID 8F30A88A-F605-4291-9927-00CF3A2AE119, small LPT model > [ 4.136077] VFS: Mounted root (ubifs filesystem) on device 0:15. > > I copied over the modules to this rootfs too :) But in general onenand > seems to behave for me. And ere are my GPCM timings when booted with GPMC_DEBUG in case they are different somehow for your device. Regards, Tony omap-gpmc 6e000000.gpmc: GPMC revision 5.0 GPMC CS0: cs_on : 0 ticks, 0 ns (was 0 ticks) 0 ns GPMC CS0: cs_rd_off : 14 ticks, 84 ns (was 16 ticks) 84 ns GPMC CS0: cs_wr_off : 19 ticks, 114 ns (was 16 ticks) 114 ns GPMC CS0: adv_on : 0 ticks, 0 ns (was 0 ticks) 0 ns GPMC CS0: adv_rd_off : 3 ticks, 18 ns (was 2 ticks) 18 ns GPMC CS0: adv_wr_off : 3 ticks, 18 ns (was 2 ticks) 18 ns GPMC CS0: oe_on : 5 ticks, 30 ns (was 2 ticks) 30 ns GPMC CS0: oe_off : 14 ticks, 84 ns (was 16 ticks) 84 ns GPMC CS0: we_on : 0 ticks, 0 ns (was 0 ticks) 0 ns GPMC CS0: we_off : 14 ticks, 84 ns (was 16 ticks) 84 ns GPMC CS0: rd_cycle : 18 ticks, 108 ns (was 19 ticks) 108 ns GPMC CS0: wr_cycle : 17 ticks, 102 ns (was 19 ticks) 102 ns GPMC CS0: access : 13 ticks, 78 ns (was 15 ticks) 78 ns GPMC CS0: page_burst_access: 0 ticks, 0 ns (was 2 ticks) 0 ns GPMC CS0: bus_turnaround : 0 ticks, 0 ns (was 0 ticks) 0 ns GPMC CS0: cycle2cycle_delay: 0 ticks, 0 ns (was 0 ticks) 0 ns GPMC CS0: wr_data_mux_bus : 5 ticks, 30 ns (was 5 ticks) 30 ns GPMC CS0: wr_access : 13 ticks, 78 ns (was 15 ticks) 78 ns GPMC CS0: wait_monitoring : 0 ticks, 0 ns (was 0 ticks) 0 ns GPMC CS0: clk_activation : 0 ticks, 0 ns (was 0 ticks) 0 ns GPMC CS0 CLK period is 6 ns (div 1) gpmc cs0 after gpmc_cs_set_timings: cs0 GPMC_CS_CONFIG1: 0xd9001200 cs0 GPMC_CS_CONFIG2: 0x00130e00 cs0 GPMC_CS_CONFIG3: 0x00030300 cs0 GPMC_CS_CONFIG4: 0x0e000e05 cs0 GPMC_CS_CONFIG5: 0x000d1112 cs0 GPMC_CS_CONFIG6: 0x8d050000 gpmc cs0 access configuration: gpmc,mux-add-data = <2> gpmc,device-width = <1> gpmc,wait-pin = <0> gpmc,burst-length = <16> gpmc,sync-write = <1> gpmc,burst-write = <1> gpmc,burst-read = <1> gpmc,burst-wrap = <1> gpmc cs0 timings configuration: gpmc,cs-on-ns = <0> /* 0 ns - 0 ns; 0 ticks */ gpmc,cs-rd-off-ns = <84> /* 79 ns - 84 ns; 14 ticks */ gpmc,cs-wr-off-ns = <114> /* 109 ns - 114 ns; 19 ticks */ gpmc,adv-on-ns = <0> /* 0 ns - 0 ns; 0 ticks */ gpmc,adv-rd-off-ns = <18> /* 13 ns - 18 ns; 3 ticks */ gpmc,adv-wr-off-ns = <18> /* 13 ns - 18 ns; 3 ticks */ gpmc,oe-on-ns = <30> /* 25 ns - 30 ns; 5 ticks */ gpmc,oe-off-ns = <84> /* 79 ns - 84 ns; 14 ticks */ gpmc,we-on-ns = <0> /* 0 ns - 0 ns; 0 ticks */ gpmc,we-off-ns = <84> /* 79 ns - 84 ns; 14 ticks */ gpmc,rd-cycle-ns = <108> /* 103 ns - 108 ns; 18 ticks */ gpmc,wr-cycle-ns = <102> /* 97 ns - 102 ns; 17 ticks */ gpmc,access-ns = <78> /* 73 ns - 78 ns; 13 ticks */ gpmc,page-burst-access-ns = <0> /* 0 ns - 0 ns; 0 ticks */ gpmc,bus-turnaround-ns = <0> /* 0 ns - 0 ns; 0 ticks */ gpmc,cycle2cycle-delay-ns = <0> /* 0 ns - 0 ns; 0 ticks */ gpmc,wait-monitoring-ns = <0> /* 0 ns - 0 ns; 0 ticks */ gpmc,clk-activation-ns = <0> /* 0 ns - 0 ns; 0 ticks */ gpmc,wr-data-mux-bus-ns = <30> /* 25 ns - 30 ns; 5 ticks */ gpmc,wr-access-ns = <78> /* 73 ns - 78 ns; 13 ticks */ GPMC CS0: cs_on : 0 ticks, 0 ns (was 0 ticks) 0 ns GPMC CS0: cs_rd_off : 16 ticks, 96 ns (was 14 ticks) 96 ns GPMC CS0: cs_wr_off : 16 ticks, 96 ns (was 19 ticks) 96 ns GPMC CS0: adv_on : 0 ticks, 0 ns (was 0 ticks) 0 ns GPMC CS0: adv_rd_off : 2 ticks, 12 ns (was 3 ticks) 12 ns GPMC CS0: adv_wr_off : 2 ticks, 12 ns (was 3 ticks) 12 ns GPMC CS0: oe_on : 3 ticks, 18 ns (was 5 ticks) 18 ns GPMC CS0: oe_off : 16 ticks, 96 ns (was 14 ticks) 96 ns GPMC CS0: we_on : 0 ticks, 0 ns (was 0 ticks) 0 ns GPMC CS0: we_off : 16 ticks, 96 ns (was 14 ticks) 96 ns GPMC CS0: rd_cycle : 19 ticks, 114 ns (was 18 ticks) 114 ns GPMC CS0: wr_cycle : 19 ticks, 114 ns (was 17 ticks) 114 ns GPMC CS0: access : 15 ticks, 90 ns (was 13 ticks) 90 ns GPMC CS0: page_burst_access: 2 ticks, 12 ns (was 0 ticks) 12 ns GPMC CS0: bus_turnaround : 0 ticks, 0 ns (was 0 ticks) 0 ns GPMC CS0: cycle2cycle_delay: 0 ticks, 0 ns (was 0 ticks) 0 ns GPMC CS0: wr_data_mux_bus : 5 ticks, 30 ns (was 5 ticks) 30 ns GPMC CS0: wr_access : 15 ticks, 90 ns (was 13 ticks) 90 ns GPMC CS0: wait_monitoring : 0 ticks, 0 ns (was 0 ticks) 0 ns GPMC CS0: clk_activation : 1 ticks, 6 ns (was 0 ticks) 6 ns GPMC CS0 CLK period is 12 ns (div 2) gpmc cs0 after gpmc_cs_set_timings: cs0 GPMC_CS_CONFIG1: 0xfb001201 cs0 GPMC_CS_CONFIG2: 0x00101000 cs0 GPMC_CS_CONFIG3: 0x00020200 cs0 GPMC_CS_CONFIG4: 0x10001003 cs0 GPMC_CS_CONFIG5: 0x020f1313 cs0 GPMC_CS_CONFIG6: 0x8f050000 gpmc cs0 access configuration: gpmc,mux-add-data = <2> gpmc,device-width = <1> gpmc,wait-pin = <0> gpmc,burst-length = <16> gpmc,sync-write = <1> gpmc,burst-write = <1> gpmc,gpmc,sync-read = <1> gpmc,burst-read = <1> gpmc,burst-wrap = <1> gpmc cs0 timings configuration: gpmc,cs-on-ns = <0> /* 0 ns - 0 ns; 0 ticks */ gpmc,cs-rd-off-ns = <96> /* 91 ns - 96 ns; 16 ticks */ gpmc,cs-wr-off-ns = <96> /* 91 ns - 96 ns; 16 ticks */ gpmc,adv-on-ns = <0> /* 0 ns - 0 ns; 0 ticks */ gpmc,adv-rd-off-ns = <12> /* 7 ns - 12 ns; 2 ticks */ gpmc,adv-wr-off-ns = <12> /* 7 ns - 12 ns; 2 ticks */ gpmc,oe-on-ns = <18> /* 13 ns - 18 ns; 3 ticks */ gpmc,oe-off-ns = <96> /* 91 ns - 96 ns; 16 ticks */ gpmc,we-on-ns = <0> /* 0 ns - 0 ns; 0 ticks */ gpmc,we-off-ns = <96> /* 91 ns - 96 ns; 16 ticks */ gpmc,rd-cycle-ns = <114> /* 109 ns - 114 ns; 19 ticks */ gpmc,wr-cycle-ns = <114> /* 109 ns - 114 ns; 19 ticks */ gpmc,access-ns = <90> /* 85 ns - 90 ns; 15 ticks */ gpmc,page-burst-access-ns = <12> /* 7 ns - 12 ns; 2 ticks */ gpmc,bus-turnaround-ns = <0> /* 0 ns - 0 ns; 0 ticks */ gpmc,cycle2cycle-delay-ns = <0> /* 0 ns - 0 ns; 0 ticks */ gpmc,wait-monitoring-ns = <0> /* 0 ns - 0 ns; 0 ticks */ gpmc,clk-activation-ns = <6> /* 1 ns - 6 ns; 1 ticks */ gpmc,wr-data-mux-bus-ns = <30> /* 25 ns - 30 ns; 5 ticks */ gpmc,wr-access-ns = <90> /* 85 ns - 90 ns; 15 ticks */ omap2-onenand omap2-onenand: initializing on CS0, phys base 0x04000000, virtual base d0940000, freq 83 MHz OneNAND Manufacturer: Numonyx (0x20) Muxed OneNAND 256MB 1.8V 16-bit (0x40) OneNAND version = 0x0031 Chip support all block unlock Chip has 2 plane Scanning device for bad blocks 6 ofpart partitions found on MTD device omap2-onenand Creating 6 MTD partitions on "omap2-onenand": 0x000000000000-0x000000020000 : "bootloader" 0x000000020000-0x000000080000 : "config" 0x000000080000-0x0000000c0000 : "log" mtdoops: ready 43, 6188 (no erase) mtdoops: Attached to MTD device 2 0x0000000c0000-0x0000002c0000 : "kernel" 0x0000002c0000-0x0000004c0000 : "initfs" 0x0000004c0000-0x000010000000 : "rootfs" -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 3.02.2016 02:00, Tony Lindgren wrote: > * Tony Lindgren <tony@atomide.com> [160202 15:40]: >> * Ivaylo Dimitrov <ivo.g.dimitrov.75@gmail.com> [160202 01:34]: >>> On 21.01.2016 11:14, Pali Rohár wrote: >>>> On Saturday 09 January 2016 02:23:26 Ivaylo Dimitrov wrote: >>>>> The key word here is "sometimes". i.e sometimes it hapens on normal reboot, >>>>> sometimes it happens on oops. >>>> >>>> So where is problem? In omap-gpmc? mtd? onenand? or ubifs? Or in >>>> different component? Do we know at least this? >>>> >>> >>> I think I made some progress on the issue, it seems I have to have *both* >>> e7b11dc7b77bfce0a351230a5feeadc1d0bba997 >>> (e7b11dc7b77bfce0a351230a5feeadc1d0bba997) reverted *and* >>> HWMOD_INIT_NO_RESET restored in omap3xxx_gpmc_hwmod flags to have working >>> onenand. >> >> That is strange. This is what I get with omap2plus_defconfig and >> omap-for-v4.5/fixes-rc1 after flashing the rootfs and booting kernel >> like you suggested on irc: What I forgot to tell on IRC is that you should try to boot stock kernel after booting mainline. Here it spits a lot of ECC errors (I have framebuffer console enabled to see those) and refuses to mount rootfs. >> >> # dmesg | grep -i -e ubi -e onenand >> [ 2.502899] omap2-onenand omap2-onenand: initializing on CS0, phys base 0x01000000, virtual base d0940000, freq 83 MHz >> [ 2.514373] OneNAND Manufacturer: Numonyx (0x20) >> [ 2.519287] Muxed OneNAND 256MB 1.8V 16-bit (0x40) >> [ 2.524444] OneNAND version = 0x0031 Exactly the same chip here. >> [ 2.671966] 6 ofpart partitions found on MTD device omap2-onenand >> [ 2.678436] Creating 6 MTD partitions on "omap2-onenand": >> [ 3.414764] ubi0: attaching mtd5 >> [ 3.668212] ubi0: scanning is finished >> [ 3.716552] ubi0: attached mtd5 (name "rootfs", size 251 MiB) >> [ 3.722839] ubi0: PEB size: 131072 bytes (128 KiB), LEB size: 129024 bytes >> [ 3.730194] ubi0: min./max. I/O unit sizes: 2048/2048, sub-page size 512 >> [ 3.737304] ubi0: VID header offset: 512 (aligned 512), data offset: 2048 >> [ 3.744537] ubi0: good PEBs: 2010, bad PEBs: 0, corrupted PEBs: 0 >> [ 3.751037] ubi0: user volume: 1, internal volumes: 1, max. volumes count: 128 >> [ 3.758697] ubi0: max/mean erase counter: 1/0, WL threshold: 4096, image sequence number: 0 >> [ 3.767578] ubi0: available PEBs: 0, total reserved PEBs: 2010, PEBs reserved for bad PEB handling: 40 >> [ 3.923980] ubi0: background thread "ubi_bgt0d" started, PID 85 >> [ 3.980529] UBIFS (ubi0:0): background thread "ubifs_bgt0_0" started, PID 87 >> [ 3.996337] UBIFS (ubi0:0): recovery needed >> [ 4.079925] UBIFS (ubi0:0): recovery completed >> [ 4.085876] UBIFS (ubi0:0): UBIFS: mounted UBI device 0, volume 0, name "rootfs" >> [ 4.093780] UBIFS (ubi0:0): LEB size: 129024 bytes (126 KiB), min./max. I/O unit sizes: 2048 bytes/2048 bytes >> [ 4.104339] UBIFS (ubi0:0): FS size: 252241920 bytes (240 MiB, 1955 LEBs), journal size 9033728 bytes (8 MiB, 71 LEBs) >> [ 4.115722] UBIFS (ubi0:0): reserved for root: 4190434 bytes (4092 KiB) >> [ 4.122772] UBIFS (ubi0:0): media format: w4/r0 (latest is w4/r0), UUID 8F30A88A-F605-4291-9927-00CF3A2AE119, small LPT model >> [ 4.136077] VFS: Mounted root (ubifs filesystem) on device 0:15. >> >> I copied over the modules to this rootfs too :) But in general onenand >> seems to behave for me. > Yes, initially it works, but is corrupted after a reboot or two here. > And ere are my GPCM timings when booted with GPMC_DEBUG > in case they are different somehow for your device. > > Regards, > > Tony > > omap-gpmc 6e000000.gpmc: GPMC revision 5.0 > GPMC CS0: cs_on : 0 ticks, 0 ns (was 0 ticks) 0 ns > GPMC CS0: cs_rd_off : 14 ticks, 84 ns (was 16 ticks) 84 ns > GPMC CS0: cs_wr_off : 19 ticks, 114 ns (was 16 ticks) 114 ns > GPMC CS0: adv_on : 0 ticks, 0 ns (was 0 ticks) 0 ns > GPMC CS0: adv_rd_off : 3 ticks, 18 ns (was 2 ticks) 18 ns > GPMC CS0: adv_wr_off : 3 ticks, 18 ns (was 2 ticks) 18 ns > GPMC CS0: oe_on : 5 ticks, 30 ns (was 2 ticks) 30 ns > GPMC CS0: oe_off : 14 ticks, 84 ns (was 16 ticks) 84 ns > GPMC CS0: we_on : 0 ticks, 0 ns (was 0 ticks) 0 ns > GPMC CS0: we_off : 14 ticks, 84 ns (was 16 ticks) 84 ns > GPMC CS0: rd_cycle : 18 ticks, 108 ns (was 19 ticks) 108 ns > GPMC CS0: wr_cycle : 17 ticks, 102 ns (was 19 ticks) 102 ns > GPMC CS0: access : 13 ticks, 78 ns (was 15 ticks) 78 ns > GPMC CS0: page_burst_access: 0 ticks, 0 ns (was 2 ticks) 0 ns > GPMC CS0: bus_turnaround : 0 ticks, 0 ns (was 0 ticks) 0 ns > GPMC CS0: cycle2cycle_delay: 0 ticks, 0 ns (was 0 ticks) 0 ns > GPMC CS0: wr_data_mux_bus : 5 ticks, 30 ns (was 5 ticks) 30 ns > GPMC CS0: wr_access : 13 ticks, 78 ns (was 15 ticks) 78 ns > GPMC CS0: wait_monitoring : 0 ticks, 0 ns (was 0 ticks) 0 ns > GPMC CS0: clk_activation : 0 ticks, 0 ns (was 0 ticks) 0 ns > GPMC CS0 CLK period is 6 ns (div 1) > gpmc cs0 after gpmc_cs_set_timings: > cs0 GPMC_CS_CONFIG1: 0xd9001200 > cs0 GPMC_CS_CONFIG2: 0x00130e00 > cs0 GPMC_CS_CONFIG3: 0x00030300 > cs0 GPMC_CS_CONFIG4: 0x0e000e05 > cs0 GPMC_CS_CONFIG5: 0x000d1112 > cs0 GPMC_CS_CONFIG6: 0x8d050000 > gpmc cs0 access configuration: > gpmc,mux-add-data = <2> > gpmc,device-width = <1> > gpmc,wait-pin = <0> > gpmc,burst-length = <16> > gpmc,sync-write = <1> > gpmc,burst-write = <1> > gpmc,burst-read = <1> > gpmc,burst-wrap = <1> > gpmc cs0 timings configuration: > gpmc,cs-on-ns = <0> /* 0 ns - 0 ns; 0 ticks */ > gpmc,cs-rd-off-ns = <84> /* 79 ns - 84 ns; 14 ticks */ > gpmc,cs-wr-off-ns = <114> /* 109 ns - 114 ns; 19 ticks */ > gpmc,adv-on-ns = <0> /* 0 ns - 0 ns; 0 ticks */ > gpmc,adv-rd-off-ns = <18> /* 13 ns - 18 ns; 3 ticks */ > gpmc,adv-wr-off-ns = <18> /* 13 ns - 18 ns; 3 ticks */ > gpmc,oe-on-ns = <30> /* 25 ns - 30 ns; 5 ticks */ > gpmc,oe-off-ns = <84> /* 79 ns - 84 ns; 14 ticks */ > gpmc,we-on-ns = <0> /* 0 ns - 0 ns; 0 ticks */ > gpmc,we-off-ns = <84> /* 79 ns - 84 ns; 14 ticks */ > gpmc,rd-cycle-ns = <108> /* 103 ns - 108 ns; 18 ticks */ > gpmc,wr-cycle-ns = <102> /* 97 ns - 102 ns; 17 ticks */ > gpmc,access-ns = <78> /* 73 ns - 78 ns; 13 ticks */ > gpmc,page-burst-access-ns = <0> /* 0 ns - 0 ns; 0 ticks */ > gpmc,bus-turnaround-ns = <0> /* 0 ns - 0 ns; 0 ticks */ > gpmc,cycle2cycle-delay-ns = <0> /* 0 ns - 0 ns; 0 ticks */ > gpmc,wait-monitoring-ns = <0> /* 0 ns - 0 ns; 0 ticks */ > gpmc,clk-activation-ns = <0> /* 0 ns - 0 ns; 0 ticks */ > gpmc,wr-data-mux-bus-ns = <30> /* 25 ns - 30 ns; 5 ticks */ > gpmc,wr-access-ns = <78> /* 73 ns - 78 ns; 13 ticks */ > GPMC CS0: cs_on : 0 ticks, 0 ns (was 0 ticks) 0 ns > GPMC CS0: cs_rd_off : 16 ticks, 96 ns (was 14 ticks) 96 ns > GPMC CS0: cs_wr_off : 16 ticks, 96 ns (was 19 ticks) 96 ns > GPMC CS0: adv_on : 0 ticks, 0 ns (was 0 ticks) 0 ns > GPMC CS0: adv_rd_off : 2 ticks, 12 ns (was 3 ticks) 12 ns > GPMC CS0: adv_wr_off : 2 ticks, 12 ns (was 3 ticks) 12 ns > GPMC CS0: oe_on : 3 ticks, 18 ns (was 5 ticks) 18 ns > GPMC CS0: oe_off : 16 ticks, 96 ns (was 14 ticks) 96 ns > GPMC CS0: we_on : 0 ticks, 0 ns (was 0 ticks) 0 ns > GPMC CS0: we_off : 16 ticks, 96 ns (was 14 ticks) 96 ns > GPMC CS0: rd_cycle : 19 ticks, 114 ns (was 18 ticks) 114 ns > GPMC CS0: wr_cycle : 19 ticks, 114 ns (was 17 ticks) 114 ns > GPMC CS0: access : 15 ticks, 90 ns (was 13 ticks) 90 ns > GPMC CS0: page_burst_access: 2 ticks, 12 ns (was 0 ticks) 12 ns > GPMC CS0: bus_turnaround : 0 ticks, 0 ns (was 0 ticks) 0 ns > GPMC CS0: cycle2cycle_delay: 0 ticks, 0 ns (was 0 ticks) 0 ns > GPMC CS0: wr_data_mux_bus : 5 ticks, 30 ns (was 5 ticks) 30 ns > GPMC CS0: wr_access : 15 ticks, 90 ns (was 13 ticks) 90 ns > GPMC CS0: wait_monitoring : 0 ticks, 0 ns (was 0 ticks) 0 ns > GPMC CS0: clk_activation : 1 ticks, 6 ns (was 0 ticks) 6 ns > GPMC CS0 CLK period is 12 ns (div 2) > gpmc cs0 after gpmc_cs_set_timings: > cs0 GPMC_CS_CONFIG1: 0xfb001201 > cs0 GPMC_CS_CONFIG2: 0x00101000 > cs0 GPMC_CS_CONFIG3: 0x00020200 > cs0 GPMC_CS_CONFIG4: 0x10001003 > cs0 GPMC_CS_CONFIG5: 0x020f1313 > cs0 GPMC_CS_CONFIG6: 0x8f050000 > gpmc cs0 access configuration: > gpmc,mux-add-data = <2> > gpmc,device-width = <1> > gpmc,wait-pin = <0> > gpmc,burst-length = <16> > gpmc,sync-write = <1> > gpmc,burst-write = <1> > gpmc,gpmc,sync-read = <1> > gpmc,burst-read = <1> > gpmc,burst-wrap = <1> > gpmc cs0 timings configuration: > gpmc,cs-on-ns = <0> /* 0 ns - 0 ns; 0 ticks */ > gpmc,cs-rd-off-ns = <96> /* 91 ns - 96 ns; 16 ticks */ > gpmc,cs-wr-off-ns = <96> /* 91 ns - 96 ns; 16 ticks */ > gpmc,adv-on-ns = <0> /* 0 ns - 0 ns; 0 ticks */ > gpmc,adv-rd-off-ns = <12> /* 7 ns - 12 ns; 2 ticks */ > gpmc,adv-wr-off-ns = <12> /* 7 ns - 12 ns; 2 ticks */ > gpmc,oe-on-ns = <18> /* 13 ns - 18 ns; 3 ticks */ > gpmc,oe-off-ns = <96> /* 91 ns - 96 ns; 16 ticks */ > gpmc,we-on-ns = <0> /* 0 ns - 0 ns; 0 ticks */ > gpmc,we-off-ns = <96> /* 91 ns - 96 ns; 16 ticks */ > gpmc,rd-cycle-ns = <114> /* 109 ns - 114 ns; 19 ticks */ > gpmc,wr-cycle-ns = <114> /* 109 ns - 114 ns; 19 ticks */ > gpmc,access-ns = <90> /* 85 ns - 90 ns; 15 ticks */ > gpmc,page-burst-access-ns = <12> /* 7 ns - 12 ns; 2 ticks */ > gpmc,bus-turnaround-ns = <0> /* 0 ns - 0 ns; 0 ticks */ > gpmc,cycle2cycle-delay-ns = <0> /* 0 ns - 0 ns; 0 ticks */ > gpmc,wait-monitoring-ns = <0> /* 0 ns - 0 ns; 0 ticks */ > gpmc,clk-activation-ns = <6> /* 1 ns - 6 ns; 1 ticks */ > gpmc,wr-data-mux-bus-ns = <30> /* 25 ns - 30 ns; 5 ticks */ > gpmc,wr-access-ns = <90> /* 85 ns - 90 ns; 15 ticks */ > omap2-onenand omap2-onenand: initializing on CS0, phys base 0x04000000, virtual base d0940000, freq 83 MHz > OneNAND Manufacturer: Numonyx (0x20) > Muxed OneNAND 256MB 1.8V 16-bit (0x40) > OneNAND version = 0x0031 > Chip support all block unlock > Chip has 2 plane > Scanning device for bad blocks > 6 ofpart partitions found on MTD device omap2-onenand > Creating 6 MTD partitions on "omap2-onenand": > 0x000000000000-0x000000020000 : "bootloader" > 0x000000020000-0x000000080000 : "config" > 0x000000080000-0x0000000c0000 : "log" > mtdoops: ready 43, 6188 (no erase) > mtdoops: Attached to MTD device 2 > 0x0000000c0000-0x0000002c0000 : "kernel" > 0x0000002c0000-0x0000004c0000 : "initfs" > 0x0000004c0000-0x000010000000 : "rootfs" > Exactly the same log here, besides "mtdoops: ready 36, 959521164 (no erase)", no idea what that "959521164" is supposed to mean. May I ask you to send me the full boot log with omap2plus_defconfig kernel booting mtd5 maemo rootfs, until it restarts and the next boot log with the stock kernel. It could be there is some other driver acting here (g_nokia for example) you don't have enabled in your config. I will play a bit more with omap2plus_defconfig here in attempt to make it boot, to see if I can recreate the issue. Also, I looked at the TRM and GPMC has more stuff than timings, like PRFETCH and ECC. Will dump those with and without HWMOD_INIT_NO_RESET to see if there is any difference. Thanks, Ivo -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 3.02.2016 09:03, Ivaylo Dimitrov wrote: > > > I will play a bit more with omap2plus_defconfig here in attempt to make > it boot, to see if I can recreate the issue. > ok, what I did here is: - zImage git clone git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap.git git checkout omap-for-v4.5/fixes-rc1 make omap2plus_defconfig make -j4 zImage make omap3-n900.dtb cat arch/arm/boot/zImage arch/arm/boot/dts/omap3-n900.dtb > zImage - flashed maemo rootfs sudo flasher-3.5 -f -F RX-51_2009SE_20.2010.36-2_PR_COMBINED_MR0_ARM.bin --flash-only=rootfs -R - booted to maemo and powered the device off sudo flasher-3.5 -k zImage -l -b"init=/sbin/preinit ubi.mtd=rootfs root=ubi0:rootfs rootfstype=ubifs rootflags=bulk_read,no_chk_data_crc rw mtdoops.mtddev=log omapfb_vram=7M omapfb.mode=lcd:848x480-16 nokia-modem.pm=0" There was nothing on the screen, but backlight was on. I removed the battery after ~30 seconds. At this point maemo is no longer bootable. Booting fb-console enabled stock kernel (http://mohammadag.xceleo.org/public/maemo/kernels/framebuffer/) via flasher3.5: sudo flasher-3.5 -k zImage-fb-omap1-pr13 -l -b produces http://46.249.74.23/maemo/onenend/stock/ . Booting 4.5-rc1 kernel from https://github.com/pali/linux-n900, with HWMOD_INIT_NO_RESET restored and your "onenand fix" patch reverted (so to not introduce additional corruption), via flasher3.5: sudo flasher-3.5 -k zImage -l -b"init=/sbin/preinit ubi.mtd=rootfs root=ubi0:rootfs rootfstype=ubifs rootflags=bulk_read,no_chk_data_crc rw mtdoops.mtddev=log omapfb_vram=7M omapfb.mode=lcd:848x480-16 nokia-modem.pm=0" results in http://46.249.74.23/maemo/onenend/linux-n900/ . note - don't try to play the videos in the browser, download them first instead, at least FF doesn't want to play videos captured by N900 :) Regards, Ivo -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
--- a/arch/arm/mach-omap2/gpmc-onenand.c +++ b/arch/arm/mach-omap2/gpmc-onenand.c @@ -153,6 +153,8 @@ static int omap2_onenand_get_freq(struct omap_onenand_platform_data *cfg, freq = 0; } + gpmc_cs_show_timings(cs, "before gpmc_cs_program_settings"); + return freq; } --- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c +++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c @@ -2150,8 +2150,7 @@ static struct omap_hwmod omap3xxx_gpmc_hwmod = { .clkdm_name = "core_l3_clkdm", .mpu_irqs = omap3xxx_gpmc_irqs, .main_clk = "gpmc_fck", - /* Skip reset for CONFIG_OMAP_GPMC_DEBUG for bootloader timings */ - .flags = HWMOD_NO_IDLEST | DEBUG_OMAP_GPMC_HWMOD_FLAGS, + .flags = HWMOD_NO_IDLEST, }; /* --- a/drivers/memory/omap-gpmc.c +++ b/drivers/memory/omap-gpmc.c @@ -1987,7 +1987,7 @@ static int gpmc_probe_generic_child(struct platform_device *pdev, if (ret < 0) goto err; - gpmc_cs_show_timings(cs, "before gpmc_cs_program_settings"); + dev_info(&pdev->dev, "GPMC reset, not showing default timings\n"); ret = gpmc_cs_program_settings(cs, &gpmc_s); if (ret < 0) goto err;