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 -
next prev parent 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.