[PATCH] ARM: OMAP2+: Warn about deprecated legacy booting mode

[PATCH] ARM: OMAP2+: Warn about deprecated legacy booting mode

[Tony Lindgren]

We're moving omaps to use device tree based booting and already have
omap2, omap4, omap5, am335x and am437x booting in device tree only
mode.

Only omap3 still has legacy booting still around and we really want
to make that device tree only. So let's add a warning about deprecated
legacy booting so we get people to upgrade their boards to use device
tree based booting and find out about any remaining issues.

Note that for most boards we already have the .dts file and those can
be booted with without changing the bootloader using the appended
DTB mode.

Signed-off-by: Tony Lindgren <tony@atomide.com>

--- a/arch/arm/mach-omap2/omap_device.c
+++ b/arch/arm/mach-omap2/omap_device.c
@@ -917,6 +917,10 @@ static int __init omap_device_late_idle(struct device *dev, void *data)
 static int __init omap_device_late_init(void)
 {
 	bus_for_each_dev(&platform_bus_type, NULL, NULL, omap_device_late_idle);
+
+	if (!of_have_populated_dt())
+		pr_warn("WARNING: legacy booting deprecated, please update to boot with .dts\n");
+
 	return 0;
 }
 omap_late_initcall_sync(omap_device_late_init);

[PATCH] ARM: OMAP2+: Warn about deprecated legacy booting mode

[Aaro Koskinen]

Hi,

On Mon, Oct 27, 2014 at 01:00:09PM -0700, Tony Lindgren wrote:
> +
> +	if (!of_have_populated_dt())
> +		pr_warn("WARNING: legacy booting deprecated, please update to boot with .dts\n");
> +

Maybe use WARN so that the warning is more verbose and kernel gets tainted?

A.

[PATCH] ARM: OMAP2+: Warn about deprecated legacy booting mode

[Tony Lindgren]

* Aaro Koskinen <aaro.koskinen@iki.fi> [141027 16:03]:
> Hi,
> 
> On Mon, Oct 27, 2014 at 01:00:09PM -0700, Tony Lindgren wrote:
> > +
> > +	if (!of_have_populated_dt())
> > +		pr_warn("WARNING: legacy booting deprecated, please update to boot with .dts\n");
> > +
> 
> Maybe use WARN so that the warning is more verbose and kernel gets tainted?

Well I was hoping to avoid annoying people with the trace.
But can do that if people prefer that, what do others think?

Regards,

Tony

[PATCH] ARM: OMAP2+: Warn about deprecated legacy booting mode

[Nishanth Menon]

On 10/28/2014 05:12 PM, Tony Lindgren wrote:
> * Aaro Koskinen <aaro.koskinen@iki.fi> [141027 16:03]:
>> Hi,
>>
>> On Mon, Oct 27, 2014 at 01:00:09PM -0700, Tony Lindgren wrote:
>>> +
>>> +	if (!of_have_populated_dt())
>>> +		pr_warn("WARNING: legacy booting deprecated, please update to boot with .dts\n");
>>> +
>>
>> Maybe use WARN so that the warning is more verbose and kernel gets tainted?
> 
> Well I was hoping to avoid annoying people with the trace.
> But can do that if people prefer that, what do others think?
> 

WARN is better and eye catchy. Also, could we add information on when
the support will be removed since we call it deprecated?


-- 
Regards,
Nishanth Menon

[PATCH] ARM: OMAP2+: Warn about deprecated legacy booting mode

[Sebastian Reichel]

Hi,

On Wed, Oct 29, 2014 at 08:43:03AM -0500, Nishanth Menon wrote:
> On 10/28/2014 05:12 PM, Tony Lindgren wrote:
> > * Aaro Koskinen <aaro.koskinen@iki.fi> [141027 16:03]:
> >> Hi,
> >>
> >> On Mon, Oct 27, 2014 at 01:00:09PM -0700, Tony Lindgren wrote:
> >>> +
> >>> +	if (!of_have_populated_dt())
> >>> +		pr_warn("WARNING: legacy booting deprecated, please update to boot with .dts\n");
> >>> +
> >>
> >> Maybe use WARN so that the warning is more verbose and kernel gets tainted?
> > 
> > Well I was hoping to avoid annoying people with the trace.
> > But can do that if people prefer that, what do others think?
> > 
> 
> WARN is better and eye catchy. Also, could we add information on when
> the support will be removed since we call it deprecated?

I also think, that more eye catchy is better.

Apart from that I wonder if we should drop support on a
board-by-board basis and then drop omap3 support completly once all
boards have been dropped.

-- Sebastian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20141029/5168a2d0/attachment.sig>

[PATCH] ARM: OMAP2+: Warn about deprecated legacy booting mode

[Tony Lindgren]

* Sebastian Reichel <sre@ring0.de> [141029 12:01]:
> Hi,
> 
> On Wed, Oct 29, 2014 at 08:43:03AM -0500, Nishanth Menon wrote:
> > On 10/28/2014 05:12 PM, Tony Lindgren wrote:
> > > * Aaro Koskinen <aaro.koskinen@iki.fi> [141027 16:03]:
> > >> Hi,
> > >>
> > >> On Mon, Oct 27, 2014 at 01:00:09PM -0700, Tony Lindgren wrote:
> > >>> +
> > >>> +	if (!of_have_populated_dt())
> > >>> +		pr_warn("WARNING: legacy booting deprecated, please update to boot with .dts\n");
> > >>> +
> > >>
> > >> Maybe use WARN so that the warning is more verbose and kernel gets tainted?
> > > 
> > > Well I was hoping to avoid annoying people with the trace.
> > > But can do that if people prefer that, what do others think?
> > > 
> > 
> > WARN is better and eye catchy. Also, could we add information on when
> > the support will be removed since we call it deprecated?

Well quoting the hostage situation from a Mr. Show episode
"Now Who Wants Ice Cream?" the answer to that would be:

OK, you want me to guess? A hundred million days, or maybe ten more
minutes, somewhere in there, I just can't say, don't know.
 
> I also think, that more eye catchy is better.

OK, updated patch below. I'd like to add this to the current
-rc cycle unless people have objections to that.
 
> Apart from that I wonder if we should drop support on a
> board-by-board basis and then drop omap3 support completly once all
> boards have been dropped.

Yes. I'll post few patches from my old board removal branch at
omap-for-v3.14/omap3-board-removal shortly.

Regards,

Tony

8< -----------------------
From: Tony Lindgren <tony@atomide.com>
Date: Mon, 27 Oct 2014 13:05:54 -0700
Subject: [PATCH] ARM: OMAP2+: Warn about deprecated legacy booting mode

We're moving omaps to use device tree based booting and already have
omap2, omap4, omap5, am335x and am437x booting in device tree only
mode.

Only omap3 still has legacy booting still around and we really want
to make that device tree only. So let's add a warning about deprecated
legacy booting so we get people to upgrade their boards to use device
tree based booting and find out about any remaining issues.

Note that for most boards we already have the .dts file and those can
be booted with without changing the bootloader using the appended
DTB mode.

Signed-off-by: Tony Lindgren <tony@atomide.com>

--- a/arch/arm/mach-omap2/omap_device.c
+++ b/arch/arm/mach-omap2/omap_device.c
@@ -917,6 +917,10 @@ static int __init omap_device_late_idle(struct device *dev, void *data)
 static int __init omap_device_late_init(void)
 {
 	bus_for_each_dev(&platform_bus_type, NULL, NULL, omap_device_late_idle);
+
+	WARN(!of_have_populated_dt(),
+		"legacy booting deprecated, please update to boot with .dts\n");
+
 	return 0;
 }
 omap_late_initcall_sync(omap_device_late_init);

[PATCH] ARM: OMAP2+: Warn about deprecated legacy booting mode

[Nishanth Menon]

On 12:39-20141029, Tony Lindgren wrote:
> * Sebastian Reichel <sre@ring0.de> [141029 12:01]:
> > Hi,
> > 
> > On Wed, Oct 29, 2014 at 08:43:03AM -0500, Nishanth Menon wrote:
> > > On 10/28/2014 05:12 PM, Tony Lindgren wrote:
> > > > * Aaro Koskinen <aaro.koskinen@iki.fi> [141027 16:03]:
> > > >> Hi,
> > > >>
> > > >> On Mon, Oct 27, 2014 at 01:00:09PM -0700, Tony Lindgren wrote:
> > > >>> +
> > > >>> +	if (!of_have_populated_dt())
> > > >>> +		pr_warn("WARNING: legacy booting deprecated, please update to boot with .dts\n");
> > > >>> +
> > > >>
> > > >> Maybe use WARN so that the warning is more verbose and kernel gets tainted?
> > > > 
> > > > Well I was hoping to avoid annoying people with the trace.
> > > > But can do that if people prefer that, what do others think?
> > > > 
> > > 
> > > WARN is better and eye catchy. Also, could we add information on when
> > > the support will be removed since we call it deprecated?
> 
> Well quoting the hostage situation from a Mr. Show episode
> "Now Who Wants Ice Cream?" the answer to that would be:
> 
> OK, you want me to guess? A hundred million days, or maybe ten more
> minutes, somewhere in there, I just can't say, don't know.

How about ~1 year? We have been talking about dt only boot for over an
year already... Can we say 3.22 kernel, platforms that are not converted
to device tree only loose legacy boot support. 

-- 
Regards,
Nishanth Menon

[PATCH] ARM: OMAP2+: Warn about deprecated legacy booting mode

[Tony Lindgren]

* Nishanth Menon <nm@ti.com> [141029 14:47]:
> On 12:39-20141029, Tony Lindgren wrote:
> > * Sebastian Reichel <sre@ring0.de> [141029 12:01]:
> > > Hi,
> > > 
> > > On Wed, Oct 29, 2014 at 08:43:03AM -0500, Nishanth Menon wrote:
> > > > On 10/28/2014 05:12 PM, Tony Lindgren wrote:
> > > > > * Aaro Koskinen <aaro.koskinen@iki.fi> [141027 16:03]:
> > > > >> Hi,
> > > > >>
> > > > >> On Mon, Oct 27, 2014 at 01:00:09PM -0700, Tony Lindgren wrote:
> > > > >>> +
> > > > >>> +	if (!of_have_populated_dt())
> > > > >>> +		pr_warn("WARNING: legacy booting deprecated, please update to boot with .dts\n");
> > > > >>> +
> > > > >>
> > > > >> Maybe use WARN so that the warning is more verbose and kernel gets tainted?
> > > > > 
> > > > > Well I was hoping to avoid annoying people with the trace.
> > > > > But can do that if people prefer that, what do others think?
> > > > > 
> > > > 
> > > > WARN is better and eye catchy. Also, could we add information on when
> > > > the support will be removed since we call it deprecated?
> > 
> > Well quoting the hostage situation from a Mr. Show episode
> > "Now Who Wants Ice Cream?" the answer to that would be:
> > 
> > OK, you want me to guess? A hundred million days, or maybe ten more
> > minutes, somewhere in there, I just can't say, don't know.
> 
> How about ~1 year? We have been talking about dt only boot for over an
> year already... Can we say 3.22 kernel, platforms that are not converted
> to device tree only loose legacy boot support. 

I'm hoping we can make it faster let's say over next two merge
windows. Pretty much everything already works with device tree
booting so now it's just a question of getting people to start
using it and fix whatever issues we may encounter.

Regards,

Tony

[PATCH] ARM: OMAP2+: Warn about deprecated legacy booting mode

[Aaro Koskinen]

On Wed, Oct 29, 2014 at 04:45:41PM -0500, Nishanth Menon wrote:
> On 12:39-20141029, Tony Lindgren wrote:
> > OK, you want me to guess? A hundred million days, or maybe ten more
> > minutes, somewhere in there, I just can't say, don't know.
> 
> How about ~1 year? We have been talking about dt only boot for over an
> year already... Can we say 3.22 kernel, platforms that are not converted
> to device tree only loose legacy boot support. 

If you want to define some date, it should be a calendar date instead
of some kernel version based on guesswork (you cannot really predict
the kernel versions for future, just remember the 2.6.39 -> 3.0 change).

Also, you cannot expect all kernel users to know what you have been
talking about. E.g. OMAP DMA API deprecation may have been discussed
before, but I only learned it after the WARN appeared in the kernel tree.
So you should start counting from that.

Personally I don't mind if you delete OMAP3 legacy boot support already
tomorrow morning, but if you want to give ~1 year transition period it
should end somewhere in the end of 2015. Of course if there are no legacy
boot users you can do it faster.

A.

[PATCH] ARM: OMAP2+: Warn about deprecated legacy booting mode

[Sebastian Reichel]

Hi,

On Wed, Oct 29, 2014 at 12:39:16PM -0700, Tony Lindgren wrote:
> 8< -----------------------
> From: Tony Lindgren <tony@atomide.com>
> Date: Mon, 27 Oct 2014 13:05:54 -0700
> Subject: [PATCH] ARM: OMAP2+: Warn about deprecated legacy booting mode
> 
> We're moving omaps to use device tree based booting and already have
> omap2, omap4, omap5, am335x and am437x booting in device tree only
> mode.
> 
> Only omap3 still has legacy booting still around and we really want
> to make that device tree only. So let's add a warning about deprecated
> legacy booting so we get people to upgrade their boards to use device
> tree based booting and find out about any remaining issues.
> 
> Note that for most boards we already have the .dts file and those can
> be booted with without changing the bootloader using the appended
> DTB mode.
> 
> Signed-off-by: Tony Lindgren <tony@atomide.com>
> 
> --- a/arch/arm/mach-omap2/omap_device.c
> +++ b/arch/arm/mach-omap2/omap_device.c
> @@ -917,6 +917,10 @@ static int __init omap_device_late_idle(struct device *dev, void *data)
>  static int __init omap_device_late_init(void)
>  {
>  	bus_for_each_dev(&platform_bus_type, NULL, NULL, omap_device_late_idle);
> +
> +	WARN(!of_have_populated_dt(),
> +		"legacy booting deprecated, please update to boot with .dts\n");
> +
>  	return 0;
>  }
>  omap_late_initcall_sync(omap_device_late_init);

Acked-By: Sebastian Reichel <sre@kernel.org>

-- Sebastian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20141030/5df331c3/attachment.sig>

[PATCH] ARM: OMAP2+: Warn about deprecated legacy booting mode

[Aaro Koskinen]

On Wed, Oct 29, 2014 at 12:39:16PM -0700, Tony Lindgren wrote:
> From: Tony Lindgren <tony@atomide.com>
> Date: Mon, 27 Oct 2014 13:05:54 -0700
> Subject: [PATCH] ARM: OMAP2+: Warn about deprecated legacy booting mode
> 
> We're moving omaps to use device tree based booting and already have
> omap2, omap4, omap5, am335x and am437x booting in device tree only
> mode.
> 
> Only omap3 still has legacy booting still around and we really want
> to make that device tree only. So let's add a warning about deprecated
> legacy booting so we get people to upgrade their boards to use device
> tree based booting and find out about any remaining issues.
> 
> Note that for most boards we already have the .dts file and those can
> be booted with without changing the bootloader using the appended
> DTB mode.
> 
> Signed-off-by: Tony Lindgren <tony@atomide.com>

Reviewed-by: Aaro Koskinen <aaro.koskinen@iki.fi>

> --- a/arch/arm/mach-omap2/omap_device.c
> +++ b/arch/arm/mach-omap2/omap_device.c
> @@ -917,6 +917,10 @@ static int __init omap_device_late_idle(struct device *dev, void *data)
>  static int __init omap_device_late_init(void)
>  {
>  	bus_for_each_dev(&platform_bus_type, NULL, NULL, omap_device_late_idle);
> +
> +	WARN(!of_have_populated_dt(),
> +		"legacy booting deprecated, please update to boot with .dts\n");
> +
>  	return 0;
>  }
>  omap_late_initcall_sync(omap_device_late_init);

[PATCH] ARM: OMAP2+: Warn about deprecated legacy booting mode

[Javier Martinez Canillas]

Hello Tony,

On Thu, Oct 30, 2014 at 12:11 AM, Aaro Koskinen <aaro.koskinen@iki.fi> wrote:
> On Wed, Oct 29, 2014 at 12:39:16PM -0700, Tony Lindgren wrote:
>> From: Tony Lindgren <tony@atomide.com>
>> Date: Mon, 27 Oct 2014 13:05:54 -0700
>> Subject: [PATCH] ARM: OMAP2+: Warn about deprecated legacy booting mode
>>
>> We're moving omaps to use device tree based booting and already have
>> omap2, omap4, omap5, am335x and am437x booting in device tree only
>> mode.
>>
>> Only omap3 still has legacy booting still around and we really want
>> to make that device tree only. So let's add a warning about deprecated
>> legacy booting so we get people to upgrade their boards to use device
>> tree based booting and find out about any remaining issues.
>>
>> Note that for most boards we already have the .dts file and those can
>> be booted with without changing the bootloader using the appended
>> DTB mode.
>>
>> Signed-off-by: Tony Lindgren <tony@atomide.com>
>
> Reviewed-by: Aaro Koskinen <aaro.koskinen@iki.fi>
>

Reviewed-by: Javier Martinez Canillas <javier@dowhile0.org>

Best regards,
Javier

[PATCH] ARM: OMAP2+: Warn about deprecated legacy booting mode

[Nishanth Menon]

On 10/29/2014 05:31 PM, Aaro Koskinen wrote:
> Also, you cannot expect all kernel users to know what you have been
> talking about. E.g. OMAP DMA API deprecation may have been discussed
> before, but I only learned it after the WARN appeared in the kernel tree.
> So you should start counting from that.
>
> Personally I don't mind if you delete OMAP3 legacy boot support already
> tomorrow morning, but if you want to give ~1 year transition period it
> should end somewhere in the end of 2015. Of course if there are no legacy
> boot users you can do it faster.

How about the following?

>
> +	WARN(!of_have_populated_dt(),
> +		"legacy booting deprecated(proposed removal in December 2015), please update to boot with .dts\n");
> +

Regards,
Nishanth Menon

[PATCH] ARM: OMAP2+: Warn about deprecated legacy booting mode

[Russell King - ARM Linux]

On Mon, Oct 27, 2014 at 01:00:09PM -0700, Tony Lindgren wrote:
> We're moving omaps to use device tree based booting and already have
> omap2, omap4, omap5, am335x and am437x booting in device tree only
> mode.
> 
> Only omap3 still has legacy booting still around and we really want
> to make that device tree only. So let's add a warning about deprecated
> legacy booting so we get people to upgrade their boards to use device
> tree based booting and find out about any remaining issues.
> 
> Note that for most boards we already have the .dts file and those can
> be booted with without changing the bootloader using the appended
> DTB mode.

Tony,

Last night I tried enabling DT booting on the LDP.  This resulted in
quite a horrid mess, so I don't think you're there still.

The biggest problem seems to be that the kernel does /nothing/ but
spit out:

power_supply twl4030_ac: driver failed to report `current_now' property: -850000
power_supply twl4030_ac: driver failed to report `current_now' property: -850000
twl4030_bci bci.7: battery disconnected
twl4030_bci bci.7: battery disconnected
power_supply twl4030_ac: driver failed to report `current_now' property: -850000
twl4030_bci bci.7: battery disconnected
power_supply twl4030_ac: driver failed to report `current_now' property: -850000
twl4030_bci bci.7: battery disconnected
twl4030_bci bci.7: battery disconnected
power_supply twl4030_ac: driver failed to report `current_now' property: -850000
twl4030_bci bci.7: battery disconnected
power_supply twl4030_ac: driver failed to report `current_now' property: -850000
twl4030_bci bci.7: battery disconnected
power_supply twl4030_ac: driver failed to report `current_now' property: -850000
twl4030_bci bci.7: battery disconnected
power_supply twl4030_ac: driver failed to report `current_now' property: -850000
twl4030_bci bci.7: battery disconnected
power_supply twl4030_ac: driver failed to report `current_now' property: -850000
twl4030_bci bci.7: battery disconnected
twl4030_bci bci.7: battery disconnected

Yes, the battery is disconnected, but there's absolutely no reason to keep
printing that damned warning time and time again.  The boot logger didn't
expect this, and it's logged about 16 hours of these continual messages
into the database... that's around 1.4GB of log!

Other errors:

omap_hwmod: mcbsp2_sidetone using broken dt data from mcbsp
omap_hwmod: mcbsp3_sidetone using broken dt data from mcbsp

WARNING: CPU: 0 PID: 1 at arch/arm/mach-omap2/omap_hwmod.c:2538 _init+0xc8/0x170()
omap_hwmod: ssi: doesn't have mpu register target base
...
omap_hwmod: usb_host_hs: could not associate to clkdm l3_init_clkdm
omap_hwmod: usb_tll_hs: could not associate to clkdm l3_init_clkdm
omap_hwmod: mcbsp2: cannot be enabled for reset (3)
...
twl4030_keypad keypad.31: OF: linux,keymap property not defined in /ocp/i2c at 48070000/twl at 48/keypad
twl4030_keypad keypad.31: Failed to build keymap
twl4030_keypad: probe of keypad.31 failed with error -2

Digging the remaining messages out from between all the crap about the
battery:

4809c000.mmc supply vmmc_aux not found, using dummy regulator
omap_hsmmc 4809c000.mmc: pins are not configured from the driver
4809c000.mmc supply card-external-vcc not found, using dummy regulator
480b4000.mmc supply vmmc not found, using dummy regulator
480b4000.mmc supply vmmc_aux not found, using dummy regulator
omap_hsmmc 480b4000.mmc: pins are not configured from the driver
mmc0: host does not support reading read-only switch. assuming write-enable.
480b4000.mmc supply card-external-vcc not found, using dummy regulator
mmc0: new high speed SD card at address 0002
mmcblk0: mmc0:0002 00000 971 MiB
omap_hsmmc 480b4000.mmc: could not set regulator OCR (-22)
480ad000.mmc supply vmmc not found, using dummy regulator
480ad000.mmc supply vmmc_aux not found, using dummy regulator
omap_hsmmc 480ad000.mmc: could not set regulator OCR (-22)
 mmcblk0: p1 p2
omap_hsmmc 480ad000.mmc: pins are not configured from the driver
mmcblk0: error -84 transferring data, sector 1473761, nr 32, cmd response 0x900, card status 0xb00
mmcblk0: retrying using single block read
mmcblk0: error -84 transferring data, sector 426249, nr 32, cmd response 0x900, card status 0xb00
mmcblk0: retrying using single block read
mmcblk0: error -84 transferring data, sector 1525321, nr 192, cmd response 0x900, card status 0xb00
mmcblk0: retrying using single block read
... etc ...

Of course, no problems with exactly the same kernel binary image without
DT.  I'd summarise this as DT remains totally unusable on LDP3430.  It's
soo unusable that it is going to /force/ me to take it out of the nightly
boot test, otherwise I'm going to have to manually intervene each and
every morning to kill the board.

-- 
FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up
according to speedtest.net.

[PATCH] ARM: OMAP2+: Warn about deprecated legacy booting mode

[Tony Lindgren]

* Russell King - ARM Linux <linux@arm.linux.org.uk> [141031 12:32]:
> 
> Last night I tried enabling DT booting on the LDP.  This resulted in
> quite a horrid mess, so I don't think you're there still.

Thanks for trying. Other than the mystery battery issue, the others
should pretty much go away with just .config changes it seems.

> The biggest problem seems to be that the kernel does /nothing/ but
> spit out:
> 
> power_supply twl4030_ac: driver failed to report `current_now' property: -850000
> power_supply twl4030_ac: driver failed to report `current_now' property: -850000
> twl4030_bci bci.7: battery disconnected
> twl4030_bci bci.7: battery disconnected
> power_supply twl4030_ac: driver failed to report `current_now' property: -850000
> twl4030_bci bci.7: battery disconnected
> power_supply twl4030_ac: driver failed to report `current_now' property: -850000
> twl4030_bci bci.7: battery disconnected
> twl4030_bci bci.7: battery disconnected
> power_supply twl4030_ac: driver failed to report `current_now' property: -850000
> twl4030_bci bci.7: battery disconnected
> power_supply twl4030_ac: driver failed to report `current_now' property: -850000
> twl4030_bci bci.7: battery disconnected
> power_supply twl4030_ac: driver failed to report `current_now' property: -850000
> twl4030_bci bci.7: battery disconnected
> power_supply twl4030_ac: driver failed to report `current_now' property: -850000
> twl4030_bci bci.7: battery disconnected
> power_supply twl4030_ac: driver failed to report `current_now' property: -850000
> twl4030_bci bci.7: battery disconnected
> twl4030_bci bci.7: battery disconnected
> 
> Yes, the battery is disconnected, but there's absolutely no reason to keep
> printing that damned warning time and time again.  The boot logger didn't
> expect this, and it's logged about 16 hours of these continual messages
> into the database... that's around 1.4GB of log!

Hmm, I thought Nishant fixed that already with commit 61a7784efd3
"power: twl4030_charger: detect battery presence prior to enabling
charger".

I'm not seeing these errors with twl4030_charger built in. For me it just
bails out without a battery like it should:

twl4030_bci 48070000.i2c:twl at 48:bci: Battery was not detected:-19

Nishant, any ideas on this one?
 
> Other errors:
> 
> omap_hwmod: mcbsp2_sidetone using broken dt data from mcbsp
> omap_hwmod: mcbsp3_sidetone using broken dt data from mcbsp

This is a known issue with data for multiple devices squashed
into one in the .dts files.

Peter, any news on fixing up this issue? I think you promised to
look at it already a while back :)

> WARNING: CPU: 0 PID: 1 at arch/arm/mach-omap2/omap_hwmod.c:2538 _init+0xc8/0x170()
> omap_hwmod: ssi: doesn't have mpu register target base
> ...

Not seeing this one, is this maybe from the legacy mode boot?

> omap_hwmod: usb_host_hs: could not associate to clkdm l3_init_clkdm
> omap_hwmod: usb_tll_hs: could not associate to clkdm l3_init_clkdm

Not seeing these either. Is this maybe from your 4430sdp instead?

> omap_hwmod: mcbsp2: cannot be enabled for reset (3)

This I'm seeing too, will take a look at this one.

> twl4030_keypad keypad.31: OF: linux,keymap property not defined in /ocp/i2c at 48070000/twl at 48/keypad
> twl4030_keypad keypad.31: Failed to build keymap
> twl4030_keypad: probe of keypad.31 failed with error -2

I'll take a look at this one as we now have a binding for
twl4030_keypad. Probably just missing the keymap in the .dts
file. The gpio keys should work though.
 
> Digging the remaining messages out from between all the crap about the
> battery:
> 
> 4809c000.mmc supply vmmc_aux not found, using dummy regulator
> omap_hsmmc 4809c000.mmc: pins are not configured from the driver
> 4809c000.mmc supply card-external-vcc not found, using dummy regulator
> 480b4000.mmc supply vmmc not found, using dummy regulator
> 480b4000.mmc supply vmmc_aux not found, using dummy regulator
> omap_hsmmc 480b4000.mmc: pins are not configured from the driver
> mmc0: host does not support reading read-only switch. assuming write-enable.
> 480b4000.mmc supply card-external-vcc not found, using dummy regulator

Not seeing this with my LDP. I think you're probably missing:
CONFIG_REGULATOR_TWL4030
CONFIG_REGULATOR_PBIAS

> mmc0: new high speed SD card at address 0002
> mmcblk0: mmc0:0002 00000 971 MiB
> omap_hsmmc 480b4000.mmc: could not set regulator OCR (-22)
> 480ad000.mmc supply vmmc not found, using dummy regulator
> 480ad000.mmc supply vmmc_aux not found, using dummy regulator
> omap_hsmmc 480ad000.mmc: could not set regulator OCR (-22)
>  mmcblk0: p1 p2
> omap_hsmmc 480ad000.mmc: pins are not configured from the driver
> mmcblk0: error -84 transferring data, sector 1473761, nr 32, cmd response 0x900, card status 0xb00
> mmcblk0: retrying using single block read
> mmcblk0: error -84 transferring data, sector 426249, nr 32, cmd response 0x900, card status 0xb00
> mmcblk0: retrying using single block read
> mmcblk0: error -84 transferring data, sector 1525321, nr 192, cmd response 0x900, card status 0xb00
> mmcblk0: retrying using single block read
> ... etc ...

I'm not seeing this one either on my LDP. I'm getting just one warning
"multiblock reads disabled due to 35xx erratum 2.1.1.128"
but the card works just fine here with no errors. I'd assume these go
away with enabling the regulators above.
 
> Of course, no problems with exactly the same kernel binary image without
> DT.  I'd summarise this as DT remains totally unusable on LDP3430.  It's
> soo unusable that it is going to /force/ me to take it out of the nightly
> boot test, otherwise I'm going to have to manually intervene each and
> every morning to kill the board.

The LDP is certainly usable here with device tree based booting.

It seems you're probably missing some .config options. Care to post
your .config somewhere? Or maybe give it a try with omap2plus_defconfig?

If that works, then maybe enable CONFIG_CHARGER_TWL4030=y in
omap2plus_defconfig and see if you get the battery issue with it too?

Regards,

Tony

[PATCH] ARM: OMAP2+: Warn about deprecated legacy booting mode

[Tony Lindgren]

* Tony Lindgren <tony@atomide.com> [141031 14:16]:
> * Russell King - ARM Linux <linux@arm.linux.org.uk> [141031 12:32]:
> > 
> > Last night I tried enabling DT booting on the LDP.  This resulted in
> > quite a horrid mess, so I don't think you're there still.
> 
> Thanks for trying. Other than the mystery battery issue, the others
> should pretty much go away with just .config changes it seems.

To dt-fy your .config, looks like you need to add these to your build
system seed config file:

CONFIG_BACKLIGHT_CLASS_DEVICE=y
CONFIG_BACKLIGHT_GPIO=y
CONFIG_BACKLIGHT_LCD_SUPPORT=y
CONFIG_CMA=y
CONFIG_DISPLAY_PANEL_SHARP_LS037V7DW01=y
CONFIG_DMA_CMA=y
CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY=y
CONFIG_FRAMEBUFFER_CONSOLE=y
CONFIG_PINCTRL_SINGLE=y

That should actually improve your setup from the current booting
with the framebuffer enabled ;)

I also posted the defconfig and demsg for you to diff against to:

http://muru.com/for-rmk/

I wonder if the battery charger hardware is broken on your LDP?

I don't think that is even being enabled in the legacy boot for
LDP as it as there's no struct twl4030_bci being passed except
from board-omap3pandora.c.

Regards,

Tony

[PATCH] ARM: OMAP2+: Warn about deprecated legacy booting mode

[Russell King - ARM Linux]

On Fri, Oct 31, 2014 at 02:13:26PM -0700, Tony Lindgren wrote:
> * Russell King - ARM Linux <linux@arm.linux.org.uk> [141031 12:32]:
> > 
> > Last night I tried enabling DT booting on the LDP.  This resulted in
> > quite a horrid mess, so I don't think you're there still.
> 
> Thanks for trying. Other than the mystery battery issue, the others
> should pretty much go away with just .config changes it seems.
> 
> > The biggest problem seems to be that the kernel does /nothing/ but
> > spit out:
> > 
> > power_supply twl4030_ac: driver failed to report `current_now' property: -850000
> > power_supply twl4030_ac: driver failed to report `current_now' property: -850000
> > twl4030_bci bci.7: battery disconnected
> > twl4030_bci bci.7: battery disconnected
> > power_supply twl4030_ac: driver failed to report `current_now' property: -850000
> > twl4030_bci bci.7: battery disconnected
> > power_supply twl4030_ac: driver failed to report `current_now' property: -850000
> > twl4030_bci bci.7: battery disconnected
> > twl4030_bci bci.7: battery disconnected
> > power_supply twl4030_ac: driver failed to report `current_now' property: -850000
> > twl4030_bci bci.7: battery disconnected
> > power_supply twl4030_ac: driver failed to report `current_now' property: -850000
> > twl4030_bci bci.7: battery disconnected
> > power_supply twl4030_ac: driver failed to report `current_now' property: -850000
> > twl4030_bci bci.7: battery disconnected
> > power_supply twl4030_ac: driver failed to report `current_now' property: -850000
> > twl4030_bci bci.7: battery disconnected
> > power_supply twl4030_ac: driver failed to report `current_now' property: -850000
> > twl4030_bci bci.7: battery disconnected
> > twl4030_bci bci.7: battery disconnected
> > 
> > Yes, the battery is disconnected, but there's absolutely no reason to keep
> > printing that damned warning time and time again.  The boot logger didn't
> > expect this, and it's logged about 16 hours of these continual messages
> > into the database... that's around 1.4GB of log!
> 
> Hmm, I thought Nishant fixed that already with commit 61a7784efd3
> "power: twl4030_charger: detect battery presence prior to enabling
> charger".
> 
> I'm not seeing these errors with twl4030_charger built in. For me it just
> bails out without a battery like it should:
> 
> twl4030_bci 48070000.i2c:twl at 48:bci: Battery was not detected:-19
> 
> Nishant, any ideas on this one?
>  
> > Other errors:
> > 
> > omap_hwmod: mcbsp2_sidetone using broken dt data from mcbsp
> > omap_hwmod: mcbsp3_sidetone using broken dt data from mcbsp
> 
> This is a known issue with data for multiple devices squashed
> into one in the .dts files.
> 
> Peter, any news on fixing up this issue? I think you promised to
> look at it already a while back :)
> 
> > WARNING: CPU: 0 PID: 1 at arch/arm/mach-omap2/omap_hwmod.c:2538 _init+0xc8/0x170()
> > omap_hwmod: ssi: doesn't have mpu register target base
> > ...
> 
> Not seeing this one, is this maybe from the legacy mode boot?
> 
> > omap_hwmod: usb_host_hs: could not associate to clkdm l3_init_clkdm
> > omap_hwmod: usb_tll_hs: could not associate to clkdm l3_init_clkdm
> 
> Not seeing these either. Is this maybe from your 4430sdp instead?

This is /all/ from the 3430 LDP.

Compare these two URLs:

http://www.arm.linux.org.uk/developer/build/result.php?type=boot&idx=2891
http://www.arm.linux.org.uk/developer/build/result.php?type=boot&idx=2892

Beware - the second one will be truncated to 1MB of log (but with the
regexp extraction of errors, it's probably going to be more like 2MB.)

Both of those are booting the _exact_ same kernel binary.  The difference
between them is that the first (2891) is booted in legacy mode.  The
second (2892) is booted with omap3-ldp.dtb appended to the zImage and
wrapped in a uImage.

There is only one config file for these two boots, because as I say, it's
the exact same binary booted in legacy mode, then booted in DT mode.

config: http://www.arm.linux.org.uk/developer/build/file.php?lid=17226

> > omap_hwmod: mcbsp2: cannot be enabled for reset (3)
> 
> This I'm seeing too, will take a look at this one.
> 
> > twl4030_keypad keypad.31: OF: linux,keymap property not defined in /ocp/i2c at 48070000/twl at 48/keypad
> > twl4030_keypad keypad.31: Failed to build keymap
> > twl4030_keypad: probe of keypad.31 failed with error -2
> 
> I'll take a look at this one as we now have a binding for
> twl4030_keypad. Probably just missing the keymap in the .dts
> file. The gpio keys should work though.
>  
> > Digging the remaining messages out from between all the crap about the
> > battery:
> > 
> > 4809c000.mmc supply vmmc_aux not found, using dummy regulator
> > omap_hsmmc 4809c000.mmc: pins are not configured from the driver
> > 4809c000.mmc supply card-external-vcc not found, using dummy regulator
> > 480b4000.mmc supply vmmc not found, using dummy regulator
> > 480b4000.mmc supply vmmc_aux not found, using dummy regulator
> > omap_hsmmc 480b4000.mmc: pins are not configured from the driver
> > mmc0: host does not support reading read-only switch. assuming write-enable.
> > 480b4000.mmc supply card-external-vcc not found, using dummy regulator
> 
> Not seeing this with my LDP. I think you're probably missing:
> CONFIG_REGULATOR_TWL4030
> CONFIG_REGULATOR_PBIAS

As you will see from the above link, I have:

CONFIG_REGULATOR_TWL4030=y

but not REGULATOR_PBIAS - because MFD_SYSCON is not set.

> > mmc0: new high speed SD card at address 0002
> > mmcblk0: mmc0:0002 00000 971 MiB
> > omap_hsmmc 480b4000.mmc: could not set regulator OCR (-22)
> > 480ad000.mmc supply vmmc not found, using dummy regulator
> > 480ad000.mmc supply vmmc_aux not found, using dummy regulator
> > omap_hsmmc 480ad000.mmc: could not set regulator OCR (-22)
> >  mmcblk0: p1 p2
> > omap_hsmmc 480ad000.mmc: pins are not configured from the driver
> > mmcblk0: error -84 transferring data, sector 1473761, nr 32, cmd response 0x900, card status 0xb00
> > mmcblk0: retrying using single block read
> > mmcblk0: error -84 transferring data, sector 426249, nr 32, cmd response 0x900, card status 0xb00
> > mmcblk0: retrying using single block read
> > mmcblk0: error -84 transferring data, sector 1525321, nr 192, cmd response 0x900, card status 0xb00
> > mmcblk0: retrying using single block read
> > ... etc ...
> 
> I'm not seeing this one either on my LDP. I'm getting just one warning
> "multiblock reads disabled due to 35xx erratum 2.1.1.128"
> but the card works just fine here with no errors. I'd assume these go
> away with enabling the regulators above.

Or it could be that the amount of crap being spewed by the battery driver
is messing up the dodgy MMC.

> > Of course, no problems with exactly the same kernel binary image without
> > DT.  I'd summarise this as DT remains totally unusable on LDP3430.  It's
> > soo unusable that it is going to /force/ me to take it out of the nightly
> > boot test, otherwise I'm going to have to manually intervene each and
> > every morning to kill the board.
> 
> The LDP is certainly usable here with device tree based booting.
> 
> It seems you're probably missing some .config options. Care to post
> your .config somewhere? Or maybe give it a try with omap2plus_defconfig?

I'm not trying with omap2plus_defconfig as this is supposed to be a
separate build.  Given that - as I say - the /exact/ same kernel binary
works in legacy mode, it suggests that there's some pretty major
differences between what devices are supported in a legacy boot mode
and what devices are supported in DT boot mode.

> If that works, then maybe enable CONFIG_CHARGER_TWL4030=y in
> omap2plus_defconfig and see if you get the battery issue with it too?

I do have that option enabled.

I really /can't/ risk letting the platform boot again in DT mode having
just played around with some options - if it spews like it did again
last night, it'll spew for the whole day tomorrow, and I really don't
want the database filling up with another gigabyte of log.

I'll see about tweaking some of those options, but it'll have to be a
manual run sometime next week to test it.

-- 
FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up
according to speedtest.net.

[PATCH] ARM: OMAP2+: Warn about deprecated legacy booting mode

[Tony Lindgren]

* Russell King - ARM Linux <linux@arm.linux.org.uk> [141031 15:35]:
> On Fri, Oct 31, 2014 at 02:13:26PM -0700, Tony Lindgren wrote:
> > * Russell King - ARM Linux <linux@arm.linux.org.uk> [141031 12:32]:
> > 
> > > WARNING: CPU: 0 PID: 1 at arch/arm/mach-omap2/omap_hwmod.c:2538 _init+0xc8/0x170()
> > > omap_hwmod: ssi: doesn't have mpu register target base
> > > ...
> > 
> > Not seeing this one, is this maybe from the legacy mode boot?
> > 
> > > omap_hwmod: usb_host_hs: could not associate to clkdm l3_init_clkdm
> > > omap_hwmod: usb_tll_hs: could not associate to clkdm l3_init_clkdm
> > 
> > Not seeing these either. Is this maybe from your 4430sdp instead?
> 
> This is /all/ from the 3430 LDP.
> 
> Compare these two URLs:
> 
> http://www.arm.linux.org.uk/developer/build/result.php?type=boot&idx=2891
> http://www.arm.linux.org.uk/developer/build/result.php?type=boot&idx=2892

Not able to load the second one because of the broken battery
driver :)

But based on the link above I can see that you're mixing in both
legacy mode warnings and DT mode warnings at least for the SSI,
so that explains why I'm not seeing the SSI error.

Still no idea where the l3_init_clkdm errors come from, are they
from your huge log?

Like I posted in this thread, I'm not seeing same errors as you are
with your config modified for DT:

http://muru.com/for-rmk/dmesg-ldp-dt-v3.18-rc2
 
> I'm not trying with omap2plus_defconfig as this is supposed to be a
> separate build.  Given that - as I say - the /exact/ same kernel binary
> works in legacy mode, it suggests that there's some pretty major
> differences between what devices are supported in a legacy boot mode
> and what devices are supported in DT boot mode.

Sure no problem. Your .config works just fine for me in DT mode
with the the options enabled like I posted in this thread.
 
> I really /can't/ risk letting the platform boot again in DT mode having
> just played around with some options - if it spews like it did again
> last night, it'll spew for the whole day tomorrow, and I really don't
> want the database filling up with another gigabyte of log.

Looks like the twl4030_charger.c driver just does printk in the irq
handler for errors :) I'm almost certain you'd get the same errors
in legacy mode too if board-ldp.c passed the platform_data to the
battery driver.. No ideas why the battery detection during probe
won't work for your hardware unless your PMIC is partially fried
or some earlier revision that's broken.

Anyways, let me know what happens with the options I suggested and
CONFIG_CHARGER_TWL4030 disabled so we can see if the other problems
are gone.

Regards,

Tony

[PATCH] ARM: OMAP2+: Warn about deprecated legacy booting mode

[Russell King - ARM Linux]

On Fri, Oct 31, 2014 at 04:37:23PM -0700, Tony Lindgren wrote:
> * Russell King - ARM Linux <linux@arm.linux.org.uk> [141031 15:35]:
> > On Fri, Oct 31, 2014 at 02:13:26PM -0700, Tony Lindgren wrote:
> > > * Russell King - ARM Linux <linux@arm.linux.org.uk> [141031 12:32]:
> > > 
> > > > WARNING: CPU: 0 PID: 1 at arch/arm/mach-omap2/omap_hwmod.c:2538 _init+0xc8/0x170()
> > > > omap_hwmod: ssi: doesn't have mpu register target base
> > > > ...
> > > 
> > > Not seeing this one, is this maybe from the legacy mode boot?
> > > 
> > > > omap_hwmod: usb_host_hs: could not associate to clkdm l3_init_clkdm
> > > > omap_hwmod: usb_tll_hs: could not associate to clkdm l3_init_clkdm
> > > 
> > > Not seeing these either. Is this maybe from your 4430sdp instead?
> > 
> > This is /all/ from the 3430 LDP.
> > 
> > Compare these two URLs:
> > 
> > http://www.arm.linux.org.uk/developer/build/result.php?type=boot&idx=2891
> > http://www.arm.linux.org.uk/developer/build/result.php?type=boot&idx=2892
> 
> Not able to load the second one because of the broken battery
> driver :)
> 
> But based on the link above I can see that you're mixing in both
> legacy mode warnings and DT mode warnings at least for the SSI,
> so that explains why I'm not seeing the SSI error.
> 
> Still no idea where the l3_init_clkdm errors come from, are they
> from your huge log?
> 
> Like I posted in this thread, I'm not seeing same errors as you are
> with your config modified for DT:
> 
> http://muru.com/for-rmk/dmesg-ldp-dt-v3.18-rc2

Gah, the build system hadn't copied the wrapped image over since 3.14 days,
so it was a boot of the 3.14 kernel.  Sorry about that.

Now fixed, things are looking better, but not good enough.  The biggest
problem for the autobooter is this:

Deactivating swap...
Unmounting local filesystems...
Can't find /mnt/ram in /etc/fstab
umount: forced umount of tmpfs failed!
reboot: Power down
...4.T.......

Texas Instruments X-Loader 1.41mmc
Starting OS Bootloader from MMC/SD1 ...


U-Boot 1.1.4 (May 22 2008 - 18:10:53)

... which then proceeds with a full boot, and a re-run of everything,
which will continue endlessly.

Power down *means* you're supposed to power down or halt.  You're *NOT*
supposed to reboot.  This needs fixing.  Diffing the two log files
gives this at that point:

-reboot: System halted
+reboot: Power down

I guess the problem is that someone's decided with DT to hook a power
down handler which reboots instead.  That's soo fscking broken.  Reboot
means reboot.  Power off (and halt) means shutdown and _do_ _not_ reboot.
If I want it to reboot, I'd have asked for a reboot.

The battery problem is gone (so must have been fixed between 3.14 and
3.18-rc2) as is the omap_hwmod warning with backtrace.

New errors are:

+omap_l3_smx omap_l3_smx.0: couldn't request debug irq
+omap_l3_smx: probe of omap_l3_smx.0 failed with error -22
+irq: no irq domain found for /ocp/pinmux at 48002030 !
+vddvario: no parameters
+vdd33a: no parameters
+omap2_set_init_voltage: unable to find boot up OPP for vdd_mpu_iva
+omap2_set_init_voltage: unable to set vdd_mpu_iva
+omap2_set_init_voltage: unable to find boot up OPP for vdd_core
+omap2_set_init_voltage: unable to set vdd_core

However, these are minor compared to the dreadful poweroff behaviour.
Still going to have to disable DT booting for the LDP because of that.

-- 
FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up
according to speedtest.net.

[PATCH] ARM: OMAP2+: Warn about deprecated legacy booting mode

[Tony Lindgren]

* Russell King - ARM Linux <linux@arm.linux.org.uk> [141031 17:46]:
> On Fri, Oct 31, 2014 at 04:37:23PM -0700, Tony Lindgren wrote:
> > 
> > Like I posted in this thread, I'm not seeing same errors as you are
> > with your config modified for DT:
> > 
> > http://muru.com/for-rmk/dmesg-ldp-dt-v3.18-rc2
> 
> Gah, the build system hadn't copied the wrapped image over since 3.14 days,
> so it was a boot of the 3.14 kernel.  Sorry about that.

Ah-hah-hah!
 
> Now fixed, things are looking better, but not good enough.  The biggest
> problem for the autobooter is this:
> 
> Deactivating swap...
> Unmounting local filesystems...
> Can't find /mnt/ram in /etc/fstab
> umount: forced umount of tmpfs failed!
> reboot: Power down
> ...4.T.......
> 
> Texas Instruments X-Loader 1.41mmc
> Starting OS Bootloader from MMC/SD1 ...
> 
> 
> U-Boot 1.1.4 (May 22 2008 - 18:10:53)
> 
> ... which then proceeds with a full boot, and a re-run of everything,
> which will continue endlessly.
> 
> Power down *means* you're supposed to power down or halt.  You're *NOT*
> supposed to reboot.  This needs fixing.  Diffing the two log files
> gives this at that point:
> 
> -reboot: System halted
> +reboot: Power down
> 
> I guess the problem is that someone's decided with DT to hook a power
> down handler which reboots instead.  That's soo fscking broken.  Reboot
> means reboot.  Power off (and halt) means shutdown and _do_ _not_ reboot.
> If I want it to reboot, I'd have asked for a reboot.

That's a regression for sure. Does not seem to happen with a later
version of the PMIC here, but I too am seeing it at least with my
LDP. I'll take a look what's the proper way to fix that as there's
now some PM support with DT based booting that's not there for legacy
booting. So the PMIC configuration is different between legacy booting
and DT booting.
 
> The battery problem is gone (so must have been fixed between 3.14 and
> 3.18-rc2) as is the omap_hwmod warning with backtrace.

OK well that's good.
 
> New errors are:
> 
> +omap_l3_smx omap_l3_smx.0: couldn't request debug irq
> +omap_l3_smx: probe of omap_l3_smx.0 failed with error -22
> +irq: no irq domain found for /ocp/pinmux at 48002030 !
> +vddvario: no parameters
> +vdd33a: no parameters
> +omap2_set_init_voltage: unable to find boot up OPP for vdd_mpu_iva
> +omap2_set_init_voltage: unable to set vdd_mpu_iva
> +omap2_set_init_voltage: unable to find boot up OPP for vdd_core
> +omap2_set_init_voltage: unable to set vdd_core

OK good these are known issues but can be dealt with later on.
 
> However, these are minor compared to the dreadful poweroff behaviour.
> Still going to have to disable DT booting for the LDP because of that.

Sure, I'll let you know as soon as I have something available
for the PMIC powerdown issue.

Regards,

Tony

[PATCH] ARM: OMAP2+: Warn about deprecated legacy booting mode

[Tony Lindgren]

* Tony Lindgren <tony@atomide.com> [141101 15:00]:
> * Russell King - ARM Linux <linux@arm.linux.org.uk> [141031 17:46]:
>  
> > However, these are minor compared to the dreadful poweroff behaviour.
> > Still going to have to disable DT booting for the LDP because of that.
> 
> Sure, I'll let you know as soon as I have something available
> for the PMIC powerdown issue.

OK found the problem. The PMIC power transition register needs to
have charger and VBUS bits disabled to prevent immediate reboot
on powerdown for some boards.

Fix posted as "mfd: twl4030-power: Fix poweroff with PM configuration
enabled":

https://lkml.org/lkml/2014/11/2/114

Regards,

Tony

[PATCH] ARM: OMAP2+: Warn about deprecated legacy booting mode

[Pavel Machek]

On Tue 2014-10-28 01:01:38, Aaro Koskinen wrote:
> Hi,
> 
> On Mon, Oct 27, 2014 at 01:00:09PM -0700, Tony Lindgren wrote:
> > +
> > +	if (!of_have_populated_dt())
> > +		pr_warn("WARNING: legacy booting deprecated, please update to boot with .dts\n");
> > +
> 
> Maybe use WARN so that the warning is more verbose and kernel gets tainted?

Well.. Pali still has regression where /proc/cpuinfo changes in a way
that breaks existing userspace, when dt is used on N900.

And rmk was less then helpfull...

Should we maybe solve that before adding backtraces to our boot
messages?

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[PATCH] ARM: OMAP2+: Warn about deprecated legacy booting mode

[Tony Lindgren]

* Pavel Machek <pavel@ucw.cz> [141126 09:31]:
> On Tue 2014-10-28 01:01:38, Aaro Koskinen wrote:
> > Hi,
> > 
> > On Mon, Oct 27, 2014 at 01:00:09PM -0700, Tony Lindgren wrote:
> > > +
> > > +	if (!of_have_populated_dt())
> > > +		pr_warn("WARNING: legacy booting deprecated, please update to boot with .dts\n");
> > > +
> > 
> > Maybe use WARN so that the warning is more verbose and kernel gets tainted?
> 
> Well.. Pali still has regression where /proc/cpuinfo changes in a way
> that breaks existing userspace, when dt is used on N900.
> 
> And rmk was less then helpfull...

Maybe Pali can try to restart that discussion? To me it seems the
/proc/cpuinfo should be the same as it's a user interface. Sorry
forgot the details of the previous discussion..

And with which app was that? Sorry I forgot..

It's weird that it's not been an issue for other though? 
 
> Should we maybe solve that before adding backtraces to our boot
> messages?

With this warning we want to notify the people actually using
mainline kernel on omap3 that they should update their systems.
And also let us know on this list about the regressions, so I
think that's quite valuable.

Regards,

Tony

[PATCH] ARM: OMAP2+: Warn about deprecated legacy booting mode

[Pali Rohár]

On Wednesday 26 November 2014 19:19:35 Tony Lindgren wrote:
> * Pavel Machek <pavel@ucw.cz> [141126 09:31]:
> > On Tue 2014-10-28 01:01:38, Aaro Koskinen wrote:
> > > Hi,
> > > 
> > > On Mon, Oct 27, 2014 at 01:00:09PM -0700, Tony Lindgren 
wrote:
> > > > +
> > > > +	if (!of_have_populated_dt())
> > > > +		pr_warn("WARNING: legacy booting deprecated, please
> > > > update to boot with .dts\n"); +
> > > 
> > > Maybe use WARN so that the warning is more verbose and
> > > kernel gets tainted?
> > 
> > Well.. Pali still has regression where /proc/cpuinfo changes
> > in a way that breaks existing userspace, when dt is used on
> > N900.
> > 
> > And rmk was less then helpfull...
> 
> Maybe Pali can try to restart that discussion? To me it seems
> the /proc/cpuinfo should be the same as it's a user
> interface. Sorry forgot the details of the previous
> discussion..
> 

Yes, two days ago I again wrote emails about this problem...

E.g. one of them, see: https://lkml.org/lkml/2014/11/24/774

> And with which app was that? Sorry I forgot..
> 

More applications/libraries for N900 which running on Maemo 5 
system. Some of them are Nokia proprietary, some of them are open 
source and some are mine.

Basically problem is that non DT boot provides this info in 
/proc/cpuinfo:

Hardware        : Nokia RX-51 board
Revision        : 0012

New DT boot provides this:

Hardware        : Generic OMAP3 (Flattened Device Tree)
Revision        : 0000

> It's weird that it's not been an issue for other though?
> 
> > Should we maybe solve that before adding backtraces to our
> > boot messages?
> 
> With this warning we want to notify the people actually using
> mainline kernel on omap3 that they should update their
> systems. And also let us know on this list about the
> regressions, so I think that's quite valuable.
> 
> Regards,
> 
> Tony

-- 
Pali Roh?r
pali.rohar at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20141126/fc7e105c/attachment.sig>

[PATCH] ARM: OMAP2+: Warn about deprecated legacy booting mode

[Tony Lindgren]

* Pali Roh?r <pali.rohar@gmail.com> [141126 10:59]:
> On Wednesday 26 November 2014 19:19:35 Tony Lindgren wrote:
> > 
> > Maybe Pali can try to restart that discussion? To me it seems
> > the /proc/cpuinfo should be the same as it's a user
> > interface. Sorry forgot the details of the previous
> > discussion..
> > 
> 
> Yes, two days ago I again wrote emails about this problem...
> 
> E.g. one of them, see: https://lkml.org/lkml/2014/11/24/774
> 
> > And with which app was that? Sorry I forgot..
> > 
> 
> More applications/libraries for N900 which running on Maemo 5 
> system. Some of them are Nokia proprietary, some of them are open 
> source and some are mine.
> 
> Basically problem is that non DT boot provides this info in 
> /proc/cpuinfo:
> 
> Hardware        : Nokia RX-51 board
> Revision        : 0012
> 
> New DT boot provides this:
> 
> Hardware        : Generic OMAP3 (Flattened Device Tree)
> Revision        : 0000

Oh you can easily fix that by adding a n900 specific
DT_MACHINE_START entry to mach-omap2/board-generic.c.

The revision entry you can populate too in pdata-quirks.c,
or maybe add something generic to populate it based on the
cmdline or a dts entry as I believe that comes from the
legacy ATAGs. I think that's just the system_rev or some
other *_rev global in the kernel.

Regards,

Tony 

[PATCH] ARM: OMAP2+: Warn about deprecated legacy booting mode

[Pali Rohár]

On Wednesday 26 November 2014 20:10:28 Tony Lindgren wrote:
> * Pali Roh?r <pali.rohar@gmail.com> [141126 10:59]:
> > On Wednesday 26 November 2014 19:19:35 Tony Lindgren wrote:
> > > Maybe Pali can try to restart that discussion? To me it
> > > seems the /proc/cpuinfo should be the same as it's a user
> > > interface. Sorry forgot the details of the previous
> > > discussion..
> > 
> > Yes, two days ago I again wrote emails about this problem...
> > 
> > E.g. one of them, see: https://lkml.org/lkml/2014/11/24/774
> > 
> > > And with which app was that? Sorry I forgot..
> > 
> > More applications/libraries for N900 which running on Maemo
> > 5 system. Some of them are Nokia proprietary, some of them
> > are open source and some are mine.
> > 
> > Basically problem is that non DT boot provides this info in
> > /proc/cpuinfo:
> > 
> > Hardware        : Nokia RX-51 board
> > Revision        : 0012
> > 
> > New DT boot provides this:
> > 
> > Hardware        : Generic OMAP3 (Flattened Device Tree)
> > Revision        : 0000
> 
> Oh you can easily fix that by adding a n900 specific
> DT_MACHINE_START entry to mach-omap2/board-generic.c.
> 

I would like to see some solution which does not depend on 
distributing addition patch which will not be in mainline 
kernel...

For this problem I proposed patch (which was rejected): 
https://lkml.org/lkml/2014/6/18/853

Basically Hardware is used to check if application is running on 
Nokia N900 or not. Also entry from Hardware is appended to Web 
browser user agent and some internet services using it as 
identifier (N900 device).

> The revision entry you can populate too in pdata-quirks.c,
> or maybe add something generic to populate it based on the
> cmdline or a dts entry as I believe that comes from the
> legacy ATAGs. I think that's just the system_rev or some
> other *_rev global in the kernel.
> 
> Regards,
> 
> Tony

Revision comes from bootloader (via ATAG) and it is HW revision 
of N900 device. It cannot be hardcoded into kernel or DTS as it 
it depends on HW.

-- 
Pali Roh?r
pali.rohar at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20141126/f8e4ee02/attachment.sig>

[PATCH] ARM: OMAP2+: Warn about deprecated legacy booting mode

[Tony Lindgren]

* Pali Roh?r <pali.rohar@gmail.com> [141126 11:24]:
> On Wednesday 26 November 2014 20:10:28 Tony Lindgren wrote:
> > * Pali Roh?r <pali.rohar@gmail.com> [141126 10:59]:
> > > On Wednesday 26 November 2014 19:19:35 Tony Lindgren wrote:
> > > > Maybe Pali can try to restart that discussion? To me it
> > > > seems the /proc/cpuinfo should be the same as it's a user
> > > > interface. Sorry forgot the details of the previous
> > > > discussion..
> > > 
> > > Yes, two days ago I again wrote emails about this problem...
> > > 
> > > E.g. one of them, see: https://lkml.org/lkml/2014/11/24/774
> > > 
> > > > And with which app was that? Sorry I forgot..
> > > 
> > > More applications/libraries for N900 which running on Maemo
> > > 5 system. Some of them are Nokia proprietary, some of them
> > > are open source and some are mine.
> > > 
> > > Basically problem is that non DT boot provides this info in
> > > /proc/cpuinfo:
> > > 
> > > Hardware        : Nokia RX-51 board
> > > Revision        : 0012
> > > 
> > > New DT boot provides this:
> > > 
> > > Hardware        : Generic OMAP3 (Flattened Device Tree)
> > > Revision        : 0000
> > 
> > Oh you can easily fix that by adding a n900 specific
> > DT_MACHINE_START entry to mach-omap2/board-generic.c.
> > 
> 
> I would like to see some solution which does not depend on 
> distributing addition patch which will not be in mainline 
> kernel...

Yes mainline of course. Maybe you misunderstood what I was
suggesting, maybe try the attached patch to fix the "Hardware"
line problem in /proc/cpuinfo?
 
> For this problem I proposed patch (which was rejected): 
> https://lkml.org/lkml/2014/6/18/853

Yes I think that should continue as a separate discussion
too if there are other differences in /proc/cpuinfo.
 
> Basically Hardware is used to check if application is running on 
> Nokia N900 or not. Also entry from Hardware is appended to Web 
> browser user agent and some internet services using it as 
> identifier (N900 device).
> 
> > The revision entry you can populate too in pdata-quirks.c,
> > or maybe add something generic to populate it based on the
> > cmdline or a dts entry as I believe that comes from the
> > legacy ATAGs. I think that's just the system_rev or some
> > other *_rev global in the kernel.
> 
> Revision comes from bootloader (via ATAG) and it is HW revision 
> of N900 device. It cannot be hardcoded into kernel or DTS as it 
> it depends on HW.

Well for the "Revision" line problem, we could pass the revision
in cmdline or .dts if not passed in the legacy ATAGs. It sounds
like were just not copying it to system_rev for DT based booting?
Maybe it's just some missing CONFIG_ATAG option that needs to be
enabled?

Regards,

Tony

8< ------------
From: Tony Lindgren <tony@atomide.com>
Date: Wed, 26 Nov 2014 11:55:29 -0800
Subject: [PATCH] ARM: OMAP2+: Fix n900 board name for legacy user space

N900 legacy user space apps need the board name in
/proc/cpuinfo to work properly for the Hardware entry.

For other boards this should not be an issues and they
can use the generic Hardware entry.

Let's fix the issue by adding a custom DT_MACHINE_START
for n900.

Signed-off-by: Tony Lindgren <tony@atomide.com>

--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -118,6 +118,24 @@ MACHINE_END
 #endif
 
 #ifdef CONFIG_ARCH_OMAP3
+/* Some boards need board name for legacy userspace in /proc/cpuinfo */
+static const char *const n900_boards_compat[] __initconst = {
+	"nokia,omap3-n900",
+	NULL,
+};
+
+DT_MACHINE_START(OMAP3_N900_DT, "Nokia RX-51 board")
+	.reserve	= omap_reserve,
+	.map_io		= omap3_map_io,
+	.init_early	= omap3430_init_early,
+	.init_machine	= omap_generic_init,
+	.init_late	= omap3_init_late,
+	.init_time	= omap3_sync32k_timer_init,
+	.dt_compat	= n900_boards_compat,
+	.restart	= omap3xxx_restart,
+MACHINE_END
+
+/* Generic omap3 boards, most boards can use these */
 static const char *const omap3_boards_compat[] __initconst = {
 	"ti,omap3430",
 	"ti,omap3",

[PATCH] ARM: OMAP2+: Warn about deprecated legacy booting mode

[Pali Rohár]

On Wednesday 26 November 2014 21:08:06 Tony Lindgren wrote:
> * Pali Roh?r <pali.rohar@gmail.com> [141126 11:24]:
> > On Wednesday 26 November 2014 20:10:28 Tony Lindgren wrote:
> > > * Pali Roh?r <pali.rohar@gmail.com> [141126 10:59]:
> > > > On Wednesday 26 November 2014 19:19:35 Tony Lindgren 
wrote:
> > > > > Maybe Pali can try to restart that discussion? To me
> > > > > it seems the /proc/cpuinfo should be the same as it's
> > > > > a user interface. Sorry forgot the details of the
> > > > > previous discussion..
> > > > 
> > > > Yes, two days ago I again wrote emails about this
> > > > problem...
> > > > 
> > > > E.g. one of them, see:
> > > > https://lkml.org/lkml/2014/11/24/774
> > > > 
> > > > > And with which app was that? Sorry I forgot..
> > > > 
> > > > More applications/libraries for N900 which running on
> > > > Maemo 5 system. Some of them are Nokia proprietary,
> > > > some of them are open source and some are mine.
> > > > 
> > > > Basically problem is that non DT boot provides this info
> > > > in /proc/cpuinfo:
> > > > 
> > > > Hardware        : Nokia RX-51 board
> > > > Revision        : 0012
> > > > 
> > > > New DT boot provides this:
> > > > 
> > > > Hardware        : Generic OMAP3 (Flattened Device Tree)
> > > > Revision        : 0000
> > > 
> > > Oh you can easily fix that by adding a n900 specific
> > > DT_MACHINE_START entry to mach-omap2/board-generic.c.
> > 
> > I would like to see some solution which does not depend on
> > distributing addition patch which will not be in mainline
> > kernel...
> 
> Yes mainline of course. Maybe you misunderstood what I was
> suggesting, maybe try the attached patch to fix the "Hardware"
> line problem in /proc/cpuinfo?
> 

With your patch I'm getting:

Hardware        : Nokia RX-51 board

So patch is good.

> > For this problem I proposed patch (which was rejected):
> > https://lkml.org/lkml/2014/6/18/853
> 
> Yes I think that should continue as a separate discussion
> too if there are other differences in /proc/cpuinfo.
> 
> > Basically Hardware is used to check if application is
> > running on Nokia N900 or not. Also entry from Hardware is
> > appended to Web browser user agent and some internet
> > services using it as identifier (N900 device).
> > 
> > > The revision entry you can populate too in pdata-quirks.c,
> > > or maybe add something generic to populate it based on the
> > > cmdline or a dts entry as I believe that comes from the
> > > legacy ATAGs. I think that's just the system_rev or some
> > > other *_rev global in the kernel.
> > 
> > Revision comes from bootloader (via ATAG) and it is HW
> > revision of N900 device. It cannot be hardcoded into kernel
> > or DTS as it it depends on HW.
> 
> Well for the "Revision" line problem, we could pass the
> revision in cmdline or .dts if not passed in the legacy
> ATAGs. It sounds like were just not copying it to system_rev
> for DT based booting? Maybe it's just some missing
> CONFIG_ATAG option that needs to be enabled?
> 
> Regards,
> 
> Tony
> 

Yes it looks like DT code does not read Revision ATAG... I tried 
to enable everything but always same problem...

-- 
Pali Roh?r
pali.rohar at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20141127/a7a93e38/attachment.sig>

[PATCH] ARM: OMAP2+: Warn about deprecated legacy booting mode

[Tony Lindgren]

* Pali Roh?r <pali.rohar@gmail.com> [141126 15:03]:
> On Wednesday 26 November 2014 21:08:06 Tony Lindgren wrote:
> 
> With your patch I'm getting:
> 
> Hardware        : Nokia RX-51 board
> 
> So patch is good.

Is that a Tested-by: then? :)
 
> > > Revision comes from bootloader (via ATAG) and it is HW
> > > revision of N900 device. It cannot be hardcoded into kernel
> > > or DTS as it it depends on HW.
> > 
> > Well for the "Revision" line problem, we could pass the
> > revision in cmdline or .dts if not passed in the legacy
> > ATAGs. It sounds like were just not copying it to system_rev
> > for DT based booting? Maybe it's just some missing
> > CONFIG_ATAG option that needs to be enabled?
> 
> Yes it looks like DT code does not read Revision ATAG... I tried 
> to enable everything but always same problem...

Maybe check if it shows up properly in /proc/atags or whatever
the interface for it was?

The build_tag_list() should parse ATAG_REVISION and then
parse_tag_revision() should copy it to system_rev. Maybe try
adding some printks to see if those functions get called?

Regards,

Tony

[PATCH] ARM: OMAP2+: Warn about deprecated legacy booting mode

[Pali Rohár]

On Thursday 27 November 2014 00:14:36 Tony Lindgren wrote:
> * Pali Roh?r <pali.rohar@gmail.com> [141126 15:03]:
> > On Wednesday 26 November 2014 21:08:06 Tony Lindgren wrote:
> > 
> > With your patch I'm getting:
> > 
> > Hardware        : Nokia RX-51 board
> > 
> > So patch is good.
> 
> Is that a Tested-by: then? :)
> 

Yes for Hardware line you can add my:

Tested-by: Pali Roh?r <pali.rohar@gmail.com>

> > > > Revision comes from bootloader (via ATAG) and it is HW
> > > > revision of N900 device. It cannot be hardcoded into
> > > > kernel or DTS as it it depends on HW.
> > > 
> > > Well for the "Revision" line problem, we could pass the
> > > revision in cmdline or .dts if not passed in the legacy
> > > ATAGs. It sounds like were just not copying it to
> > > system_rev for DT based booting? Maybe it's just some
> > > missing CONFIG_ATAG option that needs to be enabled?
> > 
> > Yes it looks like DT code does not read Revision ATAG... I
> > tried to enable everything but always same problem...
> 
> Maybe check if it shows up properly in /proc/atags or whatever
> the interface for it was?
> 

With enabled CONFIG_ARM_APPENDED_DTB=y file /proc/atags is 
missing.

> The build_tag_list() should parse ATAG_REVISION and then
> parse_tag_revision() should copy it to system_rev. Maybe try
> adding some printks to see if those functions get called?
> 
> Regards,
> 
> Tony

Now I see... Problem is that build_tag_list() is called from 
convert_to_tag_list() which is called from setup_machine_tags() 
which is called from setup_arch() only if setup_machine_fdt() 
call fails. And it fails for *non* DT boot. You can check this 
chain too.

-- 
Pali Roh?r
pali.rohar at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20141127/c8e39090/attachment.sig>

[PATCH] ARM: OMAP2+: Warn about deprecated legacy booting mode

[Tony Lindgren]

* Pali Roh?r <pali.rohar@gmail.com> [141126 15:40]:
> 
> With enabled CONFIG_ARM_APPENDED_DTB=y file /proc/atags is 
> missing.

OK I guess it should not be needed for DT based booting.
 
> > The build_tag_list() should parse ATAG_REVISION and then
> > parse_tag_revision() should copy it to system_rev. Maybe try
> > adding some printks to see if those functions get called?
> 
> Now I see... Problem is that build_tag_list() is called from 
> convert_to_tag_list() which is called from setup_machine_tags() 
> which is called from setup_arch() only if setup_machine_fdt() 
> call fails. And it fails for *non* DT boot. You can check this 
> chain too.

Thinking about this probably the best long term solution is
to pass optional board_revision in the kernel cmdline that
can be parsed early and copied to system_rev variable.

Or if you can think of some other way to get it, we can set
system_rev in pdata-quirks.c.

Or maybe add some code to copy the ATAGs somewhere where
they are out of the way and don't conflict with the device
tree data? Then we can query ATAG_REVISION from pdata-quirks.c
and set system_rev.

Regards,

Tony

[PATCH] ARM: OMAP2+: Warn about deprecated legacy booting mode

[Pavel Machek]

> 8< ------------
> From: Tony Lindgren <tony@atomide.com>
> Date: Wed, 26 Nov 2014 11:55:29 -0800
> Subject: [PATCH] ARM: OMAP2+: Fix n900 board name for legacy user space
> 
> N900 legacy user space apps need the board name in
> /proc/cpuinfo to work properly for the Hardware entry.
> 
> For other boards this should not be an issues and they
> can use the generic Hardware entry.
> 
> Let's fix the issue by adding a custom DT_MACHINE_START
> for n900.
> 
> Signed-off-by: Tony Lindgren <tony@atomide.com>

Acked-by: Pavel Machek <pavel@ucw.cz>

Thanks!
								Pavel

> 
> --- a/arch/arm/mach-omap2/board-generic.c
> +++ b/arch/arm/mach-omap2/board-generic.c
> @@ -118,6 +118,24 @@ MACHINE_END
>  #endif
>  
>  #ifdef CONFIG_ARCH_OMAP3
> +/* Some boards need board name for legacy userspace in /proc/cpuinfo */
> +static const char *const n900_boards_compat[] __initconst = {
> +	"nokia,omap3-n900",
> +	NULL,
> +};
> +
> +DT_MACHINE_START(OMAP3_N900_DT, "Nokia RX-51 board")
> +	.reserve	= omap_reserve,
> +	.map_io		= omap3_map_io,
> +	.init_early	= omap3430_init_early,
> +	.init_machine	= omap_generic_init,
> +	.init_late	= omap3_init_late,
> +	.init_time	= omap3_sync32k_timer_init,
> +	.dt_compat	= n900_boards_compat,
> +	.restart	= omap3xxx_restart,
> +MACHINE_END
> +
> +/* Generic omap3 boards, most boards can use these */
>  static const char *const omap3_boards_compat[] __initconst = {
>  	"ti,omap3430",
>  	"ti,omap3",

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[PATCH] ARM: OMAP2+: Warn about deprecated legacy booting mode

[Pali Rohár]

On Thursday 27 November 2014 02:12:04 Tony Lindgren wrote:
> * Pali Roh?r <pali.rohar@gmail.com> [141126 15:40]:
> > With enabled CONFIG_ARM_APPENDED_DTB=y file /proc/atags is
> > missing.
> 
> OK I guess it should not be needed for DT based booting.
> 

If I do not enable CONFIG_ARM_APPENDED_DTB=y then kernel is 
booting in legacy mode (not in DT).

> > > The build_tag_list() should parse ATAG_REVISION and then
> > > parse_tag_revision() should copy it to system_rev. Maybe
> > > try adding some printks to see if those functions get
> > > called?
> > 
> > Now I see... Problem is that build_tag_list() is called from
> > convert_to_tag_list() which is called from
> > setup_machine_tags() which is called from setup_arch() only
> > if setup_machine_fdt() call fails. And it fails for *non*
> > DT boot. You can check this chain too.
> 
> Thinking about this probably the best long term solution is
> to pass optional board_revision in the kernel cmdline that
> can be parsed early and copied to system_rev variable.
> 

Not possible. Our bootloader is closed & proprietary. I tried to 
replace it with u-boot I was not able to do that. So we will use 
that Nokia closed bootloader forever and it can provide data only 
in ATAG structure.

> Or if you can think of some other way to get it, we can set
> system_rev in pdata-quirks.c.
> 
> Or maybe add some code to copy the ATAGs somewhere where
> they are out of the way and don't conflict with the device
> tree data? Then we can query ATAG_REVISION from pdata-quirks.c
> and set system_rev.
> 
> Regards,
> 
> Tony

If we are able to read ATAG from pdata-quirks, then we can parse 
it there and fix problems... But I do not know if address of ATAG 
structure is available there...

-- 
Pali Roh?r
pali.rohar at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20141127/04fc59bf/attachment-0001.sig>

[PATCH] ARM: OMAP2+: Warn about deprecated legacy booting mode

[Tony Lindgren]

* Pali Roh?r <pali.rohar@gmail.com> [141127 03:34]:
> On Thursday 27 November 2014 02:12:04 Tony Lindgren wrote:
> > 
> > Thinking about this probably the best long term solution is
> > to pass optional board_revision in the kernel cmdline that
> > can be parsed early and copied to system_rev variable.
> > 
> 
> Not possible. Our bootloader is closed & proprietary. I tried to 
> replace it with u-boot I was not able to do that. So we will use 
> that Nokia closed bootloader forever and it can provide data only 
> in ATAG structure.

I'm using just mainline u-boot flashed as kernel for nolo that
then loads the kernel.

For passing the board revision using the pass through u-boot is
probably the best long term solution. U-boot can read the ATAGs
from nolo and modify the .dtb for the revision information.

Are you saying there are some issues with that?
 
> > Or if you can think of some other way to get it, we can set
> > system_rev in pdata-quirks.c.
> > 
> > Or maybe add some code to copy the ATAGs somewhere where
> > they are out of the way and don't conflict with the device
> > tree data? Then we can query ATAG_REVISION from pdata-quirks.c
> > and set system_rev.
> 
> If we are able to read ATAG from pdata-quirks, then we can parse 
> it there and fix problems... But I do not know if address of ATAG 
> structure is available there...

Are there other ATAGs needed beyond the ATAG_REVISION?

Regards,

Tony

[PATCH] ARM: OMAP2+: Warn about deprecated legacy booting mode

[Pali Rohár]

On Friday 28 November 2014 21:27:19 Tony Lindgren wrote:
> * Pali Roh?r <pali.rohar@gmail.com> [141127 03:34]:
> > On Thursday 27 November 2014 02:12:04 Tony Lindgren wrote:
> > > Thinking about this probably the best long term solution
> > > is to pass optional board_revision in the kernel cmdline
> > > that can be parsed early and copied to system_rev
> > > variable.
> > 
> > Not possible. Our bootloader is closed & proprietary. I
> > tried to replace it with u-boot I was not able to do that.
> > So we will use that Nokia closed bootloader forever and it
> > can provide data only in ATAG structure.
> 
> I'm using just mainline u-boot flashed as kernel for nolo that
> then loads the kernel.
> 

Yes, this working. I wrote & tested more those n900 uboot parts.

> For passing the board revision using the pass through u-boot
> is probably the best long term solution. U-boot can read the
> ATAGs from nolo and modify the .dtb for the revision
> information.
> 

Yes, this is possible. Current uboot rx51 code already parse
ATAGs from previous bootloader, so is also able to modify dtb.

> Are you saying there are some issues with that?
> 

uboot (in mode when is loaded from NOLO) has those issues:

1) uboot cannot read n900 onenand mtd (uboot onenand driver not
working, do not know why)
2) missing support for battery charging (can totally discharge
battery)
3) missing support for panel panel (so sometimes screen is
totally black until kernel is booted and loaded own drivers)
4) limit for storing both uboot and kernel into MTD is limited by
2MB (size of kernel nand partition)

Basically you can use uboot if you accept all above issues.

But there are people (Pavel CCed) who prefer to work without
uboot when testing kernel. So it is not good idea to lock new
kernel versions to depends on new uboot version.

> > > Or if you can think of some other way to get it, we can
> > > set system_rev in pdata-quirks.c.
> > > 
> > > Or maybe add some code to copy the ATAGs somewhere where
> > > they are out of the way and don't conflict with the device
> > > tree data? Then we can query ATAG_REVISION from
> > > pdata-quirks.c and set system_rev.
> > 
> > If we are able to read ATAG from pdata-quirks, then we can
> > parse it there and fix problems... But I do not know if
> > address of ATAG structure is available there...
> 
> Are there other ATAGs needed beyond the ATAG_REVISION?
> 
> Regards,
> 
> Tony

Sorry for longer email. I will provide some more info about it.
First I will describe that informations are passed from NOLO
to kernel. Note that all those informations are passed also from
uboot to kernel (uboot just reuse non static data from NOLO).
Then I will describe that we need in userspace.

Here are all ATAGs from NOLO:

0000 - 0005:54410001 ATAG CORE flags=00000000 pagesize=00001000 rootdev=00000000
0020 - 0004:54410002 ATAG MEM size=10000000 start=80000000
0036 - 0003:54410007 ATAG REVISION revision=00002204
0048 - 0181:414f4d50 OMAP table (724 bytes)
       0000 - 0004:4f07 UART: enabled uarts (bitmask) 00000000
       0008 - 0024:4f05 LCD:          panel=acx565akm controller=internal nreset_gpio=005a 
data_lines=0018
       0048 - 0014:4f06 GPIO SWITCH:  cam_focus    : gpio=0044 flags=01 type=02 keycode=00000000
       0072 - 0014:4f06 GPIO SWITCH:  cam_launch   : gpio=0045 flags=01 type=02 keycode=00000000
       0096 - 0014:4f06 GPIO SWITCH:  cam_shutter  : gpio=006e flags=01 type=00 keycode=00000000
       0120 - 0014:4f06 GPIO SWITCH:  cmt_apeslpx  : gpio=0046 flags=02 type=02 keycode=00000000
       0144 - 0014:4f06 GPIO SWITCH:  cmt_bsi      : gpio=009d flags=02 type=02 keycode=00000000
       0168 - 0014:4f06 GPIO SWITCH:  cmt_en       : gpio=004a flags=02 type=02 keycode=00000000
       0192 - 0014:4f06 GPIO SWITCH:  cmt_rst      : gpio=004b flags=06 type=02 keycode=00000000
       0216 - 0014:4f06 GPIO SWITCH:  cmt_rst_rq   : gpio=0049 flags=06 type=02 keycode=00000000
       0240 - 0014:4f06 GPIO SWITCH:  cmt_wddis    : gpio=000d flags=02 type=02 keycode=00000000
       0264 - 0014:4f06 GPIO SWITCH:  headphone    : gpio=00b1 flags=01 type=01 keycode=00000000
       0288 - 0014:4f06 GPIO SWITCH:  kb_lock      : gpio=0071 flags=01 type=00 keycode=00000000
       0312 - 0014:4f06 GPIO SWITCH:  proximity    : gpio=0059 flags=00 type=00 keycode=00000000
       0336 - 0014:4f06 GPIO SWITCH:  sleep_ind    : gpio=00a2 flags=02 type=02 keycode=00000000
       0360 - 0014:4f06 GPIO SWITCH:  slide        : gpio=0047 flags=00 type=00 keycode=00000000
       0384 - 0008:4e02 WLAN CX3110X: chip_type=25 power_gpio=0057 irq_gpio=002a spi_cs_gpio=ffffffff
       0396 - 001c:4f0b PARTITION:    bootloader       : size=00020000 offset=00000000 mask=00000003
       0428 - 001c:4f0b PARTITION:    config           : size=00060000 offset=00020000 mask=00000000
       0460 - 001c:4f0b PARTITION:    log              : size=00040000 offset=00080000 mask=00000000
       0492 - 001c:4f0b PARTITION:    kernel           : size=00200000 offset=000c0000 mask=00000000
       0524 - 001c:4f0b PARTITION:    initfs           : size=00200000 offset=002c0000 mask=00000000
       0556 - 001c:4f0b PARTITION:    rootfs           : size=0fb40000 offset=004c0000 mask=00000000
       0588 - 000c:4f80 BOOTREASON:   pwr_key     
       0604 - 0018:4f82 VERSION:      product      = RX-51       
       0632 - 0018:4f82 VERSION:      hw-build     = 2204        
       0660 - 0018:4f82 VERSION:      nolo         = 1.4.14      
       0688 - 0018:4f82 VERSION:      boot-mode    = normal      

ATAG structure is parsed from file /proc/atags via program
dumpatag: http://www.mesa.nl/~marcel/

I do not know what ATAG CORE is.

ATAG MEM is generated by NOLO and also uboot at runtime. But we
have hardcoded memory values in n900 DT file. Maybe we should use
those generated by uboot bootloader (or reuse uboot code for
generating) instead using hardcoded one?

ATAG REVISION is that which is magically generated by NOLO and
which we want to reuse. Better would be understand how and why it
NOLO generate (maybe there is something secret register which can
tell it?). But I was not able to find out it.

OMAP table is one big ATAG structure which contains lot of other
values. Basically all values (except uart, bootreason and
version) are static and on all n900 devices are same.

Partitions are generated by NOLO from CAL (/dev/mtd1) data, but I
think nobody ever changed them (but it is possible!).

Uart is enabled when serial console is enabled via NOLO.

Bootreason contains omap3 bootreason value from special register
(plus magic from NOLO) which is cleared automatically by NOLO (so
no way to read it from kernel).

Version contains some key-value data. Product is always RX-51,
hw-build is same as ATAG REVISION, nolo is nolo version and value
for boot-mode is ether normal or update.


What we need in userspace:

In file /proc/cpuinfo:
Hardware        : Nokia RX-51 board
Revision        : <hw_revision_number>

And in any file and any format (does not matter if text, binary,
whatever...) we need value from bootreason, boot-mode (and maybe
nolo version).

Current maemo applications are using files /proc/bootreason (for
bootreason) and /proc/component_version (for all version) which
are specific for Nokia 2.6.28 kernel. All those applications
(which reading ether bootreason or bootmode proc files) are
either shell scripts or open source, so editing them is possible.
I will start fixing them once there will be *stable* ABI for
those data.

With non DT (legacy) boot all above atags are present in binary
file /proc/atags.

But because DT boot does not provide /proc/atags file I need some
interface how to read above needed strings.

So I would like to know what is possible and how?

Does kernel provide some interface for telling userspace
applications something like bootreason (e.g power key, software
reset, rtc alarm, charger connected, ...)?

-- 
Pali Roh?r
pali.rohar at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20141128/4317909d/attachment.sig>

[PATCH] ARM: OMAP2+: Warn about deprecated legacy booting mode

[Tony Lindgren]

* Pali Roh?r <pali.rohar@gmail.com> [141128 13:43]:
> On Friday 28 November 2014 21:27:19 Tony Lindgren wrote:
> 
> > Are you saying there are some issues with that?
>
> uboot (in mode when is loaded from NOLO) has those issues:
> 
> 1) uboot cannot read n900 onenand mtd (uboot onenand driver not
> working, do not know why)
> 2) missing support for battery charging (can totally discharge
> battery)
> 3) missing support for panel panel (so sometimes screen is
> totally black until kernel is booted and loaded own drivers)
> 4) limit for storing both uboot and kernel into MTD is limited by
> 2MB (size of kernel nand partition)
> 
> Basically you can use uboot if you accept all above issues.
> 
> But there are people (Pavel CCed) who prefer to work without
> uboot when testing kernel. So it is not good idea to lock new
> kernel versions to depends on new uboot version.

OK thanks for the update, I was not aware of the issues above.
 
> > Are there other ATAGs needed beyond the ATAG_REVISION?
> 
> Sorry for longer email. I will provide some more info about it.
> First I will describe that informations are passed from NOLO
> to kernel. Note that all those informations are passed also from
> uboot to kernel (uboot just reuse non static data from NOLO).
> Then I will describe that we need in userspace.
> 
> Here are all ATAGs from NOLO:
... 

These we should not need, it's all coming from the .dts files.

> 0036 - 0003:54410007 ATAG REVISION revision=00002204
>        0588 - 000c:4f80 BOOTREASON:   pwr_key     
>        0604 - 0018:4f82 VERSION:      product      = RX-51       
>        0632 - 0018:4f82 VERSION:      hw-build     = 2204        
>        0660 - 0018:4f82 VERSION:      nolo         = 1.4.14      
>        0688 - 0018:4f82 VERSION:      boot-mode    = normal      

Seems like these are the ones we should somehow get. The others
should be coming in the .dts file already, or can be deciphered
based on the above in the kernel.
 
> ATAG MEM is generated by NOLO and also uboot at runtime. But we
> have hardcoded memory values in n900 DT file. Maybe we should use
> those generated by uboot bootloader (or reuse uboot code for
> generating) instead using hardcoded one?

Yes we should not need ATAG MEM.
 
> ATAG REVISION is that which is magically generated by NOLO and
> which we want to reuse. Better would be understand how and why it
> NOLO generate (maybe there is something secret register which can
> tell it?). But I was not able to find out it.

I would assume that's also somewhere in the cal area.
 
> OMAP table is one big ATAG structure which contains lot of other
> values. Basically all values (except uart, bootreason and
> version) are static and on all n900 devices are same.
> 
> Partitions are generated by NOLO from CAL (/dev/mtd1) data, but I
> think nobody ever changed them (but it is possible!).

AFAIK it's safe to assume they are coming in the .dts file.
 
> Uart is enabled when serial console is enabled via NOLO.

We can keep the UART enabled all the time no problem. It's timeouts
just need to be configured for idle.
 
> Bootreason contains omap3 bootreason value from special register
> (plus magic from NOLO) which is cleared automatically by NOLO (so
> no way to read it from kernel).
> 
> Version contains some key-value data. Product is always RX-51,
> hw-build is same as ATAG REVISION, nolo is nolo version and value
> for boot-mode is ether normal or update.

OK 
 
> What we need in userspace:
> 
> In file /proc/cpuinfo:
> Hardware        : Nokia RX-51 board
> Revision        : <hw_revision_number>
> 
> And in any file and any format (does not matter if text, binary,
> whatever...) we need value from bootreason, boot-mode (and maybe
> nolo version).

OK
 
> Current maemo applications are using files /proc/bootreason (for
> bootreason) and /proc/component_version (for all version) which
> are specific for Nokia 2.6.28 kernel. All those applications
> (which reading ether bootreason or bootmode proc files) are
> either shell scripts or open source, so editing them is possible.
> I will start fixing them once there will be *stable* ABI for
> those data.
> 
> With non DT (legacy) boot all above atags are present in binary
> file /proc/atags.
> 
> But because DT boot does not provide /proc/atags file I need some
> interface how to read above needed strings.
> 
> So I would like to know what is possible and how?

How about patch things so we see /proc/atags also for DT based
booting, but in a way where the ATAGs don't do anything?
 
> Does kernel provide some interface for telling userspace
> applications something like bootreason (e.g power key, software
> reset, rtc alarm, charger connected, ...)?

I don't think we have anything like that currently.

Regards,

Tony

[PATCH] ARM: OMAP2+: Warn about deprecated legacy booting mode

[Aaro Koskinen]

Hi,

On Fri, Nov 28, 2014 at 10:41:12PM +0100, Pali Roh?r wrote:
> Does kernel provide some interface for telling userspace
> applications something like bootreason (e.g power key, software
> reset, rtc alarm, charger connected, ...)?

In N950/N9, NOLO passes this information using kernel command line
and applications are reading /proc/cmdline. If I remember correctly all
those custom proc files were removed from Nokia kernel, and everything
was passed via command line.

A.

[PATCH] ARM: OMAP2+: Warn about deprecated legacy booting mode

[Aaro Koskinen]

Hi,

On Fri, Nov 28, 2014 at 10:41:12PM +0100, Pali Roh?r wrote:
> uboot (in mode when is loaded from NOLO) has those issues:
> 
> 1) uboot cannot read n900 onenand mtd (uboot onenand driver not
> working, do not know why)
> 2) missing support for battery charging (can totally discharge
> battery)

NOLO enables watchdogs when booting. So if you get stuck in the U-boot
for whatever reason the device will power off after ~30 secs or so.

A.

[PATCH] ARM: OMAP2+: Warn about deprecated legacy booting mode

[Pali Rohár]

On Friday 28 November 2014 23:24:26 Tony Lindgren wrote:
> * Pali Roh?r <pali.rohar@gmail.com> [141128 13:43]:
> > On Friday 28 November 2014 21:27:19 Tony Lindgren wrote:
> > > Are you saying there are some issues with that?
> > 
> > uboot (in mode when is loaded from NOLO) has those issues:
> > 
> > 1) uboot cannot read n900 onenand mtd (uboot onenand driver
> > not working, do not know why)
> > 2) missing support for battery charging (can totally
> > discharge battery)
> > 3) missing support for panel panel (so sometimes screen is
> > totally black until kernel is booted and loaded own drivers)
> > 4) limit for storing both uboot and kernel into MTD is
> > limited by 2MB (size of kernel nand partition)
> > 
> > Basically you can use uboot if you accept all above issues.
> > 
> > But there are people (Pavel CCed) who prefer to work without
> > uboot when testing kernel. So it is not good idea to lock
> > new kernel versions to depends on new uboot version.
> 
> OK thanks for the update, I was not aware of the issues above.
> 
> > > Are there other ATAGs needed beyond the ATAG_REVISION?
> > 
> > Sorry for longer email. I will provide some more info about
> > it. First I will describe that informations are passed from
> > NOLO to kernel. Note that all those informations are passed
> > also from uboot to kernel (uboot just reuse non static data
> > from NOLO). Then I will describe that we need in userspace.
> 
> > Here are all ATAGs from NOLO:
> ...
> 
> These we should not need, it's all coming from the .dts files.
> 
> > 0036 - 0003:54410007 ATAG REVISION revision=00002204
> > 
> >        0588 - 000c:4f80 BOOTREASON:   pwr_key
> >        0604 - 0018:4f82 VERSION:      product      = RX-51
> >        0632 - 0018:4f82 VERSION:      hw-build     = 2204
> >        0660 - 0018:4f82 VERSION:      nolo         = 1.4.14
> >        0688 - 0018:4f82 VERSION:      boot-mode    = normal
> 
> Seems like these are the ones we should somehow get. The
> others should be coming in the .dts file already, or can be
> deciphered based on the above in the kernel.
> 
> > ATAG MEM is generated by NOLO and also uboot at runtime. But
> > we have hardcoded memory values in n900 DT file. Maybe we
> > should use those generated by uboot bootloader (or reuse
> > uboot code for generating) instead using hardcoded one?
> 
> Yes we should not need ATAG MEM.
> 

Ok.

> > ATAG REVISION is that which is magically generated by NOLO
> > and which we want to reuse. Better would be understand how
> > and why it NOLO generate (maybe there is something secret
> > register which can tell it?). But I was not able to find
> > out it.
> 
> I would assume that's also somewhere in the cal area.
> 

In CAL can be stored "forced" value which overwrite that one 
automagically detected.

> > OMAP table is one big ATAG structure which contains lot of
> > other values. Basically all values (except uart, bootreason
> > and version) are static and on all n900 devices are same.
> > 
> > Partitions are generated by NOLO from CAL (/dev/mtd1) data,
> > but I think nobody ever changed them (but it is possible!).
> 
> AFAIK it's safe to assume they are coming in the .dts file.
> 

Yes, using DTS values is OK. I did not heard about anybody who 
modifying partition table. Personally, sometimes I'm doing it -- 
but only in qemu and only to increase kernel partition with 
decreasing size of initfs partition (which is not used) to make 
sure that offset of root partition is same (so nothing breaks).

> > Uart is enabled when serial console is enabled via NOLO.
> 
> We can keep the UART enabled all the time no problem. It's
> timeouts just need to be configured for idle.
> 

Probably we can ignore it. Serial console is used now maybe only 
in qemu. No idea if UART is even used.

> > Bootreason contains omap3 bootreason value from special
> > register (plus magic from NOLO) which is cleared
> > automatically by NOLO (so no way to read it from kernel).
> > 
> > Version contains some key-value data. Product is always
> > RX-51, hw-build is same as ATAG REVISION, nolo is nolo
> > version and value for boot-mode is ether normal or update.
> 
> OK
> 
> > What we need in userspace:
> > 
> > In file /proc/cpuinfo:
> > Hardware        : Nokia RX-51 board
> > Revision        : <hw_revision_number>
> > 
> > And in any file and any format (does not matter if text,
> > binary, whatever...) we need value from bootreason,
> > boot-mode (and maybe nolo version).
> 
> OK
> 
> > Current maemo applications are using files /proc/bootreason
> > (for bootreason) and /proc/component_version (for all
> > version) which are specific for Nokia 2.6.28 kernel. All
> > those applications (which reading ether bootreason or
> > bootmode proc files) are either shell scripts or open
> > source, so editing them is possible. I will start fixing
> > them once there will be *stable* ABI for those data.
> > 
> > With non DT (legacy) boot all above atags are present in
> > binary file /proc/atags.
> > 
> > But because DT boot does not provide /proc/atags file I need
> > some interface how to read above needed strings.
> > 
> > So I would like to know what is possible and how?
> 
> How about patch things so we see /proc/atags also for DT based
> booting, but in a way where the ATAGs don't do anything?
> 

Ok. Exporting /proc/atags file is good idea (even if it do 
nothing). But it is possible from pdata-quirks? Or how to achieve 
this? And once we can read atags in pdata-quirks we can parse it 
and find revision info (which needs to be changed for 
/proc/cpuinfo).

> > Does kernel provide some interface for telling userspace
> > applications something like bootreason (e.g power key,
> > software reset, rtc alarm, charger connected, ...)?
> 
> I don't think we have anything like that currently.
> 
> Regards,
> 
> Tony

Ok. If there will be some interface (in future) it would be good 
idea to add n900 bootreason (passed from bootloader) to that 
interface...

-- 
Pali Roh?r
pali.rohar at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20141128/ac896cad/attachment.sig>

[PATCH] ARM: OMAP2+: Warn about deprecated legacy booting mode

[Pali Rohár]

On Friday 28 November 2014 23:26:30 Aaro Koskinen wrote:
> Hi,
> 
> On Fri, Nov 28, 2014 at 10:41:12PM +0100, Pali Roh?r wrote:
> > Does kernel provide some interface for telling userspace
> > applications something like bootreason (e.g power key,
> > software reset, rtc alarm, charger connected, ...)?
> 
> In N950/N9, NOLO passes this information using kernel command
> line and applications are reading /proc/cmdline. If I
> remember correctly all those custom proc files were removed
> from Nokia kernel, and everything was passed via command
> line.
> 
> A.

Yes, you are right. But NOLO on N900 pass all those data via 
ATAGs only and does not pass it in /proc/cmdline :-(

-- 
Pali Roh?r
pali.rohar at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20141128/6e74d218/attachment.sig>

[PATCH] ARM: OMAP2+: Warn about deprecated legacy booting mode

[Pali Rohár]

On Friday 28 November 2014 23:41:35 Aaro Koskinen wrote:
> Hi,
> 
> On Fri, Nov 28, 2014 at 10:41:12PM +0100, Pali Roh?r wrote:
> > uboot (in mode when is loaded from NOLO) has those issues:
> > 
> > 1) uboot cannot read n900 onenand mtd (uboot onenand driver
> > not working, do not know why)
> > 2) missing support for battery charging (can totally
> > discharge battery)
> 
> NOLO enables watchdogs when booting. So if you get stuck in
> the U-boot for whatever reason the device will power off
> after ~30 secs or so.
> 
> A.

Not truth!

Uboot RX51 code periodically kick watchdogs if are enabled. I 
implemented that before RX51 uboot was merged into mainline.

-- 
Pali Roh?r
pali.rohar at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20141128/5e87b2bf/attachment-0001.sig>

[PATCH] ARM: OMAP2+: Warn about deprecated legacy booting mode

[Aaro Koskinen]

Hi,

On Fri, Nov 28, 2014 at 11:49:00PM +0100, Pali Roh?r wrote:
> On Friday 28 November 2014 23:41:35 Aaro Koskinen wrote:
> > On Fri, Nov 28, 2014 at 10:41:12PM +0100, Pali Roh?r wrote:
> > > uboot (in mode when is loaded from NOLO) has those issues:
> > > 
> > > 1) uboot cannot read n900 onenand mtd (uboot onenand driver
> > > not working, do not know why)
> > > 2) missing support for battery charging (can totally
> > > discharge battery)
> > 
> > NOLO enables watchdogs when booting. So if you get stuck in
> > the U-boot for whatever reason the device will power off
> > after ~30 secs or so.
> 
> Not truth!
> 
> Uboot RX51 code periodically kick watchdogs if are enabled. I 
> implemented that before RX51 uboot was merged into mainline.

Maybe then it shouldn't do that.

A.

[PATCH] ARM: OMAP2+: Warn about deprecated legacy booting mode

[Pali Rohár]

On Friday 28 November 2014 21:27:19 Tony Lindgren wrote:
> * Pali Roh?r <pali.rohar@gmail.com> [141127 03:34]:
> > On Thursday 27 November 2014 02:12:04 Tony Lindgren wrote:
> > > Thinking about this probably the best long term solution
> > > is to pass optional board_revision in the kernel cmdline
> > > that can be parsed early and copied to system_rev
> > > variable.
> > 
> > Not possible. Our bootloader is closed & proprietary. I
> > tried to replace it with u-boot I was not able to do that.
> > So we will use that Nokia closed bootloader forever and it
> > can provide data only in ATAG structure.
> 
> I'm using just mainline u-boot flashed as kernel for nolo that
> then loads the kernel.
> 
> For passing the board revision using the pass through u-boot
> is probably the best long term solution. U-boot can read the
> ATAGs from nolo and modify the .dtb for the revision
> information.
> 
> Are you saying there are some issues with that?
> 
> > > Or if you can think of some other way to get it, we can
> > > set system_rev in pdata-quirks.c.
> > > 
> > > Or maybe add some code to copy the ATAGs somewhere where
> > > they are out of the way and don't conflict with the device
> > > tree data? Then we can query ATAG_REVISION from
> > > pdata-quirks.c and set system_rev.
> > 
> > If we are able to read ATAG from pdata-quirks, then we can
> > parse it there and fix problems... But I do not know if
> > address of ATAG structure is available there...
> 
> Are there other ATAGs needed beyond the ATAG_REVISION?
> 
> Regards,
> 
> Tony

Ouch... Also ATAG_CMDLINE... which is probably reason why cmdline 
passed from bootloader is ignored.

-- 
Pali Roh?r
pali.rohar at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20141202/dba85c86/attachment-0001.sig>

[PATCH] ARM: OMAP2+: Warn about deprecated legacy booting mode

[Pavel Machek]

On Fri 2014-11-28 12:27:19, Tony Lindgren wrote:
> * Pali Roh?r <pali.rohar@gmail.com> [141127 03:34]:
> > On Thursday 27 November 2014 02:12:04 Tony Lindgren wrote:
> > > 
> > > Thinking about this probably the best long term solution is
> > > to pass optional board_revision in the kernel cmdline that
> > > can be parsed early and copied to system_rev variable.
> > > 
> > 
> > Not possible. Our bootloader is closed & proprietary. I tried to 
> > replace it with u-boot I was not able to do that. So we will use 
> > that Nokia closed bootloader forever and it can provide data only 
> > in ATAG structure.
> 
> I'm using just mainline u-boot flashed as kernel for nolo that
> then loads the kernel.
> 
> For passing the board revision using the pass through u-boot is
> probably the best long term solution. U-boot can read the ATAGs
> from nolo and modify the .dtb for the revision information.
> 
> Are you saying there are some issues with that?

Plenty :-).

Basically, u-boot is great for production (select one of kernels and
boot it), but pretty much unusable for development:

1) It does not support backlight, so you are interacting blind

2) Setup to load kernels over usb would probably be interesting

3) It makes kernel fail in interesting ways depending on phase of
moon.

Please, keep nolo supported. Debugging kernel & user space is bad,
debugging u-boot & kernel & user space would be even worse.

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[PATCH] ARM: OMAP2+: Warn about deprecated legacy booting mode

[Pali Rohár]

On Friday 28 November 2014 23:24:26 Tony Lindgren wrote:
> * Pali Roh?r <pali.rohar@gmail.com> [141128 13:43]:
> > On Friday 28 November 2014 21:27:19 Tony Lindgren wrote:
> > > Are you saying there are some issues with that?
> > 
> > uboot (in mode when is loaded from NOLO) has those issues:
> > 
> > 1) uboot cannot read n900 onenand mtd (uboot onenand driver
> > not working, do not know why)
> > 2) missing support for battery charging (can totally
> > discharge battery)
> > 3) missing support for panel panel (so sometimes screen is
> > totally black until kernel is booted and loaded own drivers)
> > 4) limit for storing both uboot and kernel into MTD is
> > limited by 2MB (size of kernel nand partition)
> > 
> > Basically you can use uboot if you accept all above issues.
> > 
> > But there are people (Pavel CCed) who prefer to work without
> > uboot when testing kernel. So it is not good idea to lock
> > new kernel versions to depends on new uboot version.
> 
> OK thanks for the update, I was not aware of the issues above.
> 
> > > Are there other ATAGs needed beyond the ATAG_REVISION?
> > 
> > Sorry for longer email. I will provide some more info about
> > it. First I will describe that informations are passed from
> > NOLO to kernel. Note that all those informations are passed
> > also from uboot to kernel (uboot just reuse non static data
> > from NOLO). Then I will describe that we need in userspace.
> 
> > Here are all ATAGs from NOLO:
> ...
> 
> These we should not need, it's all coming from the .dts files.
> 
> > 0036 - 0003:54410007 ATAG REVISION revision=00002204
> > 
> >        0588 - 000c:4f80 BOOTREASON:   pwr_key
> >        0604 - 0018:4f82 VERSION:      product      = RX-51
> >        0632 - 0018:4f82 VERSION:      hw-build     = 2204
> >        0660 - 0018:4f82 VERSION:      nolo         = 1.4.14
> >        0688 - 0018:4f82 VERSION:      boot-mode    = normal
> 
> Seems like these are the ones we should somehow get. The
> others should be coming in the .dts file already, or can be
> deciphered based on the above in the kernel.
> 
> > ATAG MEM is generated by NOLO and also uboot at runtime. But
> > we have hardcoded memory values in n900 DT file. Maybe we
> > should use those generated by uboot bootloader (or reuse
> > uboot code for generating) instead using hardcoded one?
> 
> Yes we should not need ATAG MEM.
> 
> > ATAG REVISION is that which is magically generated by NOLO
> > and which we want to reuse. Better would be understand how
> > and why it NOLO generate (maybe there is something secret
> > register which can tell it?). But I was not able to find
> > out it.
> 
> I would assume that's also somewhere in the cal area.
> 
> > OMAP table is one big ATAG structure which contains lot of
> > other values. Basically all values (except uart, bootreason
> > and version) are static and on all n900 devices are same.
> > 
> > Partitions are generated by NOLO from CAL (/dev/mtd1) data,
> > but I think nobody ever changed them (but it is possible!).
> 
> AFAIK it's safe to assume they are coming in the .dts file.
> 
> > Uart is enabled when serial console is enabled via NOLO.
> 
> We can keep the UART enabled all the time no problem. It's
> timeouts just need to be configured for idle.
> 
> > Bootreason contains omap3 bootreason value from special
> > register (plus magic from NOLO) which is cleared
> > automatically by NOLO (so no way to read it from kernel).
> > 
> > Version contains some key-value data. Product is always
> > RX-51, hw-build is same as ATAG REVISION, nolo is nolo
> > version and value for boot-mode is ether normal or update.
> 
> OK
> 
> > What we need in userspace:
> > 
> > In file /proc/cpuinfo:
> > Hardware        : Nokia RX-51 board
> > Revision        : <hw_revision_number>
> > 
> > And in any file and any format (does not matter if text,
> > binary, whatever...) we need value from bootreason,
> > boot-mode (and maybe nolo version).
> 
> OK
> 
> > Current maemo applications are using files /proc/bootreason
> > (for bootreason) and /proc/component_version (for all
> > version) which are specific for Nokia 2.6.28 kernel. All
> > those applications (which reading ether bootreason or
> > bootmode proc files) are either shell scripts or open
> > source, so editing them is possible. I will start fixing
> > them once there will be *stable* ABI for those data.
> > 
> > With non DT (legacy) boot all above atags are present in
> > binary file /proc/atags.
> > 
> > But because DT boot does not provide /proc/atags file I need
> > some interface how to read above needed strings.
> > 
> > So I would like to know what is possible and how?
> 
> How about patch things so we see /proc/atags also for DT based
> booting, but in a way where the ATAGs don't do anything?
> 
> > Does kernel provide some interface for telling userspace
> > applications something like bootreason (e.g power key,
> > software reset, rtc alarm, charger connected, ...)?
> 
> I don't think we have anything like that currently.
> 
> Regards,
> 
> Tony

Hi Tony,

see last mail in thread (I CCed you):
"[PATCH] ARM: /proc/cpuinfo: Use DT machine name when possible"

There is already some layer for converting ATAGs to DTB and it is 
in decompresser: arch/arm/boot/compressed/atags_to_fdt.c

I do not know if it can help us to provide /proc/cpuinfo and 
/proc/atags in DT boot, but at least this this transfer cmdline 
and mem ATAGs to DBT.

-- 
Pali Roh?r
pali.rohar at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20141204/980c7f52/attachment-0001.sig>

[PATCH] ARM: OMAP2+: Warn about deprecated legacy booting mode

[Tony Lindgren]

* Pali Roh?r <pali.rohar@gmail.com> [141204 10:36]:
> 
> see last mail in thread (I CCed you):
> "[PATCH] ARM: /proc/cpuinfo: Use DT machine name when possible"
> 
> There is already some layer for converting ATAGs to DTB and it is 
> in decompresser: arch/arm/boot/compressed/atags_to_fdt.c
> 
> I do not know if it can help us to provide /proc/cpuinfo and 
> /proc/atags in DT boot, but at least this this transfer cmdline 
> and mem ATAGs to DBT.

Yes that makes sense to me. Sorry forgot about that piece of
code as I have not tinkered with arch/arm/boot/compressed/*
for a few years.

It sounds like there may be some regression also if the cmdline
is not being passed like it already should. But I assume you
already figured that out and have some patches coming :)

Regards,

Tony

[PATCH] ARM: OMAP2+: Warn about deprecated legacy booting mode

[Pali Rohár]

On Thursday 04 December 2014 19:40:34 Tony Lindgren wrote:
> * Pali Roh?r <pali.rohar@gmail.com> [141204 10:36]:
> > see last mail in thread (I CCed you):
> > "[PATCH] ARM: /proc/cpuinfo: Use DT machine name when
> > possible"
> > 
> > There is already some layer for converting ATAGs to DTB and
> > it is in decompresser:
> > arch/arm/boot/compressed/atags_to_fdt.c
> > 
> > I do not know if it can help us to provide /proc/cpuinfo and
> > /proc/atags in DT boot, but at least this this transfer
> > cmdline and mem ATAGs to DBT.
> 
> Yes that makes sense to me. Sorry forgot about that piece of
> code as I have not tinkered with arch/arm/boot/compressed/*
> for a few years.
> 

I did not know about that code in compressed too...

> It sounds like there may be some regression also if the
> cmdline is not being passed like it already should. But I
> assume you already figured that out and have some patches
> coming :)
> 
> Regards,
> 
> Tony

I did not start find out why it not working (do not have time 
now), but at least I know where to start looking for it.

-- 
Pali Roh?r
pali.rohar at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20141204/8e596415/attachment.sig>