Re: Removing dpkg arch definition for arm64ilp32?
On Sat, Nov 11, 2023 at 08:36:16PM +, Wookey wrote: >On 2023-11-11 18:57 +0100, Guillem Jover wrote: >> Hi! >> >> On Fri, 2023-10-27 at 20:17:21 -0400, Lennart Sorensen wrote: >> > On Fri, Oct 27, 2023 at 02:29:30PM +0100, Steve McIntyre wrote: >> > > Are either of those ports (armeb/arm64ilp32) actually useful / alive >> > > at this point? >> > >> > Not that I have seen. I didn't think anything other than the IXP ever >> > really used big endian and that's a long time ago. arm64ilp32 seems >> > to serve less purpose than x32 did (and x32 doesn't seem to be doing >> > much either). Certainly looks essentially dead at this point. >> >> While scanning the libc-alpha list recently I read [M] that arm64ilp32 >> was never upstreamed in Linux nor glibc? If so, I think there's little >> point in carrying the arch definitions in dpkg, and I guess that would >> not make the cut if requested now (for reference this was requested in >> bug #824742). Does anyone know whether it was ever used or it is being >> used even if privately/internally somewhere? > >It was being used internally/developmentally for a while (at CISCO) >but, as you observe, only with large kernel and toolchain >patches. Various groups dragged their feet on this to disourage it >becoming a thing we'd all have to maintain for years. I was doing the >debian development at ARM at the time and the bootstrap was never >completed. A few people (largely just CISCO) wanted it quite >badly. Nearly everyone else thought it was not worth the maintenance >effort. No-one has asked about it for quite a few years now (last mail >Oct 2018) so I think we can assume that it is indeed dead and no-one >would notice for years/ever if you removed it from dpkg. +1 on the story and on dropping it. >> For armeb, I assume it was properly upstreamed at the time, and it was >> actually used, even if it's currently not in use (like arm) I see tons >> of references in Sources files, and thus removing the arch definitions >> for either of these would not be safe right now I think. > >It is obsolete. It probably doesn't work any more having been unused >since the early days of the NSLU2/Sarge (circa 2006/2007). It might >still have been in use till 2011ish?. As you say it should probably be >removed from upstream sources before it is removed from >dpkg. Interesting question on how much effort (if any) (and when) >should be applied to tidying up stuff like this which is simply no >longer in use. If/when 'arm' is removed 'armeb' should certainly go >with it. armeb was mostly before my involvement in any arm stuff, as Wookey says. It did at least have some life as a functioning port, at least. I'd agree on leaving it in place for now, assuming it's not causing any trouble in terms of maintenance / support. -- Steve McIntyre, Cambridge, UK.st...@einval.com "You can't barbecue lettuce!" -- Ellie Crane
Re: Bug#1054583: dpkg-dev: really enable -fstack-clash-protection onarmhf/armel
On Fri, Oct 27, 2023 at 10:30:33AM -0400, gene heskett wrote: >On 10/27/23 09:30, Steve McIntyre wrote: >> >> Are either of those ports (armeb/arm64ilp32) actually useful / alive >> at this point? >> >Another architecture you might consider adding is whatever is used in the >banana-pi-m5 boards, its an improvement on the rpi4b, without the radio, and >with all 4 usb ports running at usb3 speeds. With a 4 core arm64 running at >2GHz, so its a bit faster than the rpi4. With spi support, it would make a >great replacement for the rpi4b. At under $90 USD. Currently running >ubuntu-jammy based distro in arm64 flavor, called armbian. And running >several 3d printers here. Good stable boards. Gene, please stay out of this. You have no idea what I'm talking about here. -- Steve McIntyre, Cambridge, UK.st...@einval.com Armed with "Valor": "Centurion" represents quality of Discipline, Honor, Integrity and Loyalty. Now you don't have to be a Caesar to concord the digital world while feeling safe and proud.
Re: Bug#1054583: dpkg-dev: really enable -fstack-clash-protection on armhf/armel
On Fri, Oct 27, 2023 at 03:23:10PM +0200, Emanuele Rocca wrote: >Hi Guillem, > >On 2023-10-27 04:33, Guillem Jover wrote: >> Checking now again, I realize Wookey mentioned enabling this for the 3 >> arm arches (those would be arm64, armhf and armel), so the patch I >> provided would match that. But I was wondering now what about armeb and >> arm64ilp32? I mean, I assume those should be excluded for now as they >> did not get any testing, and they might not even be used/lively(?), > >Correct, there has been no testing done on armeb/arm64ilp32 as far as >I'm aware. I'd suggest enabling the feature only on armhf/armel for the >time being. Are either of those ports (armeb/arm64ilp32) actually useful / alive at this point? -- Steve McIntyre, Cambridge, UK.st...@einval.com "You can't barbecue lettuce!" -- Ellie Crane
Re: unbreaking LibreOffices tests on at least release architectures
On Sun, Jun 18, 2023 at 10:32:55AM +0200, Rene Engelhard wrote: >Hi, > >Am 18.06.23 um 10:19 schrieb John Paul Adrian Glaubitz: >> On Sun, 2023-06-18 at 09:31 +0200, Rene Engelhard wrote: >> > Also note I am not talking about the debian-ports architectures. Those I >> > forgot and I have no problems making them stay into "testsuite ran but >> > results ignored" set. >> Why did you send this mail exclusively to debian-ports then? > >I (obviously) wrongly assumed that this was the magic address which >duplicates to every port. > >Must have misremembered. It still does - I got this copy via the debian-arm list... -- Steve McIntyre, Cambridge, UK.st...@einval.com "This dress doesn't reverse." -- Alden Spiess
Re: Bug#1029843: live-boot: Devices Requiring Firmware: multiple requested files in single line overlapping / special characters
On Tue, May 09, 2023 at 09:53:54AM -0400, Lennart Sorensen wrote: >On Tue, May 09, 2023 at 12:22:02AM +0100, Pete Batard wrote: > >> Again, I'd prefer to go with number end-users as a better measure, since >> we're not developing for the greater variety but for is likely to benefit >> the greater masses. Of course, if ARM64 system manufacturers collectively >> decide they want to ignore Windows and SBBR, and go with openfirmware, I'll >> be more than happy to let Microsoft add openfirmware compatibility to >> Windows on ARM, as long as the end-users stop having to jump through >> system-specific hoops to install the OS they want. > >Well certainly devicetree makes the kernel and driver handling much >simpler and more consistent, but the boot loader on all the different >arm systems isn't standardized. Using UEFI on SBBR means a standard >grub2 uefi boot loader should work on any system, so that does seem >like a benefit. Of course that really just means UEFI might be a big >improvement, not that ACPI vs devicetree is. No idea if UEFI can work >with devicetree or not. Being an intel thing I would not be surprised >if ACPI is rather tied into it, since that would make sense. A quick >look at wikipedia says UEFI actually provides devicetree services on >RISC processor systems. I guess that makes sense since pretty much all >RISC systems seem to have used openfirmware or something similar so >their OS would expect that. Little endian only though of course. UEFI doesn't have to push ACPI, no. Indeed, some of the UEFI platforms out there (e.g. Macchiatobin) let you choose whether to pass on DT or ACPI to the boot loader / OS. AIUI the main reason that Microsoft went with ACPI on the Arm platform is just that they already had ACPI for x86. It's therefore much easier for them to push the same requirements onto new platforms, of course. DT for Arm is very much *not* just for Linux (see FreeBSD and other OSes, and of course various boot loaders). However, there is still an outstanding historical mess: lofs of Linux developers think that the DT configuration on various platforms is theirs to change as they please to suit the Linux kernel. The original DT plan was to only ever include DT sources with the Linux tree as a *temporary* thing until a reasonable number of platforms provided DT data directly from firmware. DT was just meant to be a static description *of the hardware*. But (like a lot of "temporary" things), we're now a lot of years later and there's no sign this is ever going to change. There's certainly no will to have a fight about this. Against that background, I genuinely think Microsoft have done the sensible thing by sticking to ACPI rather than embracing DT for Arm platforms... -- Steve McIntyre, Cambridge, UK.st...@einval.com Dance like no one's watching. Encrypt like everyone is. - @torproject
Re: Status of dpkg-shlibdeps tracking ARM object linkage ABI mismatches
Hey Guillem! On Thu, Apr 27, 2023 at 11:27:47PM +0200, Guillem Jover wrote: >Hi Steve! > >I was recently working on the Dpkg::Shlibs::Objdump module code >related to ELF and ABI tracking, and when seeing the ARM handling >missing there, recalled the issues we saw some time ago with ARM >when I tried to make that tracking more strict, which had to be >reverted due to issues with objects in the wild. For context that >was #853793. Oh $deity, that's going back a while... :-) >I was wondering whether you (or know if someone else) had worked on >the ARM port side of things to clean up those issues, from toolchain to >specific objects in packages? I'm not in a hurry to add that code back >so do not feel any pressure from this, I'm mostly wondering where we are >at with this, and whether there is something I can improve from dpkg side >in that regard, but if not that's also fine, and then I'd probably try >to update the status somewhere (code comment or wiki or something). I've moved on from being employed by Arm 3 years ago, and I've got plenty of other things to keep me busy now. If we're still seeing issues in packages today, then maybe we might find some help from Wookey or Emmanuel (who should both be reading this list!). >(I think at least the issue with wine should be solved now with commit >https://salsa.debian.org/wine-team/wine/-/commit/51f48d3e6c04cef760610d14ba5f368e7f2baf7a) Nod. -- Steve McIntyre, Cambridge, UK.st...@einval.com "War does not determine who is right - only who is left." -- Bertrand Russell
Re: Kernel doesn't find SATA ports on Softiron 1000 (arm64 Seattle)
On Sun, Mar 05, 2023 at 12:09:24AM +, Steve McIntyre wrote: >Source: linux >Version: 6.1.12-1 >Severity: important > >Hey folks, > >I've just upgraded my Seattle-based system to bookworm and it no >longer finds the onboard AHCI SATA storage so it stops at an initramfs >prompt. Going back to the current bullseye kernel (5.10.162-1), it all >works just fine. > >As far as I can see, the DTB hasn't changed in this area. The >non-booting system still has plausible-looking entries for the sATA >controllers: > >drwxr-xr-x2 000 Mar 5 00:00 >/sys/firmware/devicetree/base/smb/sata@e030 >drwxr-xr-x2 000 Mar 5 00:00 >/sys/firmware/devicetree/base/smb/sata@e0d0 > >I'll try to bisect and see where things stopped working... The failure appears in between Linux maul 6.0.0-6-arm64 #1 SMP Debian 6.0.12-1 (2022-12-09) aarch64 GNU/Linux and Linux (none) 6.1.0-0-arm64 #1 SMP Debian 6.1~rc3-1~exp1 (2022-11-02) aarch64 GNU/Linux A quick look at the output of "git diff -r debian/6.0.12-1..debian/6.1_rc3-1_exp1" in the debian linux tree doesn't show me anything likely, BICBW. Adding a CC to the debian-arm list in case any of our friendly local ARM kernel folks might be able to help... -- Steve McIntyre, Cambridge, UK.st...@einval.com "When C++ is your hammer, everything looks like a thumb." -- Steven M. Haflich
Re: About ARM
On Sat, Feb 11, 2023 at 10:21:23AM +0800, xiao sheng wen(肖盛文) wrote: >Hi Paolo, > >Debian iso support BIOS and EFI in amd64 arch. > >I didn't know whether if has any arm64 arch CPU support BIOS. No, not at all. The BIOS (as most people understand it) is an x86-only thing. There are *many* firmware implementations on various arm/arm64 platforms. The two most likely ones you'll fine on arm64 boards and machines are * U-Boot (either loading booting kernels directly, or as a limited EFI) * Tianocore (EFI only) You can happily boot Debian on many machines using either. In terms of booting the installer, there are a range of images that you can use for different U-Boot machines, or with EFI you should be able to use the standard ISOs. The libreboot link from Paolo is talking about ancient x86 hardware with coreboot, which isn't really relevant here. -- Steve McIntyre, Cambridge, UK.st...@einval.com "We're the technical experts. We were hired so that management could ignore our recommendations and tell us how to do our jobs." -- Mike Andrews
Re: another attempt at Y2038
On Tue, Oct 18, 2022 at 03:33:17PM +0200, John Paul Adrian Glaubitz wrote: >Hi Helmut! > >On 10/18/22 12:48, Helmut Grohne wrote: >> I was also wondering about this Y2038 thingy and did some experiments. >> I'm reporting what I found to document it, but don't see much actionable >> stuff here. Many thanks to Arnd Bergmann for his input. >> >> Attempt #1: rebootstrap >> >> Given that I develop rebootstrap, attempting to use it for a time64 >> bootstrap seemed quite natural. I've been talking to this with Steve >> multiple times including DC22. The question was how to plug it in. In >> the end I went for Arnd's suggestion to set DPKG_*_APPEND variables to >> modify dpkg-buildflags. Not every package uses these flags, but a >> majority do. For a survey, this is probably good enough. > >I would love to do that for m68k as well. We could use this opportunity to >rebuild the m68k port with 32-bit alignment which would solve quite a number >of problems since many projects like LLVM and Qt assume a minimum alignment >of 32 bits while m68k still defaults to 16 bits. > >Since the time64 rebootstrap would break the ABI anyway, we could use to fix >alignment issue on m68k once and for all :-). So the reason that we're talking about doing a replacement armhf port is for two reasons: * it's probably one of the few 32-bit arches that is likely to still be in routine use beyond 2038 (*many* embedded users depending on Debian stuff) * it's feasible to rebootstrap and break ABI as there isn't a large corpus of older-ABI binaries that people will care about supporting in the future. (This rules out i386 - the main reason to keep it around is just for the older binaries AFAICS.) I don't want to be rude, but I really don't see how m68k fits here. Of course, feel free to do a rebootstrap if you like, but I genuinely don't see any great need for it. -- Steve McIntyre, Cambridge, UK.st...@einval.com “Changing random stuff until your program works is bad coding practice, but if you do it fast enough it’s Machine Learning.” -- https://twitter.com/manisha72617183
Re: On the existance of arm* porters
On Thu, Aug 25, 2022 at 09:15:07AM -0700, ` Vagrant Cascadian wrote: >On 2022-08-25, Graham Inggs wrote: >> On Wed, 16 Feb 2022 at 13:36, John Paul Adrian Glaubitz >> wrote: > >>> it seems superficially plausible that the march=native >>> invocations are just instances of the compiler being probed. >> >> I have also had a look and cannot see that '-march=native' is used in >> the actual builds on any of the architectures. >> >> It would be very much appreciated if the arm porters could take a look >> at this issue, as it still plagues the scikit-learn autopkgtests on >> armhf [2], and currently prevents quite a number of packages from >> being part of testing. It appears that armel [1] has the same error, >> so hopefully one fix could resolve both. > >I pretty much think of myself, at best, as half an armhf/arm64 porter, >but this is a little bit outside of the scope of what I offered to look >after in the porter roll calls... > >Apparently I am the only porter for armhf and arm64? I had assumed there >would be someone else to fill the gaps in my skillset, but I guess >not. Argh. I used to do this, but I don't have the time or the inclination to step up any more. I'm very surprised to not see Wookey not list himself, tbh. -- Steve McIntyre, Cambridge, UK.st...@einval.com 'There is some grim amusement in watching Pence try to run the typical "politician in the middle of a natural disaster" playbook, however incompetently, while Trump scribbles all over it in crayon and eats some of the pages.' -- Russ Allbery
Re: Debian on Pine64 H64B?
On Sat, Sep 04, 2021 at 09:43:07AM -0400, Gene Heskett wrote: >On Saturday 04 September 2021 04:48:48 Reco wrote: > >> Whatever floats your boat. > >That attitude is Indicating to me that debian-arm still has zero interest >in arm. A sad truth IMO. Thanks Gene, that's *really* going to help motivate the various folks who are working on support for Arm platforms, most of them doing that work on their own time as volunteers. -- Steve McIntyre, Cambridge, UK.st...@einval.com "This dress doesn't reverse." -- Alden Spiess
Re: WARNING! shim-signed on arm64 in buster may fail to boot
On Tue, Jun 22, 2021 at 10:20:52AM +0200, Arne Ploese wrote: >Hi Steve, >the install images (i.e. >https://cdimage.debian.org/debian-cd/current/arm64/iso-cd/debian-10.10.0-arm64-netinst.iso) >are outdated too. I hit the bug after upgrading, and tried to install >it fresh - but got the same error :-). Yup. I'll have to respin the installer images soon. I'm also looking at another shim upload, so I'm probably going to wait for that yet. -- Steve McIntyre, Cambridge, UK.st...@einval.com "This dress doesn't reverse." -- Alden Spiess
Re: WARNING! shim-signed on arm64 in buster may fail to boot
Hi again, On Mon, Jun 21, 2021 at 10:46:53AM +0100, Steve McIntyre wrote: > >In testing of the 10.10. point release over the weekend, we found a >significant problem with shim-signed on arm64. ... >I'm working on a more user-friendly fix now, and I hope to push it out >via the buster-updates archive shortly. This will still not be >*working* Secure Boot for arm64, as we're still awaiting better >toolchain support to make that work. We've now released an update for shim-signed which should solve this problem: https://lists.debian.org/debian-stable-announce/2021/06/msg1.html Apologies for any hassle caused. :-( -- Steve McIntyre, Cambridge, UK.st...@einval.com You lock the door And throw away the key There's someone in my head but it's not me
WARNING! shim-signed on arm64 in buster may fail to boot
Hi folks, In testing of the 10.10. point release over the weekend, we found a significant problem with shim-signed on arm64. In pre-release testing I found problems with shim on signed versions of shim on arm64. The shim binary crashes very early (Synchronous Exception). Because of that problem, I took the hard decision to disable Secure Boot support for arm64 in Debian Buster until a solution could be found: https://wiki.debian.org/SecureBoot#arm64_problems In testing a new build to go into Buster, I found that non-signed versions were working fine on various machines. Unfortunately, it seems that the boot issues might be affected by environment. Trying the same binary build on Saturday as part of the 10.10 point release, booting an installer image crashes repeatably in a VM. It also seems that at least one of Debian's own arm64 hosts has been similarly affected. :-( Arm64 users are **strongly** advised to be careful about upgrading to the latest Buster point release (10.10). If upgrading immediately, it is recommended to disable remove shim-signed and reinstall GRUB on those systems to ensure that they will continue to boot: # apt-get remove shim-signed # dpkg --reconfigure grub-efi-amd64 and disable Secure Boot in their system firmware if it's enabled. I'm working on a more user-friendly fix now, and I hope to push it out via the buster-updates archive shortly. This will still not be *working* Secure Boot for arm64, as we're still awaiting better toolchain support to make that work. -- Steve McIntyre, Cambridge, UK.st...@einval.com "...In the UNIX world, people tend to interpret `non-technical user' as meaning someone who's only ever written one device driver." -- Daniel Pead
Re: Feedback from the community -> ARM
On Sun, Jun 13, 2021 at 01:42:55AM +0100, Pete Batard wrote: > >Granted we also should have logged a bug for that issue as soon as we picked >it up, so we have to share part of the blame on this one. But the delays in >processing #985956, even though we tried to bring attention over and over >again to the fact that this very negatively affected one of the rare UEFI >installation of Bullseye on ARM64, on what has to be the current most >widespread system for that arch, was a bit concerning. Especially, it is not >the first time we've seen what I would qualify as extended delays in trying >to get showstopping UEFI patches looked into. As a matter of fact, I >eventually gave up trying to get the necessary Pi4 network patches backported >into Debian 10 (#950578), because even though we did submit a working patch >from the get go, it took 3 months (!) to actually get someone on the Debian >side to look into it, only to then tell us to just go re-do that patch, which >is not what I would qualify as a viable mode of operation. So AFAICS what you're seeing is a severe lack of volunteer time to do some things in Debian. I've been one of the more active Debian arm porters in recent years, but I've moved on to other things and been swamped with things like shim and grub security work in my "spare" time for the last year or so. I'm also busy with a new job that (so far) has very little to do with the Arm world, so I've not been able to spend work time to pick up on some of these issues where prveiously I might have done. While this stuff is important for you and others, I'm afraid that doesn't necessarily make it top priority for volunteers already overloaded with other projects. That's not a lack of will to help, it's simple logistics. :-( We need to get more people involved to help, and that's often a struggle. >So, at the risk of being controversial, it doesn't seem to me like everybody >in the Debian world has been that willing to embrace UEFI. Or if they do, >then not everybody appears to have recognized the importance of being able to >provide Debian in UEFI mode on what has to account for the most popular ARM64 >platform. And I could point to further evidence of this when I also brought >the idea on this list that, maybe, it was time for Debian to start looking >into moving away from using good old uboot or similar for distributing >special installable images for platforms like the Pi not that we have a full >blown UEFI, as this very idea seemed to irk a few people (which, to be fair, >may not have been directly affiliated with Debian). As a Debian UEFI team person, I'm *really* happy that finally we have an affordable platform that might work sensibly like this. As Marcin says: if anything, our arm64 port has expected UEFI from the get-go. There are still remnants of this assumption in d-i if you go looking, where we don't work well enough on other platforms. However, one of our biggest issues has been the ridiculously, *appallingly* over-diverse Arm ecosystem with vendors continuing to push special-snowflake SBCs that all need special consideration just to do the simple basic things. It's batshit insane. On reflection, that mess was one of the reasons why I changed jobs. It was causing enough stress that I had to get away from it. >But regardless of this, my remark was aimed more at the topic at hand which >should be what feedback Debian may want to convey to the ARM community, and >especially the ARM platform manufacturers, and therefore goes beyond than >just the Raspberry Pi platform. > >In short, I would reiterate that, in light of the headaches caused by all the >other approaches, and especially a requirement that still seems to boil down >to providing custom images (in part because of custom boot methods as well as >proprietary blobs, which I don't realistically see as going away) the >feedback Debian should provide to ARM vendors is that, if the latter want >better cooperation with Linux distros, then they should put the onus on >releasing a working UEFI firmware for their platform, especially as it's been >demonstrated that, even for an SBC as quirky and as ill-suited for it as the >Raspberry Pi (and that was part of the point of the whole exercise), it is >not that difficult to achieve. +1000 -- Steve McIntyre, Cambridge, UK.st...@einval.com "...In the UNIX world, people tend to interpret `non-technical user' as meaning someone who's only ever written one device driver." -- Daniel Pead
Re: Debian on Apple M1 hardware
On Sat, Mar 13, 2021 at 12:12:34PM +, Pip Cet wrote: > On Sat, Mar 13, 2021 at 11:49 AM Wookey wrote: >> On 2021-03-13 10:05 +, Pip Cet wrote: >> > On Sat, Mar 13, 2021 at 9:30 AM Paul Wise wrote: >> > > so this is likely to be superseded >> > > by the work Asahi Linux is doing within Linux mainline at some point. >> >> I hadn't realised there were two projects working on this. That is >> good. But I agree with Paul that Corellium are goig to remain >> irrelevant froma debian POV if they don't upstream their code (someone > >I agree with that, too, but it's a big if. I think it's a bad idea to >assume the worst. > >> else is welcome to try and do it for them, but if they don't engage >> everyone will choose the Asahi stuff - I would too). > >Well, it's not clear to me whether Asahi is supposed to be a Linux >distribution, in which case "choosing the Asahi stuff" means not >choosing Debian. That's not really an issue. If they've done it right and upstreamed it, then everybody wins. We all get to share what they've achieved, just like they get to share what other people have. This is the key benefit of Free Software, for me. ... >I don't see any way to avoid telling people how to boot into 1TR, run >bputil (which disables the "Trusted Computing" mode), run kmutil >(which installs a kernel other than macOS), and then boot an >environment which ultimately loads the right image of Linux. I do >think we can make the rest of the process easier than it currently is. > >So the process is: > >- grab a USB image >- flash it to a USB drive >- boot your Mac and keep holding the power button for twenty seconds >or so until "boot options" are being loaded >- click on "options" >- click (this doesn't work with the keyboard) the menu bar and select >Utilities / Terminal >- run a shell script off the USB drive >- enter passwords and username at the prompt, repeatedly > >The other problem is that I do not think that we can repartition Apple >file systems yet, which adds a "play around with the Apple >repartitioning software until you finally have a linuxable partition" >step (I did that, and it made me hate macOS)... Ugh. That process looks hateful :-( -- Steve McIntyre, Cambridge, UK.st...@einval.com There's no sensation to compare with this Suspended animation, A state of bliss
Re: Bug#976481: libatomic-queue: FTBFS on arm64: hardware.hpp:25:6: error: #warning "No hardware_pause implementation available - falling back to local volatile noop." [-Werror=cpp]
On Sat, Dec 05, 2020 at 05:11:00PM +0100, Andreas Tille wrote:
>Control: tags -1 help
>
>Hi Debian Arm team,
>
>I'm sorry, I have no idea how to fix this. :-(
>
>Any help would be welcome
Looking at a few of these, the packaging for libxenium-dev tells
lies. It claims to be Architecture: all but it looks like it will only
ever work on x86 and sparc. The packaging there needs to be fixed
(file a bug?), and if your package has to build-dep on it then you're
limited to the same architectures as well. That's absolutely fine:
just don't claim to support arches you cannot work on.
/usr/include/xenium/utils.hpp:
==
namespace xenium { namespace detail {
inline void hardware_pause() {
// TODO - add pause implementations for ARM + Power
#if defined(XENIUM_ARCH_X86)
_mm_pause();
#elif defined(XENIUM_ARCH_SPARC)
smt_pause();
#else
#warning "No hardware_pause implementation available - falling back to
local volatile noop."
// this effectively prevents the compiler from optimizing away the whole
backoff operation
volatile int x = 0;
(void)x;
#endif
}
}}
#endif
==
/usr/include/xenium/utils.hpp:
==
#if defined(__sparc__)
static inline std::uint64_t getticks(void) {
std::uint64_t ret;
__asm__("rd %%tick, %0" : "=r" (ret));
return ret;
}
#elif defined(__x86_64__)
static inline std::uint64_t getticks(void) {
std::uint32_t hi, lo;
__asm__ ("rdtsc" : "=a"(lo), "=d"(hi));
return (static_cast(hi) << 32) |
static_cast(lo);
}
#elif defined(_M_AMD64)
static inline std::uint64_t getticks(void) {
return __rdtsc();
}
#else
// TODO - add support for more compilers!
#error "Unsupported compiler"
#endif
==
--
Steve McIntyre, Cambridge, UK.st...@einval.com
"Managing a volunteer open source project is a lot like herding
kittens, except the kittens randomly appear and disappear because they
have day jobs." -- Matt Mackall
Re: Bug#976572: bio-eagle: FTBFS: MemoryUtils.hpp:34:10: fatal error: xmmintrin.h: No such file or directory
Hey Andreas, On Sat, Dec 05, 2020 at 05:07:41PM +0100, Andreas Tille wrote: >Control: tags -1 help > >Hi Lucas, > >On Sat, Dec 05, 2020 at 01:15:52PM +0100, Lucas Nussbaum wrote: >> During a rebuild of all packages in sid, your package failed to build >> on arm64 (I don't know if it also fails on amd64). > >I admit I have currently no chance to test on arm64 but the package >builds fine on amd64 since the include file is part of libgcc-dev > >Any help from the arm team is welcome xmmintrin.h is fundamentally tied to x86-only SIMD intrinsics. Either the package doesn't support non-x86, or there's a bug and it's mis-detecting which platform you're on. -- Steve McIntyre, Cambridge, UK.st...@einval.com Mature Sporty Personal More Innovation More Adult A Man in Dandism Powered Midship Specialty
Re: Linker issues for libssw on armel, mips64el and mipsel
On Wed, Aug 12, 2020 at 09:33:31AM +0200, Andreas Tille wrote: >Hi, > >while the package libssw builds nicely on most architectures on armel, >mips64el and mipsel there is a linking issue[1]: > >... >c -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2 -fdebug-prefix-map=/<>=. >-fstack-protector-strong -Wformat -Werror=format-security >-DSIMDE_ENABLE_OPENMP -fopenmp-simd -O3 -DSIMDE_ENABLE_OPENMP -fopenmp-simd >-O3 -I"/include" -I"/include/linux" -I/usr/lib/jvm/default-java/include/ >-I/usr/lib/jvm/default-java/include/linux -fPIC -shared -rdynamic -o >libsswjni.so sswjni.c ssw.c -Wl,-z,relro -Wl,-z,now >cc -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2 >-fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat >-Werror=format-security -DSIMDE_ENABLE_OPENMP -fopenmp-simd -O3 >-DSIMDE_ENABLE_OPENMP -fopenmp-simd -O3 -o ssw-align main.c kseq.h -L. -lssw >-lm -lz -Wl,-z,relro -Wl,-z,now >/usr/bin/ld: cannot find -lssw >... > >(same on some non-released architectures). > >Any idea how to fix this? Comparing the buildd logs for arm64 and armel, there are obvious differences - on armel the build doesn't even attempt to make the library libssw.a. Check the Makefiles etc. to see if it has hard-coded architecture support? -- Steve McIntyre, Cambridge, UK.st...@einval.com "The problem with defending the purity of the English language is that English is about as pure as a cribhouse whore. We don't just borrow words; on occasion, English has pursued other languages down alleyways to beat them unconscious and rifle their pockets for new vocabulary." -- James D. Nicoll
Re: Graphical installer on arm64 (netboot and cdrom)
Hey Alper, Apologies, I've been swamped with a lot of other things lately, both in Debian and in starting up with a new day job. I'll try and review your more recent changes shortly... On Wed, Jul 01, 2020 at 07:46:39PM +0300, Alper Nebi Yasak wrote: >Hi, I just wanted to remind you of some patches I sent a while back. Do you >(or anyone else) have time to comment on / review / merge them? > >On 19/05/2020 17:17, Alper Nebi Yasak wrote: >> So I tested my earlier patch, and did a bit more. I've attached three >> patches, first two for debian-installer and the third for rootskel. >> >> The first patch fixes arm64 netboot and netboot-gtk mini.iso images >> which now have 'Graphical install' GRUB entries using /gtk/initrd.gz >> files which don't exist, by making that file identical to /initrd.gz. > >Also, instead of this, would it be fine to merge netboot-gtk into netboot in >general? I think that would solve this issue better. > >> The second patch adds "console=tty0" to GRUB entries marked as >> "Graphical" in grub-gencfg. Without this, "Graphical automated install" >> runs on the serial console (since that may be the "preferred" console >> due to stdout-path or SPCR on arm64). The console=tty0 cmdline argument >> also ends up in the installed system's /etc/default/grub.cfg, which is >> correct IMO. >> >> The third patch considers tty0 a possible console even if it's not in >> /proc/consoles (the patch I sent earlier). The text-mode installer >> already launches on the display in the stdout-path case, but not on the >> SPCR case. With this it launches on the display in that case as well. >> >> I've tested on an arm64 QEMU VM. After all the patches: >> - "Install" launches on serial and display >> - "Graphical install" launches on display and serial >> - "Automated install" launches only on serial >> - "Graphical automated install" launches only on display >> >> On systems where console is set with stdout-path instead, "Graphical >> install" would launch only on display, but the others would be the same. > >The three patches are available at [1] if you haven't received them, or I can >resend them if you want. > >[1] https://lists.debian.org/debian-boot/2020/05/msg00178.html > >There's also a small change I posted for bug #961590 [2] that includes >fb-modules in the netboot pkg-list, I'd be glad if that could be merged as >well. > >[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=961590#30 > -- Steve McIntyre, Cambridge, UK.st...@einval.com Mature Sporty Personal More Innovation More Adult A Man in Dandism Powered Midship Specialty
Re: Bug#956418: src:glibc: Please provide optimized builds for ARMv8.1
Hey Aurelien,
On Sun, May 03, 2020 at 11:53:35PM +0200, Aurelien Jarno wrote:
>
>One solution for this would be to ship the optimized library in the same
>package as the default library. Now this is not acceptable for embedded
>systems as they might not need that library and can't remove it. This is
>even more problematic if we need to add more optimized libraries. I guess
>this might be the case for arm64 as there are many new extensions in the
>pipe.
ACK. It's a problem to ship the different things in separate
packages. If it's really a problem for smaller systems to have all the
variants because of size, is there maybe another way to do things? How
about keeping the existing libc and have an extra package
("libc-optimised") with all the optimised versions *and* the basic
version, and have it provide/replace/conflict libc6?
(/me prepares to be ambarrassed as you point out the obvious flaw I'm
missing...)
--
Steve McIntyre, Cambridge, UK.st...@einval.com
"... the premise [is] that privacy is about hiding a wrong. It's not.
Privacy is an inherent human right, and a requirement for maintaining
the human condition with dignity and respect."
-- Bruce Schneier
Re: Graphical installer on arm64 (netboot and cdrom)
On Mon, Apr 27, 2020 at 06:41:36PM +0300, Alper Nebi Yasak wrote: >On 21/04/2020 14:14, Alper Nebi Yasak wrote: >> Since you've already pushed to master, I'll try to do a full >> installation once daily cdroms are available. > >I've tested with today's (2020-04-27) weekly-built >debian-testing-arm64-xfce-CD-1.iso on my chromebook. Overall rushing through >the graphical installation went just fine. Just some minor hardware-specific >problems, and I had to handle chromeos bootloader stuff manually, but nothing >wrong with the graphical parts from what I can tell. \o/ -- Steve McIntyre, Cambridge, UK.st...@einval.com "Because heaters aren't purple!" -- Catherine Pitt
Re: Bug#956418: src:glibc: Please provide optimized builds for ARMv8.1
On Wed, Apr 22, 2020 at 01:08:46PM -0400, Noah Meyerhans wrote: >On Wed, Apr 22, 2020 at 05:48:27PM +0100, Steve McIntyre wrote: >> I think the -moutline-atomics is probably good to enable by default >> once we've got it (gcc 10). that's the suggestion I've heard from gcc >> folks in Arm. > >JFTR, it's been backported to gcc 9 and is available in Debian's gcc-9 >as of 9.3.0-9. See >https://salsa.debian.org/toolchain-team/gcc/-/blob/gcc-9-debian/debian/patches/git-updates.diff Ah, cool. I knew it *was* being backported, but I wasn't aware it was already with us. Woot! -- Steve McIntyre, Cambridge, UK.st...@einval.com Getting a SCSI chain working is perfectly simple if you remember that there must be exactly three terminations: one on one end of the cable, one on the far end, and the goat, terminated over the SCSI chain with a silver-handled knife whilst burning *black* candles. --- Anthony DeBoer
Re: Bug#956418: src:glibc: Please provide optimized builds for ARMv8.1
Hi folks! I'm adding a CC to Steve Capper, a colleague in Arm who's our expert here for this kind of question. He's also a DM in Debian... :-) On Tue, Apr 21, 2020 at 06:37:07PM -0400, Noah Meyerhans wrote: >On Sun, Apr 12, 2020 at 12:18:35PM +0200, Aurelien Jarno wrote: > >> It would also be nice to have numbers to see the impact on non-ARMv8.1 >> CPU on real workloads. As pointed out by Florian, and if the impact is >> negligible, it might be a good idea to enable -moutline-atomics >> globally at the GCC level so that all software can benefit from it, and >> instead of only glibc. That could be either upstream or only in Debian, >> that's probably a separate discussion. Otherwise we will likely end up >> using this non-default GCC option on all packages that runs faster with >> it. > >Agreed. I think the -moutline-atomics is probably good to enable by default once we've got it (gcc 10). that's the suggestion I've heard from gcc folks in Arm. >> Also note that the mechanism allowing a safe upgrade *does* incur a >> runtime overhead as every binary now has to test for the presence of >> /etc/ld.so.nohwcap to detect a possible upgrade of the glibc in >> progress. That's why we have disabled it on architecture not providing >> an optimized library [1]. Oh, ick. :-/ >Thanks for the pointer, it's interesting to see data on that. This also >suggests that it might be worthwhile to investigate a better mechanism >for identifying the availability of hardware features. > >> > I've tested both options and found them to be acceptable on v8.1a (Neoverse >> > N1) and v8a (Cortex A72) CPUs. I can provide bulk test run data of the >> > various different configuration permutations if you'd like to see >> > additional >> > data. >> >> As said above I think we would need more numbers on real workload to >> take a decision. Don't get me wrong I do not oppose on improving atomics >> on ARMv8.1, but I would like that we chose the best option. Also if we >> go with the -moutline-atomics option, I believe it rather has to be a >> ARM porters decision than a glibc maintainers decision (hence the Cc:). > >I'll see what I can come up with. > >Do the arm porters have any opinions on this matter? It's a good question, and thanks for asking! I definitely think it's worth doing -moutline-atomics, and I'm hoping Steve can share some performance numbers to help convince. :-) -- Steve McIntyre, Cambridge, UK.st...@einval.com Who needs computer imagery when you've got Brian Blessed?
Re: Graphical installer on arm64 (netboot and cdrom)
On Mon, Apr 20, 2020 at 07:36:42PM +0300, Alper Nebi Yasak wrote: >On 20/04/2020 18:38, Steve McIntyre wrote: >> Does /dev/tty0 show up in /proc/consoles in your setup? We might need >> to tweak that yet... > >Here is a small but untested patch for rootskel's reopen-console for that. Hmmm. Is this the right answer, though? I've got totally headless arm64 machines that also have a /dev/tty0. Would we want to run d-i there? Maybe, I'm genuinely not sure. It might be harmless, I guess...? >(Thanks for the cd image, it'll probably take me until tomorrow to test and >report back on it) Cool. :-) -- Steve McIntyre, Cambridge, UK.st...@einval.com "... the premise [is] that privacy is about hiding a wrong. It's not. Privacy is an inherent human right, and a requirement for maintaining the human condition with dignity and respect." -- Bruce Schneier
Re: Graphical installer on arm64 (netboot and cdrom)
On Mon, Apr 20, 2020 at 03:43:57PM +0100, Steve McIntyre wrote: >On Mon, Apr 20, 2020 at 03:21:20PM +0100, Steve McIntyre wrote: >>On Mon, Apr 20, 2020 at 05:03:02PM +0300, Alper Nebi Yasak wrote: >>>On 20/04/2020 16:36, Steve McIntyre wrote: >>>> I'm just going to test again with that change included, then I can >>>> push a netinst image somewhere for you to test... >>> >>>I'd appreciate it. Here's another patch, this time for the armhf graphical >>>cdrom. I checked that it boots into a graphical installer when run in a QEMU >>>arm VM (still with 'direct kernel boot') but no further. If you can also make >>>an armhf netinst image from this I can test that too (at least in a VM, not >>>sure the configs for my chromebook were enabled on the armhf kernel..). >> >>Ah, OK. I wasn't sure if it was worth trying to add this on armhf >>too... :-) >> >>I'm just building with a different local patch to add the setting >>GRAPHICAL_INSTALLER=y in arm64.cfg and using that to add (or not) the >>graphical installer to each of the grub-gencfg calls. I'll let that >>finish first... > >Try the image at > > http://cdimage.debian.org/cdimage/unofficial/arm64-gi/ > >please? OK, so this lot seems to work in a VM at least (thanks Marcin!), so I've pushed this set of patches to master now. I'm not sure about adding the graphical installer for armhf right now, but I'm open to being convinced... Once we have a working d-i daily build I'll also push my changes for debian-cd to use it on arm64. -- Steve McIntyre, Cambridge, UK.st...@einval.com "I can't ever sleep on planes ... call it irrational if you like, but I'm afraid I'll miss my stop" -- Vivek Das Mohapatra
Re: Graphical installer on arm64 (netboot and cdrom)
On Mon, Apr 20, 2020 at 06:06:55PM +0200, Marcin Juszkiewicz wrote: >W dniu 20.04.2020 o 17:54, Steve McIntyre pisze: > >> OK. Can you edit the grub command line and add "console=tty0" before >> starting please? > >Now I have two d-i running. One on tty0, one on ttyAMA0: Yay! Progress - that's what we're aiming for. :-) You should be able to use either of them now - this is how we support multiple different hardware configurations. Can you use the one on tty0 OK? That's what I'm hoping to see here... -- Steve McIntyre, Cambridge, UK.st...@einval.com < Aardvark> I dislike C++ to start with. C++11 just seems to be handing rope-creating factories for users to hang multiple instances of themselves.
Re: Graphical installer on arm64 (netboot and cdrom)
On Mon, Apr 20, 2020 at 05:51:03PM +0200, Marcin Juszkiewicz wrote: >W dniu 20.04.2020 o 17:38, Steve McIntyre pisze: >> Hey Marcin! >> >> On Mon, Apr 20, 2020 at 05:36:30PM +0200, Marcin Juszkiewicz wrote: >>> W dniu 20.04.2020 o 16:43, Steve McIntyre pisze: >>> >>>> Try the image at >>>> >>>> http://cdimage.debian.org/cdimage/unofficial/arm64-gi/ >>> >>> Booted VM with it. Debian installer started on serial port still >>> despite selecting 'graphical install' in grub menu. >>> >>> Graphical display in meantime displayed only blinking cursor. >>> >>> Maybe it was because on aarch64 framebuffer is available after >>> 'virtio_gpu' kernel module gets loaded so d-i starts too early >>> to notice it. >> >> Does /dev/tty0 show up in /proc/consoles in your setup? We might need >> to tweak that yet... > >~ # cat /proc/consoles >ttyAMA0 -W- (EC p a) 204:64 >~ # > >Syslog: > >Apr 20 15:41:17 entropy-source: haveged not needed: rng detected >Apr 20 15:41:18 reopen-console: Looking at console ttyAMA0 from /proc/consoles >Apr 20 15:41:18 reopen-console:Adding ttyAMA0 to possible consoles list >Apr 20 15:41:18 reopen-console:ttyAMA0 is preferred >Apr 20 15:41:18 reopen-console: Adding inittab entry for ttyAMA0 >Apr 20 15:41:18 reopen-console: Restarting init to start d-i on the console(s) >we found >Apr 20 15:41:18 init: reloading /etc/inittab >Apr 20 15:41:18 init: starting pid 261, tty '/dev/tty4': '/usr/bin/tail -f >/var/log/syslog' >Apr 20 15:41:18 init: starting pid 265, tty '/dev/ttyAMA0': >'/sbin/debian-installer' >Apr 20 15:41:19 debconf: Setting debconf/language to en >Apr 20 15:41:20 main-menu[284]: INFO: Falling back to the package description >for brltty-udeb >Apr 20 15:41:20 main-menu[284]: INFO: Menu item 'localechooser' selected >Apr 20 15:41:21 debconf: Setting debconf/language to >Apr 20 15:41:23 main-menu[284]: INFO: Menu item 'localechooser' succeeded but >requested to be left unconfigured. >Apr 20 15:41:23 main-menu[284]: INFO: Falling back to the package description >for brltty-udeb >Apr 20 15:41:25 main-menu[284]: INFO: Falling back to the package description >for brltty-udeb >Apr 20 15:41:25 main-menu[284]: INFO: Menu item 'di-utils-shell' selected > >Just before d-i started on serial line there was some message >about missing framebuffer. OK. Can you edit the grub command line and add "console=tty0" before starting please? -- Steve McIntyre, Cambridge, UK.st...@einval.com Who needs computer imagery when you've got Brian Blessed?
Re: Graphical installer on arm64 (netboot and cdrom)
Hey Marcin! On Mon, Apr 20, 2020 at 05:36:30PM +0200, Marcin Juszkiewicz wrote: >W dniu 20.04.2020 o 16:43, Steve McIntyre pisze: > >> Try the image at >> >> http://cdimage.debian.org/cdimage/unofficial/arm64-gi/ > >Booted VM with it. Debian installer started on serial port still >despite selecting 'graphical install' in grub menu. > >Graphical display in meantime displayed only blinking cursor. > >Maybe it was because on aarch64 framebuffer is available after >'virtio_gpu' kernel module gets loaded so d-i starts too early >to notice it. Does /dev/tty0 show up in /proc/consoles in your setup? We might need to tweak that yet... -- Steve McIntyre, Cambridge, UK.st...@einval.com Armed with "Valor": "Centurion" represents quality of Discipline, Honor, Integrity and Loyalty. Now you don't have to be a Caesar to concord the digital world while feeling safe and proud.
Re: Graphical installer on arm64 (netboot and cdrom)
On Mon, Apr 20, 2020 at 03:21:20PM +0100, Steve McIntyre wrote: >On Mon, Apr 20, 2020 at 05:03:02PM +0300, Alper Nebi Yasak wrote: >>On 20/04/2020 16:36, Steve McIntyre wrote: >>> I'm just going to test again with that change included, then I can >>> push a netinst image somewhere for you to test... >> >>I'd appreciate it. Here's another patch, this time for the armhf graphical >>cdrom. I checked that it boots into a graphical installer when run in a QEMU >>arm VM (still with 'direct kernel boot') but no further. If you can also make >>an armhf netinst image from this I can test that too (at least in a VM, not >>sure the configs for my chromebook were enabled on the armhf kernel..). > >Ah, OK. I wasn't sure if it was worth trying to add this on armhf >too... :-) > >I'm just building with a different local patch to add the setting >GRAPHICAL_INSTALLER=y in arm64.cfg and using that to add (or not) the >graphical installer to each of the grub-gencfg calls. I'll let that >finish first... Try the image at http://cdimage.debian.org/cdimage/unofficial/arm64-gi/ please? -- Steve McIntyre, Cambridge, UK.st...@einval.com "Because heaters aren't purple!" -- Catherine Pitt
Re: Graphical installer on arm64 (netboot and cdrom)
On Mon, Apr 20, 2020 at 05:03:02PM +0300, Alper Nebi Yasak wrote: >On 20/04/2020 16:36, Steve McIntyre wrote: >> I'm just going to test again with that change included, then I can >> push a netinst image somewhere for you to test... > >I'd appreciate it. Here's another patch, this time for the armhf graphical >cdrom. I checked that it boots into a graphical installer when run in a QEMU >arm VM (still with 'direct kernel boot') but no further. If you can also make >an armhf netinst image from this I can test that too (at least in a VM, not >sure the configs for my chromebook were enabled on the armhf kernel..). Ah, OK. I wasn't sure if it was worth trying to add this on armhf too... :-) I'm just building with a different local patch to add the setting GRAPHICAL_INSTALLER=y in arm64.cfg and using that to add (or not) the graphical installer to each of the grub-gencfg calls. I'll let that finish first... -- Steve McIntyre, Cambridge, UK.st...@einval.com "We're the technical experts. We were hired so that management could ignore our recommendations and tell us how to do our jobs." -- Mike Andrews
Re: Graphical installer on arm64 (netboot and cdrom)
On Sun, Apr 19, 2020 at 10:23:06PM +0300, Alper Nebi Yasak wrote:
>On 16/04/2020 15:40, Steve McIntyre wrote:
>> On Tue, Apr 14, 2020 at 05:43:36PM +0100, Steve McIntyre wrote:
>> >
>> > ACK.
>> >
>> > Building locally to test here...
>>
>> And I have a build that looks OK by eye. Unfortunately, my local test
>> machine (Macchiatobin) seems to be dying and I can't test this
>> effectively now. :-(
>
>Ah, OK. Thanks for spending time on this.
>
>> It needs some tiny debian-cd changes and then we'll get
>> netinst, DVD images etc. also including the graphical installer. Final
>> thing missing - the grub.cfg that's generated for the CD/DVD/USB boot
>> doesn't include menu entries for graphical boot.
>Adding INITRD_GTK to build/config/arm.cfg as in:
>
>diff --git a/build/config/arm.cfg b/build/config/arm.cfg
>index fe8cf80f9..898795658 100644
>--- a/build/config/arm.cfg
>+++ b/build/config/arm.cfg
>@@ -23,6 +23,7 @@ arch_cd_info_dir: arm_grub_efi
> grub-gencfg \
> KERNEL /%install%/vmlinuz \
> INITRD /%install%/initrd.gz \
>+ INITRD_GTK /%install%/gtk/initrd.gz \
> HEADER boot/$(ARCH)/grub/grub-efi.cfg \
> > $(TEMP_CD_INFO_DIR)/grub/grub.cfg; \
> cp -a $(GRUB_FONT) $(TEMP_CD_INFO_DIR)/grub/font.pf2; \
>
>seems to be enough for the last part, I'm getting "Graphical install" and
>others in both cdrom{,/gtk}/debian-cd_info.tar.gz files' grub.cfg files.
>
>I expect that change will make the "Graphical" entries appear also on armhf
>where there isn't a cdrom/gtk build yet, so I'll also have a look at that.
>
>Hopefully I can learn enough debian-cd to build and test with proper images
>this time around :)
I'm just going to test again with that change included, then I can
push a netinst image somewhere for you to test...
--
Steve McIntyre, Cambridge, UK.st...@einval.com
"When C++ is your hammer, everything looks like a thumb." -- Steven M. Haflich
Re: Graphical installer on arm64 (netboot and cdrom)
On Tue, Apr 14, 2020 at 05:43:36PM +0100, Steve McIntyre wrote: > >ACK. > >Building locally to test here... And I have a build that looks OK by eye. Unfortunately, my local test machine (Macchiatobin) seems to be dying and I can't test this effectively now. :-( It needs some tiny debian-cd changes and then we'll get netinst, DVD images etc. also including the graphical installer. Final thing missing - the grub.cfg that's generated for the CD/DVD/USB boot doesn't include menu entries for graphical boot. -- Steve McIntyre, Cambridge, UK.st...@einval.com < liw> everything I know about UK hotels I learned from "Fawlty Towers"
Re: Graphical installer on arm64 (netboot and cdrom)
On Mon, Apr 06, 2020 at 10:11:12PM +0300, Alper Nebi Yasak wrote: >On 06/04/2020 17:48, Steve McIntyre wrote: >> > Alper Nebi Yasak: >> > - added event-modules to arm64 netboot-gtk >> > - commented-out serial-modules from arm64 netboot >> >> So why comment out the serial modules here? Do they cause a problem? > >The "serial-modules" udeb isn't built on arm64 yet and including it here >causes an error while building the "stamps/get_udebs-netboot-stamp" target >complaining it can't find the udeb (I haven't looked into it any further). OK, fair enough. :-) >Instead, we can enable the udeb on the kernel side, but I didn't want to wait >for another kernel release before I sent these for review. > >(The "mouse-modules" udeb isn't built on arm64 either, it depends on >"event-modules" and if enabled can/should replace that here.) ACK. Building locally to test here... -- Steve McIntyre, Cambridge, UK.st...@einval.com "Yes, of course duct tape works in a near-vacuum. Duct tape works anywhere. Duct tape is magic and should be worshipped." -― Andy Weir, "The Martian"
Re: Graphical installer on arm64 (netboot and cdrom)
Hi!
Great work here! :-) More comments inline...
On Thu, Apr 02, 2020 at 07:46:01PM +0300, Alper Nebi Yasak wrote:
>I posted a while ago about graphical installer on arm64, here's an update.
>The first two patches I've attached are Wookey's patches with two module
>changes (noted in the patch message). The third one is to enable graphical
>cdrom builds, which I tested with the d-i bullseye alpha2 arm64 xfce CD-1
>image on both a QEMU virtual machine (via virt-manager) and my chromebook
>(rk3399-gru-kevin).
>
>On the VM: I've set the firmware to UEFI, mounted the iso file as a CD, and
>used my patched vmlinuz/initrd files with "Direct kernel boot". The
>installation went fine except I needed to pass "console=tty0" in the command
>line arguments, but that's not a problem in these patches (an ACPI SPCR table
>results in Linux not registering tty0 as a console).
ACK.
>On the chromebook: I've written the iso to a partition (/dev/sda1) and used
>my patched (also with chromebook stuff) vmlinuz/initrd/dtb to boot. There, I
>had to manually specify '/dev/sda1' as the cdrom device in the cdrom-detect
>step. It worked for the base-installer step, but not for the apt-setup step,
>but the installation continued anyway with a network mirror and finished with
>success. I don't know if that apt-setup problem is considered a bug, I
>probably wasn't supposed to use a partition as a cdrom.
That'll be exactly it, yes.
>I think these patches will work fine on other hardware as well (but I don't
>have anything else to test on). Thanks in advance if anyone can have a look.
...
>From 1bbfb902cb984d83b2bb1ac40524a526ee13cdcd Mon Sep 17 00:00:00 2001
>From: Wookey
>Date: Sat, 19 Jan 2019 03:13:40 +
>Subject: [PATCH 2/3] Add missing modules (usb, fat, virtio) to arm64 netboot
> build and xorg modules to netbook-gtk
>
>Alper Nebi Yasak:
>- added event-modules to arm64 netboot-gtk
>- commented-out serial-modules from arm64 netboot
So why comment out the serial modules here? Do they cause a problem?
>Signed-off-by: Alper Nebi Yasak
>---
> build/pkg-lists/netboot/arm64.cfg | 15 ++-
> build/pkg-lists/netboot/gtk/arm64.cfg | 11 +++
> 2 files changed, 25 insertions(+), 1 deletion(-)
> create mode 100644 build/pkg-lists/netboot/gtk/arm64.cfg
>
>diff --git a/build/pkg-lists/netboot/arm64.cfg
>b/build/pkg-lists/netboot/arm64.cfg
>index d5635daa9..01fe2b0a5 100644
>--- a/build/pkg-lists/netboot/arm64.cfg
>+++ b/build/pkg-lists/netboot/arm64.cfg
>@@ -11,9 +11,22 @@ nic-modules-${kernel:Version}
> nic-usb-modules-${kernel:Version}
> nic-wireless-modules-${kernel:Version}
> virtio-modules-${kernel:Version} ?
>+usb-modules-${kernel:Version}
>
> fb-modules-${kernel:Version} ?
> input-modules-${kernel:Version} ?
>
>-#for all targets
>+# In case they need to load a driver image.
>+mountmedia
>+media-retriever
>+fat-modules-${kernel:Version}
>+usb-storage-modules-${kernel:Version}
>+mmc-modules-${kernel:Version} ?
>+
>+# brltty
>+brltty-udeb
>+# serial-modules-${kernel:Version} ?
>+usb-serial-modules-${kernel:Version} ?
>+uinput-modules-${kernel:Version} ?
>
>+#for all targets
>diff --git a/build/pkg-lists/netboot/gtk/arm64.cfg
>b/build/pkg-lists/netboot/gtk/arm64.cfg
>new file mode 100644
>index 0..bda77cdab
>--- /dev/null
>+++ b/build/pkg-lists/netboot/gtk/arm64.cfg
>@@ -0,0 +1,11 @@
>+#include "gtk-linux"
>+
>+#mouse-modules-${kernel:Version}
>+event-modules-${kernel:Version}
>+xserver-xorg-input-evdev-udeb
>+xserver-xorg-video-fbdev-udeb
>+
>+#speakup-modules-${kernel:Version}
>+#sound-modules-${kernel:Version}
>+#console-setup-linux-fonts-udeb
>+#espeakup-udeb
>--
>2.26.0
>
--
Steve McIntyre, Cambridge, UK.st...@einval.com
"Further comment on how I feel about IBM will appear once I've worked out
whether they're being malicious or incompetent. Capital letters are forecast."
Matthew Garrett, http://www.livejournal.com/users/mjg59/30675.html
Re: Trying Debian/armhf rebootstrap with time64
the bootstrap using a musleabihf target instead of gnueabihf > would avoid the current issues internal to glibc-y2038, but instead > lead to new problems with packages that do not currently work with > musl. Adelie Linux has shown that it's already possible to build > a useful distro using musl and time64[8], and this would > sidestep the question of the target triplet. While it would also > help find and fix additional bugs in packages, and make an > interesting unoffical Debian target, I don't see it replacing > the existing armhf port any time soon. Ditto. Thanks for the great summary of what you've been working on! -- Steve McIntyre, Cambridge, UK.st...@einval.com "When C++ is your hammer, everything looks like a thumb." -- Steven M. Haflich
Re: Y2038 - best way forward in Debian?
On Tue, Feb 11, 2020 at 12:01:28PM +0100, Marco d'Itri wrote: >On Feb 11, Arnd Bergmann wrote: > >> I agree that changing the i386 port is probably a bad idea at the moment, >> let's see how the armhf port turns out and fix all the bugs first, as this >> is clearly needed anyway. Once there is a working armhf version with >> full time64 user space, there can be a separate discussion about what >> to do with the i386 port (phase out i386 before y2038, migrate all of >> i386 to time64 quickly, have two separate i386 ports, or something >> else). >I have still not seen any explanation about why we expect that 32 bit >ARM systems will still be popular (as non-embedded) ~15 years from now. That's a fair question to ask! We're already seeing quite a number of people embedding small-ish ARMv7 boards in infrastructure, and AIUI a lot of them are using Debian as a base already - see the Civil Infrastructure Platform as an example: https://www.cip-project.org/ As these people are already engaging in ELTS work, I don't expect that this setup is going to go away any time soon. -- Steve McIntyre, Cambridge, UK.st...@einval.com You raise the blade, you make the change... You re-arrange me 'til I'm sane...
Y2038 - best way forward in Debian?
Hey folks, Apologies - I should have sent this mail quite a while back. :-/ Arnd Bergmann (in CC) has been helping to drive a lot of work to solve the 2038 problem in the Linux world. I've spoken about this before, e.g. at DebConf17. He's been pushing a lot of updates throughout the Linux kernel, and has also been analysing code elsewhere. He's very interested in how to update complete systems like Debian too, and we spoke about this some time ago. The kernel is *basically* fixed now. Internally, data structures should now be safe. There are a small number places where 32-bit time is still a thing, but it's in hand. A number of syscalls, ioctls, etc. have needed updates for the user-kernel interface level. glibc is the place that needs to care about most of this. The glibc folks have taken an interesting approach. * 64-bit ABIs/architectures are already using 64-bit time_t throughout. The design is sane and so we should already be mostly safe here, modulo silly code bugs (we'll always have those!) * 32-bit ABIs/arches are more awkward. glibc will continue *by default* to use 32-bit time_t to keep compatibility with existing code. This will *not* be safe as we approach 2038. * 32-bit ABIs/arches *can* be told to use 64-bit time_t from glibc upwards, but this will of course affect the ABI. Embedded uses of time_t in libraries will change size, etc. This *will* be safe for 2038. So, we're all fine? Not so much: for our 32-bit Debian arches, we will need to basically rebuild the world to be 2038-safe. When we had to do something like this in the past, to deal with the libc5->libc6 transition, we had an SONAME change in libc to work with. We decided to append the "g" tag to the names of our library binary packages to signal that a library was built against libc6. We can still see some of the effects of this in the archive, many years later (e.g. zlib1g). The problem now is that we will *not* have an soname change here to help identify code compatibility on the 32-bit front. Arnd scanned the library packages in the Debian archive and identified that about one third of our library packages would need rebuilding (and tracking) to make a (recursive) transition. We can see two different possible routes to follow: A Follow a similar path to last time (rename library packages). This will allow us to do partial upgrades, but the cost is that a vast number of packages will need work to make this happen, *potentially* building library packages twice to allow us to continue both 32-bit and 64-bit time_t support forwards for a while. This effort will be *needed* only for the sake of our 32-bit ports, but would affect *everybody*. *** OR *** B Decide which 32-bit ports we expect to care about by 2038, and re-bootstrap new versions of those ports *with different names*. This would allow most of our developers to ignore the problem here (as 64-bit arches are not affected) and let a smaller number of people re-bootstrap with new ABIs with 64-bit time_t embedded. There are some downsides here: * we would end up with two versions of some ports for a short time - probably one release of overlap * users would *not* be able to simply upgrade from one to the other, due to lack of binary compatibility We *would* be able to run old and new ABIs on top of the same (new enough) kernel (e.g. for buildds), so a lump of this would just be simply building the new world and filing bugs where needed. We'd need to decide exactly which of our 32-bit ports we would want to do this path with (probably armhf->arhmft?, maybe armel->armelt?, i386->i386t?. mipsel???). Due to the libc6 soname continuity, we will most likely *not* end up with a different visible ABI via the triplet and the runtime linker, so old/new multi-arch will be impossible. So, which way should we go? My own personal gut feel matches Arnd's, which would be route B. Some of us already have fair experience with bootstrapping new arches, and we could almost just crank the handle for most of this work. What do people think here? Which do you think is the better path? Feel free to point out things you think I may have missed. We should get started on this soon - the longer we leave it, the more likely it is that we'll see 2038 bugs biting people. -- Steve McIntyre, Cambridge, UK.st...@einval.com "Yes, of course duct tape works in a near-vacuum. Duct tape works anywhere. Duct tape is magic and should be worshipped." -― Andy Weir, "The Martian"
Re: Build failure of janest-base on arm64...
On Tue, Jan 14, 2020 at 12:57:11PM +0200, Adrian Bunk wrote: >On Tue, Jan 14, 2020 at 10:57:29AM +0100, Stéphane Glondu wrote: >>... >> Christian Marillat says that "Binutils package is broken see #911990", >> but this bug has been marked as fixed-upstream for more than 1 year, is >> it really still on topic? > >Correct bug number would be #948803 or #948819. > >The problem seems caused by the snapshot of binutils currently >used in unstable, and it is not limited to ocaml: >https://buildd.debian.org/status/architecture.php?a=arm64=sid > >This looks like ~ 70 arm64-only Build-Attempted failures since buildd >chroots were regenerated on Sunday, in a wide variety of packages. Ah, that's useful to know. I wish I'd seen that before disappearing down a rabbit-hole yesterday! :-/ -- Steve McIntyre, Cambridge, UK.st...@einval.com Getting a SCSI chain working is perfectly simple if you remember that there must be exactly three terminations: one on one end of the cable, one on the far end, and the goat, terminated over the SCSI chain with a silver-handled knife whilst burning *black* candles. --- Anthony DeBoer
Re: Build failure of janest-base on arm64...
Hi Stéphane, On Mon, Jan 13, 2020 at 05:32:35PM +0100, Stéphane Glondu wrote: >janest-base FTBFS on arm64 (and only on this architecture) (buildd >arm-arm-04) with a SIGILL. However, I cannot reproduce on arm64 >porterbox (amdahl). I've given it back, and it still fails (on arm-ubc-02). > >Does somebody have an idea on what's going on? Hmmm. So, that's failing on two different machines, each with different hardware types: * arm-arm-04 (AMD Seattle, Cortex-A57) * arm-ubc-02 (Socionext Synquacer, Cortex-A53) but works on YA different one: * amdahl (APM X-Gene 1) I've just checked on arm-arm-04 and I don't see anything in the syslog to give clues as to what mught have failed. Checking locally on my Macchiatobin: * mjolnir (Marvell Armada 8040, Cortex-A72) it also fails, which gives me a more useful way to attack this with a debugger. (sid-arm64)steve@mjolnir:~/build/janest-base/janest-base-0.13.0/_build/default/compiler-stdlib/src$ gdb ../gen/gen.exe ... (gdb) r -ocaml-where /usr/lib/ocaml -o caml.ml Starting program: /home/steve/build/janest-base/janest-base-0.13.0/_build/default/compiler-stdlib/gen/gen.exe -ocaml-where /usr/lib/ocaml -o caml.ml Program received signal SIGILL, Illegal instruction. 0xab0647f8 in e843419@0031_0203_b74 () (gdb) bt #0 0xab0647f8 in e843419@0031_0203_b74 () #1 0xab062ff8 in camlPredef__common_initial_env_322 () at typing/predef.ml:227 #2 0xab063700 in camlPredef__build_initial_env_390 () at typing/predef.ml:239 #3 0xab07800c in camlEnv__entry () at typing/env.ml:2685 #4 0xaafb1adc in caml_program () #5 0xab21f644 in caml_start_program () #6 0xab21fec0 in caml_startup_common () #7 0xab21ff08 in caml_startup () #8 0xaafb1220 in main () (gdb) list 1 ../sysdeps/unix/sysv/linux/aarch64/dl-procinfo.c: No such file or directory. (gdb) disassemble Dump of assembler code for function e843419@0031_0203_b74: => 0xab0647f8 <+0>: .inst 0x ; undefined 0xab0647fc <+4>: b 0xab063008 End of assembler dump. I'm not sure exactly what's going on here. I know *nothing* about ocaml to know what the code in predef.ml is trying to do. Line 227 is add_type ident_exn decl_exn ( The reference to dl-procinfo.c is buried in the guts of glibc - that file defines the expected cpuinfo flags. *Guessing* - is something in ocaml trying to parse the cpuinfo flags and making a mistake? That *might* explain why you're getting different results here from one machine to the next. But that's just a guess. -- Steve McIntyre, Cambridge, UK.st...@einval.com "This dress doesn't reverse." -- Alden Spiess
Re: MP30-AR0 arm64 sdcard slot not detected
Hi Mike, On Sat, Oct 19, 2019 at 07:29:41AM +0100, Michael Howard wrote: >Posted this to wrong list initially, sorry all! > >I've just re-installed debian (stretch) on the Gigabyte MP30-AR0 board using >the installer netinst iso (any later install images fail) and the sdcard slot >is not showing up. The kernel is vmlinuz-4.9.0-11-arm64 and I have also rebuilt >it ensuring all the MMC options I should need are selected. > >I'm now suspecting a devicetree issue. Checking the output from dtc, using 'dtc >-I fs -O dts /sys/firmware/devicetree/base' there is no mention of mmc. >However, an 'mmc' entry exists in the source code file 'apm-storm.dtsi', which >is 'included' by 'apm-mustang.dts', which I'm assuming is the dts file used by >the kernel build system, I used bindeb-pkg to build the debs. > >Previously, I've manually built the image, modules and dtb (last occasion using >mainline 4.9.2) and the card slot was not a problem. > >Anybody any ideas as to what's happening? Can I ensure that 'bindeb-pkg' uses a >specific dts? If so, how? First question: how are you booting the system? U-Boot or UEFI? IME the X-Gene platform should normally use a DTB provided by firmware. There are bits of the platform that are configured by firmware at boot, so you can't reliably use a static DTB with the kernel image. -- Steve McIntyre, Cambridge, UK.st...@einval.com "The problem with defending the purity of the English language is that English is about as pure as a cribhouse whore. We don't just borrow words; on occasion, English has pursued other languages down alleyways to beat them unconscious and rifle their pockets for new vocabulary." -- James D. Nicoll
BoF at DC19
Hey folks, I've just registered a session for the usual BoF at DebConf. If you have any specific topics you'd like to raise, please let me know... -- Steve McIntyre, Cambridge, UK.st...@einval.com Mature Sporty Personal More Innovation More Adult A Man in Dandism Powered Midship Specialty
Re: Debian Installer on Pine64+ (no serial console)
On Sat, May 04, 2019 at 12:29:30PM -0700, Vagrant Cascadian wrote: >On 2019-05-04, Andrei POPESCU wrote: >> On Sb, 04 mai 19, 06:57:43, Andrei POPESCU wrote: >>> >>> I'm ready to start a second try where I will be using manual >>> partitioning (without GPT), hoping I will get a bootable system. >> >> This worked, see >> https://wiki.debian.org/InstallingDebianOn/PINE64/PINEA64 > >Thanks for the wiki page! > >It's definitely frustrating that sunxi64 installs the bootloader and >boot firmware at an offset incompatible with GPT partitioning... I've >heard there might hacks to set up a compatible GPT partition table, but >the defaults are definitely incompatible. :/ Nod. partman needs updates to make things happier here. As the moment, we're defaulting to GPT for arm64 machines and that's not ideal for all users. Andrei - how was your SD card formatted when you started? Inside d-i, partman should not be creating a new partition table if there's one already there. -- Steve McIntyre, Cambridge, UK.st...@einval.com We don't need no education. We don't need no thought control.
Re: Does ARMEL toolchain include NEON support?
On Thu, Feb 28, 2019 at 01:36:33PM -0500, Jeffrey Walton wrote:
>On Thu, Feb 28, 2019 at 1:18 PM Wookey wrote:
>>
>> On 2019-02-28 09:05 +, Ian Campbell wrote:
>> >
>> > To spell it out: the gist of this is that it isn't possible to provide
>> > a single arm binary which works well for both armel and armhf (which I
>> > think is what Jeff is trying/wants to do?).
>>
>> Just to clarify: it's not possible to built a binary which works at
>> all on both armel and armhf. They are different ABIs ('architectures'
>> in Debian terminaology). Modulo things like qemu emulation or other
>> very carefully constructed binaries a binary is one ABI or the other,
>> working together with others on that basis. There are then separate
>> questions of what base ISA (instruction set) it is built to (v5, v7),
>> and to what degree it requires/supports optional features of the
>> hardware/ABI (neon, fpu, maverick etc).
>
>Forgive my ignorance...
>
>Is it possible to support both at a project's ABI level in C/C++ by
>avoiding floats and doubles in function signatures?
Basically, no. The toolchains are set up to explicitly set flags to
state which ABI a binary is targeting. It's not possible to say
"both".
--
Steve McIntyre, Cambridge, UK.st...@einval.com
"This dress doesn't reverse." -- Alden Spiess
Re: Does ARMEL toolchain include NEON support?
On Thu, Feb 28, 2019 at 06:47:30PM +0200, Adrian Bunk wrote: >On Thu, Feb 28, 2019 at 09:05:04AM +, Ian Campbell wrote: >> >> To spell it out: the gist of this is that it isn't possible to provide >> a single arm binary which works well for both armel and armhf (which I >> think is what Jeff is trying/wants to do?). > >It is not even possible to provide a single arm binary that runs on >both armel and armhf.[1] It is a different ABI. It's *technically* possible for binaries that don't ever pass FP values as function arguments, but it's really not recommended and you'd have to fight with the toolchain a lot to do it. >> The advice here is to instead ship[0] two binaries -- one targetting v5 >> (no neon etc, aka armel in Debian) and another targetting v7 (w/ >> possible(? I forget what is optional) neon and other stuff aka armhf in >> Debian and other distros). > >The main difference between armel and armhf is not the baseline >(at some point Ubuntu had bumped the armel baseline to v7), the >main difference is that there is no FPU in the armel baseline. >Which also means that floating-point parameters must get passed >in integer registers since there are no floating-point registers >in the ABI. Nod. -- Steve McIntyre, Cambridge, UK.st...@einval.com We don't need no education. We don't need no thought control.
Re: Does ARMEL toolchain include NEON support?
On Thu, Feb 28, 2019 at 09:05:04AM +, Ian Campbell wrote: >On Wed, 2019-02-27 at 23:45 +0000, Steve McIntyre wrote: >> >> So this is a place where the world is just *different* compared to x86 >> - the different versions of the ARM architectures have signficantly >> different capabilities. If you're looking to build something that >> performs well on a modern v7 CPU, compilling for v5 is a >> mistake. You'll be using the wrong locking primitives, barriers, >> etc. Equally, the features you're going to be looking for (like SMP, >> NEON) just don't make sense / don't exist on v5 CPUs. > >To spell it out: the gist of this is that it isn't possible to provide >a single arm binary which works well for both armel and armhf (which I >think is what Jeff is trying/wants to do?). > >The advice here is to instead ship[0] two binaries -- one targetting v5 >(no neon etc, aka armel in Debian) and another targetting v7 (w/ >possible(? I forget what is optional) neon and other stuff aka armhf in >Debian and other distros). Yep. -- Steve McIntyre, Cambridge, UK.st...@einval.com "I've only once written 'SQL is my bitch' in a comment. But that code is in use on a military site..." -- Simon Booth
Re: Does ARMEL toolchain include NEON support?
On Wed, Feb 27, 2019 at 06:30:36PM -0500, Jeffrey Walton wrote: >On Wed, Feb 27, 2019 at 5:46 PM Steve McIntyre wrote: >> >> So, I've got to ask - what hardware are you likely targeting here >> where it matters to build stuff for armel yet also use NEON if it's >> available? Most people with hardware that *can* do NEON should be >> using armhf, surely? > >Yeah, I know what you are saying. > >The problem in practice with mainstream compilers is (1) ARM and the >ACLE defines are a mess, (2) -march=native does not work like on i686 >or x86_64, and (3) RTFM does not work. > >For a regular user who wants to use Debian on ARM we need to figure >out how to build to the least capable machine (like ARMv5 or ARMv6) >while making more capable features (like NEON) available. So this is a place where the world is just *different* compared to x86 - the different versions of the ARM architectures have signficantly different capabilities. If you're looking to build something that performs well on a modern v7 CPU, compilling for v5 is a mistake. You'll be using the wrong locking primitives, barriers, etc. Equally, the features you're going to be looking for (like SMP, NEON) just don't make sense / don't exist on v5 CPUs. >User's don't want to RTFM to figure out what compiler switches to use. >They just want things to work. The compilers don't make it any easier >because -march=native does not work on ARM. It's a much wider world out there. :-/ >So the use case we target is, user want the most from their hardware >without reading the manual to configure properly. That means we have >to go through extra gyrations when building. > >(I know we bring it on ourselves. We could easily say fuck it - the >user did not bother to read a man page so its the user's problem. But >I'm in the camp that common cases should just work for folks. Folks >should not need to read a manual to make the common case work). Agreed. But it might not actually be *possible* to do some of the optimisation stuff you're looking at, depending on the CPUs involved. This is basically one of the reasons we started the armhf port - it's a higher baseline that makes more sense for modern ARMv7 CPUs, while still making it possible for people to use the older ARMv5 cores out there. -- Steve McIntyre, Cambridge, UK.st...@einval.com "Yes, of course duct tape works in a near-vacuum. Duct tape works anywhere. Duct tape is magic and should be worshipped." -― Andy Weir, "The Martian"
Re: Does ARMEL toolchain include NEON support?
On Wed, Feb 27, 2019 at 04:59:50PM -0500, Jeffrey Walton wrote: >On Wed, Feb 27, 2019 at 4:01 PM Steve McIntyre wrote: >> >> OK. In your build log I can see >> >> n file included from aria_simd.cpp:19: >> /usr/lib/gcc/arm-linux-gnueabi/8/include/arm_neon.h:31:2: error: #error >> "NEON intrinsics not available with the soft-float ABI. Please use >> -mfloat-abi=softfp or -mfloat-abi=hard" >> #error "NEON intrinsics not available with the soft-float ABI. Please use >> -mfloat-abi=softfp or -mfloat-abi=hard" >> >> What errors do you get if you try -mfloat-abi=softfp (etc.)? > >I seem to recall László Böszörményi, who is our package maintainer, >ran that test for us. It also failed. I believe it was roughly the >same error for both hard and soft floats. Right, OK. gcc can be infuriating at times like this. :-) >> To be able to use NEON support you may also have to specify a CPU/FPU >> combination that includes it - the default armel setup it for ARMv5 >> which is not going to help you. > >Yeah, the problem is centered around this. When we test for NEON we >include -march=armv7-a. The GNUmakefile does this >(https://github.com/weidai11/cryptopp/blob/master/GNUmakefile): > >HOSTX := $(shell $(CXX) $(CXXFLAGS) -dumpmachine 2>/dev/null | cut -f 1 -d '-') >IS_ARM32 := $(shell echo "$(HOSTX)" | $(GREP) -i -c -E >'arm|armhf|arm7l|eabihf') >IS_NEON := $(shell $(CXX) $(CXXFLAGS) -dumpmachine 2>/dev/null | >$(GREP) -i -c -E 'armv7|armhf|arm7l|eabihf|armv8|aarch32|aarch64') > >Then, it does this: > >ifeq ($(IS_ARM32)$(IS_NEON),11) > > TPROG = TestPrograms/test_arm_neon.cxx > TOPT = -march=armv7-a -mfloat-abi=$(FP_ABI) -mfpu=neon > HAVE_OPT = $(shell $(CXX) $(TCXXFLAGS) $(ZOPT) $(TOPT) $(TPROG) -o >$(TOUT) 2>&1 | tr ' ' '\n' | wc -l) > ifeq ($(strip $(HAVE_OPT)),0) >NEON_FLAG = -march=armv7-a -mfloat-abi=$(FP_ABI) -mfpu=neon > >endif > >When we detect ARM32 and NEON is available using a test compile, then >we enable IS_NEON . I'm thinking IS_ARM32 or IS_NEON is misdetecting. >The feature test works well elsewhere, including x86, x86_64, Aarch32, >Aarch64, MIPS, MIPS64, PPC, PPC64, etc. > >The problem is, I don't know what the output of or 'g++ -dumpmachine' >or 'uname -m' are, so I am not sure if we are misdetecting IS_ARM32 or >IS_NEON . So, I've got to ask - what hardware are you likely targeting here where it matters to build stuff for armel yet also use NEON if it's available? Most people with hardware that *can* do NEON should be using armhf, surely? >I wrote to the guys who maintain the build system and asked them to >provide the explicit output of the commands with the logs. They told >me the information was there without the need for providing the output >g++ -dumpmachine' or 'uname -m'. Helpful... :-/ >(My hunch is 'g++ -dumpmachine' is returning something other than what >we expect. Maybe something like 'armel'. I won't know for certain >until I see the output of the commands, but which Debian refuses to >provide). You can work this out if you have access to a Debian porter box or similar. But, for the sake of being helpful I see the following in an armel chroot locally: (sid-armel)steve@mjolnir:~$ g++ -dumpmachine arm-linux-gnueabi But that's not very instructive. More usefully, you can see what's defined by the compiler if you do the following (LONG output!): (sid-armel)steve@mjolnir:~$ g++ -dM -E -x c++ - < /dev/null #define __DBL_MIN_EXP__ (-1021) #define __HQ_FBIT__ 15 #define __FLT32X_MAX_EXP__ 1024 #define __cpp_attributes 200809 #define __UINT_LEAST16_MAX__ 0x #define __ARM_SIZEOF_WCHAR_T 4 #define __ATOMIC_ACQUIRE 2 #define __SFRACT_IBIT__ 0 #define __FLT_MIN__ 1.1754943508222875e-38F #define __GCC_IEC_559_COMPLEX 0 #define __cpp_aggregate_nsdmi 201304 #define __UFRACT_MAX__ 0XP-16UR #define __UINT_LEAST8_TYPE__ unsigned char #define __DQ_FBIT__ 63 #define __INTMAX_C(c) c ## LL #define __ULFRACT_FBIT__ 32 #define __SACCUM_EPSILON__ 0x1P-7HK #define __CHAR_BIT__ 8 #define __USQ_IBIT__ 0 #define __UINT8_MAX__ 0xff #define __ACCUM_FBIT__ 15 #define __WINT_MAX__ 0xU #define __FLT32_MIN_EXP__ (-125) #define __cpp_static_assert 200410 #define __USFRACT_FBIT__ 8 #define __ORDER_LITTLE_ENDIAN__ 1234 #define __SIZE_MAX__ 0xU #define __ARM_ARCH_ISA_ARM 1 #define __WCHAR_MAX__ 0xU #define __LACCUM_IBIT__ 32 #define __DBL_DENORM_MIN__ double(4.9406564584124654e-324L) #define __GCC_ATOMIC_CHAR_LOCK_FREE 1 #define __GCC_IEC_559 0 #define __FLT32X_DECIMAL_DIG__ 17 #define __FLT_EVAL_METHOD__ 0 #define __unix__ 1 #define __cpp_binary_literals 201304 #define __LLACCUM_MAX__ 0X7FFFP-31LLK #define __FLT64_DECIMAL_DIG__ 17 #define __GCC_ATOMIC_CHAR32_T_LOCK_FREE 1 #d
Re: Does ARMEL toolchain include NEON support?
On Wed, Feb 27, 2019 at 02:16:46PM -0500, Jeffrey Walton wrote: >Hi Everyone, > >I'm investigating a failed build for ARMEL. I don't have access to the >build machine so I have to study the logs or ask our package >maintainer to run commands for us. > >The build log is at >https://buildd.debian.org/status/package.php?p=libcrypto%2B%2B=experimental >(package) and >https://buildd.debian.org/status/fetch.php?pkg=libcrypto%2B%2B=armel=8.1.0-1=1551251751=0 >(ARMEL). > >We have tried to use -mfpu=neon and -mfloat-abi=softfp or >-mfloat-abi=hard for the NEON specific files but both produce compile >failures. "NEON specific files" are ones with the name *_simd.cpp, >like aria_simd.cpp. > >I test the build locally with about 6 ARM dev-boards and have not >encountered the problem. However, all of the dev-board are hard float >machines. OK. In your build log I can see n file included from aria_simd.cpp:19: /usr/lib/gcc/arm-linux-gnueabi/8/include/arm_neon.h:31:2: error: #error "NEON intrinsics not available with the soft-float ABI. Please use -mfloat-abi=softfp or -mfloat-abi=hard" #error "NEON intrinsics not available with the soft-float ABI. Please use -mfloat-abi=softfp or -mfloat-abi=hard" What errors do you get if you try -mfloat-abi=softfp (etc.)? To be able to use NEON support you may also have to specify a CPU/FPU combination that includes it - the default armel setup it for ARMv5 which is not going to help you. -- Steve McIntyre, Cambridge, UK.st...@einval.com "I can't ever sleep on planes ... call it irrational if you like, but I'm afraid I'll miss my stop" -- Vivek Das Mohapatra
Re: Multiple console support in d-i
t;debian-installer-startup: (OS-independent) > 1) modifies inittab > 2) runs startup scripts > 3) HUPs init I think this makes sense to me. >This seems a bit cleaner and better-named? Also is there any point >having choose-console run $@ now there is only one thing it runs >(debian-installer-startup)? > >The fly in this pointment is that there is one script that uses the >existing /sbin/debian-installer-startup. That is >debian-installer-launcher/debian-installer.sh which runs it in a live >image chroot so moving the restart init there would be an unexpected change >of interface. The desire to leave that interface alone results in this: To the best of my knowledge, debian-installer-laucnher is currently not used on our (official) live media anyway, due to longstanding bugs that nobody ever tried to fix. I wouldn't let that block you here. >choose-consoles: (OS-specific) > 1) parses consoles, saves in /var/run files > 2) modifies inittab > 3) runs debian-installer-startup > 4) HUPs init > >debian-installer-startup: (OS-independent) > 1) runs startup scripts > >Which is essentially the existing patch, but renaming reopen-console -> >choose-consoles OK. Again, I think this also looks sane. >currently we have: >::sysinit:/sbin/reopen-console /sbin/debian-installer-startup > >but I suggest we just change it to: >::sysinit:/sbin/choose-consoles >and choose consoles can explicitly run /sbin/debian-installer-startup > >This just makes it a bit more obvious how things work/fit together. > >Have I missed anything? > >Does anyone care about all this? Shall I just stop now (it's working >fine) or tidy a bit more to make the names clearer and reduce the >cruft further? As I said, I'm happy to test a clean rolled-up set of patches, one per d-i "package". If that works and looks OK, I say "go for it" but we need to be it ASAP. -- Steve McIntyre, Cambridge, UK.st...@einval.com "Arguing that you don't care about the right to privacy because you have nothing to hide is no different than saying you don't care about free speech because you have nothing to say." -- Edward Snowden
Re: After update to latest Stretch--boot stops
On Tue, Feb 19, 2019 at 02:52:39PM -0600, Nate Bargmann wrote: >I've been running Stretch on my Olimes A20-Olinuxino Micro for several >months without issue until just a while ago. I performed an update >through Aptitude whereupon the latest version of systemd and kernel were >updated. After a proper shutdown and restart the boot process stalls >at the point where "Starting kernel ..." is displayed. > >I allowed it to sit for several minutes wondering if an fsck was in >progress, but nothing appears to be happening (there are no drive LEDs, >so I don't have a means to know drive activity). > >At the moment I am stuck as I'm unsure of how to proceed to figure out >what broke. I have snapped a photo of the screen I can share if need >be. Hi Nate, Looks like you've been hit by Bug #922478 [1]. There was an unfortunate bug included in the armhf kernel for this update. A fixed kernel is on its way very soon, but for now you can manually download and install a locally-built package from Julien at https://people.debian.org/~jcristau/linux-922478/ [1] https://bugs.debian.org/922748 -- Steve McIntyre, Cambridge, UK.st...@einval.com Is there anybody out there?
Re: Multiple console support in d-i
On Sat, Jan 19, 2019 at 01:16:43PM +, Ian Campbell wrote:
>On Sat, 2019-01-19 at 11:08 +0000, Steve McIntyre wrote:
>> >So far I have done a proof-of-concept hack and demonstrated that
>> >running two instances does in fact work nicely without anything
>> >obvious breaking. The console selection still needs some work/checking
>> >(I've run out of time for that tonight, but it can easily be fished
>> >out of the kernel command line args. (or we could get fancier).
>>
>> Nod. Potentially we might end up of running on multiple
>> consoles.
>
>IIRC (and it hasn't changed in the years since I knew this stuff) we
>already have this on some of the netconsole install images for
>arm{el,hf}, you end up with an installer on serial and one on the ssh
>connection. Not an identical situation since I think the second one is
>only spawned when you login via ssh, but some sort of precedence I
>guess!
Yup, the netconsole case was exactly my inspiration for going down
this route. :-)
--
Steve McIntyre, Cambridge, UK.st...@einval.com
You lock the door
And throw away the key
There's someone in my head but it's not me
Re: Multiple console support in d-i
On Sun, Jan 20, 2019 at 03:02:33AM +, Ben Hutchings wrote: >On Sun, 2019-01-20 at 01:21 +, Wookey wrote: ... >> My current code leaves all this alone and just records/uses all >> enabled consoles on the command line, not just the last one, but >> ideally we'd autodetect and/or hardcode all the sensible available >> consoles and run on them. >> >> If 'read /proc/consoles (and check the devices exist)' does this, then >> that sounds very sensible. > >Reading /proc/consoles is exactly what you should do. Aha, thanks! I genuinely wasn't aware of /proc/consoles, and it does sound like exactly the right thing to be looking at. :-) -- Steve McIntyre, Cambridge, UK.st...@einval.com Into the distance, a ribbon of black Stretched to the point of no turning back
Re: arm64 graphical installer
[ Adding CC to debian-arm for interest ]
On Sat, Jan 19, 2019 at 03:39:44AM +, Wookey wrote:
>I've done some work on getting the graphical installer going on arm64.
\o/
>It's not quite finished, but Steve suggested I publish where I'm at so
>I can get some help with the right set of module packages, and we can
>start fixing up missing bits.
>
>The first patch (enable-arm64-netboot-gtk.patch) enables the
>support. This allows X to start on the display (if the correct console
>is found/specified - see next mail). This looks lovely, but there is
>no input working, because there are no no x input drivers installed,
>nor modules for USB devices (keyboard and mouse are USB).
>
>The second patch (add-missing-arm64-netboot-modules.patch) endeavours
>to fix that, by putting arm64 on the same basis as amd64 in terms of
>modules loaded. However not all module packages are built for arm64
>so I had to remove some to get a working build.
>
>Missing modules (not built on arm64) are:
>mouse-modules
>speakup-modules
>acpi-modules
>sound-modules
>
>we should fix that too.
>
>I was not able to demonstrate that the resulting build works fully,
>because when it tries to boot the kernel I get "Error: Invalid Magic
>number..., you need to load the kernel first". No idea why that's
>changed due to adding more module packages? Clues welcome.
>
>This all sounds more broken than it is: the difficult bit of the
>graphics works fine, we just need to make sure the right modules for X
>input are available too.
Nod. I'm thinking that arm64 is likely to look very similar to amd64
in terms of the desired module sets, module obviously-missing things
like pcmcia. :-)
Also: you've added these to a netboot gtk image. We'll want to add the
equivalent graphically-minded changes for the cdrom target too so we
can make working physical media.
>From b8d5ea7d37670c6c5f9cc251e1cfc5f007388eb6 Mon Sep 17 00:00:00 2001
>From: Wookey
>Date: Tue, 8 Jan 2019 18:14:22 +
>Subject: Add support for graphical installer to arm64
>
>
>diff --git a/build/config/arm64.cfg b/build/config/arm64.cfg
>index d9e782d..f320324 100644
>--- a/build/config/arm64.cfg
>+++ b/build/config/arm64.cfg
>@@ -1,4 +1,4 @@
>-MEDIUM_SUPPORTED = cdrom netboot device-tree u-boot
>+MEDIUM_SUPPORTED = cdrom netboot netboot-gtk device-tree u-boot
>
> KERNELMAJOR = 2.6
> # The version of the kernel to use.
>diff --git a/build/config/arm64/netboot-gtk.cfg
>b/build/config/arm64/netboot-gtk.cfg
>new file mode 100644
>index 000..0f1d246
>--- /dev/null
>+++ b/build/config/arm64/netboot-gtk.cfg
>@@ -0,0 +1,24 @@
>+MEDIA_TYPE = netboot image
>+
>+NETBOOT_DIR_TARGETS = $(TEMP_INITRD) $(TEMP_KERNEL)
>+
>+TYPE = netboot/gtk
>+
>+TARGET = $(NETBOOT_DIR) $(NETBOOT_TAR) $(MINIISO)
>+EXTRANAME = netboot/gtk/
>+
>+BOOT_SCREEN_DIR = $(NETBOOT_PATH)/boot-screens/
>+
>+MANIFEST-NETBOOT_DIR = "PXE boot directory for tftp server (graphical
>installer)"
>+MANIFEST-NETBOOT_TAR = "tarball of PXE boot directory (graphical installer)"
>+MANIFEST-MINIISO = "not so tiny CD image that boots the graphical netboot
>installer"
>+
>+IS_PURE_GTK = 1
>+
>+KEEP_GI_LANGS = 1
>+
>+VIDEO_MODE=$(VIDEO_MODE_GTK)
>+
>+# All images that include cdebconf should include symbols needed by these
>+# plugins.
>+EXTRAUDEBS += cdebconf-gtk-entropy
>From b0bc63a3baeb1e46c469d75ff7d68929be267949 Mon Sep 17 00:00:00 2001
>From: Wookey
>Date: Sat, 19 Jan 2019 03:13:40 +
>Subject: Add missing modules (usb, fat, virtio) to arm64 netboot build and
> xorg modules to netbook-gtk
>
>
>diff --git a/build/pkg-lists/netboot/arm64.cfg
>b/build/pkg-lists/netboot/arm64.cfg
>index e07dff0..18ca630 100644
>--- a/build/pkg-lists/netboot/arm64.cfg
>+++ b/build/pkg-lists/netboot/arm64.cfg
>@@ -11,9 +11,22 @@ nic-modules-${kernel:Version}
> nic-usb-modules-${kernel:Version}
> nic-wireless-modules-${kernel:Version}
> virtio-modules-${kernel:Version}
>+usb-modules-${kernel:Version}
>
> fb-modules-${kernel:Version} ?
> input-modules-${kernel:Version} ?
>
>-#for all targets
>+# In case they need to load a driver image.
>+mountmedia
>+media-retriever
>+fat-modules-${kernel:Version}
>+usb-storage-modules-${kernel:Version}
>+mmc-modules-${kernel:Version} ?
>+
>+# brltty
>+brltty-udeb
>+serial-modules-${kernel:Version} ?
>+usb-serial-modules-${kernel:Version} ?
>+uinput-modules-${kernel:Version} ?
>
>+#for all targets
>diff --git a/build/pkg-lists/netboot/gtk/arm64.cfg
>b/build/pkg-lists/netboot/gtk/arm64.cfg
>new file mode 100644
>index 000..2d8530a
>--- /dev/null
>+++ b/build/pkg-lists/netboot/gtk/arm64.cfg
>
Re: Rebuilding the entire Debian archive twice on arm64 hardware for fun and proft
On Mon, Jan 07, 2019 at 09:54:32AM +, Edmund Grimley Evans wrote: >The Haskell CP15 failures might be this: > >https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=864847 > >Since it is claimed there that the CP15 instructions come from LLVM, >the Mono failures might have a very similar cause and solution. ACK, good call and thanks for the link! That looks like exactly the problem, still. 18 months later with no response from the maintainers. :-( -- Steve McIntyre, Cambridge, UK.st...@einval.com "I used to be the first kid on the block wanting a cranial implant, now I want to be the first with a cranial firewall. " -- Charlie Stross
Re: Rebuilding the entire Debian archive twice on arm64 hardware for fun and proft
On Mon, Jan 07, 2019 at 12:07:49AM +, peter green wrote: >On 06/01/19 23:45, Steve McIntyre wrote: >> In my initial testing for rebuilding armhf only, I did not enable >> either of these. I was then finding *lots* of "Illegal Instruction" >> crashes due to CP15 barrier usage in armhf Haskell and Mono >> programs. This suggests that the baseline architecture in these >> toolchains is incorrectly set to target ARMv6 rather than >> ARMv7. That should be fixed and all those packages rebuilt at some >> point. > >Haskell does appear to be configured for armv7 in Debian (in the >sense that I had to patch the package in Raspbian to make it build >for armv6). I would guess for haskell that this is an issue that >needs digging into the upstream source, not just looking at the build >system. OK, fair enough. Something inside is using CP15 barriers for v7, then, which is just Wrong. :-) -- Steve McIntyre, Cambridge, UK.st...@einval.com < Aardvark> I dislike C++ to start with. C++11 just seems to be handing rope-creating factories for users to hang multiple instances of themselves.
Rebuilding the entire Debian archive twice on arm64 hardware for fun and proft
rohne for his script to pull down a summary of FTBFS bugs from UDD - that saved many hours of effort! Please let me know if you think you've found a problem in what I've done, or how I've analysed the results here. I still have my machines set up for easy rebuilds, so reproducing things and testing fixes is quite easy - just ask! -- Steve McIntyre, Cambridge, UK.st...@einval.com Armed with "Valor": "Centurion" represents quality of Discipline, Honor, Integrity and Loyalty. Now you don't have to be a Caesar to concord the digital world while feeling safe and proud. signature.asc Description: PGP signature
Re: coturn - bus error on armhf
On Sat, Dec 22, 2018 at 12:33:52PM +0100, wf...@niif.hu wrote: >Dear ARM porters, > >I sponsored the 4.5.0.8-1 upload of the coturn package. It's unit test >failed with bus error on armhf and sparc64: >https://buildd.debian.org/status/package.php?p=coturn >The former being a release architecture, I started investigation with >that, but I failed to reproduce this on abel.debian.org or >harris.debian.org: the package built and the unit test ran fine on >both. Could you please advise how to proceed with this problem? The >maintainer already requested a giveback, but it hasn't happened yet. That buildd (arm-arm-01) is an arm64 (ARMv8) machine configured to build armhf too. Unlike the older AMRv7 systems we'v been using to build armhf thus far, the kernel will not fix up user-space alignment bugs. I filed a bug about this exact issue in coturn a couple of days ago. See https://bugs.debian.org/916919 -- Steve McIntyre, Cambridge, UK.st...@einval.com You lock the door And throw away the key There's someone in my head but it's not me
Re: Upcoming Qt switch to OpenGL ES on arm64
On Sat, Nov 24, 2018 at 10:10:04AM -0500, Gene Heskett wrote: > >And the OpenGL driver is of zero use to me until a preemp-rt, or full >RTAI kernel accompanies it. Once that becomes available, and more pi's >are in the supply line, you will see an explosion of pi's running cnc >machinery. Why? Because we also have an SPI driver as part of LinuxCNC >that actually works, at mind boggling data rates. Sorry Gene, but that's utterly irrelevant to this discussion. We know you're interested in LinuxCNC, but not everybody is... -- Steve McIntyre, Cambridge, UK.st...@einval.com Into the distance, a ribbon of black Stretched to the point of no turning back
Re: Upcoming Qt switch to OpenGL ES on arm64
On Fri, Nov 23, 2018 at 03:27:57AM +0300, Dmitry Eremin-Solenikov wrote: >Hello, >пт, 23 нояб. 2018 г. в 03:18, Lisandro Damián Nicanor Pérez Meyer >: >> >> Hi! Please let me reply first to your last part: >> >> > Is there any possible way to support *BOTH* OpenGL / OpenGLES? Mutually >> > exclusive from an install POV, but give the end user the choice which to >> > install? Why should we have one Architecture forced down a path >> > different to another architecture? >> >> No, I'm afraid there is no way to do that. We did consider it many times, but >> is definitely too much work to hack on. >> >> So we need to force an architecture (actually, all of them!) to either one or >> the other. > >Can you build two packages and allow user to select, which one he wants to >install? Or those packages will be binary incompatible? That's a good question, yes. It'w ahst I was wondering too. ... >> So far I personally know 0 people with an arm64 board with PCI slots, while I >> know many with arm64 boards with hardware GLES support. > >I'm working with big arm64 iron, so for me a server arm64 board with PCIe slots >(and thus PCIe graphic cards) and on-board Aspeed "VGA card" is more common >compared to GLES-enabled arm64 SoC. Yeah - it depends exactly on your background. There's a small (but growing) set of arm64 desktop users, and it would be unfortunate to cut them off. -- Steve McIntyre, Cambridge, UK.st...@einval.com "... the premise [is] that privacy is about hiding a wrong. It's not. Privacy is an inherent human right, and a requirement for maintaining the human condition with dignity and respect." -- Bruce Schneier
Re: Summary of the Arm ports BoF at DC18
>On 20-09-18 10:24, Steve McIntyre wrote: >> * I'm expecting to pick up several Synquacer machines (24-core Cortex >>A53) to use for Debian, donated by Linaro. Some will become >>buildds, wanting to get more to use for autopkgtest, debian-ci, >>reproducible builds etc. [UPDATE: 3 of these are now in Vancouver, >>ready to set up as buildds] On Thu, Sep 20, 2018 at 09:49:45PM +0200, Paul Gevers wrote: > >Cool, very cool. Regarding autopkgtest/ci, do you already have any >(rudimentary) plans how you want to handle this? E.g. should DSA manage >these machines and does the infra gets access? Are there other >possibilities to host these machines? On Thu, Sep 20, 2018 at 10:05:18AM +, Holger Levsen wrote: > >did you discuss getting some of this synquacer machines to vagrant for >reproducible builds testing? Reponding to both of you... I now have 3 more basic Synquacer machines in my posession, ready to order new cases, RAM, etc. (They ship in desktop cases with a single 1TB hard drive and 4 GiB of RAM.) Again, I'm hoping to pick more up in the future, but supply is still limited. Again, I'll reiterate - these machines are *not* fast for single-threaded workloads but they have a lot of cores so it's perfecty reasonable to run lots of things in parallel. For my own build testing, I've been running up to 6 sbuilds in parallel for better throughput while lots of our builds don't parallelise individually. They should also work well for multiple VMs running in parallel. So, practical questions... Hardware setup: I've configured the earlier 3 as buildds in little 1U cases with 32GiB RAM and mirrored SSDs, but for $reasons they're not yet installed and running. I'm assuming that a similar spec would be wanted for autopkgtest/ci and reproducible builds? If so, we'll need to ask for approval for funds for that - it cost ~£750 per machine to do it. I had offers of funds at DC18 which I'm about to chase to help. Hosting: Talking to DSA, it seems they're not too keen on hosting / managing new machines for these projects. What are current hosting arrangements for you folks? -- Steve McIntyre, Cambridge, UK.st...@einval.com Who needs computer imagery when you've got Brian Blessed?
Re: icinga2 in stretch-backports: build failures on arm{el,hf}
Hey Chris, On Thu, Oct 11, 2018 at 05:33:21PM +0100, Chris Boot wrote: >Hi ARM porter folks, > >A few days I uploaded an icinga2 backport, and this has failed to build >on the 32-bit ARM architectures; it fails to run its test suite. >Unfortunately it's all C++ and Boost, and that's not something I'm >familiar with at all. > >The normal stretch version seems to build fine, and it builds fine in >unstable, just my no-change backport (which will be using older Boost >and compiler versions, naturally). > >The logs are: > >https://buildd.debian.org/status/fetch.php?pkg=icinga2=armel=2.9.2-1~bpo9%2B1=1539099705=0 ... 20/90 Test #19: base-base_dictionary/remove .***Failed0.08 sec Running 1 test case... unknown location(0): fatal error: in "base_dictionary/remove": memory access violation at address: 0x26f8: no mapping at fault address /<>/test/base-dictionary.cpp(128): last checkpoint Memory corruption? It's trying to dereference something at an invalid address. >https://buildd.debian.org/status/fetch.php?pkg=icinga2=armhf=2.9.2-1~bpo9%2B1=1539104021=0 And a whole load more invalid addresses, NULL pointers this time from the debug messages: ... 1/90 Test #3: base-base_array/resize ..***Failed0.35 sec Test setup error: memory access violation at address: 0x: no mapping at fault address Start 5: base-base_array/remove 2/90 Test #2: base-base_array/getset ..***Failed0.36 sec Test setup error: memory access violation at address: 0x: no mapping at fault address 3/90 Test #5: base-base_array/remove ..***Failed0.05 sec Test setup error: memory access violation at address: 0x: no mapping at fault address 4/90 Test #1: base-base_array/construct ...***Failed0.42 sec Test setup error: memory access violation at address: 0x: no mapping at fault address 5/90 Test #4: base-base_array/insert ..***Failed0.39 sec Test setup error: memory access violation at address: 0x: no mapping at fault address ... I'd start by digging into the code in "base" to see what it's doing with memory. Yet I can see that other builds are fine (e.g. 2.9.2-1 in unstable). An optimisation problem maybe? -- Steve McIntyre, Cambridge, UK.st...@einval.com Armed with "Valor": "Centurion" represents quality of Discipline, Honor, Integrity and Loyalty. Now you don't have to be a Caesar to concord the digital world while feeling safe and proud.
Re: Package guile-2.2 is not building on armel (Not-For-Us)... Why?
On Sun, Oct 07, 2018 at 02:17:35PM -0500, Rob Browning wrote: >Paul Wise writes: > >> There are some new arm64 buildds coming online soonish that are likely >> to be used for armhf/armel too and so this restriction may be lifted >> at some point. Until then, it might be a good idea to remove all the >> guile binary packages from armel as well as all packages that depend >> on them. > >Do we have any guesses about when soonish might be? I ask because I >know the freeze is approaching, and I'd *really* like for us to avoid >carrying guile-2.0 throughout buster if we can. Right now I'm finishing up analysis from doing full rebuilds of the archive for both armhf and armel on arm64 hosts. More news shortly... -- Steve McIntyre, Cambridge, UK.st...@einval.com "Arguing that you don't care about the right to privacy because you have nothing to hide is no different than saying you don't care about free speech because you have nothing to say." -- Edward Snowden
Re: Summary of the Arm ports BoF at DC18
On Thu, Sep 20, 2018 at 09:49:45PM +0200, Paul Gevers wrote: >Hi Steve, > >On 20-09-18 10:24, Steve McIntyre wrote: >> * I'm expecting to pick up several Synquacer machines (24-core Cortex >>A53) to use for Debian, donated by Linaro. Some will become >>buildds, wanting to get more to use for autopkgtest, debian-ci, >>reproducible builds etc. [UPDATE: 3 of these are now in Vancouver, >>ready to set up as buildds] > >Cool, very cool. Regarding autopkgtest/ci, do you already have any >(rudimentary) plans how you want to handle this? E.g. should DSA manage >these machines and does the infra gets access? Are there other >possibilities to host these machines? That's q good question. :-) Right now I only have the first 3 machines, and I'm waiting for another batch to get more. As soon as we see some more, let's see what we can work out. I don't know if the DSA folks are interested in hosting these, but I'm sure we can find a solution either way. -- Steve McIntyre, Cambridge, UK.st...@einval.com "Because heaters aren't purple!" -- Catherine Pitt
Summary of the Arm ports BoF at DC18
ment fixups on the armhf buildds? Probably, to get consistent behaviour. Even better, turn on reporting of alignment fixups so we can find and file bugs. We should also do this for autopkgtest to find more alignment faults at runtime. * I'm expecting to pick up several Synquacer machines (24-core Cortex A53) to use for Debian, donated by Linaro. Some will become buildds, wanting to get more to use for autopkgtest, debian-ci, reproducible builds etc. [UPDATE: 3 of these are now in Vancouver, ready to set up as buildds] * When will people be able to get hold of arm64 server machines readily? It's a depressing story - lots of vendors in theory, but not much commercial success so far :-( * We've had arm64 openstack images for a while now. * Lots of the large cloud-based services (e.g. Travis) are starting to support arm64 too. It's an ongoing process. * Vagrant has been experimenting with newer U-Boot versions which include the new UEFI support. Should make installation easier on some arm64 and armhf devices, for example. Possible issues with devicetree here - discussion about problems with the devicetree moving target, and hence the move to ACPI for some devices like arm64 servers. Standards like SBBR and EBBR are meant to help here, defining lowest common standards for how systems should work. * Is armel going to continue? Are the buildd support issues the only blocking problems? Basically... Clarifying - the new arm64 builders for armhf *should* also work for armel too. Wait for rebuild results to see how that works, I'd expect it to be OK. We apparently have offers of donations to help keep armel alive. Let's see! [1] http://meetings-archive.debian.net/pub/debian-meetings/2018/DebConf18/2018-08-04/arm-ports-bof.webm [2] https://www.einval.com/~steve/talks/Debconf18-arm-BoF/ [3] https://lists.debian.org/debian-arm/2018/06/msg00062.html -- Steve McIntyre, Cambridge, UK.st...@einval.com "When C++ is your hammer, everything looks like a thumb." -- Steven M. Haflich signature.asc Description: PGP signature
Re: armel/armhf arch qualification for buster: call for DSA, Security, toolchain concernsj
[ Dropped cc to debian-ports etc., switched to debian-arm instead ] On Mon, Jul 23, 2018 at 04:11:06PM +0200, John Paul Adrian Glaubitz wrote: >Hi Roger! > >On 07/23/2018 10:42 AM, Roger Shimizu wrote: >> I talked to a few people about keeping armel in buster, during 1st and >> 2nd day in debcamp. >> Seems the blocker is just the buildd server hardware, and memory size it has. > >According to my colleague Alex Graf at SUSE, you can definitely build >ARMv7 on arm64 using chroots. The only problem with chroots is that >"uname -a" shows "armv8" which some userspace applications are stumbling >over. And a few other problems - see my mail in the other sub-thread. >openSUSE/SLE builds armv7 packages in OBS/IBS using a fully emulated system >using KVM. Nod. >As for the hardware, you should watch out for hardware with ARM Cortex Cores. >Alternatively, X-Gene 1. ThunderX, ThunderX2 and Centriq are definitely not >supported. Agreed on the others, but X-Gene 1 works just fine for A32. Not sure about later cores... -- Steve McIntyre, Cambridge, UK.st...@einval.com Dance like no one's watching. Encrypt like everyone is. - @torproject
Re: Building armel on arm64
On Tue, Jul 24, 2018 at 11:22:36AM +0300, Adrian Bunk wrote: >On Tue, Jul 24, 2018 at 07:27:15AM +0100, Steve McIntyre wrote: >>... >> The next big problem I can see is in our haskell packages for >> armhf. From my build log for haskell-zxcvbn-c_1.0.1-4.log (as an >> example): >> >> ... >> Setting up llvm-3.9 (1:3.9.1-19+b1) ... >> Setting up ghc (8.2.2-4) ... >> Illegal instruction >> >> update-alternatives: using /usr/bin/ghc to provide /usr/bin/haskell-compiler >> (haskell-compiler) in auto mode >> Illegal instruction >> dpkg: error processing package ghc (--configure): >> installed ghc package post-installation script subprocess returned error >> exit status 132 >> ... >> >> I'm going to have a look at that later today. > >https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=864847#15 Aha, thanks for the pointer! :-) -- Steve McIntyre, Cambridge, UK.st...@einval.com "Yes, of course duct tape works in a near-vacuum. Duct tape works anywhere. Duct tape is magic and should be worshipped." -― Andy Weir, "The Martian"
Re: Building armel on arm64
Apologies for delayed response - I've been horrendously busy. :-/ On Sun, Jul 08, 2018 at 11:03:12PM +0300, Adrian Bunk wrote: >On Wed, Jun 27, 2018 at 08:03:00PM +, Niels Thykier wrote: >>... >> armel/armhf: >> >> >> * Undesirable to keep the hardware running beyond 2020. armhf VM >>support uncertain. (DSA) >>... > >I'd like to get a clear picture regarding the situation of building >armel for buster on arm64, ideally moving it to arm64 hardwre soon. ACK. >1. What issues are considered possible problems for moving building > armel from 32bit v7 hardware to 64bit v8 hardware? > >ARM has some history of adding new functionality in new versions of >their architecture that gets deprecated in the next version of their >architecture. > >The armel baseline (currently armv5te) is low enough that several >of the issues with running armhf code on arm64 are not present >when running armel code on arm64. > >If anyone sees potential blockers for building armel on arm64, >especially ones that are not present for building armhf on arm64, >please speak up now. I was worried about CP15 barriers, but I've been digging in docs for a while and can't find anything to back that up for v5. >2. What level of testing has been done before building armhf on arm64? > >64bit arm-arm-01 has started participating in building armhf for >unstable and experimental. > >I don't want to do less testing for armel than has been done for armhf >prior to doing that, what testing had been done for armhf on arm64 >building prior to doing it on a buildd? Not very much *so far*. I wsan't expecting to find any issues, but at least two clear issues have shown up so far: * Alignment fixups. We have these enabled on our v7 buildds, but there is no support for this at all in the arcm64 kernel. See #902990 as an example. * The definitions for MINSIGSTKSZ differ between armhf and arm64 - see #904385 To get an idea about these and any other problems, I've started a mass rebuild of the archive as armhf-on-arm64 on three machines at home. They're currently ~40% of the way through the archive and I estimate they are going to take another couple of weeks to complete. The next big problem I can see is in our haskell packages for armhf. From my build log for haskell-zxcvbn-c_1.0.1-4.log (as an example): ... Setting up llvm-3.9 (1:3.9.1-19+b1) ... Setting up ghc (8.2.2-4) ... Illegal instruction update-alternatives: using /usr/bin/ghc to provide /usr/bin/haskell-compiler (haskell-compiler) in auto mode Illegal instruction dpkg: error processing package ghc (--configure): installed ghc package post-installation script subprocess returned error exit status 132 ... I'm going to have a look at that later today. >3. Starting to build armel on arm64 > >Depending on the answers to the questions above I would like to >setup building armel on arm64, perhaps on the same arm-arm-01. Possibly. Let's see how things go - I'm looking at sourcing many more machines too... -- Steve McIntyre, Cambridge, UK.st...@einval.com "I can't ever sleep on planes ... call it irrational if you like, but I'm afraid I'll miss my stop" -- Vivek Das Mohapatra
Arm ports build machines (was Re: Arch qualification for buster: call for DSA, Security, toolchain concerns)
ul about that. Options I can see today for new publically available machines are here. I'm sure I'll have missed something obvious - please feel free to improve on this list! * Macchiatobin [1] - based on the Marvell 8040 SoC (4-core Cortex A72), supports both A32 and A64. Standard format (mini-itx) board mountable in a rack case. DIMM slot supports up to 16GiB, 3 SATA ports, multiple onboard NICs. Supported in mainline upstream kernel. Console on USB :-/. Readily available to buy. * Synquacer [2] - based on the Socionext SC2A11 SoC (24-core Cortex A53), supports both A32 and A64. Standard format (ATX) board mountable in a rack case. DIMM slots supports up to 4x16GiB, 2 SATA ports, onboard NIC. Supported in mainline upstream kernel. I'm hoping to get some of these machines donated to us from Linaro. * Qualcomm Centriq [3] - based on Qualcomm's Falkor CPU. Only supports A64 - no A32 support. All the big features you'd want in a big expensive server (management, RAM, I/O). Development machines available, but difficult to get hold of for the general public. Supported in mainline upstream kernel, some of it backported for Stretch (9.5) in #896775. * ThunderX 2 [4] - Cavium's second generation of AArch64 server CPU. Only supports A64 - no A32 support. All the big features you'd want in a big expensive server (management, RAM, I/O). Development machines available, but difficult to get hold of for the general public. Supported in mainline upstream kernel. * HiSilicon D05 [5] - HiSilicon's latest AArch64 server CPU and board. AFAIK only supports A64 - no A32 support. All the big features you'd want in a big expensive server (management, RAM, I/O). Development machines available, but difficult to get hold of for the general public - I've been trying for a while with HiSilicon. Not sure about upstream kernel support. While they're on the lower end of this list, I think the Macchiatobin and Synquacer are probably our best bets *at the moment*, particularly when considering A32 support. In suitable rack cases with PDU and serial console, would those work for DSA's needs? [1] http://macchiatobin.net/ [2] https://www.cnx-software.com/2017/09/24/gigabyte-synquacer-96boards-enterprise-platform-is-powered-by-socionext-sc2a11-24-core-armv8-soc/) [3] https://www.qualcomm.com/products/qualcomm-centriq-2400-processor [4] https://www.cavium.com/product-thunderx2-arm-processors.html [5] http://open-estuary.org/d05/ -- Steve McIntyre, Cambridge, UK.st...@einval.com Can't keep my eyes from the circling sky, Tongue-tied & twisted, Just an earth-bound misfit, I...
Re: Arch qualification for buster: call for DSA, Security, toolchain concerns
On Fri, Jun 29, 2018 at 08:27:09AM +, Riku Voipio wrote: >On Thu, Jun 28, 2018 at 08:11:14PM +0200, Florian Weimer wrote: >> * Niels Thykier: >> >> > armel/armhf: >> > >> > >> > * Undesirable to keep the hardware running beyond 2020. armhf VM >> >support uncertain. (DSA) >> >- Source: [DSA Sprint report] >> >> Fedora is facing an issue running armhf under virtualization on arm64: >> >> <https://bugzilla.redhat.com/show_bug.cgi?id=1572916> > >I think you mean: > >https://bugzilla.redhat.com/show_bug.cgi?id=1576593 Yeah, that looks more likely. I can see that Ard is already trying to help debug it. But things have gone quiet for a couple of weeks, at least in the public discussion. ... >> It's also not clear that this configuration has substantial vendor or >> community support. This makes me concerned that virtualization is a viable >> path forward here. > >I understand your concern. It would be surprising if this specific bug doesn't >get found and fixed. It's probably stuck because everyone thinks it's >probably someone elses bug ;) Yeah, that's my thought too. :-) >I still think the armhf vm on arm64 is the only reasonable path forward medium >term. The existing arm64 hw that suport arm32 vm's is still around and >infinitely better than native aarch32 builder hw, and should still be viable >for some time. Nod. The "fun" thing we see is that quite a few of the biggest AArch64 CPUs are A64-only, but there's still a selection of things available that I think look OK. I'll post separately in a moment about that... -- Steve McIntyre, Cambridge, UK.st...@einval.com Is there anybody out there?
Re: debian installer on arm64
On Sun, Jan 14, 2018 at 08:16:07PM +0100, Thorsten Alteholz wrote: >Hi Steve, > >On Sat, 13 Jan 2018, Steve McIntyre wrote: >> On Fri, Jan 12, 2018 at 07:59:14PM +0100, Thorsten Alteholz wrote: >> > am I right that this U-Boot stumbles over partition id 0xef of the second >> > partition of the installer iso? >> >> ?? Not sure what you mean... > >the iso images of the netinst arm64 debian installer have two partitions, one >of type 83 (= Linux) and one of type ef (= EFI (FAT-12/16/32)). The U-Boot in >the Macchiatobin SPI flash can access files on partitions of type 83 and 6 >with ext4load and fatload. So I assume that it just stumbles over the efi >partition due to a simple id mismatch. If this is the case one could directly >start from the usb debian installer without first having to boot the EDK2 >image from the sd card. >Does that make sense to you? Ah, I see. I didn't realise that the included U-Boot was so ... awkward. I know people are working on some limited UEFI support in U-Boot, which (eventually!) might mean this kind of thing will get much easier. I just went straight for the EDK2 image for my machine. >> Sorry, no. How old/used is the USB drive? > >Oh, this USB stick is rather old. A different one doesn't boot at all, but an >USB3 SD card reader seems to work now. Yay! -- Steve McIntyre, Cambridge, UK.st...@einval.com "Managing a volunteer open source project is a lot like herding kittens, except the kittens randomly appear and disappear because they have day jobs." -- Matt Mackall
Re: debian installer on arm64
On Fri, Jan 12, 2018 at 07:59:14PM +0100, Thorsten Alteholz wrote: >Hi Steve, > >On Fri, 12 Jan 2018, Steve McIntyre wrote: >> No, not at all. Unfortunately, the Macchiatobin still ships with >> U-Boot installed as the default firmware and it's not all that useful >> for installation. > >am I right that this U-Boot stumbles over partition id 0xef of the second >partition of the installer iso? ?? Not sure what you mean... >> The EDK2 image I've used is one built by my friend Leif (unixsmurf on >> IRC) [4], and it works reasonably well. Using that, the system should >> happily boot Debian from a USB stick and it should let you install and >> run. > >Great, thanks a lot! The installer does start now. Unfortunately I get: > >[2018-01-12 19:12:51 >Press ESCAPE for boot options ...[Bds]Booting UEFI BUFFALO USB Flash Disk >A3633130 >[2018-01-12 19:18:01 >XhcBulkTransfer: error - Time out, transfer - 40 >[2018-01-12 19:23:07 >XhcBulkTransfer: error - Time out, transfer - 40 >[2018-01-12 19:28:13 >XhcBulkTransfer: error - Time out, transfer - 40 >UsbBotExecCommand: UsbBotGetStatus (Time out) >UsbBootExecCmd: Timeout to Exec 0x0 Cmd > >but after that 16 minute timeout period it goes: > >Loading driver at 0x000B668E000 EntryPoint=0x000B668E400 >[2018-01-12 19:28:14 >Loading driver at 0x000B668E000 EntryPoint=0x000B668E400 >GNU GRUB version 2.02~beta3-5 >(...) > >and the installer is available. Do you have any idea why it needs to wait? Sorry, no. How old/used is the USB drive? -- Steve McIntyre, Cambridge, UK.st...@einval.com Can't keep my eyes from the circling sky, Tongue-tied & twisted, Just an earth-bound misfit, I...
Re: debian installer on arm64
On Thu, Jan 11, 2018 at 11:29:10PM +0100, Thorsten Alteholz wrote: >Hi, > >after getting my Macchiatobin, I naively thought that I only had to copy the >arm64 installer from [1] or an netinst image to an USB stick and I could >start with the fun. >Unfortunately that did not work. So is the whole thing not that easy as >written on [2] and do I really have to build everything from scratch like >recommended in the Macchiatobin-wiki? No, not at all. Unfortunately, the Macchiatobin still ships with U-Boot installed as the default firmware and it's not all that useful for installation. The better way to use the machine is to write an EDK2 (UEFI) image to a uSD card and boot using that. There are some switch settings documented in the solid-run docs [3] to tell the machine to boot off uSD instead of the SPI flash. The EDK2 image I've used is one built by my friend Leif (unixsmurf on IRC) [4], and it works reasonably well. Using that, the system should happily boot Debian from a USB stick and it should let you install and run. Once you've installed, *for now* you'll need to use the rescue mode option to install grub to the removable media path, as we don't yet have support for storing UEFI boot variables. We're not *quite* there for an "everything works" system, but we're not too far away. There's occasional discussion on #debian-arm, and I'm hosting a (quiet-ish) mailing list for macchiatobin discussion [5]. HTH! >[1] https://d-i.debian.org/daily-images/arm64/ >[2] https://wiki.debian.org/Arm64Port [3] https://wiki.solid-run.com/doku.php?id=products:a8040:communityboard:dipswitch [4] http://eciton.net/~leif/macchiatobin/flash-image-17.10.bin [5] https://lists.einval.com/cgi-bin/mailman/listinfo/macchiato -- Steve McIntyre, Cambridge, UK.st...@einval.com "I've only once written 'SQL is my bitch' in a comment. But that code is in use on a military site..." -- Simon Booth
Re: 0ad FTBFS on arm64: help expected
On Wed, Nov 29, 2017 at 02:49:57PM +0100, John Paul Adrian Glaubitz wrote: >On 11/29/2017 02:36 PM, Ludovic Rousseau wrote: >> I am the new Debian maintainer of 0ad (a video game). >> Since 0ad version alpha 22 (0.0.22 in Debian) the software fails to build on >> arm64. >> The build logs are at >> https://buildd.debian.org/status/fetch.php?pkg=0ad=arm64=0.0.22-1=1508351579=0 >> >> The build error is related to mozjs-38.0.0 patched and embedded in 0ad: > >mozjs is a security-relevant library. It shouldn't be embedded into 0ad. >Rather, >you should link against any of the mozjs versions packaged and available in >Debian. The security team will certainly not be happy about your embedded copy >of a Javascript engine and they might as you to fix this issue or your package >gets removed from testing. Nod. >> I have no time to work on this bug. I am not sure if many people will ever >> play 0ad on arm64 :-) >> For now support of arm64 has been removed. > >That's not how we usually fix bugs in Debian. Agreed. It would be lovely to see some efforts to clean up mess like this in the javascript world. It takes a lot of effort to port to new architectures, but due to awful API/ABI practices there are embedded (out-of-date, buggy and insecure) copies all over the place. :-( -- Steve McIntyre, Cambridge, UK.st...@einval.com You lock the door And throw away the key There's someone in my head but it's not me
Re: Anyone using stretch/buster/sid on ARMv4t ?
On Tue, Nov 07, 2017 at 01:43:50PM +0100, Hector Oron wrote: > >Also build daemons are aging, those were initially donated by Marvell >(some development boards) which then they replaced with other >development boards. We have been unable to find suitable hardware to >build armel port and current ARMv8 server class instruction set lacks >few instructions and we have been advised to not build armel ports in >such hardware. > Current build daemons got into production in 2010 -- >https://blog.einval.com/2010/09/27 >We have no current replacement for that hardware, which it's already 7 >years old and still needs to keep up running for Stretch life cycle >(and maybe LTS). >There might be other issues, as upstream support in few other projects, etc... Not quite - those are the old machines that we already replaced. The current builders for armel are Marvell Armada XP GP dev boards, commissioned in early 2014. -- Steve McIntyre, Cambridge, UK.st...@einval.com "Because heaters aren't purple!" -- Catherine Pitt
Re: how to distinguish armel and armhf at runtime?
On Fri, Sep 22, 2017 at 09:57:02PM +0200, Uwe Kleine-König wrote: >Hello, > >for the package sparse I have to distinguish armel and armhf. The reason >is that sparse parses system headers and so has to know which cpp >symbols to define. Usually it uses uname -m to distinguish platforms but >that isn't suitable to tell armel and armhf apart. > >For armhf I need to define __ARM_PCS_VFP but that must be absent on armel. Right, that makes sense. >For upstreaming a fix it would be great if the test would not be Debian >specific. That's likely to be difficult - it's perfectly possible to have headers etc. for both on a single system with multi-arch (for example). It's an ABI choice, not a hardware difference. What are you trying to work this out for? Package build time? -- Steve McIntyre, Cambridge, UK.st...@einval.com "Since phone messaging became popular, the young generation has lost the ability to read or write anything that is longer than one hundred and sixty characters." -- Ignatios Souvatzis
Re: Summary of the Arm ports BoF at DC17
On Fri, Sep 15, 2017 at 07:11:38PM +0100, Ben Hutchings wrote: >On Thu, 2017-09-14 at 03:40 +0100, Steve McIntyre wrote: >[...] >> There is optional kernel support to trap the exceptions here >> and emulate the instructions, but it's really not recommended for >> serious use (e.g. on a build machine!). >[...] > >Why is it not recommended? Terrible performance, or known bugs? I've heard estimates for performance slowdown of a factor of 20 or more, maybe worse. It's very dependent on the hardware and the code in question obviously. Sorry, I don't have any references, I'm afraid. :-/ Of course, the massive log overheard that Vagrant reports won't help much either! I'm not aware of any bugs OTTOMH. -- Steve McIntyre, Cambridge, UK.st...@einval.com There's no sensation to compare with this Suspended animation, A state of bliss
Re: Summary of the Arm ports BoF at DC17
On Thu, Sep 14, 2017 at 12:06:13PM +0200, Marco d'Itri wrote:
>On Sep 14, Steve McIntyre <st...@einval.com> wrote:
>
>> The Pine64 [6] is another alternative, based on a mobile CPU. It's
>> therefore got limited RAM and I/O. Upstreaming has taken a while, but
>> is getting there in current kernel releases. U-Boot head will work on
>> the board, including the UEFI implementation mentioned earlier.
>> There's the related PineBook project [7] too - a small laptop-style
>> machine based around the Pine64 board.
>There are also scary warnings and discussions about the Ethernet port
>being half-broken at 1 Gbps.
>
>> Answering this question ("I want something that just works, what
>> should I buy?") is always much harder than it should be... :-(
>On the lower end I strongly recommend the Olimex Lime 2, which is open
>hardware and works well with the mainline kernel and U-Boot from stretch
>(as long as you do not care about 3D, obviously):
>https://www.armbian.com/olimex-lime-2/
ACK, thanks for the recommendation!
>BTW... I like installing my little ARM systems using debootstrap
>--foreign, but I am unable to do a 100% self-contained installation
>(without using qemu, which would be cheating, or copying the initramfs
>from another system) because the initramfs has not been built yet.
>Do we distribute anyware one that may be used for the first boot?
Not that I'm aware of, no.
--
Steve McIntyre, Cambridge, UK.st...@einval.com
"C++ ate my sanity" -- Jon Rabone
Re: Summary of the Arm ports BoF at DC17
On Thu, Sep 14, 2017 at 12:58:02PM +0800, Paul Wise wrote: >On Thu, Sep 14, 2017 at 10:40 AM, Steve McIntyre wrote: > >> It's possible to replace the installed U-Boot >> on many boards, but that depends on hardware support being properly >> upstreamed; lack of that upstreaming work is another common bugbear in >> vendor U-Boot binaries. If you want to use your arm64 machine as a >> *computer*, my recommended route is UEFI; this is why all the server >> vendors have gone that route. > >Doesn't the same problem of u-boot upstreaming also apply to >UEFI/TianoCore upstreaming (but worse)? AFAICT we do not have *any* >support in our edk2 source package for anything other than virtual >machines (x86/ARMv7/ARMv8). It seems to me that u-boot is in a much >better position wrt upstream support for ARM *and* for support for >UEFI than TianoCore or other options that aren't in Debian like >coreboot. Let's be straight - the UEFI boot support in U-Boot is very much a limited project to ease booting; it's not *at all* a complete implementation of UEFI like Tianocore. It doesn't support any of the runtime interfaces, for example. I stand by my recommendation: for normal use for an end user on an arm64 machine, UEFI is a better bet than U-Boot. ... >> Last question: what should people do to keep armel? Main things: >> >> * deal with armel-specific bug reports > >For some reason there isn't an armel usertag but there is an eabi one: > >https://udd.debian.org/cgi-bin/bts-usertags.cgi?tag=eabi=debian-arm%40lists.debian.org > >> * get involved in toolchains and make sure they continue to work > >Join the #debian-toolchain IRC channel and tell doko you are there to >support armel. +1 >Improve the wiki page for armel, move it under the Ports hierarchy and >base it off the port template: > >https://wiki.debian.org/ArmEabiPort >https://wiki.debian.org/Ports >https://wiki.debian.org/PortTemplate > >Improve the web page for the ARM ports. > >https://www.debian.org/ports/arm/ Alternatively, give up on the ports web pages altogether - IMHO they're massively more effort to maintain than stuff in the wiki and that's one of the reasons why they're always so out-dated. -- Steve McIntyre, Cambridge, UK.st...@einval.com You raise the blade, you make the change... You re-arrange me 'til I'm sane...
Summary of the Arm ports BoF at DC17
ant something that just works, what should I buy?") is always much harder than it should be... :-( Hector asked about the current state of the less well-known Arm ports: big-endian versions and arm64ilp32. Lots of different BE ports have happened over the years, for various reasons. arm64ilp32 [8] is the arm64 equivalent of x32 on x64-64; IMHO there is no need for it in Debian as a mainstream port. Wookey is working on it in Linaro at the moment. There is a BE version too. While x32 *might* have some performance wins over i386 (depending on code), it's not clear that arm64ilp32 is likely to be any better than armhf (A32) in most cases. Last question: what should people do to keep armel? Main things: * deal with armel-specific bug reports * get involved in toolchains and make sure they continue to work * *mail the debian-arm list and commit to working on stuff* [1] http://meetings-archive.debian.net/pub/debian-meetings/2017/debconf17/debian-arm-bof.vp8.webm [2] http2://www.einval.com/~steve/talks/Debconf17-arm-BoF/ [3] https://lists.debian.org/debian-arm/2017/08/msg00015.html [4] https://www.scaleway.com/ [5] https://www.solid-run.com/product/armada-8040-networking-community-board/ [6] https://www.pine64.org/ [7] https://www.pine64.org/?page_id=3707 [8] https://wiki.debian.org/Arm64ilp32Port -- Steve McIntyre, Cambridge, UK.st...@einval.com "Managing a volunteer open source project is a lot like herding kittens, except the kittens randomly appear and disappear because they have day jobs." -- Matt Mackall signature.asc Description: PGP signature
Re: arm64: Booting from USB with UEFI?
On Thu, Aug 17, 2017 at 10:40:28PM +0200, Holger Wansing wrote: >Steve McIntyre <st...@einval.com> wrote: >> > >> >What's the state here? >> >Can arm64 boot directly from USB? >> >> Bugger. That's a mistake, yes. Quite a few (most?) of the arm64 UEFI >> platforms will boot from USB, and we've been making iso-hybrid CD >> images to support that ever since Jessie. > >Ok, so I will add >boot="bootable-usb;isohybrid-supported" >to the arch-options file for arm64. Cool. >But that leads to another question: >There is missing content for something like "Boot Device Selection", >see >http://d-i.alioth.debian.org/manual/en.i386/ch03s06.html#boot-dev-select >for a similar chapter for i386. >That one for i386 is probably not generic enough to fit for arm64 as well. >If someone could provide some information how to select the boot device >at arm64, that would be fine. ACK. It's more like the "Systems with UEFI firmware" section there, but also simpler - there's no need to mention CSM at all, nor Windows 8 etc. I'll try to come up with some text if nobosy beats me to it. -- Steve McIntyre, Cambridge, UK.st...@einval.com "When C++ is your hammer, everything looks like a thumb." -- Steven M. Haflich
Re: arm64: Booting from USB with UEFI?
On Thu, Aug 17, 2017 at 09:32:46PM +0200, Holger Wansing wrote: >[ Please CC me, I'm not subscribed to debian-arm ] > >Hi, > >in the installation-guide there were some changings for arm64 architecture, >being worked on by wookey and 93sam: >see >https://anonscm.debian.org/viewvc/d-i/trunk/manual/en/boot-installer/arm.xml?r1=69757=69774 >and >https://anonscm.debian.org/viewvc/d-i/trunk/manual/en/boot-installer/arm.xml?r1=69776=69781d > > >That resulted to this: > > > > Booting from USB Memory Stick with UEFI > > > > > >However, this chapter does not appear in the installation-guide for >arm64, because arm64 is not declared to be "bootable-usb" in the >arch-options file. > >What's the state here? >Can arm64 boot directly from USB? Bugger. That's a mistake, yes. Quite a few (most?) of the arm64 UEFI platforms will boot from USB, and we've been making iso-hybrid CD images to support that ever since Jessie. -- Steve McIntyre, Cambridge, UK.st...@einval.com "C++ ate my sanity" -- Jon Rabone
Re: Bug#864848: Should not talk about hd-media - that's armhf only
On Thu, Aug 17, 2017 at 09:17:22PM +0200, Holger Wansing wrote: >On Thu, 15 Jun 2017 22:51:21 +0100 >Steve McIntyre <st...@einval.com> wrote: >> Package: installation-guide-armel >> Severity: normal >> >> As seen in >> >> https://www.debian.org/releases/jessie/armel/ch05s01.html.en >> >> there's discussion of "unpack the hd-media tarball". This doesn't >> exist on armel... > >Does that mean, that armel does not support that "Boot from USB stick in >U-Boot" thingy, described under above link? >If that _is_ supported, that chapter needs to be rewritten (simply leaving >out the part where the hd-media tarball is mentioned, would make the whole >chapter senseless/important part missing). To the best of my knowledge, we don't have any such support in the armel port. I'd love to be corrected on this, but I don't see anything like that in our d-i builds. >Adding arm porters to the loop seems to make sense here. Nod. -- Steve McIntyre, Cambridge, UK.st...@einval.com You raise the blade, you make the change... You re-arrange me 'til I'm sane...
Bug#862941: binNMUs needed for multiple arm64 packages (#850814)
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu Hey folks, As first discussed a while back, we've had a bug in gold which caused some broken builds of some arm64 packages. These were mostly in backports, with a few example in the early life of stretch. Now that #850814 is fixed and we have an updated binutils in stable too, I've re-scanned the archive for arm64 binaries with broken alignment. Please binNMU the following (I hope I got the syntax right!): Backports: nmu haskell-cabal_1.22.4.0-2~bpo8+1 . arm64 . jessie-backports -m "Rebuild with fixed binutils" nmu haskell-hierarchical-clustering_0.4.6-1~bpo8+1 . arm64 . jessie-backports -m "Rebuild with fixed binutils" nmu haskell-http_4000.2.20-3~bpo8+1 . arm64 . jessie-backports . -m "Rebuild with fixed binutils" nmu haskell-mtl_2.2.1-2~bpo8+1 . arm64 . jessie-backports . -m "Rebuild with fixed binutils" nmu haskell-network_2.6.2.1-3~bpo8+1 . arm64 . jessie-backports . -m "Rebuild with fixed binutils" nmu haskell-network-uri_2.6.0.3-3~bpo8+1 . arm64 . jessie-backports . -m "Rebuild with fixed binutils" nmu haskell-old-locale_1.0.0.7-2~bpo8+1 . arm64 . jessie-backports . -m "Rebuild with fixed binutils" nmu haskell-old-time_1.1.0.3-2~bpo8+1 . arm64 . jessie-backports . -m "Rebuild with fixed binutils" nmu haskell-parsec_3.1.9-4~bpo8+1 . arm64 . jessie-backports . -m "Rebuild with fixed binutils" nmu haskell-prettyclass_1.0.0.0-4~bpo8+1 . arm64 . jessie-backports . -m "Rebuild with fixed binutils" nmu haskell-random_1.1-3~bpo8+1 . arm64 . jessie-backports . -m "Rebuild with fixed binutils" nmu haskell-stm_2.4.4-4~bpo8+1 . arm64 . jessie-backports . -m "Rebuild with fixed binutils" nmu haskell-text_1.2.1.3-2~bpo8+1 . arm64 . jessie-backports . -m "Rebuild with fixed binutils" nmu haskell-zlib_0.5.4.2-4~bpo8+1 . arm64 . jessie-backports . -m "Rebuild with fixed binutils" nmu systemd_230-7~bpo8+2 . arm64 . jessie-backports . -m "Rebuild with fixed binutils" nmu wine-development_2.0.3~bpo8+1 . arm64 . jessie-backports . -m "Rebuild with fixed binutils" Unstable: nmu wine-development_2.0.3 . arm64 . -m "Rebuild with fixed binutils" Experimental: nmu wine-development_2.8-1 . arm64 . experimental . -m "Rebuild with fixed binutils" nmu wine-2.0.1-1 . arm64 . experimental . -m "Rebuild with fixed binutils" I'm *guessing* all the Haskell packages might involve triggering more rebuild of all the rdeps too, not sure... -- System Information: Debian Release: 8.8 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-0.bpo.1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Re: d-i manual: 3 "jessie" remain in current guide
On Tue, Apr 18, 2017 at 12:21:01AM +0200, Samuel Thibault wrote: >Hello Steve, > >Steve McIntyre, on dim. 09 avril 2017 01:53:01 +0100, wrote: >> On Sat, Apr 08, 2017 at 05:39:20PM -0700, Vagrant Cascadian wrote: >> >So, unless it's implemented outside of the device-tree, or I'm >> >misreading that, I'd say it's safe to say it's still disabled. >> >> On the Mustang, you need to be using the firmware-provided >> DTB. Assuming a sane, recent UEFI firmware things USB boot should work >> just fine. I got it working for the first Jessie point release too, >> after doing a temporary build in >> http://cdimage.debian.org/cdimage/unofficial/arm64-mustang/ . >> >> I've not tested a stretch installation directly on a Mustang >> lately. The machine I used for the jessie testing has since been >> repurposed as a buildd. I'll see if I can access to test another. > >Did you manage to have a look? I've just (now!) got access to a mustang and happily booted the stretch installer. The installer found USB, loaded udebs, modules, etc. All working fine, at least to that point. I couldn't test a *complete* installation on this machine, but I'd fully expect the rest of the process to work. -- Steve McIntyre, Cambridge, UK.st...@einval.com "The problem with defending the purity of the English language is that English is about as pure as a cribhouse whore. We don't just borrow words; on occasion, English has pursued other languages down alleyways to beat them unconscious and rifle their pockets for new vocabulary." -- James D. Nicoll
Re: debian-installer now available in Ports
On Wed, Apr 12, 2017 at 01:55:08PM +0100, Steven Chamberlain wrote: >John Paul Adrian Glaubitz wrote: >> Thus, I was wondering whether any volunteers would be willing to help >> building >> ISO images for the various architectures. > >I'm already doing this for kfreebsd-amd64, but only the jessie-kfreebsd >suite: >http://jenkins.kfreebsd.eu/jenkins/view/cd/job/debian-cd_jessie-kfreebsd/lastBuild/console >and I had to patch debian-cd before it worked. (Didn't yet find time to >file bugs or submit those patches). Please post them! >I could probably set up similar jobs for kfreebsd-* sid now. > >> It's not necessary to run debian-cd on the same architecture as the >> target architecture of the ISO images. Exactly. There are sometimes difficulties with the tools needed to set up boot files etc., but they tend to be portable. >I did not even realise that. So I will add kfreebsd-i386 next. > >I expect there might be problems trying to build linux arches from a >kfreebsd host. But we should try to find out, and then maybe fix it. We were happily building kfreebsd-* images from a Linux host, so I'd expect it to work OK. I've offered before: I don't have the time personally to work on building ports images, but I'm more than happy to help other people getting them building on our official infrastructure... -- Steve McIntyre, Cambridge, UK.st...@einval.com Who needs computer imagery when you've got Brian Blessed?
Re: d-i manual: 3 "jessie" remain in current guide
On Sat, Apr 08, 2017 at 05:39:20PM -0700, Vagrant Cascadian wrote: >On 2017-04-08, Samuel Thibault wrote: >> We need an answer, so as to update the documentation: is USB still not >> supported in the stretch kernel on arm64? >> >> victory, on Mon 30 Jan 2017 21:53:52 +0900, wrote: >>> boot-installer/arm.xml:108- >>> ... Also USB is not supported in the jessie kernel so >>> installing from a USB stick does not work. ... > >This apparently is referring to apm-mustang rather than arm64 in >general... > >I don't much about that platform, but there doesn't appear to be any >mention of enabled USB in arch/arm64/boot/dts/apm/apm-mustang.dts in >linux 4.9.x. There's mention of it in the apm-storm.dtsi which it >includes, but it's marked as disabled there. > >So, unless it's implemented outside of the device-tree, or I'm >misreading that, I'd say it's safe to say it's still disabled. On the Mustang, you need to be using the firmware-provided DTB. Assuming a sane, recent UEFI firmware things USB boot should work just fine. I got it working for the first Jessie point release too, after doing a temporary build in http://cdimage.debian.org/cdimage/unofficial/arm64-mustang/ . I've not tested a stretch installation directly on a Mustang lately. The machine I used for the jessie testing has since been repurposed as a buildd. I'll see if I can access to test another. -- Steve McIntyre, Cambridge, UK.st...@einval.com Into the distance, a ribbon of black Stretched to the point of no turning back
Re: Bug#853793: dpkg: ABI mismatch detector is too strict on armel/armhf
On Thu, Feb 02, 2017 at 02:42:26PM +0100, Jens Reyer wrote: >On 02/02/2017 02:30 PM, Steve McIntyre wrote: >> Dropping the -nostdlib argument to the gcc call inside sonames2elf >> makes a difference - it'll add libc6 to the mix and force the output >> to match the system you're building for. You may then need to filter >> out the libc6 entry afterwards, but that's easily done. > >I'll do that for wine and wine-development, keeping options open for >dpkg to handle this correctly. Cool. :-) >Filtering out isn't necessary: dpkg-shlibdeps already takes care of >removing redundant entries. And we do want to depend on libc6. Ah, of course yes... -- Steve McIntyre, Cambridge, UK.st...@einval.com Into the distance, a ribbon of black Stretched to the point of no turning back
Re: Bug#853793: dpkg: ABI mismatch detector is too strict on armel/armhf
Hi, On Thu, Feb 02, 2017 at 05:10:14AM +0100, Guillem Jover wrote: >On Wed, 2017-02-01 at 15:34:04 +0000, Steve McIntyre wrote: >> >> Please don't go down that route, the ABI flags are intended to save >> people from that. I'm curious what's going wrong with libgsm1 here >> such that we're not seeing consistent ABI flags. > >Well, I don't see any other sane option really. The problem is that >the code involved is in perl so must be arch independent, in contrast >to glibc, which is built against the architecture's ABI. Nod. I feel your pain... :-/ >In this case dpkg-shlibdeps, sees an ELF object with an EM_ARM machine >ID which links against "stuff". And it traverses the linker paths, in >principle in the right order, but for example there is no guarantee of >the correct order when using the ld.so.conf paths, because they are >alpha sorted, not in host > foreign order. :( ACK. In the particular case of wine here, I can see that there's a genuine problem that we've found (see other mail to Jens). What other packages are showing problems? >So we have an ELF object that might or might not have the SOFT/HARD >flags set, which links against SONAMEs that when found might or might >not have the SOFT/HARD flags set. And it needs to know which one is >ABI compatible to keep it or discard it. Yup. By now, I'd hope that we should have a consistent set of flags in programs and libraries, though. If there are any that are not yet fixed, I'd like to know the details so we can fix them. >Also inferring the architecture from the package shipping the file is >not currently reliable, due to multilib, because those subvert the >packaging system by shipping .deb with contents for the wrong arch. :( Ewww. :-( >> If you're worried about EABIv4, does the logic of the dpkg checker not >> match the checks we added in glibc itself? > >One of the problems is that currently the ABI matcher is a bit >simplistic, and it just combines various things that need to really >match and just compares the byte-streams for equality. Because that >allows the code to do good enough matching even when it does not know >new ELF machine types. It does better than the previous objdump >matcher in any case. > >In the future I guess I'll need to special case some architectures, >in particular, at least ARM, MIPS and SH. > >And just for reference the code being discussed is: > > > <https://anonscm.debian.org/cgit/dpkg/dpkg.git/tree/scripts/Dpkg/Shlibs/Objdump.pm#n173> ACK, I found that last night. It looks a little too simplistic, as you say. It's not easy to get this right for all the arches, I totally appreciate that! -- Steve McIntyre, Cambridge, UK.st...@einval.com There's no sensation to compare with this Suspended animation, A state of bliss
Re: Bug#853793: dpkg: ABI mismatch detector is too strict on armel/armhf
On Wed, Feb 01, 2017 at 05:03:13PM +0100, Jens Reyer wrote: >On 02/01/2017 04:34 PM, Steve McIntyre wrote: >> >> Please don't go down that route, the ABI flags are intended to save >> people from that. I'm curious what's going wrong with libgsm1 here >> such that we're not seeing consistent ABI flags. > >It's not just libgsm1, on armhf the build fails because of more than 20 >libraries: > >https://buildd.debian.org/status/fetch.php?pkg=wine=armhf=1.8.6-4=1485847439=0 > >Greets >jre > > >If it helps, this is the short form of the code that triggers this (we >compute a list of dependencies for libs that are dlopen'ed by Wine): > >$ sonamesDepends="libfontconfig.so.1 libfreetype.so.6 libncurses.so.5" >$ sonamesRecommends="libcups.so.2 libdbus-1.so.3 libfontconfig.so.1 >libfreetype.so.6 libGL.so.1 libgnutls.so.30 libgsm.so.1 libjpeg.so.62 >libncurses.so.5 libodbc.so.2 libopenal.so.1 libOSMesa.so.8 >libpng16.so.16 libtiff.so.5 libX11.so.6 libXcomposite.so.1 >libXcursor.so.1 libXext.so.6 libXi.so.6 libXinerama.so.1 libXrandr.so.2 >libXrender.so.1 libxslt.so.1 libXxf86vm.so.1" > >$ printf 'INPUT(%s)\n' "$sonamesDepends" > libeverything.so >$ gcc -shared -nostdlib -Wl,--no-as-needed -L. -leverything -o elf.depends > >$ printf 'INPUT(%s)\n' "$sonamesRecommends" > libeverything.so >$ gcc -shared -nostdlib -Wl,--no-as-needed -L. -leverything -o >elf.recommends > >$ dpkg-shlibdeps --warnings=1 \ >-pdlopen \ >-dDepends -edebian/tmp/elf.depends \ >-dRecommends -edebian/tmp/elf.recommends \ >-Tdebian/libwine.substvars *wince* Not sure how valid the sonames2elf hackery is here, but it's the output of that script that's causing issues. It looks like there's a hole in the gcc pipeline around the ABI flag-handling code here, and it's outputting *both* ABI flags, which is (IIRC) strictly invalid: Flags: 0x5000600, Version5 EABI, soft-float ABI, hard-float ABI I'll look into that (again!), but that's going to take some time. Dropping the -nostdlib argument to the gcc call inside sonames2elf makes a difference - it'll add libc6 to the mix and force the output to match the system you're building for. You may then need to filter out the libc6 entry afterwards, but that's easily done. -- Steve McIntyre, Cambridge, UK.st...@einval.com Can't keep my eyes from the circling sky, Tongue-tied & twisted, Just an earth-bound misfit, I...
Re: Bug#853793: dpkg: ABI mismatch detector is too strict on armel/armhf
Hey folks, On Wed, Feb 01, 2017 at 05:08:50AM +0100, Guillem Jover wrote: >On Tue, 2017-01-31 at 22:44:36 +, James Cowgill wrote: >> >> Here libgsm.so has neither HARD or SOFT flags set. Also, asking gcc to >> generate a library which does not link against libc (this is used by >> sonames2elf in some packages) causes both flags to be set (maybe >> because it's compatible with both?). > >Even worse, I've found at least one instance of a package containing >binaries with EABIv4 (on armel, paris-traceroute). So I guess I'll have >to remove the flags matching on EM_ARM ELF binaries for now. At least >this will get us back to the previous behavior with objdump, no >regression in that sense. > >To be able to distinguish armel from armhf I'd probably need to check >the arm attributes section for Tag_ABI_VFP_args, which annoyingly >seems to be set even when the HARD flag is not set. :/ But this will >be for dpkg 1.19.x. Please don't go down that route, the ABI flags are intended to save people from that. I'm curious what's going wrong with libgsm1 here such that we're not seeing consistent ABI flags. If you're worried about EABIv4, does the logic of the dpkg checker not match the checks we added in glibc itself? -- Steve McIntyre, Cambridge, UK.st...@einval.com Mature Sporty Personal More Innovation More Adult A Man in Dandism Powered Midship Specialty
Re: armel after Stretch
Roger Shimizu wrote: >On Thu, Dec 8, 2016 at 12:53 AM, Steve McIntyre <st...@einval.com> wrote: >> >> There are kernel helpers available to provide some atomic support, but >> they'll be very slow compared to real hardware support at this level. > >Are those kernel helper already reached Debian? >Or there's still some work here? As Ben said - they're in the kernel already. But various packages *may* still need port work to use them. >> It's a similar thing, but further up the curve - that's all. We added >> armhf (as the equivalent of i686, maybe) a while back, targeting >> ARMv7. The much older CPU designs based on ARMv4 and ARMv5 are getting >> harder to support than the i586 here. The world has moved on, >> basically. > >Just like the world already moves on to amd64, but Debian still >support i386 and i686, Not so much - we don't support *actual* i386 machines any more, nor i486 nor most i586. >I think the community need armel and armhf, for quite a long time if >it's feasible. > >> You're the first armel developer to offer to dive in here, so that's a >> good start! > >Thanks, but my knowledge don't cover the lower part such as building >toolchains, >still need someone with more experience. OK. >> * *If* we wanted to try the partial architecture thing, that will >>need some effort to make it work. That's not well-defined right >>now, as it's only a vague concept at best (sorry!) > >Maybe we can avoid to do partial arch? As it's still very much a vague concept that'd be easier, yes. :-) >> * There are going to be some packages that just won't work, >>particularly JIT compilers and other code generators that assume >>ARM == ARMv7. Fixing those up might raneg between feasible and >>~impossible depending on the size of the codebase... > >If something breaks, I guess it breaks now already. >We need to fix before Stretch. >If the issue is fixed, I think there's no need to remove armel >immediately after releasing Stretch. That will be up to the release team, basically. I'm not going to be actively pushing for the removal of armel personally, but as we've seen recently (with the removal of powerpc for stretch) what matters is having multiple active porters working on fixing things steadily throughout the release cycle. So long as we (you!) can demonstrate that, armel can survive. It's not wonderful for users that things go EOL over time, but it happens. We're also giving people plenty of warning that this might be coming, so interested people can step up and provide that support to keep things going. -- Steve McIntyre, Cambridge, UK.st...@einval.com < sladen> I actually stayed in a hotel and arrived to find a post-it note stuck to the mini-bar saying "Paul: This fridge and fittings are the correct way around and do not need altering"
Re: armel after Stretch
On Fri, Dec 09, 2016 at 06:42:19PM -1000, Julien Cristau wrote: >On 12/09/2016 05:22 PM, Wookey wrote: >> We can do poor-mans partial arch by just being fairly agressive about >> disabling armel for packages that are broken or not suitable. Not very >> clever or efficient, but it is easy to do and requires no infra or >> tooling changes at all. So long as someone is volunteering for that >> (easy but unexciting) work that could work. >> >We wouldn't necessarily want to call the result a Debian release, though. Nod. Also (AIUI) fairly likely to break release work for testing migration etc. unless people are very careful... -- Steve McIntyre, Cambridge, UK.st...@einval.com < Aardvark> I dislike C++ to start with. C++11 just seems to be handing rope-creating factories for users to hang multiple instances of themselves.
Re: armel after Stretch
On Wed, Dec 07, 2016 at 05:05:58PM +0100, Emilio Pozuelo Monfort wrote: >On 07/12/16 16:53, Steve McIntyre wrote: >> * It will need somebody happy to dive into the lower levels of the >>various toolchains to verify support for atomics and make things >>work where it's not already, by adding support for the kernel >>helpers. > >There has been some recent work on this, but it seems stalled and it's not >clear >whether it works on all the armel targeted hardware (e.g. v4t), see: > >https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=820535 >https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64735 ACK. I'd missed the updates there - thanks for the links! -- Steve McIntyre, Cambridge, UK.st...@einval.com "Managing a volunteer open source project is a lot like herding kittens, except the kittens randomly appear and disappear because they have day jobs." -- Matt Mackall
Re: armel after Stretch (was: Summary of the ARM ports BoF at DC16)
On Wed, Dec 07, 2016 at 08:50:40PM +0900, Roger Shimizu wrote:
>[ intentionally keep d-d CCed ]
>
>On Fri, 22 Jul 2016 02:36:05 +0100
>Steve McIntyre <st...@einval.com> wrote:
>
>> [ Please note the cross-post and Reply-To ]
>>
>> Hi folks,
>>
>> As promised, here's a quick summary of what was discussed at the ARM
>> ports BoF session in Cape Town.
>
>Thanks for the summary!
>
>I'm ARM porter on armel/marvell (orion5x/kirkwood).
>Stretch will be frozen and released soon, which makes me bit depressed,
>because it means armel will be dropped out of unstable/testing as the
>conclusion of Cape Town BoF.
>
>So I'm writing to ask if there's any chance ...
>
>> We spoke about the past/present/future state of ARM ports in Debian.
>>
>> armel
>> =
>>
>> armel is the longest-running of our current ARM ports in Debian,
>> starting in 2007. It's starting to become difficult to support. Debian
>> is the only common distro still supporting ARMv4t. While there is
>> still good upstream support in most major packages (e.g. Linux and
>> gcc), we're seeing a growing number of issues. Some packages
>> (e.g. NodeJS) don't support pre-ARMv7 at all any more. Another problem
>> is the lack of direct support for C++11 atomics - it's possible to use
>> a kernel helper to cover for this lack, but performance will be
>> terrible.
>>
>> Possible future options for armel:
>>
>> * Partial armel architecture?
>>
>>We've talked about this in the past for various architectures, but
>>nobody has stepped up to work on it. The vast majority of the
>>outstanding armel use cases are going to be in headless servers so
>>we could maybe drop the desktop tasks and dependencies and keep
>>things like web server / mail server tasks that are much simpler.
>>
>>Downside: There's no clear plan for how to create/maintain a
>>partial architecture, let alone how to release one. Potentially
>>huge amount of work needed.
>>
>> * Update to ARMv5t (and maybe go headless)
>>
>>We might be able to extend the life of armel by upping the minimum
>>spec, and would be able to continue supporting Kirkwood and Orion
>>based machines (e.g. NAS boxes) for a while longer. This would kill
>>support for v4t devices like Openmoko, but there are precious few
>>of these older devices still around.
>
>Dropping v4t devices seems won't cause big problem, as you said
>there's few devices around currently. So I personally prefer this
>option.
AFAIK there are potentially still similar problems with ARMv5 - lack
of architcture-defined barrier primitives for C++11 atomics to
work. (I'd love to be corrected on this if people know better!) This
is one of the key points here. More and more software is expecting to
use these primitives, and a lack of them is a major problem. To
demonstrate using gcc, you can see that lock-free atomics only started
appearing in ARMv6 and were improved in ARMv7:
$ for arch in 4 5 6 7-a; do echo ARMv${arch}; echo | g++ -march=armv${arch} -dM
-E - | grep -i lock_free; done
ARMv4
#define __GCC_ATOMIC_CHAR_LOCK_FREE 1
#define __GCC_ATOMIC_CHAR32_T_LOCK_FREE 1
#define __GCC_ATOMIC_BOOL_LOCK_FREE 1
#define __GCC_ATOMIC_POINTER_LOCK_FREE 1
#define __GCC_ATOMIC_INT_LOCK_FREE 1
#define __GCC_ATOMIC_WCHAR_T_LOCK_FREE 1
#define __GCC_ATOMIC_LONG_LOCK_FREE 1
#define __GCC_ATOMIC_CHAR16_T_LOCK_FREE 1
#define __GCC_ATOMIC_LLONG_LOCK_FREE 1
#define __GCC_ATOMIC_SHORT_LOCK_FREE 1
ARMv5
#define __GCC_ATOMIC_CHAR_LOCK_FREE 1
#define __GCC_ATOMIC_CHAR32_T_LOCK_FREE 1
#define __GCC_ATOMIC_BOOL_LOCK_FREE 1
#define __GCC_ATOMIC_POINTER_LOCK_FREE 1
#define __GCC_ATOMIC_INT_LOCK_FREE 1
#define __GCC_ATOMIC_WCHAR_T_LOCK_FREE 1
#define __GCC_ATOMIC_LONG_LOCK_FREE 1
#define __GCC_ATOMIC_CHAR16_T_LOCK_FREE 1
#define __GCC_ATOMIC_LLONG_LOCK_FREE 1
#define __GCC_ATOMIC_SHORT_LOCK_FREE 1
ARMv6
#define __GCC_ATOMIC_CHAR_LOCK_FREE 1
#define __GCC_ATOMIC_CHAR32_T_LOCK_FREE 2
#define __GCC_ATOMIC_BOOL_LOCK_FREE 1
#define __GCC_ATOMIC_POINTER_LOCK_FREE 2
#define __GCC_ATOMIC_INT_LOCK_FREE 2
#define __GCC_ATOMIC_WCHAR_T_LOCK_FREE 2
#define __GCC_ATOMIC_LONG_LOCK_FREE 2
#define __GCC_ATOMIC_CHAR16_T_LOCK_FREE 1
#define __GCC_ATOMIC_LLONG_LOCK_FREE 1
#define __GCC_ATOMIC_SHORT_LOCK_FREE 1
ARMv7-a
#define __GCC_ATOMIC_CHAR_LOCK_FREE 2
#define __GCC_ATOMIC_CHAR32_T_LOCK_FREE 2
#define __GCC_ATOMIC_BOOL_LOCK_FREE 2
#define __GCC_ATOMIC_POINTER_LOCK_FREE 2
#define __GCC_ATOMIC_INT_LOCK_FREE 2
#define __GCC_ATOMIC_WCHAR_T_LOCK_FREE 2
#define __GCC_ATOMIC_LONG_LOCK_FREE 2
#define __GCC_ATOMIC_CHAR16_T_LOCK_FREE 2
#define __GCC_ATOMIC_LLONG_LOCK_FREE 2
#define __GCC_ATOMIC_SHORT_LOCK_FREE 2
There are kernel helper
Re: Please give back prometheus on armel
On Thu, Nov 24, 2016 at 11:03:22AM +0100, Emilio Pozuelo Monfort wrote: >On 24/11/16 05:37, Martín Ferrari wrote: >> On 23/11/16 19:13, Emilio Pozuelo Monfort wrote: >> >>>> prometheus 1.2.3+ds2-2 failed to build on armel, but I am not being able >>>> to reproduce this failure in porter boxes. Can you please trigger a >>>> rebuild to see if it was a transient problem? >> >>> Given back. >> >> Thanks! >> >> Now I have a problem, that maybe somebody can help with... The build >> failed again on armel[0], but I still can't reproduce this. >> >> I have just tried on abel. I created a sid chroot, and rebuild from the >> source present in the archive. I checked all the build-dependencies, and >> version numbers match exactly. >> >> But in abel the tests run just fine. Is there any significant difference >> with the armel buildds? I have the same failure both in henze and antheli. > >Hardware wise, they look similar: > >https://db.debian.org/machines.cgi?host=abel >https://db.debian.org/machines.cgi?host=henze >https://db.debian.org/machines.cgi?host=antheil > >henze is an armhf buildd that also builds armel, but antheil is an armel >buildd, >like abel, so that seems fine. Correct - they're exactly the same hardware, using the same kernel etc. The only difference is that some of these are using an armhf rootfs and some an armel rootfs (which is just an accident of history). A buildd running inside a chroot should be just the same on all these machines... -- Steve McIntyre, Cambridge, UK.st...@einval.com "Yes, of course duct tape works in a near-vacuum. Duct tape works anywhere. Duct tape is magic and should be worshipped." -― Andy Weir, "The Martian"
Re: Daily d-i builds fail on armhf and armel with segfault in mklibs
On Thu, Sep 08, 2016 at 10:41:14PM +0200, Karsten Merker wrote: >Hello everybody, > >since 2016-09-05, the daily d-i builds on armhf and armel are >incomplete. The builds fail in the library reduction step with a >segfault during the mklibs run: > >-8<--8<--8<--8<--8<--8<- >mklibs-copy --ldlib=/lib/ld-linux-armhf.so.3 -L ./tmp/hd-media/tree/usr/lib -L >./tmp/hd-media/tree/usr/lib/arm-linux-gnueabihf \ >-L ./tmp/hd-media/udeblibs -v -d ./tmp/hd-media/tree/lib > --root=./tmp/hd-media/tree \ >-L ./tmp/hd-media/tree/usr/lib/cdebconf/frontend \ >-ltext.so -lnewt.so \ >`find ./tmp/hd-media -type f -a \( -perm /0111 -o -name '*.so' -o > -name '*.so.*' \) | \ > grep -v udeblibs | grep -v 'usr/lib/xorg/modules/.*\.so'` >INFO: Using /lib/ld-linux-armhf.so.3 as dynamic linker >Segmentation fault >Command failed with status 139 : mklibs-readelf -R >./tmp/hd-media/tree/sbin/blkid >-8<--8<--8<--8<--8<--8<- > >I probably won't have time to look into this before next week, >but perhaps somebody else has some time to spare for debugging >this? I can reproduce the problem locally, so it's not something >related to the hardware of the buildhost. AFAICS it's also failing on i386, so it's not arch specific: https://d-i.debian.org/daily-images/i386/daily/build_cdrom_gtk.log ... # HACK ALERT: X.Org modules are excluded from the scan as mklibs # is unable to find symbols provided by the /usr/bin/Xorg binary mklibs-copy -L ./tmp/cdrom_gtk/tree/usr/lib -L ./tmp/cdrom_gtk/tree/usr/lib/i386-linux-gnu \ -L ./tmp/cdrom_gtk/udeblibs -v -d ./tmp/cdrom_gtk/tree/lib --root=./tmp/cdrom_gtk/tree \ -L ./tmp/cdrom_gtk/tree/usr/lib/cdebconf/frontend \ -ltext.so -lgtk.so -lnewt.so \ `find ./tmp/cdrom_gtk -type f -a \( -perm /0111 -o -name '*.so' -o -name '*.so.*' \) | \ grep -v udeblibs | grep -v 'usr/lib/xorg/modules/.*\.so'` INFO: Using /lib/ld-linux.so.2 as dynamic linker Segmentation fault Command failed with status 139 : mklibs-readelf -R ./tmp/cdrom_gtk/tree/sbin/blkid ... -- Steve McIntyre, Cambridge, UK.st...@einval.com "The problem with defending the purity of the English language is that English is about as pure as a cribhouse whore. We don't just borrow words; on occasion, English has pursued other languages down alleyways to beat them unconscious and rifle their pockets for new vocabulary." -- James D. Nicoll
Re: Thinking about a "jessie and a half" release
On Tue, Sep 06, 2016 at 11:27:49PM -0400, Jeffrey Walton wrote: >> There's something I've been pondering for a while, along with some >> other folks - it might be useful to do a "jessie and a half" release, >> similarly to what we did in the etch days. That's *basically* just >> like a normal jessie release, but with a few key updates: >> >> * backports kernel >> * rebuilt d-i to match that kernel >> * X drivers >> * ... (other things that might be needed for consistency) >> >> all rolled up with a small installer image build (netinst, maybe DVD#1). >> >> A lot of arm64 machine users would benefit from this, and maybe owners >> of very recent amd64 machines too, with better support for things on >> the Skylake platform. Those are the only two architectures I'm >> thinking of supporting at this point. >> >> Is anybody else interested in helping? Thoughts/comments? > >Sorry to bump an old thread > >Please consider moving to Clang 3.8 or 4.0 as the LLVM front end for >the platform. > >Clang 3.5 and 3.6 are no longer maintained. The bugs we are >discovering and reporting are being closed as "invalid" and "won't >fix" because Clang is outside its freshness date. > >Also pick up this for glibc: >http://stackoverflow.com/questions/17775390/clang-3-3-in-c1y-mode-cannot-parse-cstdio-header/17776548#17776548 >. Though it was first seen in Clang 3.3, its still a problem today. ACK, thanks for thinking about this still. Progress to date has been quiet, but work is ongoing. KiBi has a good set of patches ready for d-i already, and I'm working on debian-cd to add useful backports support. My first quick-hack attempt failed dismally, so I'm midway down a more disruptive but thorough set of changes now. Once that's working, I'll ask on -devel again for package lists. -- Steve McIntyre, Cambridge, UK.st...@einval.com "I used to be the first kid on the block wanting a cranial implant, now I want to be the first with a cranial firewall. " -- Charlie Stross
Re: Porter roll call for Debian Stretch
On Wed, Aug 17, 2016 at 10:05:06PM +0200, ni...@thykier.net wrote: > > * Which architectures are you committing to be an active porter for? > * Please describe recent relevant porter contributions. > * Are you running/using Debian testing or sid on said port(s)? > * Are you testing/patching d-i for the port(s)? > * If we were to enable -fPIE/-pie by default in GCC-6, should that change > also apply to this port? [0] > >Feel free to use the following template as your reply: Hi Niels, I'm a porter for armel, armhf and arm64. For all 3 architectures, I host and maintain buildds, work on d-i and installation support, work on core arch-specific things like toolchain and glibc and I triage and fix other bugs. I'm a DD. In terms of -fPIE/-pie, I'm happt that we are ready to enable by default. I've checked with the gcc maintainers in ARM too, and the worst effect we expect is a small performance impact. If anything more crops up, we have expert help available. -- Steve McIntyre, Cambridge, UK.st...@einval.com "Because heaters aren't purple!" -- Catherine Pitt signature.asc Description: Digital signature
Re: Summary of the ARM ports BoF at DC16
On Thu, Aug 11, 2016 at 11:47:12AM +, Riku Voipio wrote: >On Fri, Jul 22, 2016 at 02:36:05AM +0100, Steve McIntyre wrote: >> armhf >> = >> Current port, first released with Wheezy. Due to cross-distro effort, >> this setup (ARMv7 EABI using VFPv3D-16) is the default supported >> 32-bit ARM architecture in all distros now. We've got a couple of >> kernel variants that will support just about any new devices shipping, >> given updated drivers and device tree support. > >One issue with armhf is NEON support. Currently we support NEON as long >upstreams provide a runtime mechanism to use it. There are however a >couple of issues here > >- Some upstreams (chromium) do neon compile-time or require neon to > work at all (rustc) >- The amount of non-NEON armv7 hw is very minimal (dove, tragra2, ?), so > majority of armhf users have less performance than they could >- None of the armhf buildd's have NEON support, so no NEON code can be > run build-time (testuites etc) > >Once the next armhf buildd upgrade comes around (preferrably in form of >armhf vm's running on arm64 servers), I think we should discuss make NEON a >requirement for armhf. I disagree strongly, for multiple reasons: * there are a non-negligible number of non-NEON ARMv7 machines in the wild * we spent a very long time agreeing across the distros on the spec for armhf, and I don't want to lose the cross-distro binary compatibility that we fought for * I don't think that moving the ABI is a valid thing to do for the sake of some upstreams doing the wrong/lazy thing. -- Steve McIntyre, Cambridge, UK.st...@einval.com Is there anybody out there?
