All of lore.kernel.org
 help / color / mirror / Atom feed
From: Baruch Siach <baruch@tkos.co.il>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH v2 1/1] Solid-Run HummingBoard i2eX defconfig and bootable microSD Bash script
Date: Sun, 31 May 2015 12:02:26 +0300	[thread overview]
Message-ID: <20150531090226.GE2282@tarshish> (raw)
In-Reply-To: <alpine.DEB.2.11.1505311014390.1709@tanhuma.tkos.co.il>

Hi Yonatan,

On Sun, May 31, 2015 at 10:40:20AM +0300, Jonathan Ben Avraham wrote:
> On Sun, 31 May 2015, Baruch Siach wrote:
> >On Sun, May 31, 2015 at 01:31:24AM +0300, Jonathan Ben-Avraham wrote:
> >>+BINS="fdisk mkfs.ext4 mount umount dd mktemp partprobe"
> >>+for BIN in ${BINS}
> >>+do
> >>+	if ! which ${BIN} >/dev/null
> >>+	then
> >>+		echo "${ME} ERROR: Required executable ${BIN} is not in PATH"
> >>+		ERROR=$((${ERROR}+1))
> >>+	fi
> >>+done
> >
> >Buildroot can build host versions of util-linux (fdisk, mount, umount),
> >e2fsprogs (mkfs.ext4), and parted (partprobe). In that case you should find
> >these utilities under ${BUILDROOT_OUTPUT_DIR}/host/usr/sbin/.
> 
> For fdisk it might be better to use the Buildroot host utility rather than
> deal with the differences in fdisk between the common Linux distros.

Or even better, use sfdisk. sfdisk script should be more resistant to breakage 
on future util-linux versions.

> But for the other utilities that are almost always present, is it work
> adding them to the defconfig and increasing the build time and volume?

I don't think they should be added to defconfig. But if the user selected 
these host packages this script should use them.

> >Buildroot can create ready made ext{2,3,4} images itself. See 'Filesystem
> >images -> ext2/3/4 root filesystem' in menuconfig.
> 
> This script allows you to defer the decision on the filesystem type to a
> later stage by just using rootfs.tar. In terms of project management, I
> think that this is the best strategy. That is, to make a clean separation
> between build issues and installation issues, not to confound them.

Filesystem generation makes this script unnecessarily complex, IMO. Going for 
a single partition solution (see below) would make this script (and 
board/freescale/create-boot-sd.sh) simpler, and easier to maintain.

> >>+if ! mount ${PART1} ${MOUNT_POINT}
> >>+then
> >>+	echo "${ME} ERROR: Cannot mount ${PART1} on ${MOUNT_POINT}"
> >>+	exit 1
> >>+fi
> >>+
> >>+cp ${BUILDROOT_OUTPUT_DIR}/images/zImage ${MOUNT_POINT}
> >
> >Buildroot can do that for you as well. See 'Kernel -> Install kernel image to
> >/boot in target' in menuconfig.
> 
> Buildroot can format and identify the correct microSD device and mount the
> correct partition and then copy the image from output/images to the
> partition? I don't think so. That is what this script and
> board/freescale/create-boot-sd.sh are about.

Right. However, using the boot.scr boot script support of U-Boot (enabled in 
both SolidRun and Freescale U-Boot) would allow Buildroot to generate a single 
boot/root partition. This script, that is running as root, should only to the 
bare minimum, i.e. SD card partitioning.

> In any event, the question is not what Buildroot can do, it is what
> Buildroot *should* do. You want a clean separaration of the build operation
> and the media install operation.

baruch

-- 
     http://baruch.siach.name/blog/                  ~. .~   Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
   - baruch at tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -

  reply	other threads:[~2015-05-31  9:02 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-30 22:31 [Buildroot] [PATCH v2 1/1] Solid-Run HummingBoard i2eX defconfig and bootable microSD Bash script Jonathan Ben-Avraham
2015-05-31  7:08 ` Baruch Siach
2015-05-31  7:40   ` Jonathan Ben Avraham
2015-05-31  9:02     ` Baruch Siach [this message]
2015-05-31  9:23       ` Jonathan Ben Avraham
  -- strict thread matches above, loose matches on Subject: below --
2015-06-01 21:56 Jonathan Ben-Avraham
2015-06-01 22:00 ` Jonathan Ben Avraham
2016-01-12 21:48 ` Yann E. MORIN
2016-01-13  5:58   ` Jonathan Ben Avraham

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=20150531090226.GE2282@tarshish \
    --to=baruch@tkos.co.il \
    --cc=buildroot@busybox.net \
    /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.