Re: Objective of OpenWRT/x86?
On Fri, Apr 28, 2023 at 12:04:15PM -0600, Philip Prindeville wrote: > > > On Apr 26, 2023, at 2:17 PM, Elliott Mitchell wrote: > > > > Well, was a specific objective ever chosen for the x86 version of > > OpenWRT? > > Does it need one? As the most ubiquitous hardware out there for many users, > why would we need to box it in? > > Someone might want to throw a generic image onto a PC they have lying around > until they decide it's worth bringing up specialized hardware... going out an > buying it, building an image, installing it, troubleshooting it, etc. The usual solution is to make most things modules. Then only the portions needed for the particular situation get loaded. Having a few specifically targeted builds could also accomplish the goal. > > I can state my goal/hope for OpenWRT/x86. The *WRT Linux distributions > > were so named for originally targeting the LinkSys WRT54G. This was a > > small AP, so one might expect builds to be for small APs. By today's > > standards 128MB RAM and 16MB of storage is relatively small. > > Yeah, we had a discussion some years ago about "FAT" vs. "SKINNY" platforms > that never went anywhere. All of the AMD64 platforms were FAT. s/FAT/OBESE/ > Having robust hardware that you can prototype on, including CPU or memory > hungry development, allows us to prove the value of new capabilities that > might be ubiquitous in the next generation of COTS and SoHo routers. I've been repeatedly typing I've got no objection to having the jumbo configurations. My objection is to the lack of smaller configurations. > After all, the BoM for an extra GB of DRAM is literally pennies in large > production volumes. If you're willing to accept the quality of memory in that price range. > BTW, I run OpenWrt for its firewall capabilities... None of my boxes actually > has wireless hardware at this point, and I use a few Ubiquiti AP-AC-Pro's or > U6-LR's scattered around the house. I can see that. Fun part with VMs is being able to reboot the system, but NAT connections remaining connected. > The rule of thumb when I worked at MIT on the X Window System, was that > what's the top-of-the-line workstation today will be "budget" hardware 3-4 > years out, so to not worry about hardware constraints because by the time you > release stable, production quality software, the hardware will have gone > through one or two evolutions... > > Today's one-off advanced prototyping platform is tomorrow's BestBuy > budget/clearance item... Quite true. There is still a need to try to restrain memory consumption. > > Since this network is in the moving towards the server phase, the AP drew > > my attention. Turns out all of the hardware of an AP is available for > > servers, though in distinct form-factors. If the server has a full > > IOMMU, the hardware can be directed to a VM and you have a proper AP in a > > VM. > > "Moving towards the server phase"? I'm not getting what you mean by this. Any reasonably sized network will have a phase of things moving towards the server room and a phase of things moving towards the desktop (or phone). You can try to damp out the oscillations, but both phases will be there. Right now things are moving towards the center for me. > See above: the radios and antennae I can get as add-ons for a Xeon-D 1U pizza > box or even an APU6 mPCIe slot are vastly inferior to what ODM purpose-built > hardware like an U6-LR can do in terms of cost and performance. > > Um... you can't "virtualize" WiFi in any VM I've ever seen. You can though pass PCIe devices to a VM. The hardware will physically attach to the control host, but a VM will be able to do anything it wants with it. > > Problem is instead of the recommended 128MB memory, 16MB of storage > > (https://openwrt.org/supported_devices/432_warning) the virtualization > > examples (https://openwrt.org/docs/guide-user/virtualization/start) are > > suggesting massively more memory. 256MB (small Xen example), 512MB > > (VMware OpenWRT/15.05) or 1GB (Qemu examples). > > Sorry, why is this a "problem"? > > I spent $1100 on a Xeon-D box with 128GB of DRAM, 16 hyper threaded cores, > and 2TB of NVMe. If those numbers are to be believed (which is now suspect), it means a *requirement* to devote that much to network operations. Not being a requirement means one could use the memory for other things. Or I could allow more than that to do extra complicated network things. > > I don't yet have a full handle on the issues. My first thought was the > > large sizes come from early stage development and not wanting to bother > > with memory limitations. Another possibility is this comes from simply a > > thought pattern of "x86 memory is cheap, just throw memory at it". > > You're looking at it backwards. > > Think of it as "what could I do if I have more RAM and CPU?" Rather a lot of things completely unrelated to the things you listed. Having lower estimates provides better
Re: Objective of OpenWRT/x86?
As you point out elsewhere, this "optional builtin modules" problem is typically solved with bootstrapping initrd images. But adding something like initramfs-tools or dracut into OpenWrt would be over complicating things, since the current x86/64 images seem to suit everyone. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Objective of OpenWRT/x86?
On Sat, Apr 29, 2023 at 3:29 AM Elliott Mitchell wrote: > I'm looking at the list of built-in drivers and seeing many which > will perhaps only be used by 25% of installations. That figure seems hypothetical, but you would propose to break 25% of users installations for insignificant memory reductions? >>> Problem is instead of the recommended 128MB memory, 16MB of storage >>> (https://openwrt.org/supported_devices/432_warning) the virtualization >>> examples (https://openwrt.org/docs/guide-user/virtualization/start) are >>> suggesting massively more memory. 256MB (small Xen example), 512MB >>> (VMware OpenWRT/15.05) or 1GB (Qemu examples). >> It makes more sense to make a new lightweight VM profile rather than >> chopping stuff out of the generic ones. >> But is one needed, and how much memory would be saved? Have you >> actually tried running the "x86/64" image with 128MB ram under QEMU? >> Default 22.03.4 install shows 45MB used. With "wpad-openssl" and >> "kmod-mac80211-hwsim", its up to 53MB. These requirements rise >> depending on load. I'm guessing those memory figures in the wiki docs >> are just arbitrary, showing people they can run cool stuff. > That could be. Might simply be the wiki needs to have numbers adjusted > downwards to reflect how much memory a reasonable installation needs > instead of an advanced doing all the things installation. This misunderstanding seems to be what drove this discussion and patch series, along with wanting to cleanup "legacy" functionality others still use. Granted, there doesn't seem to be a x86/64 "minimum reqiurements" requirements in the Wiki which would help clear this up. Probably because they are so low that people don't really care. The forums also have a few questions asking about minimum requirements, but the answers are vague. > As far as creating a slimmed-down VM kernel configuration. Removing AGP > support doesn't gain much itself, but then disabling DRM support saves > 2203648 bytes. Turning USB support into modules is another 2MB. I've > gotten a potentially viable Xen kernel down to 23MB, but I hope to push > at least somewhat further. I'm not a developer, but these gains don't seem significant enough to justify a new virt profile when the current generic x86/64 images will simply work out of the box. The only real benefits of a slimmed down virt specific kernel would be a reduced attack surface (even though the code for undetected devices should be inactive). But to really commit to that minimal security footprint would require seperate virt profiles for every VM platform etc. A lot of work to undertake for a contemplative discussion... - Joe ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 9/9] kernel/x86: remove DRM support
On Thu, Apr 27, 2023 at 11:21:28AM +0200, Thibaut wrote: > > > Le 27 avr. 2023 à 02:11, Elliott Mitchell a écrit : > > > > On Thu, Apr 27, 2023 at 12:50:52AM +0200, Stefan Lippers-Hollmann wrote: > >> On 2023-04-19, Elliott Mitchell wrote: > >>> Direct Rendering Manager is mainly for running X (possibly Wayland > >>> too). As OpenWRT is meant for networking devices, there is no need > >>> for the support to be present. > >> > >> That is only partially true, the Linux kernel is making a strong push > >> away from deprecated (FB_*) graphics drivers to DRM based ones, with > >> kernel based mode setting this is getting more (any) attention for > >> console support as well. Even without getting anywhere near X/ Wayland, > >> there is more than just a 80x25 tty on real hardware (and even VMs). > > > > Real x86 hardware often has the capability to use a serial port as > > console. The conventional UEFI implementation fully supports this use > > case. I can well believe a number of manufacturers disabling the > > functionality though. > > > > VMs *can* have more than a 80x25 tty. By the time you're getting to 4 > > or more VMs you should be thinking about disabling the functionality due > > to the heavy overhead (unless the OS in the VM doesn't support serial > > consoles). > > You seem to assume that x86 is only/mainly run on VMs. > That is not necessarily the case, and I see no reason to degrade device > support that way. Okay, as already stated there are at least two solutions to this. 1> Turn most functionality into modules and include support for runtime loading of kernel modules. 2> Create more kernel variants for OpenWRT/x86. > Would you mind documenting the measurable gains from your changes, so we have > some metric to assess their relevance? > I had suspected as much, but fully disabling ISA DMA didn't directly have much impact (less than 4195 byte reduction). I was already guessing most of the gain was CONFIG_ISA=n, but hoped purging ISA DMA might squeeze out a bit more. Removing AGP shrunk vmlinux.bin by 4KB. Since the kernel is a multiple of page size, this means a reduction of 1-8191 bytes. This though may have translated into a larger impact when CONFIG_DRM was set to no. Setting CONFIG_DRM=n resulted in a vmlinux.bin delta of -2203648 bytes. Not quite a 10% reduction in kernel runtime size, but close. Here we have a major impact on kernel size. Removing USB support is certainly inappropriate for a desktop build, but appropriate for something using a serial console (some types of VM). That has a delta of -2117632 bytes. Looks like Hyper-V support is a pig. I'm merely going from the size of handy distribution modules, but appears to need ~1MB of memory. Again going by handy distribution modules, the Fusion MPT used by VMware is closer to ~350KB (not including the need for the SCSI layer). Xen meanwhile is ~200KB total. -- (\___(\___(\__ --=> 8-) EHM <=-- __/)___/)___/) \BS (| ehem+sig...@m5p.com PGP 87145445 |) / \_CS\ | _ -O #include O- _ | / _/ 8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 6/9] kernel/x86: enable x32 support for amd64
On Fri, Apr 28, 2023 at 11:00:43AM -0600, Philip Prindeville wrote: > My own experience disagrees. > > I spent 17 months bringing up a Xeon-D based traffic shaper for 40Gb/s of > traffic in a radio base station. > > And yes, when collected crunched traffic statistics, it did use more than 4GB > of address space to do so. I can believe that. Though I kind of doubt this is the typical usage of OpenWRT. A kernel can have both amd64 and x32 enabled. My thinking was in typical usage most programs won't be that large and thus x32 is smaller and faster. Note, enabling CONFIG_X86_X32 does not force the use of x32 userspace, it merely allows it. The observed kernel runtime was 4KB larger which translates to +1-8191 bytes. -- (\___(\___(\__ --=> 8-) EHM <=-- __/)___/)___/) \BS (| ehem+sig...@m5p.com PGP 87145445 |) / \_CS\ | _ -O #include O- _ | / _/ 8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 6/9] kernel/x86: enable x32 support for amd64
On Thu, Apr 27, 2023 at 11:27:30AM +0200, Thibaut wrote: > > > Le 27 avr. 2023 à 02:00, Elliott Mitchell a écrit : > > > > On Thu, Apr 27, 2023 at 12:46:49AM +0200, Stefan Lippers-Hollmann wrote: > > > >> While I might understand (understand, not support) a desire for this > >> as a dedicated subtarget (to appease the virtualization crowd), > >> although I still don't see a reason or sufficient uptake in more > >> conventional Linux environments. I would not be happy (at all) to > >> lose 'normal' x86_64 support (on real hardware) for this exotic > >> fringe hybrid. I can imagine that actually building for this > >> environment (with a 32 bit userland) might lead to 'funny' results > >> as well (as in major toolchain changes necessary to get it working > >> as expected). > > > > I'm not proposing removing amd64 support, I'm proposing x32 is likely a > > more valuable target. > > Do you mean to actually introduce an x86_x32 userspace target in OpenWrt? > If so, I suggest you take a look at [1] to get an idea of the can of worms > you might be opening there. > > I do not think OpenWrt has the resources to handle this level of breakage for > such an exotic, barely upstream supported target. It seems worthy experimention at least. Enabling the kernel option adds somewhere between 1-8191 bytes (kernel build grew 1 page). If this reduces memory usage by 10% and increases performance by 10% that seems notable. My hope is that others have flushed most of the bugs out by now. If there are still too many bugs at this point, it can be left unreleased. > > Yet what you're describing reads like your desire > > is for OpenWRT/x86 to simply be yet another desktop Linux distribution. > > > > Unless you feel a networking device really needs 256GB of memory, virtual > > machines are precisely what OpenWRT/x86 *should* target. I think it is > > reasonable to also have a jumbo/desktop build, but using an entire x86 > > machine doesn't seem to match OpenWRT's main theme. > > You seem to ignore perfectly capable so-called « mini pc » routers which are > in use out there. They don’t need a « jumbo/desktop » build and they don’t > have 256GB RAM, yet they work perfectly well with the current OpenWrt image. That is indeed a better choice for consideration. What type of installation do you think OpenWRT should target for such devices? I'm unsure how much memory such devices typically have. I was able to find listings for SO-DIMMs from 4GB to 32GB. Most recent devices will include an IOMMU and 4GB is more than enough to usefully use a hypervisor. In such a case it might well make sense to use 128MB for handling the network and devote the rest to other tasks. With a system that size, there is rather MORE urgency to keep VMs small. Alternatively do you feel a router needs 4GB of memory? Thing is this turns OpenWRT into simply another desktop Linux distribution. At which point why not go with a Linux distribution designed for the desktop and has all the desktop features? -- (\___(\___(\__ --=> 8-) EHM <=-- __/)___/)___/) \BS (| ehem+sig...@m5p.com PGP 87145445 |) / \_CS\ | _ -O #include O- _ | / _/ 8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Objective of OpenWRT/x86?
On Thu, Apr 27, 2023 at 05:04:36AM +0100, Joseph Mullally wrote: > One nice feature for users of the "x86/64" and similar builds are that > they work out of the box on most generic hardware or virtualization > platforms. I use it on real hardware and KVM with device passthrough, > and it was very easy to set up. I'm guessing this is far more common > than speculative high density VM deployments. "on most generic hardware or virtualization platforms" means lots of common and quite a number of uncommon drivers are included. Which in turn means the kernel is quite large. I'm not thinking of a high-density VM deployment. I'm looking at the list of built-in drivers and seeing many which will perhaps only be used by 25% of installations. > It makes more sense to make a new lightweight VM profile rather than > chopping stuff out of the generic ones. More likely lightweight VM /configurations/. Xen, VMware, KVM and HyperV each want one. Issue is drivers guaranteed to be used by one VM will add megabytes of wasted memory to the kernel of another. The generic kernel does serve as a starting point. Should there perhaps be a target/linux/x86vm directory? > But is one needed, and how much memory would be saved? Have you > actually tried running the "x86/64" image with 128MB ram under QEMU? > Default 22.03.4 install shows 45MB used. With "wpad-openssl" and > "kmod-mac80211-hwsim", its up to 53MB. These requirements rise > depending on load. I'm guessing those memory figures in the wiki docs > are just arbitrary, showing people they can run cool stuff. That could be. Might simply be the wiki needs to have numbers adjusted downwards to reflect how much memory a reasonable installation needs instead of an advanced doing all the things installation. > If memory usage optimization is the goal, I suggest these discussions > and patches be tested and informed by real measurements in that area, > to discuss whether the tradeoffs with compatability are worth it. Isolating each kernel configuration change can be slightly tricky. If 3 things depend on something large, it may appear removing the first two options has minimal effect, but the third has a gigantic effect. When the truth is all 3 were important. A few kernel configuration builds: OpenWRT: 28039448 bytes allnoconfig: 3101272 bytes xen.config: 14385480 bytes At one point I tried building one of the ARM targets. The resultant kernel was ~10MB. Due to x86 being around a long time and GCC having received a lot of work on x86, x86 builds of the same source tend to be distinctly smaller on x86. With that context the above numbers are underwhelming. My only hope is allnoconfig strips out boot support for most environments and most of the delta is ACPI/UEFI/PNP. While typing about `make allnoconfig`, one of OpenWRT's patches appears to break "allnoconfig". Specifically something is trying to call `skb_free_reason()`, but that function has been left out. Appears the function In particular lib/kobject_uevent.c calls the function kfree_skb(), which is declared in include/linux/skbuff.h. This is an inline which in turn calls kfree_skb_reason(), which is normally defined in net/core/skbuff.c yet CONFIG_NET=n removes this file. Seems one of the x86 patches needs some sort of adjustment. As far as creating a slimmed-down VM kernel configuration. Removing AGP support doesn't gain much itself, but then disabling DRM support saves 2203648 bytes. Turning USB support into modules is another 2MB. I've gotten a potentially viable Xen kernel down to 23MB, but I hope to push at least somewhat further. -- (\___(\___(\__ --=> 8-) EHM <=-- __/)___/)___/) \BS (| ehem+sig...@m5p.com PGP 87145445 |) / \_CS\ | _ -O #include O- _ | / _/ 8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 0/9] (mostly) x86 kernel configuration adjustments
On Thu, Apr 27, 2023 at 05:38:18AM +0200, Stefan Lippers-Hollmann wrote: > On 2023-04-26, Elliott Mitchell wrote: > > On Thu, Apr 27, 2023 at 01:11:13AM +0200, Stefan Lippers-Hollmann wrote: > > > On 2023-04-26, Elliott Mitchell wrote: > > > [...] > > > > > > > > Looks like little of ISA remained on "64", yet some DMA support remained > > > > due to the generic configuration. Remove the ISA and ISA DMA support > > > > from the top-level configuration. Geode and Legacy though almost > > > > certainly still need ISA support. > > > > > > You might find that while ISA went away as an addon slot quite quickly, > > > it still survived rather long for low performance onboard devices (e.g. > > > sensors). > > > > I know, I was unsure of when it 100% disappeared. Do you expect anything > > besides "legacy" to be used for this type of system though? > [...] > > Ignoring industrial PCs (where you may still encounter ISA today), > you'd have to venture into the pre-LPC days (and AMD, VIA, nVidia > might have gone with ISA beyond that) - which might get you into > the 2005-2009 time frame (anything with an onboard floppy controller > might be worth looking at - and those were still around into the > LGA755/ core2 (x86_64) days - in that particular case probably LPC > based though). Perhaps have "64" and "old64" (or "early64") then? Seems rather a lot of legacy disappeared between 2005 and 2010. FDC, ISA, PATA and AGP were all common in 2005, yet by 2010 they were non-existant. -- (\___(\___(\__ --=> 8-) EHM <=-- __/)___/)___/) \BS (| ehem+sig...@m5p.com PGP 87145445 |) / \_CS\ | _ -O #include O- _ | / _/ 8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Old hardware...
I have three (3) old Ubiquiti UniFi indoor access points. Still supported in OpenWRT ath79, these are from 2015 or so. They're actually new in the box, purchased for a project that required OpenWRT; when Ubiquiti locked their bootloader they became unattractive and I set them aside. I have checked them and upgraded them to 22.03. They are just 2.4 GHz. 2x2 indoor access points with POE injectors, mounting brackets, etc. If someone can use them for testing, teaching, or some other use, I'd be happy to ship them in the continental US. If you want one or all three, please contact me at bmoff...@ayrstone.com. As a side note, I tried selling them on ebay using "running OpenWRT, not Ubiquiti's firmware" as a differentiation point. I did not even get a bid, even setting the starting price at $20. On Fri, Apr 28, 2023 at 2:19 PM Bill Moffitt wrote: > > I have three (3) old Ubiquiti UniFi indoor access points. Still supported in > OpenWRT ath79, these are from 2015 or so. They're actually new in the box, > purchased for a project that required OpenWRT; when Ubiquiti locked their > bootloader they became unattractive and I set them aside. I have checked them > and upgraded them to 22.03. They are just 2.4 GHz. 2x2 indoor access points > with POE injectors, mounting brackets, etc. > > If someone can use them for testing, teaching, or some other use, I'd be > happy to ship them in the continental US. > > As a side note, I tried selling them on ebay using "running OpenWRT, not > Ubiquiti's firmware" as a differentiation point. I did not even get a bid, > even setting the starting price at $20. > > ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 1/9] kernel/generic: remove CONFIG_FB_NOTIFY
Reviewed-by: Philip Prindeville > On Apr 25, 2023, at 5:23 PM, Elliott Mitchell wrote: > > I don't know what version of Linux this option disappeared at, but > it is clearly gone now. > > Signed-off-by: Elliott Mitchell > --- > target/linux/generic/config-5.10 | 1 - > target/linux/generic/config-5.15 | 1 - > 2 files changed, 2 deletions(-) > > diff --git a/target/linux/generic/config-5.10 > b/target/linux/generic/config-5.10 > index cde0fdb0a0..f6f1fb0278 100644 > --- a/target/linux/generic/config-5.10 > +++ b/target/linux/generic/config-5.10 > @@ -1892,7 +1892,6 @@ CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-1" > # CONFIG_FB_MXS is not set > # CONFIG_FB_N411 is not set > # CONFIG_FB_NEOMAGIC is not set > -CONFIG_FB_NOTIFY=y > # CONFIG_FB_NVIDIA is not set > # CONFIG_FB_OF is not set > # CONFIG_FB_OMAP2 is not set > diff --git a/target/linux/generic/config-5.15 > b/target/linux/generic/config-5.15 > index 239a645231..ac75a480a1 100644 > --- a/target/linux/generic/config-5.15 > +++ b/target/linux/generic/config-5.15 > @@ -1979,7 +1979,6 @@ CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-1" > # CONFIG_FB_MXS is not set > # CONFIG_FB_N411 is not set > # CONFIG_FB_NEOMAGIC is not set > -CONFIG_FB_NOTIFY=y > # CONFIG_FB_NVIDIA is not set > # CONFIG_FB_OF is not set > # CONFIG_FB_OMAP2 is not set > -- > (\___(\___(\__ --=> 8-) EHM <=-- __/)___/)___/) > \BS (| ehem+open...@m5p.com PGP 87145445 |) / > \_CS\ | _ -O #include O- _ | / _/ > 8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445 > > > > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Objective of OpenWRT/x86?
> On Apr 26, 2023, at 2:17 PM, Elliott Mitchell wrote: > > Well, was a specific objective ever chosen for the x86 version of > OpenWRT? Does it need one? As the most ubiquitous hardware out there for many users, why would we need to box it in? Someone might want to throw a generic image onto a PC they have lying around until they decide it's worth bringing up specialized hardware... going out an buying it, building an image, installing it, troubleshooting it, etc. > I can state my goal/hope for OpenWRT/x86. The *WRT Linux distributions > were so named for originally targeting the LinkSys WRT54G. This was a > small AP, so one might expect builds to be for small APs. By today's > standards 128MB RAM and 16MB of storage is relatively small. Yeah, we had a discussion some years ago about "FAT" vs. "SKINNY" platforms that never went anywhere. All of the AMD64 platforms were FAT. Having robust hardware that you can prototype on, including CPU or memory hungry development, allows us to prove the value of new capabilities that might be ubiquitous in the next generation of COTS and SoHo routers. After all, the BoM for an extra GB of DRAM is literally pennies in large production volumes. BTW, I run OpenWrt for its firewall capabilities... None of my boxes actually has wireless hardware at this point, and I use a few Ubiquiti AP-AC-Pro's or U6-LR's scattered around the house. The rule of thumb when I worked at MIT on the X Window System, was that what's the top-of-the-line workstation today will be "budget" hardware 3-4 years out, so to not worry about hardware constraints because by the time you release stable, production quality software, the hardware will have gone through one or two evolutions... Today's one-off advanced prototyping platform is tomorrow's BestBuy budget/clearance item... > Since this network is in the moving towards the server phase, the AP drew > my attention. Turns out all of the hardware of an AP is available for > servers, though in distinct form-factors. If the server has a full > IOMMU, the hardware can be directed to a VM and you have a proper AP in a > VM. "Moving towards the server phase"? I'm not getting what you mean by this. See above: the radios and antennae I can get as add-ons for a Xeon-D 1U pizza box or even an APU6 mPCIe slot are vastly inferior to what ODM purpose-built hardware like an U6-LR can do in terms of cost and performance. Um... you can't "virtualize" WiFi in any VM I've ever seen. > Problem is instead of the recommended 128MB memory, 16MB of storage > (https://openwrt.org/supported_devices/432_warning) the virtualization > examples (https://openwrt.org/docs/guide-user/virtualization/start) are > suggesting massively more memory. 256MB (small Xen example), 512MB > (VMware OpenWRT/15.05) or 1GB (Qemu examples). Sorry, why is this a "problem"? I spent $1100 on a Xeon-D box with 128GB of DRAM, 16 hyper threaded cores, and 2TB of NVMe. > I don't yet have a full handle on the issues. My first thought was the > large sizes come from early stage development and not wanting to bother > with memory limitations. Another possibility is this comes from simply a > thought pattern of "x86 memory is cheap, just throw memory at it". You're looking at it backwards. Think of it as "what could I do if I have more RAM and CPU?" Could I do on-board real-time data reduction of firewall logs? Could I run fail2ban near-realtime? Could I run a sandboxed Apache proxy to all of my internal HTTP-based services and used certificate-based authentication with centralized management? I've been running VoIP on my firewall for 12 years now, with find-me follow me, and 22 extensions. I'm thinking of adding 4K video-conferencing capability if I can find the time... My security cameras do H.265 in their highest quality mode, but the renderer in Safari on my iPhone can only handle H.264... but I don't care, because I can configure a transcoding proxy to run in Apache+VLC!!! > Yet if one is wanting to use this for serious purposes, memory IS a > concern. GCC is pretty capable for x86, a quick check suggests GCC tends > to produce binaries for x86 which are four-fifths the size of those for > ARM. Yet everything for OpenWRT/x86 is suggesting at least *double* the > memory?! If I need something for "serious purposes", I budget appropriately... > One issue I've found is the kernel configurations seem ill-suited to x86. > Almost any storage driver used by 10 or more people is built into the > kernel. As a result the *single* kernel is huge. If it's not used as a boot device, we could make it kmod-able... otherwise we'd need to add initramfs... I don't think anyone wants to go down that road. Too easy to brick devices. I think we should leverage more subtargets and profiles, but that's a separate discussion. > The conventional approach for x86 is to use an initial ramdisk and build > everything as modules. Issue
Re: [PATCH 9/9] kernel/x86: remove DRM support
> On Apr 27, 2023, at 3:21 AM, Thibaut wrote: > > > >> Le 27 avr. 2023 à 02:11, Elliott Mitchell a écrit : >> >> On Thu, Apr 27, 2023 at 12:50:52AM +0200, Stefan Lippers-Hollmann wrote: >>> On 2023-04-19, Elliott Mitchell wrote: Direct Rendering Manager is mainly for running X (possibly Wayland too). As OpenWRT is meant for networking devices, there is no need for the support to be present. >>> >>> That is only partially true, the Linux kernel is making a strong push >>> away from deprecated (FB_*) graphics drivers to DRM based ones, with >>> kernel based mode setting this is getting more (any) attention for >>> console support as well. Even without getting anywhere near X/ Wayland, >>> there is more than just a 80x25 tty on real hardware (and even VMs). >> >> Real x86 hardware often has the capability to use a serial port as >> console. The conventional UEFI implementation fully supports this use >> case. I can well believe a number of manufacturers disabling the >> functionality though. >> >> VMs *can* have more than a 80x25 tty. By the time you're getting to 4 >> or more VMs you should be thinking about disabling the functionality due >> to the heavy overhead (unless the OS in the VM doesn't support serial >> consoles). > > You seem to assume that x86 is only/mainly run on VMs. > That is not necessarily the case, and I see no reason to degrade device > support that way. > > Would you mind documenting the measurable gains from your changes, so we have > some metric to assess their relevance? > > Cheers, > T True enough. I have net4801 (Geode), net5501 (Geode), alix2 (Geode), apu6 (GX-412TC), and Supermicro Xeon D1548 based routers right in front of me. Let's also not forget that Openwrt is used downstream in many projects that we have limited visibility into. -Philip ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 6/9] kernel/x86: enable x32 support for amd64
> On Apr 26, 2023, at 6:00 PM, Elliott Mitchell wrote: > > On Thu, Apr 27, 2023 at 12:46:49AM +0200, Stefan Lippers-Hollmann wrote: >> >> On 2023-03-30, Elliott Mitchell wrote: >>> Full amd64 support isn't really appropriate for most situations >>> OpenWRT is deployed. Whereas x86-x32 seems extremely appropriate for >>> these situations. As such enable x86-x32 support. >>> >>> CONFIG_ARCH_MMAP_RND_COMPAT_BITS is required to follow along, >>> otherwise the kernel build breaks. >>> >>> Signed-off-by: Elliott Mitchell >>> --- >>> I suggest OpenWRT should be placing quite a bit of effort towards >>> x86-x32. x86-x32 seems a rather superior generic target for OpenWRT. >>> Only issue is it could be valuable to have at least minimal amd64 >>> userland support alongside the x86-x32 version. >> >> x86_32 is pretty much dead in the water, with almost zero deployment >> by general purpose distributions - apart from VM data centre >> environments doing their own thing (least amount of RAM usage >> possible, everything else being secondary at best). At least Debian >> did raise security concerns about the x86_32 ISA in the past. > > Error: undefined symbol "x86_32" > > Without the extra context I would resolve that to "i386"/"ia32". I think > "x32" or "x86_x32" are better strings for this case. > > According to what I had read that was in the past when x32 was sharing > less of the i386 ABI. Notably x32 had been trying to pass time values > in a distinct fashion. I will conceed I'm unsure whether x32 is ever > truly going to get a seat at the table. > > On a different news front, Linux 5.10 has an option > CONFIG_X86_X32_DISABLED which leaves x32 disabled by default (Debian's > kernels were configured this way). Whereas 5.15 has removed the > CONFIG_X86_X32_DISABLED option which seems to suggest the concerns may > have been assuaged. > >> While I might understand (understand, not support) a desire for this >> as a dedicated subtarget (to appease the virtualization crowd), >> although I still don't see a reason or sufficient uptake in more >> conventional Linux environments. I would not be happy (at all) to >> lose 'normal' x86_64 support (on real hardware) for this exotic >> fringe hybrid. I can imagine that actually building for this >> environment (with a 32 bit userland) might lead to 'funny' results >> as well (as in major toolchain changes necessary to get it working >> as expected). > > I'm not proposing removing amd64 support, I'm proposing x32 is likely a > more valuable target. Yet what you're describing reads like your desire > is for OpenWRT/x86 to simply be yet another desktop Linux distribution. > > Unless you feel a networking device really needs 256GB of memory, virtual > machines are precisely what OpenWRT/x86 *should* target. I think it is > reasonable to also have a jumbo/desktop build, but using an entire x86 > machine doesn't seem to match OpenWRT's main theme. I personally know of companies running virtualized instances of AMD64 on m4.large or m5.large Amazon EC2 instances. I have three AMD64 firewalls... Two PC Engines APU6's (AMD GX-412TC "Jaguar" SoC based) running as a hot tandem pair for fail-over at the home office, and a dogfooding instance running on a KVM server that sandboxes my teenage kids and keeps them off the main household networks. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 6/9] kernel/x86: enable x32 support for amd64
My own experience disagrees. I spent 17 months bringing up a Xeon-D based traffic shaper for 40Gb/s of traffic in a radio base station. And yes, when collected crunched traffic statistics, it did use more than 4GB of address space to do so. > On Mar 30, 2023, at 5:30 PM, Elliott Mitchell wrote: > > Full amd64 support isn't really appropriate for most situations > OpenWRT is deployed. Whereas x86-x32 seems extremely appropriate for > these situations. As such enable x86-x32 support. > > CONFIG_ARCH_MMAP_RND_COMPAT_BITS is required to follow along, > otherwise the kernel build breaks. > > Signed-off-by: Elliott Mitchell > --- > I suggest OpenWRT should be placing quite a bit of effort towards > x86-x32. x86-x32 seems a rather superior generic target for OpenWRT. > Only issue is it could be valuable to have at least minimal amd64 > userland support alongside the x86-x32 version. > --- > target/linux/x86/64/config-5.10 | 1 - > target/linux/x86/64/config-5.15 | 1 - > target/linux/x86/config-5.10| 2 ++ > target/linux/x86/config-5.15| 2 ++ > 4 files changed, 4 insertions(+), 2 deletions(-) > > diff --git a/target/linux/x86/64/config-5.10 b/target/linux/x86/64/config-5.10 > index 1515f90932..de93495fb1 100644 > --- a/target/linux/x86/64/config-5.10 > +++ b/target/linux/x86/64/config-5.10 > @@ -470,7 +470,6 @@ CONFIG_X86_PM_TIMER=y > # CONFIG_X86_POWERNOW_K8 is not set > # CONFIG_X86_VSYSCALL_EMULATION is not set > CONFIG_X86_X2APIC=y > -# CONFIG_X86_X32 is not set > CONFIG_XEN=y > CONFIG_XENFS=y > CONFIG_XEN_512GB=y > diff --git a/target/linux/x86/64/config-5.15 b/target/linux/x86/64/config-5.15 > index a20891ea55..39e5064e53 100644 > --- a/target/linux/x86/64/config-5.15 > +++ b/target/linux/x86/64/config-5.15 > @@ -493,7 +493,6 @@ CONFIG_X86_PM_TIMER=y > # CONFIG_X86_POWERNOW_K8 is not set > # CONFIG_X86_VSYSCALL_EMULATION is not set > CONFIG_X86_X2APIC=y > -# CONFIG_X86_X32 is not set > CONFIG_XEN=y > CONFIG_XENFS=y > CONFIG_XEN_512GB=y > diff --git a/target/linux/x86/config-5.10 b/target/linux/x86/config-5.10 > index afb7adc63a..8be829d549 100644 > --- a/target/linux/x86/config-5.10 > +++ b/target/linux/x86/config-5.10 > @@ -12,6 +12,7 @@ CONFIG_ARCH_HIBERNATION_POSSIBLE=y > CONFIG_ARCH_MAY_HAVE_PC_FDC=y > CONFIG_ARCH_MIGHT_HAVE_PC_PARPORT=y > CONFIG_ARCH_MIGHT_HAVE_PC_SERIO=y > +CONFIG_ARCH_MMAP_RND_COMPAT_BITS=8 > CONFIG_ARCH_RANDOM=y > CONFIG_ARCH_SELECT_MEMORY_MODEL=y > CONFIG_ARCH_SPARSEMEM_ENABLE=y > @@ -423,6 +424,7 @@ CONFIG_X86_UP_IOAPIC=y > CONFIG_X86_USE_PPRO_CHECKSUM=y > CONFIG_X86_VERBOSE_BOOTUP=y > CONFIG_X86_VMX_FEATURE_NAMES=y > +CONFIG_X86_X32=y > CONFIG_XZ_DEC_BCJ=y > CONFIG_XZ_DEC_X86=y > CONFIG_ZLIB_INFLATE=y > diff --git a/target/linux/x86/config-5.15 b/target/linux/x86/config-5.15 > index b59e809127..afe66b27b1 100644 > --- a/target/linux/x86/config-5.15 > +++ b/target/linux/x86/config-5.15 > @@ -13,6 +13,7 @@ CONFIG_ARCH_MAY_HAVE_PC_FDC=y > CONFIG_ARCH_MHP_MEMMAP_ON_MEMORY_ENABLE=y > CONFIG_ARCH_MIGHT_HAVE_PC_PARPORT=y > CONFIG_ARCH_MIGHT_HAVE_PC_SERIO=y > +CONFIG_ARCH_MMAP_RND_COMPAT_BITS=8 > CONFIG_ARCH_NR_GPIO=512 > CONFIG_ARCH_RANDOM=y > CONFIG_ARCH_SELECT_MEMORY_MODEL=y > @@ -428,6 +429,7 @@ CONFIG_X86_UP_IOAPIC=y > CONFIG_X86_USE_PPRO_CHECKSUM=y > CONFIG_X86_VERBOSE_BOOTUP=y > CONFIG_X86_VMX_FEATURE_NAMES=y > +CONFIG_X86_X32=y > CONFIG_XZ_DEC_BCJ=y > CONFIG_XZ_DEC_X86=y > CONFIG_ZLIB_INFLATE=y > -- > (\___(\___(\__ --=> 8-) EHM <=-- __/)___/)___/) > \BS (| ehem+open...@m5p.com PGP 87145445 |) / > \_CS\ | _ -O #include O- _ | / _/ > 8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445 > > > > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 0/9] (mostly) x86 kernel configuration adjustments
> On Apr 26, 2023, at 2:11 PM, Elliott Mitchell wrote: > > Now we come to the item I've mentioned. The X32 ABI. This is running an > amd64 processor in amd64 mode, but truncating all pointers to 32 bits > (ILP32 mode). This shrinks the runtime size of programs in exchange for > limiting them to a maximum of 4GB of memory. The result is often a > significant speed increase over both i386 and amd64 modes, largely due to > reducing memory use. > > For rather a lot of programs, 4GB of memory is plenty. Have you ever > observed `ls` or a shell use anywhere near that much? The fact most > devices running OpenWRT don't have that much *total* memory says the > limitation is worthwhile. Personally I don't want to relive thunking hell. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 8/9] kernel/x86: remove support for AGP
Reviewed-by: Philip Prindeville > On Apr 12, 2023, at 11:47 PM, Elliott Mitchell wrote: > > OpenWRT is not a graphics-oriented Linux distribution. There is no > need for AGP support in any standard OpenWRT kernel. > > Signed-off-by: Elliott Mitchell > --- > target/linux/x86/64/config-5.10 | 5 - > target/linux/x86/64/config-5.15 | 5 - > target/linux/x86/generic/config-5.10 | 11 --- > target/linux/x86/generic/config-5.15 | 11 --- > target/linux/x86/legacy/config-5.10 | 11 --- > target/linux/x86/legacy/config-5.15 | 11 --- > 6 files changed, 54 deletions(-) > > diff --git a/target/linux/x86/64/config-5.10 b/target/linux/x86/64/config-5.10 > index de93495fb1..b226b347bd 100644 > --- a/target/linux/x86/64/config-5.10 > +++ b/target/linux/x86/64/config-5.10 > @@ -33,11 +33,6 @@ CONFIG_ACPI_THERMAL=y > CONFIG_ACPI_VIDEO=y > # CONFIG_ACPI_WMI is not set > # CONFIG_ACRN_GUEST is not set > -CONFIG_AGP=y > -# CONFIG_AGP_AMD64 is not set > -CONFIG_AGP_INTEL=y > -# CONFIG_AGP_SIS is not set > -# CONFIG_AGP_VIA is not set > CONFIG_AMD_IOMMU=y > # CONFIG_AMD_IOMMU_V2 is not set > CONFIG_ARCH_CPUIDLE_HALTPOLL=y > diff --git a/target/linux/x86/64/config-5.15 b/target/linux/x86/64/config-5.15 > index 39e5064e53..7f5b80e54a 100644 > --- a/target/linux/x86/64/config-5.15 > +++ b/target/linux/x86/64/config-5.15 > @@ -36,11 +36,6 @@ CONFIG_ACPI_VIDEO=y > # CONFIG_ACPI_WMI is not set > # CONFIG_ACRN_GUEST is not set > # CONFIG_ADV_SWBUTTON is not set > -CONFIG_AGP=y > -# CONFIG_AGP_AMD64 is not set > -CONFIG_AGP_INTEL=y > -# CONFIG_AGP_SIS is not set > -# CONFIG_AGP_VIA is not set > CONFIG_AMD_IOMMU=y > # CONFIG_AMD_IOMMU_V2 is not set > # CONFIG_AMD_PMC is not set > diff --git a/target/linux/x86/generic/config-5.10 > b/target/linux/x86/generic/config-5.10 > index e5359b..6da10e3776 100644 > --- a/target/linux/x86/generic/config-5.10 > +++ b/target/linux/x86/generic/config-5.10 > @@ -30,17 +30,6 @@ CONFIG_ACPI_TAD=y > CONFIG_ACPI_THERMAL=y > CONFIG_ACPI_VIDEO=y > # CONFIG_ACPI_WMI is not set > -CONFIG_AGP=y > -# CONFIG_AGP_ALI is not set > -# CONFIG_AGP_AMD is not set > -# CONFIG_AGP_AMD64 is not set > -# CONFIG_AGP_ATI is not set > -# CONFIG_AGP_EFFICEON is not set > -CONFIG_AGP_INTEL=y > -# CONFIG_AGP_NVIDIA is not set > -# CONFIG_AGP_SIS is not set > -# CONFIG_AGP_SWORKS is not set > -# CONFIG_AGP_VIA is not set > # CONFIG_APM is not set > CONFIG_ARCH_CPUIDLE_HALTPOLL=y > CONFIG_ARCH_DMA_ADDR_T_64BIT=y > diff --git a/target/linux/x86/generic/config-5.15 > b/target/linux/x86/generic/config-5.15 > index 5dbd432ce5..491e9737f5 100644 > --- a/target/linux/x86/generic/config-5.15 > +++ b/target/linux/x86/generic/config-5.15 > @@ -31,17 +31,6 @@ CONFIG_ACPI_THERMAL=y > CONFIG_ACPI_VIDEO=y > # CONFIG_ACPI_WMI is not set > # CONFIG_ADV_SWBUTTON is not set > -CONFIG_AGP=y > -# CONFIG_AGP_ALI is not set > -# CONFIG_AGP_AMD is not set > -# CONFIG_AGP_AMD64 is not set > -# CONFIG_AGP_ATI is not set > -# CONFIG_AGP_EFFICEON is not set > -CONFIG_AGP_INTEL=y > -# CONFIG_AGP_NVIDIA is not set > -# CONFIG_AGP_SIS is not set > -# CONFIG_AGP_SWORKS is not set > -# CONFIG_AGP_VIA is not set > # CONFIG_AMD_PMC is not set > # CONFIG_APM is not set > CONFIG_ARCH_CPUIDLE_HALTPOLL=y > diff --git a/target/linux/x86/legacy/config-5.10 > b/target/linux/x86/legacy/config-5.10 > index 3a44ab45d6..e5284822a5 100644 > --- a/target/linux/x86/legacy/config-5.10 > +++ b/target/linux/x86/legacy/config-5.10 > @@ -27,17 +27,6 @@ CONFIG_ACPI_SYSTEM_POWER_STATES_SUPPORT=y > CONFIG_ACPI_THERMAL=y > CONFIG_ACPI_VIDEO=y > # CONFIG_ACPI_WMI is not set > -CONFIG_AGP=y > -# CONFIG_AGP_ALI is not set > -# CONFIG_AGP_AMD is not set > -# CONFIG_AGP_AMD64 is not set > -# CONFIG_AGP_ATI is not set > -# CONFIG_AGP_EFFICEON is not set > -CONFIG_AGP_INTEL=y > -# CONFIG_AGP_NVIDIA is not set > -# CONFIG_AGP_SIS is not set > -# CONFIG_AGP_SWORKS is not set > -# CONFIG_AGP_VIA is not set > CONFIG_ARCH_MIGHT_HAVE_ACPI_PDC=y > CONFIG_BACKLIGHT_CLASS_DEVICE=y > CONFIG_BLK_DEV_SR=y > diff --git a/target/linux/x86/legacy/config-5.15 > b/target/linux/x86/legacy/config-5.15 > index 74edf85abd..7e943138d4 100644 > --- a/target/linux/x86/legacy/config-5.15 > +++ b/target/linux/x86/legacy/config-5.15 > @@ -28,17 +28,6 @@ CONFIG_ACPI_THERMAL=y > CONFIG_ACPI_VIDEO=y > # CONFIG_ACPI_WMI is not set > # CONFIG_ADV_SWBUTTON is not set > -CONFIG_AGP=y > -# CONFIG_AGP_ALI is not set > -# CONFIG_AGP_AMD is not set > -# CONFIG_AGP_AMD64 is not set > -# CONFIG_AGP_ATI is not set > -# CONFIG_AGP_EFFICEON is not set > -CONFIG_AGP_INTEL=y > -# CONFIG_AGP_NVIDIA is not set > -# CONFIG_AGP_SIS is not set > -# CONFIG_AGP_SWORKS is not set > -# CONFIG_AGP_VIA is not set > # CONFIG_AMD_PMC is not set > CONFIG_ARCH_MIGHT_HAVE_ACPI_PDC=y > CONFIG_BACKLIGHT_CLASS_DEVICE=y > -- > (\___(\___(\__ --=> 8-) EHM <=-- __/)___/)___/) > \BS (| ehem+open...@m5p.com PGP 87145445 |) / > \_CS\ |
Re: [PATCH 8/9] kernel/x86: remove support for AGP
Reviewed-by: Philip Prindeville > On Apr 12, 2023, at 11:47 PM, Elliott Mitchell wrote: > > OpenWRT is not a graphics-oriented Linux distribution. There is no > need for AGP support in any standard OpenWRT kernel. > > Signed-off-by: Elliott Mitchell > --- > target/linux/x86/64/config-5.10 | 5 - > target/linux/x86/64/config-5.15 | 5 - > target/linux/x86/generic/config-5.10 | 11 --- > target/linux/x86/generic/config-5.15 | 11 --- > target/linux/x86/legacy/config-5.10 | 11 --- > target/linux/x86/legacy/config-5.15 | 11 --- > 6 files changed, 54 deletions(-) > > diff --git a/target/linux/x86/64/config-5.10 b/target/linux/x86/64/config-5.10 > index de93495fb1..b226b347bd 100644 > --- a/target/linux/x86/64/config-5.10 > +++ b/target/linux/x86/64/config-5.10 > @@ -33,11 +33,6 @@ CONFIG_ACPI_THERMAL=y > CONFIG_ACPI_VIDEO=y > # CONFIG_ACPI_WMI is not set > # CONFIG_ACRN_GUEST is not set > -CONFIG_AGP=y > -# CONFIG_AGP_AMD64 is not set > -CONFIG_AGP_INTEL=y > -# CONFIG_AGP_SIS is not set > -# CONFIG_AGP_VIA is not set > CONFIG_AMD_IOMMU=y > # CONFIG_AMD_IOMMU_V2 is not set > CONFIG_ARCH_CPUIDLE_HALTPOLL=y > diff --git a/target/linux/x86/64/config-5.15 b/target/linux/x86/64/config-5.15 > index 39e5064e53..7f5b80e54a 100644 > --- a/target/linux/x86/64/config-5.15 > +++ b/target/linux/x86/64/config-5.15 > @@ -36,11 +36,6 @@ CONFIG_ACPI_VIDEO=y > # CONFIG_ACPI_WMI is not set > # CONFIG_ACRN_GUEST is not set > # CONFIG_ADV_SWBUTTON is not set > -CONFIG_AGP=y > -# CONFIG_AGP_AMD64 is not set > -CONFIG_AGP_INTEL=y > -# CONFIG_AGP_SIS is not set > -# CONFIG_AGP_VIA is not set > CONFIG_AMD_IOMMU=y > # CONFIG_AMD_IOMMU_V2 is not set > # CONFIG_AMD_PMC is not set > diff --git a/target/linux/x86/generic/config-5.10 > b/target/linux/x86/generic/config-5.10 > index e5359b..6da10e3776 100644 > --- a/target/linux/x86/generic/config-5.10 > +++ b/target/linux/x86/generic/config-5.10 > @@ -30,17 +30,6 @@ CONFIG_ACPI_TAD=y > CONFIG_ACPI_THERMAL=y > CONFIG_ACPI_VIDEO=y > # CONFIG_ACPI_WMI is not set > -CONFIG_AGP=y > -# CONFIG_AGP_ALI is not set > -# CONFIG_AGP_AMD is not set > -# CONFIG_AGP_AMD64 is not set > -# CONFIG_AGP_ATI is not set > -# CONFIG_AGP_EFFICEON is not set > -CONFIG_AGP_INTEL=y > -# CONFIG_AGP_NVIDIA is not set > -# CONFIG_AGP_SIS is not set > -# CONFIG_AGP_SWORKS is not set > -# CONFIG_AGP_VIA is not set > # CONFIG_APM is not set > CONFIG_ARCH_CPUIDLE_HALTPOLL=y > CONFIG_ARCH_DMA_ADDR_T_64BIT=y > diff --git a/target/linux/x86/generic/config-5.15 > b/target/linux/x86/generic/config-5.15 > index 5dbd432ce5..491e9737f5 100644 > --- a/target/linux/x86/generic/config-5.15 > +++ b/target/linux/x86/generic/config-5.15 > @@ -31,17 +31,6 @@ CONFIG_ACPI_THERMAL=y > CONFIG_ACPI_VIDEO=y > # CONFIG_ACPI_WMI is not set > # CONFIG_ADV_SWBUTTON is not set > -CONFIG_AGP=y > -# CONFIG_AGP_ALI is not set > -# CONFIG_AGP_AMD is not set > -# CONFIG_AGP_AMD64 is not set > -# CONFIG_AGP_ATI is not set > -# CONFIG_AGP_EFFICEON is not set > -CONFIG_AGP_INTEL=y > -# CONFIG_AGP_NVIDIA is not set > -# CONFIG_AGP_SIS is not set > -# CONFIG_AGP_SWORKS is not set > -# CONFIG_AGP_VIA is not set > # CONFIG_AMD_PMC is not set > # CONFIG_APM is not set > CONFIG_ARCH_CPUIDLE_HALTPOLL=y > diff --git a/target/linux/x86/legacy/config-5.10 > b/target/linux/x86/legacy/config-5.10 > index 3a44ab45d6..e5284822a5 100644 > --- a/target/linux/x86/legacy/config-5.10 > +++ b/target/linux/x86/legacy/config-5.10 > @@ -27,17 +27,6 @@ CONFIG_ACPI_SYSTEM_POWER_STATES_SUPPORT=y > CONFIG_ACPI_THERMAL=y > CONFIG_ACPI_VIDEO=y > # CONFIG_ACPI_WMI is not set > -CONFIG_AGP=y > -# CONFIG_AGP_ALI is not set > -# CONFIG_AGP_AMD is not set > -# CONFIG_AGP_AMD64 is not set > -# CONFIG_AGP_ATI is not set > -# CONFIG_AGP_EFFICEON is not set > -CONFIG_AGP_INTEL=y > -# CONFIG_AGP_NVIDIA is not set > -# CONFIG_AGP_SIS is not set > -# CONFIG_AGP_SWORKS is not set > -# CONFIG_AGP_VIA is not set > CONFIG_ARCH_MIGHT_HAVE_ACPI_PDC=y > CONFIG_BACKLIGHT_CLASS_DEVICE=y > CONFIG_BLK_DEV_SR=y > diff --git a/target/linux/x86/legacy/config-5.15 > b/target/linux/x86/legacy/config-5.15 > index 74edf85abd..7e943138d4 100644 > --- a/target/linux/x86/legacy/config-5.15 > +++ b/target/linux/x86/legacy/config-5.15 > @@ -28,17 +28,6 @@ CONFIG_ACPI_THERMAL=y > CONFIG_ACPI_VIDEO=y > # CONFIG_ACPI_WMI is not set > # CONFIG_ADV_SWBUTTON is not set > -CONFIG_AGP=y > -# CONFIG_AGP_ALI is not set > -# CONFIG_AGP_AMD is not set > -# CONFIG_AGP_AMD64 is not set > -# CONFIG_AGP_ATI is not set > -# CONFIG_AGP_EFFICEON is not set > -CONFIG_AGP_INTEL=y > -# CONFIG_AGP_NVIDIA is not set > -# CONFIG_AGP_SIS is not set > -# CONFIG_AGP_SWORKS is not set > -# CONFIG_AGP_VIA is not set > # CONFIG_AMD_PMC is not set > CONFIG_ARCH_MIGHT_HAVE_ACPI_PDC=y > CONFIG_BACKLIGHT_CLASS_DEVICE=y > -- > (\___(\___(\__ --=> 8-) EHM <=-- __/)___/)___/) > \BS (| ehem+open...@m5p.com PGP 87145445 |) / > \_CS\ |
Re: [PATCH 7/9] kernel/x86: remove all ISA support from non-legacy
Reviewed-by: Philip Prindeville > On Apr 13, 2023, at 9:58 PM, Elliott Mitchell wrote: > > While some older PCI motherboard might emulate some functions via > ISA, actual ISA is absent from anything non-legacy. Move ISA DMA > enabling to Geode and Legacy. > > Signed-off-by: Elliott Mitchell > --- > Question here is how far to go with removing ISA support? Certainly it > is appropriate to keep for the legacy build, but what of slightly more > recent hardware? Some i686 motherboards might have actual slots, but it > was quickly vestigial. > --- > target/linux/x86/config-5.10| 5 ++--- > target/linux/x86/config-5.15| 5 ++--- > target/linux/x86/geode/config-5.10 | 2 ++ > target/linux/x86/geode/config-5.15 | 2 ++ > target/linux/x86/legacy/config-5.10 | 2 ++ > target/linux/x86/legacy/config-5.15 | 2 ++ > 6 files changed, 12 insertions(+), 6 deletions(-) > > diff --git a/target/linux/x86/config-5.10 b/target/linux/x86/config-5.10 > index 8be829d549..98e0372247 100644 > --- a/target/linux/x86/config-5.10 > +++ b/target/linux/x86/config-5.10 > @@ -132,7 +132,6 @@ CONFIG_GENERIC_IOMAP=y > CONFIG_GENERIC_IRQ_MATRIX_ALLOCATOR=y > CONFIG_GENERIC_IRQ_RESERVATION_MODE=y > CONFIG_GENERIC_IRQ_SHOW=y > -CONFIG_GENERIC_ISA_DMA=y > CONFIG_GENERIC_MSI_IRQ=y > CONFIG_GENERIC_MSI_IRQ_DOMAIN=y > CONFIG_GENERIC_PCI_IOMAP=y > @@ -185,8 +184,8 @@ CONFIG_IRQ_DOMAIN=y > CONFIG_IRQ_DOMAIN_HIERARCHY=y > CONFIG_IRQ_FORCED_THREADING=y > CONFIG_IRQ_WORK=y > -# CONFIG_ISA is not set > -CONFIG_ISA_DMA_API=y > +CONFIG_ISA=n > +CONFIG_ISA_DMA_API=n > # CONFIG_IT8712F_WDT is not set > # CONFIG_IT87_WDT is not set > # CONFIG_ITCO_WDT is not set > diff --git a/target/linux/x86/config-5.15 b/target/linux/x86/config-5.15 > index afe66b27b1..3805820416 100644 > --- a/target/linux/x86/config-5.15 > +++ b/target/linux/x86/config-5.15 > @@ -133,7 +133,6 @@ CONFIG_GENERIC_IOMAP=y > CONFIG_GENERIC_IRQ_MATRIX_ALLOCATOR=y > CONFIG_GENERIC_IRQ_RESERVATION_MODE=y > CONFIG_GENERIC_IRQ_SHOW=y > -CONFIG_GENERIC_ISA_DMA=y > CONFIG_GENERIC_MSI_IRQ=y > CONFIG_GENERIC_MSI_IRQ_DOMAIN=y > CONFIG_GENERIC_PCI_IOMAP=y > @@ -187,8 +186,8 @@ CONFIG_IRQ_DOMAIN=y > CONFIG_IRQ_DOMAIN_HIERARCHY=y > CONFIG_IRQ_FORCED_THREADING=y > CONFIG_IRQ_WORK=y > -# CONFIG_ISA is not set > -CONFIG_ISA_DMA_API=y > +CONFIG_ISA=n > +CONFIG_ISA_DMA_API=n > # CONFIG_IT8712F_WDT is not set > # CONFIG_IT87_WDT is not set > # CONFIG_ITCO_WDT is not set > diff --git a/target/linux/x86/geode/config-5.10 > b/target/linux/x86/geode/config-5.10 > index 30b358b050..632e1fb7b7 100644 > --- a/target/linux/x86/geode/config-5.10 > +++ b/target/linux/x86/geode/config-5.10 > @@ -42,6 +42,7 @@ CONFIG_CS5535_MFGPT=y > CONFIG_CS5535_MFGPT_DEFAULT_IRQ=7 > CONFIG_DMA_ACPI=y > # CONFIG_EL3 is not set > +CONFIG_GENERIC_ISA_DMA=y > CONFIG_GEODE_WDT=y > CONFIG_GEOS=y > CONFIG_GPIO_ACPI=y > @@ -67,6 +68,7 @@ CONFIG_IOSF_MBI=y > CONFIG_ISA=y > # CONFIG_ISAPNP is not set > CONFIG_ISA_BUS_API=y > +CONFIG_ISA_DMA_API=y > # CONFIG_ISCSI_IBFT is not set > # CONFIG_LANCE is not set > CONFIG_LEDS_GPIO=y > diff --git a/target/linux/x86/geode/config-5.15 > b/target/linux/x86/geode/config-5.15 > index 0c54cdaf9e..deaf2123d4 100644 > --- a/target/linux/x86/geode/config-5.15 > +++ b/target/linux/x86/geode/config-5.15 > @@ -45,6 +45,7 @@ CONFIG_CS5535_MFGPT_DEFAULT_IRQ=7 > # CONFIG_CS89x0_ISA is not set > CONFIG_DMA_ACPI=y > # CONFIG_EL3 is not set > +CONFIG_GENERIC_ISA_DMA=y > CONFIG_GEODE_WDT=y > CONFIG_GEOS=y > CONFIG_GPIO_ACPI=y > @@ -74,6 +75,7 @@ CONFIG_IOSF_MBI=y > CONFIG_ISA=y > # CONFIG_ISAPNP is not set > CONFIG_ISA_BUS_API=y > +CONFIG_ISA_DMA_API=y > # CONFIG_ISCSI_IBFT is not set > # CONFIG_LANCE is not set > CONFIG_LEDS_GPIO=y > diff --git a/target/linux/x86/legacy/config-5.10 > b/target/linux/x86/legacy/config-5.10 > index a11eca8fc2..3a44ab45d6 100644 > --- a/target/linux/x86/legacy/config-5.10 > +++ b/target/linux/x86/legacy/config-5.10 > @@ -106,6 +106,7 @@ CONFIG_FONT_SUPPORT=y > CONFIG_FRAMEBUFFER_CONSOLE=y > CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY=y > # CONFIG_FRAMEBUFFER_CONSOLE_ROTATION is not set > +CONFIG_GENERIC_ISA_DMA=y > CONFIG_HDMI=y > CONFIG_HID_BATTERY_STRENGTH=y > # CONFIG_HIGHMEM4G is not set > @@ -136,6 +137,7 @@ CONFIG_IOSF_MBI=y > CONFIG_ISA=y > CONFIG_ISAPNP=y > CONFIG_ISA_BUS_API=y > +CONFIG_ISA_DMA_API=y > # CONFIG_ISCSI_IBFT is not set > CONFIG_ISO9660_FS=y > # CONFIG_JOLIET is not set > diff --git a/target/linux/x86/legacy/config-5.15 > b/target/linux/x86/legacy/config-5.15 > index b424147073..74edf85abd 100644 > --- a/target/linux/x86/legacy/config-5.15 > +++ b/target/linux/x86/legacy/config-5.15 > @@ -109,6 +109,7 @@ CONFIG_FONT_SUPPORT=y > CONFIG_FRAMEBUFFER_CONSOLE=y > CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY=y > # CONFIG_FRAMEBUFFER_CONSOLE_ROTATION is not set > +CONFIG_GENERIC_ISA_DMA=y > CONFIG_HDMI=y > CONFIG_HID_BATTERY_STRENGTH=y > # CONFIG_HIGHMEM4G is not set > @@ -142,6 +143,7 @@ CONFIG_IOSF_MBI=y > CONFIG_ISA=y > CONFIG_ISAPNP=y >
Re: [PATCH 5/9] kernel/x86: remove CONFIG_M686 from common configuration
Reviewed-by: Philip Prindeville > On Apr 17, 2023, at 9:21 AM, Elliott Mitchell wrote: > > All of the sublevels choose their own values, so there is no point > in the common file having anything. This also removes a warning from > the kernel build process. > > Signed-off-by: Elliott Mitchell > --- > target/linux/x86/config-5.10 | 2 +- > target/linux/x86/config-5.15 | 2 +- > target/linux/x86/generic/config-5.10 | 1 - > target/linux/x86/generic/config-5.15 | 1 - > target/linux/x86/geode/config-5.10 | 1 - > target/linux/x86/geode/config-5.15 | 1 - > target/linux/x86/legacy/config-5.10 | 1 - > target/linux/x86/legacy/config-5.15 | 1 - > 8 files changed, 2 insertions(+), 8 deletions(-) > > diff --git a/target/linux/x86/config-5.10 b/target/linux/x86/config-5.10 > index f6c5400e73..afb7adc63a 100644 > --- a/target/linux/x86/config-5.10 > +++ b/target/linux/x86/config-5.10 > @@ -201,7 +201,7 @@ CONFIG_LOCK_DEBUGGING_SUPPORT=y > # CONFIG_M586 is not set > # CONFIG_M586MMX is not set > # CONFIG_M586TSC is not set > -CONFIG_M686=y > +# CONFIG_M686 is not set > # CONFIG_MACHZ_WDT is not set > # CONFIG_MATOM is not set > # CONFIG_MCORE2 is not set > diff --git a/target/linux/x86/config-5.15 b/target/linux/x86/config-5.15 > index f572a62e85..b59e809127 100644 > --- a/target/linux/x86/config-5.15 > +++ b/target/linux/x86/config-5.15 > @@ -204,7 +204,7 @@ CONFIG_LOCK_DEBUGGING_SUPPORT=y > # CONFIG_M586 is not set > # CONFIG_M586MMX is not set > # CONFIG_M586TSC is not set > -CONFIG_M686=y > +# CONFIG_M686 is not set > # CONFIG_MACHZ_WDT is not set > # CONFIG_MATOM is not set > # CONFIG_MCORE2 is not set > diff --git a/target/linux/x86/generic/config-5.10 > b/target/linux/x86/generic/config-5.10 > index b683720bf8..e5359b 100644 > --- a/target/linux/x86/generic/config-5.10 > +++ b/target/linux/x86/generic/config-5.10 > @@ -235,7 +235,6 @@ CONFIG_KVM_XFER_TO_GUEST_WORK=y > # CONFIG_LANCE is not set > CONFIG_LIBNVDIMM=y > CONFIG_LOCK_SPIN_ON_OWNER=y > -# CONFIG_M686 is not set > # CONFIG_MDA_CONSOLE is not set > CONFIG_MEMORY_BALLOON=y > CONFIG_MEMREGION=y > diff --git a/target/linux/x86/generic/config-5.15 > b/target/linux/x86/generic/config-5.15 > index 1da6ad555d..5dbd432ce5 100644 > --- a/target/linux/x86/generic/config-5.15 > +++ b/target/linux/x86/generic/config-5.15 > @@ -242,7 +242,6 @@ CONFIG_KVM_XFER_TO_GUEST_WORK=y > # CONFIG_LANCE is not set > CONFIG_LIBNVDIMM=y > CONFIG_LOCK_SPIN_ON_OWNER=y > -# CONFIG_M686 is not set > # CONFIG_MDA_CONSOLE is not set > CONFIG_MEMORY_BALLOON=y > CONFIG_MEMREGION=y > diff --git a/target/linux/x86/geode/config-5.10 > b/target/linux/x86/geode/config-5.10 > index 4c661cdf19..30b358b050 100644 > --- a/target/linux/x86/geode/config-5.10 > +++ b/target/linux/x86/geode/config-5.10 > @@ -70,7 +70,6 @@ CONFIG_ISA_BUS_API=y > # CONFIG_ISCSI_IBFT is not set > # CONFIG_LANCE is not set > CONFIG_LEDS_GPIO=y > -# CONFIG_M686 is not set > # CONFIG_MDA_CONSOLE is not set > CONFIG_MFD_CORE=y > CONFIG_MFD_CS5535=y > diff --git a/target/linux/x86/geode/config-5.15 > b/target/linux/x86/geode/config-5.15 > index ca4e0abc28..0c54cdaf9e 100644 > --- a/target/linux/x86/geode/config-5.15 > +++ b/target/linux/x86/geode/config-5.15 > @@ -77,7 +77,6 @@ CONFIG_ISA_BUS_API=y > # CONFIG_ISCSI_IBFT is not set > # CONFIG_LANCE is not set > CONFIG_LEDS_GPIO=y > -# CONFIG_M686 is not set > # CONFIG_MDA_CONSOLE is not set > CONFIG_MFD_CORE=y > CONFIG_MFD_CS5535=y > diff --git a/target/linux/x86/legacy/config-5.10 > b/target/linux/x86/legacy/config-5.10 > index 12330ba92f..a11eca8fc2 100644 > --- a/target/linux/x86/legacy/config-5.10 > +++ b/target/linux/x86/legacy/config-5.10 > @@ -142,7 +142,6 @@ CONFIG_ISO9660_FS=y > CONFIG_KCMP=y > # CONFIG_LANCE is not set > CONFIG_M586MMX=y > -# CONFIG_M686 is not set > # CONFIG_MDA_CONSOLE is not set > CONFIG_MFD_CORE=y > CONFIG_MFD_INTEL_LPSS=y > diff --git a/target/linux/x86/legacy/config-5.15 > b/target/linux/x86/legacy/config-5.15 > index a75ce40ab4..b424147073 100644 > --- a/target/linux/x86/legacy/config-5.15 > +++ b/target/linux/x86/legacy/config-5.15 > @@ -148,7 +148,6 @@ CONFIG_ISO9660_FS=y > CONFIG_KCMP=y > # CONFIG_LANCE is not set > CONFIG_M586MMX=y > -# CONFIG_M686 is not set > # CONFIG_MDA_CONSOLE is not set > CONFIG_MFD_CORE=y > CONFIG_MFD_INTEL_LPSS=y > -- > (\___(\___(\__ --=> 8-) EHM <=-- __/)___/)___/) > \BS (| ehem+open...@m5p.com PGP 87145445 |) / > \_CS\ | _ -O #include O- _ | / _/ > 8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445 > > > > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 4/9] kernel/x86: move SCx200 support from generic to geode
Reviewed-by: Philip Prindeville > On Apr 13, 2023, at 6:07 PM, Elliott Mitchell wrote: > > The SCx200 is part of the Geode platform. As such generic x86 > doesn't need the driver, but Geode does. > > Signed-off-by: Elliott Mitchell > --- > target/linux/x86/config-5.10 | 5 + > target/linux/x86/config-5.15 | 5 + > target/linux/x86/geode/config-5.10 | 3 +++ > target/linux/x86/geode/config-5.15 | 3 +++ > 4 files changed, 8 insertions(+), 8 deletions(-) > > diff --git a/target/linux/x86/config-5.10 b/target/linux/x86/config-5.10 > index cfd580b282..f6c5400e73 100644 > --- a/target/linux/x86/config-5.10 > +++ b/target/linux/x86/config-5.10 > @@ -305,10 +305,7 @@ CONFIG_SATA_HOST=y > # CONFIG_SC1200_WDT is not set > CONFIG_SCSI=y > CONFIG_SCSI_SPI_ATTRS=y > -CONFIG_SCx200=y > -CONFIG_SCx200HR_TIMER=y > -# CONFIG_SCx200_GPIO is not set > -# CONFIG_SCx200_WDT is not set > +# CONFIG_SCx200 is not set > CONFIG_SERIAL_8250_PCI=y > # CONFIG_SERIAL_LANTIQ is not set > CONFIG_SERIO=y > diff --git a/target/linux/x86/config-5.15 b/target/linux/x86/config-5.15 > index acfaa0e4b7..f572a62e85 100644 > --- a/target/linux/x86/config-5.15 > +++ b/target/linux/x86/config-5.15 > @@ -309,10 +309,7 @@ CONFIG_SATA_HOST=y > CONFIG_SCSI=y > CONFIG_SCSI_COMMON=y > CONFIG_SCSI_SPI_ATTRS=y > -CONFIG_SCx200=y > -CONFIG_SCx200HR_TIMER=y > -# CONFIG_SCx200_GPIO is not set > -# CONFIG_SCx200_WDT is not set > +# CONFIG_SCx200 is not set > CONFIG_SERIAL_8250_PCI=y > # CONFIG_SERIAL_LANTIQ is not set > CONFIG_SERIO=y > diff --git a/target/linux/x86/geode/config-5.10 > b/target/linux/x86/geode/config-5.10 > index dc2ac4454b..4c661cdf19 100644 > --- a/target/linux/x86/geode/config-5.10 > +++ b/target/linux/x86/geode/config-5.10 > @@ -112,7 +112,10 @@ CONFIG_RTC_I2C_AND_SPI=y > # CONFIG_SAMSUNG_Q10 is not set > CONFIG_SC1200_WDT=y > # CONFIG_SCSI_FDOMAIN_ISA is not set > +CONFIG_SCx200=y > +CONFIG_SCx200HR_TIMER=y > CONFIG_SCx200_ACB=y > +# CONFIG_SCx200_GPIO is not set > CONFIG_SCx200_WDT=y > # CONFIG_SENSORS_AMD_ENERGY is not set > CONFIG_SENSORS_LM90=y > diff --git a/target/linux/x86/geode/config-5.15 > b/target/linux/x86/geode/config-5.15 > index 2a8db278b3..ca4e0abc28 100644 > --- a/target/linux/x86/geode/config-5.15 > +++ b/target/linux/x86/geode/config-5.15 > @@ -122,7 +122,10 @@ CONFIG_RTC_I2C_AND_SPI=y > # CONFIG_SAMSUNG_Q10 is not set > CONFIG_SC1200_WDT=y > # CONFIG_SCSI_FDOMAIN_ISA is not set > +CONFIG_SCx200=y > +CONFIG_SCx200HR_TIMER=y > CONFIG_SCx200_ACB=y > +# CONFIG_SCx200_GPIO is not set > CONFIG_SCx200_WDT=y > CONFIG_SENSORS_LM90=y > CONFIG_SERIAL_8250_PNP=y > -- > (\___(\___(\__ --=> 8-) EHM <=-- __/)___/)___/) > \BS (| ehem+open...@m5p.com PGP 87145445 |) / > \_CS\ | _ -O #include O- _ | / _/ > 8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445 > > > > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 3/9] kernel/x86: move Geode HW random from generic to geode
Reviewed-by: Philip Prindeville > On Apr 19, 2023, at 3:07 PM, Elliott Mitchell wrote: > > Quite reasonable to have support for the Geode HW random number > generator. On the Geode kernel. > > Support for the VIA HWRNG has been enabled in common. Pull that > from the Geode kernel. > > Signed-off-by: Elliott Mitchell > --- > target/linux/x86/config-5.10 | 1 - > target/linux/x86/config-5.15 | 1 - > target/linux/x86/geode/config-5.10 | 2 ++ > target/linux/x86/geode/config-5.15 | 2 ++ > 4 files changed, 4 insertions(+), 2 deletions(-) > > diff --git a/target/linux/x86/config-5.10 b/target/linux/x86/config-5.10 > index 1a2f0d653a..cfd580b282 100644 > --- a/target/linux/x86/config-5.10 > +++ b/target/linux/x86/config-5.10 > @@ -156,7 +156,6 @@ CONFIG_HPET_EMULATE_RTC=y > CONFIG_HPET_TIMER=y > # CONFIG_HP_WATCHDOG is not set > CONFIG_HW_CONSOLE=y > -CONFIG_HW_RANDOM_GEODE=y > CONFIG_HW_RANDOM_VIA=y > # CONFIG_HYPERVISOR_GUEST is not set > CONFIG_HZ_PERIODIC=y > diff --git a/target/linux/x86/config-5.15 b/target/linux/x86/config-5.15 > index 715090977b..acfaa0e4b7 100644 > --- a/target/linux/x86/config-5.15 > +++ b/target/linux/x86/config-5.15 > @@ -157,7 +157,6 @@ CONFIG_HPET_EMULATE_RTC=y > CONFIG_HPET_TIMER=y > # CONFIG_HP_WATCHDOG is not set > CONFIG_HW_CONSOLE=y > -CONFIG_HW_RANDOM_GEODE=y > CONFIG_HW_RANDOM_VIA=y > # CONFIG_HYPERVISOR_GUEST is not set > CONFIG_HZ_PERIODIC=y > diff --git a/target/linux/x86/geode/config-5.10 > b/target/linux/x86/geode/config-5.10 > index 579f316914..dc2ac4454b 100644 > --- a/target/linux/x86/geode/config-5.10 > +++ b/target/linux/x86/geode/config-5.10 > @@ -49,6 +49,8 @@ CONFIG_GPIO_CS5535=y > # CONFIG_HPET is not set > # CONFIG_HP_ACCEL is not set > CONFIG_HWMON=y > +CONFIG_HW_RANDOM_GEODE=y > +CONFIG_HW_RANDOM_VIA=n > CONFIG_I2C=y > CONFIG_I2C_ALGOBIT=y > CONFIG_I2C_ALGOPCA=y > diff --git a/target/linux/x86/geode/config-5.15 > b/target/linux/x86/geode/config-5.15 > index 2ede23ea5e..2a8db278b3 100644 > --- a/target/linux/x86/geode/config-5.15 > +++ b/target/linux/x86/geode/config-5.15 > @@ -53,6 +53,8 @@ CONFIG_GPIO_CS5535=y > # CONFIG_HPET is not set > # CONFIG_HP_ACCEL is not set > CONFIG_HWMON=y > +CONFIG_HW_RANDOM_GEODE=y > +CONFIG_HW_RANDOM_VIA=n > CONFIG_I2C=y > CONFIG_I2C_ALGOBIT=y > CONFIG_I2C_ALGOPCA=y > -- > (\___(\___(\__ --=> 8-) EHM <=-- __/)___/)___/) > \BS (| ehem+open...@m5p.com PGP 87145445 |) / > \_CS\ | _ -O #include O- _ | / _/ > 8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445 > > > > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 2/9] kernel: change CONFIG_HW_RANDOM default to y
Why isn't this migrating upwards into target/linux/generic/config-5.15 and target/linux/generic/config-5.10 in that case? And for the platforms where it was turned off, like target/linux/armvirt/32/config-5.15, why isn't that staying unchanged? > On Apr 22, 2023, at 11:46 AM, Elliott Mitchell wrote: > > Many devices do not have hardware random number generators. Yet > more do than don't, and they are becoming more common. > > Signed-off-by: Elliott Mitchell > --- > target/linux/airoha/config-5.15 | 1 - > target/linux/apm821xx/config-5.10 | 1 - > target/linux/apm821xx/config-5.15 | 1 - > target/linux/archs38/config-5.10| 1 + > target/linux/archs38/config-5.15| 1 + > target/linux/armvirt/32/config-5.10 | 1 + > target/linux/armvirt/32/config-5.15 | 1 + > target/linux/armvirt/64/config-5.10 | 1 - > target/linux/armvirt/64/config-5.15 | 1 - > target/linux/ath25/config-5.10 | 1 - > target/linux/ath79/config-5.10 | 1 + > target/linux/ath79/config-5.15 | 1 + > target/linux/bcm47xx/config-5.10| 1 - > target/linux/bcm47xx/config-5.15| 1 - > target/linux/bcm4908/config-5.10| 1 + > target/linux/bcm4908/config-5.15| 1 + > target/linux/bcm53xx/config-5.10| 1 - > target/linux/bcm53xx/config-5.15| 1 - > target/linux/bcm63xx/config-5.15| 1 - > target/linux/gemini/config-5.10 | 1 + > target/linux/gemini/config-5.15 | 1 - > target/linux/generic/config-5.10| 2 +- > target/linux/generic/config-5.15| 2 +- > target/linux/imx/config-5.15| 1 - > target/linux/ipq40xx/config-5.15| 1 - > target/linux/ipq806x/config-5.10| 1 - > target/linux/ipq806x/config-5.15| 1 - > target/linux/ipq807x/config-5.15| 1 + > target/linux/kirkwood/config-5.10 | 1 - > target/linux/kirkwood/config-5.15 | 1 - > target/linux/lantiq/ase/config-5.10 | 1 - > target/linux/lantiq/ase/config-5.15 | 1 - > target/linux/lantiq/falcon/config-5.10 | 1 + > target/linux/lantiq/falcon/config-5.15 | 1 + > target/linux/lantiq/xrx200/config-5.10 | 1 - > target/linux/lantiq/xrx200/config-5.15 | 1 - > target/linux/lantiq/xway/config-5.10| 1 - > target/linux/lantiq/xway/config-5.15| 1 - > target/linux/lantiq/xway_legacy/config-5.10 | 1 + > target/linux/lantiq/xway_legacy/config-5.15 | 1 + > target/linux/malta/config-5.10 | 1 + > target/linux/malta/config-5.15 | 1 + > target/linux/mpc85xx/config-5.10| 1 - > target/linux/mpc85xx/config-5.15| 1 - > target/linux/mvebu/config-5.10 | 1 - > target/linux/mvebu/config-5.15 | 1 - > target/linux/mxs/config-5.15| 1 + > target/linux/octeon/config-5.10 | 1 - > target/linux/octeon/config-5.15 | 1 - > target/linux/octeontx/config-5.15 | 1 - > target/linux/omap/config-5.10 | 1 - > target/linux/omap/config-5.15 | 1 - > target/linux/oxnas/config-5.15 | 1 + > target/linux/pistachio/config-5.10 | 1 + > target/linux/pistachio/config-5.15 | 1 + > target/linux/qoriq/config-5.15 | 1 - > target/linux/sunxi/config-5.15 | 1 - > target/linux/tegra/config-5.10 | 1 + > target/linux/tegra/config-5.15 | 1 + > target/linux/uml/config-5.10| 1 - > target/linux/uml/config-5.15| 1 - > target/linux/x86/config-5.10| 1 - > target/linux/x86/config-5.15| 1 - > target/linux/zynq/config-5.15 | 1 + > 64 files changed, 25 insertions(+), 41 deletions(-) > > diff --git a/target/linux/airoha/config-5.15 b/target/linux/airoha/config-5.15 > index adc8cdfb9b..cdee4b2d51 100644 > --- a/target/linux/airoha/config-5.15 > +++ b/target/linux/airoha/config-5.15 > @@ -128,7 +128,6 @@ CONFIG_HAS_IOMEM=y > CONFIG_HAS_IOPORT_MAP=y > CONFIG_HAVE_SMP=y > CONFIG_HOTPLUG_CPU=y > -CONFIG_HW_RANDOM=y > CONFIG_HZ_FIXED=0 > CONFIG_INITRAMFS_SOURCE="" > # CONFIG_IOMMU_DEBUGFS is not set > diff --git a/target/linux/apm821xx/config-5.10 > b/target/linux/apm821xx/config-5.10 > index 89d72e2641..6fcb9e4803 100644 > --- a/target/linux/apm821xx/config-5.10 > +++ b/target/linux/apm821xx/config-5.10 > @@ -97,7 +97,6 @@ CONFIG_GPIO_GENERIC_PLATFORM=y > CONFIG_HAS_DMA=y > CONFIG_HAS_IOMEM=y > CONFIG_HAS_IOPORT_MAP=y > -CONFIG_HW_RANDOM=y > CONFIG_HW_RANDOM_PPC4XX=y > CONFIG_I2C=y > CONFIG_I2C_BOARDINFO=y > diff --git a/target/linux/apm821xx/config-5.15 > b/target/linux/apm821xx/config-5.15 > index 2af8110553..fddf0cd4e2 100644 > --- a/target/linux/apm821xx/config-5.15 > +++ b/target/linux/apm821xx/config-5.15 > @@ -96,7 +96,6 @@ CONFIG_GPIO_GENERIC_PLATFORM=y > CONFIG_HAS_DMA=y >
Re: [PATCH 2/8] kernel/x86: move SCx200 support from generic to geode
Reviewed-by: Philip Prindeville > On Apr 13, 2023, at 6:07 PM, Elliott Mitchell wrote: > > The SCx200 is part of the Geode platform. As such generic x86 > doesn't need the driver, but Geode does. > > Signed-off-by: Elliott Mitchell > --- > target/linux/x86/config-5.10 | 5 + > target/linux/x86/config-5.15 | 5 + > target/linux/x86/geode/config-5.10 | 3 +++ > target/linux/x86/geode/config-5.15 | 3 +++ > 4 files changed, 8 insertions(+), 8 deletions(-) > > diff --git a/target/linux/x86/config-5.10 b/target/linux/x86/config-5.10 > index d7eb89bd6e..cdf636d05f 100644 > --- a/target/linux/x86/config-5.10 > +++ b/target/linux/x86/config-5.10 > @@ -307,10 +307,7 @@ CONFIG_SATA_HOST=y > # CONFIG_SC1200_WDT is not set > CONFIG_SCSI=y > CONFIG_SCSI_SPI_ATTRS=y > -CONFIG_SCx200=y > -CONFIG_SCx200HR_TIMER=y > -# CONFIG_SCx200_GPIO is not set > -# CONFIG_SCx200_WDT is not set > +CONFIG_SCx200=n > CONFIG_SERIAL_8250_PCI=y > # CONFIG_SERIAL_LANTIQ is not set > CONFIG_SERIO=y > diff --git a/target/linux/x86/config-5.15 b/target/linux/x86/config-5.15 > index bf1c7bf8d5..b738358216 100644 > --- a/target/linux/x86/config-5.15 > +++ b/target/linux/x86/config-5.15 > @@ -311,10 +311,7 @@ CONFIG_SATA_HOST=y > CONFIG_SCSI=y > CONFIG_SCSI_COMMON=y > CONFIG_SCSI_SPI_ATTRS=y > -CONFIG_SCx200=y > -CONFIG_SCx200HR_TIMER=y > -# CONFIG_SCx200_GPIO is not set > -# CONFIG_SCx200_WDT is not set > +CONFIG_SCx200=n > CONFIG_SERIAL_8250_PCI=y > # CONFIG_SERIAL_LANTIQ is not set > CONFIG_SERIO=y > diff --git a/target/linux/x86/geode/config-5.10 > b/target/linux/x86/geode/config-5.10 > index 579f316914..9ef5101c14 100644 > --- a/target/linux/x86/geode/config-5.10 > +++ b/target/linux/x86/geode/config-5.10 > @@ -110,7 +110,10 @@ CONFIG_RTC_I2C_AND_SPI=y > # CONFIG_SAMSUNG_Q10 is not set > CONFIG_SC1200_WDT=y > # CONFIG_SCSI_FDOMAIN_ISA is not set > +CONFIG_SCx200=y > +CONFIG_SCx200HR_TIMER=y > CONFIG_SCx200_ACB=y > +# CONFIG_SCx200_GPIO is not set > CONFIG_SCx200_WDT=y > # CONFIG_SENSORS_AMD_ENERGY is not set > CONFIG_SENSORS_LM90=y > diff --git a/target/linux/x86/geode/config-5.15 > b/target/linux/x86/geode/config-5.15 > index 2ede23ea5e..d39c305811 100644 > --- a/target/linux/x86/geode/config-5.15 > +++ b/target/linux/x86/geode/config-5.15 > @@ -120,7 +120,10 @@ CONFIG_RTC_I2C_AND_SPI=y > # CONFIG_SAMSUNG_Q10 is not set > CONFIG_SC1200_WDT=y > # CONFIG_SCSI_FDOMAIN_ISA is not set > +CONFIG_SCx200=y > +CONFIG_SCx200HR_TIMER=y > CONFIG_SCx200_ACB=y > +# CONFIG_SCx200_GPIO is not set > CONFIG_SCx200_WDT=y > CONFIG_SENSORS_LM90=y > CONFIG_SERIAL_8250_PNP=y > -- > (\___(\___(\__ --=> 8-) EHM <=-- __/)___/)___/) > \BS (| ehem+open...@m5p.com PGP 87145445 |) / > \_CS\ | _ -O #include O- _ | / _/ > 8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445 > > > > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
