From: mariusgroeger Date: Wed, 17 Jul 2002 09:52:29 +0000 (+0000) Subject: Added FAQ. X-Git-Url: https://www.infradead.org/git/?a=commitdiff_plain;h=1b4f6081216614d7c1d0ea65fd9eeeec6dcb1812;p=users%2Frw%2Farmboot.git Added FAQ. Added some stuff in README (mostly copied from PPCboot) --- diff --git a/CHANGELOG b/CHANGELOG index fb10bd0..b01dda1 100644 --- a/CHANGELOG +++ b/CHANGELOG @@ -2,6 +2,8 @@ Recent changes ====================================================================== +* Added FAQ + * Added support for SMDK2410 eval board (David Müller ) * Fix write_p15_c1() for ARM720,ARM920 diff --git a/FAQ b/FAQ new file mode 100644 index 0000000..76cc7c3 --- /dev/null +++ b/FAQ @@ -0,0 +1,77 @@ + +QUESTIONS + +1. I have built a vmlinux image but I can boot it. + +2: The mkimage tool, ARMboot's tftp command, and the bootm command require + certain load and entry addresses. I'm confused which ones to chose. + + +ANSWERS + + + +1. I have built a vmlinux image but I can boot it. +-------------------------------------------------- + +ARMboot is designed to boot Images as created by the mkimage tool, that +comes with ARMboot and is automatically built, too. You cannot directly load +the vmlinux image, as it expects a number of prerequisits such as special +register contents etc. + + + +2. The mkimage tool, ARMboot's tftp command, and the bootm command require + certain load and entry addresses. I'm confused which ones to chose. +-------------------------------------------------------------------------- + +Well, there are 3 different addresses: + +1. Kernel Load Address. This is the address, where the kernel was linked + to when you built the vmlinux and can be found in arch/arm/Makefile. + The default for it is: + + ifeq ($(CONFIG_CPU_32),y) + PROCESSOR = armv + TEXTADDR = 0xC0008000 + LDSCRIPT = arch/arm/vmlinux-armv.lds.in + endif + + Provide this as "-a" parameter to mkimage. + +2. Kernel Entry Point. This is the address, where ARMboot jumps to to + enter the Kernel. It usually is the same as the kernel load address. + + Provide this as "-e" parameter to mkimage. + +3. The Network Download Address. This is where you download the mkimage + File. This address MUST BE different to the Kernel Load Address, and + should be sufficiently far away to allow ARMboot to relocate the + image to the final Kernel Load Address. Loading to the 5th MB + within the RAM is usually a good idea, eg. if the RAM begins at + 0xc0000000, you can do this: + + LART # tftp c0400000 linux.img + ARP broadcast 1 + eth addr: 00:02:03:04:05:06 + TFTP from server 192.168.1.1; our IP address is 192.168.1.2 + Filename 'image.img'. + Load address: 0xc0400000 + Loading: + ##################################################################done + Bytes transferred = 567252 (8a7d4 hex) + LART # bootm c0400000 + Image Name: Linux 2.4.18 + Created: Mon Jun 24 12:00:01 2002 + Image Type: ARM Linux Kernel Image (gzip compressed) + Data Size: 567188 Bytes = 553 kB = 0 MB + Load Address: 0xc0008000 + Entry Point: 0xc0008000 + Verifying Checksum ... OK + Loading Kernel Image ... OK + + Starting kernel ... + Linux version 2.4.18 (mag@mag) (gcc version 2.95.3 20010315 (release)) #4 Mon Jun 17 20:35:32 CST 2002 + ... + +=========================================================================== diff --git a/MAINTAINERS b/MAINTAINERS index 73bf4c7..74b5397 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -29,6 +29,10 @@ Gary Jennejohn samsung ARM920T +David Müller + + smdk2410 ARM920T + ######################################################################### # End of MAINTAINERS list # ######################################################################### diff --git a/README b/README index 1e13bef..ed820e4 100644 --- a/README +++ b/README @@ -105,3 +105,107 @@ implementa impA7 impa7_config EP7211 based CLEP7312 ep7312_config Cirrus Logic EP7312 Dev. Board S3C2400X samsung_config Samsung S3C2400X SMDK2410X smdk2410_config Samsung SMDK2410X Eval Board + + +Testing of ARMBoot Modifications, Ports to New Hardware, etc.: +============================================================== + +If you have modified ARMBoot sources (for instance added a new board +or support for new devices, a new CPU, etc.) you are expected to +provide feedback to the other developers. The feedback normally takes +the form of a "patch", i. e. a context diff against a certain (latest +official or latest in CVS) version of ARMBoot sources. + +But before you submit such a patch, please verify that your modifi- +cation did not break existing code. At least make sure that *ALL* of +the supported boards compile WITHOUT ANY compiler warnings. To do so, +just run the "MAKEALL" script, which will configure and build ARMBoot +for ALL supported system. Be warned, this will take a while. You can +select which (cross) compiler to use py passing a `CROSS_COMPILE' +environment variable to the script, i. e. to use the cross tools from +the ELinOS Toolkit you can type + + CROSS_COMPILE=arm_armv4- MAKEALL + + +Image Formats +============= + +The "boot" commands of this monitor operate on "image" files which +can be basicly anything, preceeded by a special header; see the +definitions in include/image.h for details; basicly, the header +defines the following image properties: + +* Target Operating System (Provisions for OpenBSD, NetBSD, FreeBSD, + 4.4BSD, Linux, SVR4, Esix, Solaris, Irix, SCO, Dell, NCR, VxWorks, + LynxOS, pSOS, QNX; + Currently supported: Linux, NetBSD, VxWorks, QNX). +* Target CPU Architecture (Provisions for Alpha, ARM, Intel x86, + IA64, MIPS, MIPS, PowerPC, IBM S390, SuperH, Sparc, Sparc 64 Bit; + Currently supported: PowerPC). +* Compression Type (Provisions for uncompressed, gzip, bzip2; + Currently supported: uncompressed, gzip). +* Load Address +* Entry Point +* Image Name +* Image Timestamp + +The header is marked by a special Magic Number, and both the header +and the data portions of the image are secured against corruption by +CRC32 checksums. + + +Submitting Patches +================== + +Since the number of patches for ARMBoot is growing, we need to +establish some rules. Submissions which do not conform to these rules +may be rejected, even when they contain important and valuable stuff. + +When you send a patch, please include the following information with +it: + +* For bug fixes: a description of the bug and how your patch fixes + this bug. Please try to include a way of demonstrating that the + patch actually fixes something. + +* For new features: a description of the feature and your + implementation. + +* A CHANGELOG entry + +* A MAINTAINERS entry + +* For major contributions, your entry to the CREDITS file + +* When you add support for a new board, don't forget to add this + board to the MAKEALL script, too. + +* If your patch adds new configuration options, don't forget to + document these in the README file. + +* The patch itself. If you are accessing the CVS repository use "cvs + update; cvs diff -puRN"; else, use "diff -purN OLD NEW". If your + version of diff does not support these options, then get the latest + version of GNU diff. + + We accept patches as plain text, MIME attachments or as uuencoded + gzipped text. + +Notes: + +* Before sending the patch, run the MAKEALL script on your patched + source tree and make sure that no errors or warnings are reported + for any of the boards. + +* Keep your modifications to the necessary minimum: A patch + containing several unrelated changes or arbitrary reformats will be + returned with a request to re-formatting / split it. + +* If you modify existing code, make sure that your new code does not + add to the memory footprint of the code ;-) Small is beautiful! + When adding new features, these should compile conditionally only + (using #ifdef), and the resulting code with the new feature + disabled must not need more memory than the old code without your + modification. +