HN user
He mentioned in spots GCC 9.1 was used, albeit still missing parameters. This is odd to test considering how old it is and how the .1 release is not the last bugfix release for the 9 series.
Edit: I see the 9.1 reference is itself referencing related work, and not a source for his assembly outputs.
There are a number of RTOS’s out there now, both proprietary (e.g. VxWorks) and OSS (Zephyr) that support A-series chips with an MMU, and can operate with a single (kernel) context. They still provide bounded latencies compared to full-fat OS’s, but don’t have as much determinism as microcontrollers without page tables and caches. The cores themselves (maybe not the A35?) don’t generally work without the MMU enabled, because most ARM cores also disable the cache if the MMU is off.
That philosophy extends to the kernel only - there are multiple other dependencies for running programs that may not have a stable API/ABI, or the same compatibility approach. Shared libraries like glibc may be updated, graphical interfaces may differ, search paths may not be uniform, etc. and these can all break a program.
I’m going to bet the opposite - no school is so flush with cash they can pay a 3x premium per laptop for students thet offers the same functionality. This seems like a misguided approach to obtain mass market appeal.
How new is this project? It was really surprising to see something published in 2022 that still attempts to offer Python2 support, and all the baggage that will carry.
1. There’s extra danger every time nuclear material is launched on a satellite, be it for a thermal generator like on the Curiosity rover, or some failed tests the USA did on Pacific islands in the 60s as part of Operation Fishbowl that resulted in a large amount of waste spread downwind. 2. No satellites can actually reach the sun - to do so, anything launched from Eart would need to cancel the forward velocity to force its orbit to “fall” into the Sun. This is such a high number that it’d be cost prohibitive for the amount of fuel and size of launch vehicle required.
Ive read multiple reports that the Ubuntu distrivution is significantly slower than the Raspian bundle. I dont know the root cause, but you could check out the stock image for a comparison yourself
Purely analog circuits, including those with digital functions as an ancillary feature, are never on the latest process node. Analog functions don’t scale down well, high drive currents or voltage support require minimum feature sizes. The notable increase per node in terms of frequency support would be wasted even on parts operating up to the gigahertz range. Even the most aggressive analog circuits, like current RF-CMOS designs, are only released when the node is a few generations old. The process control required to get them functional within usable tolerances for analog circuits like current mirrors and differential pairs is greater than what digital designs demand
Not anymore for all practical purposes, but it once did for the very old 10Base-2 standard for Ethernet over coaxial cable. This is practically why the old MII Ethernet PHY interface protocol had the collision-sense lines to indicate to the MAC to stop sending data if it detects incoming data, in attempts to minimize collisions.
Can you list which ARM cores you know of that include an IOMMU? I’m personally unaware of any, as that is typically bundled as a separate IP package that must be integrated separately into the system, and is usually customized based on the number of supported masters that require virtualization.
E.g. the Xilinx ZynqMP includes the same Cortex-A53 complex the Raspberry Pi 3 has. They also included CCI-400 coherent interconnect switch to it, and also included the SMMU-500 IOMMU that partially interfaces with the A53 interconnect, but is effectively independently programmed and also controls access to DDR3/4 from the SATA, Displayport and PCIe controllers.
Per the original topic, have they released a full datasheet/reference manual for the Pi 4 SoC yet? I’ve yet to see one other than a VERY high-level overview of it’s new pieces.
No GPS sat's are in GEO - they're all in MEO, which is about half as high, though comparative in terms of dV requirement.
Two things:
1. A GPS satellite is in a very high orbit compared to LEO, and so all stages were requested to burn to completion, to ensure the satellite has enough margin to reach that orbit.
2. The second stage ends at a ~800 km orbit, while the satellite itself needs to increase this to ~12,000 km (I'm rounding these numbers). The sat has to carry enough on-board propellant to raise it's orbit that much which necessarily increases it's wet-weight due to the rocket equation.
Those (Anandtech) benchmarks were performed on Windows. All threadripper benchmarks on Linux show that it is nowhere near as awful a performer as on Windows and most compute workloads do scale okay. Seen multiple ideas thrown around like Windows not being NUMA aware with this processor or just plain bad core scheduling