Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1191462 > unrolled thread

Re: [RFC v4 03/25] m68k/atari: Move Atari-specific code out of drivers/char/nvram.c

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [RFC v4 03/25] m68k/atari: Move Atari-specific code out of drivers/char/nvram.c Michael Schmitz <schmitzmic@gmail.com> - 2015-07-24 05:00 +0200
    Re: [RFC v4 03/25] m68k/atari: Move Atari-specific code out of  drivers/char/nvram.c Michael Schmitz <schmitzmic@gmail.com> - 2015-07-26 03:10 +0200
      Re: [RFC v4 03/25] m68k/atari: Move Atari-specific code out of  drivers/char/nvram.c Finn Thain <fthain@telegraphics.com.au> - 2015-07-26 03:30 +0200
    Re: [RFC v4 03/25] m68k/atari: Move Atari-specific code out of  drivers/char/nvram.c Finn Thain <fthain@telegraphics.com.au> - 2015-07-26 03:40 +0200

#1191462 — Re: [RFC v4 03/25] m68k/atari: Move Atari-specific code out of drivers/char/nvram.c

Hi Christian,

here's what Finn asked me to run as tests:

# dmesg | grep this_id > nvram.out
# cat /proc/driver/nvram >> nvram.out
# hexdump -C /dev/nvram >> nvram.out
# cp /dev/nvram /tmp/nvram
# cp /tmp/nvram /dev/nvram
# md5sum /dev/nvram /tmp/nvram >> nvram.out

What you sent so far looks OK. I've tested the change of SCSI ID
(using EmuTOS) along with a trivial patch to atari_scsi.c (replace
offset 14 by 16) and the driver now uses the stored ID properly. I'll
sent kernels to test Finn's NVRAM patch for regression ASAP.

Thanks for your offer of help!

Cheers,

  Michael


On Thu, Jul 23, 2015 at 9:21 PM, Christian T. Steigies <cts@debian.org> wrote:
> On Wed, Jul 22, 2015 at 02:22:21PM +1000, Finn Thain wrote:
>>
>> Anyone with a suitable Atari, i.e. ATARIHW_PRESENT(TT_CLK), who can boot
>> both TOS and Linux could resolve the question. (Perhaps with an emulator?)
>>
>> Any old kernel binary would do, since atari_scsi should print either
>> "HOSTID=n" or "this_id n" at startup.
>>
>> If n doesn't agree with what TOS says about the host's SCSI ID, then I
>> think a trivial patch is safe enough. Especially if cat /proc/driver/nvram
>> produces a "SCSI host ID : m" that does agree with TOS.
>
> root@garkin:~>cat /proc/hardware
> Model:          Atari Falcon
> System Memory:  522752K
>         510 MB at 0x01000000 (alternate RAM)
> Detected hardware:
>         Falcon Shifter
>         Programmable Sound Generator
>         PCM 8 Bit Sound
>         CODEC Sound
>         SCSI Controller NCR5380 (Falcon style)
>         IDE Interface
>         8/16 Mhz Switch for FDC
>         Multi Function Peripheral MFP 68901
>         Serial Communications Controller SCC 8530
>         Paddle Interface
>         DMA Controller for SCC
>         Clock Chip MC146818A
>         Blitter
>         DSP56001 processor
>
> root@garkin:~>dmesg |grep SCSI
> [    0.000000] Atari hardware found: VIDEL STDMA-SCSI ST_MFP YM2149 PCM CODEC DSP56K SCC_DMA SCC ANALOG_JOY BLITTER IDE TT_CLK FDC_SPEED
> [    0.410000] SCSI subsystem initialized
> [    0.850000] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 251)
> [    4.230000] Atari SCSI: resetting the SCSI bus... done
> [    6.750000] scsi host0: Atari native SCSI, io_port 0x0, n_io_port 0, base 0x0, irq 15, can_queue 8, cmd_per_lun 1, sg_tablesize 0, this_id 7, flags { }, options { REAL_DMA SUPPORT_TAGS }
>
> root@garkin:~>cat /proc/driver/nvram
> Checksum status  : not valid
> Boot preference  : 0xff (undefined)
> SCSI arbitration : on
> SCSI host ID     : 7
> OS language      : 255 (undefined)
> Keyboard language: 255 (undefined)
> Date format      : 7 (undefined), 24h clock
> Boot delay       : 255s
> Video mode       : 4 colors, 40 columns, TV NTSC monitor
>                    no overscan, compat. mode off
>
>
> Let me know if you need more info.
>
> Christian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1192451 — Re: [RFC v4 03/25] m68k/atari: Move Atari-specific code out of drivers/char/nvram.c

Hi Finn,

For the sake of completeness: further testing on ARAnyM shows no 
difference between original and patched kernel in the NVRAM proc and 
diff outputs:

scsi host0: Atari native SCSI, io_port 0x0, n_io_port 0, base 0x0, irq 
15, can_queue 8, cmd_per_lun 1, sg_tablesize 0, this_id 7, flags { }, 
options { REAL_DMA SUPPORT_TAGS }
Checksum status  : valid
Boot preference  : unspecified
SCSI arbitration : on
SCSI host ID     : 7
OS language      : English (US)
Keyboard language: English (US)
Date format      : DD.MM.YY, 24h clock
Boot delay       : 32s
Video mode       : 4 colors, 40 columns, TV NTSC monitor
                    no overscan, compat. mode off
00000000  00 00 00 00 00 00 00 00  11 2e 20 01 ff 00 00 3b |.......... 
....;|
00000010  87 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00 
|................|
00000020  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00 
|................|
00000030  de 21                                             |.!|
00000032
d640bf7d535b54e39582fabdc016d7ca  /dev/nvram
d640bf7d535b54e39582fabdc016d7ca  /tmp/nvram

Happy to help ...

Cheers,

     Michael

> On Sat, 25 Jul 2015, Michael Schmitz wrote:
>
>> Hi Christian,
>>
>> good to know this worked - for the record (Finn), this is the kernel
>> with Finn's patch applied.
> That was v5 of this patch series. I will send that out to the lists now.
> It has some minor changes that relate to powerpc.
>
> Thanks for your help with this, Michael.
>
> Finn
>
>> I'll build the missing LVM module so Christian can run the tests on the
>> unpatched kernel as well.
>>
>> Thanks for testing!
>>
>>      Michael
>>
>>

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1192452 — Re: [RFC v4 03/25] m68k/atari: Move Atari-specific code out of drivers/char/nvram.c

On Sun, 26 Jul 2015, Michael Schmitz wrote:

> Hi Finn,
> 
> For the sake of completeness: further testing on ARAnyM shows no difference
> between original and patched kernel in the NVRAM proc and diff outputs:
> 
> scsi host0: Atari native SCSI, io_port 0x0, n_io_port 0, base 0x0, irq 15,
> can_queue 8, cmd_per_lun 1, sg_tablesize 0, this_id 7, flags { }, options {
> REAL_DMA SUPPORT_TAGS }
> Checksum status  : valid
> Boot preference  : unspecified
> SCSI arbitration : on
> SCSI host ID     : 7
> OS language      : English (US)
> Keyboard language: English (US)
> Date format      : DD.MM.YY, 24h clock
> Boot delay       : 32s
> Video mode       : 4 colors, 40 columns, TV NTSC monitor
>                    no overscan, compat. mode off
> 00000000  00 00 00 00 00 00 00 00  11 2e 20 01 ff 00 00 3b |.......... ....;|
> 00000010  87 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00 |................|
> 00000020  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00 |................|
> 00000030  de 21                                            |.!|
> 00000032

I'd expect to see a change in the Video mode above, because of patch 2.

With 0x3B in byte 15, I'd expect the patched kernel to produce something 
similar to Christian's /proc/driver/nvram results.

-- 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1192454 — Re: [RFC v4 03/25] m68k/atari: Move Atari-specific code out of drivers/char/nvram.c

On Sat, 25 Jul 2015, Michael Ellerman wrote:

> On Sat, 2015-07-25 at 10:35 +1000, Finn Thain wrote:
> > 
> > ... These are rudimentary tests but combined with my own testing on 
> > m68k, ppc32 and x86, coverage is quite good. Some testing on ppc64 is 
> > still lacking though.

Here's some code I wrote some time ago to help me test these patches, 
maybe it will help others (though independent results may be more 
valuable...)


-- -- 8< -- -- 


#!/bin/sh
set -e -u -x
temp=`mktemp /root/nvram.XXXX`
test -f "$temp"
cat /proc/version
if ! test -e /dev/nvram ; then
    mknod /dev/nvram c 10 144
fi
ls -l /dev/nvram
if test -c /dev/nvram ; then
    cp /dev/nvram "$temp"
    hexdump -C "$temp"
    cp /dev/zero /dev/nvram || true
    hexdump -C /dev/nvram
    cp "$temp" /dev/nvram
    hexdump -C /dev/nvram
fi


-- -- 8< -- -- 


#include <stdio.h>
#include <sys/ioctl.h>
#include <errno.h>

#if defined(__powerpc__)
#include <asm/nvram.h>
#elif defined(__i386__) || defined(__mc68020__)
#include <linux/nvram.h>
#endif

int main(void) {
        int result, i;
        FILE *f;

        f = fopen("/dev/nvram", "r+");
        if (!f) {
                perror("fopen");
                return 1;
        }

#if defined(__powerpc__)
        result = ioctl(fileno(f), IOC_NVRAM_SYNC);
	fprintf(stderr, "ioctl IOC_NVRAM_SYNC: result %d, errno %m\n", result);

        for (i = 0; i <= 8; ++i) {
                int arg = i;

                result = ioctl(fileno(f), IOC_NVRAM_GET_OFFSET, (long)&arg);
		fprintf(stderr, "ioctl IOC_NVRAM_GET_OFFSET: i %d, result %d, offset %d, errno %m\n", i, result, arg);
        }
#elif defined(__i386__) || defined(__mc68020__)
        result = ioctl(fileno(f), NVRAM_INIT);
	fprintf(stderr, "ioctl NVRAM_INIT: result %d, errno %m\n", result);

        result = ioctl(fileno(f), NVRAM_SETCKS);
	fprintf(stderr, "ioctl NVRAM_SETCKS: result %d, errno %m\n", result);
#endif

        return 0;
}


-- 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web