Re: Debian Bookworm+ on Cavium ThunderX?

On Wed, Apr 17, 2024 at 04:37:50PM +0200, Steffen Grunewald wrote: > On Mon, 2024-04-15 at 14:55:06 +0800, Paul Wise wrote: > > On Fri, 2024-04-12 at 09:28 +0200, Steffen Grunewald wrote: > > > > > Any attempt to boot a Bullseye (5.x) or Bookworm kernel (6.x) resulted in > > > an early kernel

Re: Raspberry PI 5

On Tue, Mar 05, 2024 at 02:31:57PM +0100, John Danielsson wrote: > Dear Debian Team, > > I am writing this mail to get some help for Raspberry PI 5. > I have bought a Raspberry PI 5 recently and I am not able to find a working > Debian image for it. Raspberry 4 and previous models are supported

Re: Removing dpkg arch definition for arm64ilp32?

On Sat, Nov 11, 2023 at 06:57:39PM +0100, Guillem Jover wrote: > 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

Re: Bug#1054583: dpkg-dev: really enable -fstack-clash-protection on armhf/armel

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

Re: Bug#1029843: live-boot: Devices Requiring Firmware: multiple requested files in single line overlapping / special characters

On Tue, May 09, 2023 at 12:22:02AM +0100, Pete Batard wrote: > Interesting; TIL. > > I guess I'm probably not the only person who thought DT was something that > was only cooked recently by Linux kernel maintainers, since that's when it > became mainstream for the majority of the x86/PC based

Re: Bug#1029843: live-boot: Devices Requiring Firmware: multiple requested files in single line overlapping / special characters

On Mon, May 08, 2023 at 06:16:52PM +0100, Pete Batard wrote: > Plus, UEFI has an official standard, and standards are (for the most part) a > good thing. IEEE-1275 is a standard too. > However, with what I have mentioned initially and the weight that Microsoft > has, the only way you're going to

Re: Looking for an armhf install image

On Sun, Apr 02, 2023 at 09:51:23PM -0400, Alan Corey wrote: > I know I can but it will be twice as slow, which is why I want armhf. > Under 64 bit both the data and pointers will be twice as big. With > unlimited memory that would be OK but a Pi CPU can only access 1 GB. > I've tried 64 bit.

Re: latency test results for armhf vs arm64?

On Sat, Jul 16, 2022 at 08:35:26PM +0200, Diederik de Haas wrote: > Raspbian(.org) was created by Peter Green (plugwash) (and Mike Thompson who's > name is still attached to raspbian(.org)'s GPG key, but otherwise moved on) > precisely because the RPi 1 did not meet the armhf/armv7

Re: latency test results for armhf vs arm64?

On Sat, Jul 16, 2022 at 12:19:31PM -0400, gene heskett wrote: > raspian/raspios is available in all 3 flavors. Oh right they do have the other ones, they are just not the ones they recommend by default. > True, but when those two seagate 2T drives puked in quick succession, I lost > all > my

Re: latency test results for armhf vs arm64?

On Sat, Jul 16, 2022 at 08:41:07AM -0400, gene heskett wrote: > I wish you would admit that the raspios I am running IS armhf (kernel7l) > I've no clue where you got the impression it was v6. It is not. You said raspios which sure looks like raspian. Raspian/Raspberry Pi OS is armv6. If you are

Re: armhf kernels on arm64 hardware

On Fri, Jul 15, 2022 at 09:46:59PM +0200, Arnd Bergmann wrote: > It is generally possible to run 32-bit kernels on 64-bit hardware on x86, > some armv8 and mips, but there are a lot of downsides. On powerpc, > sparc, riscv, and newer armv8/v9, one has to run a 64-bit kernel. > > Traditionally

Re: armhf kernels on arm64 hardware

On Fri, Jul 15, 2022 at 05:13:33PM +0100, Wookey wrote: > Ah thanks Paul. I was wondering why we were being accused of 'Debian > abandonning armhf' when it was news to me, and I'm just writing the > 'ARM ports status' talk for Debconf next week. > > Clearly one normally does not run foreign-arch

Re: armhf: abel.d.o hardware status ?

On Thu, Jun 30, 2022 at 08:28:42AM +0200, Mathieu Malaterre wrote: > If I compare gcc-10 vs gcc-11 I see: > > malat@abel ~ % gcc-10 --verbose > Using built-in specs. > COLLECT_GCC=gcc-10 > COLLECT_LTO_WRAPPER=/usr/lib/gcc/arm-linux-gnueabihf/10/lto-wrapper > Target: arm-linux-gnueabihf >

Re: Using a serial port

On Sat, Jun 18, 2022 at 04:59:24PM +, Andrew M.A. Cater wrote: > The "developers" who made the image for Debian: fundamentally Gunnar Wolf > who is an excellent Debian developer - expert and of very long standing - > who has done a large amount of work. You might find others who could help >

Re: Using a serial port

On Fri, Jun 17, 2022 at 06:45:02PM -0500, Steve Fatula wrote: > Is there anyway to get an attached serial port working on Debian and > raspberry PI 4? It appears the tested installs want to use it as a serial > console, I do not. I want to use UART1, the PL011, as an RS232 port to a > projector. >

Re: uboot@qnap - debian

On Sat, Feb 12, 2022 at 10:14:19AM -0500, Philippe Clérié wrote: > My apologies for the confusion. *Pi OS* here was meant as a shortcut for the > *official* distribution of Debian for the Raspberry Pi. Which I am using by > the way. The pi is just one of the systems you can run Debian on. armel

Re: armhf: neon instruction ?

On Mon, Jan 10, 2022 at 03:49:56PM +0100, Mathieu Malaterre wrote: > Dear arm porters, > > Could someone please clarify if I can build a package using gcc flags such as: > > -march=armv7-a -mfpu=neon-vfpv4 -mfloat-abi=hard -mfp16-format=ieee > > Ref: > > * >

Re: reject dhclient offer from wrong subnet

On Wed, Dec 15, 2021 at 04:26:42PM +0100, Tuxo wrote: > Hi list > > My router and my docsys modem power on at the same time. the modem is > handing out dhcp offers of 192.168.100/24 . I assume they are meant for > internal set up purposes and dhclient on my router should not catch or > respond to

Re: armv8 does not respect personality ADDR_LIMIT_3GB

On Wed, Oct 06, 2021 at 02:08:49PM -0400, Camm Maguire wrote: > Greetings, and thanks for your reply > > On Tue, 5 Oct 2021 15:01:59 -0400, Len Sorensen wrote: > > >>From what I could find, some programs allocate their own stack early in > >execution and can hence put it where they want which I

Re: armv8 does not respect personality ADDR_LIMIT_3GB

On Tue, Oct 05, 2021 at 04:17:51PM -0400, Jeffrey Walton wrote: > On Tue, Oct 5, 2021 at 4:00 PM Lennart Sorensen > wrote: > > > > ... > > This fixnum idea in gcl is broken. It must go away. Pointers are for > > addresses and nothing else. > > +1. Tagg

Re: armv8 does not respect personality ADDR_LIMIT_3GB

On Tue, Oct 05, 2021 at 03:23:53PM -0400, Camm Maguire wrote: > Greetings! > > Fair enough, but *Debian* ships a given compiled kernel fixing this > parameter, no? That is the target for the distribution and > apps/packages. Users compiling their own kernel can expect > incompatibilities.

Re: armv8 does not respect personality ADDR_LIMIT_3GB

On Tue, Oct 05, 2021 at 01:37:49PM -0400, Camm Maguire wrote: > Greetings, and thank you so much for your very detailed, clear, and > comprehensive reply! > > PER_LINUX_32GB and/or a userspace interface to set the address space > layout would be nice, but my chief concern is that whatever the

Re: Debian on Pine64 H64B?

On Tue, Sep 21, 2021 at 04:52:15PM -0400, Gene Heskett wrote: > bookmarked, that will take some study to grok how that works. Is there a > minimum kernel version? It appears it has been around for many years. Of course features have been added over time. -- Len Sorensen

Re: Debian on Pine64 H64B?

On Tue, Sep 21, 2021 at 11:36:51AM -0400, Gene Heskett wrote: > Humph, idea borrowed from the Z-80 of the very late 70's, or possibly > from the TI 9900's, which had no registers, all in memory and it changed > context by resetting the index counter to a different address for a new > set of

Re: Debian on Pine64 H64B?

On Tue, Sep 21, 2021 at 05:00:12AM -0400, Gene Heskett wrote: > No, in fact disabling that is a bios setting done before even installing > LinuxCNC. It may make winderz seem to be better, but that context > switch, done by the relatively slow bios memory is a performance killer > even if the

Re: Debian on Pine64 H64B?

On Mon, Sep 13, 2021 at 03:35:44PM -0400, Lennart Sorensen wrote: > They are not commands. They are make targets in the linux kernel source. > So no man pages. So just like you can do 'make menuconfig' you can do > 'make bindeb-pkg' once you have done the config. > > The linux

Re: Debian on Pine64 H64B?

On Fri, Sep 10, 2021 at 01:04:30PM -0400, Gene Heskett wrote: > The beaglebone is for little bitty machines with barely enough hardware > to qualify as a cnc driver, a raspi4b can run circles around it while > browsing the web with firefox, I have done it on that pi4b. The arm side of the

Re: Debian on Pine64 H64B?

On Mon, Sep 13, 2021 at 02:52:02PM -0400, Gene Heskett wrote: > And that link has a link to what I wanted to do, but its about 1.5 major > versions of the kernel out of date. It is for the basic 4.3, and I'm > already on an rt-preempt 4.19. Nothing earlier supports the pi's native > video, so

Re: Debian on Pine64 H64B?

On Fri, Sep 10, 2021 at 01:17:02PM -0400, Gene Heskett wrote: > I am not aware that it ever existed. So I install the needed meat to make > it work, via a card reader and the non-compressed tarball is just under > 30 megs. apt sees it, leaves it alone. So its pinned 6 other packages > for about

Re: Debian on Pine64 H64B?

On Fri, Sep 10, 2021 at 12:04:56PM -0400, Gene Heskett wrote: > I knew that Reco, but the howto install after building it is the best > kept secret on this ball of rock and water, so I invented my own > installer. The revelant files total under 30 megs as a tarball. > > So why do we not have a

Re: Feedback from the community -> ARM

On Thu, Jun 10, 2021 at 07:43:38PM +, Andrew M.A. Cater wrote: > Just get _someone_ to make a good quality 64 bit server which doesn't cost > the earth and works well with UEFI and relatively standard interfaces > and components. > > AMD were doing this n years ago but the devices never got

Re: OT: Huge Right to Repair Win for Consumers

On Thu, Jun 10, 2021 at 06:53:57AM +0200, John Paul Adrian Glaubitz wrote: > So, why should laws protect the intellectual property of software companies > but not the IP of hardware companies? Ideally it shouldn't. > What supporters euphemistically call a "right to repair" is in reality an >

Re: 20210210_raspi_4_buster.img - howto boot in graphics mode

On Tue, Feb 23, 2021 at 06:00:03PM +0100, martin wrote: > This morning I downloaded this image 20210210_raspi_4_buster.img from > https://raspi.debian.net/verified/ and installed it on a sdcard. All looks > well in console mode, so I installed KDE and did run adduser to create a > normal user. But

Re: Porter roll call for Debian Bullseye

On Tue, Dec 08, 2020 at 09:53:11PM +0100, Arnd Bergmann wrote: > I wonder if this is something we should address in the kernel, and make > the behavior in compat mode resemble native 32-bit kernels more closely. > > I think in general we should give as much incentive as possible for > using

Re: Porter roll call for Debian Bullseye

On Tue, Dec 08, 2020 at 08:41:07PM +0100, basti wrote: > My arm hardware a only some raspi4 and 2 QNAP TS-219 behind a vDSL line. > Not the best, but can be used if needed. > One Pi can connect to dataceter. > > If it can be cross-compiled, perhaps I can share a dedicated quad-core > xeon, 64 GB

Re: Porter roll call for Debian Bullseye

On Tue, Dec 08, 2020 at 09:21:42AM +0100, basti wrote: > Hello Adrian, > > How can I help to get bullseye on armel? My impression was that the biggest problem for armel and armhf is the lack of reliable build machines. Not sure if any of the 64 bit arm servers are suitable for building armel or

Re: Is there any "easy to use" arm64 laptop

On Thu, Oct 15, 2020 at 06:48:23PM +0200, Andreas Tille wrote: > Hi, > > On Thu, Oct 15, 2020 at 06:31:07PM +0200, Robert Wilkinson wrote: > > I agree with David. I do think it a bit rude. > > May be you might like to check whom you call rude first. I'm running > some list statistics[1] where

Re: [Help] Re: Bug#969552: phipack: arm64 autopkgtest failure: ERROR: Illegal state encountered: �

On Tue, Sep 08, 2020 at 05:35:45PM -0400, Lennart Sorensen wrote: > On Tue, Sep 08, 2020 at 10:35:26PM +0200, Andreas Tille wrote: > > Control: tags -1 help > > > > Hi Debian Arm team, > > > > I admit I have no idea how to deal with this except by excluding >

Re: [Help] Re: Bug#969552: phipack: arm64 autopkgtest failure: ERROR: Illegal state encountered: �

On Tue, Sep 08, 2020 at 10:35:26PM +0200, Andreas Tille wrote: > Control: tags -1 help > > Hi Debian Arm team, > > I admit I have no idea how to deal with this except by excluding > arm64 from the list of supported architectures which is definitely > not my prefered way of action. > > Any help

Re: The state of Arm64 on Raspberry Pi (and its Documentation

On Thu, Apr 16, 2020 at 04:15:00PM -0500, Nate Bargmann wrote: > It does seem strange to install the 'amd64' distro on my Intel Core > boxes. As I was aware of the history behind the name it made sense. > x86_64 is a bit more difficult to type but seems less ambiguous. Oh > well. Too bad it has

Re: The state of Arm64 on Raspberry Pi (and its Documentation

On Thu, Apr 16, 2020 at 07:58:29PM +0200, deloptes wrote: > I think this is the answer > https://wiki.debian.org/Arm64Port#Nomenclature_and_defines > > If your package does architecture-specific things explicitly then you will > need to understand what names to use in tests. > > The gnu name for

Re: ARC rebootstrap prereq (was Re: switching ARC to 64-bit time_t )

On Thu, Mar 26, 2020 at 03:28:36PM +0100, Helmut Grohne wrote: > One part of the question here is "why do we need libatomic-ops?". The > answer to that is, because libgc uses it and libgc is used by e.g. gcc, > gnutls, guile, and make. Possibly, some of these could be built without > libgc, but

Re: Y2038 - best way forward in Debian?

On Tue, Feb 04, 2020 at 09:38:46AM -0500, Stefan Monnier wrote: > > * 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*

Re: arm64-net-install buster 10.2

On Mon, Feb 03, 2020 at 01:50:25PM -0500, Gene Heskett wrote: > I have no "leveerage" with raspbian. They officially have zero support > for a realtime kernel. 4 posts to their forum in threads related, over4 > days have not elicited a reply from anyone. > > I have no problems building kernels

Re: arm64-net-install buster 10.2

On Mon, Feb 03, 2020 at 10:41:17AM -0500, Gene Heskett wrote: > Written to a 64GB card with dd, makes zero attempt to boot on rp4b. > > Put presently running raspbian buster 10.2 card back in, boots up normal. > > Suggestions? According to https://wiki.debian.org/RaspberryPi there is no support

Re: heatsink -- was [Re: Raspberry Pi 4 is announced]

On Fri, Jun 28, 2019 at 08:54:39PM -0400, Alan Corey wrote: > I welcome the 4 GB of RAM the most, I use 2 swap files and get tired > of waiting for swapping and unswapping. Hopefully the ethernet is no > longer tied to the USB. I suspect it is, but since there is now USB3 at least gigabit

Re: heatsink -- was [Re: Raspberry Pi 4 is announced]

On Fri, Jun 28, 2019 at 01:50:02PM -0700, Rick Thomas wrote: > So when I buy one of these in a couple of months, do I need to buy the > heatsink too? Will the heatsink fit into the standard case? If not, is > there a case that will fit? > > And, finally, is there a version of Debian that will

Re: vmlinuz-4.9.0-8-armmp-lpae pkg install fails due to /usr/bin/linux-update-symlinks

On Tue, Jan 22, 2019 at 09:59:08PM -0500, Dennis Clarke wrote: > well darn ! > > root@arm7:/boot# mount -v > /dev/mmcblk0p2 on / type ext4 (rw,relatime,data=ordered) > devtmpfs on /dev type devtmpfs > (rw,relatime,size=1021496k,nr_inodes=187164,mode=755) > sysfs on /sys type sysfs

Re: Stretch ARM installation RAM and Flash size

On Tue, Jan 15, 2019 at 07:53:34AM +1100, hh h wrote: > "Sure. If I had a heavily restricted system, I would look at LEDE > a.k.a. OpenWRT." > > That'll be my last resource, it is so easy to build my source code in > Debian than in OpenWRT which wrapped the native Linux build system > into its

Re: Stretch ARM installation RAM and Flash size

On Mon, Jan 14, 2019 at 07:26:52PM +0100, W. Martin Borgert wrote: > We're working on an embedded system, which I'm just upgrading to buster. > It eats ~ 180..190 MiB. We dpkg-exclude /usr/share/doc/ and some more, > which are not needed there. > > Also, we use not the official Debian archive

Re: Stretch ARM installation RAM and Flash size

On Sat, Jan 12, 2019 at 09:06:04PM +1100, hh h wrote: > Thanks Joonas. It is going to run the C++ program on NXP i.MX-6ULZ > ARMv7, the application is running on about 5MB RAM, I think RAM > looks fine. The boost and other C++ system libraries about 6 MB, the > program self is not too large,

Re: rock64, date is UTC, how to make EST (s/b UTC-5)

On Mon, Jul 23, 2018 at 06:53:36PM -0400, Gene Heskett wrote: > Do I have to reboot it (the rock64) after makeing everything as above? > Logging out, and back in does not shut the error message off. > > gene@coyote:~$ ssh -Y rock64@rock64 > rock64@rock64's password: > X11 forwarding request

Re: rock64, date is UTC, how to make EST (s/b UTC-5)

On Mon, Jul 23, 2018 at 04:37:48PM -0400, Gene Heskett wrote: > As I keep repeating, x is TOTALLY not available to the common user. I > need to set that up as an auto reply I guess. All the good editors, and > I'm fond of geany, but neither geany, kate nor kwrite are available, > they need x

Re: rock64, date is UTC, how to make EST (s/b UTC-5)

On Mon, Jul 23, 2018 at 07:45:12PM +, Mark Morgan Lloyd wrote: > Sudo's -E option very often helps. Well that still doesn't work because you need the right cookies for X to work. With kdesu or kdesudo or gksudo it does work. -- Len Sorensen

Re: rock64, date is UTC, how to make EST (s/b UTC-5)

On Mon, Jul 23, 2018 at 12:00:19PM -0400, Gene Heskett wrote: > First I am logging in as user 1000, aka pi on the pi and rock64 on the > rock64. Root logins are disallowed. I can sudo later, but can't run > anything that needs x, getting the can't open display :11 or some such > twaddle error.

Re: Cautionary tale: how to kill an SDCard with one simple command

On Sat, Jul 21, 2018 at 09:18:56PM +, Mark Morgan Lloyd wrote: > We've got an ODroid. The impression I got was that the hardware was fairly > well done, but that the distro that came with it (some variant of Ubuntu) > rather less so... the usual things about missing dependencies which can make

Re: Arch qualification for buster: call for DSA, Security, toolchain concerns

On Fri, Jun 29, 2018 at 06:29:48PM +0200, Geert Uytterhoeven wrote: > Are you sure you're not interchanging A8 and A9, cfr. Linux kernel commit > e388b80288aade31 ("ARM: spectre-v2: add Cortex A8 and A15 validation of the > IBE bit")? Yes. That is the main reason the A9 is faster than the A8 at

Re: Arch qualification for buster: call for DSA, Security, toolchain concerns

On Fri, Jun 29, 2018 at 10:20:50AM +0100, Luke Kenneth Casson Leighton wrote: > in addition, arm64 is usually speculative OoO (Cavium ThunderX V1 > being a notable exception) which means it's vulnerable to spectre and > meltdown attacks, whereas 32-bit ARM is exclusively in-order. if you > want

Re: Module aliases etc.

On Sat, Feb 17, 2018 at 12:05:13PM +, Mark Morgan Lloyd wrote: > I'm trying to disentangle some driver issues so that I can backport a module > for a colleague with a weird peripheral. Can anybody tell me what the "b" > field here is, and in particular the significance of the number (3 or 5 in

Re: Anyone using stretch/buster/sid on ARMv4t ?

On Mon, Nov 20, 2017 at 09:37:10AM +, Lars Brinkhoff wrote: > My StrongARM-based Netwinder machine has been lying dormant for a while, > but I was planning to bring it back up. It's ARMv4 without Thumb. Does a netwinder have enough ram these days to run the installer (or much of anything

Re: Why so little info on the Pocket Beagle?

On Tue, Oct 10, 2017 at 12:54:47PM -0500, Robert Nelson wrote: > At-least on the AM57x we have "2D" acceleration working thru the > awesome etnaviv project and the built-in GC320 Vivante 2D core.. That is true. The number of different cores in that chip is hard to keep track of. -- Len

Re: Why so little info on the Pocket Beagle?

On Tue, Oct 10, 2017 at 12:40:28PM -0400, Alan Corey wrote: > I don't get it, so they just released the Pocket Beagle but it uses > old chips they couldn't sell and wanted to get rid of? A lot of what > I'm finding is a few years old. > > Paul said that's PowerVR, we wouldn't find anything. So

Re: Why so little info on the Pocket Beagle?

On Mon, Oct 09, 2017 at 08:36:31PM -0400, Alan Corey wrote: > You mean like > https://community.imgtec.com/downloads/powervr-instruction-set-reference/ > ? Or in wget form > http://cdn.imgtec.com/sdk-documentation/PowerVR+Instruction+Set+Reference.pdf That is for the 6 series, not the 5 series

Re: Why so little info on the Pocket Beagle?

On Tue, Oct 03, 2017 at 05:34:50PM -0400, Alan Corey wrote: > By the Mouser page at > http://www.mouser.com/new/beagleboardorg/pocketbeagle/ it has a > "SGX530 graphics accelerator" so it seems like it must have video. In > my earlier looking around it seems like I ran across the fact that it >

Re: Why so little info on the Pocket Beagle?

On Tue, Oct 03, 2017 at 04:26:55PM -0400, Jeffrey Walton wrote: > According to https://github.com/beagleboard/pocketbeagle/wiki/FAQ, it > looks like you use a web browser; not a monitor. Once you get to the > config screen using the web browser, I'm guessing you can enable SSH. Oh yeah the beagle

Re: Why so little info on the Pocket Beagle?

On Tue, Oct 03, 2017 at 02:59:04PM -0400, Jeffrey Walton wrote: > For your first boot you usually attach a HD monitor and keyboard to > get through the administrivia, like setting a root password and adding > users. Once you setup locally, then you access the gadget through SSH. But how would you

Re: Why so little info on the Pocket Beagle?

On Tue, Oct 03, 2017 at 10:30:16AM -0400, Nigel Sollars wrote: > The CPU is already well documented with beaglebone (all versions ) .. I > would be very surprised if this puppy did not work out of the box. But I see no video, no serial, not networking. How do you talk to it or do you have to

Re: Bug#861281: rnahybrid: FTBFS on armel

On Tue, Sep 26, 2017 at 08:19:59PM +0100, Edmund Grimley Evans wrote: > It's a possibility to bear in mind, definitely, but the > perhaps-infinite loop can be observed with a cross-compiler: > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=876825 I just tried doing the cross compile

Re: Bug#861281: rnahybrid: FTBFS on armel

On Tue, Sep 26, 2017 at 12:21:20PM -0400, Lennart Sorensen wrote: > Here is a patch that removes all the warnings I see. Maybe that will > help. I don't have an armel to test on. > > Most of the warnings are due to missing #include in a lot of places. The failure in build may

Re: Bug#861281: rnahybrid: FTBFS on armel

On Tue, Sep 26, 2017 at 05:48:40PM +0200, Andreas Tille wrote: > Hi Lennart, > > thanks for your suggestions. I hereby will forward it upstream hoping > for comments. Here is a patch that removes all the warnings I see. Maybe that will help. I don't have an armel to test on. Most of the

Re: Bug#861281: rnahybrid: FTBFS on armel

On Tue, Sep 26, 2017 at 09:57:09AM +0100, Edmund Grimley Evans wrote: > The infinite loop is still there with gcc-7. I've created bug #876825. > > Before you exclude armel, you could perhaps try doing something about > this warning, which is given not just on armel and may or may not be > related

Re: Summary of the Arm ports BoF at DC17

On Mon, Sep 18, 2017 at 10:50:39AM +0100, Ian Campbell wrote: > On Mon, 2017-09-18 at 10:15 +0100, Edmund Grimley Evans wrote: > > > But it did remind me that on some platforms writing "2" to > > > /proc/sys/abi/cp15_barrier will enable hw support for these > > > instructions, since some platforms

Re: contemplating conversion of an r-pi3b based system to a rock64

On Mon, Sep 04, 2017 at 12:37:13PM -0400, Gene Heskett wrote: > But unless they are sneaking in under the FCC's radar, which they aren't > else customs would padlock the container, it does have to be an FCC > approved frequency and protocol in order to be able to label it with an > FCC iD # of

Re: contemplating conversion of an r-pi3b based system to a rock64

On Mon, Aug 28, 2017 at 06:31:46AM -0400, Gene Heskett wrote: > But aren't the huge majority of the wireless keyboards and mice just BT > at the core? Max reliable range when the dongles can see the master is > about 20 feet. I put the mouse in the box the pi is in, and had BT do a > scan with

Re: Testing boot loaders

On Wed, Mar 01, 2017 at 04:34:12PM +, Mark Morgan Lloyd wrote: > On 01/03/17 15:00, Lennart Sorensen wrote: > >On Wed, Mar 01, 2017 at 08:57:15AM +, Mark Morgan Lloyd wrote: > >>Yes, I agree. What I don't know yet is whether there's a comparatively > >>

Re: Testing boot loaders

On Tue, Feb 28, 2017 at 07:38:28PM +, Mark Morgan Lloyd wrote: > I wonder whether I could ask a general question, with a particular focus on > Debian ARM devices. > > I've got in front of me a file containing the image of an SD-Card that I've > exfiltrated from a Kobo ereader onto which

Re: missed keystrokes problem, back with a vengeance.

On Sun, Jan 29, 2017 at 01:48:50PM -0500, Gene Heskett wrote: > Alan, ALL of the motor drivers are switchmode, with the current > regulation running at or above 20 KHz. And these noise spikes are > ringing at nominally 100 MHz. I have managed to get the xy motor noise > under control by takeing

Re: xset +dpms is not controlling monitor powerdown on raspberry pi 3b

On Tue, Jan 10, 2017 at 06:43:57PM +, Mark Morgan Lloyd wrote: > I've just managed to rescue a bunch of Logitech compiler manuals (I've > recently had to sacrifice a lot of old stuff) with the hope of at least > getting a photo of their early products into Wp to keep the knowledge alive. > The

Re: xset +dpms is not controlling monitor powerdown on raspberry pi 3b

On Tue, Jan 10, 2017 at 08:17:59AM +, Mark Morgan Lloyd wrote: > On 09/01/17 22:00, Gene Heskett wrote: > >On Monday 09 January 2017 10:52:46 Mark Morgan Lloyd wrote: > > >> > >>Logitech should have stuck to selling compilers. > >> > >Thats a different company I believe. > > Same company, I

Re: debian-installer failure with arm64 (was RE: laxton (softiron) boot failure with Debian linux-image-4.7.0-0.bpo.1-arm64)

On Wed, Jan 04, 2017 at 06:29:07PM +, Ian Jackson wrote: > Lennart Sorensen writes ("Re: debian-installer failure with arm64 (was RE: > laxton (softiron) boot failure with Debian linux-image-4.7.0-0.bpo.1-arm64)"): > > Stretch in the archive currently has a kernel

Re: debian-installer failure with arm64 (was RE: laxton (softiron) boot failure with Debian linux-image-4.7.0-0.bpo.1-arm64)

On Tue, Jan 03, 2017 at 06:48:27PM +, Ian Jackson wrote: > (CCing debian-arm, because I think this is now something related to d-i > on ARML.) > > Hi. I'm writing with my Xen Project hat on. We have two Softiron > ARM64 servers which I am trying to get up and running in our CI > system. >

Re: Unknown QNAP Model

On Wed, Dec 21, 2016 at 01:59:52PM -0800, Martin Michlmayr wrote: > * Jörn Röder [2016-12-21 20:03]: > > i found the incredible looking example/tutorial from Martin > > Michlmayr > > https://www.cyrius.com/debian/kirkwood/qnap/ts-219/install/ and > > would like to flush my

Re: armel after Stretch (was: Summary of the ARM ports BoF at DC16)

On Wed, Dec 14, 2016 at 06:40:22PM +0100, Wouter Verhelst wrote: > On Wed, Dec 07, 2016 at 08:50:40PM +0900, Roger Shimizu wrote: > [...asking for armel to be retained...] > > One way in which the need to keep armel around would be reduced is if we > could somehow upgrade from armel machines to

Re: Samba version in armhf?

On Tue, Nov 22, 2016 at 05:11:08PM +, Jo L wrote: > The problem with 4.2.* is that according to > https://wiki.samba.org/index.php/Samba_Release_Planning#General_information > it is already EOL. And I would prefer a released version, i.e. 4.5.1, 4.4.7 > or 4.3.12 - in that order of preference,

Re: Debian, Qemu, KVM and Raspberry Pi

On Thu, Nov 17, 2016 at 08:21:13AM +, Mark Morgan Lloyd wrote: > I'm obviously watching these ongoing threads with a lot of interest :-) > > If I can ask two questions so that there's a summary in a single place ready > for me to get back onto this: > > * Assuming a host kernel that has

Re: Debian, Qemu, KVM and Raspberry Pi

On Wed, Nov 16, 2016 at 09:09:57AM +0100, Uwe Kleine-König wrote: > AFAIK the RPi3 should be supported by the Debian arm64 kernel. So maybe > the setup is easier there?! Doesn't solve that it needs VGIC emulation, which I highly doubt has gone into the mainline kernel. So KVM would still not be

Re: Debian and QEMU virtio-net-device

On Mon, Nov 14, 2016 at 02:48:24PM -0500, Jerry Stuckle wrote: > I have tried with your command: > > qemu-system-arm -M vexpress-a9 \ > -cpu cortex-a9 \ > -kernel /export/armmp/vmlinuz \ > -initrd /export/armmp/initrd.gz \ > -append

Re: Debian and QEMU virtio-net-device

On Wed, Nov 09, 2016 at 08:18:06AM -0500, Jerry Stuckle wrote: > Hi, Ian, > > Sorry for the delay and not posting to the listserv - my mistake. > > The entire qemu command line is: > > qemu-system-arm -m 1024M \ > -sd /export/armhf.qcow2 \ > -M vexpress-a9 \ > -cpu cortex-a9 \ > -kernel

Re: Debian and QEMU virtio-net-device

On Tue, Nov 08, 2016 at 06:29:38PM +0100, JF Straeten wrote: > Hi, > > On Tue, Nov 08, 2016 at 09:51:37AM -0500, Lennart Sorensen wrote: > > [...] > > > If I don't specify any nic, QEMU supplies a default which is > > > accepted by Debian. However, when I specif

Re: Debian, Qemu, KVM and Raspberry Pi

On Tue, Nov 08, 2016 at 03:01:09PM +, Mark Morgan Lloyd wrote: > I prefer to run pukka Debian rather than Raspbian, approximately as > described at http://sjoerd.luon.net/posts/2015/02/debian-jessie-on-rpi2/ > >

Re: Debian and QEMU virtio-net-device

On Mon, Nov 07, 2016 at 10:57:29PM -0500, Jerry Stuckle wrote: > Hi, all, > > I'm trying to get Debian armhf (jessie) running under qemu-system-arm. > It's working OK except for one point. > > If I don't specify any nic, QEMU supplies a default which is accepted by > Debian. However, when I

Re: Debian on Qnap TS-109

On Tue, Sep 13, 2016 at 01:57:57PM -0400, [ftp83plus] wrote: > I am a bit new to Debian, and when I laid my hands on an older Qnap TS-109, I > decided to install it to overcome Qnap's firmware limitations. I followed the > guide put up by Martin Michlmayr, but currently face three issues: > I

Re: Gigabyte MP30-AR1

On Tue, Sep 13, 2016 at 11:58:30AM +0200, Hector Oron wrote: > However, there is still one more issue when relocating initramfs and that > needs > CONFIG_ARM64_VA_BITS_48=y > but I am told that breaks userland, so it might need to be reverted. Well it "breaks" code that was wrong by design to

Re: Gigabyte MP30-AR1

On Mon, Sep 12, 2016 at 09:33:12PM +0100, Michael Howard wrote: > As mentioned in an earlier post, the debian installer didn't work with the > AR0 board either. Debian are a bit behind the curve on these server boards. Could be interesting to compare the /boot/config file for the ubuntu and

Re: Gigabyte MP30-AR1

On Mon, Sep 12, 2016 at 05:47:34PM +0100, Phil Endecott wrote: > Hector Oron wrote: > >using ACPI boot is recommended, > >however it is not supported until 4.7 kernel series > > I've had a look at what CentOS does: > > [0.00] Booting Linux on physical CPU 0x0 > [0.00]

Re: Gigabyte MP30-AR1

On Mon, Sep 12, 2016 at 02:58:47PM +0100, Phil Endecott wrote: > Hi Hector, > > Thanks for your reply. > > Hector Oron wrote: > >Which BMC firmware are you using? AFAIK there is a broken DTB in the > >manufacturer's firmware > > I replaced the shipped UEFI firmware (version D03 I think) with

Re: Gigabyte MP30-AR1

On Fri, Sep 09, 2016 at 06:29:02PM +0100, Phil Endecott wrote: > Dear Experts, > > I've splashed out and bought myself a Gigabyte MP30-AR1. This is > a "server" board with an Applied Micro X-Gene processor. > > There are various reports of people installing distributions including > Debian on

Re: Broadcom BCM2709, ARMv8, and missing CPU features

On Sat, Aug 06, 2016 at 04:25:13PM +0100, Luke Kenneth Casson Leighton wrote: > did i hear right that there's also a core design difference between > the A7 and the A53 which results in a performance/watt loss of around > 15%? so you're actually *worse off* going to 64-bit at the moment, if >

Re: Broadcom BCM2709, ARMv8, and missing CPU features

On Thu, Jul 28, 2016 at 12:22:23PM -0400, Alan Corey wrote: > Huh? I thought they claimed they were interchangeable. I had an > image from my model B days 3 years ago that I booted on my 3B. And I > cloned a working current 3B SD card and booted a Zero from it. There > isn't a different Debian

Re: Debian on RPi

On Tue, Jul 19, 2016 at 10:07:00PM +, Mark Morgan Lloyd wrote: > Is there still a kernel etc. anywhere for the original Raspberry Pi? I've > got a colleague who's dead set on using the one that we've got as a router > rather than dipping into our stock of 2's and 3's, and while usb_modeswitch

  1   2   3   4   5   >