ARM: OMAP2+: Warn about deprecated legacy booting mode

Hi,

arch/arm/mach-omap2/omap_device.c static int __init omap_device_late_idle(struct device *dev, void *data) · line 923

Quoted 4 lines · Tony Lindgren

arch/arm/mach-omap2/omap_device.c +4 -0

+
+	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?

Quoted 9 lines · Aaro Koskinen

Hi,

arch/arm/mach-omap2/omap_device.c static int __init omap_device_late_idle(struct device *dev, void *data) · line 923

Quoted 4 lines · Tony Lindgren

arch/arm/mach-omap2/omap_device.c +4 -0

+
+	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?

Quoted 11 lines · Tony Lindgren

Quoted 9 lines · Aaro Koskinen

Hi,

arch/arm/mach-omap2/omap_device.c static int __init omap_device_late_idle(struct device *dev, void *data) · line 923

Quoted 4 lines · Tony Lindgren

arch/arm/mach-omap2/omap_device.c +4 -0

+
+	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?

Quoted 3 lines

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?

Hi,

Quoted 18 lines · Nishanth Menon

Quoted 11 lines · Tony Lindgren

Quoted 9 lines · Aaro Koskinen

Hi,

Review

Quoted 4 lines · Tony Lindgren

(quoted diff) +4 -0

+
+	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?

Quoted 3 lines

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.

Quoted 19 lines · Sebastian Reichel

Hi,

Quoted 16 lines · Nishanth Menon

Quoted 14 lines · Tony Lindgren

Quoted 9 lines · Aaro Koskinen

Hi,

arch/arm/mach-omap2/omap_device.c static int __init omap_device_late_idle(struct device *dev, void *data) · line 923

Quoted 4 lines · Tony Lindgren

arch/arm/mach-omap2/omap_device.c +4 -0

+
+	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?

Quoted 2 lines

Quoted 2 lines

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.

Quoted 26 lines · Tony Lindgren

Quoted 21 lines · Sebastian Reichel

Hi,

Quoted 18 lines · Nishanth Menon

Quoted 11 lines · Tony Lindgren

Quoted 9 lines · Aaro Koskinen

Hi,

arch/arm/mach-omap2/omap_device.c static int __init omap_device_late_idle(struct device *dev, void *data) · line 923

Quoted 4 lines · Tony Lindgren

arch/arm/mach-omap2/omap_device.c +4 -0

+
+	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?

Quoted 3 lines

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:

Quoted 2 lines

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.

Quoted 2 lines · Tony Lindgren

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.

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.

8< -----------------------
From: Tony Lindgren <[email protected]>
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 <[email protected]>

From: Tony Lindgren <[email protected]>
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 <[email protected]>

arch/arm/mach-omap2/omap_device.c +4 -0

@@ -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);

Quoted 13 lines · Tony Lindgren

From: Tony Lindgren <[email protected]>
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.

Quoted 5 lines

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 <[email protected]>

Reviewed-by Aaro Koskinen <[email protected]>

Hi,

arch/arm/mach-omap2/omap_device.c static int __init omap_device_late_idle(struct device *dev, void *data) · line 923

Quoted 4 lines · Tony Lindgren

arch/arm/mach-omap2/omap_device.c +4 -0

+
+	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?

Quoted 9 lines · Aaro Koskinen

Hi,

arch/arm/mach-omap2/omap_device.c static int __init omap_device_late_idle(struct device *dev, void *data) · line 923

Quoted 4 lines · Tony Lindgren

arch/arm/mach-omap2/omap_device.c +4 -0

+
+	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?

Quoted 4 lines · Pavel Machek

Quoted 3 lines · Aaro Koskinen

Hi,

On Mon, Oct 27, 2014 at 01:00:09PM -0700, Tony Lindgren

Quoted 12 lines

Quoted 7 lines

Quoted 4 lines

arch/arm/mach-omap2/omap_device.c +3 -0

+
+	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.

Quoted 1 line

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?

Quoted 2 lines

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

Quoted 6 lines · 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

Quoted 2 lines

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

Quoted 22 lines · Pali Roh?r

Quoted 4 lines · 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

Quoted 1 line

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

Quoted 4 lines

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

Quoted 28 lines · On Wednesday 26 November 2014 20:10:28 Tony Lindgren wrote:

Quoted 26 lines · Pali Roh?r

Quoted 4 lines · 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

Quoted 1 line

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

Quoted 3 lines

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).

Quoted 5 lines

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.

Quoted 3 lines · Pali Roh?r

Quoted 2 lines · On Wednesday 26 November 2014 20:10:28 Tony Lindgren wrote:

Quoted 1 line · Pali Roh?r

On Wednesday 26 November 2014 19:19:35 Tony Lindgren

Quoted 31 lines

Quoted 30 lines

Quoted 20 lines

Quoted 4 lines

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

Quoted 1 line

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:

Quoted 7 lines

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.

Quoted 3 lines

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?

Quoted 2 lines

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.

Quoted 11 lines

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).

Quoted 5 lines

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.

Quoted 3 lines

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

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.

Quoted 4 lines

Quoted 3 lines

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.

Quoted 5 lines

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...

Quoted 7 lines · Pali Roh?r

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? :)

Quoted 10 lines

Quoted 9 lines

Quoted 3 lines

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?

Quoted 2 lines

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

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

Quoted 3 lines

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.

Quoted 2 lines · Pali Roh?r

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

OK I guess it should not be needed for DT based booting.

Quoted 10 lines

Quoted 4 lines

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

Quoted 5 lines · 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.

Quoted 7 lines

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...

Quoted 6 lines · Pali Roh?r

Quoted 4 lines · 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.

Quoted 4 lines

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?

Quoted 11 lines

Quoted 7 lines

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

Quoted 1 line · 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.

Quoted 1 line

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:

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      

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, ...)?

Quoted 14 lines · Pali Roh?r

Quoted 1 line · 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)

Quoted 5 lines

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.

Quoted 9 lines

Quoted 1 line

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.

Quoted 7 lines

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.

Quoted 4 lines

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.

Quoted 5 lines

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.

Quoted 6 lines

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.

Quoted 1 line

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.

Quoted 7 lines

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

Quoted 9 lines

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

Quoted 11 lines

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.

Quoted 4 lines

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?

Quoted 3 lines

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

Quoted 14 lines · Pali Roh?r

Quoted 1 line · 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)

Quoted 5 lines

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.

Quoted 9 lines

Quoted 1 line

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.

Quoted 7 lines

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.

Quoted 4 lines

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.

Quoted 5 lines

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.

Quoted 6 lines

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.

Quoted 1 line

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.

Quoted 7 lines

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

Quoted 9 lines

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

Quoted 8 lines

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.

Quoted 7 lines

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?

Quoted 3 lines

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

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.

Quoted 8 lines · Pali Roh?r

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

Quoted 3 lines

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

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

Hi,

Quoted 3 lines · Pali Roh?r

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.

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)

Hi,

Quoted 6 lines · Pali Roh?r

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.

Quoted 8 lines · On Friday 28 November 2014 23:41:35 Aaro Koskinen wrote:

Quoted 6 lines · Pali Roh?r

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)

Quoted 3 lines

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.

Quoted 10 lines · Pali Roh?r

Quoted 4 lines · 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?

Quoted 11 lines

Quoted 7 lines

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

Quoted 11 lines · Pali Roh?r

Quoted 5 lines · 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?

Quoted 20 lines · Tony Lindgren

Quoted 11 lines · Pali Rohár

Quoted 6 lines · 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.

Quoted 1 line

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:

8< ------------
From: Tony Lindgren <[email protected]>
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 <[email protected]>

arch/arm/mach-omap2/board-generic.c +18 -0

@@ -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",

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.

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.

Quoted 3 lines · Russell King - ARM Linux

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.

Quoted 3 lines · Russell King - ARM Linux

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.

Quoted 24 lines

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

Quoted 4 lines

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?

Quoted 4 lines

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 :)

Quoted 3 lines

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?

Quoted 2 lines

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?

Quoted 1 line

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

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

Quoted 3 lines

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.

Quoted 11 lines

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

Quoted 7 lines

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

Quoted 8 lines

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.

Quoted 5 lines

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?

Quoted 11 lines · Tony Lindgren

Quoted 3 lines · Russell King - ARM Linux

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?

Quoted 2 lines

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

Quoted 1 line

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

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.

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.

Quoted 12 lines · Russell King - ARM Linux

Quoted 11 lines · Tony Lindgren

Quoted 3 lines · Russell King - ARM Linux

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?

Quoted 2 lines

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

Quoted 8 lines

Quoted 1 line

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

Quoted 5 lines · Tony Lindgren

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:

(quoted diff) +1 -1

-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.

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

Quoted 2 lines · Russell King - ARM Linux

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.