Re: Fork of current version of »hfs« package

[Lennart Sorensen]

On Tue, May 30, 2023 at 09:24:42PM -0400, Jeffrey Walton wrote:
> Blocks are like C++ lamda's. ObjC folks like to use them to ensure
> cleanup in a function, like releasing a handle or free'ing memory.

Funny how the high level description of them couldn't even bother so
explain that.  That does make some sense.

-- 
Len Sorensen

Re: Fork of current version of »hfs« package

[Lennart Sorensen]

On Tue, May 30, 2023 at 01:24:15PM +0200, John Paul Adrian Glaubitz wrote:
> Hello!
> 
> I have started working on an updated »hfsprogs« packages based on the
> split-out version of the HFS(+) code in the »hfs« package. For this,
> I have forked Apple's original »hfs« package on Github [1].
> 
> Feel free to start contributing. It's currently work-in-progress as
> »fsck_hfs« does not compile yet and the code needs further clean-up
> which I will be doing later this week.
> 
> Adrian
> 
> > [1] https://github.com/glaubitz/hfs/tree/linux

I had a poke at it, dealt with a couple of compile issues, then
encountered Blocks and went WTF did Apple invent here?  I don't even
understand the description of their proprietary extension to C/C++/ObjC.

I had never seen code with ^ prefixed to things in this way and since I
don't understand what Blocks are supposed to accomplish I have no idea
how to remove them from the code.

-- 
Len Sorensen

Re: Why it's so difficult to fix PowerMac booting for good

[Lennart Sorensen]

On Fri, May 26, 2023 at 02:14:16PM +0200, Frank Scheiner wrote:
> As per `grub-install(8)`:
> 
> ```
> grub-install copies GRUB images into boot/grub.
> ```
> 
> As the call to `grub-install` is performed by `chroot` inside the root
> FS of the new installation, I assume the FAT bootstrap partition is
> already mounted as `/boot` at this time of the installation. I think
> this happens after all data partitions were formatted earlier during the
> Debian installation but before any files are installed. Thus making the
> call succeed w/o an explicit boot device or target directory argument.

I am pretty sure /boot can NOT be fat since it has to store files from
packages (like the kernel).  /boot/grub on the other hand might be able
to be fat.  Similar to how you can have /boot/efi be fat on x86 but not
/boot itself.

-- 
Len Sorensen

Re: Debian on IBM RS/6000 7248-43p

[Lennart Sorensen]

On Thu, May 11, 2023 at 02:05:01PM +0200, Gabriel Paubert wrote:
> That might be possible, but you need a PReP boot partition on your
> disk (type 0x41), to which you directly copy the kernel if memory
> serves.

Later releases put yaboot or grub2 on that partition so you actually
got a proper boot menu.

But yes, it simply loads and executes whatever binary is written raw to
that partition.  Could be a kernel, could be a boot loader.

-- 
Len Sorensen

Re: Debian on IBM RS/6000 7248-43p

[Lennart Sorensen]

On Thu, May 11, 2023 at 12:01:45PM +0200, Alexander Huemer wrote:
> I am the proud owner of this ancient machine on which I am attempting to 
> install Debian. This machine is equipped with a Gotek floppy emulator 
> and a ZuluSCSI emulator (for HDD and CD-ROM) for convenience reasons.
> For reference, this is a 32bit PowerPC machine following the PReP[1] 
> specification.
> 
> [2] says:
> > Debian on 32-bit PowerPC (powerpc)
> 
> > It first became an official "release architecture" with Debian 
> > GNU/Linux 2.2 ("potato") and had retained that status until the 
> > publication of Debian 9 ("stretch"). The last supported release for 
> > 32-bit PowerPC is Debian 8 ("jessie"). See the release note and 
> > installation manual for further information. 
> 
> Therefore I am focusing on Jessie.
> [3] is rather sparse on details regarding installation media options.

Well I have seen lots of people say woody worked on that machine.
Not sure how late support for that hardware stuck around.  After all
192MB ram and 133MHz 604 is not a lot of resources.  I am not sure how
late Debian would have supported installing on a machine with that little
ram, assuming you have it maxed out, which it might not be.

> Does this apply to my machine? I don't know. Where would I find the 
> respective floppy image? [4] doesn't have a 'floppy' folder or something 
> similar.

It should not apply to this machine as far as I can tell.  Yeah no floppy
based installer for debian for a long time.

> > CD-ROM based installation is supported for most architectures.
> 
> Again, I don't know if CD-ROM based installation is expected work on 
> PReP. [5] doesn't contain any ISO images. I've tried [6] though that 
> doesn't boot.

>From what I can find, that machine does boot from CD.

> I've tried the image contained in the .gz at [7], though that doesn't 
> boot either. There are several other files at the parent directory of 
> [7]. I am not sure what to do with them though.
> 
> Then there is [8]. Way older Debian release, but worth a try. The link 
> to floppy images doesn't work anymore, but IA has a copy, see [9].
> The image debian-7248-boot.img isn't recognized by the FlashFloppy 
> firmware as being a valid floppy image, hence it doesn't boot. It's 
> unclear to me what the problem with the image is, `file` recognizes it 
> just fine.
> 
> > $ file debian-7248-boot.img
> > debian-7248-boot.img: DOS/MBR boot sector; partition 1 : ID=0x41, 
> > active, start-CHS (0x0,0,2), end-CHS (0x4f,1,18), startsector 0, 2879 
> > sectors
> 
> Now I don't know what else to try anymore. If anybody is reading this 
> who has worked on a 43p before, I'd appreciate any pointers.

Well certainly a partition with type 0x41 is in fact what an IBM PReP
machine boots from.  So that does look like a bootable harddisk image.

I have not worked with such a machine, the earliest I have used was
a power6 machine, although they are still PReP and boot from the same
partition type.  Way more RAM and CPU though.

Maybe you should try woody first to see if you can get it to boot at all,
just to run something other people have said worked on it.  It ought to
boot from the CD, but woody also has floppy imags if you have to resort
to that.  At least you can find out if the machine boots at all.

I suspect you could netboot it using tftp/bootp as well but that shouldn't
be necesary.

-- 
Len Sorensen

Re: Why it's so difficult to fix PowerMac booting for good

[Lennart Sorensen]

On Wed, May 10, 2023 at 04:58:06PM +0200, John Paul Adrian Glaubitz wrote:
> Well, it works with ISO images, that's the point. The installation CDs use 
> iso9660
> as their filesystem and they have a blessed bootloader which shows in the 
> firmware's
> boot menu.
> 
> Thomas Schmitt briefly explained how xorriso does it, but I don't really 
> understand
> the underlying concept yet but I would assume you could use it for booting 
> using a
> FAT16 partition as well.

It makes the CD contain both HFS+ and ISO9660 filesystem (sharing the
same data blocks) and of course by having HFS+ it means you can bless
a boot file.  So in fact it is not working with iso9660, it is working
with HFS+.  Hybrid CDs are interesting.

So it seems the only way to not use nvram settings for booting is with
a blessed boot file, and that requires HFS/HFS+, and the current tools
to manage that are apparently non-free.

-- 
Len Sorensen

Re: Off-Topic: G5 Open Firmware instability

[Lennart Sorensen]

On Fri, May 13, 2022 at 08:56:00AM -0700, to...@suse.de wrote:
> On Fri, May 13, 2022 at 03:58:08PM +0200, Frank Scheiner wrote:
> > Hi Tony,
> 
> Hi.
> 
> > Have you already looked below the cover of the cooling system? Is 
> > there any visible leakage (remove power before looking into that)? 
> 
> Yes and no.
> 
> > not, it could be that the water cooler is missing some liquid after that
> > much time which could limit its performance.
> 
> /sys/devices/platform/windfarm.0 reports 
> 
> backside-fan: 1100
> backside-temp: 57.000
> cpu-current-0: 7.566
> cpu-current-1: 8.054
> cpu-current-2: 9.277
> cpu-current-3: 9.886
> cpufreq-clamp: 0
> cpu-front-fan-0: 3104
> cpu-front-fan-1: 3104
> cpu-power-0: 9.291
> cpu-power-1: 9.891
> cpu-power-2: 12.706
> cpu-power-3: 13.179
> cpu-pump-0: 3584
> cpu-pump-1: 3584
> cpu-rear-fan-0: 3200
> cpu-rear-fan-1: 3200
> cpu-temp-0: 39.265
> cpu-temp-1: 39.625
> cpu-temp-2: 66.046
> cpu-temp-3: 70.515
> cpu-voltage-0: 1.228
> cpu-voltage-1: 1.228
> cpu-voltage-2: 1.369
> cpu-voltage-3: 1.333
> 
> 
> Clearly cpus 2/3 are running hotter.  I need to try disabling
> them (kernel cmd line or at runtime) and see if cpus 0/1 start
> running as hot. 
> 
> > * Have you checked that the radiator of the cooling system is not
> > cluttered with dust?
> 
> Yes.
> 
> > Say do you hear the fans speeding up over time?
> 
> No.  The onty time I hear the fan speed up is if the machine hangs,
> then about 45-60 seconds later it will go full.
> 
> > You can "force" the fans to run on full speed by removing the
> > transparent cover. 
> 
> I have tried this.  No change.
> 
> > or longer that way, I'd say there's definitely something wrong with 
> > your cooling system.
> 
> Clearly there is. My concern however is that I have two issues and
> the OF one is distinct from the cooling one. The machine can boot into 
> the existing Linux (from SATA) and stay up indefinitely (if load av < 
> 1.5) but from a cold boot, will hang in OF in under 1 minute.  Maybe 
> Forth is a real resource hog :-)

It is certainly not unusual for firmware to run on a single core at 100%
(implementing idle handling and interrupts and such is just considered
too much hassle for something that isn't normally going to run).
So yeah it is actually not unlikely that openfirmware would cause the
CPU to run hot compared to linux at low load.

-- 
Len Sorensen

Re: after Debian update most apps crash - libffi issue?

[Lennart Sorensen]

On Tue, Sep 28, 2021 at 10:27:59PM +0200, John Paul Adrian Glaubitz wrote:
> Yes. And this is not acceptable because they are manipulating the baseline.
> 
> Thanks for catching this. This is our bug!

I would be surprised if powerpc is the only architecture bitten by this.
What is i386 being compiled with?

-- 
Len Sorensen

Re: after Debian update most apps crash - libffi issue?

[Lennart Sorensen]

On Tue, Sep 28, 2021 at 04:26:04PM -0400, Lennart Sorensen wrote:
> On Tue, Sep 28, 2021 at 09:34:23PM +0200, John Paul Adrian Glaubitz wrote:
> > OK. I'm regenerating the chroots on the build servers now and then
> > trigger another rebuild of the package. If that still doesn't help,
> > we know there is some runtime detection which enables these instructions
> > during build and I have to start looking into the source code.
> 
> Would this be a problem:
> 
>   powerpc*)
>  cputype=`((grep cpu /proc/cpuinfo | head -n 1 | cut -d: -f2 | cut -d, 
> -f1 | $SED 's/ //g') ; /usr/bin/machine ; /bin/machine; grep CPU 
> /var/run/dmesg.boot | head -n 1 | cut -d" " -f2) 2> /dev/null`
>  cputype=`echo $cputype | $SED -e 's/ppc//g;s/ *//g'`
>  case $cputype in
>*750*) ax_gcc_arch="750 G3" ;;
>*740[[0-9]]*) ax_gcc_arch="$cputype 7400 G4" ;;
>*74[[4-5]][[0-9]]*) ax_gcc_arch="$cputype 7450 G4" ;;
>*74[[0-9]][[0-9]]*) ax_gcc_arch="$cputype G4" ;;
>*970*) ax_gcc_arch="970 G5 power4";;
>*POWER4*|*power4*|*gq*) ax_gcc_arch="power4 970";;
>*POWER5*|*power5*|*gr*|*gs*) ax_gcc_arch="power5 power4 970";;
>603ev|8240) ax_gcc_arch="$cputype 603e 603";;
>*POWER7*) ax_gcc_arch="power7";;
>*POWER8*) ax_gcc_arch="power8";;
>*POWER9*) ax_gcc_arch="power9";;
>*POWER10*) ax_gcc_arch="power10";;
>*) ax_gcc_arch=$cputype ;;
>  esac
>  ax_gcc_arch="$ax_gcc_arch powerpc"
>  ;;
> 
> I saw that in m4/ax_gcc_archflag.m4
> 
> I guess related would be this configure option:
>   --with-gcc-arch=  use architecture  for gcc -march/-mtune,
>   instead of guessing

Or maybe:
  --enable-portable-binary
  disable compiler optimizations that would produce
  unportable binaries

-- 
Len Sorensen

Re: after Debian update most apps crash - libffi issue?

[Lennart Sorensen]

On Tue, Sep 28, 2021 at 09:34:23PM +0200, John Paul Adrian Glaubitz wrote:
> OK. I'm regenerating the chroots on the build servers now and then
> trigger another rebuild of the package. If that still doesn't help,
> we know there is some runtime detection which enables these instructions
> during build and I have to start looking into the source code.

Would this be a problem:

  powerpc*)
 cputype=`((grep cpu /proc/cpuinfo | head -n 1 | cut -d: -f2 | cut -d, -f1 
| $SED 's/ //g') ; /usr/bin/machine ; /bin/machine; grep CPU 
/var/run/dmesg.boot | head -n 1 | cut -d" " -f2) 2> /dev/null`
 cputype=`echo $cputype | $SED -e 's/ppc//g;s/ *//g'`
 case $cputype in
   *750*) ax_gcc_arch="750 G3" ;;
   *740[[0-9]]*) ax_gcc_arch="$cputype 7400 G4" ;;
   *74[[4-5]][[0-9]]*) ax_gcc_arch="$cputype 7450 G4" ;;
   *74[[0-9]][[0-9]]*) ax_gcc_arch="$cputype G4" ;;
   *970*) ax_gcc_arch="970 G5 power4";;
   *POWER4*|*power4*|*gq*) ax_gcc_arch="power4 970";;
   *POWER5*|*power5*|*gr*|*gs*) ax_gcc_arch="power5 power4 970";;
   603ev|8240) ax_gcc_arch="$cputype 603e 603";;
   *POWER7*) ax_gcc_arch="power7";;
   *POWER8*) ax_gcc_arch="power8";;
   *POWER9*) ax_gcc_arch="power9";;
   *POWER10*) ax_gcc_arch="power10";;
   *) ax_gcc_arch=$cputype ;;
 esac
 ax_gcc_arch="$ax_gcc_arch powerpc"
 ;;

I saw that in m4/ax_gcc_archflag.m4

I guess related would be this configure option:
  --with-gcc-arch=  use architecture  for gcc -march/-mtune,
  instead of guessing

-- 
Len Sorensen

Re: package containing icu-config

[Lennart Sorensen]

On Thu, Sep 09, 2021 at 05:49:29PM +, Mick Bert wrote:
> Trying to compile a software, the configure fails complaining for missing
> icu-config. I have already installed icu-devtools and libicu-dev. Which
> package should I install?
> 
> Are there a way to query which package contains a particular file (maybe
> through apt-get or apt-cache, or even a service on the web)?

apt-file search icu-config

But you won't find it since it was deprecated upstream and you are
supposed to use pkg-config now with libicu.  icu-config wasn't multiarch
compatible it seems.  Most software using libicu seems to ahve updated
by now to using pkg-config.

-- 
Len Sorensen

Re: [Pkg-javascript-devel] Bug#991638: nodejs: Please enable build on 32-bit PowerPC (powerpc)

[Lennart Sorensen]

On Thu, Jul 29, 2021 at 10:23:38PM +0200, John Paul Adrian Glaubitz wrote:
> It should work on the standard 32-bit PowerPC baseline which includes
> AltiVec. Other systems such as PowerPC E500 had their own Debian port
> anyway (powerpcspe).

32 bit powerpc does not require altivec.  e300 runs it fine and sure
doesn't have altivec.  G3 powermac had no altivec either.  A few packages
(like vlc for example) are broken and assume altivec is always present.

powerpcspe was for the offshoot that didn't use the normal FPU (had a
signal processor instruction set instead) like the e500 (but not e500mc).

-- 
Len Sorensen

Re: Altivec in baseline for ppc64?

[Lennart Sorensen]

On Fri, Jul 16, 2021 at 01:08:47PM +0200, John Paul Adrian Glaubitz wrote:
> Well, you could have runtime detection like certain multimedia codes and 
> OpenSSL use but
> most packages don't do that.
> 
> Either way, if certain downstreams want better support for certain targets, 
> they are always
> welcome to jump in and send patches to me or upstream. This port is a 
> community effort,
> after all.

Some years ago I tried to get such runtime detection added for vlc.
Upstream was certainly far from helpful and just about hostile to the
idea of adding runtime detection code on powerpc.  Given I was just
trying to help out the people hitting a problem with it (I don't have
any desktop powerpc, I only deal with embedded), I decided it wasn't
worth my effort to argue with them.

-- 
Len Sorensen

Re: Bug#989645: /usr/sbin/grub-mkconfig: dpkg: error processing package linux-image-powerpc (--configure):

[Lennart Sorensen]

On Fri, Jun 11, 2021 at 08:03:38AM -0600, Stan Johnson wrote:
> Some people find it to be important to install only free software.
> 
> If hfsprogs were truly non-free, then an alternative would need to be
> found, since hfsprogs provides required functionality.
> 
> I read the above links, which lead to this analysis:
> 
> https://lists.debian.org/debian-legal/2004/06/msg00573.html
> 
> Is it really correct that debian-legal has concluded that hfsprogs is
> not DFSG-free?  Or is the above analysis an opinion from someone who is
> not a Debian lawyer?
> 
> In this case, the Free Software Foundation (FSF) disagrees, saying "The
> Apple Public Source License (APSL) version 2.0 qualifies as a free
> software license. Apple's lawyers worked with the FSF to produce a
> license that would qualify."
> 
> https://www.gnu.org/philosophy/apsl.en.html
> 
> I would generally accept FSF legal analyses and opinions over the legal
> (or non-legal) analyses and opinions from anyone associated with any
> specific GNU/Linux distribution.

FSF created a documentation license that is non-free in Debian.  So FSF
doesn't seem like a good judge of what is or is not free.  Their focus
is a lot more narrow than Debian's in terms of what freedom's users
should have.

Reading the entry from debian-legal, I would think that it is absolutely
correct that it is non-free in Debian.

-- 
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: Donations

[Lennart Sorensen]

On Fri, Mar 05, 2021 at 12:17:25PM +0100, John Paul Adrian Glaubitz wrote:
> Thanks for the support!
> 
> Since original discussion evolved around the G3 beige model, I would prefer 
> if the community found a cheap G3 beige model to work on for me.
> 
> Also, the G3 beige tower takes less space as compared to the iMac.
> 
> Would that be ok?

I was thinking an imac was an awfully large beast when I saw the picture
in the link yesterday.  CRTs are a pain. :)

-- 
Len Sorensen

Re: Debian Sid PPC64 / IBM pSeries 550 --- Bootloaders don't work after succesful install

[Lennart Sorensen]

On Wed, Nov 04, 2020 at 02:48:03PM +, Deinsti Suski wrote:
> Hello Len
> 
> 1; Yes, we are using the MBR Partition table
> 2; the PreP partition is 8MB and has the Boot flag set to on
> 3; Debian is running on bare-metal, no hypervisor involved
> 3; Correct, the installer boots with no issues at all and it's only after
> the reboot when try to boot the installation from the HDD that both
> bootloaders just stall/fail
> 4; We are using a 1GB USB Memory stick as the installation media
> 5; we are using the Debian 10 SID NETINST for PPC64 dated 2020-05-30, the
> reason we're not using the latest snapshot is because the latest one
> (2020-10-13) fails with 'missing-firmware /dev/.udev missing firmware' and
> the installation media fails to mount
> 
> If you need any more information don't hesitate to ask

Well you are doing everything I remember doing (although at the time I
was using powerpc not ppc64 but I doubt that matters), and I used a CD,
not USB to boot.  No idea if that makes any difference.  Hopefully it
isn't confused by which disk is sda vs sdb due to the usb stick.

I had successful installs in the past (but probably 5 or 6 years ago now)
on p520 (power6) and p710 (power7) hardware both booting from CD.

-- 
Len Sorensen

Re: Debian Sid PPC64 / IBM pSeries 550 --- Bootloaders don't work after succesful install

[Lennart Sorensen]

On Sun, Nov 01, 2020 at 09:24:08PM +, Deinsti Suski wrote:
> Recently me and a friend of mine have been trying to install Debian Sid on
> an IBM pSeries 550 server to no avail; we have attempted a variety of
> methods such as installing GRUB with everything on an / ext4 partition,
> GRUB with a separate ext2 /boot and ext4 /, Yaboot with everything on an
> ext4 / and Yaboot with a ext2 /boot and ext4 / - however none of them work;
> 
> For GRUB, it just freezes at 'Welcome to GRUB!' with no disk activity and
> it never continues no matter the partition setup while for Yaboot, it
> always fails at
> "can't get  for device: 
> :-1,ls: Unable to open file, Invalid device"
> 
> we tried altering yaboot.conf by swapping out uuid's with /dev/sda2 among
> other things but no matter what it's always the same error
> 
> The hardware is an IBM pSeries 550 Server
> Processors: 4x IBM POWER6 cards with 2-Cores at 4GHz each (Total: 8 Cores)
> RAM: 92GB
> HDD: Single 300GB drive (No RAID)
> 
> Do you have any suggestions on how to get this system to boot?

I haven't done an install in quite a few years but I have a few question:

Are you using dos partition table (MBR style)?
How large is the PREP boot partition?  Is it set as bootable?

I seem to recall an 8MB prep boot partition is pretty standard and should
be plenty for grub.

Are you running on bare metal or is there a hypervisor involved?

Does the installer boot fine and only the system after installation
won't boot?

What media are you booting the installer from?

Which installer image are you using?

-- 
Len Sorensen

Re: Debian 11 ppc64be

[Lennart Sorensen]

On Tue, Oct 27, 2020 at 07:17:34AM -0400, Dennis Clarke wrote:
> Provided you don't mind the power usage you may run Debian sid on an old
> Apple Power Mac machine just fine. In fact the Power Mac quad has decent
> performance and it is great to have around for doing code test work as
> it is big endian and has a native 65536 byte memory page size. You would
> be amazed how much software in the world is written by people on x86
> little endian with the 4Kb page size and they never ever test anywhere
> else. I also have sparc64 running Debian sid but it has some real weird
> personality issues. Also, the PowerMac quad is a strange name. Really it
> is a dual socket machine with dual cores and I think the entire machine
> architecture must have been designed by IBM. The memory is proper ECC
> memory and thus you can actually trust it. Get one and give it a whirl
> and try not to smirk at the power usage. They are very power hungry
> machines. Pretty looking but power hungry.

I have encountered plenty of software making those wrong assumptions, and
fixed some of it too.  I used to work on systems running Debian ppc (32
bit), and we used an IBM power6+ (P520) and later power7 (P710) machine
as a build box (running 32 bit ppc, with 64 bit kernel).  I did some
fixing and a lot of testing to get grub working on the IBM power boxes
because I wanted to run software raid1 and yaboot didn't do that, and
grub looked like it should work, but didn't quite.  After many patches
and tests we got it to work, and of course now grub is the default on
IBM boxes in Debian.

> I build my own kernel on that thing all the time. It rips through the
> whole build process with 2800+ modules in about 90 minutes.

I remember at one of the ottawa linux symposiums, a guy from IBM mentioned
doing a kernel compile on a P595 in a few seconds.

> enceladus$ find /lib/modules/`uname -r`/ -type f | wc -l
> 2866
> 
> However it draws 300 watts at power up and settles down to 200 watts
> just doing nothing much.

Yeah IBM powerpc chips never have been that power efficient, but they
are fast.  I have sometimes considered getting a G5 machine, but not sure
my wife would be happy with me adding more old machines to the collection.

-- 
Len Sorensen

Re: Compatible Debian PPC64 B.E for L.E servers

[Lennart Sorensen]

On Mon, Oct 26, 2020 at 05:04:48PM +0100, John Paul Adrian Glaubitz wrote:
> I had to re-read this several times and just to be clear: You can still
> run big-endian code perfectly fine on POWER8 machines and newer (unless
> IBM removed support with POWER10).

You can, but it seems very few people do.  I have not read anything to
indicate they were getting rid of big endian support.  Hopefully not.

> In fact, we are running the little-endian port on the POWER8 server we got
> from IBM to host two ppc64 big-endian KVM VMs (one buildd and one Debian
> porterbox). Although that causes the host kernel to crash regularly with
> no fix in sight yet, unfortunately [1].

Ouch, that's annoying given they claim that is supposed to work just fine.

-- 
Len Sorensen

Re: Compatible Debian PPC64 B.E for L.E servers

[Lennart Sorensen]

On Sun, Oct 25, 2020 at 03:30:05PM -0300, Alexandre Bencz wrote:
> well...
> 
> this is quite interesting, even for use on Power7 servers ... I have several
> clients that use Debian on P7 and P6  so, having a compilation that uses
> the latest CPU instructions, would be interesting

Right, so already first person asked for power8 as base, you want power
7 or power 6.  Where does it end?  Power 4 seems like a good baseline,
and for the few things that matter, you can have libraries compiled for
better instruction sets that are selectively loaded.

And it seems power8+ machines really just run ppc64el because that is
what IBM wants people to run (apparently because converting the data from
big endian to little endian before passing it to an nvidia GPU that only
does little endian made a significant performance difference and there
was no reason not to switch to little endian given almost all powerpc
designs support both ways, not to mention the amount of software that
is broken on big endian because of assumptions (often implicit) by
the developers).

-- 
Len Sorensen

Re: Debian 11 ppc64be

[Lennart Sorensen]

On Mon, Oct 26, 2020 at 12:34:49AM +0100, Karl wrote:
> will there be a Debian 11 release for PPC64be again or is it Sid?
> Because on that site, it’s listed as available: 
> https://openpower.ic.unicamp.br/minicloud/

I don't recall ppc64 ever being an official released architecture.
ppc was but no longer is, and ppc64el is.

I would guess they are running the ports ppc64 build, which could
certainly be a build matching Debian 11.

-- 
Len Sorensen

Re: Installation media couldn't be mounted

[Lennart Sorensen]

On Sun, Oct 18, 2020 at 08:37:20AM -0400, Sam Imberman wrote:
> /proc/partitions:
> 
> major   minor   #blocks   name
> 11 0  1048575sr0
> 8  0   58605120  sda
> 8  16  15581184  sdb
> 8  17  318524  sdb1
> 
> Also, I uploaded screenshots of /var/log/syslog upthread, is that what you
> mean?

How did you make the bootable USB stick?  Does using dd work for a
powermac like it does on PCs?

Looking at the iso it appears to have a DOS partition table, and iso9660
header and an apple partition map.  Not sure which one the kernel decided
to use.  Certainly the size in /proc/partitions appears to agree with
the overall size and the dos partition table which should be the entire
iso file system, so mounting as iso9660 should have worked.

-- 
Len Sorensen

Re: Installation media couldn't be mounted

[Lennart Sorensen]

On Thu, Oct 15, 2020 at 11:59:32AM -0400, Sam Imberman wrote:
> Thanks for your response!
> The image is the one available at:
> https://cdimage.debian.org/cdimage/ports/10.0/powerpc/iso-cd/debian-10.0-powerpc-NETINST-1.iso
> 
> When I try to mount /dev/sdb1 manually using `mount /dev/sdb1 /cdrom` (or
> with `-t vfat`) -- I have: "Mounting /dev/sdb1 on /cdrom failed: No such
> file or directory". I have verified that /cdrom is present and writable,
> and /dev/sdb1 seems to be the right device.A

I would have expected -t isofs or something like that.  Does /cdrom even
exist then?

What does 'cat /proc/partitions' show?  Does it have an sdb1 partition?

-- 
Len Sorensen

Re: AW: debian-ports source packages

[Lennart Sorensen]

On Wed, Sep 02, 2020 at 08:45:33AM +, Budweiser Gregor wrote:
> I was not aware of this. We are using the powerpc packages. I assume
> those are more generic builds (like i386 used to be).

e500 can't execute FPU code from generic powerpc as far as I know.
At least not 64 bit FPU code.  Of course a lot of code doesn't use
FPU and hence would run fine.  Apparently if you have FPU emulation
enabled in the kernel, then software will take care of emulating it,
but of course the FPU performance will be terrible.

-- 
Len Sorensen

Re: Kernel broken for Apple powerbooks

[Lennart Sorensen]

On Fri, Aug 28, 2020 at 04:10:10PM +0200, John Paul Adrian Glaubitz wrote:
> Not sure whether it's an actual problem because the majority of users with
> a 32-bit kernel will be on Mac hardware, so the number of fixed systems
> will certainly outweigh the number of systems which can't be debugged.

That could be.  I have no idea what percentage of powerpc 32 bit systems
are mac versus other systems.  The ones I have worked with are likely
not a representative sample at all given no macs were involved.

I am not saying don't make the change, I am just asking if the potential
impact is worth it.  It could very well be the answer is yes.

> I assume the bug should be fixed by the person who introduced the bug.

I wouldn't.  The code may very well predate the VMAP_STACK support.
Adding VMAP_STACK would be unrelated to the broken code, but does affect
it of course in an unfortunate way.  So you probably need the person
that wrote the now broken assembly code to fix it, even though when it
was written there was probably nothing wrong with it.

-- 
Len Sorensen

Re: Kernel broken for Apple powerbooks

[Lennart Sorensen]

On Fri, Aug 28, 2020 at 03:14:10PM +0200, Giuseppe Sacco wrote:
> Hello,
> since two months I am debugging the kernel boot process on an Apple
> powerbook because latest Debian kernels do not boot. I already opened a bug 
> against debian src:linux package[1].
> Finally, I found the problem and I reported it upstream [2].
> It seems the fix will require some time, but in the meantime, the
> kernel may be built and work if CONFIG_VMAP_STACK is not set.
> 
> Since powerpc is not currently a released architecture, who should I
> bug for changing this option for the kernels available at 
> https://www.ports.debian.org/?
> 
> Or, is there any ppc32 porter able to propose a patch?

Seems like a pretty bad bandaid to turn off a useful debug feature on
all systems just because you enable support for the ADB_PMU.  It solves
the problem for the affected apples, but is it worth the cost to all other
32 bit powerpc systems to make debuging some kernel problems much harder?

Too bad that handling stuff is in assembly, that certainly reduces the
number of people that could fix the actual problem.

-- 
Len Sorensen

Re: Bug#826796: Request for a new: linux-image-powerpc64-4K

[Lennart Sorensen]

On Fri, Jun 05, 2020 at 03:08:55PM +0200, John Paul Adrian Glaubitz wrote:
> Is POWER5 still supported by the Linux kernel? I thought IBM removed a
> bunch of older machines but kept PowerPC 970 support.

4.17 dropped power4.  power5 and up are still supported just fine.

-- 
Len Sorensen

Re: Bug#826796: Request for a new: linux-image-powerpc64-4K

[Lennart Sorensen]

On Fri, Jun 05, 2020 at 08:37:02AM +0200, John Paul Adrian Glaubitz wrote:
> I would like to switch the ppc64 kernel back to 4k pages. The majority
> of our users are people on G5 Macs anyway, so I don't see a point
> in using 64k pages.
> 
> Anyone with a large modern POWER machine is going to run the ppc64el
> port anyway.

Only power8 and newer can run ppc64el, so all power 5, 6 and 7 users
would still need to run be.  But there are probably a lot less than of
G5 users.  And most people with work loads that have a use for 64k pages
are probably on newer machines too.

-- 
Len Sorensen

Re: Debian mirrors

[Lennart Sorensen]

On Sat, May 30, 2020 at 11:08:06PM +0200, David VANTYGHEM wrote:
> I've got a good bandwith at home. So, I'm making a mirror for Debian
> (and other Linux distributions). I'm trying jigdo but I read that it is
> not anymore updated and that it's better to use zsync
> (https://doc.ubuntu-fr.org/zsync).
> 
> Would it be possible to use zsync on PowerPC Debian mirror ? (and is it
> planned on other architectures ?)

Jigdo makes sense for making iso images from a mirror.  It makes no
sense as a tool for doing a mirror.

There are mirror scripts that use rsync that work quite well.  I haven't
seen zsync before although the description makes it sound like it is
meant for large iso images rather than mirroring an archive.

To do mirroring properly there is a page with a link to ftpsync scripts
that do it right using rsync.  Not sure if it has ports support.
I can't remember.  There is also debmirror.

https://www.debian.org/mirror/ftpmirror

-- 
Len Sorensen

Re: iMac G3 support in Sid, Impossible?

[Lennart Sorensen]

On Tue, Apr 21, 2020 at 02:16:21PM +0200, Karl wrote:
> > Am 16.04.2020 um 20:12 schrieb Lennart Sorensen 
> > :
> > 
> > … that is no longer a release architecture (because
> > apparently there wasn't enough people to maintain it at a high enough
> > level) …
> > -- 
> > Len Sorensen
> > 
> 
> Sorry, this isn’t true ...

OK then I wonder what you think the reason was.  A lot of us were quite
disappointed in the decision to drop it.  It sure looked like no matter
who offered to help maintain it, it was never considered good enough.

-- 
Len Sorensen

Re: iMac G3 support in Sid, Impossible?

[Lennart Sorensen]

On Thu, Apr 16, 2020 at 05:46:19PM +, Alex McKeever wrote:
> I was told that the kernel is why it doesn’t work 100%... that it needs User 
> Space Modesetting and thus needs an older kernel like 2.6, 3.13 or 4.4.0-187 
> to work properly at all with the Rage128. I’d hate to say it but I’ve lost 
> faith in Debian/Ubuntu. I will be giving Adelie Linux a shot because nothing 
> else modern enough supports the iMac G3’s in terms of Linux. BSD is a 
> nightmare.

You have lost faith in Debian because a 20 year old machine (made by a
company that did tons of hack jobs and had lots of bugs in the firmware)
running an architecture that is no longer a release architecture (because
apparently there wasn't enough people to maintain it at a high enough
level) has a problem with the video card (and the video card happens
to be one of the hack jobs given the card was only ever really designed
for x86 machines and not fully documented)?

-- 
Len Sorensen

Re: 64-bit subtract from vector unsigned int

[Lennart Sorensen]

On Tue, Apr 07, 2020 at 03:12:38PM +0200, Romain Dolbeau wrote:
> You remember correctly, and also G5 (PowerPC 970) are 64-bits natively
> and will happily run a 64 bits kernel (and even userland) in Linux
> (including Debian), so this is for G4 (PowerPC 74xx) only (and G5
> running OSX, or NetBSD which doesn't have a 64-bit kernel / userland
> yet).
> 
> [this is for PowerMacs - some newer, embedded, 32 bits powerpc also
> have AltiVec, although the one in the AmigaOne X5000 doesn't].

Right the X1000 had it, and the X5000 does not (but it is 64 bit),
and the A1222 doesn't even have powerpc floatingpoint.  They are such
a mess.

-- 
Len Sorensen

Re: 64-bit subtract from vector unsigned int

[Lennart Sorensen]

On Tue, Apr 07, 2020 at 05:51:54AM -0400, Jeffrey Walton wrote:
> Hi Everyone,
> 
> I'm porting a 64-bit algorithm to 32-bit PowerPC (an old PowerMac).
> The algorithm is simple when 64-bit is available, but it gets a little
> ugly under 32-bit.
> 
> PowerPC has a "Vector Subtract Carryout Unsigned Word" (vsubcuw),
> https://www.nxp.com/docs/en/reference-manual/ALTIVECPEM.pdf. The
> altivec intrinsics are vec_vsubcuw and vec_subc.
> 
> The problem is, I don't know how to use it. I've been experimenting
> with it but I don't see the use (yet).
> 
> How does one use vsubcuw to implement a subtract with borrow?

Does your 32 bit powerpc have altivec?  A lot do not.  It is certainly
not a universal feature.  As far as I remember, G4 and G5 powermacs have
it, but nothing older.

-- 
Len Sorensen

Re: PPC64: G5 & 4k/64k page size (was: Re: Call for report - G5/PPC970 status)

[Lennart Sorensen]

On Mon, Jan 06, 2020 at 08:11:47PM +0100, Romain Dolbeau wrote:
> Interesting idea (and I have a 6600 aka NV43 in there, indeed) but I
> don't think so, as
> a) 'nouveau' works in 4.19 with 64 KiB pages
> b) using "module_blacklist=nouveau" doesn't help, I just tried
> c) my original 'bisect' was probably using 'nouveau' when the kernel
> was booting, so at least some 5.x w/o the offending commit and 64 KiB
> pages is fine
> d) to my untrained eye, the crash happens _before_ nouveau is loaded
> (it seems to me I'm still on the OpenFirmware framebuffer, font change
> occurs later).
> 
> Unfortunately I don't have a PCIe OpenFirmware ATI card to test the
> theory further.
> (... well I _do_ have a Sun XVR-300 ... technically it fits the bill ... )

Oh well.  I guess that means they did fix it for all cards and I just
don't see which change was relevant for the older chips then.

Unless something was missed that only triggers occationally.  That would
be annoying.

-- 
Len Sorensen

Re: PPC64: G5 & 4k/64k page size (was: Re: Call for report - G5/PPC970 status)

[Lennart Sorensen]

On Mon, Jan 06, 2020 at 07:18:30PM +0100, Romain Dolbeau wrote:
> Applied, recompiled with 64 KiB pages, still crashes.
> 
> The backtrace seems more readable this time (and wasn't overwritten by
> something else), bad photo here:
> 

Is it possible this has to do with nouveau and not supporting 64K page
size on older nvidia chips?  My reading of the driver is that only
NV50 and above has implemented support for anything other than 4K pages,
so a geforce 6xxx series that I believe some of the G5 machines had would
be a problem with 64K pages, while those with ATI cards would probably
not have a problem.

Maybe I read the driver changes wrong, but it sure looks like only
NV50/G84 and up got the needed fixes a couple of years ago.

-- 
Len Sorensen

Re: Booting Debian 10 on powernv POWER9 machine

[Lennart Sorensen]

On Thu, Oct 17, 2019 at 02:57:12PM -0300, Gustavo Romero wrote:
> Sorry, I wrote my note super hastily and forgot to mention that I was 
> wondering
> about BE specifically. Currently I see kernel 4.16 is used by the installer 
> and
> I get a panic regarding a VMX Unavailable Exception on POWER9 powernv (both
> baremetal / OPAL and qemu emulated), so I'm wondering if anybody else is
> catching that panic too etc. I know BE support for PPC64 was dropped 
> officially
> by I understand buildd builders are still building it so there are fresh
> packages out there.
> 
> Thanks for replying and for the comments!

I don't believe 64 bit powerpc big endian was ever officially released
by Debian.  32 bit was but was dropped some time ago.

64 bit little endian on the other hand is supported.

I only ever ran 32 bit powerpc with 64 bit kernel on power6 and power7.
I have never tried ppc64 and haven't had the hardware to try ppc64le.

I see 4.19 based installer images at
https://cdimage.debian.org/cdimage/ports/debian-installer/ which might
work better.  4.16 kernel is dead and I see a recent bit of fixes related
to vmx in newer kernels which might have entered 4.19 stable updates.
After all current stable release is 4.19 based.

-- 
Len Sorensen

Re: Booting Debian 10 on powernv POWER9 machine

[Lennart Sorensen]

On Wed, Oct 16, 2019 at 06:49:03PM -0300, Gustavo Romero wrote:
> Has anybody tried to install, boot, and test successfully on a POWER9 powernv
> machine?
> 
> If so, could I get and advice on which Debian installer (ISO, initrd, and
> vmlinuz) I should use please?

I have not tried one, but I would expect the ppc64le to work on it since
it is meant for power8+.  I unfortunately have not had a chance to play
with anything newer than power7.

-- 
Len Sorensen

Re: USB-RS232 with G4 (mac mini)

[Lennart Sorensen]

On Thu, May 23, 2019 at 11:11:38AM +0200, Mathieu Malaterre wrote:
> Right I misunderstood that part. I still feel dumb, where do you get a
> serial port on any modern laptop these days ?

Another usb to serial adapter?

-- 
Len Sorensen

Re: Updated installation images for Debian Ports 2019-04-09

[Lennart Sorensen]

On Wed, Apr 10, 2019 at 02:48:59PM +0200, Frank Scheiner wrote:
> On 4/10/19 08:50, John Paul Adrian Glaubitz wrote:
> > On 4/10/19 4:53 AM, Dennis Clarke wrote:
> > > /usr/lib/grub-installer/mkhfs-bootstrap.sh: Permission denied
> > 
> > Frank, I suggest invoking your script with "sh -c", could you test this
> > patch?
> > 
> > --- grub-installer~ 2019-04-06 00:03:33.153827119 +0300
> > +++ grub-installer  2019-04-10 09:48:57.414750733 +0300
> > @@ -249,7 +249,7 @@
> >   ppc64/chrp|ppc64/chrp_rs6k|ppc64/chrp_ibm|ppc64/cell)
> >   ;;
> >   powerpc/powermac_newworld|ppc64/powermac_newworld)
> > -  /usr/lib/grub-installer/mkhfs-bootstrap.sh || exit 1
> > +  sh -c '/usr/lib/grub-installer/mkhfs-bootstrap.sh' || exit 1
> > offs=$(findfs /boot/grub)
> > [ -n "$offs" ] || error "GRUB requires that the OF partition is 
> > mounted in /boot/grub" 1>&2
> >   ;;
> 
> Sure - I'll test and force push that change.
> 
> UPDATE:
> I tested that change with [1] in "normal" installation mode and it still
> complains with "permission denied". It works through though, when I make
> "mkhfs-bootstrap.sh" executable. I then tested with a "real" sh locally
> and it behaves the same. It works with just `sh '[...]'` and
> `mkhfs-bootstrap.sh` without execute permissions.
> 
> So I now included a modified change (without ` -c`,) rebased to current
> master of the upstream branch and force pushed it to my feature branch
> on salsa.d.o. The MR is at [2].

The -c makes no sense since sh -c is for launching a shell and running a
command but since the script isn't execuatable it isn't a valid command.
sh without the -c just runs the script which is what you wanted.

-- 
Len Sorensen

Re: Some board like RaspBerry with PowerPC

[Lennart Sorensen]

On Fri, Mar 22, 2019 at 04:45:26PM +0100, mickb...@posteo.net wrote:
> The only PowerPC system I know about, is produced by Acube-systems [1], but
> the price is around ten times the Raspberry. And I have no idea whether
> debian
> is installable or not.
> 
> 
> [1] http://www.acube-systems.biz

Well you can get a Power 9 board and CPU for about 100 RPi [1].
Pretty sure Debian runs on that, including ppc64le.  Its EATX sized,
so better have a decent case.

Interestingly they actually provide source code for the firmware, BMC,
FPGA, etc for their systems.


[1] https://www.raptorcs.com/TALOSII/

-- 
Len Sorensen

Re: Some board like RaspBerry with PowerPC

[Lennart Sorensen]

On Thu, Mar 14, 2019 at 03:20:46PM -0300, Alexandre Bencz wrote:
> Hi
> Is there any board, like Raspberry, but with PowerPC CPU, that is possible
> to install Debian ?

If you mean priced like a Raspberry Pi, then certainly not.  Probably
nothing even close the that small either.

-- 
Len Sorensen

Re: old OpenServers able to use Debian?

[Lennart Sorensen]

On Thu, Feb 14, 2019 at 07:28:08AM -0500, IT1 Stuart Blake Tener, USNR wrote:
> I have some P710 or P720 (they are 4U rack mount) OpenServers from a number
> of years ago that I believe are Power5. Is there a current (or older)
> version of Debian that works for them?

P7xx should be power7 or power7+ machines.  The power5 and power6 machines
were P5xx.

They should certainly run ppc64 port.

-- 
Len Sorensen

Re: Problems with hfsprogs on G5 Power Macs

[Lennart Sorensen]

On Tue, Jan 08, 2019 at 10:40:55AM +0100, Frank Scheiner wrote:
> On 1/7/19 22:13, John Paul Adrian Glaubitz wrote:
> > On 1/7/19 10:09 PM, Frank Scheiner wrote:
> > > Program received signal SIGSEGV, Segmentation fault.
> > > 0x000100034be4 in hfs_swap_HFSBTInternalNode (src=0x7fffd3a8, 
> > > fcb=0x100081898, direction=kSwapBTNodeBigToHost) at hfs_endian.c:883
> > > 883    hfs_endian.c: No such file or directory.
> > 
> > I think the debugging process would be more verbose if the
> > debugging was done in-tree of the hfsprogress source code.
> 
> Oh, overlooked that part yesterday evening. Did that now:
> 
> ```root@powermac-g5:~/hfsprogs/hfsprogs-332.25# gdb --args
> ./fsck_hfs.tproj/fsck_hfs -d /dev/sda2
> GNU gdb (Debian 8.2-1) 8.2
> [...]
> Reading symbols from ./fsck_hfs.tproj/fsck_hfs...done.
> (gdb) run
> Starting program: /root/hfsprogs/hfsprogs-332.25/fsck_hfs.tproj/fsck_hfs -d
> /dev/sda2
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library
> "/lib/powerpc64-linux-gnu/libthread_db.so.1".
> ** /dev/sda2
>   Using cacheBlockSize=32K cacheTotalBlock=1024 cacheSize=32768K.
> ** Checking HFS volume.
> 
> Program received signal SIGSEGV, Segmentation fault.
> 0x000100034be4 in hfs_swap_HFSBTInternalNode (src=0x7fffd2f8,
> fcb=0x100081898, direction=kSwapBTNodeBigToHost) at hfs_endian.c:883
> 883   nextRecord = (char *)src->buffer + srcOffs[i-1];

Given i starts as 0 in the loop in hfs_endian.c then i-1 would be 0-1
which is not nice when i is a uint32.  Newer versions of the code from
apple (hfs 407.200.4) has changed the definition of i to int32 which
at least means 0-1 is -1 rather than a very very large number that is
likely to be out of bounds of memory.

-- 
Len Sorensen

Re: Error trying to update powerpc64 Jessie machine.

[Lennart Sorensen]

On Fri, Jun 29, 2018 at 09:09:50AM -0600, John Paul Adrian Glaubitz wrote:
> No, Debian System Administrators.

Oh great, we have overlapping acronyms. :)

-- 
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: Error trying to update powerpc64 Jessie machine.

[Lennart Sorensen]

On Fri, Jun 29, 2018 at 01:55:28AM -0700, Rick Thomas wrote:
> On Jun 28, 2018, at 8:09 AM, John Paul Adrian Glaubitz 
>  wrote:
> 
> > Yes, as announced by DSA, the powerpc buildds have been shut down:
> 
> Forgive my ignorance, What is “DSA”?

Debian Security Advisory I believe.

-- 
Len Sorensen

Re: Removal of POWER4 support, (was: [GIT PULL] Please pull powerpc/linux.git powerpc-4.17-1 tag)

[Lennart Sorensen]

On Sun, Apr 08, 2018 at 09:50:46AM +0200, Mathieu Malaterre wrote:
> Hi G5 users,
> 
> Could someone shed some lights on POWER4 removal. I thought G5 were POWER4 ?
> 
> (see below)
> ...
>  - Removal of POWER4 support, which was accidentally broken in 2016 and no one
>noticed, and blocked use of some modern instructions.
> ...
> 
> See commit 471d7ff8b51b63521c8ea35c51966ab4caa434ee in powerpc/next.

It seems that it is only generic IBM server POWER4 that is removed.
The special ones from freescale and the 970 in the G5 remain.

The PA6T has its own CPU type in the kernel, as does the 970.

-- 
Len Sorensen

Re: Spurious lzma decompression error on ppc64

[Lennart Sorensen]

On Tue, Feb 20, 2018 at 08:15:07AM +0100, Christoph Biedl wrote:
> Hello,
> 
> since a few days ago, I get messages like
> 
> | Unpacking libsmartcols1:ppc64 (2.31.1-0.4) over (2.30.2-0.3) ...
> | dpkg-deb (subprocess): decompressing archive member: lzma error: compressed 
> data
> |  is corrupt
> | dpkg-deb: error:  subprocess returned error exit status 2
> | dpkg: error processing archive 
> /var/cache/apt/archives/libsmartcols1_2.31.1-0.4_ppc64.deb (--unpack):
> |  cannot copy extracted data for 
> './lib/powerpc64-linux-gnu/libsmartcols.so.1.1.0' to 
> '/lib/powerpc64-linux-gnu/libsmartcols.so.1.1.0.dpkg-new': unexpected end of 
> file or stream
> | Errors were encountered while processing:
> |  /var/cache/apt/archives/libsmartcols1_2.31.1-0.4_ppc64.deb
> 
> There is no obvious pattern in which packages are affected, and just
> repeating the upgrade makes the problem go away. So it's rather not a
> problem with the package itself. Wisdom of the net suggest to indeed
> just redo the installation step, this is just band-aid and feels wrong.
> 
> FWIW, the computer benefits from a local apt-cacher-ng but no other
> systems (quite a few, several archs and distributions) connected to it
> shows that behaviour.
> 
> Rechecking xz-utils and liblzma using the md5sums file showed no errors.
> So I'm slightly concerned there's something inside that causes these
> errors, and the first idea was some kind of memory corruption, due to
> hardware or kernel.
> 
> Anybody else seeing something similar?

Does the problem go away if apt-cacher-ng is bypassed?

In the past I encountered issues with apt-cacher not working if a file
was ever rebuilt (so filename not changed but content was).  It would
return the wrong length, corrupt files, mismatching files, etc.
I switched to using a real proxy instead (squid in my case) and later
simply a complete local mirror of desired architectures.

I believe the ppc64 archive has occationally been rebuilt, which isn't
something done to release architectures.

apt-cacher is in my experience a very unreliable tool if anything
unexpected happens.  It makes way too many assumptions about how an
archive works.

-- 
Len Sorensen

Re: PPC64: gcc currently compiles for power4 by default, causing glibc's sqrtf to fail on e6500

[Lennart Sorensen]

On Fri, Feb 09, 2018 at 11:34:12AM +0100, John Paul Adrian Glaubitz wrote:
> This is something that needs to be discussed. A single user alone shouldn't
> warrant such major change in a port. You always have to keep in mind that
> changing the default compiler options also has potential impact on the
> performance on more modern ppc64 systems like Apple Macintosh.
> 
> So, while I'm generally not against such a change, I would like to hear
> some voices first.

Without this change, you have to declare officially that e6500 and e5500
are simply not supported CPUs.

-- 
Len Sorensen

Re: PPC64: gcc currently compiles for power4 by default, causing glibc's sqrtf to fail on e6500

[Lennart Sorensen]

On Tue, Feb 06, 2018 at 06:58:55PM +0100, John Paul Adrian Glaubitz wrote:
> It would be nice if anyone who cares about the ppc64 could actually
> post what kind of hardware they have. We should find a consensus on
> where to put the baseline.

Well at least the CPUs listed on https://wiki.debian.org/PPC64 would
be nice.  Either that or make the page match what is really supported.

> Rebuilding the whole archive isn't so much of a problem. We have already
> done that :).

Yeah at least there are some pretty fast PPC64 build boxes.

And it might be possible to scan the binaries for unsupported instructions
and just rebuild those packages, but it might not be worth the bother.

-- 
Len Sorensen

Re: PPC64: gcc currently compiles for power4 by default, causing glibc's sqrtf to fail on e6500

[Lennart Sorensen]

On Tue, Feb 06, 2018 at 03:40:20PM +0100, Bas Vermeulen wrote:
> I am trying to run the ppc64 unstable on a Freescale T2080, which uses the
> e6500 CPU. Running python (or any other application using sqrt or sqrtf)
> will cause an illegal instruction exception, because the sqrtf opcode is
> not supported on the e6500.
> 
> This seems to be caused by gcc compiling for power4 by default
> (_ARCH_PWR4=1 and _ARCH_PPCSQ=1 set in gcc -E -mD - < /dev/null), although
> jrtc27 on #debian-ports pointed to
> https://github.com/gcc-mirror/gcc/blob/da8dff89fa9398f04b107e388cb706517ced9505/gcc/config/rs6000/default64.h#L30
> which sets MASK_PPC_GPOPT by default (which includes fp sqrt).
> 
> What would be the best way to solve this problem?

Why is the default not powerpc64 instead of power4?  After all that is
the setting for generic 64 bit bit endian powerpc as far as I know.

It seems the e6500 is missing quite a few floating point instructions
from the Power ISA so targeting power4 (which is I believe full Power
ISA 2.01) is likely to cause issues.

-- 
Len Sorensen

Re: floating point types seems to need VSX support ?

[Lennart Sorensen]

On Fri, Oct 20, 2017 at 10:55:34PM -0400, Dennis Clarke wrote:
> WARNING : long and winding but full of examples.
> 
> 
> This is quite confusing with gcc 7.2.0 on latest ppc64 sid.
> 
> nix_$ uname -a
> Linux nix 4.13.0-1-powerpc64 #1 SMP Debian 4.13.4-1 (2017-10-01) ppc64
> GNU/Linux
> 
> nix_$ gcc --version
> gcc (Debian 7.2.0-11) 7.2.0
> Copyright (C) 2017 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
> 
> 
> I have carefulyl checked the the data in memory to represent a specific
> constant should be perfect across big endian 64-bit architectures. At
> least that is my hope.
> 
> So I attempt to use 128 bit long floating point data thus :
> 
> nix_$ cat not_pi.c
> 
> #include 
> #include 
> 
> /* note : see glibc source code
> sysdeps/ieee754/ldbl-128ibm/e_atan2l.c
> line 51 says :
> pi = 3.14159265358979323846264338327950280e+00L
> which is hex 4000921fb54442d18469898cc51701b8
>however that seems to not work
> */
> 
> int main ( int argc, char* argv[])
> {
> long double  pi_ld = 3.1415926535897932384626433832795028841971L;
> 
> printf ( "sizeof(long double) = %2i\n", sizeof(long double) );
> 
> printf ( " pi is not %38.36Lf\n", pi_ld );
> 
> return ( EXIT_SUCCESS );
> }
> 
> Compiles fine and prints out pi but the hex is wrong :
> 
> nix_$ gcc -m64 -g -mlong-double-128 -o not_pi not_pi.c
> nix_$ gdb not_pi
> GNU gdb (GDB) 8.0.1
> Copyright (C) 2017 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later
> 
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
> and "show warranty" for details.
> This GDB was configured as "powerpc64-unknown-linux-gnu".
> Type "show configuration" for configuration details.
> For bug reporting instructions, please see:
> .
> Find the GDB manual and other documentation resources online at:
> .
> For help, type "help".
> Type "apropos word" to search for commands related to "word"...
> Reading symbols from not_pi...done.
> (gdb) break 19
> Breakpoint 1 at 0x9c0: file not_pi.c, line 19.
> (gdb) run
> Starting program: /home/dclarke/pgm/C/pi/not_pi
> sizeof(long double) = 16
> 
> Breakpoint 1, main (argc=1, argv=0x7a38) at not_pi.c:19
> 19  printf ( " pi is not %38.36Lf\n", pi_ld );
> (gdb) print pi_ld
> $1 = 3.1415926535897932384626433832794812
> (gdb) print _ld
> $2 = (long double *) 0x75d0
> (gdb) x/16xb _ld
> 0x75d0: 0x400x090x210xfb0x540x440x2d0x18
> 0x75d8: 0x3c0xa10xa60x260x330x140x5c0x06
> (gdb) cont
> Continuing.
>  pi is not 3.141592653589793238462643383279481227
> [Inferior 1 (process 18815) exited normally]
> (gdb) quit
> nix_$
> 
> 
> The data in memory should be 0x4000921fb54442d18469898cc51701b8h.
> * * * It is not. * * *
> 
> Clearly something else is at work here.
> 
> However IF we do have exactly that value in memory and the IBM long
> double data type then we get even stranger results :
> 
> nix_$ gcc -m64 -g -mabi=ieeelongdouble -o not_pi not_pi.c
> gcc: warning: using IEEE extended precision long double
> cc1: warning: using IEEE extended precision long double
> 
> nix_$ gdb not_pi
> GNU gdb (GDB) 8.0.1
> Copyright (C) 2017 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later
> 
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
> and "show warranty" for details.
> This GDB was configured as "powerpc64-unknown-linux-gnu".
> Type "show configuration" for configuration details.
> For bug reporting instructions, please see:
> .
> Find the GDB manual and other documentation resources online at:
> .
> For help, type "help".
> Type "apropos word" to search for commands related to "word"...
> Reading symbols from not_pi...done.
> (gdb) break 19
> Breakpoint 1 at 0x9c0: file not_pi.c, line 19.
> (gdb) run
> Starting program: /home/dclarke/pgm/C/pi/not_pi
> sizeof(long double) = 16
> 
> Breakpoint 1, main (argc=1, argv=0x7a38) at not_pi.c:19
> 19  printf ( " pi is not %38.36Lf\n", pi_ld );
> (gdb) print pi_ld
> $1 = 2.0713495408493618477052677917527035
> (gdb) print _ld
> $2 = (long double *) 0x75d0
> (gdb) x/16xb _ld
> 0x75d0: 0x400x000x920x1f0xb50x440x420xd1
> 0x75d8: 0x840x690x890x8c0xc50x170x010xb8
> (gdb) cont
> Continuing.
>  pi is not 2.071349540849361847705267791752703488
> [Inferior 1 (process 18825) exited normally]
> 

Re: Maturity of GRUB on powerpc/ppc64?

[Lennart Sorensen]

On Wed, Oct 04, 2017 at 06:36:33PM +0200, John Paul Adrian Glaubitz wrote:
> Are you sure? The parted manual seems to say otherwise:
> 
> > http://www.hep.by/gnu/parted/set.html
> 
> And I can fix the problem by manually running the parted command:
> 
>   set prep 1 on

No I am not sure.  I know there is a partition type for it though, and
the debian installer for powerpc always created it properly on an IBM
pseries for me so I never looked at the details.

Looking at the parted source code, they are abusing flags to store things
that are not flags.  So it if sees partition type 0x41, it sets the "flag"
prep.  Setting the "flag" prep makes it set the partition type to 0x41.

So yes, it is in fact a partition type, and it does not need any flags
set by the looks of it.

-- 
Len Sorensen

Re: Maturity of GRUB on powerpc/ppc64?

[Lennart Sorensen]

On Wed, Oct 04, 2017 at 03:25:20PM +0200, John Paul Adrian Glaubitz wrote:
> On 10/04/2017 03:16 PM, Frank Scheiner wrote:
> > Hey Adrian, you are really helpful! :-)
> 
> So are all your tests. Your input is really appreciated, thank you!
> 
> > I will check this out for the Power Macs and try to fix any issues on
> > the way by directly adapting `/usr/bin/grub-installer`.
> 
> Yep, that's the idea. I assume there are only minor changes necessary
> to be made until everything works as intended.
> 
> I still haven't managed to fully fix GRUB on POWER-based systems though
> as I cannot get partman to flag the boot partition as PREP. And without
> that flag, grub-installer is unable to find the target partition for
> installing GRUB.

It is not a flag, it is a partition type.  PPC PReP Boot is partition
type 0x41.  Similar to how Linux is type 0x83 and Linux swap is type 0x82.

I don't remember if it wants the boot flag set on it or not.

> I have to dig into the partman source code more to be able to find
> the problem.
> 
> > But could take until the weekend to find the time. :-/ I'll keep you 
> > informed.
> 
> No worries, take your time.

-- 
Len Sorensen

Re: New discussion: ppc64 installer -- ext2 /boot partition to keep sabot happy.

[Lennart Sorensen]

On Tue, Sep 26, 2017 at 04:16:23PM -0400, Milan Kupcevic wrote:
> Linux only oldworld Mac machines were using Quik.
> 
> https://packages.debian.org/sid/quik
> 
> Quik was not able to dual boot so if you had MacOS and linux the only
> way to dual boot was to have the BootX (Penguin Icon) module installed
> in MacOS which would let you load linux kernel from within MacOS space.
> 
> There is a Quik fork named iQuik which is amazingly enough still
> maintained. Take a look at this:
> 
> https://github.com/andreiw/iQUIK/blob/master/README

Nifty.  I see it mentions getting rid of the libext2fs requirement,
which is good, since that was what broke the builds last time (and was
a pain to fix but I did.  I can't remember why I did it).

-- 
Len Sorensen

Re: New discussion: ppc64 installer -- ext2 /boot partition to keep sabot happy.

[Lennart Sorensen]

On Tue, Sep 26, 2017 at 08:40:13PM +0200, John Paul Adrian Glaubitz wrote:
> Ok, so I guess the first step would be to patch partman-auto to increase
> the size of the bootloader partition for all sub-architectures.
> 
> Question: Does GRUB work on all the PowerPC variants that Yaboot supports?

Well I think it supports only ieee1275 machines, aka those with
openfirmware.

> According to [1], Yaboot supports:
> 
> - Mac Newworld, CHRP, CHRP/RS6000, CHRP_IBM and Cell.

Well at least my understanding is that the newworld machines, the IBM
cell machines, and the IBM power machines should all be openfirmware,
and hence should work with grub.

> Are these all supported by GRUB? If yes, the transition won't break
> anything. I don't know what platforms like Oldworld use though. I assume
> they are booted from Penguin from MacOS?

Do oldworld still use QUIK?

> So, do we all agree that the first thing is to increase the size of the
> bootloader partitions for the aforementioned systems?

I saw in centos's documentation that for IBM i and p series they say
the PReP boot partition should be 4 to 8MB and never over 10MB.

The HFS boot size changes certainly sound sensible.

-- 
Len Sorensen

Re: New ppc64 installer image available -- installation test report

[Lennart Sorensen]

On Mon, Sep 25, 2017 at 10:45:42PM -0700, Rick Thomas wrote:
> I gave it a whirl.  I used the same procedure as described in my previous 
> report.
> 
> The differences I noticed were:
> 
> When it got to partitioning I chose (as last time) “guided — use whole disk”.
> It produced a partitioning that had a 1MB HFS partition marked as bootable, 
> but no ext2 partition for /boot.
> Based on Frank’s experience that yaboot couldn’t handle ext4, I believe the 
> ext2 /boot is necessary.
> In any case, I manually created one.

Yes yaboot can not handle ext4 anymore, so for yaboot a /boot with ext2
is pretty much required.  Grub would have no such issue.

> One other oddity I noticed was that the HFS partition was not labeled 
> “bootstrap” as it has always been in the past.
> The name does not appear to be necessary, but loosing it would be a break 
> from tradition.
> 
> It wrote yaboot to the HFS partition OK and rebooted.
> This time it did *not* have any problem finding the root partition, so the 
> boot went without mishap.
> I did not need to use “rescue” to patch yaboot.conf and run ybin.
> 
> As an experiment, I did try booting from the CD and entering “rescue” at the 
> boot prompt.  It booted fine, but (as before) it came up in “install” mode, 
> not “rescue”.
> 
> If you think it would be helpful, I can do it again but leave the 
> partitioning alone — not create an ext2 /boot partition.  This would verify 
> (or falsify) Frank’s observation that yaboot requires ext2.

Well I know yaboot is built using an old version of the libe2fs that
does not support some modern ext4 features, so I would be surprised
if it reliably could read ext4 anymore.  It might sometimes work, but
not always.

> Interestingly, I have a G4 (32-bit) Mac that lacks a separate /boot partition 
> and uses ext4 for its root partition.  It boots fine using yaboot version 
> 1.3.16-4.  The G5 I’m doing tests on is using yaboot version 1.3.17-4.

It depends if your ext4 has certain new features enabled/in use or not.

I remember when I switched to ext4 on x86 originally, grub 0.97 was fine
with it, until my next new kernel was installed and it somehow was written
using extents which grub 0.97 at the time could not read, and hence the
old kernel I could boot but the new one I could not until I patched grub
to support that.  So really it depends what state your ext4 is in.
I don't like my boot process to depend on that, so ext2 for /boot with
yaboot seems like a very good idea for keeping things stable and working.

> One other thought:  A single MB for the HFS partition may be too small if we 
> want to support both grub and yaboot at the same time.  How about 2MB (or 
> even 10? — disk space is cheap).

It sounds like plenty.  How big do they seem to be?  My memory tells me
something like 300k is all grub uses so far but I may be out of date.

-- 
Len Sorensen

Re: debian-installer: please default to grub-ieee1275 on powerpc instead of yaboot

[Lennart Sorensen]

On Mon, Sep 25, 2017 at 05:19:00PM +0200, Simon Richter wrote:
> Quick question: what about directly booting a zImage from OpenFirmware,
> is that still an option?

Not sure.

It makes it hard to pick which kernel to boot though, and hard to pass
arguments to the kernel, and since we must use an initramfs, it makes
that a pain too.

I would not waste any time looking at that.  It's not a nice way to boot.

-- 
Len Sorensen

Re: debian-installer: please default to grub-ieee1275 on powerpc instead of yaboot

[Lennart Sorensen]

On Mon, Sep 25, 2017 at 03:15:15PM +, luigi burdo wrote:
> I had in past issue with grub on opensuse, i have a G5 970MP.
> 
> Adrian make a great present to us, making us have again debian working on BE .
> 
> please do not made again it not usable on our hardware choosing grub.

I have had issues with grub on opensuse running x86, so that doesn't
really mean much.

yaboot isn't being maintained, is a pain to build because it only
works with an obsolete version of the ext fs library, which makes it
incompatible with new ext* features.

Much better to spend effort getting any bugs in grub fixed.  A lot were
fixed some 5 or 6 years ago when I wanted grub on an IBM p520 and worked
with upstream to debug a lot of issues there over a few months.

-- 
Len Sorensen

Re: debian-installer: please default to grub-ieee1275 on powerpc instead of yaboot

[Lennart Sorensen]

On Sat, Sep 23, 2017 at 02:25:32PM +0200, Frank Scheiner wrote:
> Do we have information about how it looks (e.g. is it Grub by default and
> then, where is it installed?) for a POWER8 machine with Debian Stretch
> (ppc64le) installed from an installer image?
> 
> If also working for ppc64 and powerpc architecture machines that way it
> could be straight-forward to use the same method (with respective
> partitioning schemes for Apple and IBM machines) there, too.

Well I think at this point it seems the only option is:

powerpc/ppc64:
On IBM use DOS partition table with a prep boot partition for grub.
On Apple use Apple partition table (I don't know where grub is installed
on those).

ppc64el:
On IBM use GPT and install grub there as is already the case.

There does not appear to be any way to merge what Apple and IBM
machines do.  They are just not compatible that way.

-- 
Len Sorensen

Re: debian-installer: please default to grub-ieee1275 on powerpc instead of yaboot

[Lennart Sorensen]

On Fri, Sep 22, 2017 at 11:49:38AM +0200, John Paul Adrian Glaubitz wrote:
> I was just wondering whether it makes sense for GRUB to use MS-DOS partition
> on a Mac, thinking it may be better than Mac partition tables, I was
> basically just thinking aloud. If it's not necessary for GRUB to work
> properly, then we can stick with the current partition scheme, of course.

Well it doesn't sound better, and would certainly be unfriendly do dual
booting with MacOS.

> FWIW, I made this change [1] to partman-partitioning now which will result
> to debian-installer using the same disk labels on ppc64 for the various
> sub-architectures as on powerpc. There are, of course, no 64-Bit OldWorld
> Macs, Cell CPUs and so on, but I guess my change is more elegant than 
> duplicating
> the case statement for ppc64 and removing all the unsupported 
> subarchitectures.

I would have thought the firmware on the mac would insist on an apple
partition table to boot.

-- 
Len Sorensen

Re: debian-installer: please default to grub-ieee1275 on powerpc instead of yaboot

[Lennart Sorensen]

On Thu, Sep 21, 2017 at 10:37:43PM +0200, John Paul Adrian Glaubitz wrote:
> I have one POWER7 machine that has been provided to me by IBM for testing
> purposes and to host one of our buildds. I have performed a test installation
> of openSUSE Tumbleweed on it.
> 
> Here's the partitioning scheme that is being used:
> 
> (parted) p
> Model: Virtio Block Device (virtblk)
> Disk /dev/vda: 42.9GB
> Sector size (logical/physical): 512B/512B
> Partition Table: msdos
> Disk Flags:
> 
> Number  Start   End SizeType File system Flags
>  1  1049kB  2097kB  1049kB  primary  boot, prep, type=41
>  2  2097kB  2163MB  2161MB  primary  linux-swap(v1)  type=82
>  3  2163MB  18.9GB  16.7GB  primary  btrfs   type=83
>  4  18.9GB  42.9GB  24.0GB  primary  xfs type=83
> 
> (parted)
> 
> Interestingly, /boot is part of the btrfs filesystem:
> 
> linux-mfl2:~ # mount | grep boot
> /dev/vda3 on /boot/grub2/powerpc-ieee1275 type btrfs 
> (rw,relatime,space_cache,subvolid=261,subvol=/@/boot/grub2/powerpc-ieee1275)
> linux-mfl2:~ #

Well as long as grub can read that, then no problem.  So as long as
grub-install is including btrfs support in the grub image placed in the
prep boot partition, then /boot can be on btrfs.  That is almost certainly
the case.

> Ok, so I guess we can basically rule out GPT for the default label even
> on POWER systems. I would therefore then vote for using MS-DOS partition
> tables on POWER systems, i.e. what is already used now.

For powerpc/ppc64 I would agree.  For ppc64el GPT should be fine, and
I believe someone said that is in fact what they have done since it is
power8+ only.

> So, MS-DOS partition tables will not work at all on a Mac, correct?

Not as far as I know.  And given the apple partition table is better
anyhow, why would you want to?

-- 
Len Sorensen

Re: debian-installer: please default to grub-ieee1275 on powerpc instead of yaboot

[Lennart Sorensen]

On Thu, Sep 21, 2017 at 06:26:10PM +0200, John Paul Adrian Glaubitz wrote:
> Ok, good to know. What about GPT partition tables? On ppc64el, i.e. POWER8
> and newer, the default labels are all GPT. Any idea which is the earliest
> POWER5+ machine which supports GPT or should we just assume MS-DOS
> partition tabels for all POWER machines?

I unfortunately never tried GPT on any IBM power machines and I no longer
have access to them.

I found this:

http://download.boulder.ibm.com/ibmdl/pub/software/server/firmware/AH-Firmware-Hist.html

So it claims that on power7 the firmware upgrade in 2013 added support
for booting from a GPT disk.  So to me that means a lot of power7 systems
out there won't be able to (since not everyone has updated the firmware).
It doesn't say what you have to create as a boot partition when using
GPT though, so no idea how one would use it.  It might support FAT32
filesystem and accessing the grub file the way UEFI systems do, and
similar to what I think PowerMac machines do.

I can't find anything to suggest any power6 or power5 system ever had
an update to allow it.

I would expect all power8 machines had GPT support from the start,
and hence defaulting to that makes sense.

> > The grub modules stay in whatever /boot is on, and the grub image
> > generated contains enough of grub to read filesystems and is loaded
> > by the firmware from the prep boot partition (it litterally reads that
> > partition into ram as raw data, and executes it). 
> 
> Interesting. Do you know whether the mechanism is the same? My worries
> are that users on older PowerPC hardware, especially Apple Macintosh
> would have to go through extra lengths to get this working.

On a powermac is is certainly different.  You would have an apple
partition table instead, along with whatever else a mac requires boot wise
(which I don't know off hand).

> It seems that openSUSE for ppc and ppc64 always seems to default to
> GRUB.

Makes sense, since it is a nice boot loader.

> Could someone with both 32-bit and 64-bit Macs maybe perform test
> installations of openSUSE on their machines?
> 
> > http://download.opensuse.org/ports/ppc/tumbleweed/iso/
> 
> The latest release for 32-bit powerpc seems to be 11.1:
> 
> > http://mirrors.vbi.vt.edu/linux/opensuse/discontinued/distribution/11.1/iso/
> 
> You can also test other distributions like Fedora, for example. Latest
> version with ppc32 support seems to be 12:
> 
> > https://archives.fedoraproject.org/pub/archive/fedora/linux/releases/12/Fedora/ppc/iso/
> 
> The more test results we have, the better. If it turns out that GRUB will
> even work properly on 32-bit PowerPC machines, I think it would be the
> best option to make GRUB default for "powerpc" as well.
> 
> Of course, we can still keep yaboot on the FTP archives. It will not
> be a potential source of issues anymore, however.

i386 offered lilo as an alternative to grub for quite a while in the
installer.

-- 
Len Sorensen

Re: debian-installer: please default to grub-ieee1275 on powerpc instead of yaboot

[Lennart Sorensen]

On Thu, Sep 21, 2017 at 02:49:53PM +0200, Frank Scheiner wrote:
> On 09/21/2017 02:21 PM, John Paul Adrian Glaubitz wrote:
> > [...]
> > What we need are people who are willing to extensively test d-i
> > images with GRUB on powerpc and ppc64 and report back.
> 
> I can offer to test with all sorts of Power Mac G4s and an Xserve G4 for
> powerpc. I still need to buy a few CD-RWs though. :-)
> 
>  Also, I'm
> > not yet sure whether I have understood how exactly GRUB is properly
> > configured and used on powerpc and ppc64.
> 
> (1) Mathieu's pointer to [1] (with Grub's expectations) came a little too
> late for me and the howto I provided on [2].
> 
> (2) It looks like Rogério Brito on [3] wanted to make sure that his Grub
> installation also works with what yaboot "dictated" during installation
> (e.g. 800 KB HFS partition, etc.).
> 
> I'm unsure what the best approach would be. Assuming that on updates to Grub
> a new grub.img needs to be created, with approach (2) only a single file
> needs to be copied to the HFS partition. With approach (1) I actually don't
> know if the HFS partition will contain all the Grub modules in addition. But
> approach (1) seems to be the "default" for Grub and most likely the shipped
> tools also have the same expectations.
> 
> [1]: https://bugs.debian.org/691207
> 
> [2]: https://lists.debian.org/debian-powerpc/2017/09/msg00034.html
> 
> [3]: http://cynic.cc/blog/posts/running_grub2_on_powerpc_macs/

Well in the case of IBM power systems, you use a DOS MBR partition scheme
and you create a Prep boot partition, which should be 1MB or so in size,
and grub is installed there as a raw image.  Has been working fine for
a while as far as I have been able to tell.  The grub modules stay in
whatever /boot is on, and the grub image generated contains enough of
grub to read filesystems and is loaded by the firmware from the prep
boot partition (it litterally reads that partition into ram as raw data,
and executes it).  This is why the prep boot partition has to be large
enough to hold whatever the grub image with required starting modules
needs.

-- 
Len Sorensen

Re: Talos™ II Secure Workstation Pre-Order

[Lennart Sorensen]

On Fri, Aug 11, 2017 at 04:46:50PM +0200, Carlos wrote:
> AFAIK, the US prices are always without taxes.
> Don’t forget the import tax, you have to pay. For Germany 19%, if I’m right.
> 
> You can try, to let send the POWER9 system from a private person to the EU. 
> But if this fails, you have to pay also a tax penalty, AFAIK.
> 
> Additional informations about the system:
> 
> - E-ATX (12“ x 13“) mainboard
> - With the 3U HSF assemblies, noise is very low.
> - Power consumption of the POWER9 is far less than POWER8
> - If you buy the Dual CPU bundle, the PSU needs a dual EPS 12V connector
> - no mini PCIe slot
> - No M2 slot
> - 1x OCuLink port (what is this?)

http://blog.fosketts.net/2017/06/22/what-is-oculink/

So PCIe over a cable, similar to what thunderbolt does.

-- 
Len Sorensen

Re: debian-installer now available in Ports

[Lennart Sorensen]

On Sat, Apr 15, 2017 at 11:05:10AM -0700, Herminio Hernandez Jr.  wrote:
> The problem is I do not think yaboot is maintained either. 

Well it does have the problem of being stuck with an old e2fs lib,
which prevents using ext4 and maybe even some ext3 features on /boot.
It does appear a bit better off than quik in maintainance, although
grub2 is doing much better.

-- 
Len Sorensen

Re: debian-installer now available in Ports

[Lennart Sorensen]

On Sat, Apr 15, 2017 at 08:30:42PM +0300, Risto Suominen wrote:
> I still have a few powerpc Macs, both OldWorld and NewWorld.
> 
> The oldest one (6100/66) has no Open Firmware, the next one (7600/132)
> has OF 1.x, then comes Beige G3 with OF 2.x, and the first NewWorld
> machine Blue G3 with OF 3.x.
> 
> - the 6100 can only run MkLinux on top of Mach microkernel.
> 
> - the 7600 can boot Linux with Bootx from Mac OS, or with quik directly from 
> OF.
> 
> - the same applies to Beige.
> 
> - the Blue needs yaboot or grub2.
> 
> So, I'm saying that yaboot or grub2 is not usable on OldWorld
> machines. To automate the installation, the installer should be able
> to install quik on them. But I'm afraid that no one has maintained
> quik. Perhaps yaboot or grub2 could be expanded to handle OldWorld as
> well. And making a CD bootable on OldWorld machines is yet another
> challenge.

I suppose quik does appear a bit unmaintained.  It appears the last fix
to it was what I did 7 years ago to make it compile and work again.
I wonder if it still works.  I think I needed it to work for playing in
qemu at the time, but I suspect it isn't needed for that anymore.

-- 
Len Sorensen

Re: 64 bit java?

[Lennart Sorensen]

On Wed, Mar 29, 2017 at 09:57:25AM -0400, Adam Stouffer wrote:
> On Wed, Mar 29, 2017 at 3:04 AM, Christian Zigotzky
>  wrote:
> > Have you already added [arch=powerpc] to the other deb lines? (not deb-src 
> > lines)
> >
> > -- Christian
> 
> Yes, here is my sources.list
> 
> #
> 
> # deb cdrom:[Debian GNU/Linux 8.7.1 _Jessie_ - Official powerpc NETINST 
> Binary-1
>  20170116-11:54]/ jessie main
> 
> #deb cdrom:[Debian GNU/Linux 8.7.1 _Jessie_ - Official powerpc NETINST 
> Binary-1
> 20170116-11:54]/ jessie main
> 
> deb [arch=ppc64] http://ftp-nyc.osuosl.org/debian/ jessie main
> deb-src http://ftp-nyc.osuosl.org/debian/ jessie main
> 
> deb [arch=ppc64] http://security.debian.org/ jessie/updates main
> deb-src http://security.debian.org/ jessie/updates main

Those two have to be arch=powerpc

There is no ppc64 on those servers.

> # jessie-updates, previously known as 'volatile'
> deb [arch=ppc64] http://mirror.techfak.uni-bielefeld.de/debian/ 
> jessie-updates m
> ain
> deb-src http://mirror.techfak.uni-bielefeld.de/debian/ jessie-updates main

That one too should be powerpc not ppc64.

> deb [arch=ppc64] http://ftp.ports.debian.org/debian-ports/ unstable main
> deb [arch=ppc64] http://incoming.ports.debian.org/buildd/ unstable main
> deb [arch=ppc64] http://ftp.ports.debian.org/debian-ports/ unreleased main
> 
> I also ran "dpkg --add-architecture ppc64" again and get the same results.
> 
> W: Failed to fetch
> http://security.debian.org/dists/jessie/updates/InRelease  Unable to
> find expected entry 'main/binary-ppc64/Packages' in Release file
> (Wrong sources.list entry or malformed file)
> 
> W: Failed to fetch
> http://mirror.techfak.uni-bielefeld.de/debian/dists/jessie-updates/InRelease
>  Unable to find expected entry 'main/binary-ppc64/Packages' in Release
> file (Wrong sources.list entry or malformed file)
> 
> W: Failed to fetch
> http://ftp-nyc.osuosl.org/debian/dists/jessie/Release  Unable to find
> expected entry 'main/binary-ppc64/Packages' in Release file (Wrong
> sources.list entry or malformed file)
> 
> E: Some index files failed to download. They have been ignored, or old
> ones used instead.
> 
> The entries its looking for do not exist in the Release files.

-- 
Len Sorensen

Re: POWER6 not seeing memory above 2Gb

[Lennart Sorensen]

On Thu, Mar 23, 2017 at 03:22:46PM -0400, Adam Stouffer wrote:
> So I have grub2 booting the same kernel but again the same result.
> Only 2Gb available.

What was on this machine before?  Is it possible that you are in fact
running inside an existing LPAR config, which might have limited memory
assigned?

-- 
Len Sorensen

Re: POWER6 not seeing memory above 2Gb

[Lennart Sorensen]

On Thu, Mar 23, 2017 at 11:45:10AM -0400, Adam Stouffer wrote:
> On Thu, Mar 23, 2017 at 10:21 AM, Lennart Sorensen
> <lsore...@csclub.uwaterloo.ca> wrote
> >
> >
> >
> > That ought to be working.  I know the p520 I worked with before it
> > worked fine.
> >
> > Which bootloader are you using?  I use grub2, just in case the bootloader
> > has anything to do with memory detection in linux.
> >
> > --
> > Len Sorensen
> 
> 
> Ah, that might be the case. Yaboot seemed to have some install issues
> anyhow. What would be the best way to switch from yaboot to grub2?

Good question.  I installed the machine with grub2 originally years ago,
so I didn't have to try (I wanted MD raid1 which yaboot couldn't handle
at that time, so I wanted grub2 to work, no matter what it took).  Took
some work at the time, debugging disk issues and other issues in grub2,
but eventually grub2 got to the point of working on the p520 properly.
These days it ought to just work.

I remember needing a Prep boot partition, which grub-install was then
pointed at.  I can't remember if yaboot does it the same way.

It might be as simple as installing the grub-ieee1275 package and running
grub-install /dev/sda1 (assuming sda1 is the PReP boot partition).

-- 
Len Sorensen

Re: problems with wheezy and xbmc

[Lennart Sorensen]

On Thu, Mar 23, 2017 at 04:48:27PM +0100, Richard Kuenz wrote:
> Thank you very much,
> 
> i would have installed now
> 
> 
> vdpau-va-driver
> 
> 
> 
> and output changes
> 
> rich@debian:~$ xbmc
> libva: VA-API version 0.32.0
> libva: va_getDriverName() returns 0
> libva: Trying to open /usr/lib/powerpc-linux-gnu/dri/nouveau_drv_video.so
> libva: va_openDriver() returns -1
> 
> 
> 
> 
> 
> but the problem rasterized graphics remains.
> 
> 
> someone in the kodi forum already told me about mesa something, but your
> mentioned driver-package seem awailable only from jessie-backports onto sid.
> what to do then?
> and , if install this mesa thing, would this break something in graphics,
> because outside of xbmc and mpv it looks really good with this graphics.

No idea.  Any good reason for not running Jessie?

I see that vdpau-va-driver in wheezy does NOT include nouveau_drv_video.soA

Starting in jessie it exists in the package.

-- 
Len Sorensen

Re: problems with wheezy and xbmc

[Lennart Sorensen]

On Thu, Mar 23, 2017 at 02:57:02PM +0100, Richard Kuenz wrote:
> Hello ,
> 
> i have installed Debian Wheezy on my Powermac G5 Quad.
> 
> 
> please help me to solve one problem i have with graphics. whether i use xbmc
> or kodi or mpv for videoplayback, it always comes with rasterised graphics;
> no problem with vlc or mplayer or videoplayback directly on youtube.
> 
> 
> this is some output
> 
> 
> rich@debian:~$ glxinfo | grep -i renderer
> OpenGL renderer string: Gallium 0.4 on NV47
> 
> 
> rich@debian:~$ vblank_mode=0 glxgears
> ATTENTION: default value of option vblank_mode overridden by environment.
> ATTENTION: default value of option vblank_mode overridden by environment.
> 1946 frames in 5.3 seconds = 364.961 FPS
> 1946 frames in 5.0 seconds = 388.572 FPS
> 
> 
> 
> 
> but
> 
> 
> rich@debian:~$ xbmc
> libva: VA-API version 0.32.0
> libva: va_getDriverName() returns 0
> libva: Trying to open /usr/lib/powerpc-linux-gnu/dri/nouveau_drv_video.so
> libva: va_openDriver() returns -1
> libva: VA-API version 0.32.0
> libva: va_getDriverName() returns 0
> libva: Trying to open /usr/lib/powerpc-linux-gnu/dri/nouveau_drv_video.so
> libva: va_openDriver() returns -1
> libva: VA-API version 0.32.0
> libva: va_getDriverName() returns 0
> libva: Trying to open /usr/lib/powerpc-linux-gnu/dri/nouveau_drv_video.so
> libva: va_openDriver() returns -1
> libva: VA-API version 0.32.0
> libva: va_getDriverName() returns 0
> libva: Trying to open /usr/lib/powerpc-linux-gnu/dri/nouveau_drv_video.so
> libva: va_openDriver() returns -1
> libva: VA-API version 0.32.0
> libva: va_getDriverName() returns 0
> libva: Trying to open /usr/lib/powerpc-linux-gnu/dri/nouveau_drv_video.so
> libva: va_openDriver() returns -1
> libva: VA-API version 0.32.0
> libva: va_getDriverName() returns 0
> libva: Trying to open /usr/lib/powerpc-linux-gnu/dri/nouveau_drv_video.so
> libva: va_openDriver() returns -1
> libva: VA-API version 0.32.0
> libva: va_getDriverName() returns 0
> libva: Trying to open /usr/lib/powerpc-linux-gnu/dri/nouveau_drv_video.so
> libva: va_openDriver() returns -1
> libva: VA-API version 0.32.0
> libva: va_getDriverName() returns 0
> libva: Trying to open /usr/lib/powerpc-linux-gnu/dri/nouveau_drv_video.so
> libva: va_openDriver() returns -1
> libva: VA-API version 0.32.0
> libva: va_getDriverName() returns 0
> libva: Trying to open /usr/lib/powerpc-linux-gnu/dri/nouveau_drv_video.so
> libva: va_openDriver() returns -1
> libva: VA-API version 0.32.0
> libva: va_getDriverName() returns 0
> libva: Trying to open /usr/lib/powerpc-linux-gnu/dri/nouveau_drv_video.so
> libva: va_openDriver() returns -1
> libva: VA-API version 0.32.0
> libva: va_getDriverName() returns 0
> libva: Trying to open /usr/lib/powerpc-linux-gnu/dri/nouveau_drv_video.so
> libva: va_openDriver() returns -1
> libva: VA-API version 0.32.0
> libva: va_getDriverName() returns 0
> libva: Trying to open /usr/lib/powerpc-linux-gnu/dri/nouveau_drv_video.so
> libva: va_openDriver() returns -1
> libva: VA-API version 0.32.0
> libva: va_getDriverName() returns 0
> libva: Trying to open /usr/lib/powerpc-linux-gnu/dri/nouveau_drv_video.so
> libva: va_openDriver() returns -1
> 
> what is wrong with my graphics?
> the card should be capable it it is 7800gtx 256mb.

Do you have the file it is mentioning?

It should be in mesa-va-drivers or vdpau-va-driver package.

-- 
Len Sorensen

Re: POWER6 not seeing memory above 2Gb

[Lennart Sorensen]

On Thu, Mar 23, 2017 at 10:14:27AM -0400, Adam Stouffer wrote:
> No LPAR or VM, running just "bare metal". I had AIX installed previously
> and it recognized 16Gb.
> 
> uname -a
> Linux new-host-4 3.16.0-4-powerpc64 #1 SMP Debian 3.16.39-1+deb8u2
> (2017-03-07) ppc64 GNU/Linux
> 
> lscpu
> Architecture:  ppc64
> CPU op-mode(s):32-bit, 64-bit
> Byte Order:Big Endian
> CPU(s):4
> On-line CPU(s) list:   0-3
> Thread(s) per core:2
> Core(s) per socket:1
> Socket(s): 2
> NUMA node(s):  1
> Model: IBM,8203-E4A
> Hypervisor vendor: pHyp
> Virtualization type:   para
> L1d cache: 64K
> L1i cache: 64K
> NUMA node0 CPU(s): 0-3
> 
> Seems like a config issue? Wouldn't a 32 bit kernel see the 32 bit limit,
> under 4Gb?

That ought to be working.  I know the p520 I worked with before it
worked fine.

Which bootloader are you using?  I use grub2, just in case the bootloader
has anything to do with memory detection in linux.

-- 
Len Sorensen

Re: POWER6 not seeing memory above 2Gb

[Lennart Sorensen]

On Wed, Mar 22, 2017 at 09:07:49PM -0400, Adam Stouffer wrote:
> Hello all, I'm new to the list and just installed jessie on my IBM
> 8203-E4A box. It's a dual core 4.2Ghz with 16Gb of memory.
> 
> But anyhow like the subject says the kernel is only reporting 2Gb of
> available memory. I tried appending "mem=16G" as a boot argument but
> no change.
> 
> Here is the output from dmesg with kernel 3.16.0

Well I know running a 64 bit kernel on that model, does see 16GB ram.
But I was doing that with no LPAR or anything else, just Debian installed
straight onto the machine (IBM support people have a hard time
understanding that people might do that).

So either you somehow installed a 32 bit kernel, or you have an LPAR or
something else restricting your memory size.

-- 
Len Sorensen

Re: debian-installer: virtio support for powerpc cdrom/netboot installs

[Lennart Sorensen]

On Thu, Mar 23, 2017 at 09:54:01AM +, Jonni O'Gorman wrote:
> can you tell me how to unsubscribe from this list...

https://lists.debian.org/

-- 
Len Sorensen

Re: Problems installing Debian on Powerbooks

[Lennart Sorensen]

On Thu, Mar 09, 2017 at 10:50:44AM -0800, Nicholas Dal Porto wrote:
> I have the non-free package installed.
> 
> Here's the output of lspci -vvv: http://pastebin.com/raw/aQSVwyUW
> 
> I also have Network Manager installed. Anything I need to do there or with 
> any network config files?

I think you need firmware-b43-installer installed.

Claims to be firmware download tool for old b43xx card firmware.

Also can you check 'lsmod' and see if b43 is loaded?

-- 
Len Sorensen

Re: Problems installing Debian on Powerbooks

[Lennart Sorensen]

On Wed, Mar 08, 2017 at 10:28:57PM -0800, Nicholas Dal Porto wrote:
> It was the RAM! Replaced it and it installed without a hitch. However, 
> Wireless isn't working. Anyone know a fix?

Did you enable non-free and install the firmware-linux-nonfree package?

Or perhaps a different nonfree firmware package specific to the wifi
device.

Check the dmesg output to see if it mentions a missing firmware file.

-- 
Len Sorensen

Re: Bug#857172: Please enable SSE2 on amd64 and disable altivec on PPC ports

[Lennart Sorensen]

On Wed, Mar 08, 2017 at 08:08:59PM +0100, Riccardo Mottola wrote:
> Well, it is very sad we aren't release anymore, IMHO, although a fact.
> Yet i think it is wrong raising the bar and excluding many CPUs just because
> it makes things easier.
> powerpc was (and probably still is) a quite popular debian port and I know
> of many who run those coloured iMacs with Debian!
> 
> There are also other non-Mac machines. E.g. I am pretty sure the Linkbook
> doesn't have altivec and there were a couple of other similar small netbooks
> which sadly did not get popular compared to ARM.

This is a current in production machine:

http://www.amigaos.net/hardware/133/amigaone-x5000

No altivec.  Not an old CPU.

-- 
Len Sorensen

Re: Bug#857172: Please enable SSE2 on amd64 and disable altivec on PPC ports

[Lennart Sorensen]

On Wed, Mar 08, 2017 at 04:06:17PM +0100, John Paul Adrian Glaubitz wrote:
> The firefox package is built with AltiVec enabled and so is mplayer,
> for example. So, yes, Altivec is actively used and I would honestly
> refrain from disabling it in a performance-sensitive package like
> babl.
> 
> Altivec is disabled on powerpcspe where it's not available in the
> hardware, but most machines on which people install Debian powerpc
> should have Altivec.

e5500 does not have it, which means one of the modern powerpc chips
doesn't support it.

Certainly the powerpc64 port claims e5500 support, and hence does NOT
assume altivec support.

It really is something that should be runtime detected and used if
present but not required.

-- 
Len Sorensen

Re: Problems installing Debian on Powerbooks

[Lennart Sorensen]

On Wed, Mar 08, 2017 at 01:17:11PM +0100, John Paul Adrian Glaubitz wrote:
> On Tue, Mar 07, 2017 at 03:31:15PM -0800, Nicholas Dal Porto wrote:
> > Here's a photo of the pertinent section: http://i.imgur.com/hHZyDfg.jpg
> 
> Various components and scripts load by the installer are crashing. This is
> most likely due to a broken toolchain during build. It could be related
> to PIE being enabled for the toolchain by default [1].

Or the machine has bad ram.  But certainly a toolchain problem is
possible, although I would have thought others would have hit that
already if that was the case.

> Please let me know which version of Debian you were trying to install. I
> need to know the exact name and source of the ISO image and how the image
> was burnt. Please always provide this information in the future as otherwise
> it very difficult to track down the issue.
> 
> However, if these specific error messages are reproducible with *any*
> version of Debian (Squeeze, Wheezy, Jessie), it's most likely a hardware
> issue and you should perform some memory and CPU testing.

Yeah testing with something else is a good idea.

-- 
Len Sorensen

Re: Problems installing Debian on Powerbooks

[Lennart Sorensen]

On Wed, Mar 08, 2017 at 09:38:36AM +0100, Elimar Riesebieter wrote:
> * Nicholas Dal Porto  [2017-03-07 15:31 -0800]:
> 
> > Here's a photo of the pertinent section: http://i.imgur.com/hHZyDfg.jpg
> 
> Want you run a raid6 on a Powerbook? Seems to be impossible!

The kernel always prints that.  Nothing to do with wanting to use raid
or not.

-- 
Len Sorensen

Re: What are the fastest Mozilla's Gecko-based web browsers for PowerBook G4?

[Lennart Sorensen]

On Tue, Mar 07, 2017 at 11:01:04PM -0800, PhiLLip Pi wrote:
> In my couple days old Debian Jessie/stable PowerPC on a very old 2002 
> 15" Titanium PowerBook G4 with 512 MB of RAM, it came with Firefox v45.7 
> ESR but it is very slow and uses too much memories.
> 
> I wonder if there are faster Gecko-based web browsers. If they do exist, 
> then they need to still work with my 20 MB places.sqlite file from and 
> with my faster computers' (new/lat)est SeaMonkey and Firefox versions 
> (Windows, Mac OS, and Linux/Debian). Same for plugins (e.g., Flash) and 
> extensions (uBlock Origin). 

I am quite sure there has never been and never will be a flash plugin
for powerpc (well at least not one that is worth using, so not gnash
for example).

Of course one could argue flash isn't worth using at all, but that's a
different issue.

-- 
Len Sorensen

Re: Is it possible to use a 2002 (Titanium) 15" PowerBook G4's wifi with WPA2, PSK, AES, etc.?

[Lennart Sorensen]

On Tue, Mar 07, 2017 at 10:46:16AM -0800, PhiLLip Pi wrote:
> Here is what I know based on my new Debian PPC v8's installation:
> dmesg (full log in http://pastebin.ca/3777025 ):
> $ dmesg |grep airport
> [   11.706958] airport 0.15 (Benjamin Herrenschmidt 
> )
> [   11.707033] airport: Physical address 8003
> [   12.913489] airport 0.0003:radio: Hardware identity 0005:0001:0001:0002
> [   12.921204] airport 0.0003:radio: Station identity  001f:0001:0008:0046
> [   12.928672] airport 0.0003:radio: Firmware determined as Lucent/Agere 
> 8.70
> [   13.135033] airport 0.0003:radio: firmware: failed to load 
> agere_sta_fw.bin (-2)
> [   13.143969] airport 0.0003:radio: firmware: failed to load 
> agere_sta_fw.bin (-2)
> [   13.151299] airport 0.0003:radio: Hardware identity 0005:0001:0001:0002
> [   13.158542] airport 0.0003:radio: Station identity  001f:0001:0008:0046
> [   13.165525] airport 0.0003:radio: Firmware determined as Lucent/Agere 
> 8.70
> [   13.172456] airport 0.0003:radio: Ad-hoc demo mode supported
> [   13.179321] airport 0.0003:radio: IEEE standard IBSS ad-hoc mode 
> supported
> [   13.186201] airport 0.0003:radio: WEP supported, 104-bit key
> As you can see, it only goes up to WEP. No WPA2. I noticed it said 
> missing agere_sta_fw.bin firmware from 
> added "http://ftp.de.debian.org/debian jessie main non-free" in my 
> /etc/apt/sources.list file. So, I rebooted and rechecked. Now, it 
> doesn't say it and shows WPA supported, but not WPA2 (better security)? 
> :(

The orinoco does not do WPA2 from what I can find.  WPA is the best it
can do.

Apparently 15" titanium powerbook 2002 is much too vague to determine
the machine in question.  That covers about 5 or 6 different models
it seems.  Some with orinoco, some with b43, and perhaps even some with
something else.

Seems the b43xx based models are b/g and WPA2 capable, while the orinoco
based ones are b only with WPA at best.

-- 
Len Sorensen

Re: Is it possible to use a 2002 (Titanium) 15" PowerBook G4's wifi with WPA2, PSK, AES, etc.?

[Lennart Sorensen]

On Tue, Mar 07, 2017 at 02:32:55AM -0800, PhiLLip Pi wrote:
> I know Mac OS Xes can't, but I wonder if this is the same issue with 
> Debian/Linux.

Do you know which wifi chip it has?

As far as I can tell from some searching, it is probably a
broadcom 43xx chip.  If it is, then there is some hope, since I
see someone at least got wpa2+psk with aes working apparantly:
http://ramblingfoo.blogspot.ca/2008/02/wpa2-psk-with-aes-on-broadcom-wlan0.html

-- 
Len Sorensen

Re: Newbie trying to install Debian PPC into an old 15" PowerBook G4...

[Lennart Sorensen]

On Sun, Mar 05, 2017 at 11:37:36PM -0800, PhiLLip Pi wrote:
> Hmm, I must be blind. I can't seem to find any X11, XFree86, Xwhatever, 
> etc. packages for GUI stuff. Also, is this net installer really limited 
> compared to regular Debian installer for 64-bit non-Mac PCs? Am I 
> expecting too much from an old PowerBook G4? :(

X11 is called xorg.

Could try 'tasksel' to select graphical desktop install.

Or install task-xfce-desktop or similar.

The netinstall will have access to everything in debian over the internet.

-- 
Len Sorensen

Re: Fwd: Re: Newbie trying to install Debian PPC into an old 15" PowerBook G4...

[Lennart Sorensen]

On Fri, Mar 03, 2017 at 07:38:47PM -0800, PhiLLip Pi wrote:
> On Fri, Mar 03, 2017 at 11:07:23AM -0500, Lennart Sorensen wrote:
> 
> > > I downloaded, burned, and booted 
> > > http://cdimage.ubuntu.com/releases/precise/release/ubuntu-12.04-desktop-powerpc.iso
> > >  
> > > since I didn't have a blank DVD to use for the bigger and newer 
> > > http://cdimage.ubuntu.com/lubuntu/releases/trusty/release/lubuntu-14.04.5-desktop-powerpc.iso
> > >  
> > > file. Maybe that's a good thing because v12.04 was SOO 
> > > slow as to be expected. :(
> > > 
> > > Anyways, it took me a while to navigate since I don't use Ubuntu. I 
> > > managed to find Terminal with its Unity's hotkeys (ctrl+alt+T). I ran 
> > > "sudo gparted" command. I resized the free drive space in half. Now, we 
> > > wait...
> > 
> > I hope it works.
> 
> Nope, it failed pretty fast but I didn't have free time to research, 
> screen capture, upload, etc. for you guys due to a family emergency 
> (nothing serious). Now, I have time for now! GParted's details showed:
> 
> GParted 0.11.0 --enable-libparted-dmraid
> 
> Libparted 2.3
> 
> Shrink /dev/sda5 from 55.89 GiB to 36.11 GiB  00:15:57( ERROR )
> 
>  calibrate /dev/sda5  00:00:04( SUCCESS )
> 
>   path: /dev/sda5
>   start: 704
>   end: 117,209,529
>   size: 117,208,826 (55.89 GiB)
> 
>  check file system on /dev/sda5 for errors and (if possible) fix 
> them( N/A )
> 
>   checking is not available for this file system
> 
>  shrink file system  00:15:44( ERROR )
> 
>   using libparted
> 
>  libparted messages( INFO )
> 
>   Input/output error during read on /dev/sda
> 
>   An error occurred during extent relocation.
> 
>   Data relocation has failed.
> 
>   Resizing the HFS+ volume has failed.
> 
> 
> 
> Create Primary Partition #1 (unformatted, 19.78 GiB) on /dev/sda
> 
> 
> I also managed to get a screen capture to share of the whole desktop 
> screen: https://i.imgur.com/vD5a7L7.png ... I hope those help? As you 
> can see, it failed in step 0! :( Maybe I am doing it wrong?
> 
> Maybe I should try installing Ubuntu instead of Debian from this 
> bootable CD to see if it lets me resize and install if it comes with a 
> fancy GUI installer?
> 
> Uh oh. I wonder if my HDD got hosed during this attempt. Scary! :/

That input/output error message makes me wonder if your disk has bad
sectors.

That could be a problem.

-- 
Len Sorensen

Re: Fwd: Re: Newbie trying to install Debian PPC into an old 15" PowerBook G4...

[Lennart Sorensen]

On Fri, Mar 03, 2017 at 06:54:23AM -0800, PhiLLip Pi wrote:
> I downloaded, burned, and booted 
> http://cdimage.ubuntu.com/releases/precise/release/ubuntu-12.04-desktop-powerpc.iso
>  
> since I didn't have a blank DVD to use for the bigger and newer 
> http://cdimage.ubuntu.com/lubuntu/releases/trusty/release/lubuntu-14.04.5-desktop-powerpc.iso
>  
> file. Maybe that's a good thing because v12.04 was SOO 
> slow as to be expected. :(
> 
> Anyways, it took me a while to navigate since I don't use Ubuntu. I 
> managed to find Terminal with its Unity's hotkeys (ctrl+alt+T). I ran 
> "sudo gparted" command. I resized the free drive space in half. Now, we 
> wait...

I hope it works.

-- 
Len Sorensen

Re: Newbie trying to install Debian PPC into an old 15" PowerBook G4...

[Lennart Sorensen]

On Thu, Mar 02, 2017 at 07:30:34AM -0800, PhiLLip Pi wrote:
> On Thu, Mar 02, 2017 at 10:28:48AM -0500, Lennart Sorensen wrote:
> > On Thu, Mar 02, 2017 at 12:05:20AM -0800, Ant wrote:
> > > According to 
> > > https://www.debian.org/releases/stable/powerpc/ch03s05.html.en and 
> > > https://wiki.debian.org/PowerPC/FAQ#How_do_I_partition_my_hard_drive.3F 
> > > web pages, I can't resize my HDD's current default HFS drive into two 
> > > partitions. I have to redo the HDD's partition setup to dual boot.
> > > 
> > > Am I correct? If so, then I thought Debian installer could resize 
> > > existing the drive like with Windows in IBM PCs. :(
> > > 
> > > Thank you in advance. :)
> > 
> > I suspect the safe and simple option is to use mac os to shrink the
> > current HFS partition first.
> 
> In the installed v10.2.8's Disk Utility app, it wouldn't let me. In its 
> bootable DVD's v10.2.1's Disk Utility, it said it would have to erase my 
> volumes (delete everything)? Is that how it is supposed to happen?

No idea.  I just saw that you were supposed to be able to resize HFS
partitions in the disk utility.  Apparently resize is a feature that
requires 10.5 or higher, so your extremely ancient version won't help you.

-- 
Len Sorensen

Re: Newbie trying to install Debian PPC into an old 15" PowerBook G4...

[Lennart Sorensen]

On Thu, Mar 02, 2017 at 12:05:20AM -0800, Ant wrote:
> According to 
> https://www.debian.org/releases/stable/powerpc/ch03s05.html.en and 
> https://wiki.debian.org/PowerPC/FAQ#How_do_I_partition_my_hard_drive.3F 
> web pages, I can't resize my HDD's current default HFS drive into two 
> partitions. I have to redo the HDD's partition setup to dual boot.
> 
> Am I correct? If so, then I thought Debian installer could resize 
> existing the drive like with Windows in IBM PCs. :(
> 
> Thank you in advance. :)

I suspect the safe and simple option is to use mac os to shrink the
current HFS partition first.

-- 
Len Sorensen

Re: yaboot problem? OS won't load after install on a Power Mac G5

[Lennart Sorensen]

On Thu, Feb 16, 2017 at 09:57:06PM +0200, ilko Iliev wrote:
> Hi Len,
> 
> Thanks for the suggestion but alas that didn't work either, same thing 
> happens.

So you tried this?

#1 32.2 kB  Apple
#2  1.0 MB B K boot untitled
#3  1.0 GB   f ext2 untitled /boot
#4  316 GB   f ext4 untitled /
#5  3.0 GB   f swap swap swap

-- 
Len Sorensen

Re: Firefox 51.0.1-1 on Debian Sid/experimental PowerPC (PPC32): Segmentation fault

[Lennart Sorensen]

On Mon, Feb 13, 2017 at 04:44:22PM -0500,  wrote:
> Well there does exist cheaper options, like the $4k T4240QDS-PB, which
> is 12 core (24 threads) 1.8Ghz 64 bit powerpc.
> 
> The P5040RDB is $3k for a quad core 64 bit powerpc.
> 
> That's still not hobby level pricing though.  Better than the price of
> the talos, but also not ppc64el compatible (as far as I know).

Seems you can get an IBM S812LC with an 8 core Power8 for under $5k with
32GB ram.  That would make for a nice build machine.  You wouldn't want
to be anywhere near it due to the fan noise though.

-- 
Len Sorensen

Re: Firefox 51.0.1-1 on Debian Sid/experimental PowerPC (PPC32): Segmentation fault

[Lennart Sorensen]

On Mon, Feb 13, 2017 at 10:44:57PM +0200, Konstantinos Margaritis wrote:
> As with all new languages it will take time, but eventually it will get
> there, with a big IF. The biggest(only?) problem with PowerPC in
> general right now is hardware availability not lack of interested
> developers. Developers will try anything new if it's decently priced
> (as ARM/MIPS have already proven). Show me a decent 64-bit PowerPC
> board at ~100-200EUR, Talos was a great idea, but about $17k more
> expensive than it should have been.

Well there does exist cheaper options, like the $4k T4240QDS-PB, which
is 12 core (24 threads) 1.8Ghz 64 bit powerpc.

The P5040RDB is $3k for a quad core 64 bit powerpc.

That's still not hobby level pricing though.  Better than the price of
the talos, but also not ppc64el compatible (as far as I know).

-- 
Len Sorensen

Re: yaboot problem? OS won't load after install on a Power Mac G5

[Lennart Sorensen]

On Wed, Feb 08, 2017 at 07:06:30PM +0200, ilko Iliev wrote:
> Hi Christoph,
> 
> Indeed, these files seem to exist http://i.imgur.com/uAPd5sL.jpg
> 
> As to the question regarding the FS type for /boot I'm not really sure, it's 
> whatever comes with this setup http://i.imgur.com/fPYDHbI.jpg
>  but there was a setting including "mac newworld" something  in the name.
> I took the screenshot during the last install, I tried a couple of times 
> before that trying different partitioning e.g. LVM and others, in one of my 
> attempts I renamed 'boot' from "untitled" to Apple_Bootstrap as I found a 
> post by someone saying it worked for him when he was installing Ubuntu.
> 
> P.S. Sorry if not the proper way to reply to a mail list, never used them 
> before :/

OK, that means your kernel and /boot is on partition 3, which is ext4.

That probably won't work these days.

A seperate /boot partition for storing the kernel and ramdisk using ext2
would probably help.

-- 
Len Sorensen

Re: Performance difference 32bit/64bit userland

[Lennart Sorensen]

On Wed, Feb 08, 2017 at 03:08:41PM +0100, Mathieu Malaterre wrote:
> I always assumed it was possible to run ppc32 (be) or ppc64 (be)
> userlands on a ppc64el system. Is this a restriction at Linux level or
> hardware level ?

I thought at least KVM virtual machines it was possible to do.  Not sure
about running big endian binaries on a little endian kernel.

The endian switching feature of powerpc is certainly unusual.  It is
the only CPU I know of that allows each process to set its endianess.
prctl has a PR_SET_ENDIAN option that is powerpc only.

-- 
Len Sorensen

Re: Performance difference 32bit/64bit userland

[Lennart Sorensen]

On Wed, Feb 08, 2017 at 11:21:00AM -0200, Breno Leitao wrote:
> On 02/07/2017 07:22 PM, Lennart Sorensen wrote:
> > ppc64el is different since it is targeting systems where the applications
> > are expected to need a lot of ram, and switching the little endian
> > improves performance when working with GPUs (which are all designed
> > for the x86 little endian world).  At the same time being able to
> > assume power8 as a minimum cpu means you can gain some instruction set
> > improvements that normal powerpc can't assume.
> 
> Correct. And we can't do 32-bits userspace also, since we do not have a
> 32-bits little endian ABI. For ppc64el, bi-arch does not seem to be a valid
> feature.

Yes, I don't think ppc64el architecture has defined a 32 bit variant.
I don't think they see any point.

Of course linux could run little endian on powerpc if someone wanted to.
After all Windows NT did so the CPUs (for the most part) can do it.

-- 
Len Sorensen

Re: Performance difference 32bit/64bit userland

[Lennart Sorensen]

On Tue, Feb 07, 2017 at 09:39:21PM +0100, John Paul Adrian Glaubitz wrote:
> Yes, but lots of platforms fully migrate to 64-bit userland these days. Like
> PowerPC, SPARC used to be 32-bit userland on a 64-bit kernel. However, Oracle
> is shifting Linux for SPARC to 64-bit these days.

I think eventually maintaining the dual library builds and the tool
chain and such starts to be a hassle, when things like web browsers and
graphics editing programs and such start to have reasons to want more
than 2 or 3GB of ram.  So the tradeoff in performance versus the hassle
of keeping a dual set of libraries around can change towards keeping
things simpler instead once enough applications start to have reason to
want 64 bit.

Of course the x32 architecture existing at all makes you think not
everyone is convinced it isn't worthwhile.

-- 
Len Sorensen

Re: Performance difference 32bit/64bit userland

[Lennart Sorensen]

On Tue, Feb 07, 2017 at 10:05:38PM +0200, Gatis Visnevskis wrote:
> Well explained!
> 
> In enterprise world, Java applications will benefit from 64-bit addressing.
> Another example is Oracle, 32-bit server side is dropped while ago. So it
> also make sense to compile all Oracle client linked apps with 64-bit
> compiler. Might be offtopic, but all above is true also for AIX. Most
> binaries are 32-bit.

Certainly part of what has kept too much work going into ppc64 is probably
that 32 bit power pc with a 64 bit kernel gives the best performance
for most uses, and just installing a few things 64 bit where needed is
the best balance.  Sparc I believe has been similar in the past, where
64 bit kernel to allow more overall memory was useful, but keeping most
things user space 32 bit was the best for performance.

ppc64el is different since it is targeting systems where the applications
are expected to need a lot of ram, and switching the little endian
improves performance when working with GPUs (which are all designed
for the x86 little endian world).  At the same time being able to
assume power8 as a minimum cpu means you can gain some instruction set
improvements that normal powerpc can't assume.  ppc64 can't make such
assumptions since it will run on a much wider range of 64 bit powerpc
chips.

-- 
Len Sorensen

Re: yaboot problem? OS won't load after install on a Power Mac G5

[Lennart Sorensen]

On Mon, Feb 06, 2017 at 09:30:37PM +0200, ilko Iliev wrote:
> I tried several times installing Debian on a Power Mac G5 machine, each time 
> I go through the install process without any issues, but once I reboot after 
> the install the system hangs in a perpetual " Loading second stage 
> bootstrap..."
> I suspect it might be a yaboot issue, I mounted the HDD on another machine 
> and here is the yaboot.conf:

What file system are you using for /boot and /root?

Yaboot has had issues in the past with dealing with new ext3 and ext4
features because it was built (staticly) against an outdated e2fslibs
version as far as I recall.  ext2 for /boot is certainly much safer and
not likely to break.

The other suggestions about video issues and such are very much worth
checking too.

-- 
Len Sorensen

Re: A few questions about stretch ( testing ) on a PowerMac G5

[Lennart Sorensen]

On Tue, Feb 07, 2017 at 05:28:00PM +, luigi burdo wrote:
> Sid ppc32 on X1000
> 
> Sid spe on A1222
> 
> i thinnk []

OK that makes sense.

> What i need to know where to find SID PPC64 distro to test?

I have no seen an installer yet for any ppc64.  Only ppc64el, which I
don't think would work on the X5000.

-- 
Len Sorensen