Re: modifying and verifying debian installer for armhf board (a10-eoma68)
Ian Campbell writes: Hi, > On Sun, 2013-05-19 at 18:48 +0100, luke.leighton wrote: >> > But the obvious answer here is to get support for your device into the >> > appropriate Debian kernel flavour and then integrated into the standard >> > d-i images. If there is upstream support then this ought to be more or >> > less trivial. >> >> yeees.. that would be good. what's the procedure there? someone's >> already built one: >> http://dl.linux-sunxi.org/users/niall/debian/ > > If you can identify which config options need to be enabled for a v3.9 > kernel (which I think is due to hit Sid soon) then a wishlist bug would > do the job. Likewise if there are some backports required etc you could > request them in the same bug. > > Looks like CONFIG_ARCH_SUNXI is part of the multi_v7_defconfig upstream, > which suggests it would be a candidate for being enabled in the new mp > (multiplatform) kernel flavour. It's enabled in my local 3.9 armmp work [1] but allwinner a10 support in mainline resume to soc/ram and watchdog support (watchdog not in 3.9) so all you can do is booting a ramdisk and connect on the serial port to 'use' it. Arnaud [1] will be committed soon. I'm making some more testing before committing it. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87vc6bwe9k@lebrac.rtp-net.org
Re: modifying and verifying debian installer for armhf board (a10-eoma68)
"luke.leighton" writes: Hi, > On Sun, May 19, 2013 at 7:49 AM, Ian Campbell wrote: >> On Sat, 2013-05-18 at 12:18 +0100, luke.leighton wrote: >>> * create a modified netinst-initrd that uses usb0 ethernet gadget >>> *blind* (no console!!) which gets far enough on its own to do DHCP >>> client >>> >>> * also pre-install some sort of service (ssh? busybox telnet? other?) >>> which allows an interactive login >> [...] >>> * log in (somehow) to the board over usbnet >> >> Sounds like you want a network-console flavour image, like the ones used >> for kirkwood, http://www.cyrius.com/debian/kirkwood/qnap/ts-41x/install/ > > it does, doesn't it? i've been thinking that through (and also > looking at the source of debian-installer). the only thing that > doesn't make sense is: it's all set up to require a password. why > would you need a password for connecting to something that - pretty > much without fail - is going to be sitting 1/2 a metre away on the end > of a usb cable and nothing else? > > i.e. there's no guarantee on these devices especially things like the > MK802 that there will be ethernet. there's almost certainly no > tablets using allwinner a10 processors that have ethernet (not even > the flying squirrel). > > so i'm tempted to just do an experiment - just because i can - to use > busybox-telnetd - because the route of using openssh _has_ been solved > already but isn't quiiite appropriate, and i think > telnetd-over-g_ether will turn out to be a very useful combination. > > i'd do g_serial and it would be done already but i need the damn > micro-usb port for a network! :) what about using cdc composite gadget driver ? : >From drivers/usb/gadget/Kconfig: config USB_CDC_COMPOSITE tristate "CDC Composite Device (Ethernet and ACM)" > >> (obviously the bit about using the factory image to flash the firmware >> you can ignore in favour of fel boot). > > yes. once running, still need to resolve what kernel to install (if > any). is that possible with debian-installer? the procedures for > installing a kernel (which are normally required to be in the 1st > partition, fat-formatted) and even just _obtaining_ a kernel are > tricky: absolutely everyone right now either custom-builds or uses > stock ones. > > how do you tell debian-installer "i don't want a kernel installed > thanks for offering"? > it may have changed but I think that d-i will tell you that it didn't find any kernel and ask you if you want to proceed without one. If you accept, it'll go on finishing installing things. Arnaud -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/874ndzz1yh@lebrac.rtp-net.org
Re: Bug#680699: unblock: flash-kernel/3.1
Philipp Kern writes: > Hi, > > On Sun, Jul 08, 2012 at 03:16:41AM +0200, Hector Oron wrote: >> Please unblock package flash-kernel >> >> Hello, >> >> flash-kernel/3.1 adds device tree support for Dreamplug device (used by >> freedombox). >> >> Dreamplug support has been backported into linux/3.2.21-1, which we expect >> it to get into wheezy sometime. >> >> Therefore, it would be really nice if we can get flash-kernel/3.1 in >> wheezy. >> >> unblock flash-kernel/3.1 > > my only concern is that /proc/device-tree/model takes precedence over > /proc/cpuinfo in any case with no fallback to the latter. So if any ARM SoC > gets device-tree enabled by a backport it might potentially need a change to > flash-kernel, if the "Hardware" string does not match up with what the model > file delivers. no. With DT, the Hardware string doesn't change with the model but with the SoC. For instance, all kirkwood systems booting with DT have : Hardware: Marvell Kirkwood (Flattened Device Tree) [ defined in arch/arm/mach-kirkwood/board-dt.c ] Then, the model is found in /proc/device-tree/model and I don't think that things in /proc are changing a lot. Arnaud -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87bojqiqv4@lebrac.rtp-net.org
Re: [RFC] include DTB in linux-image files on armel
Ian Campbell writes: > On Fri, 2012-04-20 at 14:25 +0100, Ian Campbell wrote: >> On Fri, 2012-04-20 at 13:35 +0200, Bastian Blank wrote: >> > On Fri, Apr 20, 2012 at 11:11:27AM +0100, Ian Campbell wrote: >> > > -install-image_armel_$(FEATURESET)_$(FLAVOUR)_plain_image \ >> > > +ifneq ($(filter armel,$(ARCH)),) >> > > +install-image_$(ARCH)_$(FEATURESET)_$(FLAVOUR)_plain_image: >> > >> > What is this supposed to do? >> >> I'm not sure. I copied the pattern from the similar powerpc case. >> s390/s390x does the same. >> >> Oh, I see, those cases both cover multiple arches and use $(ARCH), hence >> need gating appropriately. As it stands my patch only support armel so >> could use armel explicitly. Except I think we need to add armhf support >> for this too and that would require this pattern. > > Here is an updated patch, supports armhf as well. There's not actually afaik, some imx and omap boards have DT support in the 3.2 kernel but I have less things supported. For instance, I guess that if you try to boot a DT enabled kernel on imx53qsb/loco, you won't get sata support. > any users in armhf AFAIK, actually until dreamplug support goes in there > is none in armel either... dreamplug and iomega iconnect if I manage to get iconnect support merged :) > > It now uses /usr/lib/linux-image-VERSION/foo.dtb which is consistent > with the attached flash-kernel-install-dtb.patch which is under > discussion in #667681. > > Ian. > > diff --git a/linux-2.6/debian/rules.real b/linux-2.6/debian/rules.real > index a7f56c3..2fbcdc8 100644 > --- a/linux-2.6/debian/rules.real > +++ b/linux-2.6/debian/rules.real > @@ -356,8 +356,16 @@ endif > PACKAGE_DIR='$(PACKAGE_DIR)' PACKAGE_NAME='$(PACKAGE_NAME)' > REAL_VERSION='$(REAL_VERSION)' > +$(MAKE_SELF) install-base > > -install-image_armel_$(FEATURESET)_$(FLAVOUR)_plain_image \ > -install-image_armhf_$(FEATURESET)_$(FLAVOUR)_plain_image \ > +ifneq ($(filter armel armhf,$(ARCH)),) > +install-image_$(ARCH)_$(FEATURESET)_$(FLAVOUR)_plain_image: DTB_INSTALL_DIR > = /usr/lib/linux-image-$(REAL_VERSION) > +install-image_$(ARCH)_$(FEATURESET)_$(FLAVOUR)_plain_image: > + install -m644 '$(DIR)/arch/$(KERNEL_ARCH)/boot/zImage' > $(INSTALL_DIR)/vmlinuz-$(REAL_VERSION) > + +$(MAKE_CLEAN) -C $(DIR) dtbs > + shopt -s nullglob ; for i in $(DIR)/arch/arm/boot/*.dtb ; do \ > + install -D -m644 $$i > '$(PACKAGE_DIR)'/'$(DTB_INSTALL_DIR)'/$$(basename $$i) ; \ > + done > +endif fwiw, I've looked at the powerpc kernel package and looks like that they're shipping the DTS file and not the DTB. I've no opinion on this except that if we choose to ship DTB, we need to be sure that dtc is installed when building (I didn't check if it was already in build-deps). Arnaud -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87ipgqydsg@lebrac.rtp-net.org
Re: Debian ARM architectures and subarchitectures
Loïc Minier writes:
> On Mon, Apr 04, 2011, Hector Oron wrote:
>> static const char *supported_generic_subarches[] = {
>> "dove",
>
> matches mach-dove, no plat-dove
>
>> "omap",
>
> matches plat-omap, but no mach-omap (mach-omap1 supports OMAP1xxx and
> mach-omap2 supports OMAP 2+ -- 2xxx, 3xxx, 4xxx).
>
>> "omap4",
>
> doesn't match any plat or mach dir
>
>> "mx51",
>
> neither does this
>
>> and machine mappings has:
>> { "Freescale MX51 Babbage Board", "imx5" }, /* iMX51 reference hardware.
>> */
>
> plat-imx5 is a name which was used in the Freescale BSP which also used
> mach-imx51 in the past.
>
>> Would it break 'others' configurations if we set/change 'mx5' as
>> subarchitecture, which seems to be the most reasonable one at the
>> moment.
>
> I think you really want to go for mx5; as this was never supported in
> Debian so far, that should be ok; if you need to change existing
> imx5/mx51 bits, poke the Ubuntu folks (or I can forward) as it might
> impact them.
>
> I've commented in Debian #612376 on why we want mx5; quoting myself:
> """Currently, the upstream
> kernel doesn't support building both i.MX51 and i.MX53 in the same
> kernel but the Linux Linaro branch and the Freescale BSP kernel do;
> also, I think the patches by Eric Miao allowing this (runtime phys
> offset patches -- i.MX51 has phys RAM at 0x9000 while i.MX53 has it
> at 0x7000, see arch/arm/mach-mx5/Makefile.boot) are pending in
> Sacha Hauer's tree, but I'm not entirely sure.
that's why I was talking of checking imx51/imx53 support in same
kernel. iirc imx50 has same addresses as imx53.
>
> Technically, mx5 would only support mx51 right now, but would soon
> allow supporting mx53 as well, notably for mx53loco / quickstart boards
> which I bet a bunch of Debian ARM users will get."""
tbh, I was thinking of loco boards when talking of imx53. Given the
price of loco, it makes them interesting so would be bad to have 2
kernels instead of one.
>
> In the kernel, there's plat-mxc, mach-imx, mach-mx3 and mach-mx5. I
> expect Debian will want to support popular mach-mx5 hardware for i.MX51
> (Efika MX Smartbook and Smarttop) and i.MX53 (Freescale MX53LOCO /
> Quickstart board).
>
> Also note that the currently supported subarches in Debian ARM are:
> - iop32x (matches mach-iop32x, not plat-iop -- there are some other
>mach-iop*)
> - kirkwood (matches mach-kirkwood, no plat-kirkwood I think it's
>plat-orion)
yeah, it's plat-orion for mach-kirkwood, mach-orion5x. I guess it's true
for mv78xx0 too.
Arnaud
--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87fwpym46l@lebrac.rtp-net.org
