[quote pid='39500' dateline='1533109973']
What's the crash you are seeing for eMMC ?
For the thermal driver I'm currently finishing my patch to upstream the dts binding for it and will commit FreeBSD code soon.
The ethernet controller have it's own DMA controller iirc, is that what you have talking about ?
For USB iirc one of the port is configured as OTG and we don't support this (there is a review with patch)
What do you mean by "kernel is placed into SPL" ???
[/quote]
* eMMC crashes on a protocol issue;
* Thermal is nice I cannot do without!
- by the way: CPUFreq is also mostly a DTB patch I think. (it was pretty easy for me)
* USB didn't even try the host port yet haha, didn't even think remotely it would work.
* Ethernet did 7MB/s when I first started testing FreeBSD on the clusterboard.
The syscons in the DTB was not correct and also I think I needed to change some small
other stuff making it work more stable.
And removed some stuff to get it going up to 92MB/s on the clusterboard (at peak), ~80MB/s steady.
* I was experimenting with flashing the entire kernel to SPL and loading it from there.
It does fit/work it will make kernel upgrades a pain for now.
But then you don't need u-boot to fetch the kernel from NFS anymore and can 'almost' directly start it.
FreeBSD boot from eMMC without the patch
Edit:
I just noticed I used the wrong DTB. I was still testing stuff the lazy way and forgot about it until I rechecked the boot messages.
I'll upload the new DTB you can place in the MSDOS partition /sopine.dtb to fix the syscon driver.
Doesn't seem to make much of a difference still peaking at ~92MB/s and CPU stays pretty low (<8%) while utilizing network.
It does get HOT fast when doing lots of traffic
'dd if=/dev/urandom bs=1m | ssh node dd of=/dev/null' and without a fan it will throttle down to 500Mhz in a couple of minutes.
Still trying to pinpoint the link dropping issue (you notice the most in log messages) I think it's something rgephy is doing.. (don't mind the time, this node cannot access a NTP server atm because I'm too lazy to fix my firewall or install ntp)
*edit 2:
The syscon fix and delay to 0,2 are looking to have fixed the link drop issue.
None of the 7 nodes have dropped link in the last 20 minutes or so this is looking promising.
If all is stable I'll make a diff, check all modifications (aka ugly hacks) and post them.
What's the crash you are seeing for eMMC ?
For the thermal driver I'm currently finishing my patch to upstream the dts binding for it and will commit FreeBSD code soon.
The ethernet controller have it's own DMA controller iirc, is that what you have talking about ?
For USB iirc one of the port is configured as OTG and we don't support this (there is a review with patch)
What do you mean by "kernel is placed into SPL" ???
[/quote]
* eMMC crashes on a protocol issue;
Code:
Allwinner datasheet;
* "SMHC Controller support up to MMC5.0"
-- 52 is activated in the features.
* Thermal is nice I cannot do without!
- by the way: CPUFreq is also mostly a DTB patch I think. (it was pretty easy for me)
* USB didn't even try the host port yet haha, didn't even think remotely it would work.
* Ethernet did 7MB/s when I first started testing FreeBSD on the clusterboard.
The syscons in the DTB was not correct and also I think I needed to change some small
other stuff making it work more stable.
And removed some stuff to get it going up to 92MB/s on the clusterboard (at peak), ~80MB/s steady.
* I was experimenting with flashing the entire kernel to SPL and loading it from there.
It does fit/work it will make kernel upgrades a pain for now.
But then you don't need u-boot to fetch the kernel from NFS anymore and can 'almost' directly start it.
FreeBSD boot from eMMC without the patch
Code:
AW_MMC_INT_RESP_TIMEOUT
AW_MMC_INT_RESP_TIMEOUT
AW_MMC_INT_RESP_TIMEOUT
AW_MMC_INT_RESP_TIMEOUT
AW_MMC_INT_RESP_TIMEOUT
AW_MMC_INT_RESP_TIMEOUT
AW_MMC_INT_RESP_TIMEOUT
AW_MMC_INT_RESP_TIMEOUT
AW_MMC_INT_RESP_TIMEOUT
AW_MMC_INT_RESP_TIMEOUT
AW_MMC_INT_RESP_TIMEOUT
mmc0: No compatible cards found on bus
aw_mmc0: Spurious interrupt - no active request, rint: 0x00000004
AW_MMC_INT_RESP_TIMEOUT
AW_MMC_INT_RESP_TIMEOUT
AW_MMC_INT_RESP_TIMEOUT
AW_MMC_INT_RESP_TIMEOUT
AW_MMC_INT_RESP_TIMEOUT
AW_MMC_INT_RESP_TIMEOUT
AW_MMC_INT_RESP_TIMEOUT
AW_MMC_INT_RESP_TIMEOUT
AW_MMC_INT_DATA_END_BIT_ERR
AW_MMC_INT_RESP_TIMEOUT
AW_MMC_INT_RESP_TIMEOUT
AW_MMC_INT_RESP_TIMEOUT
AW_MMC_INT_RESP_TIMEOUT
mmc1: Failed to set VCCQ for card at relative address 2
AW_MMC_INT_DATA_CRC_ERR
AW_MMC_INT_DATA_CRC_ERR
AW_MMC_INT_DATA_CRC_ERR
AW_MMC_INT_DATA_CRC_ERR
uhub1: 1 port with 1 removable, self powered
mmcsd0: Error reading EXT_CSD Failed
device_attach: mmcsd0 attach returned 6
Release APs...arc4random: no preloaded entropy cache
done
Trying to mount root from ufs:/dev/ufs/rootfs [rw,noatime]...
Root mount waiting for:CPU 0: ARM Cortex-A53 r0p4 affinity: usbus3 0
usbus2 usbus0
Instruction Set Attributes 0 = <AES+PMULL,SHA1,SHA2,CRC32>
Instruction Set Attributes 1 = <>
Processor Features 0 = <AdvSIMD,Float,EL3 32,EL2 32,EL1 32,EL0 32>
Processor Features 1 = <0>
Memory Model Features 0 = <4k Granule,64k Granule,MixedEndian,S/NS Mem,16bit ASID,1TB PA>
Memory Model Features 1 = <>
Memory Model Features 2 = <32b CCIDX,48b VA>
Debug Features 0 = <2 CTX Breakpoints,4 Watchpoints,6 Breakpoints,PMUv3,Debug v8>
Debug Features 1 = <0>
Auxiliary Features 0 = <0>
Auxiliary Features 1 = <0>
CPU 1: ARM Cortex-A53 r0p4 affinity: 1
CPU 2: ARM Cortex-A53 r0p4 affinity: 2
CPU 3: ARM Cortex-A53 r0p4 affinity: 3
uhub3: 1 port with 1 removable, self powered
uhub0: 1 port with 1 removable, self powered
uhub2: 1 port with 1 removable, self powered
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,noatime
Manual root filesystem specification:
<fstype>:<device> [options]
Mount <device> using filesystem <fstype>
and with the specified (optional) option list.
eg. ufs:/dev/da0s1a
zfs:tank
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>
I just noticed I used the wrong DTB. I was still testing stuff the lazy way and forgot about it until I rechecked the boot messages.
I'll upload the new DTB you can place in the MSDOS partition /sopine.dtb to fix the syscon driver.
Doesn't seem to make much of a difference still peaking at ~92MB/s and CPU stays pretty low (<8%) while utilizing network.
It does get HOT fast when doing lots of traffic
'dd if=/dev/urandom bs=1m | ssh node dd of=/dev/null' and without a fan it will throttle down to 500Mhz in a couple of minutes.
Still trying to pinpoint the link dropping issue (you notice the most in log messages) I think it's something rgephy is doing.. (don't mind the time, this node cannot access a NTP server atm because I'm too lazy to fix my firewall or install ntp)
Code:
# dd if=FreeBSD-aarch64-12-sopine-SoPine.img.orig of=/dev/null bs=1M
2384+1 records in
2384+1 records out
2499999744 bytes transferred in 26.997205 secs (92602168 bytes/sec)
# df -h .
Filesystem Size Used Avail Capacity Mounted on
10.90.90.166:/pi 129G 71G 58G 55% /mnt/nfs
# tail /var/log/messages
Jan 1 00:08:33 NODE001 kernel: awg0: link state changed to DOWN
Jan 1 00:08:33 NODE001 kernel: awg0: link state changed to UP
Jan 1 00:08:33 NODE001 kernel: awg0: link state changed to DOWN
Jan 1 00:08:33 NODE001 kernel: awg0: link state changed to UP
The syscon fix and delay to 0,2 are looking to have fixed the link drop issue.
None of the 7 nodes have dropped link in the last 20 minutes or so this is looking promising.
If all is stable I'll make a diff, check all modifications (aka ugly hacks) and post them.