--- /dev/null
+
+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
+ ...
+
+===========================================================================
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.
+
projects / users / rw / armboot.git / commitdiff