From mboxrd@z Thu Jan 1 00:00:00 1970 From: Greg Ungerer Date: Mon, 23 May 2005 11:32:05 +1000 Subject: [U-Boot-Users] [PATCH] add OpenGear CM4008 board support In-Reply-To: <20050520144554.E25FDC1512@atlas.denx.de> References: <20050520144554.E25FDC1512@atlas.denx.de> Message-ID: <42913295.6080308@moreton.com.au> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hi Wolfgang, Wolfgang Denk wrote: > Dear Greg, > > in message <428DF0F8.5090404@moreton.com.au> you wrote: > >>The gofsk command is something I added to support loading >>snapgear/uClinux-dist style raw filesystem+kernel images. > > I don't understand why a separate command is needed for that; you > need to store the start address of the image anyway, so you can also > store it's size and use this to compute any other offset; or store > the kernel address, too. Not quite. The start address is fixed (as in fixed position in flash normally). Size is completely dependant on the image - so you need to compute that at run time. You don't want to store the length independantly. >>The image itself is a simple concatenation of a root filesystem >>and a kernel. Typically it is used with a CRAMfs root filesystem. >>The primary motivator for not having any header on this image is >>that it can be dumped directly into an MTD flash partition, and >>it can be directly mounted as the root filesystem. For known > > > This is normal. We don't have headers for standard filesystem images > like cramfs, ext2 or jffs2 for exactly this reason. Yes, but that is not the point here. The is a complete system image with no heads (system being kernel and root filesystem). >>filesystem types (like CRAMfs and ROMfs) the loader simply looks >>over the filesystem to get to the kernel for boot time starting. > > Why do you need a separate command for this? The other possibility seemed to be for a complicated sequence of commands to extract the size - though I didn't try to actually do this. But I still wanted to construct the armtags for boot. I couldn't see that this was currently possible if not used a strictly tagged ARM u-boot image. >>Patch attached is my current implementation of this. >> >>Is this something that you would allow into the main tree? > > No, I don't think so. I don't see what it gives you what you cannot > get with the existing commands and clever usage of a few environment > variables. Also, in general I find it is not a good idea to combine > filesystem and OS kernel into ane image. As a general rule I have always found the exact opposite. Although conveient for debugging I find sepearate kernel and filesystems a limitation in real field setups. A single flash partition with no additional layout restrictions is a much more flexible arrangment. Doesn't limit one or the others size or location. > Usually you buy more > restrictions than advantages this way. If you feel you must do it, > you could extend the capabilities of mutli-file images to match your > needs. > > But the main question is: what can you do with this setup that cannot > be done with the existing code, too? I couldn't see how to load a raw image (no header) and still get the ARM tags setup for booting. ofcousre this was with 1.1.1 when I originally did this. Is it possible now? Regards Greg