anybody look at the X5 firmware yet?

just went live on bitmain site today

it's a bit weird, cgminer on the host controller, but it looks like it talks to another controller instead of addressing the chips directly

the firmware for that secondary controller has some binary that appears to have a packed copy of xmrig inside of it, haven't tried to extract it yet tho

can you post a link for it, looked around but couldn't find the downloads part

XMR Cryptonight -> ANTMINER X5

the host controller firmware is pretty boring, typical bitmain setup, runs their cgminer fork called "godminer"

thank you

there are some zip files in /usr/bin that hold firmware for another device(?) though, that's where the xmrig mentions are

gen_mango_xmrig tries to do some direct writes to /dev/mem so I can't just pull the image out with emulating it :(

give somebody 20 mins with a disassembler and I'm sure they'll get more info though

the only thing of note I have seen so far is copious mentions of RVN, some memory self test stuff, DAG gen etc in godminer,  so it looks like they have a ProgPoW ASIC sitting around

but that's off topic here :^)

i think the main controller is an ARM64

>Image: Linux kernel ARM64 boot executable Image, little-endian, 4K pages

>busybox: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-armhf.so.3, for GNU/Linux 3.2.0, BuildID[sha1]=8a195c14dab122ded000d1a906f3b1cdf5b9c334, stripped

and this is the busybox that /linuxrc etc. links to

>init: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-armhf.so.3, for GNU/Linux 3.2.0, BuildID[sha1]=6fd94c88462017a5c47b77084f40ac7fe2316265, stripped

init too

0.0g.gg/?1e184b3eb5841337#FhgTEDDqxQdFsaaq9UgL9xY6pC6Vwa89MRfDcKP9FLp here is the xmrig config.json that was left in /etc/ funny that address was at least used on supportxmr a year ago

0.0g.gg/?8eeea717379690da#7qi2caWvR…jxNn9MH3jRiKfpczZfLBEvKshFgLp3q5o6J there's this file called levels.json for some kind of core number and frequency definition. i'm not familiar with the part numbers, so it may be mapping to other coin miners

those don't look like bitmain part numbers, odd

is that config.json from the main image or the image inside the zip file?

I haven't disassembled anything yet but from first glance it looks like they still run cgminer/godminer on host controller and talk to their modified xmrig inside the 2nd level controller (which is also aarch64)

modified xmrig does some odd poking in /dev/mem though so I am unsure what it is actually doing without disassembly

on their more traditional miners they often do that to talk to FPGA in the controller SoC, but that seems unlikely here

didn't see any "image in zip" yet. i'll fire up the rev.eng. VM after a reboot

its in /usr/bin/**

*.zip

I forget the filename. not at my workstation rn

I checked the /etc first, slowly going to that side. so my finding is in main image

both zip files in /usr/bin have more full firmware images, compiled slightly differently, userland bins are aarch64

maybe they are emulating aarch64 on riscv :P

that 2nd level image init.d will run gen_mango_xmrig twice, seems to unpack another binary in each case. seems they did some obfuscation

maybe they have some custom SoC with am aarch64 core and a load of riscv cores just tacked on the side as coprocessors

sounds unnecessarily complicated but bitmain has a habit of doing that

then they are memory mapped for "remote control"

yep. that was my immediate theory

we do that in FPGAs all the time

but like I said I have no disassembly tools on hand, personal machine is kaput right now :(

can't run IDA on a phone yet

not the best practice when you already have the manufacturing uphand but possible none the less

I will check monerologs later to see if you found anything interesting. Happy hunting:))

sure thing, see ya

>bin/busybox: ELF 64-bit LSB executable, ARM aarch64, version 1 (SYSV), dynamically linked, interpreter /lib/ld-uClibc.so.0, stripped

ok this is interesting, the "image inside zip" at the /usr/bin/update_total.zip has this, linked to uClibc, and it's aarch64. aarch64 with no mmu ?

that gen_mango_xmrig binary seems to be trying to do some SPI writing, so maybe the slave devices are booting from spiflash like a regular router mobo. i suspect those memmaps are related to that

Interesting

like eureka said, it's generating mango_xmrig, calling that, deleting that, then calling gen_mango_xmrig again with the parameter "2" this time, as in second stage, then it runs mango_xmrig again

Only ARM code spotted so far?

yeap-

>gen_mango_xmrig: ELF 64-bit LSB executable, ARM aarch64, version 1 (SYSV), statically linked, for GNU/Linux 3.7.0, BuildID[sha1]=2941dc4d421b82a10496d7c436f0c55ead2f1677, stripped

maybe it unpacks risc-v code and uploads it via some weird custom interface?

yeah if that's the case i'm trying to catch the unpack routine. that generates mango_xmrig and whatever mango_xmrig is doing.

hmm, maybe mango is risc-v chip's codename?

Don't say it's mango pi :D

D1, C906 Core, RISC-V core up to 1GHz

xuantie c906 there

ping hyc - read above ^^^

yeah thought of that but didn't check yet

specs are not good enough for RandomX: mangopi.org/mqpro

V1.0, 2022.01.05, first release

hmm, around the same time I spotted the nonce pattern

maybe Bitmain ordered some custom mango boards with more memory

or even sponsored this whole mango pi, so they could sell their own boards later

and this board is very small (physically) - probably one of Bitmain's requirements :D

yeah

what's with generating those 2 binaries and doing bunch of spi writes tho

xuantie c910 is still more likely candidate. c906 is too weak and it's just a single core

that may be the cheap "controller" they want

*would want

in that mini ram fs there's spi-config and spi-pipe as well, feels like this mini distro need the spi communication one way or the other

that mini image is PRETTY_NAME="Buildroot 2019.08.2"

>Unix path: /home/felix/work/mining_machine/bootloader-arm64/u-boot/board/sophgo/mango/board.c

caught in the mini image this and many other paths

ooo i think found something spicy

some strings that may be helpful "RISC-V only mode" "Disable RISC-V subsystem" "A53 master mode" -> as in arm cortex-a53?

as in : "MangoPi Module MCore-H616 Core Board 4-core A53" ??

hackster.imgix.net/uploads/attachments/1488227/image_XFSvPJL5Gd.png it's also available like this as a SoM

I think our suspicion about riscv piggybacking on arm64 as controller is correct

so did they make their own boards with arm64 main cpu and risc-v co-processors?

found the cpu, sophon.ai/product/introduce/sg2042.html

figures it's being sold in sophon wing too, they did the same in bytom miners

64 cores, 64 MB cache?

reused shitty TPU they couldn't sell for AI purposes, came up with a PoW that could be done on TPU chips.

are you sure they use this cpu?

it's the same model number in cgminer bin, and the file path mentions sophgo

then they can use 32 cores for AES, and 32 cores for RandomX :D

so odds are very good

so they can have RandomX implementation that uses 2 cores to calculate each hash

this could be a very cool platform for non-hashing usage tbh

when jailbreak :D

if it really does have full MMU and everything

If I had $2k I would have bought a unit for teardown:(

bitmain site sold out in about 6 minutes though. typical

SG2042 has Xuantie C910 cores

so no hardware AES

so it makes sense to use 1 core for AES, and 1 core for RandomX

adding AES to the main loop will brick it

or at least half the hashrate

should verify that they did not add AES first

because they can't send data back and forth between cores quickly enough

it isn't impossible they added AES extensions, I didn't see any evidence of either possibility yet

it's only possible to find it out when you extract risc-v binaries and disassemble them

then you can just look for risc-v aes instructions

yep, I have no tooling available to unpack that mango bin yet sadly

wasted enough time unpacking stuff over ssh on my phone

good call on c910 though. I think you are correct

64 MB cache means they can only use 32 cores for main RandomX loop, but they can use 2 cores per hash when doing AES loop

AES loop is up to 4x parallelizable

timing of the sg2042 launch seems closely related here

I don't think Xuantie C910 has AES support, I can't find anything about it

only a few weeks ago

wait, it says C920?

no I don't think the stock core does either, but Bitmain is well capable of adding support on their own

They're all RV64GCV - and this one doesn't have cryptography instructions

Bitmain can of course add it

hash/watt efficiency suggests they do have hardware AES, and they also probably reduced core count to 32 (or increased cache size) to not waste energy

it's possible they just reused the same basic design as sg2042

248 Days Ago: 3,411,522

Total Hashes 35Valid / 25

Invalid Shares 0.00000910XMR pending

they didn't do much mining with it, barely enough to test it worked

If they have hardware AES, then RandomX AES tweak will only slow it down a little - depending on how fast their CPU cache is (AES rounds can take more clock cycles than waiting for data from the cache)

this would be 2nd or 3rd time they used a design from their sophon branch for mining purposes so I wouldn't be surprised at all

don't bitmain still run their own monero pool

or in antpool?

try looking up addr there

No, they use supportxmr and nanopool

and hashvault

found it on hashvault

Total Paid 18.2578

no workers lol

must be newly reopened

first payment on January 13th, 2023

if there is anything related to solar panels in the firmware, check for a custom 80% xmrig donation fee/address

Last Share

15 days ago

OK, I'm going to sleep now, hope you can make some perf estimates based on c910/c920 specs scaled to the sg2042

and happy hunting for more details, this is the first new mining hardware that I've found exciting in a few years now

This address was active on hashvault at least since January 12th, 2023 (first block found)

one last thing, codename for sg2042 is mango

I think evidence points pretty well

So it's sg2042. The only question is if it's a stock sg2042, or Bitmain version with AES and the proper cache/core ratio.

if anybody here manages to obtain an X5, please get us access to poke at it :))

I would not be surprised if it was stock though, bitmain already has two other miners using unmodified stock sophon parts

B3/B7

but who knows, maybe X5 is custom. if late 2021 start date for that nonce band is truly the X5, maybe it uses an earlier version of sg2042 design with different cache/core ratio

sg2042 seems only announced publicly around the start of this year

Bitmain of course had access to early sg2042 engineering samples, because Sophon is their subsidiary.

which means they can use a version with hardware AES

and for example 32 cores, 64 MB cache

nonce bands started around Christmas 2021, the earliest confirmed time the XMR address from firmware was active, is January 12th, 2023

So there's a gap of ~1 year that's not confirmed yet

elucidator so many mangos :D github.com/sophgo/linux-riscv/tree/…2042-dev/arch/riscv/boot/dts/sophgo

i actually saw a specific device tree file name but couldn't find any reference online

hoping it would show the interconnection enable lines

mango_r_bcx22601_v0.0.dtb this

mango_fpga.dtb, mango_evb_v0.0.dtb, mango_r_evb_v0.0.dtb, mango_r_bcx22601_v0.0.dtb

there are references to all these

Now I'm beginning to understand their logic regarding ROI. Take something they already had (SG2042 prototype), tweak it a little for RandomX, slap a bunch of them in a case with two 140mm fans, and you're done :D They didn't spend a lot of extra money on this.

So they have 10 SG2042 boards there, each running 52 threads. Maybe they even used chips that didn't have all 64 cores working. I always wondered why they run 52 threads

0.0g.gg/?e1dcb73313040b28#4sEwH7TL7…gGxjzfmN9sB5yhfmpYfZR3uMGkJn9b2jcY3 first dtb i decoded

0.0g.gg/?adae82177e5385fc#FRjpTLNku…gbceKowFevQ1g59SByGqjnr6UZk158ZG76Y second dtb

nice

this sg2042 is a monster CPU: "Dual vector pipelines on that C910 too. Each, as I understand it, with a 256 bit ALU. And pipelined for 1 vector instruction per cycle throughput. C906 has a single vector pipeline, 128 bit ALU, 3 cycles per instruction (at LMUL=1). So that is 16 single precision FMAs (two FLOPS) per core per cycle. Times 2 GHz, times

64, equals 2 teraflops."

2 TFLops

That's AMD EPYC level

EPYC Rome (Zen2) has up to 2 TFlops, EPYC Milan (Zen3) has up to 3.8 TFlops

although they do it with double precision, which is more impressive

dtb2 repeats itself again, here is the dtb3 0.0g.gg/?fba4f0e4716c9cc2#5kNQXq9mm…w5qZC9JNBzmsenXajn4Py5xaejRdBcNLUEQ which is very similar to dtb2

compatible = "sophgo,mango-cdns-pcie";

case closed

0.0g.gg/?0973ea2e6b011b1b#GBdtjRU39…ifpmaM8Ga1ewpgPyxeSJVGiZQJxAjfv2Pfw and the last one, again very similar

i'm seeing another 5 set with exact same sizes, assuming they are repeating like the second repeats in the image

Linux version 5.4.219-mango-g4d7f47813614-dirty (felix@felix-System-Product-Name) (gcc version 6.3.1 20170404 (Linaro GCC 6.3-2017.05)) #27 SMP Sun Jun 25 19:12:55 CST 2023

there's a line in aarch64 kernel image saying "failed to get riscv reset control"

Interesting article arxiv.org/pdf/2309.00381.pdf

Each C920 core contains 64KB of L1 instruction (I) and data (D)

cache, 1MB of L2 cache which is shared between the cluster of four

cores, and 64MB of L3 system cache which is shared by all cores in

the package. The SG2042 also provides four DDR4-3200 memory

controllers, and 32 lanes of PCI-E Gen4

C920 = C910 + vector FPU

Which is what they use in X5

quad-channel DDR4 means they can easily have up to 40 kh/s per board, and they have 10 boards in X5. So they run 21.2 kh/s per board - totally possible with quad channel DDR4, and they don't even need good timings for it

TDP 120W

So 10 boards = 1200W + memory + fans = 1350W

64 RISC-V cpu cores which implements IMAFDC

again no mention of cryptography extensions (no AES)

I still think they run 32 cores for RandomX and then switch to 2 cores per hash when they need to do AES hashing

its scary how much we can reverse engineer the hardware of something we've never had our hands on or even seen pictures of :D

looking at the xmrig.conf they've disabled hw-aes so it looks likely thats what they're doing.

This xmrig must be heavily modified in any case, so I wouldn't trust config values

sech1: you gonna LOVE this

Because they even have "cpu enabled -> false" there :D

found the device trees with riscv configs, they call it rxu, randomX unit i guess ?

nice

so how many cores in this rxu?

one sec, lemme upload all 5 extra device trees so i can look in detail as well as you guys

i'm seeing 32 rxu in one of them

32 rxu, 64 cores = 2 cores to calculate single hash

if AES is software, it makes sense to use 2 cores for it

then our RandomX AES tweak will really nerf it

It double the amount of AES per hash, and they won't be able to use 2 cores for AES in the main loop

protectedtext.com/antminerx5?antminerx5 alright this should be more convenient, each file in a tab

rxu_dataset_mem

ohhh, juicy

when i compare, there are minor differences between device trees like only one having the fan control stuff like they offloaded that to only one of the units

looks like 5x boards with each 32 "rxu"

they have different reset addresses etc. which is to be expected.

sech sg2042mcu on dtb3

interesting, one of them has emmc on board

They should have 10 boards

Maybe grouped 2x5

maybe

so firmware gets uploaded 2 times

ohhh

because there are 10 stripes in the nonce pattern

that's why 2 stages ? gotta look further into that generator

i found and renamed some functions in IDA, pushed my changes to that public lumina server but dunno if anybody else here is using that

reset-names = "rxu\0riscv" finally some proper mention of riskv :D

*riscv

not sure if it can help, this is stock sg2042: lore.kernel.org/lkml/CAHAQgRDtQDx-D…NM9rXu43dWCw0ehXPA⊙mgc/T

"Sophon SG2042 64x 2.0 GHz OoO cores similar to Arm A72, each core with a 256 bit vector unit, 64K L1 cache, 1M L2 (shared per 4 cores), 4M L3 local to a cluster of 4 cores, with the other 15x 4 MB L3 accessible via NoC at ~half the local bandwidth."

Ohh, local L3 slice is very nice for RandomX

it means they have low latency when accessing scratchpad

EVEN if they have hardware AES in their version, this low L3 latency means they don't have this huge idle wait in the main loop, so new AES instructions will slow it down anyway

i ran their "update_app" binary through qemu but doesn't show anything useful ofc qu.ax/Afge.png

RandomX dataset again

rxu_dataset_mem0, rxu_dataset_mem1

dataset_memory_init

hmm, they have 2 datasets

so it's probably 5 boards, with 2 CPUs on each

so 2 NUMA nodes, 2 datasets

These boards look more and more like Dual EPYC servers :D

So, to summarize: they have a small arm controller board, 5 child boards with: a secondary arm controller cpu, 2 SG2042 64-core CPUs, 8 DDR4 sticks (quad channel for each CPU)

Although they can probably get away with only 2 DDR4 sticks per CPU if they have good timings

It's 100% not an ASIC

btw, based on the price of components, the real cost should be in 5 figures

which explains why it sould out so quickly

if you jailbreak it, it's a compute monster

wonder how much they ROI-ed

how fucked is your business model if you have to ROI your hardware before selling?

(sorry for unrelated question tho)

better than "cloud mining" services :D

lol fair enough :P

They didn't ROI it, it's too expensive. 10xSG2042 CPUs alone cost more than $10k

40 DDR4 sticks are not free too :D

Bitmain can make more X5 units, but they will lose money if they try to ROI by mining, and they can't sell them at only $3k

So they probably won't make any more

tomorrow's headlines: main monero miner dev recommended antminer x5 saying it's priceless

lol

sech1, yeah what I ment was that they need to mine on them for some time and then sell them just to get ROI back ... but maybe not even as you said lol

that's kinda sad

I suspect they just used SG2042 engineering samples for X5

early engineering samples

So maybe when they make SG2042's successor, we'll get another wave of RandomX "ASICs" :D

which are not really ASICs, it's custom boards with CPUs on them

And again it will be a small batch with not so great power efficiency (especially after RandomX tweaks)

I just don't see how they can mass produce them and sell than at less than 30% of what it costed :D

they must have been bored and maybe were like "no randomx asics? challenge accepted"

but then the whole thing was a ded end

and they figured better sell the bricks since we're not getting ROI from mining

also probably they got cheaper parts

looks a single one might have made it to ebay

more allegedly available at aliexpress

Note: This is the pre-sale price, and the actual price may fluctuate in real time. Please contact us before placing an order!!!!!

so no point asking them to "pop it open and send me a pic of the internals please"

It just looks like 5 server dual cpu boards inside

Something like 1U EPYC servers, just smaller

maybe some of the Aliexpress selllers? one says has 2 left, one says has 50(!?) available - aliexpress.com/w/wholesale-bitmain-…ntminer+X5&spm=a2g0o.home.1000002.0

well cramming about 40 Lichee 4A compute modules into carrier boards into an off the shelf case is expensive as heck, while a set of 'off the shelf' dual cpu boards and either some epycs or chinese knockoff branded equivalent would be cheaper and easier I'd imagine... however the risc-v side of things confuses me... unless they're using a risc-v SBC as the controller

the hashrate is the same as 10x 7950x's, but that'd cost a metric shit-tonne more to build

risc-v because SG2042 is risc-v

and they use it for other stuff

so yes, they could slap 5 dual EPYC boards and get the same hashrates and power usage

but they can't get EPYCs for cheap, but they can get SG2042 because it's their own chip

wait, no. They only need 2 dual EPYC boards

i figured out where the aarch64 bit is coming from

they have recently started using another sophon/cvitek chip for their control boards instead of a zynq

cv1835

s19xp uses it as well apparently

so it doesn't really look like they have any aarch64 control cpu on die, that might've been a red herring :D

but the binaries in the firmware are all aarch64

risc-v code is generated on the fly and then sent to the sg2042

sent how though?

via memory mapping, and pci-e commands

kind of like a gpu

sg2042 work like co-processors there

ah that makes sense

are they loading job work onto sg2042 only? or is each sg2042 running a rx jit

sorry, i meant those together

how much is the cv1835 controller responsible for there

I think sg2042 runs jit too. Maybe even the whole XMRig compiled for risc-v

controller is only responsible for booting sg2042 and sending jobs to it

did anybody get in with IDA/ghidra/etc yet and start looking at that gen_mango_xmrig ?

Oh right. It must be risc-v compiled xmrig judging by the name

it would make sense, maybe they are generating hardcoded parameters and then sending the binary over to sg2042s like you said

explains the /dev/mem poking

i thought it was pretty weird they run cgminer on the host still

so they have xmrig sending nonces to cgminer to send to the pool? :D

cgminer controls all 5 boards and 10 cpus

and we get a nice 10-stripe pattern :D api.hashvault.pro/v3/monero/network…?hashrate=true&nonceColor=%23ff6600

2 sg2042 per board?

yes

because they initialize 2 datasets in the firmware

2 datasets = 1 dataset per CPU

makes sense, i wonder if they are running each sg2042 independently or if they are sharing the memory per board

which is typical for NUMA-enabled system with more than 1 CPU

sg2042 apparently does support multi-cpu operation

wow, i'm kicking myself for not getting one at $2.2k now

that is some serious compute power for that price

yeap

jailbreak will make it very nice buy

they must have barely ROI'd if at all

well ... i wonder how wide the pcie connection to the cv1835 is

and it's not an ASIC. If it gets jailbroken, you can run almost anything there

that is the bottleneck really

and controller probably only supports 100m ethernet like usual bitmain controllers

i/o might be bad, but compute power is huge

yep

each CPU is 2 TFlops, so 20 TFlops in total

that's getting into gpu territory

<p​olar9669:matrix.org> Who cares we are going to brick it anyways

20 TFlops is RTX 3070 level

is it really worth bricking them lol, if they are out of bitmain's hands and in the hands of end users?

but it's more flexible than a GPU

they aren't making any more of these at this price point

no way ...

They can't be bricked

because it's CPUs

"bricked" as in severe perf impact

AES tweak will of course make them slower, but I don't know how much slower

It depends on if they have stock SG2042 (no AES), or some custom SG2042

did anybody confirm your 2nd core aes theory yet?

If it's stock SG2042, then it's the most logical thing to do

Run AES in software, but use 2 cores for it

because it only has enough cache for 32 threads, but it has 64 cores

<p​olar9669:matrix.org> It’s about sending a message

looking at new sophon product list, they have invested heavily into non-mining chip designs in recent times, so i would not rule out these being slightly different than stock sg2042 until we can actually disassemble their xmrig fork

polar9669, bitmain lost a whole lot of money on this endeavour ...

i would argue monero folks won here

sure they got a fair portion of our nethash for some time but there's no way they made a respectable profit

Stock SG2042 would get nerfed to 60-70% of their current hashrate after the AES tweak

so 130-140 kh/s

<p​olar9669:matrix.org> They didn’t loose much, it’s their r&d cost for Rsic-v

that's still pretty good for a single unit

Custom SG2042 with AES would get 5-10% slowdown

<p​olar9669:matrix.org> They will make next gen soc

<p​olar9669:matrix.org> Which will work for tweaked pow

they make these SoC for domestic chinese use, mining is just an afterthought

and with current xmr emissions do you really think they will spend all that time on an updated model?

They can make it as a byproduct

Develop new chip -> use eng. samples in "ASICs"

<p​olar9669:matrix.org> Bitmain owns sophgo, so yes it’s a by product of their research

<p​olar9669:matrix.org> ASICS nice

Imagine if AMD decides to "test" their new CPUs :D

before selling :D

<p​olar9669:matrix.org> You won’t notice

Not in the nonce patterns, no

<p​olar9669:matrix.org> Also if and when sohpgo soc have enough demand they wouldn’t use them to mine 😅

if they do make an X7 i would fully expect them to have hardware AES

<p​olar9669:matrix.org> Unless it’s cheaper than competing amd cpus

When sophgo soc has enough demand, XMRig will add support for it :D

And end users will use them to mine

getting a native riscv jit would be cool :)

<p​olar9669:matrix.org> They would make, they will need to make next gen rsic-v soc anyways thanks to US restrictions

well, risc-v jit already exists, just not for public. Ask Bitmain to make a pull request :D

<p​olar9669:matrix.org> That would be nice 👌

By the way, I found an unfinished risc-v jit on github a few years ago

it's gone now, but I have a copy

It's from 2019 and has an interesting script in the repo: paste.debian.net/hidden/0707d4d6

So they probably started working on it already in 2019?

imafdc though, no vector extension?

is this really related?

well, they didn't have xuantie c910 in 2019

so no vector extensions

any other clues in the repo?

just a funny coincidence to find a risc-v jit (unfinished) and a chinese developer name in it

i mean, maybe related, but who knows

eureka elucidator: excellent analysis, thanks for sharing

there are so many chinese private farms and developers it could've been any of them tbh

back when FPGA was really kicking off there were dozens of them all independently building algos for these various shitcoins

I can upload it somewhere for people to look at it.

that would be interesting

Don't want to upload it to github though

if it is related maybe we can find some heritage in the x5 firmware

msvc project 🤔

src/riscv folder and jit_compiler_riscv* files are where it is

no, it has CMakeLists.txt

but it's unfinished and I never tried to build it

<eureka> did anybody get in with IDA/ghidra/etc yet and start looking at that gen_mango_xmrig ? => I did, went on it with ida pro for a while

that dtb is interesting, they have each core listed?

my first understanding is: it's pulling that xmrig binary from spi bus and running it

that's why there's no sign of it in the gen_xmrig binary data wise

I think that update_app binary is jucier, I posted a failed running attempt screenshot

ah yeah i tried both in qemu but just sigbus pretty much immediately, when doing /dev/mem stuff

which is predictable

it has lots of messages and you can kinda follow the flow of operations easily, initialization of lots of stuff

yeap

with a fake /dev/mem ofc lol

SG2042 sells for $1499 on a cheap ATX board, so the real price of the miner should be at least 15k

if the gen_xmrig binary was "decrypting" data from its own binary, I was gonna bypass the memmap errors to spit out the binary but unfortunately not

but they're the maker, so they're nowhere near retail price for their own costs

being the maker comes with a huge dev cost too tho

well, sophon is a big seller in chinese surveillance market

so they probably make most of their profits there

i am sure that mining with this product was mostly just a side hustle

hence the "image processing focused ai cores" I guess

all the x5 listings I see on aliexpress are over $4k

makes sense

they were being sold at $2.2k on the first day

because if you tear it down, you get 40 DDR4 sticks :D

which can cost 4k if you sell them :D

i would be surprised if they used socketed DIMMs

lol

if only we had one and sniff that spi bus and/or the serial busses that controller speaks with "randomx" units

if any of them were to be external ofc

i can go talk to some hardware dealers and see if they have them available

spi flash is external, me thinks

not sure if any of my old contacts are still in miner hardware business though

like we said - anybody building a device for randomx will just wind up building a better computer, and everyone can benefit. these would be great HPC number crunchers.

why wouldn't they use socketed DIMMs?

they didn't for E3, just soldered a shitload of individual DDR3 on each daughterboard

like 18 of them per ETH chip

sech1: sourcing mem ICs and soldering on board is cheaper? since their subsidiary is already a sbc manufacturee

and they have a large stock of individual DRAM ICs anyway

makes sense

socketed would be unnecessary expense and point of failure

plus the socket cost hehe

but they need a lot of them for each CPU

also affects the size probably

it would make the board bigger

socketed DIMMs save space because they're vertical

and they need vertical space for CPU heatsinks anyway

just double side it™

beneath the matching CPUs

it looks more and more like a GPU board design :D

just with 2x64 core CPUs in the middle :D

they used a full sized s19 style chassis, so I doubt they have enough space between boards for even DIMM socket at an angle

it would be funny if we were to pour all this knowledge and brainstorming to business and make an even better one

board + sink have basically no clearance between each other in that chassis

it's 140mm wide (because of fans used)

28 mm for each of the 5 boards

it will probably look similar to this one: youtube.com/watch?v=ew6mL5BjpdI

5 boards in one of those chassis seems unlikely, 2x5 grouping might just be logical

although maybe they use thinner sinks because of lower power usage

standard S19 style chassis has 3 boards

TDP is 120 watts per CPU

yep tevador that is what I was thinking is likely

they probably have each sg2042 on a daughterboard

although I would have expected it to be 2x sg2042 and the DDR4 on a daughterboard

not 1 board per sg2042

they have two CPUs on each of 5 boards

not much point in speculating about internal layout until we get visual confirmation

i don't know how they would get 5 boards in that chassis without very thin heatsinks

it's not speculating: qu.ax/Afge.png

they load 2 datasets

one per CPU - otherwise there's no point in doing it

yeah I don't doubt the CPUs are paired

but that could still well just be a logical distribution

they may not physically be on 5 separate hashboards

yes, physically they can be on 10 separate boards, or on 2 boards. But I don't think it's 3, then math doesn't work :D

2 boards seems more likely than 5

all of their recent products with that chassis design use an interchangeable chassis

with 3 slots for hashboards

it seems unlikely they would manufacture a modified chassis just for this low volume product

batch size estimate is what, around 2k units?

yes

they have 400-450 MH/s

that seems pretty average given their historical batch sizes for altcoins

historically their first runs have produced ~1800-2200 units for each coin

idk maybe it is 5 boards and a custom chassis, but those boards would be very tightly packed

probably alright with dual 140mm forced air lol

yes, dual 140mm should be enough to cool down only 1350 watts

their other ASICs use more power in the same chassis

considering the heat that'd come out of a bunch of SBCs running flat out... wonder what the long term derogation is like on these new cpus

i would imagine they have dynamic clocking based on conditions

basically every other bitmain product does

this is pretty different to other bitmain products though. Wonder if anyone has actually received one yet?

every 'personal' sale of them all uses the same stock images, and quote really long delivery times

considering they posted firmware already, they are definitely in people's hands

they usually don't post firmware until some time after products already shipped

give it about a week or two and we will see more resales coming up once people realise they only make like $8/day before power lol

can only assume having one of those running on desk is going to be loud as hell

loud, yeah, but probably less so than a S19xp at 3300W

I doubt my house wiring could handle another kW being drawn from it :P

those are quoted at 85dB

honestly if I was to run one of these for any purposes I'd probably transplant them into a 2U chassis :D

got my desk split over two wiring loops. Must be 2kw on one, and if I put my aircon on, 3kw on the other

and yes, I am solely to blame for the bad weather in the UK at the moment. Bought a portable airconditioner over a week ago. Was on for one day, then the national temperature dropped by 15c

oh yeah.. i forgot UK does that batshit ring topology

hey, that ring topology is ideal for a 'normal' house hold :P

4pcs, 2 laptops, 3pis, 5 android tv boxes, a projector, aircon unit, floor fan, 3d printer, 4 monitors and whatever mobile devices I'm charging at the time... if everything was all on at once I could see the wiring ring getting a bit warm

eureka hmm, can it be that they have 5 boards there, but arranged in 2 columns (2 boards at the front and then 3 board in the back)

or probably 3 boards in the front, closer to fans

possibly

I would imagine the sg2042s are on daughterboards and not directly on the hashboards themselves

can't find a single picture where you can see through the fan blades :/

so maybe there are unpopulated sockets for more modules :)))

the E3 teardown pics are a good example of that type of layout

not sure if anybody still has inno A10 teardown pics either but they also did the same sort of design

what model is that?

the innosilicon A10

ah nice

yeah, each daughterboard there has 4-8GiB GDDR5

public std::thread::_State_impl<std::_Bind_simple<void (*)(randomx_dataset *,randomx_cache *,unsigned long,unsigned long) ()(randomx_dataset *,randomx_cache *,unsigned int,unsigned int)> => from the controller software

depending on submodel

sech1: ^

they have the RXUs in /dev/rxuX

interesting

maybe worth taking a look at the kernel image

hopefully, there is a RandomX license next to the firmware file :P

pshh they don't respect any other project license

yeah i extracted the kernel image as well, there are references to riscv there ofc

open source releases stopped after S9 for the most part

i only looked at strings in the kernel image so far but yes I saw a lot of potentially custom code

that's also where I saw the cv1835 mentions too

cv183x_sdk

apparently they have switched to using that chip for control boards in all their new products

all the binaries are statically linked, hence all the functions are anonymous, i renamed some that i caught, mostly renaming something sensible seen what syscall it makes inside, like checkfile, fwrite, fopen etc.

kind of an odd choice for control chip, but must be a cost savings for them compared to zynq or old altera SoC they were using before

but it has all these security camera features sitting unused :D and a small TPU

I actually wonder how they use it on S19XP, because previously they used the FPGA in the zynq to generate work for the sha256d cores

public randomx::InterpretedVm<randomx::LargePageAllocator,true>

job time with 32 bit nonce is so short that CPU couldn't keep up with that

globalsources.com/product/detail?productId=1206024672 what do you think they're going to do about charging for delivery? Add a few thousand dollars to the price?

maybe they moved to generating jobs on chip in S19 series?

i thought i saw some AES implementation, followed the references back and saw that :D

RandomX has software AES implementation

i would be careful with that, sale price was $2.2k from bitmain direct

anything below $2.2 is going to be questionable at best

ofc in typical fashion only people with cronjobs to submit orders managed to get one from bitmain

been the same since 2017

:P

if those are real pictures they have a cover over control board connections :( can't get board count

std::_Bind_simple<void (*)(randomx_dataset *,randomx_cache *,unsigned long,unsigned long) ()(randomx_dataset *,randomx_cache *,unsigned int,unsigned int) looks like dataset initialization function

wish it really had a huge Monero decal on the side though

that would be sick

the lack of a monero logo really makes me dislike it... so much real estate on that case for some decals

some of the miners meant purely for consumer use have had logos

goldshell made some ltc miners with doge on them. lol

sech1: yeap, i'm seeing the instructions from github.com/tevador/RandomX/blob/mas…src/assembly_generator_x86.cpp#L558 this, weird it's in the aarch binary tho, i guess they didn't remove unneeded parts

im not surprised they didn't remove unneeded bits. X5 firmware has drivers for all their current generation chips

fair fair... bit of laser engraving makes all the difference

ckb, kda, hns, btc, ltc

assembly_generator_x86 is only used in tests/code-generator.cpp

The "true" in InterpretedVm<randomx::LargePageAllocator,true> means software AES.

so they compiled the whole RandomX repo and all binaries in it

question is, is it just locked down to randomx, or could it be used on a algo-switching pool like MO?

tevador: yeah but it's just one instance of such code, they got all kinds of similar stuff in it

in its current state i would say no paulio_uk

xmrig is not talking to the pool directly, they are using their cgminer fork

if they use xmrig under the hood, it can mine all algorithms

paulio_uk: judging from the control software it's pretty much randomx oriented

but given jailbreak and modification i am sure it can do most CPU oriented algorithms

updated software can enable other algorithms

so likely to see some firmware updates in the near future then

*firmware

they are even calling each riscv sub processor rxu, which we guess as "randomX units"

i would very much like to get linux booting independently on each sg2042, but then i wonder how to interface with the host

Because it was designed for RandomX, but they can easily add GhostRider algo for example

as risc-v is definitely becoming more main stream, all it would take is a risc-v targeted alt-coin to hit the streets and those things would be tanks

sech1: yeap

maybe hack up virtio to do a virtual nic to the host controller :D

and bridge to the controller ethernet

i wonder how many lanes the connections to the sg2042 are using, probably only x1

maybe we'll have a leak, get our hands on their "SDK", who knows

the stock sg2042 "sdk" is in the sophgo github

I mean if its a box packed with off the shelf parts (or soon to be public available off the shelf parts) we're going to see clones in no time at all

oh .. not sdk, just CAD files? lol github.com/sophgo/sophgo-hardware

i doubt we would see any clones

Yes, $15k clones :D

i don't think they sell bare cpu to individuals, and retail price is very high

if anything, people would buy X5 just to take the cpus out lol

elucidator: you can try to find this string "Platform doesn't support hardware AES" and where it's referenced. This could confirm they are using softAes.

cpus in X5 can be different from the current retail SG2042

they were assembled in 2021, after all

cv1835 "datasheet" does not seem to mention PCIe at all, oddly

tevador: not in the binary

did anybody find more evidence of there being another sub-controller?

the fact that there is that separate buildroot in those zip files makes me think so

and those userland bins are compiled for aarch64, instead of just 32 bit builds for the host controller userland

host image: bin/busybox: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-armhf.so.3, for GNU/Linux 3.2.0, BuildID[sha1]=8a195c14dab122ded000d1a906f3b1cdf5b9c334, stripped

update_total.bin image: /tmp/x5-chip/_update_total.bin.extracted/ramdisk/bin/busybox: ELF 64-bit LSB executable, ARM aarch64, version 1 (SYSV), dynamically linked, interpreter /lib/ld-uClibc.so.0, stripped

aarch64 binaries will not have the string, if the risc-v binary also doesn't have it, it might mean they have a hardware AES implementation

tevador: unfortunately we are yet to have any riscv bonary

*binary

elucidator, which binary are you looking at right now

risc-v binary can be packed and/or encrypted

mango_xmrig ?

so there will be no visible strings in it

i'm checking update_app.bin

ah ok

that has stuff like : create seed thread failed, create rxu thread failed, malloc seed pool failed, ringbuffer init faile

but yes, "Platform doesn't support hardware AES" should be in the compiled risc-v binary

if they didn't remove it on purpose

there is a 2nd ELF header inside update_app.bin with a strange set of params

ELF 64-bit LSB *unknown arch 0x464c* (SYSV)

strings only look like part of glibc

ah yeah i saw that two elf header there, i was gonna extract and see if it has anyting by itself

i think it is just part of glibc, since there is a ELF coredump header directly after it

first one seems "empty" only 16 bytes later the second one starts

maybe part of the loader

yeah second one's empty too, mostly bunch of strings after that

arm64 status register reading everywhere.. i should really have a plugin to pretty print those

eureka: you are saying it's a .zip file but mine is a .bin file did we get different images ?

 /tmp/x5/usr/bin/update_app.zip:   Zip archive data, at least v2.0 to extract, compression method=deflate

 /tmp/x5/usr/bin/update_total.zip: Zip archive data, at least v2.0 to extract, compression method=deflate

ah, it's automatically unpacked for me.. sorry my bad

brb, work emergency :)

CPUID=$(hexdump -n20 -e '32/1 "%02x"' /sys/class/cvi-base/base_efuse_shadow | dd skip=24 count=16 bs=1 2>&-) => wonder what's there

i just realized they have lighttpd running on it with lots of dashboard files

yeah each miner has a webui usually elucidator

yeap, seems to be their stock cgminer dashboard

if there's such a thing

and a bunch of bash scripts in cgi-bin directory acting as the "dynamic" part of the webpage for api access

eureka: seems like there's already a tool in the distro to unpack the .bmu files. /usr/bin/Fileparser

useful

./FileParser -s CVCtrl_X5 Antminer-X5-CV-release-202308311152.bmu rootfs/etc/bitmain.pub => you run it like this

i usually just grab the cpio bit and extract that

it extracts to /tmp/tmpfw/

yeah it didn't change the result

qu.ax/aFlM.png resulting these files

boot.bin is that gzipped cpio archive

0.0g.gg/?c350b5065ed7fc63#3xe6ZYeEf…DVnkHqoBUGJXccSwrtptQzcpk13pY8AEgfY here is the default output of the tool

it wants the "minertype" which is whatever is in the /etc/subtype file

in this case CVCtrl_X5

qemu cried about not being able to find "/lib/ld-linux-armhf.so.3" so i just did export QEMU_LD_PREFIX=/rootfs_of_antminer so it just used it and ran the tool

i actually followed the breadcrumbs from the web dashboard cgi scripts to see what "update firmware" page does. saw the tool there and tried to replicate the parameters as well. then i followed other pages it requested to see where they get "minertype" from etc. resulting this. ah and also there's a kernel module called "cv183x_wdt.ko" i guess that also hints the controller being cv1835 like eureka said.

and there's "cv183x_pwm.ko", that guy is definitely the one that controls the fans.

sech1: i finally made some sense out of those different device trees

0.0g.gg/?69d04501fef0dfc3#E3yaDFoUE…TB4VZxWzberAHJgnVQ17zhp57in9vha8nU4 they are for different "variants" i think, as in probably they are not used at the same time

one of them shows emmc, the other shows spinand

maybe they are in use at the same time, i'm not 100% sure

<c​harutocafe:matrix.org> a bit out of the loop, are the "asics" asic after all?

They use boards with SG2042 which are regular CPUs (but server grade 64 core CPUs)

And DDR4 memory to feed these CPUs

<c​harutocafe:matrix.org> ah yes

<c​harutocafe:matrix.org> the future

<c​harutocafe:matrix.org> so, if they're not asics, does it make sense to brick them?

They can't be bricked

They can only be slowed down

<c​harutocafe:matrix.org> well yeah

<c​harutocafe:matrix.org> they don't have hardware AES, right?

Stock SG2042 doesn't have AES

but there's a chance Bitmain used some custom version

<c​harutocafe:matrix.org> got it

<c​harutocafe:matrix.org> they claim 6.37 J/H, any clue how that compares with current x86 options?

Because I don't see how they could've reached this power efficiency without hardware AES

X5 has 157 h/J efficiency

<c​harutocafe:matrix.org> kH*

tuned 7950X rig can reach 150 h/J

dual AMD EPYC server can go above 150 h/J

<c​harutocafe:matrix.org> ok so efficiency is more or less in line with current best offers

<c​harutocafe:matrix.org> looks like a pretty good mining machine tbh, hopefully these cpus become widely available from other manufacturers.

Sophon (SG2042 maker) is Bitmain's subsidiary

So no

<c​harutocafe:matrix.org> although i thought that risc-v for current monero mining was a problem due to lack of JIT compilation

Obviously they wrote risc-v jit compiler

<c​harutocafe:matrix.org> can it be reverse engineered from the firmware?

It's easier to write the jit compiler from scratch

<c​harutocafe:matrix.org> that's fair

<c​harutocafe:matrix.org> couldn't it be done via LLVM so a single compiler was written for many different architectures including risc-v?

<c​harutocafe:matrix.org> apologies if it's a stupid question

it would be too slow to have LLVM layer

<c​harutocafe:matrix.org> understood, thanks.

LLVM is better for AOT compilation, lots of optimization is slow

i guess i see why you use H/j for randomx since numbers are low, but j/{,K,M,G,T}H is the normal comparison for most algorithms with high hashrate :D

<e​ndor00:matrix.org> Same difference, really

<e​ndor00:matrix.org> Plus, breakeven H/J is directly proportional to electricity cost

yeah I am just used to the alternative representation for discussion about most hardware

some slightly better datasheet github.com/milkv-pioneer/hardware/blob/main/SG2042-TRM.pdf

Does the firmware have any risc-v code at all? Or is it all aarch64?

not found any risc-v code yet, but there is a lot of surface left to disassemble

elucidator i would try disassembling godminer, it seems to call the update_app bin

I may try that later, we are about to go to vacation so don't know how much I have left with workstation for upcoming days.