public inbox for kexec@lists.infradead.org
 help / color / mirror / Atom feed
From: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
To: "Suzuki K. Poulose" <suzuki@in.ibm.com>
Cc: lethal@linux-sh.org, horms@verge.net.au,
	kexec@lists.infradead.org, mat@brain-dump.org
Subject: Re: [PATCH 3/3] ppc/uImage: Add support for RAM Disks
Date: Sun, 27 Jan 2013 17:39:34 +0100	[thread overview]
Message-ID: <51055846.4040200@linutronix.de> (raw)
In-Reply-To: <50F7C8A7.4000100@in.ibm.com>

On 01/17/2013 10:47 AM, Suzuki K. Poulose wrote:
>>> +{
>>> +    struct Image_info img;
>>> +    off_t size;
>>> +    const unsigned char *buf =
>>> +            (const unsigned char *)slurp_file(filename, &size);
>>
>> is the const cast required here?
> 
> Yes, the uImage_probe() expects (const unsigned char *) as the first
> argument.

That is okay, you can pass a non-const pointer to function that expects
a const pointer. You just can't pass a const pointer to a non-const
function and you should not cast in that situtation as well.

>>> +        buf = img.buf;
>>> +        size = img.len;
>>> +    }
>>> +
>>> +    *r_size = size;
>>> +    return buf;
>>> +}
>>> +   
>>> int uImage_ppc_probe(const char *buf, off_t len)
>>> {
>>>     int type;
>>> @@ -196,7 +216,7 @@ static int ppc_load_bare_bits(int argc, char
>>> **argv, const char *buf,
>>>     blob_buf = fixup_dtb_init(info, blob_buf, &blob_size, load_addr,
>>> &dtb_addr);
>>>
>>>     if (ramdisk) {
>>> -        seg_buf = slurp_file(ramdisk, &seg_size);
>>> +        seg_buf = slurp_ramdisk_ppc(ramdisk, &seg_size);
>>
>> I'm not sure but this kinda breaks the case where someone was using a
>> plain file without the uImage header. I don't know if someone used this
>> at all but it seems we have code for this. The way you load the uImage
>> is very generic and I would expect to load it the same way on ARM or SH.
>>
> If the ramdisk doesn't have uImage header, the slurp_ramdisk_ppc()
> defaults to the original behaviour. i.e, it just does a slurp_file()
> as it used to do earlier.
that is okay then.

>> One thing that is different compared to kernel: If the compression is
>> set to GZ on a ramdisk image you should not uncompress it. I think that
>> uImage_load() decompresses the .gz part for you but I am not sure.
>>
> 
> Did you mean, uImage_load() shouldn't do a decompression for ramdisk ?

Yes. If you look at u-boot source, you will notice that it will
decompress a kernel if it is gzip/bzip2/whatever compressed and ignore
the compression field in case of a ramdisk. I think you should behave
like u-boot does.

Sebastian

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

      reply	other threads:[~2013-01-27 16:39 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-01-11  6:41 [PATCH 0/3] kexec: Support for uImage RAMDisks Suzuki K. Poulose
2013-01-11  6:41 ` [PATCH 1/3] kexec/uImage: Return the image type for uImage_probe Suzuki K. Poulose
2013-01-16 17:20   ` Sebastian Andrzej Siewior
2013-01-17  3:10     ` Suzuki K. Poulose
2013-01-11  6:41 ` [PATCH 2/3] kexec/uImage: Recognize uImage RAM Disks Suzuki K. Poulose
2013-01-11  6:42 ` [PATCH 3/3] ppc/uImage: Add support for " Suzuki K. Poulose
2013-01-11  7:11   ` McClintock Matthew-B29882
2013-01-14  5:14     ` Suzuki K. Poulose
2013-01-14 15:14       ` McClintock Matthew-B29882
2013-01-16 17:30         ` Sebastian Andrzej Siewior
2013-01-16 17:37           ` McClintock Matthew-B29882
2013-01-16 17:26   ` Sebastian Andrzej Siewior
2013-01-17  9:47     ` Suzuki K. Poulose
2013-01-27 16:39       ` Sebastian Andrzej Siewior [this message]

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=51055846.4040200@linutronix.de \
    --to=bigeasy@linutronix.de \
    --cc=horms@verge.net.au \
    --cc=kexec@lists.infradead.org \
    --cc=lethal@linux-sh.org \
    --cc=mat@brain-dump.org \
    --cc=suzuki@in.ibm.com \
    /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