Raspberry Pi 3 img?

Ozfer said:
Arm64 is the future I would not be surprised if 10 years from now the norm is many cored arm desktops/laptops with only SSDs and everyone will forget disks and disk drives.... and windows could quite possibly be dead
Click to expand...

Intel seems to be giving up on doing mobile, and I read that they have opened their foundaries (starting with 10 nm, and then also for 7 nm lithographies) - to those who want to build ARM mobile devices. Samsung has (apparently) been negotiating for use of Intel's foundry to do their own mobile (smartphone) SoCs.

One of the problems is heat, which worsens as the lithography gets ever smaller. 10 nm litho allows twice as much stuff in the same space, but generates about the same heat. Current chips are mostly 20 - 40 nm (Pi3 SoC is 40 nm). If the same die size is filled to max, the heat doubles (less a little for thermal tech). Heat will be ever more problematic as the geometries shrink, even for mobile SoC devices. AFAIK Intel's CISC chips are quicker to heat, due to higher area/function ratios. So, yes, I think ARM is not stopping anytime soon (maybe that's why Japan's SoftBank is buying them out).
 
Hi,
I think that Motorola is not dead, may be help Motorola with the developers free world (opensource), and also the legend reborn if this last create an processor multi cores = may be to counter ARM processor, i don't forgot the time of 6800 processor....
 
10.3 is in maintenance mode, no new features will be added to it. Support for RPI3 will first land in -CURRENT and probably MFC'ed to 11-STABLE.
 
acheron said:
10.3 is in maintenance mode, no new features will be added to it. Support for RPI3 wil first land in -CURRENT and probably MFC'ed to 11-STABLE.
Click to expand...

Ahh I see. So would it be unreasonable to see a version out for RPi3 before this using some sort of pre-release?
Also, is it assumed that the 11.0 release will support it out of the box?
 
Ok, so where can I find any information on who is working on it within the FreeBSD team?
Or is there any 3rd party information that breaksdown the process to get this working on the RPI3?
 
I can't get my RPi3 to budge with the FreeBSD / RaspBSD image. It boots and runs Raspbian just fine, so I know the hardware is good. I even created my raspbian image using the same method and the same SD card that failed with FreeBSD. If I understood the process correctly, this should have worked - so maybe I have a basic misunderstanding somewhere?
I downloaded FreeBSD-aarch64-12.0-GENERIC-313109M.img.gz from www.raspbsd.org onto my Intel FreeBSD 10.1 system and gunzipped it. I SFTP'ed it to a Windows system (since I don't have an SD interface on my FreeBSD system) and did
\local\bin\dd bs=1M if=FreeBSD-aarch64-12.0-GENERIC-313109M.img of=\\.\e: --progress
and it counted off 1900-some blocks. At that point, I expected to see a FAT32 file system with the low-level boot files, but Windows just says something about needing to format the device before it can be used (which I did not do). With the Raspbian image, I can definitely see the low-level boot files on the FAT32 part of the device. When I put this SD card in the PI3, I don't even see a flicker on the green light. It is clearly not seeing an MBR or filesystem that it recognizes. Did I do something wrong? Is it possible that the image is corrupted? What should I expect to see after doing the dd to \\.\e:? Shouldn't I be able to see the low-level boot files at that point? Is there another way entirely to get to where I want to be? Anyway - any pointers or clues will be appreciated.
 
I'm not sure about the generic ARM64 images.
There has been some recent RPI3 updates including support for SMP on crochet though.
RPi3 is still in early stages. There also had been some churn with a newer u-boot version I have seen on the mailing list.
It's in working order now with a SMP kernel.
Thanks to both Gonzo and Diane and everybody else involved.
 
Hmm, the image from http://www.raspbsd.org (r313109) works on my new RPi3. :)

However, I get random crashes (signal 4 = illegal instruction, signal 11 = segmentation fault) while compiling ports, the world etc.

I eventually managed to compile all ports I need, since make build can continue where it left off.

Unfortunately, compiling the world can't make it thru. The CPU temperature rises to about 75°C when make buildworld, or 85°C when make -j4 buildworld is invoked.
  1. Is anybody else getting the core dumps while compiling?
  2. Is it possible to limit the speed of CPU? The sysctl dev.cpu.0 does show that powerd is dynamically adjusting CPU speed.
I shall install CentOS or Raspbian in the following days to stress test my hardware.
 
I hope someone can help. I've got FreeBSD-aarch64-12.0-GENERIC-313109M.img.gz from raspbsd.org with SHA256 of 3A192593804B70783C0233B0FC2F11BC76892C8C9A29FAA19722CF5CD0CA96D6 which I confirmed with Brad. When I unzip it, I get a file of 1949999616 bytes with SHA256 of ed3c54e3a293b086dab4b7f2b002e52bb5f074788ff85c6a2afca2c54dcbed5a. The thing is, the first 1790 bytes of that file are all zero! That seems unlikely to be a FAT file system no matter how I copy it on to my SD. Unless my 313109M is different than your 313109 (no M? Is that possible?) than this seems impossible. I used the same process to write the NOOBS and that worked fine, so I don't think my process or utility is faulty. But I'm totally at a loss as to how I could start with a file of the right SHA256 hash value and expand it without error to a file that starts with 1790 zero bytes and still be using the same bits as everyone else is. Is there some way to get my hands on 313772?
 
-Rozi- said:
Hmm, the image from http://www.raspbsd.org (r313109) works on my new RPi3. :)

However, I get random crashes (signal 4 = illegal instruction, signal 11 = segmentation fault) while compiling ports, the world etc.

I eventually managed to compile all ports I need, since make build can continue where it left off.

Unfortunately, compiling the world can't make it thru. The CPU temperature rises to about 75°C when make buildworld, or 85°C when make -j4 buildworld is invoked.
  1. Is anybody else getting the core dumps while compiling?
  2. Is it possible to limit the speed of CPU? The sysctl dev.cpu.0 does show that powerd is dynamically adjusting CPU speed.
I shall install CentOS or Raspbian in the following days to stress test my hardware.
Click to expand...
What about cooling instead of limiting the CPU speed? Do you have the heat sink kit? What about a tiny bit of active cooling?
 
Alathar said:
I hope someone can help. I've got FreeBSD-aarch64-12.0-GENERIC-313109M.img.gz from raspbsd.org with SHA256 of 3A192593804B70783C0233B0FC2F11BC76892C8C9A29FAA19722CF5CD0CA96D6 which I confirmed with Brad. When I unzip it, I get a file of 1949999616 bytes with SHA256 of ed3c54e3a293b086dab4b7f2b002e52bb5f074788ff85c6a2afca2c54dcbed5a. The thing is, the first 1790 bytes of that file are all zero! That seems unlikely to be a FAT file system no matter how I copy it on to my SD. Unless my 313109M is different than your 313109 (no M? Is that possible?) than this seems impossible. I used the same process to write the NOOBS and that worked fine, so I don't think my process or utility is faulty. But I'm totally at a loss as to how I could start with a file of the right SHA256 hash value and expand it without error to a file that starts with 1790 zero bytes and still be using the same bits as everyone else is. Is there some way to get my hands on 313772?
Click to expand...

That's OK. I confirm the same SHA-256, and the file does begin with zeros as you described. Using Win32DiskImager I can write it to a microSD card that boots in RPi3 just fine. (I don't know about HDMI, as I attach using RS-232 cable to get the console.)
 
Alathar said:
Is there some way to get my hands on 313772?
Click to expand...

I send an e-mail to RaspBSD maintainer a couple of days ago asking the same. No reply. Not sure I got the right address, though.

So, I did it myself:
  1. Installed the VirtualBox
  2. Set-up a FreeBSD-11-amd64 guest
  3. Installed git
  4. Installed crochet: mkdir crochet && git clone https://github.com/freebsd/crochet.git crochet
  5. Checked-out FreeBSD-12-CURRENT (r314132): svnlite checkout crochet/src
  6. Installed all required tools (preferably from ports collection; pkg repository is outdated for RPi3 builds):
    • aarch64-binutils-2.27_6,1
    • u-boot-rpi3-2017.01
  7. Made a new config: cp crochet/config.sh.sample crochet/rpi3.config.sh
  8. Edited crochet/rpi3.config.sh to suit my needs. If only I could get the configuration file from RaspBSD for a head start. :(
  9. Build the IMG file: cd crochet && ./crochet.sh -c rpi3.config.sh
Unfortunately, all U-Boot partition filenames were uppercase 8+3 FAT, so the image didn't boot. I fixed that by hand by comparing boot partitions between my and RaspBSD image. It booted then.

It took me a day, but it was fun. :) Much to my wife's dismay. :(

My observations about FreeBSD-aarch64-12.0-GENERIC-314132 after the first few hours:
  1. Occasionally, it displays some diagnostic trace dump on the console about lock order reversal. Looks like some debugging stuff.
  2. powerd does not start: powerd: no cpufreq(4) support -- aborting: No such file or directory
  3. So far no core dumps. But I didn't have time to do some real stress-testing yet. :)
 
Alathar said:
What about cooling instead of limiting the CPU speed? Do you have the heat sink kit? What about a tiny bit of active cooling?
Click to expand...

I do have a heat-sink kit. But it seemed that the core dumps on r313109 were not caused by the temperature. Because I got some core dumps soon after the start of the "make -j4 buildworld" before CPU got hot.

Plus, the frequency of core dumps did increase, when I ran some USB intensive operations in parallel (like grep or find on the root partition).

I disconnected everything (no Ethernet, no USB) to keep interrupts as low as possible, and ran "make buildworls" in a single thread, without other activities in parallel. The build actually survived about 8 hours until it hit some error in the source code. It couldn't last for an hour before this. If I would manually heat the CPU meanwhile, and the build would remain stable, it could be a proof of an interrupt issue rather than a thermal one.
 
-Rozi- said:
That's OK. I confirm the same SHA-256, and the file does begin with zeros as you described. Using Win32DiskImager I can write it to a microSD card that boots in RPi3 just fine. (I don't know about HDMI, as I attach using RS-232 cable to get the console.)
Click to expand...
OK! Well, that must be the problem, then. I'd have not thought of that without your help. Yes, I am trying to use the HDMI console. Actually, I was hoping to boot it completely headless, and do everything via SSH. Maybe I'll just unplug the HDMI and keyboard and mouse and see what happens with Ethernet only. You see, I only have ONE USB/RS-232 adapter.... So if I plug that into the PI, then I don't have an RS-232 capable laptop anymore... So, maybe I'll have to go out and buy a second USB/RS-232 adapter - which seems a little silly: Pi3 <-> USB <-> RS-232 splicer <-> USB <-> laptop.... And I still don't understand why Windows doesn't see the FAT32 boot partition... Mystery upon mystery... But THANK YOU for this help! I really appreciate it.
 
You must log in or register to reply here.
Back
Top