All of lore.kernel.org
 help / color / mirror / Atom feed
From: Joel A Fernandes <agnel.joel@gmail.com>
To: Patches and discussions about the oe-core layer
	<openembedded-core@lists.openembedded.org>
Subject: Re: [RFC oe-core] mkcard: Add a script to parition and format an SD Card
Date: Tue, 30 Aug 2011 16:08:29 -0500	[thread overview]
Message-ID: <CAD=GYpZBDShMM-fWYcTWFrJ=jHD8gNsSivOZD=BTHZUk5eek+w@mail.gmail.com> (raw)
In-Reply-To: <8954E4C1-E43C-46BE-91AB-6DAFF38D2A4A@dominion.thruhere.net>

On Tue, Aug 30, 2011 at 12:47 PM, Koen Kooi <koen@dominion.thruhere.net> wrote:
>
> Op 30 aug. 2011, om 18:46 heeft Jason Kridner het volgende geschreven:
>
>> On Mon, Aug 29, 2011 at 7:08 PM, Joel A Fernandes <agnel.joel@gmail.com> wrote:
>>> On Mon, Aug 29, 2011 at 4:03 PM, Jason Kridner <jkridner@beagleboard.org> wrote:
>>>>>>>
>>>>>>> This script is BSP specific and shouldn't live in the OE-core layer.
>>>>>>
>>>>>> The only issue is this script is used from within the IMAGE_CMD_sdimg
>>>>>> code which lives in OE-core (meta/classes/image_types.
>>>>>
>>>>> classes shouldn't be calling external scripts
>>>>>
>>>>
>>>> Is the right approach to add parameters to the IMAGE_CMD_sdimg class
>>>> such that it can be used generically to produce SD card images,
>>>> instead of trying to move this to meta-ti?  Should it perhaps be a bit
>>>> closer to what is being done by the Linaro image tools [1]?
>>>>
>>>> [1] https://wiki.linaro.org/Source/ImageBuilding
>>>>
>>>
>>> Don't the Linaro scripts need to run on the target?
>>
>> No.
>>
>>> Does it fit well
>>> with OE(-core) ?
>>
>> I don't know, but I hoped that others would comment to help figure it
>> out.  I think it is a common challenge not just for ARM architectures.
>> I'm not sure if the approach is general enough or not, but it does go
>> beyond the BeagleBoard.
>>
>> My primary concerns about leaving it in the BSP are:
>> 1) that there is some room for non-BeagleBoard specific optimizations
>> to the card layout and
>> 2) there may be improvements to the tools that make it easier to
>> create images for systems with different boot requirements.
>>
>> Also, I think we might want to move to an ext3 partition only in the
>> future or other such layout optimizations.  I'd like that to be
>> something that can be parameterized by the BSP.
>
> I think you're missing the point:
>
> The *script* needs to go into the BSP, you are free to extend the bbclasses with code to deal with sd cards internally in OE-core.
>
>

I think there are 2 threads to this discussion. One talks about mkcard
script (which I think Koen is asking to move to BSP), and the other is
the IMAGE_CMD_sdimg variable from image_types.bbclass which holds the
code to create the image (which Jason is referring to).

I am dropping mkcard script as it requires root access (due to kparted
and device mapper), instead I'm just using loop and avoiding device
mapper.

As for the IMAGE_CMD_sdimg , I'm thinking a clean way is to extend
image_types.bbclass from within the BSP layer (which I think Koen also
is suggesting).

Maybe I'm just summarizing what everyone is saying, but just making
sure everyone is on the same page.

Thanks,
Joel



  reply	other threads:[~2011-08-30 21:13 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-08-29  6:12 [RFC oe-core] mkcard: Add a script to parition and format an SD Card Joel A Fernandes
2011-08-29  6:28 ` Joel A Fernandes
2011-08-29  7:58 ` Koen Kooi
2011-08-29 13:32   ` Andrea Adami
2011-08-29 13:37     ` Joel A Fernandes
2011-08-29 15:10   ` Joel A Fernandes
2011-08-29 17:33     ` Koen Kooi
2011-08-29 21:03       ` Jason Kridner
2011-08-29 23:08         ` Joel A Fernandes
2011-08-30  7:13           ` Koen Kooi
2011-08-30 16:46           ` Jason Kridner
2011-08-30 17:47             ` Koen Kooi
2011-08-30 21:08               ` Joel A Fernandes [this message]
2011-09-02 15:44               ` Joel A Fernandes
2011-09-02 16:00                 ` Koen Kooi
2011-09-02 18:12                   ` Joel A Fernandes
2011-08-30  9:31         ` Richard Purdie
2011-08-30  9:36           ` Graeme Gregory
2011-08-30 10:34             ` Koen Kooi
2011-08-30 10:38               ` Graeme Gregory

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='CAD=GYpZBDShMM-fWYcTWFrJ=jHD8gNsSivOZD=BTHZUk5eek+w@mail.gmail.com' \
    --to=agnel.joel@gmail.com \
    --cc=openembedded-core@lists.openembedded.org \
    /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.