XIP_KERNEL and !ARCH_MULTIPLATFORM

XIP_KERNEL and !ARCH_MULTIPLATFORM

[Chris Brandt]

I've been running XIP_KERNEL with linux-3.14 on a Renesas RZ/A1 (ARCH_R7S72100) for a while now (with some bug fixes of course) so I thought I'd see if my fixes should be pushed back upstream.

However, I see that all the Renesas parts are being moved to ARCH_MULTIPLATFORM, which by means of arch/arm/Kconfig disallows XIP_KERNEL.

Looking back through the mailing list archives I see that there was some discussion on this, but never really a conclusion.

So my question is basically: What is the correct configuration to use XIP_KERNEL with a Renesas SoC? Is the idea that I need to go carve up my own config and do everything outside the normal tree from here on out?

Thanks,
Chris

XIP_KERNEL and !ARCH_MULTIPLATFORM

[Chris Brandt]

I've been running XIP_KERNEL with linux-3.14 on a Renesas RZ/A1 (ARCH_R7S72100) for a while now (with some bug fixes of course) so I thought I'd see if my fixes should be pushed back upstream.

However, I see that all the Renesas parts are being moved to ARCH_MULTIPLATFORM, which by means of arch/arm/Kconfig disallows XIP_KERNEL.

Looking back through the mailing list archives I see that there was some discussion on this, but never really a conclusion.

So my question is basically: What is the correct configuration to use XIP_KERNEL with a Renesas SoC? Is the idea that I need to go carve up my own config and do everything outside the normal tree from here on out?

Thanks,
Chris

Re: XIP_KERNEL and !ARCH_MULTIPLATFORM

[Russell King - ARM Linux]

On Tue, Mar 17, 2015 at 03:48:38AM +0000, Chris Brandt wrote:
> I've been running XIP_KERNEL with linux-3.14 on a Renesas RZ/A1 (ARCH_R7S72100) for a while now (with some bug fixes of course) so I thought I'd see if my fixes should be pushed back upstream.
> 
> However, I see that all the Renesas parts are being moved to ARCH_MULTIPLATFORM, which by means of arch/arm/Kconfig disallows XIP_KERNEL.
> 
> Looking back through the mailing list archives I see that there was some discussion on this, but never really a conclusion.
> 
> So my question is basically: What is the correct configuration to use XIP_KERNEL with a Renesas SoC? Is the idea that I need to go carve up my own config and do everything outside the normal tree from here on out?

I think we need to re-think our Kconfig approach towards multiplatform.

As seems to be far too common, we charge headlong towards some wonderful
modern structure and decide that the old structure is plainly bad and
somehow disgusting.  While I can see that reasoning, in part in this
instance that was due to XIP not seeming to have many users (and its
only users were old platforms which were never really going to convert to
multiplatform) so it did seem sane to disallow XIP.

One thing which the whole multiplatform/DT project has taught me though
is that the above approach is virtually always wrong.  We've run into it
over ATAGs and we've run into it over Kconfig symbols.  The "eww, legacy,
that's disgusting" crap really needs to stop and a more balanced view is
necessary.  What we _should_ be doing (imho) is celebrating legacy stuff.
It's what got us to where we are today.  More importantly though, when it
was written, it was written with the same intentions that we write modern
code.  What we view today as wonderful code will be tomorrow's legacy code,
and we'll probably be going "eww, legacy" at it again!

We've run into the need a few times now to allow a SoC family converted to
multiplatform to also be chosen using the previous non-multiplatform
behaviour.

What I believe is that rather than ripping out the old platform choices,
we should have augmented them with the multiplatform support instead.
We could then make the big choice statement either include a multiplatform
option, or we could disable it when multiplatform was enabled.  More
importantly, we would still have the ability to turn multiplatform off
and target just one SoC family along with allowing things like XIP.

Yes, it would've been slightly longer winded to achieve, but it's do-able.

1. Convert all choice config symbols to (ARCH|MACH)_SP_foo.
2. Convert all multiplatform config symbols to (ARCH|MACH)_MP_foo.
3. Add (ARCH|MACH)_foo which would be selected by the corresponding above
   two symbols.

We then have a way to either select a SoC family as part of the multi
platform project, or as a stand-alone platform for things like old noMMU
and XIP.

The problem with this approach is we end up breaking everyone's config
file - because "make oldconfig" has no way to work out that it a
reference to ARCH_foo should select ARCH_[MS]P_foo instead - so we'd end
up with no platforms selected.  That can be worked around with a
progressive approach to converting this stuff in a way that ensures we
gain the new symbols in people's defconfigs before we switch things
around.

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

XIP_KERNEL and !ARCH_MULTIPLATFORM

[Russell King - ARM Linux]

On Tue, Mar 17, 2015 at 03:48:38AM +0000, Chris Brandt wrote:
> I've been running XIP_KERNEL with linux-3.14 on a Renesas RZ/A1 (ARCH_R7S72100) for a while now (with some bug fixes of course) so I thought I'd see if my fixes should be pushed back upstream.
> 
> However, I see that all the Renesas parts are being moved to ARCH_MULTIPLATFORM, which by means of arch/arm/Kconfig disallows XIP_KERNEL.
> 
> Looking back through the mailing list archives I see that there was some discussion on this, but never really a conclusion.
> 
> So my question is basically: What is the correct configuration to use XIP_KERNEL with a Renesas SoC? Is the idea that I need to go carve up my own config and do everything outside the normal tree from here on out?

I think we need to re-think our Kconfig approach towards multiplatform.

As seems to be far too common, we charge headlong towards some wonderful
modern structure and decide that the old structure is plainly bad and
somehow disgusting.  While I can see that reasoning, in part in this
instance that was due to XIP not seeming to have many users (and its
only users were old platforms which were never really going to convert to
multiplatform) so it did seem sane to disallow XIP.

One thing which the whole multiplatform/DT project has taught me though
is that the above approach is virtually always wrong.  We've run into it
over ATAGs and we've run into it over Kconfig symbols.  The "eww, legacy,
that's disgusting" crap really needs to stop and a more balanced view is
necessary.  What we _should_ be doing (imho) is celebrating legacy stuff.
It's what got us to where we are today.  More importantly though, when it
was written, it was written with the same intentions that we write modern
code.  What we view today as wonderful code will be tomorrow's legacy code,
and we'll probably be going "eww, legacy" at it again!

We've run into the need a few times now to allow a SoC family converted to
multiplatform to also be chosen using the previous non-multiplatform
behaviour.

What I believe is that rather than ripping out the old platform choices,
we should have augmented them with the multiplatform support instead.
We could then make the big choice statement either include a multiplatform
option, or we could disable it when multiplatform was enabled.  More
importantly, we would still have the ability to turn multiplatform off
and target just one SoC family along with allowing things like XIP.

Yes, it would've been slightly longer winded to achieve, but it's do-able.

1. Convert all choice config symbols to (ARCH|MACH)_SP_foo.
2. Convert all multiplatform config symbols to (ARCH|MACH)_MP_foo.
3. Add (ARCH|MACH)_foo which would be selected by the corresponding above
   two symbols.

We then have a way to either select a SoC family as part of the multi
platform project, or as a stand-alone platform for things like old noMMU
and XIP.

The problem with this approach is we end up breaking everyone's config
file - because "make oldconfig" has no way to work out that it a
reference to ARCH_foo should select ARCH_[MS]P_foo instead - so we'd end
up with no platforms selected.  That can be worked around with a
progressive approach to converting this stuff in a way that ensures we
gain the new symbols in people's defconfigs before we switch things
around.

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

Re: XIP_KERNEL and !ARCH_MULTIPLATFORM

[Geert Uytterhoeven]

Hi Chris,

On Tue, Mar 17, 2015 at 4:48 AM, Chris Brandt <Chris.Brandt@renesas.com> wrote:
> I've been running XIP_KERNEL with linux-3.14 on a Renesas RZ/A1 (ARCH_R7S72100) for a while now (with some bug fixes of course) so I thought I'd see if my fixes should be pushed back upstream.
>
> However, I see that all the Renesas parts are being moved to ARCH_MULTIPLATFORM, which by means of arch/arm/Kconfig disallows XIP_KERNEL.
>
> Looking back through the mailing list archives I see that there was some discussion on this, but never really a conclusion.
>
> So my question is basically: What is the correct configuration to use XIP_KERNEL with a Renesas SoC? Is the idea that I need to go carve up my own config and do everything outside the normal tree from here on out?

The issue you're facing is that ARCH_MULTIPLATFORM actually means two things:
  1. Use modern infrastructure (e.g. DT, CCF, GPIOLIB, ...) instead of board
     files with platform devices,
  2. Allow to build a single kernel that supports multiple SoC families and/or
     boards.

The first thing is not incompatible with XIP_KERNEL (AFAIK), the second is
(or rather, may be?).

Perhaps ARCH_MULTIPLATFORM should be replaced by ARCH_ARM_NEWWORLD
almost everywhere, and (new) ARCH_MULTIPLATFORM should be reserved
(if needed at all) to protect features that are not compatible with running on
multiple machines?

Besides, I think a multi-platform XIP (or nommu) kernel is possible, as long
as XIP_PHYS_ADDR (or PHYS_OFFSET) is suitable for all platforms included.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

XIP_KERNEL and !ARCH_MULTIPLATFORM

[Geert Uytterhoeven]

Hi Chris,

On Tue, Mar 17, 2015 at 4:48 AM, Chris Brandt <Chris.Brandt@renesas.com> wrote:
> I've been running XIP_KERNEL with linux-3.14 on a Renesas RZ/A1 (ARCH_R7S72100) for a while now (with some bug fixes of course) so I thought I'd see if my fixes should be pushed back upstream.
>
> However, I see that all the Renesas parts are being moved to ARCH_MULTIPLATFORM, which by means of arch/arm/Kconfig disallows XIP_KERNEL.
>
> Looking back through the mailing list archives I see that there was some discussion on this, but never really a conclusion.
>
> So my question is basically: What is the correct configuration to use XIP_KERNEL with a Renesas SoC? Is the idea that I need to go carve up my own config and do everything outside the normal tree from here on out?

The issue you're facing is that ARCH_MULTIPLATFORM actually means two things:
  1. Use modern infrastructure (e.g. DT, CCF, GPIOLIB, ...) instead of board
     files with platform devices,
  2. Allow to build a single kernel that supports multiple SoC families and/or
     boards.

The first thing is not incompatible with XIP_KERNEL (AFAIK), the second is
(or rather, may be?).

Perhaps ARCH_MULTIPLATFORM should be replaced by ARCH_ARM_NEWWORLD
almost everywhere, and (new) ARCH_MULTIPLATFORM should be reserved
(if needed at all) to protect features that are not compatible with running on
multiple machines?

Besides, I think a multi-platform XIP (or nommu) kernel is possible, as long
as XIP_PHYS_ADDR (or PHYS_OFFSET) is suitable for all platforms included.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

RE: XIP_KERNEL and !ARCH_MULTIPLATFORM

[Chris Brandt]

>  While I can see that reasoning, in part in this instance that was due to XIP not seeming to have many users (and its only users were old platforms...

I would say XIP has just been waiting for the right part to come alone. The ARCH_R7S72100 has 10MB of internal RAM and can execute directly from external Quad-SPI flash (no DDR, no NOR).
I also dusted off the Advanced XIP File System (AXFS) so now userland uses as little RAM as possible as well.

> We've run into the need a few times now to allow a SoC family converted to multiplatform to also be chosen using the previous non-multiplatform behaviour.

If Linux only ran on PCs, then maybe this wouldn't be such an issue. But with Linux on an SoC, you can (and should) get creative with what you are making. ARCH_MULTIPLATFORM seems to suppress that.

> What I believe is that rather than ripping out the old platform choices, we should have augmented them with the multiplatform support instead

Agreed.

> One thing which the whole multiplatform/DT project has taught me though is that the above approach is virtually always wrong

The one nice thing DT does is clean up and consolidate the mundane stuff in the board file, but that didn't mean I wanted you to take the board file completely away from me.

> That can be worked around with a progressive approach to converting this stuff in a way that ensures we gain the new symbols in people's defconfigs before we switch things around.

Since either way this sounds like a long process, and I still want to see if I can get XIP working with the latest kernel, will you accept patches on something that can't be built with the current architecture?
 
Chris

XIP_KERNEL and !ARCH_MULTIPLATFORM

[Chris Brandt]

>  While I can see that reasoning, in part in this instance that was due to XIP not seeming to have many users (and its only users were old platforms...

I would say XIP has just been waiting for the right part to come alone. The ARCH_R7S72100 has 10MB of internal RAM and can execute directly from external Quad-SPI flash (no DDR, no NOR).
I also dusted off the Advanced XIP File System (AXFS) so now userland uses as little RAM as possible as well.

> We've run into the need a few times now to allow a SoC family converted to multiplatform to also be chosen using the previous non-multiplatform behaviour.

If Linux only ran on PCs, then maybe this wouldn't be such an issue. But with Linux on an SoC, you can (and should) get creative with what you are making. ARCH_MULTIPLATFORM seems to suppress that.

> What I believe is that rather than ripping out the old platform choices, we should have augmented them with the multiplatform support instead

Agreed.

> One thing which the whole multiplatform/DT project has taught me though is that the above approach is virtually always wrong

The one nice thing DT does is clean up and consolidate the mundane stuff in the board file, but that didn't mean I wanted you to take the board file completely away from me.

> That can be worked around with a progressive approach to converting this stuff in a way that ensures we gain the new symbols in people's defconfigs before we switch things around.

Since either way this sounds like a long process, and I still want to see if I can get XIP working with the latest kernel, will you accept patches on something that can't be built with the current architecture?
 
Chris

RE: XIP_KERNEL and !ARCH_MULTIPLATFORM

[Chris Brandt]

SGkgR2VlcnQsDQoNCj4gQmVzaWRlcywgSSB0aGluayBhIG11bHRpLXBsYXRmb3JtIFhJUCAob3Ig
bm9tbXUpIGtlcm5lbCBpcyBwb3NzaWJsZSwgYXMgbG9uZyBhcyBYSVBfUEhZU19BRERSIChvciBQ
SFlTX09GRlNFVCkgaXMgc3VpdGFibGUgZm9yIGFsbCBwbGF0Zm9ybXMgaW5jbHVkZWQNCg0KUG9z
c2libGUuLi5idXQuLi5tYXliZSBwb2ludGxlc3MuIElmIHlvdSdyZSBkb2luZyBYSVAsIHRoZW4g
bW9zdCBsaWtlbHkgeW91J3ZlIGdvdCBhIHNwZWNpZmljIHBsYXRmb3JtIHRoYXQgeW91IGFyZSB0
cnlpbmcgdG8gZG8gYXMgbXVjaCBhcyB5b3UgY2FuIGluIGFzIGxpdHRsZSAoUkFNKSBhcyBwb3Nz
aWJsZS4NCg0KV2FzIEFSQ0hfTVVMVElQTEFURk9STSByZWFsbHkgdHJ5aW5nIHRvIGZpeCBzb21l
IGh1Z2UgZXhpc3RpbmcgcHJvYmxlbT8gT3Igd2FzIGl0IG1vcmUgb2YgYSAnaGVyZSdzIGEgY3V0
ZSB0aGluZyB3ZSBjb3VsZCBkbyc/DQpJbiBteSBtaW5kLCBhbiBTb0MgYnkgbmF0dXJlIGlzIHVz
ZWQgZm9yIHNwZWNpZmljIGVtYmVkZGVkIHByb2R1Y3QgYW5kIHlvdSBjb3VsZCBjYXJlIGxlc3Mg
aWYgdGhlIGJpbmFyeSBydW5zIG9uIGFueXRoaW5nIGVsc2UuIE9mIGNvdXJzZSB0aGUgcmFuZ2Ug
b2YgU29DcyB0aGF0IGNhbiBydW4gTGludXggbm93IGEgZGF5cyB2YXJpZXMgZ3JlYXRseSwgc28g
SSBkb24ndCB0aGluayB5b3UgY2FuIHB1dCB0aGVtIGFsbCBpbiB0aGUgc2FtZSBjYXRlZ29yeSBs
aWtlIEFSQ0hfTVVMVElQTEFURk9STSB3YXMgdHJ5aW5nIHRvIGRvLg0KDQoNCj4gUGVyaGFwcyBB
UkNIX01VTFRJUExBVEZPUk0gc2hvdWxkIGJlIHJlcGxhY2VkIGJ5IEFSQ0hfQVJNX05FV1dPUkxE
IGFsbW9zdCBldmVyeXdoZXJlLCBhbmQgKG5ldykgQVJDSF9NVUxUSVBMQVRGT1JNIHNob3VsZCBi
ZSByZXNlcnZlZCAoaWYgbmVlZGVkIGF0IGFsbCkgdG8gcHJvdGVjdCBmZWF0dXJlcyB0aGF0IGFy
ZSBub3QgY29tcGF0aWJsZSB3aXRoIHJ1bm5pbmcgb24gbXVsdGlwbGUgbWFjaGluZXM/DQoNClRo
YXQncyBub3QgYmFkLiBJIHRoaW5rIGl0IHN0aWxsIGNvbWVzIGRvd24gdG8gaWYgeW91IHdhbnQg
dG8gYnVpbGQgWElQLCB5b3UgZG9uJ3QgY2FyZSBhYm91dCBBUkNIX01VTFRJUExBVEZPUk0gc3Vw
cG9ydCwgYW5kIHRoZSBYSVBfUEhZU19BRERSIChhbmQgUEhZU19PRkZTRVQpIHlvdSBuZWVkIHRv
IHVzZSBpcyBkZXZpY2Ugc3BlY2lmaWMgYW55d2F5Lg0KDQpJdCBhbHNvIGxvb2tzIGxpa2UgYSBj
b3VwbGUgbW9udGggYWdvIHNvbWVvbmUgYWxzbyBwb2ludGVkIG91dCB0aGF0IGp1c3QgYmVjYXVz
ZSB0aGUgYmFzZSBjb3JlIGlzIHRoZSBzYW1lLCB0aGF0IGRvZXNuJ3QgbWVhbiBhbGwgdGhlIGVy
cmF0YXMgYXJlIHRoZSBzYW1lLCBhbmQgQVJDSF9NVUxUSVBMQVRGT1JNIGRvZXNuJ3QgZml0IHRo
ZXJlIGFzIHdlbGwuDQoNCkNocmlzDQoNCg=

XIP_KERNEL and !ARCH_MULTIPLATFORM

[Chris Brandt]

Hi Geert,

> Besides, I think a multi-platform XIP (or nommu) kernel is possible, as long as XIP_PHYS_ADDR (or PHYS_OFFSET) is suitable for all platforms included

Possible...but...maybe pointless. If you're doing XIP, then most likely you've got a specific platform that you are trying to do as much as you can in as little (RAM) as possible.

Was ARCH_MULTIPLATFORM really trying to fix some huge existing problem? Or was it more of a 'here's a cute thing we could do'?
In my mind, an SoC by nature is used for specific embedded product and you could care less if the binary runs on anything else. Of course the range of SoCs that can run Linux now a days varies greatly, so I don't think you can put them all in the same category like ARCH_MULTIPLATFORM was trying to do.


> Perhaps ARCH_MULTIPLATFORM should be replaced by ARCH_ARM_NEWWORLD almost everywhere, and (new) ARCH_MULTIPLATFORM should be reserved (if needed at all) to protect features that are not compatible with running on multiple machines?

That's not bad. I think it still comes down to if you want to build XIP, you don't care about ARCH_MULTIPLATFORM support, and the XIP_PHYS_ADDR (and PHYS_OFFSET) you need to use is device specific anyway.

It also looks like a couple month ago someone also pointed out that just because the base core is the same, that doesn't mean all the erratas are the same, and ARCH_MULTIPLATFORM doesn't fit there as well.

Chris

Re: XIP_KERNEL and !ARCH_MULTIPLATFORM

[Geert Uytterhoeven]

Hi Chris,

On Tue, Mar 17, 2015 at 2:46 PM, Chris Brandt <Chris.Brandt@renesas.com> wrote:
>> Besides, I think a multi-platform XIP (or nommu) kernel is possible, as long as XIP_PHYS_ADDR (or PHYS_OFFSET) is suitable for all platforms included
>
> Possible...but...maybe pointless. If you're doing XIP, then most likely you've got a specific platform that you are trying to do as much as you can in as little (RAM) as possible.

Sure. For your real embedded device, you want a small kernel, without any cruft.

> Was ARCH_MULTIPLATFORM really trying to fix some huge existing problem? Or was it more of a 'here's a cute thing we could do'?
> In my mind, an SoC by nature is used for specific embedded product and you could care less if the binary runs on anything else. Of course the range of SoCs that can run Linux now a days varies greatly, so I don't think you can put them all in the same category like ARCH_MULTIPLATFORM was trying to do.

ARCH_MULTIPLATFORM (the multi-platform part) was also introduced to reduce the
number of kernels you have to built. This matters not only for testing
(increasing build coverage while reducing the number of kernels vs. the number
of machines), but also for Linux distributions, who typically ship only a few
kernels, but want to support as many machine types as possible.

>> Perhaps ARCH_MULTIPLATFORM should be replaced by ARCH_ARM_NEWWORLD almost everywhere, and (new) ARCH_MULTIPLATFORM should be reserved (if needed at all) to protect features that are not compatible with running on multiple machines?
>
> That's not bad. I think it still comes down to if you want to build XIP, you don't care about ARCH_MULTIPLATFORM support, and the XIP_PHYS_ADDR (and PHYS_OFFSET) you need to use is device specific anyway.

Now, to solve your problem: can you get it to work by dropping XIP_KERNEL's
dependency on !ARCH_MULTIPLATFORM in arch/arm/Kconfig?

> It also looks like a couple month ago someone also pointed out that just because the base core is the same, that doesn't mean all the erratas are the same, and ARCH_MULTIPLATFORM doesn't fit there as well.

Possibly.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

XIP_KERNEL and !ARCH_MULTIPLATFORM

[Geert Uytterhoeven]

Hi Chris,

On Tue, Mar 17, 2015 at 2:46 PM, Chris Brandt <Chris.Brandt@renesas.com> wrote:
>> Besides, I think a multi-platform XIP (or nommu) kernel is possible, as long as XIP_PHYS_ADDR (or PHYS_OFFSET) is suitable for all platforms included
>
> Possible...but...maybe pointless. If you're doing XIP, then most likely you've got a specific platform that you are trying to do as much as you can in as little (RAM) as possible.

Sure. For your real embedded device, you want a small kernel, without any cruft.

> Was ARCH_MULTIPLATFORM really trying to fix some huge existing problem? Or was it more of a 'here's a cute thing we could do'?
> In my mind, an SoC by nature is used for specific embedded product and you could care less if the binary runs on anything else. Of course the range of SoCs that can run Linux now a days varies greatly, so I don't think you can put them all in the same category like ARCH_MULTIPLATFORM was trying to do.

ARCH_MULTIPLATFORM (the multi-platform part) was also introduced to reduce the
number of kernels you have to built. This matters not only for testing
(increasing build coverage while reducing the number of kernels vs. the number
of machines), but also for Linux distributions, who typically ship only a few
kernels, but want to support as many machine types as possible.

>> Perhaps ARCH_MULTIPLATFORM should be replaced by ARCH_ARM_NEWWORLD almost everywhere, and (new) ARCH_MULTIPLATFORM should be reserved (if needed at all) to protect features that are not compatible with running on multiple machines?
>
> That's not bad. I think it still comes down to if you want to build XIP, you don't care about ARCH_MULTIPLATFORM support, and the XIP_PHYS_ADDR (and PHYS_OFFSET) you need to use is device specific anyway.

Now, to solve your problem: can you get it to work by dropping XIP_KERNEL's
dependency on !ARCH_MULTIPLATFORM in arch/arm/Kconfig?

> It also looks like a couple month ago someone also pointed out that just because the base core is the same, that doesn't mean all the erratas are the same, and ARCH_MULTIPLATFORM doesn't fit there as well.

Possibly.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

RE: XIP_KERNEL and !ARCH_MULTIPLATFORM

[Chris Brandt]

SGkgR2VlcnQsDQoNCj4gVGhpcyBtYXR0ZXJzIG5vdCBvbmx5IGZvciB0ZXN0aW5nIChpbmNyZWFz
aW5nIGJ1aWxkIGNvdmVyYWdlIHdoaWxlIHJlZHVjaW5nIHRoZSBudW1iZXIgb2Yga2VybmVscyB2
cy4gdGhlIG51bWJlciBvZiBtYWNoaW5lcyksIGJ1dCBhbHNvIGZvciBMaW51eCBkaXN0cmlidXRp
b25zLCB3aG8gdHlwaWNhbGx5IHNoaXAgb25seSBhIGZldyBrZXJuZWxzLCBidXQgd2FudCB0byBz
dXBwb3J0IGFzIG1hbnkgbWFjaGluZSB0eXBlcyBhcyBwb3NzaWJsZS4NCg0KT0ssIEkgY2FuIHNl
ZSB0aGUgZGVzaXJlIG5vdy4gQnV0LCB0aGVyZSBtdXN0IGJlIGEgaGFwcHkgbWVkaXVtIHNvbWV3
aGVyZS4NCg0KDQo+IE5vdywgdG8gc29sdmUgeW91ciBwcm9ibGVtOiBjYW4geW91IGdldCBpdCB0
byB3b3JrIGJ5IGRyb3BwaW5nIFhJUF9LRVJORUwncyBkZXBlbmRlbmN5IG9uICFBUkNIX01VTFRJ
UExBVEZPUk0gaW4gYXJjaC9hcm0vS2NvbmZpZz8NCg0KTm9wZSwgYmVjYXVzZSBDT05GSUdfUEhZ
U19PRkZTRVQgZG9lc24ndCBnZXQgZGVmaW5lZDoNCiAgICAgICAgIiAoLmhlYWQudGV4dCsweDY4
KTogdW5kZWZpbmVkIHJlZmVyZW5jZSB0byBgQ09ORklHX1BIWVNfT0ZGU0VUJyINCg0KY29uZmln
IFBIWVNfT0ZGU0VUDQoJaGV4ICJQaHlzaWNhbCBhZGRyZXNzIG9mIG1haW4gbWVtb3J5IiBpZiBN
TVUNCglkZXBlbmRzIG9uICFBUk1fUEFUQ0hfUEhZU19WSVJUDQoNClRoYXQgd2FzIHBhdGNoICMx
IHRvIGdldCBYSVAgd29ya2luZyBpbiB0aGUgMy4xNCBrZXJuZWwuDQoNClNvLCBwdXR0aW5nIHRo
YXQgcGF0Y2ggaW4gZm9yIEFSQ0hfTVVMVElQTEFURk9STToNCmNvbmZpZyBBUkNIX01VTFRJUExB
VEZPUk0NCglib29sICJBbGxvdyBtdWx0aXBsZSBwbGF0Zm9ybXMgdG8gYmUgc2VsZWN0ZWQiDQoJ
ZGVwZW5kcyBvbiBNTVUNCglzZWxlY3QgQVJDSF9XQU5UX09QVElPTkFMX0dQSU9MSUINCglzZWxl
Y3QgQVJNX0hBU19TR19DSEFJTg0KLQlzZWxlY3QgQVJNX1BBVENIX1BIWVNfVklSVA0KKwlzZWxl
Y3QgQVJNX1BBVENIX1BIWVNfVklSVCBpZiAhWElQX0tFUk5FTA0KDQpUaGF0IHdpbGwgZ2V0IHlv
dSB0byBiZSBhYmxlIHRvIHNldCBQSFlTX09GRlNFVCBhbmQgdGhlbiBidWlsZCwgYnV0IHN0aWxs
IG5vdCBhY3R1YWxseSB3b3JrLg0KDQpGb3IgY29kZSwgaXQgbG9va3MgbGlrZSBJIHN0aWxsIG5l
ZWQgdG8gYXBwbHkgbXkgMy4xNCBwYXRjaGVzIHRvOg0KICAgIGFyY2gvYXJtL21tL21tdS5jDQog
ICAgYXJjaC9hcm0vbW0vcHJvYy12Ny5TDQogICAgc2NyaXB0cy9saW5rLXZtbGludXguc2gNCg0K
VW5mb3J0dW5hdGVseSwgSSdtIHN0aWxsIG1pc3Npbmcgc29tZXRoaW5nIHRvIGJvb3QgYWxsIHRo
ZSB3YXkgdXAuIExvb2tpbmcgYXQgIF9fbG9nX2J1ZiBJIGNhbiBzZWUgaXQgd2FzIHN0YXJ0aW5n
IHRvIGJvb3QgKDQuMC4wLXJjNCksIGJ1dCBkaWVzIGVhcmx5IG9uLg0KU28sIEknbSBhc3N1bWlu
ZyBzb21ldGhpbmcgaW4gdGhlIGtlcm5lbCBoYXMgY2hhbmdlZCBzaW5jZSAzLjE0IGFuZCBJIGhh
dmUgdG8gdHJhY2sgaXQgZG93bi4NCg0KQ2hyaXMNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut
LS0tLQ0KRnJvbTogZ2VlcnQudXl0dGVyaG9ldmVuQGdtYWlsLmNvbSBbbWFpbHRvOmdlZXJ0LnV5
dHRlcmhvZXZlbkBnbWFpbC5jb21dIE9uIEJlaGFsZiBPZiBHZWVydCBVeXR0ZXJob2V2ZW4NClNl
bnQ6IFR1ZXNkYXksIE1hcmNoIDE3LCAyMDE1IDk6NTcgQU0NClRvOiBDaHJpcyBCcmFuZHQNCkNj
OiBsaW51eC1hcm0ta2VybmVsQGxpc3RzLmluZnJhZGVhZC5vcmc7IGxpbnV4LXNoQHZnZXIua2Vy
bmVsLm9yZw0KU3ViamVjdDogUmU6IFhJUF9LRVJORUwgYW5kICFBUkNIX01VTFRJUExBVEZPUk0N
Cg0KSGkgQ2hyaXMsDQoNCk9uIFR1ZSwgTWFyIDE3LCAyMDE1IGF0IDI6NDYgUE0sIENocmlzIEJy
YW5kdCA8Q2hyaXMuQnJhbmR0QHJlbmVzYXMuY29tPiB3cm90ZToNCj4+IEJlc2lkZXMsIEkgdGhp
bmsgYSBtdWx0aS1wbGF0Zm9ybSBYSVAgKG9yIG5vbW11KSBrZXJuZWwgaXMgcG9zc2libGUsIA0K
Pj4gYXMgbG9uZyBhcyBYSVBfUEhZU19BRERSIChvciBQSFlTX09GRlNFVCkgaXMgc3VpdGFibGUg
Zm9yIGFsbCANCj4+IHBsYXRmb3JtcyBpbmNsdWRlZA0KPg0KPiBQb3NzaWJsZS4uLmJ1dC4uLm1h
eWJlIHBvaW50bGVzcy4gSWYgeW91J3JlIGRvaW5nIFhJUCwgdGhlbiBtb3N0IGxpa2VseSB5b3Un
dmUgZ290IGEgc3BlY2lmaWMgcGxhdGZvcm0gdGhhdCB5b3UgYXJlIHRyeWluZyB0byBkbyBhcyBt
dWNoIGFzIHlvdSBjYW4gaW4gYXMgbGl0dGxlIChSQU0pIGFzIHBvc3NpYmxlLg0KDQpTdXJlLiBG
b3IgeW91ciByZWFsIGVtYmVkZGVkIGRldmljZSwgeW91IHdhbnQgYSBzbWFsbCBrZXJuZWwsIHdp
dGhvdXQgYW55IGNydWZ0Lg0KDQo+IFdhcyBBUkNIX01VTFRJUExBVEZPUk0gcmVhbGx5IHRyeWlu
ZyB0byBmaXggc29tZSBodWdlIGV4aXN0aW5nIHByb2JsZW0/IE9yIHdhcyBpdCBtb3JlIG9mIGEg
J2hlcmUncyBhIGN1dGUgdGhpbmcgd2UgY291bGQgZG8nPw0KPiBJbiBteSBtaW5kLCBhbiBTb0Mg
YnkgbmF0dXJlIGlzIHVzZWQgZm9yIHNwZWNpZmljIGVtYmVkZGVkIHByb2R1Y3QgYW5kIHlvdSBj
b3VsZCBjYXJlIGxlc3MgaWYgdGhlIGJpbmFyeSBydW5zIG9uIGFueXRoaW5nIGVsc2UuIE9mIGNv
dXJzZSB0aGUgcmFuZ2Ugb2YgU29DcyB0aGF0IGNhbiBydW4gTGludXggbm93IGEgZGF5cyB2YXJp
ZXMgZ3JlYXRseSwgc28gSSBkb24ndCB0aGluayB5b3UgY2FuIHB1dCB0aGVtIGFsbCBpbiB0aGUg
c2FtZSBjYXRlZ29yeSBsaWtlIEFSQ0hfTVVMVElQTEFURk9STSB3YXMgdHJ5aW5nIHRvIGRvLg0K
DQpBUkNIX01VTFRJUExBVEZPUk0gKHRoZSBtdWx0aS1wbGF0Zm9ybSBwYXJ0KSB3YXMgYWxzbyBp
bnRyb2R1Y2VkIHRvIHJlZHVjZSB0aGUgbnVtYmVyIG9mIGtlcm5lbHMgeW91IGhhdmUgdG8gYnVp
bHQuIFRoaXMgbWF0dGVycyBub3Qgb25seSBmb3IgdGVzdGluZyAoaW5jcmVhc2luZyBidWlsZCBj
b3ZlcmFnZSB3aGlsZSByZWR1Y2luZyB0aGUgbnVtYmVyIG9mIGtlcm5lbHMgdnMuIHRoZSBudW1i
ZXIgb2YgbWFjaGluZXMpLCBidXQgYWxzbyBmb3IgTGludXggZGlzdHJpYnV0aW9ucywgd2hvIHR5
cGljYWxseSBzaGlwIG9ubHkgYSBmZXcga2VybmVscywgYnV0IHdhbnQgdG8gc3VwcG9ydCBhcyBt
YW55IG1hY2hpbmUgdHlwZXMgYXMgcG9zc2libGUuDQoNCj4+IFBlcmhhcHMgQVJDSF9NVUxUSVBM
QVRGT1JNIHNob3VsZCBiZSByZXBsYWNlZCBieSBBUkNIX0FSTV9ORVdXT1JMRCBhbG1vc3QgZXZl
cnl3aGVyZSwgYW5kIChuZXcpIEFSQ0hfTVVMVElQTEFURk9STSBzaG91bGQgYmUgcmVzZXJ2ZWQg
KGlmIG5lZWRlZCBhdCBhbGwpIHRvIHByb3RlY3QgZmVhdHVyZXMgdGhhdCBhcmUgbm90IGNvbXBh
dGlibGUgd2l0aCBydW5uaW5nIG9uIG11bHRpcGxlIG1hY2hpbmVzPw0KPg0KPiBUaGF0J3Mgbm90
IGJhZC4gSSB0aGluayBpdCBzdGlsbCBjb21lcyBkb3duIHRvIGlmIHlvdSB3YW50IHRvIGJ1aWxk
IFhJUCwgeW91IGRvbid0IGNhcmUgYWJvdXQgQVJDSF9NVUxUSVBMQVRGT1JNIHN1cHBvcnQsIGFu
ZCB0aGUgWElQX1BIWVNfQUREUiAoYW5kIFBIWVNfT0ZGU0VUKSB5b3UgbmVlZCB0byB1c2UgaXMg
ZGV2aWNlIHNwZWNpZmljIGFueXdheS4NCg0KTm93LCB0byBzb2x2ZSB5b3VyIHByb2JsZW06IGNh
biB5b3UgZ2V0IGl0IHRvIHdvcmsgYnkgZHJvcHBpbmcgWElQX0tFUk5FTCdzIGRlcGVuZGVuY3kg
b24gIUFSQ0hfTVVMVElQTEFURk9STSBpbiBhcmNoL2FybS9LY29uZmlnPw0KDQo+IEl0IGFsc28g
bG9va3MgbGlrZSBhIGNvdXBsZSBtb250aCBhZ28gc29tZW9uZSBhbHNvIHBvaW50ZWQgb3V0IHRo
YXQganVzdCBiZWNhdXNlIHRoZSBiYXNlIGNvcmUgaXMgdGhlIHNhbWUsIHRoYXQgZG9lc24ndCBt
ZWFuIGFsbCB0aGUgZXJyYXRhcyBhcmUgdGhlIHNhbWUsIGFuZCBBUkNIX01VTFRJUExBVEZPUk0g
ZG9lc24ndCBmaXQgdGhlcmUgYXMgd2VsbC4NCg0KUG9zc2libHkuDQoNCkdye29ldGplLGVldGlu
Z31zLA0KDQogICAgICAgICAgICAgICAgICAgICAgICBHZWVydA0KDQotLQ0KR2VlcnQgVXl0dGVy
aG9ldmVuIC0tIFRoZXJlJ3MgbG90cyBvZiBMaW51eCBiZXlvbmQgaWEzMiAtLSBnZWVydEBsaW51
eC1tNjhrLm9yZw0KDQpJbiBwZXJzb25hbCBjb252ZXJzYXRpb25zIHdpdGggdGVjaG5pY2FsIHBl
b3BsZSwgSSBjYWxsIG15c2VsZiBhIGhhY2tlci4gQnV0IHdoZW4gSSdtIHRhbGtpbmcgdG8gam91
cm5hbGlzdHMgSSBqdXN0IHNheSAicHJvZ3JhbW1lciIgb3Igc29tZXRoaW5nIGxpa2UgdGhhdC4N
CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLS0gTGludXMgVG9ydmFsZHMNCg=

XIP_KERNEL and !ARCH_MULTIPLATFORM

[Chris Brandt]

Hi Geert,

> This matters not only for testing (increasing build coverage while reducing the number of kernels vs. the number of machines), but also for Linux distributions, who typically ship only a few kernels, but want to support as many machine types as possible.

OK, I can see the desire now. But, there must be a happy medium somewhere.


> Now, to solve your problem: can you get it to work by dropping XIP_KERNEL's dependency on !ARCH_MULTIPLATFORM in arch/arm/Kconfig?

Nope, because CONFIG_PHYS_OFFSET doesn't get defined:
        " (.head.text+0x68): undefined reference to `CONFIG_PHYS_OFFSET'"

config PHYS_OFFSET
	hex "Physical address of main memory" if MMU
	depends on !ARM_PATCH_PHYS_VIRT

That was patch #1 to get XIP working in the 3.14 kernel.

So, putting that patch in for ARCH_MULTIPLATFORM:
config ARCH_MULTIPLATFORM
	bool "Allow multiple platforms to be selected"
	depends on MMU
	select ARCH_WANT_OPTIONAL_GPIOLIB
	select ARM_HAS_SG_CHAIN
-	select ARM_PATCH_PHYS_VIRT
+	select ARM_PATCH_PHYS_VIRT if !XIP_KERNEL

That will get you to be able to set PHYS_OFFSET and then build, but still not actually work.

For code, it looks like I still need to apply my 3.14 patches to:
    arch/arm/mm/mmu.c
    arch/arm/mm/proc-v7.S
    scripts/link-vmlinux.sh

Unfortunately, I'm still missing something to boot all the way up. Looking at  __log_buf I can see it was starting to boot (4.0.0-rc4), but dies early on.
So, I'm assuming something in the kernel has changed since 3.14 and I have to track it down.

Chris


-----Original Message-----
From: geert.uytterhoeven@gmail.com [mailto:geert.uytterhoeven at gmail.com] On Behalf Of Geert Uytterhoeven
Sent: Tuesday, March 17, 2015 9:57 AM
To: Chris Brandt
Cc: linux-arm-kernel at lists.infradead.org; linux-sh at vger.kernel.org
Subject: Re: XIP_KERNEL and !ARCH_MULTIPLATFORM

Hi Chris,

On Tue, Mar 17, 2015 at 2:46 PM, Chris Brandt <Chris.Brandt@renesas.com> wrote:
>> Besides, I think a multi-platform XIP (or nommu) kernel is possible, 
>> as long as XIP_PHYS_ADDR (or PHYS_OFFSET) is suitable for all 
>> platforms included
>
> Possible...but...maybe pointless. If you're doing XIP, then most likely you've got a specific platform that you are trying to do as much as you can in as little (RAM) as possible.

Sure. For your real embedded device, you want a small kernel, without any cruft.

> Was ARCH_MULTIPLATFORM really trying to fix some huge existing problem? Or was it more of a 'here's a cute thing we could do'?
> In my mind, an SoC by nature is used for specific embedded product and you could care less if the binary runs on anything else. Of course the range of SoCs that can run Linux now a days varies greatly, so I don't think you can put them all in the same category like ARCH_MULTIPLATFORM was trying to do.

ARCH_MULTIPLATFORM (the multi-platform part) was also introduced to reduce the number of kernels you have to built. This matters not only for testing (increasing build coverage while reducing the number of kernels vs. the number of machines), but also for Linux distributions, who typically ship only a few kernels, but want to support as many machine types as possible.

>> Perhaps ARCH_MULTIPLATFORM should be replaced by ARCH_ARM_NEWWORLD almost everywhere, and (new) ARCH_MULTIPLATFORM should be reserved (if needed at all) to protect features that are not compatible with running on multiple machines?
>
> That's not bad. I think it still comes down to if you want to build XIP, you don't care about ARCH_MULTIPLATFORM support, and the XIP_PHYS_ADDR (and PHYS_OFFSET) you need to use is device specific anyway.

Now, to solve your problem: can you get it to work by dropping XIP_KERNEL's dependency on !ARCH_MULTIPLATFORM in arch/arm/Kconfig?

> It also looks like a couple month ago someone also pointed out that just because the base core is the same, that doesn't mean all the erratas are the same, and ARCH_MULTIPLATFORM doesn't fit there as well.

Possibly.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: XIP_KERNEL and !ARCH_MULTIPLATFORM

[Geert Uytterhoeven]

Hi Chris,

On Tue, Mar 17, 2015 at 5:08 PM, Chris Brandt <Chris.Brandt@renesas.com> wrote:
>> Now, to solve your problem: can you get it to work by dropping XIP_KERNEL's dependency on !ARCH_MULTIPLATFORM in arch/arm/Kconfig?
>
> Nope, because CONFIG_PHYS_OFFSET doesn't get defined:
>         " (.head.text+0x68): undefined reference to `CONFIG_PHYS_OFFSET'"
>
> config PHYS_OFFSET
>         hex "Physical address of main memory" if MMU
>         depends on !ARM_PATCH_PHYS_VIRT
>
> That was patch #1 to get XIP working in the 3.14 kernel.
>
> So, putting that patch in for ARCH_MULTIPLATFORM:
> config ARCH_MULTIPLATFORM
>         bool "Allow multiple platforms to be selected"
>         depends on MMU
>         select ARCH_WANT_OPTIONAL_GPIOLIB
>         select ARM_HAS_SG_CHAIN
> -       select ARM_PATCH_PHYS_VIRT
> +       select ARM_PATCH_PHYS_VIRT if !XIP_KERNEL
>
> That will get you to be able to set PHYS_OFFSET and then build, but still not actually work.
>
> For code, it looks like I still need to apply my 3.14 patches to:
>     arch/arm/mm/mmu.c
>     arch/arm/mm/proc-v7.S
>     scripts/link-vmlinux.sh
>
> Unfortunately, I'm still missing something to boot all the way up. Looking at  __log_buf I can see it was starting to boot (4.0.0-rc4), but dies early on.

DEBUG_LL=y may help you here. It's easier than doing a post-mortem analysis
on __log_buf from U-Boot.
As we still have anti-social platforms, you best remove all non-SCIF default
addresses from the DEBUG_UART_PHYS section in arch/arm/Kconfig.debug though.

> So, I'm assuming something in the kernel has changed since 3.14 and I have to track it down.

3.14 has (limited) RZ/A1H multi-platform support. Perhaps you can try getting
XIP to work with a multi-platform v3.14 kernel first, and find out what broke
in newer versions later?

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

XIP_KERNEL and !ARCH_MULTIPLATFORM

[Geert Uytterhoeven]

Hi Chris,

On Tue, Mar 17, 2015 at 5:08 PM, Chris Brandt <Chris.Brandt@renesas.com> wrote:
>> Now, to solve your problem: can you get it to work by dropping XIP_KERNEL's dependency on !ARCH_MULTIPLATFORM in arch/arm/Kconfig?
>
> Nope, because CONFIG_PHYS_OFFSET doesn't get defined:
>         " (.head.text+0x68): undefined reference to `CONFIG_PHYS_OFFSET'"
>
> config PHYS_OFFSET
>         hex "Physical address of main memory" if MMU
>         depends on !ARM_PATCH_PHYS_VIRT
>
> That was patch #1 to get XIP working in the 3.14 kernel.
>
> So, putting that patch in for ARCH_MULTIPLATFORM:
> config ARCH_MULTIPLATFORM
>         bool "Allow multiple platforms to be selected"
>         depends on MMU
>         select ARCH_WANT_OPTIONAL_GPIOLIB
>         select ARM_HAS_SG_CHAIN
> -       select ARM_PATCH_PHYS_VIRT
> +       select ARM_PATCH_PHYS_VIRT if !XIP_KERNEL
>
> That will get you to be able to set PHYS_OFFSET and then build, but still not actually work.
>
> For code, it looks like I still need to apply my 3.14 patches to:
>     arch/arm/mm/mmu.c
>     arch/arm/mm/proc-v7.S
>     scripts/link-vmlinux.sh
>
> Unfortunately, I'm still missing something to boot all the way up. Looking at  __log_buf I can see it was starting to boot (4.0.0-rc4), but dies early on.

DEBUG_LL=y may help you here. It's easier than doing a post-mortem analysis
on __log_buf from U-Boot.
As we still have anti-social platforms, you best remove all non-SCIF default
addresses from the DEBUG_UART_PHYS section in arch/arm/Kconfig.debug though.

> So, I'm assuming something in the kernel has changed since 3.14 and I have to track it down.

3.14 has (limited) RZ/A1H multi-platform support. Perhaps you can try getting
XIP to work with a multi-platform v3.14 kernel first, and find out what broke
in newer versions later?

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: XIP_KERNEL and !ARCH_MULTIPLATFORM

[Russell King - ARM Linux]

On Tue, Mar 17, 2015 at 05:20:01PM +0100, Geert Uytterhoeven wrote:
> DEBUG_LL=y may help you here. It's easier than doing a post-mortem analysis
> on __log_buf from U-Boot.
> As we still have anti-social platforms, you best remove all non-SCIF default
> addresses from the DEBUG_UART_PHYS section in arch/arm/Kconfig.debug though.

Or enter the appropriate address directly, which is what's intended in
the long term.  Having zillions of defaults in Kconfig is not that much
better from what we had before...

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

XIP_KERNEL and !ARCH_MULTIPLATFORM

[Russell King - ARM Linux]

On Tue, Mar 17, 2015 at 05:20:01PM +0100, Geert Uytterhoeven wrote:
> DEBUG_LL=y may help you here. It's easier than doing a post-mortem analysis
> on __log_buf from U-Boot.
> As we still have anti-social platforms, you best remove all non-SCIF default
> addresses from the DEBUG_UART_PHYS section in arch/arm/Kconfig.debug though.

Or enter the appropriate address directly, which is what's intended in
the long term.  Having zillions of defaults in Kconfig is not that much
better from what we had before...

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

RE: XIP_KERNEL and !ARCH_MULTIPLATFORM

[Chris Brandt]

SGkgR2VlcnQsDQoNCj4gREVCVUdfTEw9eSBtYXkgaGVscCB5b3UgaGVyZS4gSXQncyBlYXNpZXIg
dGhhbiBkb2luZyBhIHBvc3QtbW9ydGVtIGFuYWx5c2lzIG9uIF9fbG9nX2J1ZiBmcm9tIFUtQm9v
dC4NCg0KVGhhdCBkaWRuJ3QgZXhpc3QgZm9yIG1lIGluIDMuMTQgZm9yIFJaL0ExLiBJIHRob3Vn
aHQgSSBzYXcgc29tZW9uZSBhZGQgaXQgKEkgc3RhcnRlZCB0byB3b3JrIG9uIGl0Li4uYnV0IGRp
ZG4ndCBmaW5pc2gpLg0KDQo+IDMuMTQgaGFzIChsaW1pdGVkKSBSWi9BMUggbXVsdGktcGxhdGZv
cm0gc3VwcG9ydC4gUGVyaGFwcyB5b3UgY2FuIHRyeSBnZXR0aW5nIFhJUCB0byB3b3JrIHdpdGgg
YSBtdWx0aS1wbGF0Zm9ybSB2My4xNCBrZXJuZWwgZmlyc3QsIGFuZCBmaW5kIG91dCB3aGF0IGJy
b2tlIGluIG5ld2VyIHZlcnNpb25zIGxhdGVyPw0KDQpJIHRoaW5rIGZpcnN0IEknbGwganVzdCBn
byBiYWNrIHRvIGhvdyBJIGRlYnVnZ2VkIFhJUCBpbiAzLjE0Li4uLi5KVEFHIGFuZCBhIGRpc2Fz
c2VtYmx5IHdpbmRvdy4gSXQncyBub3QgcHJldHR5LCBidXQgaXQncyB3aGF0IEkgaGF2ZSBhdmFp
bGFibGUgdG8gd29yayB3aXRoLg0KDQpDaHJpcw0KDQo

XIP_KERNEL and !ARCH_MULTIPLATFORM

[Chris Brandt]

Hi Geert,

> DEBUG_LL=y may help you here. It's easier than doing a post-mortem analysis on __log_buf from U-Boot.

That didn't exist for me in 3.14 for RZ/A1. I thought I saw someone add it (I started to work on it...but didn't finish).

> 3.14 has (limited) RZ/A1H multi-platform support. Perhaps you can try getting XIP to work with a multi-platform v3.14 kernel first, and find out what broke in newer versions later?

I think first I'll just go back to how I debugged XIP in 3.14.....JTAG and a disassembly window. It's not pretty, but it's what I have available to work with.

Chris

Re: XIP_KERNEL and !ARCH_MULTIPLATFORM

[Uwe Kleine-König]

Hello,

On Tue, Mar 17, 2015 at 03:48:38AM +0000, Chris Brandt wrote:
> I've been running XIP_KERNEL with linux-3.14 on a Renesas RZ/A1
> (ARCH_R7S72100) for a while now (with some bug fixes of course) so I
> thought I'd see if my fixes should be pushed back upstream.
> 
> However, I see that all the Renesas parts are being moved to
> ARCH_MULTIPLATFORM, which by means of arch/arm/Kconfig disallows
> XIP_KERNEL.
I think the problem is that there is no agreement on what
"ARCH_MULTIPLATFORM" means.

On one hand it can mean "This platform is available to be selected for a
kernel that supports several different architectures". That's why
MACH_IMX31_DT depends on ARCH_MULTI_V6 and so ARCH_MULTIPLATFORM.

On the other hand we have things like: ARCH_MULTIPLATFORM selects
ARM_PATCH_PHYS_VIRT. These are actually only necessary if you enable
different machines that use different RAM offsets. XIP_KERNEL is in
this category, too.

Now add that you want to do compile testing with random configs. That
means you must somehow describe the condition that allows enabling
XIP_KERNEL. You either have maintain an ugly list which machines might
be enabled together and which are mutually exclusive. Or you accept not
to allow all configs that are technically possible and sensible and go
for XIP_KERNEL depending on !ARCH_MULTIPLATFORM.

So *technically* there is no reason to disallow selecting XIP_KERNEL for
a multiplatform enabled SoC. But to implement the Kconfig logic to allow
that without allowing broken configurations is hardly possible.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

XIP_KERNEL and !ARCH_MULTIPLATFORM

[Uwe Kleine-König]

Hello,

On Tue, Mar 17, 2015 at 03:48:38AM +0000, Chris Brandt wrote:
> I've been running XIP_KERNEL with linux-3.14 on a Renesas RZ/A1
> (ARCH_R7S72100) for a while now (with some bug fixes of course) so I
> thought I'd see if my fixes should be pushed back upstream.
> 
> However, I see that all the Renesas parts are being moved to
> ARCH_MULTIPLATFORM, which by means of arch/arm/Kconfig disallows
> XIP_KERNEL.
I think the problem is that there is no agreement on what
"ARCH_MULTIPLATFORM" means.

On one hand it can mean "This platform is available to be selected for a
kernel that supports several different architectures". That's why
MACH_IMX31_DT depends on ARCH_MULTI_V6 and so ARCH_MULTIPLATFORM.

On the other hand we have things like: ARCH_MULTIPLATFORM selects
ARM_PATCH_PHYS_VIRT. These are actually only necessary if you enable
different machines that use different RAM offsets. XIP_KERNEL is in
this category, too.

Now add that you want to do compile testing with random configs. That
means you must somehow describe the condition that allows enabling
XIP_KERNEL. You either have maintain an ugly list which machines might
be enabled together and which are mutually exclusive. Or you accept not
to allow all configs that are technically possible and sensible and go
for XIP_KERNEL depending on !ARCH_MULTIPLATFORM.

So *technically* there is no reason to disallow selecting XIP_KERNEL for
a multiplatform enabled SoC. But to implement the Kconfig logic to allow
that without allowing broken configurations is hardly possible.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

RE: XIP_KERNEL and !ARCH_MULTIPLATFORM

[Chris Brandt]

> > DEBUG_LL=y may help you here. It's easier than doing a post-mortem 
> > analysis on __log_buf from U-Boot.
> > As we still have anti-social platforms, you best remove all non-SCIF 
> > default addresses from the DEBUG_UART_PHYS section in arch/arm/Kconfig.debug though.
> 
> Or enter the appropriate address directly, which is what's intended in the long term.  Having zillions of defaults in Kconfig is not that much better from what we had before...

I would say having to manually enter an address is acceptable for debugging (in my opinion)

Chris

XIP_KERNEL and !ARCH_MULTIPLATFORM

[Chris Brandt]

> > DEBUG_LL=y may help you here. It's easier than doing a post-mortem 
> > analysis on __log_buf from U-Boot.
> > As we still have anti-social platforms, you best remove all non-SCIF 
> > default addresses from the DEBUG_UART_PHYS section in arch/arm/Kconfig.debug though.
> 
> Or enter the appropriate address directly, which is what's intended in the long term.  Having zillions of defaults in Kconfig is not that much better from what we had before...

I would say having to manually enter an address is acceptable for debugging (in my opinion)

Chris

RE: XIP_KERNEL and !ARCH_MULTIPLATFORM

[Chris Brandt]

RXZlbnR1YWxseS4uLi5JIGdvdCBpdCB0byBib290Lg0KDQpJIGhhZCB0byByZW1vdmUgYm90aCBD
T05GSUdfSElHSE1FTSBhbmQgQ09ORklHX1NNUCBhbmQgdGhlbiBJIGNvdWxkIGJvb3QgY29tcGxl
dGVseSBmcm9tIFJPTSAod2hpY2ggZm9yIG1lIGlzIGV4dGVybmFsIFFTUEkgZmxhc2ggdGhhdCBp
cyBtZW1vcnkgbWFwcGluZyBpbnRvIGxpbmVhciBDUFUgc3BhY2UgYXQgYWRkcmVzcyAweDE4MDAw
MDAwKQ0KDQpTbywgdGhlIHRvdGFsIGNoYW5nZXMgd2FzOg0KDQoxLiBzdGFydCB3aXRoIHNobW9i
aWxlX2RlZmNvbmZpZw0KMi4gcmVtb3ZlIGFsbCBhcmNoaXRlY3R1cmVzIGJ1dCBSWi9BMSAoQVJD
SF9SN1M3MjEwMCkNCjMuIHJlbW92ZSAhQVJDSF9NVUxUSVBMQVRGT1JNIGZyb20gWElQX0tFUk5F
TCdzIGRlcGVuZGVuY2llcw0KNC4gbW9kaWZ5ICAnc2VsZWN0IEFSTV9QQVRDSF9QSFlTX1ZJUlQg
aWYgIVhJUF9LRVJORUwnICBpbiBQSFlTX09GRlNFVCAoYmVjYXVzZSBJIG5lZWQgdG8gYmUgYWJs
ZSB0byBzZXQgUEhZU19PRkZTRVQpDQo1LiBwYXRjaCB1cCBtbXUuYywgcHJvYy12Ny5TIGFuZCBs
aW5rLXZtbGludXguc2gNCjYuIHJlbW92ZSBDT05GSUdfSElHSE1FTSBhbmQgQ09ORklHX1NNUA0K
DQpJIGFsc28gbW9kaWZpZWQgdGhlIERUIHRvIHVzZSBpbnRlcm5hbCBSQU0gaW5zdGVhZCBleHRl
cm5hbCBTRFJBTS4NCg0KT2YgY291cnNlIHRvIGFjdHVhbGx5IGJvb3QgYW4gWElQIGtlcm5lbCwg
eW91IGhhdmUgdG8gbWFrZSBhIGN1c3RvbSBjb21tYW5kIGluIHUtYm9vdCAodXNpbmcgYm9vdG0g
b3IgZ28gaXMgbm90IGdvaW5nIHRvIHdvcmspLg0KDQoNCkdlbmVyYWxseSB0aGlzIGV4ZXJjaXNl
IGhhcyB0YXVnaHQgbWUgdGhhdCAgWElQIGFuZCBBUkNIX01VTFRJUExBVEZPUk0gZG8gbm90IHBs
YXkgd2VsbCB0b2dldGhlci4NCg0KU28gd2hpbGUgSSB0aGluayBsaW51eC00LjAgd2lsbCBoYXZl
IHRoZSBhYmlsaXR5IHRvIHJ1biBYSVAgd2l0aCBhbmQgQVJNdjcgKHdpdGggYSBoYW5kZnVsIG9m
IHBhdGNoZXMpLCB5b3UnbGwgZGVmaW5pdGVseSBuZWVkIHRvIHN0YXJ0IHdpdGggYW4gb3V0IG9m
IHRyZWUgY29uZmlnLg0KDQpDaHJpcw0KDQo

XIP_KERNEL and !ARCH_MULTIPLATFORM

[Chris Brandt]

Eventually....I got it to boot.

I had to remove both CONFIG_HIGHMEM and CONFIG_SMP and then I could boot completely from ROM (which for me is external QSPI flash that is memory mapping into linear CPU space at address 0x18000000)

So, the total changes was:

1. start with shmobile_defconfig
2. remove all architectures but RZ/A1 (ARCH_R7S72100)
3. remove !ARCH_MULTIPLATFORM from XIP_KERNEL's dependencies
4. modify  'select ARM_PATCH_PHYS_VIRT if !XIP_KERNEL'  in PHYS_OFFSET (because I need to be able to set PHYS_OFFSET)
5. patch up mmu.c, proc-v7.S and link-vmlinux.sh
6. remove CONFIG_HIGHMEM and CONFIG_SMP

I also modified the DT to use internal RAM instead external SDRAM.

Of course to actually boot an XIP kernel, you have to make a custom command in u-boot (using bootm or go is not going to work).


Generally this exercise has taught me that  XIP and ARCH_MULTIPLATFORM do not play well together.

So while I think linux-4.0 will have the ability to run XIP with and ARMv7 (with a handful of patches), you'll definitely need to start with an out of tree config.

Chris

Re: XIP_KERNEL and !ARCH_MULTIPLATFORM

[Uwe Kleine-König]

On Thu, Mar 19, 2015 at 08:57:21PM +0000, Chris Brandt wrote:
> Eventually....I got it to boot.
> 
> I had to remove both CONFIG_HIGHMEM and CONFIG_SMP and then I could boot completely from ROM (which for me is external QSPI flash that is memory mapping into linear CPU space at address 0x18000000)
> 
> So, the total changes was:
> 
> 1. start with shmobile_defconfig
> 2. remove all architectures but RZ/A1 (ARCH_R7S72100)
> 3. remove !ARCH_MULTIPLATFORM from XIP_KERNEL's dependencies
> 4. modify  'select ARM_PATCH_PHYS_VIRT if !XIP_KERNEL'  in PHYS_OFFSET (because I need to be able to set PHYS_OFFSET)
> 5. patch up mmu.c, proc-v7.S and link-vmlinux.sh
> 6. remove CONFIG_HIGHMEM and CONFIG_SMP
> 
> I also modified the DT to use internal RAM instead external SDRAM.
> 
> Of course to actually boot an XIP kernel, you have to make a custom command in u-boot (using bootm or go is not going to work).
It should. I remember that you need to pass something unintuitive to
mkimage (to not say buggy). See
http://lists.denx.de/pipermail/u-boot/2007-March/020171.html for my try
to fix that back when I still cared about U-Boot.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

XIP_KERNEL and !ARCH_MULTIPLATFORM

[Uwe Kleine-König]

On Thu, Mar 19, 2015 at 08:57:21PM +0000, Chris Brandt wrote:
> Eventually....I got it to boot.
> 
> I had to remove both CONFIG_HIGHMEM and CONFIG_SMP and then I could boot completely from ROM (which for me is external QSPI flash that is memory mapping into linear CPU space at address 0x18000000)
> 
> So, the total changes was:
> 
> 1. start with shmobile_defconfig
> 2. remove all architectures but RZ/A1 (ARCH_R7S72100)
> 3. remove !ARCH_MULTIPLATFORM from XIP_KERNEL's dependencies
> 4. modify  'select ARM_PATCH_PHYS_VIRT if !XIP_KERNEL'  in PHYS_OFFSET (because I need to be able to set PHYS_OFFSET)
> 5. patch up mmu.c, proc-v7.S and link-vmlinux.sh
> 6. remove CONFIG_HIGHMEM and CONFIG_SMP
> 
> I also modified the DT to use internal RAM instead external SDRAM.
> 
> Of course to actually boot an XIP kernel, you have to make a custom command in u-boot (using bootm or go is not going to work).
It should. I remember that you need to pass something unintuitive to
mkimage (to not say buggy). See
http://lists.denx.de/pipermail/u-boot/2007-March/020171.html for my try
to fix that back when I still cared about U-Boot.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

RE: XIP_KERNEL and !ARCH_MULTIPLATFORM

[Chris Brandt]

> > Of course to actually boot an XIP kernel, you have to make a custom command in u-boot (using bootm or go is not going to work).
> It should. I remember that you need to pass something unintuitive to mkimage (to not say buggy). See http://lists.denx.de/pipermail/u-boot/2007-March/020171.html for my try to fix that back when I still cared about U-Boot.

I originally started down that path...but it was so screwed up and really only worked for the power PC architecture. It was more work to hack it than just making a very simple function that loaded the R0,R1,R2 registers and jumped to the start of the kernel.

Chris

XIP_KERNEL and !ARCH_MULTIPLATFORM

[Chris Brandt]

> > Of course to actually boot an XIP kernel, you have to make a custom command in u-boot (using bootm or go is not going to work).
> It should. I remember that you need to pass something unintuitive to mkimage (to not say buggy). See http://lists.denx.de/pipermail/u-boot/2007-March/020171.html for my try to fix that back when I still cared about U-Boot.

I originally started down that path...but it was so screwed up and really only worked for the power PC architecture. It was more work to hack it than just making a very simple function that loaded the R0,R1,R2 registers and jumped to the start of the kernel.

Chris

Re: XIP_KERNEL and !ARCH_MULTIPLATFORM

[Russell King - ARM Linux]

On Thu, Mar 19, 2015 at 08:57:21PM +0000, Chris Brandt wrote:
> Eventually....I got it to boot.
> 
> I had to remove both CONFIG_HIGHMEM and CONFIG_SMP and then I could
> boot completely from ROM (which for me is external QSPI flash that
> is memory mapping into linear CPU space at address 0x18000000)

At first glance, HIGHMEM shouldn't be affected by XIP_KERNEL at all.

However, SMP_ON_UP is incompatible with XIP_KERNEL (as already listed
in its dependencies) and building with SMP=y without SMP_ON_UP, and
trying to run on UP hardware will definitely fail.

To put that another way:
1. SMP_ON_UP relies on being able to change the kernel text, which it
   can't do with an XIP kernel.
2. UP hardware requires either a SMP=n kernel _or_ SMP=SMP_ON_UP=y
   kernel.

> So, the total changes was:
> 
> 1. start with shmobile_defconfig
> 2. remove all architectures but RZ/A1 (ARCH_R7S72100)
> 3. remove !ARCH_MULTIPLATFORM from XIP_KERNEL's dependencies
> 4. modify  'select ARM_PATCH_PHYS_VIRT if !XIP_KERNEL'  in PHYS_OFFSET
>    (because I need to be able to set PHYS_OFFSET)

I'm not sure what you mean by this.  We have:

config PHYS_OFFSET
        hex "Physical address of main memory" if MMU
        depends on !ARM_PATCH_PHYS_VIRT

which is quite correct - PHYS_OFFSET depends on not having the phys
offset patching code enabled.  However, for an XIP kernel, you don't
want to have the phys offset patching code enabled, so you want
ARM_PATCH_PHYS_VIRT to be off.

Maybe you mean the "select ARM_PATCH_PHYS_VIRT" under ARCH_MULTIPLATFORM?

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

XIP_KERNEL and !ARCH_MULTIPLATFORM

[Russell King - ARM Linux]

On Thu, Mar 19, 2015 at 08:57:21PM +0000, Chris Brandt wrote:
> Eventually....I got it to boot.
> 
> I had to remove both CONFIG_HIGHMEM and CONFIG_SMP and then I could
> boot completely from ROM (which for me is external QSPI flash that
> is memory mapping into linear CPU space at address 0x18000000)

At first glance, HIGHMEM shouldn't be affected by XIP_KERNEL at all.

However, SMP_ON_UP is incompatible with XIP_KERNEL (as already listed
in its dependencies) and building with SMP=y without SMP_ON_UP, and
trying to run on UP hardware will definitely fail.

To put that another way:
1. SMP_ON_UP relies on being able to change the kernel text, which it
   can't do with an XIP kernel.
2. UP hardware requires either a SMP=n kernel _or_ SMP=SMP_ON_UP=y
   kernel.

> So, the total changes was:
> 
> 1. start with shmobile_defconfig
> 2. remove all architectures but RZ/A1 (ARCH_R7S72100)
> 3. remove !ARCH_MULTIPLATFORM from XIP_KERNEL's dependencies
> 4. modify  'select ARM_PATCH_PHYS_VIRT if !XIP_KERNEL'  in PHYS_OFFSET
>    (because I need to be able to set PHYS_OFFSET)

I'm not sure what you mean by this.  We have:

config PHYS_OFFSET
        hex "Physical address of main memory" if MMU
        depends on !ARM_PATCH_PHYS_VIRT

which is quite correct - PHYS_OFFSET depends on not having the phys
offset patching code enabled.  However, for an XIP kernel, you don't
want to have the phys offset patching code enabled, so you want
ARM_PATCH_PHYS_VIRT to be off.

Maybe you mean the "select ARM_PATCH_PHYS_VIRT" under ARCH_MULTIPLATFORM?

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

RE: XIP_KERNEL and !ARCH_MULTIPLATFORM

[Chris Brandt]

> At first glance, HIGHMEM shouldn't be affected by XIP_KERNEL at all.

I really didn't find the root cause of this. I just remember looking at the crashed log and it seemed like removing HIGHMEM would fix it....and it did (can't remember the details).

> However, SMP_ON_UP is incompatible with XIP_KERNEL (as already listed in its dependencies) and building with SMP=y without SMP_ON_UP, and trying to run on UP hardware will definitely fail.

So, it sounds like you are saying XIP_KERNEL and SMP is not going to happen.

However, you said:
> To put that another way:
> 1. SMP_ON_UP relies on being able to change the kernel text, which it
>    can't do with an XIP kernel.

But, what kernel text are we talking about? All of it, or just certain parts?
What if I changed the linker to put all those files in a specific area and then remap that one area to RAM (of course and copy the binary too). Yes, sounds pretty hack-ish, but if XIP can't go past single core, it might not have a long term future anyway.


> I'm not sure what you mean by this.  We have:
>
> config PHYS_OFFSET
>         hex "Physical address of main memory" if MMU
>         depends on !ARM_PATCH_PHYS_VIRT
>
> which is quite correct - PHYS_OFFSET depends on not having the phys offset patching code enabled.  However, for
> an XIP kernel, you don't want to have the phys offset patching code enabled, so you want ARM_PATCH_PHYS_VIRT to be off.

You are correct...maybe my wording was confusing. This is what I meant:

config ARCH_MULTIPLATFORM
	bool "Allow multiple platforms to be selected"
	depends on MMU
	select ARCH_WANT_OPTIONAL_GPIOLIB
	select ARM_HAS_SG_CHAIN
-	select ARM_PATCH_PHYS_VIRT
+	select ARM_PATCH_PHYS_VIRT if !XIP_KERNEL
	select AUTO_ZRELADDR


Chris

XIP_KERNEL and !ARCH_MULTIPLATFORM

[Chris Brandt]

> At first glance, HIGHMEM shouldn't be affected by XIP_KERNEL at all.

I really didn't find the root cause of this. I just remember looking at the crashed log and it seemed like removing HIGHMEM would fix it....and it did (can't remember the details).

> However, SMP_ON_UP is incompatible with XIP_KERNEL (as already listed in its dependencies) and building with SMP=y without SMP_ON_UP, and trying to run on UP hardware will definitely fail.

So, it sounds like you are saying XIP_KERNEL and SMP is not going to happen.

However, you said:
> To put that another way:
> 1. SMP_ON_UP relies on being able to change the kernel text, which it
>    can't do with an XIP kernel.

But, what kernel text are we talking about? All of it, or just certain parts?
What if I changed the linker to put all those files in a specific area and then remap that one area to RAM (of course and copy the binary too). Yes, sounds pretty hack-ish, but if XIP can't go past single core, it might not have a long term future anyway.


> I'm not sure what you mean by this.  We have:
>
> config PHYS_OFFSET
>         hex "Physical address of main memory" if MMU
>         depends on !ARM_PATCH_PHYS_VIRT
>
> which is quite correct - PHYS_OFFSET depends on not having the phys offset patching code enabled.  However, for
> an XIP kernel, you don't want to have the phys offset patching code enabled, so you want ARM_PATCH_PHYS_VIRT to be off.

You are correct...maybe my wording was confusing. This is what I meant:

config ARCH_MULTIPLATFORM
	bool "Allow multiple platforms to be selected"
	depends on MMU
	select ARCH_WANT_OPTIONAL_GPIOLIB
	select ARM_HAS_SG_CHAIN
-	select ARM_PATCH_PHYS_VIRT
+	select ARM_PATCH_PHYS_VIRT if !XIP_KERNEL
	select AUTO_ZRELADDR


Chris

Re: XIP_KERNEL and !ARCH_MULTIPLATFORM

[Uwe Kleine-König]

Hello Chris,

On Fri, Mar 20, 2015 at 08:18:10PM +0000, Chris Brandt wrote:
> > > Of course to actually boot an XIP kernel, you have to make a custom command in u-boot (using bootm or go is not going to work).
> > It should. I remember that you need to pass something unintuitive to
> > mkimage (to not say buggy). See
> > http://lists.denx.de/pipermail/u-boot/2007-March/020171.html for my
> > try to fix that back when I still cared about U-Boot.
> 
> I originally started down that path...but it was so screwed up and
> really only worked for the power PC architecture. It was more work to
> hack it than just making a very simple function that loaded the
> R0,R1,R2 registers and jumped to the start of the kernel.
Back then it worked for me on ARM, too.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

XIP_KERNEL and !ARCH_MULTIPLATFORM

[Uwe Kleine-König]

Hello Chris,

On Fri, Mar 20, 2015 at 08:18:10PM +0000, Chris Brandt wrote:
> > > Of course to actually boot an XIP kernel, you have to make a custom command in u-boot (using bootm or go is not going to work).
> > It should. I remember that you need to pass something unintuitive to
> > mkimage (to not say buggy). See
> > http://lists.denx.de/pipermail/u-boot/2007-March/020171.html for my
> > try to fix that back when I still cared about U-Boot.
> 
> I originally started down that path...but it was so screwed up and
> really only worked for the power PC architecture. It was more work to
> hack it than just making a very simple function that loaded the
> R0,R1,R2 registers and jumped to the start of the kernel.
Back then it worked for me on ARM, too.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

Re: XIP_KERNEL and !ARCH_MULTIPLATFORM

[Russell King - ARM Linux]

On Sat, Mar 21, 2015 at 03:39:30PM +0000, Chris Brandt wrote:
> > At first glance, HIGHMEM shouldn't be affected by XIP_KERNEL at all.
> 
> I really didn't find the root cause of this. I just remember looking at the crashed log and it seemed like removing HIGHMEM would fix it....and it did (can't remember the details).
> 
> > However, SMP_ON_UP is incompatible with XIP_KERNEL (as already listed in its dependencies) and building with SMP=y without SMP_ON_UP, and trying to run on UP hardware will definitely fail.
> 
> So, it sounds like you are saying XIP_KERNEL and SMP is not going to happen.

XIP_KERNEL=y and SMP=y can happen if the CPU you're booting on has the SMP
extensions.  In other words, it's a single CPU which was implemented with
the SMP extensions enabled, or it's part of a SMP set.

So, allowing both XIP_KERNEL=y and SMP=y is quite correct: however, folk
need to understand that the SMP option _must_ match the hardware they're
booting on.

> However, you said:
> > To put that another way:
> > 1. SMP_ON_UP relies on being able to change the kernel text, which it
> >    can't do with an XIP kernel.
> 
> But, what kernel text are we talking about? All of it, or just certain
> parts?

I'm afraid quite a lot of it.  If you consider that the SMP alternatives
table is 0x5ee0 bytes long for my iMX6 kernel, and that each entry is
8 bytes, that's 3036 locations throughout the kernel text which need to
be fixed up for a SMP_ON_UP kernel.  They start at 0xc0012460, and
continue up to 0xc09ef31c.  That covers much of the kernel .text and
the .text.init sections.

In an XIP kernel, the .text locations will most likely be in read-only
memory, and so can't be fixed up.

> You are correct...maybe my wording was confusing. This is what I meant:
> 
> config ARCH_MULTIPLATFORM
> 	bool "Allow multiple platforms to be selected"
> 	depends on MMU
> 	select ARCH_WANT_OPTIONAL_GPIOLIB
> 	select ARM_HAS_SG_CHAIN
> -	select ARM_PATCH_PHYS_VIRT
> +	select ARM_PATCH_PHYS_VIRT if !XIP_KERNEL

Yes, that makes sense if we agree that we want to have multi-platform
XIP kernels.

The problem is going to be expressing what a set of valid configurations
are - soo many of them just won't boot.  For example, if any of the
multiplatforms select SMP, but you want a non-SMP XIP kernel, you have
to devine which platforms are forcibly selecting SMP and turn them off.
In some of the kernel configurators, that's almost impossible to find
out.

I guess the other problem is going to be that people will want to add a
set of reasonable defaults for CONFIG_PHYS_OFFSET based upon the
platform selected - and we know that we have problems with that kind of
thing when it comes to the DEBUG_LL stuff interacting with a multiplatform
kernel.

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

XIP_KERNEL and !ARCH_MULTIPLATFORM

[Russell King - ARM Linux]

On Sat, Mar 21, 2015 at 03:39:30PM +0000, Chris Brandt wrote:
> > At first glance, HIGHMEM shouldn't be affected by XIP_KERNEL at all.
> 
> I really didn't find the root cause of this. I just remember looking at the crashed log and it seemed like removing HIGHMEM would fix it....and it did (can't remember the details).
> 
> > However, SMP_ON_UP is incompatible with XIP_KERNEL (as already listed in its dependencies) and building with SMP=y without SMP_ON_UP, and trying to run on UP hardware will definitely fail.
> 
> So, it sounds like you are saying XIP_KERNEL and SMP is not going to happen.

XIP_KERNEL=y and SMP=y can happen if the CPU you're booting on has the SMP
extensions.  In other words, it's a single CPU which was implemented with
the SMP extensions enabled, or it's part of a SMP set.

So, allowing both XIP_KERNEL=y and SMP=y is quite correct: however, folk
need to understand that the SMP option _must_ match the hardware they're
booting on.

> However, you said:
> > To put that another way:
> > 1. SMP_ON_UP relies on being able to change the kernel text, which it
> >    can't do with an XIP kernel.
> 
> But, what kernel text are we talking about? All of it, or just certain
> parts?

I'm afraid quite a lot of it.  If you consider that the SMP alternatives
table is 0x5ee0 bytes long for my iMX6 kernel, and that each entry is
8 bytes, that's 3036 locations throughout the kernel text which need to
be fixed up for a SMP_ON_UP kernel.  They start at 0xc0012460, and
continue up to 0xc09ef31c.  That covers much of the kernel .text and
the .text.init sections.

In an XIP kernel, the .text locations will most likely be in read-only
memory, and so can't be fixed up.

> You are correct...maybe my wording was confusing. This is what I meant:
> 
> config ARCH_MULTIPLATFORM
> 	bool "Allow multiple platforms to be selected"
> 	depends on MMU
> 	select ARCH_WANT_OPTIONAL_GPIOLIB
> 	select ARM_HAS_SG_CHAIN
> -	select ARM_PATCH_PHYS_VIRT
> +	select ARM_PATCH_PHYS_VIRT if !XIP_KERNEL

Yes, that makes sense if we agree that we want to have multi-platform
XIP kernels.

The problem is going to be expressing what a set of valid configurations
are - soo many of them just won't boot.  For example, if any of the
multiplatforms select SMP, but you want a non-SMP XIP kernel, you have
to devine which platforms are forcibly selecting SMP and turn them off.
In some of the kernel configurators, that's almost impossible to find
out.

I guess the other problem is going to be that people will want to add a
set of reasonable defaults for CONFIG_PHYS_OFFSET based upon the
platform selected - and we know that we have problems with that kind of
thing when it comes to the DEBUG_LL stuff interacting with a multiplatform
kernel.

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

Re: XIP_KERNEL and !ARCH_MULTIPLATFORM

[Arnd Bergmann]

On Saturday 21 March 2015, Chris Brandt wrote:
> > At first glance, HIGHMEM shouldn't be affected by XIP_KERNEL at all.
> 
> I really didn't find the root cause of this. I just remember looking at the crashed log and it seemed like removing HIGHMEM would fix it....and it did (can't remember the details).
> 
> > However, SMP_ON_UP is incompatible with XIP_KERNEL (as already listed in its dependencies) and building with SMP=y without SMP_ON_UP, and trying to run on UP hardware will definitely fail.
> 
> So, it sounds like you are saying XIP_KERNEL and SMP is not going to happen.
> 
> However, you said:
> > To put that another way:
> > 1. SMP_ON_UP relies on being able to change the kernel text, which it
> >    can't do with an XIP kernel.
> 
> But, what kernel text are we talking about? All of it, or just certain parts?
> What if I changed the linker to put all those files in a specific area and
> then remap that one area to RAM (of course and copy the binary too). Yes,
> sounds pretty hack-ish, but if XIP can't go past single core, it might not
> have a long term future anyway.

XIP should be fine on ARMv7 SMP, which does not require SMP_ON_UP.

Maybe it's enough to describe the dependency in the opposite way and make
XIP_KERNEL depend on !SMP_ON_UP. You should never really need the two
together anyway, since SMP_ON_UP is only needed for kernels that are
meant to run on SMP machines with full SMP support as well as legacy
ARMv6 machines without SMP instructions.
 

	Arnd

XIP_KERNEL and !ARCH_MULTIPLATFORM

[Arnd Bergmann]

On Saturday 21 March 2015, Chris Brandt wrote:
> > At first glance, HIGHMEM shouldn't be affected by XIP_KERNEL at all.
> 
> I really didn't find the root cause of this. I just remember looking at the crashed log and it seemed like removing HIGHMEM would fix it....and it did (can't remember the details).
> 
> > However, SMP_ON_UP is incompatible with XIP_KERNEL (as already listed in its dependencies) and building with SMP=y without SMP_ON_UP, and trying to run on UP hardware will definitely fail.
> 
> So, it sounds like you are saying XIP_KERNEL and SMP is not going to happen.
> 
> However, you said:
> > To put that another way:
> > 1. SMP_ON_UP relies on being able to change the kernel text, which it
> >    can't do with an XIP kernel.
> 
> But, what kernel text are we talking about? All of it, or just certain parts?
> What if I changed the linker to put all those files in a specific area and
> then remap that one area to RAM (of course and copy the binary too). Yes,
> sounds pretty hack-ish, but if XIP can't go past single core, it might not
> have a long term future anyway.

XIP should be fine on ARMv7 SMP, which does not require SMP_ON_UP.

Maybe it's enough to describe the dependency in the opposite way and make
XIP_KERNEL depend on !SMP_ON_UP. You should never really need the two
together anyway, since SMP_ON_UP is only needed for kernels that are
meant to run on SMP machines with full SMP support as well as legacy
ARMv6 machines without SMP instructions.
 

	Arnd

Re: XIP_KERNEL and !ARCH_MULTIPLATFORM

[Arnd Bergmann]

On Sunday 22 March 2015, Russell King - ARM Linux wrote:
> > You are correct...maybe my wording was confusing. This is what I meant:
> > 
> > config ARCH_MULTIPLATFORM
> >       bool "Allow multiple platforms to be selected"
> >       depends on MMU
> >       select ARCH_WANT_OPTIONAL_GPIOLIB
> >       select ARM_HAS_SG_CHAIN
> > -     select ARM_PATCH_PHYS_VIRT
> > +     select ARM_PATCH_PHYS_VIRT if !XIP_KERNEL
> 
> Yes, that makes sense if we agree that we want to have multi-platform
> XIP kernels.

I'd rather see this possibility enabled than have separate multiplatform
and non-multiplatform Kconfig entries for each machine that may
want XIP_KERNEL. The same thing applies to no-MMU support: we now
have platforms (i.MX for now, other likely to follow) that are already
multiplatform and that are gaining support for no-MMU implementations.

For those too, we need to set the physical address, which means
we can not run on othe rmachines that may be configured at the
same time.

> The problem is going to be expressing what a set of valid configurations
> are - soo many of them just won't boot.  For example, if any of the
> multiplatforms select SMP, but you want a non-SMP XIP kernel, you have
> to devine which platforms are forcibly selecting SMP and turn them off.
> In some of the kernel configurators, that's almost impossible to find
> out.

For a XIP kernel, I'd normally expect the user to turn off all machines
other than the one that the kernel is meant to run on, except for build
testing.

> I guess the other problem is going to be that people will want to add a
> set of reasonable defaults for CONFIG_PHYS_OFFSET based upon the
> platform selected - and we know that we have problems with that kind of
> thing when it comes to the DEBUG_LL stuff interacting with a multiplatform
> kernel.

I think a number of people have expressed that they'd rather get rid of the
DEBUG_LL list in the long run, now that we have earlycon working. If we
can treat XIP_KERNEL as a special case that would only be used for special
embedded systems, I don't think we need a preconfigured list of defaults,
but rather hide XIP_KERNEL under CONFIG_EXPERT and expect the few users
that need it to know the address or start with a working defconfig file
that has it configured.

	Arnd

XIP_KERNEL and !ARCH_MULTIPLATFORM

[Arnd Bergmann]

On Sunday 22 March 2015, Russell King - ARM Linux wrote:
> > You are correct...maybe my wording was confusing. This is what I meant:
> > 
> > config ARCH_MULTIPLATFORM
> >       bool "Allow multiple platforms to be selected"
> >       depends on MMU
> >       select ARCH_WANT_OPTIONAL_GPIOLIB
> >       select ARM_HAS_SG_CHAIN
> > -     select ARM_PATCH_PHYS_VIRT
> > +     select ARM_PATCH_PHYS_VIRT if !XIP_KERNEL
> 
> Yes, that makes sense if we agree that we want to have multi-platform
> XIP kernels.

I'd rather see this possibility enabled than have separate multiplatform
and non-multiplatform Kconfig entries for each machine that may
want XIP_KERNEL. The same thing applies to no-MMU support: we now
have platforms (i.MX for now, other likely to follow) that are already
multiplatform and that are gaining support for no-MMU implementations.

For those too, we need to set the physical address, which means
we can not run on othe rmachines that may be configured at the
same time.

> The problem is going to be expressing what a set of valid configurations
> are - soo many of them just won't boot.  For example, if any of the
> multiplatforms select SMP, but you want a non-SMP XIP kernel, you have
> to devine which platforms are forcibly selecting SMP and turn them off.
> In some of the kernel configurators, that's almost impossible to find
> out.

For a XIP kernel, I'd normally expect the user to turn off all machines
other than the one that the kernel is meant to run on, except for build
testing.

> I guess the other problem is going to be that people will want to add a
> set of reasonable defaults for CONFIG_PHYS_OFFSET based upon the
> platform selected - and we know that we have problems with that kind of
> thing when it comes to the DEBUG_LL stuff interacting with a multiplatform
> kernel.

I think a number of people have expressed that they'd rather get rid of the
DEBUG_LL list in the long run, now that we have earlycon working. If we
can treat XIP_KERNEL as a special case that would only be used for special
embedded systems, I don't think we need a preconfigured list of defaults,
but rather hide XIP_KERNEL under CONFIG_EXPERT and expect the few users
that need it to know the address or start with a working defconfig file
that has it configured.

	Arnd

RE: XIP_KERNEL and !ARCH_MULTIPLATFORM

[Chris Brandt]

> So, allowing both XIP_KERNEL=y and SMP=y is quite correct: however, folk need to understand that the SMP option _must_ match the hardware they're booting on.

OK. I think I have some studying to do before I try to attempt XIP on another platform. Or at least, give some guidance to the chip designers if XIP Linux will be a desired operational mode.


> If you consider that the SMP alternatives table is 0x5ee0 bytes long for my iMX6 kernel, and that each entry is 8 bytes, -snip-

Well there goes that idea.


> Yes, that makes sense if we agree that we want to have multi-platform XIP kernels.

My initial ambition was to simply understand what the minimum Kconfig changes were needed to build XIP on the current upstream kernel.
I'm not convinced XIP and multi-platform really make sense together (unless ARM comes up with a new supper speedy configurable cache system just for DDR reads, but DDR writes have to be done from different address location).


I guess my first goal is to make sure the existing XIP_KERNEL code doesn't get yanked out because no one thought it was being used.

Chris

XIP_KERNEL and !ARCH_MULTIPLATFORM

[Chris Brandt]

> So, allowing both XIP_KERNEL=y and SMP=y is quite correct: however, folk need to understand that the SMP option _must_ match the hardware they're booting on.

OK. I think I have some studying to do before I try to attempt XIP on another platform. Or at least, give some guidance to the chip designers if XIP Linux will be a desired operational mode.


> If you consider that the SMP alternatives table is 0x5ee0 bytes long for my iMX6 kernel, and that each entry is 8 bytes, -snip-

Well there goes that idea.


> Yes, that makes sense if we agree that we want to have multi-platform XIP kernels.

My initial ambition was to simply understand what the minimum Kconfig changes were needed to build XIP on the current upstream kernel.
I'm not convinced XIP and multi-platform really make sense together (unless ARM comes up with a new supper speedy configurable cache system just for DDR reads, but DDR writes have to be done from different address location).


I guess my first goal is to make sure the existing XIP_KERNEL code doesn't get yanked out because no one thought it was being used.

Chris

Re: XIP_KERNEL and !ARCH_MULTIPLATFORM

[Geert Uytterhoeven]

Hi Chris,

On Sat, Mar 21, 2015 at 4:39 PM, Chris Brandt <Chris.Brandt@renesas.com> wrote:
>> However, SMP_ON_UP is incompatible with XIP_KERNEL (as already listed in its dependencies) and building with SMP=y without SMP_ON_UP, and trying to run on UP hardware will definitely fail.
>
> So, it sounds like you are saying XIP_KERNEL and SMP is not going to happen.

I think you misunderstood: XIP_KERNEL=y and SMP=y should work on an SMP
system, XIP_KERNEL=y and SMP=n should work on a uniprocessor system.

The problem is SMP_ON_UP (run SMP=y kernel on a uniprocessor system).
You just can't have one kernel that works on both.

As Arnd mentioned, making XIP_KERNEL depend on !SMP_ON_UP sounds
like the way to go.

BTW, since you're asking about SMP=y, I guess you're not just interested in
running XIP_KERNEL=y on r7s72100, which is UP?

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

XIP_KERNEL and !ARCH_MULTIPLATFORM

[Geert Uytterhoeven]

Hi Chris,

On Sat, Mar 21, 2015 at 4:39 PM, Chris Brandt <Chris.Brandt@renesas.com> wrote:
>> However, SMP_ON_UP is incompatible with XIP_KERNEL (as already listed in its dependencies) and building with SMP=y without SMP_ON_UP, and trying to run on UP hardware will definitely fail.
>
> So, it sounds like you are saying XIP_KERNEL and SMP is not going to happen.

I think you misunderstood: XIP_KERNEL=y and SMP=y should work on an SMP
system, XIP_KERNEL=y and SMP=n should work on a uniprocessor system.

The problem is SMP_ON_UP (run SMP=y kernel on a uniprocessor system).
You just can't have one kernel that works on both.

As Arnd mentioned, making XIP_KERNEL depend on !SMP_ON_UP sounds
like the way to go.

BTW, since you're asking about SMP=y, I guess you're not just interested in
running XIP_KERNEL=y on r7s72100, which is UP?

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

RE: XIP_KERNEL and !ARCH_MULTIPLATFORM

[Chris Brandt]

> If we can treat XIP_KERNEL as a special case that would only be used for special embedded systems,
>      -snip-
> or start with a working defconfig file that has it configured.

So far, it sounds like that's the only way XIP_KERNEL can be used.


Chris

XIP_KERNEL and !ARCH_MULTIPLATFORM

[Chris Brandt]

> If we can treat XIP_KERNEL as a special case that would only be used for special embedded systems,
>      -snip-
> or start with a working defconfig file that has it configured.

So far, it sounds like that's the only way XIP_KERNEL can be used.


Chris

RE: XIP_KERNEL and !ARCH_MULTIPLATFORM

[Chris Brandt]

SGkgR2VlcnQsDQoNClllcywgaXQncyBtYWtpbmcgbW9yZSBzZW5zZSB0byBtZSBub3cuDQoNCj4g
QlRXLCBzaW5jZSB5b3UncmUgYXNraW5nIGFib3V0IFNNUD15LCBJIGd1ZXNzIHlvdSdyZSBub3Qg
anVzdCBpbnRlcmVzdGVkIGluIHJ1bm5pbmcgWElQX0tFUk5FTD15IG9uIHI3czcyMTAwLCB3aGlj
aCBpcyBVUD8NCg0KWWVzLiBXaGlsZSB0aGUgcjdzNzIxMDAgaXRzZWxmIGhhcyBzb21lIG5pY2Ug
Y2FwYWJpbGl0aWVzIHN1aXRlZCBmb3IgWElQLCBJJ20gdGhpbmtpbmcgd2hhdCBlbHNlIHRoaXMg
Y291bGQgYmUgZXhwYW5kZWQgdG8uDQoNCkNocmlzDQoNCg=

XIP_KERNEL and !ARCH_MULTIPLATFORM

[Chris Brandt]

Hi Geert,

Yes, it's making more sense to me now.

> BTW, since you're asking about SMP=y, I guess you're not just interested in running XIP_KERNEL=y on r7s72100, which is UP?

Yes. While the r7s72100 itself has some nice capabilities suited for XIP, I'm thinking what else this could be expanded to.

Chris

Re: XIP_KERNEL and !ARCH_MULTIPLATFORM

[Arnd Bergmann]

On Monday 23 March 2015, Chris Brandt wrote:
> > Yes, that makes sense if we agree that we want to have multi-platform XIP kernels.
> 
> My initial ambition was to simply understand what the minimum Kconfig changes were
> needed to build XIP on the current upstream kernel.

I think it should be enough to change the dependency from !ARCH_MULTIPLATFORM
to !SMP_ON_UP as a start, and drop the reverse dependency in SMP_ON_UP.

Try running 'make randconfig' a few hundred times (without building the kernel)
and see if any obvious Kconfig warnings come up after doing that.

> I'm not convinced XIP and multi-platform really make sense together (unless ARM
> comes up with a new supper speedy configurable cache system just for DDR reads,
> but DDR writes have to be done from different address location).

There are two different scenarios to consider here:

a) building a kernel for a single machine while CONFIG_ARCH_MULTIPLATFORM is
   enabled
b) actually enabling all sorts of machines

I have patches to make ARCH_MULTIPLATFORM always enabled on all ARMv6/v7
targets and would like to get them into the next kernel. The main reasons
for this are to get rid of the special cases for non-multiplatform targets,
and to allow 'make allmodconfig' to include all known v6/v7 targets. This
means that I would definitely want to see XIP_KERNEL being possible on your
machine with a), but I agree that there is not much use for b) here.
 
> I guess my first goal is to make sure the existing XIP_KERNEL code doesn't
> get yanked out because no one thought it was being used.
 
Don't worry about that. We definitely rely on XIP_KERNEL for some of the
NOMMU targets, and it's not going away.

	Arnd

XIP_KERNEL and !ARCH_MULTIPLATFORM

[Arnd Bergmann]

On Monday 23 March 2015, Chris Brandt wrote:
> > Yes, that makes sense if we agree that we want to have multi-platform XIP kernels.
> 
> My initial ambition was to simply understand what the minimum Kconfig changes were
> needed to build XIP on the current upstream kernel.

I think it should be enough to change the dependency from !ARCH_MULTIPLATFORM
to !SMP_ON_UP as a start, and drop the reverse dependency in SMP_ON_UP.

Try running 'make randconfig' a few hundred times (without building the kernel)
and see if any obvious Kconfig warnings come up after doing that.

> I'm not convinced XIP and multi-platform really make sense together (unless ARM
> comes up with a new supper speedy configurable cache system just for DDR reads,
> but DDR writes have to be done from different address location).

There are two different scenarios to consider here:

a) building a kernel for a single machine while CONFIG_ARCH_MULTIPLATFORM is
   enabled
b) actually enabling all sorts of machines

I have patches to make ARCH_MULTIPLATFORM always enabled on all ARMv6/v7
targets and would like to get them into the next kernel. The main reasons
for this are to get rid of the special cases for non-multiplatform targets,
and to allow 'make allmodconfig' to include all known v6/v7 targets. This
means that I would definitely want to see XIP_KERNEL being possible on your
machine with a), but I agree that there is not much use for b) here.
 
> I guess my first goal is to make sure the existing XIP_KERNEL code doesn't
> get yanked out because no one thought it was being used.
 
Don't worry about that. We definitely rely on XIP_KERNEL for some of the
NOMMU targets, and it's not going away.

	Arnd

RE: XIP_KERNEL and !ARCH_MULTIPLATFORM

[Chris Brandt]

> There are two different scenarios to consider here:
> 
> a) building a kernel for a single machine while CONFIG_ARCH_MULTIPLATFORM is
>    enabled
> b) actually enabling all sorts of machines
>
> This means that I would definitely want to see XIP_KERNEL being possible on your
> machine with a), but I agree that there is not much use for b) here.

Given that XIP_KERNEL on ARMv7 is not a very common build configuration, this seems reasonable.


Chris

XIP_KERNEL and !ARCH_MULTIPLATFORM

[Chris Brandt]

> There are two different scenarios to consider here:
> 
> a) building a kernel for a single machine while CONFIG_ARCH_MULTIPLATFORM is
>    enabled
> b) actually enabling all sorts of machines
>
> This means that I would definitely want to see XIP_KERNEL being possible on your
> machine with a), but I agree that there is not much use for b) here.

Given that XIP_KERNEL on ARMv7 is not a very common build configuration, this seems reasonable.


Chris

Re: XIP_KERNEL and !ARCH_MULTIPLATFORM

[Russell King - ARM Linux]

On Tue, Mar 17, 2015 at 03:48:38AM +0000, Chris Brandt wrote:
> I've been running XIP_KERNEL with linux-3.14 on a Renesas RZ/A1
> (ARCH_R7S72100) for a while now (with some bug fixes of course) so I
> thought I'd see if my fixes should be pushed back upstream.
> 
> However, I see that all the Renesas parts are being moved to
> ARCH_MULTIPLATFORM, which by means of arch/arm/Kconfig disallows
> XIP_KERNEL.

Having fixed the ARM946 code last night, I ran into a similar problem
with Integrator - the platform which ARM946 is supposed to be buildable
for.

ARM946 is a noMMU device, but the conversion of Integrator to
multiplatform left no way to select ARM946 (or, indeed, ARM940).

Both this case, and your case, are both /regressions/ - they're bugs
which we have introduced by preventing previously working configurations
from working today.  As long as we have people wanting to build these,
that matters, and we have to fix it.

There's been some discussion around this at length already.  However,
my view is that we do *not* want to remove interaction between !MMU/XIP
and multiplatform.  That's crazy - it opens the door to having lots of
buildable but un-runnable configurations, and searching the configuration
for that unexpected option which needs to be turned off for things to
work is a real pain - especially if it is buried behind a whole truck
load of select statements.

We have had something that worked very well for this kind of stuff for
many many years - that is the top level choice statement where the
multi-platform option can be found.

For Integrator, for example, we can restore !MMU building very easily:

1. Fix dc680b989d51 ("ARM: fix multiplatform allmodcompile") in a way
   that extends what's already done for ARMv6 and ARMv7 CPUs, but in
   a cleaner manner by introducing a set of class symbols:

   config CPU_CLASS_xx
	def_bool ARCH_MULTI_xx || !ARCH_MULTIPLATFORM

   and use these, in part, to control the visibility of CPU options.

2. Effectively restore Integrator to the top level choice for !MMU:

   config ARM_SINGLE_INTEGRATOR
	bool "ARM Ltd. Integrator family (noMMU)"
	depends on !MMU

   and change arch/arm/mach-integrator/Kconfig thusly:

 config ARCH_INTEGRATOR
	bool "ARM Ltd. Integrator family" if (ARCH_MULTI_V4T || ARCH_MULTI_V5 || ARCH_MULTI_V6)
+	default y if ARM_SINGLE_INTEGRATOR
	select ARM_AMBA
-	select ARM_PATCH_PHYS_VIRT if MMU
-	select AUTO_ZRELADDR

The same can be done for !XIP_KERNEL builds too (which is why I decided
not to use ARM_NOMMU_xxx in its name).

We can _also_ allow a certain amount of multiplatform building too.
Consider, for example, Cortex-M3, where each M3 based platform has a
similar memory layout.  For that, we can have top level choice statement
for all M3 platforms, and add the appropriate "default y if
ARM_SINGLE_CORTEXM3" or augment the "bool" visibility in mach-*/Kconfig.

Shmobile is slightly more complicated as I'm not aware of what the
differences are as far as XIP goes.  I'm sure something along these
lines can be done to restore the old situation which you were using for
XIP support there.  So, we have multiplatform for MMU && !XIP builds,
but go back to something along the lines of the class-of-machines
implementation before hand.

I think many people forget what we _used_ to have already largely solved
the noMMU/XIP build issue, and I think people are rushing too quickly
into multiplatform and kicking out all the "eww, legacy, hates that we
do" stuff which _actually_ worked fairly well.

Now for the niggle that the above causes - that's with UNCOMPRESS_INCLUDE.
For Integrator, we go back to expecting mach/uncompress.h because
multiplatform isn't enabled anymore.  I'm debating whether we should
provide a default implementation for that which the compiler finds by
having it last on its list of directories to search.  We can then get
rid of UNCOMPRESS_INCLUDE entirely, and just use the lack of include
file to fall back to the default debug/uncompress.h, which sounds like
another simple solution.

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

XIP_KERNEL and !ARCH_MULTIPLATFORM

[Russell King - ARM Linux]

On Tue, Mar 17, 2015 at 03:48:38AM +0000, Chris Brandt wrote:
> I've been running XIP_KERNEL with linux-3.14 on a Renesas RZ/A1
> (ARCH_R7S72100) for a while now (with some bug fixes of course) so I
> thought I'd see if my fixes should be pushed back upstream.
> 
> However, I see that all the Renesas parts are being moved to
> ARCH_MULTIPLATFORM, which by means of arch/arm/Kconfig disallows
> XIP_KERNEL.

Having fixed the ARM946 code last night, I ran into a similar problem
with Integrator - the platform which ARM946 is supposed to be buildable
for.

ARM946 is a noMMU device, but the conversion of Integrator to
multiplatform left no way to select ARM946 (or, indeed, ARM940).

Both this case, and your case, are both /regressions/ - they're bugs
which we have introduced by preventing previously working configurations
from working today.  As long as we have people wanting to build these,
that matters, and we have to fix it.

There's been some discussion around this at length already.  However,
my view is that we do *not* want to remove interaction between !MMU/XIP
and multiplatform.  That's crazy - it opens the door to having lots of
buildable but un-runnable configurations, and searching the configuration
for that unexpected option which needs to be turned off for things to
work is a real pain - especially if it is buried behind a whole truck
load of select statements.

We have had something that worked very well for this kind of stuff for
many many years - that is the top level choice statement where the
multi-platform option can be found.

For Integrator, for example, we can restore !MMU building very easily:

1. Fix dc680b989d51 ("ARM: fix multiplatform allmodcompile") in a way
   that extends what's already done for ARMv6 and ARMv7 CPUs, but in
   a cleaner manner by introducing a set of class symbols:

   config CPU_CLASS_xx
	def_bool ARCH_MULTI_xx || !ARCH_MULTIPLATFORM

   and use these, in part, to control the visibility of CPU options.

2. Effectively restore Integrator to the top level choice for !MMU:

   config ARM_SINGLE_INTEGRATOR
	bool "ARM Ltd. Integrator family (noMMU)"
	depends on !MMU

   and change arch/arm/mach-integrator/Kconfig thusly:

 config ARCH_INTEGRATOR
	bool "ARM Ltd. Integrator family" if (ARCH_MULTI_V4T || ARCH_MULTI_V5 || ARCH_MULTI_V6)
+	default y if ARM_SINGLE_INTEGRATOR
	select ARM_AMBA
-	select ARM_PATCH_PHYS_VIRT if MMU
-	select AUTO_ZRELADDR

The same can be done for !XIP_KERNEL builds too (which is why I decided
not to use ARM_NOMMU_xxx in its name).

We can _also_ allow a certain amount of multiplatform building too.
Consider, for example, Cortex-M3, where each M3 based platform has a
similar memory layout.  For that, we can have top level choice statement
for all M3 platforms, and add the appropriate "default y if
ARM_SINGLE_CORTEXM3" or augment the "bool" visibility in mach-*/Kconfig.

Shmobile is slightly more complicated as I'm not aware of what the
differences are as far as XIP goes.  I'm sure something along these
lines can be done to restore the old situation which you were using for
XIP support there.  So, we have multiplatform for MMU && !XIP builds,
but go back to something along the lines of the class-of-machines
implementation before hand.

I think many people forget what we _used_ to have already largely solved
the noMMU/XIP build issue, and I think people are rushing too quickly
into multiplatform and kicking out all the "eww, legacy, hates that we
do" stuff which _actually_ worked fairly well.

Now for the niggle that the above causes - that's with UNCOMPRESS_INCLUDE.
For Integrator, we go back to expecting mach/uncompress.h because
multiplatform isn't enabled anymore.  I'm debating whether we should
provide a default implementation for that which the compiler finds by
having it last on its list of directories to search.  We can then get
rid of UNCOMPRESS_INCLUDE entirely, and just use the lack of include
file to fall back to the default debug/uncompress.h, which sounds like
another simple solution.

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

RE: XIP_KERNEL and !ARCH_MULTIPLATFORM

[Chris Brandt]

> We have had something that worked very well for this kind of stuff for many many years - that
> is the top level choice statement where the multi-platform option can be found.


In arch/arm/Kconfig, there is already a
config ARCH_SHMOBILE_LEGACY
	bool "Renesas ARM SoCs (non-multiplatform)"
	select ARCH_SHMOBILE

But, that will only get you to a limited number of systems to choose from.


The system I want (ARCH_R7S72100), in arch/arm/mach-shmobile/Kconfig is buried inside
if ARCH_SHMOBILE_MULTI
. . .
. . .
config ARCH_R7S72100
	bool "RZ/A1H (R7S72100)"
	select SYS_SUPPORTS_SH_MTU2
. . .
. . .
endif


Hence, I can't select ARCH_R7S72100 without first selecting multi-platform.

So, to not break multi-platform, but still allow single builds (and not
break anyone's existing config files), we'd have to go back to the way
it was, which was having duplicate ARCH entries in:

if ARCH_SHMOBILE_MULTI
. . .
. . .
endif

 and

if ARCH_SHMOBILE_LEGACY
. . .
. . .
endif

However, this idea conflicts with Arnd's statement:

> a) building a kernel for a single machine while CONFIG_ARCH_MULTIPLATFORM is
>    enabled
>
> I have patches to make ARCH_MULTIPLATFORM always enabled on all ARMv6/v7 (snip)
>
> This means that I would definitely want to see XIP_KERNEL being possible on your machine with a)


I must be missing something, but the only way to have it show up in the menu under multi-platform and single-platform is to duplicate the ARCH_xxx entry.


Chris

XIP_KERNEL and !ARCH_MULTIPLATFORM

[Chris Brandt]

> We have had something that worked very well for this kind of stuff for many many years - that
> is the top level choice statement where the multi-platform option can be found.


In arch/arm/Kconfig, there is already a
config ARCH_SHMOBILE_LEGACY
	bool "Renesas ARM SoCs (non-multiplatform)"
	select ARCH_SHMOBILE

But, that will only get you to a limited number of systems to choose from.


The system I want (ARCH_R7S72100), in arch/arm/mach-shmobile/Kconfig is buried inside
if ARCH_SHMOBILE_MULTI
. . .
. . .
config ARCH_R7S72100
	bool "RZ/A1H (R7S72100)"
	select SYS_SUPPORTS_SH_MTU2
. . .
. . .
endif


Hence, I can't select ARCH_R7S72100 without first selecting multi-platform.

So, to not break multi-platform, but still allow single builds (and not
break anyone's existing config files), we'd have to go back to the way
it was, which was having duplicate ARCH entries in:

if ARCH_SHMOBILE_MULTI
. . .
. . .
endif

 and

if ARCH_SHMOBILE_LEGACY
. . .
. . .
endif

However, this idea conflicts with Arnd's statement:

> a) building a kernel for a single machine while CONFIG_ARCH_MULTIPLATFORM is
>    enabled
>
> I have patches to make ARCH_MULTIPLATFORM always enabled on all ARMv6/v7 (snip)
>
> This means that I would definitely want to see XIP_KERNEL being possible on your machine with a)


I must be missing something, but the only way to have it show up in the menu under multi-platform and single-platform is to duplicate the ARCH_xxx entry.


Chris