05:09:54 <eureka> anybody look at the X5 firmware yet?
05:10:02 <eureka> just went live on bitmain site today
05:11:25 <eureka> 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
05:12:00 <eureka> 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
05:12:34 <elucidator> can you post a link for it, looked around but couldn't find the downloads part
05:12:52 <eureka> https://m.bitmain.com/support/download
05:13:14 <eureka> XMR Cryptonight -> ANTMINER X5
05:13:46 <eureka> the host controller firmware is pretty boring, typical bitmain setup, runs their cgminer fork called "godminer"
05:13:48 <elucidator> thank you
05:14:19 <eureka> there are some zip files in /usr/bin that hold firmware for another device(?) though, that's where the xmrig mentions are
05:15:00 <eureka> gen_mango_xmrig tries to do some direct writes to /dev/mem so I can't just pull the image out with emulating it :(
05:16:03 <eureka> give somebody 20 mins with a disassembler and I'm sure they'll get more info though
05:18:13 <eureka> 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
05:18:20 <eureka> but that's off topic here :^)
05:38:26 <elucidator> i think the main controller is an ARM64
05:39:16 <elucidator> >Image: Linux kernel ARM64 boot executable Image, little-endian, 4K pages
05:39:33 <elucidator> >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
05:40:04 <elucidator> and this is the busybox that /linuxrc etc. links to
05:40:31 <elucidator> >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
05:40:35 <elucidator> init too
05:42:39 <elucidator> https://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
05:45:50 <elucidator> https://0.0g.gg/?8eeea717379690da#7qi2caWvRjxNn9MH3jRiKfpczZfLBEvKshFgLp3q5o6J 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 
05:49:04 <eureka> those don't look like bitmain part numbers, odd
05:49:54 <eureka> is that config.json from the main image or the image inside the zip file?
05:50:45 <eureka> 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)
05:51:16 <eureka> modified xmrig does some odd poking in /dev/mem though so I am unsure what it is actually doing without disassembly
05:51:48 <eureka> on their more traditional miners they often do that to talk to FPGA in the controller SoC, but that seems unlikely here
05:52:06 <elucidator> didn't see any "image in zip" yet. i'll fire up the rev.eng. VM after a reboot
05:52:16 <eureka> its in /usr/bin/**
05:52:20 <eureka> *.zip
05:52:29 <eureka> I forget the filename. not at my workstation rn
05:52:58 <elucidator> I checked the /etc first, slowly going to that side. so my finding is in main image
05:53:01 <eureka> both zip files in /usr/bin have more full firmware images, compiled slightly differently, userland bins are aarch64
05:53:35 <elucidator> maybe they are emulating aarch64 on riscv :P
05:53:57 <eureka> 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
05:54:35 <eureka> maybe they have some custom SoC with am aarch64 core and a load of riscv cores just tacked on the side as coprocessors
05:54:56 <eureka> sounds unnecessarily complicated but bitmain has a habit of doing that
05:55:15 <elucidator> then they are memory mapped for "remote control"
05:55:26 <eureka> yep. that was my immediate theory
05:55:27 <elucidator> we do that in FPGAs all the time 
05:55:48 <eureka> but like I said I have no disassembly tools on hand, personal machine is kaput right now :(
05:55:54 <eureka> can't run IDA on a phone yet
05:56:18 <elucidator> not the best practice when you already have the manufacturing uphand but possible none the less 
05:57:52 <eureka> I will check monerologs later to see if you found anything interesting. Happy hunting:))
05:58:25 <elucidator> sure thing, see ya
06:07:16 <elucidator> >bin/busybox: ELF 64-bit LSB executable, ARM aarch64, version 1 (SYSV), dynamically linked, interpreter /lib/ld-uClibc.so.0, stripped
06:08:22 <elucidator> 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 ?
06:26:48 <elucidator> 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
06:41:01 <sech1> Interesting
06:42:35 <elucidator> 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
06:43:24 <sech1> Only ARM code spotted so far?
06:43:29 <elucidator> yeap-
06:45:10 <elucidator> >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
06:49:08 <sech1> maybe it unpacks risc-v code and uploads it via some weird custom interface?
06:50:57 <elucidator> yeah if that's the case i'm trying to catch the unpack routine. that generates mango_xmrig and whatever mango_xmrig is doing.
06:53:25 <sech1> hmm, maybe mango is risc-v chip's codename?
06:53:51 <sech1> Don't say it's mango pi :D
06:54:17 <sech1> D1, C906 Core, RISC-V core up to 1GHz
06:54:53 <sech1> https://riscv.org/wp-content/uploads/2020/11/Allwinner-XuanTie-C906-RISC-V-Processor.jpg
06:55:01 <sech1> xuantie c906 there
06:56:18 <sech1> ping hyc - read above ^^^
06:56:42 <elucidator> yeah thought of that but didn't check yet
06:58:02 <sech1> specs are not good enough for RandomX: https://mangopi.org/mqpro
06:58:19 <sech1> V1.0, 2022.01.05, first release
06:58:31 <sech1> hmm, around the same time I spotted the nonce pattern
06:58:44 <sech1> maybe Bitmain ordered some custom mango boards with more memory
06:59:08 <sech1> or even sponsored this whole mango pi, so they could sell their own boards later
06:59:59 <sech1> and this board is very small (physically) - probably one of Bitmain's requirements :D
07:00:22 <elucidator> yeah
07:01:03 <elucidator> what's with generating those 2 binaries and doing bunch of spi writes tho
07:03:15 <sech1> xuantie c910 is still more likely candidate. c906 is too weak and it's just a single core
07:03:54 <elucidator> that may be the cheap "controller" they want
07:04:00 <elucidator> *would want
07:05:41 <elucidator> 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
07:07:52 <elucidator> that mini image is PRETTY_NAME="Buildroot 2019.08.2"
07:10:22 <elucidator> >Unix path: /home/felix/work/mining_machine/bootloader-arm64/u-boot/board/sophgo/mango/board.c
07:10:47 <elucidator> caught in the mini image this and many other paths
07:13:31 <elucidator> ooo i think found something spicy
07:14:41 <elucidator> https://0.0g.gg/?deb301ead4117a97#4Cu5E4uevwMoKTuhqV3S4SvRtUoUPBteYLHR4kbFZvMe
07:17:12 <elucidator> some strings that may be helpful "RISC-V only mode" "Disable RISC-V subsystem" "A53 master mode" -> as in arm cortex-a53?
07:17:39 <elucidator> as in : "MangoPi Module MCore-H616 Core Board 4-core A53" ??
07:18:47 <elucidator> https://hackster.imgix.net/uploads/attachments/1488227/image_XFSvPJL5Gd.png it's also available like this as a SoM
07:29:31 <elucidator> I think our suspicion about riscv piggybacking on arm64 as controller is correct
07:46:19 <sech1> so did they make their own boards with arm64 main cpu and risc-v co-processors?
07:46:57 <eureka> found the cpu, https://www.sophon.ai/product/introduce/sg2042.html
07:47:46 <eureka> figures it's being sold in sophon wing too, they did the same in bytom miners
07:48:10 <sech1> 64 cores, 64 MB cache?
07:48:14 <eureka> reused shitty TPU they couldn't sell for AI purposes, came up with a PoW that could be done on TPU chips.
07:48:19 <sech1> are you sure they use this cpu?
07:48:40 <eureka> it's the same model number in cgminer bin, and the file path mentions sophgo
07:48:41 <sech1> then they can use 32 cores for AES, and 32 cores for RandomX :D
07:48:44 <eureka> so odds are very good
07:48:59 <sech1> so they can have RandomX implementation that uses 2 cores to calculate each hash
07:49:09 <eureka> this could be a very cool platform for non-hashing usage tbh
07:49:26 <sech1> when jailbreak :D
07:49:29 <eureka> if it really does have full MMU and everything
07:49:43 <eureka> If I had $2k I would have bought a unit for teardown:(
07:50:03 <eureka> bitmain site sold out in about 6 minutes though. typical
07:50:38 <sech1> SG2042 has Xuantie C910 cores
07:50:44 <sech1> so no hardware AES
07:51:04 <sech1> so it makes sense to use 1 core for AES, and 1 core for RandomX
07:51:14 <sech1> adding AES to the main loop will brick it
07:51:26 <sech1> or at least half the hashrate
07:51:35 <eureka> should verify that they did not add AES first
07:51:41 <sech1> because they can't send data back and forth between cores quickly enough
07:52:22 <eureka> it isn't impossible they added AES extensions, I didn't see any evidence of either possibility yet
07:53:04 <sech1> it's only possible to find it out when you extract risc-v binaries and disassemble them
07:53:18 <sech1> then you can just look for risc-v aes instructions
07:53:26 <eureka> yep, I have no tooling available to unpack that mango bin yet sadly
07:53:36 <eureka> wasted enough time unpacking stuff over ssh on my phone
07:53:57 <eureka> good call on c910 though. I think you are correct
07:54:03 <sech1> 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
07:54:34 <sech1> AES loop is up to 4x parallelizable
07:56:16 <eureka> https://github.com/sophgocommunity/Pioneer_Doc
07:57:05 <eureka> timing of the sg2042 launch seems closely related here
07:57:07 <sech1> I don't think Xuantie C910 has AES support, I can't find anything about it
07:57:10 <eureka> only a few weeks ago
07:57:42 <sech1> wait, it says C920?
07:57:44 <eureka> no I don't think the stock core does either, but Bitmain is well capable of adding support on their own
07:59:08 <sech1> They're all RV64GCV - and this one doesn't have cryptography instructions
07:59:57 <sech1> Bitmain can of course add it
08:00:27 <sech1> 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
08:02:48 <eureka> it's possible they just reused the same basic design as sg2042
08:03:33 <flame> 248 Days Ago: 3,411,522 
08:03:33 <flame> Total Hashes  35Valid  / 25
08:03:33 <flame> Invalid Shares  0.00000910XMR pending
08:04:01 <flame> they didn't do much mining with it, barely enough to test it worked
08:04:38 <sech1> 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)
08:04:41 <eureka> 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
08:05:12 <eureka> don't bitmain still run their own monero pool
08:05:19 <eureka> or in antpool?
08:05:32 <eureka> try looking up addr there
08:05:40 <sech1> No, they use supportxmr and nanopool
08:06:25 <sech1> and hashvault
08:06:29 <sech1> found it on hashvault
08:07:00 <eureka> https://v3.antpool.com/coinInfo?coinType=XMR&currency=USD
08:07:03 <sech1>  Total Paid 18.2578
08:07:04 <eureka> no workers lol
08:07:13 <eureka> must be newly reopened
08:07:18 <sech1> first payment on January 13th, 2023
08:08:00 <plowsof> if there is anything related to solar panels in the firmware, check for a custom 80% xmrig donation fee/address 
08:08:44 <flame> Last Share
08:08:44 <flame>  15 days ago
08:11:02 <eureka> OK, I'm going to sleep now, hope you can make some perf estimates based on c910/c920 specs scaled to the sg2042
08:11:21 <eureka> and happy hunting for more details, this is the first new mining hardware that I've found exciting in a few years now
08:12:31 <sech1> This address was active on hashvault at least since January 12th, 2023 (first block found)
08:32:13 <eureka> one last thing, codename for sg2042 is mango
08:32:15 <eureka> https://github.com/sophgo/linux-riscv/commit/f1b435611f9a02b30fd8f19347566117472f0cc4
08:32:25 <eureka> I think evidence points pretty well
08:33:49 <sech1> 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.
08:35:27 <eureka> if anybody here manages to obtain an X5, please get us access to poke at it :))
08:36:30 <eureka> I would not be surprised if it was stock though, bitmain already has two other miners using unmodified stock sophon parts
08:36:40 <eureka> B3/B7
08:38:04 <eureka> 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
08:38:26 <eureka> sg2042 seems only announced publicly around the start of this year
08:42:28 <sech1> Bitmain of course had access to early sg2042 engineering samples, because Sophon is their subsidiary.
08:42:58 <sech1> which means they can use a version with hardware AES
08:43:11 <sech1> and for example 32 cores, 64 MB cache
08:48:44 <sech1> nonce bands started around Christmas 2021, the earliest confirmed time the XMR address from firmware was active, is January 12th, 2023
08:48:57 <sech1> So there's a gap of ~1 year that's not confirmed yet
11:15:54 <sech1> elucidator so many mangos :D https://github.com/sophgo/linux-riscv/tree/sg2042-dev/arch/riscv/boot/dts/sophgo
11:16:53 <elucidator> i actually saw a specific device tree file name but couldn't find any reference online
11:17:06 <elucidator> hoping it would show the interconnection enable lines
11:17:35 <elucidator> mango_r_bcx22601_v0.0.dtb this
11:18:13 <elucidator> mango_fpga.dtb, mango_evb_v0.0.dtb, mango_r_evb_v0.0.dtb, mango_r_bcx22601_v0.0.dtb
11:18:20 <elucidator> there are references to all these
11:21:15 <sech1> 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.
11:22:22 <sech1> 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
11:33:49 <elucidator> https://0.0g.gg/?e1dcb73313040b28#4sEwH7TL7gGxjzfmN9sB5yhfmpYfZR3uMGkJn9b2jcY3 first dtb i decoded
11:36:33 <elucidator> https://0.0g.gg/?adae82177e5385fc#FRjpTLNkugbceKowFevQ1g59SByGqjnr6UZk158ZG76Y second dtb
11:37:29 <sech1> nice
11:37:46 <sech1> 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
11:37:46 <sech1> 64, equals 2 teraflops."
11:37:50 <sech1> 2 TFLops
11:39:35 <sech1> That's AMD EPYC level
11:41:41 <sech1> EPYC Rome (Zen2) has up to 2 TFlops, EPYC Milan (Zen3) has up to 3.8 TFlops
11:42:07 <sech1> although they do it with double precision, which is more impressive
11:42:54 <elucidator> dtb2 repeats itself again, here is the dtb3 https://0.0g.gg/?fba4f0e4716c9cc2#5kNQXq9mmw5qZC9JNBzmsenXajn4Py5xaejRdBcNLUEQ which is very similar to dtb2
11:43:50 <sech1> compatible = "sophgo,mango-cdns-pcie";
11:44:11 <sech1> case closed
11:45:19 <elucidator> https://0.0g.gg/?0973ea2e6b011b1b#GBdtjRU39ifpmaM8Ga1ewpgPyxeSJVGiZQJxAjfv2Pfw and the last one, again very similar
11:45:53 <elucidator> i'm seeing another 5 set with exact same sizes, assuming they are repeating like the second repeats in the image
11:50:04 <elucidator> 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
11:50:22 <elucidator> there's a line in aarch64 kernel image saying "failed to get riscv reset control"
11:54:18 <sech1> Interesting article https://arxiv.org/pdf/2309.00381.pdf
11:54:33 <sech1> Each C920 core contains 64KB of L1 instruction (I) and data (D)
11:54:33 <sech1> cache, 1MB of L2 cache which is shared between the cluster of four
11:54:33 <sech1> cores, and 64MB of L3 system cache which is shared by all cores in
11:54:33 <sech1> the package. The SG2042 also provides four DDR4-3200 memory
11:54:33 <sech1> controllers, and 32 lanes of PCI-E Gen4
11:54:40 <sech1> C920 = C910 + vector FPU
11:54:47 <sech1> Which is what they use in X5
11:55:51 <sech1> 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
12:00:58 <sech1> https://github.com/milkv-pioneer/hardware/blob/main/SG2042-TRM.pdf
12:01:09 <sech1> TDP 120W
12:01:33 <sech1> So 10 boards = 1200W + memory + fans = 1350W
12:03:09 <sech1> 64 RISC-V cpu cores which implements IMAFDC
12:03:19 <sech1> again no mention of cryptography extensions (no AES)
12:03:54 <sech1> I still think they run 32 cores for RandomX and then switch to 2 cores per hash when they need to do AES hashing
12:09:11 <paulio_uk> 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
12:10:45 <paulio_uk> looking at the xmrig.conf they've disabled hw-aes so it looks likely thats what they're doing.
12:11:16 <sech1> This xmrig must be heavily modified in any case, so I wouldn't trust config values
12:11:59 <elucidator> sech1: you gonna LOVE this
12:12:15 <sech1> Because they even have "cpu enabled -> false" there :D
12:12:27 <elucidator> found the device trees with riscv configs, they call it rxu, randomX unit i guess ?
12:12:43 <sech1> nice
12:12:47 <sech1> so how many cores in this rxu?
12:13:21 <elucidator> one sec, lemme upload all 5 extra device trees so i can look in detail as well as you guys
12:13:32 <elucidator> i'm seeing 32 rxu in one of them
12:14:18 <sech1> 32 rxu, 64 cores = 2 cores to calculate single hash
12:14:37 <sech1> if AES is software, it makes sense to use 2 cores for it
12:15:02 <sech1> then our RandomX AES tweak will really nerf it
12:15:19 <sech1> It double the amount of AES per hash, and they won't be able to use 2 cores for AES in the main loop
12:16:12 <elucidator> https://www.protectedtext.com/antminerx5?antminerx5 alright this should be more convenient, each file in a tab
12:17:16 <sech1> rxu_dataset_mem
12:17:19 <sech1> ohhh, juicy
12:18:15 <elucidator> 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 
12:18:34 <elucidator> looks like 5x boards with each 32 "rxu"
12:19:08 <elucidator> they have different reset addresses etc. which is to be expected.
12:19:52 <elucidator> sech sg2042mcu on dtb3
12:20:47 <elucidator> interesting, one of them has emmc on board
12:20:52 <sech1> They should have 10 boards
12:20:57 <sech1> Maybe grouped 2x5
12:21:04 <elucidator> maybe
12:21:06 <sech1> so firmware gets uploaded 2 times
12:21:14 <elucidator> ohhh
12:21:26 <sech1> because there are 10 stripes in the nonce pattern
12:21:29 <elucidator> that's why 2 stages ? gotta look further into that generator
12:22:08 <elucidator> 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 
12:22:52 <elucidator> reset-names = "rxu\0riscv" finally some proper mention of riskv :D
12:22:57 <elucidator> *riscv
12:35:40 <sech1> not sure if it can help, this is stock sg2042: https://lore.kernel.org/lkml/CAHAQgRDtQDx-DBSs6Afs_C3qrRDxqONENM9rXu43dWCw0ehXPA⊙mgc/T/
12:38:05 <sech1> "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."
12:38:17 <sech1> Ohh, local L3 slice is very nice for RandomX
12:38:25 <sech1> it means they have low latency when accessing scratchpad
12:44:06 <sech1> 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
12:46:46 <elucidator> i ran their "update_app" binary through qemu but doesn't show anything useful ofc https://qu.ax/Afge.png
12:49:39 <sech1> RandomX dataset again
12:49:50 <sech1> rxu_dataset_mem0, rxu_dataset_mem1
12:49:57 <sech1> dataset_memory_init
12:52:18 <sech1> hmm, they have 2 datasets
12:52:25 <sech1> so it's probably 5 boards, with 2 CPUs on each
12:52:30 <sech1> so 2 NUMA nodes, 2 datasets
12:53:06 <sech1> These boards look more and more like Dual EPYC servers :D
12:55:52 <sech1> 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)
12:56:08 <sech1> Although they can probably get away with only 2 DDR4 sticks per CPU if they have good timings
12:58:43 <sech1> It's 100% not an ASIC
12:58:58 <sech1> btw, based on the price of components, the real cost should be in 5 figures
12:59:14 <sech1> which explains why it sould out so quickly
12:59:27 <sech1> if you jailbreak it, it's a compute monster
13:04:55 <elucidator> wonder how much they ROI-ed
13:05:46 <kico> how fucked is your business model if you have to ROI your hardware before selling?
13:06:24 <kico> (sorry for unrelated question tho)
13:06:39 <elucidator> better than "cloud mining" services :D
13:06:53 <kico> lol fair enough :P
13:09:44 <sech1> They didn't ROI it, it's too expensive. 10xSG2042 CPUs alone cost more than $10k
13:10:16 <sech1> 40 DDR4 sticks are not free too :D
13:11:26 <sech1> 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
13:11:31 <sech1> So they probably won't make any more
13:11:34 <elucidator> tomorrow's headlines: main monero miner dev recommended antminer x5 saying it's priceless
13:13:28 <kico> lol
13:14:18 <kico> 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
13:14:22 <kico> that's kinda sad
13:15:51 <sech1> I suspect they just used SG2042 engineering samples for X5
13:16:28 <sech1> early engineering samples
13:17:03 <sech1> So maybe when they make SG2042's successor, we'll get another wave of RandomX "ASICs" :D
13:19:36 <sech1> which are not really ASICs, it's custom boards with CPUs on them
13:21:46 <sech1> And again it will be a small batch with not so great power efficiency (especially after RandomX tweaks)
13:22:10 <sech1> I just don't see how they can mass produce them and sell than at less than 30% of what it costed :D
13:23:09 <kico> they must have been bored and maybe were like "no randomx asics? challenge accepted"
13:23:25 <kico> but then the whole thing was a ded end
13:23:46 <kico> and they figured better sell the bricks since we're not getting ROI from mining
13:24:03 <kico> also probably they got cheaper parts
15:05:51 <Inge> https://www.ebay.com/itm/355044750541?hash=item52aa50f4cd:g:Hm0AAOSw1OVlCT
15:10:53 <Inge> looks a single one might have made it to ebay
15:15:06 <Inge> more allegedly available at aliexpress
15:18:35 <paulio_uk> Note: This is the pre-sale price, and the actual price may fluctuate in real time. Please contact us before placing an order!!!!!
15:19:08 <paulio_uk> so no point asking them to "pop it open and send me a pic of the internals please"
15:20:54 <sech1> It just looks like 5 server dual cpu boards inside
15:21:02 <sech1> Something like 1U EPYC servers, just smaller
15:21:04 <Inge> maybe some of the Aliexpress selllers? one says has 2 left, one says has 50(!?) available - https://www.aliexpress.com/w/wholesale-bitmain-antminer-X5.html?catId=0&initiative_id=SB_20230919071355&SearchText=bitmain+antminer+X5&spm=a2g0o.home.1000002.0
15:29:02 <paulio_uk> 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
15:30:22 <paulio_uk> the hashrate is the same as 10x 7950x's, but that'd cost a metric shit-tonne more to build
15:59:07 <sech1> risc-v because SG2042 is risc-v
15:59:11 <sech1> and they use it for other stuff
16:00:06 <sech1> so yes, they could slap 5 dual EPYC boards and get the same hashrates and power usage
16:00:25 <sech1> but they can't get EPYCs for cheap, but they can get SG2042 because it's their own chip
16:01:03 <sech1> wait, no. They only need 2 dual EPYC boards
16:01:22 <eureka> i figured out where the aarch64 bit is coming from
16:01:47 <eureka> they have recently started using another sophon/cvitek chip for their control boards instead of a zynq
16:01:53 <eureka> cv1835
16:01:57 <eureka> https://www.sophon.ai/product/introduce/cv1835.html
16:02:03 <eureka> s19xp uses it as well apparently
16:03:40 <eureka> so it doesn't really look like they have any aarch64 control cpu on die, that might've been a red herring :D
16:05:50 <sech1> but the binaries in the firmware are all aarch64
16:06:09 <sech1> risc-v code is generated on the fly and then sent to the sg2042
16:06:24 <eureka> sent how though?
16:07:06 <sech1> via memory mapping, and pci-e commands
16:07:11 <sech1> kind of like a gpu
16:07:33 <sech1> sg2042 work like co-processors there
16:07:51 <eureka> ah that makes sense
16:08:54 <eureka> are they loading job work onto sg2042 only? or is each sg2042 running a rx jit
16:09:16 <eureka> sorry, i meant those together
16:10:00 <eureka> how much is the cv1835 controller responsible for there
16:10:04 <sech1> I think sg2042 runs jit too. Maybe even the whole XMRig compiled for risc-v
16:10:23 <sech1> controller is only responsible for booting sg2042 and sending jobs to it
16:10:26 <eureka> did anybody get in with IDA/ghidra/etc yet and start looking at that gen_mango_xmrig ?
16:10:48 <sech1> Oh right. It must be risc-v compiled xmrig judging by the name
16:11:27 <eureka> it would make sense, maybe they are generating hardcoded parameters and then sending the binary over to sg2042s like you said
16:11:36 <eureka> explains the /dev/mem poking
16:12:26 <eureka> i thought it was pretty weird they run cgminer on the host still
16:12:35 <eureka> so they have xmrig sending nonces to cgminer to send to the pool? :D
16:12:40 <sech1> cgminer controls all 5 boards and 10 cpus
16:12:54 <sech1> and we get a nice 10-stripe pattern :D https://api.hashvault.pro/v3/monero/network/nonce/distribution/png?hashrate=true&nonceColor=%23ff6600
16:13:39 <eureka> 2 sg2042 per board?
16:13:43 <sech1> yes
16:13:53 <sech1> because they initialize 2 datasets in the firmware
16:13:59 <sech1> 2 datasets = 1 dataset per CPU
16:14:25 <eureka> makes sense, i wonder if they are running each sg2042 independently or if they are sharing the memory per board
16:14:32 <sech1> which is typical for NUMA-enabled system with more than 1 CPU
16:14:33 <eureka> sg2042 apparently does support multi-cpu operation
16:15:19 <eureka> wow, i'm kicking myself for not getting one at $2.2k now
16:15:29 <eureka> that is some serious compute power for that price
16:15:43 <sech1> yeap
16:15:56 <sech1> jailbreak will make it very nice buy
16:15:57 <eureka> they must have barely ROI'd if at all
16:16:24 <eureka> well ... i wonder how wide the pcie connection to the cv1835 is
16:16:25 <sech1> and it's not an ASIC. If it gets jailbroken, you can run almost anything there
16:16:28 <eureka> that is the bottleneck really
16:16:42 <eureka> and controller probably only supports 100m ethernet like usual bitmain controllers
16:17:05 <sech1> i/o might be bad, but compute power is huge
16:17:10 <eureka> yep
16:17:13 <sech1> each CPU is 2 TFlops, so 20 TFlops in total
16:17:33 <eureka> that's getting into gpu territory
16:17:40 <m-relay> <p​olar9669:matrix.org> Who cares we are going to brick it anyways
16:18:20 <sech1> 20 TFlops is RTX 3070 level
16:18:41 <eureka> is it really worth bricking them lol, if they are out of bitmain's hands and in the hands of end users?
16:18:47 <sech1> but it's more flexible than a GPU
16:18:49 <eureka> they aren't making any more of these at this price point
16:18:51 <eureka> no way ...
16:18:59 <sech1> They can't be bricked
16:19:03 <sech1> because it's CPUs
16:19:14 <eureka> "bricked" as in severe perf impact
16:19:18 <sech1> AES tweak will of course make them slower, but I don't know how much slower
16:19:33 <sech1> It depends on if they have stock SG2042 (no AES), or some custom SG2042
16:19:34 <eureka> did anybody confirm your 2nd core aes theory yet?
16:19:51 <sech1> If it's stock SG2042, then it's the most logical thing to do
16:19:58 <sech1> Run AES in software, but use 2 cores for it
16:20:16 <sech1> because it only has enough cache for 32 threads, but it has 64 cores
16:20:56 <m-relay> <p​olar9669:matrix.org> It’s about sending a message
16:21:20 <eureka> 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
16:21:44 <eureka> polar9669, bitmain lost a whole lot of money on this endeavour ...
16:21:52 <eureka> i would argue monero folks won here
16:22:11 <eureka> sure they got a fair portion of our nethash for some time but there's no way they made a respectable profit
16:22:21 <sech1> Stock SG2042 would get nerfed to 60-70% of their current hashrate after the AES tweak
16:22:36 <sech1> so 130-140 kh/s
16:22:44 <m-relay> <p​olar9669:matrix.org> They didn’t loose much, it’s their r&d cost for Rsic-v
16:22:47 <eureka> that's still pretty good for a single unit
16:22:47 <sech1> Custom SG2042 with AES would get 5-10% slowdown
16:22:55 <m-relay> <p​olar9669:matrix.org> They will make next gen soc
16:23:03 <m-relay> <p​olar9669:matrix.org> Which will work for tweaked pow
16:23:15 <eureka> they make these SoC for domestic chinese use, mining is just an afterthought
16:23:38 <eureka> and with current xmr emissions do you really think they will spend all that time on an updated model?
16:24:01 <sech1> They can make it as a byproduct
16:24:15 <sech1> Develop new chip -> use eng. samples in "ASICs"
16:24:19 <m-relay> <p​olar9669:matrix.org> Bitmain owns sophgo, so yes it’s a by product of their research
16:24:41 <m-relay> <p​olar9669:matrix.org> ASICS nice
16:24:58 <sech1> Imagine if AMD decides to "test" their new CPUs :D
16:25:04 <sech1> before selling :D
16:25:29 <m-relay> <p​olar9669:matrix.org> You won’t notice
16:25:53 <sech1> Not in the nonce patterns, no
16:27:17 <m-relay> <p​olar9669:matrix.org> Also if and when sohpgo soc have enough demand they wouldn’t use them to mine 😅
16:27:33 <eureka> if they do make an X7 i would fully expect them to have hardware AES
16:27:33 <m-relay> <p​olar9669:matrix.org> Unless it’s cheaper than competing amd cpus
16:27:43 <sech1> When sophgo soc has enough demand, XMRig will add support for it :D
16:27:49 <sech1> And end users will use them to mine
16:28:15 <eureka> getting a native riscv jit would be cool :)
16:28:51 <m-relay> <p​olar9669:matrix.org> They would make, they will need to make next gen rsic-v soc anyways thanks to US restrictions
16:29:00 <sech1> well, risc-v jit already exists, just not for public. Ask Bitmain to make a pull request :D
16:29:15 <m-relay> <p​olar9669:matrix.org> That would be nice 👌
16:29:38 <sech1> By the way, I found an unfinished risc-v jit on github a few years ago
16:29:45 <sech1> it's gone now, but I have a copy
16:30:29 <sech1> It's from 2019 and has an interesting script in the repo: https://paste.debian.net/hidden/0707d4d6/
16:30:39 <sech1> So they probably started working on it already in 2019?
16:31:07 <eureka> imafdc though, no vector extension?
16:31:11 <eureka> is this really related?
16:32:01 <sech1> well, they didn't have xuantie c910 in 2019
16:32:09 <sech1> so no vector extensions
16:32:35 <eureka> any other clues in the repo?
16:32:43 <sech1> just a funny coincidence to find a risc-v jit (unfinished) and a chinese developer name in it
16:32:45 <eureka> i mean, maybe related, but who knows
16:32:57 <tevador> eureka elucidator: excellent analysis, thanks for sharing
16:32:58 <eureka> there are so many chinese private farms and developers it could've been any of them tbh
16:33:29 <eureka> back when FPGA was really kicking off there were dozens of them all independently building algos for these various shitcoins
16:33:45 <sech1> I can upload it somewhere for people to look at it.
16:33:50 <eureka> that would be interesting
16:33:53 <sech1> Don't want to upload it to github though
16:34:04 <eureka> if it is related maybe we can find some heritage in the x5 firmware
16:34:45 <sech1> https://p2pool.io/RandomX-RISCV-riscv.zip
16:35:38 <eureka> msvc project 🤔
16:35:40 <sech1> src/riscv folder and jit_compiler_riscv* files are where it is
16:35:46 <sech1> no, it has CMakeLists.txt
16:35:55 <sech1> but it's unfinished and I never tried to build it
16:39:59 <elucidator> <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
16:40:19 <eureka> that dtb is interesting, they have each core listed?
16:40:36 <elucidator> my first understanding is: it's pulling that xmrig binary from spi bus and running it
16:40:59 <elucidator> that's why there's no sign of it in the gen_xmrig binary data wise
16:41:48 <elucidator> I think that update_app binary is jucier, I posted a failed running attempt screenshot 
16:42:28 <eureka> ah yeah i tried both in qemu but just sigbus pretty much immediately, when doing /dev/mem stuff
16:42:31 <eureka> which is predictable
16:42:31 <elucidator> it has lots of messages and you can kinda follow the flow of operations easily, initialization of lots of stuff 
16:42:37 <elucidator> yeap
16:42:40 <eureka> with a fake /dev/mem ofc lol
16:43:30 <tevador> SG2042 sells for $1499 on a cheap ATX board, so the real price of the miner should be at least 15k
16:43:51 <elucidator> 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
16:44:01 <hyc> but they're the maker, so they're nowhere near retail price for their own costs
16:44:28 <elucidator> being the maker comes with a huge dev cost too tho
16:45:03 <eureka> well, sophon is a big seller in chinese surveillance market
16:45:07 <eureka> so they probably make most of their profits there
16:45:27 <eureka> i am sure that mining with this product was mostly just a side hustle
16:45:28 <elucidator> hence the "image processing focused ai cores" I guess
16:46:02 <hyc> all the x5 listings I see on aliexpress are over $4k
16:46:15 <sech1> makes sense
16:46:20 <eureka> they were being sold at $2.2k on the first day
16:46:23 <sech1> because if you tear it down, you get 40 DDR4 sticks :D
16:46:31 <sech1> which can cost 4k if you sell them :D
16:46:40 <eureka> i would be surprised if they used socketed DIMMs
16:46:40 <hyc> lol
16:47:03 <elucidator> if only we had one and sniff that spi bus and/or the serial busses that controller speaks with "randomx" units
16:47:13 <elucidator> if any of them were to be external ofc
16:47:31 <eureka> i can go talk to some hardware dealers and see if they have them available
16:47:33 <elucidator> spi flash is external, me thinks
16:47:54 <eureka> not sure if any of my old contacts are still in miner hardware business though
16:48:20 <hyc> 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.
16:48:26 <sech1> why wouldn't they use socketed DIMMs?
16:48:47 <eureka> they didn't for E3, just soldered a shitload of individual DDR3 on each daughterboard
16:48:54 <eureka> like 18 of them per ETH chip
16:49:00 <elucidator> sech1: sourcing mem ICs and soldering on board is cheaper? since their subsidiary is already a sbc manufacturee
16:49:09 <eureka> and they have a large stock of individual DRAM ICs anyway
16:49:15 <sech1> makes sense
16:49:32 <eureka> socketed would be unnecessary expense and point of failure
16:49:48 <elucidator> plus the socket cost hehe
16:50:00 <sech1> but they need a lot of them for each CPU
16:50:03 <elucidator> also affects the size probably
16:50:06 <sech1> it would make the board bigger
16:50:18 <sech1> socketed DIMMs save space because they're vertical
16:50:27 <sech1> and they need vertical space for CPU heatsinks anyway
16:50:37 <elucidator> just double side it™
16:51:01 <elucidator> beneath the matching CPUs
16:51:09 <sech1> it looks more and more like a GPU board design :D
16:51:26 <sech1> just with 2x64 core CPUs in the middle :D
16:51:34 <eureka> they used a full sized s19 style chassis, so I doubt they have enough space between boards for even DIMM socket at an angle
16:51:50 <elucidator> it would be funny if we were to pour all this knowledge and brainstorming to business and make an even better one
16:51:51 <eureka> board + sink have basically no clearance between each other in that chassis
16:52:20 <sech1> it's 140mm wide (because of fans used)
16:52:28 <sech1> 28 mm for each of the 5 boards
16:52:45 <tevador> it will probably look similar to this one: https://www.youtube.com/watch?v=ew6mL5BjpdI
16:52:53 <eureka> 5 boards in one of those chassis seems unlikely, 2x5 grouping might just be logical
16:53:08 <eureka> although maybe they use thinner sinks because of lower power usage
16:53:15 <eureka> standard S19 style chassis has 3 boards
16:53:47 <sech1> TDP is 120 watts per CPU
16:53:55 <eureka> yep tevador that is what I was thinking is likely
16:54:06 <eureka> they probably have each sg2042 on a daughterboard
16:54:19 <eureka> although I would have expected it to be 2x sg2042 and the DDR4 on a daughterboard
16:54:22 <eureka> not 1 board per sg2042
16:54:35 <sech1> they have two CPUs on each of 5 boards
16:55:02 <eureka> not much point in speculating about internal layout until we get visual confirmation
16:55:29 <eureka> i don't know how they would get 5 boards in that chassis without very thin heatsinks
16:55:44 <sech1> it's not speculating: https://qu.ax/Afge.png
16:55:48 <sech1> they load 2 datasets
16:55:59 <sech1> one per CPU - otherwise there's no point in doing it
16:56:02 <eureka> yeah I don't doubt the CPUs are paired
16:56:14 <eureka> but that could still well just be a logical distribution
16:56:24 <eureka> they may not physically be on 5 separate hashboards
16:57:00 <sech1> 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
16:57:18 <eureka> 2 boards seems more likely than 5
16:57:34 <eureka> all of their recent products with that chassis design use an interchangeable chassis
16:57:42 <eureka> with 3 slots for hashboards
16:58:10 <eureka> it seems unlikely they would manufacture a modified chassis just for this low volume product
16:58:23 <eureka> batch size estimate is what, around 2k units?
16:58:36 <sech1> yes
16:58:46 <sech1> they have 400-450 MH/s
16:58:49 <eureka> that seems pretty average given their historical batch sizes for altcoins
16:59:21 <eureka> historically their first runs have produced ~1800-2200 units for each coin
16:59:53 <eureka> idk maybe it is 5 boards and a custom chassis, but those boards would be very tightly packed
17:00:05 <eureka> probably alright with dual 140mm forced air lol
17:00:37 <sech1> yes, dual 140mm should be enough to cool down only 1350 watts
17:00:47 <sech1> their other ASICs use more power in the same chassis
17:02:52 <paulio_uk> 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
17:03:19 <eureka> i would imagine they have dynamic clocking based on conditions
17:03:23 <eureka> basically every other bitmain product does
17:04:38 <paulio_uk> this is pretty different to other bitmain products though. Wonder if anyone has actually received one yet?
17:04:55 <paulio_uk> every 'personal' sale of them all uses the same stock images, and quote really long delivery times
17:05:19 <eureka> considering they posted firmware already, they are definitely in people's hands
17:05:29 <eureka> they usually don't post firmware until some time after products already shipped
17:06:10 <eureka> 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
17:07:48 <paulio_uk> can only assume having one of those running on desk is going to be loud as hell
17:08:09 <eureka> loud, yeah, but probably less so than a S19xp at 3300W
17:08:14 <paulio_uk> I doubt my house wiring could handle another kW being drawn from it :P
17:08:16 <eureka> those are quoted at 85dB
17:09:10 <eureka> honestly if I was to run one of these for any purposes I'd probably transplant them into a 2U chassis :D
17:09:29 <paulio_uk> got my desk split over two wiring loops. Must be 2kw on one, and if I put my aircon on, 3kw on the other
17:10:27 <paulio_uk> 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
17:10:29 <eureka> oh yeah.. i forgot UK does that batshit ring topology
17:11:24 <paulio_uk> hey, that ring topology is ideal for a 'normal' house hold :P
17:12:54 <paulio_uk> 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
17:14:56 <sech1> 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)
17:15:13 <sech1> or probably 3 boards in the front, closer to fans
17:15:19 <eureka> possibly
17:15:39 <eureka> I would imagine the sg2042s are on daughterboards and not directly on the hashboards themselves
17:15:46 <paulio_uk> can't find a single picture where you can see through the fan blades :/
17:15:56 <eureka> so maybe there are unpopulated sockets for more modules :)))
17:16:23 <eureka> the E3 teardown pics are a good example of that type of layout
17:16:38 <eureka> not sure if anybody still has inno A10 teardown pics either but they also did the same sort of design
17:18:22 <paulio_uk> https://www.zeusbtc.com/Upload/image/202208/16608974514619001.jpg
17:18:38 <eureka> what model is that?
17:18:58 <paulio_uk> the innosilicon A10
17:23:26 <eureka> ah nice
17:23:52 <eureka> yeah, each daughterboard there has 4-8GiB GDDR5
17:23:57 <elucidator> 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
17:23:57 <eureka> depending on submodel
17:24:01 <elucidator> sech1: ^
17:25:51 <elucidator> https://0.0g.gg/?37fa72b6bb01003d#GifBAx81Ex4CfHJoi9tgsmVw33MQnCvMZsi4k9XVMU5N
17:26:05 <elucidator> they have the RXUs in /dev/rxuX
17:28:38 <eureka> interesting
17:28:46 <eureka> maybe worth taking a look at the kernel image
17:29:27 <tevador> hopefully, there is a RandomX license next to the firmware file :P
17:30:10 <eureka> pshh they don't respect any other project license
17:30:28 <elucidator> yeah i extracted the kernel image as well, there are references to riscv there ofc
17:30:28 <eureka> open source releases stopped after S9 for the most part
17:30:50 <eureka> i only looked at strings in the kernel image so far but yes I saw a lot of potentially custom code
17:31:10 <eureka> that's also where I saw the cv1835 mentions too
17:31:15 <eureka> cv183x_sdk
17:31:30 <eureka> apparently they have switched to using that chip for control boards in all their new products
17:32:18 <elucidator> 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.
17:33:18 <eureka> 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
17:33:31 <eureka> but it has all these security camera features sitting unused :D and a small TPU
17:34:09 <eureka> 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
17:34:11 <elucidator> public randomx::InterpretedVm<randomx::LargePageAllocator,true>
17:34:20 <eureka> job time with 32 bit nonce is so short that CPU couldn't keep up with that
17:34:22 <paulio_uk> https://www.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?
17:34:28 <eureka> maybe they moved to generating jobs on chip in S19 series?
17:34:33 <elucidator> i thought i saw some AES implementation, followed the references back and saw that :D
17:35:08 <sech1> RandomX has software AES implementation
17:35:12 <eureka> i would be careful with that, sale price was $2.2k from bitmain direct
17:35:19 <eureka> anything below $2.2 is going to be questionable at best
17:35:52 <eureka> ofc in typical fashion only people with cronjobs to submit orders managed to get one from bitmain
17:36:00 <eureka> been the same since 2017
17:36:06 <paulio_uk> :P
17:36:39 <eureka> if those are real pictures they have a cover over control board connections :( can't get board count
17:36:52 <sech1> 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
17:36:57 <eureka> wish it really had a huge Monero decal on the side though
17:37:00 <eureka> that would be sick
17:37:39 <paulio_uk> the lack of a monero logo really makes me dislike it... so much real estate on that case for some decals
17:38:08 <eureka> some of the miners meant purely for consumer use have had logos
17:38:19 <eureka> goldshell made some ltc miners with doge on them. lol
17:38:19 <elucidator> sech1: yeap, i'm seeing the instructions from https://github.com/tevador/RandomX/blob/master/src/assembly_generator_x86.cpp#L558 this, weird it's in the aarch binary tho, i guess they didn't remove unneeded parts
17:39:10 <eureka> https://5.imimg.com/data5/SELLER/Default/2022/4/DL/CD/LA/151304250/brand-new-goldshell-mini-doge-box-asic-miner-w-special-graphic-ar.jpg
17:39:35 <eureka> im not surprised they didn't remove unneeded bits. X5 firmware has drivers for all their current generation chips
17:39:39 <paulio_uk> fair fair... bit of laser engraving makes all the difference
17:39:53 <eureka> ckb, kda, hns, btc, ltc
17:40:10 <sech1> assembly_generator_x86 is only used in tests/code-generator.cpp
17:40:16 <tevador> The "true" in InterpretedVm<randomx::LargePageAllocator,true> means software AES.
17:40:19 <sech1> so they compiled the whole RandomX repo and all binaries in it
17:40:59 <paulio_uk> question is, is it just locked down to randomx, or could it be used on a algo-switching pool like MO?
17:41:02 <elucidator> tevador: yeah but it's just one instance of such code, they got all kinds of similar stuff in it
17:41:10 <eureka> in its current state i would say no paulio_uk
17:41:27 <eureka> xmrig is not talking to the pool directly, they are using their cgminer fork
17:41:30 <sech1> if they use xmrig under the hood, it can mine all algorithms
17:41:32 <elucidator> paulio_uk: judging from the control software it's pretty much randomx oriented
17:41:52 <eureka> but given jailbreak and modification i am sure it can do most CPU oriented algorithms
17:41:59 <sech1> updated software can enable other algorithms
17:42:01 <paulio_uk> so likely to see some firmware updates in the near future then
17:42:01 <sech1> *firmware
17:42:16 <elucidator> they are even calling each riscv sub processor rxu, which we guess as "randomX units"
17:43:31 <eureka> i would very much like to get linux booting independently on each sg2042, but then i wonder how to interface with the host
17:43:34 <sech1> Because it was designed for RandomX, but they can easily add GhostRider algo for example
17:43:42 <paulio_uk> 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
17:43:49 <elucidator> sech1: yeap
17:43:52 <eureka> maybe hack up virtio to do a virtual nic to the host controller :D
17:44:02 <eureka> and bridge to the controller ethernet
17:44:17 <eureka> i wonder how many lanes the connections to the sg2042 are using, probably only x1
17:45:18 <elucidator> maybe we'll have a leak, get our hands on their "SDK", who knows 
17:46:01 <eureka> the stock sg2042 "sdk" is in the sophgo github
17:47:04 <paulio_uk> 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
17:47:11 <eureka> oh .. not sdk, just CAD files? lol https://github.com/sophgo/sophgo-hardware
17:47:29 <eureka> i doubt we would see any clones
17:47:42 <sech1> Yes, $15k clones :D
17:47:53 <eureka> i don't think they sell bare cpu to individuals, and retail price is very high
17:48:05 <eureka> if anything, people would buy X5 just to take the cpus out lol
17:48:24 <tevador> 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.
17:48:28 <sech1> cpus in X5 can be different from the current retail SG2042
17:48:35 <sech1> they were assembled in 2021, after all
17:48:38 <eureka> cv1835 "datasheet" does not seem to mention PCIe at all, oddly
17:49:05 <elucidator> tevador: not in the binary
17:49:08 <eureka> did anybody find more evidence of there being another sub-controller?
17:49:37 <eureka> the fact that there is that separate buildroot in those zip files makes me think so
17:50:14 <eureka> and those userland bins are compiled for aarch64, instead of just 32 bit builds for the host controller userland
17:51:00 <eureka> 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
17:51:11 <eureka> 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
17:51:52 <tevador> 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
17:52:17 <elucidator> tevador: unfortunately we are yet to have any riscv bonary
17:52:22 <elucidator> *binary
17:52:36 <eureka> elucidator, which binary are you looking at right now
17:52:42 <sech1> risc-v binary can be packed and/or encrypted
17:52:43 <eureka> mango_xmrig ?
17:52:49 <sech1> so there will be no visible strings in it
17:52:53 <elucidator> i'm checking update_app.bin
17:52:56 <eureka> ah ok
17:53:50 <elucidator> that has stuff like : create seed thread failed, create rxu thread failed, malloc seed pool failed, ringbuffer init faile
17:53:53 <sech1> but yes, "Platform doesn't support hardware AES" should be in the compiled risc-v binary
17:53:58 <sech1> if they didn't remove it on purpose
17:54:02 <eureka> there is a 2nd ELF header inside update_app.bin with a strange set of params
17:54:06 <eureka> ELF 64-bit LSB *unknown arch 0x464c* (SYSV)
17:54:52 <eureka> strings only look like part of glibc
17:55:23 <elucidator> ah yeah i saw that two elf header there, i was gonna extract and see if it has anyting by itself
17:55:41 <eureka> i think it is just part of glibc, since there is a ELF coredump header directly after it
17:55:43 <elucidator> first one seems "empty" only 16 bytes later the second one starts
17:55:47 <eureka> maybe part of the loader
17:57:02 <elucidator> yeah second one's empty too, mostly bunch of strings after that
17:59:00 <elucidator> arm64 status register reading everywhere.. i should really have a plugin to pretty print those
18:04:03 <elucidator> eureka: you are saying it's a .zip file but mine is a .bin file did we get different images ?
18:04:50 <eureka>  /tmp/x5/usr/bin/update_app.zip:   Zip archive data, at least v2.0 to extract, compression method=deflate
18:04:58 <eureka>  /tmp/x5/usr/bin/update_total.zip: Zip archive data, at least v2.0 to extract, compression method=deflate
18:05:15 <elucidator> ah, it's automatically unpacked for me.. sorry my bad
18:05:17 <eureka> brb, work emergency :)
18:12:09 <elucidator> 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 
18:14:50 <elucidator> i just realized they have lighttpd running on it with lots of dashboard files
18:15:24 <kico> yeah each miner has a webui usually elucidator 
18:15:40 <elucidator> yeap, seems to be their stock cgminer dashboard
18:15:48 <elucidator> if there's such a thing 
18:17:20 <elucidator> and a bunch of bash scripts in cgi-bin directory acting as the "dynamic" part of the webpage for api access
18:41:43 <elucidator> eureka: seems like there's already a tool in the distro to unpack the .bmu files. /usr/bin/Fileparser
18:42:13 <eureka> useful
18:42:16 <elucidator> ./FileParser -s CVCtrl_X5 Antminer-X5-CV-release-202308311152.bmu rootfs/etc/bitmain.pub => you run it like this 
18:42:26 <eureka> i usually just grab the cpio bit and extract that
18:42:28 <elucidator> it extracts to /tmp/tmpfw/
18:42:57 <elucidator> yeah it didn't change the result 
18:43:28 <elucidator> https://qu.ax/aFlM.png resulting these files
18:43:55 <elucidator> boot.bin is that gzipped cpio archive
18:45:10 <elucidator> https://0.0g.gg/?c350b5065ed7fc63#3xe6ZYeEfDVnkHqoBUGJXccSwrtptQzcpk13pY8AEgfY here is the default output of the tool
18:45:30 <elucidator> it wants the "minertype" which is whatever is in the /etc/subtype file
18:45:37 <elucidator> in this case CVCtrl_X5
18:47:00 <elucidator> 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
18:51:45 <elucidator> 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.
18:52:58 <elucidator> and there's "cv183x_pwm.ko", that guy is definitely the one that controls the fans.
19:21:41 <elucidator> sech1: i finally made some sense out of those different device trees
19:22:36 <elucidator> https://0.0g.gg/?69d04501fef0dfc3#E3yaDFoUETB4VZxWzberAHJgnVQ17zhp57in9vha8nU4 they are for different "variants" i think, as in probably they are not used at the same time
19:23:03 <elucidator> one of them shows emmc, the other shows spinand
19:24:18 <elucidator> maybe they are in use at the same time, i'm not 100% sure
20:38:57 <m-relay> <c​harutocafe:matrix.org> a bit out of the loop, are the "asics" asic after all?
20:39:51 <sech1> They use boards with SG2042 which are regular CPUs (but server grade 64 core CPUs)
20:40:12 <sech1> And DDR4 memory to feed these CPUs
20:40:41 <m-relay> <c​harutocafe:matrix.org> ah yes
20:40:44 <m-relay> <c​harutocafe:matrix.org> the future
20:40:58 <m-relay> <c​harutocafe:matrix.org> so, if they're not asics, does it make sense to brick them?
20:41:06 <sech1> They can't be bricked
20:41:17 <sech1> They can only be slowed down
20:41:25 <m-relay> <c​harutocafe:matrix.org> well yeah
20:41:36 <m-relay> <c​harutocafe:matrix.org> they don't have hardware AES, right?
20:41:51 <sech1> Stock SG2042 doesn't have AES
20:42:00 <sech1> but there's a chance Bitmain used some custom version
20:42:21 <m-relay> <c​harutocafe:matrix.org> got it
20:42:41 <m-relay> <c​harutocafe:matrix.org> they claim 6.37 J/H, any clue how that compares with current x86 options?
20:42:47 <sech1> Because I don't see how they could've reached this power efficiency without hardware AES
20:43:16 <sech1> X5 has 157 h/J efficiency
20:43:17 <m-relay> <c​harutocafe:matrix.org> kH*
20:43:28 <sech1> tuned 7950X rig can reach 150 h/J
20:43:40 <sech1> dual AMD EPYC server can go above 150 h/J
20:44:14 <m-relay> <c​harutocafe:matrix.org> ok so efficiency is more or less in line with current best offers
20:45:03 <m-relay> <c​harutocafe:matrix.org> looks like a pretty good mining machine tbh, hopefully these cpus become widely available from other manufacturers.
20:45:25 <sech1> Sophon (SG2042 maker) is Bitmain's subsidiary
20:45:28 <sech1> So no
20:45:30 <m-relay> <c​harutocafe:matrix.org> although i thought that risc-v for current monero mining was a problem due to lack of JIT compilation
20:45:47 <sech1> Obviously they wrote risc-v jit compiler
20:46:13 <m-relay> <c​harutocafe:matrix.org> can it be reverse engineered from the firmware?
20:47:53 <sech1> It's easier to write the jit compiler from scratch
20:48:56 <m-relay> <c​harutocafe:matrix.org> that's fair
20:50:14 <m-relay> <c​harutocafe:matrix.org> couldn't it be done via LLVM so a single compiler was written for many different architectures including risc-v?
20:50:41 <m-relay> <c​harutocafe:matrix.org> apologies if it's a stupid question
20:57:59 <sech1> it would be too slow to have LLVM layer
20:59:27 <m-relay> <c​harutocafe:matrix.org> understood, thanks.
21:10:23 <eureka> LLVM is better for AOT compilation, lots of optimization is slow
21:11:49 <eureka> 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
21:12:46 <m-relay> <e​ndor00:matrix.org> Same difference, really
21:13:06 <m-relay> <e​ndor00:matrix.org> Plus, breakeven H/J is directly proportional to electricity cost
21:13:06 <eureka> yeah I am just used to the alternative representation for discussion about most hardware
21:14:36 <eureka> some slightly better datasheet https://github.com/milkv-pioneer/hardware/blob/main/SG2042-TRM.pdf
21:17:57 <tevador> Does the firmware have any risc-v code at all? Or is it all aarch64?
21:20:24 <eureka> not found any risc-v code yet, but there is a lot of surface left to disassemble
21:29:45 <eureka> elucidator i would try disassembling godminer, it seems to call the update_app bin
22:03:56 <elucidator> 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.