m68k-queue

m68k-queue

[Geert Uytterhoeven]

m68k-queue is at a historical low:

$ git cherry -v v3.10-rc1 m68k-queue | wc -l
11
$

and of course I want to keep that, and improve it!

  - m68k/irq: Add handle_polled_irq() for timer based soft interrupts
    Still no response from tglx :-(
  - m68k/atari: use polled interrupt handler for timer D interrupts
    Depends on above
  - m68k/atari: EtherNAT - ethernet support (smc91x)
    m68k/atari: EtherNEC - ethernet support (ne)
    Michael will submit
  - m68k/atari: USB - add ISP1160 USB host controller support
    Michael WIP?
  - m68k/atari: Update defconfigs for new features
    m68k/mac: Update defconfig
    I'm working on the defconfigs
  - fs/fat: Revert "msdos fs: remove unsettable atari option"
    fs/fat: Atari FAT updates
    fs/fat: Use correct logical sector size for Atari GEMDOS FAT
    Who dares to stand in front of the fat maintainer and will submit these?
    Michael, too?
  - mac: ADB raw packets
    I guess this can be dropped?

Thanks!

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: m68k-queue

[schmitz]

Hi Geert,
> m68k-queue is at a historical low:
>
> $ git cherry -v v3.10-rc1 m68k-queue | wc -l
> 11
> $
>
> and of course I want to keep that, and improve it!
>
>   - m68k/irq: Add handle_polled_irq() for timer based soft interrupts
>     Still no response from tglx :-(
>   - m68k/atari: use polled interrupt handler for timer D interrupts
>     Depends on above
>   - m68k/atari: EtherNAT - ethernet support (smc91x)
>     m68k/atari: EtherNEC - ethernet support (ne)
>     Michael will submit
>   
Yep, that's the plan. (I'm having DSL stability issues at home ATM, 
right smack bang during the times when I can usually work on kernel 
hacking :-(  Line alive for 20 seconds, then dead for 60 seconds. Using 
a serial modem would work better).
>   - m68k/atari: USB - add ISP1160 USB host controller support
>     Michael WIP?
>   
I'll have to submit that for comments as-is, I really don't want to mess 
with the mm code.
>   - m68k/atari: Update defconfigs for new features
>     m68k/mac: Update defconfig
>     I'm working on the defconfigs
>   - fs/fat: Revert "msdos fs: remove unsettable atari option"
>     fs/fat: Atari FAT updates
>     fs/fat: Use correct logical sector size for Atari GEMDOS FAT
>     Who dares to stand in front of the fat maintainer and will submit these?
>     Michael, too?
>   
Funny that - I left out these by accident, and still could mount my GEM 
FAT partition used to store kernel images. All I had to do was omit the 
'atari=no' option.

I'll have to verify that this also works with floppy, but my gut feeling 
is whenever you create a partition that requires special handling by the 
'atari' option, you end up with a partition that has cluster size larger 
than mm block size which means the filesystem is unusable since Linux 
2.6 anyway.

That needs someone to look into who understands the GEM FAT format - I 
might just have been setting the wrong combination of filesystem size, 
FAT size and cluster size that forced this error.

Seeing as I don't speak enough FAT, I hardly qualify to submit that ...
>   - mac: ADB raw packets
>     I guess this can be dropped?
>   
I'd guess so - I struggle to recall what this was for. Perhaps to talk 
to the clock chip on some Macs. Anyone?

Cheers,

    Michael

> Thanks!
>
> Gr{oetje,eeting}s,
>
>                         Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
>                                 -- Linus Torvalds
> --
> To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>   

Re: m68k-queue

[Brad Boyer]

On Tue, May 14, 2013 at 08:56:44PM +1200, schmitz wrote:
> >  - mac: ADB raw packets
> >    I guess this can be dropped?
> I'd guess so - I struggle to recall what this was for. Perhaps to
> talk to the clock chip on some Macs. Anyone?

If you can give instructions on how to look at this one patch (or
just send it in email), I'll take a look and hopefully I remember
enough of the history to give some kind of explanation.

	Brad Boyer
	flar@allandria.com

Re: m68k-queue

[Geert Uytterhoeven]

On Wed, May 15, 2013 at 7:45 AM, Brad Boyer <flar@allandria.com> wrote:
> On Tue, May 14, 2013 at 08:56:44PM +1200, schmitz wrote:
>> >  - mac: ADB raw packets
>> >    I guess this can be dropped?
>> I'd guess so - I struggle to recall what this was for. Perhaps to
>> talk to the clock chip on some Macs. Anyone?
>
> If you can give instructions on how to look at this one patch (or
> just send it in email), I'll take a look and hopefully I remember
> enough of the history to give some kind of explanation.

https://git.kernel.org/cgit/linux/kernel/git/geert/linux-m68k.git/log/?h=m68k-queue
and click on the commit you're interested in.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: m68k-queue

[Finn Thain]

On Tue, 14 May 2013, schmitz wrote:

> >   - mac: ADB raw packets
> >     I guess this can be dropped?

Geert, you should drop this patch, because there are no other patches in 
your queue that use ADBREQ_RAW and because it seems to be broken (the idea 
of sending a raw packet using adb_request() was apparently to permit 
req->data[0] != ADB_PACKET). Also it seems to have become obsolete back in 
2006.

> 
> I'd guess so - I struggle to recall what this was for. Perhaps to talk 
> to the clock chip on some Macs.

I went digging in the mac68k repo. ADBREQ_RAW shows up here:

    "Latest ADB changes including the new 68k PMU driver."
    http://linux-mac68k.cvs.sourceforge.net/viewvc/linux-mac68k/linux-mac68k/drivers/macintosh/adb.c?r1=1.15&r2=1.16&

    "Added Baboon interrupt support.
    Moved all time and PRAM-related functions into misc.c."
    http://linux-mac68k.cvs.sourceforge.net/viewvc/linux-mac68k/linux-mac68k/arch/m68k/mac/misc.c?r1=1.4&r2=1.5&

You are right, ADBREQ_RAW was clearly PRAM and clock related.

And this seems to indicate roughly when it got broken:

    "Merge with 2.4.0 release."
    http://linux-mac68k.cvs.sourceforge.net/viewvc/linux-mac68k/linux-mac68k/drivers/macintosh/adb.c?r1=1.21&r2=1.22

Anyway, in mainline kernels, adb_request() was not called from the PRAM 
and clock related code since 2006 when Al Viro got that code to build 
again:

    https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/arch/m68k/mac/misc.c?id=3272244c2b1a8f13cec83c04b8245fa7fcb47a27

Finn

Re: m68k-queue

[Michael Schmitz]

Finn,

> I went digging in the mac68k repo. ADBREQ_RAW shows up here:
>
>     "Latest ADB changes including the new 68k PMU driver."
>     http://linux-mac68k.cvs.sourceforge.net/viewvc/linux-mac68k/linux-mac68k/drivers/macintosh/adb.c?r1=1.15&r2=1.16&
>
>     "Added Baboon interrupt support.
>     Moved all time and PRAM-related functions into misc.c."
>     http://linux-mac68k.cvs.sourceforge.net/viewvc/linux-mac68k/linux-mac68k/arch/m68k/mac/misc.c?r1=1.4&r2=1.5&
>
> You are right, ADBREQ_RAW was clearly PRAM and clock related.

Thanks for this bit of detective work - I had forgotten about the
mac68k CVS. Or never knew about it).

> And this seems to indicate roughly when it got broken:
>
>     "Merge with 2.4.0 release."
>     http://linux-mac68k.cvs.sourceforge.net/viewvc/linux-mac68k/linux-mac68k/drivers/macintosh/adb.c?r1=1.21&r2=1.22

Appears it was broken in v1.21 already (unconditionally sets the first
byte to ADB_PACKET).

If clock/pram access is all handled by other code now, the patch
should indeed be dropped.

Cheers,

  Michael


On Wed, May 15, 2013 at 8:47 PM, Finn Thain <fthain@telegraphics.com.au> wrote:
>
> On Tue, 14 May 2013, schmitz wrote:
>
>> >   - mac: ADB raw packets
>> >     I guess this can be dropped?
>
> Geert, you should drop this patch, because there are no other patches in
> your queue that use ADBREQ_RAW and because it seems to be broken (the idea
> of sending a raw packet using adb_request() was apparently to permit
> req->data[0] != ADB_PACKET). Also it seems to have become obsolete back in
> 2006.
>
>>
>> I'd guess so - I struggle to recall what this was for. Perhaps to talk
>> to the clock chip on some Macs.
>
> I went digging in the mac68k repo. ADBREQ_RAW shows up here:
>
>     "Latest ADB changes including the new 68k PMU driver."
>     http://linux-mac68k.cvs.sourceforge.net/viewvc/linux-mac68k/linux-mac68k/drivers/macintosh/adb.c?r1=1.15&r2=1.16&
>
>     "Added Baboon interrupt support.
>     Moved all time and PRAM-related functions into misc.c."
>     http://linux-mac68k.cvs.sourceforge.net/viewvc/linux-mac68k/linux-mac68k/arch/m68k/mac/misc.c?r1=1.4&r2=1.5&
>
> You are right, ADBREQ_RAW was clearly PRAM and clock related.
>
> And this seems to indicate roughly when it got broken:
>
>     "Merge with 2.4.0 release."
>     http://linux-mac68k.cvs.sourceforge.net/viewvc/linux-mac68k/linux-mac68k/drivers/macintosh/adb.c?r1=1.21&r2=1.22
>
> Anyway, in mainline kernels, adb_request() was not called from the PRAM
> and clock related code since 2006 when Al Viro got that code to build
> again:
>
>     https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/arch/m68k/mac/misc.c?id=3272244c2b1a8f13cec83c04b8245fa7fcb47a27
>
> Finn
> --
> To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: m68k-queue

[Finn Thain]

On Thu, 16 May 2013, Michael Schmitz wrote:

> I had forgotten about the mac68k CVS. Or never knew about it.
> 

As I recall, there used to be a repository that lived on purplehat.net 
which was said to have been lost in a disk crash.

What is on sourceforge is quite a few years older than that, but the odd 
commit did prove useful sometimes for cherry picking for 2.6, even though 
the sourceforge repo has very little beyond Linux 2.2. There is a 2.4 
branch but it was always too buggy to be viable, and didn't track mainline 
beyond 2.4.18.

Which reminds me - I'd like to update the mac68k sites. The sourceforge 
material (i.e. downloads) are ancient and buggy and the project docs needs 
some updating.

Spare time permitting, I'd like to make available some current kernel 
binaries and tools for download (and remove/archive the broken 2.4 
downloads), provide instructions for cross-compiling mainline kernels 
using a current toolchain, with links to Thorsten's cross-compilers and so 
on.

The old material is a bit of an embarrassment, and the omission of current 
binaries suggests that the port never worked since 2.2...

Does anyone have any thoughts about a refresh of the mac68k 
downloads/docs?

Finn

Re: m68k-queue

[Michael Schmitz]

Finn,

> As I recall, there used to be a repository that lived on purplehat.net
> which was said to have been lost in a disk crash.
>
> What is on sourceforge is quite a few years older than that, but the odd
> commit did prove useful sometimes for cherry picking for 2.6, even though
> the sourceforge repo has very little beyond Linux 2.2. There is a 2.4
> branch but it was always too buggy to be viable, and didn't track mainline
> beyond 2.4.18.

I must have been using 2.2 and never tried 2.4 I guess. Too many disk
crashes to trace that now.

It appears there has been testing on recent kernels and continued
improvement of hardware support - what is the latest kernel version
that you or others tested?

> Which reminds me - I'd like to update the mac68k sites. The sourceforge
> material (i.e. downloads) are ancient and buggy and the project docs needs
> some updating.
>
> Spare time permitting, I'd like to make available some current kernel
> binaries and tools for download (and remove/archive the broken 2.4
> downloads), provide instructions for cross-compiling mainline kernels
> using a current toolchain, with links to Thorsten's cross-compilers and so
> on.

By all means - if you have something that works better than what's
there; update it.

> The old material is a bit of an embarrassment, and the omission of current
> binaries suggests that the port never worked since 2.2...

Entirely possible. Some of the stuff that used to work fine on my
Falcon is only supported in the 2.4 series now. Never got it to work
since.

> Does anyone have any thoughts about a refresh of the mac68k
> downloads/docs?

I've lost track - does the current unstable/experimental debian-ports
distribution boot and install on Macs? Shame there's no such thing as
060 accelerator for Macs, but with 040 models it might be feasible.

If so, docs and tools to boot and install might be appreciated.

Cheers,

  Michael



On Thu, May 16, 2013 at 2:55 PM, Finn Thain <fthain@telegraphics.com.au> wrote:
>
> On Thu, 16 May 2013, Michael Schmitz wrote:
>
>> I had forgotten about the mac68k CVS. Or never knew about it.
>>
>
> As I recall, there used to be a repository that lived on purplehat.net
> which was said to have been lost in a disk crash.
>
> What is on sourceforge is quite a few years older than that, but the odd
> commit did prove useful sometimes for cherry picking for 2.6, even though
> the sourceforge repo has very little beyond Linux 2.2. There is a 2.4
> branch but it was always too buggy to be viable, and didn't track mainline
> beyond 2.4.18.
>
> Which reminds me - I'd like to update the mac68k sites. The sourceforge
> material (i.e. downloads) are ancient and buggy and the project docs needs
> some updating.
>
> Spare time permitting, I'd like to make available some current kernel
> binaries and tools for download (and remove/archive the broken 2.4
> downloads), provide instructions for cross-compiling mainline kernels
> using a current toolchain, with links to Thorsten's cross-compilers and so
> on.
>
> The old material is a bit of an embarrassment, and the omission of current
> binaries suggests that the port never worked since 2.2...
>
> Does anyone have any thoughts about a refresh of the mac68k
> downloads/docs?
>
> Finn

Re: m68k-queue

[Finn Thain]

On Fri, 17 May 2013, Michael Schmitz wrote:

> 
> It appears there has been testing on recent kernels and continued 
> improvement of hardware support - what is the latest kernel version that 
> you or others tested?

The most recent kernel that I tested was 3.2, with the patches I was 
working on at the time. Those patches went into 3.3, but they aren't 
important for 68040 machines.

Hardware support for most Quadras was stable for a couple of years prior 
to 3.2. Please see http://mac.linux-m68k.org/status/

> 
> I've lost track - does the current unstable/experimental debian-ports 
> distribution boot and install on Macs?

I haven't tested Thorsten's current images. But if they work on '040 
Aranym, I can see no reason why they wouldn't work on '040 Macs. 
(Excepting those Macs with the buggy 68LC040 chip revision.)

I did boot Thorsten's work successfully on a PowerBook 540 a while back (I 
used ATAoE because of SCSI issues but SONIC ethernet DMA is faster than 
local disk controllers anyway). I forget whether it was a debootstrap or 
chroot.

The CD-ROM images at people.debian.org/~smarenka didn't work last time I 
tried.

> Shame there's no such thing as 060 accelerator for Macs, but with 040 
> models it might be feasible.

The DMA support in the SONIC ethernet driver and the PDMA support in the 
ESP SCSI driver help a lot. Given 256 MB of RAM, a Quadra 950 would be a 
good option.

Finn

Re: m68k-queue

[Michael Schmitz]

Finn,
>> It appears there has been testing on recent kernels and continued 
>> improvement of hardware support - what is the latest kernel version that 
>> you or others tested?
>>     
>
> The most recent kernel that I tested was 3.2, with the patches I was 
> working on at the time. Those patches went into 3.3, but they aren't 
> important for 68040 machines.
>   

Should still work in 3.10 I'd expect.

>> I've lost track - does the current unstable/experimental debian-ports 
>> distribution boot and install on Macs?
>>     
>
> I haven't tested Thorsten's current images. But if they work on '040 
> Aranym, I can see no reason why they wouldn't work on '040 Macs. 
> (Excepting those Macs with the buggy 68LC040 chip revision.)
>   

That's understood.
> I did boot Thorsten's work successfully on a PowerBook 540 a while back (I 
> used ATAoE because of SCSI issues but SONIC ethernet DMA is faster than 
> local disk controllers anyway). I forget whether it was a debootstrap or 
> chroot.
>
> The CD-ROM images at people.debian.org/~smarenka didn't work last time I 
> tried.
>   
Getting installable CD-ROM images to work again is a whole new can of 
worms - Thorsten's chroot images or debootstrap instructions should be 
good enough for now.

>> Shame there's no such thing as 060 accelerator for Macs, but with 040 
>> models it might be feasible.
>>     
>
> The DMA support in the SONIC ethernet driver and the PDMA support in the 
> ESP SCSI driver help a lot. Given 256 MB of RAM, a Quadra 950 would be a 
> good option.
>   

True - what bogs down my Falcon is the PIO mode IDE, first and foremost. 
DMA SCSI might be a bit better but I've not had the SCSI driver stable 
since 2.4 or 2.6.

Cheers,

    Michael

Re: m68k-queue

[Andreas Schwab]

Finn Thain <fthain@telegraphics.com.au> writes:

> I haven't tested Thorsten's current images. But if they work on '040 
> Aranym, I can see no reason why they wouldn't work on '040 Macs. 

There are a lot of possible reason why an emulator would not expose bugs
in the kernel.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: m68k-queue

[Geert Uytterhoeven]

On Sat, May 18, 2013 at 8:28 AM, Andreas Schwab <schwab@linux-m68k.org> wrote:
>> I haven't tested Thorsten's current images. But if they work on '040
>> Aranym, I can see no reason why they wouldn't work on '040 Macs.
>
> There are a lot of possible reason why an emulator would not expose bugs
> in the kernel.

Modern kernels seem to work fine on the '040 in my Amiga.
Note that I'm not (yet) running a modern userland. Still the old real Debian.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: m68k-queue

[Brad Boyer]

On Wed, May 15, 2013 at 08:53:15AM +0200, Geert Uytterhoeven wrote:
> On Wed, May 15, 2013 at 7:45 AM, Brad Boyer <flar@allandria.com> wrote:
> > On Tue, May 14, 2013 at 08:56:44PM +1200, schmitz wrote:
> >> >  - mac: ADB raw packets
> >> >    I guess this can be dropped?
> >> I'd guess so - I struggle to recall what this was for. Perhaps to
> >> talk to the clock chip on some Macs. Anyone?
> >
> > If you can give instructions on how to look at this one patch (or
> > just send it in email), I'll take a look and hopefully I remember
> > enough of the history to give some kind of explanation.
> 
> https://git.kernel.org/cgit/linux/kernel/git/geert/linux-m68k.git/log/?h=m68k-queue
> and click on the commit you're interested in.

Thank you. I took a look, and I agree with everyone else that this was a
legacy patch that isn't required.

The original idea was to use the same API for both real ADB requests and
everything else that goes through the PMU, Egret, or CUDA chips. This
includes not only RTC/PRAM management, but power control and several
other things as well. It wasn't such a great idea, honestly.

	Brad Boyer
	flar@allandria.com

Re: m68k-queue

[Brad Boyer]

On Fri, May 17, 2013 at 10:40:17AM +1200, Michael Schmitz wrote:
> I've lost track - does the current unstable/experimental debian-ports
> distribution boot and install on Macs? Shame there's no such thing as
> 060 accelerator for Macs, but with 040 models it might be feasible.

At one point, I remember being told that someone had managed to build
an 060 upgrade for some 040 based Mac. However, it required patching the
ROM as well. The official Apple ROMs for the 040 models are incapable of
booting and running reliably on an 060. Most models have unique ROMs,
which makes such a project even harder. It might be easier to get it
working if only Linux needed to work, but it's still likely to be painful.

It's similar to making an 040 upgrade board for an 030 based Mac, which
I believe were available. Those sorts of things generally do the initial
boot on the original processor then patch the OS in RAM and switch.

We would probably get a better performance boost out of getting drivers
working for some more NuBus cards. There were SCSI cards with real DMA
(as well as better chipsets like the NCR 53c7xx series or the Qlogic
ISP1000) that would make a big difference. A BusMaster card could
offload data movement for a variety of uses. There were video cards with
extensive 2D acceleration as well. Some of the Radius video cards appear
to be programmable enough to be used similarly to the BusMaster.

I have a pretty good collection of these cards, but it's hard to find
time to work on this stuff due to my regular job. In particular, I have
an FWB JackHammer (53c720) and an ATTO Silicon Express IV (ISP1000).
These cards are both Ultra-Wide SCSI and have real DMA engines.

	Brad Boyer
	flar@allandria.com

Re: m68k-queue

[schmitz]

Brad,

>> https://git.kernel.org/cgit/linux/kernel/git/geert/linux-m68k.git/log/?h=m68k-queue
>> and click on the commit you're interested in.
>>     
>
> Thank you. I took a look, and I agree with everyone else that this was a
> legacy patch that isn't required.
>
> The original idea was to use the same API for both real ADB requests and
> everything else that goes through the PMU, Egret, or CUDA chips. This
> includes not only RTC/PRAM management, but power control and several
> other things as well. It wasn't such a great idea, honestly.
>   
I'm sure it was one of these 'how can we get some piece of code reused 
to do something almost entirely unrelated' ideas. Sounds like what I'd 
have done just to solve the hwclock handling and get on with hacking 
other stuff without being irritated by constant fscks ...

Code quality has improved a huge lot since. Keep in mind that mac68k was 
developed separate from m68k in the beginning. I have never had Alan's 
instinct for writing good clean code, 'it works' was usually good enough.

Cheers,

    Michael

Re: m68k-queue

[Brad Boyer]

On Sat, May 18, 2013 at 08:38:26PM +1200, schmitz wrote:
> I'm sure it was one of these 'how can we get some piece of code
> reused to do something almost entirely unrelated' ideas. Sounds like
> what I'd have done just to solve the hwclock handling and get on
> with hacking other stuff without being irritated by constant fscks
> ...
> 
> Code quality has improved a huge lot since. Keep in mind that mac68k
> was developed separate from m68k in the beginning. I have never had
> Alan's instinct for writing good clean code, 'it works' was usually
> good enough.

I hope nobody took my comments as criticism of their coding skills. I'm
pretty sure I was not only involved in but at the time actively advocated
the solution I was saying was a bad idea. I've certainly been guilty of
as much or more sloppy coding than everyone else.

In any case, I want to encourage all the people who still do work on
this that their work is not wasted and people do appreciate it.

	Brad Boyer
	flar@allandria.com