# Raspberry Pi 4 announced



## ekingston (Jun 24, 2019)

In case people haven't noticed, the Raspberry Pi 4 has been announced. Theoretically it's available but as is typical, everything is back-order (in the suppliers I deal with). There are some interesting updates:

1.5 GHz Quad Core
1, 2, or 4 GB of RAM (you choose at time of purchase)
Dual 4K display support (and switch to HDMI-C type connector)
New power (usb-c type connector)

I am looking forward to seeing how things progress for FreeBSD on RPi for this one. The specs are on-par with a low-end desktop/netbook type system.


----------



## SirDice (Jun 24, 2019)

I'm actually really interested in the programmable FPGA it supposedly has. Would be interesting to be able to play with that.


----------



## ekingston (Jun 24, 2019)

SirDice said:


> I'm actually really interested in the programmable FPGA it supposedly has. Would be interesting to be able to play with that.



I didn't see that in any of the documentation. Is it mentioned on the raspberry pi site somewhere? A good FPGA that is configurable by software on the Pi itself could be a lot of fun to mess with.


----------



## SirDice (Jun 24, 2019)

The Raspberry Pi 4: A sneak peak prototype review.
					

There's been a lot of speculation from the SBC community about what the Raspberry Pi 4 will look like and the Raspberry Pi Foundation has really kept the lid on it. However, I was recently given a pretty honorable opportunity. To road-test a prototype of the Raspberry Pi 4.




					www.mickmake.com
				






ekingston said:


> A good FPGA that is configurable by software on the Pi itself could be a lot of fun to mess with.


Exactly what I was thinking too.


----------



## Ordoban (Jun 24, 2019)

Are you sure this Announcement was not an *April Fool*?


----------



## SirDice (Jun 24, 2019)

That would a shame, I was really looking forward to that.


----------



## msplsh (Jun 24, 2019)

FPGA is not listed and not visible so unless it's hiding in another chip, I wouldn't bet on it.  The prototype probably had one because that's cheaper to prototype with then having to make new silicon?  Also, April 1, FWIW.

AArch64 is destined for Tier 1 support, so this and the B+ have a lot to look forward to.


----------



## SirDice (Jun 25, 2019)

msplsh said:


> Also, April 1, FWIW.


Yeah, I'm slowly starting to realize that's probably the case. The only articles I found mentioning it are dated 1 April. Bugger.


----------



## forquare (Jun 25, 2019)

I was chatting with a friend last night, and part of me did think that this could be a nice little desktop for very simple work-loads.  Most of my heavy lifting gets done on servers, but I could always have a beefier system nearby that isn't always powered on for cases where I'd need some extra umph, but power down when I just wanted to save power.


----------



## 6502 (Jun 25, 2019)

RPi is ideal for Media Player. BTW, it is time to add SATA port.


----------



## ekingston (Jun 25, 2019)

6502 said:


> RPi is ideal for Media Player. BTW, it is time to add SATA port.



I didn't buy the RPi 3 (I have a RPi 2) specifically because I was really hoping the next one would have an M.2 slot for an SSD. Although that really breaks the price point as those things are expensive compared to there rest of the RPi components.

On the other hand, the RPi 4 sort of breaks the price point too. The 4GB model is well above the initial price of the RPi 3B+ when it came out.


----------



## SirDice (Jun 25, 2019)

At least it now has 2 USB 3.0 ports. And, as far as I know, the gigabit interface can really do gigabit speeds. With the previous Raspberries it was connected via USB bus and limited to 300Mbit/s.

I'm trying to get my hands on one but every shop I tried has them in back-order.


----------



## ekingston (Jun 25, 2019)

SirDice said:


> At least it now has 2 USB 3.0 ports. And, as far as I know, the gigabit interface can really do gigabit speeds. With the previous Raspberries it was connected via USB bus and limited to 300Mbit/s.
> 
> I'm trying to get my hands on one but every shop I tried has them in back-order.



I am happy about both the gigabit and USB 3.0 ports and looking forward to getting one myself.

When I first learned about the release of the RPi4, I went to my usual distributor and they has some in stock (according to their website). By the time I was ready to hit "buy", it informed me they were on back-order. Sure enough, going back to the product page, they were all out.

I decided to wait a few months. Not only for the RPi4 to be in-stock but also for an update to the Pi Desktop case and some cooling options specific to the 4. I can also hope that the smart people who port FreeBSD to the RPi will have the 4 included and maybe wifi working.


----------



## xtremae (Jun 25, 2019)

I checked a few European stores but they seem to be back-order only at the moment.


----------



## forquare (Jun 25, 2019)

From the *release blog post*:



> All three variants are launching today: we have initially built more of the 2GB variant than of the others, and will adjust the mix over time as we discover which one is most popular.



I'd imagine it's quite highly sought after, and if they really are 9-12 months ahead of schedule perhaps the production hadn't ramped up enough to provide a significant buffer?


----------



## ekingston (Jun 25, 2019)

forquare said:


> From the *release blog post*:
> 
> 
> 
> I'd imagine it's quite highly sought after, and if they really are 9-12 months ahead of schedule perhaps the production hadn't ramped up enough to provide a significant buffer?



I've never seen any RPi have enough stock to cover demand within the first few months of release. I will happily wait a few months. Give the after-market a chance to make cool things and then buy.


----------



## kpedersen (Jun 25, 2019)

SirDice said:


> I'm trying to get my hands on one but every shop I tried has them in back-order.



Its annoying but at least with the Pi Foundation, they do ultimately manage to keep up a stable supply after a month or two. Unlike many other projects that end up like "vaporware".

That said, if you don't need so much CPU power, around nowish (when a new model comes out), it is the perfect opportunity to stock up on the previous generation Pi 3 at second hand stores like CEX because they will be dirt cheap (~£3 here) since quite a lot of people simply want the latest model regardless and sell their old one.

Also if you know someone who works at a school you might be able to get a box full because it is too tricky to teach young kids using all slightly different models apparently.


----------



## Spartrekus (Jun 25, 2019)

will it be expensive, e.g. 100 bucks ?


----------



## ralphbsz (Jun 25, 2019)

forquare said:


> ... this could be a nice little desktop for very simple work-loads.


For a few weeks, I had a RPi3B on my workbench, while I was prototyping with it and setting it up (it now does full-time duty as an industrial control data acquisition system, which is a lot of big words for saying it measures and records a few water pressures and tank water levels). During the setup time, I had monitor, mouse and keyboard connected, and for fun I started X on it. Works fine, you can run a web browser, you can edit text in multiple terminal emulator windows. Boring. Just a normal Unix desktop. A little slow at time, but at $35 and 3W power consumption, I can handle that. So if the RPi3B was already a nice little desktop, the model 4 would definitely do it.



6502 said:


> BTW, it is time to add SATA port.


With the USB 3.0, is that really necessary? And given the form factor, and the size of a SATA connector, I'm not sure that would work well, without making it physically incompatible with the established ecosystem.



SirDice said:


> And, as far as I know, the gigabit interface can really do gigabit speeds.


Which brings up a question: For what workload and application would the CPU and other interfaces be able to actually serve the 100 MByte/s that true gigabit can transport? Given the CPU speed and number of bytes, there are only 60 instructions one could execute per byte. That's not very much.



ekingston said:


> ... I was really hoping the next one would have an M.2 slot for an SSD.


That might be feasible, by putting the M.2 "socket" on the bottom side of the board, parallel to the board; sort of in the same fashion that the SD card slot is mounted today. It might barely fit. Given that all the engineering information (circuit diagram, PC board layout) for the Pi is public, I think it should be possible for a vendor (either the Pi foundation or someone else) to try to build such a device, although I'm not 100% sure what the IP situation is.


----------



## msplsh (Jun 25, 2019)

The 3B+ was limited to 1/3 of the speed of Gigabit due to being connected via USB2.  They probably just changed the bus and now the limiter is just how fast you can deal with stuff, which might be pretty fast if you serve out of RAM.  There's four cores to do stuff with...

In order to get a SSD on it, you would probably have to disable USB 3.  But you can see from the USB benchmarks at Tom's that it's probably not even going to help.









						Raspberry Pi 4: Review, Buying Guide and How to Use
					

Faster processor, more RAM and 4K video output




					www.tomshardware.com


----------



## 6502 (Jun 25, 2019)

ralphbsz said:


> Which brings up a question: For what workload and application would the CPU and other interfaces be able to actually serve the 100 MByte/s that true gigabit can transport?


You can simply copy a file. For 4K video the files can be 10GB or more. Try to copy 10GB over 100mbit Ethernet with 10MB/s speed.


----------



## ralphbsz (Jun 25, 2019)

The Tom's Hardware benchmark seems to show that the hardware is capable of using USB storage up to ~350 MByte/s; at that point, I buy the argument that Gigabit ethernet could actually be fully utilized.


----------



## Spartrekus (Jun 25, 2019)

Hopefully we can finally run DUNE 2 on RPI 4 without huge lags.  It was actually just for the 8086 DX or SX.
This would be cool.


----------



## Deleted member 9563 (Jun 25, 2019)

That would be *486* DX or SX.  I can supply you with the appropriate chip or hardware if you're interested. Anyway, I don't know sheepshit from dates when it comes to games, but I'd think the actual requirement would be a 386, unless more speed was required.


----------



## Spartrekus (Jun 25, 2019)

OJ said:


> That would be *486* DX or SX.  I can supply you with the appropriate chip or hardware if you're interested. Anyway, I don't know sheepshit from dates when it comes to games, but I'd think the actual requirement would be a 386, unless more speed was required.


Thank you very much.

Legacy Dune 2 runs quite slow.
The libraries and the arm cpu are actually the bottle neck.





						Dune Legacy
					

Dune Legacy is an effort by a handful of developers to revitalize the first-ever real-time strategy game. The original game was the basis for the hugely successful Command and Conquer series, and the gameplay has been replicated an extended to a wide variety of storylines and series. Lead one of...




					dunelegacy.sourceforge.net
				




OJ: Nice to run DOS, it just runs fast.


----------



## ucomp (Jun 26, 2019)

msplsh said:


> .............
> AArch64 is destined for Tier 1 support, so this and the B+ have a lot to look forward to.



My tests with all three major BSDs on several SBCs in the last few days, however, speak a completely different language:
*Tier1 is light-years away*, both in terms of hardware and software.

e.g. Hardware: Look at the headline:  The Power to Serve
How could FreeBSD  serve ZFS on a hardware platform, which
has only 1 cheaper SBC on the market with ECC-RAM?
Especially, considering that the board is of course sold out ...

e.g. Software: I have never seen FreeBSD crashing like this (down to total data loss),
like on these  SD-cards & USB-sticks on the RPI3. for me  this happened 4 times in a few days!
regardless of whether it was due to the hardware or software:
This is never Tier 1-destined

As a developer you ask yourself whether you want to invest all those unpaid working hours
in a platform which is , as of now, simply incompatible with the key-features of FreeBSD
( Data-integrity, Stability, speed... and so on) .
I would say: why not (for fun) ,  to save electricity and maybe only because of the hope that time will change the current massive limits of this platform -
support for aarch64- why not ..but unfortunately currently more Tier8 or Tier9 than Tier1 

Perhaps good for Raspbian to add 2 HDMI-ports , for FreeBSD useless.

For the low price of the RPI4 we will get the fun we paid for but we will never get a Tier 1 production - ready FreeBSD because these SBCs are not built for The Power to Serve.


----------



## forquare (Jun 26, 2019)

ucomp said:


> How could FreeBSD  serve ZFS on a hardware platform, which
> has only 1 cheaper SBC on the market with ECC-RAM?



Reminder that ZFS on non-ECC RAM still has better data integrity than most other file systems on the same hardware.


----------



## 6502 (Jun 26, 2019)

I think it is obvious that FreeBSD will use UFS on RPi. ZFS on 1-2GB RAM and SD card sounds like bad idea. The price for 4GB version goes too far from the initial idea for cheap SBC. I will prefer NUC or second hand Lenovo Tiny.


----------



## forquare (Jun 26, 2019)

I was thinking for things like ZFS replication to a USB3 HDD at home, nothing particularly performance intensive.  Even 1GB RAM is fine at a push for something like that (a friend currently does this with an RPi3, albeit with hampered Ethenet performance and over USB2).


----------



## msplsh (Jun 26, 2019)

I'm not talking AArch64 Tier 1 support as a theoretical wish, it's a funded project of the FreeBSD Foundation






						FreeBSD ARMv8 64-bit ARM port | FreeBSD Foundation
					

Developers: Andrew Turner and Semihalf sp.j. Officially known as AArch64, the 64-bit ARM architecture is also known as ARMv8 and arm64. The 64-bit ARM architecture is expected to find use in traditional server markets, in contrast to the embedded and mobile markets where 32-bit ARM is widely...




					www.freebsdfoundation.org


----------



## SirDice (Jun 26, 2019)

msplsh said:


> I'm not talking AArch64 Tier 1 support as a theoretical wish, it's a funded project of the FreeBSD Foundation


Nobody said it was theoretical. There's just a bunch of work that needs to be done. In other words, it's not going to be done any time soon. 


			ARMTier1 - FreeBSD Wiki


----------



## ucomp (Jun 26, 2019)

forquare said:


> Reminder that ZFS on non-ECC RAM still has better data integrity than most other file systems on the same hardware.


perhaps true for x86 with a little luck....
I give you a hint :
e.g. U-Boot for aarch64 is currently not under BSD- "control" .


forquare said:


> ...  USB3 HDD at home ....


at home we can do all unsupported things we want  ... at home I plugged in an USB- HDD (via power passive Dongle) and it crashed the dongle to electrical death .  
long story pros and cons aarch64 consumer- hardware...
but for FreeBSD i would say:
arm64 is currently a load of crap ... has to got to Tier 3 ...
or the Foundation and Core Team would say:
O.K., we have the manpower to support it so let's go


----------



## Spartrekus (Jun 26, 2019)

6502 said:


> I think it is obvious that FreeBSD will use UFS on RPi. ZFS on 1-2GB RAM and SD card sounds like bad idea. The price for 4GB version goes too far from the initial idea for cheap SBC. I will prefer NUC or second hand Lenovo Tiny.


Let's say simply
ZFS is slow ... but fine. 
UFS is fast for RPI.


----------



## CraigHB (Jun 28, 2019)

6502 said:


> RPi is ideal for Media Player. BTW, it is time to add SATA port.



I've read RPi4 has some heating issues as a media box, even after adding a heatsink.  I use an AMLogic platform for that.  My media box runs a version of Linux (CoreELEC), but at some point I'd like to try building a media box with FreeBSD on an AMD APU, would be an interesting albeit a challenging project.  Never really considered FreeBSD on ARM, might be a stretch.


----------



## Spartrekus (Jun 28, 2019)

Hi,

What about mini HDMI?

I find that this mini HDMI is a big drawback

Kind regards




https://miro.medium.com/max/2400/1*gH0mrG3eebvHt4KTj9oOig.png


----------



## ekingston (Jun 28, 2019)

Spartrekus said:


> What about mini HDMI?
> 
> I find that this mini HDMI is a big drawback



What is the issue with mini HDMI? Other than needing an adapter (or cable with mini-hdmi on one end)?


----------



## Nicola Mingotti (Jun 28, 2019)

SirDice said:


> I'm actually really interested in the programmable FPGA it supposedly has. Would be interesting to be able to play with that.


 oh, that could be fun, a reason to buy the RPI, otherwise IMO the BeagleBones are really more interesting.


----------



## Spartrekus (Jun 28, 2019)

ekingston said:


> What is the issue with mini HDMI? Other than needing an adapter (or cable with mini-hdmi on one end)?



the adapter is rather the problem. I go to meeting rooms with the pi, without thinking about forgetting the adapter. Just the pi. ...

my monitor is happy with large hdmi, it is standard today and it is big enough not to break easily.


----------



## RobCrowston (Jun 28, 2019)

It is not mini HDMI, it is micro HDMI

I made that mistake, didn't realise until the pi4 arrived. Had to buy a replacement cable.


----------



## Nicola Mingotti (Jun 28, 2019)

It is a pity the initial spec were an Apri Fool ... I belived it, as Fox Mulder would 

In this case I see no reason at all to leave the BeagleBone. This device has no PWM and no ADC. For electronics projects is not much interesting.


----------



## Spartrekus (Jun 28, 2019)

Hi Nico,
what would be the best alternative to RPI 3 or 4 ?


----------



## Nicola Mingotti (Jun 28, 2019)

Spartrekus said:


> Hi Nico,
> what would be the best alternative to RPI 3 or 4 ?



Hi Spartrekus ! 

The only two boards similar to RPI  i tried are the RPI (2|3) [not sure of the number right now, I am at airport] and the BeagleBone Black/Green.

I saw many reviews of other machines online and, in my opinion, they are more similar to the RPI than to the BBB. If you want to play with electronics, the is BBB is superior to the RPI from all points of view. It is true, it costs a bit more. 

What I particularly love in the BBB is that it has these features other SOC usually do not have:
-] PWM: this is very useful for motors. Bitbanging a GPIO is not a serious option.
-] ADC: this is useful if you want to read an analog signal, e.g. how much light there is in your room.
-] PRUSS: these are 2 little processors separate from the main CPU that you can use for real time stuff.
-] eMMC + SSD: that is on BBB you have about 4G on boad storage memory, i usually install FreeBSD there. I use the SSD only for install or experiments. 
-] software controllable pull(Up|Down) on GPIO

The RPI is superior to BBB for one thing AFAIK, video streaming, because it has a specific on board chip for that.

Most of what I know on this stuff I learnt on Derek Molloy book "Exploring BeagleBone". It is a very good book. 

bye


----------



## ralphbsz (Jun 29, 2019)

ucomp said:


> ... serve ZFS on a hardware platform, which has only 1 cheaper SBC on the market with ECC-RAM?


As forquare already said: ECC is not a prerequisite for ZFS. On the contrary, ZFS without ECC is still better (in terms of data durability) than other file systems without ECC. What is however true: since ZFS solves quite a few other data corruption issues (using checksums and scrubbing), the next big gain to be made once one has ZFS running is to use ECC. So ECC helps relatively more on ZFS than on other file systems.



> I have never seen FreeBSD crashing like this (down to total data loss),
> like on these  SD-cards & USB-sticks on the RPI3. for me  this happened 4 times in a few days!


I ran FreeBSD on a RPi3B for a few months, including a few days of intense prototyping on the lab bench. I don't remember it ever crashing. Nor did I have any data loss episode.



6502 said:


> I think it is obvious that FreeBSD will use UFS on RPi. ZFS on 1-2GB RAM and SD card sounds like bad idea.


Why is ZFS worse than UFS on SD cards? Rather on the contrary, if you think through how ZFS lays out data (log-based), it probably benefits from a FTL (flash translation layer) and large blocks more than other file systems.  And we know that for small file systems, you can very successfully run ZFS without terribly much memory. I have about a handful of TB of ZFS disk space in production on a 3GB 32-bit machine, which has been stable for several years.



> The price for 4GB version goes too far from the initial idea for cheap SBC.


How does the price for the 4GB version compare to competitive systems? It seems to me that being under $100 it is still very cheap.



Spartrekus said:


> Let's say simply
> ZFS is slow ... but fine.
> UFS is fast for RPI.


Do you have any evidence for ZFS being particularly slow on RPi? Show me the data.


----------



## Spartrekus (Jun 29, 2019)

ralphbsz said:


> As forquare already said: ECC is not a prerequisite for ZFS. On the contrary, ZFS without ECC is still better (in terms of data durability) than other file systems without ECC. What is however true: since ZFS solves quite a few other data corruption issues (using checksums and scrubbing), the next big gain to be made once one has ZFS running is to use ECC. So ECC helps relatively more on ZFS than on other file systems.
> 
> 
> I ran FreeBSD on a RPi3B for a few months, including a few days of intense prototyping on the lab bench. I don't remember it ever crashing. Nor did I have any data loss episode.
> ...


what about if the FreeBSD RPI3b servers a sshfs server with sshfs fuse for several machines, with two 6TB disks usb ?
The 2 x 6tb harddisks are powered by hub 3.0 high power on rpi3b.
Then, ZFS or UFS?


----------



## ralphbsz (Jun 29, 2019)

I have no idea about running sshfs. I've seen it go very wrong when administered badly.

But in general, if you have two disks, I would always run ZFS and use RAID (in this case mirroring). Unless you really don't care about your data, in which case you don't need any file system.


----------



## kpedersen (Jun 29, 2019)

Spartrekus said:


> what about if the FreeBSD RPI3b servers a sshfs server with sshfs fuse for several



Remember sshfs is very inefficient; it can only really do what SSH can do, so appending files generally involves a complete replace. A proper network filesystem like NFS or Samba is generally better. And to be honest, for batches (which sshfs is generally mentioned for), then rsync is still better.


----------



## Spartrekus (Jun 29, 2019)

ralphbsz said:


> I have no idea about running sshfs. I've seen it go very wrong when administered badly.
> 
> But in general, if you have two disks, I would always run ZFS and use RAID (in this case mirroring). Unless you really don't care about your data, in which case you don't need any file system.



for the fuse sshfs, I use the easy way if I have a distant machine.
sshfs is cool with a tunnel, so that you can use your data anywhere anytime anymachine.

ntpd_enable="YES" 
ntpd_sync_on_start="YES" 
sshd_enable="YES" 
fusefs_enable="YES" 
allscreens_flags="-f terminus-b32" 
#apache24_enable="YES" 


         nsystem( "    kldload fuse ; chmod 777 /dev/fuse " );
         nsystem("      sysctl vfs.usermount " );
         nsystem("      sysctl vfs.usermount=1 " );
         nsystem("      sysctl vfs.usermount  " );


----------



## ucomp (Jun 29, 2019)

ralphbsz said:


> ....


well, Ralph, thanks  for sharing your feedback / experiences with the arm-platform .
you seem to consider it as "Tier1/SD-card-ZFS-production-ready" and I considered it as "Tier3- crap" (at the moment)   ....
should be something  something like Tier 2 ( what it really is ) . 
--
I wanted to work on a slightly more complex port for arm64, where all 3 major BSDs are to be taken into account. As long as there are enough happy arm users like you, I think again about whether I should fish my SBC cluster  out of the recycle bin ;-) So actually fun



--- edit:--


ralphbsz said:


> ...
> in production on a 3GB 32-bit machine...


by the way ...
i386 != arm;


----------



## George (Jun 29, 2019)

I prefer a small laptop like a Pinebook. With the Raspberry Pi, half of my desk is covered with cables (keyboard, mouse, hdmi, power supply..)


----------



## ralphbsz (Jun 29, 2019)

ucomp said:


> you seem to consider it as "Tier1/SD-card-ZFS-production-ready" and I considered it as "Tier3- crap" (at the moment)   ....


I did not say that ARM is Tier 1. Matter-of-fact, I didn't say that anything about Tiers. What I did say is that when I ran it, I did not experience the frequent crashes that you seem to have experienced: I had no crashes.



> i386 != arm;


I am very aware of that. My point was that it is perfectly possible to serve ZFS on a 32-bit machine with a small number of GB of RAM. From an architectural point of view (CPU, memory, interfaces), an RPi4 with 4GB should do at least as well as my home server, which handles the workload just fine.


----------



## kpedersen (Jun 29, 2019)

Elazar said:


> I prefer a small laptop like a Pinebook.


Agreed, unfortunately those guys don't quite have their sht together to provide a stable supply. It is all "build to order / pre-order" vapourware.

Normally I would consider gutting an old broken thinkpad and putting the Pi in there but there is too much proprietary weirdness going on with i.e the video connectors.

I am basically waiting for a stable laptop shell to put a Raspberry Pi in and then I think I can pretty much abandon commercial laptops (even for work) and never ever look back. It will happen in possibly about 5 years time? Can't wait.


----------



## ucomp (Jun 29, 2019)

ralphbsz said:


> I did not say ..... I didn't say...... What I did say is ..., I did ....*I had no crashes.*


Regardless of what you didn't say that I said that you did say but you didn't say ...
öööh, what did I want to say?..  the weather is very hot in Europe  today, I have to begin again   ...

thanks for the information  that you had no crashes , so I'm currently thinking of the sense of a HCL(hardware compatibility-list ) , specially for peripherals on arm and storage devices.... although I currently guess that these devices are not reliable for a stable storage cluster and ZFS... I`ll try it again and if crashes again I will come with crash-logs(if possible).. or something similar



kpedersen said:


> ...
> I am basically waiting for a stable laptop shell...  in possibly about 5 years time...



Apple will do the business while your PI is crying for help in the thinkpad 

by the way I've got a Rock64 , booting OpenBSD&NetBSD, FreeBSD unfortunately  is only capable to boot via PXE.... but that's another thing...


----------



## kpedersen (Jun 30, 2019)

ucomp said:


> Apple will do the business while your PI is crying for help in the thinkpad



Microsoft beat Apple to it in terms of a locked down consumer toy using an ARM chip. A broken Pi in a broken Thinkpad is infinitely more usable than either of these products and will last much longer in all fairness


----------



## ucomp (Jun 30, 2019)

kpedersen said:


> ...A broken Pi in a broken Thinkpad is infinitely more usable than either of these products and will last much longer in all fairness


Since Sir Ive left Apple they will consider to work with you as the new hardware-designer .   
... RT failed, afaik e.g. Asus NovaGo failed, but wait for the Arm-Unix-Macbook,
it won't fail.. 
while you will give a talk on your ThinkPi on a BSDCan, FreeBSD 14 src will be typed on a Macbook ;-)


----------



## ucomp (Jun 30, 2019)

kpedersen said:


> ... locked down consumer...


just to add :
what they really locked down is not the consumer,  ... there are millions of   happy Mac-Consumers since decades...

What they  really locked down is the professionals on HiPerformanceComputing( now addressed by new MacPro) and especially on the server side. Good for FreeBSD, if Apple would make a better Server-OS than FreeBSD, some of us were not here.

The RPI4 won't address the gap between Server power and power-consumption.
Its a toy and although I found it really cool to type into the FreeBSD/NetBSS/OpenBSD- SBC-shells on my iPad via VNC , this is really just for fun and doesn't address the need for power-saving servers...

So Mr. Pedersen, we are waiting for you as the new FreeBSD-chief hardware-designer ;-)   please give us  new ideas for a power-saving Arm-server
or you will be fired       ;-)


--- edit:--
perhaps the RPI4 performs a little better on FreeBSD than what I've seen on other SBCs, we will see... I have not much hope to be honest because what do we want from 50-60$ ?@ Apple you won't  get a keyboard for this price
--


----------



## kpedersen (Jun 30, 2019)

ucomp said:


> Apple would make a better Server-OS than FreeBSD, some of us were not here.



Apple can never make a better Server-OS. Those times have passed; it will be playing catch up millions of man-hours. The days of proprietary operating systems (in the enterprise at least) is disappearing extremely quickly.

Once Windows becomes a weird Linux distro and macOS simply disappears like most old-fashioned UNIXes; I don't think we will ever see a proprietary operating system taking over again.
The future still isn't ideal though, I think where users will be stung and imprisoned is on the hardware side instead. Possibly worse because it is a harder problem to solve. Jail Breaking is a never ending cycle .



ucomp said:


> So Mr. Pedersen, we are waiting for you as the new FreeBSD-chief hardware-designer ;-)   please give us  new ideas for a power-saving Arm-server
> or you will be fired       ;-)



Yep, I had just 2 requirements originally:

As open as an off-the-shelf x86 server
More than 2 suppliers
But then I realized, #2 can not exist if it isn't fairly open hardware; so honestly we can reduce the requirements to just:

More than 2 suppliers
Until then, it is a toy and the industry as a whole will not touch it. This can even be seen in history when IBM refused to buy Intel as the only supplier, so Intel licensed to AMD ultimately producing some good amount of competition in the long run and ensuring that if Intel (or AMD) ever locked down users too much, it would certainly go bankrupt.

And then finally as chief FreeBSD hardware designer; once the above happens, then we will invest time and man power into supporting it in a technical capacity... but not a moment sooner IMO. Sure developers can hack on these toys for fun; but users should not expect any kinds of professional guarantee.

Hacking on the Raspberry Pi is fun but how many revisions did the BBC Micro have before it disappeared off the face of the planet and left only x86 in its wake? I rekon we will have another 5 years of the Pi before it disappears (Pi 6 being the last one?). Is that *really* worth a developer spending many hours of their life on unless they are having fun or learning?


----------



## CraigHB (Jun 30, 2019)

kpedersen said:


> Hacking on the Raspberry Pi is fun but how many revisions did the BBC Micro have before it disappeared off the face of the planet and left only x86 in its wake? I rekon we will have another 5 years of the Pi before it disappears (Pi 6 being the last one?).



Isn't that just a subset of ARM (Broadcom) support we're talking about?  Certainly the ARM platform and Broadcom are not going to disappear any time soon.


----------



## ucomp (Jun 30, 2019)

kpedersen said:


> Is that *really* worth a developer spending many hours of their life on unless they are having fun or learning?


exactly the question I asked myself in an earlier post...


SirDice said:


> ..... it's not going to be done any time soon.
> 
> 
> ARMTier1 - FreeBSD Wiki


and according to the last Wiki-update the arm-devs ask themselves since 1 year...
in src there are sometimes changes for arm but this Tier2-thing is something like hanging in the air... when I asked "should I work on Sparc" for a project on the mailing lists there was a quick answer from the Sparc-chief inspector , when it came to aarch64 we had a minute's silence


----------



## kpedersen (Jun 30, 2019)

CraigHB said:


> Isn't that just a subset of ARM (Broadcom) support we're talking about?  Certainly the ARM platform and Broadcom are not going to disappear any time soon.



True but when it comes to computing they haven't quite appeared yet in the first place. For example how many ARM laptops or desktops do you have?


----------



## Phishfry (Jun 30, 2019)

The Google beast did ship some Chromebooks with Arm.
Take them out of the equation and we are talking crickets.

I see it more in embedded settings like STB and Digital Signage.

Don't forget the Microsooft Surface!!! Also Kindles and all the little tablets out there...


----------



## Phishfry (Jun 30, 2019)

I get the feeling that developer interest in Arm has waned. 
Some of the current maintainers have day job around Arm so those branches are supported well.
The rest seems like its a never ending game of catch-up.
Here we have RPi4 presented and we still did not get all the RPi3 working.
I do know that Gonzo and 3 or 4 others brought the initial RPi3 board support.
They were hoping others would finish it up but that never happened.
So there really are a very small number of people working on these platforms.
Will this crew be around for RPi4? Gonzo had very little personal interest in RPi3.
He just contributed to help out the embedded cause and he is the ultimate FreeBSD tweaker.
To him porting comes easy it seems...


----------



## mark_j (Jun 30, 2019)

Spartrekus said:


> Hi Nico,
> what would be the best alternative to RPI 3 or 4 ?


Best alternative? That's too vague. Base Pi4 is still a price point that no other sbc can match, especially when considering OS support. 
It comes down to what you want to pay, what level of support for your sbc is provided by your chosen OS, what sbc provides the solution to your requirements like low power, maker board etc.
Personally I have used cubox i4pro for years. It's not in the same price range as PIs but equally it's more powerful and has the interfaces i want.


----------



## malavon (Jun 30, 2019)

Phishfry said:


> Here we have RPi4 presented and we still did not get all the RPi3 working.
> I do know that Gonzo and 3 or 4 others brought the initial RPi3 board support.
> They were hoping others would finish it up but that never happened.


Well, the thing is that Broadcom doesn't want to help with that. There are a few alternatives that are definitely decently documented without NDA's.
The TI offering - that one I know - and the NXP offerings - only from hear-say - are documented very well and it's a lot easier to support these.
Since the TI processors are used on the BeagleBone/Board lines, we'll be sure to have these for the time to come. Others will indeed be a lot harder to port.
It's actually a pity that the Raspberry Pi has become so much more popular than the open designs. Then again, over-the-shelf industrial processors will never be as cheap as a low-cost mobile SoC in the same range.

Anyway, somewhere in the far future I'm sure FreeBSD will be running on the AM572x (BeagleBoard x15) and later offerings. If it hasn't been taken care of by the time I need it, I'll do it myself without a doubt.
I am however not interested in the Pi family either, so that's still a dead-end.


----------



## Phishfry (Jun 30, 2019)

Yes and thanks to TI we have all the source in FreeBSD. BBB is an excellent platform.
With its wealth of IO it is still the best choice on FreeSBD. embedded eMMC is nice too.
I never tried the BBB Green. The BBB Black did all I needed.
The addition of Wifi seemed to be a turning point on these boards. They went from PRUSS and PRU like features to bubble gum.
Grove connectors? Whats wrong with pins? Do I need HDMI on an embedded board? Do I need video at all?
I never understood how a crypto miner could use these boards either... People just invent uses it seems.


----------



## ucomp (Jul 1, 2019)

well, things become a bit clearer now..even on the cloud-side I had not the best experience ... because I paid $2,50 a day for an AWS-ARM64-VM whereas I pay $2,50 a month for an X86-cloud-VM. not very attractive to develop ports on such an Arm-backend..


----------



## Phishfry (Jul 1, 2019)

I wonder if the 30x price is because of the high price of the Arm Server gear. Xeon versus Arm can't be that far apart in cost.
Maybe it is demand based pricing? Wonder who is using the Gigabyte rack units..

If you have to ask how much they cost then you can't afford them. No pricing on the Gigabyte offerings.


----------



## ucomp (Jul 1, 2019)

I compared an AWS 4GB RAM  Arm64VM incl. 10GB S3 FreeBSD-VM-image usage 1 day with my cheapest 4GB RAM Hetzner x86-FreeBSD-VM , far and wide no cheap offer for ARM VMs, seems s AWS is even the only one which offers ARM-VMs except a company which has not the best feedback from users ... O.K., good night and thanks for yours clear statements to Arm-status of FreeBSD here ...


----------



## CraigHB (Jul 1, 2019)

malavon said:


> The TI offering - that one I know - and the NXP offerings - only from hear-say - are documented very well and it's a lot easier to support these.



I don't know what Broadcom did to get such a hold on the ARM market, but anyone can make an ARM processor by paying the license.  TI and NXP make really nice stuff, I've used a range of their chip products.  I've not used any of their ARM processors, but I'm sure they're up to snuff with the rest of their line.

It would be nice if an SBC maker could get an RPi like hold on the market using a TI or NXP ARM processor.  In that case FreeBSD support could actually become pretty solid provided there's developer interest.  TI documentation is exceptionally good, best I've seen for any chip maker.

There's at least one inexpensive Intel based SBC I know of that can sort of fill the stop gap.  The Hardkernel Odroid-H2 could be a good option (https://www.hardkernel.com/shop/odroid-h2) .  It's still more expensive than an RPi, but also a lot cheaper than a desktop build.


----------



## jem (Jul 1, 2019)

I was lucky enough to order one of these on Friday when they very briefly came back into stock at one of the UK resellers.  It arrived next morning.

For now I am only running Raspbian Buster on it, as I believe there have been enough changes to the platform to mean that existing RPi-compatible OS builds won't work.

First impressions are that it feels much snappier than the 3B+.  I believe the SDcard interface is faster and I/O heavy stuff like installing loads of packages is much quicker than it used to be.

The gigabit and wireless interfaces are PCIe attached, not USB as they were in previous versions.

It seems like a very good improvement, but until more OS choices are available, it may be a bit limited in usefulness.


----------



## Spartrekus (Jul 1, 2019)

I am kinda sure that I will break the mini hdmi of rpi4,  because I travel a lot and it is easily broken ...


----------



## ucomp (Jul 2, 2019)

Spartrekus said:


> I am kinda sure that I will break the mini hdmi of rpi4,  because I travel a lot and it is easily broken ...


 ...
and don`t let the beer leak out in your backpack, also the USB-ports are from very poor hardware-design in this regard .


----------



## Phishfry (Jul 2, 2019)

Spartrekus said:


> I am kinda sure that I will break the mini hdmi of rpi4, because I travel a lot and it is easily broken ...


I had a MinnowboardMax rigged up mobile and broke the microHDMI off that with a Liliput monitor connected.
Well, now it's tty console-only on that board.
$150 oops.
It gave me a reason to buy the Minnowboard Turbot (newer model).
The TinCan lure is nice as it adds some mPCIe for Wifi and mSATA compared to Arm boards.








						Silverjaw Lure - MinnowBoard
					

The Silverjaw Lure is dual break-out board providing both an mPCIe and mSATA slot via MinnowBoard development boards’ HSE connector.




					minnowboard.org
				



Plus we have GPIO driver in base for Minnowboard.
You can find them new on ebay for $70 but they were pre-production boards like the MBMax(No RTC/CMOS battery holder or pins).
If the Silverjaw lure was still available I would buy a MBMax for $70. I know how to solder now!


----------



## Spartrekus (Jul 2, 2019)

Phishfry said:


> I had a MinnowboardMax rigged up mobile and broke the microHDMI off that with a Liliput monitor connected.
> Well, now it's tty console-only on that board.
> $150 oops.
> It gave me a reason to buy the Minnowboard Turbot (newer model).
> ...


Can at some point we return to regular HDMI rather than microHDMI? It means more machine to be built, because like phones, many might be defect after little use.
modern hardware ... I still have my old HP calc .... still working.


----------



## Phishfry (Jul 2, 2019)

Spartrekus said:


> Can at some point we return to regular HDMI rather than microHDMI?


I wish they had VGA. Too many EDID headaches with HDMI. Have you ever seen VGA not connect because of EDID.
Instead of the CSI camera and DSI interface, VGA please.
The comment about CuBox is right on. I have HummingBoard Ix4 and they seem way better. MiniPCIe slot onboard.
Solid Run is really trying hard in this arena with lots of offerings.
They must be challenging Gateworks and some of the others established in the commercial space. Maybe half the price.


----------



## Spartrekus (Jul 2, 2019)

Phishfry said:


> I wish they had VGA. Too many EDID headaches with HDMI. Have you ever seen VGA not connect because of EDID.
> Instead of the CSI camera and DSI interface, VGA please.
> The comment about CuBox is right on. I have HummingBoard Ix4 and they seem way better. MiniPCIe slot onboard.
> Solid Run is really trying hard in this arena with lots of offerings.
> They must be challenging Gateworks and some of the others established in the commercial space. Maybe half the price.



this is the fun that close source software driven by large companies like microsoft will influence opensource hardware and available technologies.

Raspberry is destined to opensource linux, but if they use old technologies,  might oblige raspberry to implement newer techs.
HDMI will disappear like PS2, like COM1, like LPT, like old cables, ...
If we used those old technologies, we would still use MSDOS or that old vim. We would never had emails all the time with us on the  iphone or android samsung. ...


----------



## JLAIP (Jul 19, 2019)

Just received a 4GB Pi4 and thought I'd offer another rationale for its existence that isn't often talked about: The Pi's relatively miniscule power consumption makes it a great [backup] desktop option during power outages (i.e., when forced to run for extended periods on limited battery power).

I'm currently running it with a non-standard power supply (p/s) that isn't providing the recommended dose of current, but an OEM p/s's scheduled to arrive tomorrow and I'll have a better take once it's hooked-up good 'n' proper.

But, so far at least, this gizmo would easily suffice when the lights're out and one needs to be mindful of every milliamp. And geting it to [properly and reliably] run XP or 'BSD would ice the cake.


----------



## ralphbsz (Jul 19, 2019)

Actually, that's a good argument. Say it uses 250mA at 5V; add to that 50mA each for keyboard and mouse, that's less than 2W for the computer itself. The problem is actually the screen; just looked it up: The official 7" RPi display uses 0.5A at 5V (that's another 2.5W); while it is a small and crappy display, that's better than nothing. SO let's assume the total is 5W. A car-size 12V battery contains about 30Ah usable (don't want to drain it much further); at 12V that's 360Wh, which can provide the 5W for the RPi for 72 hours. Even if you slap a few penalties for voltage conversion on, that's still a heck of a long time.

On the other hand, a good laptop keeps you going for 12 hours, and has WAY better display.


----------



## JLAIP (Jul 19, 2019)

I wish I had a laptop that ran for 12 hours, but I don't. Still, I reckon that any laptop will draw more current than the Pi, so I 'spect the Pi'll still run longer.

In my case, when the lights go out: I've got a 19" LED TV that runs on ~30w (which I'll be mating to a small Blu-Ray player that runs on ~10w) that I'll be running the Pi through. My least power-hungry laptop—a dated but fully functional Dell running BSD 12—eats ~70w and the Pi's got more RAM (4gb vs .5gb in the laptop), a faster cpu (1.5g vs 1.0g) and runs longer....lots longer. And since I already had the TV, mouse and keyboard, the Pi cost me less than I'd spend on a coupla books. I kinda think everyone outta get a Pi and some type of battery back-up to use when the unexpected occurs. And, aside from its many nits, I think that more than justifies the price of admission.


----------



## ralphbsz (Jul 19, 2019)

I agree this is a very low-cost version of getting compute power for when the power goes out. Your suggested setup requires lots of tinkering, and you'll have to deal with several voltage converters, but that's all doable.

We have a "similar" solution, just with different components. In spite of living within 20 minutes of Silicon Valley (the technologically most advanced place on the planet), our electrical power at home is quite unreliable, with frequent outages due to rain and storms in the winter, and due to fires in the summer. Unfortunately, our house needs electricity to have water (we have our own well and pump system), and water is particularly important when there is a fire nearby. So the way the way I get nearly uninterrupted computing is this: Small computer in the basement, together with a wireless AP and the DSL modem. Both are fed by a small office-grade UPS. All user interface computers are laptops, which have their own batteries. The whole house electrical system is on a large automatic transfer switch, which is fed from our normal electrical company, and from a generator. The generator is a 16kW model, supplied from a 500 gallon (2000L) tank of propane. When the power goes out, all we notice is that the lights go out for about 15 seconds, which is how long it takes for the generator to decide that the electrical grid has really failed, start the engine, and operate the transfer switch.


----------



## JLAIP (Jul 19, 2019)

ralphbsz said:


> The whole house electrical system is on a large automatic transfer switch, which is fed from our normal electrical company, and from a generator. The generator is a 16kW model, supplied from a 500 gallon (2000L) tank of propane. When the power goes out, all we notice is that the lights go out for about 15 seconds, which is how long it takes for the generator to decide that the electrical grid has really failed, start the engine, and operate the transfer switch.



_Not to deviate from the thread theme (too far)....._
Although I'm on the other side of the country, it sounds like we share the same [unreliable] electrical "pump".

I've been without power—sitting in the dark—for > five consecutive days, four times in the last seven years. I learned my lesson after the third time. Unfortunately, I'm unable to install a 16kW generator (though my boss's got something similar at his pad), so I went with a 1.1kW solar generator, which, although it lacks the testicular fortitude to run high current devices (e.g., house A/C, heat, electric stoves, etc.....tho' it will run the likes of an upright Hoover and microwave oven), it's silent, small/portable, produces no noxious exhaust (i.e., usable indoors) and able to run small- to mid-sized devices for as long as there's sunlight to keep its battery "refueled".

And since switching all the 75-to-100w incandescent lights over to 6-7w LED light bulbs, purchasing a coupla lithium/D-cell-powered smart fans and having the tiny-watt Pi to use in place of 70+ watt laptops/desktops, I'm finding that I can weather the coming storms with relative ease. And all for a relatively reasonable cost that doesn't keep the neighborhood up all night..


----------



## JLAIP (Jul 19, 2019)

ralphbsz said:


> Your suggested setup requires lots of tinkering, and you'll have to deal with several voltage converters, but that's all doable.



Yeah, it used to. I built a diy generator a few years ago that did require a good bit of messing about. But after it got stolen by landscapers, I abandoned that for one of these new plug 'n' play *generators* and some PV panels (which just plug into the generator). Easy-peasy. While not perfect, it gets the job done and I never even have to warm up the Weller or pester any HAM guys to check my (often faulty) electrical computations ("e=cm2" or something like that)..


----------



## JLAIP (Jul 19, 2019)

UPDATE: Now that I've got the proper p/s, shadowed the cpu/ram with an oscillating propeller contraption (i.e., cpu fan from the Pi guy, which's keeping the board close to room temperature!), tinkered with Raspian's innards and placated the LAN config abacus, this thing swings! I've been running it for several hours today--watching youtube videos (via Chromium), taking care of a bit o' correspondence (via Claws) and watching a coupla .mp4s (via VLC)--and it hasn't missed a beat or bottle-necked my movements in any way. Golly, I dunno how I did without a Pi all this time. Everyone really outta get one of these gizmos, if for no other reason than as a backup desktop because it runs on fumes (i.e., 15 watts)! Kudos to the Pi guys--they finally got it right. I guess the next version'll be a Pi-supercomputer running Plan9 or Maruti.


----------



## maks (Aug 4, 2019)

Recently purchased the Pi 4 with 4Gb on board. Tried *FreeBSD-12.0-RELEASE-arm64-aarch64-RPI3.img.xz* from here https://www.freebsd.org/where.html
And OS even did not start.


----------



## JLAIP (Aug 4, 2019)

My experience with 12 mirrors yours. I've tried three ARM versions of 12 and none booted. Until/unless there's an ARM version made for the Pi, I'll stick with Raspian, which I think is a very good OS for the platform.


----------



## mark_j (Aug 5, 2019)

maks said:


> Recently purchased the Pi 4 with 4Gb on board. Tried *FreeBSD-12.0-RELEASE-arm64-aarch64-RPI3.img.xz* from here https://www.freebsd.org/where.html
> And OS even did not start.


It won't because uboot has not been updated yet.


----------



## Phishfry (Aug 5, 2019)

mark_j said:


> It won't because uboot has not been updated yet.


Yes but that is one small part of it. The DeviceTreeBinary is like the BIOS in that it describes every piece of hardware to the O/S.
Uboot is like a bootstrap loader.
Now imagine the differences between Pi3 and Pi4.
Do you really think another DTB is going to work. No it will not. It is describing totally different hardware.
The DTB describes the harware and address locations to the OS loader.


----------



## mark_j (Aug 5, 2019)

Regardless, no uboot, no boot. It's only just been finished for Linux, so expect to wait a year for FreeBSD. Use Linux instead. (I differentiate Linux v Raspbian as obviously Rasbian has binary blobs for their boot code - via the GPU)


----------



## maks (Aug 5, 2019)

Raspbian very good OS for that platform. You are right. And I am really impressed with the capabilities of this micro computer.


----------



## RobCrowston (Aug 7, 2019)

mark_j said:


> It won't because uboot has not been updated yet.



There is a functioning u-boot, written by Andrei Gherzan, for the purposes of booting 64 bit Linux. He is working on upstreaming his patches. I have some patches on top of his on my github aimed at FreeBSD. It’s entirely experimental. I don’t think I can post a link to it as a newbie here but you can google it.

However, u-boot passes a bad pointer to the http functions which crashes the freebsd loader; a work around is to compile the freebsd loader without http support.

There are a few other changes you need to make in the bcm device drivers to get a bootable kernel. You also need to patch armstubs.bin if you want multiprocessor support (also on my github but needs a further update to initialize the interrupt controller).

At the moment I am having a lot of trouble with the DMA controller. Disabling DMA support in the sdhci driver has enabled me to mount root. Yesterday I got as far as starting /sbin/init, but I have another panic to debug.

Even when this is done, there is no support yet for ethernet or USB. USB is tricky because it comes over PCI-E for which we don’t have a driver. Trying to smuggle in a generic driver crashed during hardware enumeration, but I admit I didn’t try very hard.

The ethernet may work with some tweaks to the mii driver. I haven’t tried it yet.

The framebuffer driver also needs work.


----------



## SirDice (Aug 7, 2019)

RobCrowston said:


> I have some patches on top of his on my github aimed at FreeBSD. I don’t think I can post a link to it as a newbie but you can google it.


We don't have a problem with links like that. We only frown at links to sites that have nothing to do with FreeBSD (mainly to combat SEO spam).


----------



## RobCrowston (Aug 8, 2019)

I am pleased to report I have reached the login prompt on the raspberry pi 4.

Unfortunately I can’t login yet as shortly after /sbin/init starts something trashes the serial com link and I only get garbage over serial (in either direction). Probably just a misconfiguration.


----------



## ykla (Aug 20, 2019)

I tried FreeBSD 12/13/release then neither of them can boot on RPI4B.


----------



## soulmachine (Aug 20, 2019)

ykla said:


> I tried FreeBSD 12/13/release then neither of them can boot on RPI4B.


Same here


----------



## Deleted member 9563 (Aug 20, 2019)

My original RPi 1 is still nailed to the wall and chugging away serving web pages. Just keeps on ticking.


----------



## freq (Aug 20, 2019)

You really can't go wrong with any of the rpi models. I have the rpi4 coming and am looking forward to tooling with 64bits and 4gb ram. I do nearly everything important on my network via my headless rpi and this will be a much needed upgrade for me.


----------



## freq (Aug 20, 2019)

RobCrowston said:


> I am pleased to report I have reached the login prompt on the raspberry pi 4.
> 
> Unfortunately I can’t login yet as shortly after /sbin/init starts something trashes the serial com link and I only get garbage over serial (in either direction). Probably just a misconfiguration.


Almost!


----------



## RobCrowston (Aug 26, 2019)

ykla said:


> I tried FreeBSD 12/13/release then neither of them can boot on RPI4B.



There are a number of code and configuration changes you need to make in the armstub firmware file, u-boot, and the FreeBSD kernel.

I'll try to find some time to package up what I have so far. I want to make sure SMP works properly first (I did most of the legwork for it but then switched back to testing single-threaded for ease of debugging).

Note, I do not have USB or ethernet working, these require new drivers, so there's not a lot you can do with the Pi4 even when it is running FreeBSD.


----------



## Deleted member 58728 (Sep 15, 2019)

ralphbsz said:


> For a few weeks, I had a RPi3B on my workbench, while I was prototyping with it and setting it up (it now does full-time duty as an industrial control data acquisition system, which is a lot of big words for saying it measures and records a few water pressures and tank water levels). During the setup time, I had monitor, mouse and keyboard connected, and for fun I started X on it. Works fine, you can run a web browser, you can edit text in multiple terminal emulator windows. Boring. Just a normal Unix desktop. A little slow at time, but at $35 and 3W power consumption, I can handle that. So if the RPi3B was already a nice little desktop, the model 4 would definitely do it.
> 
> 
> With the USB 3.0, is that really necessary? And given the form factor, and the size of a SATA connector, I'm not sure that would work well, without making it physically incompatible with the established ecosystem.
> ...


You can get a msata hat


----------



## xandor (Sep 17, 2019)

It looks like there is a fully 64bit uboot available at https://github.com/balena-os/u-boot for the RP4. Unfortunately, i have no time to digg in to this.. Perhaps somebody?

apperently it has been merge with upstream.


----------



## RobCrowston (Sep 18, 2019)

u-boot works fine on the rpi-4 and has done for a while

From a FreeBSD perspective I have a bootable system (running arm64 13-CURRENT smp) but the problem is now the lack of any drivers. No ethernet, no PCI-E, no USB. (Well, the OTG port works out of the box but that’s most typically used for power.)


----------



## ykla (Oct 17, 2019)

The most important thing is that freebsd  not supports SDIO now.


----------



## weberjn (Nov 1, 2019)

RobCrowston said:


> I am pleased to report I have reached the login prompt on the raspberry pi 4.
> 
> Unfortunately I can’t login yet as shortly after /sbin/init starts something trashes the serial com link and I only get garbage over serial (in either direction). Probably just a misconfiguration.



Any progress in the last three months?


----------



## RobCrowston (Nov 4, 2019)

weberjn said:


> Any progress in the last three months?



I am able to login interactively over serial by doubling the speed of the serial link after init starts. I haven’t the faintest idea why the link speed changes. Things work well enough, but no peripherals or network so I’m limited in what I can test after logging in. But fundamentally the operating system works.

I took a look at the Linux ethernet driver “genet” in the hopes I could re-implement it on the FreeBSD side. I guess there might be licensing issues with that, but I figured it’s better than nothing. Unfortunately I don’t really understand the Linux stack well enough to make much progress. I also reached out to broadcom to ask for the specs. They were not helpful. I haven’t really had a lot of time to work on it unfortunately.


----------



## weberjn (Nov 6, 2019)

RobCrowston said:


> I also reached out to broadcom to ask for the specs. They were not helpful. I haven’t really had a lot of time to work on it unfortunately.



Anyway, thanks for the update. Is your code so far somewhere accessible?

Thanks for your work, I do believe support for the RPI4 ist very important.


----------



## stratact (Nov 8, 2019)

Just noticed from a `portsnap fetch update`, that a RPI4 version of uboot is available.






						FreshPorts -- sysutils/u-boot-rpi4: Cross-build das u-boot for model rpi4
					

U-Boot loader and related files for the RPi4  For general information about U-Boot see WWW: https://www.denx.de/wiki/U-Boot




					www.freshports.org


----------



## RobCrowston (Nov 10, 2019)

Kyle Evans has picked this up and made a number of PRs to mainline in the last few days to enable pi4 support out of the box. I’m very pleased. In particular he figured out the DMA controller problem I wasn’t able to solve.


----------



## webpr (Jan 20, 2020)

Any progress in the last months?


----------



## ucomp (Jan 20, 2020)

webpr said:


> Any progress ......?


from the developers view : YES
from the users view : NO
--
it's bootable, with me it managed an over 10 hours compilation with the -j4 option(100%CPU usage) with only few problems, so the CPU-hacks are not the worst. the next major step will be the integration/implementation of drivers for SDIO because there's no network at the moment.the "official" wifi-driver worked for me with NetBSD-SDIO- implementation, so it`s technically possible to get Wifi to work with the brcmfmac closed source driver.
Don`t know if someone's working on reverse engineering but a guess :  no

Although we will get this amateur board to work one day... :
if you expect a working FreeBSD-board with similar performance in this price range, buy another one (I could give a recommendation but don't want to advertise it here).
don't look for boards which are  better advertised than RPI(because you won't find one). look  for boards which work better than RPI instead and for those with more professional features.


----------



## RobCrowston (Jan 21, 2020)

webpr said:


> Any progress in the last months?



Got some way towards a working PCI-E driver. Currently having trouble mapping the bridge memory window


----------



## weberjn (Jan 22, 2020)

ucomp said:


> it's bootable



So you booted from SD using the NetBSD drivers?

What about an SSD attached to USB (via a USB to Sata adapter cable)? would that work?

Does ethernet work? Wifi is not important, I'd prefer ethernet for stability and security reasons.


----------



## RobCrowston (Jan 22, 2020)

We have a working SD card driver in HEAD (currently doesn’t work for me again probably because I have some weird setup to get the JTAG to work).

USB is attached over PCI-E, so there’s no USB. Even if we had a working USB, you would still need to keep /boot/kernel on the SD card because u-boot doesn’t support the pi4 PCIE/USB, so we couldn’t start the kernel from USB.

There’s no ethernet (yet another custom chip that will need a new driver).

The NetBSD driver mentioned above is for wifi. Someone is working on that I think.


----------



## ucomp (Jan 22, 2020)

weberjn said:


> So you booted from SD using the NetBSD drivers?


yes, FreeBSD boots from SD on the RPI4 but that has nothing to do with NetBSD



RobCrowston said:


> We have a working SD card driver in HEAD (currently doesn’t work for me again probably because I have some weird setup to get the JTAG to work).
> ..... The NetBSD driver ...


.. there's no SD-card driver in that sense , it boots from u-boot & the manufacturer's firmware.
there's no NetBSD-driver, it's even funnier:
I had bind the Debian-driver  in NetBSD because the original brcmfmac von Broadcom didn't work 
So to make it a little more understandable:
for Wifi there's only a closed source driver from Broadcom but it seems that there are 'different' versions around.

from my reading in the FreeBSD-src the only thing to do is to bind the brcmfmac-file to SDIO(SDIO is implemented in FreeBSD src). I didn't finish the last compile with SDIO on RPI4 yet because some other things had to be fixed in src. We will see if binding the brcmfmac-file in SDIO is an accepted way for merging in src.
All other Rob described is correct: USB etc. is apparently really problematic because of the closed source ...


----------



## RobCrowston (Jan 23, 2020)

ucomp said:


> .. there's no SD-card driver in that sense , it boots from u-boot & the manufacturer's firmware.


At least at one point you could mount root using the native FreeBSD SD card driver. See https://reviews.freebsd.org/rS354560


----------



## ucomp (Jan 23, 2020)

RobCrowston said:


> .... you could mount root .....



(maybe for coincidence) 
I'm exactly hanging @mountroot at the moment  
(after installkernel GENERIC-MMCCAM )


Spoiler: mountroot



MMC:   emmc2@7e340000: 0, mmc@7e300000: 1
Loading Environment from FAT... In:    serial
Out:   serial
Err:   serial
Net:   Net Initialization Skipped
No ethernet found.
Hit any key to stop autoboot:  0
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:1...
Found EFI removable media binary efi/boot/bootaa64.efi
libfdt fdt_check_header(): FDT_ERR_BADMAGIC
Scanning disk emmc2@7e340000.blk...
Scanning disk mmc@7e300000.blk...
Disk mmc@7e300000.blk not ready
Found 3 disks
BootOrder not defined
EFI boot manager: Cannot load any image
678800 bytes read in 78 ms (8.3 MiB/s)
libfdt fdt_check_header(): FDT_ERR_BADMAGIC
Consoles: EFI console 
    Reading loader env vars from /efi/freebsd/loader.env


Loading kernel...
/boot/kernel/kernel text=0x98e51c data=0x1900a8 data=0x0+0x79d260 syms=[0x8+0x145a58+0x8+0x12fb47]
Loading configured modules...
/boot/kernel/umodem.ko text=0x2100 text=0x13a0 data=0x6e0+0x10 syms=[0x8+0xf48+0x8+0xb6e]
/boot/entropy size=0x1000

Hit [Enter] to boot immediately, or any other key for command prompt.
Booting [/boot/kernel/kernel]...               
Using DTB provided by EFI at 0x7ef2000.
---<<BOOT>>---
KDB: debugger backends: ddb
KDB: current backend: ddb
Copyright (c) 1992-2020 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
        The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 13.0-CURRENT #0 r357013M: Thu Jan 23 19:55:28 UTC 2020
    root@generic:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC-MMCCAM arm64
FreeBSD clang version 9.0.1 (git@github.com:llvm/llvm-project.git c1a0a213378a458fbea1a5c77b315c7dce08fd05) (based on LLVM 9.0.1)
WARNING: WITNESS option enabled, expect reduced performance.
VT: init without driver.
module firmware already present!
KLD file umodem.ko is missing dependencies
Starting CPU 1 (1)
Starting CPU 2 (2)
Starting CPU 3 (3)
FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs
random: unblocking device.
random: entropy device external interface
MAP 39f53000 mode 2 pages 1
MAP 39f57000 mode 2 pages 1
MAP 3b360000 mode 2 pages 16
MAP fe100000 mode 0 pages 1
WARNING: Device "kbd" is Giant locked and may be deleted before FreeBSD 13.0.
kbd0 at kbdmux0
WARNING: Device "openfirm" is Giant locked and may be deleted before FreeBSD 13.0.
ofwbus0: <Open Firmware Device Tree>
simplebus0: <Flattened device tree simple bus> on ofwbus0
ofw_clkbus0: <OFW clocks bus> on ofwbus0
clk_fixed0: <Fixed clock> on ofw_clkbus0
clk_fixed1: <Fixed clock> on ofw_clkbus0
simplebus1: <Flattened device tree simple bus> on ofwbus0
simplebus2: <Flattened device tree simple bus> on ofwbus0
regfix0: <Fixed Regulator> on ofwbus0
regfix1: <Fixed Regulator> on ofwbus0
psci0: <ARM Power State Co-ordination Interface Driver> on ofwbus0
psci0: PSCI version number mismatched with DT
device_attach: psci0 attach returned 6
psci0: <ARM Power State Co-ordination Interface Driver> on ofwbus0
psci0: PSCI version number mismatched with DT
device_attach: psci0 attach returned 6
psci0: <ARM Power State Co-ordination Interface Driver> on ofwbus0
psci0: PSCI version number mismatched with DT
device_attach: psci0 attach returned 6
psci0: <ARM Power State Co-ordination Interface Driver> on ofwbus0
psci0: PSCI version number mismatched with DT
device_attach: psci0 attach returned 6
psci0: <ARM Power State Co-ordination Interface Driver> on ofwbus0
psci0: PSCI version number mismatched with DT
device_attach: psci0 attach returned 6
psci0: <ARM Power State Co-ordination Interface Driver> on ofwbus0
psci0: PSCI version number mismatched with DT
device_attach: psci0 attach returned 6
psci0: <ARM Power State Co-ordination Interface Driver> on ofwbus0
psci0: PSCI version number mismatched with DT
device_attach: psci0 attach returned 6
psci0: <ARM Power State Co-ordination Interface Driver> on ofwbus0
psci0: PSCI version number mismatched with DT
device_attach: psci0 attach returned 6
gic0: <ARM Generic Interrupt Controller> mem 0x40041000-0x40041fff,0x40042000-0x40043fff,0x40044000-0x40045fff,0x40046000-0x40047fff irq 46 on simplebus0
gic0: pn 0x2, arch 0x2, rev 0x1, implementer 0x43b irqs 256
psci0: <ARM Power State Co-ordination Interface Driver> on ofwbus0
psci0: PSCI version number mismatched with DT
device_attach: psci0 attach returned 6
gpio0: <BCM2708/2835 GPIO controller> mem 0x7e200000-0x7e2000b3 irq 22,23 on simplebus0
gpiobus0: <OFW GPIO bus> on gpio0
psci0: <ARM Power State Co-ordination Interface Driver> on ofwbus0
psci0: PSCI version number mismatched with DT
device_attach: psci0 attach returned 6
gpioregulator0: <GPIO controlled regulator> on ofwbus0
gpioregulator0: cannot get pin 0
gpioregulator0: cannot parse parameters
device_attach: gpioregulator0 attach returned 6
psci0: <ARM Power State Co-ordination Interface Driver> on ofwbus0
psci0: PSCI version number mismatched with DT
device_attach: psci0 attach returned 6
generic_timer0: <ARMv7 Generic Timer> irq 4,5,6,7 on ofwbus0
Timecounter "ARM MPCore Timecounter" frequency 54000000 Hz quality 1000
Event timer "ARM MPCore Eventtimer" frequency 54000000 Hz quality 1000
gpioregulator0: <GPIO controlled regulator> on ofwbus0
gpioregulator0: cannot get pin 0
gpioregulator0: cannot parse parameters
device_attach: gpioregulator0 attach returned 6
psci0: <ARM Power State Co-ordination Interface Driver> on ofwbus0
psci0: PSCI version number mismatched with DT
device_attach: psci0 attach returned 6
gpioregulator0: <GPIO controlled regulator> on ofwbus0
gpioregulator0: cannot get pin 0
gpioregulator0: cannot parse parameters
device_attach: gpioregulator0 attach returned 6
psci0: <ARM Power State Co-ordination Interface Driver> on ofwbus0
psci0: PSCI version number mismatched with DT
device_attach: psci0 attach returned 6
gpioregulator0: <GPIO controlled regulator> on ofwbus0
gpioregulator0: cannot get pin 0
gpioregulator0: cannot parse parameters
device_attach: gpioregulator0 attach returned 6
psci0: <ARM Power State Co-ordination Interface Driver> on ofwbus0
psci0: PSCI version number mismatched with DT
device_attach: psci0 attach returned 6
gpioregulator0: <GPIO controlled regulator> on ofwbus0
gpioregulator0: cannot get pin 0
gpioregulator0: cannot parse parameters
device_attach: gpioregulator0 attach returned 6
psci0: <ARM Power State Co-ordination Interface Driver> on ofwbus0
psci0: PSCI version number mismatched with DT
device_attach: psci0 attach returned 6
usb_nop_xceiv0: <USB NOP PHY> on ofwbus0
gpioregulator0: <GPIO controlled regulator> on ofwbus0
gpioregulator0: cannot get pin 0
gpioregulator0: cannot parse parameters
device_attach: gpioregulator0 attach returned 6
psci0: <ARM Power State Co-ordination Interface Driver> on ofwbus0
psci0: PSCI version number mismatched with DT
device_attach: psci0 attach returned 6
bcm_dma0: <BCM2835 DMA Controller> mem 0x7e007000-0x7e007aff irq 9,10,11,12,13,14,15,16,17,18,19 on simplebus0
bcmwd0: <BCM2708/2835 Watchdog> mem 0x7e100000-0x7e100113,0x7e00a000-0x7e00a023,0x7ec11000-0x7ec1101f on simplebus0
mbox0: <BCM2835 VideoCore Mailbox> mem 0x7e00b880-0x7e00b8bf irq 21 on simplebus0
gpioc0: <GPIO controller> on gpio0
uart0: <PrimeCell UART (PL011)> mem 0x7e201000-0x7e2011ff irq 24 on simplebus0
uart0: console (115200,n,8,1)
spi0: <BCM2708/2835 SPI controller> mem 0x7e204000-0x7e2041ff irq 26 on simplebus0
spibus0: <OFW SPI bus> on spi0
spibus0: <unknown card> at cs 0 mode 0
spibus0: <unknown card> at cs 1 mode 0
iichb0: <BCM2708/2835 BSC controller> mem 0x7e804000-0x7e804fff irq 38 on simplebus0
sdhci_bcm0: <Broadcom 2708 SDHCI controller> mem 0x7e340000-0x7e3400ff irq 60 on simplebus0
mmc_alloc_device()
sdhci_bcm1: <Broadcom 2708 SDHCI controller> mem 0x7e300000-0x7e3000ff irq 61 on simplebus0
mmc_alloc_device()
fb0: <BCM2835 VT framebuffer driver> on simplebus0
fb0: changing fb bpp from 0 to 24
mbox0: mbox response error
fb0: bcm2835_mbox_fb_init failed, err=5
device_attach: fb0 attach returned 6
cpulist0: <Open Firmware CPU Group> on ofwbus0
cpu0: <Open Firmware CPU> on cpulist0
cpu1: <Open Firmware CPU> on cpulist0
cpu2: <Open Firmware CPU> on cpulist0
cpu3: <Open Firmware CPU> on cpulist0
gpioled0: <GPIO LEDs> on ofwbus0
gpioled0: <led1> failed to map pin
gpioregulator0: <GPIO controlled regulator> on ofwbus0
gpioregulator0: cannot get pin 0
gpioregulator0: cannot parse parameters
device_attach: gpioregulator0 attach returned 6
cryptosoft0: <software crypto>
Timecounters tick every 1.000 msec
mmc_dev_async(async_code=0x20, path_id=0, target_id=0, lun_id=0
Got AC_PATH_REGISTERED -- whatever...
mmc_dev_async(async_code=0x20, path_id=0, target_id=ffffffff, lun_id=ffffffff
mmc_dev_async(async_code=0x20, path_id=1, target_id=0, lun_id=0
Got AC_PATH_REGISTERED -- whatever...
mmc_dev_async(async_code=0x20, path_id=1, target_id=ffffffff, lun_id=ffffffff
Obsolete code will be removed soon: random(9) is the obsolete Park-Miller LCG from 1988
usb_needs_explore_all: no devclass
iicbus0: <OFW I2C bus> on iichb0
iic0: <I2C generic I/O> on iicbus0
(noperiph:sdhci_slot0:0:-1:ffffffff): XPT_SCAN_{BUS,TGT,LUN}
(noperiph:sdhci_slot0:0:0:0): XPT_SCAN_{BUS,TGT,LUN}
(noperiph:sdhci_slot0:0:0:0):  Set up the mmcprobe device...
(mmcprobe0:sdhci_slot0:0:0:0): Periph created
(mmcprobe0:sdhci_slot0:0:0:0): Probe started
(mmcprobe0:sdhci_slot0:0:0:0): Probe PROBE_INVALID to PROBE_RESET
(mmcprobe0:sdhci_slot0:0:0:0): mmcprobe_start
(mmcprobe0:sdhci_slot0:0:0:0): Start with PROBE_RESET
sdhci_bcm0-slot0: Clock => 0
sdhci_bcm0-slot0: VDD => 21
sdhci_bcm0-slot0: CS => 0
sdhci_bcm0-slot0: Bus width => 0
sdhci_bcm0-slot0: Power mode => 1
sdhci_bcm0-slot0: Bus mode => 1
sdhci_bcm0-slot0: sdhci_cam_update_ios: power_mode=1, clk=0, bus_width=0, timing=0
Release APs...Trying to mount root from ufs:/dev/ufs/rootfs [rw]...
Root mount waiting for: CAM
sdhci_bcm0-slot0: Clock => 400000
sdhci_bcm0-slot0: Power mode => 2
sdhci_bcm0-slot0: Timing => 0
sdhci_bcm0-slot0: sdhci_cam_update_ios: power_mode=2, clk=400000, bus_width=0, timing=0
sdhci_bcm0-slot0: CS => 1
sdhci_bcm0-slot0: sdhci_cam_update_ios: power_mode=2, clk=400000, bus_width=0, timing=0
(mmcprobe0:sdhci_slot0:0:0:0): Send first XPT_MMC_IO
(noperiph:sdhci_slot1:0:-1:ffffffff): XPT_SCAN_{BUS,TGT,LUN}
(noperiph:sdhci_slot1:0:0:0): XPT_SCAN_{BUS,TGT,LUN}
(noperiph:sdhci_slot1:0:0:0):  Set up the mmcprobe device...
(mmcprobe1:sdhci_slot1:0:0:0): Periph created
(mmcprobe1:sdhci_slot1:0:0:0): Probe started
(mmcprobe1:sdhci_slot1:0:0:0): Probe PROBE_INVALID to PROBE_RESET
(mmcprobe1:sdhci_slot1:0:0:0): mmcprobe_start
(mmcprobe1:sdhci_slot1:0:0:0): Start with PROBE_RESET
sdhci_bcm1-slot0: Clock => 0
sdhci_bcm1-slot0: VDD => 21
sdhci_bcm1-slot0: CS => 0
sdhci_bcm1-slot0: Bus width => 0
sdhci_bcm1-slot0: Power mode => 1
sdhci_bcm1-slot0: Bus mode => 1
sdhci_bcm1-slot0: sdhci_cam_update_ios: power_mode=1, clk=0, bus_width=0, timing=0
APs not started
CPU  0: ARM Cortex-A72 r0p3 affinity:  0
 Instruction Set Attributes 0 = <CRC32>
 Instruction Set Attributes 1 = <>
         Processor Features 0 = <AdvSIMD,FP,EL3 32,EL2 32,EL1 32,EL0 32>
         Processor Features 1 = <>
      Memory Model Features 0 = <TGran4,TGran64,SNSMem,BigEnd,16bit ASID,16TB PA>
      Memory Model Features 1 = <8bit VMID>
      Memory Model Features 2 = <32bit CCIDX,48bit VA>
             Debug Features 0 = <2 CTX BKPTs,4 Watchpoints,6 Breakpoints,PMUv3,Debugv8>
             Debug Features 1 = <>
         Auxiliary Features 0 = <>
         Auxiliary Features 1 = <>
CPU  1: (null) (null) r0p0 affinity:  0
CPU  2: (null) (null) r0p0 affinity:  0
CPU  3: (null) (null) r0p0 affinity:  0
WARNING: WITNESS option enabled, expect reduced performance.
(mmcprobe0:sdhci_slot0:0:0:0): mmcprobe_done
Starting completion of PROBE_RESET
(mmcprobe0:sdhci_slot0:0:0:0): done with PROBE_RESET
(mmcprobe0:sdhci_slot0:0:0:0): Probe PROBE_RESET to PROBE_SEND_IF_COND
mmc_probedone: remaining freezecnt 0
(mmcprobe0:sdhci_slot0:0:0:0): mmcprobe_start
(mmcprobe0:sdhci_slot0:0:0:0): Start with PROBE_SEND_IF_COND
sdhci_bcm1-slot0: Clock => 399361
sdhci_bcm1-slot0: Power mode => 2
sdhci_bcm1-slot0: Timing => 0
sdhci_bcm1-slot0: sdhci_cam_update_ios: power_mode=2, clk=399361, bus_width=0, timing=0
Root mount waiting for: CAM
sdhci_bcm1-slot0: CS => 1
sdhci_bcm1-slot0: sdhci_cam_update_ios: power_mode=2, clk=399361, bus_width=0, timing=0
(mmcprobe1:sdhci_slot1:0:0:0): Send first XPT_MMC_IO
mountroot: waiting for device /dev/ufs/rootfs...
Mounting from ufs:/dev/ufs/rootfs failed with error 19.

Loader variables:
  vfs.root.mountfrom=ufs:/dev/ufs/rootfs
  vfs.root.mountfrom.options=rw

Manual root filesystem specification:
  <fstype>:<device> [options]
      Mount <device> using filesystem <fstype>
      and with the specified (optional) option list.

    eg. ufs:/dev/da0s1a
        zfs:zroot/ROOT/default
        cd9660:/dev/cd0 ro
          (which is equivalent to: mount -t cd9660 -o ro /dev/cd0 /)

  ?               List valid disk boot devices
  .               Yield 1 second (for background tasks)
  <empty line>    Abort manual input

mountroot> sdhci_bcm0-slot0: Controller timeout
sdhci_bcm0-slot0: ============== REGISTER DUMP ==============
sdhci_bcm0-slot0: Sys addr: 0x00000000 | Version:  0x00001002
sdhci_bcm0-slot0: Blk size: 0x00000000 | Blk cnt:  0x00000000
sdhci_bcm0-slot0: Argument: 0x000001aa | Trn mode: 0x00000000
sdhci_bcm0-slot0: Present:  0x1fff0000 | Host ctl: 0x00000000
sdhci_bcm0-slot0: Power:    0x0000000f | Blk gap:  0x00000080
sdhci_bcm0-slot0: Wake-up:  0x00000000 | Clock:    0x00007d07
sdhci_bcm0-slot0: Timeout:  0x00000000 | Int stat: 0x00000001
sdhci_bcm0-slot0: Int enab: 0x01ff003b | Sig enab: 0x01ff003b
sdhci_bcm0-slot0: AC12 err: 0x00000000 | Host ctl2:0x00000000
sdhci_bcm0-slot0: Caps:     0x45ee6432 | Caps2:    0x0000a525
sdhci_bcm0-slot0: Max curr: 0x00080008 | ADMA err: 0x00000000
sdhci_bcm0-slot0: ADMA addr:0x00000000 | Slot int: 0x00000001
sdhci_bcm0-slot0: ===========================================
sdhci_bcm1-slot0: Controller timeout
sdhci_bcm1-slot0: ============== REGISTER DUMP ==============
sdhci_bcm1-slot0: Sys addr: 0x00000000 | Version:  0x00009902
sdhci_bcm1-slot0: Blk size: 0x00000000 | Blk cnt:  0x00000000
sdhci_bcm1-slot0: Argument: 0x00000000 | Trn mode: 0x00000000
sdhci_bcm1-slot0: Present:  0x000f0001 | Host ctl: 0x00000000
sdhci_bcm1-slot0: Power:    0x0000000f | Blk gap:  0x00000000
sdhci_bcm1-slot0: Wake-up:  0x00000000 | Clock:    0x00003947
sdhci_bcm1-slot0: Timeout:  0x00000000 | Int stat: 0x00038000
sdhci_bcm1-slot0: Int enab: 0x01ff00bb | Sig enab: 0x01ff00bb
sdhci_bcm1-slot0: AC12 err: 0x00000000 | Host ctl2:0x00000000
sdhci_bcm1-slot0: Caps:     0x00000000 | Caps2:    0x00000000
sdhci_bcm1-slot0: Max curr: 0x00000001 | ADMA err: 0x00000000
sdhci_bcm1-slot0: ADMA addr:0x00000000 | Slot int: 0x00000001
sdhci_bcm1-slot0: ===========================================
(mmcprobe0:sdhci_slot0:0:0:0): mmcprobe_done
(mmcprobe0:sdhci_slot0:0:0:0): IF_COND: error 1, pattern 00000000
(mmcprobe0:sdhci_slot0:0:0:0): Probe PROBE_SEND_IF_COND to PROBE_SDIO_RESET
mmc_probedone: remaining freezecnt 0
(mmcprobe0:sdhci_slot0:0:0:0): mmcprobe_start
(mmcprobe0:sdhci_slot0:0:0:0): Start with PROBE_SDIO_RESET
(mmcprobe1:sdhci_slot1:0:0:0): mmcprobe_done
Starting completion of PROBE_RESET
(mmcprobe1:sdhci_slot1:0:0:0): done with PROBE_RESET
(mmcprobe1:sdhci_slot1:0:0:0): GO_IDLE_STATE failed with error 1
(mmcprobe1:sdhci_slot1:0:0:0): Probe PROBE_RESET to PROBE_INVALID
mmc_probedone: remaining freezecnt 0
(mmcprobe1:sdhci_slot1:0:0:0): Periph invalidated
(mmcprobe1:sdhci_slot1:0:0:0): Periph destroyed
?

List of GEOM managed disk devices:


mountroot> sdhci_bcm0-slot0: Controller timeout
sdhci_bcm0-slot0: ============== REGISTER DUMP ==============
sdhci_bcm0-slot0: Sys addr: 0x00000000 | Version:  0x00001002
sdhci_bcm0-slot0: Blk size: 0x00000000 | Blk cnt:  0x00000000
sdhci_bcm0-slot0: Argument: 0x88000c08 | Trn mode: 0x00000000
sdhci_bcm0-slot0: Present:  0x1fff0000 | Host ctl: 0x00000000
sdhci_bcm0-slot0: Power:    0x0000000f | Blk gap:  0x00000080
sdhci_bcm0-slot0: Wake-up:  0x00000000 | Clock:    0x00007d07
sdhci_bcm0-slot0: Timeout:  0x00000000 | Int stat: 0x00018000
sdhci_bcm0-slot0: Int enab: 0x01ff003b | Sig enab: 0x01ff003b
sdhci_bcm0-slot0: AC12 err: 0x00000000 | Host ctl2:0x00000000
sdhci_bcm0-slot0: Caps:     0x45ee6432 | Caps2:    0x0000a525
sdhci_bcm0-slot0: Max curr: 0x00080008 | ADMA err: 0x00000000
sdhci_bcm0-slot0: ADMA addr:0x00000000 | Slot int: 0x00000001
sdhci_bcm0-slot0: ===========================================
(mmcprobe0:sdhci_slot0:0:0:0): mmcprobe_done
(mmcprobe0:sdhci_slot0:0:0:0): SDIO_RESET: error 1, CCCR CTL register: 00000000
(mmcprobe0:sdhci_slot0:0:0:0): Probe PROBE_SDIO_RESET to PROBE_SDIO_INIT
mmc_probedone: remaining freezecnt 0
(mmcprobe0:sdhci_slot0:0:0:0): mmcprobe_start
(mmcprobe0:sdhci_slot0:0:0:0): Start with PROBE_SDIO_INIT
?

List of GEOM managed disk devices:


mountroot> ?

List of GEOM managed disk devices:


mountroot>
panic: mountroot: unable to (re-)mount root.
cpuid = 0
time = 32
KDB: stack backtrace:
db_trace_self() at db_trace_self_wrapper+0x28
         pc = 0xffff00000073c68c  lr = 0xffff000000110570
         sp = 0xffff000040265370  fp = 0xffff000040265580

db_trace_self_wrapper() at vpanic+0x194
         pc = 0xffff000000110570  lr = 0xffff00000040b03c
         sp = 0xffff000040265590  fp = 0xffff000040265640

vpanic() at panic+0x44
         pc = 0xffff00000040b03c  lr = 0xffff00000040ade4
         sp = 0xffff000040265650  fp = 0xffff0000402656d0

panic() at vfs_mountroot+0x1558
         pc = 0xffff00000040ade4  lr = 0xffff0000004d1950
         sp = 0xffff0000402656e0  fp = 0xffff000040265880

vfs_mountroot() at start_init+0x28
         pc = 0xffff0000004d1950  lr = 0xffff0000003a3cec
         sp = 0xffff000040265890  fp = 0xffff000040265940

start_init() at fork_exit+0x7c
         pc = 0xffff0000003a3cec  lr = 0xffff0000003ca2f8
         sp = 0xffff000040265950  fp = 0xffff000040265980

fork_exit() at fork_trampoline+0x10
         pc = 0xffff0000003ca2f8  lr = 0xffff0000007592cc
         sp = 0xffff000040265990  fp = 0x0000000000000000

KDB: enter: panic
[ thread pid 1 tid 100002 ]
Stopped at      0
db>


----------



## ykla (Apr 22, 2020)

Waiting for bcm-sdio driver.


----------



## J O H N (May 20, 2020)

ekingston said:


> In case people haven't noticed, the Raspberry Pi 4 has been announced. Theoretically it's available but as is typical, everything is back-order (in the suppliers I deal with). There are some interesting updates:
> 
> 1.5 GHz Quad Core
> 1, 2, or 4 GB of RAM (you choose at time of purchase)
> ...



I just imaged an SD card with  64-bit ARMv8 aarch64 and booted it on a 4GB Raspberry Pi 4 model B (2018).  It booted without modification and displayed on an HDMI monitor but there was no power to any of the USB ports.  It did recognize the Ethernet port (not the wireless one).  So close....

Anyway, I just wanted to congratulate all of you whom have been working so hard on this distro and, in particular, for the Raspberry Pi.

Kind regards.


----------



## kpedersen (May 20, 2020)

This is really great. It is really nice to see that FreeBSD is remaining fairly light and portable to alternative architectures. I like the idea that if a truely fantastic one comes along, FreeBSD will not be lagging behind in support due to too much reliance on x86 assumptions.

I notice that the OpenBSD port to this platform has no HDMI (needs to be setup via serial). I assumed this was due to some missing Broadcom blob. How is it that the FreeBSD port has working HDMI?


----------



## RobCrowston (May 23, 2020)

I haven't looked in a lot of detail, but OpenBSD uses TianoCore EDK2 instead of U-Boot. That has some advantages, for instance, the PCI-E controller is initialized ready for the operating system to use. I wasn't aware that HDMI didn't function. AFAIK we do nothing special for HDMI, it's just prepared for us by u-boot like any other video device.

Also, this is not the only arm64 device. On the other side of the scale FreeBSD works for instance on Amazon's 64 core Graviton2 architecture and Amazon has been submitting patches recently to improve the situation there. There's also been long standing support for Cavium ThunderX 96 core machines. I don't see support for the Pi ever being much better than experimental because we really have no manufacturer support at all.

I figured out how to route MSI interrupts on the Pi4 today ... but the USB controller is still not initializing properly. Still more work required!


----------



## RobCrowston (May 29, 2020)

In good news, I have an early version of the PCI-E driver now available for anyone who wants to test it. It works okay enough for me with a keyboard and mouse, but mass storage devices are a bit less reliable. Folks connecting through USB hubs are having more trouble. I'll try to get it up on Phabricator shortly as I made some minor surgery in the current PCI-E system which someone will probably want me to change.

In bad news, it seems that the Pi foundation has redesigned the hardware path by which the XHCI chip loads its firmware in the 8 GiB design of the Pi 4. I have an 8 GiB model on order, should arrive in the next few days.


----------



## ucomp (May 30, 2020)

RobCrowston said:


> PCI-E driver now available for anyone who wants to test it.



Freaks, what's going on here, nobody of you tests the driver? Everyone wants something but nobody wants to help?
So let's go: one two three four, start the test,
five six seven eight, come on, start your tests ✌


----------



## ucomp (May 30, 2020)

ucomp said:


> So let's go: one two three four, start the test,
> five six seven eight, come on, start your tests



we `ve found another tester , so we are complete, thanks a lot !

you here  can drive home , you can, you can, you can drive home ... scoobidooo, lullaloo...


----------



## RobCrowston (Jun 6, 2020)

Acquired the 8 GB model and got it started this morning. Requires a relatively simple patch to u-boot.

However the progress we made with xhci and ethernet has been undone. I think repairing xhci will be easy enough. Not sure about ethernet.


----------



## ucomp (Jun 7, 2020)

RobCrowston said:


> Not sure about ethernet.


As you already know, your BSD-world-premiere-u-boot-hack on the RPI4/8GB is even better than you thought  

```
root@generic:~ # sysctl hw.physmem
hw.physmem: 8422461440
root@generic:~ # ping forums.freebsd.org
PING forums.freebsd.org (204.109.59.195): 56 data bytes
64 bytes from 204.109.59.195: icmp_seq=0 ttl=45 time=213.881 ms
64 bytes from 204.109.59.195: icmp_seq=1 ttl=45 time=203.807 ms
64 bytes from 204.109.59.195: icmp_seq=2 ttl=45 time=189.085 ms
^C
--- forums.freebsd.org ping statistics ---
3 packets transmitted, 3 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 189.085/202.258/213.881/10.182 ms
```


----------

