Hi Linus,
On Mon, Jun 15, 2020 at 11:11:04AM +0200, Linus Walleij wrote:
> OK I would be very happy to look at it so I can learn a bit about the
> hands-on and general approach here. Just send it to this address
> directly and I will look!
Have sent it
> > For the next 3 weeks, right now, i can
Hi,
On Sun, Jun 14, 2020 at 06:51:43PM +0530, afzal mohammed wrote:
> It is MB/s for copying one file to another via user space buffer, i.e.
> the value coreutils 'dd' shows w/ status=progress (here it was busybox
> 'dd', so instead it was enabling a compile time
Hi,
On Sat, Jun 13, 2020 at 10:45:33PM +0200, Arnd Bergmann wrote:
> 4% boot time increase sounds like a lot, especially if that is only for
> copy_from_user/copy_to_user. In the end it really depends on how well
> get_user()/put_user() and small copies can be optimized in the end.
i mentioned t
Hi,
On Sat, Jun 13, 2020 at 02:15:52PM +0100, Russell King - ARM Linux admin wrote:
> On Sat, Jun 13, 2020 at 05:34:32PM +0530, afzal mohammed wrote:
> > i think C
> > library cuts any size read, write to page size (if it exceeds) &
> > invokes the system call.
> Yo
Hi,
On Sat, Jun 13, 2020 at 01:56:15PM +0100, Al Viro wrote:
> Incidentally, what about get_user()/put_user()? _That_ is where it's
> going to really hurt...
All other uaccess routines are also planned to be added, posting only
copy_{from,to}_user() was to get early feedback (mentioned in the
c
Hi,
On Sat, Jun 13, 2020 at 02:08:11PM +0300, Andy Shevchenko wrote:
> On Fri, Jun 12, 2020 at 1:20 PM afzal mohammed
> wrote:
> > +// Started from arch/um/kernel/skas/uaccess.c
>
> Does it mean you will deduplicate it there?
What i meant was, that file was taken as a templ
Hi,
On Fri, Jun 12, 2020 at 10:07:28PM +0200, Arnd Bergmann wrote:
> I think a lot
> of usercopy calls are only for a few bytes, though this is of course
> highly workload dependent and you might only care about the large
> ones.
Observation is that max. pages reaching copy_{from,to}_user() is 2
Hi,
On Fri, Jun 12, 2020 at 09:31:12PM +0530, afzal mohammed wrote:
> 512 1K 4K 16K 32K 64K 1M
>
> normal 30 46 89 95 90 85 65
>
> uaccess_w_memcpy 28.545 85 92 91 85 65
Hi,
On Fri, Jun 12, 2020 at 11:19:23AM -0400, Nicolas Pitre wrote:
> On Fri, 12 Jun 2020, afzal mohammed wrote:
> > Performance wise, results are not encouraging, 'dd' on tmpfs results,
> Could you compare with CONFIG_UACCESS_WITH_MEMCPY as well?
512
Hi,
On Fri, Jun 12, 2020 at 02:02:13PM +0200, Arnd Bergmann wrote:
> On Fri, Jun 12, 2020 at 12:18 PM afzal mohammed
> wrote:
> > Roughly a one-third drop in performance. Disabling highmem improves
> > performance only slightly.
> There are probably some things that can b
Hi,
On Wed, Jun 10, 2020 at 12:10:21PM +0200, Linus Walleij wrote:
> On Mon, Jun 8, 2020 at 1:09 PM afzal mohammed wrote:
> > Not yet. Yes, i will do the performance evaluation.
> >
> > i am also worried about the impact on performance as these
> > [ get_user_page
Select UACCESS_GUP_KMAP_MEMCPY initially.
Signed-off-by: afzal mohammed
---
arch/arm/Kconfig | 9 +
1 file changed, 9 insertions(+)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index c77c93c485a08..ae2687679d7c8 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1326,6
merged in
mainline.
[1]
https://lore.kernel.org/lkml/Pine.LNX.4.44.0307082332450.17252-10@localhost.localdomain/
Signed-off-by: afzal mohammed
---
lib/Kconfig | 4 +
lib/Makefile | 3 +
lib/uaccess_gup_kmap_memcpy.c | 162 ++
Turn off existing raw_copy_{from,to}_user() using
arm_copy_{from,to}_user() when CONFIG_UACCESS_GUP_KMAP_MEMCPY is
enabled.
Signed-off-by: afzal mohammed
---
arch/arm/include/asm/uaccess.h | 20
arch/arm/kernel/armksyms.c | 2 ++
arch/arm/lib/Makefile | 7
t for testing first patch.
Regards
afzal
afzal mohammed (3):
lib: copy_{from,to}_user using gup & kmap_atomic()
ARM: uaccess: let UACCESS_GUP_KMAP_MEMCPY enabling
ARM: provide CONFIG_VMSPLIT_4G_DEV for development
arch/arm/Kconfig | 9 ++
arch/arm/include/asm/uaccess.h
Hi,
On Mon, Jun 08, 2020 at 08:47:27PM +0530, afzal mohammed wrote:
> On Mon, Jun 08, 2020 at 04:43:57PM +0200, Arnd Bergmann wrote:
> > There is another difference: get_user_pages_fast() does not return
> > a vm_area_struct pointer, which is where you would check the access
>
Hi,
On Mon, Jun 08, 2020 at 04:43:57PM +0200, Arnd Bergmann wrote:
> There is another difference: get_user_pages_fast() does not return
> a vm_area_struct pointer, which is where you would check the access
> permissions. I suppose those pointers could not be returned to callers
> that don't alre
Hi,
On Sun, Jun 07, 2020 at 09:26:26PM +0200, Arnd Bergmann wrote:
> I think you have to use get_user_pages() though instead of
> get_user_pages_fast(),
> in order to be able to check the permission bits to prevent doing a
> copy_to_user()
> into read-only mappings.
i was not aware of this, is i
Hi,
[ my previous mail did not make into linux-arm-kernel mailing list,
got a mail saying it has a suspicious header and that it is waiting
moderator approval ]
On Sun, Jun 07, 2020 at 05:11:16PM +0100, Russell King - ARM Linux admin wrote:
> On Sun, Jun 07, 2020 at 06:29:32PM +0530, af
Hi,
On Sat, May 16, 2020 at 09:35:57AM +0200, Arnd Bergmann wrote:
> On Sat, May 16, 2020 at 8:06 AM afzal mohammed
> wrote:
> > Okay, so the conclusion i take is,
> > 1. VMSPLIT 4G/4G have to live alongside highmem
> > 2. For user space copy, do pinning followed
Hi,
On Thu, May 14, 2020 at 05:32:41PM +0200, Arnd Bergmann wrote:
> Typical distros currently offer two kernels, with and without LPAE,
> and they probably don't want to add a third one for LPAE with
> either highmem or vmsplit-4g-4g. Having extra user address
> space and more lowmem is both goi
Hi,
On Thu, May 14, 2020 at 07:05:45PM +0530, afzal mohammed wrote:
> So if we make VMSPLIT_4G_4G, depends on !HIGH_MEMORY (w/ mention of
> caveat in Kconfig help that this is meant for platforms w/ <=4GB), then
> we can do copy_{from,to}_user the same way currently do, and no need
Hi,
On Thu, May 14, 2020 at 02:41:11PM +0200, Arnd Bergmann wrote:
> On Thu, May 14, 2020 at 1:18 PM afzal mohammed
> wrote:
> > 1. SoC w/ LPAE
> > 2. TTBR1 (top 256MB) for static kernel, modules, io mappings, vmalloc,
> > kmap, fixmap & vectors
> R
Hi,
On Tue, May 12, 2020 at 09:49:59PM +0200, Arnd Bergmann wrote:
> Any idea which bit you want to try next?
My plan has been to next post patches for the static kernel migration
to vmalloc space (currently the code is rigid, taking easy route
wherever possible & not of high quality) as that fe
Hi,
On Mon, May 11, 2020 at 05:29:29PM +0200, Arnd Bergmann wrote:
> What do you currently do with the module address space?
In the current setup, module address space was untouched, i.e. virtual
address difference b/n text & module space is far greater than 32MB, at
least > (2+768+16)MB and mod
Hi,
Kernel now boots to prompt w/ static kernel mapping moved to vmalloc
space.
Changes currently done have a couple of platform specific things, this
has to be modified to make it multiplatform friendly (also to be taken
care is ARM_PATCH_PHYS_VIRT case). Module address space has to be
taken car
place setup_irq() by request_irq()")
> Signed-off-by: Arnd Bergmann
Sorry for the mistake and thanks for the fix,
Acked-by: afzal mohammed
Regards
afzal
[ +linux-arm-kernel
Context: This is regarding VMSPLIT_4G_4G support for 32-bit ARM as a
possible replacement to highmem. For that, initially, it is being
attempted to move static kernel mapping from lowmem to vmalloc space.
in next reply, i will remove everyone/list !ARM related ]
Hi,
Hi Arnd,
> On Tue, Apr 14, 2020 at 09:29:46PM +0200, Arnd Bergmann wrote:
> > Another thing to try early is to move the vmlinux virtual address
> > from the linear mapping into vmalloc space. This does not require
> > LPAE either, but it only works on relatively modern platforms that
> > don't ha
Hi Maxime,
On Sun, Mar 18, 2018 at 09:22:51PM +0100, Maxime Ripard wrote:
> The first part is supposed to be the name of the boards. I did sed
> s/leds/teres-i/, and applied, together with all the patches but the
> PWM (so I had to drop the backlight node as well).
>
> Please coordinate with Andr
Hi,
On Fri, Mar 16, 2018 at 12:07:53PM +0530, afzal mohammed wrote:
> Received only patch 4 & 5 in my inbox, receive path was via
> linux-kernel rather than linux-arm-kernel, but in both archives all
> patches are seen (though threading seems not right), probably missing
> pa
the series from patchwork, for the series,
Tested-by: afzal mohammed
afzal
Hi,
On Thu, Mar 15, 2018 at 10:36:06PM +0530, afzal mohammed wrote:
> Thanks for the patches
>
> w/ defconfig could reach to prompt via serial console using audio
> jack.
>
> And just by enabling PWM_SUN4I & FB_SIMPLE, laptop could function
> standalone as well.
>
Hi,
On Thu, Mar 15, 2018 at 10:56:48AM +0100, Arnd Bergmann wrote:
> On Thu, Mar 15, 2018 at 10:42 AM, David Howells wrote:
> > Do we have anything left that still implements NOMMU?
Please don't kill !MMU.
> Yes, plenty.
> I've made an overview of the remaining architectures for my own refere
Hi,
On Mon, Mar 12, 2018 at 04:10:45PM +, Harald Geyer wrote:
> This series adds support for the TERES I open hardware laptop produced
> by olimex. With these patches and a bootloader capable of setting up
> simple framebuffer the laptop is quite useable.
Thanks for the patches
w/ defconfig
Hi,
On Sun, Feb 11, 2018 at 11:19:10AM -0800, tip-bot for David Woodhouse wrote:
> x86/speculation: Use IBRS if available before calling into firmware
>
> Retpoline means the kernel is safe because it has no indirect branches.
> But firmware isn't, so use IBRS for firmware calls if it's availabl
Hi,
On Thu, Jan 04, 2018 at 11:27:55AM +0100, Markus Heiser wrote:
> IMO symlinks are mostly ending in a mess, URLs are never stable.
> There is a
>
> https://www.kernel.org/doc/html/latest/objects.inv
>
> to handle such requirements. Take a look at *intersphinx* :
>
> http://www.sphinx-doc
Hi,
On Thu, Jan 04, 2018 at 09:48:50AM +0800, Boqun Feng wrote:
> > The location chosen is "Documentation/kernel-hacking", i was unsure
> > where this should reside & there was no .rst file in top-level directory
> > "Documentation", so put it into one of the existing folder that seemed
> > to me
Hi,
On Thu, Jan 04, 2018 at 12:48:28AM +0100, Peter Zijlstra wrote:
> > Let PDF & HTML's be created out of memory-barriers Text by
> > reStructuring.
> So I hate this rst crap with a passion, so NAK from me.
Okay, the outcome is exactly as was feared.
Abondoning the patch, let this be > /dev/n
hat it can be
cross-linked
Signed-off-by: afzal mohammed
---
Hi,
With this change, pdf & html could be generated. There certainly are
improvements to be made, but thought of first knowing whether migrating
memory-barriers from txt to rst is welcome.
The location chosen is "Documentatio
Hi,
On Fri, Dec 22, 2017 at 09:41:32AM +0530, afzal mohammed wrote:
> On Thu, Dec 21, 2017 at 08:15:02AM -0800, Paul E. McKenney wrote:
> > Have you installed and run the herd tool? Doing so would allow you
> > to experiment with changes to the litmus tests.
>
> Yes, i in
Hi,
On Thu, Dec 21, 2017 at 08:15:02AM -0800, Paul E. McKenney wrote:
> On Thu, Dec 21, 2017 at 09:00:55AM +0530, afzal mohammed wrote:
> > Since it is now mentioned that r1 can have final value of 0, though it
> > is understood, it might make things crystal clear and
Hi,
On Wed, Dec 20, 2017 at 08:45:38AM -0800, Paul E. McKenney wrote:
> On Wed, Dec 20, 2017 at 05:01:45PM +0530, afzal mohammed wrote:
> > > +It is tempting to assume that CPU0()'s store to x is globally ordered
> > > +before CPU1()'s store to z, but this is not t
Hi,
Is this patch not destined to the HEAD of Torvalds ?, got that feeling
as this was in flight around merge window & have not yet made there.
On Wed, Nov 15, 2017 at 08:37:49AM -0800, Paul E. McKenney wrote:
> diff --git a/tools/memory-model/Documentation/recipes.txt
> b/tools/memory-model/Do
Hi,
A trivial & late (sorry) comment,
On Wed, Nov 15, 2017 at 08:37:49AM -0800, Paul E. McKenney wrote:
> +THE HAPPENS-BEFORE RELATION: hb
> +---
> +Less trivial examples of prop all involve fences. Unlike the simple
> +examples above, they can require that some ins
Hi,
On Mon, Dec 11, 2017 at 02:40:43PM +0100, Arnd Bergmann wrote:
> On Mon, Dec 11, 2017 at 11:25 AM, Linus Walleij
> >> This patch prepares the STM32 machine for the integration of Cortex-A
> >> based microprocessor (MPU), on top of the existing Cortex-M
> >> microcontroller family (MCU). Since
Hi,
On Mon, May 01, 2017 at 10:50:57AM -0400, David Miller wrote:
> From: afzal mohammed
> > On Wed, Jan 11, 2017 at 09:07:35PM -0500, David Miller wrote:
> >> From: Florian Fainelli
> >> > I am seeing emails being received right now from @vger.kernel.org th
Hi,
On Wed, Jan 11, 2017 at 09:07:35PM -0500, David Miller wrote:
> From: Florian Fainelli
> > I am seeing emails being received right now from @vger.kernel.org that
> > seem to be from this morning according to my mailer. Has anything
> > changed on vger.kernel.org that could cause that? Other
Hi,
On Thu, Mar 23, 2017 at 09:37:48PM +1000, Greg Ungerer wrote:
> Tested-by: Greg Ungerer
Thanks Greg
Since there was no negative feedback yet, change has been deposited in
rmk's patch system as 8665/1
Regards
afzal
Hi,
On Fri, Mar 17, 2017 at 10:10:34PM +0530, afzal mohammed wrote:
> Greg upon trying to boot no-MMU Kernel on ARM926EJ reported boot
> failure. He root caused it to ID_PFR1 access introduced by the
> commit mentioned in the fixes tag below.
>
> All CP15 processors need not
. Hence check
for it before accessing processor feature register, ID_PFR1.
Fixes: f8300a0b5de0 ("ARM: 8647/2: nommu: dynamic exception base address
setting")
Reported-by: Greg Ungerer
Signed-off-by: afzal mohammed
---
Hi Russell,
It would be good to have the fix go in during -rc, as,
Hi,
On Thu, Feb 02, 2017 at 12:12:26PM -0800, Florian Fainelli wrote:
> The TS-72xx/73xx boards have a CPLD watchdog which is configured to
> reset the board after 8 seconds, if the kernel is large enough that this
> takes about this time to decompress the kernel, we will encounter a
> spurious re
Hi,
On Wed, Feb 01, 2017 at 10:33:17AM +, Vladimir Murzin wrote:
> On 31/01/17 19:24, Russell King - ARM Linux wrote:
> > On Tue, Jan 31, 2017 at 06:34:46PM +0530, afzal mohammed wrote:
> >> ARM core changes to support !MMU Kernel on v7-A MMU processors.
> >>
>
VECTORS_BASE displays the exception base address. Now on no-MMU as
the exception base address is dynamically estimated, define
VECTORS_BASE to the variable holding it.
As it is the case, limit VECTORS_BASE constant definition to MMU.
Suggested-by: Russell King
Signed-off-by: afzal mohammed
Now that exception based address is handled dynamically for
processors with CP15, remove Hivecs configuration in assembly.
Signed-off-by: afzal mohammed
Tested-by: Vladimir Murzin
---
v3:
Vladimir's Tested-by
arch/arm/kernel/head-nommu.S | 5 -
1 file changed, 5 deletions(-)
diff
f-by: afzal mohammed
Tested-by: Vladimir Murzin
---
v3:
Vladimir's Tested-by
v2:
Use existing helpers to detect security extensions
Rewrite a CPP step to C for readability
arch/arm/mm/nommu.c | 52 ++--
1 file changed, 50 insertions(+), 2
//lists.infradead.org/pipermail/linux-arm-kernel/2017-January/481904.html
(in -next)
[3] "[RFC v2 PATCH 00/23] Allow NOMMU for MULTIPLATFORM",
http://lists.infradead.org/pipermail/linux-arm-kernel/2016-November/470966.html
(git://linux-arm.org/linux-vm.git nommu-rfc-v2)
afzal m
Hi,
On Mon, Jan 30, 2017 at 02:03:26PM +, Russell King - ARM Linux wrote:
> On Sun, Jan 22, 2017 at 08:52:12AM +0530, afzal mohammed wrote:
> > The exception base address is now dynamically estimated for no-MMU,
> > display it. As it is the case, now limit VECTORS_BA
Enable EXT4_FS to have rootfs in EXT[2-4].
Other changes are result of savedefconfig keeping minimal config (even
without enabling EXT4_FS, these would be present).
Signed-off-by: afzal mohammed
---
Hi Shawn,
i am not sure about the route for this patch, sending it you as the
Vybrid
Hi,
On Fri, Jan 20, 2017 at 09:50:22PM +0530, Afzal Mohammed wrote:
> On Thu, Jan 19, 2017 at 01:59:09PM +, Vladimir Murzin wrote:
> > You can use
> >
> > cpuid_feature_extract(CPUID_EXT_PFR1, 4)
> >
> > and add a comment explaining what we are loo
Hi,
On Thu, Jan 19, 2017 at 02:24:24PM +, Russell King - ARM Linux wrote:
> On Thu, Jan 19, 2017 at 02:07:39AM +0530, afzal mohammed wrote:
> > +#define VECTORS_BASE 0x
>
> This should be UL(0x)
This has been taken care in v2.
Regards
afzal
Now that exception based address is handled dynamically for
processors with CP15, remove Hivecs configuration in assembly.
Signed-off-by: afzal mohammed
---
arch/arm/kernel/head-nommu.S | 5 -
1 file changed, 5 deletions(-)
diff --git a/arch/arm/kernel/head-nommu.S b/arch/arm/kernel/head
The exception base address is now dynamically estimated for no-MMU,
display it. As it is the case, now limit VECTORS_BASE usage to MMU
scenario.
Signed-off-by: afzal mohammed
---
v2:
A change to accomodate bisectability resolution on patch 1/4
arch/arm/include/asm/memory.h | 4 ++--
arch/arm
f-by: afzal mohammed
---
v2:
Use existing helpers to detect security extensions
Rewrite a CPP step to C for readability
arch/arm/mm/nommu.c | 52 ++--
1 file changed, 50 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mm/nommu.c b/arch/ar
infrastructure that found the
bisectability issue. This macro will be restricted to MMU case upon
dynamically determining exception base address for no-MMU.
Once exception address is handled dynamically for no-MMU,
VECTORS_BASE can be removed from Kconfig.
Suggested-by: Russell King
Signed-off-by: afzal
d.org/pipermail/linux-arm-kernel/2016-December/473593.html
(in -next)
afzal mohammed (4):
ARM: mmu: decouple VECTORS_BASE from Kconfig
ARM: nommu: dynamic exception base address setting
ARM: nommu: display vectors base
ARM: nommu: remove Hivecs configuration is asm
arch/arm/include/asm/m
Hi,
On Thu, Jan 19, 2017 at 01:59:09PM +, Vladimir Murzin wrote:
> On 18/01/17 20:38, afzal mohammed wrote:
> > +#define ID_PFR1_SE (0x3 << 4) /* Security extension enable bits */
>
> This bitfiled is 4 bits wide.
Since only 2 LSb's out of the 4 were enough
Hi,
On Thu, Jan 19, 2017 at 02:24:24PM +, Russell King - ARM Linux wrote:
> On Thu, Jan 19, 2017 at 02:07:39AM +0530, afzal mohammed wrote:
> > +++ b/arch/arm/include/asm/memory.h
> > +#define VECTORS_BASE 0x
>
> This sh
+ Marvell Berlin SoC maintainers - Sebastian, Jisheng
On Thu, Jan 19, 2017 at 02:07:39AM +0530, afzal mohammed wrote:
> For MMU configurations, VECTORS_BASE is always 0x, a macro
> definition will suffice.
>
> Once exception address is handled dynamically for no-MMU also (
Hi,
On Wed, Jan 18, 2017 at 10:13:15PM +, Russell King - ARM Linux wrote:
> On Thu, Jan 19, 2017 at 02:08:37AM +0530, afzal mohammed wrote:
> > + MLK_ROUNDUP(vectors_base, vectors_base + PAGE_SIZE),
>
> I think MLK() will do here - no need to use the roun
The exception base address is now dynamically estimated for no-MMU
case, display it.
Signed-off-by: afzal mohammed
---
arch/arm/mm/init.c | 5 +
arch/arm/mm/mm.h | 5 +++--
2 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mm/init.c b/arch/arm/mm/init.c
index
Now that exception based address is handled dynamically for
processors with CP15, remove Highvecs configuration in assembly.
Signed-off-by: afzal mohammed
---
arch/arm/kernel/head-nommu.S | 5 -
1 file changed, 5 deletions(-)
diff --git a/arch/arm/kernel/head-nommu.S b/arch/arm/kernel/head
f-by: afzal mohammed
---
arch/arm/mm/nommu.c | 64 +++--
1 file changed, 62 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mm/nommu.c b/arch/arm/mm/nommu.c
index 2740967727e2..db8e784f20f3 100644
--- a/arch/arm/mm/nommu.c
+++ b/arch/arm/mm/nom
: afzal mohammed
---
Though there was no build error without inclusion of asm/memory.h, to
be on the safer side it has been added, to reduce chances of build
breakage in random configurations.
arch/arm/include/asm/memory.h | 2 ++
arch/arm/mach-berlin/platsmp.c | 3 ++-
arch/arm/mm/dump.c
r MULTIPLATFORM",
http://lists.infradead.org/pipermail/linux-arm-kernel/2016-November/470966.html
(git://linux-arm.org/linux-vm.git nommu-rfc-v2)
[2] "[PATCH 1/2] ARM: nommu: allow enabling REMAP_VECTORS_TO_RAM"
http://lists.infradead.org/pipermail/linux-arm-kernel/2016-Decem
Hi,
On Mon, Jan 16, 2017 at 09:53:41AM +, Vladimir Murzin wrote:
> On 15/01/17 11:47, Afzal Mohammed wrote:
> > mpu_setup_region() in arch/arm/mm/nommu.c that takes care of
> > MPU_RAM_REGION only. And that seems to be a kind of redundant as it is
> > also done in asm
Hi,
On Sat, Jan 07, 2017 at 10:43:39PM +0530, Afzal Mohammed wrote:
> On Tue, Dec 13, 2016 at 10:02:26AM +, Russell King - ARM Linux wrote:
> > Also, if the region setup for the vectors was moved as well, it would
> > then be possible to check the ID registers to determi
Hi,
On Sat, Jan 07, 2017 at 06:24:15PM +, Russell King - ARM Linux wrote:
> As I've said, CONFIG_VECTORS_BASE is _always_ 0x on MMU, so
> this always displays 0x - 0x1000 here.
> Older ARM CPUs without the V bit (ARMv3 and early ARMv4) expect the
> vectors to be at virtua
Hi,
On Sat, Jan 07, 2017 at 11:32:27PM +0530, Afzal Mohammed wrote:
> i had thought that for MMU case if Hivecs is not enabled,
> CONFIG_VECTOR_BASE has to be considered as 0x at least for the
s/CONFIG_VECTOR_BASE/exception base address
> purpose of displaying exception bas
Hi,
On Sat, Jan 07, 2017 at 05:38:32PM +, Russell King - ARM Linux wrote:
> On Sat, Jan 07, 2017 at 10:52:28PM +0530, afzal mohammed wrote:
> > TODO:
> > Kill off VECTORS_BASE completely - this would require to handle MMU
> > case as well as ARM_MPU scenario dynamically
vectors base is now dynamically updated for Hivecs as well as for
REMAP_VECTORS_TO_RAM case to DRAM_START. Hence remove these CP15
cases.
TODO:
Kill off VECTORS_BASE completely - this would require to handle MMU
case as well as ARM_MPU scenario dynamically.
Signed-off-by: afzal mohammed
Display dynamically estimated nommu exception base.
TODO: Dynamically update MMU case too.
Signed-off-by: afzal mohammed
---
arch/arm/mm/init.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/arch/arm/mm/init.c b/arch/arm/mm/init.c
index 370581aeb871..1777ee23a6a2 100644
--- a
Now that exception based address is handled dynamically for
processors with CP15, remove Hivecs configuration in assembly.
Signed-off-by: afzal mohammed
---
arch/arm/kernel/head-nommu.S | 5 -
1 file changed, 5 deletions(-)
diff --git a/arch/arm/kernel/head-nommu.S b/arch/arm/kernel/head
No-MMU dynamic exception base address configuration on processors
with CP15.
TODO: Handle MMU case as well as ARM_MPU scenario dynamically
Signed-off-by: afzal mohammed
---
arch/arm/mm/nommu.c | 62 +++--
1 file changed, 60 insertions(+), 2
Hi,
On Tue, Dec 13, 2016 at 10:02:26AM +, Russell King - ARM Linux wrote:
> Is there really any need to do this in head.S ? I believe it's
> entirely possible to do it later - arch/arm/mm/nommu.c:paging_init().
As memblock_reserve() for exception address was done before
paging_init(), seems
nded as a license change.
Acked-by: Afzal Mohammed
Regards
afzal
Hi,
On Tue, Dec 13, 2016 at 09:38:21AM +, Vladimir Murzin wrote:
> On 11/12/16 13:12, Afzal Mohammed wrote:
> > this probably would have to be made robust so as to not cause issue on
> > other v7-A's upon trying to do !MMU (this won't affect normal MMU boot),
Hi,
On Tue, Dec 13, 2016 at 10:02:26AM +, Russell King - ARM Linux wrote:
> On Sun, Dec 11, 2016 at 06:42:55PM +0530, Afzal Mohammed wrote:
> > bic r0, r0, #CR_V
> > #endif
> > mcr p15, 0, r0, c1, c0, 0 @ write control
Hi,
On Sun, Dec 11, 2016 at 06:40:28PM +0530, Afzal Mohammed wrote:
> Kernel reached the stage of invoking user space init & panicked, though
> it could not reach till prompt for want of user space executables
>
> So far i have not come across a toolchain (or a way to create
Hi,
On Sun, Dec 11, 2016 at 06:42:55PM +0530, Afzal Mohammed wrote:
> Kernel text start at an offset of at least 32K to account for page
> tables in MMU case.
Proper way to put it might have been "32K (to account for 16K initial
page tables & the old atags)", unless i missed
change prior to this.
Kernel text start at an offset of at least 32K to account for page
tables in MMU case. On a !MMU build too this space is kept aside, and
since 2 pages (8K) is the maximum for exception plus stubs, it can be
placed at the start of RAM.
Signed-off-by: Afzal Mohammed
---
i am a
.
Signed-off-by: Afzal Mohammed
---
arch/arm/Kconfig-nommu | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/arm/Kconfig-nommu b/arch/arm/Kconfig-nommu
index aed66d5df7f1..b7576349528c 100644
--- a/arch/arm/Kconfig-nommu
+++ b/arch/arm/Kconfig-nommu
@@ -34,8 +34,7 @@ config
ecurity extensions are not enabled. Also effect
of hypervisor extension also need to be considered. Please let know if
any better ways to handle this.
Boot logs at the end.
Afzal Mohammed (2):
ARM: nommu: allow enabling REMAP_VECTORS_TO_RAM
ARM: nommu: remap exception base address t
Hi,
On Thu, Nov 24, 2016 at 10:41:29PM +0100, Michael Kerrisk (man-pages) wrote:
>Suppose that there are two autogroups competing for the same
>CPU. The first group contains ten CPU-bound processes from a
>kernel build started with make -j10. The other contains a si
Hi,
On Wed, Jul 13, 2016 at 03:26:40PM +0800, Wan Zongshun wrote:
> Do you mean I should add cpus into soc
yes
Regards
afzal
Hi,
On Sun, Jul 10, 2016 at 03:42:20PM +0800, Wan Zongshun wrote:
> This patch is to add dts support for nuc970 platform.
cpu ! in soc ? lost in fab ? ;)
Regards
afzal
Hi,
On Fri, Jun 24, 2016 at 12:15:41PM -0400, Lennart Sorensen wrote:
> although the style does require using brackets for the else if the
> if required them.
As an aside, though most of the style rationale is K & R, K & R
consistently uses unbalanced braces for if-else-*
For a one that learns
Hi,
On Fri, Jun 24, 2016 at 11:35:15AM +0530, Mugunthan V N wrote:
> On Thursday 23 June 2016 06:26 PM, Ivan Khoronzhuk wrote:
> >> +if (pool->cpumap) {
> >> +dma_free_coherent(pool->dev, pool->mem_size, pool->cpumap,
> >> + pool->phys);
> >> +} else {
> >> +
Hi,
On Mon, Jun 13, 2016 at 05:24:09PM +0200, Alexandre Belloni wrote:
> On 11/06/2016 at 00:30:36 +0200, Arnd Bergmann wrote :
> > Does this have to be called that early? It seems wasteful to always
> > call udelay() here, when these are functions that are normally
> > allowed to sleep.
> So I'
Hi,
On Thu, May 26, 2016 at 04:44:02PM -0500, Rob Landley wrote:
> As far as I know, we're the first nommu SMP implementation in Linux.
According to hearsay, thou shall be called Buzz Aldrin, Blackfin is
Neil Armstrong.
Regards
afzal
1 - 100 of 321 matches
Mail list logo
