Repository navigation
dev call 20261026
Jitsi: Recording is on.
Ryan: All right. Welcome everyone from around the world to our lucky number 13th development call. As you just heard, these meetings are recorded and transcribed with AI, so if you care, be careful what you say. And the goal here is to, every two weeks, make sure everyone knows what's happening in the project and related projects, and discuss some things that are easier to discuss in person. And it's nice to just see everybody. I'll start with a few non-development workflow items. So daylight savings is about to happen in the US. So I just thought I'd do a quick poll of the audience and see whether we stick to our UTC time or follow daylight saving time. I for one think probably following the daylight savings time change makes sense because all of our lives and schedules pretty much run on a local time like that. I don't want to shift everyone's schedule around, but I just wanted to check. Does that make sense to everybody else? Any objections, I guess, is the way to frame that.
Tyler: So it would just move the call back one hour, right?
Ryan: Yeah. Spring ahead, fall back. What is that?
Tyler: I'm fine with that.
Ryan: That means it'll move to 1,800. All right.
Tyler: I think so.
Ryan: All right, that'll be the plan unless someone objects strongly.
Ryan: Last week, I was at the Rust Bitcoin Summit in Nashville, so a bit more traveling for me. I'm way conferenced out at this point, but I felt like this was a good one to go to, and it was. It was sort of a small gathering of most of the, well, yeah a lot of the major Bitcoin Rust projects so the rust-bitcoin library guys sort of host it anchor it and then bdk and ldk the major sort of wallet libraries built on top of rust-bitcoin and then various users of those libraries show up so We're actually a user of rust-bitcoin, the lowest level library. But I didn't necessarily show up there to ask library questions or to give them feedback as a user. I went there because trying to put open source mining back into the open source Bitcoin conversation. So I think I made progress on that front. I was able to sit there at the table with all the rest of the projects, some of the gigabrains in Bitcoin really. And several times we go around and talk about like, what is your project? Where does it fit in? So I got to talk about Mujina a couple of times. And of course, with everybody hanging out for a couple of days over dinners and lunches. And so we were in the big boy club now, maybe, or at least in the conversation. So that was exciting. And it was also just useful for me to sort of sit there and absorb what I could from some of these projects that have been around a while and with experienced maintainers and just hear what they're dealing with these days and how they handle things. It's so interesting. Everyone is really wrestling with AI and AI contributions and security scans, all the same issues. And I think it's just okay that everyone's sort of take is like, well, we're doing our best, but we're learning because this is new to all of us. So there's no right answers yet. And everybody's just doing their best. So one thing I found interesting is... I don't know how many of you have kept your ear to this, but in the open source world at large, there's seems to be a very interesting split between people who think AI is, you know, of the devil and we need to ban it from our, you know, no contributions allowed that come from AI and like, you're not allowed to use AI to help. Like if you want to commit to significant open source projects that have been around a long time and then others embrace it. I think I'm happy to report that among the Bitcoiners, like everyone views this as a productivity enhancing tool. And yeah, it's changing our world rapidly, but to not embrace it would be foolish. So that was kind of cool.
Brett: Yeah, I think it's somewhat in between the two somewhere like, Oh, everybody should be using it. And AI is of the devil. I think it's somewhere. Well, for sure.
Ryan: But I was, I was happy to see the Bitcoiners, seem to be sort of universally, I don't know if optimistic's the right word, but we're not doomers. We build things and we adapt, and so the attitude about that was pretty positive. So I just wanted to tell you all that Mujina is on the map with the rest of the Rust project, Bitcoin projects, so that was pretty cool.
Schnitzel: Is there like anything that was most surprising for you or maybe most surprising for them that you learned or they learned?
Ryan: Let's see. I don't know how to characterize this exactly, but I was a little surprised. Some of the projects seem to... Accept or use themselves a little more AI slop than I would have assumed for major wallet library, foundation libraries. You know? I mean, I think we review things pretty hard here. Or I do. And I don't, I don't, there were some things, and maybe this just depends on what area of the code it's going into. But There are some projects that take things pretty quickly, more quickly than I would have assumed. That was one thought that stuck out to me. Okay, yeah. And in the other direction, I had several conversations over dinners in Nashville with people. And these are Bitcoin gigabrains, right? Almost everyone is surprised by how closed source and backwards things are in mining and they're just not aware of it like the smartest people you know you explain what a dev fee is and how their miners actually phone home and hash part of their work to some other pool like and minds are just blown cuz this is just not common knowledge. So that was interesting. I don't, I guess that's not terribly surprising, right? Skot. I mean, we, I think we know this we've, we've seen this before, but I just continue to be surprised by, how much there is for us to teach the world about mining.
Skot: Yeah, it seems like a lot of people haven't paid attention to mining for a while, which is surprising being as it's an important part of the Bitcoin space.
Ryan: Yeah. So it's cool that we can raise that flag, I guess. And because that... While that lack of knowledge seems to be pretty universal, also universal is everyone's enthusiasm when they hear how we're trying to fix those problems. And everyone agrees they are problems, that open source is a solution. Everyone's really excited about what we're doing. So that's affirming and good to see.
Ryan: I'll share that most of my focus here lately has been working on the Mujina OS image that will get installed by the installer into an S19, S19 J Pros. So I've been a little light on the PR reviews and other stuff this week, or the last two weeks, partially because I was traveling and partially because I'm just trying to focus on this OS image stuff. And sometime soon I need to prepare. Maybe I'll take a half hour out of one of our calls and get out some block diagrams and talk about how all the pieces fit together. But it is a pretty major... There's a lot of moving pieces in Mujina, right? I don't know if I've... Sometimes it can be hard to communicate. But we have our whole regular software project, right? The process that does the mining. But like... There's probably 100 other pieces that go into what's really a full-blown Linux image that gets installed on these mining devices when we get us to the point of making it easy and on par with what a factory image or third-party image is so that it fully takes over a control board. There's just been a lot going into that, but I'm super excited. This is going to be really fun to release and work with. But there's lots to do and a lot of requirements around this to keep in mind. I think, what are some of those? Well, I think the last couple of weeks have been an increasing reminder that software is not a ship at once and then go away you know it's ossified kind of product like I have I have harped with companies I've worked for and clients for years like software is continually a living breathing thing you know for lots of reasons but importantly among them is security updates and I think we've get continual reminders of that but As an OS image, Mujina is going to be taking on a pretty significant surface area. For security issues. You know, our application itself is really not, you know, we're sort of fortunate, you know, we're not a wallet that holds people's money. But we have our own issues, right? But the, you know, the security surface area of Mujina itself is not probably not super large, like the mining process, though, you know, everything can become a vector, but probably the tougher surface area is the whole OS image, you know, because then we're shipping a hundred different open source projects and kernels, and you've got a fleet full of devices with images that fall out of date. And, you know, this, this latest SSL cert vulnerability is an interesting case study because on a normal Linux system, you've got system-wide security routes installed. But then depending on library choices that you or other applications have made, sometimes the route of trust does not go to the system and is sort of baked into libraries you've chosen to use. So in Rust, that can certainly be an issue. And then, you know, so when a vulnerability like this comes out and you want to drop one of these routes or intermediate CAs from your chain of trust, like that means a software update to the system and potentially several libraries. So you got to be able to figure out what your vulnerabilities are and ship updates to them. So I see your hands up, Brett. I'll let you go before I keep going.
Brett: I was just going to ask, do you have any, like, is there a specific plan in place for how you want to implement that OS image? Like, are you planning to do a Yocto build, a Buildroot build? Like, is there any specific thoughts there? Because obviously I have connections with James Hilliard, who is a large maintainer of the Buildroot project and could probably provide some insight there. But I'm just wondering if you have any preference.
Ryan: Yeah. I have used all of those. Ways of doing it over the many years and have various reasons to dislike most of them. But I am building a Debian derivative. So, I am not using Yocto or Buildroot.
Brett: Interesting. So, is it gonna be a relatively stripped down image then if you're building off of Debian?
Ryan: Yes.
Brett: Okay.
Ryan: Very stripped down. Know not build from scratch stripped down as far as you could get with something like buildroot but I also don't think for most embedded systems that that's necessary in 2026 to be that that small you know there are trade-offs with
Brett: I'd be concerned about things like the BeagleBone Black board on S19s, right? If there's ever a situation you wanted to flash to that. I think that system, as far as I understand, is pretty difficult. I could be wrong, but that's just what I've heard from the proprietary firmware developers is that that system is rough.
Ryan: Yeah, I don't know of any particular issues we would have with that. I've used those in the past. So, well, the idea, and this is something I should go into in more depth at a different time, I suppose. But the idea with the trade-offs we're trying to, that we want, the good parts we want of being a Debian derivative is, first of all, to be... Oh, man. Back in the day, we used to make a big distinction between source distributions and binary distributions. Meaning, you know, did you when you installed Linux or built it or updated it or worked with it, were you building everything from scratch from source code? Or was there sort of an intermediate step where which is sort of the way a lot of the world went. So you'll probably be familiar with this. Like, you know, if you install package XYZ on your Linux machine, it's pulling a prebuilt version of that off of a server somewhere. So that's what we used. That's the binary distribution side of things, which is, nice to work with for various reasons. But that's probably not the place I should have started. We wanna hang off of a major distribution like Debian. One of the benefits we would get of doing that is that they've already packaged most of the things we would care to use. They already build most of the things we care to use. They do security maintenance and packaging of those security updates. There's a whole package management infrastructure system that we can use to great effect in our own system for composing images originally and for network, for updates over the network or otherwise. And the idea here is just to do as little... For our, that, that is just, that puts the maintenance burden on ourselves as possible. We, it's sort of like the modularity we go for in other areas of Mujina, where we only wanna customize the things we care about our special sauce. And if we can benefit from open source in the way we always talk about, that means there's other teams worrying about their pieces because they're specialists in that. And we can sort of just reap the benefits of riding on coattails. That's sort of why ‑‑ you know, and that applies in various ways to all these projects. Sort of drafting off of being a Debian derivative like this. We've chosen that as our upstream, or I've chosen that as our upstream for these initial images.
Skot: And there's lots of projects that do Debian derivatives.
Ryan: So it's not always obvious. Done in the embedded space, but an embedded product like these control boards in the year 2026 is so much like just a standard Linux system back in the day that it really becomes possible. There's no reason that just because it's an embedded device, it needs to be built from source completely with special compilers, with special flags thrown to minimize. We're trying to take the easier route and stick to as standard of a Linux system as we can. Within our limits. So I'll talk about it more technically later, I suppose, once I've prepared. I'm kind of just winging it here and hand waving. But that's sort of the update, I guess. Skot, go ahead.
Skot: I just wanted to say, I think that's a great idea. I think it will be much easier for people who want to modify their own Mujina OS to get in there and start changing things, you know, like SSH into the system and start like, you know, APT install this and that and play around. And they'll probably see a lot of similarities to what they've done on Raspberry Pi or something like that.
Ryan: Yeah, yeah, 100%. And yeah, that's a good point. What you get on a Raspberry Pi is a Debian derivative also. So it's not like we're out in crazy, uncharted territory here. And yeah, and that hits the second thing I couldn't think of before when I was talking about the importance of updates as one of our requirements. Another one of our requirements is, or design goals, let's say, is that... We expect people to take our images as sort of a base and then we want them to we want it to be easy to add to or sort of derive from us you know at another layer to build like if you're gonna do I'll use schnitzel as an example though he's sort of out ahead of the ahead of the support we have to offer at the moment but like for riot like maybe ideally in the future like they don't have to roll as much of this on their own or some other product that wants to be derived from agina you know it's not just gonna One of the options that we're trying to offer is it's not just going to be about using the Mujina minor process, but like, hey, here's our OS image. You can make your own OS image relatively easily. Here's how. The same way you would derive from our source code or something maybe, like, hey, you can easily make a... Derivative OS image that fits into your own installer or whatever for tinkering and for people making products. So those are some of the things that this is designed to do. Like I say, we'll come back to that in a future week when I'm a little more prepared to demonstrate and talk about it. Let's see. This got a bit of a backseat to traveling and some other stuff because I needed to be able to sit down and think about this.
Ryan: But I saw the stuff you posted lately, Skot, about using the RHAP protocol in various places in other projects. And so I really want to get this spec extracted. And published to that repository, sort of just written up straight as a document. And I've spent some serious time thinking about what's already there. I will start and just commit with the document I have, which is about what's already there. But I think to make this widespread, before it becomes widespread, I think I talked about this to you in person. I'm seriously considering adding a few things. Because I'm uncomfortable with the current version's lack of frame delimiters. Because it just seems like this protocol is not going to recover well if there's ever any errors or things get out of sync. Or if you unplug a USB cable, in our case, and then plug it back in without repowering the device or something, Both sides stay up, but the cable just gets unplugged for a second. Or Mujina freezes and resets, but the control board has still been powered the whole time. There's just situations that aren't going to recover right now. So I don't know how, I mean, I guess until I write something up and you have a chance to look at it. I've avoided trying to make, you know, shoot, what's his name? K two or K three. I can't, I didn't wanna complicate his original K one. Oh, I was wrong. I didn't wanna complicate his original thing if I didn't have to, but I think the lack of, delimiters on these frames is something I wanna change. I don't know if you have any thoughts on that now, or you just want to wait until I have something to show.
Skot: Sounds good to me. Let's go.
Ryan: Okay. Yeah, frame delimiters, and then probably optionally the idea of introducing some kind of idea of a session. So you can open the session, and then if you get disconnected, like the... The board has the opportunity, I guess it doesn't have to, but has the opportunity to realize, oh, that got disconnected. I should put myself back in a safe state. And if it's using sessions, then when something like Mujina plugs in, it knows where it's starting rather than have to query all the hardware and figure out where's everything at right now. There could be a known... I'm actually starting like we, that kind of happens. We kind of take it for granted right now because we know we're the only thing that talks to this and we assume that, well, it's just been powered up. But like I say, in some of these recovery and unplug situations, like you can't assume that, you know, maybe you were connected to that device five minutes ago and you put the power supply in a particular state.
Brett: Like,
Ryan: And now you're connecting and how do you know what state it's in? So the idea of like a session that you could like start at zero might be nice. Okay, well, I will endeavor to get these written up soon this week because... Feels like we have a chance to sort of define it now, get it right now before all of a sudden it explodes onto all sorts of different devices. Oh, I think what I saw was over on OSMU where you were talking about advocating for this as a good... Maybe even build this protocol into... Bitaxe firmware so that it can be used for factory tests. And then maybe we can even use it that way in Mujina.
Skot: Yeah, I think we've got broad support for that. Replacing the Bitaxe self-test mode with essentially just a RHAP mode so that would mean RHAP would ship on on all Bitaxes you wouldn't have to separately install it if you want to you know use a bid axe with Mujina so it'd just be there but yeah we can cool you can definitely wait until you get this all specced out because it will need to be re-implemented in c and all kinds of good stuff there
Ryan: Which is why I really just wanted to address my nagging concern about the lack of recovery, like delimiters and stuff. Cause yeah, once we get this widespread, we don't have to, we don't have to make a change like that later. Better to do that right away. All right. I will keep moving. There's lots to potentially talk about here.
Ryan: I don't see Jayr here on the call, but the Stratum V2, make sure I see everybody. Yeah, the Stratum V2 PR proceeds forward. I gave, I think I talked about this a little bit last time, but I gave lots of feedback on it and pushed this commit here, number 125 of my own with some discussion that sort of updates some things as a base for that. Jayr reviewed that for me and then I merged it. This is just stuff on sort of the Stratum client side of Mujina. So shared stuff between Stratum V1 and V2 that sort of needed a few tweaks to the abstractions so that V2 would slot in nicely. And then Jayr rebased his stuff on that, and he's continuing some of those review cleanups. One of the things we're doing as a project is during that review, I thought of some things that might be nice to add to the Stratum V2 spec. It has lots of areas where it talks about timing out after a reasonable time. And there's a couple gaps there, like some of the stuff we've seen in Stratum V1 where especially with these security scans where it's like, well, how do I know if the pool has gone silent on me or if it's just waiting to acknowledge something or like, there's no, there's not a lot of rules in Stratum V1, obviously about server liveliness. A lot of it just happens sort of automatically because Stratum V1 is pretty chatty, but Stratum V2 is less chatty. So it doesn't necessarily send you a job, you know, every, 60 seconds or 30 seconds or something. A standard, by the way, which was sort of just de facto set by the way CKPool was implemented back in the day. So we actually gave some comments and commented on some stuff in the Stratum mining repo about the spec so that we can maybe get some definition to some of these times. Because we're finding as we implement a client, well, even if the spec doesn't really address it, we have to invent a number. We have to put something in our software. So I think it would be better if it's specified so that every puts, everybody thinks about it. And then we all put the same, some things into our software instead of having, the situation like emerged with SV1, where a lot of things were just defined by what people did and then what became popular, which is the whole, one of the things Stratum V2 is trying to avoid is, leaving things to chance like that or to emergence. So. So we're taking advantage of our being a part of the Stratum V2 working group and might get some input into the continued involvement of the SV2 spec there. So thought I'd mention that.
Ryan: Let's see, there are several small bug fixes here that have come in that I did not take the chance to review over the last two weeks. If anyone's here that did these and wants to talk about them, but I don't see the contributors here. Susan, I see you here, but we did talk about this last call, and I just didn't get a chance to look at it yet. So I still see number 118 there. Thank you, and I will get to that. Also, IxTech Sean submitted some stuff for Windows. Supports that I need to give a little, I did look through that, I just didn't get a chance to write my feedback. Seems like there's enough people out there that wanna see this work on Windows, so we'll continue to try to merge that stuff.
Dylan: There are dozens of us.
Ryan: A dozen, oh, Dylan, I missed an opportunity to make a joke at your expense. But see, I think of you as you're not gonna be a Windows user for much longer, so.
Dylan: You're right.
Ryan: That's why it didn't come to mind. Let's see. Any comments on PR stuff before I move on to issues, activity on issues? Don't think so, okay. Issues, I talked about this a long time ago.
Ryan: We sort of have an automatic bot in the repo that responds to Rust advisories on any library we depend on. So a couple of those fired within the last two weeks. What I do is look at them and see like, some feature in a library has a bug. Does it affect Mujina or is it like in some corner of the library we don't use? Because if it's the way to fix most of these advisories is to take the patch latest version of the library from upstream, but we don't wanna do that without, adhering to our, our cooldown period. Like to let dependencies we like to let everyone else in the world test dependencies for a while before we take them in case people have injected bugs or exploits into them or or whatever so we certainly don't want to take anything like immediately just because of a security panic especially if it doesn't affect us so that that is usually what happens is it's something in the library we don't actually aren't are not actually affected by and so we can just wait And we'll take the update in the normal course of time. So that was the case with three of them. There was a new one yesterday that I was out this weekend and didn't get a chance to look at, but I will take a look at that soon. If we find that one of these advisories addresses something we do use, then it's worth taking the update immediately and not waiting for our cool down period. So that's kind of how I'm approaching those. Someone reported some feedback here number on discussion 131 looks like they were running some experiments on bm 1370 chips in a NerdAxe or a NerdOCTAXE I guess and they gave us some feedback on the reference doc we have in Mujina. Skot, do you know who this is? Is this a person in OSMU that you're familiar with? The1Anubis was the handle? Is that somebody I know?
Skot: I don't think so.
Ryan: Okay. Not sure how they were aware of our BM1370 reference doc, but... Maybe they have a different name. I don't know. One of these doesn't sound familiar, but... Oh, yeah, their GitHub name could be different. Just a few minor things. They had tested some corner cases that probably aren't actually that important, but if you try to get a BM1370 to use fewer than four version bits, then it sort of messes with the design... The hierarchical design of the cores and sub cores and then they start repeating they start repeating work like there's you really can't run them below four bits of version mask which I don't think anyone would ever really try to do in this day and age nevertheless I We'll probably make a few patches to that reference doc just to completely document the chips as much as we know about them. So that was cool. Sounds good. Yeah. And then there's another bug that I haven't had a chance to look at. I think we sort of have a known problem. We're good at hot plug. We're not so great at hot remove right now. So a few bugs to fix there.
Ryan: Onto the Telegram channel, there was a lot of activity the last two weeks. Ronald isn't here, but he seems to be continuing to work on running Mujina on his RDSs. And he talked a little bit about doing the optimization and auto-tuning stuff. He also suggested that perhaps it might apply to other models of miners. I haven't seen what he's talking about yet, so I'll be interested to see that. Someone asked if we are ready for S19 J Pros yet. Gave an answer this morning that we're almost there, which is the same answer we keep giving. That's the image and installer stuff I continue to work on. There is, of course, at least Schnitzel's and probably Schnitzel's and Skot's, S19 J Pro sort of Vibe versions, and we link to those from the website. So I guess someone could try that if they wanted to. But I suppose it sort of depends on their skill level and willingness to take risks. And it's sort of just a lot different from the official version we're going to release. So I would probably just wait a couple weeks if it were me.
Ryan: There was some discussion about the APW power supplies. Skot, do you want to summarize that so that I'm not doing all the talking?
Skot: Yeah. Well, I guess the initial question was whether LibreBoard will talk to an Antminer power supply. That's called the APW-12 in this case. And it has its own... A terrible interface and special connector. And I think that LibreBoard and since looking at connection, correct me if I'm wrong here, but like the LibreBoard is not sort of out of the box targeting being a Antminer control board replacement. It's more of a development board for building your own control boards. And then a reference design for talking with 256 projects like the EmberOne. And so I think the answer there is no, there isn't a plan to add the APW interface to the LibreBoard.
Schnitzel: Direction yeah yeah so in the current version that we're building the idea is not to add any manufacturer specific pins or blocks or connectors or anything however I actually had a couple of people that asked me like how hard would it be to add S19 J Pro or just like Antminer connectors and APW stuff so right right now we said well that's what the Bitcrane is for and things like that but I'm just realizing that like for us it's easy to build pcbs there's parts in the world that is really hard and having one pcb and all so I am thinking about to maybe make like an a LibreBoard dash Antminer or something that basically just has an AditBoard on it already, or has all connected into one PCB, but that has nothing that has been decided. In the current form, yes, it does not have an APW connector, but you should be very easily being able to build a little converter board, because my understanding is it's I2C and one GPIO pin, I think it is. So you could literally build a hat that has this connector or just a cable that you plug into the correct pins of the Raspberry Pi. So it's possible, but it's not out of the box.
Skot: Yeah, I think that's the right move, at least for in the beginning, because then you can use a LibreBoard and set it up for whatever setup you want to do using AditBoards for connecting Antminer hash board data. And then I started a project after this comment on Telegram called the APWMeister, and it's basically an AditBoard, but for the APW connector on the power supply. These are just USB adapters to those interfaces. And yeah, I mean, I'm sure that will be helpful for Mujina development maybe. And then people who want to develop on AditBoards and use their Antminer power supplies and hash boards. So APWMeister is coming very soon. I have my AI working.
Ryan: Very hard on it this is going to be a entirely vibe coded pcb I'm excited to see how it works out I think I think that will be very useful because we've talked about these power supplies are so cheap and available they're good for lots of things so to have like a little USB adapter for that Again, something speaking our RHAP protocol. That'd be useful for all sorts of tinkering.
Skot: Yeah, yeah. I think so. I think so. We'll get this banged out and give it a try, and it'd be cool to deploy official RHAP to it, RHAP-D to it. Yeah. Yeah.
Ryan: All right, so that's hardware fun.
Ryan: Schnitzel, you announced that LibreBoard v3 is on its way.
Schnitzel: Correct. My Chinese friends are working hard on drilling holes and potting epoxy and stuff like that. Yeah, so the Revision 3 has been sent off to JLCPCB. I've been able to integrate most of the things that, Ryan, you already found, we found, like in testing LibreBoard rev1. I added a couple of additional goodies that we didn't even know about, but the AI is found. One of the things that we wanted to talk about that I couldn't do is a way to individually turn on and off the four USB-C connectors. They're USB 2.0, but they're USB-C connectors. It would have been too complex on where we are right now to change this because I would need to have to change the ground planes for all the powers and I had to just reroute a lot. But I did add a full USB hub reset. So you can reset all four and the USB hub at the same time. So there's a new port on the GPIO extender that we already added to run the to add some of the stuff. So there's now a reset thing and everything else pretty much should work or at least I couldn't find any more issues. I'm also trying to get them fully assembled from JLCPCB. And for anybody that wants to know, five cost around $1,000. So if you order five, it costs you $200 a piece. But that obviously goes massively down as you order more. And the idea, obviously, is not to have them manufactured. But people sometimes ask me, what will it cost to generate them in small quantities? And that's, I guess, we now know. Yeah, as soon as I will receive it, I will obviously test all of the five in my bench and then I will send them around. So Ryan, you will get one. Skot will get one. I've also met with the Jua Kali people from Gridless. They will get one. And there's a fifth one that I don't know yet who wants it or who will get it. So if anybody has a good plan with it, let me know. Yes, what I'm also doing, I'm working now while I'm waiting, I'm working on documentations. So Ryan I definitely would like to have your review right because you're basically the most the person that needs to build against it the most but it's going to be on the GitHub repository so I will share it around as soon as it's there I want to make sure that we have a really good document tape and specifically like these things like how to attach different miners and what to do what the thinking behind all of that is I think that's going to very important because people think that this will work out of the box and things like that. I don't want to spend too much time talking about it, but yes, it's happening. If anybody wants to review some documentation, it's going to come on soon.
Ryan: Yeah, very cool. And that reminds me about yet another one of the design, goals, of the OS is that it, has to be portable to lots of different. Portable with minimal changes to lots of different hardware platforms. So the S19 J Pro is, you know, that's the Bitmain stock control board. But we also want to be able to install basically the exact same thing, modulo, you know, hardware drivers and stuff, differences. To the LibreBoard. So we are keeping that in mind.
Ryan: I didn't put it on the list, but Skot, you also teased a picture of the Bitaxe Bonanza.
Skot: Yeah yeah got a Bitaxe bonanza version one zero zero four and it seems to be working pretty good I am going to I got five of these made at jlc pcb see you later schnitzel I got five of these made at jlc pcb I have them do the whole back side that has like 99 of the parts and then I solder on the asics myself so that takes a little bit but Yeah, I gave one of them to Johnny already. He's working on the firmware. He's reporting great success so far, but I am waiting on the new display board to come in. That's a separate PCB. So as soon as that comes in, then, yeah, I'll give them out to, I guess, key developers like you, Ryan, to play with. Yeah. Yeah. Seems to be working pretty good. Knock on wood.
Ryan: Very cool. Well, thank you. That will help. I'm, I'm excited for that. Cause that will help me be able to merge anything that Johnny and Ronald contribute on the BZM2 chips.
Skot: Yeah, hopefully it'll be a good development platform for experimenting with Mujina drivers for the BZM2. It's got four BZM2s on it. They're all powered in series, so you can play with what it means to ramp it up, the frequency and the voltage to get the domains balanced and things like that.
Ryan: Sweet. All right. The only thing I also listed on the agenda was that IxTech Sean also mentioned that he had run Aadhi's Vibe on the Nano 3S. So that's cool. Yeah, well, open floor for the next couple minutes.
Skot: I had a really exciting discovery this morning and last night that is sort of relevant to Mujina, but the Bitmain A6 in the S23, the BM1373, which is actually a BM1372 with a different label on it, but... We determined, and it appears to be working in initial test cases, that we can read the voltage of each of the chip's internal cores digitally over the chip, as well as the chip's die temperature over the serial port. So that is fantastic. Yes this is really cool this is something that's been sorely lacking from bitmain chips for a long time and it's just because I guess we've never figured out how to do it and so that seems to be working and then just you know banging on my ai agent we actually figured out that the same thing is true for the bm 1370s this is insane blowing my mind you're kidding we've been been playing around with these chips for so long and just like really wish that this was the case that we could measure we could digitally measure the temperature and the chip's internal voltage domains digitally and turns out it seems like it's just been there the whole time so this is exciting You know, I felt like it should have been there. It really, it seemed like insane to not have it actually.
Ryan: Does it go through that CORE_MAILBOX register or is it like directly on a register that you read or write or something?
Skot: Yeah, it's directly on a set of registers that you read and write. It appears to be like a raw ADC.
Ryan: Wow. And per, how granular is it, did you say?
Skot: So the voltage is per internal core. So that's four on the BM1370. And I believe, yeah, four on the BM1372 as well. So you can get voltage on each of the cores, and then temperature just appears to be one temperature diode for the whole chip.
Ryan: Wow.
Skot: We have one temperature ADC. And it does appear that Bitmain firmware is heavily oversampling it, too. So it takes a while to do a reading, because you need to get many temperature samples and average them together.
Ryan: How did we not see this in stock firmware traces?
Skot: I don't think stock firmware does it, which is insane because I found this out through disassembling the S23 firmware. And it straight up has the functions there to do this. So, yeah, not really sure. I've never done a dump on a S23 communication, but... I don't know if they just decided to add it later for the BM1370. Very unclear.
Ryan: Wow. Well, that's super exciting. Where will we be able to find your research?
Skot: So it'll get, it'll get pushed out in a new version of ESP-Miner, for both the Bitaxe Naja and the Bitaxe Gamma, pretty soon need to give it a little more testing, and need to make sure that the temperature readings are real. That's pretty important, for the whole function of ESP-Miner. Yeah, it'll be, it'll be published as a part of ESP-Miner.
Ryan: Well, cool. Can't wait. We will steal it as soon as it's available.
Skot: Please do.
Ryan: Yeah. Awesome. All right. Well, thanks for showing up, everybody. We got a hard deadline this week, so I will see you all online and in the next call in two weeks.
Susan: Thanks, Ryan. Talk to you later.
Ryan: Thank you. Thanks, guys. See you, Susan.
Dev-call summaries and transcripts live in the Dev Calls discussion category. Transcript pages here are linked from their discussion threads.