Re: Synology PPCBoot SK98 network bug fix

[Frank Wille <frank%phoenix.owl.de@localhost>]

On Tue, 14 Jun 2011 08:37:53 +0100
Julian Coleman <jdc%coris.org.uk@localhost> wrote:

> I looked again at our kernel driver and also the ppcboot sources, and saw
> that we don't do the XMAC set up in altboot.

AFAIK the XMAC registers are irrelevant for a Marvell Yukon chip.


>  However, adding that didn't
> make any difference, so I'm still using 8 receive buffers.

There must be something we are missing. Increasing the number of
receive buffers is not an option.

A last possibility would be to dump the registers when the kernel
driver is running, to spot any differences.


> copied it via bootp and wrote it to flash at 0xFFF5000.  I still get:
> 
>   *** Warning - bad CRC, using default environment
> 
> though.  I checked that the CRC was correct by using:
> 
>   crc32 fff50004 20000 0
> 
> so I must have the address wrong.

According to ppcboot/include/configs/DS207.h the address seems correct.
For comparison: my 101g+ stores its environment strings at 0xfff40000.


> I added RAIDframe to the GENERIC kernel and configured the two disks as
> RAID 0.

Excellent idea! Running multi-disk NAS boxes in RAID mode should be
quite normal, but I never had the chance to test that.


> fdisk:
>   0: NetBSD (sysid 169)
>     start 64, size 625142384 (305245 MB, Cyls 0/1/2-38913/80/63)

Why 64? IIRC the MBR must not be changed when using RAID. So you could
probably align your NetBSD MBR partition with the first track. It is 63
in my case.


> disklabel:
>   e: 625142384        64       RAID                     # (Cyl.      0*-
> 620180)

Why 'e'? Maybe it doesn't matter, but I do usually take 'a'.


> and the boot output:
> 
>   wd0: <ST3320620AS> DMA LBA LBA48 305245 MB
>   wd0e: raid
>   raid.a: ffs (128)
>   raid.b: swap        (4194432)
>   raid.d: ffs (5245056)
>   raid.e: ffs (9439360)
>   raid.f: ffs (17827968)
>   raid.g: ffs (26216576)
>   raid.h: ffs (30410880)

Nice.


> One thing that I noticed was that the dsk.c:dsk_strategy() doesn't seem to
> read from the correct offset.  It has:
> 
>       if ((dlp = d->dlabel) != NULL)
>               bno += dlp->d_partitions[d->part].p_offset;

It reads from the correct offset, as long as you don't have a RAID
setup.


> but the partition offsets are relative to the start of the disklabel, and
> not relative to the start of the disk.  So, I added the offsets to all the
> partitions in decode_dlabel() (for all cases, not only RAID).

Hmmm...


> I'm not
> sure how it worked before if the boot partition wasn't at the start of
> the disk?

It worked, because the MBR partition offset was taken into account, here:
        first = (bsdp) ? bswap32(bsdp->mbrp_start) : 0;


> Note, that the patch will not work if there is a boot partition
> followed by RAID paritions on the disk.

When I apply your patch, it doesn't work for me, using a normal wd0a
boot partition. Seems you missed something.

For example I do not understand why you are adding the MBR-partition
offset 'first' again, to all partitions:
                pp->p_offset += first + rf_offset;

This moves my wd0a from 63 to 126, and loading fails.

What I think you have to do is to read the RAID disklabel (probably
at wd0e+RF_PROTECTED_SECTORS+LABELSECTORS in your case), as soon as
you find a RAID-fs. Then fix all partition-offset fields in this label,
by adding the start sector of your RAID partition (wd0e).


> I also noticed that:
> 
>   go 1000000 wd0:netbsd ask
> 
> didn't cause the kernel to ask for the root partition,

Options must always be specified before the kernel name.
Or you can also say: the kernel name does always have to come last. :)


> and that the disk lights stay as blinking orange.

Altboot stops the Power LED from blinking, as one of its first actions.
Never had a problem here.


-- 
Frank Wille