kexec: cpufreq: omap3: hangs in dpll3xxx.c::_omap3_dpll_write_clken()
I've been experiencing solid hangs on my beaglexm with v3.7 after kexec: here is my .config (omap2plus + EHCI/OHCI + CPUFREQ + DEVTMP): http://people.canonical.com/~ppisati/omap3_cpufreq_kexec/config here is the diff i added to get some debugging: http://people.canonical.com/~ppisati/omap3_cpufreq_kexec/dpll-debug.diff here is a trace of the kexeced kernel: http://people.canonical.com/~ppisati/omap3_cpufreq_kexec/kexec-boot.txt Since i'n not familiar with those dplls, can anyone shed some light? -- bye, p. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: kexec: cpufreq: omap3: hangs in dpll3xxx.c::_omap3_dpll_write_clken()
On Tue, Dec 11, 2012 at 08:20:13PM +, Paul Walmsley wrote: > On Tue, 11 Dec 2012, Paolo Pisati wrote: > > > I've been experiencing solid hangs on my beaglexm with v3.7 after > > kexec: > > Does it crash if you boot v3.7 directly from the bootloader, i.e., without > kexec? nope, works perfectly fine when booted from the bootlader. -- bye, p. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: kexec: cpufreq: omap3: hangs in dpll3xxx.c::_omap3_dpll_write_clken()
On Tue, Dec 11, 2012 at 08:32:25PM +, Paul Walmsley wrote: > On Tue, 11 Dec 2012, Paul Walmsley wrote: > > > On Tue, 11 Dec 2012, Paolo Pisati wrote: > > > > > I've been experiencing solid hangs on my beaglexm with v3.7 after > > > kexec: > > > > Does it crash if you boot v3.7 directly from the bootloader, i.e., without > > kexec? > > Also you might want to verify that the voltage on VDD1 is what the kernel > thinks it is: > > [5.638183] notification 0 of frequency transition to 80 kHz > [5.644775] cpu cpu0: cpufreq-omap: 300 MHz, -1 mV --> 800 MHz, 1325 mV > > You can probe this with a multimeter on one side of the VDD1 inductor. > It's on the underside of the Beagle-XM near the DC input jack - it's > marked "L4" on the silkscreen text. uhm no, my multimeter says it's around 113mV... -- bye, p. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] regulator: core: if voltage scaling fails, restore original voltage values
Signed-off-by: Paolo Pisati --- drivers/regulator/core.c | 16 ++-- 1 file changed, 14 insertions(+), 2 deletions(-) diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c index e872c8b..c347fd0 100644 --- a/drivers/regulator/core.c +++ b/drivers/regulator/core.c @@ -2250,6 +2250,7 @@ int regulator_set_voltage(struct regulator *regulator, int min_uV, int max_uV) { struct regulator_dev *rdev = regulator->rdev; int ret = 0; + int old_min_uV, old_max_uV; mutex_lock(&rdev->mutex); @@ -2271,18 +2272,29 @@ int regulator_set_voltage(struct regulator *regulator, int min_uV, int max_uV) ret = regulator_check_voltage(rdev, &min_uV, &max_uV); if (ret < 0) goto out; + + /* restore original values in case of error */ + old_min_uV = regulator->min_uV; + old_max_uV = regulator->max_uV; regulator->min_uV = min_uV; regulator->max_uV = max_uV; ret = regulator_check_consumers(rdev, &min_uV, &max_uV); if (ret < 0) - goto out; + goto out2; ret = _regulator_do_set_voltage(rdev, min_uV, max_uV); - + if (ret < 0) + goto out2; + out: mutex_unlock(&rdev->mutex); return ret; +out2: + regulator->min_uV = old_min_uV; + regulator->max_uV = old_max_uV; + mutex_unlock(&rdev->mutex); + return ret; } EXPORT_SYMBOL_GPL(regulator_set_voltage); -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] regulator: core: if voltage scaling fails, restore original
And after a second look it's clear what's going on: [...] [5.575744] cpu cpu0: cpufreq-omap: 300 MHz, -1 mV --> 800 MHz, 1325 mV [5.582946] voltdm_scale: No voltage scale API registered for vdd_mpu_iva [5.590332] cpu cpu0: omap_target: unable to scale voltage up. [1] [5.596649] notification 1 of frequency transition to 30 kHz [5.603179] FREQ: 30 - CPU: 0 [5.606597] governor: change or update limits [5.611572] __cpufreq_governor for CPU 0, event 3 [5.616699] setting to 80 kHz because of event 3 [5.622039] target for CPU 0: 80 kHz, relation 1 [5.627441] request for target 80 kHz (relation: 1) for cpu 0 [5.634063] target is 2 (80 kHz, 2) [5.638183] notification 0 of frequency transition to 80 kHz [5.644775] cpu cpu0: cpufreq-omap: 300 MHz, -1 mV --> 800 MHz, 1325 mV [2] [hangs here] first time[1] it tries to ramp up frequency (and thus voltage), regulator_set_voltage() returns an error and we exit: omap-cpufreq.c::omap_target(): ... dev_dbg(mpu_dev, "cpufreq-omap: %u MHz, %ld mV --> %u MHz, %ld mV\n", freqs.old / 1000, volt_old ? volt_old / 1000 : -1, freqs.new / 1000, volt ? volt / 1000 : -1); /* scaling up? scale voltage before frequency */ if (mpu_reg && (freqs.new > freqs.old)) { r = regulator_set_voltage(mpu_reg, volt - tol, volt + tol); if (r < 0) { dev_warn(mpu_dev, "%s: unable to scale voltage up.\n", __func__); freqs.new = freqs.old; goto done; } } ret = clk_set_rate(mpu_clk, freqs.new * 1000); ... but inside regulator_set_voltage(), we save the new regulator voltage before actually ramping up: core.c::regulator_set_voltage(): ... regulator->min_uV = min_uV; regulator->max_uV = max_uV; ret = regulator_check_consumers(rdev, &min_uV, &max_uV); if (ret < 0) goto out2; ret = _regulator_do_set_voltage(rdev, min_uV, max_uV); <-- ERROR!!! if (ret < 0) goto out2; ... and by the time we try to change frequency again[2], regulator_set_voltage() is a noop because it thinks we are already at the desired voltage: core.c::regulator_set_voltage(): ... /* If we're setting the same range as last time the change * should be a noop (some cpufreq implementations use the same * voltage for multiple frequencies, for example). */ if (regulator->min_uV == min_uV && regulator->max_uV == max_uV) goto out; ... and as a consequence, in omap_target(), we call clk_set_rate() with the wrong voltage. The attached patch restore the original regulator voltage values in case of an error. CCing stable@ since it predates 2.6.38rc1 when the noop optimization was introduced: commit 95a3c23ae620c1b4c499746e70f4034bdc067737 Author: Mark Brown Date: Thu Dec 16 15:49:37 2010 + regulator: Optimise out noop voltage changes Paolo Pisati (1): regulator: core: if voltage scaling fails, restore original voltage values drivers/regulator/core.c | 16 ++-- 1 file changed, 14 insertions(+), 2 deletions(-) -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] regulator: core: if voltage scaling fails, restore original
On Thu, Dec 13, 2012 at 05:15:33AM +, Mark Brown wrote: > On Wed, Dec 12, 2012 at 12:45:52PM +0100, Paolo Pisati wrote: > > And after a second look it's clear what's going on: > > After a second look at what? You've not provided any context, I've no > idea what you're talking about here. forgot the --in-reply-to=..., i'll resend as a new thread. -- bye, p. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] [resend] regulator: core: if voltage scaling fails, restore original values
* should be a noop (some cpufreq implementations use the same * voltage for multiple frequencies, for example). */ if (regulator->min_uV == min_uV && regulator->max_uV == max_uV) goto out; ... and as a consequence, in omap_target(), we call clk_set_rate() with the wrong voltage. The attached patch restore the original regulator voltage values in case of an error. CCing stable@ since it predates 2.6.38rc1 when the noop optimization was introduced: commit 95a3c23ae620c1b4c499746e70f4034bdc067737 Author: Mark Brown Date: Thu Dec 16 15:49:37 2010 + regulator: Optimise out noop voltage changes Paolo Pisati (1): regulator: core: if voltage scaling fails, restore original voltage values drivers/regulator/core.c | 16 ++-- 1 file changed, 14 insertions(+), 2 deletions(-) -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] regulator: core: if voltage scaling fails, restore original voltage values
Signed-off-by: Paolo Pisati Tested-by: Robert Nelson --- drivers/regulator/core.c | 16 ++-- 1 file changed, 14 insertions(+), 2 deletions(-) diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c index e872c8b..c347fd0 100644 --- a/drivers/regulator/core.c +++ b/drivers/regulator/core.c @@ -2250,6 +2250,7 @@ int regulator_set_voltage(struct regulator *regulator, int min_uV, int max_uV) { struct regulator_dev *rdev = regulator->rdev; int ret = 0; + int old_min_uV, old_max_uV; mutex_lock(&rdev->mutex); @@ -2271,18 +2272,29 @@ int regulator_set_voltage(struct regulator *regulator, int min_uV, int max_uV) ret = regulator_check_voltage(rdev, &min_uV, &max_uV); if (ret < 0) goto out; + + /* restore original values in case of error */ + old_min_uV = regulator->min_uV; + old_max_uV = regulator->max_uV; regulator->min_uV = min_uV; regulator->max_uV = max_uV; ret = regulator_check_consumers(rdev, &min_uV, &max_uV); if (ret < 0) - goto out; + goto out2; ret = _regulator_do_set_voltage(rdev, min_uV, max_uV); - + if (ret < 0) + goto out2; + out: mutex_unlock(&rdev->mutex); return ret; +out2: + regulator->min_uV = old_min_uV; + regulator->max_uV = old_max_uV; + mutex_unlock(&rdev->mutex); + return ret; } EXPORT_SYMBOL_GPL(regulator_set_voltage); -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] regulator: core: if voltage scaling fails, restore original voltage values
On Thu, Dec 13, 2012 at 11:47:15AM +0200, Felipe Balbi wrote: > On Thu, Dec 13, 2012 at 10:13:00AM +0100, Paolo Pisati wrote: > > Signed-off-by: Paolo Pisati > > Tested-by: Robert Nelson > > please read Documentation/stable_kernel_rules.txt, you'll see this is > wrong. you mean that i should have waited for the commit to hit Linus's tree before cc-ing stable? -- bye, p. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] staging/omapdrm: garbage collect OMAP_DSS_DISPLAY_SUSPENDED
Compilation fix - leftover from: commit 998c336d4c7183301ed6a6ca93952f63e3cf694f Author: Tomi Valkeinen Date: Wed May 30 13:26:00 2012 +0300 OMAPDSS: remove omap_dss_device's suspend/resume Cc: stable # v3.7 Signed-off-by: Paolo Pisati --- drivers/staging/omapdrm/omap_connector.c |3 --- 1 file changed, 3 deletions(-) diff --git a/drivers/staging/omapdrm/omap_connector.c b/drivers/staging/omapdrm/omap_connector.c index 91edb3f..ff25467 100644 --- a/drivers/staging/omapdrm/omap_connector.c +++ b/drivers/staging/omapdrm/omap_connector.c @@ -113,9 +113,6 @@ static void omap_connector_dpms(struct drm_connector *connector, int mode) if (mode == DRM_MODE_DPMS_ON) { /* store resume info for suspended displays */ switch (dssdev->state) { - case OMAP_DSS_DISPLAY_SUSPENDED: - dssdev->activate_after_resume = true; - break; case OMAP_DSS_DISPLAY_DISABLED: { int ret = dssdev->driver->enable(dssdev); if (ret) { -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] staging/omapdrm: garbage collect OMAP_DSS_DISPLAY_SUSPENDED
On Thu, Jan 10, 2013 at 09:42:27PM +0100, Paolo Pisati wrote: > Compilation fix - leftover from: > > commit 998c336d4c7183301ed6a6ca93952f63e3cf694f > Author: Tomi Valkeinen > Date: Wed May 30 13:26:00 2012 +0300 > > OMAPDSS: remove omap_dss_device's suspend/resume > > Cc: stable # v3.7 > Signed-off-by: Paolo Pisati bah, never mind: https://git.kernel.org/?p=linux/kernel/git/gregkh/staging.git;a=commit;h=f5f9454c2145fa018c9808597739abce67114ac7 fixes the compilation breakagage. It could be useful for v3.7 stable tough. -- bye, p. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
3.8rc4+ and cpu_freq omap: hangs, oopses, etcetc
Hi, i can't boot my pandaes with 3.8rc4 + cpu_freq + ehci/ohci enabled, as it usually hangs with: [ 26.718322] INFO: rcu_sched detected stalls on CPUs/tasks: { 1} (detected by 0, t=2690 jiffies, g=4294967100, c=4294967099, q=749) [ 26.730682] Task dump for CPU 1: [ 26.734069] udevd R running 0 772 1 0x0002 [ 26.740783] [] (__schedule+0x34c/0x728) from [] (0xeebbaa70) complete dmesg with clks warnings and a "BUG: spinlock wrong CPU on CPU#1" here: http://paste.ubuntu.com/1563384/ sometimes it randomly oopses around usb: [4.922180] hub 1-1:1.0: port 1: status 0101 change 0001 [4.936706] Unable to handle kernel NULL pointer dereference at virtual address 0004 [4.945220] pgd = c0004000 [4.948059] [0004] *pgd= [4.951843] Internal error: Oops: 5 [#1] SMP ARM [4.956695] Modules linked in: [4.959899] CPU: 1Tainted: GW (3.8.0-rc4-00139-g1d85490 #1) [4.967224] PC is at _set_bit+0x1c/0x40 [4.971252] LR is at out_of_memory+0x7c/0x2f8 [4.975830] pc : []lr : []psr: 6193 [4.975830] sp : ee839a40 ip : fp : [4.987884] r10: 000e r9 : c088f5d8 r8 : c07ab33c [4.993377] r7 : ee8373c0 r6 : c07d1014 r5 : c1547e90 r4 : [5.000244] r3 : 0004 r2 : 0001 r1 : 0004 r0 : [5.007080] Flags: nZCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment kernel [5.014862] Control: 10c53c7d Table: 8000404a DAC: 0017 [5.020904] Process swapper/0 (pid: 1, stack limit = 0xee838240) [5.023437] usb 1-1: link qh256-0001/eeda8b00 start 1 [1/0 us] [5.023468] hub 1-1:1.0: state 7 ports 5 chg 0002 evt [5.023773] hub 1-1:1.0: port 1, status 0101, change , 12 Mb/s Complete dmesg here: http://paste.ubuntu.com/1563423/ Or: [4.927307] Unable to handle kernel NULL pointer dereference at virtual address 0014 [4.935821] pgd = c0004000 [4.938659] [0014] *pgd= [4.942413] Internal error: Oops: 5 [#1] SMP ARM [4.947265] Modules linked in: [4.950469] CPU: 1Tainted: GW (3.8.0-rc4 #1) [4.956420] PC is at rcu_irq_exit+0x20/0xc4 [4.960845] LR is at irq_enter+0x18/0x70 [4.964965] pc : []lr : []psr: a193 [4.964965] sp : ee87de90 ip : fff2 fp : ee87df54 [4.977020] r10: c07491d0 r9 : r8 : 0001 [4.982482] r7 : c073ae80 r6 : a193 r5 : 0001 r4 : ee87c000 [4.989349] r3 : c0745d88 r2 : r1 : 0560 r0 : c0049a0c [4.992736] usb 1-1: link qh256-0001/eedb0f80 start 1 [1/0 us] [4.992767] hub 1-1:1.0: state 7 ports 5 chg 0002 evt [4.993255] hub 1-1:1.0: port 1, status 0101, change , 12 Mb/s Complete dmesg here: http://paste.ubuntu.com/1563483/ Same happens with latest linus/master: 1d85490 Merge tag '3.8-pci-fixes-2' of ... Config can be found here: http://people.canonical.com/~ppisati/38rc4/config.omap2plus_cpufreq Disabling cpufreq i can get my board to boot, and 3.7.y is working fine. Any clue? -- bye, p. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
omap4: 3.8: IPV6 + PREEMPT_VOLUNTARY + !DEBUG_[SPINLOCK|MUTEXES] = BUG()
I keep getting this BUG() when there's IPV6 traffic in in my lan on a panda board with these configs: -start from a vanilla omap config (make ARCH=arm omap2plus_defconfig) -enable IPV6 and PREEMPT_VOLUNTARY -turn off CONFIG_DEBUG_SPINLOCK CONFIG_DEBUG_MUTEXES CONFIG_DEBUG_LOCK_ALLOC CONFIG_PROVE_LOCKING CONFIG_LOCKDEP CONFIG_TRACE_IRQFLAGS (or apply this patch fragment: http://people.canonical.com/~ppisati/panda_ipv6/config_lock_off.patch) -enable some useful options (like EHCI for my usb disk, etcetc) -finish off the build make ARCH=arm olddefconfig make ARCH=arm zImage -boot the board, wait for some ipv6 traffic: IP6 fe80::213:20ff:fefb:6364.mdns > ff02::fb.mdns: 0 PTR (QM)? _mumble._tcp.local. (36) and enjoy: [Thu Feb 21 10:23:07 2013] BUG: scheduling while atomic: swapper/0/0/0x4100 [Thu Feb 21 10:23:07 2013] Modules linked in: [Thu Feb 21 10:23:07 2013] [] (unwind_backtrace+0x0/0xf0) from [] (__schedule_bug+0x48/0x5c) [Thu Feb 21 10:23:07 2013] [] (__schedule_bug+0x48/0x5c) from [] (__schedule+0x700/0x740) [Thu Feb 21 10:23:07 2013] [] (__schedule+0x700/0x740) from [] (__cond_resched+0x24/0x34) [Thu Feb 21 10:23:07 2013] [] (__cond_resched+0x24/0x34) from [] (_cond_resched+0x3c/0x44) [Thu Feb 21 10:23:07 2013] [] (_cond_resched+0x3c/0x44) from [] (do_alignment+0x178/0x78c) [Thu Feb 21 10:23:07 2013] [] (do_alignment+0x178/0x78c) from [] (do_DataAbort+0x34/0x98) [Thu Feb 21 10:23:07 2013] [] (do_DataAbort+0x34/0x98) from [] (__dabt_svc+0x40/0x60) [Thu Feb 21 10:23:07 2013] Exception stack(0xc0763d70 to 0xc0763db8) [Thu Feb 21 10:23:07 2013] 3d60: e97e805e e97e806e 2c00 1100 [Thu Feb 21 10:23:07 2013] 3d80: ea86bb00 002c 0011 e97e807e c076d2a8 e97e805e e97e806e 002c [Thu Feb 21 10:23:07 2013] 3da0: 3d00 c0763dbc c04b98fc c02a8490 0113 [Thu Feb 21 10:23:07 2013] [] (__dabt_svc+0x40/0x60) from [] (__csum_ipv6_magic+0x8/0xc8) here you can find a .config for a 3.8 kernel showing this problem: http://people.canonical.com/~ppisati/panda_ipv6/config and a precompiled zImage: http://people.canonical.com/~ppisati/panda_ipv6/zImage any idea how can i debug this? -- bye, p. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: omap4: 3.8: IPV6 + PREEMPT_VOLUNTARY + !DEBUG_[SPINLOCK|MUTEXES] = BUG()
On Fri, Feb 22, 2013 at 12:36:37PM +, Russell King - ARM Linux wrote: > On Thu, Feb 21, 2013 at 10:48:19AM +0100, Paolo Pisati wrote: > > any idea how can i debug this? > > Please try this patch, and report back whether it solves your problem. > Thanks. yes, it solves my problem: any chance we can see it in 3.9 or 3.8.x? -- bye, p. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: omap4: 3.8: IPV6 + PREEMPT_VOLUNTARY + !DEBUG_[SPINLOCK|MUTEXES] = BUG()
On Mon, Feb 25, 2013 at 04:14:01PM +, Russell King - ARM Linux wrote: > > I was just looking to send a chase for this, because I'm about to > remerge my tree and I wanted this patch committed. > > Can I use your name and email address in the commit for the Reported-by > and Tested-by tags (which will be published in the kernel repository) > please? Thanks. absolutely: Reported-by: Paolo Pisati Tested-by: Paolo Pisati -- bye, p. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
3.15+: omap4: mmc: multi_v7: can't boot off mmc
I'm having an hard time making the vanilla v7_defconfig boot off the mmc on my pandaboard: [1.698272] omap_hsmmc 4809c000.mmc: unable to get vmmc regulator -517 [1.705139] platform 4809c000.mmc: Driver omap_hsmmc requests probe deferral [1.712890] omap_hsmmc 480d5000.mmc: unable to get vmmc regulator -517 [1.719787] platform 480d5000.mmc: Driver omap_hsmmc requests probe deferral [1.727691] sdhci-pltfm: SDHCI platform and OF driver helper [1.734619] usbcore: registered new interface driver usbhid [1.740478] usbhid: USB HID core driver [1.749359] TCP: cubic registered [1.752838] NET: Registered protocol family 17 [1.757690] Key type dns_resolver registered [1.762756] Power Management for TI OMAP4+ devices. [1.767883] Power Management for TI OMAP4. [1.772186] OMAP4 PM: u-boot >= v2012.07 is required for full PM support [1.779296] ThumbEE CPU extension supported. [1.779296] Registering SWP/SWPB emulation handler [1.790008] vwl1271: 1800 mV [1.794952] Skipping twl internal clock init and using bootloader value (unknown osc rate) [1.805358] twl 0-0048: PIH (irq 39) nested IRQs [1.811340] twl_rtc rtc.14: Power up reset detected. [1.817260] twl_rtc rtc.14: Enabling TWL-RTC [1.824249] twl_rtc rtc.14: rtc core: registered rtc.14 as rtc0 [1.831451] VAUX1_6030: 1000 <--> 3000 mV at 1800 mV [1.837677] VAUX2_6030: 1200 <--> 2800 mV at 1800 mV [1.844024] VAUX3_6030: 1000 <--> 3000 mV at 1200 mV [1.850311] VMMC: 1200 <--> 3000 mV at 3000 mV [1.855957] VPP: 1800 <--> 2500 mV at 1900 mV [1.861572] VUSIM: 1200 <--> 2900 mV at 1800 mV [1.866577] VDAC: 1800 mV [1.869964] VANA: 2100 mV [1.874114] VCXIO: 1800 mV [1.877624] VUSB: 3300 mV [1.881317] V1V8: 1800 mV [1.884979] V2V1: 2100 mV [1.967407] usb 1-1: new high-speed USB device number 2 using ehci-omap [2.094512] omap_i2c 4807.i2c: bus 0 rev0.10 at 400 kHz [2.104583] omap_i2c 48072000.i2c: bus 1 rev0.10 at 400 kHz [2.114044] omap_i2c 4806.i2c: bus 2 rev0.10 at 100 kHz [2.121582] hub 1-1:1.0: USB hub found [2.125854] hub 1-1:1.0: 5 ports detected [2.131744] omap_i2c 4835.i2c: bus 3 rev0.10 at 400 kHz [2.140686] omap_hsmmc 4809c000.mmc: pins are not configured from the driver [2.321166] twl_rtc rtc.14: setting system clock to 2000-01-01 00:00:00 UTC (946684800) [2.336578] ALSA device list: [2.339782] No soundcards found. [2.339782] VFS: Cannot open root device "mmcblk0p2" or unknown-block(0,0): error -6 [2.352478] Please append a correct "root=" boot option; here are the available partitions: [2.361297] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) [2.367980] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 3.14.0-12143-g552e691 #70 [2.377716] [] (unwind_backtrace) from [] (show_stack+0x10/0x14) [2.385864] [] (show_stack) from [] (dump_stack+0x88/0x98) [2.390289] [] (dump_stack) from [] (panic+0xa0/0x208) [2.400695] [] (panic) from [] (mount_block_root+0x1a0/0x230) [2.408569] [] (mount_block_root) from [] (mount_root+0x108/0x110) [2.408569] [] (mount_root) from [] (prepare_namespace+0x158/0x1a0) [2.425292] [] (prepare_namespace) from [] (kernel_init_freeable+0x1cc/0x1dc) [2.430084] [] (kernel_init_freeable) from [] (kernel_init+0x8/0xf0) [2.443145] [] (kernel_init) from [] (ret_from_fork+0x14/0x3c) [2.447967] CPU0: stopping [2.451110] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.14.0-12143-g552e691 #70 [2.451110] [] (unwind_backtrace) from [] (show_stack+0x10/0x14) [2.451110] [] (show_stack) from [] (dump_stack+0x88/0x98) [2.451110] [] (dump_stack) from [] (handle_IPI+0x148/0x174) [2.477386] [] (handle_IPI) from [] (gic_handle_irq+0x58/0x5c) [2.477386] [] (gic_handle_irq) from [] (__irq_svc+0x40/0x50) [2.477386] Exception stack(0xc0b6def0 to 0xc0b6df38) [2.506256] dee0: c0b7bf54 c0b7bf54 004c [2.506256] df00: 91be7a33 92080d44 eaf94de8 c0c8f2bc ea4bdd94 [2.523437] df20: 0010 c0b6df38 c06bcbf8 c06bcc04 6153 [2.523437] [] (__irq_svc) from [] (cpuidle_enter_state+0x68/0xf8) [2.523437] [] (cpuidle_enter_state) from [] (cpuidle_enter_state_coupled+0x130/0x378) [2.523437] [] (cpuidle_enter_state_coupled) from [] (cpu_startup_entry+0x200/0x230) [2.558868] [] (cpu_startup_entry) from [] (start_kernel+0x348/0x354) [2.567474] [] (start_kernel) from [<80208074>] (0x80208074) [2.567474] ---[ end Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) i tracked it down to the "PBIAS on DT" merge in 3.15-rc1: commit 97e18dc007546fce8e99098480b921a02ebb3037 Merge: 042f7b7 c674801 Author: Linus Torvalds Date: Wed Apr 9 08:39:39 2014 -0700 Merge tag 'mmc-updates-for-3.15-rc1' of git://git.kernel.org/
Re: 3.15+: omap4: mmc: multi_v7: can't boot off mmc
On Wed, Sep 10, 2014 at 11:50:01AM -0500, Nishanth Menon wrote: > On 17:33-20140910, Paolo Pisati wrote: > > I'm having an hard time making the vanilla v7_defconfig boot off the mmc on > > my > > pandaboard: > > V3.15: > https://github.com/nmenon/kernel-test-logs/blob/v3.15/multi_v7_defconfig/pandaboard-vanilla.txt > https://github.com/nmenon/kernel-test-logs/blob/v3.15/multi_v7_defconfig/pandaboard-es.txt are you 100% sure that this is a pure multi_v7_defconfig? because, by default, REGULATOR_PBIAS is off. > You might be interested in using partuuid to be careful about the probe > order deltas that may take place. i'm not sure i understood what you mean here. -- bye, p. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 3.15+: omap4: mmc: multi_v7: can't boot off mmc
On Thu, Sep 11, 2014 at 10:01:32AM +0200, Paolo Pisati wrote: > On Wed, Sep 10, 2014 at 11:50:01AM -0500, Nishanth Menon wrote: > > On 17:33-20140910, Paolo Pisati wrote: > > > I'm having an hard time making the vanilla v7_defconfig boot off the mmc > > > on my > > > pandaboard: > > > > V3.15: > > https://github.com/nmenon/kernel-test-logs/blob/v3.15/multi_v7_defconfig/pandaboard-vanilla.txt > > https://github.com/nmenon/kernel-test-logs/blob/v3.15/multi_v7_defconfig/pandaboard-es.txt > > are you 100% sure that this is a pure multi_v7_defconfig? because, by > default, > REGULATOR_PBIAS is off. > > > You might be interested in using partuuid to be careful about the probe > > order deltas that may take place. > > i'm not sure i understood what you mean here. ok, nevermind, i found the problem, i forgot the "rootwait" parameter in bootargs. -- bye, p. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
omap_wdt: node present in device-tree but kmod is not autoloaded
The question is two-folded, hence the crossposting. I have a kernel that runs perfectly on my beaglebone black, except for one thing - the kmod for the watchdog is not autoloaded upon boot albeit the device-tree node is present: ubuntu@beaglebone:~$ dmesg | grep wdt ubuntu@beaglebone:~$ ll /dev/watch* ls: cannot access /dev/watch*: No such file or directory ubuntu@beaglebone:~$ ls -la /proc/device-tree/ocp/wdt\@44e35000/ total 0 drwxr-xr-x 2 root root 0 Aug 25 13:43 . drwxr-xr-x 54 root root 0 Aug 25 13:43 .. -r--r--r-- 1 root root 13 Aug 25 13:43 compatible -r--r--r-- 1 root root 4 Aug 25 13:43 interrupts -r--r--r-- 1 root root 4 Aug 25 13:43 name -r--r--r-- 1 root root 8 Aug 25 13:43 reg -r--r--r-- 1 root root 10 Aug 25 13:43 ti,hwmods ubuntu@beaglebone:~$ cat /proc/device-tree/ocp/wdt\@44e35000/compatible ti,omap3-wdt ubuntu@beaglebone:~$ ls -la /sys/bus/platform/devices/ocp/*wdt* total 0 drwxr-xr-x 3 root root0 Aug 25 13:49 ./ drwxr-xr-x 33 root root0 Aug 25 13:49 ../ -rw-r--r-- 1 root root 4096 Aug 25 13:49 driver_override -r--r--r-- 1 root root 4096 Aug 25 13:49 modalias lrwxrwxrwx 1 root root0 Aug 25 13:49 of_node -> ../../../../firmware/devicetree/base/ocp/wdt@44e35000/ drwxr-xr-x 2 root root0 Aug 25 13:49 power/ lrwxrwxrwx 1 root root0 Aug 25 13:49 subsystem -> ../../../../bus/platform/ -rw-r--r-- 1 root root 4096 Aug 25 13:49 uevent and if i manually load the module: ubuntu@beaglebone:~$ sudo modprobe omap_wdt ubuntu@beaglebone:~$ dmesg | grep wdt [ 388.104283] omap_wdt: OMAP Watchdog Timer Rev 0x01: initial timeout 60 sec ubuntu@beaglebone:~$ ls -la /dev/watchdog* crw--- 1 root root 10, 130 Aug 25 13:46 /dev/watchdog crw--- 1 root root 251, 0 Aug 25 13:46 /dev/watchdog0 ubuntu@beaglebone:~$ ls -la /sys/bus/platform/devices/ocp/*wdt* total 0 drwxr-xr-x 3 root root0 Aug 25 13:53 . drwxr-xr-x 33 root root0 Aug 25 13:49 .. lrwxrwxrwx 1 root root0 Aug 25 13:53 driver -> ../../../../bus/platform/drivers/omap_wdt -rw-r--r-- 1 root root 4096 Aug 25 13:49 driver_override -r--r--r-- 1 root root 4096 Aug 25 13:49 modalias lrwxrwxrwx 1 root root0 Aug 25 13:49 of_node -> ../../../../firmware/devicetree/base/ocp/wdt@44e35000 drwxr-xr-x 2 root root0 Aug 25 13:49 power lrwxrwxrwx 1 root root0 Aug 25 13:49 subsystem -> ../../../../bus/platform -rw-r--r-- 1 root root 4096 Aug 25 13:49 uevent and then the device works as expected. So here are my questions: 1) My understanding was that, once a device node was present in the device-tree and there was a compatible driver available, it would have been autoloaded, so why it's not happening here? 2) And more importantly, how do i debug these situations? Building a kernel with the driver built-in, and comparing the two dmesgs, didn't show any noticeable difference either. Any idea? -- bye, p. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM/dts: hdmi-codec: panda/es dt entries
Signed-off-by: Paolo Pisati --- arch/arm/boot/dts/omap4-panda-common.dtsi |9 - arch/arm/boot/dts/omap4-panda-es.dts |3 ++- 2 files changed, 10 insertions(+), 2 deletions(-) diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi b/arch/arm/boot/dts/omap4-panda-common.dtsi index 88c6a05..f4aeaa1 100644 --- a/arch/arm/boot/dts/omap4-panda-common.dtsi +++ b/arch/arm/boot/dts/omap4-panda-common.dtsi @@ -36,9 +36,15 @@ }; }; + hdmi_audio: hdmi_audio@0 { + compatible = "linux,hdmi-audio"; + status = "okay"; + }; + sound: sound { compatible = "ti,abe-twl6040"; ti,model = "PandaBoard"; + ti,audio-codec = <&hdmi_audio>; ti,mclk-freq = <3840>; @@ -57,7 +63,8 @@ "HSMIC", "Headset Mic", "Headset Mic", "Headset Mic Bias", "AFML", "Line In", - "AFMR", "Line In"; + "AFMR", "Line In", + "HDMI Out", "TX"; }; /* HS USB Port 1 Power */ diff --git a/arch/arm/boot/dts/omap4-panda-es.dts b/arch/arm/boot/dts/omap4-panda-es.dts index 816d1c9..70152d6 100644 --- a/arch/arm/boot/dts/omap4-panda-es.dts +++ b/arch/arm/boot/dts/omap4-panda-es.dts @@ -23,7 +23,8 @@ "Line Out", "AUXL", "Line Out", "AUXR", "AFML", "Line In", - "AFMR", "Line In"; + "AFMR", "Line In", + "HDMI Out", "TX"; }; /* PandaboardES has external pullups on SCL & SDA */ -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] [RESEND] ARM/dts: hdmi-codec: panda/es dt entries
Signed-off-by: Paolo Pisati --- arch/arm/boot/dts/omap4-panda-common.dtsi |9 - arch/arm/boot/dts/omap4-panda-es.dts |3 ++- 2 files changed, 10 insertions(+), 2 deletions(-) diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi b/arch/arm/boot/dts/omap4-panda-common.dtsi index 88c6a05..f4aeaa1 100644 --- a/arch/arm/boot/dts/omap4-panda-common.dtsi +++ b/arch/arm/boot/dts/omap4-panda-common.dtsi @@ -36,9 +36,15 @@ }; }; + hdmi_audio: hdmi_audio@0 { + compatible = "linux,hdmi-audio"; + status = "okay"; + }; + sound: sound { compatible = "ti,abe-twl6040"; ti,model = "PandaBoard"; + ti,audio-codec = <&hdmi_audio>; ti,mclk-freq = <3840>; @@ -57,7 +63,8 @@ "HSMIC", "Headset Mic", "Headset Mic", "Headset Mic Bias", "AFML", "Line In", - "AFMR", "Line In"; + "AFMR", "Line In", + "HDMI Out", "TX"; }; /* HS USB Port 1 Power */ diff --git a/arch/arm/boot/dts/omap4-panda-es.dts b/arch/arm/boot/dts/omap4-panda-es.dts index 816d1c9..70152d6 100644 --- a/arch/arm/boot/dts/omap4-panda-es.dts +++ b/arch/arm/boot/dts/omap4-panda-es.dts @@ -23,7 +23,8 @@ "Line Out", "AUXL", "Line Out", "AUXR", "AFML", "Line In", - "AFMR", "Line In"; + "AFMR", "Line In", + "HDMI Out", "TX"; }; /* PandaboardES has external pullups on SCL & SDA */ -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] ARM/dts: hdmi-codec: panda/es dt entries
HDMI codec dummy entries for Panda/ES. Signed-off-by: Paolo Pisati --- Depends on "0f7f3d1 ASoC: hdmi-codec: Add devicetree binding with documentation", eligible for a 3.14-rcX fix. arch/arm/boot/dts/omap4-panda-common.dtsi |9 - arch/arm/boot/dts/omap4-panda-es.dts |3 ++- 2 files changed, 10 insertions(+), 2 deletions(-) diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi b/arch/arm/boot/dts/omap4-panda-common.dtsi index 88c6a05..f4aeaa1 100644 --- a/arch/arm/boot/dts/omap4-panda-common.dtsi +++ b/arch/arm/boot/dts/omap4-panda-common.dtsi @@ -36,9 +36,15 @@ }; }; + hdmi_audio: hdmi_audio@0 { + compatible = "linux,hdmi-audio"; + status = "okay"; + }; + sound: sound { compatible = "ti,abe-twl6040"; ti,model = "PandaBoard"; + ti,audio-codec = <&hdmi_audio>; ti,mclk-freq = <3840>; @@ -57,7 +63,8 @@ "HSMIC", "Headset Mic", "Headset Mic", "Headset Mic Bias", "AFML", "Line In", - "AFMR", "Line In"; + "AFMR", "Line In", + "HDMI Out", "TX"; }; /* HS USB Port 1 Power */ diff --git a/arch/arm/boot/dts/omap4-panda-es.dts b/arch/arm/boot/dts/omap4-panda-es.dts index 816d1c9..70152d6 100644 --- a/arch/arm/boot/dts/omap4-panda-es.dts +++ b/arch/arm/boot/dts/omap4-panda-es.dts @@ -23,7 +23,8 @@ "Line Out", "AUXL", "Line Out", "AUXR", "AFML", "Line In", - "AFMR", "Line In"; + "AFMR", "Line In", + "HDMI Out", "TX"; }; /* PandaboardES has external pullups on SCL & SDA */ -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] ARM/dts: hdmi-codec: panda/es dt entries
On Wed, Feb 19, 2014 at 10:15:24AM +0200, Peter Ujfalusi wrote: > > diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi > > b/arch/arm/boot/dts/omap4-panda-common.dtsi > > index 88c6a05..f4aeaa1 100644 > > --- a/arch/arm/boot/dts/omap4-panda-common.dtsi > > +++ b/arch/arm/boot/dts/omap4-panda-common.dtsi > > @@ -36,9 +36,15 @@ > > }; > > }; > > > > + hdmi_audio: hdmi_audio@0 { > > + compatible = "linux,hdmi-audio"; > > + status = "okay"; > > + }; > > + > > sound: sound { > > compatible = "ti,abe-twl6040"; > > ti,model = "PandaBoard"; > > + ti,audio-codec = <&hdmi_audio>; > > I don't think this is going to work. The omap-abe-twl6040 machine driver only > handles mcpdm and dmic right know. > 'ti,audio-codec' is not even supported and it is kind of misleading naming in > this context since twl6040 is also a codec, so why only the dummy-hdmi codec > deserves to be called as codec. i see what you mean: i thought that hdmi_audio to actually work had to be referenced inside the sound node (hence my inclusion there) but i was wrong and it had nothing to do with twl6040, would this one be ok for you? diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi b/arch/arm/boot/dts/omap4-panda-common.dtsi index 88c6a05..b6dd458 100644 --- a/arch/arm/boot/dts/omap4-panda-common.dtsi +++ b/arch/arm/boot/dts/omap4-panda-common.dtsi @@ -36,6 +36,11 @@ }; }; + hdmi_audio: hdmi_audio@0 { + compatible = "linux,hdmi-audio"; + status = "okay"; + }; + sound: sound { compatible = "ti,abe-twl6040"; ti,model = "PandaBoard"; > Furthermore: we have the omap-hdmi-card machine driver to handle the HDMI > audio. It lacks DT support AFAIK but should not be a big deal to add the > bindings. > To get the hdmi audio working you also need to have phandle for the omap-hdmi > DAI, the codec alone is not enough. > you mean sound/soc/omap/omap-hdmi-card.c? that's exactly what i'm trying to fix. With the above patch, plus: -CONFIG_DISPLAY_CONNECTOR_HDMI=m +CONFIG_DISPLAY_CONNECTOR_HDMI=y CONFIG_DISPLAY_ENCODER_TFP410=m -CONFIG_DISPLAY_ENCODER_TPD12S015=m +CONFIG_DISPLAY_ENCODER_TPD12S015=y to make the omap-hdmi-audio-dai attach (sound/soc/omap/omap-hdmi.c) and something like this (that is not upstreamable as i understand but is an unfortunate fallout from the board removal[*]): --- a/arch/arm/mach-omap2/devices.c +++ b/arch/arm/mach-omap2/devices.c @@ -335,6 +335,11 @@ static struct platform_device omap_hdmi_audio = { .id = -1, }; +static struct platform_device hdmi_audio_codec = { + .name = "hdmi-audio-codec", + .id = -1, +}; + static void __init omap_init_hdmi_audio(void) { struct omap_hwmod *oh; @@ -349,6 +354,7 @@ static void __init omap_init_hdmi_audio(void) "Can't build omap_device for omap-hdmi-audio-dai.\n"); platform_device_register(&omap_hdmi_audio); + platform_device_register(&hdmi_audio_codec); } #else static inline void omap_init_hdmi_audio(void) {} i finally get my OMAPHDMI device back: flag@panda:~$ cat /proc/asound/cards 0 [OMAPHDMI ]: OMAPHDMI - OMAPHDMI OMAPHDMI 1 [PandaBoardES ]: PandaBoardES - PandaBoardES PandaBoardES [*]: in arch/arm/mach-omap2/board-omap4panda.c we had: -static struct platform_device panda_hdmi_audio_codec = { - .name = "hdmi-audio-codec", - .id = -1, -}; -static struct platform_device *panda_devices[] __initdata = { ... - &panda_hdmi_audio_codec, ... -}; that was registered as part of omap4_panda_init(): - platform_add_devices(panda_devices, ARRAY_SIZE(panda_devices)); -- bye, p. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
omap4, panda: 3.11, dtb and wifi
i know we switched to dtb-only booting, but what's happened to wifi? 3.5.x: flag@flag-desktop:~$ ls -la /sys/bus/platform/devices/wl12xx/ total 0 drwxr-xr-x 5 root root0 set 13 17:26 . drwxr-xr-x 4 root root0 set 13 17:26 .. -rw-r--r-- 1 root root 4096 set 13 17:28 bt_coex_state lrwxrwxrwx 1 root root0 set 13 17:27 driver -> ../../../../../../../../bus/platform/drivers/wl12xx_driver -r 1 root root0 set 13 17:28 fwlog -r--r--r-- 1 root root 4096 set 13 17:28 hw_pg_ver drwxr-xr-x 3 root root0 set 13 17:27 ieee80211 -r--r--r-- 1 root root 4096 set 13 17:28 modalias drwxr-xr-x 3 root root0 set 13 17:27 net drwxr-xr-x 2 root root0 set 13 17:28 power lrwxrwxrwx 1 root root0 set 13 17:27 subsystem -> ../../../../../../../../bus/platform -rw-r--r-- 1 root root 4096 set 13 17:26 uevent 3.11.x: flag@flag-desktop:~$ ls -la /sys/bus/platform/devices/wl* ls: cannot access /sys/bus/platform/devices/wl*: No such file or directory -- bye, p. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
panda, 3.11 and wifi: 'wlcore: ERROR timeout waiting for the hardware to complete initialization'
Dear, after the inclusion of 851320e: ARM: dts: Fix muxing and regulator for wl12xx on the SDIO bus for pandaboard wlan0 is back on my pandaes, but it doesn't work and my logs are swamped with: [ 56.255401] wlcore: ERROR timeout waiting for the hardware to complete initialization [ 56.264770] wlcore: ERROR firmware boot failed despite 3 retries [ 58.689971] wlcore: ERROR timeout waiting for the hardware to complete initialization [ 61.086730] wlcore: ERROR timeout waiting for the hardware to complete initialization [ 63.523223] wlcore: ERROR timeout waiting for the hardware to complete initialization [ 63.532592] wlcore: ERROR firmware boot failed despite 3 retries ... any idea what could be wrong now? here is a complete dmesg: http://goo.gl/e1ZDVp -- bye, p. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
3.12: omap4: cpuidle: solid hangs at boot
Vanilla 3.12 multi_v7_defconfig + cpu_idle result in a solid hang on my pandaes board: has anyone experienced it before? is cpu_idle safe on omap4? same kernel boots fine on omap3 and some other arm boards fwiw. if you want to reproduce it: config: http://people.canonical.com/~ppisati/3.12_armv7multi_cpuidle/config zImage: http://people.canonical.com/~ppisati/3.12_armv7multi_cpuidle/zImage boot log: http://paste.ubuntu.com/6415293/ -- bye, p. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
am335x boneblack memory size and dtb: is memory live patched?
Lately i've been trying to track down a panic i hit when i pass the "mem=256M" option to a 3.16 kernel on a bleaglebone black, and i noticed this: dtc -I dtb ./arch/arm/boot/dts/am335x-boneblack.dtb ... memory { device_type = "memory"; reg = <0x8000 0x1000>; }; ... that's 256M of memory while the beaglebone black has 512M, does it mean the dtb is live patched (by u-boot?) before being passed to the kernel? -- bye, p. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
beaglebone black: is mem=... broken?
Boot hangs when passing mem=256M to a 3.16 kernel (but i was able to reproduce it with multi_v7_defconfig on a 3.19rcX kernel too): 80e6d694: 0024 65746e49 6c616e72..$.Internal 80e6d6a4: 72726520 203a726f 73706f4f 2035203a error: Oops: 5 80e6d6b4: 5d31235b 504d5320 4d524120 [#1] SMP ARM 80e6d6c4: 0012 75646f4dModu 80e6d6d4: 2073656c 6b6e696c 69206465 3a6eles linked in:.. 80e6d6e4: 80e6d6f4: 6f4320300 Co 80e6d704: 203a6d6d 70617773 20726570 20746f4emm: swapper Not 80e6d714: 6e696174 20646574 36312e33 322d302etainted 3.16.0-2 80e6d724: 65672d38 6972656e 33232063 62552d388-generic #38-Ub 80e6d734: 75746e75 002duntu..-. 80e6d744: 6b736174 3063203a 61313964task: c0d91a 80e6d754: 74203832 63203a69 34386430 2030303028 ti: c0d84000 80e6d764: 6b736174 3a69742e 64306320 30303438task.ti: c0d8400 80e6d774: 0030 00220.". 80e6d784: 69204350 74612073 74646620PC is at fdt 80e6d794: 6568635f 685f6b63 65646165 78302b72_check_header+0x 80e6d7a4: 78302f30 3437 0/0x74.. 80e6d7b4: 74612073s at 80e6d7c4: 755f5f20 616c666e 6e657474 7665645f __unflatten_dev 80e6d7d4: 5f656369 65657274 3778302b 78302f38ice_tree+0x78/0x 80e6d7e4: 00306132 2a0. 80e6d7f4: 65323930092e 80e6d804: 3e383064 2020205d 20726c20 3c5b203ad08>]lr : [< 80e6d814: 64373063 34303335 20205d3e 73702020c07d5304>]ps 80e6d824: 36203a72 30303030 0a333931 3a207073r: 6193.sp : 80e6d834: 64306320 33663538 69202030 203a2070 c0d85f30 ip : 80e6d844: 31663038 37616638 70662020 63203a2080f18fa7 fp : c 80e6d854: 33666530 00343661 0ef3a64. 80e6d864: 80e6d874: 36623063c0b6 80e6d884: 30393730 38722020 63203a20 613264300790 r8 : c0d2a 80e6d894: 00383435 548. 80e6d8a4: 80e6d8b4: 303030355000 80e6d8c4: 35722020 63203a20 33366530 20306330 r5 : c0e630c0 80e6d8d4: 20347220 3063203a 30333665 3063 r4 : c0e630c0.. 80e6d8e4: 80e6d8f4: 722020300 r 80e6d904: 203a2032 30303030 30303030 317220202 : r1 80e6d914: 63203a20 30316630 20633231 20307220 : c0f1012c r0 80e6d924: 6663203a 3035 3030 : cfff5000.. 80e6d934: 67616c46Flag 80e6d944: 6e203a73 2076435a 51524920 666f2073s: nZCv IRQs of 80e6d954: 46202066 20735149 20206e6f 65646f4df FIQs on Mode 80e6d964: 43565320 2032335f 41534920 4d524120 SVC_32 ISA ARM 80e6d974: 65532020 6e656d67 656b2074 6c656e72 Segment kernel Another thing that i noticed was that we actually pass 256M as the physical memory, while the beaglebone black has 512M - is the dt live patched by the bootloader before being passed to the kernel? dtc -I dtb ./arch/arm/boot/dts/am335x-boneblack.dtb ... memory { device_type = "memory"; reg = <0x8000 0x1000>; }; ... -- bye, p. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: beaglebone black: is mem=... broken?
On Sun, Jan 18, 2015 at 06:38:46PM +0100, Geert Uytterhoeven wrote: > > The boot loader copied the DT to the end of real RAM, not to the end of > the 256 MiB block? Hence the kernel accesses unmapped memory > when checking the FDT header? actually everything is below 256M since physical memory starts at 0x8000: U-Boot# printenv loadaddr loadaddr=0x8200 U-Boot# printenv fdtaddr fdtaddr=0x8800 U-Boot# load mmc 0:1 ${loadaddr} zimage reading zimage 5694816 bytes read in 318 ms (17.1 MiB/s) U-Boot# load mmc 0:1 ${fdtaddr} am335x-boneblack.dtb reading am335x-boneblack.dtb 29985 bytes read in 10 ms (2.9 MiB/s) U-Boot# setenv bootargs console=ttyO0,115200n8 root=/dev/mmcblk0p2 ro rootfstype=ext4 rootwait debug earlyprintk mem=256M U-Boot# bootz ${loadaddr} - ${fdtaddr} Kernel image @ 0x8200 [ 0x00 - 0x56e560 ] ## Flattened Device Tree blob at 8800 Booting using the fdt blob at 0x8800 Loading Device Tree to 8fff5000, end 8520 ... OK Starting kernel ... hangs there, and after i reset i found the aforementioned oops in __log_buf. Here is without the mem= argument: U-Boot SPL 2015.01 (Jan 16 2015 - 10:20:36) MMC: block number 0x100 exceeds max(0x0) MMC: block number 0x200 exceeds max(0x0) *** Error - No Valid Environment Area found Using default environment U-Boot 2015.01 (Jan 16 2015 - 10:20:36) Watchdog enabled I2C: ready DRAM: 512 MiB MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1 Net:not set. Validating first E-fuse MAC cpsw, usb_ether Hit any key to stop autoboot: 0 U-Boot# load mmc 0:1 ${loadaddr} zimage reading zimage 5694816 bytes read in 318 ms (17.1 MiB/s) U-Boot# load mmc 0:1 ${fdtaddr} am335x-boneblack.dtb reading am335x-boneblack.dtb 29985 bytes read in 11 ms (2.6 MiB/s) U-Boot# setenv bootargs console=ttyO0,115200n8 root=/dev/mmcblk0p2 ro rootfstype=ext4 rootwait debug earlyprintk U-Boot# bootz ${loadaddr} - ${fdtaddr} Kernel image @ 0x8200 [ 0x00 - 0x56e560 ] ## Flattened Device Tree blob at 8800 Booting using the fdt blob at 0x8800 Loading Device Tree to 8fff5000, end 8520 ... OK Starting kernel ... [0.00] Booting Linux on physical CPU 0x0 [0.00] Linux version 3.19.0-rc4-1-g45aa0b7 (flag@luxor) (gcc version 4.8.2 (Ubuntu/Linaro 4.8.2-16ubuntu4) ) #1 SMP Fri Jan 16 10:33:22 CET5 ... -- bye, p. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
3.1[34]: omap4: panda: hang on reboot?
I've been experiencing hangs on reboot on two different panda boards (es rev1 and vanilla rev a1) with v3.14-rc8 (but reproducible in 3.13 too): toolchanin: gcc version 4.8.1 (Ubuntu/Linaro 4.8.1-10ubuntu7) the config is a multi_v7_defconfig plus a couple of codepages: http://people.canonical.com/~ppisati/omap4_reboot_hangs/config a prebuilt zImage is available here: http://people.canonical.com/~ppisati/omap4_reboot_hangs/zImage sometimes i can hit this two times in a row, others it's a bit less frequent - put this into your crontab and let it go: */5 * * * * /bin/date >> /reboot.log && /sbin/reboot it never passed 2hrs of reboot cycles. I already tried different u-boots but that doesn't make any difference, am i the only one experiencing this issue? -- bye, p. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 3.1[34]: omap4: panda: hang on reboot?
On Thu, Mar 27, 2014 at 06:54:14PM +0100, Paolo Pisati wrote: > I've been experiencing hangs on reboot on two different panda boards (es rev1 > and vanilla rev a1) with v3.14-rc8 (but reproducible in 3.13 too): > > toolchanin: gcc version 4.8.1 (Ubuntu/Linaro 4.8.1-10ubuntu7) > > the config is a multi_v7_defconfig plus a couple of codepages: > > http://people.canonical.com/~ppisati/omap4_reboot_hangs/config > > a prebuilt zImage is available here: > > http://people.canonical.com/~ppisati/omap4_reboot_hangs/zImage > > sometimes i can hit this two times in a row, others it's a bit less > frequent - put this into your crontab and let it go: > > */5 * * * * /bin/date >> /reboot.log && /sbin/reboot > > it never passed 2hrs of reboot cycles. > > I already tried different u-boots but that doesn't make any difference, > am i the only one experiencing this issue? i bisected it down to this commit: commit e002264f7e45d7661b237045577052fd0b40f89c Author: Balaji T K Date: Mon Oct 21 00:25:18 2013 +0530 mmc: omap_hsmmc: Fix pbias_disable for omap4 pbias_disable is set to protect the mmc pbias i/o cells in DT boot by preventing voltage switch. Currently pbias_disable is enabled only for omap3 and not for omap4 due to reg_offset difference of 0x100. Enable pbias_disable for omap4+ too by using res->start which does not include the reg_offset. Signed-off-by: Balaji T K Signed-off-by: Chris Ball with this commit reverted, i can reboot in a loop for hours without any problem, while if i keep this patch, my pandas don't survive more that two hours (again, it's really random as it could hang a couple of times in a row and then work like a charm for ten reboots straight). Any idea? does it ring any bell? -- bye, p. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP baseline test results for v3.14
On Wed, Apr 02, 2014 at 10:15:13AM -0700, Tony Lindgren wrote: > > Paul uses MMC filesystem, I use NFS. As Felipe Pointed out as well, I > > did rootcause MMC filesystem mount issue here: > > http://marc.info/?l=linux-omap&m=139637044425644&w=2 > > Balaji, care to take a look at the issue for MMC? It may > be already fixed in next with the PBIAS handling? it may be related (or not), but i'm experiencing reboot issues with 3.13/.14 on omap4 (panda), and after a bisection i found out that reverting commit e002264f7e45d7661b237045577052fd0b40f89c Author: Balaji T K ti.com> Date: Mon Oct 21 00:25:18 2013 +0530 mmc: omap_hsmmc: Fix pbias_disable for omap4 pbias_disable is set to protect the mmc pbias i/o cells in DT boot by preventing voltage switch. Currently pbias_disable is enabled only for omap3 and not for omap4 due to reg_offset difference of 0x100. Enable pbias_disable for omap4+ too by using res->start which does not include the reg_offset. Signed-off-by: Balaji T K ti.com> Signed-off-by: Chris Ball laptop.org> made it go away: can you point me to those pbias handling patches (i guess something about dt-booting handling pbias correctly now)? Root on mmc in my case. -- bye, p. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html