05:09:54 anybody look at the X5 firmware yet? 05:10:02 just went live on bitmain site today 05:11:25 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 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 can you post a link for it, looked around but couldn't find the downloads part 05:12:52 https://m.bitmain.com/support/download 05:13:14 XMR Cryptonight -> ANTMINER X5 05:13:46 the host controller firmware is pretty boring, typical bitmain setup, runs their cgminer fork called "godminer" 05:13:48 thank you 05:14:19 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 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 give somebody 20 mins with a disassembler and I'm sure they'll get more info though 05:18:13 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 but that's off topic here :^) 05:38:26 i think the main controller is an ARM64 05:39:16 >Image: Linux kernel ARM64 boot executable Image, little-endian, 4K pages 05:39:33 >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 and this is the busybox that /linuxrc etc. links to 05:40:31 >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 init too 05:42:39 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 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 those don't look like bitmain part numbers, odd 05:49:54 is that config.json from the main image or the image inside the zip file? 05:50:45 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 modified xmrig does some odd poking in /dev/mem though so I am unsure what it is actually doing without disassembly 05:51:48 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 didn't see any "image in zip" yet. i'll fire up the rev.eng. VM after a reboot 05:52:16 its in /usr/bin/** 05:52:20 *.zip 05:52:29 I forget the filename. not at my workstation rn 05:52:58 I checked the /etc first, slowly going to that side. so my finding is in main image 05:53:01 both zip files in /usr/bin have more full firmware images, compiled slightly differently, userland bins are aarch64 05:53:35 maybe they are emulating aarch64 on riscv :P 05:53:57 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 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 sounds unnecessarily complicated but bitmain has a habit of doing that 05:55:15 then they are memory mapped for "remote control" 05:55:26 yep. that was my immediate theory 05:55:27 we do that in FPGAs all the time 05:55:48 but like I said I have no disassembly tools on hand, personal machine is kaput right now :( 05:55:54 can't run IDA on a phone yet 05:56:18 not the best practice when you already have the manufacturing uphand but possible none the less 05:57:52 I will check monerologs later to see if you found anything interesting. Happy hunting:)) 05:58:25 sure thing, see ya 06:07:16 >bin/busybox: ELF 64-bit LSB executable, ARM aarch64, version 1 (SYSV), dynamically linked, interpreter /lib/ld-uClibc.so.0, stripped 06:08:22 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 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 Interesting 06:42:35 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 Only ARM code spotted so far? 06:43:29 yeap- 06:45:10 >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 maybe it unpacks risc-v code and uploads it via some weird custom interface? 06:50:57 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 hmm, maybe mango is risc-v chip's codename? 06:53:51 Don't say it's mango pi :D 06:54:17 D1, C906 Core, RISC-V core up to 1GHz 06:54:53 https://riscv.org/wp-content/uploads/2020/11/Allwinner-XuanTie-C906-RISC-V-Processor.jpg 06:55:01 xuantie c906 there 06:56:18 ping hyc - read above ^^^ 06:56:42 yeah thought of that but didn't check yet 06:58:02 specs are not good enough for RandomX: https://mangopi.org/mqpro 06:58:19 V1.0, 2022.01.05, first release 06:58:31 hmm, around the same time I spotted the nonce pattern 06:58:44 maybe Bitmain ordered some custom mango boards with more memory 06:59:08 or even sponsored this whole mango pi, so they could sell their own boards later 06:59:59 and this board is very small (physically) - probably one of Bitmain's requirements :D 07:00:22 yeah 07:01:03 what's with generating those 2 binaries and doing bunch of spi writes tho 07:03:15 xuantie c910 is still more likely candidate. c906 is too weak and it's just a single core 07:03:54 that may be the cheap "controller" they want 07:04:00 *would want 07:05:41 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 that mini image is PRETTY_NAME="Buildroot 2019.08.2" 07:10:22 >Unix path: /home/felix/work/mining_machine/bootloader-arm64/u-boot/board/sophgo/mango/board.c 07:10:47 caught in the mini image this and many other paths 07:13:31 ooo i think found something spicy 07:14:41 https://0.0g.gg/?deb301ead4117a97#4Cu5E4uevwMoKTuhqV3S4SvRtUoUPBteYLHR4kbFZvMe 07:17:12 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 as in : "MangoPi Module MCore-H616 Core Board 4-core A53" ?? 07:18:47 https://hackster.imgix.net/uploads/attachments/1488227/image_XFSvPJL5Gd.png it's also available like this as a SoM 07:29:31 I think our suspicion about riscv piggybacking on arm64 as controller is correct 07:46:19 so did they make their own boards with arm64 main cpu and risc-v co-processors? 07:46:57 found the cpu, https://www.sophon.ai/product/introduce/sg2042.html 07:47:46 figures it's being sold in sophon wing too, they did the same in bytom miners 07:48:10 64 cores, 64 MB cache? 07:48:14 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 are you sure they use this cpu? 07:48:40 it's the same model number in cgminer bin, and the file path mentions sophgo 07:48:41 then they can use 32 cores for AES, and 32 cores for RandomX :D 07:48:44 so odds are very good 07:48:59 so they can have RandomX implementation that uses 2 cores to calculate each hash 07:49:09 this could be a very cool platform for non-hashing usage tbh 07:49:26 when jailbreak :D 07:49:29 if it really does have full MMU and everything 07:49:43 If I had $2k I would have bought a unit for teardown:( 07:50:03 bitmain site sold out in about 6 minutes though. typical 07:50:38 SG2042 has Xuantie C910 cores 07:50:44 so no hardware AES 07:51:04 so it makes sense to use 1 core for AES, and 1 core for RandomX 07:51:14 adding AES to the main loop will brick it 07:51:26 or at least half the hashrate 07:51:35 should verify that they did not add AES first 07:51:41 because they can't send data back and forth between cores quickly enough 07:52:22 it isn't impossible they added AES extensions, I didn't see any evidence of either possibility yet 07:53:04 it's only possible to find it out when you extract risc-v binaries and disassemble them 07:53:18 then you can just look for risc-v aes instructions 07:53:26 yep, I have no tooling available to unpack that mango bin yet sadly 07:53:36 wasted enough time unpacking stuff over ssh on my phone 07:53:57 good call on c910 though. I think you are correct 07:54:03 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 AES loop is up to 4x parallelizable 07:56:16 https://github.com/sophgocommunity/Pioneer_Doc 07:57:05 timing of the sg2042 launch seems closely related here 07:57:07 I don't think Xuantie C910 has AES support, I can't find anything about it 07:57:10 only a few weeks ago 07:57:42 wait, it says C920? 07:57:44 no I don't think the stock core does either, but Bitmain is well capable of adding support on their own 07:59:08 They're all RV64GCV - and this one doesn't have cryptography instructions 07:59:57 Bitmain can of course add it 08:00:27 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 it's possible they just reused the same basic design as sg2042 08:03:33 248 Days Ago: 3,411,522 08:03:33 Total Hashes 35Valid / 25 08:03:33 Invalid Shares 0.00000910XMR pending 08:04:01 they didn't do much mining with it, barely enough to test it worked 08:04:38 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 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 don't bitmain still run their own monero pool 08:05:19 or in antpool? 08:05:32 try looking up addr there 08:05:40 No, they use supportxmr and nanopool 08:06:25 and hashvault 08:06:29 found it on hashvault 08:07:00 https://v3.antpool.com/coinInfo?coinType=XMR¤cy=USD 08:07:03 Total Paid 18.2578 08:07:04 no workers lol 08:07:13 must be newly reopened 08:07:18 first payment on January 13th, 2023 08:08:00 if there is anything related to solar panels in the firmware, check for a custom 80% xmrig donation fee/address 08:08:44 Last Share 08:08:44 15 days ago 08:11:02 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 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 This address was active on hashvault at least since January 12th, 2023 (first block found) 08:32:13 one last thing, codename for sg2042 is mango 08:32:15 https://github.com/sophgo/linux-riscv/commit/f1b435611f9a02b30fd8f19347566117472f0cc4 08:32:25 I think evidence points pretty well 08:33:49 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 if anybody here manages to obtain an X5, please get us access to poke at it :)) 08:36:30 I would not be surprised if it was stock though, bitmain already has two other miners using unmodified stock sophon parts 08:36:40 B3/B7 08:38:04 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 sg2042 seems only announced publicly around the start of this year 08:42:28 Bitmain of course had access to early sg2042 engineering samples, because Sophon is their subsidiary. 08:42:58 which means they can use a version with hardware AES 08:43:11 and for example 32 cores, 64 MB cache 08:48:44 nonce bands started around Christmas 2021, the earliest confirmed time the XMR address from firmware was active, is January 12th, 2023 08:48:57 So there's a gap of ~1 year that's not confirmed yet 11:15:54 elucidator so many mangos :D https://github.com/sophgo/linux-riscv/tree/sg2042-dev/arch/riscv/boot/dts/sophgo 11:16:53 i actually saw a specific device tree file name but couldn't find any reference online 11:17:06 hoping it would show the interconnection enable lines 11:17:35 mango_r_bcx22601_v0.0.dtb this 11:18:13 mango_fpga.dtb, mango_evb_v0.0.dtb, mango_r_evb_v0.0.dtb, mango_r_bcx22601_v0.0.dtb 11:18:20 there are references to all these 11:21:15 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 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 https://0.0g.gg/?e1dcb73313040b28#4sEwH7TL7gGxjzfmN9sB5yhfmpYfZR3uMGkJn9b2jcY3 first dtb i decoded 11:36:33 https://0.0g.gg/?adae82177e5385fc#FRjpTLNkugbceKowFevQ1g59SByGqjnr6UZk158ZG76Y second dtb 11:37:29 nice 11:37:46 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 64, equals 2 teraflops." 11:37:50 2 TFLops 11:39:35 That's AMD EPYC level 11:41:41 EPYC Rome (Zen2) has up to 2 TFlops, EPYC Milan (Zen3) has up to 3.8 TFlops 11:42:07 although they do it with double precision, which is more impressive 11:42:54 dtb2 repeats itself again, here is the dtb3 https://0.0g.gg/?fba4f0e4716c9cc2#5kNQXq9mmw5qZC9JNBzmsenXajn4Py5xaejRdBcNLUEQ which is very similar to dtb2 11:43:50 compatible = "sophgo,mango-cdns-pcie"; 11:44:11 case closed 11:45:19 https://0.0g.gg/?0973ea2e6b011b1b#GBdtjRU39ifpmaM8Ga1ewpgPyxeSJVGiZQJxAjfv2Pfw and the last one, again very similar 11:45:53 i'm seeing another 5 set with exact same sizes, assuming they are repeating like the second repeats in the image 11:50:04 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 there's a line in aarch64 kernel image saying "failed to get riscv reset control" 11:54:18 Interesting article https://arxiv.org/pdf/2309.00381.pdf 11:54:33 Each C920 core contains 64KB of L1 instruction (I) and data (D) 11:54:33 cache, 1MB of L2 cache which is shared between the cluster of four 11:54:33 cores, and 64MB of L3 system cache which is shared by all cores in 11:54:33 the package. The SG2042 also provides four DDR4-3200 memory 11:54:33 controllers, and 32 lanes of PCI-E Gen4 11:54:40 C920 = C910 + vector FPU 11:54:47 Which is what they use in X5 11:55:51 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 https://github.com/milkv-pioneer/hardware/blob/main/SG2042-TRM.pdf 12:01:09 TDP 120W 12:01:33 So 10 boards = 1200W + memory + fans = 1350W 12:03:09 64 RISC-V cpu cores which implements IMAFDC 12:03:19 again no mention of cryptography extensions (no AES) 12:03:54 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 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 looking at the xmrig.conf they've disabled hw-aes so it looks likely thats what they're doing. 12:11:16 This xmrig must be heavily modified in any case, so I wouldn't trust config values 12:11:59 sech1: you gonna LOVE this 12:12:15 Because they even have "cpu enabled -> false" there :D 12:12:27 found the device trees with riscv configs, they call it rxu, randomX unit i guess ? 12:12:43 nice 12:12:47 so how many cores in this rxu? 12:13:21 one sec, lemme upload all 5 extra device trees so i can look in detail as well as you guys 12:13:32 i'm seeing 32 rxu in one of them 12:14:18 32 rxu, 64 cores = 2 cores to calculate single hash 12:14:37 if AES is software, it makes sense to use 2 cores for it 12:15:02 then our RandomX AES tweak will really nerf it 12:15:19 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 https://www.protectedtext.com/antminerx5?antminerx5 alright this should be more convenient, each file in a tab 12:17:16 rxu_dataset_mem 12:17:19 ohhh, juicy 12:18:15 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 looks like 5x boards with each 32 "rxu" 12:19:08 they have different reset addresses etc. which is to be expected. 12:19:52 sech sg2042mcu on dtb3 12:20:47 interesting, one of them has emmc on board 12:20:52 They should have 10 boards 12:20:57 Maybe grouped 2x5 12:21:04 maybe 12:21:06 so firmware gets uploaded 2 times 12:21:14 ohhh 12:21:26 because there are 10 stripes in the nonce pattern 12:21:29 that's why 2 stages ? gotta look further into that generator 12:22:08 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 reset-names = "rxu\0riscv" finally some proper mention of riskv :D 12:22:57 *riscv 12:35:40 not sure if it can help, this is stock sg2042: https://lore.kernel.org/lkml/CAHAQgRDtQDx-DBSs6Afs_C3qrRDxqONENM9rXu43dWCw0ehXPA⊙mgc/T/ 12:38:05 "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 Ohh, local L3 slice is very nice for RandomX 12:38:25 it means they have low latency when accessing scratchpad 12:44:06 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 i ran their "update_app" binary through qemu but doesn't show anything useful ofc https://qu.ax/Afge.png 12:49:39 RandomX dataset again 12:49:50 rxu_dataset_mem0, rxu_dataset_mem1 12:49:57 dataset_memory_init 12:52:18 hmm, they have 2 datasets 12:52:25 so it's probably 5 boards, with 2 CPUs on each 12:52:30 so 2 NUMA nodes, 2 datasets 12:53:06 These boards look more and more like Dual EPYC servers :D 12:55:52 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 Although they can probably get away with only 2 DDR4 sticks per CPU if they have good timings 12:58:43 It's 100% not an ASIC 12:58:58 btw, based on the price of components, the real cost should be in 5 figures 12:59:14 which explains why it sould out so quickly 12:59:27 if you jailbreak it, it's a compute monster 13:04:55 wonder how much they ROI-ed 13:05:46 how fucked is your business model if you have to ROI your hardware before selling? 13:06:24 (sorry for unrelated question tho) 13:06:39 better than "cloud mining" services :D 13:06:53 lol fair enough :P 13:09:44 They didn't ROI it, it's too expensive. 10xSG2042 CPUs alone cost more than $10k 13:10:16 40 DDR4 sticks are not free too :D 13:11:26 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 So they probably won't make any more 13:11:34 tomorrow's headlines: main monero miner dev recommended antminer x5 saying it's priceless 13:13:28 lol 13:14:18 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 that's kinda sad 13:15:51 I suspect they just used SG2042 engineering samples for X5 13:16:28 early engineering samples 13:17:03 So maybe when they make SG2042's successor, we'll get another wave of RandomX "ASICs" :D 13:19:36 which are not really ASICs, it's custom boards with CPUs on them 13:21:46 And again it will be a small batch with not so great power efficiency (especially after RandomX tweaks) 13:22:10 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 they must have been bored and maybe were like "no randomx asics? challenge accepted" 13:23:25 but then the whole thing was a ded end 13:23:46 and they figured better sell the bricks since we're not getting ROI from mining 13:24:03 also probably they got cheaper parts 15:05:51 https://www.ebay.com/itm/355044750541?hash=item52aa50f4cd:g:Hm0AAOSw1OVlCT 15:10:53 looks a single one might have made it to ebay 15:15:06 more allegedly available at aliexpress 15:18:35 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 so no point asking them to "pop it open and send me a pic of the internals please" 15:20:54 It just looks like 5 server dual cpu boards inside 15:21:02 Something like 1U EPYC servers, just smaller 15:21:04 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 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 the hashrate is the same as 10x 7950x's, but that'd cost a metric shit-tonne more to build 15:59:07 risc-v because SG2042 is risc-v 15:59:11 and they use it for other stuff 16:00:06 so yes, they could slap 5 dual EPYC boards and get the same hashrates and power usage 16:00:25 but they can't get EPYCs for cheap, but they can get SG2042 because it's their own chip 16:01:03 wait, no. They only need 2 dual EPYC boards 16:01:22 i figured out where the aarch64 bit is coming from 16:01:47 they have recently started using another sophon/cvitek chip for their control boards instead of a zynq 16:01:53 cv1835 16:01:57 https://www.sophon.ai/product/introduce/cv1835.html 16:02:03 s19xp uses it as well apparently 16:03:40 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 but the binaries in the firmware are all aarch64 16:06:09 risc-v code is generated on the fly and then sent to the sg2042 16:06:24 sent how though? 16:07:06 via memory mapping, and pci-e commands 16:07:11 kind of like a gpu 16:07:33 sg2042 work like co-processors there 16:07:51 ah that makes sense 16:08:54 are they loading job work onto sg2042 only? or is each sg2042 running a rx jit 16:09:16 sorry, i meant those together 16:10:00 how much is the cv1835 controller responsible for there 16:10:04 I think sg2042 runs jit too. Maybe even the whole XMRig compiled for risc-v 16:10:23 controller is only responsible for booting sg2042 and sending jobs to it 16:10:26 did anybody get in with IDA/ghidra/etc yet and start looking at that gen_mango_xmrig ? 16:10:48 Oh right. It must be risc-v compiled xmrig judging by the name 16:11:27 it would make sense, maybe they are generating hardcoded parameters and then sending the binary over to sg2042s like you said 16:11:36 explains the /dev/mem poking 16:12:26 i thought it was pretty weird they run cgminer on the host still 16:12:35 so they have xmrig sending nonces to cgminer to send to the pool? :D 16:12:40 cgminer controls all 5 boards and 10 cpus 16:12:54 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 2 sg2042 per board? 16:13:43 yes 16:13:53 because they initialize 2 datasets in the firmware 16:13:59 2 datasets = 1 dataset per CPU 16:14:25 makes sense, i wonder if they are running each sg2042 independently or if they are sharing the memory per board 16:14:32 which is typical for NUMA-enabled system with more than 1 CPU 16:14:33 sg2042 apparently does support multi-cpu operation 16:15:19 wow, i'm kicking myself for not getting one at $2.2k now 16:15:29 that is some serious compute power for that price 16:15:43 yeap 16:15:56 jailbreak will make it very nice buy 16:15:57 they must have barely ROI'd if at all 16:16:24 well ... i wonder how wide the pcie connection to the cv1835 is 16:16:25 and it's not an ASIC. If it gets jailbroken, you can run almost anything there 16:16:28 that is the bottleneck really 16:16:42 and controller probably only supports 100m ethernet like usual bitmain controllers 16:17:05 i/o might be bad, but compute power is huge 16:17:10 yep 16:17:13 each CPU is 2 TFlops, so 20 TFlops in total 16:17:33 that's getting into gpu territory 16:17:40 Who cares we are going to brick it anyways 16:18:20 20 TFlops is RTX 3070 level 16:18:41 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 but it's more flexible than a GPU 16:18:49 they aren't making any more of these at this price point 16:18:51 no way ... 16:18:59 They can't be bricked 16:19:03 because it's CPUs 16:19:14 "bricked" as in severe perf impact 16:19:18 AES tweak will of course make them slower, but I don't know how much slower 16:19:33 It depends on if they have stock SG2042 (no AES), or some custom SG2042 16:19:34 did anybody confirm your 2nd core aes theory yet? 16:19:51 If it's stock SG2042, then it's the most logical thing to do 16:19:58 Run AES in software, but use 2 cores for it 16:20:16 because it only has enough cache for 32 threads, but it has 64 cores 16:20:56 It’s about sending a message 16:21:20 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 polar9669, bitmain lost a whole lot of money on this endeavour ... 16:21:52 i would argue monero folks won here 16:22:11 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 Stock SG2042 would get nerfed to 60-70% of their current hashrate after the AES tweak 16:22:36 so 130-140 kh/s 16:22:44 They didn’t loose much, it’s their r&d cost for Rsic-v 16:22:47 that's still pretty good for a single unit 16:22:47 Custom SG2042 with AES would get 5-10% slowdown 16:22:55 They will make next gen soc 16:23:03 Which will work for tweaked pow 16:23:15 they make these SoC for domestic chinese use, mining is just an afterthought 16:23:38 and with current xmr emissions do you really think they will spend all that time on an updated model? 16:24:01 They can make it as a byproduct 16:24:15 Develop new chip -> use eng. samples in "ASICs" 16:24:19 Bitmain owns sophgo, so yes it’s a by product of their research 16:24:41 ASICS nice 16:24:58 Imagine if AMD decides to "test" their new CPUs :D 16:25:04 before selling :D 16:25:29 You won’t notice 16:25:53 Not in the nonce patterns, no 16:27:17 Also if and when sohpgo soc have enough demand they wouldn’t use them to mine 😅 16:27:33 if they do make an X7 i would fully expect them to have hardware AES 16:27:33 Unless it’s cheaper than competing amd cpus 16:27:43 When sophgo soc has enough demand, XMRig will add support for it :D 16:27:49 And end users will use them to mine 16:28:15 getting a native riscv jit would be cool :) 16:28:51 They would make, they will need to make next gen rsic-v soc anyways thanks to US restrictions 16:29:00 well, risc-v jit already exists, just not for public. Ask Bitmain to make a pull request :D 16:29:15 That would be nice 👌 16:29:38 By the way, I found an unfinished risc-v jit on github a few years ago 16:29:45 it's gone now, but I have a copy 16:30:29 It's from 2019 and has an interesting script in the repo: https://paste.debian.net/hidden/0707d4d6/ 16:30:39 So they probably started working on it already in 2019? 16:31:07 imafdc though, no vector extension? 16:31:11 is this really related? 16:32:01 well, they didn't have xuantie c910 in 2019 16:32:09 so no vector extensions 16:32:35