[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <SG2PR06MB1165840F183EADFC3265D7D98A8C0@SG2PR06MB1165.apcprd06.prod.outlook.com>
Date: Mon, 14 Aug 2017 17:11:53 +0000
From: Chris Brandt <Chris.Brandt@...esas.com>
To: Nicolas Pitre <nicolas.pitre@...aro.org>,
Alexander Viro <viro@...iv.linux.org.uk>
CC: "linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>,
"linux-embedded@...r.kernel.org" <linux-embedded@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH 0/5] cramfs refresh for embedded usage
On Friday, August 11, 2017, Nicolas Pitre wrote:
> This series brings a nice refresh to the cramfs filesystem, adding the
> following capabilities:
>
> - Direct memory access, bypassing the block and/or MTD layers entirely.
>
> - Ability to store individual data blocks uncompressed.
>
> - Ability to locate individual data blocks anywhere in the filesystem.
>
> The end result is a very tight filesystem that can be accessed directly
> from ROM without any other subsystem underneath. Also this allows for
> user space XIP which is a very important feature for tiny embedded
> systems.
I just applied the patches tried this simple test:
- tested with a Renesas RZ/A1 (Cortex-A9...so it has an MMU).
- I set the sticky bit for busybox before using mkcramfs
- booted (with squashfs) and mounted the cramfs image
- confirmed that the sticky bit was still set on busybox
- was able to execute busybox in the cramfs image
However, at this point I'm not sure how I can confirm that the XIP
busybox actually executed as XIP or not.
Chris
Powered by blists - more mailing lists