Re: build interval for the "weekly" CDs (was: [RFC] d-i hd-media support for armhf)
Karsten Merker (2014-09-27): > On Mon, Sep 22, 2014 at 12:17:23AM +0200, Karsten Merker wrote: > > > I have started working on implementing hd-media support for the > > armhf platform in debian-installer. > [snip] > > Attached is a first preliminary attempt at an implementation. > > The long list of kernel modules in the pkg-list is currently > > necessary for testing the code as the current weekly CD image > > contains modules for an older kernel, so the modules must for the > > moment be put into the initrd. This will of course be changed > > for the final version. > > Hello, > > I am working on a V2 of my hd-media support patch and would like to > test it with a current weekly CD. I have therefore just looked at > http://cdimage.debian.org/cdimage/weekly-builds/armhf/jigdo-cd/ and it > still shows the CD image from 2014-09-15, which is quite a few days > older than a week. Is this intended or is there perhaps some problem > with the CD-building process? Presumably fallouts due to tasksel changes, which Steve only patched yesterday? Mraw, KiBi. signature.asc Description: Digital signature
Re: build interval for the "weekly" CDs (was: [RFC] d-i hd-media support for armhf)
On Sat, Sep 27, 2014 at 11:49:37PM +0200, Karsten Merker wrote: >On Mon, Sep 22, 2014 at 12:17:23AM +0200, Karsten Merker wrote: > >> I have started working on implementing hd-media support for the >> armhf platform in debian-installer. >[snip] >> Attached is a first preliminary attempt at an implementation. >> The long list of kernel modules in the pkg-list is currently >> necessary for testing the code as the current weekly CD image >> contains modules for an older kernel, so the modules must for the >> moment be put into the initrd. This will of course be changed >> for the final version. > >I am working on a V2 of my hd-media support patch and would like to >test it with a current weekly CD. I have therefore just looked at >http://cdimage.debian.org/cdimage/weekly-builds/armhf/jigdo-cd/ and it >still shows the CD image from 2014-09-15, which is quite a few days >older than a week. Is this intended or is there perhaps some problem >with the CD-building process? Hi! The weekly builds happen every Monday normally, but this last Monday there were problems with the builds due to changes in tasksel. We've fixed things now, so the next set on Monday should hopefully work fine for you. If it's urgent, I can force a manual build - just let me know. -- Steve McIntyre, Cambridge, UK.st...@einval.com You lock the door And throw away the key There's someone in my head but it's not me -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140927221221.gf12...@einval.com
Re: [RFC] d-i hd-media support for armhf
> Anywhere under /boot would do, wouldn't it? Debian and Ubuntu seem to be > the main ones which use /usr or /lib. Ubuntu was looking to move to /boot/dtb-$(uname -r) (mirroring fedora's location) https://lists.ubuntu.com/archives/kernel-team/2014-August/048015.html But later reverted it: https://lists.ubuntu.com/archives/kernel-team/2014-September/048075.html it would be very nice, if we could just move to one location and call it done. ;) For bb.org, I've setup the default u-boot bootloader to loop thru all the known locations based on $(uname -r) with a grub inspired shim to update /boot/uEnv.txt with the new $(uname -r).. Regards, -- Robert Nelson http://www.rcn-ee.com/ -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/caochtyinnpke8qgzt-mrqlgmjcvxk0k6aqblj5nj8txxyij...@mail.gmail.com
Re: [RFC] d-i hd-media support for armhf
On Tue, Sep 23, 2014 at 09:01:46PM +0100, Ian Campbell wrote: > It appears not :-/ > Thinking about it some more we don't really need this for the sort of > default boot script I was thinking about, just a dtb -> dtb-$uname > symlink to match the vmlinuz/initrd.img ones is sufficient given the > ability to supply our own boot.scr, and flash kernel can arrange that > regardless of the packaged location. > I notice that the Debian powerpc packages use the same /usr/lib path as > the arm ones, I don't have the knowledge to go messing around with that, > which makes me inclined to leave ARM alone too rather than diverge > across the arches. > > The linked wiki page still lists a set of options. > FWIW this new u-boot stuff include $fdtfile which is the file name, but > I don't think it includes (or cares about) the path to it. > > At the time of that thread, I recall that the proposed standardization of > > dtb locations was mostly not useful for the platforms I cared about because > > they were going to be placed in locations that wouldn't help u-boot find > > them in order to pass them to the kernel. > Anywhere under /boot would do, wouldn't it? Debian and Ubuntu seem to be > the main ones which use /usr or /lib. Anywhere under /boot, provided that u-boot can find it. The linaro proposal was for distribution packages to /ship/ the dtb files under /boot; that doesn't help u-boot if they're also going to be qualified by uname, without additional glue code for your boot.scr; and if you have to have additional glue code, why put it in boot.scr instead of in flash-kernel? One possible answer to this question is: so that flash-kernel doesn't have to iterate over all of the dtbs for the current kernel and copy them around. But I think we're even farther from having any kind of standard boot.scr/uEnv.txt infrastructure that would cope with this, than we are from having dtbs themselves as a standard interface. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: [RFC] d-i hd-media support for armhf
On Tue, 2014-09-23 at 12:02 -0700, Steve Langasek wrote:
> On Tue, Sep 23, 2014 at 07:31:32PM +0100, Ian Campbell wrote:
> > On Mon, 2014-09-22 at 00:17 +0200, Karsten Merker wrote:
>
> > (bit of an aside)
> > > diff --git a/build/boot/arm/bootscr.mainline_common
> > > b/build/boot/arm/bootscr.mainline_common
> > > new file mode 100644
> > > index 000..268eeba
> > > --- /dev/null
> > > +++ b/build/boot/arm/bootscr.mainline_common
>
> > This be a good starting point for something which could be added to
> > flash-kernel too as a default/generic boot script too.
>
> > Only wrinkle is the dependency on dtbs/${fdtfile}, but
> > http://lists.linaro.org/pipermail/cross-distro/2014-May/000676.html was
> > proposing something along those lines too, so perhaps I should just bite
> > the bullet and move them...
>
> Did that thread converge on a recommendation?
It appears not :-/
Thinking about it some more we don't really need this for the sort of
default boot script I was thinking about, just a dtb -> dtb-$uname
symlink to match the vmlinuz/initrd.img ones is sufficient given the
ability to supply our own boot.scr, and flash kernel can arrange that
regardless of the packaged location.
I notice that the Debian powerpc packages use the same /usr/lib path as
the arm ones, I don't have the knowledge to go messing around with that,
which makes me inclined to leave ARM alone too rather than diverge
across the arches.
> The linked wiki page still lists a set of options.
FWIW this new u-boot stuff include $fdtfile which is the file name, but
I don't think it includes (or cares about) the path to it.
> At the time of that thread, I recall that the proposed standardization of
> dtb locations was mostly not useful for the platforms I cared about because
> they were going to be placed in locations that wouldn't help u-boot find
> them in order to pass them to the kernel.
Anywhere under /boot would do, wouldn't it? Debian and Ubuntu seem to be
the main ones which use /usr or /lib.
Ian.
--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1411502506.3824.4.ca...@hellion.org.uk
Re: [RFC] d-i hd-media support for armhf
On Tue, Sep 23, 2014 at 07:31:32PM +0100, Ian Campbell wrote:
> On Mon, 2014-09-22 at 00:17 +0200, Karsten Merker wrote:
> (bit of an aside)
> > diff --git a/build/boot/arm/bootscr.mainline_common
> > b/build/boot/arm/bootscr.mainline_common
> > new file mode 100644
> > index 000..268eeba
> > --- /dev/null
> > +++ b/build/boot/arm/bootscr.mainline_common
> This be a good starting point for something which could be added to
> flash-kernel too as a default/generic boot script too.
> Only wrinkle is the dependency on dtbs/${fdtfile}, but
> http://lists.linaro.org/pipermail/cross-distro/2014-May/000676.html was
> proposing something along those lines too, so perhaps I should just bite
> the bullet and move them...
Did that thread converge on a recommendation? The linked wiki page still
lists a set of options.
At the time of that thread, I recall that the proposed standardization of
dtb locations was mostly not useful for the platforms I cared about because
they were going to be placed in locations that wouldn't help u-boot find
them in order to pass them to the kernel.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
signature.asc
Description: Digital signature
Re: [RFC] d-i hd-media support for armhf
On Mon, 2014-09-22 at 00:17 +0200, Karsten Merker wrote:
(bit of an aside)
> diff --git a/build/boot/arm/bootscr.mainline_common
> b/build/boot/arm/bootscr.mainline_common
> new file mode 100644
> index 000..268eeba
> --- /dev/null
> +++ b/build/boot/arm/bootscr.mainline_common
This be a good starting point for something which could be added to
flash-kernel too as a default/generic boot script too.
Only wrinkle is the dependency on dtbs/${fdtfile}, but
http://lists.linaro.org/pipermail/cross-distro/2014-May/000676.html was
proposing something along those lines too, so perhaps I should just bite
the bullet and move them...
> @@ -0,0 +1,30 @@
> +# Bootscript using the new unified bootcmd handling
> +# introduced with u-boot v2014.10
> +
> +if test -n "${boot_targets}"; then
> + echo "Mainline u-boot / new-style environment detected."
> +else
> + echo "Non-mainline u-boot detected. This boot script uses the unified
> bootcmd"
> + echo "handling of mainline u-boot (>=v2014.10), which is not available on
> your"
> + echo "system. Please boot the installer manually."
> + exit 0
> +fi
> +
> +if test -z "${fdtfile}"; then
> + echo 'fdtfile environment variable not set. Aborting boot process.'
> + exit 0
> +fi
> +
> +if test ! -e ${devtype} ${devnum}:${bootpart} dtbs/${fdtfile}; then
> + echo "This installer medium does not contain a suitable device-tree file
> for"
> + echo "this system (${fdtfile}). Aborting boot process."
> + exit 0
> +fi
> +
> +setenv bootargs "${bootargs} console=${console}"
> +
> +load ${devtype} ${devnum}:${bootpart} ${kernel_addr_r} vmlinuz \
> +&& load ${devtype} ${devnum}:${bootpart} ${fdt_addr_r} dtbs/${fdtfile} \
> +&& load ${devtype} ${devnum}:${bootpart} ${ramdisk_addr_r} initrd.gz \
> +&& echo "Booting the Debian installer..." \
> +&& bootz ${kernel_addr_r} ${ramdisk_addr_r}:${filesize} ${fdt_addr_r}
--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1411497092.27559.28.ca...@hellion.org.uk
Re: [RFC] d-i hd-media support for armhf
On 2014-09-21 17:17:23 -0500, Karsten Merker wrote: > I believe that on armhf systems a tarball makes more sense than > a disk image for the following reasons: Thanks for working on this! > - We do not install a boot sector on armhf but just a u-boot > script. This is a normal file which can be copied onto a USB > stick with an exiting filesystem of arbitrary size and mostly > arbitrary type (fat16/fat32/ext2/ext3/ext4), so there is no > need to provide a block-wise disk image with a fixed size. > This allows using nearly any exiting usb stick as installation > medium without overwriting the data on it, and it provides > flexibility regarding media size. Sounds good. There are several platforms that do not have u-boot on any sort of built-in media, but it wouldn't be hard to write a script that dumps the tarball and writes u-boot to the media, at least for some "common" platforms. > Due to the diversity of the various armhf platforms and their > (sometimes years-old) u-boot versions, it is nearly impossible to > provide a boot script that works on all of them. Therefore I > target systems which run a current mainline u-boot. Mainline > u-boot 2014.10 (which is planned to go into Jessie) introduces a > common bootcmd handling for all platforms, so that one boot > script can be used on all supported platforms. > > The d-i boot script checks whether it is called on such a modern > u-boot and provides appropriate information when not. Sounds good. Not all platforms seem to have adopted this yet, but it's probably worth considering patching some u-boot platforms to do so in Debian... > I have run some tests with the resulting tarball contents and a > Jesse CD1 iso copied onto a USB stick; booting and detecting the > ISO worked as expected on a Cubietruck (armhf/sunxi) with > mainline u-boot. Which ISO did you use? live well, vagrant pgpHJvOrFCCP9.pgp Description: PGP signature
