From: Marek Vasut <marek.vasut@gmail.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH v2 2/2] RISCV: image: Parse Image.gz support in booti.
Date: Fri, 26 Apr 2019 20:04:15 +0200 [thread overview]
Message-ID: <10a880f3-e63d-ff99-4553-d85568cf3517@gmail.com> (raw)
In-Reply-To: <cbac5e0d-9003-c125-db0d-d19e93a78e11@wdc.com>
On 4/26/19 7:08 PM, Atish Patra wrote:
> On 4/25/19 10:33 PM, Marek Vasut wrote:
>> On 4/25/19 9:56 PM, Atish Patra wrote:
>>> Add gz parsing logic so that booti can parse both Image
>>> and Image.gz.
>>>
>>> Signed-off-by: Atish Patra <atish.patra@wdc.com>
>>> ---
>>> arch/riscv/lib/image.c | 28 +++++++++++++++++++++++++++-
>>> 1 file changed, 27 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/arch/riscv/lib/image.c b/arch/riscv/lib/image.c
>>> index e8802007c446..73ebd0da3885 100644
>>> --- a/arch/riscv/lib/image.c
>>> +++ b/arch/riscv/lib/image.c
>>> @@ -9,6 +9,8 @@
>>> #include <common.h>
>>> #include <mapmem.h>
>>> #include <errno.h>
>>> +#include <bootm.h>
>>> +#include <malloc.h>
>>> #include <linux/sizes.h>
>>> #include <linux/stddef.h>
>>> @@ -16,6 +18,8 @@ DECLARE_GLOBAL_DATA_PTR;
>>> /* ASCII version of "RISCV" defined in Linux kernel */
>>> #define LINUX_RISCV_IMAGE_MAGIC 0x5643534952
>>> +#define GZ_HEADER_0 0x1f
>>> +#define GZ_HEADER_1 0x8b
>>> struct linux_image_h {
>>> uint32_t code0; /* Executable code */
>>> @@ -32,9 +36,31 @@ int booti_setup(ulong image, ulong
>>> *relocated_addr, ulong *size,
>>> bool force_reloc)
>>> {
>>> struct linux_image_h *lhdr;
>>> + uint8_t *temp;
>>> + void *dest;
>>> + ulong dest_end;
>>> + int ret;
>>> + /* TODO: Is there a way to figure out length of compressed
>>> Image.gz ?
>>> + * Otherwise, set it to SYS_BOOTM_LEN which should be sufficient.
>>> + */
>>
>> Presumably this is a RFC patch then ?
>>
> Yeah. I am not very sure if there is a better way to determine the size.
> Hence the comment. I am hoping somebody here would suggest something ;).
Mark the patch as RFC next time please.
>> What happens if you have two (or more) gzip-ed files back-to-back ?
>> Wouldn't you then decompress both ? That might lead to all kinds of
>> problems.
>>
>
> That will be catastrophic. But this was intended only for booti and the
> expectation was that only Image.gz must be loaded before this.
That also means it's horribly fragile.
> Having said that, if we can find a reliable way of figuring out the
> compressed file size here, we can get rid of this hack.
See below
>>> + int len = CONFIG_SYS_BOOTM_LEN;
>>> +
>>> + temp = (uint8_t *)map_sysmem(image, 0);
>>
>> Is the type cast really needed ?
>>
>
> Just wanted to be explicit. Will remove it.
>
>>> - lhdr = (struct linux_image_h *)map_sysmem(image, 0);
>>> + if (*(temp) == GZ_HEADER_0 && *(temp+1) == GZ_HEADER_1) {
>>
>> Wrap the image in some fitImage or so contained, mark the image as gzip
>> compressed there and all this goes away.
>>
>
> Yes. FIT image parsing can be done in that way. However, the idea was
> here to load Image.gz directly. Image.gz is default compressed Linux
> kernel image format in RISC-V.
Sigh, and the image header is compressed as well, so there's no way to
identify the image format, right ? And there's no decompressor, so the
dcompressing has to be done by bootloader, which would need some sort of
very smart way of figuring out which exact compression method is used ?
--
Best regards,
Marek Vasut
next prev parent reply other threads:[~2019-04-26 18:04 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-25 19:56 [U-Boot] [PATCH v2 1/2] RISCV: image: Add booti support Atish Patra
2019-04-25 19:56 ` [U-Boot] [PATCH v2 2/2] RISCV: image: Parse Image.gz support in booti Atish Patra
2019-04-26 1:43 ` Marek Vasut
2019-04-26 17:08 ` Atish Patra
2019-04-26 18:04 ` Marek Vasut [this message]
2019-04-30 1:27 ` Atish Patra
2019-04-30 9:52 ` Marek Vasut
2019-04-30 18:13 ` Atish Patra
2019-04-30 19:11 ` Marek Vasut
2019-04-30 20:38 ` Atish Patra
2019-04-30 21:42 ` Marek Vasut
2019-04-30 22:06 ` Atish Patra
2019-05-01 10:34 ` Marek Vasut
2019-05-01 18:22 ` Atish Patra
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=10a880f3-e63d-ff99-4553-d85568cf3517@gmail.com \
--to=marek.vasut@gmail.com \
--cc=u-boot@lists.denx.de \
/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