Port-sandpoint archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Synology PPCBoot SK98 network bug fix



Hi,

> Ok. Now it works for me too!

Great!

> 1. I get a warning that the howmany() macro is unknown in raidframe.h:
>   warning: implicit declaration of function 'howmany'
> This is solved by including <sys/param.h>. I wonder how it worked for you?

Oops!  Fixed.  My build was pulling in the system raidframevar.h (which
didn't have the "howmany" definition).

> 2. You are still using 'first' to calculate the offset for your partitions
> in the RAID: rf_offset = first + RF_PROTECTED_SECTORS;
> Although it works for you now, it would probably fail if you had a
> non-RAID partition in your disklabel before the RAID part. For example:
>   a: 144808272        63     4.2BSD   2048 16384     0
>   d: 167773473 144808335       RAID
> Here rf_offset should be 144808335+RF_PROTECTED_SECTORS and not
> 63+RF_PROTECTED_SECTORS. Solution: Use the RAID partition's 'p_offset'
> instead of 'first'.

That's true.  However, as I mentioned before, perhaps it is better to only
allow a RAID partition as the first partition (or not at all).  In the
above case, we can't tell if the bootable partition is 'a' or 'd'.  So,
I'm inclined to just check if partition 'a' is of type RAID.

> 3. When you read the new disklabel from RAID you assume that it starts
> right at the beginning of the sector. Probably this is always true, but
> I would not rely on that, but scan through all the 512 bytes of the
> sector, while looking for DISKMAGIC (as already done before).

OK.  I will do that.

> The disk lights? In my older model the disk LED cannot be controlled at
> all. It is directly connected to the disk. The known protocol allows to
> control the power LED, the status LED and the USB LED.

Yes.  There are two disk lights on the DS207.  I will look through the
linux source to see where they are controlled from.

Somewhat more annoying to me is my current network problem.  I mentioned
before that neither altboot nor the kernel could transmit packets.  This is
still the case after a power cycle.  I can download a new altboot.bin using
`bootp` from the firmware prompt to test fixes, which is good, so I will
try and spot what has gone wrong in the chip initialisation (I have register
dumps from altboot to compare).

Thanks,

J

-- 
  My other computer also runs NetBSD    /        Sailing at Newbiggin
        http://www.netbsd.org/        /   http://www.newbigginsailingclub.org/


Home | Main Index | Thread Index | Old Index