Re: What to do with d-i on armel?
On Wed, Jan 17, 2024, at 23:54, Ben Hutchings wrote: > On Wed, 2024-01-10 at 08:34 +0100, Arnd Bergmann wrote: >> >> Qemu versatilepb is probably the most accessible arm926 >> platform, though there are a couple of other armv5/v6 (ast2400, >> ast2500, pxa27x, raspi1ap) in qemu that one should be able >> to get to work as well if anyone found the time. > > We used to have a configuration for Versatile, but it got broken > accidentally; when I found out I removed it because no-one had > complained in 9 months. (Maybe that was a bit quick!) > > We do have a configuration for RPi 0/1, which is supported with images > at <https://raspi.debian.net/> rather than through d-i. > > I don't think anyone has proposed configurations to support the other > platforms. My guess is that the remaining armel users expect a bit of manual work, and tend to have their own kernels. Setting up qemu is rather tricky as well, so I would tend to assume I made a mistake if I can't get the versatilepb kernel to work, not a bug in the package. I definitely put a lot of work into the kernel changes myself that enabled us to have a multiplatform kernel for all armv5 targets as of linux-6.1, and I think it's a bit sad to see this not getting used in Debian at all. >> Since armel userland should work fine with any armhf or >> arm64 kernel, it might still be useful to repackage >> one or both of those for the armel archive and use this >> to have an installation method for armel on modern >> hardware. [Side note: I would also like to see an arm64 >> kernel image added to armhf, it's probably more useful >> than the armmp-lpae kernel in terms of enabling users.] > > We used to do this for amd64 kernels on i386. Then Debian implemented > multiarch and it became an unnecessary waste of build resources. > Still, we are lacking support for adding a "foreign" architecture and > kernel package at installation time. mipsel (now discontinued) also does the same thing by shipping only 64-bit kernels for loongson and octeon hardware, plus a 32-bit kernel for the malta reference system. The situation for mipsel and armhf is similar here, as most modern SoCs really requires running a 64-bit kernel, but you often don't have enough RAM to install the 64-bit userland on small systems. On x86, this is usually not an issue since all current 64-bit machines are still able to boot a 32-bit installer and then get the 64-bit kernel later. Granted, this is much less important on armel today, since there is really no reason to run armel userland on armv7 or armv8 hardware other than for debugging. It would be nice to have an easy way to run the armel installer with an armhf kernel for setting up an armel rootfs in qemu, but debvm probably fills this niche better already. If armhf ever moves to requiring vfpv3-d32 and neon, having an armel installer with an armv7 kernel for the handful of non-neon machines would be helpful though. > (This specific combination would also be hard to support in the current > linux packaging because arm64 and armhf have different kernel > architectures and toolchains, unlike amd64 and i386.) Right, though changing the kernel package to support this sounds easier than changing the installer to use a foreign architecture kernel package. >> At the moment, it is possible to enable support for >> arm1176 (as in bcm2835) in a normal armhf kernel and >> have that boot on armv6k, armv7 and armv8 hardware. >> I actually want to change that in the kernel though: >> Now that we dropped SMP support in armv6, as it now >> makes more sense to have armv6k grouped with armv5 >> and instead have a generic kernel for armel that >> works on bcm2835, versatilepb, at91, kirkwood and >> all the others that one might use. > > If someone wants to make this work in Debian that would be great, but > without a specific maintainer it's not going to happen. Understood. Arnd
Re: What to do with d-i on armel?
On Sun, Jan 7, 2024, at 23:07, Bastian Blank wrote: > Hi > > With Linux 6.6 we dropped the Marvell specific kernel image, as it > was not known to work on any of the available devices. We still have > another armel kernel left, the one of the Raspberry Pi 0 and 1, which > uses an ARMv6 CPU. > > This also removed all the udebs from armel, which makes many d-i > components not longer have fullfiled dependencies and the release stuff > of course acting up. > > Do we have any armel subarch that can be installed via d-i? A few ideas from the kernel's point of view: The most important ARMv5 platform is now probably at91, as Microchip still releases new sam9 chips[1] and is going to keep supporting it for a while. I would guess that the latest ones are not even that far off the performance of the kirkwood/mv78xx0 or bcm2835 parts, but I don't have numbers. Qemu versatilepb is probably the most accessible arm926 platform, though there are a couple of other armv5/v6 (ast2400, ast2500, pxa27x, raspi1ap) in qemu that one should be able to get to work as well if anyone found the time. Since armel userland should work fine with any armhf or arm64 kernel, it might still be useful to repackage one or both of those for the armel archive and use this to have an installation method for armel on modern hardware. [Side note: I would also like to see an arm64 kernel image added to armhf, it's probably more useful than the armmp-lpae kernel in terms of enabling users.] At the moment, it is possible to enable support for arm1176 (as in bcm2835) in a normal armhf kernel and have that boot on armv6k, armv7 and armv8 hardware. I actually want to change that in the kernel though: Now that we dropped SMP support in armv6, as it now makes more sense to have armv6k grouped with armv5 and instead have a generic kernel for armel that works on bcm2835, versatilepb, at91, kirkwood and all the others that one might use. Arnd [1] https://www.microchip.com/en-us/product/sam9x75
Re: [patch 09/14] tmpfs: disallow CONFIG_TMPFS_INODE64 on alpha
On Wed, Feb 10, 2021 at 8:17 PM Linus Torvalds wrote: > > On Wed, Feb 10, 2021 at 5:39 AM Heiko Carstens wrote: > > > > I couldn't spot any and also gave the patch below a try and my system > > still boots without any errors. > > So, as far as I can tell it _should_ be ok to change this. > > So your patch (with the fix on top) looks sane to me. > > I'm not entirely sure it is worth it, but the fact that we've had bugs > wrt this before does seem to imply that we should do this. > > I'd remove the __kernel_ino_t type entirely, but I wonder if user > space might depend on it. I do find > >#ifndef __kernel_ino_t >typedef __kernel_ulong_t __kernel_ino_t; >#endif > > in the GNU libc headers I have, but then I don't find any actual use > of that, so it looks like it may be jyst a "we copied things for other > reasons". I checked debian codesearch to see if there are any users in distro source code and found exactly one instance that will definitely break at compile time: https://sources.debian.org/src/nfs-utils/1:1.3.4-4/support/include/nfs/nfs.h/?hl=99#L99 This is a copy of a kernel header that was removed ten years ago with commit c152292f9ee7 ("nfsd: remove include/linux/nfsd/syscall.h"). The mainline version of that package removed the contents in 2016 in the following release (2.1.1), but debian is still on the previous version (1.3.4) http://git.linux-nfs.org/?p=steved/nfs-utils.git;a=commitdiff;h=fc1127d754578cd1 Someone will have to update the package for Debian, but it seems that would be a good idea anyway. Arnd
Re: bullseye-installer fails on Cubox-i due to networking issue
On Thu, Dec 24, 2020 at 3:38 PM Rainer Dorsch wrote: > > Hi, > > I tried to run the bullseye installer from > > http://ftp2.de.debian.org/debian/dists/bullseye/main/installer-armhf/current/ > images/netboot/SD-card-images/ > > on a cubox-i using a serial console today. > > It seems the network interface does not come up properly: > > ~ # dmesg |grep eth > [5.009246] fec 2188000.ethernet: Invalid MAC address: 00:00:00:00:00:00 > [5.015982] fec 2188000.ethernet: Using random MAC address: 4a: > 0d:a7:66:c1:e6 > [5.028381] mdio_bus 2188000.ethernet-1: MDIO device at address 0 is > missing. > [ 138.479638] fec 2188000.ethernet eth0: Unable to connect to phy > [ 139.674014] fec 2188000.ethernet eth0: Unable to connect to phy > [ 141.218830] fec 2188000.ethernet eth0: Unable to connect to phy > [ 147.400881] fec 2188000.ethernet eth0: Unable to connect to phy > [ 199.375688] fec 2188000.ethernet eth0: Unable to connect to phy > [ 736.031852] fec 2188000.ethernet eth0: Unable to connect to phy > [ 906.069383] fec 2188000.ethernet eth0: Unable to connect to phy > [ 1156.891662] fec 2188000.ethernet eth0: Unable to connect to phy > [ 1266.982998] fec 2188000.ethernet eth0: Unable to connect to phy Which was the last kernel version on which it worked correctly? There were a couple of regressions based on incorrect phy-mode settings after a phy driver changed its behavior in an incompatible way. This should be the relevant hunk in your board, it was merged into linux-5.2: 0672d22a1924 ("ARM: dts: imx: Fix the AR803X phy-mode") diff --git a/arch/arm/boot/dts/imx6qdl-sr-som.dtsi b/arch/arm/boot/dts/imx6qdl-sr-som.dtsi index 4ccb7afc4b35..6d7f6b9035bc 100644 --- a/arch/arm/boot/dts/imx6qdl-sr-som.dtsi +++ b/arch/arm/boot/dts/imx6qdl-sr-som.dtsi @@ -53,7 +53,7 @@ vcc_3v3: regulator-vcc-3v3 { &fec { pinctrl-names = "default"; pinctrl-0 = <&pinctrl_microsom_enet_ar8035>; - phy-mode = "rgmii"; + phy-mode = "rgmii-id"; phy-reset-duration = <2>; phy-reset-gpios = <&gpio4 15 GPIO_ACTIVE_LOW>; status = "okay"; If you have a dtb file from before that change and want to run it on a newer kernel, at least this change is needed. > ~ # > > Not sure if this backtrace is related or even expected: > > [5.626874] Freeing unused kernel memory: 2048K > [5.632309] [ cut here ] > [5.636982] WARNING: CPU: 0 PID: 1 at arch/arm/mm/dump.c:248 > note_page+0x3d0/0x3dc > [5.644576] arm/mm: Found insecure W+X mapping at address 0xf0879000 > [5.650947] Modules linked in: > [5.654033] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.9.0-4-armmp #1 > Debian 5.9.11-1 > [5.661953] Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree) I see the current kernel version here, which is helpful in figuring out the problem, but I don't think the warning is relevant here. I do see two code changes that may be relevant 0da1ccbbefb6 ("net: fec: Fix PHY init after phy_reset_after_clk_enable()") 1e6114f51f9d ("net: fec: fix MDIO probing for some FEC hardware blocks") both of them are backported into linux-5.9.y and are part of 5.9.7 or newer, so you probably have them already, but there is a chance that one of these patches caused a regression, so maybe try a v5.9.0 for comparison. Arnd
Re: [RFC, PATCH, v3.9] default exported asm symbols to zero
On Saturday, December 3, 2016 4:36:37 AM CET Ben Hutchings wrote: > On Fri, 2016-12-02 at 13:40 +0100, Arnd Bergmann wrote: > > With binutils-2.16 and before, a weak missing symbol was kept during the > > final link, and a missing CRC for an export would lead to that CRC > > being treated as zero implicitly. With binutils-2.17, the crc > > symbol gets dropped, and any module trying to use it will fail to > > load. > > > > This sets the weak CRC symbol to zero explicitly, making it defined > > in vmlinux, which in turn lets us load the modules referring to > > that CRC. > > > > The comment above the __CRC_SYMBOL macro suggests that this was > > always the intention, although it also seems that all symbols > > defined in C have a correct CRC these days, and only the exports > > that are now done in assembly need this. > > > > > Signed-off-by: Arnd Bergmann > > --- > > Not sure if this is the correct way of doing it, but this seems trivial > > enough and lets me build the kernel with missing CRCs with any binutils > > version. > > I tried this along with Adam's patch on x86_64, with Debian's binutils > 2.27.51.20161127. The result was that the kernel's __kcrctab held 0 > for several symbols, even though there was type information in asm- > prototypes.h and Module.symvers and the modules had a non-zero CRC for > those symbols. With just Adam's patch, the kernel and modules agreed. Can you be more specific? Which symbols are those? I would have expected modpost to generate Module.symvers from the vmlinux file, so I wonder where that difference comes from. Arnd
Re: [RFC, PATCH, v3.9] default exported asm symbols to zero
On Friday, December 2, 2016 1:59:15 PM CET Geert Uytterhoeven wrote: > On Fri, Dec 2, 2016 at 1:40 PM, Arnd Bergmann wrote: > > With binutils-2.16 and before, a weak missing symbol was kept during the > > 2.26? > > > final link, and a missing CRC for an export would lead to that CRC > > being treated as zero implicitly. With binutils-2.17, the crc > > 2.27?' Yes, serious version number deficiency on my end. Also 4.9 instead of 3.9 in the subject... Arnd
Re: [PATCH] x86/kbuild: enable modversions for symbols exported from asm
On Tuesday, November 29, 2016 9:14:46 AM CET Linus Torvalds wrote: > On Tue, Nov 29, 2016 at 9:10 AM, Linus Torvalds > wrote: > > > > So quite frankly, I don't want to make our kernel sources worse due to > > broken shit tools getting something wrong that we shouldn't even care > > about. > > And yes, I'm on binutils 2.26 (with no issues), so it could be that > it's 2.27 that triggers this. > > We could make the pr_warn_once() mention "broken binutils?" so that > people know why the warning happens. I've tried to get to the bottom of this, but couldn't find anything related to the toolchain version. I've tried binutils 2.23, 2.24, 2.26 and 2.27, and also gcc-7.0, gcc-5.4.1 and gcc-4.9.3, but with today's linux-next, I always get WARNING: EXPORT symbol "mcount" [arch/x86/entry/built-in.ko] version generation failed, symbol will not be versioned. WARNING: EXPORT symbol "mcount" [arch/x86/built-in.ko] version generation failed, symbol will not be versioned. WARNING: EXPORT symbol "cmpxchg8b_emu" [vmlinux] version generation failed, symbol will not be versioned. WARNING: EXPORT symbol "empty_zero_page" [vmlinux] version generation failed, symbol will not be versioned. WARNING: EXPORT symbol "mcount" [vmlinux] version generation failed, symbol will not be versioned. WARNING: EXPORT symbol "cmpxchg8b_emu" [vmlinux] version generation failed, symbol will not be versioned. WARNING: EXPORT symbol "empty_zero_page" [vmlinux] version generation failed, symbol will not be versioned. WARNING: EXPORT symbol "mcount" [vmlinux] version generation failed, symbol will not be versioned. Out of 12 randconfig builds that had CONFIG_MODVERSIONS enabled, all 12 had this problem, though not always with all the symbols. Arnd
Re: [PATCH 21/21] ARM: Kirkwood: Remove DT support
On Friday 21 February 2014 02:00:27 Ben Hutchings wrote: > On Thu, 2014-02-20 at 14:24 +, Ian Campbell wrote: > > On Thu, 2014-02-20 at 14:23 +0100, Andrew Lunn wrote: > [...] > > > What i suspect we will end up doing it dropping the last patch for the > > > moment and ensuring ARCH_KIRKWOOD still supports all the DT machines. > > > I think that just needs care with arch/arm/boot/dts/Makefile. > > > > > > Once we have the last four converted over to DT, you can then do a > > > straight swap, mach-kirkwood for mach-mvebu. > > > > That sounds like a good plan, thanks! > > > > If we are going to do a straight swap I suppose it might as go for a v5 > > multiplatform flavour instead of a mvebu specific one. > [...] > > I would love it if we could do that. > > By the way, we still have the problem that at least one supported > orion5x machine (D-Link DNS-323) only has a ~1.5 MB kernel partition. > So we would probably have to keep a reduced orion5x config for those > machines, alongside the mvebu or multiplatform kernel. orion5x is still some time away from being included in mvebu, 3.16 at the earliest, so it will have to stay separate anyway. My hope is really that we get very little overhead in enabling multiplatform on mvebu compared to a orion5x or kirkwood standalone configuration, so depending on what the platforms have you could end up with e.g. a 1.5MB "mini" multiplatform kernel that includes all machines that have 2MB or less for their kernel partitions and a "everything included" multiplatform kernel for the machines with larger partititons. For instance kirkwood-rd88f6281 has a 2MB uImage partition and everything else seems to have at least 4MB. Arnd -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1438274.4sq9OA90up@wuerfel
Re: [PATCH 21/21] ARM: Kirkwood: Remove DT support
On Friday 21 February 2014 01:47:31 Ben Hutchings wrote: > On Thu, 2014-02-20 at 16:19 +0100, Arnd Bergmann wrote: > > On Thursday 20 February 2014 14:21:10 Ian Campbell wrote: > > > For all I know, the only interesting ixp4xx platforms are the consumer > > products listed on http://www.nslu2-linux.org/, the other ones you support > > are development boards that tend to exist only in very small quantities. > > > > The main limitation would be the amount of installed RAM, which is > > either 32MB or 64MB depending on the machine for these. Running a > > modern Debian with these constraints is probably possible but > > doesn't sound like fun. > > Our most pressing constraint has actually been the size of the kernel > partition in flash, which is only ~1.4 MB on some of the iop32x and > ixp4xx machines (and ~1.5 MB on one of the orion5x machines). We've > modularised as much as possible and turned off some of the features that > are otherwise standard across all Debian architectures. Makes sense. I'm impressed you actually manage to get a modern kernel in 1.5MB and have it boot up a (mostly) full distro. I think we have in the past dropped a subarchitecture from the kernel when it turned out its defconfig could no longer fit within the 2MB of flash it has. > But I got fed up with trying to make it fit, and no-one else stepped up > to maintain the reduced configurations, so the last time iop32x went > over the limit I removed it. As Ian hinted, ixp4xx might follow. Ok. As I mentioned, I believe OpenWRT is really the playground for the remaining ixp4xx users that are doing new installs. Arnd -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1725547.sbei6Aef3A@wuerfel
Re: [PATCH 21/21] ARM: Kirkwood: Remove DT support
On Thursday 20 February 2014 14:21:10 Ian Campbell wrote: > On Thu, 2014-02-20 at 14:53 +0100, Arnd Bergmann wrote: > > On Thursday 20 February 2014 12:51:04 Ian Campbell wrote: > > * ixp4xx is too different from the others and I don't think it's > > possible to turn it over to multiplatform. > > * I see a iop32x_defconfig in svn that you didn't mention here, > > but it's basically the same problem as ixp4xx. > > This is only in Wheezy and not in trunk (which will become Jessie). AIUI > support for these has been dropped for the next version of Debian so > Wheezy is the last one and we don't need to worry about upgrade for > these. Ok, I see. > TBH I'm not sure that ixp4xx isn't in the same boat, I suppose we'll > see. For all I know, the only interesting ixp4xx platforms are the consumer products listed on http://www.nslu2-linux.org/, the other ones you support are development boards that tend to exist only in very small quantities. The main limitation would be the amount of installed RAM, which is either 32MB or 64MB depending on the machine for these. Running a modern Debian with these constraints is probably possible but doesn't sound like fun. ;-) Also, the upstream kernel port isn't that well maintained, a lot the development seems to have happened in OpenWRT and not mainlined, including a dozen new machines that were already ported in 2009. Then again, Martin Michlmayr has instructions for running Wheezy on the 32MB nslu2, and I guess as long as he's interested in the hardware, new versions of Debian will keep running on it. > > The embedded mxs family is probably most interesting among these, > > but there is also a community around the wondermedia stuff, which is > > used in cheap tablets and laptops. > > Interesting. I don't know how many of these are supported by Debian -- > mostly these things get added when someone acquires one and scratches > that itch. > > I suppose if we could remove at least one existing flavour in favour of > a v5 multiplatform config then there probably wouldn't be many > objections to doing that. That will probably come as a natural progression after kirkwood gets replaced with mvebu. > > As I said, it may be useful to do multiplatform support for MACH_ORION5x, > > but for MACH_KIRKWOOD, we have come too far now to turn back. > > Understood. It sounds like mach-kirkwood is very close to being > removable altogether though (by migrating the last few boards to > mach-mvebu), which would make distro upgrades much simpler, since we can > just do a straight swap rather than trying to figure out which one we > need. Yes, makes sense. Arnd -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/35719313.JyFlzSVKnx@wuerfel
Re: [PATCH 21/21] ARM: Kirkwood: Remove DT support
On Thursday 20 February 2014 12:51:04 Ian Campbell wrote: > On Thu, 2014-02-20 at 13:18 +0100, Andrew Lunn wrote: > > On Thu, Feb 20, 2014 at 11:34:36AM +, Ian Campbell wrote: > Debian has a single v7 flavour, armmp which uses the multi platform > stuff. (actually there is a second armmp-lpae, but lets ignore that) > > I'm only really concerned about the v5 stuff here. Debian has multiple > v5 flavours: ixp4xx, kirkwood, mv78xx0, orion5x and versatile. Unfortunately, this selection include multiple platforms that we don't plan to (ever) support in a multiplatform kernel, while a lot of platforms you don't currently support are already enabled or will be at some point. * ixp4xx is too different from the others and I don't think it's possible to turn it over to multiplatform. * I see a iop32x_defconfig in svn that you didn't mention here, but it's basically the same problem as ixp4xx. * kirkwood/mv78xx0/orion5x are essentially one platform and work in progress. * versatile is easy to do as multiplatform, I just haven't gotten around to do it. ARMv5 platforms that are already working with ARCH_MULTIPLATFORM: * freescale mxc (i.mx21 and i.mx25) * freescale mxs (i.mx23 and i.mx28) * st-ericsson Nomadik * st-ericsson u300 * st spear3xx * st spear6xx * TI NSpire * VIA/Wondermedia vt85xx/wm85xx/wm86xx The embedded mxs family is probably most interesting among these, but there is also a community around the wondermedia stuff, which is used in cheap tablets and laptops. > > What this patchset does is also make mach-mvebu part of the multi v5 > > kernel. So you just need one kernel for all ARM v5 machines which are > > part of multi v5. The long term goal is that you need just two 32 ARM > > kernels, multi v5 and multi v7. However orion5x and mv76xx0 are not > > yet part of theses, so we are not there yet. > > So in answer to my question, on v5 ARCH_KIRKWOOD and ARCH_MVEBU *cannot* > coexist in the same binary? That has been the plan for the kirkwood migration for the last few years, yes. The idea is that every kirkwood machine that anyone is interested in should be supported by ARCH_MVEBU, and we can keep ARCH_KIRKWOOD for the ones we don't care about until it is just dropped. Same for orion5x, dove and mv78xx0, just a different schedule for moving them over. Now in theory, we could have them supported in a multiplatform kernel, but that would mean extra work that we planned to avoid by converting them to DT first. As I said, it may be useful to do multiplatform support for MACH_ORION5x, but for MACH_KIRKWOOD, we have come too far now to turn back. Arnd -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2127012.W6WnQnXmRo@wuerfel
Re: [PATCH 21/21] ARM: Kirkwood: Remove DT support
On Thursday 20 February 2014 13:18:21 Andrew Lunn wrote: > > What this patchset does is also make mach-mvebu part of the multi v5 > kernel. So you just need one kernel for all ARM v5 machines which are > part of multi v5. The long term goal is that you need just two 32 ARM > kernels, multi v5 and multi v7. However orion5x and mv76xx0 are not > yet part of theses, so we are not there yet. BTW, if converting enough of orion5x to DT takes too long to deprecate that platform any time soon, I'd prefer moving it over to multiplatform while keeping the legacy board files in there. That should get substantially easier once mv78xx0, kirkwood and dove have been dealt with and we can collapse plat-orion and mach-orion5x into one directory. > > IOW that all of the platforms currently supported by the > > Debian kirkwood flavour remain supportable in the same binary after this > > change. It looks like it should be to me, but I'm not 100% sure. > > If you don't support LaCie 2Big and 5Big, HP t5325 thin client and > Marvell OpenRD then yes, you have one binary. That binary could > potentially support over v5 machines, but i have no idea what ARM > machines Debian actually supports. Is there a list somewhere? http://anonscm.debian.org/viewvc/kernel/releases/linux/3.12.9-1/debian/config/armel/config.kirkwood?view=markup just lists all kirkwood machines as enabled, but that of course doesn't meant they are actually working or supported. Arnd -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/11515265.X2qOAjvHY6@wuerfel
Re: [Arm-netbook] getting allwinner SoC support upstream (was Re: Uploading linux (3.9.4-1))
On Thursday 06 June 2013, Maxime Ripard wrote: > So yes, Allwinner has an evil vendor tree (c), with a solution similar yet > inferior (because not generic enough) to the device tree, but they show > interest on going down the mainline road. Right, and of course there is nothing special about that, everybody starts out with they own even vendor tree (c), and as hardware support gets merged upstream, the diff gets smaller, even though the code in the mainline kernel is normally very different from what they started out with. Chances are actually that the Allwinner (A10/A13/A20, not A31) platform may end up being the first modern one that is fully supported upstream including a GPU driver, since it is one of the obvious targets for the reverse-engineering efforts. Ironically (given NVIDIA's reputation), the Tegra platform is the strongest competitor I see in that race at the moment. For all I can tell, things are progressing nicely, given that it's currently a volunteer effort. If anyone needs things to move faster, I'd recommend them to send money to free-electrons.com. Arnd -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130606.53780.a...@arndb.de
Re: trying to use virtio with the wheezy installer on arm versatile oops
On Wednesday 26 September 2012, Arnaud Patard wrote: > Torben Hohn writes: > > > i tried to use virtio inside qemu-system-arm emulating versatile. > > > > getting this kernel oops: > > > > [ 341.274760] pgd = cd818000 > > x > > [ 341.274940] [44000412] > > *pgd=qj > > [ 341.275424] Internal error: Oops: 805 [#1] > > [ 341.275756] Modules linked in: virtio_pci(+) virtio_ring virtio ohci_hcd > > ehci_hcd usbcore smc91x mii usb_common > > [ 341.276703] CPU: 0Not tainted (3.2.0-3-versatile #1) > > [ 341.277479] PC is at vp_reset+0xc/0x5c [virtio_pci] > > [ 341.277834] LR is at register_virtio_device+0x44/0x8c [virtio] > > ok, easy to reproduce. Will look at that. > > Can you please open a bug report to keep track of this bug ? > Sorry, It's really my fault for not updating the patches I did back then. The basic problem of course is missing I/O space support in the versatile platform. The implementation would be done slightly differently today, but basically my patches are still needed. Arnd -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201209271421.53817.a...@arndb.de
Bug#340508: missing modules on s390/s390x (mkinitramfs for 2.6.14)
Am Sonntag 04 Dezember 2005 16:31 schrieb Frans Pop: > Reason is that dasd_mod needs an option to tell it which dasd devices > should be used. I've written a script that creates a config file for > modprobe in /etc/modprobe.d/. > The script is a first approximation and probably needs cleaning up. > Background info and some possible issues are documented in the script. Note that it is not required to pass the list of dasd devices when loading the module. You also have the option of enabling devices through sysfs or with one of the tools from s390tools (I forgot the name of the binary), which is probably easier to do from initramfs. Arnd <>< -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]