Date: Sun, 9 Mar 2008 20:26:33 +0000 (GMT) From: wpaul@FreeBSD.ORG (Bill Paul) To: raj@semihalf.com (Rafal Jaworowski) Cc: marcel@FreeBSD.org, cvs-src@FreeBSD.org, xcllnt@mac.com, cvs-all@FreeBSD.org, src-committers@FreeBSD.org Subject: Re: cvs commit: src/sys/powerpc/booke machdep.c Message-ID: <20080309202633.1DEC11065672@hub.freebsd.org> In-Reply-To: <47D2E72E.1000107@semihalf.com> from Rafal Jaworowski at "Mar 8, 2008 08:21:18 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
> Marcel Moolenaar wrote: > >> > >> Thanks for hooking this up, Marcel; it was [far] on my list too :) > > > > I just wanted my kernel builds to be faster :-) > > > > Ah, self-hosted builds you mean? Over NFS, right? (this is how we usually test > this) > > >> BTW: currently U-Boot is broken for most of PPC variations (including > >> 85xx) in > >> the following way: d-cache is not being flushed before disabling and > >> strange > >> things happen as you imagine. For a quick workaround apply something > >> like this > >> when using ELF images: > >> http://people.freebsd.org/~raj/patches/misc/uboot-dcache-workaround.diff > > > > Yup. That's what we do at Juniper. I don't see any bad effects other > > than having to invalidate the cache before (re-)enabling it so I don't > > have that patch applied myself... > > > > I have seen strange things, including hangs, and also TSEC non-functional > effects due to this issue... :) > > > The problem I'm having with U-Boot is with the TSEC driver as you've > > seen on the U-Boot mailing list. I have one MPC8555CDS sitting idle > > after the U-Boot upgrade because I can't netboot :-/ > > > > Yes, I saw. Let me re-flash my 8555 with the latest image and try, but when > I'm not remote i.e. Monday. Don't know if you know this tip, but there used to > be a second flash bank on the MPC8555CDS that you can access while running > from the boot one, so you can recover in such scenario without a h/w debugger > by copying over that backup flash bank, provided you have a working image there... > > Rafal > I am not on the U-Boot mailing list, so I'm not familiar with the TSEC problems you're having, but I'm curious: are you saying that when you try to boot a FreeBSD kernel image with the cache disabled, U-Boot can download and start the kernel, but FreeBSD fails to mount its rootfs correctly because of problems with the TSEC? If that is what you're saying, then something about this is very confusing: the FreeBSD TSEC driver appears to be enabling the TSEC's RX and TX snooping featurss, so in theory (if I understand things correctly, which I might not), the cache behavior really shouldn't affect it. With VxWorks, the bootrom typically runs with the data cache disabled and then the VxWorks image enables it once it's loaded, but the same TSEC driver works properly in both scenarios. Some questions that I have: - Is bus_dma aware of the fact that the TSEC is snooped? Because if it is, it seems to me that all the sync operations should reduce to no-ops. - In the encap routine, the driver always sets the R bit immediately on the first descriptor of every outbound frame. (The Ready bit is basically the ownership bit that indicates to the TSEC that the descriptor is ready for processing.) The VxWorks driver always leaves the R bit in first descriptor cleared until all subsequent descriptors have been set up. This is to prevent the TSEC from potentially racing with the encap routine and processing the first few descriptors of an outbound frame before all descriptors are ready. It might be a good idea to have the encap routine in the FreeBSD driver work the same way. I know the idea is to set up all the descriptors first and then initiate transmission by setting the THLT bit in the TSTAT register, but this doesn't account for the possibility that the transmitter is already busy with a previous transmit request when you go to set up new descriptors. - Has anyone actually tried to debug the TSEC issue, such as by setting up tcpdump to capture traffic from the 8555 or instrumenting the driver? It might be worthwhile to actually find the problem rather than just saying "it works if we hack U-Boot" since this might be a symptom of a larger problem that needs to be fixed. -Bill
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080309202633.1DEC11065672>