Re: v3.19-rc1 regression(?) on N900
On Wednesday 24 December 2014 23:57:38 Nishanth Menon wrote: based on automated testing with u-boot as a chained bootloader.. v3.18: boots fine: https://github.com/nmenon/kernel-test-logs/blob/v3.18/omap2plu s_defconfig/n900.txt v3.19-rc1: hung https://github.com/nmenon/kernel-test-logs/blob/v3.19-rc1/omap 2plus_defconfig/n900.txt in the interim, my farm had a bit of breakdown around the time of n900 breakdown.. as per my last functional linux-next logs: https://github.com/nmenon/kernel-test-logs/blob/next-20141204/ omap2plus_defconfig/n900.txt - hung. https://github.com/nmenon/kernel-test-logs/blob/next-20141112/ omap2plus_defconfig/n900.txt - working. DEBUG_LL, CONFIG_DEBUG_OMAP3UART3=y and early_printk did not yield information either Note: I am using the combined uImage+dtb image.[2] I think this might just be my setup..(i use chained loader - NOLO-u-boot-serial download-kernel) but anyways.. Since Pali thought others might be interested in sharing experience... [1] http://slexy.org/raw/s2osxhhwbR [2] https://github.com/nmenon/linux-2.6-playground/commit/177f5f71 b3f21ea484ee4b09a2e0c015de522417 CCing other people. I see same problem in qemu with 3.19-rc1 kernel when doing DT boot. In qemu I'm using direct booting from OneNAND (X-Loader -- NOLO -- kernel) without U-Boot. After NOLO load boot kernel I do not see any other output from serial console. Also on qemu screen there is no new output (just NOKIA logo from bootloader). I do not have this problem when doing legacy/board code boot with 3.19-rc1 kernel, so this problem is related to DT. Kernel 3.18-rc1 worked fine for both DT and legacy boot. Can somebody look what broke DT booting? -- Pali Rohár pali.ro...@gmail.com signature.asc Description: This is a digitally signed message part.
Re: v3.19-rc1 regression(?) on N900
On Thu 2014-12-25 09:32:40, Pali Rohár wrote: On Wednesday 24 December 2014 23:57:38 Nishanth Menon wrote: based on automated testing with u-boot as a chained bootloader.. v3.18: boots fine: https://github.com/nmenon/kernel-test-logs/blob/v3.18/omap2plu s_defconfig/n900.txt v3.19-rc1: hung https://github.com/nmenon/kernel-test-logs/blob/v3.19-rc1/omap 2plus_defconfig/n900.txt in the interim, my farm had a bit of breakdown around the time of n900 breakdown.. as per my last functional linux-next logs: https://github.com/nmenon/kernel-test-logs/blob/next-20141204/ omap2plus_defconfig/n900.txt - hung. https://github.com/nmenon/kernel-test-logs/blob/next-20141112/ omap2plus_defconfig/n900.txt - working. DEBUG_LL, CONFIG_DEBUG_OMAP3UART3=y and early_printk did not yield information either Early hang, independend on config. That's dtb too big. Delete something, and it should work again. Plus you'll note video regression. # I test-merged 3315764efceaccfb02c7d4c99ef8eed6716cd861, and boom, # video is gone. # # I reverted # # 4b4123f0c7b02f7cf1a3189f967f079197578c3a..9051909e451a0368c95ccf74562adb53fd2719f8 # in 3.19, and voila, video is back. CCing other people. I see same problem in qemu with 3.19-rc1 kernel when doing DT boot. In qemu I'm using direct booting from OneNAND (X-Loader -- NOLO -- kernel) without U-Boot. After NOLO load boot kernel I do not see any other output from serial console. Also on qemu screen there is no new output (just NOKIA logo from bootloader). I do not have this problem when doing legacy/board code boot with 3.19-rc1 kernel, so this problem is related to DT. Kernel 3.18-rc1 worked fine for both DT and legacy boot. Can somebody look what broke DT booting? It was too big dtb, at least for me. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- 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] arm: omap: reduce zImage size on omap2plus_defconfig
Hi Tony, On 12/24/14 21:04, Tony Lindgren wrote: * Felipe Balbi ba...@ti.com [141224 07:52]: Hi, On Wed, Dec 24, 2014 at 01:53:46PM +0200, Igor Grinberg wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/23/14 18:19, Felipe Balbi wrote: On Tue, Dec 23, 2014 at 09:30:45AM +0200, Igor Grinberg wrote: Hi Felipe, On 12/22/14 20:05, Felipe Balbi wrote: [...] CONFIG_SCSI_SCAN_ASYNC=y -CONFIG_ATA=y -CONFIG_SATA_AHCI_PLATFORM=y -CONFIG_MD=y +CONFIG_ATA=m +CONFIG_SATA_AHCI_PLATFORM=m Isn't this needed for the rootfs on SATA devices? there's no known boards with rootfs on SATA. Until then, we can reduce the size. What makes you say so? The decision for rootfs on SATA is taken dynamically. OMAP5 boards (specifically cm-t54) can have rootfs on SATA... I'll leave the decision to Tony. Even though they _can_, they really don't and IIRC, OMAP5's SATA has so many silicon errata that it'd be annoying to find that special device which works (e.g it can't negotiate lower speeds with SATA III devices and it won't support SATA I). Yet, it is not that buggy and at least until now, I di not get any reports about badly working SATA from customers... As of today, we don't know of anybody really shipping anything with rootfs on SATA and distros would rather ship initiramfs than a giant zImage anyway. So, you just continue to ignore what I'm saying... even after I point to a device... Is it SATA that makes it so giant? Because I find it worth having in SATA than spare some more k's... Tony, your call. I think we should move omap2plus_defconfig to be mostly modular and usable for distros as a base. Most distros prefer to build almost everything as loadable modules. And my preference is that we should only keep the minimum rootfs for devices and serial support as built-in and rely on initramfs for most drivers. And slowly move also the remaining built-in drivers to be loadable modules. The reasons for having drivers as loadable modules are many. It allows distros to use the same kernel for all the devices without bloating the kernel. It makes developing drivers easier as just the module needs to be reloaded. And loadable modules protect us from cross-framework spaghetti calls in the kernel as the interfaces are clearly defined. Are there people really using SATA as rootfs right now on omaps? Yes. That is exactly my point. If it's only something that will be more widely used in the future, then I suggest we make it into a loadable module, and presume initramfs and loadable module also for any new devices. The same way x86 has been doing with distros for years. The difference from x86 is that we're in embedded here and although initramfs is a kind of option, but it means, you need to load even more data during the boot process... it is annoying and I would not want to use it on embedded. (BTW, x86_64_defconfig has it compiled in...) We can also, split the defconfig as it was some time ago... but I would not want to go that direction... If we go the initramfs way, then why not also load MMC from it? That will also reduce kernel size... (but add initramfs size) I'm sure you will find making the MMC a loadable module inconvenient. That how I find making the SATA a loadable module... Right now, we tell our customers that they can use mainline with omap2plus_defconfig. If you decide to drop SATA, we will not be able to do that anymore. Anyway, like Felipe said, it is your call. I will not interfere anymore... -- Regards, Igor. -- 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: v3.19-rc1 regression(?) on N900
On Thu 2014-12-25 09:32:40, Pali Rohár wrote:
On Wednesday 24 December 2014 23:57:38 Nishanth Menon wrote:
based on automated testing with u-boot as a chained
bootloader..
v3.18: boots fine:
https://github.com/nmenon/kernel-test-logs/blob/v3.18/omap2plu
s_defconfig/n900.txt
v3.19-rc1: hung
https://github.com/nmenon/kernel-test-logs/blob/v3.19-rc1/omap
2plus_defconfig/n900.txt
in the interim, my farm had a bit of breakdown around the time
of n900 breakdown..
as per my last functional linux-next logs:
https://github.com/nmenon/kernel-test-logs/blob/next-20141204/
omap2plus_defconfig/n900.txt - hung.
https://github.com/nmenon/kernel-test-logs/blob/next-20141112/
omap2plus_defconfig/n900.txt - working.
DEBUG_LL, CONFIG_DEBUG_OMAP3UART3=y and early_printk did not
yield information either
Note: I am using the combined uImage+dtb image.[2]
I think this might just be my setup..(i use chained loader -
NOLO-u-boot-serial download-kernel) but anyways.. Since
Pali thought others might be interested in sharing
experience...
[1] http://slexy.org/raw/s2osxhhwbR
[2]
https://github.com/nmenon/linux-2.6-playground/commit/177f5f71
b3f21ea484ee4b09a2e0c015de522417
CCing other people.
I see same problem in qemu with 3.19-rc1 kernel when doing DT
boot. In qemu I'm using direct booting from OneNAND (X-Loader --
NOLO -- kernel) without U-Boot. After NOLO load boot kernel I
do not see any other output from serial console. Also on qemu
screen there is no new output (just NOKIA logo from bootloader).
I do not have this problem when doing legacy/board code boot with
3.19-rc1 kernel, so this problem is related to DT.
Kernel 3.18-rc1 worked fine for both DT and legacy boot.
Can somebody look what broke DT booting?
You should be able to apply this to get it back to boot.
diff --git a/arch/arm/boot/dts/omap3-n900.dts b/arch/arm/boot/dts/omap3-n900.dts
index 53f3ca0..7c17d084 100644
--- a/arch/arm/boot/dts/omap3-n900.dts
+++ b/arch/arm/boot/dts/omap3-n900.dts
@@ -13,9 +13,16 @@
#include dt-bindings/input/input.h
/ {
- model = Nokia N900;
+ model = Nokia RX-51 board;
compatible = nokia,omap3-n900, ti,omap3430, ti,omap3;
+ aliases {
+ i2c0;
+ i2c1 = i2c1;
+ i2c2 = i2c2;
+ i2c3 = i2c3;
+ };
+
cpus {
cpu@0 {
cpu0-supply = vcc;
@@ -26,7 +33,7 @@
compatible = gpio-leds;
heartbeat {
label = debug::sleep;
- gpios = gpio6 2 GPIO_ACTIVE_HIGH; /* gpio162 */
+ gpios = gpio6 2 GPIO_ACTIVE_HIGH; /* 162 */
linux,default-trigger = default-on;
pinctrl-names = default;
pinctrl-0 = debug_leds;
@@ -140,14 +147,6 @@
;
};
- ethernet_pins: pinmux_ethernet_pins {
- pinctrl-single,pins =
- OMAP3_CORE1_IOPAD(0x20b4, PIN_INPUT_PULLDOWN |
MUX_MODE4) /* gpmc_ncs3.gpio_54 */
- OMAP3_CORE1_IOPAD(0x20fc, PIN_OUTPUT | MUX_MODE4)
/* dss_data16.gpio_86 */
- OMAP3_CORE1_IOPAD(0x219c, PIN_OUTPUT | MUX_MODE4)
/* uart3_rts_sd.gpio_164 */
- ;
- };
-
gpmc_pins: pinmux_gpmc_pins {
pinctrl-single,pins =
@@ -307,7 +306,7 @@
regulator-name = V28;
regulator-min-microvolt = 280;
regulator-max-microvolt = 280;
- regulator-always-on; /* due battery cover sensor */
+ regulator-always-on; /* due to battery cover sensor */
};
vaux2 {
@@ -365,7 +364,6 @@
regulator-name = VIO;
regulator-min-microvolt = 180;
regulator-max-microvolt = 180;
-
};
vintana1 {
@@ -504,30 +502,6 @@
clock-mode = /bits/ 8 0; /* LP55XX_CLOCK_AUTO */
enable-gpio = gpio2 9 GPIO_ACTIVE_HIGH; /* 41 */
- chan0 {
- chan-name = lp5523:kb1;
- led-cur = /bits/ 8 50;
- max-cur = /bits/ 8 100;
- };
-
- chan1 {
- chan-name = lp5523:kb2;
- led-cur = /bits/ 8 50;
- max-cur = /bits/ 8 100;
- };
-
- chan2 {
- chan-name = lp5523:kb3;
- led-cur = /bits/ 8 50;
- max-cur = /bits/ 8 100;
- };
-
- chan3 {
- chan-name = lp5523:kb4;
- led-cur = /bits/ 8 50;
- max-cur = /bits/ 8 100;
- };
-
chan4 {
chan-name = lp5523:b;
led-cur = /bits/ 8 50;
@@ -545,18 +519,6 @@
Re: v3.19-rc1 regression(?) on N900
Hi, On Thu, Dec 25, 2014 at 10:11:21AM +0100, Pavel Machek wrote: On Thu 2014-12-25 09:32:40, Pali Rohár wrote: On Wednesday 24 December 2014 23:57:38 Nishanth Menon wrote: based on automated testing with u-boot as a chained bootloader.. v3.19-rc1: hung https://github.com/nmenon/kernel-test-logs/blob/v3.19-rc1/omap 2plus_defconfig/n900.txt Early hang, independend on config. That's dtb too big. Delete something, and it should work again. For me, DT boot works fine with 3.19-rc1 as is... Plus you'll note video regression. ...however, I can confirm that framebuffer is broken: [8.230743] omapfb omapfb: no displays [8.255584] omapfb omapfb: failed to setup omapfb [8.260620] platform omapfb: Driver omapfb requests probe deferral [8.284118] of_get_named_gpiod_flags: parsed 'reset-gpios' property of node '/ocp/spi@48098000/acx565akm@2[0]' - status (0) [8.284271] acx565akm spi1.2: failed to find video source [8.290069] spi spi1.2: Driver acx565akm requests probe deferral I bisected it to ef691ff48bc8 (OMAPDSS: DT: Get source endpoint by matching reg-id). When I revert that, also FB works with 3.19-rc1. A. -- 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] arm: omap: reduce zImage size on omap2plus_defconfig
Hi, On Wed, Dec 24, 2014 at 11:04:01AM -0800, Tony Lindgren wrote: * Felipe Balbi ba...@ti.com [141224 07:52]: Hi, On Wed, Dec 24, 2014 at 01:53:46PM +0200, Igor Grinberg wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/23/14 18:19, Felipe Balbi wrote: On Tue, Dec 23, 2014 at 09:30:45AM +0200, Igor Grinberg wrote: Hi Felipe, On 12/22/14 20:05, Felipe Balbi wrote: [...] CONFIG_SCSI_SCAN_ASYNC=y -CONFIG_ATA=y -CONFIG_SATA_AHCI_PLATFORM=y -CONFIG_MD=y +CONFIG_ATA=m +CONFIG_SATA_AHCI_PLATFORM=m Isn't this needed for the rootfs on SATA devices? there's no known boards with rootfs on SATA. Until then, we can reduce the size. What makes you say so? The decision for rootfs on SATA is taken dynamically. OMAP5 boards (specifically cm-t54) can have rootfs on SATA... I'll leave the decision to Tony. Even though they _can_, they really don't and IIRC, OMAP5's SATA has so many silicon errata that it'd be annoying to find that special device which works (e.g it can't negotiate lower speeds with SATA III devices and it won't support SATA I). As of today, we don't know of anybody really shipping anything with rootfs on SATA and distros would rather ship initiramfs than a giant zImage anyway. Tony, your call. I think we should move omap2plus_defconfig to be mostly modular and usable for distros as a base. Most distros prefer to build almost everything as loadable modules. And my preference is that we should only keep the minimum rootfs for devices and serial support as built-in and rely on initramfs for most drivers. And slowly move also the remaining built-in drivers to be loadable modules. The reasons for having drivers as loadable modules are many. It allows distros to use the same kernel for all the devices without bloating the kernel. It makes developing drivers easier as just the module needs to be reloaded. And loadable modules protect us from cross-framework spaghetti calls in the kernel as the interfaces are clearly defined. Are there people really using SATA as rootfs right now on omaps? not that we know :-) The only platforms available today with SATA are OMAP5432 uEVM and DRA7x EVM, the latter being mostly used by TIers as of now (at least from mainline point of view). If it's only something that will be more widely used in the future, then I suggest we make it into a loadable module, and presume initramfs and loadable module also for any new devices. The same way x86 has been doing with distros for years. alright, as a module it shall remain. -- balbi signature.asc Description: Digital signature
Re: linux-next: add the omap-pending tree
Hi Paul, On Fri, 19 Dec 2014 19:28:08 + (UTC) Paul Walmsley p...@pwsan.com wrote: Might you be willing to include this branch in your linux-next builds? git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending.git#for-next It will include OMAP clock, bus architecture, and low-level power management patches that are planned to be included in pull requests to the OMAP upstream maintainer, Tony Lindgren. He in turn will submit pull requests to the arm-soc tree. The objective in including this branch is to get these patches integration-tested earlier than they would be otherwise. Added from today (called omap and with you as the contact). Thanks for adding your subsystem tree as a participant of linux-next. As you may know, this is not a judgment of your code. The purpose of linux-next is for integration testing and to lower the impact of conflicts between subsystems in the next merge window. You will need to ensure that the patches/commits in your tree/series have been: * submitted under GPL v2 (or later) and include the Contributor's Signed-off-by, * posted to the relevant mailing list, * reviewed by you (or another maintainer of your subsystem tree), * successfully unit tested, and * destined for the current or next Linux merge window. Basically, this should be just what you would send to Linus (or ask him to fetch). It is allowed to be rebased if you deem it necessary. -- Cheers, Stephen Rothwell s...@canb.auug.org.au pgp4RiC3BC1JZ.pgp Description: OpenPGP digital signature
Re: linux-next: add the omap-pending tree
Hi Paul, On Fri, 26 Dec 2014 15:38:22 +1100 Stephen Rothwell s...@canb.auug.org.au wrote: On Fri, 19 Dec 2014 19:28:08 + (UTC) Paul Walmsley p...@pwsan.com wrote: Might you be willing to include this branch in your linux-next builds? git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending.git#for-next It will include OMAP clock, bus architecture, and low-level power management patches that are planned to be included in pull requests to the OMAP upstream maintainer, Tony Lindgren. He in turn will submit pull requests to the arm-soc tree. The objective in including this branch is to get these patches integration-tested earlier than they would be otherwise. Added from today (called omap and with you as the contact). Actually called omap-pending :-) -- Cheers, Stephen Rothwells...@canb.auug.org.au pgpDhgbeYcWtr.pgp Description: OpenPGP digital signature
Re: [PATCH] arm: omap: reduce zImage size on omap2plus_defconfig
Hi, On Thu, Dec 25, 2014 at 12:13:07PM +0200, Igor Grinberg wrote: Hi Tony, On 12/24/14 21:04, Tony Lindgren wrote: * Felipe Balbi ba...@ti.com [141224 07:52]: Hi, On Wed, Dec 24, 2014 at 01:53:46PM +0200, Igor Grinberg wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/23/14 18:19, Felipe Balbi wrote: On Tue, Dec 23, 2014 at 09:30:45AM +0200, Igor Grinberg wrote: Hi Felipe, On 12/22/14 20:05, Felipe Balbi wrote: [...] CONFIG_SCSI_SCAN_ASYNC=y -CONFIG_ATA=y -CONFIG_SATA_AHCI_PLATFORM=y -CONFIG_MD=y +CONFIG_ATA=m +CONFIG_SATA_AHCI_PLATFORM=m Isn't this needed for the rootfs on SATA devices? there's no known boards with rootfs on SATA. Until then, we can reduce the size. What makes you say so? The decision for rootfs on SATA is taken dynamically. OMAP5 boards (specifically cm-t54) can have rootfs on SATA... I'll leave the decision to Tony. Even though they _can_, they really don't and IIRC, OMAP5's SATA has so many silicon errata that it'd be annoying to find that special device which works (e.g it can't negotiate lower speeds with SATA III devices and it won't support SATA I). Yet, it is not that buggy and at least until now, I di not get any reports about badly working SATA from customers... As of today, we don't know of anybody really shipping anything with rootfs on SATA and distros would rather ship initiramfs than a giant zImage anyway. So, you just continue to ignore what I'm saying... even after I point to a device... you pointed a device which *can* have rootfs on SATA, not one which *has* rootfs on SATA, there's a very big difference there. Is it SATA that makes it so giant? Because I find it worth having in SATA than spare some more k's... that's your point of view. As Tony mentioned, we have a very standard way of dealing with this which is initramfs and x86 has been using that for the past 15+ years. Tony, your call. I think we should move omap2plus_defconfig to be mostly modular and usable for distros as a base. Most distros prefer to build almost everything as loadable modules. And my preference is that we should only keep the minimum rootfs for devices and serial support as built-in and rely on initramfs for most drivers. And slowly move also the remaining built-in drivers to be loadable modules. The reasons for having drivers as loadable modules are many. It allows distros to use the same kernel for all the devices without bloating the kernel. It makes developing drivers easier as just the module needs to be reloaded. And loadable modules protect us from cross-framework spaghetti calls in the kernel as the interfaces are clearly defined. Are there people really using SATA as rootfs right now on omaps? Yes. That is exactly my point. read your email, you said it *CAN* have rootfs on SATA. If it's only something that will be more widely used in the future, then I suggest we make it into a loadable module, and presume initramfs and loadable module also for any new devices. The same way x86 has been doing with distros for years. The difference from x86 is that we're in embedded here and bullshit, you would never ship a product with omap2plus_defconfig. You'd build your own at which point you would switch SATA to built-in. although initramfs is a kind of option, but it means, you need to load even more data during the boot process... it is annoying and I would not want to use it on embedded. make your own defconfig. (BTW, x86_64_defconfig has it compiled in...) We can also, split the defconfig as it was some time ago... but I would not want to go that direction... If we go the initramfs way, then why not also load MMC from it? That will also reduce kernel size... (but add initramfs size) I'm fine with that. The difference is that people have been relying on MMC built-in for the past 10+ years, since the old OMAP1 MMC driver, changing that now is likely to cause some my board won't boot anymore bug reports. I'm sure you will find making the MMC a loadable module inconvenient. That how I find making the SATA a loadable module... Right now, we tell our customers that they can use mainline with omap2plus_defconfig. that's the worst thing you can do. You should at a minimum provide your customers with a more minimal rootfs. Why would you have your customers build MUSB on an OMAP5 board ? Why would they build 5 different network device drivers ? Why would they build almost every single PMIC we ever used ? The list goes on and on. -- balbi signature.asc Description: Digital signature
Re: linux-next: add the omap-pending tree
Hi Tony, On Fri, 19 Dec 2014 12:02:30 -0800 Tony Lindgren t...@atomide.com wrote: Makes sense to me. The delay in getting omap stuff into Linux next via arm-soc for-next is just too long because of the large number of pending pull requests for various ARM SoCs. Maybe that requires a conversation with the arm-soc tree mailtainers ... While at it, can you please also (re-)add omap for-next too: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap.git#for-next Added from today (called omap with you as the contact). Thanks for adding your subsystem tree as a participant of linux-next. As you may know, this is not a judgment of your code. The purpose of linux-next is for integration testing and to lower the impact of conflicts between subsystems in the next merge window. You will need to ensure that the patches/commits in your tree/series have been: * submitted under GPL v2 (or later) and include the Contributor's Signed-off-by, * posted to the relevant mailing list, * reviewed by you (or another maintainer of your subsystem tree), * successfully unit tested, and * destined for the current or next Linux merge window. Basically, this should be just what you would send to Linus (or ask him to fetch). It is allowed to be rebased if you deem it necessary. -- Cheers, Stephen Rothwell s...@canb.auug.org.au pgp0B4RsFPBy4.pgp Description: OpenPGP digital signature
