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
prev parent 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.