Date: Sun, 17 Feb 2008 22:36:13 +0100 From: Rafal Jaworowski <raj@semihalf.com> To: Marcel Moolenaar <xcllnt@mac.com> Cc: Marcel Moolenaar <marcel@freebsd.org>, Perforce Change Reviews <perforce@freebsd.org> Subject: Re: PERFORCE change 135517 for review Message-ID: <47B8A8CD.3040707@semihalf.com> In-Reply-To: <ABEEBD0D-6693-4448-8D2F-679F37367832@mac.com> References: <200802162141.m1GLfgkj048217@repoman.freebsd.org> <47B75EB3.2020001@semihalf.com> <504560A3-EABB-4896-8B3E-C7FC89F31EFB@mac.com> <47B84D9B.4010903@semihalf.com> <ABEEBD0D-6693-4448-8D2F-679F37367832@mac.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Marcel Moolenaar wrote: >>>>> Save U-Boot's registers at startup and restore them when >>>>> performing a syscall. This way we don't have to compile >>>>> code specially to avoid using those registers. Otherwise >>>>> we have to encode knowledge of those registers in at least >>>>> 4 makefiles and introduce a build knob to enable it all. >>>>> This does not allow us to build everything with a single >>>>> build world. >>>> >>>> Hi Marcel, >>>> >>>> I'm not quite sure this is sufficient... I already had a similar >>>> save/restore >>>> in place, but there is some general problem with U-Boot that leads to >>>> hangs >>>> (experienced): >>> >>> Interesting, I didn't see any such problems with 1.3.2-rc1. >>> >> >> After a bit of digging, I guess this is why it didn't bite you up >> front: very >> recently (last minute inclusions during 1.3.2-rc1 preparation) Wolfgang >> changed the dedicated regs layout... with r29 going -> r2 due to certain >> problems with gcc 4.x producing bigger code when not all 'high' >> registers it >> likes are available in the whole block etc. > > I'm happy I removed all that knowledge in makefiles and put it in a > single source file. Maybe we should save and restore all registers > so that we don't have to worry about it anymore. > I don't feel saving/restoring all registers is really required. The problem really is not in what we do when synchronously calling the API, which is under control, but that full context is not saved/restored when u-Boot takes exceptions. Another comment: please note that killing WITH_UBOOT introduces another problem: now both sys/boot/powerpc/uboot/loader and sys/boot/powerpc/ofw/loader are built during buildworld, which may be good from one point of view, but there's no control over which of the loader file is taken during installworld: it seems the last one (u-boot's in this case) overwrites the previous... With such approach at least different names for the binaries are needed, but I'm still not quite convinced WITH_UBOOT should be gone. I'd like to have some control against what underlying firmware the PPC loader is built/installed. Rafal
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?47B8A8CD.3040707>