Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751640AbdHNRbw (ORCPT ); Mon, 14 Aug 2017 13:31:52 -0400 Received: from mail-io0-f169.google.com ([209.85.223.169]:36043 "EHLO mail-io0-f169.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751030AbdHNRbu (ORCPT ); Mon, 14 Aug 2017 13:31:50 -0400 Date: Mon, 14 Aug 2017 13:31:47 -0400 (EDT) From: Nicolas Pitre To: Chris Brandt cc: Alexander Viro , "linux-fsdevel@vger.kernel.org" , "linux-embedded@vger.kernel.org" , "linux-kernel@vger.kernel.org" Subject: RE: [PATCH 0/5] cramfs refresh for embedded usage In-Reply-To: Message-ID: References: <20170811192252.19062-1-nicolas.pitre@linaro.org> User-Agent: Alpine 2.20 (LFD 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1629 Lines: 43 On Mon, 14 Aug 2017, Chris Brandt wrote: > 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 You need the newer mkcramfs I linked to in the documentation. With it you don't need to play tricks with the sticky bit anymore. However you need to specify -X twice (or just once for no-MMU targets) and it will make every ELF files XIPable automatically. > - 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. Just use busybox's built-in cat command and dump the content of /proc/self/maps. You should see an offset that refers to a physical address within your cramfs image for those segments marked read-only and executable. Nicolas