Re: Bug#772953: Enable several Kconfigs to support OMAP5432 uEVM devboard
On Tue, Dec 23, 2014 at 7:44 PM, Ian Campbell wrote: > On Tue, 2014-12-23 at 16:27 +0800, Chen Baozi wrote: >> I have a glance at the kernel’s installer configs and tried the netboot >> without any modification. Some work should be done to make debian-installer >> support OMAP5 uEVM (e.g., ethernet driver etc). > > Right, those should be listed in e.g. > debian/installer/armhf/modules/armhf-armmp/nic-modules. > >> By waiting the kernel building with some initial attempted configs added, >> just one question to ask. I looked through the >> debian/installer/armhf/modules/armhf-armmp/, but it looks like none of >> files is about regulator modules. However, according to my previous >> experience, missing regulator driver modules is the main reason that >> the old debian kernel doesn’t support OMAP5 uEVM. How does debian-installer >> deal with this situation (if it does need extra regulator drivers included?) > > Long term its a bit of an open question what we do wrt modules such as > regulators, clocks, pinctrl etc. > > So far we have been a bit lucky: either such things are so central to > the platform that it is acceptable (at least for now) to just build them > into the main kernel binary by making them =y (e.g. CONFIG_I2C_S3C2410 > which is for the main power controller on arndale) or they are closely > associated with some particular device and it makes sense to put them in > that udeb (e.g. phy-exynos5250-sata in sata-modules, or phy-sun4i-usb in > usb-modules). > > Eventually I expect that we will end up creating separate udebs for > these things, but I'm hoping that we can defer that until at least > Stretch to avoid needing to mess around with any more new packages for > Jessie. > > If uEVM has some module which either shouldn't be built in or isn't > obviously associated with a particular device let us know what it is and > we can have a think about how best to approach it. > > One thing I've played with, and I'm not sure if this is acceptable or > not, is to put core drivers which aren't =y into the kernel-image udeb > itself. I'm not really sure if that's a good idea, we don't currently do > this for anything AFAIK, but it's perhaps an option. With the attached patch applied, debian installer (tested with network-console) can support OMAP5's ethernet driver and external MicroSD card. Note that I added related regulator & phy entries to files that mainly writes the modules which use them, since there is no file dedicated to those modules. Baozi. --- diff -Nru linux-3.16.7/debian/installer/armhf/modules/armhf-armmp/mmc-modules linux-3.16.7-ckt2/debian/installer/armhf/modules/armhf-armmp/mmc-modules --- linux-3.16.7/debian/installer/armhf/modules/armhf-armmp/mmc-modules 2014-09-21 20:04:21.0 + +++ linux-3.16.7-ckt2/debian/installer/armhf/modules/armhf-armmp/mmc-modules 2014-12-26 03:16:02.0 + @@ -4,3 +4,5 @@ omap_hsmmc sunxi-mmc dw_mmc-exynos +pbias-regulator +palmas-regulator diff -Nru linux-3.16.7/debian/installer/armhf/modules/armhf-armmp/usb-modules linux-3.16.7-ckt2/debian/installer/armhf/modules/armhf-armmp/usb-modules --- linux-3.16.7/debian/installer/armhf/modules/armhf-armmp/usb-modules 2014-12-23 08:10:49.0 + +++ linux-3.16.7-ckt2/debian/installer/armhf/modules/armhf-armmp/usb-modules 2014-12-25 02:56:08.0 + @@ -1,8 +1,13 @@ #include phy-sun4i-usb dwc3-exynos ohci-exynos ehci-exynos phy-exynos-usb2 ci_hdrc_imx +phy-mxs-usb +dwc3-omap +ohci-omap3 +ehci-omap +phy-omap-usb2 +phy-ti-pipe3 -- 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/caeyzweflwsbbpd-yrcxcplpfbupsahc4ycwmtu1r3xdmdou...@mail.gmail.com
Bug#773763: task-mate-desktop: Should install libreoffice-gnome
Samuel Thibault, le Wed 24 Dec 2014 17:49:08 +0100, a écrit : > This would probably need to be added to other desktop tasks too: > task-lxde-desktop, task-xfce-desktop, task-cinnamon-desktop, I forgot to mention the additional sizes for those: LXDE: 350KiB XFCE: 350KiB Cinnamon: it's actually already getting installed. Samuel -- 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/20141226104354.GC3060@type
Re: Bug#772953: Enable several Kconfigs to support OMAP5432 uEVM devboard
On Fri, Dec 26, 2014 at 6:43 PM, Chen Baozi wrote: > On Tue, Dec 23, 2014 at 7:44 PM, Ian Campbell wrote: >> On Tue, 2014-12-23 at 16:27 +0800, Chen Baozi wrote: >>> I have a glance at the kernel’s installer configs and tried the netboot >>> without any modification. Some work should be done to make debian-installer >>> support OMAP5 uEVM (e.g., ethernet driver etc). >> >> Right, those should be listed in e.g. >> debian/installer/armhf/modules/armhf-armmp/nic-modules. >> >>> By waiting the kernel building with some initial attempted configs added, >>> just one question to ask. I looked through the >>> debian/installer/armhf/modules/armhf-armmp/, but it looks like none of >>> files is about regulator modules. However, according to my previous >>> experience, missing regulator driver modules is the main reason that >>> the old debian kernel doesn’t support OMAP5 uEVM. How does debian-installer >>> deal with this situation (if it does need extra regulator drivers included?) >> >> Long term its a bit of an open question what we do wrt modules such as >> regulators, clocks, pinctrl etc. >> >> So far we have been a bit lucky: either such things are so central to >> the platform that it is acceptable (at least for now) to just build them >> into the main kernel binary by making them =y (e.g. CONFIG_I2C_S3C2410 >> which is for the main power controller on arndale) or they are closely >> associated with some particular device and it makes sense to put them in >> that udeb (e.g. phy-exynos5250-sata in sata-modules, or phy-sun4i-usb in >> usb-modules). >> >> Eventually I expect that we will end up creating separate udebs for >> these things, but I'm hoping that we can defer that until at least >> Stretch to avoid needing to mess around with any more new packages for >> Jessie. >> >> If uEVM has some module which either shouldn't be built in or isn't >> obviously associated with a particular device let us know what it is and >> we can have a think about how best to approach it. >> >> One thing I've played with, and I'm not sure if this is acceptable or >> not, is to put core drivers which aren't =y into the kernel-image udeb >> itself. I'm not really sure if that's a good idea, we don't currently do >> this for anything AFAIK, but it's perhaps an option. > > With the attached patch applied, debian installer (tested with > network-console) > can support OMAP5's ethernet driver and external MicroSD card. > > Note that I added related regulator & phy entries to files that mainly writes > the modules which use them, since there is no file dedicated to those > modules. > > Baozi. > > --- > diff -Nru linux-3.16.7/debian/installer/armhf/modules/armhf-armmp/mmc-modules > linux-3.16.7-ckt2/debian/installer/armhf/modules/armhf-armmp/mmc-modules > --- linux-3.16.7/debian/installer/armhf/modules/armhf-armmp/mmc-modules > 2014-09-21 20:04:21.0 + > +++ linux-3.16.7-ckt2/debian/installer/armhf/modules/armhf-armmp/mmc-modules > 2014-12-26 03:16:02.0 + > @@ -4,3 +4,5 @@ > omap_hsmmc > sunxi-mmc > dw_mmc-exynos > +pbias-regulator > +palmas-regulator > diff -Nru linux-3.16.7/debian/installer/armhf/modules/armhf-armmp/usb-modules > linux-3.16.7-ckt2/debian/installer/armhf/modules/armhf-armmp/usb-modules > --- linux-3.16.7/debian/installer/armhf/modules/armhf-armmp/usb-modules > 2014-12-23 08:10:49.0 + > +++ linux-3.16.7-ckt2/debian/installer/armhf/modules/armhf-armmp/usb-modules > 2014-12-25 02:56:08.0 + > @@ -1,8 +1,13 @@ > #include > phy-sun4i-usb > dwc3-exynos > ohci-exynos > ehci-exynos > phy-exynos-usb2 > ci_hdrc_imx > +phy-mxs-usb ^ Oops, this is introduced by '-ckt2', not by me... > +dwc3-omap > +ohci-omap3 > +ehci-omap > +phy-omap-usb2 > +phy-ti-pipe3 -- 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/caeyzweet7al4pqglvxkr41fx1ohfy+gymp9w7zqklbel7bh...@mail.gmail.com
Bug#773991: flash-kernel: Fails when mtdblock kernel module isn't loaded
Package: flash-kernel Version: 3.28 Severity: normal Hello, on my ReadyNAS 104 (see database entry included below) a typical run after a fresh reboot looks as follows: $ sudo flash-kernel Installing armada-370-netgear-rn104.dtb into /boot/dtb-3.16.0-4-armmp Taking backup of dtb-3.16.0-4-armmp. Installing new dtb-3.16.0-4-armmp. flash-kernel: installing version 3.16.0-4-armmp /dev/mtdblock2 is not a block device After $ sudo modprobe mtdblock it works just fine. I wonder if flash-kernel should be smart enough to load the module itself. Best regards Uwe -- System Information: Debian Release: 8.0 APT prefers testing APT policy: (500, 'testing') Architecture: armhf (armv7l) Kernel: Linux 3.16.0-4-armmp (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages flash-kernel depends on: ii debconf [debconf-2.0] 1.5.55 ii devio 1.2-1 ii initramfs-tools0.116 ii linux-base 3.5 ii ucf3.0030 flash-kernel recommends no packages. Versions of packages flash-kernel suggests: ii u-boot-tools 2014.10+dfsg1-2 -- Configuration Files: /etc/flash-kernel/db changed: Machine: NETGEAR ReadyNAS 104 DTB-Id: armada-370-netgear-rn104.dtb DTB-Append: yes Mtd-Kernel: uImage Mtd-Initrd: minirootfs U-Boot-Kernel-Address: 0x0400 U-Boot-Initrd-Address: 0x0500 Required-Packages: u-boot-tools -- debconf information excluded -- 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/20141226193034.2133.54782.report...@crater.defre.kleine-koenig.org
Bug#773890: flash-kernel: No entry for BeagleBone Black when running 3.18 kernel
On Wed, 2014-12-24 at 12:42 -0800, Vagrant Cascadian wrote: > Package: flash-kernel > Version: 3.28 > Severity: normal > Tags: patch > > When running the 3.18 kernel from experimental on a BeagleBone Black, > /proc/device-tree/model contains "TI AM335x BeagleBone Black". With > the 3.16 kernel from Jessie, it contains "TI AM335x BeagleBone". > > The following patch adds an additional Machine entry for the more > specific name. Not sure if there's a more elegant way to add an entry > that's simply a duplicate of another entry with a different Machine id. It's permissible to have multiple Machine entries in a stanza, so if the only difference is that field then it's fine to just add a new one (a bunch of the kirkwood TS-xxx enties follow this pattern since they have a boardfile name and a DTB name). I wonder though if the DTB-Id field should be different? I think not on the basis that the difference is down to git.kernel.org/linus/9a15fff05b702c3ea29ae64db0d3ff0355431eab If you can confirm that is the case I can easily sort that out as I commit it. I wonder if 9a15fff ought to be backported to the kernel in Jessie and correspondingly whether this flash-kernel change ought to happen in Jessie too (otherwise I'd just put it in experimental for the rest of the freeze). 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/1419624098.13595.9.ca...@debian.org
Bug#773890: flash-kernel: No entry for BeagleBone Black when running 3.18 kernel
On 2014-12-26, Ian Campbell wrote: > On Wed, 2014-12-24 at 12:42 -0800, Vagrant Cascadian wrote: >> The following patch adds an additional Machine entry for the more >> specific name. Not sure if there's a more elegant way to add an entry >> that's simply a duplicate of another entry with a different Machine id. > > It's permissible to have multiple Machine entries in a stanza, so if the > only difference is that field then it's fine to just add a new one (a > bunch of the kirkwood TS-xxx enties follow this pattern since they have > a boardfile name and a DTB name). Ok, then I think we should simply add the second Machine entry to the same stanza... > I wonder though if the DTB-Id field should be different? I think not on > the basis that the difference is down to > git.kernel.org/linus/9a15fff05b702c3ea29ae64db0d3ff0355431eab If you change the DTB-Id to be for the BeagleBone white, it will break on BeagleBone Black running kernels 3.16 or earlier, including the kernel shipped on the BeagleBone Black eMMC by the vendor, making it harder to "upgrade" to a pure Debian system. I'm not sure that the BeagleBone white is actually supported in Debian's kernel or in Debian's flash-kernel... so it doesn't make much sense to add support now, when that would break a currently supported platform. > I wonder if 9a15fff ought to be backported to the kernel in Jessie and > correspondingly whether this flash-kernel change ought to happen in > Jessie too (otherwise I'd just put it in experimental for the rest of > the freeze). I think it would make sense to support both Machine IDs for the BeagleBone Black in Jessie's flash-kernel regardless of weather the change was backported to the kernel, as it can result in an unbootable system: Running 3.16.x, install linux-image-3.18*, flash-kernel updates the boot script without complaint. Reboot to 3.18.x. Remove linux-image-3.18*, flash-kernel fails to update /boot/boot.scr, system is unbootable... Basically long-running inability to distinguish between the white and black models make this impossible to "get right" for both, but I believe there are far more BeagleBone Black systems in the wild, and is better supported out of the box. It would be better to require manual intervention on the BeagleBone white models than the other way around. live well, vagrant signature.asc Description: PGP signature
Bug#772855: installation-reports: unable to connect to a wifi network on channel 13
On Sat, 2014-12-13 at 21:51 +0100, Lukasz Stelmach wrote: > On 11.12.2014 21:57, Ben Hutchings wrote: > > On Thu, 2014-12-11 at 19:28 +0100, Łukasz Stelmach wrote: > >> Package: installation-reports > >> Severity: important > >> > >> Dear Maintainer, > >> > >> I downloaded Debian 7.7 installation image[1]. > >> > >> I followed the installation procedure and chose wlan0 networki interface > >> when asked to configure the primary network interface. Then there was no > >> WLAN on the list of availble networks. It appeared after I changed > >> channel on my AP from 13 to 1. > >> > >> I suspect the reason of this problem MAY be the default regulatory > >> settings of wifi stack/card driver in the Linux kernel if it is prepared > >> for the USA where, according to Wikipedia[2], the channel may be used > >> only under certain conditions. > >> > >> [1] debian-7.7.0-amd64-i386-netinst.iso (md5 > >> afc576c3886f9abab9ba886c4cd51a88) > >> [2] https://en.wikipedia.org/wiki/List_of_WLAN_channels > > > > The default is to use the 'world' regulatory domain, not the US domain. > > This still allows scanning for and using an AP on all channels; it just > > doesn't allow transmissions above channel 11 until an AP is found. > > > > However this might be overridden based on the country setting of the > > wireless network adapter. > > That's strange, apparently the card has been prepared to be for > Australians, who can use channel 13. > > --8<---cut here---start->8--- > Dec 13 18:15:35 main-menu[392]: INFO: Menu item 'ethdetect' selected > Dec 13 18:15:36 kernel: [ 112.707682] cfg80211: Calling CRDA to update world > regulatory domain > Dec 13 18:15:36 kernel: [ 112.716130] ath9k :03:00.0: setting latency > timer to 64 > Dec 13 18:15:36 kernel: [ 112.723098] ath: EEPROM regdomain: 0x21 > Dec 13 18:15:36 kernel: [ 112.723101] ath: EEPROM indicates we should expect > a direct regpair map > Dec 13 18:15:36 kernel: [ 112.723103] ath: Country alpha2 being used: AU > Dec 13 18:15:36 kernel: [ 112.723104] ath: Regpair used: 0x21 > Dec 13 18:15:36 kernel: [ 112.726937] ieee80211 phy0: Selected rate control > algorithm 'minstrel_ht' > Dec 13 18:15:36 kernel: [ 112.727445] Registered led device: ath9k-phy0 > Dec 13 18:15:36 kernel: [ 112.727450] ieee80211 phy0: Atheros AR9485 Rev:1 > mem=0xc90011a0, irq=30 > Dec 13 18:15:38 kernel: [ 115.279119] ADDRCONF(NETDEV_UP): wlan0: link is > not ready > Dec 13 18:15:40 main-menu[392]: INFO: Menu item 'netcfg' selected > --8<---cut here---end--->8--- This driver uses a table of maximum TX power per channel in the wireless controller's EEPROM. It looks like when the 'regpair' value is 0x21 then it expects to find ETSI rules for the 2.4 GHz band, allowing use of channel 13, but it might not. Does the interface work on channel 13 after installation? (And assuming that you install crda.) [...] > > Also please provide the system log from the installer. > > There is probablo nothing more interesting there than the above excerpty > but I am attaching it anyway. Right, I didn't see any extra clues there. Ben. -- Ben Hutchings It is easier to change the specification to fit the program than vice versa. signature.asc Description: This is a digitally signed message part
Re: Providing (armhf) u-boot images together with d-i images?
On 2014-12-26, Karsten Merker wrote:
> On Tue, Dec 23, 2014 at 02:17:16PM -0800, Vagrant Cascadian wrote:
>> On 2014-12-23, Karsten Merker wrote:
>> I don't think it's possible yet to have the device-independent parts
>> working with *all* platforms (at least for Jessie), but we can get close
>> with a few relatively simple workarounds:
>>
>> Some of the issues with "bootscr.mainline_common" are inconsistancies
>> across platforms with the u-boot console settings (particularly the baud
>> rate not being appended)
...
> I do not know what the default environment on those platforms
> looks like, but assuming that they define the fdtfile environment
> variable, how about adding stanzas like
>
> if test "${fdtfile}" = "am335x-boneblack.dtb" ; then
> (set the necessary environment variables)
> fi
>
> to bootscr.mainline_common for those special cases?
For the default serial console, yes, this could work (at least for
imx6q-wandboard.dtb and imx6q-cubox-i.dtb). For setting the framebuffer
or other console, it would still probably require manually (or through
uEnv.txt) setting the console variable.
It would get increasingly more complicated the more boards get supported
over time, but at the moment we're looking at only a handful of boards.
Alternately, could also check for specific values of console/baudrate,
which could support broader classes of systems:
# wandboard, cubox-i and possibly other imx systems may need to append
# the baud rate.
if test "${console}" = "ttymxc0" && test -n "${baudrate}" ; then
setenv console=${console},${baudrate}
fi
This way, if the user has manually configured the console value somehow
(such as console=tty0 for framebuffer), it doesn't blindly overwrite it
just because it detects a certain ${fdtfile}.
That doesn't address the conditionals that the BeagleBone Black would
need, which could potentially boot off of eMMC or an inserted SD card,
and thus ${devnum} and related variables would need to be set
conditionally...
I had planned on patching u-boot to emulate the config_distro_bootcmd
for BeagleBone Black (like with wandboard/cubox-i), but was unable to
resolve incompatible uses of ${bootpart}.
> Regarding uEnv.txt: is that file automatically read by the
> default environment of those platforms before executing boot.scr,
> or does boot.scr have to explicitly source uEnv.txt?
The BeagleBone Black, Wandboard* and CuBox-i systems should all load
uEnv.txt before the bootscript, at least with the u-boot in Debian. I've
added some patches for uEnv.txt support and changed the order on some of
those to make sure that they worked more-or-less consistantly.
I tried getting uEnv.txt support into mainline u-boot's
config_distro_bootcmd.h, but didn't get much favorable feedback about
that:
http://lists.denx.de/pipermail/u-boot/2014-October/190843.html
Though I do think it's generally useful to be able to make "generic"
images and tweak them with a few uEnv.txt variables to set things that
are not detectable.
>> The netboot images here seem more like the mini.iso netboot images on
>> x86, though I've tested several armhf installs with the boot.scr,
>> kernel, initrd, dtb all downloaded via TFTP (more like the pxe boot
>> images on x86).
...
> I have added support for building a netboot.tar.gz similar to the
> i386/amd64 PXE one in V2 of the patchset.
Excellent!
live well,
vagrant
signature.asc
Description: PGP signature
