Linkstation Mini and __machine_arch_type problem, not booting since 3.8
Hi everyone,
First, I am new here (and not subscribed, so Cc me please). I hope I am on the right list [edit: resent to the correct one, again].
I usually run old kernels (3.2) on my Linkstation Mini (CONFIG_MACH_LINKSTATION_MINI, Marvell Orion based, non-DT) but I wanted
to try a newer one and found that after 3.7, it didn't boot anymore at
all: no message at all displayed, not even with earlyprintk. I bisected the faulty commit down to b8b499c86be58cb309964fcab5b62ac4a240a878 ?ARM:
7602/1: Pass real "__machine_arch_type" variable to setup_machine_tags()
procedure? which looks like a quite broad change, and makes me 1) not really understand what it does 2) astonished not to see someone else affected (judging by the time since it doesn't work). Using the version prior to this commit works, but trying to revert it on some newer version (4.1-rc7) also fails, so the change must be something deeper that I can handle. Note that when I disable CONFIG_CPU_FEROCEON_OLD_ID (it is such an old Feroceon), it still correctly displays at boot ?Error: unrecognized/unsupported processor variant (0x41069260).?, so the machine ID is somewhat read correctly.
Also, my intent at first was to try converting this machine to DT, so maybe
the solution to my problem would simply be to try converting it and see if it fixes the problem?
Thanks for any thought on this problem,
--
benjamin
Hi,
Le lundi 15 juin 2015 ? 15:51 +0200, Benjamin Cama a ?crit :
Quoted 2 lines
it didn't boot anymore at
all: no message at all displayed, not even with earlyprintk
Note that I tried the earlyprintk=serial,ttyS0,115200 with a working kernel as I do for the non-working ones, and it hangs at boot too, so this is no indication, sorry.
Quoted 8 lines
I bisected
the faulty commit down tob8b499c86be58cb309964fcab5b62ac4a240a878?ARM:
7602/1: Pass real "__machine_arch_type" variable tosetup_machine_tags()
procedure? which looks like a quite broad change, and makes me 1) not really understand what it does 2) astonished not to see someone else affected (judging by the time since it doesn't work).
I dug some more and found what changed: it simply passes the bootloader -provided machine ID instead of the kernel-configured one! This is quite a change indeed, which is not mentionned in the commit text. This may seem good for vendor-provided support which assigns IDs early with upstream, but for user one (like for this machine), the machine ID will in general be some ID that has nothing to do with the one passed by the bootloader. So this ought to be mentioned somewhere!
How I found this? Well, my bootloader passes a bad machine ID (526 instead of 1858), and thus the code doesn't recognize it. What I cannot understand is why the decompressor doesn't even run with a wrong machine ID (MMU initialization that depend on it maybe??). This is very strange.
And also, I don't get why a more recent kernel with a hardcoded machine ID (personal modification) doesn't work either. Maybe I should bisect that too.
Quoted 8 lines
Using the version
prior to this commit works, but trying to revert it on some newer version (4.1-rc7) also fails, so the change must be something deeper that I can handle. Note that when I disableCONFIG_CPU_FEROCEON_OLD_ID
(it is such an old Feroceon), it still correctly displays at boot ?Error: unrecognized/unsupported processor variant (0x41069260).?, so the machine ID is somewhat read correctly.
Note about my confusion: this is the processor ID, not the machine ID.
Thanks for any help again,
--
benjamin
Hi again (feeling lonely),
I have got some news, I think I found the culprit.
Le mardi 16 juin 2015 ? 11:20 +0200, Benjamin Cama a ?crit :
Quoted 7 lines
Le lundi 15 juin 2015 ? 15:51 +0200, Benjamin Cama a ?crit :
Quoted 2 lines
it didn't boot anymore at
all: no message at all displayed, not even with earlyprintkNote that I tried the earlyprintk=serial,ttyS0,115200 with a working kernel as I do for the non-working ones, and it hangs at boot too, so this is no indication, sorry.
(Note for later: read the manual first, earlyprintk on this arch is for a special tool to handle on the serial port on the host side. So it looks like it hangs when running with it.)
Quoted 11 lines
Quoted 10 lines
I bisected
the faulty commit down tob8b499c86be58cb309964fcab5b62ac4a240a878?ARM:
7602/1: Pass real "__machine_arch_type" variable tosetup_machine_tags()
procedure? which looks like a quite broad change, and makes me 1) not
really understand what it does 2) astonished not to see someone else
affected (judging by the time since it doesn't work).
Quoted 7 lines
I dug some more and found what changed: it simply passes the bootloader -provided machine ID instead of the kernel-configured one! This is quite a change indeed, which is not mentionned in the commit text. This may seem good for vendor-provided support which assigns IDs early with upstream, but for user one (like for this machine), the machine ID will in general be some ID that has nothing to do with the one passed by the bootloader. So this ought to be mentioned somewhere!
No comment on this? I continued with my hack which hardcodes the machine ID, but has anyone some advice on how it should be done? Should the behavior be reverted, or is there a clean way to force a machine ID at build time?
Quoted 5 lines
How I found this? Well, my bootloader passes a bad machine ID (526 instead of 1858), and thus the code doesn't recognize it. What I cannot understand is why the decompressor doesn't even run with a wrong machine ID (MMU initialization that depend on it maybe??). This is very strange.
(that was because I enabled earlyprintk, which for some reason removes messages from the decompressor? or maybe I mixed things up while configuring the kernel)
Quoted 3 lines
And also, I don't get why a more recent kernel with a hardcoded machine ID (personal modification) doesn't work either. Maybe I should bisect that too.
And I did it. And I stumbled upon commit a71b092a9c68685a270ebdde7b5986ba8787e575 ?ARM: Convert handle_IRQ to use __handle_domain_irq? (author Cc'ed). The new function __handle_domain_irq (in kernel/irq/irqdesc.c, which comes just two commits before, with 76ba59f8366f2d9282cb5bda9de75b4b68cbe55f) is subtly different from the one it replaces, handle_IRQ, as it checks if the irq is not 0 as well as checking for an upper bound. Removing the check for 0 makes my machine work again! But honestly, I do not know if a zero irq is legit, so I hope some more knowledgeable people will tell me if this is OK.
-- >8 --
Subject: [PATCH] Make __handle_domain_irq accept IRQ 0
The same as handle_IRQ did before.
--- kernel/irq/irqdesc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
kernel/irq/irqdesc.c +1 -1
@@ -365,7 +365,7 @@ int __handle_domain_irq(struct irq_domain *domain, unsigned int hwirq,* Some hardware gives randomly wrong interrupts. Rather * than crashing, do something sensible. */ -if (unlikely (!irq || irq >= nr_irqs)) { +if (unlikely (irq >= nr_irqs)) {ack_bad_irq (irq); ret = -EINVAL ; }else {
Signature · 1 line
2.1.4
Hi Benjamin,
Quoted 1 line · Benjamin Cama
Hi again (feeling lonely),
[...]
Quoted 27 lines
And I did it. And I stumbled upon commit
a71b092a9c68685a270ebdde7b5986ba8787e575?ARM: Converthandle_IRQto use__handle_domain_irq? (author Cc'ed). The new function__handle_domain_irq(inkernel/irq/irqdesc.c, which comes just two commits before, with76ba59f8366f2d9282cb5bda9de75b4b68cbe55f) is subtly different from the one it replaces,handle_IRQ, as it checks if the irq is not 0 as well as checking for an upper bound. Removing the check for 0 makes my machine work again! But honestly, I do not know if a zero irq is legit, so I hope some more knowledgeable people will tell me if this is OK.-- >8 --
Subject: [PATCH] Make__handle_domain_irqaccept IRQ 0The same as
handle_IRQdid before.Signed-off-by Benjamin Cama <[email protected]>--- kernel/irq/irqdesc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)kernel/irq/irqdesc.c +0
-0
kernel/irq/irqdesc.c int __handle_domain_irq(struct irq_domain *domain, unsigned int hwirq, · line 371
Quoted 8 lines
kernel/irq/irqdesc.c +1
-1@@ -365,7 +365,7 @@ int __handle_domain_irq(struct irq_domain *domain, unsigned int hwirq,* Some hardware gives randomly wrong interrupts. Rather * than crashing, do something sensible. */ -if (unlikely (!irq || irq >= nr_irqs)) { +if (unlikely (irq >= nr_irqs)) {ack_bad_irq (irq); ret = -EINVAL ; }else {
Unfortunately, this is the wrong thing to do. IRQ0 is invalid, has been for a very long time, and actually represents the lack of interrupt.
The way you can address this is by making sure your favourite platform does not use IRQ0 at all, which is done by not assuming that Linux IRQ number (which is always completely virtual) is the same as the number designating the actual HW interrupt line.
For example, have a look at 18f3aec (ARM: 8230/1: sa1100: shift IRQs by one) for an example of such a (very simple) conversion. You'll need to tweak irq.c too.
Other commits for sa1100 will hopefully convince you to switch to irq domains altogether. This will greatly facilitate a possible further transition to DT if you wish to do so.
Looking forward to reviewing your patches,
M.
Signature · 1 line
Jazz is not dead. It just smells funny...
Quoted 15 lines · On Thursday 18 June 2015 08:52:08 Marc Zyngier wrote:
On 18/06/15 03:12, Benjamin Cama wrote:
Unfortunately, this is the wrong thing to do. IRQ0 is invalid, has been for a very long time, and actually represents the lack of interrupt.
The way you can address this is by making sure your favourite platform does not use IRQ0 at all, which is done by not assuming that Linux IRQ number (which is always completely virtual) is the same as the number designating the actual HW interrupt line.
For example, have a look at 18f3aec (ARM: 8230/1: sa1100: shift IRQs by one) for an example of such a (very simple) conversion. You'll need to tweak
irq.ctoo.
Quoted 5 lines
Other commits for sa1100 will hopefully convince you to switch to irq domains altogether. This will greatly facilitate a possible further transition to DT if you wish to do so.
Looking forward to reviewing your patches,
Converting to DT should indeed solve the problem, as that uses a more modern irqchip driver that does not use IRQ0.
Thomas Petazzoni has worked on converting orion5x machines to DT in the past, I've cc'd him and the mvebu maintainers here, they should be able to comment on what is actually required to do the conversion. It's possible that all drivers you need have already been converted and you just need to add a new dts files similar to the other arch/arm/boot/dts/orion5x-*.dts files and can remove that other board file.
Arnd
Andrew Lunn
maintainerQuoted 7 lines
Thomas Petazzoni has worked on converting orion5x machines to DT in the past, I've cc'd him and the mvebu maintainers here, they should be able to comment on what is actually required to do the conversion. It's possible that all drivers you need have already been converted and you just need to add a new dts files similar to the other
arch/arm/boot/dts/orion5x-*.dtsfiles and can remove that other board file.
I had a quick look at lsmini-setup.c. Everything it uses is DT ready, so the conversion should be painless.
Andrew
Hi Marc,
Le jeudi 18 juin 2015 ? 08:52 +0100, Marc Zyngier a ?crit :
Quoted 32 lines · Benjamin Cama
Quoted 31 lines
And I did it. And I stumbled upon commit
a71b092a9c68685a270ebdde7b5986ba8787e575?ARM: Converthandle_IRQto use__handle_domain_irq? (author Cc'ed). The new function__handle_domain_irq(inkernel/irq/irqdesc.c, which comes just two commits before, with76ba59f8366f2d9282cb5bda9de75b4b68cbe55f) is subtly different from the one it replaces,handle_IRQ, as it checks if the irq is not 0 as well as checking for an upper bound. Removing the check for 0 makes my machine work again! But honestly, I do not know if a zero irq is legit, so I hope some more knowledgeable people will tell me if this is OK.-- >8 --
Subject: [PATCH] Make__handle_domain_irqaccept IRQ 0The same as
handle_IRQdid before.Signed-off-by Benjamin Cama <[email protected]>--- kernel/irq/irqdesc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)kernel/irq/irqdesc.c +0
-1@@ -365,7 +365,7 @@ int __handle_domain_irq(struct irq_domain*domain, unsigned int hwirq, * Some hardware gives randomly wrong interrupts. Rather * than crashing, do something sensible. */ -if (unlikely (!irq || irq >= nr_irqs)) {
Quoted 8 lines
Quoted 5 lines
kernel/irq/irqdesc.c +1
-0+if (unlikely (irq >= nr_irqs)) {ack_bad_irq (irq); ret = -EINVAL ;} else {Unfortunately, this is the wrong thing to do. IRQ0 is invalid, has been for a very long time, and actually represents the lack of interrupt.
OK, sorry for the mistake, I didn't know. Shouldn't the IRQ initialization routine check this and warn the user that it may cause problems? ?Silently? making IRQ0 forbidden doesn't help for the platforms that are not fixed yet.
Quoted 5 lines
The way you can address this is by making sure your favourite platform does not use IRQ0 at all, which is done by not assuming that Linux IRQ number (which is always completely virtual) is the same as the number designating the actual HW interrupt line.
Quoted 7 lines
For example, have a look at 18f3aec (ARM: 8230/1: sa1100: shift IRQs by one) for an example of such a (very simple) conversion. You'll need to tweak
irq.ctoo.Other commits for sa1100 will hopefully convince you to switch to irq domains altogether. This will greatly facilitate a possible further transition to DT if you wish to do so.
I read quite a bit about all this virtual/hardware IRQ stuff, and the irq domains, interesting. I see that orion5x seems to be one of the last platforms not using it (appart from DT-converted boards); is it a bad sign about its durability??
Quoted 1 line
Looking forward to reviewing your patches,
Thanks for your help and support. As the others suggested (thanks to all of you too), I will try the DT way directly then.
Regards,
--
benjamin
Quoted 44 lines · Benjamin Cama
Hi Marc,
Le jeudi 18 juin 2015 ? 08:52 +0100, Marc Zyngier a ?crit :
Quoted 32 lines · Benjamin Cama
Quoted 31 lines
And I did it. And I stumbled upon commit
a71b092a9c68685a270ebdde7b5986ba8787e575?ARM: Converthandle_IRQto use__handle_domain_irq? (author Cc'ed). The new function__handle_domain_irq(inkernel/irq/irqdesc.c, which comes just two commits before, with76ba59f8366f2d9282cb5bda9de75b4b68cbe55f) is subtly different from the one it replaces,handle_IRQ, as it checks if the irq is not 0 as well as checking for an upper bound. Removing the check for 0 makes my machine work again! But honestly, I do not know if a zero irq is legit, so I hope some more knowledgeable people will tell me if this is OK.-- >8 --
Subject: [PATCH] Make__handle_domain_irqaccept IRQ 0The same as
handle_IRQdid before.Signed-off-by Benjamin Cama <[email protected]>--- kernel/irq/irqdesc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)kernel/irq/irqdesc.c +0
-1@@ -365,7 +365,7 @@ int __handle_domain_irq(struct irq_domain*domain, unsigned int hwirq, * Some hardware gives randomly wrong interrupts. Rather * than crashing, do something sensible. */ -if (unlikely (!irq || irq >= nr_irqs)) {Quoted 8 lines
Quoted 5 lines
kernel/irq/irqdesc.c +1
-0+if (unlikely (irq >= nr_irqs)) {ack_bad_irq (irq); ret = -EINVAL ;} else {Unfortunately, this is the wrong thing to do. IRQ0 is invalid, has been for a very long time, and actually represents the lack of interrupt.
Quoted 4 lines
OK, sorry for the mistake, I didn't know. Shouldn't the IRQ initialization routine check this and warn the user that it may cause problems? ?Silently? making IRQ0 forbidden doesn't help for the platforms that are not fixed yet.
Well, this is hardly a new rule. It has been like this for quite a long
time: http://yarchive.net/comp/linux/zero.html
As for the checking and warning, this is on a very hot path, for an error case that really shouldn't occur.
<rant>
I've also come to the conclusion that people often choose to ignore warnings. It boots, so who cares? Funnily enough, they react when their toy doesn't work any more.
</rant>
Quoted 10 lines
Quoted 10 lines
The way you can address this is by making sure your favourite platform does not use IRQ0 at all, which is done by not assuming that Linux IRQ number (which is always completely virtual) is the same as the number designating the actual HW interrupt line.
For example, have a look at 18f3aec (ARM: 8230/1: sa1100: shift IRQs by one) for an example of such a (very simple) conversion. You'll need to tweak
irq.ctoo.
Quoted 8 lines
Quoted 3 lines
Other commits for sa1100 will hopefully convince you to switch to irq domains altogether. This will greatly facilitate a possible further transition to DT if you wish to do so.
I read quite a bit about all this virtual/hardware IRQ stuff, and the irq domains, interesting. I see that orion5x seems to be one of the last platforms not using it (appart from DT-converted boards); is it a bad sign about its durability??
No, we have platforms that will most probably never be converted to DT, and they are very far from rotting in the tree.
Thanks,
M.
Signature · 1 line
Jazz is not dead. It just smells funny...
Le vendredi 19 juin 2015 ? 10:13 +0100, Marc Zyngier a ?crit :
Quoted 10 lines · Benjamin Cama
Quoted 8 lines
Le jeudi 18 juin 2015 ? 08:52 +0100, Marc Zyngier a ?crit :
Quoted 2 lines
Unfortunately, this is the wrong thing to do. IRQ0 is invalid, has been for a very long time, and actually represents the lack of interrupt.
OK, sorry for the mistake, I didn't know. Shouldn't the IRQ initialization routine check this and warn the user that it may cause problems? ?Silently? making IRQ0 forbidden doesn't help for the platforms that are not fixed yet.
Quoted 5 lines
Well, this is hardly a new rule. It has been like this for quite a long
time: http://yarchive.net/comp/linux/zero.htmlAs for the checking and warning, this is on a very hot path, for an error case that really shouldn't occur.
I was not talking about the irq handler, but the irq initialization routine (on orion5x, orion_irq_init calls irq_alloc_generic_chip with 0), which takes the starting irq number and may warn when it is zero (well, it may also start allocating at zero but never use it, so this may not be a totally correct assumption, but I think this comes close, and it's just a warning).
Quoted 5 lines
<rant>
I've also come to the conclusion that people often choose to ignore warnings. It boots, so who cares? Funnily enough, they react when their toy doesn't work any more.
</rant>
Well, original Orion support seems to come from Marvell itself?
Quoted 14 lines
Quoted 14 lines
Quoted 13 lines
The way you can address this is by making sure your favourite platform does not use IRQ0 at all, which is done by not assuming that Linux IRQ number (which is always completely virtual) is the same as the number designating the actual HW interrupt line.
For example, have a look at 18f3aec (ARM: 8230/1: sa1100: shift IRQs by one) for an example of such a (very simple) conversion. You'll need to tweak
irq.ctoo.Other commits for sa1100 will hopefully convince you to switch to irq domains altogether. This will greatly facilitate a possible further transition to DT if you wish to do so.
Quoted 7 lines
Quoted 4 lines
I read quite a bit about all this virtual/hardware IRQ stuff, and the irq domains, interesting. I see that orion5x seems to be one of the last platforms not using it (appart from DT-converted boards); is it a bad sign about its durability??
No, we have platforms that will most probably never be converted to DT, and they are very far from rotting in the tree.
Nice to know. One of the reasons for converting my board to DT was fear that it may one day be mandatory. Is there any particular reason for keeping some boards non-DT while still being maintained?
Regards,
--
benjamin
Benjamin,
Quoted 2 lines · Benjamin Cama
Le vendredi 19 juin 2015 ?? 10:13 +0100, Marc Zyngier a ??crit :
Quoted 1 line · Benjamin Cama
...
Quoted 11 lines
Quoted 7 lines
Quoted 4 lines
I read quite a bit about all this virtual/hardware IRQ stuff, and the irq domains, interesting. I see that orion5x seems to be one of the last platforms not using it (appart from DT-converted boards); is it a bad sign about its durability????
No, we have platforms that will most probably never be converted to DT, and they are very far from rotting in the tree.
Nice to know. One of the reasons for converting my board to DT was fear that it may one day be mandatory. Is there any particular reason for keeping some boards non-DT while still being maintained?
If folks are using the sub-arch and interested in maintaining them, they stick around. mach-orion5x/ is a wierd case because there aren't many users. The mvebu folks have put a lot of work into supporting / converting the legacy platforms (kirkwood, dove). Thomas did most of the work converting orion5x, but there simply aren't many users to test. So it's in a half-converted state.
iow, we're glad to see you contributing patches for orion5x. ;-)
thx,
Jason.
Quoted 17 lines · Benjamin Cama
Le vendredi 19 juin 2015 ? 10:13 +0100, Marc Zyngier a ?crit :
Quoted 10 lines · Benjamin Cama
Quoted 8 lines
Le jeudi 18 juin 2015 ? 08:52 +0100, Marc Zyngier a ?crit :
Quoted 2 lines
Unfortunately, this is the wrong thing to do. IRQ0 is invalid, has been for a very long time, and actually represents the lack of interrupt.
OK, sorry for the mistake, I didn't know. Shouldn't the IRQ initialization routine check this and warn the user that it may cause problems? ?Silently? making IRQ0 forbidden doesn't help for the platforms that are not fixed yet.
Quoted 5 lines
Well, this is hardly a new rule. It has been like this for quite a long
time: http://yarchive.net/comp/linux/zero.htmlAs for the checking and warning, this is on a very hot path, for an error case that really shouldn't occur.
Quoted 6 lines
I was not talking about the irq handler, but the irq initialization routine (on orion5x,
orion_irq_initcallsirq_alloc_generic_chipwith 0), which takes the starting irq number and may warn when it is zero (well, it may also start allocating at zero but never use it, so this may not be a totally correct assumption, but I think this comes close, and it's just a warning).
It needs fixing nevertheless - arguments along the lines of "this used to work" don't work for this topic.
The simple answer is to adjust the initialisation to bump the IRQ numbers up by one, and them adjust the interrupt numbers in arch/arm/mach-whatever/include/asm/irqs.h also up by one. That's far easier to do than spending ages trying to argue against the "IRQ0 is not valid" issue, only to ultimately get nowhere, and end up with that as the only way forward anyway.
Signature · 2 lines
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up according to speedtest.net.
Hi Russell,
Le 2015-06-19 15:13, Russell King - ARM Linux a ?crit?:
Quoted 37 lines · Benjamin Cama
Quoted 22 lines
Le vendredi 19 juin 2015 ? 10:13 +0100, Marc Zyngier a ?crit :
Quoted 3 lines · Benjamin Cama
Quoted 2 lines
Le jeudi 18 juin 2015 ? 08:52 +0100, Marc Zyngier a ?crit :
Quoted 1 line
Unfortunately, this is the wrong thing to do. IRQ0 is invalid,
has been
Quoted 1 line
Quoted 1 line
Quoted 1 line
for a very long time, and actually represents the lack of
interrupt.
Quoted 3 lines
Quoted 3 lines
OK, sorry for the mistake, I didn't know. Shouldn't the IRQ initialization routine check this and warn the user that it may
cause
Quoted 4 lines
Quoted 2 lines
problems? ?Silently? making IRQ0 forbidden doesn't help for the platforms that are not fixed yet.
Well, this is hardly a new rule. It has been like this for quite a
long
Quoted 3 lines
time: http://yarchive.net/comp/linux/zero.html
As for the checking and warning, this is on a very hot path, for
an
Quoted 1 line
error case that really shouldn't occur.
Quoted 9 lines
I was not talking about the irq handler, but the irq initialization routine (on orion5x,
orion_irq_initcallsirq_alloc_generic_chipwith
0), which takes the starting irq number and may warn when it is zero (well, it may also start allocating at zero but never use it, so this
may not be a totally correct assumption, but I think this comes close,
and it's just a warning).It needs fixing nevertheless - arguments along the lines of "this used
to work" don't work for this topic.
Quoted 6 lines
The simple answer is to adjust the initialisation to bump the IRQ numbers up by one, and them adjust the interrupt numbers in
arch/arm/mach-whatever/include/asm/irqs.halso up by one. That's far easier to do than spending ages trying to argue against the "IRQ0 is not valid" issue, only to ultimately get nowhere, and end up with that as the only way forward anyway.
Do not misunderstand me: I am not at all for keeping the situation like this!
What I ask is just for users to be notified of this new requirement:
for my
case, my board simply couldn't boot anymore, without any explanation. If there
was a message along the lines ?You are setting up IRQs starting from 0, which
is not supported by the kernel anymore? just before crashing, maybe it would
help debugging the issue.
I could try to write a patch for it, but I was first wondering if this is a
good idea or not.
Regards,
--
benjamin
Quoted 2 lines · Benjamin Cama
Le 2015-06-19 15:13, Russell King - ARM Linux a ??crit??:
Quoted 1 line · Benjamin Cama
...
Quoted 25 lines
Quoted 10 lines
Quoted 6 lines
I was not talking about the irq handler, but the irq initialization routine (on orion5x,
orion_irq_initcallsirq_alloc_generic_chipwith 0), which takes the starting irq number and may warn when it is zero (well, it may also start allocating at zero but never use it, so this may not be a totally correct assumption, but I think this comes close, and it's just a warning).It needs fixing nevertheless - arguments along the lines of "this used to work" don't work for this topic.
Quoted 6 lines
The simple answer is to adjust the initialisation to bump the IRQ numbers up by one, and them adjust the interrupt numbers in
arch/arm/mach-whatever/include/asm/irqs.halso up by one. That's far easier to do than spending ages trying to argue against the "IRQ0 is not valid" issue, only to ultimately get nowhere, and end up with that as the only way forward anyway.Do not misunderstand me: I am not at all for keeping the situation like this! What I ask is just for users to be notified of this new
requirement: for my case, my board simply couldn't boot anymore, without any explanation. If there was a message along the lines ???You are setting up IRQs starting from 0, which is not supported by the kernel anymore??? just before crashing, maybe it would help debugging the issue.
Quoted 2 lines
I could try to write a patch for it, but I was first wondering if this is a good idea or not.
Let's just get the dts patch reviewed and merged first. Russell actually wrote the patch to do what he's describing for mach-dove.
http://lists.infradead.org/pipermail/linux-arm-kernel/2014-December/309684.html
Although, it looks like it never got updated for submission...
http://lists.infradead.org/pipermail/linux-arm-kernel/2014-December/311800.html
thx,
Jason.
Quoted 8 lines · Jason Cooper
Let's just get the dts patch reviewed and merged first. Russell actually wrote the patch to do what he's describing for mach-dove.
http://lists.infradead.org/pipermail/linux-arm-kernel/2014-December/309684.html
Although, it looks like it never got updated for submission...
http://lists.infradead.org/pipermail/linux-arm-kernel/2014-December/311800.html
I do still have that patch, it's based on v4.0 though - like all my Dove work, it only builds on the previous -final kernel release.
"Getting it out there" is really low on my priority list because of the amount of hassle involved in trying to get anything merged (read that as: I've basically given up trying anymore because of the amount of back pressure from people who don't read the comments from the previous submission, and end up making the same old comments every time - thereby ensuring that there is little in the way of forward progress. No, we're not using syscon nor regmap for the PMU...)
Signature · 2 lines
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up according to speedtest.net.
Quoted 4 lines · Russell King - ARM Linux
Quoted 3 lines · Jason Cooper
Let's just get the dts patch reviewed and merged first. Russell actually wrote the patch to do what he's describing for mach-dove.
Quoted 8 lines
Quoted 5 lines
http://lists.infradead.org/pipermail/linux-arm-kernel/2014-December/309684.html
Although, it looks like it never got updated for submission...
http://lists.infradead.org/pipermail/linux-arm-kernel/2014-December/311800.html
I do still have that patch, it's based on v4.0 though - like all my Dove work, it only builds on the previous -final kernel release.
Benjamin, after the dts, would you mind picking up Russell's dove patch and making a cooresponding orion5x patch?
thx,
Jason.
Le vendredi 19 juin 2015 ? 17:13 +0000, Jason Cooper a ?crit :
Quoted 9 lines · Russell King - ARM Linux
Quoted 8 lines · Jason Cooper
Quoted 7 lines
Let's just get the dts patch reviewed and merged first. Russell actually wrote the patch to do what he's describing for mach-dove.
http://lists.infradead.org/pipermail/linux-arm-kernel/2014-December/309684.html
Although, it looks like it never got updated for submission...
Quoted 7 lines
Quoted 4 lines
I do still have that patch, it's based on v4.0 though - like all my Dove work, it only builds on the previous -final kernel release.
Benjamin, after the dts, would you mind picking up Russell's dove patch and making a cooresponding orion5x patch?
If the plan is to move to DT, is it still needed?
--
benjamin
Quoted 12 lines · Benjamin Cama
Le vendredi 19 juin 2015 ?? 17:13 +0000, Jason Cooper a ??crit :
Quoted 11 lines · Russell King - ARM Linux
Quoted 10 lines · Jason Cooper
Quoted 8 lines
Let's just get the dts patch reviewed and merged first. Russell actually wrote the patch to do what he's describing for mach-dove.
http://lists.infradead.org/pipermail/linux-arm-kernel/2014-December/309684.html
Although, it looks like it never got updated for submission...
http://lists.infradead.org/pipermail/linux-arm-kernel/2014-December/311800.html
Quoted 7 lines
Quoted 5 lines
Quoted 2 lines
I do still have that patch, it's based on v4.0 though - like all my Dove work, it only builds on the previous -final kernel release.
Benjamin, after the dts, would you mind picking up Russell's dove patch and making a cooresponding orion5x patch?
If the plan is to move to DT, is it still needed?
Sure, because orion5x is slow-going. There aren't that many users. Since we prefer tested patches, we need to grab the opportunity when it comes a long. It could be another year or more before we see more patches for orion5x. Fully converting orion5x to DT doesn't have a schedule, it's as we encounter devs willing to post patches for their boards.
The opportunity here is that you were just booting a legacy board file on an orion5x SoC. Therefore, you're in the best position to write/test the irq change.
thx,
Jason.
Le lundi 22 juin 2015 ? 12:08 +0000, Jason Cooper a ?crit :
Quoted 19 lines · Benjamin Cama
Quoted 18 lines
Le vendredi 19 juin 2015 ?? 17:13 +0000, Jason Cooper a ??crit :
Quoted 16 lines · Russell King - ARM Linux
Quoted 12 lines · Jason Cooper
Quoted 8 lines
Let's just get the dts patch reviewed and merged first. Russell actually wrote the patch to do what he's describing for mach-dove.
http://lists.infradead.org/pipermail/linux-arm-kernel/2014-December/309684.html
Although, it looks like it never got updated for submission...
http://lists.infradead.org/pipermail/linux-arm-kernel/2014-December/311800.html
I do still have that patch, it's based on v4.0 though - like all my Dove work, it only builds on the previous -final kernel release.
Benjamin, after the dts, would you mind picking up Russell's dove patch and making a cooresponding orion5x patch?
Quoted 8 lines
Quoted 1 line
If the plan is to move to DT, is it still needed?
Sure, because orion5x is slow-going. There aren't that many users. Since we prefer tested patches, we need to grab the opportunity when it comes a long. It could be another year or more before we see more patches for orion5x. Fully converting orion5x to DT doesn't have a schedule, it's as we encounter devs willing to post patches for their boards.
According to rmk, letting their board break may be a quicker way to get the patches ;-) (and I agree with that: I wouldn't have moved to DT so fast if the build didn't break, it is a good incentive).
Quoted 3 lines
The opportunity here is that you were just booting a legacy board file on an orion5x SoC. Therefore, you're in the best position to write/test the irq change.
OK, I understand. I'll try to find the time to test the non-DT case and offer a patch. About Russell's one: how is the Signed-off-by going in this case? I put his and then mine?
Regards,
--
benjamin
Quoted 3 lines · Benjamin Cama
OK, I understand. I'll try to find the time to test the non-DT case and offer a patch. About Russell's one: how is the Signed-off-by going in this case? I put his and then mine?
If you produce an entirely separate patch to address Orion5x in the same way that I've done with Dove, then there's no reason to have my sign-off on it, because none of it will contain work that I've done.
Also note that I've actually re-sent that patch today, and Andrew says he'll apply it around -rc1 time, so you don't have to include the Dove bits in your patch.
Signature · 2 lines
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up according to speedtest.net.
Quoted 29 lines · Benjamin Cama
Le lundi 22 juin 2015 ?? 12:08 +0000, Jason Cooper a ??crit :
Quoted 19 lines · Benjamin Cama
Quoted 18 lines
Le vendredi 19 juin 2015 ?? 17:13 +0000, Jason Cooper a ??crit :
Quoted 16 lines · Russell King - ARM Linux
Quoted 12 lines · Jason Cooper
Quoted 8 lines
Let's just get the dts patch reviewed and merged first. Russell actually wrote the patch to do what he's describing for mach-dove.
http://lists.infradead.org/pipermail/linux-arm-kernel/2014-December/309684.html
Although, it looks like it never got updated for submission...
http://lists.infradead.org/pipermail/linux-arm-kernel/2014-December/311800.html
I do still have that patch, it's based on v4.0 though - like all my Dove work, it only builds on the previous -final kernel release.
Benjamin, after the dts, would you mind picking up Russell's dove patch and making a cooresponding orion5x patch?
Quoted 8 lines
Quoted 1 line
If the plan is to move to DT, is it still needed?
Sure, because orion5x is slow-going. There aren't that many users. Since we prefer tested patches, we need to grab the opportunity when it comes a long. It could be another year or more before we see more patches for orion5x. Fully converting orion5x to DT doesn't have a schedule, it's as we encounter devs willing to post patches for their boards.
Quoted 3 lines
According to rmk, letting their board break may be a quicker way to get the patches ;-) (and I agree with that: I wouldn't have moved to DT so fast if the build didn't break, it is a good incentive).
Oddly enough, that's how I got roped into being a maintainer. :-P
Quoted 7 lines
Quoted 3 lines
The opportunity here is that you were just booting a legacy board file on an orion5x SoC. Therefore, you're in the best position to write/test the irq change.
OK, I understand. I'll try to find the time to test the non-DT case and offer a patch. About Russell's one: how is the Signed-off-by going in this case? I put his and then mine?
Well, it looks like it applies cleanly to linux-next, so we can probably take it as is. My request was wrt the original patch I linked to, which would have needed a rebase.
So, no need to do anything with rmk's patch. Just use it as a base for the orion5x case if you need to.
thx,
Jason.
A message that is not in the archive (sent off-list or not yet received): [email protected]
PATCH 1/1 ARM: orion5x: fix legacy orion5x IRQ numbers
Since v3.18, attempts to deviler IRQ0 are rejected, breaking orion5x. Fix this by increasing all interrupts by one, as did 5d6bed2a9c8b for dove. Also, force MULTI_IRQ_HANDLER for all orion platforms (including dove) as the specific handler is needed to shift back IRQ numbers by one.
---
Hi everyone,
I finally nailed it: my attempt at copying Russell's patch for dove did not work because MULTI_IRQ_HANDLER was not set. It is not in the defconfig; maybe it should be now? I hesitated to put it as a dependency for PLAT_ORION_LEGACY, but as the platform is globally broken without it, I added it.
What do you think?
arch/arm/Kconfig | 1 + arch/arm/mach-orion5x/include/mach/irqs.h | 64 +++++++++++++++---------------- arch/arm/mach-orion5x/irq.c | 4 +- 3 files changed, 35 insertions(+), 34 deletions(-)
arch/arm/Kconfig +1 -0
@@ -968,6 +968,7 @@ config PLAT_ORION config PLAT_ORION_LEGACY bool select PLAT_ORION + select MULTI_IRQ_HANDLER config PLAT_PXA bool
arch/arm/mach-orion5x/include/mach/irqs.h +32 -32
74 lines not on this page · raw message
arch/arm/mach-orion5x/irq.c +2 -2
@@ -42,7 +42,7 @@ __exception_irq_entry orion5x_legacy_handle_irq(struct pt_regs *regs) stat =readl_relaxed (MAIN_IRQ_CAUSE ); stat &=readl_relaxed (MAIN_IRQ_MASK );if (stat) { -unsigned int hwirq =__fls (stat); +unsigned int hwirq =1 +__fls (stat);handle_IRQ (hwirq, regs);return ; }
@@ -51,7 +51,7 @@ __exception_irq_entry orion5x_legacy_handle_irq(struct pt_regs *regs)void __init orion5x_init_irq (void ) { -orion_irq_init (0 ,MAIN_IRQ_MASK ); +orion_irq_init (1 ,MAIN_IRQ_MASK );#ifdef CONFIG_MULTI_IRQ_HANDLER set_handle_irq (orion5x_legacy_handle_irq);
Signature · 1 line
2.1.4
PATCH 1/1 ARM: orion5x: fix legacy orion5x IRQ numbers
Quoted 10 lines · On Tuesday 14 July 2015 16:25:58 Benjamin Cama wrote:
Hi everyone,
I finally nailed it: my attempt at copying Russell's patch for dove did not work because
MULTI_IRQ_HANDLERwas not set. It is not in the defconfig; maybe it should be now? I hesitated to put it as a dependency forPLAT_ORION_LEGACY, but as the platform is globally broken without it, I added it.What do you think?
I think it makes sense the way you did here.
See also my patch at
I'd be happy if we could just merge that one, along with the other plat-orion multiplatform patches at
http://git.kernel.org/cgit/linux/kernel/git/arnd/playground.git/log/?h=b1f5b2f1a738d7f78b94856bfe7a1a7d4da1fbd1
I did not manage to get them merged before my parental leave and certainly won't be able to do it before I get back to work, but maybe someone else can have a look. I think the five patches should all be fine there, they mainly need testing on real hardware.
Arnd
PATCH 1/1 ARM: orion5x: fix legacy orion5x IRQ numbers
Hi Arnd, Benjamin,
Quoted 18 lines · Arnd Bergmann
Quoted 10 lines · On Tuesday 14 July 2015 16:25:58 Benjamin Cama wrote:
Hi everyone,
I finally nailed it: my attempt at copying Russell's patch for dove did not work because
MULTI_IRQ_HANDLERwas not set. It is not in the defconfig; maybe it should be now? I hesitated to put it as a dependency forPLAT_ORION_LEGACY, but as the platform is globally broken without it, I added it.What do you think?
I think it makes sense the way you did here.
See also my patch at
Quoted 8 lines
I'd be happy if we could just merge that one, along with the other plat-orion multiplatform patches at
http://git.kernel.org/cgit/linux/kernel/git/arnd/playground.git/log/?h=b1f5b2f1a738d7f78b94856bfe7a1a7d4da1fbd1I did not manage to get them merged before my parental leave and certainly won't be able to do it before I get back to work, but maybe someone else can have a look. I think the five patches should all be fine there, they mainly need testing on real hardware.
Benjamin's patch definitely needs to be applied, as another orion user got an issue too:
http://lists.infradead.org/pipermail/linux-arm-kernel/2015-August/364503.html
The remaining question in this thread was about only taking Benjamin patch or the full series from Arnd. But now it is too late to take the full series and currently there is a bug in 4.2-rc. So first I will apply this patch with the hope that it could be merged before the 4.2 release.
Later we definitely will need to take care of Arnd series.
Thanks,
Gregory
Quoted 3 lines
Arnd
Signature · 4 lines
Gregory Clement, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com
Quoted 5 lines · Benjamin Cama
Hi Russell,
Do not misunderstand me: I am not at all for keeping the situation like this! What I ask is just for users to be notified of this new requirement:
for my case, my board simply couldn't boot anymore, without any explanation.
It's not a new requirement. It's something that's been there all along, and is finally starting to bite places where it never used to bite before. It's a latent bug in platform code, that's all.
This "IRQ0 is bad" has been known for quite some while - you've already been pointed at Linus' rant about it, dated 25 Jan 2007. If you do a bit of research, you'll find that the orion code was contributed _after_ that date.
While it's easy to stick a warning into orion_irq_init() (or whatever the function is called), it's utterly pointless now that it's been found - just fix all the users of orion_irq_init() now and be done with it.
As for "shouldn't this have had a warning in the past", well, maybe, but consider this task:
Please go and look at the other mach-* directories, and find all those which might use IRQ0, and arrange for them to print a warning.
I'm sure you'll see what a task it is that you're asking for.
What you're asking for is actually unreasonable.
(I am aware that Dove broke exactly for this reason, and I've been carrying a patch since December 2014 to fix Dove - but I just don't have the time to get it merged - like most of my other Dove work.)
Signature · 2 lines
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up according to speedtest.net.
Le vendredi 19 juin 2015 ? 16:44 +0100, Russell King - ARM Linux a ?crit :
Quoted 7 lines · Benjamin Cama
Quoted 5 lines
Hi Russell,
Do not misunderstand me: I am not at all for keeping the situation like this! What I ask is just for users to be notified of this new requirement:
for my case, my board simply couldn't boot anymore, without any explanation.
Quoted 8 lines
It's not a new requirement. It's something that's been there all along, and is finally starting to bite places where it never used to bite before. It's a latent bug in platform code, that's all.
This "IRQ0 is bad" has been known for quite some while - you've already been pointed at Linus' rant about it, dated 25 Jan 2007. If you do a bit of research, you'll find that the orion code was contributed _after_ that date.
Yes, I understand.
Quoted 3 lines
While it's easy to stick a warning into
orion_irq_init()(or whatever the function is called), it's utterly pointless now that it's been found - just fix all the users oforion_irq_init()now and be done with it.
Well, I could do that but I do not have all the hardware to test it on.
Quoted 10 lines
As for "shouldn't this have had a warning in the past", well, maybe, but consider this task:
> Please go and look at the other mach-* directories, and find > all those which might use IRQ0, and arrange for them to print > a warning.
I'm sure you'll see what a task it is that you're asking for.
What you're asking for is actually unreasonable.
I was not at all asking for that, sorry for the misunderstanding again:
I was imagining putting a warning or BUG_ON in e.g. irq_alloc_generic_chip (and just one place; I am not even sure this is the right one: I am quite a beginner in kernel code, to put things in context). I tried that but with bad results (just a hard reboot for BUG_ON without message) maybe because without earlyprintk, it happens too early in the boot process to display anything to the user. So this is a bad idea indeed.
Quoted 3 lines
(I am aware that Dove broke exactly for this reason, and I've been carrying a patch since December 2014 to fix Dove - but I just don't have the time to get it merged - like most of my other Dove work.)
I tried a quick grep'ing of platforms allocating IRQ0, and all Orion is indeed doing it, as well as davinci. But apart from them, the rest seems OK, so the platforms having this problem seem indeed to be very few.
Regards,
--
benjamin
Hi Benjamin,
Quoted 24 lines · Benjamin Cama
Hi everyone,
First, I am new here (and not subscribed, so Cc me please). I hope I am on the right list [edit: resent to the correct one, again].
I usually run old kernels (3.2) on my Linkstation Mini (
CONFIG_MACH_LINKSTATION_MINI, Marvell Orion based, non-DT) but I wanted
to try a newer one and found that after 3.7, it didn't boot anymore at
all: no message at all displayed, not even with earlyprintk. I bisected the faulty commit down tob8b499c86be58cb309964fcab5b62ac4a240a878?ARM:
7602/1: Pass real "__machine_arch_type" variable tosetup_machine_tags()
procedure? which looks like a quite broad change, and makes me 1) not really understand what it does 2) astonished not to see someone else affected (judging by the time since it doesn't work). Using the version prior to this commit works, but trying to revert it on some newer version (4.1-rc7) also fails, so the change must be something deeper that I can handle. Note that when I disableCONFIG_CPU_FEROCEON_OLD_ID(it is such an old Feroceon), it still correctly displays at boot ?Error: unrecognized/unsupported processor variant (0x41069260).?, so the machine ID is somewhat read correctly.
Quoted 4 lines
Also, my intent at first was to try converting this machine to DT, so maybe
the solution to my problem would simply be to try converting it and see if it fixes the problem?
Indeed it is your best option given the problem you exposed later in this thread. Our plan in mid-term is to completely remove the non-DT support. So converting the board is definitely the right thing to do.
The conversation should not be too hard to achieve, you will have mainly to write a dts, build a dtb an append it to your kernel.
You can have a look on waht was done for the LaCie d2 Network platform, see 94b0bd366e36379c994bdaa84f 'ARM: orion5x: convert d2net to Device Tree'
If you have any trouble or question during the conversion we will help you.
Thanks,
Gregory
Quoted 12 lines
Thanks for any thought on this problem,
--
benjamin_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel at lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Signature · 4 lines
Gregory Clement, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com
Hi Gr?gory, Andrew and Arnd,
Le jeudi 18 juin 2015 ? 10:12 +0200, Gregory CLEMENT a ?crit :
Quoted 6 lines · Benjamin Cama
Quoted 4 lines
Also, my intent at first was to try converting this machine to DT, so maybe
the solution to my problem would simply be to try converting it and see if it fixes the problem?
Quoted 8 lines
Indeed it is your best option given the problem you exposed later in this thread. Our plan in mid-term is to completely remove the non-DT support. So converting the board is definitely the right thing to do.
The conversation should not be too hard to achieve, you will have mainly to write a dts, build a dtb an append it to your kernel.
You can have a look on waht was done for the LaCie d2 Network platform, see94b0bd366e36379c994bdaa84f'ARM: orion5x: convert d2net to Device Tree'
OK, I tried following you advice, and copied step by step the dts with values corresponding to my board.
Quoted 2 lines
If you have any trouble or question during the conversion we will help you.
It took several iterations to get done, but attached is the dts I wrote. Still, it doesn't boot and I get no message after the decompressor message. But I get something: the leds change according to the configuration of the dts, so something is going on (I noticed the change after several failed boot where no led changed and fixing a typo made it).
My main problem is getting some debug messages: no amount of "debug" and "loglevel" on the command line seems to change anything. Is it too early in the boot process to get anything output or am I doing something wrong? (I activated some configs for debugging, but I may have missed the good one)
Thanks,
--
benjamin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: orion5x-ls-wsgl.dts
Type: audio/vnd.dts
Size: 4026 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20150619/cb40848b/attachment-0001.dts>
Hi Benjamin,
Quoted 31 lines · Benjamin Cama
Hi Gr?gory, Andrew and Arnd,
Le jeudi 18 juin 2015 ? 10:12 +0200, Gregory CLEMENT a ?crit :
Quoted 6 lines · Benjamin Cama
Quoted 4 lines
Also, my intent at first was to try converting this machine to DT, so maybe
the solution to my problem would simply be to try converting it and see if it fixes the problem?Quoted 8 lines
Indeed it is your best option given the problem you exposed later in this thread. Our plan in mid-term is to completely remove the non-DT support. So converting the board is definitely the right thing to do.
The conversation should not be too hard to achieve, you will have mainly to write a dts, build a dtb an append it to your kernel.
You can have a look on waht was done for the LaCie d2 Network platform, see94b0bd366e36379c994bdaa84f'ARM: orion5x: convert d2net to Device Tree'OK, I tried following you advice, and copied step by step the dts with values corresponding to my board.
Quoted 2 lines
If you have any trouble or question during the conversion we will help you.
It took several iterations to get done, but attached is the dts I wrote. Still, it doesn't boot and I get no message after the decompressor message. But I get something: the leds change according to the configuration of the dts, so something is going on (I noticed the change after several failed boot where no led changed and fixing a typo made it).
Quoted 5 lines
My main problem is getting some debug messages: no amount of "debug" and "loglevel" on the command line seems to change anything. Is it too early in the boot process to get anything output or am I doing something wrong? (I activated some configs for debugging, but I may have missed the good one)
Try to activate earlyprintk. For this you have to select CONFIG_EARLY_PRINTK which depend on DEBUG_LL. You will also have to add the argument "earlyprintk" to your kernel parameters.
Gregory
Quoted 5 lines
Thanks,
--
benjamin
Signature · 4 lines
Gregory Clement, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com
Quoted 40 lines · Gregory CLEMENT
Hi Benjamin,
Quoted 31 lines · Benjamin Cama
Hi Gr??gory, Andrew and Arnd,
Le jeudi 18 juin 2015 ?? 10:12 +0200, Gregory CLEMENT a ??crit :
Quoted 6 lines · Benjamin Cama
Quoted 4 lines
Also, my intent at first was to try converting this machine to DT, so maybe
the solution to my problem would simply be to try converting it and see if it fixes the problem?Quoted 8 lines
Indeed it is your best option given the problem you exposed later in this thread. Our plan in mid-term is to completely remove the non-DT support. So converting the board is definitely the right thing to do.
The conversation should not be too hard to achieve, you will have mainly to write a dts, build a dtb an append it to your kernel.
You can have a look on waht was done for the LaCie d2 Network platform, see94b0bd366e36379c994bdaa84f'ARM: orion5x: convert d2net to Device Tree'OK, I tried following you advice, and copied step by step the dts with values corresponding to my board.
Quoted 2 lines
If you have any trouble or question during the conversion we will help you.
It took several iterations to get done, but attached is the dts I wrote. Still, it doesn't boot and I get no message after the decompressor message. But I get something: the leds change according to the configuration of the dts, so something is going on (I noticed the change after several failed boot where no led changed and fixing a typo made it).
Quoted 5 lines
My main problem is getting some debug messages: no amount of "debug" and "loglevel" on the command line seems to change anything. Is it too early in the boot process to get anything output or am I doing something wrong? (I activated some configs for debugging, but I may have missed the good one)
Quoted 3 lines
Try to activate earlyprintk. For this you have to select
CONFIG_EARLY_PRINTKwhich depend onDEBUG_LL. You will also have to add the argument "earlyprintk" to your kernel parameters.
SERIAL_OF_PLATFORM?
thx,
Jason.
Le vendredi 19 juin 2015 ? 11:41 +0000, Jason Cooper a ?crit :
Quoted 11 lines · Gregory CLEMENT
Quoted 10 lines · Benjamin Cama
Quoted 5 lines
My main problem is getting some debug messages: no amount of "debug" and "loglevel" on the command line seems to change anything. Is it too early in the boot process to get anything output or am I doing something wrong? (I activated some configs for debugging, but I may have missed the good one)
Try to activate earlyprintk. For this you have to select
CONFIG_EARLY_PRINTKwhich depend onDEBUG_LL. You will also have to add the argument "earlyprintk" to your kernel parameters.
Yes, this is what I tried before without success, but then I looked again and realized? that I missed the option to choose the correct output just below the ?Kernel low-level debugging functions? option because the text line was too long and I didn't see it chose ?EmbeddedICE DCC channel? by default instead of the UART. Big fail for me here.
Still, no output.
Quoted 1 line
SERIAL_OF_PLATFORM?
Oh, and that was it! Why isn't it selected by the DT config? I see that it's in the defconfigs, but selected nowhere by any option. Is there a particular reason for this?
Then I saw the kernel log, I witnessed that it worked well, it just couldn't find a root fs (I was booting with dummy parameters). So the DT I made is actually working!
Thanks for your help, the patch will be following, --
benjamin
Andrew Lunn
maintainerQuoted 3 lines
Quoted 1 line
SERIAL_OF_PLATFORM?Oh, and that was it!
This used to catch us all out a lot. What configuration are you using? orion5x_defconfig? Very likely a patch adding it to that would be accepted.
Andrew
Le samedi 20 juin 2015 ? 16:36 +0200, Andrew Lunn a ?crit :
Quoted 8 lines
Quoted 4 lines
Quoted 2 lines
SERIAL_OF_PLATFORM?Oh, and that was it!
This used to catch us all out a lot. What configuration are you using?
orion5x_defconfig? Very likely a patch adding it to that would be accepted.
None. Sorry, I am used to the x86 world where I almost never used default configs (and it's been a long time, too). I admit I never fully understood the logic behind the defconfigs, apart from it meaning some kind of ?less important? dependency on some specific options. Shouldn't the main UART be a ?hard? dependency on every board?!
--
benjamin
Andrew Lunn
maintainerQuoted 10 lines · Benjamin Cama
Le samedi 20 juin 2015 ? 16:36 +0200, Andrew Lunn a ?crit :
Quoted 8 lines
Quoted 4 lines
Quoted 2 lines
SERIAL_OF_PLATFORM?Oh, and that was it!
This used to catch us all out a lot. What configuration are you using?
orion5x_defconfig? Very likely a patch adding it to that would be accepted.
Quoted 5 lines
None. Sorry, I am used to the x86 world where I almost never used default configs (and it's been a long time, too). I admit I never fully understood the logic behind the defconfigs, apart from it meaning some kind of ???less important??? dependency on some specific options. Shouldn't the main UART be a ???hard??? dependency on every board?!
You say you are from the x86 world. When did you last use a serial console on an x86? Anyway, the thinking at the time was that for most NAS boxes, there is no DB-9 on the back. You have to open up the case, and connect to a header, or even solder wires to the board, in order to use a TTL-Serial converter. Very few people actually do that, so why make the kernel a bit bigger?
But we have moved on since then, mostly because we ourselves have forgotten this option too many times. We have SERIAL_OF_PLATFORM enabled in the _defconfig.
Andrew
A message that is not in the archive (sent off-list or not yet received): [email protected]
SERIAL_OF_PLATFORM default setting for DT headless systems
Quoted 41 lines · Benjamin Cama
Le dimanche 21 juin 2015 ?? 22:07 +0200, Andrew Lunn a ??crit :
Quoted 11 lines · Benjamin Cama
Quoted 10 lines
Le samedi 20 juin 2015 ?? 16:36 +0200, Andrew Lunn a ??crit :
Quoted 8 lines
Quoted 4 lines
Quoted 2 lines
SERIAL_OF_PLATFORM?Oh, and that was it!
This used to catch us all out a lot. What configuration are you using?
orion5x_defconfig? Very likely a patch adding it to that would be accepted.Quoted 8 lines
Quoted 5 lines
None. Sorry, I am used to the x86 world where I almost never used default configs (and it's been a long time, too). I admit I never fully understood the logic behind the defconfigs, apart from it meaning some kind of ???less important??? dependency on some specific options. Shouldn't the main UART be a ???hard??? dependency on every board?!
You say you are from the x86 world. When did you last use a serial console on an x86?
Almost daily on my headless VMs ;-) But more seriously, yes, this is very uncommon today. But on x86 you have virtual terminals on your graphic output; NAS boxes don't have them (well, maybe some high-end model, but it is uncommon).
Quoted 5 lines
Anyway, the thinking at the time was that for most
NAS boxes, there is no DB-9 on the back. You have to open up the case, and connect to a header, or even solder wires to the board, in order to use a TTL-Serial converter. Very few people actually do that, so why make the kernel a bit bigger?Is this really a size problem? Because having a serial port on a *headless* machine is the most useful thing I can think of. So, to me, this option should definitely be activated on headless systems by default, even if the kernel grows a bit because of it. But I agree that it is useless without some advanced access to the serial port, which is not very common. OTOH, I think only people who have such access run non -stock kernels (i.e. the very one we are integrating right here, because vendors don't care after they shipped their device).
Quoted 8 lines
Quoted 3 lines
But we have moved on since then, mostly because we ourselves have forgotten this option too many times. We have
SERIAL_OF_PLATFORMenabled in the_defconfig.That is nice to have it in the defconfig, thanks for that. But I really think one should consider again having some dependency on it for some headless platforms. I would really like to have other arguments against my view apart from size problems.
Well, it really comes down to the roles for Kconfig vice defconfigs. If we say a driver or a board 'selects' or 'depends' on something, then we are saying either "The build will break without it", or "The board will fail to boot without it". Neither is true for SERIAL_OF_PLATFORM.
The defconfigs have a much looser accepted definition of "a generally minimal, but useful set of features for an SoC, platform or multi-platform".
Since the Kconfigs make something a hard requirement for *all* users, we try to avoid setting those unless necessary. I know I can't predict all the various usecases for an arm kernel, so we try to avoid forcing decisions on users.
The defconfigs fill the gap nicely because a user can start with a defconfig, then enable/disable features according to their specific use-case.
As for arguments other than size (which I think is a good one, but still), I like security posture. I have implemented several systems, where the design criteria was to remove everything not actually in use. The serial port driver was one of many features removed from the system. The physical serial port remained if we needed to run the debug image on a board. If SERIAL_OF_PLATFORM was a depend, then I would have had to carry yet another patch outside of mainline.
thx,
Jason.
SERIAL_OF_PLATFORM default setting for DT headless systems
Le lundi 22 juin 2015 ? 18:23 +0000, Jason Cooper a ?crit :
Quoted 51 lines · Benjamin Cama
Quoted 41 lines
Le dimanche 21 juin 2015 ?? 22:07 +0200, Andrew Lunn a ??crit :
Quoted 11 lines · Benjamin Cama
Quoted 10 lines
Le samedi 20 juin 2015 ?? 16:36 +0200, Andrew Lunn a ??crit :
Quoted 8 lines
Quoted 4 lines
Quoted 2 lines
SERIAL_OF_PLATFORM?Oh, and that was it!
This used to catch us all out a lot. What configuration are you using?
orion5x_defconfig? Very likely a patch adding it to that would be accepted.Quoted 8 lines
Quoted 5 lines
None. Sorry, I am used to the x86 world where I almost never used default configs (and it's been a long time, too). I admit I never fully understood the logic behind the defconfigs, apart from it meaning some kind of ???less important??? dependency on some specific options. Shouldn't the main UART be a ???hard??? dependency on every board?!
You say you are from the x86 world. When did you last use a serial console on an x86?
Almost daily on my headless VMs ;-) But more seriously, yes, this is very uncommon today. But on x86 you have virtual terminals on your graphic output; NAS boxes don't have them (well, maybe some high-end model, but it is uncommon).
Quoted 5 lines
Anyway, the thinking at the time was that for most
NAS boxes, there is no DB-9 on the back. You have to open up the case, and connect to a header, or even solder wires to the board, in order to use a TTL-Serial converter. Very few people actually do that, so why make the kernel a bit bigger?Is this really a size problem? Because having a serial port on a *headless* machine is the most useful thing I can think of. So, to me, this option should definitely be activated on headless systems by default, even if the kernel grows a bit because of it. But I agree that it is useless without some advanced access to the serial port, which is not very common. OTOH, I think only people who have such access run non -stock kernels (i.e. the very one we are integrating right here, because vendors don't care after they shipped their device).
Quoted 8 lines
Quoted 3 lines
But we have moved on since then, mostly because we ourselves have forgotten this option too many times. We have
SERIAL_OF_PLATFORMenabled in the_defconfig.That is nice to have it in the defconfig, thanks for that. But I really think one should consider again having some dependency on it for some headless platforms. I would really like to have other arguments against my view apart from size problems.
Quoted 4 lines
Well, it really comes down to the roles for
Kconfigvice defconfigs. If we say a driver or a board 'selects' or 'depends' on something, then we are saying either "The build will break without it", or "The board will fail to boot without it". Neither is true forSERIAL_OF_PLATFORM.
OK, I get that.
Quoted 3 lines
The defconfigs have a much looser accepted definition of "a generally minimal, but useful set of features for an SoC, platform or multi-platform".
OK. That is the difference I was trying to understand when talking about ?hard? or ?less important? dependency. Now I understand what are the Kconfigs about: just the minimal stuff.
Quoted 8 lines
Since the Kconfigs make something a hard requirement for *all* users, we try to avoid setting those unless necessary. I know I can't predict all the various usecases for an arm kernel, so we try to avoid forcing decisions on users.
The defconfigs fill the gap nicely because a user can start with a defconfig, then enable/disable features according to their specific use-case.
OK, I get the idea of their use. The assumption I had about defconfig was right, but I didn't know the Kconfig was the absolute minimal stuff; I thought it was maybe some ?good default without too much cruft?, but I was wrong.
Quoted 7 lines
As for arguments other than size (which I think is a good one, but still), I like security posture. I have implemented several systems, where the design criteria was to remove everything not actually in use. The serial port driver was one of many features removed from the system. The physical serial port remained if we needed to run the debug image on a board. If
SERIAL_OF_PLATFORMwas a depend, then I would have had to carry yet another patch outside of mainline.
Thanks for pointing that out, too, I hadn't think of it. And sorry if I sounded too assertive.
Thanks again for the very good explanation,
--
benjamin
Quoted 6 lines · Benjamin Cama
Le samedi 20 juin 2015 ?? 16:36 +0200, Andrew Lunn a ??crit :
Quoted 5 lines
Quoted 4 lines
Quoted 2 lines
SERIAL_OF_PLATFORM?Oh, and that was it!
Quoted 8 lines
Quoted 3 lines
This used to catch us all out a lot. What configuration are you using?
orion5x_defconfig? Very likely a patch adding it to that would be accepted.None. Sorry, I am used to the x86 world where I almost never used default configs (and it's been a long time, too). I admit I never fully understood the logic behind the defconfigs, apart from it meaning some kind of ???less important??? dependency on some specific options.
The defconfigs are very useful in arm-soc. There are so many board variations and combinations of drivers, that the defconfigs provide a sane starting point while keeping build times down.
Several arm maintainers have boot farms that are continuously boot testing kernels on a variety of boards. In addition, most of the arm kernel developers work from the defconfigs as a base. Which means, most of the time, the defconfig will at least boot for a given board.
thx,
Jason.
Le lundi 22 juin 2015 ? 12:00 +0000, Jason Cooper a ?crit :
Quoted 16 lines · Benjamin Cama
Quoted 6 lines
Le samedi 20 juin 2015 ?? 16:36 +0200, Andrew Lunn a ??crit :
Quoted 5 lines
Quoted 4 lines
Quoted 2 lines
SERIAL_OF_PLATFORM?Oh, and that was it!
Quoted 8 lines
Quoted 3 lines
This used to catch us all out a lot. What configuration are you using?
orion5x_defconfig? Very likely a patch adding it to that would be accepted.None. Sorry, I am used to the x86 world where I almost never used default configs (and it's been a long time, too). I admit I never fully understood the logic behind the defconfigs, apart from it meaning some kind of ???less important??? dependency on some specific options.
Quoted 8 lines
The defconfigs are very useful in arm-soc. There are so many board variations and combinations of drivers, that the defconfigs provide a sane starting point while keeping build times down.
Several arm maintainers have boot farms that are continuously boot testing kernels on a variety of boards. In addition, most of the arm kernel developers work from the defconfigs as a base. Which means, most of the time, the defconfig will at least boot for a given board.
OK, thanks for the explanation, I can understand the need.
Anyway, I still think making SERIAL_OF_PLATFORM selected on headless systems a good idea; see my other thread.
Regards,
--
benjamin
Andrew Lunn
maintainer/dts-v1/;
/* TODO: the specific power off method */
You can achieve this using the restart-poweroff driver. See the kirkwood linkstation DTS files for an example.
#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/input/input.h>
#include <dt-bindings/interrupt-controller/irq.h>
#include "orion5x-mv88f5182.dtsi"
/ {
model = "Buffalo Linkstation Mini (LS-WSGL)";
compatible = "buffalo,linkstation_mini", "marvell,orion5x-88f5182", "marvell,orion5x";
memory {
reg = <0x00000000 0x8000000>; /* 128 MB */
};
chosen {
bootargs = "console=ttyS0,115200";
linux,stdout-path = &uart0;
};
soc {
ranges = <MBUS_ID(0xf0, 0x01) 0 0xf1000000 0x100000>,
<MBUS_ID(0x09, 0x00) 0 0xf2200000 0x800>,
<MBUS_ID(0x01, 0x0f) 0 0xf4000000 0x40000>;
};
gpio-keys {
compatible = "gpio-keys";
pinctrl-0 = <&pmx_buttons>;
pinctrl-names = "default";
#address-cells = <1>;
#size-cells = <0>;
func {
label = "Function Button";
linux,code = <KEY_OPTION>;
gpios = <&gpio0 15 GPIO_ACTIVE_LOW>;
};
power {
label = "Power-on Switch";
linux,input-type = <5>; /* EV_SW */
linux,code = <0>; /* LSMINI_SW_POWER */
gpios = <&gpio0 18 GPIO_ACTIVE_LOW>;
};
autopower {
label = "Power-auto Switch";
linux,input-type = <5>; /* EV_SW */
linux,code = <1>; /* LSMINI_SW_AUTOPOWER */
gpios = <&gpio0 17 GPIO_ACTIVE_LOW>;
};There is a contribute for two other linkstation devices also made today, which have these two same buttons. I'm not sure these are the best choice of keys, but what every we decide, we should use the same for all linkstation devices.
};
gpio-leds {
compatible = "gpio-leds";
pinctrl-0 = <&pmx_leds>;
pinctrl-names = "default";
alarm {
label = "alarm:red";The board name should be in here. "lswsgl:alarm:red". Same for all the LEDs.
gpio = <&gpio0 2 GPIO_ACTIVE_LOW>;
};
info {
label = "info:amber";
gpio = <&gpio0 3 GPIO_ACTIVE_LOW>;
};
func {
label = "func:blue:top";
gpio = <&gpio0 9 GPIO_ACTIVE_LOW>;
};
power {
label = "power:blue:bottom";
gpio = <&gpio0 14 GPIO_ACTIVE_LOW>;
default-state = "on";
};
};
regulators {
compatible = "simple-bus";
#address-cells = <1>;
#size-cells = <0>;
pinctrl-0 = <&pmx_sata0_power &pmx_sata1_power &pmx_usb_power>;
pinctrl-names = "default";
sata0_power: regulator at 0 {
compatible = "regulator-fixed";
reg = <0>;
regulator-name = "SATA0 Power";
regulator-min-microvolt = <5000000>;
regulator-max-microvolt = <5000000>;
enable-active-high;
regulator-always-on;
regulator-boot-on;
gpio = <&gpio0 1 GPIO_ACTIVE_HIGH>;
};
sata1_power: regulator at 1 {
compatible = "regulator-fixed";
reg = <1>;
regulator-name = "SATA1 Power";
regulator-min-microvolt = <5000000>;
regulator-max-microvolt = <5000000>;
enable-active-high;
regulator-always-on;
regulator-boot-on;
gpio = <&gpio0 19 GPIO_ACTIVE_HIGH>;
};
usb_power: regulator at 2 {
compatible = "regulator-fixed";
reg = <2>;
regulator-name = "USB Power";
regulator-min-microvolt = <5000000>;
regulator-max-microvolt = <5000000>;
enable-active-high;
regulator-always-on;
regulator-boot-on;
gpio = <&gpio0 16 GPIO_ACTIVE_HIGH>;
};
};
};&devbus_bootcs {
status = "okay";
devbus,keep-config;
flash at 0 {
compatible = "cfi-flash";
reg = <0 0x40000>;
bank-width = <1>;
#address-cells = <1>;
#size-cells = <1>;
partition at 0 {
label = "Full256Kb";
reg = <0 0x40000>;
read-only;
};
};
};&mdio {
status = "okay";
ethphy: ethernet-phy {
reg = <8>;
};
};&ehci0 {
status = "okay";
};ð {
status = "okay";
ethernet-port at 0 {
phy-handle = <ðphy>;
};
};&i2c {
status = "okay";
clock-frequency = <100000>;
#address-cells = <1>;
rtc at 32 {
compatible = "ricoh,rs5c372a";
reg = <0x32>;
};
};&pinctrl {
pmx_buttons: pmx-buttons {
marvell,pins = "mpp15", "mpp17", "mpp18";
marvell,function = "gpio";
};
pmx_leds: pmx-leds {
marvell,pins = "mpp2", "mpp3", "mpp9", "mpp14";
marvell,function = "gpio";
};It would be normal to have four separate entries for these leds.
Otherwise, this looks pretty good.
Andrew