FreeBSD 10.0 on Raspberry PI B+ no network devices

[Luiz Otavio O Souza]

On 14 October 2014 01:13, Bernd Walter wrote:
> On Tue, Oct 14, 2014 at 05:27:43AM +0200, Bernd Walter wrote:
>> On Wed, Aug 27, 2014 at 02:14:00AM +0200, Andreas Schwarz wrote:
>> > On Tue, 26 Aug 2014 19:20:38 -0400
>> > George Rosamond <george at ceetonetechnology.com> wrote:
>> > > Erich Dollansky wrote:
>> > > > On Mon, 25 Aug 2014 16:35:36 +0200 (CEST)
>> > > > Andreas Schwarz <Andreas.Schwarz at schwarzes.net> wrote:
>> > > >
>> > > >> I've got also two B+ Models two weeks ago and I'm able to use the
>> > > >> image (r269955) from my B Models without any problems. The only
>> > > >> thing, what I had to do, was to upgrade the bootloader to a recent
>> > > >> version.
>> > > >>
>> > > >> Have a look at :
>> > > >>
>> > > >>   https://github.com/raspberrypi/firmware/tree/master/boot
>> > > >>
>> > > > I used now the image from
>> > > >
>> > > > http://freebsd-current.os-hackers.jp/pub/FreeBSD/snapshots/20140725/raspberry-pi/
>> > > >
>> > > > and the machine boots. I do not know more at the moment.
>> > >
>> > > I assume the entire RPi firmware from Github directory gets dumped into
>> > > /boot/msdos?
>> >
>> > Yes, but we don't need the kernel.img, at this point we are loading the
>> > uboot.img (keep uboot.img and ubldr from your existing boot partition).
>>
>> In my case the update was even required to work with the SD card.
>> I got timeout errors after size line.
>> The same card worked fine in a 512MB B.
>>
>> After updating the bootcode to those from:
>> https://github.com/raspberrypi/firmware/tree/master/boot
>> Just bootcoed.bin wasn't enough, I also had to get fixup* and startup*.
>> The card and USB worked fine after updating all the files.
>> I also tested the updated bootcode on a normal 512MB B and it also booted.
>> Would be nice to have crochet updated for the newer bootcode.
>> If required I can also test boot on a 256MB B.
>
> Ok - that card problem seems random or contact related.
> Whatever, it is 6 am - time to sleep ;-)

I've found a missing silicon bug workaround on our driver.

It's pretty recent and i'm still building new images to test with more
cards, but it did fix all the instability i was seeing on the
identification of one of my cards.

Together with the new firmware (yes, there is another SD fix there) my
RPi B rev 2 (with this same card) has gone from unusable to rock
stable (i've done 80 cold boots without any damage/corruption to the
card).

Please, give it a try and let me know if it helps.

Luiz
-------------- next part --------------
Index: sys/arm/broadcom/bcm2835/bcm2835_sdhci.c
===================================================================
--- sys/arm/broadcom/bcm2835/bcm2835_sdhci.c	(revision 272928)
+++ sys/arm/broadcom/bcm2835/bcm2835_sdhci.c	(working copy)
@@ -312,21 +312,10 @@
 static inline void
 WR4(struct bcm_sdhci_softc *sc, bus_size_t off, uint32_t val)
 {
+
 	bus_space_write_4(sc->sc_bst, sc->sc_bsh, off, val);
-
-	if ((off != SDHCI_BUFFER && off != SDHCI_INT_STATUS && off != SDHCI_CLOCK_CONTROL))
-	{
-		int timeout = 100000;
-		while (val != bus_space_read_4(sc->sc_bst, sc->sc_bsh, off) 
-		    && --timeout > 0)
-			continue;
-
-		if (timeout <= 0)
-			printf("sdhci_brcm: writing 0x%X to reg 0x%X "
-				"always gives 0x%X\n",
-				val, (uint32_t)off, 
-				bus_space_read_4(sc->sc_bst, sc->sc_bsh, off));
-	}
+	if (sc->sc_slot.clock > 0)
+		DELAY(((2 * 1000000) / sc->sc_slot.clock) + 1);
 }
 
 static uint8_t