freebsd on pi4b won't boot

(This follows from the wireshark thread, but I've tried to move on)
I have a sparkling new rpi4B 4Gb. It booted raspbian (off the net)
happily, so I know that (a) the hardware works, and (b) I know how to
write the relevant sd card.
I've written the system
FreeBSD-13.0-RELEASE-arm64-aarch64-RPI.img
onto the sdcard, but all I get is the multicoloured screen that
indicates a problem. The green LED flickered irregularly on the way -
but hard to know which flickers are significant.
(I've used the same system in a pi3 - boots correctly)
I've also tried putting the same card in a USB reader (I gather from the
web that that ought to boot) - that gives a screenload of text moaning
about MSD command timeout plus other stuff. then seems to crash the pi
and goes back to the coloured screen.
In desperation I've tried writing the image to an HDD and connecting to
USB. That just goes to the coloured screen.
Can anyone help me get this going please? I really want to boot from HD
ultimately. Thanks.
--
Mike Scott 
Harlow, England
Reply to
Mike Scott
Loading thread data ...
[snip]
Best to take a look at the freebsd-arm mailing list archives at
formatting link
While at it, subscribe to at least freebsd-arm. I've gotten vast amounts of help there.
There are a few (many?) details to be worked through. I did it after getting my RPI4, which is now working happily, proof positive that it's a doable proposition with limited knowhow. As a first try, just pick a different snapshot and try that. Older, newer, doesn't matter. Start with SD card boot, then move to USB when you've got a good image.
I've put some random notes at
formatting link
but there are better resources by now.
Hope this helps,
bob prohaska
Reply to
bob prohaska
Sorry, didn't refresh the clipboard. My notes are at
formatting link
Alas, the disclaimer really does still apply.
Apologies for the confusion!
bob prohaska
Reply to
bob prohaska
Thanks for the advice. After posting, I kept digging around, and came up with a long thread at
formatting link

of which comment #15 gives a download link (sourceforge) for an updated u-boot.bin which works fine for the sdcard boot.
However, booting from HD, it stalled after complaining 'mountroot: waiting for device /dev/ufs/rootfs'.
Cranking up kern.cam.boot_delay to 10 sec, necessary for the pi3, has mixed success here. Sometimes boots, sometimes not; sometimes tries the network instead. I'll free up a spare disk, and see if that makes a difference.
--
Mike Scott 
Harlow, England
Reply to
Mike Scott
FWIW, here's the /boot/loader.conf for my Pi4: # more /boot/loader.conf # Configure USB OTG; see usb_template(4). hw.usb.template=3 umodem_load="YES" # Multiple console (serial+efi gop) enabled. boot_multicons="YES" boot_serial="YES" # Disable the beastie menu and color beastie_disable="YES" loader_color="NO" filemon_load="YES" net.inet.tcp.tolerate_missing_ts="1"
In particular, I don't recall where the line hw.usb.template=3 came from. If you don't have it that might be worth a try. My HDD is a 1 TB Seagate in a $10 USB-SATA case, both from Amazon, about as cheap as it gets.
If you don't have a serial console set up it might pay to acquire the usb-serial adapter needed. FreeBSD still won't listen to the USB keyboard in single-user mode. That makes it very difficult to debug (and report) problems.
Glad you got it working thus far!
bob prohaska
Reply to
bob prohaska
....
Thanks for the info.
I've now had it running happily off either sdcard or booting from HD. But I've hit another annoyance.
Basically, it won't run with two USB HDs attached. If I boot off sdcard, then plug in the disks, the first is fine: the second produces a stack of errors then crashes.
Messages start with da0: .... destroyed then it detaches the keyboard and mouse, then I get usbd_req_re_enumerate: .... USB_ERR_IOERROR, ignored
and it's power cycle time. Ouch!
Anyone had two HD's working in at once?
The PSU is the rpi 15W standard issue, btw. Could that be an issue though?
--
Mike Scott 
Harlow, England
Reply to
Mike Scott
The pi internals cannot supply 2 HDs with power. Use an external USB C hub with its own power.
--
http://www.netunix.com/
Reply to
crn
It's pretty much certain.
I do have a RasPi with two HDDs attached, but to make that work I had to get a very powerful PSU (mine's rated at 8 amps, which is more than enough, but it was not expensive), and, crucially, I had to jumper the main 5V line to the USB power pins so as to avoid the current limiting circuitry asspciated with USB within the Pi. This has my setup relying on the PSU's current limiting.
Don't do this unless you know what you're doing.
The other advice, getting a powered USB hub, is wise.
This may be jumping ahead a bit; but, if you get a hub and want to run both the Pi and the hub off the same PSU, beware of cheap power splitters that don't have enough copper in them and thus drop too much voltage.
David
Reply to
David Higton
....
OK, thanks - I get the picture. NCD, as my old maths teacher used to say.
The immediate reason for doing this is that the root partition resizes to fill the disk. I can't work out a way of making it resize to what I want -- hence a desire to copy between disks. But my knowledge of partitions is ATM clearly too limited :-{
Longer term is that this would prevent my current offline backup scheme (plug in backup disk, rsync, unplug disk) from working. I'll have to think a bit before proceeding.
Thanks again (to all, for your answers and patience).
--
Mike Scott 
Harlow, England
Reply to
Mike Scott
Don't forget that rsync can backup to a disk attached to a different machine on your LAN - when this is running there's a copy of rsync running on each machine: they talk to each other to transfer the data being backed up so, if the disk receiving backed up files is attached to a host other than the RPi, you don't need to attach more than one HDD to it.
I've been using this backup system for several years now. I'm backing up one RPi and three other Linux systems onto the same USB-connected HDD which, like you're planning to do, is kept offline in a firesafe when not receiving backups. Actually I have two backup disks, which are used in rotation, so there is always one in the firesafe with the door closed.
--
--   
Martin    | martin at 
 Click to see the full signature
Reply to
Martin Gregorie
Yes. The tradeoffs between a usb connected drive and a usb connected gigabit ethernet are worth exploring, if you have, or feel like building, a NAS type solution
--
WOKE is an acronym... Without Originality, Knowledge or Education.
Reply to
The Natural Philosopher
Thanks to both for the comments.
FWIW my main backup strategy is dump running daily, networking the output to my desktop machine. So if the server dies nastily and kills its disks, the data is safe elsewhere (although restore is /very/ messy!). That's kept for a couple of weeks. The 'rsync' backup is done occasionally, mainly to have a hot standby that's "not too out-of-date".
I'll review matters when the pi is running to my satisfaction.
--
Mike Scott 
Harlow, England
Reply to
Mike Scott
Backup frequency: I do the backups I described on a weekly basis, immediately before running software updates on all systems. That's a dnf update on the Fedora-based systems and apt update on RPis.
One of the Fedora machines is also my 'house server', which means it holds much more data, (mail archive, git repositories for locally developed software, etc.) so it additionally gets backed up overnight using rsnapshot, with the backups held on a USB drive that sits alongside the machine it backs up.
As this is primarily a sort of 'finger-trouble' protection I accept that its not proof against power spikes, fire, etc. Using a USB drive is a deliberate choice: each night a cron job mounts it, runs the rsnapshot backup and unmounts it, so it should should be fairly safe against malicious software because its invisible when unmounted. The backup run normally takes just under 10 minutes.
--
--   
Martin    | martin at 
 Click to see the full signature
Reply to
Martin Gregorie
Not trivial, but doable if you can afford a few do-overs 8-)
Here are some notes that might help:
formatting link
My procedure supposes single-user mode. You can suppress the filesystem resize by mouting the unbooted image media elsewhere and renaming or deleting an empty file in the FreeBSD root directory named firstboot.
HTH,
bob prohaska
Reply to
bob prohaska
...or a USB drive which has it's own power skt and PSU.
Reply to
NoOne

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.