AMD adopting "FRED", rip IDT.
PDF:
https://docs.amd.com/api/khub/documents/d9fyzSaZGtRoheP5zIbbrg/content
#amd64
🤸 updated #docker images for #duckdb v1.4.3
- based on Alpine: https://hub.docker.com/r/codieplusplus/duckdb
- based on Debian: https://hub.docker.com/r/codieplusplus/duckdb-debian
@deliri Either way, @bananapi illustrates the problem with (halfassed) #RaspberryPi competitiors:
- It's not enough to just spit out an SBC and some bootable ROM! The people want proper #documentation. And besides @raspberry_pi / #RaspberryPi, very few actually write those (i.e. @olimex )…
Cuz if people like #ChrisBarnatt struggle to do anything, why should anyone even more competent like @geerlingguy invest his precious time to make fundamental basics work?
- I mean as much as he jokes about having to compile the #LinuxKernel, I'm pretty shure $5 in hardware cost savings isn't going to get him up and fanboy things.
Personally, I think everytime he has to fiddle around that neck-deep, I consider this a fundamental failure by said SBC if not #ARM64 as #architecture, as in almost all cases this is something that just works on #amd64!
- Espechally since these are "consumer-facing" boards with "consumer-style interfaces" and advertised to consumers, not some obscure embedded/industrial SOM like a #Vortex86!
MAXCPUS on OpenBSD/amd64-current is now 255 https://undeadly.org/cgi?action=article;sid=20260115135856 #openbsd #amd64 #current #maxcpus #development #highperformance #multicore #libresoftware #freesofware
@mntmn oh cool.
- Send them my regards...
Given how #Framework has put me off with their sponsorships and how the continued #Enshittification of #ThinkPad|s (and me not stomaching the cost of a #3Dprinter for the #NUCbook) m, I do have the privilegue of my daily driver tools being not hard-locked to #amd64 and thus being able to switch architectures…
- Something that seems potentially necessary as #Intel and #AMD refuse to stop #enshittifying!
@Oleksii @robinsyl #ARM64 grows because #Intel and #AMD basically gave up delivering compareable computing power in the same thermal, electrical and price envelope.
- See Z3735F (2,2W), N3010 (3W) & x5-E8000 (4W) having no successors of equally low TDP or even lower in production! The closest ist the i3-N300 (7W) and N95 (15W) respectably.
Add to it the rise of #SBCs like #RaspberryPi that further kicked the cost down in terms of basic computing and the big #Linux #community that welcomes cheap #hardware and does it's best to put it to good use.
- See the #MNTreform by @mntmn, which embraces #ComputeModules and doesn't have any #amd64 #mainboard (or rather #SOM) option AFAIK...
It truly confirms @landley 's saying that #Innovation in Computing it actually trickling up and thus #tech gets moved from the #Desk to the #Rack to "the #Cloud"...
- I mean, in many #DevelopingCountries the #Desktop and #Laptops get skipped for very cheap #Smartphones and cheaper #Tablets to the point that regular #PC's ain't common outside of businesses and government offices...
Obviously, I wished for truly #OpenSource'd #RISCv to take the place but that's about 5-25 years lagging behind #ARM due to #patents in many key technologies like #PowerSaving...
- But we've to admit that on a global scale, #Flathub is a #RoundingError in terms of #SoftwareDistribution, because not every Desktop - Linux distro supports it, much less uses it per default!
@robinsyl I am convinced that #Valve is gonna try to seriously support #ARM & #Linux longterm because they don't want to depend upon #amd64 / #ix86 & #Windows for survival and profit.
- I'm shure the same engineers who cooked up the #SteamFrame work hard on supporting mainstream ARM devices like the #Pi500Plus, because the more platforms #Steam can serve a decent amount of their catalog the easier it is for them to make money.
And in the end that's what they care about...
- Tho I don't put my hopes up high re: any new devices and espechally not reasonable pricing, cuz the "#AIbubble" and the #PriceFixing tripol of #RAM [Chip] manufacturers are currently busy #scalping RAM & #Flash into unobtainable amounts.
https://www.youtube.com/watch?v=9hLiwNViMak
https://www.youtube.com/watch?v=9A-eeJP0J7c
When the #SteamMachine was announced everyone with a calculator could see this is ginna be a $/€ 749,-- #GabeCube because unlike any #GameConsole they explicitly refuse to go with the "Razer & Blades- Model" and sell the device at a loss.
- At the current prediction and RAM prices everyone not deranged expects this to be a $/€ 999,99 box if Valve preordered enough RAM to have an inventory cushion at launch.
And with the current price developments I'd not be surprised if sooner or later devices get stolen just to rip the RAM & SSD out of them and distribute them second hand like weed to a coffeeshop in Amsterdam.
@mrmasterkeyboard @hexaheximal In terms of architectures I'm mostly limited by time, hardware that I have access to and toolchain support.
If @musl / #musl (or rather the
musl-crossbinaries) and #toybox as well as #Linux and #Clang / #LLVM or #GCC support go and #boot is documented porting is relatively "easy"…_OS/1337OFC doesn't have much to it so compared to #AdelieLinux, it should be straightforward.
#OS1337 on #Xenon is quite low on the list but still not on the bottom because I have systems in my possession. Unlike "normal" #32bit #PowerPC systems.
- Mind you I have exactly 0 "#PowerSaving" or other energy optimizations in
_OS/1337(or even multithreading) support built-in, which on most modern systems results in dogshit performance below rated base clock because modern CPUs and Chipsets expect the OS to communicate with them and if it doesn't they gonna assume the OS is fubar and drop into failsafe modes. With some luck they may even prevent the CPU from frying itself and turn on the fan on their own.
I don't have much hands-on aside from mainstream #ix86 / #x86 / #amd64 Systems and #ARMv5r11 / #ARM64 SBCs.
Ассемблер для гоферов. Стек. Особенности amd64, arm64 и arm. Часть 3
В этой части мы научимся создавать и использовать локальные переменные на стеке в наших ассемблерных функциях, а также поговорим о различиях процессорных архитектур и о том, как их использовать в Go-ассемблере.
https://habr.com/ru/companies/ruvds/articles/979326/
#go #assembler #stack #стек #amd64 #arm64 #arm #ruvds_статьи
My journey to a #RealTimeLinux kernel for #AMD64 on Buildroot continues!
Many failed experiments with different kernel/RT patch combos (6.18, 6.12, 6.1), but learning a ton about patching & Buildroot quirks. Still stuck on enabling CONFIG_PREEMPT_RT, but feeling closer to the breakthrough!
My portable #BashLab is ready for more. 🤓
#EmbeddedLinux #Buildroot #RTOS #LinuxKernel #DIY #PortableLab
@beoz @marcel naja, soweit der Zug nicht in den frühen 90ern gebaut wurde und #amd64 unbezahlbar noch #64bit-#Unixtime ad #32bit-Systemen implementiert war betrachte ich das schon als Verletzung der #Berufsethik als #IT'ler.
Ronny Schäfer Stimme: "Die wissen doch wie lang so'n Zug runfährt, oder?"
Ассемблер для гоферов. Структура и макросы. Часть 2
В этой части (первая тут ) мы поговорим о структуре Go-программы с использованием ассемблера, о хитростях макросов. Будем писать дальше нашу ассемблерную функцию.
Ассемблер для гоферов. Часть 1
Вообще-то на Хабре уже были статьи про Go-ассемблер, но они перегружены мудрёными терминами, разной низкоуровневой спецификой и не дают ясного понимания когда и зачем нам помогут помочь ассемблерные функции. В этой статье я постараюсь дать больше сути, необходимый минимум, чтобы стало ясно, в каких случаях и зачем нам может помочь ассемблер в Го. Ну и с чем его едят.
Запуск x64 программ на ARM или почему вы не захотите этим заниматься
Вам нужно было хоть раз запускать x64 программы под Linux на ARM платфоме? Если да - это статья для вас. В ней я рассказываю про способы запуска программ с другой архитектуры на ARM. Также это статья для вас, если вы хотите на будущее знать способы, которые есть для запуска. Когда наступит эра ARM-ноутбуков и ПК вам это может очень даже пригодится.
https://habr.com/ru/articles/974608/
#arm #arm64 #amd #amd64 #i386 #запуск_x64_на_arm #эмуляция_x64 #игры_на_linux #fex #box64
@betelgeuse93 @itsfoss Okay, I've to admit this is very #EU-centric but there are lots of #refurbished #amd64-based, #fanless #ThinClients on the market.
- Not just on eNay but also directly at some big #refurbishers.
One can easily find a hp t520 or t620 with dualcore AMD GX-Series APUs, 4GB RAM and 16GB SSD for as little as €25 with power supply (excl. shipping)...
- They run box-standard #Linux distros and are fast enough to even be used for @tails_live / @tails / #Tails to browse the internet.
OFC as we all know from #LowSpecGamer the #UsedMarket in #DevelopingNations is completely fucked up which is why stuff like a GT210, 750 and 1030 will still sell there.
@f4grx meanwhile, I also have something for you and other gdb with qemu users ;)
Installation
Either check out the directory with AnonCVS…
cd
mkdir -p .etc
cd .etc
cvs -Rqd _anoncvs@anoncvs.mirbsd.org:/cvs co -PA -d gdb contrib/hosted/tg/gdb
… or download the individual files (all but .cvsignore) from CVSweb https://mbsd.evolvis.org/cvs.cgi/contrib/hosted/tg/gdb/ (user=pass public due to LLM scrapers) and put them into a new directory ~/.etc/gdb/.
If you don’t use qemu 5.2 (Debian bullseye) or one with compatible XML files, you’ll have to do extra work. See below the <hr /> at the end of the post for this and a compatibility table.
Then, symlink ~/.etc/gdb/.gdbinit to ~/.gdbinit or merge things into yours if you already have one.
Usage
Start qemu either as qemu-system-i386 -S -s … (to run a 32-bit VM, then you use the qemu32 command inside gdb) or qemu-system-x86_64 -S -s … (to run a 64-bit VM, then you use the qemu64 command inside gdb). The -S makes it wait for a gdb c command before even booting. This gives you ample time to attach both vncviewer (as qemu lost its builtin SDL GUI 🤬🤬🤬) and gdb.
Start gdb and issue the user-defined qemu32 or qemu64 command.
BIOS
For a classical BIOS system, you’ll be in 16-bit real mode at F000:FFF0 at the beginning, so if you want to debug there a bit, run the c16 command to switch over, do a b *0x7c00 to set a breakpoint on the MBR, c to run until there, i to inspect the registers, u or uu COUNT to disassemble some, t to step into and tt to step over (uses a temp breakpoint at the next address, so make sure the mode is correct). Once it enters protected mode, issue the c32 command, once it enters long mode (if any), issue the c64 command. I’ve tested this with a MirBSD/i386 ISO and a Grml/amd64 ISO.
EFI
For your EFI scenario, set a breakpoint on your multiboot entry point (I used b *0x00100074 having gotten the address from nm on your ELF file, if you have symbols you can do that) and run c. Once it breaks, run the c32 command. Same as above, you can then use i, u, uu COUNT, t, tt, … (there’s also an i32 command if you prefer gdb’s standard format, it’s cleaned up a little, the i16 one is inspired by DOS DEBUG.COM; for 64-bit mode, only i64 is available in gdb’s format but the other still work and show the truncated values, perhaps somewhat usefully, especially for #x32 / #amd64ilp32 or when running a 32-bit userspace program). You can use c32 and c64 to switch between the modes and even use c16 if your bootloader exits 32-bit mode (e.g. to run BIOS calls before entering long mode), though that will be exceedingly rare in an EFI setup. I’ve tested that with the ISO you gave me.
others
The d and r2p commands are less useful to you, as they work with 16:16 segmented far pointers. The other commands (printqs5static, printqs5dynamic and the offsetof macro) are perhaps more useful when debugging host applications.
I’ve tried to make this not break when gdb is used for nōn-x86 targets, though the usability is limited there, of course.
HTH & HAND!
tdesc files
Compatibility matrix
As far as I can tell, the earliest version in which the tdesc XML files work is qemu 4.0.0 so you can exclude this for anything older.
There is, at the time of this writing, only one more commit (75ac231c67cdb13f0609943fab5499963858b587) on these files, which begun to be included with qemu 7.2.0 so anything between 4.0.0 and 7.1.x uses the same format, the one of the files contained in the repo.
Though, from the commit message, it looks like the diff…
- <flags id="i386_efer" size="8">
+ <flags id="i386_efer" size="4">
… might be needed anyway, and it affects qemu-system-i386 only, too. Do this too if you get the Remote 'g' packet reply message and it differs by four bytes only.
Updating the tdesc files
If you find that your qemu’s files have sufficiently changed from the version I committed, you need to do the following:
- replace the downloaded/checked-out files
i386-32bit.xmlandi386-64bit.xmlwith these from thegdb-xml/directory of the source tarball of your qemu version - it is a good tone to add a matching
<!-- obtained from qemu VERSION -->comment into line 2 like I did, so future you will be less surprised if he has to work with this more - run the
i386-64bit32.shscript to regenerate thei386-64bit32.xmlfile from the newi386-64bit.xmlfile (do somediffing to verify the changes are still good in your version)
Then you’re all set and can test things.
#x86 #i8086 #i386 #amd64 #gdb #qemu #debugging #asm #assembly
@aeva Currently the "dogshit wall" is #i486SX because #Linux dropped support for #i386 with Versions 3.4.99 & 3.6.9 respectably, tho most people would say anything below #amd64 w/ #SSE2 (or #i686) is out of #mainstream support already, with #RHEL6 being EoL'd & #Debian being the last major distros offering #32bit support.
Client Info
Server: https://mastodon.social
Version: 2025.07
Repository: https://github.com/cyevgeniy/lmst