public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Heiko Schocher <hs@denx.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH 1/2 v2] cramfs: make cramfs usable on non NOR flash
Date: Thu, 28 Jan 2010 12:02:48 +0100	[thread overview]
Message-ID: <4B616ED8.6000109@denx.de> (raw)
In-Reply-To: <20100128101537.501C83F6C0@gemini.denx.de>

Hello Wolfgang,

Wolfgang Denk wrote:
> In message <4B613D24.7060604@denx.de> you wrote:
[...]
>>> What about systems that have both NOR _and_ NAND?
>> Are there such systems, with cramfs support? Actual cramfs support
>> in mainline is only for NOR devices ...
> 
> Yes, but I understand that you want to also support cramfs when not
> stored in NOR.
> 
> With your code I can read files from a cramfs image stored in RAM
> (when there is nor NOR flash), _or_ I can read it from NOR flash.
> Right?

No. This should work also!

Accessing a cramfs through a nor, the "cramfs_load()" is used,
as in ./common/cmd_jffs2.c, and if reading a file which resists
in RAM "cramfsload" command is used for reading the file.

> But what about reading from files a cramfs image stored in RAM  on  a
> system  that  _has_  NOR flash? And being able to read files a cramfs
> image stored in NOR as well? It seems your code cannot do this.

in fs/cramfs/cramfs.c

#define PART_OFFSET(x)  (x->offset + flash_info[x->dev->id->num].start[0])

and in common/cmd_cramfs.c

part.offset = addr - flash_info[id.num].start[0];

so, flash_info[id.num].start[0] is not really used, if using
cramfsload, so it should be possible to load a file out
of a cramfs, wherever the cramfs resides ... Nevertheless,
flash_info_t is defined or not, also, using "cramfs_load()"
on a NOR flash works, because there is no change.

My Patch is only necessary, because, if a board have no NOR flash,
flash_info_t is not defined.

> I understand that the suggested patch is an improvement over the
> existing state (it adds the capability to read cramfs in RAM on
> NOR-les systems), but I think this restriction ("on NOR-less
> systems") should be lifted as well.
> 
> In other words: I think, the decision whether to use
> 
> 	part.offset = addr - flash_info[id.num].start[0];
> or
> 	part.offset = addr;
> 
> should be made at run time (based on the location of the image - in

but on a board without NOR flash, you have no flash_info_t
defined, which results in a compilerror.

bye
Heiko
-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany

  reply	other threads:[~2010-01-28 11:02 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-01-07  7:56 [U-Boot] arm: suen3, suen3_v1, mgcoge2_arm_p1a support Heiko Schocher
2010-01-17 23:51 ` Wolfgang Denk
2010-01-18  8:34   ` Heiko Schocher
2010-01-18  9:31     ` Stefan Roese
2010-01-27  7:23   ` Heiko Schocher
2010-01-27  7:30     ` [U-Boot] [PATCH 1/2 v2] cramfs: make cramfs usable on non NOR flash Heiko Schocher
2010-01-27 19:28       ` Wolfgang Denk
2010-01-28  7:30         ` Heiko Schocher
2010-01-28 10:15           ` Wolfgang Denk
2010-01-28 11:02             ` Heiko Schocher [this message]
2010-01-27  7:31     ` [U-Boot] [PATCH 2/2 v2] arm: suen3, suen3_v1, mgcoge2_arm_p1a support Heiko Schocher
2010-01-27 13:50       ` Tom
2010-01-27 14:43         ` Heiko Schocher
2010-01-28 13:54           ` Tom
2010-01-27 19:49       ` Wolfgang Denk
2010-02-01  7:37       ` [U-Boot] [PATCH 2/2 v3] " Heiko Schocher
2010-02-02 18:07         ` Prafulla Wadaskar
2010-02-03  6:42           ` Wolfgang Denk
2010-02-03 15:52           ` Heiko Schocher
2010-02-03 16:53             ` Stefan Roese
2010-02-03 22:32             ` Scott Wood
2010-02-04  7:24               ` Heiko Schocher
2010-02-08 19:23                 ` Scott Wood
2010-02-10  7:09             ` Heiko Schocher
2010-02-10  7:41               ` Prafulla Wadaskar
2010-02-10  9:27                 ` Heiko Schocher

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4B616ED8.6000109@denx.de \
    --to=hs@denx.de \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox