Re: [PATCH 5/5] arm: boot: store ATAGs structure into DT "/chosen/linux,atags" entry
On Tue, 15 Dec 2015, Russell King - ARM Linux wrote: > On Tue, Dec 15, 2015 at 10:33:25AM +0100, Pali Rohár wrote: > > So am I understand correctly that solution would be to hack > > arch/arm/mm/mmu.c to not overwrite page at PHYS_OFFSET? > > That's completely unnecessary: there are enough platform hooks to cope > with whatever the platform requires. Indeed. I didn't notice that mdesc->reserve() exists these days and is perfect for this purpose as you say. Nicolas
Re: [PATCH 5/5] arm: boot: store ATAGs structure into DT "/chosen/linux,atags" entry
On Mon, 30 Nov 2015, Pali Rohár wrote: > On Monday 30 November 2015 07:23:53 Tony Lindgren wrote: > > * Pali Rohár <pali.ro...@gmail.com> [151129 16:16]: > > > On Monday 30 November 2015 01:09:17 Nicolas Pitre wrote: > > > > On Sun, 29 Nov 2015, Russell King - ARM Linux wrote: > > > > > On Sat, Nov 28, 2015 at 12:34:23PM -0500, Nicolas Pitre wrote: > > > > > > Good. And Arnd likes the idea too. So we might be converging at > > > > > > last which is a good thing. > > > > > > > > > > I disagree with the idea that there is convergence. There might be > > > > > convergence towards an idea, but... Here's a mail extract, from > > > > > July 7th, from earlier in this very thread: > > > > > > > > > > Pali: > > > > > > Me: > > > > > > > Are the ATAGs at a fixed address on the N900? > > > > > > > > > > > > Yes, in board-rx51.c is: > > > > > > > > > > > > .atag_offset= 0x100 > > > > > > > > > > > > and Nokia Bootloader (proprietary) store them to that address. > > > > > > > > > > > > > Can that be handled in > > > > > > > some kind of legacy file for the N900 which calls save_atags() > > > > > > > on it, so we don't end up introducing yet more stuff that we > > > > > > > have to maintain into the distant future? If not, what about > > > > > > > copying a known working atag structure into a legacy file for > > > > > > > the N900? > > > > > > > > > > > > I already asked question if it is possible to read ATAGs from DT > > > > > > booted kernel. And somebody (do not remember who) wrote to ML, > > > > > > that it is not possible and it can be done in that uncompress > > > > > > code. > > > > > > > > Who is that somebody? If ever it happened to be me then objection is > > > > withdrawn. Otherwise that somebody should come forth and speak up > > > > again. > > > > > > > > > > ... do not remember ... this discussion were in more email threads and > > > takes more then one year... sorry but my memory is not excellent > > > > Yes this certainly seems like the best solution. I think we got into > > the atags-to-dt track as some of the atags are already being translated. > > > > In this case there's no need to translate them AFAIK. You can just > > parse them and have them available for the user space. So as long as > > nothing trashes the atags at the atag_offset, you should be able to > > call a function to parse them in the n900 specific init_machine. > > > > Regards, > > > > Tony > > In arch/arm/kernel/setup.c is function setup_arch() and it calls: > > mdesc = setup_machine_fdt(__atags_pointer); > if (!mdesc) > mdesc = setup_machine_tags(__atags_pointer, __machine_arch_type); > > So it looks like that on atags address is stored either atags structure > or DT structure... so it is truth kernel uncompress code put DT blob to > same offset where is expected atags structure? No. It doesn't put it anywhere. Those functions read DT/ATAGs from the passed address. But you know this address won't be the one you want for the legacy ATAGs. What you should do is to add a init_early hook to your mdesc structure and retrieve your ATAGs from there directly at PAGE_OFFSET + 0x100. Now I suspect paging_init() marks the point where the ATAGs will be overwritten. To prevent this, you might have to add an additional tweak in arm_mm_memblock_reserve() similar to the one already present for CONFIG_SA. Something like: memblock_reserve(PHYS_OFFSET, PAGE_SIZE); And later on you can return that page back to the system. Nicolas
Re: [PATCH 5/5] arm: boot: store ATAGs structure into DT "/chosen/linux,atags" entry
On Sun, 29 Nov 2015, Russell King - ARM Linux wrote: > On Sat, Nov 28, 2015 at 12:34:23PM -0500, Nicolas Pitre wrote: > > Good. And Arnd likes the idea too. So we might be converging at last > > which is a good thing. > > I disagree with the idea that there is convergence. There might be > convergence towards an idea, but... Here's a mail extract, from July > 7th, from earlier in this very thread: > > Pali: > > Me: > > > Are the ATAGs at a fixed address on the N900? > > > > Yes, in board-rx51.c is: > > > > .atag_offset= 0x100 > > > > and Nokia Bootloader (proprietary) store them to that address. > > > > > Can that be handled in > > > some kind of legacy file for the N900 which calls save_atags() on it, so > > > we don't end up introducing yet more stuff that we have to maintain into > > > the distant future? If not, what about copying a known working atag > > > structure into a legacy file for the N900? > > > > > > > I already asked question if it is possible to read ATAGs from DT booted > > kernel. And somebody (do not remember who) wrote to ML, that it is not > > possible and it can be done in that uncompress code. Who is that somebody? If ever it happened to be me then objection is withdrawn. Otherwise that somebody should come forth and speak up again. > So you're converging on an idea that has already been rejected. That's > not a good thing, IMHO. All the alternatives are worse and being rejected as well. In that case we should settle on the idea that satisfies the most people. Nicolas -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/5] arm: boot: store ATAGs structure into DT "/chosen/linux,atags" entry
On Sat, 28 Nov 2015, Russell King - ARM Linux wrote: > On Fri, Nov 27, 2015 at 06:28:50PM -0500, Nicolas Pitre wrote: > > On Fri, 27 Nov 2015, Arnd Bergmann wrote: > > > > > I don't mind creating the /proc/atags compatibility hack from the kernel > > > for a DT based N700 kernel, as long as we limit it as much as we can > > > to the machines that need it. Leaving a board file for the N700 in place > > > that contains the procfs code (and not much more) seems reasonable > > > here, as we are talking about a board specific hack and the whole point > > > appears to be running unmodified user space. > > > > > > Regarding how to get the data into the kernel in the first place, my > > > preferred choice would still be to have an intermediate bootloader > > > such as pxa-impedance-matcher, but I won't complain if others are > > > happy enough about putting it into the ATAGS compat code we already > > > have, as long as it's limited to the boards we know need it. > > > > Assuming you have a N700 board file for special procfs code, then why > > not getting at the atags in memory where the bootloader has put them > > directly from that same board file? This way it'll really be limited to > > the board we know needs it and the special exception will be contained > > to that one file. Amongst the machine specific hooks, there is one that > > gets invoked early during boot before those atags are overwritten. > > I've already suggested that. Good. And Arnd likes the idea too. So we might be converging at last which is a good thing. Nicolas -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/5] arm: boot: store ATAGs structure into DT "/chosen/linux,atags" entry
On Fri, 27 Nov 2015, Arnd Bergmann wrote: > I don't mind creating the /proc/atags compatibility hack from the kernel > for a DT based N700 kernel, as long as we limit it as much as we can > to the machines that need it. Leaving a board file for the N700 in place > that contains the procfs code (and not much more) seems reasonable > here, as we are talking about a board specific hack and the whole point > appears to be running unmodified user space. > > Regarding how to get the data into the kernel in the first place, my > preferred choice would still be to have an intermediate bootloader > such as pxa-impedance-matcher, but I won't complain if others are > happy enough about putting it into the ATAGS compat code we already > have, as long as it's limited to the boards we know need it. Assuming you have a N700 board file for special procfs code, then why not getting at the atags in memory where the bootloader has put them directly from that same board file? This way it'll really be limited to the board we know needs it and the special exception will be contained to that one file. Amongst the machine specific hooks, there is one that gets invoked early during boot before those atags are overwritten. Nicolas -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ti/clkt_dpll: fix wrong do_div() usage
do_div() is meant to be used with an unsigned dividend.
Signed-off-by: Nicolas Pitre <n...@linaro.org>
diff --git a/drivers/clk/ti/clkt_dpll.c b/drivers/clk/ti/clkt_dpll.c
index 9023ca9caf..b5cc6f66ae 100644
--- a/drivers/clk/ti/clkt_dpll.c
+++ b/drivers/clk/ti/clkt_dpll.c
@@ -240,7 +240,7 @@ u8 omap2_init_dpll_parent(struct clk_hw *hw)
*/
unsigned long omap2_get_dpll_rate(struct clk_hw_omap *clk)
{
- long long dpll_clk;
+ u64 dpll_clk;
u32 dpll_mult, dpll_div, v;
struct dpll_data *dd;
@@ -262,7 +262,7 @@ unsigned long omap2_get_dpll_rate(struct clk_hw_omap *clk)
dpll_div = v & dd->div1_mask;
dpll_div >>= __ffs(dd->div1_mask);
- dpll_clk = (long long)clk_get_rate(dd->clk_ref) * dpll_mult;
+ dpll_clk = (u64)clk_get_rate(dd->clk_ref) * dpll_mult;
do_div(dpll_clk, dpll_div + 1);
return dpll_clk;
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ti/fapll: fix wrong do_div() usage
do_div() is meant to be used with an unsigned dividend.
Signed-off-by: Nicolas Pitre <n...@linaro.org>
diff --git a/drivers/clk/ti/fapll.c b/drivers/clk/ti/fapll.c
index f4b2e9888b..66a0d0ed8b 100644
--- a/drivers/clk/ti/fapll.c
+++ b/drivers/clk/ti/fapll.c
@@ -168,7 +168,7 @@ static unsigned long ti_fapll_recalc_rate(struct clk_hw *hw,
{
struct fapll_data *fd = to_fapll(hw);
u32 fapll_n, fapll_p, v;
- long long rate;
+ u64 rate;
if (ti_fapll_clock_is_bypass(fd))
return parent_rate;
@@ -314,7 +314,7 @@ static unsigned long ti_fapll_synth_recalc_rate(struct
clk_hw *hw,
{
struct fapll_synth *synth = to_synth(hw);
u32 synth_div_m;
- long long rate;
+ u64 rate;
/* The audio_pll_clk1 is hardwired to produce 32.768KiHz clock */
if (!synth->div)
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: N900 v3.19-rc5 arm atags_to_fdt.c is broken
On Mon, 2 Feb 2015, Pavel Machek wrote: On Tue 2015-01-27 10:16:24, Nicolas Pitre wrote: On Tue, 27 Jan 2015, Pavel Machek wrote: I would say, problem is because omap3-n900 binary DT is too large I agree. OK if that's the case, then your patch makes sense to me. It also seems we can have the temporary stack be larger than the initial stack just for atags_to_fdt. The stack size isn't the issue, but rather its location. We need to position it away from the DT data. The DT size is known and we could use that, plus some room for the insertion of new data coming from the ATAG conversion. Something like the following would be a more robust solution: Tested-by: Pavel Machek pa...@ucw.cz (Note, that in 3.19 dts for n900 got too big, so we are actually triggering old bugs. That means that this is a regression fix, and should go in ASAP). It is queued here: http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=8294/1 Hmm, but it should be on kernel.org, not in private arm trees, as it fixes a regression. Russell, you are the ARM maintainer, can you push it to Linus? The patch is included in RMK's fixes branch already, along with other fixes. I suppose it'll make its way to Linus before v3.19 final. Nicolas -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: N900 v3.19-rc5 arm atags_to_fdt.c is broken
On Tue, 27 Jan 2015, Russell King - ARM Linux wrote: On Tue, Jan 27, 2015 at 10:16:24AM -0500, Nicolas Pitre wrote: On Tue, 27 Jan 2015, Pavel Machek wrote: (Note, that in 3.19 dts for n900 got too big, so we are actually triggering old bugs. That means that this is a regression fix, and should go in ASAP). It is queued here: http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=8294/1 Irrespective of that patch, I commented on another thread (about adding the serial number to DT): | How about something a little more radical. | | Rather than trying to squeeze various ATAGs into DT, why don't we add a | standard ATAG to contain the DT and pass that through into the kernel. | This is IMHO how we _should_ have done the ATAG compatibility from the | start. | | That means we could get rid of most of the libfdt in the decompressor, | and instead resolve the differences in the kernel. That would allow us to get rid of all the FDT compatibility code in the decompressor, and when we encounter these special ATAGs, we can deal with them in the kernel instead of having to mess around with the DT. I'd also assume (although I haven't checked) that it would be much easier to add additional DT properties in the kernel environment, rather than in the rather restrictive decompressor environment. Well... I was initially against any ATAG-to-DT compatibility at all. IMHO the right solution is to update the bootloader. However people complained that updating the bootloader wasn't possible. I therefore suggested they go with a shim layer I termed the impedance matcher acting like an intermediate boot stage converting their (often unofficial and out-of-tree) ATAGs into proper DT nodes. Some people did exactly that and it works wonderfully for them. It also works wonderfully for kernel maintenance as the platform specific tweaks are kept out of the kernel tree. Still, that wasn't good enough for some cases as the move to DT regressed some platforms that just used to work before. Concatenating a DTB to zImage was tolerable but installing an additional shim layer was too much. Hence the ATAG-to-DT compat code in the decompressor. This was meant to smooth things around the transition to DT, etc. After all, those devices with non-replaceable bootloaders where shim layers are not possible should get out of commission eventually? We'd need to be careful about how we deal with the atags vs DT. I'd suggest (as above) that we have a tag which points at the DT in physical memory, and its size, and pre-scan the atag list for that. When we find it, we kick off the DT based stuff as we would normally do, and follow it with a parse of the atags. This would cause the atags to override whatever is in the DT, which afaics is the behaviour that we actually want. Maybe. However that would be yet another scheme for supporting legacy platforms with locked bootloaders. I really think we have enough of them already and I'd much prefer if we started _removing_ them not creating additional ones. The ATAG-to-DT code in the bootloader is still rather small and it works quite well, and it allows for configuring out ATAG support out of the kernel entirely. It should be sufficient for all the official (e.g. upstream) ATAGs already. If that's not good enough then people should consider the impedance matcher approach. We could augment that with code to update DT too so that we can export just the DT based information to kexec'd kernels. That should already be the case, no? Nicolas -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: N900 v3.19-rc5 arm atags_to_fdt.c is broken
On Tue, 27 Jan 2015, Pavel Machek wrote: I would say, problem is because omap3-n900 binary DT is too large I agree. OK if that's the case, then your patch makes sense to me. It also seems we can have the temporary stack be larger than the initial stack just for atags_to_fdt. The stack size isn't the issue, but rather its location. We need to position it away from the DT data. The DT size is known and we could use that, plus some room for the insertion of new data coming from the ATAG conversion. Something like the following would be a more robust solution: Tested-by: Pavel Machek pa...@ucw.cz (Note, that in 3.19 dts for n900 got too big, so we are actually triggering old bugs. That means that this is a regression fix, and should go in ASAP). It is queued here: http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=8294/1 Nicolas -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: N900 v3.19-rc5 arm atags_to_fdt.c is broken
On Mon, 26 Jan 2015, Tony Lindgren wrote:
* Pali Rohár pali.ro...@gmail.com [150126 08:26]:
On Monday 26 January 2015 17:14:55 Tony Lindgren wrote:
* Pali Rohár pali.ro...@gmail.com [150123 14:39]:
On Friday 23 January 2015 22:39:55 Pali Rohár wrote:
Hello,
when I boot zImage with appended DT n900 in qemu
fdt_open_into() function called from file
arch/arm/boot/compressed/atags_to_fdt.c (in function
atags_to_fdt) always returns -FDT_ERR_NOSPACE.
It means that all ATAGS (including cmdline arguments)
passed by bootloader are ignored.
On real n900 device I see that booted DT version also
ignore cmdline arguments from bootloader. I cannot debug
decompress code on real device, but I think it is same
problem as in qemu.
Looks like this quick patch is fixing above problem:
diff --git a/arch/arm/boot/compressed/head.S
b/arch/arm/boot/compressed/head.S index 68be901..4a7d75b
100644
--- a/arch/arm/boot/compressed/head.S
+++ b/arch/arm/boot/compressed/head.S
@@ -268,7 +268,7 @@ restart:adr r0, LC0
* area. No GOT fixup has occurred yet, but none of
the
* code we're about to call uses any global variable.
*/
- add sp, sp, #0x1
+ add sp, sp, #0x2
stmfd sp!, {r0-r3, ip, lr}
mov r0, r8
mov r1, r6
@@ -289,7 +289,7 @@ restart:adr r0, LC0
bleqatags_to_fdt
ldmfd sp!, {r0-r3, ip, lr}
- sub sp, sp, #0x1
+ sub sp, sp, #0x2
#endif
mov r8, r6 @ use the appended
device tree
Nico, got any ideas about this one? This seems like a
regression somewhere..
Regards,
Tony
$ du -b arch/arm/boot/dts/omap3-n900.dtb
70212 arch/arm/boot/dts/omap3-n900.dtb
$ echo $((0x1))
65536
I would say, problem is because omap3-n900 binary DT is too large
I agree.
OK if that's the case, then your patch makes sense to me. It also
seems we can have the temporary stack be larger than the initial
stack just for atags_to_fdt.
The stack size isn't the issue, but rather its location. We need to
position it away from the DT data. The DT size is known and we could
use that, plus some room for the insertion of new data coming from the
ATAG conversion.
Something like the following would be a more robust solution:
diff --git a/arch/arm/boot/compressed/head.S b/arch/arm/boot/compressed/head.S
index 68be901759..89718de9dd 100644
--- a/arch/arm/boot/compressed/head.S
+++ b/arch/arm/boot/compressed/head.S
@@ -263,16 +263,37 @@ restart: adr r0, LC0
* OK... Let's do some funky business here.
* If we do have a DTB appended to zImage, and we do have
* an ATAG list around, we want the later to be translated
-* and folded into the former here. To be on the safe side,
-* let's temporarily move the stack away into the malloc
-* area. No GOT fixup has occurred yet, but none of the
-* code we're about to call uses any global variable.
+* and folded into the former here. No GOT fixup has occurred
+* yet, but none of the code we're about to call uses any
+* global variable.
*/
- add sp, sp, #0x1
+
+ /* Get the initial DTB size */
+ ldr r5, [r6, #4]
+#ifndef __ARMEB__
+ /* convert to little endian */
+ eor r1, r5, r5, ror #16
+ bic r1, r1, #0x00ff
+ mov r5, r5, ror #8
+ eor r5, r5, r1, lsr #8
+#endif
+ /* 50% DTB growth should be good enough */
+ add r5, r5, r5, lsr #1
+ /* preserve 64-bit alignment */
+ add r5, r5, #7
+ bic r5, r5, #7
+ /* clamp to 32KB min and 1MB max */
+ movsr1, r5, lsr #15
+ moveq r5, #(1 15)
+ movsr1, r5, lsr #20
+ movne r5, #(1 20)
+
+ /* Temporarily relocate the stack past the DTB work space */
+ add sp, sp, r5
stmfd sp!, {r0-r3, ip, lr}
mov r0, r8
mov r1, r6
- sub r2, sp, r6
+ mov r2, r5
bl atags_to_fdt
/*
@@ -285,11 +306,11 @@ restart: adr r0, LC0
bic r0, r0, #1
add r0, r0, #0x100
mov r1, r6
- sub r2, sp, r6
+
Re: N900 v3.19-rc5 arm atags_to_fdt.c is broken
On Mon, 26 Jan 2015, Pavel Machek wrote: Hi! $ du -b arch/arm/boot/dts/omap3-n900.dtb 70212 arch/arm/boot/dts/omap3-n900.dtb $ echo $((0x1)) 65536 I would say, problem is because omap3-n900 binary DT is too large I agree. OK if that's the case, then your patch makes sense to me. It also seems we can have the temporary stack be larger than the initial stack just for atags_to_fdt. The stack size isn't the issue, but rather its location. We need to position it away from the DT data. The DT size is known and we could use that, plus some room for the insertion of new data coming from the ATAG conversion. Something like the following would be a more robust solution: diff --git a/arch/arm/boot/compressed/head.S b/arch/arm/boot/compressed/head.S index 68be901759..89718de9dd 100644 --- a/arch/arm/boot/compressed/head.S +++ b/arch/arm/boot/compressed/head.S @@ -263,16 +263,37 @@ restart: adr r0, LC0 * OK... Let's do some funky business here. * If we do have a DTB appended to zImage, and we do have * an ATAG list around, we want the later to be translated -* and folded into the former here. To be on the safe side, -* let's temporarily move the stack away into the malloc -* area. No GOT fixup has occurred yet, but none of the -* code we're about to call uses any global variable. +* and folded into the former here. No GOT fixup has occurred +* yet, but none of the code we're about to call uses any +* global variable. */ - add sp, sp, #0x1 + + /* Get the initial DTB size */ + ldr r5, [r6, #4] +#ifndef __ARMEB__ + /* convert to little endian */ + eor r1, r5, r5, ror #16 + bic r1, r1, #0x00ff + mov r5, r5, ror #8 + eor r5, r5, r1, lsr #8 +#endif + /* 50% DTB growth should be good enough */ + add r5, r5, r5, lsr #1 + /* preserve 64-bit alignment */ + add r5, r5, #7 + bic r5, r5, #7 + /* clamp to 32KB min and 1MB max */ + movsr1, r5, lsr #15 + moveq r5, #(1 15) + movsr1, r5, lsr #20 + movne r5, #(1 20) Dunno. Would it be easier/simpler to just use 1MB, always? Do we support machines with 16MB RAM? If people are used to put other things relatively close to the kernel image like, say, some initrd image, then I'd prefer to be more conservative and avoid spreading out too much. Nicolas -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: Blacklist GCC 4.8.0 to GCC 4.8.2 - PR58854
On Thu, 16 Oct 2014, Russell King - ARM Linux wrote: So, let me put this another way: a compiler with this bug is _completely_ unsuitable for use for compiling programs for use under the Linux kernel _as well_ as the Linux kernel itself. The difference is that the Linaro compilers come with an expectation that they are usable on ARM... whereas stock versions cover a lot more and so the ARM arch is probably very small number of their users. Hence why I recommend that Linaro takes down their buggy compiler. Their 4.8.3 version should not be used *anywhere*, just the same as the stock 4.8 to 4.8.2 inclusive should also not be used anywhere on ARM either. Here's the answer from the toolchain team: On Thu, 16 Oct 2014, Yvan Roux yvan.r...@linaro.org wrote: | Hi Nicolas, | | thanks for bringing this to our knowledge. | | The fix for PR58854 was included in our releases since the GCC | 4.8-2013.12 which is based on a 4.8.3 prerelease version (at svn | revision 205577). As we are doing monthly releases based on a | revision of the related FSF branch, using GCC_VERSION (__GNUC__, | __GNUC_MINOR,__GNUC_PATCHLEVEL) is not accurate enough to identify the | release version (all our releases between November 2013 and May 2014 | will be 4.8.3) the __VERSION__ predefined macro is a bit more accurate | here (4.8.3 20131202 (prerelease)) but not completely satisfactory. | | I completely agree that we should at least mention in our impacted | releases download pages that this bug is present. Nicolas -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: convert all mov.* pc, reg to bx reg for ARMv6+ (part1)
On Tue, 1 Jul 2014, Will Deacon wrote: Hi Mans, On Tue, Jul 01, 2014 at 06:24:43PM +0100, Måns Rullgård wrote: Russell King - ARM Linux li...@arm.linux.org.uk writes: As you point out, bx lr /may/ be treated specially (I've actually been Most, if not all, Cortex-A cores do this according the public TRMs. They also do the same thing for mov pc, lr so there will probably be no performance gain from this change. It's still a good idea though, since we don't know what future cores will do. Funnily enough, that's not actually true (and is more or less what prompted this patch after discussion with Russell). There are cores out there that don't predict mov pc, lr at all (let alone do anything with the return stack). discussing this with Will Deacon over the last couple of days, who has also been talking to the hardware people in ARM, and Will is happy with this patch as in its current form.) This is why I've changed all mov pc, reg instructions which return in some way to use this macro, and left others (those which are used to call some function and return back to the same point) alone. In that case the patch should be fine. Your patch description didn't make it clear that only actual returns were being changed. I'm led to believe that some predictors require lr in order to update the return stack, whilst others don't. That part is all horribly micro-architectural, so the current patch is doing the right thing by sticking to the ARM ARM but enabling us to hook into other registers later on if we choose. May I suggest to have a patch with only the macro definition in it and all this discussion in the commit log please? The usage sites should be done in a separate patch to make it clearer. Nicolas
Re: new binutils needed for arm in 3.12-rc1
On Wed, 25 Sep 2013, Rob Landley wrote:
On 09/24/2013 09:07:57 PM, Nicolas Pitre wrote:
I'd strongly suggest you make your binutils compatible with newer
instruction syntax instead of making the kernel more complex.
Meaning I play whack-a-mole as this becomes permission to depend on endless
new gnuisms just because they're there and nobody else is regression testing
against them, not because they actually add anything.
Gnuism?
Let me quote the ARM ARchitecture Reference Manual, version 7 revision C,
section A8.8.44 (sorry for the whitespace dammage):
|A8.8.44 DSB
|
|Data Synchronization Barrier is a memory barrier that ensures the
|completion of memory accesses, see Data Synchronization Barrier (DSB) on
|page A3-150.
|
|Encoding T1 ARMv7
|
|DSBc option
|
|15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
|
|1 1 1 1 0 0 1 1 1 0 1 1 (1) (1) (1) (1) 1 0 (0) 0 (1) (1) (1) (1) 0 1 0 0
option
|
|// No additional decoding required
|
|Encoding A1 ARMv7
|
|DSB option
|
|31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4
3 2 1 0
|
|1 1 1 1 0 1 0 1 0 1 1 1 (1) (1) (1) (1) (1) (1) (1) (1) (0) (0) (0) (0) 0 1 0
0 option
|
|// No additional decoding required
|
|Assembler syntax
|
|DSB{c}{q} {option}
|
|where:
|
|c, q See Standard assembler syntax fields on page A8-285. An ARM DSB
|instruction must be unconditional.
|
|option Specifies an optional limitation on the DSB operation. Values are:
|
|SY Full system is the required shareability domain, reads and writes are
|the required access types. Can be omitted. This option is referred to as
|the full system DSB. Encoded as option == ''.
|
|ST Full system is the required shareability domain, writes are the
|required access type. SYST is a synonym for ST. Encoded as option ==
|'1110'.
|
|ISH Inner Shareable is the required shareability domain, reads and
|writes are the required access types. Encoded as option == '1011'.
|
|ISHST Inner Shareable is the required shareability domain, writes are
|the required access type. Encoded as option == '1010'.
|
|NSH Non-shareable is the required shareability domain, reads and writes
|are the required access types. Encoded as option == '0111'.
|
|NSHST Non-shareable is the required shareability domain, writes are the
|required access type. Encoded as option == '0110'.
|
|OSH Outer Shareable is the required shareability domain, reads and
|writes are the required access types. Encoded as option == '0011'.
|
|OSHST Outer Shareable is the required shareability domain, writes are
|the required access type. Encoded as option == '0010'.
So what's the link with the above and your issue with GPLv3, besides the
fact that the last binutils version to have been released under the
GPLv2 is defficient?
For the record I have no opinion to provide about GPLv2 vs GPLv3 in the
context of this thread.
It could be as simple as making gas accept an extra argument for
instructions like dsb and just ignoring it.
So you prefer I come up with the reversion patches locally and _not_ send them
upstream?
Sort of. And I'm suggesting you patch your binutils rather than the
kernel. Given you're not upgrading your binutils anymore that means
you'll have to apply that patch only once instead of having to apply it
to every kernel upgrade.
But I do at least post said patches publicly, and other people use 'em
when I do...
Excellent.
Nicolas
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: new binutils needed for arm in 3.12-rc1
On Tue, 24 Sep 2013, Rob Landley wrote: On 09/24/2013 04:48:00 PM, Russell King - ARM Linux wrote: Now, if you feel strongly about this, we _could_ introduce a CONFIG_OLD_BINUTILS and give everyone their cake - but it will be fragile. Not everyone will remember to get that right, because they'll be using the later binutils. Also, we already have an excessive number of potential breakage-inducing options and we certainly don't need another. I'm doing the regression testing either way, on several different architectures. (Although I tend to to only really do a thorough job quarterly when a new kernel comes out and it's time to make it work.) So I'm going to be doing something locally like this anyway, and if a CONFIG_OLD_BINUTILS is acceptable I might as well push it upstream. If you are convinced you have no choice but to stick to old binutils, I'd strongly suggest you make your binutils compatible with newer instruction syntax instead of making the kernel more complex. This is more in line with being future proof rather than stuck into the past. It could be as simple as making gas accept an extra argument for instructions like dsb and just ignoring it. Nicolas -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Build error in torvalds kernel 3.11 for omap2plus
On Mon, 9 Sep 2013, Guenter Roeck wrote: On 09/09/2013 03:51 AM, Russell King - ARM Linux wrote: On Sun, Sep 08, 2013 at 10:16:14AM -0700, Guenter Roeck wrote: Since we are at it: Build reference: v3.11-7887-gb409624 Building arm:defconfig ... passed Building arm:allmodconfig ... failed -- Error log: arch/arm/mach-cns3xxx/pcie.c: In function 'cns3xxx_pcie_hw_init': arch/arm/mach-cns3xxx/pcie.c:350:1: warning: the frame size of 1064 bytes is larger than 1024 bytes [-Wframe-larger-than=] arch/arm/kernel/return_address.c:63:2: warning: #warning TODO: return_address should use unwind tables [-Wcpp] arch/arm/kernel/return_address.c:63:2: warning: #warning TODO: return_address should use unwind tables [-Wcpp] /tmp/cce439dZ.s: Assembler messages: /tmp/cce439dZ.s:506: Error: selected processor does not support ARM mode `isb ' /tmp/cce439dZ.s:512: Error: selected processor does not support ARM mode `isb ' /tmp/cce439dZ.s:513: Error: selected processor does not support ARM mode `dsb ' /tmp/cce439dZ.s:583: Error: selected processor does not support ARM mode `isb ' /tmp/cce439dZ.s:589: Error: selected processor does not support ARM mode `isb ' /tmp/cce439dZ.s:590: Error: selected processor does not support ARM mode `dsb ' make[1]: *** [arch/arm/mach-vexpress/dcscb.o] Error 1 make: *** [arch/arm/mach-vexpress] Error 2 make: *** Waiting for unfinished jobs -- Any solution for this one ? omap2plus passes for me. gcc version used is arm-poky-linux-gnueabi-gcc (GCC) 4.7.2 from poky 1.3. That's due to: commit e8f9bb1bd6bb93fff773345cc54c42585e0e3ece Author: Nicolas Pitre nicolas.pi...@linaro.org Date: Tue Jul 16 20:59:53 2013 -0400 ARM: vexpress/dcscb: fix cache disabling sequences Unlike real A15/A7's, the RTSM simulation doesn't appear to hit the cache when the CTRL.C bit is cleared. Let's ensure there is no memory access within the disable and flush cache sequence, including to the stack. Signed-off-by: Nicolas Pitre n...@linaro.org which introduces some 'isb' and 'dsb' instructions which are not available on ARMv6 CPUs - however, their 'mcr' equivalents are. Either dcscb needs to be built with an -march=armv7 override, or they need to use the mcr equivalent instructions. Well, I hope it will get fixed one way or another. I don't know enough about arm to fix it myself. Would you try this patch please: diff --git a/arch/arm/mach-vexpress/Makefile b/arch/arm/mach-vexpress/Makefile index 36ea824712..505e64ab3e 100644 --- a/arch/arm/mach-vexpress/Makefile +++ b/arch/arm/mach-vexpress/Makefile @@ -7,6 +7,8 @@ ccflags-$(CONFIG_ARCH_MULTIPLATFORM) := -I$(srctree)/$(src)/include \ obj-y := v2m.o obj-$(CONFIG_ARCH_VEXPRESS_CA9X4) += ct-ca9x4.o obj-$(CONFIG_ARCH_VEXPRESS_DCSCB) += dcscb.o dcscb_setup.o +CFLAGS_dcscb.o += -march=armv7-a obj-$(CONFIG_ARCH_VEXPRESS_TC2_PM) += tc2_pm.o spc.o +CFLAGS_tc2_pm.o+= -march=armv7-a obj-$(CONFIG_SMP) += platsmp.o obj-$(CONFIG_HOTPLUG_CPU) += hotplug.o -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Build error in torvalds kernel 3.11 for omap2plus
Adding Kevin Hilman to the CC as he might be interested as well. On Mon, 9 Sep 2013, Guenter Roeck wrote: On Mon, Sep 09, 2013 at 09:31:41PM +0100, Russell King - ARM Linux wrote: On Mon, Sep 09, 2013 at 09:03:48AM -0700, Guenter Roeck wrote: Unfortunately, there are more problems. arch/arm/kernel/built-in.o: In function `ret_fast_syscall': /home/groeck/src/linux-stable/arch/arm/kernel/entry-common.S:42: undefined reference to `user_enter' arch/arm/kernel/built-in.o: In function `no_work_pending': /home/groeck/src/linux-stable/arch/arm/kernel/entry-common.S:77: undefined reference to `user_enter' arch/arm/kernel/built-in.o: In function `vector_swi': /home/groeck/src/linux-stable/arch/arm/kernel/entry-common.S:376: undefined reference to `user_exit' arch/arm/kernel/built-in.o: In function `__dabt_usr': /home/groeck/src/linux-stable/arch/arm/kernel/entry-armv.S:365: undefined reference to `user_exit' arch/arm/kernel/built-in.o: In function `__irq_usr': /home/groeck/src/linux-stable/arch/arm/kernel/entry-armv.S:375: undefined reference to `user_exit' arch/arm/kernel/built-in.o: In function `__und_usr': /home/groeck/src/linux-stable/arch/arm/kernel/entry-armv.S:388: undefined reference to `user_exit' arch/arm/kernel/built-in.o: In function `__pabt_usr': /home/groeck/src/linux-stable/arch/arm/kernel/entry-armv.S:662: undefined reference to `user_exit' These are due to ad65782fba50 (context_tracking: Optimize main APIs off case with static key) converting these functions to be inline. No idea what the fix for this is other than reverting the change. Any ideas Frederic? I am all for reverting unless this can be fixed quickly. AFAICS this breaks all arm builds if CONFIG_CONTEXT_TRACKING is enabled. Guenter -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Latest build results - errors/warnings - lots of them
On Tue, 30 Apr 2013, Dave Martin wrote: On Tue, Apr 30, 2013 at 01:04:20PM +0200, Arnd Bergmann wrote: On Tuesday 30 April 2013, Russell King - ARM Linux wrote: Latest nightly build of 3.9+my for-next+arm-soc's for-next results in a great load of new warnings and errors. arch/arm/common/mcpm_head.S, arch/arm/common/mcpm_platsmp.c, arch/arm/common/vlock.S are the biggest source of errors. [...] arch/arm/common/mcpm_head.S:39: Error: selected processor does not support ARM mode `ubfx r9,r0,#0,#8' arch/arm/common/mcpm_head.S:40: Error: selected processor does not support ARM mode `ubfx r10,r0,#8,#8' arch/arm/common/mcpm_head.S:100: Error: selected processor does not support ARM mode `dmb' arch/arm/common/mcpm_head.S:115: Error: selected processor does not support ARM mode `dmb' arch/arm/common/mcpm_head.S:127: Error: selected processor does not support ARM mode `dmb' arch/arm/common/mcpm_head.S:131: Error: selected processor does not support ARM mode `dmb' arch/arm/common/mcpm_head.S:138: Error: selected processor does not support ARM mode `dsb' arch/arm/common/mcpm_head.S:152: Error: selected processor does not support ARM mode `dmb' arch/arm/common/mcpm_head.S:161: Error: selected processor does not support ARM mode `dmb' arch/arm/common/mcpm_head.S:175: Error: selected processor does not support ARM mode `dmb' arch/arm/common/vlock.S:62: Error: selected processor does not support ARM mode `dmb' arch/arm/common/vlock.S:72: Error: selected processor does not support ARM mode `dmb' arch/arm/common/vlock.S:72: Error: selected processor does not support ARM mode `dsb' arch/arm/common/vlock.S:89: Error: selected processor does not support ARM mode `dmb' arch/arm/common/vlock.S:95: Error: selected processor does not support ARM mode `dmb' arch/arm/common/vlock.S:95: Error: selected processor does not support ARM mode `dsb' arch/arm/common/vlock.S:102: Error: selected processor does not support ARM mode `dmb' arch/arm/common/vlock.S:105: Error: selected processor does not support ARM mode `dsb' Right, the problem here is that the code was never tested with an ARMv6+ARMv7 config. We can either fix it up by adding .arch armv7-a in the assembly files, or by doing the same in the Makefile: AFLAGS_vlock.S += -march=armv7-a AFLAGS_mcpm_head.S += -march=armv7-a Hmmm, this code was tested with ARCH_MULTIPLATFORM, but it looks like no v6 boards were configured in when testing that... Assuming people are OK with the Makefile route, here's a patch for that, build-tested with a v6+v7 ARCH_MULTIPLATFORM config. Isn't the .arch armv7-a route a bit cleaner? That would have been my choice, although I don't feel strongly about it. Nicolas -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Latest build results - errors/warnings - lots of them
On Tue, 30 Apr 2013, Dave Martin wrote: On Tue, Apr 30, 2013 at 11:12:12AM -0400, Nicolas Pitre wrote: On Tue, 30 Apr 2013, Dave Martin wrote: On Tue, Apr 30, 2013 at 01:04:20PM +0200, Arnd Bergmann wrote: On Tuesday 30 April 2013, Russell King - ARM Linux wrote: Latest nightly build of 3.9+my for-next+arm-soc's for-next results in a great load of new warnings and errors. arch/arm/common/mcpm_head.S, arch/arm/common/mcpm_platsmp.c, arch/arm/common/vlock.S are the biggest source of errors. [...] arch/arm/common/mcpm_head.S:39: Error: selected processor does not support ARM mode `ubfx r9,r0,#0,#8' arch/arm/common/mcpm_head.S:40: Error: selected processor does not support ARM mode `ubfx r10,r0,#8,#8' arch/arm/common/mcpm_head.S:100: Error: selected processor does not support ARM mode `dmb' arch/arm/common/mcpm_head.S:115: Error: selected processor does not support ARM mode `dmb' arch/arm/common/mcpm_head.S:127: Error: selected processor does not support ARM mode `dmb' arch/arm/common/mcpm_head.S:131: Error: selected processor does not support ARM mode `dmb' arch/arm/common/mcpm_head.S:138: Error: selected processor does not support ARM mode `dsb' arch/arm/common/mcpm_head.S:152: Error: selected processor does not support ARM mode `dmb' arch/arm/common/mcpm_head.S:161: Error: selected processor does not support ARM mode `dmb' arch/arm/common/mcpm_head.S:175: Error: selected processor does not support ARM mode `dmb' arch/arm/common/vlock.S:62: Error: selected processor does not support ARM mode `dmb' arch/arm/common/vlock.S:72: Error: selected processor does not support ARM mode `dmb' arch/arm/common/vlock.S:72: Error: selected processor does not support ARM mode `dsb' arch/arm/common/vlock.S:89: Error: selected processor does not support ARM mode `dmb' arch/arm/common/vlock.S:95: Error: selected processor does not support ARM mode `dmb' arch/arm/common/vlock.S:95: Error: selected processor does not support ARM mode `dsb' arch/arm/common/vlock.S:102: Error: selected processor does not support ARM mode `dmb' arch/arm/common/vlock.S:105: Error: selected processor does not support ARM mode `dsb' Right, the problem here is that the code was never tested with an ARMv6+ARMv7 config. We can either fix it up by adding .arch armv7-a in the assembly files, or by doing the same in the Makefile: AFLAGS_vlock.S += -march=armv7-a AFLAGS_mcpm_head.S += -march=armv7-a Hmmm, this code was tested with ARCH_MULTIPLATFORM, but it looks like no v6 boards were configured in when testing that... Assuming people are OK with the Makefile route, here's a patch for that, build-tested with a v6+v7 ARCH_MULTIPLATFORM config. Isn't the .arch armv7-a route a bit cleaner? That would have been my choice, although I don't feel strongly about it. I don't feel strongly either. We already have the CFLAGS_DISABLE stuff, so it didn't feel that unnatural to add this in the Makefile; but .arch would work equally well. If somebody wants to change it, it's not a problem for me, but I didn't want to create extra disruption by proposing a different patch... Fair enough. Acked-by: Nicolas Pitre n...@linaro.org Cheers ---Dave -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [U-Boot] [RFC] Kbuild support for ARM FIT images
On Thu, 21 Feb 2013, Tom Rini wrote: FIT isn't required. FIT is just trying to offer a nice usability thing to folks. Usability is often counter-balanced by maintenance costs. A point of device trees is a single image works in a lot of places. FIT gives you a single file works in a lot of places. The whole _point_ for bringing DT into the ARM land was to decouple the the various platform specific stuff from the kernel, and even allow existing distros to work on yet-to-be-created devices unchanged, just like X86 PC class machines. Now you're suggesting that the kernel and the DT information should be glued together again. That looks like a move backward to me. Yet, having that platform stuff in plain C code as we had before, given it is maintained properly, is still the most efficient way to achieve that usability wise. So let's stop kidding ourselves and be coherent please: either we move device specifics away from the kernel, or we keep them together. In other words, the DT should ideally come preinstalled with the bootloader on a given board/device for distros to not even have to care about it, or we put that data back inside the kernel and dispense ourselves from all the added DT overhead entirely. But an hybrid mixed solution like FIT is IMHO the worst of both worlds and sending a wrong message. uboot dug _itself_ into this hole. It's uboot's problem. A whole lot of people dug this particular hole. Joel is trying to offer up a solution that maybe makes things easier for everyone. Or it gets rejected here too and distros will come up with their N different ways to try and provide easier experiences to the end user. Nothing being perfect, it is probably unreasonable to think that every board will start shipping with complete and correct DT description, etc. But so is the state of FIT support right now. That solution to make things easier for everyone should actually make that DT vs kernel separation more effective and provide better mechanisms for gluing the various DTBs to their respective boards, and not to glue them to the kernel to populate a distro filesystem with them. Nicolas -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [U-Boot] [RFC] Kbuild support for ARM FIT images
On Thu, 21 Feb 2013, Tom Rini wrote: On 02/21/2013 12:25 PM, Nicolas Pitre wrote: On Thu, 21 Feb 2013, Tom Rini wrote: [snip] uboot dug _itself_ into this hole. It's uboot's problem. A whole lot of people dug this particular hole. Joel is trying to offer up a solution that maybe makes things easier for everyone. Or it gets rejected here too and distros will come up with their N different ways to try and provide easier experiences to the end user. Nothing being perfect, it is probably unreasonable to think that every board will start shipping with complete and correct DT description, etc. But so is the state of FIT support right now. That solution to make things easier for everyone should actually make that DT vs kernel separation more effective and provide better mechanisms for gluing the various DTBs to their respective boards, and not to glue them to the kernel to populate a distro filesystem with them. I very much agree here. And in the end, what I really really want to avoid is every distribution (or similar grouping of stuff) coming up with N different ways to solve the problem of how do I get the user the right device tree to go with $whatever board they happen to be running. DT installation must be outside of the distribution's responsibilities. It should be the OEM's responsibility, just like BIOS updates for PCs which don't come from Fedora/Debian/Ubuntu. Obviously, having the dts files in the kernel tree does confuse people in that regard, but that must not deter people from doing the right thing. If the clever solution everyone comes up with is some other container that's not FIT, that's fine, patches welcome and happily reviewed for whatever the solution is. I just don't want people thinking this is a problem that hasn't been thought of before. Ideally, there should be no such containers. You should simply pick any kernel, or install your distro of choice, and run that on any DT ready hardware. A distro could list the minimum version of a DTB some particular boards were tested with, just like they sometimes do for some PC BIOSes. That said, maybe some provision for DTB versioning would be a good idea if not done already. Nicolas -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [U-Boot] [RFC] Kbuild support for ARM FIT images
On Thu, 21 Feb 2013, Jason Gunthorpe wrote: On Thu, Feb 21, 2013 at 12:25:21PM -0500, Nicolas Pitre wrote: So let's stop kidding ourselves and be coherent please: either we move device specifics away from the kernel, or we keep them together. In other words, the DT should ideally come preinstalled with the bootloader on a given board/device for distros to not even have to care about it, or we put that data back inside the kernel and dispense ourselves from all the added DT overhead entirely. But an hybrid mixed solution like FIT is IMHO the worst of both worlds and sending a wrong message. Just to thread jack a bit here.. We've been using DT on production embedded stuff sice about 2.6.20ish on PPC and now ARM. We treat the dtb as a kernel version specific file, much like an initrd and ensure that the kernel only ever boots with its proper dtb. This is based on experience that the dtbs change depending on the state of the drivers in the kernel, what gets mainlined and when, etc. For embedded appliance product you may do as you wish. Nobody will interfere in the way you develop and support your own products (as long as you honor the applicable licenses of course). But here we're discussing ARM Linux distributions having to deal with different hardware devices. It simply doesn't make sense to bundle every hardware specific data with the kernel in that context. Embedding this stuff into the bootloader is *not* desirable for my embedded scenarios. We don't use FIT (or uboot) but we do the same thing: a single image is constructed with the proper dtb, kernel and initrd, and that is what the bootloader boots. No one is advocating to embed the DT stuff in the bootloader. The DTB may be buggy and/or incomplete and being able to update it safely i.e. independently from the bootloader is necessary. Why? This is an embedded appliance product. We need to be able to deliver firmware upgrades that *work*. We can't brick the board because the bootloader and kernel get out of sync. The boot loader has to be *simple*, it has to boot every past, present and future kernel or we start taking risks that a firmware flash will end up bricking it. People making dev boards and distros for them certainly have different requirements, but we've decided that the single image approach is the best for appliance style products. Absolutely. And in your case, DT is not bringing any benefit over the previous situation where everything was compiled into the kernel. I suspect you're not using the multi-platform support either which is one of the major endeavor on ARM right now. Nicolas -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [U-Boot] [RFC] Kbuild support for ARM FIT images
On Thu, 21 Feb 2013, Stephen Warren wrote:
On 02/21/2013 12:21 PM, Nicolas Pitre wrote:
DT installation must be outside of the distribution's responsibilities.
It should be the OEM's responsibility, just like BIOS updates for PCs
which don't come from Fedora/Debian/Ubuntu. Obviously, having the dts
files in the kernel tree does confuse people in that regard, but that
must not deter people from doing the right thing.
The guidance that has been given in the past is that the kernel zImage
and DTB /must/ be stored in the same location, whether that means the
/boot filesystem, flash partitions, or whatever, so that if required,
the kernel and DTB can be updated at the same time, and using the same
process, so it's guaranteed to be easy enough to update the DTB if you
already know how to update the kernel.
Where were such guidance given?
I don't think this is wise anyway. The DT content for a given piece of
hardware should stabilize quickly, while the kernel can be updated for
years. So there is no need for making the DTB update into the same
process as the kernel.
And as I stated earlier, the distros will care about kernel updates, but
they shouldn't have to care about DTB updates.
The only reason why we do have to update DTBs frequently is because the
whole thing is still being developed and established. But frequent DTB
updates are not the end goal, and therefore we shouldn't design
installation and update mechanisms around the current state of affairs
which is not meant to persist.
Has that guidance changed?
Consider this as my plea to have it changed.
Also, how can the OEM provide a DTB? The distro is responsible for
installing all the filesystem content.
And that's probably not a good idea either.
There's no defined way of passing
a DTB from some pre-bootloader firmware into the bootloader and through
to the kernel;
That doesn't have to stay that way, does it? Maybe those efforts put on
things like FIT or the like could be applied to this problem instead?
Yet that depends how you define a pre-bootloader and a bootloader.
Some people call UEFI the bootloader and grub or u-boot running on top
as the second stage bootloader. I've heard people talking about
making u-boot into a _user_ of the DTB in addition to the kernel, which
would make some sense. In that case, the second stage bootloader could
be somewhat generic as well. But if that layer is generic, then there
must be some kind of standard adaptation layer or API provided by the
first stage bootloader to the second stage bootloader. Passing on
some hardware configuration payload would be part of that API.
Sidenote: there is noise about using ACPI instead of DT on ARM servers
for example, so that's another reason why distributions should not
engage into this responsibility too much.
And obviously the DTB has to be tied to the machine specific boot layer.
And the method to retrieve it would, obviously, be machine specific at
that point. This doesn't have to come frfom the filesystem used by the
final operating system.
the only way to get a DTB to the kernel right now is for
the bootloader to load it itself (either as part of a single file, or as
a separate file) and pass it to the kernel. So, there's really no way
for an OEM to provide a DTB in a BIOS-like fashion.
That will have to change.
Why shouldn't the OEM just provide their *.dts files, and people can
either compile them and put them into /boot, or distros can package them
and the package will install them into /boot. That's extremely simple
and while each distro will have to create their own packaging script,
that's something they already know how to do, and a package that just
dumps a file onto a disk is extremely simple, so people wouldn't have to
go inventing distro-specific solutions.
Because that shouldn't be the distro's business. Because the distros
shouldn't have to be aware of all possible DTBs around and gather them
on their install media and figure out during installation which one to
use, or configure the bootloader so it knows which one to pass back to
the kernel, when the OEMs may as well just ship the right one with their
hardware without the distro to care at all. Because a distro should be
installable on some future hardware that didn't exist when that distro
was put together. Because, ideally, you should be able to pop out the
disk (or SD card) from device X and put it into device Y and just boot
without changing anything.
The device tree data is describing hardware, it should be tied to the
hardware, not to the distribution. Hardware doesn't change, kernels and
distros do.
If U-Boot always searched a disk for e.g. /boot/boot.scr or similar and
just executed that, and there was a standard boot.scr that worked on all
boards by use of e.g. bootz, ${soc}, ${board}, then that could be
distro-agnostic too. And life would be simple, without the need for any
extra build
Re: [U-Boot] [RFC] Kbuild support for ARM FIT images
On Thu, 21 Feb 2013, Jason Gunthorpe wrote: On Thu, Feb 21, 2013 at 02:57:46PM -0500, Nicolas Pitre wrote: For embedded appliance product you may do as you wish. Nobody will interfere in the way you develop and support your own products (as long as you honor the applicable licenses of course). I was specifically responding to your statement that 'a hybrid mixed solution like FIT is IMHO the worst of both worlds and sending a wrong message.' We have been making good use of such an arrangement, and it is defintely not 'the wrong message' for certain applications. In fact, as I said, it is probably the *right* message for embedded users. No it is not. FIT is about bundling a multi-platform kernel with a bunch of DTBs together in a single file. I don't think you need that for your embedded system. The wrong message here is to distribute multiple DTBs around, whether it is with FIT or on a distro install media. Even if I was a distro user, the idea that my dt and kernel would be decoupled is very scary. That was still the design goal for DT. Realize that today, my Kirkwood systems require a different DT for at least 3.7 and 3.8 kernels, and quite possibly different again for 3.9!! Understandable, given that Kirkwood is being ported to DT right now. But if DT had been used from the start when we introduced Kirkwood support to Linux back in 2008 you most likely wouldn't have to change the DTB on your board at all today. This will eventually settle on kirkwood, but I bet the same pattern will repeat on the next new SOC. Possible, although new SOCs do start with DT from the start which is much easier than trying to retrofit it to existing code without breaking things. And given that patterns emerge, there is no need to redesign new bindings for every new SOC. I would have thought keeping the device tree data and kernel together is preferred for most cases as it is more inline with Documentation/stable_api_nonsense.txt. Making the DT a strong stable API boundary sounds really hard to me, and if the churn on ARM so far is indication, it may not be realistic.. The DT is meant to describe hardware. As far as I know, the hardware I own seems to be rather static and stable, and unlike software there is no way I can change it (soldering irons don't count). Distros already ship huge kernels with modules for every hardware out there. Shipping all the DTs as well doesn't seem like a problem. But it is! Even shipping multiple kernels _is_ a problem for them. Hence this multi-platform kernel effort. Otherwise why would we bother? According to your logic, distros could package and distribute BIOS updates for all the X86 systems out there. After all, if they did, they would guarantee even better support on the hardware they target and not have to carry those ACPI quirks in the kernel, no? Ask them if they find this idea rejoicing. You might be surprised. I am thinking something like /lib/device-tree/`uname -r`/... Where (taking a PC analog) the bootloader is told to grab: /boot/vmlinuz-3.9 /boot/initrd.img-3.9 /lib/device-tree/3.9/ti/omap/foo-bar-board And what is the advantage over not having to carry all those files at all on your filesystem? The kernel build can be nice and uniform, while the distro can provide scripts/tools to bundle the kernel zimage, kernel modules, initramfs stuff and dtb into something bootable - be it FIT, uimage, bootz script, grub script or whatever. Or they may simply not bother if the bootloader that comes with the hardware already does the right thing which is even better. Embedding this stuff into the bootloader is *not* desirable for my embedded scenarios. We don't use FIT (or uboot) but we do the same thing: a single image is constructed with the proper dtb, kernel and initrd, and that is what the bootloader boots. No one is advocating to embed the DT stuff in the bootloader. The DTB may be buggy and/or incomplete and being able to update it safely i.e. independently from the bootloader is necessary. Sorry, what did you mean by: 'the DT should ideally come preinstalled with the bootloader on a given board/device' ? When you acquire some hardware, it should come with a DTB and bootloader pre-installed, ready to boot any distribution (as long as its kernel supports the SoC of course). Your hardware vendor should offer DTB updates on its website. The DTB should not be compiled into the bootloader so DTB updates can be done independently from risky bootloader updates. Nicolas -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/NOT FOR MERGING 2/3] serial: omap: remove hwmod dependency
On Fri, 15 Feb 2013, Tony Lindgren wrote: * Santosh Shilimkar santosh.shilim...@ti.com [130215 05:34]: On Friday 15 February 2013 06:57 PM, Russell King - ARM Linux wrote: On Fri, Feb 15, 2013 at 06:56:47PM +0530, Santosh Shilimkar wrote: Whats your view on use of arch_ioremap_caller() hook ? This can allow us to avoid the dual ioremap() issue discussed here if the hook maintains the list of mapped ios. I was even thinking of having such intelligence within the core ioremap code but thought that might be too invasive. Why do you even need it? There's no problem with ioremapping the same space multiple times (you end up with multiple mappings but that shouldn't be a problem, except for the additional space used.) It just waste of iospace and Tony insisted to have just single ioremap() hence all this discussion The main goal is to avoid duplicating data both in hwmod and DT. That's pretty much solved as we can have the driver probe populate the common data for hwmod from DT as Santosh has already demonstrated. Then we also want the driver specific idle and reset code to be done in the drivers rather than in hwmod and glue it together with hwmod using runtime PM. The biggest issue there is how do we reset and idle some piece of hardware for PM purposes when there's no driver loaded. For the duplicate ioremapping, I don't think there's any need to do it if we get things right. Note that if the ioremap matches a static map area there is no cost to ioremap it multiple times. Nicolas -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH, RFC] default machine descriptor for multiplatform
On Thu, 31 Jan 2013, Arnd Bergmann wrote:
This is what I think it would look like to do a default platform
with an empty machine descriptor on ARM. It makes the few required
entries in the descriptor optional by using the new irqchip_init()
and clocksource_of_init() functions as defaults, and adds
a fallback for the DT case to customize_machine to probe all
the default devices.
For the case that CONFIG_MULTIPLATFORM is enabled, it then
adds a machine descriptor that never matches any machine but
is used as a fallback if nothing else matches.
Signed-off-by: Arnd Bergmann a...@arndb.de
Looks sensible.
Acked-by: Nicolas Pitre n...@linaro.org
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 3e3444e..8ff1d38 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -979,7 +979,6 @@ config ARCH_MULTI_V7
bool ARMv7 based platforms (Cortex-A, PJ4, Krait)
default y
select ARCH_MULTI_V6_V7
- select ARCH_VEXPRESS
select CPU_V7
config ARCH_MULTI_V6_V7
diff --git a/arch/arm/kernel/devtree.c b/arch/arm/kernel/devtree.c
index 70f1bde..e6e34ba 100644
--- a/arch/arm/kernel/devtree.c
+++ b/arch/arm/kernel/devtree.c
@@ -180,6 +180,13 @@ struct machine_desc * __init setup_machine_fdt(unsigned
int dt_phys)
unsigned long dt_root;
const char *model;
+ if (IS_ENABLED(CONFIG_ARCH_MULTIPLATFORM)) {
+ DT_MACHINE_START(GENERIC_DT, Generic DT based system)
+ MACHINE_END
+
+ mdesc_best = (struct machine_desc *)__mach_desc_GENERIC_DT;
+ }
+
if (!dt_phys)
return NULL;
@@ -199,7 +206,7 @@ struct machine_desc * __init setup_machine_fdt(unsigned
int dt_phys)
mdesc_score = score;
}
}
- if (!mdesc_best) {
+ if (!mdesc_best !IS_ENABLED(CONFIG_ARCH_MULTIPLATFORM)) {
const char *prop;
long size;
diff --git a/arch/arm/kernel/irq.c b/arch/arm/kernel/irq.c
index 8e4ef4c..df6f9a1 100644
--- a/arch/arm/kernel/irq.c
+++ b/arch/arm/kernel/irq.c
@@ -26,6 +26,7 @@
#include linux/ioport.h
#include linux/interrupt.h
#include linux/irq.h
+#include linux/irqchip.h
#include linux/random.h
#include linux/smp.h
#include linux/init.h
@@ -114,7 +115,10 @@ EXPORT_SYMBOL_GPL(set_irq_flags);
void __init init_IRQ(void)
{
- machine_desc-init_irq();
+ if (machine_desc-init_irq)
+ machine_desc-init_irq();
+ else
+ irqchip_init();
}
#ifdef CONFIG_MULTI_IRQ_HANDLER
diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index 3f6cbb2..1d40c9d 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -18,6 +18,7 @@
#include linux/bootmem.h
#include linux/seq_file.h
#include linux/screen_info.h
+#include linux/of_platform.h
#include linux/init.h
#include linux/kexec.h
#include linux/of_fdt.h
@@ -640,9 +641,17 @@ struct screen_info screen_info = {
static int __init customize_machine(void)
{
- /* customizes platform devices, or adds new ones */
+ /*
+ * customizes platform devices, or adds new ones
+ * On DT based machines, we fall back to populating the
+ * machine from the device tree, if no callback is provided,
+ * otherwise we would always need an init_machine callback.
+ */
if (machine_desc-init_machine)
machine_desc-init_machine();
+ else
+ of_platform_populate(NULL, of_default_bus_match_table,
+ NULL, NULL);
return 0;
}
arch_initcall(customize_machine);
@@ -732,7 +741,7 @@ void __init setup_arch(char **cmdline_p)
setup_processor();
mdesc = setup_machine_fdt(__atags_pointer);
- if (!mdesc)
+ if (!mdesc __machine_arch_type != ~0)
mdesc = setup_machine_tags(__atags_pointer,
__machine_arch_type);
machine_desc = mdesc;
machine_name = mdesc-name;
diff --git a/arch/arm/kernel/time.c b/arch/arm/kernel/time.c
index 955d92d..abff4e9 100644
--- a/arch/arm/kernel/time.c
+++ b/arch/arm/kernel/time.c
@@ -22,6 +22,7 @@
#include linux/errno.h
#include linux/profile.h
#include linux/timer.h
+#include linux/clocksource.h
#include linux/irq.h
#include asm/thread_info.h
@@ -115,6 +116,10 @@ int __init register_persistent_clock(clock_access_fn
read_boot,
void __init time_init(void)
{
- machine_desc-init_time();
+ if (machine_desc-init_time)
+ machine_desc-init_time();
+ else
+ clocksource_of_init();
+
sched_clock_postinit();
}
diff --git a/drivers/irqchip/irqchip.c b/drivers/irqchip/irqchip.c
index f496afc..c5e7a45 100644
--- a/drivers/irqchip/irqchip.c
+++ b/drivers/irqchip/irqchip.c
@@ -24,7 +24,13 @@ irqchip_of_match_end __used __section(__irqchip_of_end);
extern struct of_device_id __irqchip_begin[];
+#ifdef CONFIG_IRQCHIP
void __init
Re: [RFC PATCH v3 1/2] ARM: kernel: update cpuinfo to print SoC model name
On Wed, 30 Jan 2013, Ruslan Bilovol wrote: Currently, reading /proc/cpuinfo provides userspace with CPU ID of the CPU carrying out the read from the file. Userspace using this information may decide what module to load or how to configure some specific (and processor-depended) settings or so. However, since really different SoCs can share same ARM core, this information currently is not so useful. For example, TI OMAP4460 and OMAP4470 SoCs show the same information in the /proc/cpuinfo whereas they are different. Since in most cases ARM CPU is a part of some system on a chip (SoC), the cpuinfo file looks like exactly that place, where this information have to be displayed. So added new line SoC name in the cpuinfo output for system on a chip name. It is placed between CPU information and machine information, so the file structure looks gracefully (CPU-SoC-Hardware) Example: / # cat proc/cpuinfo [...] CPU variant : 0x2 CPU part: 0xc09 CPU revision: 10 SoC name: OMAP4470 Hardware: OMAP4 Blaze Tablet Please remove that extra blank line between SoC name and Hardware. The blank line after CPU revision is fine. Also, please rename this to System name. Not all systems are on chip. By using System name this is more universally useful. Nicolas -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH v3 1/2] ARM: kernel: update cpuinfo to print SoC model name
On Wed, 30 Jan 2013, Matt Sealey wrote: On Wed, Jan 30, 2013 at 1:07 PM, Nicolas Pitre n...@fluxnic.net wrote: On Wed, 30 Jan 2013, Ruslan Bilovol wrote: Currently, reading /proc/cpuinfo provides userspace with CPU ID of the CPU carrying out the read from the file. Userspace using this information may decide what module to load or how to configure some specific (and processor-depended) settings or so. However, since really different SoCs can share same ARM core, this information currently is not so useful. For example, TI OMAP4460 and OMAP4470 SoCs show the same information in the /proc/cpuinfo whereas they are different. Since in most cases ARM CPU is a part of some system on a chip (SoC), the cpuinfo file looks like exactly that place, where this information have to be displayed. So added new line SoC name in the cpuinfo output for system on a chip name. It is placed between CPU information and machine information, so the file structure looks gracefully (CPU-SoC-Hardware) Example: / # cat proc/cpuinfo [...] CPU variant : 0x2 CPU part: 0xc09 CPU revision: 10 SoC name: OMAP4470 Hardware: OMAP4 Blaze Tablet Please remove that extra blank line between SoC name and Hardware. The blank line after CPU revision is fine. Also, please rename this to System name. Not all systems are on chip. By using System name this is more universally useful. I can't agree with System name, it is confusing in common terminology since it's about the same definition as the current Hardware line. If we're just printing out the name of the device surrounding the CPU - be it a Northbridge/Southbridge combination or SoC packaging - Chipset might be a better name for it. That suits me as well. Nicolas -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH v3 1/2] ARM: kernel: update cpuinfo to print SoC model name
On Wed, 30 Jan 2013, Russell King - ARM Linux wrote: On Wed, Jan 30, 2013 at 02:07:53PM -0500, Nicolas Pitre wrote: On Wed, 30 Jan 2013, Ruslan Bilovol wrote: Currently, reading /proc/cpuinfo provides userspace with CPU ID of the CPU carrying out the read from the file. Userspace using this information may decide what module to load or how to configure some specific (and processor-depended) settings or so. However, since really different SoCs can share same ARM core, this information currently is not so useful. For example, TI OMAP4460 and OMAP4470 SoCs show the same information in the /proc/cpuinfo whereas they are different. Since in most cases ARM CPU is a part of some system on a chip (SoC), the cpuinfo file looks like exactly that place, where this information have to be displayed. So added new line SoC name in the cpuinfo output for system on a chip name. It is placed between CPU information and machine information, so the file structure looks gracefully (CPU-SoC-Hardware) Example: / # cat proc/cpuinfo [...] CPU variant : 0x2 CPU part: 0xc09 CPU revision: 10 SoC name: OMAP4470 Hardware: OMAP4 Blaze Tablet Please remove that extra blank line between SoC name and Hardware. The blank line after CPU revision is fine. Also, please rename this to System name. Not all systems are on chip. By using System name this is more universally useful. You may notice I've already suggested that this should be using the SoC infrastructure to export this information, which was explicitly designed to do this. Absolutely. If a mechanism is already in place then it should be used. Nicolas -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Failure to boot...
On Wed, 30 Jan 2013, Olof Johansson wrote: My Panda ES works with omap2plus_defconfig, but I just noticed that the in-kernel uImage target will use a bad load/entry address so loading and booting that uImage will hang u-boot: Image Name: Linux-3.8.0-rc5-00389-g120d4a8 Created: Wed Jan 30 18:30:39 2013 Image Type: ARM Linux Kernel Image (uncompressed) Data Size:3843912 Bytes = 3753.82 kB = 3.67 MB Load Address: fff2 Entry Point: fff2 Looking at the latest build and boot log for SDP (oldconfig) on your build status site verifies that you hit that case too. :( Wrapping by hand (which my scripts already do) produces a bootable image; just verified both with and without device-tree on my panda. git bisect points at a069486162a59513053cf772515217ca61727704 (ARM: OMAP2+: Enable ARCH_MULTIPLATFORM support) Hmm. This happens because nothing sources arch/arm/mach-*/Makefile.boot for CONFIG_ARCH_MULTIPLATFORM builds, even if only a single platform is enabled, since $MACHINE is empty. The uImage format is incompatible with multi-platform builds, period. The uImage wrapping should be done at kernel _installation_ time, not at _build_ time. That is, people shoud get into the habit of distributing a zImage binary, and the installation procedure on a particular platform should take care of running mkimage on it. Better yet (IMHO): just enable the zboot command in U-Boot to let you boot a zImage binary directly. It seems like most of the available options to deal with this are bad. One thing we should never do though, is to pretend to make a working uImage when we're not. Maybe abort building just like in the case of multiple load addresses? Absolutely. diff --git a/arch/arm/boot/Makefile b/arch/arm/boot/Makefile index abfce28..71768b8 100644 --- a/arch/arm/boot/Makefile +++ b/arch/arm/boot/Makefile @@ -68,8 +68,8 @@ else endif check_for_multiple_loadaddr = \ -if [ $(words $(UIMAGE_LOADADDR)) -gt 1 ]; then \ - echo 'multiple load addresses: $(UIMAGE_LOADADDR)'; \ +if [ $(words $(UIMAGE_LOADADDR)) -ne 1 ]; then \ + echo 'multiple (or no) load addresses: $(UIMAGE_LOADADDR)'; \ echo 'This is incompatible with uImages'; \ echo 'Specify LOADADDR on the commandline to build an uImage'; \ false; \ Acked-by: Nicolas Pitre n...@linaro.org Nicolas -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: add get_user() support for 8 byte types
On Thu, 15 Nov 2012, Rob Clark wrote:
From: Rob Clark r...@ti.com
A new atomic modeset/pageflip ioctl being developed in DRM requires
get_user() to work for 64bit types (in addition to just put_user()).
v1: original
v2: pass correct size to check_uaccess, and better handling of narrowing
double word read with __get_user_xb() (Russell King's suggestion)
v3: explain in comment about why this works for narrowing fetch to 1,
2, or 4 byte type on ARM.
Signed-off-by: Rob Clark r...@ti.com
Acked-by: Nicolas Pitre n...@linaro.org
---
arch/arm/include/asm/uaccess.h | 22 +-
arch/arm/lib/getuser.S | 17 -
2 files changed, 37 insertions(+), 2 deletions(-)
diff --git a/arch/arm/include/asm/uaccess.h b/arch/arm/include/asm/uaccess.h
index 7e1f760..4cfa793 100644
--- a/arch/arm/include/asm/uaccess.h
+++ b/arch/arm/include/asm/uaccess.h
@@ -100,6 +100,7 @@ static inline void set_fs(mm_segment_t fs)
extern int __get_user_1(void *);
extern int __get_user_2(void *);
extern int __get_user_4(void *);
+extern int __get_user_8(void *);
#define __GUP_CLOBBER_1 lr, cc
#ifdef CONFIG_CPU_USE_DOMAINS
@@ -108,6 +109,7 @@ extern int __get_user_4(void *);
#define __GUP_CLOBBER_2 lr, cc
#endif
#define __GUP_CLOBBER_4 lr, cc
+#define __GUP_CLOBBER_8 lr, cc
#define __get_user_x(__r2,__p,__e,__l,__s) \
__asm__ __volatile__ ( \
@@ -118,11 +120,23 @@ extern int __get_user_4(void *);
: 0 (__p), r (__l) \
: __GUP_CLOBBER_##__s)
+/*
+ * Narrowing a double-word get into a single 32bit word register, which works
+ * for 1, 2, or 4 byte types on ARM because there are no integer registers
+ * smaller than 32bit
+ */
+#ifdef BIG_ENDIAN
+#define __get_user_xb(__r2,__p,__e,__l,__s) \
+ __get_user_x(__r2,(uintptr_t)__p + 4,__e,__l,__s)
+#else
+#define __get_user_xb __get_user_x
+#endif
+
#define __get_user_check(x,p)
\
({ \
unsigned long __limit = current_thread_info()-addr_limit - 1; \
register const typeof(*(p)) __user *__p asm(r0) = (p);\
- register unsigned long __r2 asm(r2); \
+ register typeof(x) __r2 asm(r2); \
register unsigned long __l asm(r1) = __limit; \
register int __e asm(r0); \
switch (sizeof(*(__p))) { \
@@ -135,6 +149,12 @@ extern int __get_user_4(void *);
case 4: \
__get_user_x(__r2, __p, __e, __l, 4); \
break; \
+ case 8: \
+ if (sizeof((x)) 8)\
+ __get_user_xb(__r2, __p, __e, __l, 4); \
+ else\
+ __get_user_x(__r2, __p, __e, __l, 8); \
+ break; \
default: __e = __get_user_bad(); break; \
} \
x = (typeof(*(p))) __r2;\
diff --git a/arch/arm/lib/getuser.S b/arch/arm/lib/getuser.S
index 9b06bb4..ed98707 100644
--- a/arch/arm/lib/getuser.S
+++ b/arch/arm/lib/getuser.S
@@ -18,7 +18,7 @@
* Inputs: r0 contains the address
* r1 contains the address limit, which must be preserved
* Outputs: r0 is the error code
- * r2 contains the zero-extended value
+ * r2, r3 contains the zero-extended value
* lr corrupted
*
* No other registers must be altered. (see asm/uaccess.h
@@ -66,6 +66,19 @@ ENTRY(__get_user_4)
mov pc, lr
ENDPROC(__get_user_4)
+ENTRY(__get_user_8)
+ check_uaccess r0, 8, r1, r2, __get_user_bad
+#ifdef CONFIG_THUMB2_KERNEL
+5: TUSER(ldr)r2, [r0]
+6: TUSER(ldr)r3, [r0, #4]
+#else
+5: TUSER(ldr)r2, [r0], #4
+6: TUSER(ldr)r3, [r0]
+#endif
+ mov r0, #0
+ mov pc, lr
+ENDPROC(__get_user_8)
+
__get_user_bad:
mov r2, #0
mov r0, #-EFAULT
@@ -77,4 +90,6 @@ ENDPROC(__get_user_bad)
.long 2b, __get_user_bad
.long 3b, __get_user_bad
.long 4b, __get_user_bad
+ .long 5b, __get_user_bad
+ .long 6b, __get_user_bad
.popsection
--
1.8.0
--
To unsubscribe from this list: send the line unsubscribe linux-kernel
Re: [PATCH v2 2/7] ARM: virt: allow the kernel to be entered in HYP mode
On Sat, 6 Oct 2012, Marc Zyngier wrote: Hi Tony, On Fri, 5 Oct 2012 13:08:22 -0700, Tony Lindgren t...@atomide.com wrote: Hi, * Marc Zyngier marc.zyng...@arm.com [120907 10:04]: From: Dave Martin dave.mar...@linaro.org This patch does two things: * Ensure that asynchronous aborts are masked at kernel entry. The bootloader should be masking these anyway, but this reduces the damage window just in case it doesn't. * Enter svc mode via exception return to ensure that CPU state is properly serialised. This does not matter when switching from an ordinary privileged mode (PL1 modes in ARMv7-AR rev C parlance), but it potentially does matter when switching from a another privileged mode such as hyp mode. This should allow the kernel to boot safely either from svc mode or hyp mode, even if no support for use of the ARM Virtualization Extensions is built into the kernel. Signed-off-by: Dave Martin dave.mar...@linaro.org Signed-off-by: Marc Zyngier marc.zyng...@arm.com Just bisected this down in linux-next for breaking booting of my omap2420 ARMv6 based n8x0.. --- a/arch/arm/kernel/head.S +++ b/arch/arm/kernel/head.S @@ -83,8 +83,12 @@ ENTRY(stext) THUMB( .thumb ) @ switch to Thumb now. THUMB(1: ) - setmode PSR_F_BIT | PSR_I_BIT | SVC_MODE, r9 @ ensure svc mode - @ and irqs disabled +#ifdef CONFIG_ARM_VIRT_EXT + bl __hyp_stub_install +#endif + @ ensure svc mode and all interrupts masked + safe_svcmode_maskall r9 + mrc p15, 0, r9, c0, c0 @ get processor id bl __lookup_processor_type @ r5=procinfo r9=cpuid movsr10, r5 @ invalid processor (r5=0)? ..and looks like undoing this part fixes it. Any ideas? I quickly tried disabling ARCH_OMAP3 and ARCH_OMAP4 so it's ARMv6 but that does not help. If you compiled for v6 only, we can safely exclude __hyp_stub_install, and I assume that you get past the decompressor. If so, that indicates some side effect of the safe_svcmode_maskall macro, and I suspect the movs pc, lr bit. That would be surprizing if the movs pc, lr was to blame. This should work on all architectures. However the A bit might be to blame. Can you try the attached patch? It basically falls back to the previous behaviour if not entered in HYP mode. This is likely to work of course. However I think we should try to pinpoint the exact problem i.e. whether it is the A bit or the movs pc, lr which makes a difference (it is unlikely to be both). So I was about to suggest to test this patch as well: diff --git a/arch/arm/include/asm/assembler.h b/arch/arm/include/asm/assembler.h index 683a1e6b60..118e22ee46 100644 --- a/arch/arm/include/asm/assembler.h +++ b/arch/arm/include/asm/assembler.h @@ -254,8 +254,7 @@ mov lr , \reg and lr , lr , #MODE_MASK cmp lr , #HYP_MODE - orr \reg , \reg , #PSR_A_BIT | PSR_I_BIT | PSR_F_BIT - bic \reg , \reg , #MODE_MASK + mov \reg , #PSR_I_BIT | PSR_F_BIT orr \reg , \reg , #SVC_MODE THUMB( orr \reg , \reg , #PSR_T_BIT) msr spsr_cxsf, \reg Nicolas -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/7] ARM: virt: allow the kernel to be entered in HYP mode
On Sat, 6 Oct 2012, Tony Lindgren wrote: * Marc Zyngier marc.zyng...@arm.com [121006 03:19]: If so, that indicates some side effect of the safe_svcmode_maskall macro, and I suspect the movs pc, lr bit. Can you try the attached patch? It basically falls back to the previous behaviour if not entered in HYP mode. Yes, with this it boots OK. OK. In that case, I suggest this patch be sent to Russell to fix this issue so he could push the ARM stuff to Linus ASAP. Acked-by: Nicolas Pitre n...@linaro.org Nicolas -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/7] ARM: virt: allow the kernel to be entered in HYP mode
On Fri, 5 Oct 2012, Tony Lindgren wrote: * Tony Lindgren t...@atomide.com [121005 16:27]: * Russell King - ARM Linux li...@arm.linux.org.uk [121005 16:10]: On Fri, Oct 05, 2012 at 01:08:22PM -0700, Tony Lindgren wrote: Just bisected this down in linux-next for breaking booting of my omap2420 ARMv6 based n8x0.. --- a/arch/arm/kernel/head.S +++ b/arch/arm/kernel/head.S @@ -83,8 +83,12 @@ ENTRY(stext) THUMB( .thumb ) @ switch to Thumb now. THUMB(1:) - setmode PSR_F_BIT | PSR_I_BIT | SVC_MODE, r9 @ ensure svc mode - @ and irqs disabled +#ifdef CONFIG_ARM_VIRT_EXT + bl __hyp_stub_install +#endif + @ ensure svc mode and all interrupts masked + safe_svcmode_maskall r9 + mrc p15, 0, r9, c0, c0 @ get processor id bl __lookup_processor_type @ r5=procinfo r9=cpuid movsr10, r5 @ invalid processor (r5=0)? ..and looks like undoing this part fixes it. Any ideas? I quickly tried disabling ARCH_OMAP3 and ARCH_OMAP4 so it's ARMv6 but that does not help. The same kernel boots on 2430sdp, which is the same ARMv6 core as 2430 if I remember correctly. So this hints that it has something to do with the bits set differently by the bootloader? Possibly. What if you apply this on top: diff --git a/arch/arm/include/asm/assembler.h b/arch/arm/include/asm/assembler.h index 683a1e6b60..b276c26e19 100644 --- a/arch/arm/include/asm/assembler.h +++ b/arch/arm/include/asm/assembler.h @@ -254,8 +254,7 @@ mov lr , \reg and lr , lr , #MODE_MASK cmp lr , #HYP_MODE - orr \reg , \reg , #PSR_A_BIT | PSR_I_BIT | PSR_F_BIT - bic \reg , \reg , #MODE_MASK + mov \reg , #PSR_A_BIT | PSR_I_BIT | PSR_F_BIT orr \reg , \reg , #SVC_MODE THUMB( orr \reg , \reg , #PSR_T_BIT) msr spsr_cxsf, \reg Nicolas -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH v2 1/5] ARM: mm: implement LoUIS API for cache maintenance ops
On Tue, 18 Sep 2012, Lorenzo Pieralisi wrote:
ARM v7 architecture introduced the concept of cache levels and related
control registers. New processors like A7 and A15 embed an L2 unified cache
controller that becomes part of the cache level hierarchy. Some operations in
the kernel like cpu_suspend and __cpu_disable do not require a flush of the
entire cache hierarchy to DRAM but just the cache levels belonging to the
Level of Unification Inner Shareable (LoUIS), which in most of ARM v7 systems
correspond to L1.
The current cache flushing API used in cpu_suspend and __cpu_disable,
flush_cache_all(), ends up flushing the whole cache hierarchy since for
v7 it cleans and invalidates all cache levels up to Level of Coherency
(LoC) which cripples system performance when used in hot paths like hotplug
and cpuidle.
Therefore a new kernel cache maintenance API must be added to cope with
latest ARM system requirements.
This patch adds flush_cache_louis() to the ARM kernel cache maintenance API.
This function cleans and invalidates all data cache levels up to the
Level of Unification Inner Shareable (LoUIS) and invalidates the instruction
cache for processors that support it ( v7).
This patch also creates an alias of the cache LoUIS function to flush_kern_all
for all processor versions prior to v7, so that the current cache flushing
behaviour is unchanged for those processors.
v7 cache maintenance code implements a cache LoUIS function that cleans and
invalidates the D-cache up to LoUIS and invalidates the I-cache, according
to the new API.
Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com
Signed-off-by: Lorenzo Pieralisi lorenzo.pieral...@arm.com
Reviewed-by: Nicolas Pitre n...@linaro.org
---
arch/arm/include/asm/cacheflush.h | 15 +++
arch/arm/include/asm/glue-cache.h | 1 +
arch/arm/mm/cache-fa.S| 3 +++
arch/arm/mm/cache-v3.S| 3 +++
arch/arm/mm/cache-v4.S| 3 +++
arch/arm/mm/cache-v4wb.S | 3 +++
arch/arm/mm/cache-v4wt.S | 3 +++
arch/arm/mm/cache-v6.S| 3 +++
arch/arm/mm/cache-v7.S| 36
arch/arm/mm/proc-arm1020.S| 3 +++
arch/arm/mm/proc-arm1020e.S | 3 +++
arch/arm/mm/proc-arm1022.S| 3 +++
arch/arm/mm/proc-arm1026.S| 3 +++
arch/arm/mm/proc-arm920.S | 3 +++
arch/arm/mm/proc-arm922.S | 3 +++
arch/arm/mm/proc-arm925.S | 3 +++
arch/arm/mm/proc-arm926.S | 3 +++
arch/arm/mm/proc-arm940.S | 3 +++
arch/arm/mm/proc-arm946.S | 3 +++
arch/arm/mm/proc-feroceon.S | 3 +++
arch/arm/mm/proc-macros.S | 1 +
arch/arm/mm/proc-mohawk.S | 3 +++
arch/arm/mm/proc-xsc3.S | 3 +++
arch/arm/mm/proc-xscale.S | 3 +++
24 files changed, 113 insertions(+)
diff --git a/arch/arm/include/asm/cacheflush.h
b/arch/arm/include/asm/cacheflush.h
index c6e2ed9..4e8217b 100644
--- a/arch/arm/include/asm/cacheflush.h
+++ b/arch/arm/include/asm/cacheflush.h
@@ -50,6 +50,13 @@
*
* Unconditionally clean and invalidate the entire cache.
*
+ * flush_kern_louis()
+ *
+ * Flush data cache levels up to the level of unification
+ * inner shareable and invalidate the I-cache.
+ * Only needed from v7 onwards, falls back to flush_cache_all()
+ * for all other processor versions.
+ *
* flush_user_all()
*
* Clean and invalidate all user space cache entries
@@ -98,6 +105,7 @@
struct cpu_cache_fns {
void (*flush_icache_all)(void);
void (*flush_kern_all)(void);
+ void (*flush_kern_louis)(void);
void (*flush_user_all)(void);
void (*flush_user_range)(unsigned long, unsigned long, unsigned int);
@@ -120,6 +128,7 @@ extern struct cpu_cache_fns cpu_cache;
#define __cpuc_flush_icache_all cpu_cache.flush_icache_all
#define __cpuc_flush_kern_allcpu_cache.flush_kern_all
+#define __cpuc_flush_kern_louis cpu_cache.flush_kern_louis
#define __cpuc_flush_user_allcpu_cache.flush_user_all
#define __cpuc_flush_user_range cpu_cache.flush_user_range
#define __cpuc_coherent_kern_range cpu_cache.coherent_kern_range
@@ -140,6 +149,7 @@ extern struct cpu_cache_fns cpu_cache;
extern void __cpuc_flush_icache_all(void);
extern void __cpuc_flush_kern_all(void);
+extern void __cpuc_flush_kern_louis(void);
extern void __cpuc_flush_user_all(void);
extern void __cpuc_flush_user_range(unsigned long, unsigned long, unsigned
int);
extern void __cpuc_coherent_kern_range(unsigned long, unsigned long);
@@ -205,6 +215,11 @@ static inline void __flush_icache_all(void)
__flush_icache_preferred();
}
+/*
+ * Flush caches up to Level of Unification Inner Shareable
+ */
+#define flush_cache_louis
Re: [RFC PATCH v2 2/5] ARM: mm: rename jump labels in v7_flush_dcache_all function
On Tue, 18 Sep 2012, Lorenzo Pieralisi wrote: This patch renames jump labels in v7_flush_dcache_all in order to define a specific flush cache levels entry point. TODO: factor out the level flushing loop if considered worthwhile and define the input registers requirements. Signed-off-by: Lorenzo Pieralisi lorenzo.pieral...@arm.com Acked-by: Nicolas Pitre n...@linaro.org --- arch/arm/mm/cache-v7.S | 14 +++--- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/arch/arm/mm/cache-v7.S b/arch/arm/mm/cache-v7.S index d1fa2f6..140b294 100644 --- a/arch/arm/mm/cache-v7.S +++ b/arch/arm/mm/cache-v7.S @@ -48,7 +48,7 @@ ENTRY(v7_flush_dcache_louis) mov r3, r3, lsr #20 @ r3 = LoUIS * 2 moveq pc, lr @ return if level == 0 mov r10, #0 @ r10 (starting level) = 0 - b loop1 @ start flushing cache levels + b flush_levels@ start flushing cache levels ENDPROC(v7_flush_dcache_louis) /* @@ -67,7 +67,7 @@ ENTRY(v7_flush_dcache_all) mov r3, r3, lsr #23 @ left align loc bit field beq finished@ if loc is 0, then no need to clean mov r10, #0 @ start clean at cache level 0 -loop1: +flush_levels: add r2, r10, r10, lsr #1@ work out 3x current cache level mov r1, r0, lsr r2 @ extract cache type bits from clidr and r1, r1, #7 @ mask of the bits for current cache only @@ -89,9 +89,9 @@ loop1: clz r5, r4 @ find bit position of way size increment ldr r7, =0x7fff andsr7, r7, r1, lsr #13 @ extract max number of the index size -loop2: +loop1: mov r9, r4 @ create working copy of max way size -loop3: +loop2: ARM(orr r11, r10, r9, lsl r5) @ factor way and cache number into r11 THUMB( lsl r6, r9, r5 ) THUMB( orr r11, r10, r6) @ factor way and cache number into r11 @@ -100,13 +100,13 @@ loop3: THUMB( orr r11, r11, r6) @ factor index number into r11 mcr p15, 0, r11, c7, c14, 2 @ clean invalidate by set/way subsr9, r9, #1 @ decrement the way - bge loop3 - subsr7, r7, #1 @ decrement the index bge loop2 + subsr7, r7, #1 @ decrement the index + bge loop1 skip: add r10, r10, #2@ increment cache number cmp r3, r10 - bgt loop1 + bgt flush_levels finished: mov r10, #0 @ swith back to cache level 0 mcr p15, 2, r10, c0, c0, 0 @ select current cache level in cssr -- 1.7.12 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH v2 3/5] ARM: kernel: update cpu_suspend code to use cache LoUIS operations
On Tue, 18 Sep 2012, Lorenzo Pieralisi wrote:
In processors like A15/A7 L2 cache is unified and integrated within the
processor cache hierarchy, so that it is not considered an outer cache
anymore. For processors like A15/A7 flush_cache_all() ends up cleaning
all cache levels up to Level of Coherency (LoC) that includes
the L2 unified cache.
When a single CPU is suspended (CPU idle) a complete L2 clean is not
required, so generic cpu_suspend code must clean the data cache using the
newly introduced cache LoUIS function.
The context and stack pointer (context pointer) are cleaned to main memory
using cache area functions that operate on MVA and guarantee that the data
is written back to main memory (perform cache cleaning up to the Point of
Coherency - PoC) so that the processor can fetch the context when the MMU
is off in the cpu_resume code path.
outer_cache management remains unchanged.
Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com
Signed-off-by: Lorenzo Pieralisi lorenzo.pieral...@arm.com
Reviewed-by: Nicolas Pitre n...@linaro.org
---
arch/arm/kernel/suspend.c | 17 -
1 file changed, 16 insertions(+), 1 deletion(-)
diff --git a/arch/arm/kernel/suspend.c b/arch/arm/kernel/suspend.c
index 1794cc3..358bca3 100644
--- a/arch/arm/kernel/suspend.c
+++ b/arch/arm/kernel/suspend.c
@@ -17,6 +17,8 @@ extern void cpu_resume_mmu(void);
*/
void __cpu_suspend_save(u32 *ptr, u32 ptrsz, u32 sp, u32 *save_ptr)
{
+ u32 *ctx = ptr;
+
*save_ptr = virt_to_phys(ptr);
/* This must correspond to the LDM in cpu_resume() assembly */
@@ -26,7 +28,20 @@ void __cpu_suspend_save(u32 *ptr, u32 ptrsz, u32 sp, u32
*save_ptr)
cpu_do_suspend(ptr);
- flush_cache_all();
+ flush_cache_louis();
+
+ /*
+ * flush_cache_louis does not guarantee that
+ * save_ptr and ptr are cleaned to main memory,
+ * just up to the Level of Unification Inner Shareable.
+ * Since the context pointer and context itself
+ * are to be retrieved with the MMU off that
+ * data must be cleaned from all cache levels
+ * to main memory using area cache primitives.
+ */
+ __cpuc_flush_dcache_area(ctx, ptrsz);
+ __cpuc_flush_dcache_area(save_ptr, sizeof(*save_ptr));
+
outer_clean_range(*save_ptr, *save_ptr + ptrsz);
outer_clean_range(virt_to_phys(save_ptr),
virt_to_phys(save_ptr) + sizeof(*save_ptr));
--
1.7.12
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH v2 4/5] ARM: kernel: update __cpu_disable to use cache LoUIS maintenance API
On Tue, 18 Sep 2012, Lorenzo Pieralisi wrote: When a CPU is hotplugged out caches that reside in its power domain lose their contents and so must be cleaned to the next memory level. Currently, __cpu_disable calls flush_cache_all() that for new generation processor like A15/A7 ends up cleaning and invalidating all cache levels up to Level of Coherency, which includes the unified L2. This ends up being a waste of cycles since the L2 cache contents are not lost on power down. This patch updates __cpu_disable to use the new LoUIS API cache operations. Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com Signed-off-by: Lorenzo Pieralisi lorenzo.pieral...@arm.com Acked-by: Nicolas Pitre n...@linaro.org --- arch/arm/kernel/smp.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/arch/arm/kernel/smp.c b/arch/arm/kernel/smp.c index d3eb222..f44e9cd 100644 --- a/arch/arm/kernel/smp.c +++ b/arch/arm/kernel/smp.c @@ -136,8 +136,11 @@ int __cpu_disable(void) /* * Flush user cache and TLB mappings, and then remove this CPU * from the vm mask set of all processes. + * + * Caches are flushed to the Level of Unification Inner Shareable + * to write-back dirty lines to unified caches shared by all CPUs. */ - flush_cache_all(); + flush_cache_louis(); local_flush_tlb_all(); clear_tasks_mm_cpumask(cpu); -- 1.7.12 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH v2 5/5] ARM: mm: update __v7_setup() to the new LoUIS cache maintenance API
On Tue, 18 Sep 2012, Lorenzo Pieralisi wrote:
From: Santosh Shilimkar santosh.shilim...@ti.com
The ARMv7 processor setup function __v7_setup() cleans and invalidates the
CPU cache before enabling MMU to start the CPU with a clean CPU local cache.
But on ARMv7 architectures like Cortex-[A15/A8], this code will end
up flushing the L2 caches(up to level of Coherency) which is undesirable
and expensive. The setup functions are used in the CPU hotplug scenario too
and hence flushing all cache levels should be avoided.
This patch replaces the cache flushing call with the newly introduced
v7 dcache LoUIS API where only cache levels up to LoUIS are cleaned and
invalidated when a processors executes __v7_setup which is the expected
behavior.
For processors like A9 and A5 where the L2 cache is an outer one the
behavior should be unchanged.
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
Signed-off-by: Lorenzo Pieralisi lorenzo.pieral...@arm.com
Reviewed-by: Nicolas Pitre n...@linaro.org
---
arch/arm/mm/proc-v7.S | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mm/proc-v7.S b/arch/arm/mm/proc-v7.S
index c2e2b66..846d279 100644
--- a/arch/arm/mm/proc-v7.S
+++ b/arch/arm/mm/proc-v7.S
@@ -172,7 +172,7 @@ __v7_ca15mp_setup:
__v7_setup:
adr r12, __v7_setup_stack @ the local stack
stmia r12, {r0-r5, r7, r9, r11, lr}
- bl v7_flush_dcache_all
+ bl v7_flush_dcache_louis
ldmia r12, {r0-r5, r7, r9, r11, lr}
mrc p15, 0, r0, c0, c0, 0 @ read main ID register
--
1.7.12
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Without MACH_ option Early printk (DEBUG_LL)
On Mon, 3 Sep 2012, Mohammed, Afzal wrote: Hi, On Fri, Aug 31, 2012 at 23:53:32, Nicolas Pitre wrote: On Fri, 31 Aug 2012, Hiremath, Vaibhav wrote: On Fri, Aug 31, 2012 at 22:43:36, Russell King - ARM Linux wrote: On Fri, Aug 31, 2012 at 08:24:51PM +0530, Vaibhav Hiremath wrote: AM335X EVM (based on AM33XX device) only supports DT boot mode and doesn't have CONFIG_MACH_AM335XEVM option defined. Some time back during baseport submission we had aligned that, we won't create separate EVM options, killing the board file all-together. Having said that, the early printk option (DEBUG_LL) is broken, the auto-generated file ./include/generated/mach-types.h still refers to CONFIG_MACH_AM335XEVM option, machine types are entirely meaningless for DT based systems. Can you comment on this? Based on that I will submit the patch. Pointless. You can't use machine_is_am335xevm() when you're using DT. They how do you recommend to resolve early prink issue (required during decompression)? Right now the best you can do is to have empty stubs that display nothing. Won't having compile time selection of debug uart over machine based runtime detection help here ? It certainly would. But then your kernel won't run on anything but the specific machine for which the compile time UART selection was made. As soon as you have more than one possible UART config for the set of machines you want your kernel binary to run on, you'll have to give up on the early output during kernel decompression. Nicolas -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Without MACH_ option Early printk (DEBUG_LL)
On Fri, 31 Aug 2012, Hiremath, Vaibhav wrote: On Fri, Aug 31, 2012 at 22:43:36, Russell King - ARM Linux wrote: On Fri, Aug 31, 2012 at 08:24:51PM +0530, Vaibhav Hiremath wrote: Hi Russell Tony, AM335X EVM (based on AM33XX device) only supports DT boot mode and doesn't have CONFIG_MACH_AM335XEVM option defined. Some time back during baseport submission we had aligned that, we won't create separate EVM options, killing the board file all-together. Having said that, the early printk option (DEBUG_LL) is broken, the auto-generated file ./include/generated/mach-types.h still refers to CONFIG_MACH_AM335XEVM option, #ifdef CONFIG_MACH_AM335XEVM # ifdef machine_arch_type # undef machine_arch_type # define machine_arch_type __machine_arch_type # else # define machine_arch_type MACH_TYPE_AM335XEVM # endif # define machine_is_am335xevm() (machine_arch_type == MACH_TYPE_AM335XEVM) #else # define machine_is_am335xevm() (0) #endif machine types are entirely meaningless for DT based systems. Can you comment on this? Based on that I will submit the patch. Pointless. You can't use machine_is_am335xevm() when you're using DT. They how do you recommend to resolve early prink issue (required during decompression)? Right now the best you can do is to have empty stubs that display nothing. Nicolas -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/11] OMAP2+: Add SoC specific map_io functions
On Mon, 14 May 2012, Cousson, Benoit wrote: Salut Thomas, Sorry for the delay. On 5/4/2012 5:59 PM, Thomas Petazzoni wrote: Hello Benoit, Le Fri, 23 Sep 2011 22:23:09 +0200, Benoit Coussonb-cous...@ti.com a écrit : Add SoC specific map_io function to be used by the generic DT board file. This is an intermediate step before having some generic DT aware map_io function. Signed-off-by: Benoit Coussonb-cous...@ti.com Cc: Tony Lindgrent...@atomide.com Do you know if some progress has been made on having a generic DT aware map_io function, or is the per-SoC -map_io() function still the recommended way of handling SoC having different requirements of static mappings at boot time? Mmm, Maybe I'm wrong, but I'm not sure people are really pushing to store that inside DT. But to be honest, I don't really know :-) In general, static vs dynamic IO mappings are just some Linux implementation details. This distinction does not belong in DT. Nicolas
Re: [PATCH v7 1/3] Documentation: common clk API
On Wed, 21 Mar 2012, Paul Walmsley wrote: Hello Nico, On Tue, 20 Mar 2012, Nicolas Pitre wrote: This common clk API has been under development for over *two* years already, with several attempts to merge it. And each previous merge attempt aborted because someone came along at the last minute to do exactly what you are doing i.e. underline all the flaws and call for a redesign. This is becoming a bad joke. There is a misunderstanding. I am not calling for a redesign. I am simply stating that the current maturity level of the API and code should be documented in the Kconfig dependencies or description text before the code goes upstream. The objectives are to make future changes easier, set expectations, and clearly disclose the extent to which the API and code will need to change. Maybe there is no actual consensus on that extent. The code will be easier to change once it is in mainline, simply due to the fact that you can also change all its users at once. And it is well possible that most users won't have to deal with the same magnitude of complexity as yours, again reducing the scope for resistance to changes. I hope you are right. To me, these conclusions seem unlikely. It seems equally likely that these rationales will make it much more difficult to change the code once it's upstream and platforms are depending on it. No code should go upstream if no one depends on it. Therefore we change code that many platforms depend on all the time. What is killing us is the need to synchronize with multiple external code bases scattered around. Particularly given the ongoing sensitivity to reducing churn of mainline code, so publicly discussed. Please stop buying into that crap. We congratulate ourselves every merge cycles with the current process being able to deal with around half a million of lines changed every 3 months or so. It's pointless churn that is frowned upon, not useful and incremental API changes. I don't think that pointless would apply here. So it seems like a good idea to attempt to address these potential roadblocks and criticisms to major clock framework changes early. I understand your concern, however I don't think it is as serious as you are making it. One last comment to address which is orthogonal to the technical content of this discussion. Otherwise one might ask where were you during those development years if you claim that the behavior and/or API of the common clock code still need to change significantly? One might ask this. If one were to ask this, another might briefly outline the participation in public and private clock discussions at Linaro Connect in Budapest and Redwood Shores, at LPC in Santa Rosa, at ELCE/KS in Prague, at ELC in Redwood Shores, in conference calls, IRC sessions, and private E-mails with many of the people included in the header of this message, not to mention the list posts. Sure. I was there too and came across you many times. I just don't understand why some apparent consensus was built around the current submission, that people involved appeared to be highly satisfied at last, given the emphasis you are giving to your present concern which doesn't seem to be widely shared. This is a bit surprising. None of the concerns that have been described are new. There has been an endeavour to discuss them with anyone who seemed even remotely interested. Let's change tactics then. We've been discussing this code for over two years and no one could really benefit from it during that time. Maybe future discussion could become more productive and concrete when some code is merged _and_ used at last. Nicolas -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v8 0/8] Consolidate cpuidle functionality
On Tue, 20 Mar 2012, Kevin Hilman wrote: Looks like you never heard from anyone actively working on at91, shmobile, kirwood or davinci. I'm not sure we should merge those platform-specific changes without an ack from those platform maintainers. Depends. There is a limit to how long you may be willing to wait after people. Sometimes the only way to make progress is to merge the thing and hope that someone who cares will test the stuff during the ~2 months -rc period and provide any fix then. And if that doesn't happen during that time then either the code is just right and no one noticed the change, or no one cares anymore. IMHO, Rob posted those patches many times now for quite a while (many months) already. So I'd suggest simply pushing that stuff into mainline as is. Nicolas -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v8 0/8] Consolidate cpuidle functionality
On Wed, 21 Mar 2012, Amit Kucheria wrote: On Wed, Mar 21, 2012 at 12:48 AM, Kevin Hilman khil...@ti.com wrote: Maybe it's time that drivers/cpuidle gets a maintainer. With lots of discussions of scheduler changes that affect load estimation, I suspect we're all going to have a bit of CPUidle work to do in the not-so-distant future. I don't mean to be piling on to Len here, but Daniel Lezcano too has a bunch of clean ups that didn't get any maintainer review for over two months. He has now refreshed them for 3.3 and is getting ready to send them out again. We (Linaro) expect to be spending a lot of time on cpuidle in the future and would be glad to help review, test and collect patches into a tree for Linus/Andrew to pull while we wait for Len to respond or another maintainer to emerge. As I advised recently, it is usually a good idea for the person/group who is working the most on a subsystem to simply take the lead and become the new maintainer. Waiting for another maintainer to emerge could be compared to cowardice. Nicolas
Re: [PATCH v7 1/3] Documentation: common clk API
On Tue, 20 Mar 2012, Paul Walmsley wrote: We need to indicate in some way that the existing code and API is very likely to change in ways that could involve quite a bit of work for adopters. [...] Anyway. It is okay if we want to have some starter common clock framework in mainline; this is why deferring the merge hasn't been proposed. But the point is that anyone who bases their code or platform on the common clock framework needs to be aware that, to satisfy one of its major use-cases, the behavior and/or API of the common clock code may need to change significantly. Paul, While I understand your concern, please don't forget that the perfect is the enemy of the good. This common clk API has been under development for over *two* years already, with several attempts to merge it. And each previous merge attempt aborted because someone came along at the last minute to do exactly what you are doing i.e. underline all the flaws and call for a redesign. This is becoming a bad joke. We finally have something that the majority of reviewers are happy with and which should cover the majority of existing cases out there. Let's give it a chance, shall we? Otherwise one might ask where were you during those development years if you claim that the behavior and/or API of the common clock code still need to change significantly? Explicitly stating this is not only simple courtesy to its users, many of whom won't have been privy to its development. It also is intended to make the code easier to change once it reaches mainline. The code will be easier to change once it is in mainline, simply due to the fact that you can also change all its users at once. And it is well possible that most users won't have to deal with the same magnitude of complexity as yours, again reducing the scope for resistance to changes. Let's see how things go with the current code and improve it incrementally. Otherwise no one will get involved with this API which is almost just as bad as not having the code merged at all. So, until the API is well-defined and does all that it needs to do for its major users, [...] No, the API simply can't ever be well defined if people don't actually start using it to eventually refine it further. Major users were converted to it, and in most cases The API does all that it needs to do already. Otherwise you'll be stuck in a catch22 situation forever. And APIs in the Linux kernel do change all the time. There is no stable API in the kernel. Extensions will come about eventually, and existing users (simple ones by definition if the current API already meets their needs) should be converted over easily. Nicolas -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] of: Add generic device tree DMA helpers
On Thu, 15 Mar 2012, Russell King - ARM Linux wrote: I really don't like these behind-the-scenes discussions which never then get followed up in public, and people then start quoting what was agreed as that's the way things must be done. It's a bit like folk at the recent Linaro Connect apparantly discussing my machine registry and deciding that it should be shut down. No one has yet talked to me about that or even done the curtesy of asking me what my view is. Let me catch the ball in flight here as the responsible folk was me. For the transition to DT to be effective for new boards on ARM, I suggested that the machine registry would need to be closed at this point i.e. no new additions to it. As far as I remember, Vincent volunteered to talk to you about it, which he apparently did within the same hour. That's all there was to it. Nicolas -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP3 L2/outer cache enabled in kernel (after being disabled by uBoot)?
On Tue, 31 Jan 2012, Catalin Marinas wrote: Maybe we could factor out the CPU-specific settings from proc-v*.S into a separate arch/arm/boot/preload directory. We keep proc-v*.S entirely generic and the implementation-defined bits setting in the preload code. You could have an option to link the preload with the kernel but we could recommend that people run this code from boot-loader before invoking the kernel. This code would be dependent on platform and chosen at build-time. But the actual kernel image would be generic. I'd recommend against that. Again, the reason is not technical but rather has to do with the tendency to laziness of human beings. So please let's not go there or it'll become the de facto standard. Furthermore, if this is risky to leave a vulnerable window by activating some workarounds later during the boot process, then the risk won't go away entirely by moving those workarounds a bit earlier. In which case the only real solution is to have them enabled by the bootloader before the cache is even turned on for the first time, and this is hardly Linux specific anyway. The whole idea behind having a generic kernel is all about distributions. If a generic kernel has to be distributed with a platform specific pre-kernel blob then we've gained nothing. Same goes for the DTB. Those platform specific blobs must be distributed _with_ the hardware and _not_ with the software distribution. Having the dts files in the kernel right now is only a convenience for the transition to device tree. Eventually they all will be removed from the tree when we get to a minimum of stability in the device tree implementation and the DTB will also have to come with the hardware along with the bootloader. Nicolas -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP3 L2/outer cache enabled in kernel (after being disabled by uBoot)?
On Tue, 31 Jan 2012, Shilimkar, Santosh wrote: On Tue, Jan 31, 2012 at 3:26 PM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: So, as many people have said, we're not going to go down the route of allowing platforms to hook into this code. There's plenty of other solutions to this problem in different parts of the system that would be more than adequate, and would benefit everyone not just the kernel. Sure. The marco has missed those details. Thanks for the useful information. At least I can fix the stack size for internal use. If you intend to ignore our advises and continue with the quick and dirty solution for your internal tree, then at least don't brag on a public list about it. Your continued resistance to every alternative suggestion but your (broken) hook is getting extremely frustrating. Please try some of these other approaches which are being proposed. Thanks. I was just trying to get more information about the alternatives and trying to bring out possible issues. I know for sure that boot-loader is not an option since we have had many instances where it has not worked. I also understand that patching early common code is going to be tricky and of-course against the single zImage. So the option mentioned by Nicolas and Catalin about 1:1 mapping and configuring the registers in platform specific code was looking a way forward. So was asking more questions about whether this can work in all cases. Specifically for A15. So far this is apparently your best option. And luckily the code to create a 1:1 mapping, turn off MMU, then turn MMU back on and tear down the 1:1 mapping already exists. All you need to do is to insert the cache workaround activation in the middle of that instead of shutting the CPU down. As per Catalin's email, it is best to handle those cases before MMU is enabled with boot-monitor or pre-load code. These days bootloaders are turning the MMU on for themselves, so you'll need pre-load code for the bootloader already. Either that, or the issue is not necessarily _that_ critical in which case you can afford to enable your workaround a bit later during the kernel boot. Nicolas
Re: OMAP3 L2/outer cache enabled in kernel (after being disabled by uBoot)?
On Tue, 17 Jan 2012, Shilimkar, Santosh wrote: On Tue, Jan 17, 2012 at 5:27 PM, Catalin Marinas catalin.mari...@arm.com wrote: BTW, does the firmware make any checks on what bits it allows to be set? Some of them may have security implications (and may not even be documented). Anyway, the first step is this API provided by the secure firmware. Since such API may need to be called before the MMU is initialised, Linux would need to have knowledge of the platform type early on. Having some platform hook (asm macro) to call early on wouldn't work with the single zImage configuration. Stack space is not an issue as we already have one for ARMv7 for D-cache flushing (XIP kernels would work but they aren't that many). That's true. That stack is ugly and _does_ break XIP (even if there aren't that many if at all on ARMv7). Since we're already writing to RAM while setting up the initial page table and therefore we did the necessary work to locate it already, we could as well put a temporary stack for early usage right below the page table. Firmware point is actually irrelevant for OMAP since it can't be changed once it is ROMed. Patching in boot-loaders isn't an option either since every customers prefers to use there own boot-loader and then controlling this vital bits is impossible. So I re-iterate that we need to have solution to this problem. I don't disagree with this, a solution is needed. In the past I was for having platform hooks in the early kernel code path but in the light of latest kernel developments (FDT, single zImage), I no longer see this as acceptable. Thanks for acknowledging the problem. Not allowing such hooks for single zImage doesn't seems to be right. Nobody ships kernel build for all socs, and it's usage is really limited to few distro's. But that's different topic. No, I think this is right on topic. If nobody ships a kernel for multiple SOCs, this is because right now this can't be done. But distros are craving for this ability. How about allowing platform hooks for single SOC builds. I mean having this code under !single_zImage or something like that. That way we don't impact the single zImage efforts and also allow socs to have all those critical, vital bits enabled for the SOC specific builds. Absolutely not! Because if we start doing that, people will get lazy and no platform will ever work in a multi-SOC kernel. If your SOC require some fancy setup that is not shared by other platforms then please abstract that into the bootloader, or make sure it can be deferred later on. Nicolas -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP3 L2/outer cache enabled in kernel (after being disabled by uBoot)?
On Tue, 17 Jan 2012, Shilimkar, Santosh wrote: On Tue, Jan 17, 2012 at 8:39 PM, Nicolas Pitre n...@fluxnic.net wrote: On Tue, 17 Jan 2012, Shilimkar, Santosh wrote: How about allowing platform hooks for single SOC builds. I mean having this code under !single_zImage or something like that. That way we don't impact the single zImage efforts and also allow socs to have all those critical, vital bits enabled for the SOC specific builds. Absolutely not! Because if we start doing that, people will get lazy and no platform will ever work in a multi-SOC kernel. If your SOC require some fancy setup that is not shared by other platforms then please abstract that into the bootloader, or make sure it can be deferred later on. There is nothing fancy here. It's an ARM security architecture feature which OMAP implements. Have given enough reason about boot-loaders issues. I was not convinced by those reasons. Just push harder on the bootloader side. There is _no_ reason for the bootloader not to take care of this very platform specific issue. You can even do it into a standalone uImage that returns to u-Boot after it is done with its magic. Is OMAP getting beaten up here just because it uses ARM security feature and implements it's mechanics? I don't care if this is OMAP, UX500 or i.MX. There is a line to be drawn and this is just too bad if you are trying to cross it. Nicolas
Re: OMAP3 L2/outer cache enabled in kernel (after being disabled by uBoot)?
On Tue, 17 Jan 2012, Nicolas Pitre wrote: On Tue, 17 Jan 2012, Shilimkar, Santosh wrote: On Tue, Jan 17, 2012 at 8:39 PM, Nicolas Pitre n...@fluxnic.net wrote: On Tue, 17 Jan 2012, Shilimkar, Santosh wrote: How about allowing platform hooks for single SOC builds. I mean having this code under !single_zImage or something like that. That way we don't impact the single zImage efforts and also allow socs to have all those critical, vital bits enabled for the SOC specific builds. Absolutely not! Because if we start doing that, people will get lazy and no platform will ever work in a multi-SOC kernel. If your SOC require some fancy setup that is not shared by other platforms then please abstract that into the bootloader, or make sure it can be deferred later on. There is nothing fancy here. It's an ARM security architecture feature which OMAP implements. Have given enough reason about boot-loaders issues. I was not convinced by those reasons. Just push harder on the bootloader side. There is _no_ reason for the bootloader not to take care of this very platform specific issue. You can even do it into a standalone uImage that returns to u-Boot after it is done with its magic. Alternatively, you may leverage all the infrastructure that was implemented to support CPU offlining i.e. the creation of a 1:1 mapping needed to disable the MMU and so on. That should be possible for you to just have the MMU turned off, then call the secure mode to turn on L2, then restore MMU and normal operation of the kernel. This can be accomplished later during boot rather than right at the beginning. Nicolas
Re: OMAP3 L2/outer cache enabled in kernel (after being disabled by uBoot)?
On Tue, 17 Jan 2012, Shilimkar, Santosh wrote: On Tue, Jan 17, 2012 at 9:45 PM, Nicolas Pitre n...@fluxnic.net wrote: On Tue, 17 Jan 2012, Shilimkar, Santosh wrote: On Tue, Jan 17, 2012 at 8:39 PM, Nicolas Pitre n...@fluxnic.net wrote: On Tue, 17 Jan 2012, Shilimkar, Santosh wrote: How about allowing platform hooks for single SOC builds. I mean having this code under !single_zImage or something like that. That way we don't impact the single zImage efforts and also allow socs to have all those critical, vital bits enabled for the SOC specific builds. Absolutely not! Because if we start doing that, people will get lazy and no platform will ever work in a multi-SOC kernel. If your SOC require some fancy setup that is not shared by other platforms then please abstract that into the bootloader, or make sure it can be deferred later on. There is nothing fancy here. It's an ARM security architecture feature which OMAP implements. Have given enough reason about boot-loaders issues. I was not convinced by those reasons. Just push harder on the bootloader side. There is _no_ reason for the bootloader not to take care of this very platform specific issue. You can even do it into a standalone uImage that returns to u-Boot after it is done with its magic. Is OMAP getting beaten up here just because it uses ARM security feature and implements it's mechanics? I don't care if this is OMAP, UX500 or i.MX. There is a line to be drawn and this is just too bad if you are trying to cross it. Well I was trying to get a solution for a genuine problem. Let's take an example. #ifdef CONFIG_ARM_ERRATA_742230 cmp r6, #0x22 @ only present up to r2p2 mrcle p15, 0, r10, c15, c0, 1 @ read diagnostic register orrle r10, r10, #1 4 @ set bit #4 mcrle p15, 0, r10, c15, c0, 1 @ write diagnostic register #endif The SoC's which doesn't have security restriction and the kernel is in secure mode, above errata is applied in it's right place. Before MMU is enabled. There are many bits like this which are patched in kernel. On OMAP, all these can't be set-up in kernel since kernel is in non-secure mode. To set such bit's we need to call some pre-defined security calls. Absolutely. Just don't do it in the early kernel boot code where it is not convenient to do so. Nicolas
Re: [PATCH] arm: omap4: Fix omap_barriers_init for generic ioremap changes
On Thu, 12 Jan 2012, Tony Lindgren wrote:
Commit 73829af71fdb8655e7ba4b5a2a6612ad34a75a11
(Merge branch 'vmalloc' of git://git.linaro.org/people/nico/linux
into devel-stable) merged generic ioremap changes.
Commit 137d105d50f6e6c373c1aa759f59045e6239cf66
(ARM: OMAP4: Fix errata i688 with MPU interconnect barriers)
added a workaround for omap4.
In order for the errata to work, we now need the following
patch or else we'll get:
kernel BUG at mm/vmalloc.c:1134!
Signed-off-by: Tony Lindgren t...@atomide.com
--- a/arch/arm/mach-omap2/common.h
+++ b/arch/arm/mach-omap2/common.h
@@ -132,6 +132,7 @@ void omap3_map_io(void);
void am33xx_map_io(void);
void omap4_map_io(void);
void ti81xx_map_io(void);
+int omap_barriers_init(void);
/**
* omap_test_timeout - busy-loop, testing a condition
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -306,7 +306,12 @@ void __init omapam33xx_map_common_io(void)
#ifdef CONFIG_ARCH_OMAP4
void __init omap44xx_map_common_io(void)
{
+ int res;
+
iotable_init(omap44xx_io_desc, ARRAY_SIZE(omap44xx_io_desc));
+ res = omap_barriers_init();
+ if (res)
+ pr_err(Barriers broken\n);
Do you really need that return code?
It was initially hooked to core_initcall() which requires a return code.
Now that you call it directly you could get rid of it.
Nicolas
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] arm: omap4: Fix omap_barriers_init for generic ioremap changes
On Thu, 12 Jan 2012, Nicolas Pitre wrote:
On Thu, 12 Jan 2012, Tony Lindgren wrote:
Commit 73829af71fdb8655e7ba4b5a2a6612ad34a75a11
(Merge branch 'vmalloc' of git://git.linaro.org/people/nico/linux
into devel-stable) merged generic ioremap changes.
Commit 137d105d50f6e6c373c1aa759f59045e6239cf66
(ARM: OMAP4: Fix errata i688 with MPU interconnect barriers)
added a workaround for omap4.
In order for the errata to work, we now need the following
patch or else we'll get:
kernel BUG at mm/vmalloc.c:1134!
Signed-off-by: Tony Lindgren t...@atomide.com
--- a/arch/arm/mach-omap2/common.h
+++ b/arch/arm/mach-omap2/common.h
@@ -132,6 +132,7 @@ void omap3_map_io(void);
void am33xx_map_io(void);
void omap4_map_io(void);
void ti81xx_map_io(void);
+int omap_barriers_init(void);
/**
* omap_test_timeout - busy-loop, testing a condition
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -306,7 +306,12 @@ void __init omapam33xx_map_common_io(void)
#ifdef CONFIG_ARCH_OMAP4
void __init omap44xx_map_common_io(void)
{
+ int res;
+
iotable_init(omap44xx_io_desc, ARRAY_SIZE(omap44xx_io_desc));
+ res = omap_barriers_init();
+ if (res)
+ pr_err(Barriers broken\n);
Do you really need that return code?
It was initially hooked to core_initcall() which requires a return code.
Now that you call it directly you could get rid of it.
s/rid of it/rid of the return code/
Nicolas
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] OMAP: Update nr_irqs field in machine descriptors
On Thu, 6 Oct 2011, Tony Lindgren wrote: * S, Venkatraman svenk...@ti.com [110825 07:23]: On Thu, Aug 25, 2011 at 5:19 PM, Cousson, Benoit b-cous...@ti.com wrote: Hi Venkat, On 8/24/2011 9:46 PM, S, Venkatraman wrote: As part of an effort to get single ARM kernel binary [1], multiple definitions of NR_IRQS under various platforms have to be reconciled and abstracted away from common code. This patch series takes the small step of populating the machine descriptors with the pre-existing nr_irqs field. Eventually, the common irq handler code will only look at this field and not the compile time constant. Not related to this patch, but still on that topic. The current NR_IRQS depends as well on board stuff, like for example : the Phoenix IRQs:TWL6030_IRQ_BASE, TWL6040_CODEC_IRQ_BASE. Is there a plan to get rid of this static defines? Currently, the goal is to get rid of the singleton nature of NR_IRQS. Then it just becomes a property of the platform, and the arm common code should not see this define. This cleanup has to be done across multiple SoCs, not just OMAP. After I get to complete some meaningful cleanup of NR_IRQS, I can look into the static defines that you mention. I suggest we wait on this patch as the NR_IRQS should be the board specific true number of interrupts including chained interrupts from external devices like twl. So just setting it to NR_IRQS does not help much. Also, the board-*.c files will be going aways with device tree at some point. This is prerequisite to some other cleanup orthogonal to DT being worked in parallel. I would prefer if DT wasn't a serialization point for this. Nicolas
Re: [PATCH 0/4] initialize omap SRAM later on with __arm_ioremap_exec()
On Fri, 7 Oct 2011, Santosh Shilimkar wrote: I have reviewed and tested this series. No problems seen. As asked on other thread, if you are targeting this one for 3.2, then sram changes would have a small conflict with OMAP4 errata patch. If it is for 3.3, we should be able to sort out that conflict easily. 3.2 please. I've postponed one of my series to 3.3 because it breaks OMAP unless those changes are applied first. Nicolas -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 7/7] ARM: OMAP: Warn if omap_ioremap is called before SoC detection
On Fri, 7 Oct 2011, Tony Lindgren wrote:
We don't have cpu_is_omap SoC detection initialized until
SoC detection is initialized from init_early.
Note that with the common map_io we should no longer need
cpu_is_omap for ioremap.
Signed-off-by: Tony Lindgren t...@atomide.com
Acked-by: Nicolas Pitre nicolas.pi...@linaro.org
---
arch/arm/mach-omap1/io.c |1 +
arch/arm/mach-omap2/io.c |1 +
arch/arm/plat-omap/include/plat/io.h |2 ++
arch/arm/plat-omap/io.c | 10 ++
4 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap1/io.c b/arch/arm/mach-omap1/io.c
index 8140a4e..fd9eb09 100644
--- a/arch/arm/mach-omap1/io.c
+++ b/arch/arm/mach-omap1/io.c
@@ -121,6 +121,7 @@ void __init omap16xx_map_io(void)
void omap1_init_early(void)
{
omap_check_revision();
+ omap_ioremap_init();
/* REVISIT: Refer to OMAP5910 Errata, Advisory SYS_1: Timeout Abort
* on a Posted Write in the TIPB Bridge.
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index d5caac3..aa96538 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -323,6 +323,7 @@ void __iomem *omap_irq_base;
static void __init omap_common_init_early(void)
{
omap2_check_revision();
+ omap_ioremap_init();
}
static void __init omap_hwmod_init_postsetup(void)
diff --git a/arch/arm/plat-omap/include/plat/io.h
b/arch/arm/plat-omap/include/plat/io.h
index c0c7850..5ffbea6 100644
--- a/arch/arm/plat-omap/include/plat/io.h
+++ b/arch/arm/plat-omap/include/plat/io.h
@@ -247,6 +247,8 @@
* NOTE: Please use ioremap + __raw_read/write where possible instead of
these
*/
+void omap_ioremap_init(void);
+
extern u8 omap_readb(u32 pa);
extern u16 omap_readw(u32 pa);
extern u32 omap_readl(u32 pa);
diff --git a/arch/arm/plat-omap/io.c b/arch/arm/plat-omap/io.c
index f1ecfa9..1bbcbde 100644
--- a/arch/arm/plat-omap/io.c
+++ b/arch/arm/plat-omap/io.c
@@ -23,11 +23,16 @@
#define BETWEEN(p,st,sz) ((p) = (st) (p) ((st) + (sz)))
#define XLATE(p,pst,vst) ((void __iomem *)((p) - (pst) + (vst)))
+static int initialized;
+
/*
* Intercept ioremap() requests for addresses in our fixed mapping regions.
*/
void __iomem *omap_ioremap(unsigned long p, size_t size, unsigned int type)
{
+
+ WARN(!initialized, Do not use ioremap before init_early\n);
+
#ifdef CONFIG_ARCH_OMAP1
if (cpu_class_is_omap1()) {
if (BETWEEN(p, OMAP1_IO_PHYS, OMAP1_IO_SIZE))
@@ -139,3 +144,8 @@ void omap_iounmap(volatile void __iomem *addr)
__iounmap(addr);
}
EXPORT_SYMBOL(omap_iounmap);
+
+void __init omap_ioremap_init(void)
+{
+ initialized++;
+}
___
linux-arm-kernel mailing list
linux-arm-ker...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] OMAP: Update nr_irqs field in machine descriptors
On Fri, 7 Oct 2011, Tony Lindgren wrote: * Nicolas Pitre n...@fluxnic.net [111007 12:41]: On Thu, 6 Oct 2011, Tony Lindgren wrote: * S, Venkatraman svenk...@ti.com [110825 07:23]: On Thu, Aug 25, 2011 at 5:19 PM, Cousson, Benoit b-cous...@ti.com wrote: Hi Venkat, On 8/24/2011 9:46 PM, S, Venkatraman wrote: As part of an effort to get single ARM kernel binary [1], multiple definitions of NR_IRQS under various platforms have to be reconciled and abstracted away from common code. This patch series takes the small step of populating the machine descriptors with the pre-existing nr_irqs field. Eventually, the common irq handler code will only look at this field and not the compile time constant. Not related to this patch, but still on that topic. The current NR_IRQS depends as well on board stuff, like for example : the Phoenix IRQs:TWL6030_IRQ_BASE, TWL6040_CODEC_IRQ_BASE. Is there a plan to get rid of this static defines? Currently, the goal is to get rid of the singleton nature of NR_IRQS. Then it just becomes a property of the platform, and the arm common code should not see this define. This cleanup has to be done across multiple SoCs, not just OMAP. After I get to complete some meaningful cleanup of NR_IRQS, I can look into the static defines that you mention. I suggest we wait on this patch as the NR_IRQS should be the board specific true number of interrupts including chained interrupts from external devices like twl. So just setting it to NR_IRQS does not help much. Also, the board-*.c files will be going aways with device tree at some point. This is prerequisite to some other cleanup orthogonal to DT being worked in parallel. I would prefer if DT wasn't a serialization point for this. I see. How about let's populate the real number of interrupts for the known boards then while at it. Sure, if you know what you are doing (which I'm sure you do). Otherwise using NR_IRQS is more or less a functional no-op wrt the current situation, and therefore what I would have used myself because I don't know much about the various OMAP boards. Nicolas
Re: [PATCH 5/4] ARM: OMAP: Move set_globals initialization to happen in init_early
On Fri, 7 Oct 2011, Tony Lindgren wrote: * Santosh Shilimkar santosh.shilim...@ti.com [111006 23:22]: The changes looks fine to me. Though the ugly hard-coding is back with it, it's a step towards generic_io, so hopefully it won't have to stay for long time. Nico please correct me if I'm wrong, but I think that with generic map_io we have static mappings in place after map_io, and then ioremap should work for the static mappings right after map_io except without the need for __arch_ioremap. Yes, that _should_ work. Nicolas -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Please help with the OMAP static mapping mess
On Mon, 3 Oct 2011, Russell King - ARM Linux wrote: On Mon, Oct 03, 2011 at 06:09:57PM -0400, Nicolas Pitre wrote: On Mon, 3 Oct 2011, Tony Lindgren wrote: Having the SRAM base address move around with different sizes also requires the SoC detection.. Otherwise we can end up mapping wrong size and end up trying to access secure SRAM that will hang the system. The way to fix it is to move SRAM init happen much later so we don't have to map it early. I guess now we could use ioremap for SRAM, although we may not want device attributes for the executable code? Got any suggestions here on how we should map SRAM later on? You can use a variant of ioremap() such as __arm_ioremap() which let you specify the memory attribute. Just be aware that __arm_ioremap() always ends up with stuff in the kernel domain, but that's not what you end up with using create_mapping(). So I'd prefer it if you didn't suggest that __arm_ioremap() should be used with types not listed in asm/io.h. Well, here we're talking about MT_MEMORY and MT_MEMORY_NONCACHED, and they are using DOMAIN_KERNEL already. So no difference there. Which makes me think... with all those architectures intercepting ioremap calls in order to provide an equivalent static mapping address, they already get an unexpected domain given that static mappings are mostly DOMAIN_IO and not DOMAIN_KERNEL as would result from an non intercepted ioremap call. Nicolas -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Please help with the OMAP static mapping mess
On Tue, 4 Oct 2011, Santosh Shilimkar wrote: On Tuesday 04 October 2011 04:08 AM, Tony Lindgren wrote: * Nicolas Pitre n...@fluxnic.net [111003 14:36]: On Mon, 3 Oct 2011, Tony Lindgren wrote: Having the SRAM base address move around with different sizes also requires the SoC detection.. Otherwise we can end up mapping wrong size and end up trying to access secure SRAM that will hang the system. The way to fix it is to move SRAM init happen much later so we don't have to map it early. I guess now we could use ioremap for SRAM, although we may not want device attributes for the executable code? Got any suggestions here on how we should map SRAM later on? You can use a variant of ioremap() such as __arm_ioremap() which let you specify the memory attribute. OK, I'll take a look at that. I have tried __arm_ioremap_pfn() for some DDR mapping and it didn't work as expected. The mapping was not getting created. Did you investigate why it wasn't created? Must have been a trivial issue surely? But you have to wait until memory management is fully initialized to call the real ioremap() though, which happens later during the boot. Needless to say this can't be an IO memory. I later managed to get around with it by using iotable_init() though downside is I have to pick a static virtual address for the mapping. You are using either MT_MEMORY or MT_MEMORY_NONCACHED in your map_desc entry. So using e.g. __arm_ioremap(phys_addr, size, MT_MEMORY) should give you what you need, given that this is called late enough of course. But I agree that SRAM mapping can be moved further down. We just need to ensure that it's ready before we initialise SDRC and PM code. SDRC reconfigure of DDR needs to be executed from SRAM and of-course the PM WFI routine. Today we do SDRC init early and that's the reason SRAM is mapped before that. So both of them needs to be moved down in the boot to make it work. Note that it is best not to call iotable_init() outside of the mdesc-map_io call path. So either you reshuffle the initialization order so that the static mappings alre always in place before doing the ioremap() trick, or you use __arm_ioremap() later on. Nicolas -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Please help with the OMAP static mapping mess
On Tue, 4 Oct 2011, Russell King - ARM Linux wrote: On Tue, Oct 04, 2011 at 05:10:36PM -0400, Nicolas Pitre wrote: Which makes me think... with all those architectures intercepting ioremap calls in order to provide an equivalent static mapping address, they already get an unexpected domain given that static mappings are mostly DOMAIN_IO and not DOMAIN_KERNEL as would result from an non intercepted ioremap call. That's a necessary evil - otherwise we have to separate out the ioremap from vmalloc. Incidentally, how are you dealing with the problem of a static mapping setting up a L1 page table entry for DOMAIN_IO, and then a vmalloc request coming in, overlapping that L1 page table? If this memory then gets accessed with get_user() with set_fs(get_ds()), the kernel will oops as we don't switch DOMAIN_IO memory on set_fs(). (I don't know if this happens in practice, but there's nothing to say that it's illegal to do this.) I suppose that didn't happen so far. Granted, moving the ioremap optimization into core code for all machines will increase the possibility for this to happen, even if still small. With CPU_USE_DOMAINS not set, set_fs() is a no-op anyway, besides addr_limit that is. Is there a strong benefit in having static mappings being DOMAIN_IO instead of DOMAIN_KERNEL? Nicolas -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Please help with the OMAP static mapping mess
On Tue, 4 Oct 2011, Tony Lindgren wrote: In any case, I suggest we add the following __arm_ioremap_exec patch and then sort out issues with it as they show up. This allows further work on the common SRAM genalloc patches and generic map_io patches. Nico, I already have a series converting omap2+ to use the the patch below, and it seems to be working just fine for SRAM. I'll post that series separately shortly. Maybe take a look and see if that allows you to do the generic map_io changes? Yes, that looks fine. Maybe you could avoid exporting the symbol until it is actually needed though. The other thing I need is for the code using ioremap() such as in omap2_set_globals_control() to be called only after the corresponding static mappings are already installed. Then everything should go smoothly. Nicolas -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] ARM: Add __arm_ioremap_exec for mapping external memory as MT_MEMORY
On Tue, 4 Oct 2011, Tony Lindgren wrote:
This allows mapping external memory such as SRAM for use.
This is needed for some small chunks of code, such as reprogramming
SDRAM memory source clocks that can't be executed in SDRAM. Other
use cases include some PM related code.
Signed-off-by: Tony Lindgren t...@atomide.com
Acked-by: Nicolas Pitre nicolas.pi...@linaro.org
As mentioned, you might consider dropping the export until needed.
---
arch/arm/include/asm/io.h |1 +
arch/arm/mm/ioremap.c | 22 ++
2 files changed, 23 insertions(+), 0 deletions(-)
diff --git a/arch/arm/include/asm/io.h b/arch/arm/include/asm/io.h
index d66605d..4ff152e 100644
--- a/arch/arm/include/asm/io.h
+++ b/arch/arm/include/asm/io.h
@@ -80,6 +80,7 @@ extern void __iomem *__arm_ioremap_caller(unsigned long,
size_t, unsigned int,
extern void __iomem *__arm_ioremap_pfn(unsigned long, unsigned long, size_t,
unsigned int);
extern void __iomem *__arm_ioremap(unsigned long, size_t, unsigned int);
+extern void __iomem *__arm_ioremap_exec(unsigned long, size_t, int cached);
extern void __iounmap(volatile void __iomem *addr);
/*
diff --git a/arch/arm/mm/ioremap.c b/arch/arm/mm/ioremap.c
index ab50627..a813658 100644
--- a/arch/arm/mm/ioremap.c
+++ b/arch/arm/mm/ioremap.c
@@ -289,6 +289,28 @@ __arm_ioremap(unsigned long phys_addr, size_t size,
unsigned int mtype)
}
EXPORT_SYMBOL(__arm_ioremap);
+/*
+ * Remap an arbitrary physical address space into the kernel virtual
+ * address space as memory. Needed when the kernel wants to execute
+ * code in external memory. This is needed for reprogramming source
+ * clocks that would affect normal memory for example. Please see
+ * CONFIG_GENERIC_ALLOCATOR for allocating external memory.
+ */
+void __iomem *
+__arm_ioremap_exec(unsigned long phys_addr, size_t size, int cached)
+{
+ unsigned int mtype;
+
+ if (cached)
+ mtype = MT_MEMORY;
+ else
+ mtype = MT_MEMORY_NONCACHED;
+
+ return __arm_ioremap_caller(phys_addr, size, mtype,
+ __builtin_return_address(0));
+}
+EXPORT_SYMBOL(__arm_ioremap_exec);
+
void __iounmap(volatile void __iomem *io_addr)
{
void *addr = (void *)(PAGE_MASK (unsigned long)io_addr);
___
linux-arm-kernel mailing list
linux-arm-ker...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/4] ARM: OMAP: Map SRAM later on with ioremap_exec()
On Tue, 4 Oct 2011, Tony Lindgren wrote:
This allows us to remove omap hacks for map_io.
Signed-off-by: Tony Lindgren t...@atomide.com
Nice cleanup.
Acked-by: Nicolas Pitre nicolas.pi...@linaro.org
---
arch/arm/mach-omap2/io.c | 19 +---
arch/arm/plat-omap/sram.c | 69
+
2 files changed, 22 insertions(+), 66 deletions(-)
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index 82230e1..8069ca8 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -239,22 +239,11 @@ static struct map_desc omap44xx_io_desc[] __initdata = {
};
#endif
-static void __init _omap2_map_common_io(void)
-{
- /* Normally devicemaps_init() would flush caches and tlb after
- * mdesc-map_io(), but we must also do it here because of the CPU
- * revision check below.
- */
- local_flush_tlb_all();
- flush_cache_all();
-}
-
#ifdef CONFIG_SOC_OMAP2420
void __init omap242x_map_common_io(void)
{
iotable_init(omap24xx_io_desc, ARRAY_SIZE(omap24xx_io_desc));
iotable_init(omap242x_io_desc, ARRAY_SIZE(omap242x_io_desc));
- _omap2_map_common_io();
}
#endif
@@ -263,7 +252,6 @@ void __init omap243x_map_common_io(void)
{
iotable_init(omap24xx_io_desc, ARRAY_SIZE(omap24xx_io_desc));
iotable_init(omap243x_io_desc, ARRAY_SIZE(omap243x_io_desc));
- _omap2_map_common_io();
}
#endif
@@ -271,7 +259,6 @@ void __init omap243x_map_common_io(void)
void __init omap34xx_map_common_io(void)
{
iotable_init(omap34xx_io_desc, ARRAY_SIZE(omap34xx_io_desc));
- _omap2_map_common_io();
}
#endif
@@ -279,7 +266,6 @@ void __init omap34xx_map_common_io(void)
void __init omapti816x_map_common_io(void)
{
iotable_init(omapti816x_io_desc, ARRAY_SIZE(omapti816x_io_desc));
- _omap2_map_common_io();
}
#endif
@@ -287,7 +273,6 @@ void __init omapti816x_map_common_io(void)
void __init omap44xx_map_common_io(void)
{
iotable_init(omap44xx_io_desc, ARRAY_SIZE(omap44xx_io_desc));
- _omap2_map_common_io();
}
#endif
@@ -336,7 +321,6 @@ void __iomem *omap_irq_base;
static void __init omap_common_init_early(void)
{
omap2_check_revision();
- omap_sram_init();
}
static void __init omap_hwmod_init_postsetup(void)
@@ -448,11 +432,12 @@ void __init omap4430_init_early(void)
void __init omap_sdrc_init(struct omap_sdrc_params *sdrc_cs0,
struct omap_sdrc_params *sdrc_cs1)
{
+ omap_sram_init();
+
if (cpu_is_omap24xx() || omap3_has_sdrc()) {
omap2_sdrc_init(sdrc_cs0, sdrc_cs1);
_omap2_init_reprogram_sdrc();
}
-
}
/*
diff --git a/arch/arm/plat-omap/sram.c b/arch/arm/plat-omap/sram.c
index 3c8aa44..8b28664 100644
--- a/arch/arm/plat-omap/sram.c
+++ b/arch/arm/plat-omap/sram.c
@@ -38,16 +38,9 @@
#endif
#define OMAP1_SRAM_PA0x2000
-#define OMAP1_SRAM_VAVMALLOC_END
#define OMAP2_SRAM_PUB_PA(OMAP2_SRAM_PA + 0xf800)
-#define OMAP2_SRAM_VA0xfe40
-#define OMAP2_SRAM_PUB_VA(OMAP2_SRAM_VA + 0x800)
-#define OMAP3_SRAM_VA 0xfe40
#define OMAP3_SRAM_PUB_PA (OMAP3_SRAM_PA + 0x8000)
-#define OMAP3_SRAM_PUB_VA (OMAP3_SRAM_VA + 0x8000)
-#define OMAP4_SRAM_VA0xfe40
#define OMAP4_SRAM_PUB_PA(OMAP4_SRAM_PA + 0x4000)
-#define OMAP4_SRAM_PUB_VA(OMAP4_SRAM_VA + 0x4000)
#if defined(CONFIG_ARCH_OMAP2PLUS)
#define SRAM_BOOTLOADER_SZ 0x00
@@ -70,9 +63,9 @@
#define ROUND_DOWN(value,boundary) ((value) (~((boundary)-1)))
static unsigned long omap_sram_start;
-static unsigned long omap_sram_base;
+static void __iomem *omap_sram_base;
static unsigned long omap_sram_size;
-static unsigned long omap_sram_ceil;
+static void __iomem *omap_sram_ceil;
/*
* Depending on the target RAMFS firewall setup, the public usable amount of
@@ -112,7 +105,6 @@ static void __init omap_detect_sram(void)
if (cpu_class_is_omap2()) {
if (is_sram_locked()) {
if (cpu_is_omap34xx()) {
- omap_sram_base = OMAP3_SRAM_PUB_VA;
omap_sram_start = OMAP3_SRAM_PUB_PA;
if ((omap_type() == OMAP2_DEVICE_TYPE_EMU) ||
(omap_type() == OMAP2_DEVICE_TYPE_SEC)) {
@@ -121,25 +113,20 @@ static void __init omap_detect_sram(void)
omap_sram_size = 0x8000; /* 32K */
}
} else if (cpu_is_omap44xx()) {
- omap_sram_base = OMAP4_SRAM_PUB_VA;
omap_sram_start = OMAP4_SRAM_PUB_PA;
omap_sram_size = 0xa000; /* 40K */
} else
Re: [PATCH 5/4] ARM: OMAP: Move set_globals initialization to happen in init_early
On Tue, 4 Oct 2011, Tony Lindgren wrote:
Otherwise we can't do generic map_io as we currently rely on
static mappings that work only because of arch_ioremap.
Signed-off-by: Tony Lindgren t...@atomide.com
That's great.
Acked-by: Nicolas Pitre nicolas.pi...@linaro.org
diff --git a/arch/arm/mach-omap2/board-ti8168evm.c
b/arch/arm/mach-omap2/board-ti8168evm.c
index e26c79c..e6ee884 100644
--- a/arch/arm/mach-omap2/board-ti8168evm.c
+++ b/arch/arm/mach-omap2/board-ti8168evm.c
@@ -37,7 +37,6 @@ static void __init ti8168_evm_init(void)
static void __init ti8168_evm_map_io(void)
{
- omap2_set_globals_ti816x();
omapti816x_map_common_io();
}
diff --git a/arch/arm/mach-omap2/common.c b/arch/arm/mach-omap2/common.c
index de61f15..f19a332 100644
--- a/arch/arm/mach-omap2/common.c
+++ b/arch/arm/mach-omap2/common.c
@@ -59,7 +59,6 @@ void __init omap2_set_globals_242x(void)
void __init omap242x_map_io(void)
{
- omap2_set_globals_242x();
omap242x_map_common_io();
}
#endif
@@ -83,7 +82,6 @@ void __init omap2_set_globals_243x(void)
void __init omap243x_map_io(void)
{
- omap2_set_globals_243x();
omap243x_map_common_io();
}
#endif
@@ -107,7 +105,6 @@ void __init omap2_set_globals_3xxx(void)
void __init omap3_map_io(void)
{
- omap2_set_globals_3xxx();
omap34xx_map_common_io();
}
@@ -153,7 +150,6 @@ void __init omap2_set_globals_443x(void)
void __init omap4_map_io(void)
{
- omap2_set_globals_443x();
omap44xx_map_common_io();
}
#endif
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index 4957554..527abdd 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -44,6 +44,7 @@
#include clockdomain.h
#include plat/omap_hwmod.h
#include plat/multi.h
+#include plat/common.h
/*
* The machine specific code may provide the extra mapping besides the
@@ -363,6 +364,7 @@ static void __init omap_hwmod_init_postsetup(void)
void __init omap2420_init_early(void)
{
+ omap2_set_globals_242x();
omap_common_init_early();
omap2xxx_voltagedomains_init();
omap242x_powerdomains_init();
@@ -374,6 +376,7 @@ void __init omap2420_init_early(void)
void __init omap2430_init_early(void)
{
+ omap2_set_globals_243x();
omap_common_init_early();
omap2xxx_voltagedomains_init();
omap243x_powerdomains_init();
@@ -389,6 +392,7 @@ void __init omap2430_init_early(void)
*/
void __init omap3_init_early(void)
{
+ omap2_set_globals_3xxx();
omap_common_init_early();
omap3xxx_voltagedomains_init();
omap3xxx_powerdomains_init();
@@ -420,11 +424,19 @@ void __init am35xx_init_early(void)
void __init ti816x_init_early(void)
{
- omap3_init_early();
+ omap2_set_globals_ti816x();
+ omap_common_init_early();
+ omap3xxx_voltagedomains_init();
+ omap3xxx_powerdomains_init();
+ omap3xxx_clockdomains_init();
+ omap3xxx_hwmod_init();
+ omap_hwmod_init_postsetup();
+ omap3xxx_clk_init();
}
void __init omap4430_init_early(void)
{
+ omap2_set_globals_443x();
omap_common_init_early();
omap44xx_voltagedomains_init();
omap44xx_powerdomains_init();
___
linux-arm-kernel mailing list
linux-arm-ker...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Please help with the OMAP static mapping mess
On Tue, 4 Oct 2011, Rob Herring wrote: On 10/04/2011 04:21 PM, Nicolas Pitre wrote: On Tue, 4 Oct 2011, Santosh Shilimkar wrote: On Tuesday 04 October 2011 04:08 AM, Tony Lindgren wrote: * Nicolas Pitre n...@fluxnic.net [111003 14:36]: On Mon, 3 Oct 2011, Tony Lindgren wrote: Having the SRAM base address move around with different sizes also requires the SoC detection.. Otherwise we can end up mapping wrong size and end up trying to access secure SRAM that will hang the system. The way to fix it is to move SRAM init happen much later so we don't have to map it early. I guess now we could use ioremap for SRAM, although we may not want device attributes for the executable code? Got any suggestions here on how we should map SRAM later on? You can use a variant of ioremap() such as __arm_ioremap() which let you specify the memory attribute. OK, I'll take a look at that. I have tried __arm_ioremap_pfn() for some DDR mapping and it didn't work as expected. The mapping was not getting created. Did you investigate why it wasn't created? Must have been a trivial issue surely? But you have to wait until memory management is fully initialized to call the real ioremap() though, which happens later during the boot. Isn't ioremap prevented from using main memory now? My point is that the memory allocator has to be fully initialized because memory might need to be allocated when ioremap() is called. At the point where static mappings are created, the regular memory allocator is not available yet. Nicolas -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Please help with the OMAP static mapping mess
rant
I must state up front that I'm starting to share the frustration that
was publicly expressed by some other kernel maintainers on a few
occasions during the last year. I'm sorry that this frustration
build-up often ends up bursting out on the OMAP code, but the OMAP
kernel community is not (or at least used not to) always play fair with
the rest of the kernel code and this is probably what is tipping us over
the edge. There is a faint let's hack our way through locally and work
around the generic code limitations smell here that is not pleasant at
all.
/rant
So... here's the issue:
In arch/arm/mach-omap2/common.c:
static void __init __omap2_set_globals(struct omap_globals *omap2_globals)
{
omap2_set_globals_tap(omap2_globals);
omap2_set_globals_sdrc(omap2_globals);
omap2_set_globals_control(omap2_globals);
omap2_set_globals_prcm(omap2_globals);
}
and also
void __init omap2_set_globals_443x(void)
{
omap2_set_globals_tap(omap4_globals);
omap2_set_globals_control(omap4_globals);
omap2_set_globals_prcm(omap4_globals);
}
Except for omap2_set_globals_tap(), those calls all look like:
void __init omap2_set_globals_prcm(struct omap_globals *omap2_globals)
{
/* Static mapping, never released */
if (omap2_globals-prm) {
prm_base = ioremap(omap2_globals-prm, SZ_8K);
WARN_ON(!prm_base);
}
if (omap2_globals-cm) {
cm_base = ioremap(omap2_globals-cm, SZ_8K);
WARN_ON(!cm_base);
}
if (omap2_globals-cm2) {
cm2_base = ioremap(omap2_globals-cm2, SZ_8K);
WARN_ON(!cm2_base);
}
}
The problem is that those ioremap() calls are performed _*before*_ the
memory is fully set up yet, and also even before the corresponding
static mappings are even in place! So not only is the ioremap code
unoperational at this point, but a generic way to trap ioremap() calls
in order to toss a static mapping back won't even work here because
iotable_init() was not even called yet.
The current code get away with it because OMAP is providing its own
__arch_ioremap() which does the interception and provide a virtual
address from hardcoded but yet to exist mappings. But the goal of
global kernel maintenance is to _remove_ such SOC-specific special cases
and move such a perfectly valid optimization into core code where it can
be applied uniformly to all. So the OMAP __arch_ioremap() is going
away, meaning that static mappings have to be in place before ioremap()
calls can return something minimally usable.
OK, so let's modify omap4_panda_map_io() just to test this one board and
reverse the omap44xx_map_common_io() and omap2_set_globals_443x() call
order. Now the mappings will be there before ioremap() is called. But
that, too, doesn't work and the kernel now complains with:
|OMAP revision unknown, please fix!
|Uninitialized omap_chip, please fix!
|Could not detect SRAM size
But it looks like omap2_set_globals_tap() still has to be called first!
Isn't this wonderfully convoluted?
Also the repeated local_flush_tlb_all()/flush_cache_all() calls found in
the OMAP mdesc-map_io code paths (one in _omap2_map_common_io(),
another in omap_map_sram(), just to pick those as examples) is a sure
sign that too much is being done via this call and layering violations
are present.
So could someone in the OMAP camp fix this nonsense ASAP please?
Of course, yesterday would be best.
Furthermore... there is also a static mapping for physical address
0x4e00 using virtual address 0xff10 which is already reserved
for other purposes i.e. the consistent DMA area. It is not immediately
obvious where this comes from without being intimate with the OMAP code.
Can this be fixed as well i.e. moved elsewhere please?
Patches will be extremely welcome.
Thank you.
Nicolas
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Please help with the OMAP static mapping mess
On Mon, 3 Oct 2011, Tony Lindgren wrote: * Nicolas Pitre n...@fluxnic.net [111003 11:26]: The problem is that those ioremap() calls are performed _*before*_ the memory is fully set up yet, and also even before the corresponding static mappings are even in place! So not only is the ioremap code unoperational at this point, but a generic way to trap ioremap() calls in order to toss a static mapping back won't even work here because iotable_init() was not even called yet. The current code get away with it because OMAP is providing its own __arch_ioremap() which does the interception and provide a virtual address from hardcoded but yet to exist mappings. But the goal of global kernel maintenance is to _remove_ such SOC-specific special cases and move such a perfectly valid optimization into core code where it can be applied uniformly to all. So the OMAP __arch_ioremap() is going away, meaning that static mappings have to be in place before ioremap() calls can return something minimally usable. Sure this would be nice to fix, see below. Great! OK, so let's modify omap4_panda_map_io() just to test this one board and reverse the omap44xx_map_common_io() and omap2_set_globals_443x() call order. Now the mappings will be there before ioremap() is called. But that, too, doesn't work and the kernel now complains with: |OMAP revision unknown, please fix! |Uninitialized omap_chip, please fix! |Could not detect SRAM size But it looks like omap2_set_globals_tap() still has to be called first! Isn't this wonderfully convoluted? We've already unravelled some of that with the init_early changes. Earlier having the IO space moving around between 2420/2430/3430 meant that we had to map some IO to detect the SoC. Now we have SoC specific initcalls where we assume the SoC category is initialized from board-*.c file (and from DT at some point). But the map_io method always has been tied to machine specific descriptors. That always implied a fixed SoC category, no? Unless you have a machine which can accommodate multiple different SOCs but that's very uncommon. Having the SRAM base address move around with different sizes also requires the SoC detection.. Otherwise we can end up mapping wrong size and end up trying to access secure SRAM that will hang the system. The way to fix it is to move SRAM init happen much later so we don't have to map it early. I guess now we could use ioremap for SRAM, although we may not want device attributes for the executable code? Got any suggestions here on how we should map SRAM later on? You can use a variant of ioremap() such as __arm_ioremap() which let you specify the memory attribute. So could someone in the OMAP camp fix this nonsense ASAP please? Of course, yesterday would be best. Heh. Were working on it. So far it's been moving things to get initialized later, separate sys_timer code from dmtimer driver features, initialize only the hwmods needed for sys_timer early, SoC specific initcalls to clear the SoC detection out of the early init path and so on. Wonderful! Furthermore... there is also a static mapping for physical address 0x4e00 using virtual address 0xff10 which is already reserved for other purposes i.e. the consistent DMA area. It is not immediately obvious where this comes from without being intimate with the OMAP code. Can this be fixed as well i.e. moved elsewhere please? This sounds like a bug somewhere. Which omap are you seeing this on? OMAP4430 on a Panda board. Here are the static mappings I'm seeing: phys = 0x4400 virt = 0xf800 size = 0x10 phys = 0x4a00 virt = 0xfc00 size = 0x40 phys = 0x5000 virt = 0xf900 size = 0x10 phys = 0x4c00 virt = 0xfd10 size = 0x10 phys = 0x4d00 virt = 0xfe10 size = 0x10 phys = 0x4e00 virt = 0xff10 size = 0x10 --- phys = 0x4800 virt = 0xfa00 size = 0x40 phys = 0x5400 virt = 0xfe80 size = 0x80 It is also possible that I might have screwed something up on my side. What is located at 0x4e00? Nicolas -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Please help with the OMAP static mapping mess
On Mon, 3 Oct 2011, Nicolas Pitre wrote: On Mon, 3 Oct 2011, Tony Lindgren wrote: * Nicolas Pitre n...@fluxnic.net [111003 11:26]: Furthermore... there is also a static mapping for physical address 0x4e00 using virtual address 0xff10 which is already reserved for other purposes i.e. the consistent DMA area. It is not immediately obvious where this comes from without being intimate with the OMAP code. Can this be fixed as well i.e. moved elsewhere please? This sounds like a bug somewhere. Which omap are you seeing this on? OMAP4430 on a Panda board. Here are the static mappings I'm seeing: phys = 0x4400 virt = 0xf800 size = 0x10 phys = 0x4a00 virt = 0xfc00 size = 0x40 phys = 0x5000 virt = 0xf900 size = 0x10 phys = 0x4c00 virt = 0xfd10 size = 0x10 phys = 0x4d00 virt = 0xfe10 size = 0x10 phys = 0x4e00 virt = 0xff10 size = 0x10 --- phys = 0x4800 virt = 0xfa00 size = 0x40 phys = 0x5400 virt = 0xfe80 size = 0x80 It looks like this comes from OMAP44XX_DMM_VIRT. #define OMAP44XX_DMM_PHYS OMAP44XX_DMM_BASE /* 0x4e00 -- 0xfd30 */ #define OMAP44XX_DMM_VIRT (OMAP44XX_DMM_PHYS + OMAP4_L3_PER_IO_OFFSET) #define OMAP44XX_DMM_SIZE SZ_1M The comment suggesting a mapping correspondance is obviously wrong. We have: #define OMAP44XX_DMM_BASE 0x4e00 #define OMAP4_L3_PER_IO_OFFSET 0xb110 Hence 0x4e00 + 0xb110 = 0xff10. Nicolas It is also possible that I might have screwed something up on my side. What is located at 0x4e00? Nicolas -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL v3] OMAP: clock/powerdomain/clockdomain/hwmod: fixes for 3.1-rc
On Thu, 8 Sep 2011, Arnd Bergmann wrote: On Tuesday 06 September 2011, Russell King - ARM Linux wrote: On Tue, Sep 06, 2011 at 04:29:14AM -0700, Tony Lindgren wrote: Arnd, Care to pull the following fixes to the -rc series from Paul? Tony, I don't think that will happen until master.kernel.org is back online as the tree was hosted on that machine. Right. I have a number of pull requests lined up. While I did consider starting a new tree on git.linaro.org to handle the time until then, I'm still hoping for hera to get back online at some point, and linux-next is equally disabled for now. I think that putting the tree on git.linaro.org would be a good thing to do as an intermediate measure. Nicolas -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: testing-board branch: rebase to RMK's devel-stable?
On Fri, 2 Sep 2011, Kevin Hilman wrote: Hi Tony, Your testing-board branch currently has a couple new boards that are missing the boot_params to atag_offset conversion (patch below.) There's a patch below to fix this, but maybe it's better to just rebase your testing-board branch onto Russell's devel-stable branch (where he's merged the seris from Nico) so any board stuff we add is sure to do it correctly. I would suggest that too. Nicolas -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: testing-board branch: rebase to RMK's devel-stable?
On Fri, 2 Sep 2011, Nicolas Pitre wrote: On Fri, 2 Sep 2011, Kevin Hilman wrote: Hi Tony, Your testing-board branch currently has a couple new boards that are missing the boot_params to atag_offset conversion (patch below.) There's a patch below to fix this, but maybe it's better to just rebase your testing-board branch onto Russell's devel-stable branch (where he's merged the seris from Nico) so any board stuff we add is sure to do it correctly. I would suggest that too. Better yet, if your bootloader does pass the address of the ATAG list via r2 already (contemporary u-Boot versions do) then the boot_params/atag_offset entry is redundant and can simply be dropped upfront. Nicolas -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: ehci: make HC see up-to-date qh/qtd descriptor ASAP
On Wed, 31 Aug 2011, Will Deacon wrote:
On Wed, Aug 31, 2011 at 02:43:33PM +0100, Mark Salter wrote:
On Wed, 2011-08-31 at 09:49 +0100, Will Deacon wrote:
On Wed, Aug 31, 2011 at 01:23:47AM +0100, Chen Peter-B29397 wrote:
One question: why this write buffer issue did not happen at UP ARM V7
platform, whose dma buffer
also uncache, but bufferable?
Which CPU was on this platform?
Using a 3.1.0-rc4+ kernel on a Pandaboard, and running 'hdparm -t' on a
usb disk drive, I see ~5.8MB/s read speed. Same kernel, but passing
nosmp on the commandline, I see 20.3MB/s.
Can someone explain why nosmp would make such a difference?
Oh gawd, that's horrible. I have a feeling it's probably a separate issue
though, caused by:
omap_modify_auxcoreboot0(0x200, 0xfdff);
in boot_secondary for OMAP. Unfortunately I have no idea what that line is
doing because it ends up talking to the secure monitor.
Well, this issue is apparently affecting other ARMv9 implementations
too. In which case this code in arch/arm/mm/mmu.c could be responsible:
if (is_smp()) {
/*
* Mark memory with the shared attribute
* for SMP systems
*/
user_pgprot |= L_PTE_SHARED;
kern_pgprot |= L_PTE_SHARED;
vecs_pgprot |= L_PTE_SHARED;
mem_types[MT_DEVICE_WC].prot_sect |= PMD_SECT_S;
mem_types[MT_DEVICE_WC].prot_pte |= L_PTE_SHARED;
mem_types[MT_DEVICE_CACHED].prot_sect |= PMD_SECT_S;
mem_types[MT_DEVICE_CACHED].prot_pte |= L_PTE_SHARED;
mem_types[MT_MEMORY].prot_sect |= PMD_SECT_S;
mem_types[MT_MEMORY].prot_pte |= L_PTE_SHARED;
mem_types[MT_MEMORY_NONCACHED].prot_sect |= PMD_SECT_S;
mem_types[MT_MEMORY_NONCACHED].prot_pte |= L_PTE_SHARED;
}
However I don't see the nosmp kernel argument having any effect on the
result from is_smp().
Nicolas
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 00/18] I2C: OMAP: I2C fixes, removal of cpu_is... from driver
On Wed, 15 Jun 2011, Ben Dooks wrote: On Wed, Jun 01, 2011 at 05:19:26PM -0700, Kevin Hilman wrote: Ben, Please pull in this series from Andy Green for the next merge window. v4 is simply a rebase of Andy's v3 against v3.0-rc1 with some basic sanity testing against with the latest kernel. These look much more like functionality changes than actual fixes, and are much more suited for inclusion into -next for once the next stable release is out. What do you mean, exactly? The merge window, as opposed to the -rc period, is good for functionality changes, no? Those patches have been out for quite a while, and they got quite extensive testing in the OMAP tree, and in the kernel included with the Linaro 11.05 release as well. Nicolas -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Fix generic irq chip
On Fri, 20 May 2011, Russell King - ARM Linux wrote: As a result of c42321c (genirq: Make generic irq chip depend on CONFIG_GENERIC_IRQ_CHIP), we now need those platforms using this in my tree to select this symbol. Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk -- Please send acks ASAP. Thanks to Mark for pointing this out with a patch for Samsung. Acked-by: Nicolas Pitre n...@fluxnic.net arch/arm/Kconfig |2 ++ arch/arm/plat-omap/Kconfig |1 + 2 files changed, 3 insertions(+), 0 deletions(-) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 44c16f0..9b63bab 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -854,6 +854,7 @@ config ARCH_DAVINCI select HAVE_IDE select CLKDEV_LOOKUP select GENERIC_ALLOCATOR + select GENERIC_IRQ_CHIP select ARCH_HAS_HOLES_MEMORYMODEL help Support for TI's DaVinci platform. @@ -1033,6 +1034,7 @@ config PLAT_IOP config PLAT_ORION bool + select GENERIC_IRQ_CHIP select HAVE_SCHED_CLOCK config PLAT_PXA diff --git a/arch/arm/plat-omap/Kconfig b/arch/arm/plat-omap/Kconfig index cd5f993..29b4c35 100644 --- a/arch/arm/plat-omap/Kconfig +++ b/arch/arm/plat-omap/Kconfig @@ -18,6 +18,7 @@ config ARCH_OMAP1 config ARCH_OMAP2PLUS bool TI OMAP2/3/4 select CLKDEV_LOOKUP + select GENERIC_IRQ_CHIP select OMAP_DM_TIMER help Systems based on OMAP2, OMAP3 or OMAP4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: Fix relocation if image end past uncompressed kernel end
On Wed, 27 Apr 2011, Tony Lindgren wrote: * Tony Lindgren t...@atomide.com [110427 05:44]: We can't overwrite the running code when relocating only a small amount, say 0x100 or so. There's no need to relocate all the way past the compressed kernel, we just need to relocate past the size of the code in head.o. Updated patch below using the GOT end instead of the compressed image end. Oops, the mov should be movle of course. Updated patch below. This is wrong. You're using r12 before it is fixed up with the proper offset. And this could simply be fixed with a big enough constant like this: diff --git a/arch/arm/boot/compressed/head.S b/arch/arm/boot/compressed/head.S index 8dab5e3..71fc1d9 100644 --- a/arch/arm/boot/compressed/head.S +++ b/arch/arm/boot/compressed/head.S @@ -250,8 +250,11 @@ restart: adr r0, LC0 * Because we always copy ahead, we need to do it from the end and go * backward in case the source and destination overlap. */ - /* Round up to next 256-byte boundary. */ - add r10, r10, #256 + /* +* Round to a 256-byte boundary on the next page. This +* avoids overwriting ourself if the offset is small. +*/ + add r10, r10, #4096 bic r10, r10, #255 sub r9, r6, r5 @ size to copy -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: Fix bad SP address after relocating kernel
On Tue, 26 Apr 2011, Tony Lindgren wrote:
Otherwise cache_clean_flush can overwrite some of the relocated
area depending on where the kernel image gets loaded. This fixes
booting on n900 after commit 6d7d0ae51574943bf571d269da3243257a2d15db
(ARM: 6750/1: improvements to compressed/head.S).
Gh. Indeed.
Thanks to Aaro Koskinen aaro.koski...@nokia.com for debugging
the address of the relocated area that gets corrupted, and to
Nicolas Pitre nicolas.pi...@linaro.org for the other uncompress
related fixes.
Signed-off-by: Tony Lindgren t...@atomide.com
I think there could be a better fix yet. Could you test this patch:
diff --git a/arch/arm/boot/compressed/head.S b/arch/arm/boot/compressed/head.S
index adf583c..8e3c54b 100644
--- a/arch/arm/boot/compressed/head.S
+++ b/arch/arm/boot/compressed/head.S
@@ -838,9 +838,11 @@ __armv3_mmu_cache_off:
* Clean and flush the cache to maintain consistency.
*
* On exit,
- * r1, r2, r3, r9, r10, r11, r12 corrupted
+ * r0, r1, r2, r3, r5, r9, r10, r11, r12, sp corrupted
* This routine must preserve:
* r4, r6, r7, r8
+ *
+ * Yes, sp is destroyed by this call in the armv7 hierarchical case.
*/
.align 5
cache_clean_flush:
@@ -888,7 +890,6 @@ __armv7_mmu_cache_flush:
b iflush
hierarchical:
mcr p15, 0, r10, c7, c10, 5 @ DMB
- stmfd sp!, {r0-r7, r9-r11}
mrc p15, 1, r0, c0, c0, 1 @ read clidr
andsr3, r0, #0x700 @ extract loc from clidr
mov r3, r3, lsr #23 @ left align loc bit field
@@ -905,31 +906,31 @@ loop1:
mrc p15, 1, r1, c0, c0, 0 @ read the new csidr
and r2, r1, #7 @ extract the length of the
cache lines
add r2, r2, #4 @ add 4 (line length offset)
- ldr r4, =0x3ff
- andsr4, r4, r1, lsr #3 @ find maximum number on the
way size
- clz r5, r4 @ find bit position of way size
increment
- ldr r7, =0x7fff
- andsr7, r7, r1, lsr #13 @ extract max number of the
index size
+ ldr r9, =0x3ff
+ andsr9, r9, r1, lsr #3 @ find maximum number on the
way size
+ clz r5, r9 @ find bit position of way size
increment
+ mov sp, r9
+ ldr r9, =0x7fff
+ andsr1, r9, r1, lsr #13 @ extract max number of the
index size
loop2:
- mov r9, r4 @ create working copy of max
way size
+ mov r9, sp @ create working copy of max
way size
loop3:
ARM( orr r11, r10, r9, lsl r5) @ factor way and cache number
into r11
- ARM( orr r11, r11, r7, lsl r2) @ factor index number into r11
- THUMB(lsl r6, r9, r5 )
- THUMB(orr r11, r10, r6) @ factor way and
cache number into r11
- THUMB(lsl r6, r7, r2 )
- THUMB(orr r11, r11, r6) @ factor index number
into r11
+ ARM( orr r11, r11, r1, lsl r2) @ factor index number into r11
+ THUMB(lsl r12, r9, r5 )
+ THUMB(orr r11, r10, r12 ) @ factor way and
cache number into r11
+ THUMB(lsl r12, r1, r2 )
+ THUMB(orr r11, r11, r12 ) @ factor index number
into r11
mcr p15, 0, r11, c7, c14, 2 @ clean invalidate by set/way
subsr9, r9, #1 @ decrement the way
bge loop3
- subsr7, r7, #1 @ decrement the index
+ subsr1, r1, #1 @ decrement the index
bge loop2
skip:
add r10, r10, #2@ increment cache number
cmp r3, r10
bgt loop1
finished:
- ldmfd sp!, {r0-r7, r9-r11}
mov r10, #0 @ swith back to cache level 0
mcr p15, 2, r10, c0, c0, 0 @ select current cache level in
cssr
iflush:
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: Fix relocation if image end past uncompressed kernel end
On Thu, 21 Apr 2011, Tony Lindgren wrote: * Nicolas Pitre nicolas.pi...@linaro.org [110421 20:20]: I found the bugger. The problem was a bad stack alignment. .. as this patch won't solve the n900 booting problem with zImage. With LZMA I'm still also getting LZMA data is corrupt. Hmmm.. Is it possible you have bad RAM? In compressed/head.S, locate this code: #ifdef CONFIG_AUTO_ZRELADDR @ determine final kernel image address mov r4, pc and r4, r4, #0xf800 add r4, r4, #TEXT_OFFSET #else ldr r4, =zreladdr #endif Right after that, simply override r4 with a physical address towards the end of the RAM, say 8MB before end of RAM (unless your decompressed kernel is larger than that). That won't make a booting system, but at least you will be able to test the decompressor when loaded at various locations in memory without involving the relocation loop. Nicolas -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: Fix relocation if image end past uncompressed kernel end
On Thu, 21 Apr 2011, Tony Lindgren wrote: Otherwise we end up overwriting ourselves. This fixes booting on n900 after commit 6d7d0ae51574943bf571d269da3243257a2d15db (ARM: 6750/1: improvements to compressed/head.S). Signed-off-by: Tony Lindgren t...@atomide.com I don't understand why this is needed. The copy loop is explicitly copying from the end going backward exactly to cope with this possibility. Hmmm... Nicolas -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: Fix relocation if image end past uncompressed kernel end
On Thu, 21 Apr 2011, Nicolas Pitre wrote: On Thu, 21 Apr 2011, Tony Lindgren wrote: Otherwise we end up overwriting ourselves. This fixes booting on n900 after commit 6d7d0ae51574943bf571d269da3243257a2d15db (ARM: 6750/1: improvements to compressed/head.S). Signed-off-by: Tony Lindgren t...@atomide.com I don't understand why this is needed. The copy loop is explicitly copying from the end going backward exactly to cope with this possibility. I think your patch is 1) unneeded (see the copy loop code and the comment before it), and 2) simply hiding the real bug. I just need to modify the code in compressed/misc.c slightly for the lzma decompressor to start or stop working randomly. It seems that this code might be sensitive to slight displacement in memory caused by modifications to totally unrelated code. I'm still trying to track this down. Nicolas -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: Fix relocation if image end past uncompressed kernel end
On Thu, 21 Apr 2011, Nicolas Pitre wrote:
On Thu, 21 Apr 2011, Nicolas Pitre wrote:
On Thu, 21 Apr 2011, Tony Lindgren wrote:
Otherwise we end up overwriting ourselves. This fixes booting
on n900 after commit 6d7d0ae51574943bf571d269da3243257a2d15db
(ARM: 6750/1: improvements to compressed/head.S).
Signed-off-by: Tony Lindgren t...@atomide.com
I don't understand why this is needed. The copy loop is explicitly
copying from the end going backward exactly to cope with this
possibility.
I think your patch is 1) unneeded (see the copy loop code and the
comment before it), and 2) simply hiding the real bug.
I just need to modify the code in compressed/misc.c slightly for the
lzma decompressor to start or stop working randomly. It seems that this
code might be sensitive to slight displacement in memory caused by
modifications to totally unrelated code. I'm still trying to track this
down.
I found the bugger. The problem was a bad stack alignment.
- 8
From: Nicolas Pitre nicolas.pi...@linaro.org
ARM: zImage: make sure the stack is 64-bit aligned
With ARMv5+ and EABI, the compiler expects a 64-bit aligned stack so
instructions like STRD and LDRD can be used. Without this, mysterious
boot failures were seen semi randomly with the LZMA decompressor.
While at it, let's align .bss as well.
Signed-off-by: Nicolas Pitre nicolas.pi...@linaro.org
diff --git a/arch/arm/boot/compressed/Makefile
b/arch/arm/boot/compressed/Makefile
index 58ac434..79b5c62 100644
--- a/arch/arm/boot/compressed/Makefile
+++ b/arch/arm/boot/compressed/Makefile
@@ -74,7 +74,7 @@ ZTEXTADDR := $(CONFIG_ZBOOT_ROM_TEXT)
ZBSSADDR := $(CONFIG_ZBOOT_ROM_BSS)
else
ZTEXTADDR := 0
-ZBSSADDR := ALIGN(4)
+ZBSSADDR := ALIGN(8)
endif
SEDFLAGS = s/TEXT_START/$(ZTEXTADDR)/;s/BSS_START/$(ZBSSADDR)/
diff --git a/arch/arm/boot/compressed/vmlinux.lds.in
b/arch/arm/boot/compressed/vmlinux.lds.in
index 5309909..ea80abe 100644
--- a/arch/arm/boot/compressed/vmlinux.lds.in
+++ b/arch/arm/boot/compressed/vmlinux.lds.in
@@ -54,6 +54,7 @@ SECTIONS
.bss : { *(.bss) }
_end = .;
+ . = ALIGN(8);/* the stack must be 64-bit aligned */
.stack : { *(.stack) }
.stab 0 : { *(.stab) }
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Code for v2.6.39 merge window frozen, patches archived
On Tue, 19 Apr 2011, Tony Lindgren wrote: Aaro and I speculated that boards using u-boot with uImage work, while n900 is using zImage and fails with the same kernel probably because of the different placement of compressed image in the memory. Could you try the following (by changing the argument to mkimage accordingly). Try to load the kernel at the following offsets: - 0x8000 from start of memory - 0x10 from start of memory - 0x300 from start of memory and tell me if any of those behaves differently? Nicolas -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Code for v2.6.39 merge window frozen, patches archived
On Wed, 13 Apr 2011, Tony Lindgren wrote: * Nicolas Pitre nicolas.pi...@linaro.org [110402 05:40]: On Thu, 31 Mar 2011, Aaro Koskinen wrote: Hi, On Wed, 30 Mar 2011, Kevin Hilman wrote: Tony Lindgren t...@atomide.com writes: FYI, looks like we've started hitting some booter -l kernel size limit in addition to booter -f size limit.. Now kernels built with omap2plus_defconfig won't boot on n900 any longer. I guess you are seeing it just hanging at Uncompressing Linux... done, booting the kernel.? I guess the way around that is to install the u-boot loader package. Alternatively CONFIG_KERNEL_LZMA=y will get the kernel zImage size back within size limits that will boot on n900. Hmm, I'm a bit puzzled. For me, .38 works but .39-rc1 does not, and I can't see any special limit exceeded. Also LZMA is broken: Uncompressing Linux... LZMA data is corrupt -- System halted I did some bisecting, and with the following commit reverted -rc1 works: commit d239b1dc093d551046a909920b5310c1d1e308c1 Author: Nicolas Pitre nicolas.pi...@linaro.org Date: Mon Feb 21 04:57:38 2011 +0100 ARM: 6746/1: remove the 4x expansion presumption while decompressing the kernel With the revert, also bigger gzipped kernel works. OK I will have a look. Hmm while playing with the device tree append patch, decompress_kernel trashes the first 16 bytes of the device tree data. Now I wonder if these issues are related.. Aaro, you mentioned to me that reverting commit 6d7d0ae51574943bf571d269da3243257a2d15db helps too? With the device tree append patch reverting commit d239b1dc093d551046a909920b5310c1d1e308c1 does not help, and reverting 6d7d0ae51574943bf571d269da3243257a2d15db requires some manual merging.. You cannot use the DT append patch without 6d7d0ae515 in place. The later is a prerequisite for the former. Anyways, that might be another way to reproduce the problem if these issues are related. I've started to instrument the problematic CONFIG_KERNEL_LZMA case. So far this is still a mystery. Do you have problems with the DT append patch even with CONFIG_KERNEL_GZIP=y? Nicolas -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] arm: Replace CONFIG_HAS_TLS_REG with HWCAP_TLS and check for it on V6
On Fri, 8 Apr 2011, Li Li wrote: Dears, I cannot understand how TLS EMU ensure it's SMP safe, because get_tls helper (at 0x0fe0) just read the value from 0x0ff0. But all SMP cores should have the exact same mapping to the vectors page (at 0x). So various threads running on different SMP cores at the same time would get the same emulated TLS value (instead of thread specific value set via set_tls). Could anybody explain this a little bit? On SMP the hardware TLS register is always available, therefore the TLS value is not stored at 0x0ff0. The code actually installed at 0x0fe0 is modified at boot time by kuser_get_tls_init to select either the ldr or the mrc instruction to retrieve the TLS value. Nicolas -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] omap changes for v2.6.39 merge window
On Mon, 4 Apr 2011, Benjamin Herrenschmidt wrote: On Fri, 2011-04-01 at 16:28 +0200, Detlef Vollmann wrote: * No board files Where do you put code that needs to run very early (e.g. pinging the watchdog)? Even on powerpc I keep board files :-) The main thing is: - The generic - board linkage must not be hard (ie, no platform_restart, but a board_ops.restart() etc) We have that on ARM already. See for example the struct machine_desc definition in arch/arm/include/asm/mach/arch.h. - An average board file is a few hundreds line long, that's it, mostly it hooks up to generically provided functions, tho it gets the choice of _which_ ones to hookup. Again that's largely the same situation on ARM. Taking Kirkwood for example (wc -l arch/arm/mach-kirkwood/*-setup.c) the average for board file tends to be more towards 200 lines though. Here DT could make a difference by moving the statically defined board resources elsewhere. - It can still quirk/fixup a thing or two if needed, I thinkt it's useful to keep that around, as long as such quirks remain small and few. At the end of the day, if dealing with one board special case gives you the choice between changing a ton of infrastructure/core to introduce a new abstraction to deal with -that- special case vs. having a one liner fixup in the platform code, the later is the most sensible option. The hard part of course is to have sensible maintainers to make sure this doesn't grow back to the old mess. Totally agreed. I think that's the core of the issue on ARM: we simply aren't factoring out the duplication aggressively enough in order to keep the board code to the absolute minimum. The fact that different SoCs are totally alien to each other never encouraged that. Nicolas -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] omap changes for v2.6.39 merge window
On Fri, 1 Apr 2011, Arnd Bergmann wrote: On Friday 01 April 2011, Detlef Vollmann wrote: On 04/01/11 16:59, Arnd Bergmann wrote: On Friday 01 April 2011, Detlef Vollmann wrote: On 04/01/11 15:54, Arnd Bergmann wrote: 9. All interesting work is going into a handful of platforms, all of which are ARMv7 based. Define interesting. The ones that are causing the churn that we're talking about. Platforms that have been working forever and only need to get the occasional bug fix are boring, i.e. not the problem. In the ARM tree I only know mach-at91. Atmel still introduces new SOCs based on ARM926EJ-S, and that makes perfect sense for lots of applications. I thought new ones were generally Cortex-M3 based. Either way, even if there are exceptions, focusing on ARMv7 at first should give a good representation of the new development. The actual CPU core doesn't matter at all. Whether it is ARM926EJ-S, XScale, PJ4 or Cortex-A8/A9, _that_ is the part that is extremely well maintained and abstracted already. The focus should instead be put on those platforms that are the most used irrespective of their cores. And by selecting the most used platforms, we have a greater chance to create community momentum, and good examples will be spread more quickly. 12. Supporting many different boards with a single kernel binary is a useful goal. Generally not for embedded systems (for me, a mobile PDA/phone is just a small computer with a crappy keyboard, but not an embedded system). True. For embedded, this would not be an important thing to do, but also not hurt. It costs you flash space. Well, the idea was not to force everyone to enable all options. When this is done right, the kernel would not be any bigger. With many SOCs each with their own peculiarities, the kernel would obviously grow bigger. But the major advantage of being _able_ to do that is not ultimately to have only one kernel with multi-board support even if in some context this has great value, but rather to enforce good code reuse and abstraction. Russell suggested that we enable CONFIG_ARM_PATCH_PHYS_VIRT by default. This is already one way to remove one of the most fundamental board specific piece of information that can be deduced at run time instead of having compile time constants per SOC. I however don't think it is practical to go off in a separate mach-nocrap space and do things in parallel. Taking OMAP as an example, there is already way too big of an infrastructure in place to simply rewrite it in parallel to new OMAP versions coming up. It would be more useful and scalable to simply sit down, look at the current mess, and identify common patterns that can be easily factored out into some shared library code, and all that would be left in the board or SOC specific files eventually is the data to register with that library code. Nothing so complicated as grand plans or planification that makes it look like a mountain. Two patterns were identified so far, and they are: 1) GPIO drivers As Linus observed, in the majority of the cases GPIOs are accessed through simple memory-mapped registers. Some have absolute state registers, the others have separate clear/set registers. Suffice to create two generic GPIO drivers each covering those two common cases, and those generic drivers would simply register with the higher level gpiolib code, and all the board code would have to do is to provide the data for those GPIOs (register offsets, number of GPIOs, etc.). Whether this data eventually comes from DT is an orthogonal issue. 2) IRQ chip drivers Again, as Thomas observed, the same issue exists with the majority of the IRQ chip drivers. Most of them follow a common simple pattern that can be abstracted in some generic library code due to their very similar mode of operation. Writing a common driver would leave the board specific code with only a data table describing hardware registers. A good example of such rationalization that already happened is the leds-gpio driver (./drivers/leds/leds-gpio.c), or similarly the gpio-keys driver (drivers/input/keyboard/gpio_keys.c). I remember when those board files were implementing their own simple drivers hooking directly to the input API or the LED API. After that let's take another identified common pattern and factorize it out from board code. That might be timers (see RMK's recent sched_clock() rationalization). That might be clocks (patches from Jeremy Kerr exist and need merged). Etc. Eventually we won't be able to find any more identifiable patterns which are factorisable, and what will be left in board files is only genuine SOC differences. And if all that is left is actually only data tables, then maybe such board files could go entirely and that data be passed via device tree, but that is still a long way off. I
Re: [GIT PULL] omap changes for v2.6.39 merge window
On Fri, 1 Apr 2011, Arnd Bergmann wrote: On Friday 01 April 2011, Will Deacon wrote: 1. The core arch code is not a problem (Russell does a great job here) 2. The platform specific code contains a lot of crap that doesn't belong there (not enough reviewers to push back on crap) 3. The amount of crap in platform specfic files is growing exponentially, despite the best efforts of a handful of people to clean it up. 4. Having one source file per board does not scale any more. 5. Discoverable hardware would solve this, but is not going to happen in practice. 6. Board firmware would not solve this and is usually not present. 7. Boot loaders can not be trusted to pass valid information 8. Device tree blobs can solve a lot of the problems, and nobody has come up with a better solution. Right, so this is directly related to point (5) because in essence FDT is a way to make undiscoverable hardware discoverable by probing the tree. The `it's just data' mantra sums it up nicely. Well, except that because of point 7, device trees are still inferior to having correct and complete information in hardware. I helped with the design of a rather simple patch for ARM allowing for: cat zImage foobar.dtb zImage_with_dtb Then the kernel is smart enough to detect it has a dtb on its tail and use it. In a perfect world the bootloader would be bug free and always up to date with the best DT data. In practice I'm very skeptical this will always be the case and painless. At least the above makes it very simple to have a self contained kernel when (not if) need be. 9. All interesting work is going into a handful of platforms, all of which are ARMv7 based. I think starting out ARMv7-only might make this more manageable but there are still shed loads of pre-v7 chips out there which we should try not to break. Yes, see below: the idea is to touch as little of the existing code as possible, at least in the first stages. I don't think this is a realistic approach. See my previous mail. Once you start identifying concrete and well defined areas that needs cleaning, it is best to come up with solutions that covers as much existing code as possible, validating that the solution is also worth it in the process. The more existing code you may cover with your cleanup, the more likely it will fit future hardware as well. Nicolas -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] omap changes for v2.6.39 merge window
On Sat, 2 Apr 2011, Arnd Bergmann wrote: On Friday 01 April 2011 21:54:47 Nicolas Pitre wrote: I however don't think it is practical to go off in a separate mach-nocrap space and do things in parallel. Taking OMAP as an example, there is already way too big of an infrastructure in place to simply rewrite it in parallel to new OMAP versions coming up. It would be more useful and scalable to simply sit down, look at the current mess, and identify common patterns that can be easily factored out into some shared library code, and all that would be left in the board or SOC specific files eventually is the data to register with that library code. Nothing so complicated as grand plans or planification that makes it look like a mountain. This is exactly the question it comes down to. So far, we have focused on cleaning up platforms bit by bit. Given sufficient resources, I'm sure this can work. You assume that continuing on this path is the fastest way to clean up the whole mess, while my suggestion is based on the assumption that we can do better by starting a small fork. I don't think any fork would gain any traction. That would only, heh, fork the work force into two suboptimal branches for quite a while, and given that we're talking about platform code, by the time the new branch is usable and useful the hardware will probably be obsolete. The only way this may work is for totally new platforms but we're not talking about a fork in that case. I think we can both agree that by equally distributing the workforce to both approaches, we'd be off worse than doing one of them right ;-) Absolutely. I think what is needed here is a bunch of people willing to work on such things, extracting those common patterns, and creating the infrastructure to cover them. Once that is in place then we will be in a position to push back on code submissions that don't use that infrastructure, and be on the lookout for new patterns to emerge. Just with the above I think there is sufficient work to keep us busy for a while. That is true, and I think we will need to do this. But as far as I can tell, the problems that you talk about addressing are a different class from the ones I was thinking of, because they only deal with areas that are already isolated drivers with an existing API. They are areas with the best return on the investment. This has the potential of making quite a bunch of code go away quickly. And the goal is indeed to keep platform code hooking into existing APIs under control, so that global maintenance tasks such as the one tglx did are less painful. Obscure board code that no one else care about because no other boards share the same hardware model, and which doesn't rely on common kernel infrastructure, is not really a problem even if it looks like crap because no one will have to touch it. And eventually the board will become unused and we'll just delete that code. The things that I see as harder to do are where we need to change the way that parts of the platform code interact with each other: * platform specific IOMMU interfaces that need to be migrated to common interfaces This can be done by actually forking the platform specific IOMMU code only, just for the time required to migrate drivers to the common interface. * duplicated but slightly different header files in include/mach/ Oh, actually that's part of the easy problems. This simply require time to progressively do the boring work. With CONFIG_ARM_PATCH_PHYS_VIRT turned on we can get rid of almost all instances of arch/arm/mach-*/include/mach/memory.h already. Getting rid of all instances of arch/arm/mach-*/include/mach/vmalloc.h can be trivially achieved by simply moving the VMALLOC_END values into the corresponding struct machine_desc instances. And so on for many other files. This is all necessary for the single-binary multi-SOC kernel work anyway. * static platform device definitions that get migrated to device tree definitions. That require some kind of compatibility layer to make the transition transparent to users. I think Grant had some good ideas for this. Changing these tree-wide feels like open-heart surgery, and we'd spend much time trying not to break stuff that could better be used to fix other stuff. Well, depends how you see it. Sure this might cause some occasional breakages, but normally those should be pretty obvious and easy to fix. And the more we can do that stuff, the better future code adhering to the new model will be. The example that I have in mind is the time when we had a powerpc and a ppc architecture in parallel, with ppc supporting a lot of hardware that powerpc did not, but all new development getting done on powerpc. This took years longer than we had expected at first, but I still think it was a helpful fork. On ARM, we are in a much better shape in the core code than what
Re: Code for v2.6.39 merge window frozen, patches archived
On Thu, 31 Mar 2011, Aaro Koskinen wrote: Hi, On Wed, 30 Mar 2011, Kevin Hilman wrote: Tony Lindgren t...@atomide.com writes: FYI, looks like we've started hitting some booter -l kernel size limit in addition to booter -f size limit.. Now kernels built with omap2plus_defconfig won't boot on n900 any longer. I guess you are seeing it just hanging at Uncompressing Linux... done, booting the kernel.? I guess the way around that is to install the u-boot loader package. Alternatively CONFIG_KERNEL_LZMA=y will get the kernel zImage size back within size limits that will boot on n900. Hmm, I'm a bit puzzled. For me, .38 works but .39-rc1 does not, and I can't see any special limit exceeded. Also LZMA is broken: Uncompressing Linux... LZMA data is corrupt -- System halted I did some bisecting, and with the following commit reverted -rc1 works: commit d239b1dc093d551046a909920b5310c1d1e308c1 Author: Nicolas Pitre nicolas.pi...@linaro.org Date: Mon Feb 21 04:57:38 2011 +0100 ARM: 6746/1: remove the 4x expansion presumption while decompressing the kernel With the revert, also bigger gzipped kernel works. OK I will have a look. Nicolas -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] omap changes for v2.6.39 merge window
On Wed, 30 Mar 2011, da...@lang.hm wrote: On Wed, 30 Mar 2011, Nicolas Pitre wrote: As long as SOC vendors keep producing wildly different architectures besides the core CPU we'll have this problem. Denying the reality won't make that problem go away either. And device tree won't stop those vendor from still trying to do things differently (better?) because they are not constrained by having to ensure this single proprietary software stack still boot. the thing that you are not convincing us of is that all these different SoCs are so wildly different architectures. You can have a look at the code. It is all there. And the different GPIO controllers are just the tip of the iceberg. But by all means if you actually find a way to abstract most differences between those SOCs then please say so. Many people tried already. Maybe they weren't smart enough. back in the early days of the PCs, different systems from different vendors had different bus types, peripherals at different addresses, etc. that didn't make all of those vendors systems different architectures, instead those things were varients of the x86 architecture. Most of them didn't survive. That really helps. with ARM you do have a couple different architectures (arm5 vs arm7 for example), That's the easy part. Well not necessarily that easy, but RMK did a damn good job of it and looking at the result you may think that was easy. but what you are hearing people say is that arm7+IPblock1+IPblock2 arm7+IPblock1+IPblock3 arm7+IPblock2+IPblock3 are not three different architectures, they are one architecture with different devices attached. what's more, you seem to be saying that arm7+IPblock1 and arm7+IPblock1 are different architectures if the wiring between the arm core and IPblock1 are different (they are different 'boards' or different chip models, possibly from different manufacturers) That's again the easy part. If that was all that simple we would be all happy campers. I see the variations here as a good thing, just like having a huge number of pluggable cards in a PC was a good thing (even though it made it hard to have an OS that supports every card out there) What we have here is more like a large number of PCs, each one with a different set of cards. The different SOCs are like PCs, and the cards are those set of peripherals to be found in those SOCs. But it is not just about peripherals, and system level things like timers and interrupt controllers. It is also about the huge complexity put into the hardware for power management. you will find different clocks/PLLs, power domains and regulators, and that has to be intermixed with various sleep states, wake sources and conditions, etc. And no ressemblance is to be found between different vendors for those pm features unfortunately. Even with a common high level abstraction (which abstraction is still being worked on) you will still need the backend code to interface with the hardware. Maybe someday the optimal (or even just good enough) power management hardware infrastructure will be found and everybody will standardize on that. But we're apparently not there yet. in the case of the PC, systems that were too different died off, systems that could have their differences abstracted into different drivers prospered. Maybe that will happen eventually. In the mean time they are rather all successful despite the major hardware discrepancies because the kernel is Open Source and it is relatively easy for each vendor to hack the kernel until it works on their own hardware. User space is largely unaffected so the kernel becomes the actual abstraction. I am _not_ saying that all arm systems need to standardize on one interrupt controller, I wish they had. I am saying that the kernel support for ARM needs to be able to _easily_ be told that this chip has interrupt chip type 24 connected this way, and interrupt chip type 87 connected that way, without needing to create a new architecture. But then we have the next SOC coming up with yet another IRQ controller built into it. So yet more code is required to deal with it. Amongst the 15 ARM vendors or so, no IRQ controller is the same. If the kernel is compiled with the appropriate drivers, it should even be able to be done without needing to recompile the kernel. Obviously. And that's not a problem. The problem is to actually support all the different hardware blocks. Hence the volume of code out there. If you do configure your kernel for one specific target which has a specific SOC implying a specific IRQ, timer, GPIO, clock, power, memory and peripheral bus, then you'll end up using relatively few lines of code from the arch/arm/ directory. If instead you want support for a SOC from another vendor, then you'll need a different set of source code similar to the differences between an ARM SOC and a MIPS SOC. Now I
Re: [GIT PULL] omap changes for v2.6.39 merge window
On Thu, 31 Mar 2011, Geert Uytterhoeven wrote: On Thu, Mar 31, 2011 at 01:31, Nicolas Pitre n...@fluxnic.net wrote: On ARM there is simply not such thing as a single machine design to clone, and a closed source test bench to design for. There are other architectures that didn't start from a single root platform, but still support multi-platform kernels. Sure, so does ARM with some restrictions. Nicolas -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] omap changes for v2.6.39 merge window
On Thu, 31 Mar 2011, da...@lang.hm wrote: I think that part of the issue is that when Linus points out a problem, the response isn't we agree and are working on it, here's what we are doing, instead it seems to be mostly there is no problem, this is just because there is so much variation in ARM The problem is two-fold: 1) - ARM hardware manufacturers are morons... - ARM vendors do things differently just to be difficult... - the crazy arm fragmentation... Translate this into whatever ways you like. The fact is that ARM is quite popular as a CPU core but there is very little in terms of standardization around that CPU core. *OBVIOUSLY* this is a problem. But there is _nothing_ we can do about that besides the current moaning and the hope that those vendors will hear us and stop trying to be different from their competitors. Apparently that won't happen in the near future, so we can either sit on our arses proclaiming repeatedly that this is a problem until those hardware vendors put their acts together, or we find ways to deal with it somehow. 2) Because of (1) we do end up being floded by SOC specific support code with an unprecedented scale. Here's the stat: $ git diff --shortstat v2.6.38..v2.6.39-rc1 arch/arm/ 1319 files changed, 61303 insertions(+), 33780 deletions(-) $ git diff --shortstat v2.6.38..v2.6.39-rc1 arch/x86/ 241 files changed, 6508 insertions(+), 4326 deletions(-) That's ten (10) times more lines added in the ARM directory than in the X86 directory. Is this a sudden burst or a tendency? $ git diff --shortstat v2.6.37..v2.6.38 arch/arm/ 1257 files changed, 72412 insertions(+), 29361 deletions(-) $ git diff --shortstat v2.6.37..v2.6.38 arch/x86/ 216 files changed, 10021 insertions(+), 5016 deletions(-) $ git diff --shortstat v2.6.36..v2.6.37 arch/arm/ 1314 files changed, 55072 insertions(+), 17620 deletions(-) $ git diff --shortstat v2.6.36..v2.6.37 arch/x86/ 299 files changed, 16130 insertions(+), 12800 deletions(-) $ git diff --shortstat v2.6.35..v2.6.36 arch/arm 1041 files changed, 53428 insertions(+), 25722 deletions(-) $ git diff --shortstat v2.6.35..v2.6.36 arch/x86/ 231 files changed, 7216 insertions(+), 8028 deletions(-) So that appears to be quite normal to see ARM vendors together producing many times the level of activities compared to X86. So... Is there missed opportunity for better code reuse here? Most probably. Is all that code the result of misabstracted and duplicated code? Certainly not. Let's just presume that half of that code is genuine crap and the other half is simply the result of new hardware for which there is no existing model to fit it in. Even then, do we have 5 times the reviewer bandwidth to properly review all that code compared to X86? Absolutely not, not even close. If prominent people looking at this from the side line continue bashing at those who are both feet in the mud trying to contain the flood rather than actually helping then nothing will change. Instead this only creates despair and the splashed people may simply decide to throw in the towel, at which point things will collapse for real. In reality, the system has been going as it is for quite a while and with more or less the same level of intensity. And the fact is that _users_ of the ARM kernel are not complaining. Things are far from being perfect, but so far things have been good enough for the majority of the people involved, and improvements are constantly being worked on with the men power available. Nicolas -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] omap changes for v2.6.39 merge window
On Thu, 31 Mar 2011, Thomas Gleixner wrote: Start off with such a trivial, but immense effective cleanup and see what it helps to share code even accross SoC vendors. They all glue together random IP blocks from the market and there are not soo many sources which are relevant. This makes sense in all aspects: 1) less and better code 2) faster setup for new SoCs 3) shared benefit for all vendors If this was always true. Someone commented on the fact that the IP block providing USB on OMAP is shared with a couple other platforms. But about 2600 lines of pure glue is still necessary around the common driver to make it work for everyone. I'm not saying that separate drivers are called for here, simply that hardware people _will_ screw it up, especially when they are hooking it up to a non-standard SOC-specific bus. Another example: there used to be many different IP blocks providing MMC/SD/SDIO support that people were adding to their SOCs. Each SOC would have its own reinvention of the wheel but they were all different but simple wheels, and drivers for them were obvious and straight forward. Then came the SDHCI standard. At first few implementation existed so the sdhci driver was, too, rather straight forward. But hardware manufacturers thought (rightfully) that this would be a good idea to use that standard instead of using their custom simple wheel. And so they did, releasing new SOC revision with the old wheel replaced by a square implementation of the sdhci one. Today the sdhci driver is literally bastardized by all the quirks needed to work around all the different and creative bugs or even standard misinterpretation of the standard out there in the field. And in many cases the sdhci version is even _less_ functional than the custom and already supported implementation it replaced. And what would the hardware guys tell you? That software is cheap. Nicolas -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] omap changes for v2.6.39 merge window
On Thu, 31 Mar 2011, Linus Torvalds wrote: What I'm _not_ seeing is a lot of cross-platform maintenance or sense of people trying to reign things in and look for solutions to the proliferation of random stupid and mindless platform code. I do that, Russell does that, Catalin does that, Tony does that, and maybe less than a handful of other important people I'm not listing (sorry). But clearly we are far far from being enough people doing that kind of work. And the fact is that the volume of ARM platform code is steadily being produced at a rate far surpassing X86, and even higher than all the other architectures put together. Linaro is trying to help here, but Linaro cannot conjure the needed experience and knowledge for that kind of work with a magic wand. So we need help! If core kernel people could get off their X86 stool and get down in the ARM mud to help sort out this mess that would be really nice (thanks tglx). Until then all that the few of us can do is to contain the flood and hope for the best, and so far things being as they are have still worked surprisingly well in practice for users. If compensation is a concern then I think Linaro might be able to arrange something. And we can't count on vendor people doing this work. They are all busy porting the kernel to their next SOC version so they can win the next big Android hardware design, and doing so with our kernel quality standards is already quite a struggle for them. What is going on at the moment is some effort to introduce DT support to ARM. The core support is there, but that is useless until platform code is moved to it, and corresponding work is put into bootloaders, etc. That is progressing... slowly. Also there is some work to be able to build a kernel supporting more than one SOC family at once. Of course there is no practical use for a single kernel binary that boots on all existing boards, but moving towards such a goal has beneficial side effects such as good consolidation when possible. But we also need some slack wrt number of lines changed. An increased consolidation effort will create more churn not less, at least for a while. The OMAP clock merge conflict was the result of some cleanup which will make further consolidation easier. Nicolas -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] omap changes for v2.6.39 merge window
On Thu, 31 Mar 2011, Linus Torvalds wrote: On Thu, Mar 31, 2011 at 12:25 PM, Nicolas Pitre n...@fluxnic.net wrote: So we need help! If core kernel people could get off their X86 stool and get down in the ARM mud to help sort out this mess that would be really nice (thanks tglx). Until then all that the few of us can do is to contain the flood and hope for the best, and so far things being as they are have still worked surprisingly well in practice for users. If compensation is a concern then I think Linaro might be able to arrange something. The thing is, maintainers don't scale. True. My remark about core kernel people still stands though. The only way to get quality code is to try to improve the quality from the leaf nodes, because otherwise you'll always end up playing catch-up. You'll get new bad code faster than you can clean it up. Leaf nodes on ARM are people coming from corporate background with the old school software development methodologies. They do it as a _job_ first and foremost. They only work on Linux because that's what their boss assigned them to. Don't get me wrong: that doesn't mean they are bad people. Simply that they are not into it for the public recognition (or flaming) from their peers. Once their code works they lose interest and move on. That mindset is extremely hard to change and take time, on a scale of years. Much more time than required to produce the code needed to support that new SOC out of the pipeline. There are notable exceptions obviously. But this is still a scalability problem in itself. So we need men-in-the-middle attacks. I've told people this before, and I'll tell it again: when I flame submaintainers, they should try to push the pain down. I'm not really asking those submaintainers to clean up all the stuff they are getting: I'm basically asking people to say no, or at least push back a lot, and argue with the people who send you code. Tell them what you don't like about the code, and tell them that you can't take it any more. I wish we could be sufficient people to be able to determine what we actually don't like about the code. There is simply not enough core kernel people with the required visibility doing such work in ARM land. That's the fundamental problem. The fact that the most successful real ARM devices running Linux out there still aren't supported in mainline doesn't help building a community of enthusiasts around it either. And we can't count on vendor people doing this work. They are all busy porting the kernel to their next SOC version so they can win the next big Android hardware design, and doing so with our kernel quality standards is already quite a struggle for them. This really isn't the argument. The argument should be that if they want their code up-stream, they need to do a good job. If they don't, why should you take it at all? Embedded vendors did keep their code out of the kernel before. We've been hammering them about upstreaming their code for years. Now they are striking back with too much code for our review capacity. So problematic code gets merged without anyone noticing because it compiles and does work, until someone comes along with a wide scale API cleanup and stumble on it. The alternative is to only accept fully reviewed code, but to scale with the numbers we've all seen, 60% of the reviewers should be looking at ARM code and that's not happening. We've been there before, like two years ago or so. Pressure builds up at the maintainer gate as the backlog grows and key people get burned out, then the system collapses. No one wants to go back there. What is going on at the moment is some effort to introduce DT support to ARM. The core support is there, but that is useless until platform code is moved to it, and corresponding work is put into bootloaders, etc. That is progressing... slowly. How about not moving platform code TO it, but at least saying that you won't accept new platform code that doesn't use it? When somebody sends you a new platform, just say no if it's another copy-paste job or another add yet another #ifdef or conditional to a messy driver. DT has to prove itself on ARM with a few existing platforms before we can open the flood gate towards it. If something is wrong with DT support it is best to fix only the core stuff without also having to fix all users and possibly all bootloaders, etc. That work is progressing slowly because there are more people praising DT than people doing the actual work. Nicolas
Re: [GIT PULL] omap changes for v2.6.39 merge window
On Wed, 30 Mar 2011, Linus Torvalds wrote: ARM right now i a nightmare, and most of it is because ARM hardware manufacturers are morons. If in your mind competitors == morons then you might be right. But the way the ARM tree is then laid out has made that even more painful, and the decision to put all the crazy board details in the kernel tables instead of trying to have a per-board boot loader that fills in the details is just crazy. I beg to disagree. Trying to rely on bootloaders doing things right is like saying that x86 should always rely on the BIOS doing things right. We have this chance in the OMAP case to have a manufacturer who is smart enough to document all those things so that the kernel can be autonomous and more reliable, and the BIOS joke avoided entirely. When something needs fixing it is much easier to update the kernel ourselves than waiting after any bootloader updates which are themselves much more risky to perform. Granted, things could be structured in a better way so to minimize the risk of conflicts when clocks for unrelated drivers are updated at the same time. Something like initcall tables or the like. Look at the dirstat for arch/ in just the current merge window (cut-off at 5% just to not get too much): [torvalds@i5 linux]$ git diff -C --dirstat=5 --cumulative v2.6.38.. arch 14.0% arch/arm/mach-omap2/ 5.8% arch/arm/plat-mxc/include/mach/ 6.3% arch/arm/plat-mxc/ 57.1% arch/arm/ 5.4% arch/m68k/ 9.6% arch/unicore32/ 6.9% arch/x86/ 100.0% arch/ almost *SIXTY* percent of all arch updates were to ARM code. Absolutely not! You have 14% going to OMAP code which happens to be under arch/arm/ but there is nothing ARM specific in there. If OMAP was using a PPC or a MIPS core then you'd have the same result except under arch/powerpc or arch/mips. There is very little in terms of ARM specific peculiarities under arch/arm/mach-omap2/ in fact. And it happens that, after all the beating we've made on those embedded (ARM) SOC manufacturers, trying to push the point home that it is far better for everyone to have support merged in the mainline kernel instead of keeping their patches piled up into an obsolete kernel version, it happens that the OMAP folks are the top champions when it's time to upstream their code. Are we going to complain to them now that they're doing exactly what the upstream kernel community people have been asking of them for so many years? And that's despite the fact that one of those architectures (unicore32) is a totally new architecture, and despite m68k having gone through a first-level unification of nommu and mmu code! So what? That only shows that those architectures are not being used as much as ARM is. This is probably just a reflect of actual market share. And was this just a fluke? No. Doing the same for 2.3.37..38 gives 58.3% for arch/arm (and in that release we had a blackfin unification effort, otherwise arm would have been an even bigger percentage). And don't be surprised if the dirstat result for arch/arm/ goes up even further in the near future. Other SOC manufacturers which happen to have chosen an ARM core for their CPU are also coming out of their moronic stupor and waking up to speed with this Open Source thing. If they were choosing a MIPS core this could rebalance the dirstat, but they happen to also have an ARM core with a _completely_ different architecture around it since that's what they compete over. If ARM Ltd was to dictate everything composing the ARM architecture like what happened on X86 then you'd end up with a much lower level of competition and innovation. If that means doing someting similar to git mv arch/arm/mach-omap2 arch/omap2 for the dirstat to be more meaningful then let's do it. But I think that a different interpretation of the one you did would be more appropriate here. That's ridiculous. It's entirely due to the whole f*cked-up arm ecosystem. Well, let's face it, ARM is at the moment highly successful. And yes it might be destabilizing as ARM might be surpassing the X86 kernel development rate while X86 always used to be the ultimate reference. But calling the whole ecosystem f*cked-up because we have issue scaling to it properly is a rather cheap argument. Something needs to be done. A small part is to make sure the source code is more hierarchical, so that we don't have those crazy shared data-files that are ugly as hell and get conflicts because different boards all think they need to care. Absolutely! But the larger problem is that somebody really REALLY needs to think about how to get those crazy board details out of the kernel entirely. Having per-board drivers for real hardware is sane - having to have per-board detail files for clock chips is just crazy. Split off that thing a Linux ARM second-stage bootloader project that has the per-board tables or something. Don't pollute the main
Re: [GIT PULL] omap changes for v2.6.39 merge window
On Wed, 30 Mar 2011, Linus Torvalds wrote: On Wed, Mar 30, 2011 at 1:41 PM, Nicolas Pitre n...@fluxnic.net wrote: If in your mind competitors == morons then you might be right. There's a difference between competition and do things differently just to be difficult. Absolutely. We've seen that from some proprietary software companies. Trying to rely on bootloaders doing things right is like saying that x86 should always rely on the BIOS doing things right. No. Not at all. The problem with firmware/BIOS is that it's set in stone and closed-source. I'm suggesting splitting out the crazy part into a separate project that does this. Open-source. Like a mini-kernel. Because the thing is, the main kernel doesn't care, and _shouldn't_ care. Those board files are just noise. Sure, but important noise nevertheless. As long as the noise is confined to a limited set of .c files I'm happy. OTOH I have very little hope for a separate project that would only deal with that noise. That will simply never fly, even less so as an Open Source project. The insentive for people to work on such thing simply aren't there as that is totally uninteresting and without any rewards. Furthermore, this does create pain. you have to make things in sync between the kernel and the mini-kernel (let's call it bootloader). In practice the bootloader is always maintained separately from the kernel, on its own pace and with its own release schedule. Trying to synchronize independent projects is really painful as you know already, otherwise the user space for perf would still be maintained separately from the kernel, right? Now, when there is a bug in one of the clock settings, or one clock is missing for that new kernel driver to work properly, the bootloader would have to be fixed, revalidated, and the fix deployed separately but still in addition to the kernel. This process still adds to the pain such that what people do in those cases is simply to hack the driver code in the kernel. Instead, the OMAP folks created a table to abstract them into something more manageable. And here's the final catch. Most of those clocks are often derived from each other in a tree structure inside the SOC. And for power saving reasons, some crazy people want to dynamically change the config for those clocks at run time according to the required frequency for given loads, turn them off when possible, and of course turn the parent clock off as well if all the children clocks are themselves turned off. So the kernel has NO CHOICE but to be fully aware of them. Then comes power domains with the cascade of regulators and so forth, again all software controlled. Add to the mix the different sleep states that can be derived from that, which is far more sophisticated than ACPI states on Intel. And in some cases, the hardware capabilities are there but people still didn't find the optimal way to drive them, so research is still on-going software wise. And obviously those SOC vendors do compete on that front since power consumption is the killing weapon these days. No wonder why they are so different from each other with all that board crap. The long-term situation should be that you should be able to have ONE binary kernel just work. That's where we are on x86. Really. But X86 is peanuts. Really. There was one machine called the IBM PC at some point that everybody cloned, and the rest was totally irrelevant. Then came that thing called Windows that reinforced this hardware monoculture as it was used for the ultimate conformance testing. This is damn easy in that case to produce a kernel that works virtually everywhere. On ARM there is simply not such thing as a single machine design to clone, and a closed source test bench to design for. And this is orthogonal to this discussion anyway, as having in-kernel clock tables is not incompatible with a single kernel binary. Dropping at runtime those clock tables that are irrelevant to the currently running hardware is not rocket science. Without that kind of long-term view, where do you think ARM is going to be in five years? ARM is going to still be relevant simply because they now have Linux that they can modify to suit their latest changes. That's one thing with Open Source which can be good or bad: full hardware compatibility is no longer an issue since the software can be adapted at will. Still... there are on-going efforts to consolidate things amongst all the ARM vendors. The ARM architecture is standardizing more and more stuff in the whole stack in every revision. But they won't standardize everything otherwise they'll kill that competing ecosystem. almost *SIXTY* percent of all arch updates were to ARM code. Absolutely not! You have 14% going to OMAP code which happens to be under arch/arm/ but there is nothing ARM specific in there. If OMAP was using a PPC or a MIPS core then you'd have
