| Message ID | 201501262009.45854@pali (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Mon, Jan 26, 2015 at 1:09 PM, Pali Rohár <pali.rohar@gmail.com> wrote: > Ok, here is patch which set Revision field (global variable system_rev) in /proc/cpuinfo from DT > revision property: > > diff --git a/arch/arm/kernel/devtree.c b/arch/arm/kernel/devtree.c > index 11c54de..9946c1b 100644 > --- a/arch/arm/kernel/devtree.c > +++ b/arch/arm/kernel/devtree.c > @@ -19,6 +19,7 @@ > #include <linux/of_irq.h> > #include <linux/of_platform.h> > #include <linux/smp.h> > +#include <linux/libfdt_env.h> > > #include <asm/cputype.h> > #include <asm/setup.h> > @@ -26,6 +27,7 @@ > #include <asm/smp_plat.h> > #include <asm/mach/arch.h> > #include <asm/mach-types.h> > +#include <asm/system_info.h> > > > #ifdef CONFIG_SMP > @@ -204,6 +206,8 @@ static const void * __init arch_get_next_mach(const char *const **match) > const struct machine_desc * __init setup_machine_fdt(unsigned int dt_phys) > { > const struct machine_desc *mdesc, *mdesc_best = NULL; > + unsigned long dt_root; > + const u32 *prop; > > #ifdef CONFIG_ARCH_MULTIPLATFORM > DT_MACHINE_START(GENERIC_DT, "Generic DT based system") > @@ -215,17 +219,16 @@ const struct machine_desc * __init setup_machine_fdt(unsigned int dt_phys) > if (!dt_phys || !early_init_dt_verify(phys_to_virt(dt_phys))) > return NULL; > > + dt_root = of_get_flat_dt_root(); > mdesc = of_flat_dt_match_machine(mdesc_best, arch_get_next_mach); > > if (!mdesc) { > const char *prop; > int size; > - unsigned long dt_root; > > early_print("\nError: unrecognized/unsupported " > "device tree compatible list:\n[ "); > > - dt_root = of_get_flat_dt_root(); > prop = of_get_flat_dt_prop(dt_root, "compatible", &size); > while (size > 0) { > early_print("'%s' ", prop); > @@ -246,5 +249,10 @@ const struct machine_desc * __init setup_machine_fdt(unsigned int dt_phys) > /* Change machine number to match the mdesc we're using */ > __machine_arch_type = mdesc->nr; > > + /* Set system revision from DT */ > + prop = of_get_flat_dt_prop(dt_root, "revision", NULL); > + if (prop) > + system_rev = fdt32_to_cpu(*prop); > + > return mdesc; > } > > > And here is patch which convert ATAG revision into DT revision property and append it into DT in > decompress code: > > diff --git a/arch/arm/boot/compressed/atags_to_fdt.c b/arch/arm/boot/compressed/atags_to_fdt.c > index 9448aa0..e7e1cc9 100644 > --- a/arch/arm/boot/compressed/atags_to_fdt.c > +++ b/arch/arm/boot/compressed/atags_to_fdt.c > @@ -171,6 +171,8 @@ int atags_to_fdt(void *atag_list, void *fdt, int total_space) > cpu_to_fdt32(atag->u.mem.size); > } > > + } else if (atag->hdr.tag == ATAG_REVISION) { > + setprop_cell(fdt, "/", "revision", atag->u.revision.rev); > } else if (atag->hdr.tag == ATAG_INITRD2) { > uint32_t initrd_start, initrd_size; > initrd_start = atag->u.initrd.start; > > > I tested it on DT booted Nokia N900 and it is working, in /proc/cpuinfo is revision from ATAG. > > I do not know which DT property to use for storing HW Revision, so if "/revision" is not correct one, > let me know what to use instead. Also you can add my Signed-off-by for both patches. It is the correct property, but /revision in DT is a string. You need to add your own sign-off. Rob
Am 26.01.2015 um 20:09 schrieb Pali Rohár: > diff --git a/arch/arm/kernel/devtree.c b/arch/arm/kernel/devtree.c > index 11c54de..9946c1b 100644 > --- a/arch/arm/kernel/devtree.c > +++ b/arch/arm/kernel/devtree.c [...] > @@ -204,6 +206,8 @@ static const void * __init arch_get_next_mach(const char *const **match) > const struct machine_desc * __init setup_machine_fdt(unsigned int dt_phys) > { > const struct machine_desc *mdesc, *mdesc_best = NULL; > + unsigned long dt_root; > + const u32 *prop; > > #ifdef CONFIG_ARCH_MULTIPLATFORM > DT_MACHINE_START(GENERIC_DT, "Generic DT based system") > @@ -215,17 +219,16 @@ const struct machine_desc * __init setup_machine_fdt(unsigned int dt_phys) > if (!dt_phys || !early_init_dt_verify(phys_to_virt(dt_phys))) > return NULL; > > + dt_root = of_get_flat_dt_root(); > mdesc = of_flat_dt_match_machine(mdesc_best, arch_get_next_mach); > > if (!mdesc) { > const char *prop; Probably the use of two differently typed variables of name "prop" in this function is not intentional? Regards, Andreas > int size; > - unsigned long dt_root; > > early_print("\nError: unrecognized/unsupported " > "device tree compatible list:\n[ "); > > - dt_root = of_get_flat_dt_root(); > prop = of_get_flat_dt_prop(dt_root, "compatible", &size); > while (size > 0) { > early_print("'%s' ", prop); > @@ -246,5 +249,10 @@ const struct machine_desc * __init setup_machine_fdt(unsigned int dt_phys) > /* Change machine number to match the mdesc we're using */ > __machine_arch_type = mdesc->nr; > > + /* Set system revision from DT */ > + prop = of_get_flat_dt_prop(dt_root, "revision", NULL); > + if (prop) > + system_rev = fdt32_to_cpu(*prop); > + > return mdesc; > } [snip]
On Monday 26 January 2015 21:22:27 Rob Herring wrote: > On Mon, Jan 26, 2015 at 1:09 PM, Pali Rohár <pali.rohar@gmail.com> wrote: > > Ok, here is patch which set Revision field (global variable > > system_rev) in /proc/cpuinfo from DT revision property: > > > > diff --git a/arch/arm/kernel/devtree.c > > b/arch/arm/kernel/devtree.c index 11c54de..9946c1b 100644 > > --- a/arch/arm/kernel/devtree.c > > +++ b/arch/arm/kernel/devtree.c > > @@ -19,6 +19,7 @@ > > > > #include <linux/of_irq.h> > > #include <linux/of_platform.h> > > #include <linux/smp.h> > > > > +#include <linux/libfdt_env.h> > > > > #include <asm/cputype.h> > > #include <asm/setup.h> > > > > @@ -26,6 +27,7 @@ > > > > #include <asm/smp_plat.h> > > #include <asm/mach/arch.h> > > #include <asm/mach-types.h> > > > > +#include <asm/system_info.h> > > > > #ifdef CONFIG_SMP > > > > @@ -204,6 +206,8 @@ static const void * __init > > arch_get_next_mach(const char *const **match) > > > > const struct machine_desc * __init > > setup_machine_fdt(unsigned int dt_phys) { > > > > const struct machine_desc *mdesc, *mdesc_best = > > NULL; > > > > + unsigned long dt_root; > > + const u32 *prop; > > > > #ifdef CONFIG_ARCH_MULTIPLATFORM > > > > DT_MACHINE_START(GENERIC_DT, "Generic DT based > > system") > > > > @@ -215,17 +219,16 @@ const struct machine_desc * __init > > setup_machine_fdt(unsigned int dt_phys) > > > > if (!dt_phys || > > !early_init_dt_verify(phys_to_virt(dt_phys))) > > > > return NULL; > > > > + dt_root = of_get_flat_dt_root(); > > > > mdesc = of_flat_dt_match_machine(mdesc_best, > > arch_get_next_mach); > > > > if (!mdesc) { > > > > const char *prop; > > int size; > > > > - unsigned long dt_root; > > > > early_print("\nError: > > unrecognized/unsupported " > > > > "device tree compatible list:\n[ > > "); > > > > - dt_root = of_get_flat_dt_root(); > > > > prop = of_get_flat_dt_prop(dt_root, > > "compatible", &size); while (size > 0) { > > > > early_print("'%s' ", prop); > > > > @@ -246,5 +249,10 @@ const struct machine_desc * __init > > setup_machine_fdt(unsigned int dt_phys) > > > > /* Change machine number to match the mdesc we're > > using */ __machine_arch_type = mdesc->nr; > > > > + /* Set system revision from DT */ > > + prop = of_get_flat_dt_prop(dt_root, "revision", > > NULL); + if (prop) > > + system_rev = fdt32_to_cpu(*prop); > > + > > > > return mdesc; > > > > } > > > > And here is patch which convert ATAG revision into DT > > revision property and append it into DT in decompress code: > > > > diff --git a/arch/arm/boot/compressed/atags_to_fdt.c > > b/arch/arm/boot/compressed/atags_to_fdt.c index > > 9448aa0..e7e1cc9 100644 > > --- a/arch/arm/boot/compressed/atags_to_fdt.c > > +++ b/arch/arm/boot/compressed/atags_to_fdt.c > > @@ -171,6 +171,8 @@ int atags_to_fdt(void *atag_list, void > > *fdt, int total_space) > > > > cpu_to_fdt32(atag->u > > .mem.size); > > > > } > > > > + } else if (atag->hdr.tag == ATAG_REVISION) { > > + setprop_cell(fdt, "/", "revision", > > atag->u.revision.rev); > > > > } else if (atag->hdr.tag == ATAG_INITRD2) { > > > > uint32_t initrd_start, initrd_size; > > initrd_start = atag->u.initrd.start; > > > > I tested it on DT booted Nokia N900 and it is working, in > > /proc/cpuinfo is revision from ATAG. > > > > I do not know which DT property to use for storing HW > > Revision, so if "/revision" is not correct one, let me know > > what to use instead. Also you can add my Signed-off-by for > > both patches. > > It is the correct property, but /revision in DT is a string. > > You need to add your own sign-off. > > Rob Any documentation which says that /revision is string? If it is really string, how to store ATAG_REVISON (number) to string? dec or hex?
lOn Fri, Jan 30, 2015 at 8:14 AM, Pali Rohár <pali.rohar@gmail.com> wrote: > On Monday 26 January 2015 21:22:27 Rob Herring wrote: >> On Mon, Jan 26, 2015 at 1:09 PM, Pali Rohár > <pali.rohar@gmail.com> wrote: >> > Ok, here is patch which set Revision field (global variable >> > system_rev) in /proc/cpuinfo from DT revision property: [...] >> > I do not know which DT property to use for storing HW >> > Revision, so if "/revision" is not correct one, let me know >> > what to use instead. Also you can add my Signed-off-by for >> > both patches. >> >> It is the correct property, but /revision in DT is a string. >> >> You need to add your own sign-off. >> >> Rob > > Any documentation which says that /revision is string? Sorry, I was confusing this with serial-number, so I guess a number is fine here. > If it is really string, how to store ATAG_REVISON (number) to > string? dec or hex? However /proc/cpuinfo displays it would be fine if you stay with a string. Rob
On Friday 30 January 2015 22:03:36 Rob Herring wrote: > lOn Fri, Jan 30, 2015 at 8:14 AM, Pali Rohár <pali.rohar@gmail.com> wrote: > > On Monday 26 January 2015 21:22:27 Rob Herring wrote: > >> On Mon, Jan 26, 2015 at 1:09 PM, Pali Rohár > > > > <pali.rohar@gmail.com> wrote: > >> > Ok, here is patch which set Revision field (global > >> > variable > > >> > system_rev) in /proc/cpuinfo from DT revision property: > [...] > > >> > I do not know which DT property to use for storing HW > >> > Revision, so if "/revision" is not correct one, let me > >> > know what to use instead. Also you can add my > >> > Signed-off-by for both patches. > >> > >> It is the correct property, but /revision in DT is a > >> string. > >> > >> You need to add your own sign-off. > >> > >> Rob > > > > Any documentation which says that /revision is string? > > Sorry, I was confusing this with serial-number, so I guess a > number is fine here. > > > If it is really string, how to store ATAG_REVISON (number) > > to string? dec or hex? > > However /proc/cpuinfo displays it would be fine if you stay > with a string. > > Rob I will send new patch which will store number value as string. So same output will be in /proc/cpuinfo and in DT /revision.
This patch adds support for DT "/revision" and convert ATAG_REVISION to DT. Pali Rohár (2): arm: devtree: Set system_rev from DT revision arm: boot: convert ATAG_REVISION to DT revision field arch/arm/boot/compressed/atags_to_fdt.c | 37 +++++++++++++++++++++++++++++++ arch/arm/kernel/devtree.c | 20 ++++++++++++----- 2 files changed, 52 insertions(+), 5 deletions(-)
On Monday 26 January 2015 23:34:34 Andreas Färber wrote: > Am 26.01.2015 um 20:09 schrieb Pali Rohár: > > diff --git a/arch/arm/kernel/devtree.c > > b/arch/arm/kernel/devtree.c index 11c54de..9946c1b 100644 > > --- a/arch/arm/kernel/devtree.c > > +++ b/arch/arm/kernel/devtree.c > > [...] > > > @@ -204,6 +206,8 @@ static const void * __init > > arch_get_next_mach(const char *const **match) > > > > const struct machine_desc * __init > > setup_machine_fdt(unsigned int dt_phys) { > > > > const struct machine_desc *mdesc, *mdesc_best = NULL; > > > > + unsigned long dt_root; > > + const u32 *prop; > > > > #ifdef CONFIG_ARCH_MULTIPLATFORM > > > > DT_MACHINE_START(GENERIC_DT, "Generic DT based system") > > > > @@ -215,17 +219,16 @@ const struct machine_desc * __init > > setup_machine_fdt(unsigned int dt_phys) > > > > if (!dt_phys || > > !early_init_dt_verify(phys_to_virt(dt_phys))) > > > > return NULL; > > > > + dt_root = of_get_flat_dt_root(); > > > > mdesc = of_flat_dt_match_machine(mdesc_best, > > arch_get_next_mach); > > > > if (!mdesc) { > > > > const char *prop; > > Probably the use of two differently typed variables of name > "prop" in this function is not intentional? > Fixed in PATCH v2. > Regards, > Andreas > > > int size; > > > > - unsigned long dt_root; > > > > early_print("\nError: unrecognized/unsupported " > > > > "device tree compatible list:\n[ "); > > > > - dt_root = of_get_flat_dt_root(); > > > > prop = of_get_flat_dt_prop(dt_root, "compatible", &size); > > while (size > 0) { > > > > early_print("'%s' ", prop); > > > > @@ -246,5 +249,10 @@ const struct machine_desc * __init > > setup_machine_fdt(unsigned int dt_phys) > > > > /* Change machine number to match the mdesc we're using */ > > __machine_arch_type = mdesc->nr; > > > > + /* Set system revision from DT */ > > + prop = of_get_flat_dt_prop(dt_root, "revision", NULL); > > + if (prop) > > + system_rev = fdt32_to_cpu(*prop); > > + > > > > return mdesc; > > > > } > > [snip]
On Fri 2015-02-27 16:55:26, Pali Rohár wrote: > This patch adds support for DT "/revision" and convert ATAG_REVISION to DT. > > Pali Rohár (2): > arm: devtree: Set system_rev from DT revision > arm: boot: convert ATAG_REVISION to DT revision field Acked-by: Pavel Machek <pavel@ucw.cz>
* Pavel Machek <pavel@ucw.cz> [150302 03:32]: > On Fri 2015-02-27 16:55:26, Pali Rohár wrote: > > This patch adds support for DT "/revision" and convert ATAG_REVISION to DT. > > > > Pali Rohár (2): > > arm: devtree: Set system_rev from DT revision > > arm: boot: convert ATAG_REVISION to DT revision field > > Acked-by: Pavel Machek <pavel@ucw.cz> Are these queued somewhere now? Sounds like this is the last pending issue for n900 to use legacy user space with current mainline kernels, so I'd like to get these in so we can get closer to making omap3 boot in device tree only mode. Regards, Tony
On Mon, Mar 16, 2015 at 08:44:10AM -0700, Tony Lindgren wrote: > * Pavel Machek <pavel@ucw.cz> [150302 03:32]: > > On Fri 2015-02-27 16:55:26, Pali Rohár wrote: > > > This patch adds support for DT "/revision" and convert ATAG_REVISION to DT. > > > > > > Pali Rohár (2): > > > arm: devtree: Set system_rev from DT revision > > > arm: boot: convert ATAG_REVISION to DT revision field > > > > Acked-by: Pavel Machek <pavel@ucw.cz> > > Are these queued somewhere now? Sounds like this is the last pending > issue for n900 to use legacy user space with current mainline kernels, > so I'd like to get these in so we can get closer to making omap3 boot > in device tree only mode. Not that I know of. As everyone is aware, patches need to be in my patch system if they want me to apply them - which would've been especially important as I was away from kernel stuff for a week at the start of March (for medical reasons) and I can't be expected to track the status of stuff which is buried behind 1000+ extra mails. In any case, I'm currently not accepting /any/ patches into my tree at present; I'm chasing a horrid instability on one of my test platforms which is making it impossible to tell whether any particular change or changes in my tree is responsible or not for it. It doesn't seem to be a hardware failure (if it was, I'd simply take the board out of the nightly test system.) It's quite literally taking hours to figure out what's going on - I've been on this for about 12 hours now and still not much closer to knowing what's causing it (other than I know that -rc1 plus my queue seems to be fine, -rc3 plus my queue is definitely broken, -rc3 alone is fine. So something I'm already carrying seems to be responsible, but each time I identify a particular patch and drop _just_ that change, I find that the problem is back when I try my queue minus the bad changes. With a test cycle time of 20+ minutes (due to the number of boots required to make certain of a dependable result), this is /really/ slow progress. Right now, I can't be positively sure that /anything/ I have already merged isn't a factor in causing this problem, so I don't want to augment my tree with any additional patches which would upset my ability to move about in the tree, and get reproducable results from repeated testing. To merge something else will probably mean I'll have to start again from the beginning and the last 12 hours spent testing will have been wasted. Sorry.
On Mon, 16 Mar 2015, Russell King - ARM Linux wrote: > In any case, I'm currently not accepting /any/ patches into my tree at > present; I'm chasing a horrid instability on one of my test platforms > which is making it impossible to tell whether any particular change or > changes in my tree is responsible or not for it. It doesn't seem to be > a hardware failure (if it was, I'd simply take the board out of the > nightly test system.) > > It's quite literally taking hours to figure out what's going on - I've > been on this for about 12 hours now and still not much closer to knowing > what's causing it (other than I know that -rc1 plus my queue seems to be > fine, -rc3 plus my queue is definitely broken, -rc3 alone is fine. So > something I'm already carrying seems to be responsible, but each time I > identify a particular patch and drop _just_ that change, I find that the > problem is back when I try my queue minus the bad changes. With a test > cycle time of 20+ minutes (due to the number of boots required to make > certain of a dependable result), this is /really/ slow progress. > > Right now, I can't be positively sure that /anything/ I have already > merged isn't a factor in causing this problem, so I don't want to > augment my tree with any additional patches which would upset my > ability to move about in the tree, and get reproducable results from > repeated testing. To merge something else will probably mean I'll > have to start again from the beginning and the last 12 hours spent > testing will have been wasted. Your publicly visible tree contains only a few mundane patches. Is that the tree you're testing with? If no then could you publish it for others to have a look and test? Nicolas
* Russell King - ARM Linux <linux@arm.linux.org.uk> [150316 09:15]: > On Mon, Mar 16, 2015 at 08:44:10AM -0700, Tony Lindgren wrote: > > * Pavel Machek <pavel@ucw.cz> [150302 03:32]: > > > On Fri 2015-02-27 16:55:26, Pali Rohár wrote: > > > > This patch adds support for DT "/revision" and convert ATAG_REVISION to DT. > > > > > > > > Pali Rohár (2): > > > > arm: devtree: Set system_rev from DT revision > > > > arm: boot: convert ATAG_REVISION to DT revision field > > > > > > Acked-by: Pavel Machek <pavel@ucw.cz> > > > > Are these queued somewhere now? Sounds like this is the last pending > > issue for n900 to use legacy user space with current mainline kernels, > > so I'd like to get these in so we can get closer to making omap3 boot > > in device tree only mode. > > Not that I know of. As everyone is aware, patches need to be in my > patch system if they want me to apply them - which would've been > especially important as I was away from kernel stuff for a week at > the start of March (for medical reasons) and I can't be expected to > track the status of stuff which is buried behind 1000+ extra mails. Pali, care to upload these two patches to Russell's patch tracking system if no other comments? > In any case, I'm currently not accepting /any/ patches into my tree at > present; I'm chasing a horrid instability on one of my test platforms > which is making it impossible to tell whether any particular change or > changes in my tree is responsible or not for it. It doesn't seem to be > a hardware failure (if it was, I'd simply take the board out of the > nightly test system.) > > It's quite literally taking hours to figure out what's going on - I've > been on this for about 12 hours now and still not much closer to knowing > what's causing it (other than I know that -rc1 plus my queue seems to be > fine, -rc3 plus my queue is definitely broken, -rc3 alone is fine. So > something I'm already carrying seems to be responsible, but each time I > identify a particular patch and drop _just_ that change, I find that the > problem is back when I try my queue minus the bad changes. With a test > cycle time of 20+ minutes (due to the number of boots required to make > certain of a dependable result), this is /really/ slow progress. > > Right now, I can't be positively sure that /anything/ I have already > merged isn't a factor in causing this problem, so I don't want to > augment my tree with any additional patches which would upset my > ability to move about in the tree, and get reproducable results from > repeated testing. To merge something else will probably mean I'll > have to start again from the beginning and the last 12 hours spent > testing will have been wasted. Oh debugging those things sucks. Maybe try with CONFIG_DEBUG_SLAB to see if you trigger any poison. Regards, Tony
On Mon, Mar 16, 2015 at 12:43:47PM -0400, Nicolas Pitre wrote: > Your publicly visible tree contains only a few mundane patches. > Is that the tree you're testing with? If no then could you publish it > for others to have a look and test? Okay, having investigated three cases of this, ended up mostly at dead-ends, and having talked to Will, I think the conclusion is that no one really understands what's going on here. :p A number of people (including people within ARM) have seen the problem that I've seen with a variety of kernel versions, including versions which I haven't seen a problem with. My own investigations turn up patches which don't have that much to do with the SMP booting itself: yes, one was a L2C patch, but I've had that for a very long time. The FIQ changes for the GIC which shouldn't have affected it. Olof's MMC patches to support resets and regulators which we don't even get to, so couldn't affect it /code-wise/. What all these have in common is an influence on the layout of the kernel image. Exactly what that is, I don't know yet - I've not had the time to be able to investigate that deeply as I've been trying to characterise the failure and track it down to an easy "this works, this doesn't" test case. I now have that with a kernel without MMC changes vs a kernel with MMC changes - where I know that the actual changes have nothing to do with the problem itself. There's only one person (not me) who has been able to get a reasonable amount of debug so far - Sudeep (@arm) has found that both CPU0 and CPU1 are stuck in the radix code, but merely using the debugger "frees" them from there. Now that I'm aware that _others_ are or have seen the same issue I am, I can worry slightly less about the issue... and what it confirms to me is that it's less about what the kernel code is, more about the placement of kernel code. The unfortunate side effect is that it cuts down on the amount of useful testing I can do prior to sending stuff to Linus... but C'est la vie.
On Mon, Mar 16, 2015 at 11:10:26AM -0700, Tony Lindgren wrote: > * Russell King - ARM Linux <linux@arm.linux.org.uk> [150316 09:15]: > > On Mon, Mar 16, 2015 at 08:44:10AM -0700, Tony Lindgren wrote: > > > * Pavel Machek <pavel@ucw.cz> [150302 03:32]: > > > > On Fri 2015-02-27 16:55:26, Pali Rohár wrote: > > > > > This patch adds support for DT "/revision" and convert ATAG_REVISION to DT. > > > > > > > > > > Pali Rohár (2): > > > > > arm: devtree: Set system_rev from DT revision > > > > > arm: boot: convert ATAG_REVISION to DT revision field > > > > > > > > Acked-by: Pavel Machek <pavel@ucw.cz> > > > > > > Are these queued somewhere now? Sounds like this is the last pending > > > issue for n900 to use legacy user space with current mainline kernels, > > > so I'd like to get these in so we can get closer to making omap3 boot > > > in device tree only mode. > > > > Not that I know of. As everyone is aware, patches need to be in my > > patch system if they want me to apply them - which would've been > > especially important as I was away from kernel stuff for a week at > > the start of March (for medical reasons) and I can't be expected to > > track the status of stuff which is buried behind 1000+ extra mails. > > Pali, care to upload these two patches to Russell's patch tracking > system if no other comments? If it's done soon, I should be able to send them to Linus fairly quickly, since this problem I'm grappling with is being seen by others who have better tools to be able to investigate the problem (and hence they're in a better position to investigate what's going on.)
On Monday 16 March 2015 20:59:04 Russell King - ARM Linux wrote: > On Mon, Mar 16, 2015 at 11:10:26AM -0700, Tony Lindgren wrote: > > * Russell King - ARM Linux <linux@arm.linux.org.uk> [150316 > > 09:15]: > > > On Mon, Mar 16, 2015 at 08:44:10AM -0700, Tony Lindgren > > > wrote: > > > > * Pavel Machek <pavel@ucw.cz> [150302 03:32]: > > > > > On Fri 2015-02-27 16:55:26, Pali Rohár wrote: > > > > > > This patch adds support for DT "/revision" and > > > > > > convert ATAG_REVISION to DT. > > > > > > > > > > > > Pali Rohár (2): > > > > > > arm: devtree: Set system_rev from DT revision > > > > > > arm: boot: convert ATAG_REVISION to DT revision > > > > > > field > > > > > > > > > > Acked-by: Pavel Machek <pavel@ucw.cz> > > > > > > > > Are these queued somewhere now? Sounds like this is the > > > > last pending issue for n900 to use legacy user space > > > > with current mainline kernels, so I'd like to get these > > > > in so we can get closer to making omap3 boot in device > > > > tree only mode. > > > > > > Not that I know of. As everyone is aware, patches need to > > > be in my patch system if they want me to apply them - > > > which would've been especially important as I was away > > > from kernel stuff for a week at the start of March (for > > > medical reasons) and I can't be expected to track the > > > status of stuff which is buried behind 1000+ extra mails. > > > > Pali, care to upload these two patches to Russell's patch > > tracking system if no other comments? > > If it's done soon, I should be able to send them to Linus > fairly quickly, since this problem I'm grappling with is > being seen by others who have better tools to be able to > investigate the problem (and hence they're in a better > position to investigate what's going on.) I have no idea how to upload those patches into tracking system. Right now I do not have enough time for testing any patches... Tony, or somebody else, if you have free time, can you upload (my) patches to that needed tracking system?
* Pali Rohár <pali.rohar@gmail.com> [150316 13:54]: > On Monday 16 March 2015 20:59:04 Russell King - ARM Linux wrote: > > On Mon, Mar 16, 2015 at 11:10:26AM -0700, Tony Lindgren wrote: > > > * Russell King - ARM Linux <linux@arm.linux.org.uk> [150316 > > > 09:15]: > > > > On Mon, Mar 16, 2015 at 08:44:10AM -0700, Tony Lindgren > > > > wrote: > > > > > * Pavel Machek <pavel@ucw.cz> [150302 03:32]: > > > > > > On Fri 2015-02-27 16:55:26, Pali Rohár wrote: > > > > > > > This patch adds support for DT "/revision" and > > > > > > > convert ATAG_REVISION to DT. > > > > > > > > > > > > > > Pali Rohár (2): > > > > > > > arm: devtree: Set system_rev from DT revision > > > > > > > arm: boot: convert ATAG_REVISION to DT revision > > > > > > > field > > > > > > > > > > > > Acked-by: Pavel Machek <pavel@ucw.cz> > > > > > > > > > > Are these queued somewhere now? Sounds like this is the > > > > > last pending issue for n900 to use legacy user space > > > > > with current mainline kernels, so I'd like to get these > > > > > in so we can get closer to making omap3 boot in device > > > > > tree only mode. > > > > > > > > Not that I know of. As everyone is aware, patches need to > > > > be in my patch system if they want me to apply them - > > > > which would've been especially important as I was away > > > > from kernel stuff for a week at the start of March (for > > > > medical reasons) and I can't be expected to track the > > > > status of stuff which is buried behind 1000+ extra mails. > > > > > > Pali, care to upload these two patches to Russell's patch > > > tracking system if no other comments? > > > > If it's done soon, I should be able to send them to Linus > > fairly quickly, since this problem I'm grappling with is > > being seen by others who have better tools to be able to > > investigate the problem (and hence they're in a better > > position to investigate what's going on.) > > I have no idea how to upload those patches into tracking system. > Right now I do not have enough time for testing any patches... Well it's pretty easy, all you have to do is upload them to: http://www.arm.linux.org.uk/developer/patches/ There's an email interface it too. > Tony, or somebody else, if you have free time, can you upload > (my) patches to that needed tracking system? Eeek, I'm swamped too, probably best that you do it yourself since they're your patches. Regards, Tony
diff --git a/arch/arm/kernel/devtree.c b/arch/arm/kernel/devtree.c index 11c54de..9946c1b 100644 --- a/arch/arm/kernel/devtree.c +++ b/arch/arm/kernel/devtree.c @@ -19,6 +19,7 @@ #include <linux/of_irq.h> #include <linux/of_platform.h> #include <linux/smp.h> +#include <linux/libfdt_env.h> #include <asm/cputype.h> #include <asm/setup.h> @@ -26,6 +27,7 @@ #include <asm/smp_plat.h> #include <asm/mach/arch.h> #include <asm/mach-types.h> +#include <asm/system_info.h> #ifdef CONFIG_SMP @@ -204,6 +206,8 @@ static const void * __init arch_get_next_mach(const char *const **match) const struct machine_desc * __init setup_machine_fdt(unsigned int dt_phys) { const struct machine_desc *mdesc, *mdesc_best = NULL; + unsigned long dt_root; + const u32 *prop; #ifdef CONFIG_ARCH_MULTIPLATFORM DT_MACHINE_START(GENERIC_DT, "Generic DT based system") @@ -215,17 +219,16 @@ const struct machine_desc * __init setup_machine_fdt(unsigned int dt_phys) if (!dt_phys || !early_init_dt_verify(phys_to_virt(dt_phys))) return NULL; + dt_root = of_get_flat_dt_root(); mdesc = of_flat_dt_match_machine(mdesc_best, arch_get_next_mach); if (!mdesc) { const char *prop; int size; - unsigned long dt_root; early_print("\nError: unrecognized/unsupported " "device tree compatible list:\n[ "); - dt_root = of_get_flat_dt_root(); prop = of_get_flat_dt_prop(dt_root, "compatible", &size); while (size > 0) { early_print("'%s' ", prop); @@ -246,5 +249,10 @@ const struct machine_desc * __init setup_machine_fdt(unsigned int dt_phys) /* Change machine number to match the mdesc we're using */ __machine_arch_type = mdesc->nr; + /* Set system revision from DT */ + prop = of_get_flat_dt_prop(dt_root, "revision", NULL); + if (prop) + system_rev = fdt32_to_cpu(*prop); + return mdesc; } And here is patch which convert ATAG revision into DT revision property and append it into DT in decompress code: diff --git a/arch/arm/boot/compressed/atags_to_fdt.c b/arch/arm/boot/compressed/atags_to_fdt.c index 9448aa0..e7e1cc9 100644 --- a/arch/arm/boot/compressed/atags_to_fdt.c +++ b/arch/arm/boot/compressed/atags_to_fdt.c @@ -171,6 +171,8 @@ int atags_to_fdt(void *atag_list, void *fdt, int total_space) cpu_to_fdt32(atag->u.mem.size); } + } else if (atag->hdr.tag == ATAG_REVISION) { + setprop_cell(fdt, "/", "revision", atag->u.revision.rev); } else if (atag->hdr.tag == ATAG_INITRD2) { uint32_t initrd_start, initrd_size; initrd_start = atag->u.initrd.start;