Crochet should use u-boot from ports

[brd]

Mostly this is a reminder for myself

[kientzle]

RPi2 uses U-Boot from ports and can serve as a model for converting others.

I have a patch here for RPi that I'll clean up and commit soon.

I tried switching BeagleBone but couldn't get it to boot(?) I suspect I missed some subtle difference between the U-Boot BeagleBone port and Crochet's U-Boot build.

Others are fair game...

[f-andrey]

for BeagleBone working patch's https://github.com/gvnn3/crochet-freebsd/

[kientzle]

On Jun 15, 2015, at 1:27 AM, Andrey notifications@github.com wrote:

for BeagleBone working patch's https://github.com/gvnn3/crochet-freebsd https://github.com/gvnn3/crochet-freebsd

Have you built an image recently using the most up-to-date u-boot-beaglebone package?

I still get images that won’t boot.

Tim

[f-andrey]

Yes, mine main repo https://bitbucket.org/f_andrey/crochet-for-me image http://bsdnir.info/files/ more userland folder description Now this image booting with SD card, but it has a couple of problems https://lists.freebsd.org/pipermail/freebsd-arm/2015-June/011568.html

# pkg info -x ^u-b
u-boot-beaglebone-2014.10_1```

UPD: images updated

[f-andrey]

After 8232907 RPi and beaglebone perfectly building with ports u-boot

[kientzle]

This is complete for RPi, RPi2, and BeagleBone. People who have access to hardware for testing should use those as models for converting other boards.

[kah42pub]

This is a followup to my freebsd-arm post about u-boot-rpi not building. That builds for me just fine, now, but I am unable to build an RPI-B image with crochet that will boot. The build completes just fine but the boot hangs at the Uboot> prompt. I'm mostly looking to see if it just isn't working for me or if this is a wider problem. I'm building from a late July crochet snapshot and a very recent (August-2015) FreeBSD 11 Current snapshot.

I've tried writing images out to varying brands of 4GB, 8GB, and 16GB SD cards (class 4 and class 10) all with the same result. Anyone else having this problem with RPI-B?

For the record, I can build for the RPI2 and BeagleBone Black and they all work. Thanks.

Kris

[brd]

I won't be able to test till tomorrow, but until then you could try one of the RPi-B images from here: http://raspbsd.org

[kah42pub]

On 8/18/15 02:50, Brad Davis wrote:

I won't be able to test till tomorrow, but until then you could try one of the RPi-B images from here: http://raspbsd.org

— Reply to this email directly or view it on GitHub https://github.com/freebsd/crochet/issues/115#issuecomment-132148441.

Sorry it took me a while for me to get back to this. I found these images on that site:

FreeBSD-armv6-11.0-RPI-B-286145.img FreeBSD-armv6-11.0-RPI-B-286591.img FreeBSD-armv6-11.0-RPI-B-286947.img

I tried all of them across a variety of SD cards (class 4 & class 10, Kingston, Sandisk, and Lexar) of 1GB, 4GB, 8GB, and 16GB capacity and in two different RPI-B boards. All of these images/SD Card/board combinations failed in the same manner. If this is an equipment problem on my side I don't know where else to look for it. Note that I do have working images for the RPI-B from early crochet/U-Boot combinations but I don't know for sure how far back. I ran across this while trying to get everything current.

All my SD cards have been tested in a RPI2 and/or a BBB (images built with crochet) so I know they work at least for other boards.

The working image I have for the RPI-B was built with an old crochet/U-Boot version and is on a Kingston 16GB class 10 SD card. FreeBSD ... 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r280407M

Now I'm curious if you were able to make a good image. I'm actually hoping you were able to get an image that will boot - better for only one person (me) to have this problem than everyone. Thanks.

Kris

[kientzle]

I've run into cases in the past where a particular BBB was rendered almost unbootable after trying to enable eMMC booting. This is a side-effect of U-Boot being unable to determine where it was booted from (this is a limit of the ROM boot code). So even if the first-stage MLO loads from where you expect, the boot can end up chaining from SD to eMMC or vice-versa.

The only really effective way to fix this is to somehow get something booted, then zero out the first 64k or so of the eMMC. That way, SD boots will not find valid boot code on eMMC which will prevent SD boots from trying to switch to eMMC.

[f-andrey]

I'm test images for RPI-B and not confirm not bootable

Testing FreeBSD-armv6-11.0-RPI-B-286947.img via raspbsd.org and image build crochet and u-boot-rpi-2013.01_2 (updated for my site)

SDHC SD16G 3.0

# uname -a
FreeBSD raspberry-pi 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r286947: Wed Aug 19 16:28:49 MDT 2015     brd@hive.den.so14k.com:/usr/local/raspbsd/obj/RPI-B/obj/arm.armv6/usr/local/raspbsd/src/RPI-B/sys/RPI-B  arm

# uname -a
FreeBSD r-pi.local 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r286991: Fri Aug 21 20:10:29 MSK 2015     root@des.local:/usr/obj/arm.armv6/usr/src/sys/RPI-B  arm

@kah42pub Can you connect to the serial console?

[kah42pub]

On 8/21/15 10:50, Andrey wrote:

I'm test images for RPI-B and not confirm not bootable

Testing FreeBSD-armv6-11.0-RPI-B-286947.img via raspbsd.org and image build crochet and u-boot-rpi-2013.01_2 (updated for my site)

SDHC SD16G 3.0

|# uname -a FreeBSD raspberry-pi 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r286947: Wed Aug 19 16:28:49 MDT 2015 brd@hive.den.so14k.com:/usr/local/raspbsd/obj/RPI-B/obj/arm.armv6/usr/local/raspbsd/src/RPI-B/sys/RPI-B arm |

|# uname -a FreeBSD r-pi.local 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r286991: Fri Aug 21 20:10:29 MSK 2015 root@des.local:/usr/obj/arm.armv6/usr/src/sys/RPI-B arm |

@kah42pub https://github.com/kah42pub Can you connect to the serial console?

— Reply to this email directly or view it on GitHub https://github.com/freebsd/crochet/issues/115#issuecomment-133510809.

It must be something I'm doing, then. My serial cable is broken so I'll have to get a new one. Thanks for testing.

Kris

[kientzle]

Closing this since most boards have been converted to use ports.