| Message ID | 1377079147.31937.37.camel@hastur.hellion.org.uk (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Wed, Aug 21, 2013 at 10:59:07AM +0100, Ian Campbell wrote: > Unless there are any more comments on the correctness of the advice I > suppose this should go via Russell's PTS? Now to dredge up the 8 year > old memories of how that stuff works... It's quite simple - with the standard git formatted email (iow, without 8<==== stuff or similar), just send it to the PTS address. In other words, summary in the subject line, patch description in the body along with the sign-off, the end-of-description marker, be that the dashes or "PATCH FOLLOWS", and the patch following that. The only additional thing that needs to be added is a "Kernelversion:" tag to specify which kernel version the patch was generated against. That can go almost anywhere in the message before the actual patch itself. Alternatively, if you can remember your web login etc, then you can use the online form, which tries to make it easier (since it generates the formatted email for you - but some people find this method harder.)
On Wed, 2013-08-21 at 11:05 +0100, Russell King - ARM Linux wrote: > On Wed, Aug 21, 2013 at 10:59:07AM +0100, Ian Campbell wrote: > > Unless there are any more comments on the correctness of the advice I > > suppose this should go via Russell's PTS? Now to dredge up the 8 year > > old memories of how that stuff works... > > It's quite simple - with the standard git formatted email (iow, without > 8<==== stuff or similar), just send it to the PTS address. > > In other words, summary in the subject line, patch description in the > body along with the sign-off, the end-of-description marker, be that > the dashes or "PATCH FOLLOWS", and the patch following that. Thanks, git has simplified this a fair bit it seems. > The only additional thing that needs to be added is a "Kernelversion:" > tag to specify which kernel version the patch was generated against. > That can go almost anywhere in the message before the actual patch > itself. Cool. Does it understand git tags and stuff? e.g v3.11-rc3 or a sha1? > Alternatively, if you can remember your web login etc, then you can use > the online form, which tries to make it easier (since it generates the > formatted email for you - but some people find this method harder.) I think remembering my web login is probably the biggest barrier for me there. In fact remembering the username is probably too much ;-) Ian.
On Wed, Aug 21, 2013 at 11:16:28AM +0100, Ian Campbell wrote: > On Wed, 2013-08-21 at 11:05 +0100, Russell King - ARM Linux wrote: > > The only additional thing that needs to be added is a "Kernelversion:" > > tag to specify which kernel version the patch was generated against. > > That can go almost anywhere in the message before the actual patch > > itself. > > Cool. Does it understand git tags and stuff? e.g v3.11-rc3 or a sha1? I'd prefer not full sha1's - the numeric version is normally close enough to work out where it needs to go should it not apply immediately. > > Alternatively, if you can remember your web login etc, then you can use > > the online form, which tries to make it easier (since it generates the > > formatted email for you - but some people find this method harder.) > > I think remembering my web login is probably the biggest barrier for me > there. In fact remembering the username is probably too much ;-) Well, I've updated the email address to your current one, so you should be able to recover the password now.
On Wed, 2013-08-21 at 11:21 +0100, Russell King - ARM Linux wrote: > On Wed, Aug 21, 2013 at 11:16:28AM +0100, Ian Campbell wrote: > > On Wed, 2013-08-21 at 11:05 +0100, Russell King - ARM Linux wrote: > > > The only additional thing that needs to be added is a "Kernelversion:" > > > tag to specify which kernel version the patch was generated against. > > > That can go almost anywhere in the message before the actual patch > > > itself. > > > > Cool. Does it understand git tags and stuff? e.g v3.11-rc3 or a sha1? > > I'd prefer not full sha1's - the numeric version is normally close enough > to work out where it needs to go should it not apply immediately. OK, thanks, > > > Alternatively, if you can remember your web login etc, then you can use > > > the online form, which tries to make it easier (since it generates the > > > formatted email for you - but some people find this method harder.) > > > > I think remembering my web login is probably the biggest barrier for me > > there. In fact remembering the username is probably too much ;-) > > Well, I've updated the email address to your current one, so you should > be able to recover the password now. Super, thanks. Ian.
On Wed, 2013-08-21 at 10:59 +0100, Ian Campbell wrote: > Unless there are any more comments on the correctness of the advice I > suppose this should go via Russell's PTS? Now to dredge up the 8 year > old memories of how that stuff works... See 7824/1 Thanks, Ian.
diff --git a/Documentation/arm/Booting b/Documentation/arm/Booting index 0c1f475..371814a 100644 --- a/Documentation/arm/Booting +++ b/Documentation/arm/Booting @@ -18,7 +18,8 @@ following: 2. Initialise one serial port. 3. Detect the machine type. 4. Setup the kernel tagged list. -5. Call the kernel image. +5. Load initramfs. +6. Call the kernel image. 1. Setup and initialise RAM @@ -120,12 +121,27 @@ tagged list. The boot loader must pass at a minimum the size and location of the system memory, and the root filesystem location. The dtb must be placed in a region of memory where the kernel decompressor will not -overwrite it. The recommended placement is in the first 16KiB of RAM -with the caveat that it may not be located at physical address 0 since -the kernel interprets a value of 0 in r2 to mean neither a tagged list -nor a dtb were passed. +overwrite it, whilst remaining within the region which will be covered +by the kernel's low-memory mapping. -5. Calling the kernel image +A safe location is just above the 128MiB boundary from start of RAM. + +5. Load initramfs. +------------------ + +Existing boot loaders: OPTIONAL +New boot loaders: OPTIONAL + +If an initramfs is in use then, as with the dtb, it must be placed in +a region of memory where the kernel decompressor will not overwrite it +while also with the region which will be covered by the kernel's +low-memory mapping. + +A safe location is just above the device tree blob which itself will +be loaded just above the 128MiB boundary from the start of RAM as +recommended above. + +6. Calling the kernel image --------------------------- Existing boot loaders: MANDATORY @@ -136,11 +152,17 @@ is stored in flash, and is linked correctly to be run from flash, then it is legal for the boot loader to call the zImage in flash directly. -The zImage may also be placed in system RAM (at any location) and -called there. Note that the kernel uses 16K of RAM below the image -to store page tables. The recommended placement is 32KiB into RAM. +The zImage may also be placed in system RAM and called there. The +kernel should be placed in the first 128MiB of RAM. It is recommended +that it is loaded above 32MiB in order to avoid the need to relocate +prior to decompression, which will make the boot process slightly +faster. + +When booting a raw (non-zImage) kernel the constraints are tighter. +In this case the kernel must be loaded at an offset into system equal +to TEXT_OFFSET - PAGE_OFFSET. -In either case, the following conditions must be met: +In any case, the following conditions must be met: - Quiesce all DMA capable devices so that memory does not get corrupted by bogus network packets or disk data. This will save