public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Bartlomiej Sieka <tur@semihalf.com>
To: u-boot@lists.denx.de
Subject: [U-Boot-Users] [PATCH] Add 'imload' command
Date: Thu, 14 Feb 2008 08:38:00 +0100	[thread overview]
Message-ID: <47B3EFD8.9020706@semihalf.com> (raw)
In-Reply-To: <fa686aa40802131713n77a633a6h6e9d9e1d9ac01c48@mail.gmail.com>

Grant Likely wrote:
> On Feb 13, 2008 12:55 PM, Bartlomiej Sieka <tur@semihalf.com> wrote:
>> Kumar Gala wrote:
>>> On Feb 13, 2008, at 4:11 AM, Bartlomiej Sieka wrote:
>>>
>>>> Kumar Gala wrote:
>>>>> 'imload' provides a more direct means to load from an image file.
>>>>> Also created a load_image routine out of the code in do_bootm() that
>>>>> is shared between do_bootm() and do_imload().
>>>>> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
>>>>> ---
>>>>> Note, this is against the u-boot-testing new-image branch.
>>>> Thanks.
>>>>
>>>> Two comments:
>>>> - The load_image routine (and consequently imload commad) will not
>>>> work when the image is stored in Data Flash.
>>> what's the issue here?
>> Please have a look at code under CONFIG_HAS_DATAFLASH in get_kernel()
>> (formerly in do_bootm()), especially the read_dataflash() function. The
>> issue is that you have to copy data from Data Flash in a specific way in
>> order to have random access to it. So for example this line in your code:
>> type_name = image_get_type_name (image_get_type (hdr));
>> will effectively try to access hdr->ih_type, which will not work when
>> hdr is an address in Data Flash.
> 
> Ugh, please don't continue down that path.  Dataflash is a serial
> flash technology, but the driver pretends that it is memory mapped.
> It is not a good abstraction that I really think needs to be removed.

Hi Grant,

Not sure if your comment was directed to Kumar or me, but I'm replying
just in case.

I'm all for removing the code under CONFIG_HAS_DATAFLASH from at least
boot-related functions (haven't looked at other affected places in
U-Boot). We've not removed it in the new image format work, because by
default we try to preserve the status quo. When the new format handling
is introduced, we don't want to break too many things that people are
used to.

Regards,
Bartlomiej

  parent reply	other threads:[~2008-02-14  7:38 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-02-13  5:10 [U-Boot-Users] [PATCH] Add 'imload' command Kumar Gala
2008-02-13 10:11 ` Bartlomiej Sieka
2008-02-13 13:06   ` Kumar Gala
2008-02-13 19:55     ` Bartlomiej Sieka
2008-02-13 20:15       ` Kumar Gala
2008-02-13 20:22         ` Bartlomiej Sieka
2008-02-13 20:34           ` Kumar Gala
2008-02-14  1:13       ` Grant Likely
2008-02-14  3:54         ` Kumar Gala
2008-02-14  7:38         ` Bartlomiej Sieka [this message]
2008-02-15 16:35         ` Detlev Zundel
2008-02-13 22:31 ` Wolfgang Denk
2008-02-13 22:38   ` Kumar Gala
2008-02-13 23:01     ` Wolfgang Denk
2008-02-13 23:46       ` Kumar Gala
2008-02-14  0:37         ` Wolfgang Denk
2008-02-14  0:50           ` Kumar Gala
2008-02-14  5:35   ` Kumar Gala

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=47B3EFD8.9020706@semihalf.com \
    --to=tur@semihalf.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