Re: Debian Bookworm+ on Cavium ThunderX?

[Lennart Sorensen]

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 panic.
> > 
> > Try the latest sid kernel (6.7.9) and the latest upstream too.
> 
> Doing so the Debian way would require a major upgrade of the related tools
> (most notably, gcc), also to build some initrd - something I'd like to avoid
> on the only system with that kind of hardware I have.
> 
> I'll go for some live distros first since I cannot fully exclude "just a 
> missing kernel parameter", and Ubuntu 23.10 seems to be the newest I can
> get hold of. Previous attempts used PXE boot, so kernel parameters might
> be something to look for first.
> 
>   This
> > sounds like something that will need a git bisect to figure out though.
> > https://wiki.debian.org/DebianKernel/GitBisect
> 
> That's the really time-consuming part...
> I'm kind of surprised that nobody else seems to use this hardware platform?

Back when I had a user for such machines, no one would sell you one unless
you were a large cloud provider.  Then I changed jobs and no longer have
any need for it, but at least it seems there is some option to buy them
these days.

Did you check if it has a /boot/config file for the working kernel that
you could compare to see if there were any interesting options it had
enabled that the current debian kernel doesn't?

Of course if support for the CPU was never merged to the mainline kernel,
then you are probably out of luck.

I do see
/usr/lib/linux-image-6.1.0-0.deb11.13-arm64/cavium/thunder-88xx.dtb in
the kernel package, so at least that is promising.  Is the machine using
UEFI or some custom boot method?  I see dtb files in the "BIOS" update,
so I am guessing it isn't UEFI.

It certainly looks like one of the weirder designs, and gigabyte seems
to have stuppod any support 5 years ago.

-- 
Len Sorensen

Re: Raspberry PI 5

[Lennart Sorensen]

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 but PI 5
> is not. Can you please send me a working image ?
> I need urgent help for my Raspberry PI 5.
> 
> Thank you in advance,

Requirements for Debian to support hardware includes upstream support
in the mainline linux kernel.  That hasn't happened yet for the Pi 5.
So that needs to be finished first.  If they hurry up maybe there is a
chance it will be supported in the next Debian release.

Maybe someone has made an image with Debian and a custom kernel for the
Pi 5, but it wouldn't be a supported official thing for sure.

-- 
Len Sorensen

Re: Removing dpkg arch definition for arm64ilp32?

[Lennart Sorensen]

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 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? I'd think that could be a
> good argument to make an exception, and keep this for a while still. I
> see no usage of this arch in Debian Sources files for example, so it'd
> seem safe to remove the arch definition in the Debian context.
> 
> [M] 
> 
> 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.

armeb definitely was used in systems.

Certainly everything I could find about arm64ilp32 seems to indicate it
was experimental and support has been deleted from gcc and libc quite
a long time ago at least as far as I can tell.  I sure can't find the
code in the kernel anymore unless it is well hidden.

-- 
Len Sorensen

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

[Lennart Sorensen]

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.

-- 
Len Sorensen

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

[Lennart Sorensen]

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 end-user crowd.

You are definitely not the only one.  The ability to attach an fdt
devicetree file to the kernel on systems that didn't have openfirmware
to provide the data was a more recent addition, but it was simply taking
advantage of a system that was already present for years.

> Well, the thing is overall units tends to correlate pretty closely to
> overall end-users. And, while one may try to plan for what one expects/hopes
> the end-user landscape to shift towards, one must still strive to create
> software that makes life easier for the current one. In terms of units, ACPI
> has certainly been more widespread, even if it's mostly due to the
> homogeneity of the dominant arch and platform (x86 based PC).

Certainly it is hard to fight against anything Microsoft and Intel have
decided they are going to use.  Neither one seems to care much what
anyone else is doing already.

> > Apple is almost certainly back to devicetree on their arm devices since
> > they used it on their powerpc based systems already in the past.
> 
> If that's the case, then (I'm going to assume that) it's shame Apple didn't
> use their position to join the discussion and provide some opposition to
> Microsoft, when it came to going with ACPI-only for SBBR...

Apple doesn't seem interested in their OS being able to run on anyone
else's hardware or anyone else's OS running on their hardware.  So not
complyoing with standards probably suits them just fine.

> I'd venture to say that there's been a bit of a chicken and egg problem
> there, which SBBR is in part trying to solve, by attempting to remove one of
> the hurdle people face when getting an ARM64 server, i.e. how the heck am I
> going to install my OS/distro of choice on this machine, instead of being
> constrained by whatever custom version of some other OS/distro the
> manufacturer of the platform decided to go with.

Being able to install an OS certainly is handy, although being able to
even buy the hardware is probably the first step.

> I do agree that we're still early in the game here, if game there eventually
> is, which is the *precise* reason why a group of us worked together to
> provide an SBBR implementation on the commonplace and relatively limited Pi
> platforms, i.e. something that is everything but an ARM server, to both
> provide an easy to access working implementation as well as demonstrate to
> ARM64 system manufacturers that, if this can be accomplished for the Pi with
> limited effort, this should certainly be achievable for their platform.

Certainly useful to have a small cheap platform to be able to work on it.
Unfortunate that even a Pi is a bit hard to get a hold of these days.

> 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.

> I'm going to go further than that and say that not even Microsoft
> appears/appeared to care that much about running Windows on ARM systems, as
> we pretty much offered them a golden opportunity to chase a goal they should
> be exceedingly familiar with, and, what's more, one that Apple will never
> challenge them on, namely running their OS on *cheap* commonplace hardware.
> But they pretty much ignored the crowd that was interested in running
> Windows on the Pi, even as Windows 11 21H2 does run very decently on an 8 GB
> Pi 4 and, current hardware price hike notwithstanding, could have gained
> significant traction with the low income masses. This, in turn, could 

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

[Lennart Sorensen]

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 have vendors moving away from ACPI is if
> Microsoft decides to add support for DT in Windows (or something else that
> they see better than ACPI)... which I don't really see happening in the near
> to medium term, since, much to their benefit, Microsoft did manage to get
> the ARM SBBR specs to go with ACPI and thus continue business as usual as
> far as Windows is concerned.
> 
> Again, I am hoping that there was some consideration given by Microsoft and
> other members of the SBBR committee as to whether it made sense to go with
> Device Tree. One of the problems I would see however is that, I doubt the
> Linux folks consulted with Microsoft when they introduced Device Tree (then
> again why and how would they) to see if Microsoft had some interest for
> using it in the long run, and if so, what they could do to make it more
> palatable for Windows usage.

Well devicetree is part of open firmware aka IEEE-1275, from 1994.
ACPI is from 1996.  And of course since I don't think Sun cared at
all what Microsoft thought when they designed the firmware interface,
I don't think that matters.  Since open firmware or at least devicetree
has then ended up used on SPARC, PowerPC, ARM, MIPS, and who knows what
else, while ACPI is x86 and now some ARM but nothing else as far as I
can tell, other than in terms of overall units using it, ACPI certainly
has a lot less interest.

> And that's the old problem of ecosystems being split on OS lines, when it
> would be nice if we could look a bit further than that, with Linuxfolks most
> likely not that eager to ask Microsoft if they have some input on the
> direction they wanted to take when they introduced DT, and, likewise,
> Microsoft unlikely to want to use some "Not Invented Here" technologies like
> DT, even more so when you have the other elephant in the room for the "Not
> Invented Here", i.e. Apple, which seems so adverse to compromising with
> anybody that it provides the worst example to follow such as, using their
> own version of EFI on x86 based hardware rather than UEFI, and then dropping
> that altogether on their ARM based silicon, to now use their own completely
> custom pre OS execution environment. At this stage, I should probably add
> that it's going to be fat chance to ever see Apple use SBBR on their
> hardware even, if on paper, it should have been a perfect target for it and
> sure would have make booting and installing Debian on Apple Silicon
> easier... even if one were to be constrained to use ACPI over DT.

Apple is almost certainly back to devicetree on their arm devices since
they used it on their powerpc based systems already in the past.

> To me, it looks like mostly a question of reducing development cost as well
> as what one can get away with by not going out of their way to try to talk
> and seek compromise with other parties. And, as usual, it's the end-users
> that pay the price by having hardware and OSes that restrict what they
> should be able to do with it, starting with their ability to install the OS
> they prefer on modern ARM64 hardware.
> 
> And that's actually the reason why I think efforts like SBBR should be
> supported, because they are trying to break the status quo, even if it
> appears that Microsoft might have gotten what they wanted at the detriment
> of Linux, and even if Apple are unlikely to ever want to touch SBBR with a
> ten foot pole...

Well unfortunately for years it seems the status quo has also been 64
bit arm servers being annonced, but not able to be purchased anywhere
unless you were google or amazon or some other large cloud provider.
Apparently they didn't actually want to sell their systems.  Then they
complained that there was no market for arm servers.  Maybe it has gotten
better in the last few years, but in my current job having arm servers
is no longer relevant unfortunately.  I sure wanted some 8 or 10 years
ago when they were announcing them but not actually selling them.

> Well supported across architectures: yes.
> Well supported across OSes: Unfortunately no, when you do consider Windows.

Any OS that ever ran on an openfirmware system, which is a lot of them.

> And that is the main issue here. SBBR is not just for Linux, or for Windows.
> So, yes, someone, on the OS side, is likely to have to do extra work, whose
> only purpose will be to allow people to install a completely different OS.
> And yes, that sucks. But if it benefits end-users, it's the price one has to
> pay.

It seems that it benefits only one OS, the one it seems just about no
one cares to run on arm systems.

Doesn't mean that long term ACPI and UEFI might not be better for SBBR.
I highly doubt the decision was made without 

Re: Looking for an armhf install image

[Lennart Sorensen]

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.

It's certainly a balance trade off.  The pointers will be twice as large.
The data will be whatever size the code asked for.  Only in the case that
the code asked to use a long will be be 32 bit in one case and 64 bit
in the other case.  Most code isn't that sloppy about their data types.

In terms of actual code, apparently the A53 core runs 64 bit code about
20% faster than 32 bit code, so it comes down to whether you are doing
execution heavy or data heavy work.

-- 
Len Sorensen

Re: latency test results for armhf vs arm64?

[Lennart Sorensen]

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 qualifications that 
> Debian uses.
> The Raspberry Pi Foundation (RPF) started with (Debian's) armel (armv5) 
> architecture, but that was slow and didn't optimally use the HW that was 
> available on the RPi 1.
> 
> So Plugwash (and Mike) started a recompilation of the Debian archive which 
> makes better use of the HW available in the RPi 1. Confusingly, they labeled 
> it armhf, while it was and is NOT the same as Debian's armhf.
> To add to the confusion, RPF called their OS also Raspbian :-/
> 
> AFAIK it's still Plugwash that runs the buildd which compiles the packages 
> for 
> Raspbian/RaspiOS, but those packages are now also mirrored on RPF servers/
> archives. That is still ~armv6 (+hardfloat+sth IIRC).
> 
> The RPi 2 (and newer) can run Debian's armhf (armv7).
> 
> The RPi 3 and newer can also run arm64 and that is the same as Debian's.
> 
> I am *quite* sure RaspiOS is not available in normal/Debian's armhf, but only 
> in their own armv6+ (but labeled armhf) and arm64.

Yeah looking at raspberrypi.com they seem to have 64 bit and 32 bit
builds.  The 32 bit is definitely armv6 since it says it is compatible
with all versions of the pi.  Pretty sure they have never done armv7
since that would just be what Debian already provides and would break
the Pi 0 and Pi 1 after all although the 2 would be happier.  It shoudl
happily run on a kernel that supports armv7 but it does mean user space
certainly isn't fully taking advantage of what a pi 2 or newer offers.

I certainly only see 2 flavours on the page.  The original armel I don't
think has been made for quite a few years at this point and proper armv7
armhf they have certainly never done either.  So they have 2 flavours:
armv6 and armv8.

-- 
Len Sorensen

Re: latency test results for armhf vs arm64?

[Lennart Sorensen]

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 patched amanda sources. I'd only been running amanda since 1998.
> I figured if bullseye ever stabilizes I might see about starting it up
> again. But UM
> sold it to zmanda so progress stopped, and then was sold to Betsol about 2
> years back, and so far they've been all hat and no cattle. As far as I'm
> concerned its time to look for a new backup strategy that mimics how amanda
> worked. IOW I'm still building this box, almost from scratch. Its been very
> painful
> so far with bullseye.

Yeah loosing multiple drives sucks.

My important stuff sits on a raid6 setup and does automatic off site
(to my parents house) backups using rsnapshot.

-- 
Len Sorensen

Re: latency test results for armhf vs arm64?

[Lennart Sorensen]

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 running Debian armhf, then it is armv7 but it
would be a lot less confusing to call it Debian and not raspios in
that case.

Doesn't matter what your kernel is.  What is your userspace you are
actually running?

> The card its running on right now is over 2 years old, zero problems,
> and has had all updates, including a daily update of linuxcnc from the
> the buildbot, or if the buildbot is down, my own scripts also building
> installable deb's. The secret is use a big enough card that it has enough
> room to do its maintenance. 64G card has around 15G's on it.

Backups once in a while of the card is still nice to have.

-- 
Len Sorensen

Re: armhf kernels on arm64 hardware

[Lennart Sorensen]

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 you'd only have a 64-bit kernel but 32-bit user space, at
> least on powerpc, pa-risc and sparc.
> 
> I think x86 and arm are the odd ones out here, because Debian has
> never shipped a 64-bit kernel packaged as a 32-bit .deb file here,
> though at the moment mipsel is the only one that ships with
> 64-bit kernel by default.

http://snapshot.debian.org/archive/debian/20050312T00Z/pool/main/k/kernel-image-2.6.9-amd64/kernel-image-2.6.9-9-amd64-generic_2.6.9-4_i386.deb

Debian did plenty of them.  It was very commonly used.

-- 
Len Sorensen

Re: armhf kernels on arm64 hardware

[Lennart Sorensen]

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 kernels on hardware so
> we don't have to support it, and Ben is right to say 'this is not a
> bug'.
> 
> On the other hand, if the armhf kernel does work on RPi4 with a few
> config options, and there is an actual use case, then the question is
> what is the downside of enabling the config options?
> 
> Does this only work for the RPi4, or does it enable/prevent 32-bit kernels on 
> other 64-bit machines?

Certainly people have been running 32 bit kernels on the Pi 3 and 4 and
it works fine.  Some high end aarch64 CPUs don't support 32 bit mode,
but that is certainly not the case for the Pi's CPU.

> Do i386 kernels work on amd64 machines?

Yes, but...  They certainly don't work with more than 3.5GB or so of ram
unless you use the pae version of the kernel then you can have some more.
There have been issues in some cases with systems that had too much ram
where rather than just ignoring it the kernel would fail to boot.

Of course it was very common a 15 or 20 years ago to run debian i386 with
an amd64 kernel and was fully supported by debian including the installer
which as far as I remember even recommended that kernel if supported by
the host.  Quite a bit of user space code still had issues with 64 bit,
but you got to run a kernel that could take full advantage of your ram
and other cpu features, while running 32 bit user space (since the amd64
kernel of course can run i386 binaries just fine).

For example this was very much in Debian:
http://snapshot.debian.org/archive/debian/20050312T00Z/pool/main/k/kernel-image-2.6.9-amd64/kernel-image-2.6.9-9-amd64-generic_2.6.9-4_i386.deb

So an amd64 kernel in the i386 archive.

> Sounds like something that might be worth discussion at debconf next week. 
> I'll mention it in the talk.

Well it would essentially mean treating arm like i386 used to be treated.
It is certainly not a thing Debian hasn't supported before.

-- 
Len Sorensen

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

[Lennart Sorensen]

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
> Configured with: ../src/configure -v --with-pkgversion='Debian
> 10.3.0-16' --with-bugurl=file:///usr/share/doc/gcc-10/README.Bugs
> --enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++,m2
> --prefix=/usr --with-gcc-major-version-only --program-suffix=-10
> --program-prefix=arm-linux-gnueabihf- --enable-shared
> --enable-linker-build-id --libexecdir=/usr/lib
> --without-included-gettext --enable-threads=posix --libdir=/usr/lib
> --enable-nls --enable-bootstrap --enable-clocale=gnu
> --enable-libstdcxx-debug --enable-libstdcxx-time=yes
> --with-default-libstdcxx-abi=new --enable-gnu-unique-object
> --disable-libitm --disable-libquadmath --disable-libquadmath-support
> --enable-plugin --enable-default-pie --with-system-zlib
> --enable-libphobos-checking=release --with-target-system-zlib=auto
> --enable-objc-gc=auto --enable-multiarch --disable-sjlj-exceptions
> --with-arch=armv7-a --with-fpu=vfpv3-d16 --with-float=hard
> --with-mode=thumb --disable-werror --enable-checking=release
> --build=arm-linux-gnueabihf --host=arm-linux-gnueabihf
> --target=arm-linux-gnueabihf
> Thread model: posix
> Supported LTO compression algorithms: zlib zstd
> gcc version 10.3.0 (Debian 10.3.0-16)
> 
> while
> 
> malat@abel ~ % gcc-11 --verbose
> Using built-in specs.
> COLLECT_GCC=gcc-11
> COLLECT_LTO_WRAPPER=/usr/lib/gcc/arm-linux-gnueabihf/11/lto-wrapper
> Target: arm-linux-gnueabihf
> Configured with: ../src/configure -v --with-pkgversion='Debian
> 11.3.0-3' --with-bugurl=file:///usr/share/doc/gcc-11/README.Bugs
> --enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++,m2
> --prefix=/usr --with-gcc-major-version-only --program-suffix=-11
> --program-prefix=arm-linux-gnueabihf- --enable-shared
> --enable-linker-build-id --libexecdir=/usr/lib
> --without-included-gettext --enable-threads=posix --libdir=/usr/lib
> --enable-nls --enable-bootstrap --enable-clocale=gnu
> --enable-libstdcxx-debug --enable-libstdcxx-time=yes
> --with-default-libstdcxx-abi=new --enable-gnu-unique-object
> --disable-libitm --disable-libquadmath --disable-libquadmath-support
> --enable-plugin --enable-default-pie --with-system-zlib
> --enable-libphobos-checking=release --with-target-system-zlib=auto
> --enable-objc-gc=auto --enable-multiarch --disable-sjlj-exceptions
> --with-arch=armv7-a+fp --with-float=hard --with-mode=thumb
> --disable-werror --enable-checking=release --build=arm-linux-gnueabihf
> --host=arm-linux-gnueabihf --target=arm-linux-gnueabihf
> Thread model: posix
> Supported LTO compression algorithms: zlib zstd
> gcc version 11.3.0 (Debian 11.3.0-3)
> 
> Could someone confirm, the spec file is accurate for Debian armhf (no
> neon) ? I fail to understand why spec file would be different for us
> (--with-arch=armv7-a --with-fpu=vfpv3-d16 suddenly became
> --with-arch=armv7-a+fp).
> 
> If I read the doc online correctly:
> 
> https://gcc.gnu.org/onlinedocs/gcc/ARM-Options.html
> 
> states:
> 
> -mfpu=name
> [...]
> The setting ‘auto’ is the default and is special. It causes the
> compiler to select the floating-point and Advanced SIMD instructions
> based on the settings of -mcpu and -march.
> 
> In the case of valgrind I can see:
> 
> ` -marm -mcpu=cortex-a8`
> 
> I cannot find in the doc what 'cortex-a8' stands for: neon or not neon ?

Cortex-A8 always has neon as far as I remember.  Cortex-A9 unfortunately
has it optional and of course some non Cortex arm implementations
don't have neon either.  So cortex-a8 is not a valid choice as a generic
arm v7 armhf processor.

-- 
Len Sorensen

Re: Using a serial port

[Lennart Sorensen]

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
> on IRC - OFTC channels #debian-arm and #debian-raspberrypi
> 
> The Raspberry Pi does things its own way and the way the overlays work
> is largely particular to the RPi.

Beaglebone does overlays too.  It is not Pi specific, it is a useful
kernel feature.  Devicetree overlays (and devicetree in general) of course
started on powerpc, so no it is not a Pi thing, the Pi just happens to
be the most common platform that is actually making people realize the
feature exists.  It's only been around for 8 or so years after all.

-- 
Len Sorensen

Re: Using a serial port

[Lennart Sorensen]

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.
> 
> I can do this using Raspberry OS, but, not Debian using the tested installs.
> There is no way to disable Bluetooth via the overlays used on Raspberry OS.
> I can sort of mess around and stop the console from being started on ttyS1,
> but no way to use the port as a serial port to send and received data.
> Apparently the dtoverlays are not there.
> 
> So, is there any way to really use a serial port, attached to any GPIO pins,
> as a real RS232 port using Debian images? if so, what do I need to disable
> or enable?
> 
> As mentioned, had it working on Raspberry OS which is based on Bullseye. But
> unfortunately I can't use Raspberry OS for our usage.

>From what I have read you should be able to enable uart2 through uart5
on the Pi4B using the dts overlays.  I don't have a Pi4 yet so no
experience with doing that unfortunately.

https://forums.raspberrypi.com/viewtopic.php?t=244827 seems to have some
talk about it though.

-- 
Len Sorensen

Re: uboot@qnap - debian

[Lennart Sorensen]

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 being the
only one an armv6 could run since armhf quite sensibly picked armv7 since
there was a lot of those around and very few armv6 systems.  The fact
broadcom decided to put an armv6 into a video chip and someone then
decided to turn that into a system (even though the armv6 was probably
not a great choice for that use case) could not have been predicted.
Adding another arm architecture on top of armel and armhf just because
of the pi would not have made sense and of course the Pi 2 and newer
are all capable of using armhf, so it was only the first Pi that had a
problem (and I must admit I was never interested in the first pi since
to me that was just way too under powered to be useful, while I do have
both a 2 and a 3).

I actually consider it lucky the pi wasn't out when armhf's requirements
were done or we might have ended up with armv6 as the baseline due to
a single system, cripling all the other armv7 boards.

-- 
Len Sorensen

Re: armhf: neon instruction ?

[Lennart Sorensen]

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:
> 
> * 
> https://salsa.debian.org/debian-phototools-team/highway/-/blob/master/CMakeLists.txt#L182-185

Well the debian armhf specification does NOT require neon support,
so packages should not require neon unless it is optional and provided
as runtime detected code or an alternate library to load or whatever
method works.

-- 
Len Sorensen

Re: reject dhclient offer from wrong subnet

[Lennart Sorensen]

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 them. Only the final offer after modem bootup has completed does
> contain the WAN subnet and a lease time of 4 hours.
> 
> Can I configure dhclient on my router to discard lease offers from a certain
> subnet? I could also try to match the lease time, the 192.168.100/24 lease
> time is only several seconds (!!) short, the real one will be 4 hours or
> more and come with a valid WAN subnet mask.
> 
> I never had this problem before, so I don't know how to change dhclient's
> behaviour to a bogus lease offer.
> 
> Maybe iptables could assist and block multicast traffic from/to the wrong
> subnet? I'm not sure I would still get the actual WAN lease then.

Which dhcp client?

if dhclient, the config allows specifying a reject subnet range, so you
could do something like:
reject 192.168.100.0/24

-- 
Len Sorensen

Re: armv8 does not respect personality ADDR_LIMIT_3GB

[Lennart Sorensen]

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 guess would free
> >up some known address space range.  Potentially.  With address space
> 
> Might you please provide an explicit reference for this?

I can't seem to find the page I read, but it seems that you might be
able to use clone() to create a new process with a stack you allocated.
So if you can somehow allocate a stack at a lower address and then
clone() to switch to a process with that stack, and reserve the memory
range you want to abuse, and check that it was able to (after all with
address space randomization it doesn't have to work if you ask for a
specific address), then you could probably get away with things after
that by using that reserved range for the fixnum stuff.  But it would
probably need different handling for 32 and 64 bit machines, and would
have to do this all at runtime of course, since there is no promise of
what size of address space the kernel will give you.  I see arm has 1G,
2G, 3G and possibly others.  What you build on is certainly not any
indication of what you might run on.  If I recall correctly the page I
read was someone trying to do this in virgil.

There really doesn't seem to be any way to ensure you can abuse a
certain range of the address space, beacuse well, you are abusing it.
It's not proper coding and not something linux ever promised you could do.
x86 being one of the first 32/64 bit dual architectures added the 3GB
workaround to help out code while it got fixed up.  But it seems no other
architectures later did the same since it wasn't meant to be a solution,
just a workaround.

I also get the impression in my searching for stuff about this problem,
that 3/4 of the things I find about wanting to do this are gcl related.
I guess it may be the only major offender really left that anyone uses
at all.  Seems everything else either gave up, or actually fixed their
code.

-- 
Len Sorensen

Re: armv8 does not respect personality ADDR_LIMIT_3GB

[Lennart Sorensen]

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. Tagged pointers caused a lot of problems porting some packages to
> Aarch64. Tagged pointers were blocking a number of web related
> packages. It also caused a number of CVEs, like CVE-2020-9391.

And I found this post:

https://lore.kernel.org/lkml/20081006132651.gg3...@one.firstfloor.org/

where Andi Kleen calls the need for ADDR_LIMIT_3GB "a kludge for
bug-to-bug compatibility with old binaries (that is where the 3GB
personality came from to work around bugs in some old JVMs that could
not deal with a full 4GB address space), it shouldn't be really used
for anything new."  And that was 13 years ago.  Seems some code still
isn't fixed.  Not working with a full 4GB address space is considered
a bug and should be treated as such.

-- 
Len Sorensen

Re: armv8 does not respect personality ADDR_LIMIT_3GB

[Lennart Sorensen]

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.

Debian is not just expected to be compatible with packages from the
same release.

This fixnum idea in gcl is broken.  It must go away.  Pointers are for
addresses and nothing else.

-- 
Len Sorensen

Re: armv8 does not respect personality ADDR_LIMIT_3GB

[Lennart Sorensen]

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 kernel
> provides to userspace be the same on all machines purporting to be of
> the same 'architecture'.  On further investigation, it appears that
> 32bit arm(el)(hf) kernels have a 3GB address space, starting the stack
> at 0xbfff, regardless of the PER_LINUX_32GB personality setting, and
> that 32bit compatibility mode on a 64bit kernel provides a 4GB address
> space, starting the stack at 0x, again regardless of
> personality, as you state.  To me it seems that the 64bit kernel, if it
> offers a compatibility mode, should match whatever the contemporaneous
> 32bit kernel behavior is, making this a bug in the compatibility mode.
> 
> Even if this is not deemed a bug, 32bit chroot under 64bit is
> effectively a different architecture at present.  I suggest that
> arm(el)(hf) refer to a genuine 32bit kernel, whatever address space it
> chooses to provide, and that therefore as long as this difference is
> outstanding, some method in buildd be provided to allow packages to
> specify that they should only be built in a 'true' environment.  Might
> this be possible?
> 
> I can put a runtime check in gcl to detect such a mismatch and exit with
> an explanatory message for the (hopefully) unlikely case that some
> non-developer user wants to run these 32bit binaries under a 64bit
> kernel in chroot.
> 
> If/when the 32bit address space goes to 3.75GB, that will necessitate a
> recompile, but as long as consistency is maintained 32bit binaries can
> be distributed and expected to run on machines of the same
> 'architecture'.
> 
> Your thoughts?

Seems to me that gcl is making assumptions that are invalid.  Like
assuming the stack start location at compile time will forever be valid.
Or assuming that there is any address space free above the stack.
I don't think any linux architecture ABI has ever made such a promise.

So it seems to me that gcl is simply wrong and should be rewritten
properly.  Looks like a potentially large job.

>From what I could find, some programs allocate their own stack early in
execution and can hence put it where they want which I guess would free
up some known address space range.  Potentially.  With address space
randomization, can you really ever be sure that there will be a part of
address space that isn't used?  Code really should stop trying to abuse
bits in pointers for their own purposes.  It always ends up breaking no
matter how clever they people that came up with it thought they were at
the time.

-- 
Len Sorensen

Re: Debian on Pine64 H64B?

[Lennart Sorensen]

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?

[Lennart Sorensen]

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 registers. Same idea, different execution but it worked well.

Well those required the software to ask to change the pointer to memory
for the registers.  The hyperthreading just has two sets of registers and
switches between them whenever the other thread stalls (so no delay for
any code to run to do the switch).  But since to the OS it looks like 2
CPUs, the fact that the amount of clock cycles each thread gets to execute
varies, makes to a mess if you are trying to do predicable realtime.
I certainly can't imagine a real time system working right with
hyperthreading enabled.

> But it in 3 examples of the Z-80 in about 1981 while I was coding up an 
> ATS that looked like a transmitter remote control (different FCC rules) 
> only 1 would reliably swap registers when it read an E6 command. I paid 
> for two more as the warranty had expired by the time I discovered it, so 
> in 5 examples, I actually got two that worked. They were about $35/copy 
> at the time. I mistakenly thought it might have been a step up from the 
> first micro-controller I used to make a commercial production tool at a 
> tv station, an RCA 1802.
> 
> That was in 1979-80, and turned out to be so handy they were still using 
> it in 1995. Thats a couple eons in tv station control room gear life. 
> The RCA Just Worked, the Zilog not so much. I've done several other tv 
> production related projects since, never touched a Zilog product again. 
> Very bad aftertaste.
> 
> Motorola's 6809, now the smarter Hitachi 6309, a cmos workalike until we 
> discovered it had more registers than the moto version. A fact that 
> hitachi is still contractually enjoined from ever confirming the 
> existance of, they had permission to clone it, but never saw the moto 
> masks, so they microcoded it, filling up the empty spaces in the 6809 
> mapping. So that was my fav small cpu for 30 years.
> 
> In any event, it sure screws things up in terms of IRQ latency. The other 
> thing we turn off if we can is the SMS stuff, it can throw a several 
> millisecond monkey wrench into the gears if software stepping. Not very 
> often, but will leave its mark (litteraly) on the part being carved at 
> the time. A gear tooth out of position, which since cutting a gear tooth 
> is a repetitive operation, means that tooth may be narrower by .001".
> 
> Another item that impinges on the arm speed is that the arm doesn't have 
> the concept, so we've been told, of "isolcpus", where a cpu core is 
> removed from the schedulers execution pool, and later given the job of 
> handling the irq's. This works well on the wintels, but not as 
> effectively on the AMD stuff.
> 
> My understanding is that you can isolate an arm core but cannot later 
> assign it a task until a powerdown reset is done.  So code that can 
> service an irq on x86-64 in 4 microseconds, can only do it in about 12 
> microseconds on arm because a core to do it on has to be selected and 
> the context switch performed. Fireing up firefox might extend that lag 
> to 200 microseconds, but otherwise the worst case on the rpi4 is around 
> 50 microseconds but it might take several minutes to record that big a 
> lag with the kernel I'm using. That has not been a problem with the work 
> I've done with it.
> 
> Is that understanding correct ?

Well I can find people reporting that 'isolcpus' worked on RPi4, but
that core 0 was an exception and could not be isulated (since it is the
boot CPU and the isolation was done before the other cores were booted
it seemed).  But it also said 'isolcpus' is deprecated and replaced by
'cpusets'

https://www.kernel.org/doc/html/v5.9/admin-guide/cgroup-v1/cpusets.html

-- 
Len Sorensen

Re: Debian on Pine64 H64B?

[Lennart Sorensen]

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 code is stashed in L1 cache. I've 5 i5's of various builds 
> here, and none of them have that enabled even if its not running 
> machinery. This cheap 6 core i5 certainly doesn't need it and its 
> actually running at 800 MHz, but capable of 3.7 GHz. Close to zero heat, 
> all 6 cores are below 32C right now.

The BIOS has nothing to do with context switching.  Hyperthreading doesn't
even do context switching, it has two sets of registers so it can do
free context switching while the other thread is waiting for something.

Hyperthreading's only big problems are that it makes execution speed of
each thread unpredictable and since two threads are sharing a core,
it reduces the performance of single threaded code on that core.

-- 
Len Sorensen

Re: Debian on Pine64 H64B?

[Lennart Sorensen]

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 kernel sources have had the ability to generate debian packages
> for quite a few years now.

~/git-trees/linux> make help|grep deb
  deb-pkg - Build both source and binary deb kernel packages
  bindeb-pkg  - Build only the binary kernel deb package

-- 
Len Sorensen

Re: Debian on Pine64 H64B?

[Lennart Sorensen]

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 beaglebone is certainly not impressive, but the
PRU cores are potentially interesting for driving realtime hardware.
It's what they are for.  Of course they are not arm cores, they use their
own instructions so one would have to write code for a TI proprietary
core that only a small number of processors support.  But it does mean
you have dedicated cores designed for driving hardware without having
to share resources with the main OS.  Certainly the raw arm processing
power of the Pi4 is easier to work with and more portable to other
systems in the future.

-- 
Len Sorensen

Re: Debian on Pine64 H64B?

[Lennart Sorensen]

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 the video you see with a 4.3 is hundreds of milliseconds 
> behind the machine.

It mentions 4.15 as an example and says to change it to the version you
are actually building.

> 5.14-rc1-rt1 was just announced on the rt list
> 
> > That mentions the bindeb-pkg and deb-pkg arguments.  I am not sure
> > what the difference is.
> 
> And I have neither man page. What package contains those?

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 kernel sources have had the ability to generate debian packages
for quite a few years now.

-- 
Len Sorensen

Re: Debian on Pine64 H64B?

[Lennart Sorensen]

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 20 months now.
> 
> Link to how to docs? I ought to check out something newer than 4.19.xx
> 
> Thanks Lennart. Take care & stay well.

Well I found stuff here:

https://wiki.debian.org/BuildADebianKernelPackage

That mentions the bindeb-pkg and deb-pkg arguments.  I am not sure what
the difference is.

-- 
Len Sorensen

Re: Debian on Pine64 H64B?

[Lennart Sorensen]

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 .deb builder for kernels.? Such secrecy, since it 
> doesn't involve the blacklisted firmware, and which my install doesn't 
> touch, certainly seems politically non-productive to me.

Did make-kpkg stop existing?  It's been a while since I had a reason to
build my own kernel on any of my debian systems.  I must admit searching
for it, it does appear to no longer exist.  Hmm.

Some searching on google seems to indicate that these days one is
expected to use make deb-pkg in the kernel tree instead.  I must admit
I have never tried that.

-- 
Len Sorensen

Re: Feedback from the community -> ARM

[Lennart Sorensen]

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 popular/cheap
> enough for use. Marvell have the espressobin and macchiatobin - just 
> get something that looks like a performant mini-ATX / itx board and
> can run forever at low power but in a standard form factor.

I remember seeing many arm servers announced.  I don't recall really
seeing any you could buy unless you were a data center.  If you were a
developer it seemed no one wanted to talk to you.  And then they wondered
why no one was showing interest in their servers that no one could write
code for.

-- 
Len Sorensen

Re: OT: Huge Right to Repair Win for Consumers

[Lennart Sorensen]

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
> initiative against the right of companies to protect their intellectual
> property.

There are plenty of other things that protect that (or fail to do so
either way).

> Why should any company take the risk of investment for new hardware 
> developments
> when they have to fear that every other company in the world will get free 
> access
> to their blue prints?

There are plenty of companies (often in China) that have no problem
copying a product without the schematics.  So at best that would save
them a tiny bit of work.  So that argument is nonsense.

> The claim that hardware companies intentionally make it hard to repair 
> consumer
> products is a conspiracy theory. In reality, a consumer product is primarily 
> optimized
> for production costs which implies cheap capacitors or cases that are glued 
> together.

Apple has made TI not sell power management chips to anyone but apple.
So if a laptop stops charging because that chip broke, rather than
solder on a new chip, Apple wants you to replace te entire board
(which conviniently has the SSD soldered on, so goodbye to your data).
Or clever people will take that chip of a broken board where that chip
still works and save the owner a lot of hassle and money.

Never mind the insanity that is John Deere.

There is no conspiracy theory, but clearly plenty of clueless people.

> Lots of consumers seem to forget that a product sold into the market not only 
> must
> cover the material costs but also the costs of engineering, marketing, 
> customer
> support, customs, compliance tests and so on. And in the end, you still want 
> there
> to be a small profit left which is what makes the whole business model viable 
> in
> the first place.

They can still do that.  But they better not rely on insane repair costs
or early replacements as part of making it profitable.  The product as
originally sold should cover that.

> If law initiatives also now want to take away the exclusive rights of 
> hardware designers
> over their blueprints and hence the market advantage over competitors that 
> they took an
> investment risk for, companies will lose the incentive to design and develop 
> new
> products.

Strangely companies had no problem making and selling products in the
past when it used to be common to include repair schematics with products
(like stoves, fridges, washing machines, furnaces, etc).

> Companies aren't charities so in the end they must protect their investments 
> and have to
> make profits to survive.

Some of them seem to be making plenty and certainly not paying their
share of taxes for society to function properly.

-- 
Len Sorensen

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

[Lennart Sorensen]

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 now I cannot find out how to boot into graphics mode. There
> is no good old startx but the sddm login is in /etc/init.d. I tried to start
> it but I don't get any reaction. So my question is:
> 
> How do I boot into graphics mode?

You probably didn't install it.  The image is probably kept as minimal as 
possible by default.

running 'tasksel' should let you add the graphical desktop and such.

-- 
Len Sorensen

Re: Porter roll call for Debian Bullseye

[Lennart Sorensen]

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 64-bit kernels even when running legacy user space, in
> particular as the 32-bit kernel is also missing some pieces for
> running 32-bit user space on 64-bit hardware.
> 
> Right, most importantly, the ones that do not work include
> 
> - ThunderX
> - ThunderX2
> - Apple M1
> 
> while the ones that do have aarch32 mode include
> 
> - All Ampere servers
> - Amazon EC2
> - NXP LX2160, as used in Solidrun LX2K machines
> - All other Cortex-A72 and A76 based servers

But does aarch32 mode imply full support for armv4 instructions?
armhf at armv7 should be fine I would think, but is armel still v4 or did
it move to v5?  I can't remember.  At least it appears the kernel has
options for emulating things like SWP and SWPB if they are missing.
Perhaps the future for armhf and even armel isn't totally hopeless.

-- 
Len Sorensen

Re: Porter roll call for Debian Bullseye

[Lennart Sorensen]

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 RAM, 2TB HDD Server.
> 
> Perhaps Amazon EC2 can be used?

My understanding is that Debian never cross compiles (maybe there are
exceptions for m68k or something, not sure).  Cross compiling tends to
be a problem for things using autoconf since it expects to be able to
compile and run a test program on the target.

And some packages would take way to long to compile on small machines
like a pi4 due to not enough ram.  And for build machines, you want rack
mountable machines with remote management.  Not something that doesn't
even have a power switch or ability to be restarted remotely if needed.
The people running Debian's build systems obviously are interested in
something reliable that won't cause problems and require a lot of manual
intervention for however many years the release will be supported.

No idea if AWS's arm systems are 64 bit only (many new arm server chips
are) or if they also can run 32 bit arm code, and even if they can run
32 bit arm code, which level of the instruction set do they support?

-- 
Len Sorensen

Re: Porter roll call for Debian Bullseye

[Lennart Sorensen]

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 armhf or if they lack certain
required instructions.

-- 
Len Sorensen

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

[Lennart Sorensen]

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 you can see that I'm not only subscribed
> to several lists but even top poster on a few of these.  I know how it
> works to subscribe a list.  I also know how to read the web archive -
> even how to drain a mbox from there to properly respond to some answer I
> might have got.
> 
> I wished all mailing lists on Debian would be such a welcoming place
> that people who have a plea (newbee or not) would not be titled rude.
> 
> Thanks to those who simply did the favour to me to keep me in CC in
> their helpful replies
> 
>  Andreas.
> 
> 
> [1] http://blends.debian.net/liststats/

Debian mailing lists don't require being subscribed to post (at least none
that I can think of, there are probably a few exceptions), and the debian
mailing list etiquette says "When replying to messages on the mailing
list, do not send a carbon copy (CC) to the original poster unless they
explicitly request to be copied." which would seemingly imply that it
is appropriate to request being CC'd if you want to.  So it seems that
it would be rude to think someone is rude for asking for it when it is
part of the code of conduct of the debian mailing lists.

I am personally terrible at remembering not to CC people on debian lists
due to it being so commonly expected on other lists.

-- 
Len Sorensen

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

[Lennart Sorensen]

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
> > arm64 from the list of supported architectures which is definitely
> > not my prefered way of action.
> > 
> > Any help would be really appreciated.
> 
> I don't have access to an arm64 system at the moment, but a good start
> might be to fix the compiler warnings, such as the array subscript out
> of bounds in global.c line 44.  The rest of the warnings appear harmless.
> 
> It would appear that GAP_SIZE = 2 is wrong given GAP[] only contains a
> single character.

I found the actual problem.  Someone didn't know that there are 3 types
of char in C.  char, signed char and unsigned char.  char is _only_ for
use in strings, and never to be used as a numerical value.  This is due
to the sign of char being implementation specific.  On x86 it is signed,
on arm it is unsigned.  So any time you want to work with numerical
values of a char, you must specify if you want signed or unsigned.
Changing char ch to unsigned char ch, made x86 fail the same way arm64
did, and making it signed char, makes both pass the test.

So here is a patch that appears to solve the problems in the code.

-- 
Len Sorensen
diff -ruN phipack-0.0.20160614/src/fasta.c phipack-0.0.20160614.arm64/src/fasta.c
--- phipack-0.0.20160614/src/fasta.c	2016-06-14 00:18:29.0 -0400
+++ phipack-0.0.20160614.arm64/src/fasta.c	2020-09-08 19:08:06.672390326 -0400
@@ -36,7 +36,7 @@
 void read_sequence_name(FILE *in_file,char *name, int capacity)
 {
   int i=0;
-  char ch='\0';
+  signed char ch='\0';
 
   ch=fgetc(in_file);
   if(ch != '>')
@@ -97,7 +97,7 @@
 {
   int bases_read=0;
   int new_limit;
-  char ch;
+  signed char ch;
   char s[250];
   
   ch=fgetc(in_file);
@@ -175,7 +175,7 @@
   int *seq_counter;
   int i;
  
-  char ch;
+  signed char ch;
 
   int cur_seqs;
   int num_seqs=1,new_num;
diff -ruN phipack-0.0.20160614/src/global.c phipack-0.0.20160614.arm64/src/global.c
--- phipack-0.0.20160614/src/global.c	2016-06-13 22:33:15.0 -0400
+++ phipack-0.0.20160614.arm64/src/global.c	2020-09-08 18:04:48.956444973 -0400
@@ -34,7 +34,7 @@
 const int AA_AMBIG_SIZE =2;
 
 const char GAP[] = {'-'};
-const int GAP_SIZE=2;
+const int GAP_SIZE=1;
 
 cbool memberOf(const char *set, const int num, char ch)
 {
@@ -79,10 +79,10 @@
   switch(alignKind)
 {
 case DNA:
-  return (memberOf(DNA_MISSING,DNA_MISSING_SIZE,ch) || memberOf(DNA_AMBIG,DNA_AMBIG_SIZE,ch));
+  return (memberOf(DNA_MISSING,DNA_MISSING_SIZE,ch) || memberOf(DNA_AMBIG,DNA_AMBIG_SIZE,ch)) ? TRUE : FALSE;
   break;
 case AA:
-  return (memberOf(AA_MISSING,AA_MISSING_SIZE,ch) || memberOf(AA_AMBIG,AA_AMBIG_SIZE,ch));
+  return (memberOf(AA_MISSING,AA_MISSING_SIZE,ch) || memberOf(AA_AMBIG,AA_AMBIG_SIZE,ch)) ? TRUE : FALSE;
   break;
 case OTHER:
   if(ch == GLOBAL_MISSING)
diff -ruN phipack-0.0.20160614/src/main.c phipack-0.0.20160614.arm64/src/main.c
--- phipack-0.0.20160614/src/main.c	2016-06-14 00:18:17.0 -0400
+++ phipack-0.0.20160614.arm64/src/main.c	2020-09-08 19:17:18.230153542 -0400
@@ -71,7 +71,8 @@
 
 void get_params(int argc, char**argv, options *opt) 
 { 
-  char *cur,ch,nextch;
+  char *cur;
+  signed char ch,nextch;
   char temp[MAX_SIZE+1];
   int i;
   cbool inFileFound=FALSE;
diff -ruN phipack-0.0.20160614/src/mem.c phipack-0.0.20160614.arm64/src/mem.c
--- phipack-0.0.20160614/src/mem.c	2016-06-13 22:33:15.0 -0400
+++ phipack-0.0.20160614.arm64/src/mem.c	2020-09-08 19:12:52.415278666 -0400
@@ -96,7 +96,7 @@
 
 char ffclose(FILE *handle)
 {
-  char f;
+  signed char f;
   char s[MAX_SIZE+1];
 
   f=fclose(handle);
diff -ruN phipack-0.0.20160614/src/misc.c phipack-0.0.20160614.arm64/src/misc.c
--- phipack-0.0.20160614/src/misc.c	2016-06-13 22:33:15.0 -0400
+++ phipack-0.0.20160614.arm64/src/misc.c	2020-09-08 19:08:28.352322441 -0400
@@ -46,7 +46,7 @@
 
 char skip_all_space(FILE *in_file)
 {
-  char ch;
+  signed char ch;
   
   ch=fgetc(in_file);
   while((ch != EOF) && isspace(ch))
@@ -61,7 +61,7 @@
 
 char skip_newlines(FILE *in_file)
 {
-  char ch;
+  signed char ch;
   
   ch=fgetc(in_file);
   while((ch != EOF) && (ch == '\n'))
@@ -76,7 +76,7 @@
 
 char skip_non_newline(FILE *in_file)
 {
-  char ch;
+  signed char ch;
   
   ch=fgetc(in_file);
   while((ch != EOF) && (ch != '\n'))
@@ -90,7 +90,7 @@
 
 char skip_non_newline_space(FILE *in_file)
 {
-  char ch;
+  signed char ch;
   
   ch=fgetc(in_file);
   while((ch != EOF) && (ch != '\n') && isspace(ch))
diff -ruN phipack-0.0.20160614/src/phylip.c phipack-0.0.20160614.arm64/src/phylip.c
--- phipack-0.0.20160614/src/phylip.c	2016-06-14 00:18:17.0 -0400
+++ 

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

[Lennart Sorensen]

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 would be really appreciated.

I don't have access to an arm64 system at the moment, but a good start
might be to fix the compiler warnings, such as the array subscript out
of bounds in global.c line 44.  The rest of the warnings appear harmless.

It would appear that GAP_SIZE = 2 is wrong given GAP[] only contains a
single character.

-- 
Len Sorensen

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

[Lennart Sorensen]

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 an underscore which isn't permitted in architecture names
in debian since it is the field separator in the package filename. :)

-- 
Len Sorensen

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

[Lennart Sorensen]

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 the architecture (as given to configure) is
> aarch64-linux-gnu.
> 
> The debian name for the architecture is arm64
> 
> GCC defines __aarch64__ for the architecture.
> 
> Be careful of things which check for arm* in debian architecture tests, as
> it is usually wrong to do the same thing for arm64 as for 32-bit arm
> (arm/armel/armhf). In general, if you are not sure, you should do the same
> thing as on amd64 as that matches quite closely (64 bit, little endian,
> 32-bit ints and floats, 64-bit pointers, longs and doubles).
> 
> Check the link below for 'upstream package porting' to see if your package
> has had porting attention from Linaro.
> 
> There is also a big-endian version of the architecture/ABI:
> aarch64_be-linux-gnu but we're not supporting that in Debian (so there is
> no corresponding Debian architecture name) and hopefully will never have
> to. Nevertheless you might want to check for this by way of completeness in
> upstream code. 

Well a lot of people looking for 64bit arm support would look for arm64,
while aarch64 is technically the name, it sure doesn't scream "arm"
at a user.

Besides there is i386 which intel retroactively called IA32, and then to
confuse everyone decided IA64 was itanium, not the 64bit version of x86.
Lots of people tried to install ia64 debian on 64 bit x86 machines
over the years.  Debian calls it amd64 while gcc calls it x86_64 and
intel calls it em64t or maybe now they changed it to "intel 64", not
sure actually.

-- 
Len Sorensen

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

[Lennart Sorensen]

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 this is how they are packaged for Debian at present.  Package
> dependencies currently say that we need libatomic-ops.
> 
> The other part is "what is missing in libatomic-ops"? If you look at a
> more recent implementation, such as riscv, you see that it basically
> says "trust gcc". So I guess all you need here is an arc-specific
> implementation that says "gcc knows what it is doing, use its
> primitives".
> 
> Given sufficient work, I guess libatomic-ops could be removed in favour
> of using the gcc built-ins directly. Not sure whether that'd fly with
> libgc upstream though.
> 
> So no, this is not a stupid question. Thank you for asking.

The way I read the details on libatomic is that it provides functions
to implement the things a given architecture can't do with intrinsics
in gcc directly.  So on some architectures it does nothing and on others
it implements missing bits for atomic operations.

-- 
Len Sorensen

Re: Y2038 - best way forward in Debian?

[Lennart Sorensen]

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* 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.
> 
> And that's chosen at build time (i.e. when compiling glibc)?
> Why not provide different entry points for time-manipulating functions,
> so a single build can support both applications using 32bit time and
> applications using 64bit time?
> 
> E.g.
> 
> struct time32_t ...
> struct time64_t ...
> 
> double difftime32 (time32_t time1, time32_t time0);
> double difftime64 (time64_t time1, time64_t time0);
> 
> and in the time.h have
> 
> #if TOO_OLD_TO_LIVE_PAST_2038
> typedef time32_t time_t;
> ...
> #else
> typedef time64_t time_t;
> ...
> #endif

I agree.  Why should this be any different than 64 bit file support?
Transparent on 64 bit architectures, and 32bit code gets to pick the
one it wants to support at compile time while glibc supports both,
and eventually just about everything switches.  You can even eventually
add warnings when any program calls the 32 bit version of the functions.

-- 
Len Sorensen

Re: arm64-net-install buster 10.2

[Lennart Sorensen]

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 on the rpi4b as I two SSD'd mounted 
> on sata-usb3 cables, so a full kernel bulld is under an hour in wall 
> time.  I also, because its only a 2G pi, have a 10G swap partition 
> mounted, and the swapfile turned off to reduce pressure on the u-sd 
> card.
> 
> The pi-4b is a whole new critter worth looking at.
>
> It is supported upstream by any linux-rt kernel newer than 4.14 although 
> 4.14's support for the mali gfx isn't quite fully baked until 4.19.y.

Ehm, I was pretty sure all Raspberry Pi models have broadcom videocore
graphics, and certainly not mali.

> I am actually running a 
> 
> Linux rpi4.coyote.den 4.19.71-rt24-v7l+ #1 SMP PREEMPT RT Thu Oct 10 
> 15:22:22 EDT 2019 armv7l GNU/Linux
> 
> right now, but a /boot/dts/overlays directory has apparently been removed 
> from newer ones, and I'm trying to find a workaround, or make an arm64 
> boot work and rebuild LinuxCNC to run on a 64 bit build. I'd settle for 
> either scenario.
> 
> So it would appear Len. And I'll repeat, the original 10.0 netinstall 
> Just Worked, and felt dead stable, but now a 10.2 of this buster doesn't 
> even try to boot.  The main diff is that there is now a pair of ssd's on 
> sata adaptors plugged into the usb-3 ports with a total of 360G 
> available as scratchpad workspaces.

I don't see how adding USB disks should change anything.

Did you upgrade the working 10.0 system, or did you do a new image?
Because the only think that makes sense to me is that the 10.0 image
wasn't a pure Debian image, but rather one modified enough for RPi4
operation.

> Thanks Len, for any enlightement.

I don't have a 4 (only a 2 and 3 so far).  What I have read made me
think that it simply should not work so far with Debian.  There appears
to be some unofficial modified images out that that should work.

-- 
Len Sorensen

Re: arm64-net-install buster 10.2

[Lennart Sorensen]

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
for the Pi4 in Debian's kernel yet (after all it has to be supported
upstream before Debian will support it).  Raspbian has no issues with
using a patched kernel with stuff that isn't supported upstream yet as
long as it makes Pi models work with it.

Also the boot process for the 4 is completely different than the older
models as far as I know.

-- 
Len Sorensen

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

[Lennart Sorensen]

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 ethernet
can actually be done.  But looking at the specs my guess appears wrong.
It claims ethernet is on the SoC and that USB 3 is done through a PCIe
link.  Only 4Gbps total for the USB ports, so certainly won't do true
USB 3 speeds but probably good enough for most uses.

-- 
Len Sorensen

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

[Lennart Sorensen]

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 run on one of these?  Or 
> should I just plan on running Raspbian?

Debian almost certainly won't run.  I don't even see RPi4 support in the
linux kernel upstream yet, so Raspbian is using a patched kernel to make
it work I suspect.  Debian won't patch in support for anything that
isn't already supported upstream in the kernel.

So for now, most likely Raspbian is the only thing that will run easily
on the RPi4.

-- 
Len Sorensen

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

[Lennart Sorensen]

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 (rw,nosuid,nodev,noexec,relatime)
> proc on /proc type proc (rw,relatime)
> securityfs on /sys/kernel/security type securityfs
> (rw,nosuid,nodev,noexec,relatime)
> tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
> devpts on /dev/pts type devpts
> (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
> tmpfs on /run type tmpfs (rw,nosuid,nodev,mode=755)
> tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k)
> tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,mode=755)
> cgroup on /sys/fs/cgroup/systemd type cgroup 
> (rw,nosuid,nodev,noexec,relatime,xattr,release_agent=/lib/systemd/systemd-cgroups-agent,name=systemd)
> pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime)
> cgroup on /sys/fs/cgroup/cpuset type cgroup
> (rw,nosuid,nodev,noexec,relatime,cpuset)
> cgroup on /sys/fs/cgroup/devices type cgroup
> (rw,nosuid,nodev,noexec,relatime,devices)
> cgroup on /sys/fs/cgroup/freezer type cgroup
> (rw,nosuid,nodev,noexec,relatime,freezer)
> cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup
> (rw,nosuid,nodev,noexec,relatime,cpu,cpuacct)
> mqueue on /dev/mqueue type mqueue (rw,relatime)
> debugfs on /sys/kernel/debug type debugfs (rw,relatime)
> configfs on /sys/kernel/config type configfs (rw,relatime)
> fusectl on /sys/fs/fuse/connections type fusectl (rw,relatime)
> /dev/mmcblk0p1 on /boot type vfat 
> (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro)
> tmpfs on /run/user/0 type tmpfs
> (rw,nosuid,nodev,relatime,size=206040k,mode=700)
> root@arm7:/boot#
> 
> What I need is a proper Debian install process on this tinker board ASUS
> thing and then I can say goodbye to the linaro install that comes with
> it.
> 
> Thanks for catching that and .. gee .. is there a way to recover?

I would think this could work:

Move the files belonging to debian packages from /boot to another
location, then unmount /boot and move the files into the /boot that
is part of / then mount your boot partition as something else (like
/vfatboot or something).  On these types of machines usually you use
the flash-kernel package, which copies to correct files from /boot to
the vfat boot partition when a new kernel is installed and generates the
needed uboot scripts or whatever a given system requires.  That is once
you add the machine identifier to the database for flash-kernel.

There seems to be no reason to have a seperate /boot partition from the
debian point of view if the system boots from a vfat partition so easier
to just make /boot be a plain directory on the root partition in that
case.

-- 
Len Sorensen

Re: Stretch ARM installation RAM and Flash size

[Lennart Sorensen]

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 own build system, someone might like it, but I would prefer
> an open environment.
> 
> What I really don't understand is why could the OpenWRT to make the OS
> so small but Debian ARM embedded system could not?

Debian tends to enable all the features, while the embedded systems tend
to only turn on exactly what they need.  Debian is trying to target a
generic platform and work for everything, while openwrt/lede/yocto tend
to aim at building for a specific target device.

OpenWRT uses musl for libc, not glibc, which has less features and
optimized for size rather than performance when there is a choice to
be made.  Yocto lets you pick which libc you want to build with.

-- 
Len Sorensen

Re: Stretch ARM installation RAM and Flash size

[Lennart Sorensen]

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 with its > 53000 binary
> packages, but a local mirror with only 450 packages. Otherwise apt
> collapses once in a while with our 128 MiB RAM.
> 
> It is still Debian armel, only it's reduced and we add our own dozen
> of packages. debianforembeddedsystems/rules :—)

Yes if you do your own build you can make it smaller.  Dumping
/usr/share/doc, man pages, locale files, and a few other things can save
a fair bit of space.

Still not yocto level of shrinking of course or alpine.

-- 
Len Sorensen

Re: Stretch ARM installation RAM and Flash size

[Lennart Sorensen]

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, about 2 MB libraries and 500 KB binary
> application, I need to know the OS Debian Stretch armhf size.

I would be impressed by a Debian install in less than 250MB storage space.
It would have to be rather minimal.  Even running apt-get update to
pull the list of available packages easily grabs 40MB disk space in
my experience.

-- 
Len Sorensen

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

[Lennart Sorensen]

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 failed on channel 0

Restarting sshd would be required.

> > What the name of user 1000 is has nothing to do with it (Only really
> > NFS has issues with uid's not matching between machines and there are
> > ways to deal with that too).
> 
> Well, something is makeing sure I can't do anything from any keyboard but 
> the machines own keyboard and monitor.
> 
> Thanks Lennart, you actually tried to answer my question, and I 
> appreciate it.

Well somehow I missed what the original problem was initially.

-- 
Len Sorensen

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

[Lennart Sorensen]

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 and bailout when they're are denied its use, so I'm stuck 
> with nano, and its half a screen vertical jump for a scroll drives me 
> plumb out of my skull, spending 95% of my time looking for the damned 
> curser. No way in hell you can write good code with that distraction.
> 
> I'm running out of patience, everyone is reading what they *think* I 
> wrote, then answering that question I didn't ask. That is not helpfull 
> and just confuses the next person that replies to what ought to be a new 
> thread, its that far from the actual subject.

(Went back and reread the thread...)

When you said you had isses with ssh -Y not allow X connections...

Check that /etc/ssh/sshd_config on the rock64 has these settings:

X11Forwarding yes
X11UseLocalhost no

And that the package 'xauth' is installed.

Either of those missing will prevent ssh from forwarding X connections.

What the name of user 1000 is has nothing to do with it (Only really
NFS has issues with uid's not matching between machines and there are
ways to deal with that too).

-- 
Len Sorensen

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

[Lennart Sorensen]

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)

[Lennart Sorensen]

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.  And I've no clue if ts this wheezy machine, or that 
> jessie or stretch machine reporting the error I see on my konsole here 
> on wheezy.

Once you su or sudo you no longer have permission to access X.  If you
want that use gksudo or kdesudo which handle keeping access to X while
switching to root.

-- 
Len Sorensen

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

[Lennart Sorensen]

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
> things very flaky (e.g. autoremove broke X11 beyond repair).
> 
> My recollection of the UEFI situation is that Intel et al. made "Secure
> Boot" optional on PCs but mandatory on ARM systems that had UEFI.

Microsoft made that a rule for devices that are Windows Certified.
x86 devices with Windows should have an option to let the user decide
about secureboot (but it must be on by default), while arm devices must
always use secureboot with Windows.

Intel had nothing to do with that.

-- 
Len Sorensen

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

[Lennart Sorensen]

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 the same
clock speed by quite a bit.

For example http://www.360doc.com/content/12/0806/14/350555_228637047.shtml 
says:
Cortex-A9 has many advanced features for a RISC CPU, such as speculative
data accesses, branch prediction, multi-issuing of instructions,
hardware cache coherency, out-of-order execution and register renaming.
Cortex-A8 does not have these, except for dual-issuing instructions and
branch prediction.

So the A8 still has branch prediction so it can keep the pipeline fed,
even with in order execution.  Spectre isn't really about out-of-order
excution as much as it is about speculative memory accesses which some
in-order execution chips have too.

-- 
Len Sorensen

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

[Lennart Sorensen]

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 to GUARANTEE that you've got spectre-immune hardware you need
> either any 32-bit system (where even Cortex A7 has virtualisattion) or
> if 64-bit is absolutely required use Cortex A53.

The Cortex A8, A7 and A5 are in order.  The A9, A15, A17 etc are out of
order execution.  So any 32 bit arm worth using is pretty much always
out of order execution.

For 64 bit, I think the A35 and A53 are in order while the A57, A72 etc
are out of order.

Of course non Cortex designs vary (I think Marvel's JP4 core was out of
order execution for example).

After all, in general in order execution equals awful performance.

-- 
Len Sorensen

Re: Module aliases etc.

[Lennart Sorensen]

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
> the example below)?
> 
> alias:  hid:b0003g*v056Ep010D
> alias:  hid:b0003g*v056Ep010C
> alias:  hid:b0003g*v056Ep00FF
> alias:  hid:b0003g*v056Ep00FE
> alias:  hid:b0005g*v056Ep0061
> 
> I'd assumed from udev/hwdb that it was a bus identifier applicable to
> something that was actually plugged in, but I'm curious to see it varying on
> a virgin system that's never seen the peripheral in question.

Well the kernel source code says:

return scnprintf(buf, PAGE_SIZE, "hid:b%04Xg%04Xv%08Xp%08X\n",
 hdev->bus, hdev->group, hdev->vendor, hdev->product);

Also:

   switch (hdev->bus) {
case BUS_USB:
bus = "USB";
break;
case BUS_BLUETOOTH:
bus = "BLUETOOTH";
break;
case BUS_I2C:
bus = "I2C";
break;
default:
bus = "";
}

So it appears to be a bus type.  3 is USB, 5 is BLUETOOTH according to input.h

-- 
Len Sorensen

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

[Lennart Sorensen]

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 really)?

-- 
Len Sorensen

Re: Why so little info on the Pocket Beagle?

[Lennart Sorensen]

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 Sorensen

Re: Why so little info on the Pocket Beagle?

[Lennart Sorensen]

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 that's the
> PowerVR instruction set, just the GPU stuff with the shaders and such.
> I haven't found a CPU instruction set but I haven't really looked,
> maybe they're the same as other ARM chips?  Somewhere I've got one of
> those from a Pi

The CPU is a Cortex-A8.  Totally standard and fully documented.  That's
not the issue at all.  The issue is the lack of any documentation on
the GPU that is part of the AM355x.

> There's a page at http://www.ti.com/product/AM3358/technicaldocuments
> I recently discovered. I've been looking at a sprs717j.pdf I got
> somewhere else.  It covers the AM335x Sitara line, looks like it was
> originally written Oct 2011 but revised Apr 2016, this gif is page 8.
> I thought from somewhere the chip in the Pocket Beagle is an AM3358.
> The package it came in says AM335x (scans of card from package).

A lot of arm chips have powervr graphics in them, with hence awful
support for the video unless you are willing to put up with the
proprietary drivers.

As for why they used it, well the chip exists and is already used on
the other beagleboard models so people are used to it.

The AM335x has been around a while, this one just uses a new tiny package
version of it with ram and lots of other bits integrated in a single
package to make it smaller and cheaper.

TI has been putting the same awful powervr design in their chips for
years.  The AM57xx has the same crap unfortunately, although the rest
of the chip is quite a bit newer and nicer (Although I guess by now some
people would think the Cortex-A15 is starting to get dated too).

-- 
Len Sorensen

Re: Why so little info on the Pocket Beagle?

[Lennart Sorensen]

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 (like the 530).  The 6 series
is quite sane it seems and partially documented.  The 5 series on the
other hand I get the impression that they don't have anyone in the
company anymore that even understands.  It appears to be very weird
based on what I have read of reverse engineering attempts.

Still that document is apparently just the assembly language for part
of the 6 series, and isn't nearly enough to make anything useful.

-- 
Len Sorensen

Re: Why so little info on the Pocket Beagle?

[Lennart Sorensen]

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
> has a micro (not mini) HDMI, so I wanted to double check that because
> I only have mini, but couldn't find it again.  It does have several
> serial ports or at least uarts.  Their graphics are so big they
> basically didn't work until I made them 1/4 size in Gimp.  It has 2
> SPI ports by the pinouts.  Yes, I have 3 Raspberry Pi 3Bs and a couple
> Zeros, I wanted to diversify a little.  Or I just wonder why nobody
> else bothers to include A/D ports.

No it uses a CPU that has video.  I don't see any indication that you
can access the video in any way.

-- 
Len Sorensen

Re: Why so little info on the Pocket Beagle?

[Lennart Sorensen]

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 does ethernet over USB too now that I think back to
last time I played with a beagle black.  That must be what they use.

> After reading about it, I think it sounds like a neat project with
> some niche applications. But I also think you should probably use a
> more traditional dev-board, like a Pine-64, ODROID-C2, LeMaker HiKey,
> RaspberryPi-3, BananaPi, CunieTruck 5, etc. You will find them easier
> to use.

I was mainly curious what they were using (since they have so little
info about it on their website so far).

I have brought up some arm reference boards and from scratch boards,
so I wouldn't be too concerned about doing it for myself.  I just don't
currently have anything I would want to do with it.  It sure is a nice
little board though.

-- 
Len Sorensen

Re: Why so little info on the Pocket Beagle?

[Lennart Sorensen]

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 attach a monitor to a pocketbeagle that has no video
connector?

Seems to me usb serial is the only option, or blink an led.

-- 
Len Sorensen

Re: Why so little info on the Pocket Beagle?

[Lennart Sorensen]

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 write an SD card with all the software ready to go
and then boot it and have it sit headless doing its thing?

I imagine it could do a USB gadget serial console if you set it up right.

-- 
Len Sorensen

Re: Bug#861281: rnahybrid: FTBFS on armel

[Lennart Sorensen]

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 manually, and it does actually
complete, but it takes MUCH longer than the native x86 compile.  So at
least with gcc 7.2.0 it is NOT an infinite loop, it just looks like it.

On this machine it takes about 50 seconds to compile energy.c for amd64,
and it takes the cross compiler 25 minutes to compile energy.c for armel.
It also used 660MB ram, while the amd64 compile only used 150MB.
Maybe the extra registers on arm is making the compiler try a lot more
optimization possibilities with all the loops.

So I can see how the armel build machine is timing out.  Also it means
gcc does NOT have an infinite loop bug, at least not in 7.2.  I suspect
gcc 6 didn't either.

> (I will test with the compilers in unstable, as requested, if no one
> else gets there first.)

Well I tried as you can see.

> I don't think the buildds report memory usage, but the time is 150 minutes:
> 
> https://buildd.debian.org/status/logs.php?pkg=rnahybrid=armel

So the build timeout is too short for this package on that build machine
with the way gcc optimizes now.

-- 
Len Sorensen

Re: Bug#861281: rnahybrid: FTBFS on armel

[Lennart Sorensen]

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 in fact just be because the build machine is
too slow.

The file it timed out on takes almost 1 minute to compile on a 2GHz x86.
That one file is about 90% of the total build time of the package.

How long does it take on the armel build box and how much memory does
it use while doing it?  My x86 hit close to 150MB for the cc1 process
on that file.  Memory bandwidth could possible affect the compile time
on that file a lot.

So perhaps the real answer is that the timeout on this package needs
to be increased, or it should only be built on the fastest of the
armel build machines.

The energy.c file is over 12000 lines long and contains massive nested
loops that the optimizer is probably trying to do nice things to.

I highly doubt there is a bug in gcc, or any infinite loop.  Just gcc
is trying harder to optimize than it used to, and the timeout is too low.

I would be very surprised if a manual attempt to build it on armel would
not succeed, although you are probably looking at 4 hours to do it.

-- 
Len Sorensen

Re: Bug#861281: rnahybrid: FTBFS on armel

[Lennart Sorensen]

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 warnings are due to missing #include in a lot of places.

-- 
Len Sorensen
diff -ur rnahybrid-2.1.2.orig/src/energy.c rnahybrid-2.1.2/src/energy.c
--- rnahybrid-2.1.2.orig/src/energy.c	2013-08-25 11:51:20.0 -0400
+++ rnahybrid-2.1.2/src/energy.c	2017-09-26 11:04:34.747986466 -0400
@@ -536,7 +536,7 @@
 void init_dr_dangle_dg_ar()
 {
   int i,j,k;
-  for(i=0;i

Re: Bug#861281: rnahybrid: FTBFS on armel

[Lennart Sorensen]

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 to the compiler going into an infinite loop:
> 
> energy.c:539:104: warning: iteration 6 invokes undefined behavior
> [-Waggressive-loop-optimizations]

Is it because of this:
energy.c:539:53: note: within this loop
   for(i=0;i There are other warnings, too, but undefined behaviour is particularly scary.

The pointers being converted to integers concern me a bit.  That might
cause big problems on 64 bit systems.

It sure looks like some seriously sloppy coding.

-- 
Len Sorensen

Re: Summary of the Arm ports BoF at DC17

[Lennart Sorensen]

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 do support them even thought
> > > they
> > > are deprecated. It's certainly worth investigating what your
> > > hardware
> > > supports.
> > 
> > Not necessarily disagreeing with the content of that but the
> > terminology seems wrong: I don't have a reference to hand but I'm
> > fairly sure that hardware is *required* to support a "deprecated"
> > instruction. "Deprecated" usually means something like: unless you
> > know what you're doing you probably shouldn't use this feature
> > because
> > it might perform badly and it might not be available in a future
> > version (of the Arm architecture in this case).
> 
> In principal I agree with your interpretation of "Deprecated" but the
> wording in Linux's Documentation/arm64/legacy_instructions.txt which
> documents this stuff is:
> 
> * Hardware Execution
>   Value: 2
>   Although marked as deprecated, some implementations may support the
>   enabling/disabling of hardware support for the execution of these
>   instructions. Using hardware execution generally provides better
>   performance, but at the loss of ability to gather runtime statistics
>   about the use of the deprecated instructions.
> 
> Which in "some implementations may" at least implies the possibility
> that some hardware may not support these instructions. I don't seem to
> be able to download an ARM ARM right now to see what the actual wording
> used there is.

I believe it says some hardware might support disabling the support
for the deprecated instruction.  It does not say they don't support the
deprecated instruction.  Having the ability to disable a feature that
you ideally shouldn't use can be very helpful to make sure you aren't
accidentally using it after all.

Nothing in that text says that some hardware might not implement the
deprecated instruction.  The might is talking about the ability to turn
off deprecated instructions.

-- 
Len Sorensen

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

[Lennart Sorensen]

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 JNZYR0017 on the bottom of this K360. It also has regulatory 
> labels from at least a dozen other national regulatory agencies from all 
> over the planet.  A very busy label. So the frequency and protocol are 
> supposedly known to the various regulatory agencies.  The above Jnumber 
> doesn't not search in their database, at least not those pieces I can 
> access.

It is 2.4GHz just like BT and lots of wifi.  Doesn't make it BT though.

-- 
Len Sorensen

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

[Lennart Sorensen]

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 bluetoothctl, while I jiggled the mouse, nothing detected.

Certainly Logitech's wireless is not BT.  I seem to recall reading that
they found BT way too unreliable and instead use their own protocol.
Not sure about other makes.

-- 
Len Sorensen

Re: Testing boot loaders

[Lennart Sorensen]

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
> >>straightforward way to copy the loader (plus its header etc.) into the
> >>appropriate area of Qemu's address space and then transfer to it. Ideally
> >>after that there would be enough startup messages to indicate that the
> >>kernel was running, even if there wasn't emulated framebuffer hardware.
> >>
> >>I think that the latest Qemu might have MX50 support, but at this stage it's
> >>the initial boot that's interesting.
> >
> >Hmm, all I had seen was MX25.  Looking at the git tree I see 25, 31 and 6,
> >but no 5x.
> 
> Is this relevant? It's come via Android but does appear to have hardware
> definitions.
> 
> https://github.com/esminc/qemu/tree/master/Source/device-qemu/android/android-goldfish-3.4/arch/arm/mach-imx

Well that is in fact a linux-3.4 android kernel source tree, not qemu.

See 
https://github.com/esminc/qemu/blob/master/Source/device-qemu/android/android-goldfish-3.4/README

So no help there unfortunately.  Getting the hardware difinitions is easy.
Emulating them on the other hand is not.

-- 
Len Sorensen

Re: Testing boot loaders

[Lennart Sorensen]

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 somebody wants me to put Debian.
> It appears to have a common or garden partition table at the start, live and
> recovery filesystems, and then a large storage area:
> 
> Device Boot   Start End Sectors  Size Id Type
> kobo.bin1 49152  573440  524289  256M 83 Linux
> kobo.bin2573441 1097729  524289  256M 83 Linux
> kobo.bin3   1097730 7744511 6646782  3.2G  b W95 FAT32
> 
> I believe that there's a configured copy of U-Boot and the kernel in the
> unpartitioned area at the start of the device, there isn't any jump code in
> the partition table.
> 
> The device is based on the "Freescale MX50 Reference Design Platform", and
> kernel sources etc. are available on Github, I think I can see that the boot
> loader's entry is at 0xF8006458.
> 
> Is it possible to use Qemu or some comparable emulator to check the boot
> sequence in situ, i.e. without breaking the U-Boot and kernel images out
> into separate files?

Well in case you don't know, at least on the i.MX51 the boot code is
at offset 1024 bytes from the start of the device (so slightly after
the partition table).  I suspect the i.MX50 probably does the same, so
the u-boot or other boot code should be found between 1K and the start
of the first partition.

My guess would be .bin1 and .bin2 are primary and backup system
partitions, with the FAT32 purely for ebook storage and exposed as a
disk when a USB connection to another machine is made.

-- 
Len Sorensen

Re: missed keystrokes problem, back with a vengeance.

[Lennart Sorensen]

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 out the switchmode psu's, and putting in 
> tordoid transformers, bridge rectifiers, and the biggest electrolytic I 
> had in the drawers that had sufficient withstand voltage.  Its a star 
> ground system, and the output cables to the motors are shielded, and the 
> shield grounded as it goes by this single bolt ground on its way out of 
> the box. The shielding extends both ways from that point but is not 
> connected either at the motor, or at the driver, just at the bolt.  This 
> is std in such noisy machinery.

Well the USB would probably be at either 12MHz (USB 1.x) or 480MHz (for
USB 2), but most likely USB1 for your keyboard.  That certainly is a
potential place to hit with noise if you are getting spikes into the
100MHz range.  And USB cables don't appear to be that well shielded in
general (they seem to aim for cheap).

-- 
Len Sorensen

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

[Lennart Sorensen]

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 v3 copyright notices start off at 1984 (v2 might have earlier dates but
> I can't see where I've put it), and I am pretty sure that that predates
> their mice; my recollection is that Mouse Systems and "PC Mouse" which might
> or might not have been distinct had the market to themselves in the earliest
> days.

Well they were doing mice in 1982 along with some gui editor.  I think
modula-2 and debuging came in 1983.  Selling mice by themselves seem to
have been a couple of years later, whenever the C7 came out, although
they were selling mice to Apollo and HP before that.  Not sure if they
also supplied Sun or if that was someone else, although given it was
optical, probably someone else.

> Logitech started to walk away from compilers and concentrate on peripherals
> when they bought a small company (AMS?) in Warrington ("where the wodka
> comes from") that made mice etc. for the likes of Amstrad computers, AIUI
> they also had... errm... personnel problems which effectively resulted in
> their shutting down the UK office (a nicely-appointed tithe barn somewhere
> in the Home Counties, possibly Berkshire but I forget the exact location).
> 
> Of course, Logitech's M2 was challenged by JPI/Topspeed which was bought out
> of Borland. legend had it that Borland effectively sabotaged the 8-bit
> variant by retaining the manual copyright and refusing to reprint, but the
> 16-bit variants did fairly well for a while until they had... errm...
> personnel problems in their USA office which effectively forced them to sell
> out to Clarion.
> 
> I supported the Logitech compiler being used for embedded '186 work at
> Lowbrow Uni in the mid-80s, and later did a fair amount of embedded work
> using TopSpeed (bare-metal '286 code). These days of course one would use
> ARM for comparable jobs, with or without a standard OS.

Yeah lots of options today.

Borland and Watcom and such all seem to have died out by now.

-- 
Len Sorensen

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

[Lennart Sorensen]

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 was their de-facto UK tech support for a while. Long
> predated Linux of course (in a nod to the fact that we're wandering way OT).

Logitech made software and mice right from the start, and only got into
compilers (module-2 I believe) a bit later (although not very much later
it seems)

Not like Microsoft that started in compilers and much later got into mice.

-- 
Len Sorensen

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

[Lennart Sorensen]

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 version of 4.8.11, so an
> > installer booted with 4.7.8 is going to have a hard time finding working
> > kernel modules.
> ...
> > Maybe these would work better:
> > https://d-i.debian.org/daily-images/arm64/daily/netboot/debian-installer/arm64/
> 
> Yes, they do, much better, thank you.  There are still some alarming
> messages on the console which I will take up with the
> hardware/firmware folks, but d-i ran to completion and generated a
> system which boots.
> 
> Is it the case, then, that the images here
> 
> > >  
> > > http://ftp.debian.org/debian//dists/stretch/main/installer-arm64/current/images/netboot//debian-installer/arm64/linux
> 
> are simply useless now ?  They seemed like the obvious starting point
> to me.  (The corresponding amd64 installer is what I used to install
> stretch on an x86 machine fairly recently.)

Yes due to stretch changing from 4.7 to 4.8 kernel since those images
were made, the netboot images for the most recent d-i alpha build are
in fact useless now.  Maybe someone should update the errata page for
the alpha8 to mention that.

Well at least the up to date stuff works, which is at least a good sign
for the stretch release.

> Anyway, what I really want is a suitable combination of parts in
> backports.  Should I expect this all to work if I use a backports
> kernel ?

Well you would have the problem of how to convince the netboot installer
to grab kernel modules from backports rather than jessie.  I imagine
there is a way to do that.  But if the available modules that it downloads
match the kernel booted, then it ought to fine.  Not sure what the state
of arm64 support is in jessie.

> If so then I will try it again more systematically and report what
> goes wrong - but IIRC[1] it's probably the same thing: not finding the
> kernel modules.

Most likely.

-- 
Len Sorensen

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

[Lennart Sorensen]

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.
> 
> Right now, I can't get d-i to install on them.  I have tried jessie
> with a backports kernel, and stretch.
> 
> With stretch, d-i bombs out here:
> 
>   Jan  3 18:00:44.412384 Download installer components
>   Jan  3 18:00:45.044389 -
>   Jan  3 18:00:45.052432 Jan  3 18:00:45.052445 No kernel modules were found. 
> This probably is due to a mismatch between the 
>   Jan  3 18:00:45.060411 kernel used by this version of the installer and the 
> kernel version available 
>   Jan  3 18:00:45.060450 in the archive.
>   Jan  3 18:00:45.068415 Jan  3 18:00:45.068427 If you're installing from a 
> mirror, you can work around this problem by 
>   Jan  3 18:00:45.068458 choosing to install a different version of Debian. 
> The install will probably 
>   Jan  3 18:00:45.076422 fail to work if you continue without kernel modules.
>   Jan  3 18:00:45.084417 Continue the install without loading kernel modules?
>   Jan  3 18:00:45.084448   1: Yes  2: No [*]
> 
> If I select `1', it then continues without detecting any hard disks
> (`No disk drive was detected').
> 
> 
> My kernel image and initrd are:
> 
>  
> http://ftp.debian.org/debian//dists/stretch/main/installer-arm64/current/images/netboot//debian-installer/arm64/linux
>  76ec5622593eeebb7203748530e6b28adedba63a1c23f4e23d086372538fa006  linux
> 
>  
> http://ftp.debian.org/debian//dists/stretch/main/installer-arm64/current/images/netboot//debian-installer/arm64/initrd.gz
>  862e74a54665b1198ee697d8414e19da3ed9b05613cded73db764ea8920aeee5  initrd.gz
> 
> 
> My grub.cfg, which I am using to netboot the image, and my preseed
> file, are below.
> 
> 
> If I boot with `auto' removed from my command line I can quit into a
> shell after "No kernel modules were found" and then I see this:
> 
> ~ # uname -av
> Linux laxton0 4.7.0-1-arm64 #1 SMP Debian 4.7.8-1 (2016-10-19) aarch64 
> GNU/Linux
> ~ # ls /lib/modules/4.7.0-1-arm64/
> kernel   modules.builtin.bin  modules.order
> modules.aliasmodules.dep  modules.softdep
> modules.alias.binmodules.dep.bin  modules.symbols
> modules.builtin  modules.devname  modules.symbols.bin

Stretch in the archive currently has a kernel version of 4.8.11, so an
installer booted with 4.7.8 is going to have a hard time finding working
kernel modules.

An installer that has more parts included than the network boot one
would have a much better chance of working.

It would seem the files you are using are dated October 31, 2016, which
is a couple of months ago, and a lot has happened in stretch since.

Maybe these would work better:
https://d-i.debian.org/daily-images/arm64/daily/netboot/debian-installer/arm64/

-- 
Len Sorensen

Re: Unknown QNAP Model

[Lennart Sorensen]

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 qnap TS-231+ with a debian installation too.
> 
> > I’ve seen that Martin worked with the 21x and 22x devices and i’d
> > like to know how i can check if this might be possible. Do you know
> > what the differences between the TS-21x, -22x and -23x are?
> 
> Unfortunately, the TS-231+ uses a completely different ARM chip to
> the TS-21x/TS-22x models.
> 
> I'm not aware of any plans to support the TS-231+ (due to, as Rob
> pointed out, lack of kernel support).

Well at least there is alpine.dtsi and alpine-db.dts, so at least a
start to supporting the AL212 exists in the kernel already.

-- 
Len Sorensen

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

[Lennart Sorensen]

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 armhf ones, without
> requiring a reinstall.
> 
> After all, armel has been around longer than armhf has, which means that
> there may be some machines out in the wild that were installed (and
> upgraded) when armel existed but armhf did not yet (or at least, was not
> stable yet). Some of those machines might be armv7 machines that would
> be perfectly capable of running the armhf port, except that it wasn't
> around yet when they were first installed, and switching to armhf
> without reinstalling isn't possible.
> 
> I once did try to do a similar migration on my Thecus (from arm to
> armel, rather than armel to armhf), but that failed miserably; and since
> I hadn't installed the firmware update to be able to access the console
> so as to figure out what went wrong, that essentially bricked the
> machine.
> 
> If there was a supported and tested way to upgrade older armel
> installations on hardware that actually works with armhf, then those
> machines wouldn't need to be able to run armel anymore, and part of this
> problem would go away...

I actually highly doubt there are that many armv7 boxes running armel.
armhf was a nice performance improvement and worth the hassle to reinstall
if you had such a box in the first place.  I think most armel systems
are probably armv5, often the marvell chips.  Not sure if anyone is
running it on Raspberry pi (Original, not 2 or 3) systems or if those
all run Rasbian armhf instead.

-- 
Len Sorensen

Re: Samba version in armhf?

[Lennart Sorensen]

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, but that is for sure personal. For
> an LTS distro you may want to be conservative and choose the opposite order,
> but an EOL release is imho not a good idea as it does not even get security
> fixes.

Just because upstream doesn't release security updates for 4.2 anymore
does not mean the debian security team doesn't port the fixes to 4.2
for jessie.

Looking at the changelog, they have clearly been doing so.

New versions introduce new bugs, and in a stable release, that is not
what you want.

-- 
Len Sorensen

Re: Debian, Qemu, KVM and Raspberry Pi

[Lennart Sorensen]

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 apparently been built with KVM etc.,
> what's the best way to test that it exposes the required functionality?
> 
> *  What's the recommended Debian guest, and am I correct in assuming that
> the only indication of whether it's using KVM etc. is its speed of
> execution?
> 
> I'm interested in embedding a low-traffic DMZ in a firewall, I think Qemu is
> adequate for this but wouldn't trust weaker containerisation.

KVM on arm requires:

CPUs booted in HYP mode (so boot loader has to be done right).

Kernel built with VGIC support (or in the case of the RPi 2 and 3
with emulated VGIC since it doesn't have the normal VGIC that most arm
chips have).

Either a 64 bit kernel or an lpae kernel.

New enough qemu to have support for kvm on arm (not usually a problem
anymore).  RPi2/3 requires a patched one since the emulated VGIC
apparently requires qemu to be tied to specific cores so that the first
core can stay responsible for the VGIC emulation and not confuse qemu.

Really the RPi2/3 is just too weird to really support KVM due to the
lack of standard expected arm cpu features.  I don't expect it to ever
have mainline kernel and qemu support due to those hardware deficiensies.

If you have an arm system that boots with the cpu in HYP mode and have
a kernel with KVM support enabled.  I see the armhf lpae kernel has KVM
support enabled in debian.  I don't see it in the arm64 kernel config,
so it is not enabled there yet.  Probably should be.

If you have that, then you should be able to run qemu with the -enable-kvm
flag and it should work.

-- 
Len Sorensen

Re: Debian, Qemu, KVM and Raspberry Pi

[Lennart Sorensen]

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 easy.

Even looks like the current emulation patch is mutually exclusive with
normal VGIC support in the kernel, so not something ready to go in at
this point.

-- 
Len Sorensen

Re: Debian and QEMU virtio-net-device

[Lennart Sorensen]

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 console=ttyAMA0,115200 \
> -dtb /export/armmp/vexpress-v2p-ca9.dtb \
> -net nic,model=lan9118,netdev=net0 \
> -netdev user,id=net0 \
> -monitor stdio
> 
> I have also tried without the last three lines, with
> 
> -append root=/dev/mmcblk0p2
> 
> both with and without the console parameter,
> 
> and
> 
> -append root=/dev/mmcblk0
> 
> (didn't expect this to work - but worth a try).
> 
> None of them give me anything but a blank qemu window. The qemu monitor
> says the process is running, but no indication that it's doing anything.
> 
> I also remounted the qemu disk and verified the initrd, vmlinuz and .dtb
> files matched those downloaded, just in case I corrupted something along
> the way.
> 
> There's got to be something very basic I'm missing here, but I have no
> idea what it is.

Try hitting control+alt+3 to get to the virtual serial port in qemu.
Normally graphics is 1, monitor is 2, and serial port is 3.  Works for me.

Could of course be on 2 given the -monitor stdio passed.

-- 
Len Sorensen

Re: Debian and QEMU virtio-net-device

[Lennart Sorensen]

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 /export/boot/vmlinuz \
> -initrd /export/boot/initrd.img \
> -append "root=/dev/mmcblk0p2" \
> -monitor stdio \
> -netdev bridge,br=bridge0,id=net0,helper=/usr/lib/qemu/qemu-bridge-helper \
> -device virtio-net-device,netdev=net0,mac=DE:AD:BE:EF:37:30

Could you try adding -dtb with the right dtb for that machine?
ARM kernels really want a DTB to control all the busses and devices
in general.

Did you append the dtb to the kernel instead or something?  I can't even
get qemu to boot without the -dtb.  Of course I also get no output unless
I pass a console argument to the kernel.

I don't have a bridge setup, but using -netdev user instead of -netdev
bridge, I get working networking.

With working virtio net you will see NOTHING in dmesg.  It doesn't
print anything.  'ip link' will show eth0 however, and if your bridge
setup is done right, it will work.  Trying user mode first is a lot
simpler and an easier way to check if the virtio is working first before
worrying about the bridge setup.

The smx device is a different one, and not the one used by virtio.

-- 
Len Sorensen

Re: Debian and QEMU virtio-net-device

[Lennart Sorensen]

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 specify a virtio-net-device
> > > (so I can bridge to the host nic), I get no nic.
> 
> [...]
> > > -netdev
> > > -bridge,br=bridge0,id=net0,helper=/usr/lib/qemu/qemu-bridge-helper
> > > -\ device virtio-net-device,netdev=net0,mac=DE:AD:BE:EF:37:30 \
> 
> Could you try with another macadress ?
> 
> Here (on amd64, though), sometimes qemu doesn't like some macadress,
> dunno why...
> 
> The tool 'macchanger' can create a valid one.

I tried with that mac address and I did not see a problem with that.

-- 
Len Sorensen

Re: Debian, Qemu, KVM and Raspberry Pi

[Lennart Sorensen]

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/
> 
> http://blog.flexvdi.com/2015/03/17/enabling-kvm-virtualization-on-the-raspberry-pi-2/
> and related pages describes getting Qemu+KVM running on an RPi2.

Wow I did not know it used a non standard interrupt controller.  Ouch that
would make it painful.

> Has anybody done this, are there comparable instructions for an RPi3, and-
> above all- is there a straightforward kernel release suitable for host and
> guest?
> 
> I've had it working after a fashion on an RPi2, but I found the process of
> working out how the standard kernel was built and then merging patches from
> GOK where to be painful.

I suspect it would be quite similar between the Pi2 and pi3, although
who knows, there could be more small differences showing up.

I have only run kvm for arm on an AM572x which has a standard interrupt
controller and hence was not too bad to get going.

-- 
Len Sorensen

Re: Debian and QEMU virtio-net-device

[Lennart Sorensen]

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 specify a virtio-net-device (so I can bridge to
> the host nic), I get no nic.
> 
> The nic is defined in the QEMU startup with:
> 
> -netdev bridge,br=bridge0,id=net0,helper=/usr/lib/qemu/qemu-bridge-helper \
> -device virtio-net-device,netdev=net0,mac=DE:AD:BE:EF:37:30 \

Without the rest of the command line it is hard to know.

This works for me:

qemu-system-arm -machine vexpress-a15 \
-device virtio-net-device,netdev=net0 -netdev type=user,id=net0 \
-dtb vexpress-v2p-ca15-tc1.dtb -kernel vmlinuz -initrd initrd.gz \
-drive file=debian-8.6.0-armhf-netinst.iso,if=none,id=cd \
-device virtio-scsi-device -device scsi-cd,drive=cd \
-append "console=ttyAMA0" -nographic

Of course adding a hard disk would be useful.

So what system were you emulating?

-- 
Len Sorensen

Re: Debian on Qnap TS-109

[Lennart Sorensen]

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 can't log in through SSH using root user. It denies me access even when I 
> use the password set during setup. I can log in using the standard user, and 
> perform "su" to get to root. How come root can't log in directly?
> More annoyingly, it beeps every two minutes for unknown reasons. 
> The "status" LED is flashing red. LAN LED is off, although the NAS does 
> receive a valid IP address on the LAN.
> I shut down the NAS, disconnected network cable, then turned it back on using 
> the button, and connected the network cable. 

There is a setting by default in /etc/ssh/sshd_config:

PermitRootLogin prohibit-password

That means root user can only login with a key, not with a password.
Other users can login either way.

If you want the old behaviour that used to be the default, you would
have to change the setting to yes.

-- 
Len Sorensen

Re: Gigabyte MP30-AR1

[Lennart Sorensen]

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 begin with.  It seems
it is being worked on to fix that.

You would think after running into trouble so many times over the decades
people would have stopped doing flags in the top bits of pointers by now,
but no, some people just can't leave those "unused" bits alone.

-- 
Len Sorensen

Re: Gigabyte MP30-AR1

[Lennart Sorensen]

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 debian kernels, and even the Centos one for that matter.

-- 
Len Sorensen

Re: Gigabyte MP30-AR1

[Lennart Sorensen]

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] Initializing cgroup subsys cpuset
> [0.00] Initializing cgroup subsys cpu
> [0.00] Initializing cgroup subsys cpuacct
> [0.00] Linux version 4.2.0-0.27.el7.1.aarch64
> (mockbu...@apmb0.centos.lab) (gcc version 4.8.5 20150623 (Red Hat 4.8.5-4)
> (GCC) ) #1 SMP Tue Mar 22 15:55:54 CDT 2016
> [0.00] CPU: AArch64 Processor [500f0001] revision 1
> [0.00] Detected PIPT I-cache on CPU0
> [0.00] efi: Getting EFI parameters from FDT:
> [0.00] EFI v2.40 by American Megatrends
> [0.00] efi:  ACPI 2.0=0x807ff43000  ESRT=0x807e161e18  SMBIOS 
> 3.0=0x807e161c18
> [0.00] Reserving 2048MB of memory at 30720MB for crashkernel

It steals 2GB of ram for the crashkernel?  That seems greedy.

> [0.00] cma: Reserved 512 MiB at 0xc000
> [0.00] ACPI: Early table checksum verification disabled
> [0.00] ACPI: RSDP 0x00807FF43000 24 (v02 ALASKA)
> [0.00] ACPI: XSDT 0x00807FF43028 74 (v01 ALASKA A M I
> 01072009 AMI  00010013)
> [0.00] ACPI: FACP 0x00807FF430A0 00010C (v05 ALASKA A M I
> 01072009 AMI  00010013)
> [0.00] ACPI: DSDT 0x00807FF431B0 0054A2 (v05 ALASKA A M I
> 0001 INTL 20130517)
> [0.00] ACPI: GTDT 0x00807FF48658 E0 (v01 ALASKA A M I
> 0001 AMI  00010013)
> [0.00] ACPI: MCFG 0x00807FF48738 7C (v01 APMXGENE
> 0001 AMI  00010013)
> [0.00] ACPI: FIDT 0x00807FF487B8 9C (v01 ALASKA A M I
> 01072009 AMI  00010013)
> [0.00] ACPI: SPMI 0x00807FF48858 41 (v05 ALASKA A M I
>  AMI. )
> [0.00] ACPI: APIC 0x00807FF488A0 0002A4 (v03 APMXGENE
> 0003  0113)
> [0.00] ACPI: SSDT 0x00807FF48B48 78 (v02 REDHAT MACADDRS
> 0001  0113)
> [0.00] ACPI: SSDT 0x00807FF48BC0 32 (v02 REDHAT UARTCLKS
> 0001  0113)
> [0.00] ACPI: SPCR 0x00807FF48BF8 50 (v02 A M I  APTIO V
> 01072009 AMI. 0005000B)
> [0.00] ACPI: BGRT 0x00807FF48C48 38 (v01 ALASKA A M I
> 01072009 AMI  00010013)
> 
> Lots more mentions of ACPI:
> 
> dmesg | grep ACPI
> 
> 
> [0.00] efi:  ACPI 2.0=0x807ff43000  ESRT=0x807e161e18  SMBIOS 
> 3.0=0x807e161c18
> [0.00] ACPI: Early table checksum verification disabled
> [0.00] ACPI: RSDP 0x00807FF43000 24 (v02 ALASKA)
> [0.00] ACPI: XSDT 0x00807FF43028 74 (v01 ALASKA A M I
> 01072009 AMI  00010013)
> [0.00] ACPI: FACP 0x00807FF430A0 00010C (v05 ALASKA A M I
> 01072009 AMI  00010013)
> [0.00] ACPI: DSDT 0x00807FF431B0 0054A2 (v05 ALASKA A M I
> 0001 INTL 20130517)
> [0.00] ACPI: GTDT 0x00807FF48658 E0 (v01 ALASKA A M I
> 0001 AMI  00010013)
> [0.00] ACPI: MCFG 0x00807FF48738 7C (v01 APMXGENE
> 0001 AMI  00010013)
> [0.00] ACPI: FIDT 0x00807FF487B8 9C (v01 ALASKA A M I
> 01072009 AMI  00010013)
> [0.00] ACPI: SPMI 0x00807FF48858 41 (v05 ALASKA A M I
>  AMI. )
> [0.00] ACPI: APIC 0x00807FF488A0 0002A4 (v03 APMXGENE
> 0003  0113)
> [0.00] ACPI: SSDT 0x00807FF48B48 78 (v02 REDHAT MACADDRS
> 0001  0113)
> [0.00] ACPI: SSDT 0x00807FF48BC0 32 (v02 REDHAT UARTCLKS
> 0001  0113)
> [0.00] ACPI: SPCR 0x00807FF48BF8 50 (v02 A M I  APTIO V
> 01072009 AMI. 0005000B)
> [0.00] ACPI: BGRT 0x00807FF48C48 38 (v01 ALASKA A M I
> 01072009 AMI  00010013)
> [0.00] psci: is not implemented in ACPI.
> [0.00] smp_parking_protocol_cpu_init: ACPI parked addr=80009000
> [0.00] smp_parking_protocol_cpu_init: ACPI parked addr=8000a000
> [0.00] smp_parking_protocol_cpu_init: ACPI parked addr=8000b000
> [0.00] smp_parking_protocol_cpu_init: ACPI parked addr=8000c000
> [0.00] smp_parking_protocol_cpu_init: ACPI parked addr=8000d000
> [0.00] smp_parking_protocol_cpu_init: ACPI parked addr=8000e000
> [0.00] smp_parking_protocol_cpu_init: ACPI parked addr=8000f000
> [0.000138] ACPI: Core revision 20150619
> [0.004761] ACPI: All ACPI Tables successfully acquired
> [0.028062] ACPI: bus type PCI registered
> [0.028066] acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5
> [0.028071] ACPI: IORT: Failed to get table, AE_NOT_FOUND
> [0.054416] ACPI: Added _OSI(Module Device)
> [0.054421] ACPI: Added _OSI(Processor Device)
> [0.054423] ACPI: Added _OSI(3.0 _SCP Extensions)
> [0.054425] ACPI: Added _OSI(Processor Aggregator Device)
> [0.063243] ACPI: 

Re: Gigabyte MP30-AR1

[Lennart Sorensen]

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 version
> F01 from http://b2b.gigabyte.com/products/product-page.aspx?pid=5912#bios .
> Any idea if that is supposed to fix the DTB?  There doesn't seem to be
> a changelog :-(
> 
> Do you think that the broken DTB would explain the issue I was seeing?
> 
> (I don't think you mean BMC firmware, but if you do I've not updated
> that - and I've now managed to brick the BMC by attempting to change it
> to "shared network" mode, which seems not to work on this hardware.
> Hopefully I will eventually find some way to reset it back to dedicated
> network mode...)
> 
> >therefore using ACPI boot is recommended,
> >however it is not supported until 4.7 kernel series, and then you'll
> >find #834505 (TL,DR; needs to enable ACPI and relocate initramfs
> >within first 32GB of RAM address space). Given all that machine should
> >boot.
> 
> Ha OK, I was vaguely aware that there was a setting for ACPI or device tree
> and I was going to try changing it - but maybe there isn't much hope!
> 
> Hector, is it you that has been getting the board mentioned in that bug
> working?  What's the easiest way for me to duplicate what you've done?

Well since sid has 4.7 kernel, maybe the daily build of the installer
has 4.7 kernel.  Hmm, no, just checked, they are 4.6 still.  Too bad.

-- 
Len Sorensen

Re: Gigabyte MP30-AR1

[Lennart Sorensen]

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 the previous MP30-AR0.  The difference between the -AR0 and
> the -AR1 is that mine ships with UEFI, while the earlier board shipped
> with U-Boot.  I think that apart from that the boards are identical.
> 
> So far my attempts at installing Debian have not been successful.
> I have, however, managed to install CentOS!  So there is hope.  In
> each case I've put an ISO image onto a flash drive; UEFI has detected
> this and presented it in its boot menu.  Then GRUB runs successfully,
> but it seems to fail to start the installer's kernel; with the current
> strech/sid installer mini.iso 
> (http://ftp.debian.org/debian/dists/sid/main/installer-arm64/current/images/netboot/mini.iso)
> I get:
> 
> EFI stub: Booting Linux Kernel...
> ConvertPages: Incompatible memory types
> EFI stub: EFI_RNG_PROTOCOL unavailable, no randomness supplied
> EFI stub: Using DTB from configuration table
> EFI stub: Exiting boot services and installing virtual address map...
> OSBootEvent = Success
> L3c Cache: 8MB

My understanding is that UEFI on arm can provide either a FDT or ACPI
(Doing both means ACPI is used and FDT ignored).  So that message about
using the DTB from the config table sounds like the kernel found the FDT
(flattened device tree).

I must admit I am not sure if those message are from UEFI, the boot
loader, or the kernel.  I haven't checked if Debian's arm64 installer
is supposed to work with UEFI yet.  The ports page seems to indicate it
does on at least some machines.

> One possibility is that I just need to supply a suitable console=
> argument to the installer kernel command line; this seemed to help in
> some of the -AR0 installation reports.  I've tried various things but
> none of them help.  Maybe I just don't know what the installer kernel
> thinks the serial port is called.

That is quite possible.  If you boot the centos installer, can you ask
it what /proc/cmdline says the console is?  Or check dmseg.

> Another thought is related to device tree blobs.  I see that the ISO
> image contains DTBs for various boards, including the X-Gene Mustang,
> but not for this board.  How are device trees supposed to work with
> UEFI?  Does the ISO image have to provide it?

No UEFI is supposed to provide it.

> Or perhaps there is something else I've overlooked.  What do you suggest?
> (Where do the experts on X-Gene and UEFI etc. hang out?) Perhaps it
> would be easiest to debootstrap from CentOS!

Hopefully it won't be that bad. :)

-- 
Len Sorensen

Re: Broadcom BCM2709, ARMv8, and missing CPU features

[Lennart Sorensen]

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
> power (battery life) really matters.  i think it was on anandtech or
> something.

Well the 64 bit equivalant of the A7 would be the A35.  The A53 is higher
level, more like an A9 I would think while the A57 is A15 type of
performance level and A72 probably maps to about A17, or maybe even
better.

Certainly in terms of MIPS/MHz, the A53 is between the A8 and A9, while
the A57 is A15/A17 level, and the A72 is quite a bit faster than the rest.
Apparently there is an A73 coming that adds another 30% performance over
the A72.

The A35 is supposed to be 6 to 40% better performance than the A7 at
the same power.

-- 
Len Sorensen

Re: Broadcom BCM2709, ARMv8, and missing CPU features

[Lennart Sorensen]

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 image for every brand of motherboard and CPU,
> they probe to see what hardware is there.  I wouldn't expect older
> images to contain drivers for newer hardware maybe.
> 
> I guess I wouldn't make too much of the jump to 64 bit just yet.  I
> remember when i386 jumped to 32 bit.  16 bit had a messy segmented
> memory addressing scheme I was glad to get away from.  I can't afford
> more than 32 bits worth of RAM anyway, especially since I've usually
> got about 4 machines running.

Well it isn't actually just a question of memory (most 8bit CPUs had 16
bit address space, and many 16 bit CPUs had 24 or 32 bit address space,
and some 32 bit x86 and arm chips can do 36 or 40 bit address space
physically).  What you often gain going to a 64 bit CPU is the ability
to do 64 bit arithmetic in one instruction, and store the variables
in one register rather than two, rather than a bunch of stuff the
compiler generates for you.  After all if you take two 64 bit integrs
and try to multiply them on a 32 bit CPU, most of the time you end up
with numerous multiply, shift, add, mask, instructions to implement
the calculation using 32 bit only instructions, while on a 64 bit CPU
usually it is just one instruction.  So the 64 bit CPU will probably do
the calculation faster than the 32 bit CPU.  Of course if you only need
32 bit calculations, then it doesn't matter, so in many cases it isn't an
issue, but when it matters it can really make a difference in performance.

-- 
Len Sorensen

Re: Debian on RPi

[Lennart Sorensen]

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
> runs fine on pukka Debian I've had very little success with Raspbian.

Well debian armhf won't run on the RPi (only RPi 2 and 3) no matter what
you do.

Debian armel would run, but be slower for some things (mainly floating
point things), although not using thunmb2 would probably make it slower
at all things, not that the RPi 1 has support for that.

Geneerally I would think Raspbian is the right thing to use and if it
has bugs those are worth getting fixed.

-- 
Len Sorensen