Debian donation to m68k arrived

The Debian m68k port has been entitled by the DPL to receive a donation of five memory expansion cards for the m68k autobuilders. The cards arrived two weeks ago and are now being shipped to the appropriate buildd admins. Adding those 256 MB memory expansion will have a huge effect to the m68k buildds, because most of them are Amigas that are currently running with “just” 128 MB.

The problem with those expansion cards is to make use of them. Sounds strange but this is the story behind it….

Those memory expansion cards, namely it is the BigRamPlus from Individual Computers, are Zorro III bus cards, which has some speed limitations. The Amiga memory model is best described in the Amiga Hardware Reference Manual. For Zorro III based Amigas this is described in the section “A3000 memory map“, where you can see that the memory model is divided into different address space. The most important address space is the “Coprocessor Slot Expansion” space, starting at $0800 0000. This is where the memory on the CPU accelerator cards will be found and which runs at full CPU speed.

The BigRamPlus, however, is located within “Zorro III Expansion” address space at $1000 0000 and will have transfer rates of about 13 MB/s. Then again there’s still the motherboard expansion memory and others like Zorro II expansion memory. Unfortunately the current kernel does not support SPARSEMEM on m68k, but is using DISCONTIGMEM as Geert Uytterhoven explained. In short: we need SPARSEMEM support to easily make use of all available memory chunks that can be found. To make it a little more difficult, Amigas do use some kind of memory priority. Memory on accelerator cards usually has a priority of 40, motherboard expansion memory has a priority of, let’s say, 20 and chip memory a pri of 0. This priority usually is equivalent to speed of memory. So, we want to have the kernel loaded to accelerator memory, of course.

Basically we could do that by using a memfile and define the different memory chunks in the appropriate priority list like this one:

2097152
0x08000000 67108864
0x07400000 12582912
0x05000000 268435424

Would be an easy solution, right? Except that this doesn’t work out. Currently the kernel will be loaded into the first memory chunk that is defined and ignore all memory chunks before that address space. As you can see 0x07400000 and 0x05000000 would be ignored because of this. Getting confused? No problem! It will get worse! ðŸ˜‰

There’s another method of accessing memory for Amigas: it’s called z2ram and will use Zorro II as, let’s say, swapping area. But maybe you guessed it: z2ram does not work for Zorro III memory (yet). So, this won’t work either.

Geert suggested to use that Zorro III memory as mtd device and finally this worked out! You’ll need these modules in your kernel: 

CONFIG_MTD=m
CONFIG_MTD_CMDLINE_PARTS=m
CONFIG_MTD_BLKDEVS=m
CONFIG_MTD_SWAP=m
CONFIG_MTD_MAP_BANK_WIDTH_1=y
CONFIG_MTD_MAP_BANK_WIDTH_2=y
CONFIG_MTD_MAP_BANK_WIDTH_4=y
CONFIG_MTD_CFI_I1=y
CONFIG_MTD_CFI_I2=y
CONFIG_MTD_SLRAM=m
CONFIG_MTD_PHRAM=m

Then you just need to create the mtd device and configure it as swap space: 

/sbin/modprobe phram phram=bigram0,0x50000000,0xfffffe0
/sbin/modprobe mtdblock
/sbin/mkswap /dev/mtdblock0
/sbin/swapon -p 5 /dev/mtdblock0

And then you’re done: 

# swapon -s
Filename                                Type            Size    Used    Priority
/dev/sda3                               partition       205932  8       1
/dev/sdb3                               partition       875536  16      1
/dev/mtdblock0                          partition       262136  53952   5

To make it even worse (yes, there’s still room for that! ;)) you can put two memory expansion cards into one box: 

# lszorro -v
00: MacroSystems USA Warp Engine 40xx [Accelerator, SCSI Host Adapter and RAM Expansion]
        40000000 (512K)

01: Unknown device 0e3b:20:00
        50000000 (256M)

02: Village Tronic Picasso II/II+ RAM [Graphics Card]
        00200000 (2M)

03: Village Tronic Picasso II/II+ [Graphics Card]
        00e90000 (64K)

04: Hydra Systems Amiganet [Ethernet Card]
        00ea0000 (64K)

05: Unknown device 0e3b:20:00
        60000000 (256M)

The two “Unknown device” entries are the two BigRamPlus cards. As you can see card #1 starts at 0x50000000 and card #2 starts at 0x60000000. Unfortunately the phram kernel module can be loaded twice with different start addresses, but the idea to start at 0x50000000 with a size of 512M won’t work either as there seems to be a reserved 0x20 bytes a range at the beginning of each card. Anyway…

So, to make a very long and weird story short: the donated memory cards from Debian can now be used as additional and fast swap space for the buildds as long as it takes to get SPARSEMEM support working.

Thanks again for donating the money for those memory expansion cards for the good old m68k port. Once done SPARSEMEM support in the m68k will benefit not only these cards in Amigas but Ataris as well.

Uncategorized

4 thoughts on “Debian donation to m68k arrived

  1. Could you load the phram
    Could you load the phram module with the full range, and then use the kernel’s badram mechanism to tell it not to use the reserved 0x20 bytes?

    1. I haven’t tried with badram

      I haven’t tried with badram option yet. And the second card is meant for another buildd, so it won’t stay in this box forever anyway…

      Additionally I would expected some race condition between these two kernel options, but that’s just an assumption.

  2. Reserved 0x20 bytes
    The AmigaOS puts a struct MemHeader at the beginning of each block of physical memory:

    struct MemHeader {
    struct Node mh_Node;
    UWORD mh_Attributes; /* characteristics of this region */
    struct MemChunk *mh_First; /* first free region */
    APTR mh_Lower; /* lower memory bound */
    APTR mh_Upper; /* upper memory bound+1 */
    ULONG mh_Free; /* total number of free bytes */
    };

    mh_Lower will normally be set to mh + 1, i.e. (u8 *)mh + 0x20, and I assume Linux uses mh_Lower and mh_Upper without adjustment (except maybe rounding up/down to page boundaries?). But I don’t think there’s any reason for Linux to preserve these structures, so if mh_Lower is set as expected then it could be adjusted downard.

    (Also note there’s no requirement that MemHeader is actually at the start of the memory chunk.)

    Based on a quick inspection of the m68k setup code, it looks like it’s the responsibility of the boot loader to read the MemHeader list and pass an array of chunk addresses to the kernel, so the fix belongs there.

    1. Yeah, under AmigaOS the

      Yeah, under AmigaOS the memory block starts at 0x50…020. At least this shows up in tools like Xopa under AmigaOS. As you can see by the pasted lines, it is no problem to use the memory from inside Linux starting at 0x50…000, though.

      My personal guess is, why that fails in the first place, that phram module is rather simple and expects a memory range en-block on one device. However, these two cards are two devices and maybe that’s the reason why it fails? OTOH the memory subsystem in Linux should hide the two devices as it should just see starting address and size.

      Anyway, regarding the boot loader it would be nice to have a newer version of amiboot anyway to fix problems with kernel size and compression, but I don’t know who wants to take that action, though. 😉

      I hope that Geert or Michael will come up with some SPARSEMEM code to test somewhen. At least they seem to be eager to make use of this for Ataris as well.

      Now, when there would be a new Super Buster rev 12 that would raise the DMA bandwidth to the Zorro III bus to 100+ MB/s, *that* would be nice, of course! ðŸ˜‰

       

Comments are closed.