| Message ID | 20141126200806.GO2817@atomide.com |
|---|---|
| State | New |
| Headers | show |
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@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
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@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
> 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",
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@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
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@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, 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.
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.
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...
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 :-(
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.
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.
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.
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
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@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
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.
--- 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",