Re: Rasberry Pi 4 has no USB
On Sun, 28 Feb 2021 09:26:23 -0800 Carl Johnson wrote: > I have an 8GB RPi 4B that I am trying out, but it has no USB response at > all. That means that I can't use a keyboard or mouse, but I can use a > serial console and ethernet. I can plug any USB device into any port, > but there is nothing logged in /var/messages. Running usbconfig as root > just reports 'No device match or lack of permissions'. Running > 'dmesg | grep -i usb' reports only the following lines: > > usb_nop_xceiv0: on ofwbus0 > bcm_xhci0: irq 81 at > device 0.0 on pci2 > usb_needs_explore_all: no devclass > > Running 'pciconf -lv' shows there is a VL805 USB controller present. I > tested this with Linux and everything worked properly. This is a new > computer that I bought only a couple of weeks ago. Does anybody have > any ideas on what this might be, or what I could do to try to figure it > out? > > Thanks in advance for any ideas. > -- > Carl Johnson ca...@peak.org > > ___ > freebsd-stable@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" Hello, This is known, see https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=252971#c25 I wanted to wait that a tag was created on the rpi-firmware github repo but it seems that they don't want to so I'll update the port next week so RC1 will have the updated firmware. Cheers, -- Emmanuel Vadot ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: CFT: FreeBSD Package Base
On Mon, 29 Apr 2019 10:05:59 -0400 Kris Moore wrote: > On Mon, Apr 29, 2019 at 9:55 AM Emmanuel Vadot > wrote: > > > On Mon, 29 Apr 2019 09:25:05 -0400 > > Kris Moore wrote: > > > > > On Mon, Apr 29, 2019 at 8:12 AM Emmanuel Vadot > > > wrote: > > > > > > > > > > > Hi Kris, > > > > > > > > On Sun, 28 Apr 2019 15:52:21 -0400 > > > > wrote: > > > > > > > > > FreeBSD Community, > > > > > > > > > > > > > > > > > > > > I'm pleased to announce a CFT for builds of FreeBSD 12-stable and > > > > 13-current > > > > > using "TrueOS-inspired" packaged base. These are stock FreeBSD images > > > > which > > > > > will allow users to perform all updating via the 'pkg' command > > directly. > > > > > Rather than trying to answer all questions in this announcement, > > we've > > > > > created a FAQ page with more details. Please refer to this page, and > > let > > > > us > > > > > know if you have additional questions that we can include on that > > page > > > > going > > > > > forward. > > > > > > > > > > > > > While I appreciate the effort I have some doubt about your > > > > "re-implementation" of pkgbase. I don't see any improvement compared to > > > > what is in base currently, I even see downside of your implementation. > > > > > > > > - How do you plan with the need of updating kernel first, reboot and > > > > updating the rest of the userland after ? (Needed for major and minor > > > > upgrade, 12.0 to 12.1 for example, and simple update in -STABLE and > > > > -HEAD branch). This is still a problem with the base pkgbase. > > > > > > > > > > We've written our own tool "sysutils/sysup" in GO which handles this. It > > > performs updates using Boot-Environments to ensure that kernel/world are > > > updated at same time. > > > > > > > Which could never be imported into FreeBSD. > > > > Not suggesting it should be. Just information on how we solved that problem > in our own appliance / platforms. For FreeBSD it would need some tooling > still to handle this style of updating, regardless of which pkg base is > used. > > And for what it's worth, FreeBSD is all the poorer for not being able to > bring modern language based tools into the base. Personally I'm hoping the > shift to base-packages makes this a moot point since the idea of 'what is > base' can be diluted to just a manifest of what gets installed out of box. > Just my 2C on the matter though :) > > > > > > > > > > > > > > - This is even worse because you are using the same repository for > > > > base and pkg so if a user pkg update and both kernel and pkg(8) needs > > > > to be updated and pkg use a new syscall or capsicum thing it will be > > > > updated first and couldn't proceed with the rest of the update (this is > > > > a supposition, I haven't personally tested). > > > > > > > > > > See above. > > > > You can selectively update os/kernel and reboot before doing rest. > > > > > > > > > > > > - It seems that multiple kernels isn't supported in your > > > > implementation, this is already supported in pkgbase but still need > > > > some love. This is an important point as it will allow user to choose > > > > easily the kernel that they want to use and will also allow us > > > > developper to push kernels with new features to help testing. > > > > > > > > > > Incorrect, on the 13-CURRENT build if you install kernel-debug, you'll > > get > > > the Witness-enabled kernel installed alongside non-debugging one. > > > > Mhm no, the kernel-debug packages only add the debug file > > in /usr/lib/debug/boot/ > > I'm talking about installing multiple kernels in // > > (i.e. /boot/kernel.GENERIC /boot/kernel.MYFEATUREIWANTTOTEST) like > > describe here : > > > > https://wiki.freebsd.org/PkgBase#Project_goals_and_additional_unresolved_issues > > in the "How to handle /boot/kernel and /boot/kernel.$KERNCONF" point. > > > > > Incorrect, os/kernel-debug installs /boot/kernel-debug which is (on > 13-CURRENT) the Witness enabled
Re: CFT: FreeBSD Package Base
On Mon, 29 Apr 2019 09:25:05 -0400 Kris Moore wrote: > On Mon, Apr 29, 2019 at 8:12 AM Emmanuel Vadot > wrote: > > > > > Hi Kris, > > > > On Sun, 28 Apr 2019 15:52:21 -0400 > > wrote: > > > > > FreeBSD Community, > > > > > > > > > > > > I'm pleased to announce a CFT for builds of FreeBSD 12-stable and > > 13-current > > > using "TrueOS-inspired" packaged base. These are stock FreeBSD images > > which > > > will allow users to perform all updating via the 'pkg' command directly. > > > Rather than trying to answer all questions in this announcement, we've > > > created a FAQ page with more details. Please refer to this page, and let > > us > > > know if you have additional questions that we can include on that page > > going > > > forward. > > > > > > > While I appreciate the effort I have some doubt about your > > "re-implementation" of pkgbase. I don't see any improvement compared to > > what is in base currently, I even see downside of your implementation. > > > > - How do you plan with the need of updating kernel first, reboot and > > updating the rest of the userland after ? (Needed for major and minor > > upgrade, 12.0 to 12.1 for example, and simple update in -STABLE and > > -HEAD branch). This is still a problem with the base pkgbase. > > > > We've written our own tool "sysutils/sysup" in GO which handles this. It > performs updates using Boot-Environments to ensure that kernel/world are > updated at same time. > Which could never be imported into FreeBSD. > > > > - This is even worse because you are using the same repository for > > base and pkg so if a user pkg update and both kernel and pkg(8) needs > > to be updated and pkg use a new syscall or capsicum thing it will be > > updated first and couldn't proceed with the rest of the update (this is > > a supposition, I haven't personally tested). > > > > See above. > > > > - It seems that multiple kernels isn't supported in your > > implementation, this is already supported in pkgbase but still need > > some love. This is an important point as it will allow user to choose > > easily the kernel that they want to use and will also allow us > > developper to push kernels with new features to help testing. > > > > Incorrect, on the 13-CURRENT build if you install kernel-debug, you'll get > the Witness-enabled kernel installed alongside non-debugging one. Mhm no, the kernel-debug packages only add the debug file in /usr/lib/debug/boot/ I'm talking about installing multiple kernels in // (i.e. /boot/kernel.GENERIC /boot/kernel.MYFEATUREIWANTTOTEST) like describe here : https://wiki.freebsd.org/PkgBase#Project_goals_and_additional_unresolved_issues in the "How to handle /boot/kernel and /boot/kernel.$KERNCONF" point. > > > - Since you reduced the granularity on the userland bits it would mean > > that if we use your implementation for -p updates we would download the > > whole userland packages instead of just updating the package that was > > patched. For example with pkgbase, updating from 12.0 to 12.0p1 will > > only update the FreeBSD-runtime package. Yes this package is still big > > to download when you compare to what have changed but until pkg(8) have > > delta pkg supports (and if it will have support, I don't know if > > this is a wish or not) this is the best way to go. > > > > Correct, this is by design. We used the in-tree pkg base for nearly a year, > and found that the granularity didn't really offer any savings from a > download or time perspective. Updating 100+ packages took far longer than a > single one, due to all the meta operations. Additionally in real-world > usage, we found that base packages tended to all get updated at the same > time, which took far longer via pkg, since it had to go and perform 100+ > fetch operations just to download the base system bits. > But you never need to update 100+ packages on a proper pkgbase setup for -p updates. Again on a 12.0 to 12.0-p1 update only one package will be updated. > > > - I see that you are sorting the plist for kernel and userland based > > on the line length [1], why is that ? > > > Whoops! I'll fix :) > > > > > > I think that the only advantage that your solution offers is that if > > we remove a componant of base (rcmds for example in 12-CURRENT) those > > files would be removed as they are in the userland-base package while > > for pkgbase the F
Re: CFT: FreeBSD Package Base
Hi Kris, On Sun, 28 Apr 2019 15:52:21 -0400 wrote: > FreeBSD Community, > > > > I'm pleased to announce a CFT for builds of FreeBSD 12-stable and 13-current > using "TrueOS-inspired" packaged base. These are stock FreeBSD images which > will allow users to perform all updating via the 'pkg' command directly. > Rather than trying to answer all questions in this announcement, we've > created a FAQ page with more details. Please refer to this page, and let us > know if you have additional questions that we can include on that page going > forward. > While I appreciate the effort I have some doubt about your "re-implementation" of pkgbase. I don't see any improvement compared to what is in base currently, I even see downside of your implementation. - How do you plan with the need of updating kernel first, reboot and updating the rest of the userland after ? (Needed for major and minor upgrade, 12.0 to 12.1 for example, and simple update in -STABLE and -HEAD branch). This is still a problem with the base pkgbase. - This is even worse because you are using the same repository for base and pkg so if a user pkg update and both kernel and pkg(8) needs to be updated and pkg use a new syscall or capsicum thing it will be updated first and couldn't proceed with the rest of the update (this is a supposition, I haven't personally tested). - It seems that multiple kernels isn't supported in your implementation, this is already supported in pkgbase but still need some love. This is an important point as it will allow user to choose easily the kernel that they want to use and will also allow us developper to push kernels with new features to help testing. - Since you reduced the granularity on the userland bits it would mean that if we use your implementation for -p updates we would download the whole userland packages instead of just updating the package that was patched. For example with pkgbase, updating from 12.0 to 12.0p1 will only update the FreeBSD-runtime package. Yes this package is still big to download when you compare to what have changed but until pkg(8) have delta pkg supports (and if it will have support, I don't know if this is a wish or not) this is the best way to go. - I see that you are sorting the plist for kernel and userland based on the line length [1], why is that ? I think that the only advantage that your solution offers is that if we remove a componant of base (rcmds for example in 12-CURRENT) those files would be removed as they are in the userland-base package while for pkgbase the FreeBSD-rcmd package will be deleted in the repo and will not be deleted in the user computer. > > Additionally, I will be hosting a Package Base working group at BSDCan 2019, > and welcome user and developer attendance to discuss this and other ongoing > package work: > > > > https://wiki.freebsd.org/DevSummit/201905/PackageBase > I will be present and looking forward to work with you on this. Cheers, P.S. : FYI I'm working on pkgbase currently and I will have some patches to commit soon (bsdinstall support, memstick creation that install a pkgbase aware installaton etc ...). [1] : https://github.com/trueos/trueos-ports/blob/trueos-master/os/userland-base/Makefile#L35 -- Emmanuel Vadot ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Fujitsu Lifebook E751 (iGPU: HM65): distorted console with UEFI boot
Hi, On Wed, 28 Nov 2018 10:51:11 +0100 "O. Hartmann" wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > I ran into some trouble booting off a Fujitsu Lifebook E751 (firmware is > latest, r1.22 > from 2013). The E751 is of model series S26391-K326-V100 and equipted with a > Core > i5-2520M CPU and supposed to be also equipted with a iGPU HM65 according to > the > techniscal specifications from Fujitsu. > > Trying to boot off 12-PRERELEASE/12-RC2 and/or 13-CURRENT (most recent I > could grap from > the download page), the screen becomes distorted immediately after the kernel > has > loaded and initialised/booted. The screen is at the loader's all right so far. > > Trying to disable graphics mode via escaping to the loader's prompt and > setting > > set hw.vga.textmode=1 > > subsequently loading the kernel and then booting, doesn't help. The screen is > distorted > again. The notebook seems UEFI only and doesn't boot off from MBR partioned > devices (i.e. > NanoBSD I used to use). > > Loading /boot/kernel/i915kms.ko > > after manually having loaded /boot/kernel/kernel (and not booted yet) doesn't > change > anything either. > > Booting off and installing Linux (Ubuntu, Mint so far, most revent verions I > can get my > hands on) is no problem. The console works fine from the beginning and so the > graphics. > > Is there a chance to get a FreeBSD booting the easy way? > > The provided boot images do not contain any of the > graphics/drm-stable|next|legacy-kmod > stuff, I tried to load i915kms.ko off from /boot/modules/ (were those modules > from the > ports are supposed to reside) but no chance. > > Before starting investigating this issue further I'd like to ask wether there > is a > general support provided or is that type of notebook dead matter for FreeBSD > of the > modern kind? > > Thanks in advance, > > oh > > p.s. please CC me, I'm not subscribing all lists. > > - -- > O. Hartmann > -BEGIN PGP SIGNATURE- > > iLUEARMKAB0WIQQZVZMzAtwC2T/86TrS528fyFhYlAUCW/5lKgAKCRDS528fyFhY > lMhRAf4yv4MqmHYVZIKo+TE1VACuHpXSv8ad4JzVKMG/S9uGcLLDfLgSM9699FDP > /QhIMCCHJ1hGAtXACdwGCsyZ5LmiAf93JHFU0W+GJWdXJI+sRcWvEZrzQlb5Czhf > vaM5QZ+3n0ermbe5/Ibvo/yzhL5YyonG7/lEqvnf7GAA+snv+Dvg > =XD7b > -END PGP SIGNATURE- Could you post a picture somewhere ? I have a laptop which have efifb problem, what I need to do is (at loader prompt) : gop set 4 (to switch to a different mode) gop set 0 (switch to the correct mode) You can gop list (iirc) to checks the available mode. The problem is that we are mixing serial and gop in loader.efi and when you set one mode in serial (or for SIMPLE_TEXT_PROTOCOL) is can mess the graphical mode. -- Emmanuel Vadot ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: BPi-M3 under stable/11 details: boots but with only 4 cores used for SMP --of 8 cores present. . .
Ah yes, well same thing, we don't support cluster :) On Mon, 24 Oct 2016 15:42:40 -0700 Mark Millard wrote: > On 2016-Oct-24, at 2:00 PM, Emmanuel Vadot wrote: > > > > Hello Mark, > > > > The A83T is BIG/Little IIRC and we don't support that. That's why you > > only see 4 cores on the 8. > > That is not what I get from reading the A83T documentation. All the CPU > references are to the same type of CPU for each of the 8. But there is a > NUMA-ish pair of "clusters" of "CPU"s without a common L2-cache or other > cache across the clusters. > > http://linux-sunxi.org/A83T says . . . > > > This SoC does NOT comply with the ARM big.LITTLE architecture, therefore it > > is in no way energy efficent and gets very hot. > > > > CPU: > > ? ARM Cortex-A7 Octa-Core > > > A83T_Datasheet_v1.3_20150510.pdf says: > > > Main features of A83T include: > > ? CPU architecture: Based on an octa-core CortexTM-A7 CPU architecture, . . > > .. > > > > 2.1. CPU Architecture > > > > ? ARMv7 ISA standard instruction set plus Thumb-2 and Jazeller RCT > > > > ? NEON with SIMD and VFPv4 > > > > ? Support LPAE > > > > ? 32KB I-cache and 32KB D-cache per CPU > > > > ? 1MB L2-cache > > The "A883T Block Diagram (Figure 3-1 page labeled 12) simply says "A7 x 8". > > A83T_User_Manual_v1.5.1_20150513.pdf has some more detailed diagrams and more > information. . . > > There are two CPU Clusters (0 and 1). It is more of a NUMA context due to > caching within each cluster that is not across the clusters. This document's > wording is more explicit, mentioning clusters for the L2-cache level (page > labeled 51) in even its basic description of caches in the A83T archtiecture: > > > 2.1.1. CPU Architecture > > > > The A83T platform is based on octa-core CortexTM-A7 CPU architecture. > > > > ? ? ARMv7 ISA standard instruction set plus Thumb-2 and Jazeller RCT > > > > ? ? NEON with SIMD and VFPv4 support > > > > ? ? Support LPAE > > > > ? ? 32KB I-cache and 32KB D-cache per CPU > > > > ? ? 1MB L2-cache(512KB per Cluster) > > > See this document's Figure 3-1 "System Bus Tree" (on the page labeled 66). > > From what I read one can control clock frequencies per cluster but it is > allowed to have them both the same all the time that frequencies are stable > for a while. > > And I'll stop with the details that I see with that. > > There may be some folks around with knowledge of more detail that might well > be able to say "but it is not NUMA like for these details . . .". By no mean > have I analyzed all the consequences of all the details. > > But I find no evidence of BIG/Little use of different classes of cores at > necessarily different cock rates and the like. As much as I've looked at > looks more symmetric than that. > > > > > cpulist0 shows 8 core because every core in is the dtb. > > > > On Mon, 24 Oct 2016 09:04:35 -0700 > > Mark Millard wrote: > > > >> The is for a Banana Pi M3 V1.2 board with the barrel power connector. The > >> 5V 2A supply that I had to fit the barrel hole can not power the board > >> sufficiently to boot --even when no fan is being powered. In order to boot > >> with a fan I have both that and an official rpi3 power supply plugged in. > >> The rpi3 power supply will not power the GPIO fan connections but can boot > >> the board by itself (V5.1v and 2.5A but cell phone charger > >> cabling/connections). I've got a heat sink on the CPU as well. > >> > >>> root@bananapi-m3:~ # uname -apKU > >>> FreeBSD bananapi-m3 11.0-STABLE FreeBSD 11.0-STABLE #0 r307797M: Mon Oct > >>> 24 00:41:16 PDT 2016 > >>> markmi@FreeBSDx64:/usr/local/src/crochet/work/obj/arm.armv6/usr/src/sys/ALLWINNER > >>> arm armv6 1100505 1 > >>> 100505 > >> > >>> root@bananapi-m3:~ # freebsd-version -ku > >>> 11.0-STABLE > >>> 11.0-STABLE > >> > >> In the below note that "FreeBSD/SMP: Multiprocessor System Detected: 4 > >> CPUs" but cpulist0 shows cpu0 through cpu7. For now: So much for seeing > >> how buildworld/buildkernel would go using all 8 cores. > >> > >> (Note: the serial connection tends to drop some text sometimes. That may > >> have happened some for the below.) > >> > >
Re: BPi-M3 under stable/11 details: boots but with only 4 cores used for SMP --of 8 cores present. . .
gt; (probe0:umass-sim0:0:0:0): CAM status: CCB request completed with an error > > (probe0:umass-sim0:0:0:0): Error 5, Retries exhausted > > So far the probe0 messages stop after just a few like the above. > > Also it looks like the 8GB eMMC (mmc1 / mmcsd1) is likely not supported yet. > > I have not yet tried connecting an external usb drive. > > Some structure of what was done with the cores shows in the sysctl -a output: > cpu names 0-3 and 100-103. > > (Note: the serial connection tends to drop some text sometimes. That may have > happened some for the below.) > > > root@bananapi-m3:~ # sysctl -a | grep cpu > > kern.smp.cpus: 4 > > kern.smp.maxcpus: 4 > > kern.ccpu: 0 > > 0, 1, 2, 3 > >0, 1, 2, 3 > > kern.sched.cpusetsize: 4 > > kern.pin_pcpu_swi: 0 > > kern.vt.splash_cpu_duration: 10 > > kern.vt.splash_cpu_style: 2 > > kern.vt.splash_ncpu: 0 > > kern.vt.splash_cpu: 0 > > net.inet.tcp.per_cpu_timers: 0 > > debug.PMAP1changedcpu: 106 > > debug.cpufreq.verbose: 0 > > debug.cpufreq.lowest: 0 > > hw.ncpu: 4 > > dev.cpu.7.%parent: cpulist0 > > dev.cpu.7.%pnpinfo: name=cpu@103 compat=arm,cortex-a7 > > dev.cpu.7.%location: > > dev.cpu.7.%driver: cpu > > dev.cpu.7.%desc: Open Firmware CPU > > dev.cpu.6.%parent: cpulist0 > > dev.cpu.6.%pnpinfo: name=cpu@102 compat=arm,cortex-a7 > > dev.cpu.6.%location: > > dev.cpu.6.%driver: cpu > > dev.cpu.6.%desc: Open Firmware CPU > > dev.cpu.5.%parent: cpulist0 > > dev.cpu.5.%pnpinfo: name=cpu@101 compat=arm,cortex-a7 > > dev.cpu.5.%location: > > dev.cpu.5.%dri.5.%desc: Open Firmware CPU > > dev.cpu.4.%parent: cpulist0 > > dev.cpu.4.%pnpinfo: name=cpu@100 compat=arm,cortex-a7 > > dev.cpu.4.%location: > > dev.cpu.4.%driver: cpu > > dev.cpu.4.%desc: Open Firmware CPU > > dev.cpu.3.%parent: cpulist0 > > dev.cpu.3.%pnpinfo: name=cpu@3 compat=arm,cortex-a7 > > dev.cpu.3.%location: > > dev.cpu.3.%driver: cpu > > dev.cpu.3.%desc: Open Firmware CPU > > dev.cpu.2.%parent: cpulist0 > > dev.cpu.2.%pnpinfo: name=cpu@2 compat=arm,cortex-a7 > > dev.cpu.2.%location: > > dev.cpu.2.%driver: cpu > > dev.cpu.2.%desc: Open Firmware CPU > > dev.cpu.1.%parent: cpulist0 > > dev.cpu.1.%location: > > dev.cpu.1.%driver: cpu > > dev.cpu.1.%desc: Open Firmware CPU > > dev.cpu.0.%parent: cpulist0 > > dev.cpu.0.%pnpinfo: name=cpu@0 compat=arm,cortex-a7 > > dev.cpu.0.%location: > > dev.cpu.0.%driver: cpu > > dev.cpu.0.%desc: Open Firmware CPU > > dev.cpu.0.%parent: cpulist0 > > dev.cpulist.0.%parent: ofwbus0 > > dev.cpulist.0.%pnpinfo: name=cpus > > dev.cpulist.0.%location: > > dev.cpulist.0.%driver: cpulist > > dev.cpulist.0.%desc: Open Firmware CPU Group > > dev.cpulist.%parent: > > dev.aw_cpusclk.0.%parent: aw_ccu0 > > dev.aw_cpusclk.0.%pnpinfo: name=clk@01f0140inner,sun8i-a83t-cpus-clk > > dev.aw_cpusclk.0.%location: > > dev.aw_cpusclk.0.%driver: aw_cpusclk > > dev.aw_cpusclk.0.%desc: Allwinner CPUS Clock > > dev.aw_cpusclk.%parent: > > security.jail.param.cpuset.id: 0 > > > > === > Mark Millard > markmi at dsl-only.net > > ___ > freebsd-stable@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" -- Emmanuel Vadot ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 11.0-RELEASE tier level for arm64/aaarch64 and the officially built arm/armv6 variants?
l someone need to write > >> an "Arm Handbook" to be promoted? > > > > No. While useful, most of that already exists. > > Thanks for the response Warner, I always appreciate the chance to > learn more about FreeBSD. > Russ > > > Warner > > > >>> Interesting and good to know. Thanks. > >>> > >>> I might have guessed that going along with the u-boot issue would be the > >>> fanout in: > >>> > >>> 11.0/sys/arm/ . . . > >>> > >>> allwinner/a10/ > >>> allwinner/a20/ > >>> allwinner/a31/ > >>> allwinner/a83t/ > >>> allwinner/h3/ > >>> . . . > >>> broadcom/bcm2835/ > >>> . . . > >>> > >>> (Full list not shown.) > >>> > >>> I was thinking that this might make the tier level specific to the status > >>> of each such directory's content so that it was the combination of that > >>> and the sysutils/u-boot-*/ status that made the difference for assigning > >>> the level. I'd guess that lack of a usable directory in either place > >>> would not be tier 2 even. Similarly until the required sys/arm/*/* and > >>> sysutils/u-boot-*/ directory-tree content have reached a sufficiently > >>> complete status. > >>> > >>> I'd expect that there will always be a lag for what exists in the world > >>> vs. what has these materials worked out in FreeBSD. > >>> > >>> > >>>>> Also from https://www.freebsd.org/platforms/arm.html : > >>>>> > >>>>>> Initial support for 64-bit ARM is complete. 64-bit ARM platforms > >>>>>> follow a set of standard conventions, and a single FreeBSD build will > >>>>>> work on hardware from multiple vendors. As a result, FreeBSD will > >>>>>> provide official releases for FreeBSD/arm64 and packages will be > >>>>>> available. FreeBSD/arm64 is on the path to becoming a Tier 1 > >>>>>> architecture. > >>>>> > >>>>> Will 11.0-RELEASE make arm64/aarch64 Tier 1? > >>>>> > >>>>> [I will note that, while there are no official builds for the Pine64 > >>>>> family (A64 based) that are under the Allwinner arm activity, the SOC's > >>>>> involved are Cortex-A53 64-bit arm based. They likely do not fit in the > >>>>> "standard conventions" or arm64/aarch64 would be where they would have > >>>>> been supported. Some rewording might be appropriate for the above quote > >>>>> as well.] > >>>> > >>>> No. aarch64 isn't Tier 1 yet. There's many small bits that are > >>>> missing. It is quite solidly Tier 2, but we don't have a linker, we > >>>> don't have widespread hardware availability, we don't have production > >>>> experience with the platform. Most things work, but there's still some > >>>> gotchas. There's still the 'u-boot' problem with many arm64 systems > >>>> because for systems that use u-boot to bootstrap UEFI, you need a > >>>> different image for each board (some closely related board families > >>>> can get by with one to be pedantic). All these issues are still > >>>> significant barriers to production use. It's not been officially > >>>> promoted yet and I don't think the time is quite right yet. > >>> > >>> Intersting as well. I'd guess that conceptually this probably would apply > >>> to both: > >>> > >>> sys/arm/allwinner/a64/ and sysutils/u-boot/pine64/ > >>> (presuming, contrary to fact, that 11.0 had sys/arm/allwinner/a64/ ) > >>> > >>> and. . . > >>> > >>> sys/arm64/cavium/ > >>> sys/arm64/cloudabi64/ > >>> > >>> So just sys/arm/ vs. sys/arm64/ for an aarch64 would not really make a > >>> difference yet for tier level. > >>> > >>>> Warner > >>> > >>> Thanks again for the notes. > >>> > >>> === > >>> Mark Millard > >>> markmi at dsl-only.net > >>> > >>> ___ > >>> freebsd-...@freebsd.org mailing list > >>> https://lists.freebsd.org/mailman/listinfo/freebsd-arm > >>> To unsubscribe, send any mail to "freebsd-arm-unsubscr...@freebsd.org" > ___ > freebsd-stable@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" -- Emmanuel Vadot ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
