 Hello. Hi, Unexpected Maker. Hi, Piata. I'm trying a new mic setup today. Hopefully it's good. I saw Yanni was waiting with a deep diver gif. The window's all squared away here. You can hear me though, right? It looks okay on my end. It's just going to be mono. Loud and clear. Awesome. I was listening to it. It was a little bit fuzzy earlier, but um, we'll see. The nice thing about this is I don't have to worry about moving around. And I am trying the ultra low latency on YouTube as well, so we'll see how that goes too. I forgot to move my... I can always go to the old audio. You can you can hear me on the other mic now, I assume. Something happened on the USB, I think. Ah, bummer. It looks okay. So yeah, so this is the other audio. I don't know what happened. Failed to read out thermal zone. I don't see any... this is all like boot stuff. Oh, that's garbage. I wonder what happened. I mean, I know Linux hates USB, that's for sure. I was hoping this would be a good solution. OBS doesn't see it now. I got a Scarlett 2i2. It looks like it's okay. Hang in there, folks. I know you're... You all are great. Unplugging it and plugging it back in. Oh, DCD's reading the USB book. What makes this harder is there's a cat on my lap right now too. There's the plug. I'm surprised it ends on my lap even though I'm talking. I re-plugged it in. Yeah, I'll be better. Sorry. I don't know. Okay, I'm moving back to the old system. That's unfortunate. It just like disappeared from... It disappeared from OBS. Like I had it in there and then it wasn't. Sorry, folks. Hang in there. I'm just gonna get my headphones back on as a way to make sure that I'm somewhat close to the mic. I had too many cables on my desk. Oh, maybe it got... There it is. Vin, pick it up. All right, kitty, get up. I know, I know. Sorry, folks. We'll get going here in just a second. She had to file her complaint that she was getting kicked off. I knew today would be like that. Trying out a new audio thing is always, always sketchy. I guess I could have tried it like under the hood. Okay, we're going. We're using... Let me know if that original audio was much better, although I think I recycled all the packaging already. I shouldn't have done that. But yeah, we'll go with this today. It should be fine. So let me say hi to folks. Yeah, M. Lindholm. Thanks for saying the audio was back and gone. Hey, Dave. Hey, Bruce. Hi, Pierre. Hi, unexpected maker. KeithyEE. AskPatrickW. BruceS. Hi, Charles. Hey, Dr. Hi, Huha007. Thank you all for hanging in there. Hi, HamzLabs. Hi, Skr. They were going good until this is loud. I can turn it down. Happy Friday, Linux 203. This should be kind of what it normally is. Hi, Xmicron. Okay, let's get going. Let me hide the... Not this. Oh, we might do KeyCad. I don't think so, though. I hide this. And we'll do housekeeping first. Hello, everyone. My name is Scott. This is a deep dive with Scott. That's me. I work for Adafruit. They're an open source hardware and software company based out in New York City. I work for them on CircuitPython. CircuitPython is a version of Python designed for microcontrollers. So really small, inexpensive, easy to access, easy to put in lots of different things, sorts of computers. And we try to bring the Python language to that. So it's really the merging of software and hardware in that world. So that's what CircuitPython is. That's what Adafruit is. This is a deep dive. They happen normally Fridays at 2 p.m. Pacific. We're a little bit late here today because I was trying to use a new audio setup that properly stopped working right after I started using it. So that's great. Really good. But we're back with the old system. It should be just fine. It should be solid because it's what we've used for a while. Yeah, so this is a deep dive. If you have questions, I'm happy to answer them. I'm kind of in the middle of something. So we'll dive pretty much right in. Yeah, so they typically run for about two hours. So we'll be here for two hours. So that's plenty of time for questions if you have them. And next week we'll be on Friday as well. And then the next week after that, I'm planning on taking off. So the first of October, there will not be a stream. So one week from now, there will be. And then two weeks from now, I'm out of town. So there will not be. And is that all the housekeeping? I guess the cat down here, that's Spook. He's usually in here. The other cat that was on my lap is Vin. She usually doesn't like it when I start talking. So she peased out. So Spook is epileptic. Occasionally he has seizures. But it's been actually, he's been really doing really well. So that probably won't happen. But I just like to give folks a little bit of a heads up for that. Yeah, could I set it up to automatically do like two hours of Spook just sleeping in the window? Yeah, it's getting rainier here too. That's what Bruce is saying. Hey, what's up? Bed intruder. Okay, so let's, I haven't seen any, yeah, open source lo-fi kitty cam great filler. Yeah, I won't be here to run it. So we'd have to teach Vin how to run it and Spook could just sleep there. All right, so let us dive right in, I guess. I haven't seen any questions come up. So if you have questions, otherwise what I've been working on, I talked about it a little bit on show and tell, but I've been trying to get tiny USB running on the Raspberry Pi, the Raspberry Pi, not the Pico, but the proper Raspberry Pi. This is something I've talked about the last few weeks. But because unexpected maker picked up the S3 work and I looked at the data sheet and was like, hmm, like the only thing that really needs a lot of work on the S3 is Bealeigh and I don't, I need a break from Bealeigh. So something that's been on my mind a lot is bringing tiny USB and circuit Python to the Raspberry Pi 4 in particular. And so I've been working on that and haven't been making a lot of progress, but it's like learning all about it. Yeah, I'm sorry, I'll show you what my setup is. So unfortunately, the only power supply I had for the for the CM4 IO board is actually the one that I use for the overhead. I ordered more from Digikey, but it doesn't come until next week. So I'll use Catcam here. Hi, Wendy. Yeah, we'll go to Catcam here. You can see there's Catcam, there's Spook. So let me show you the setup here. I won't be able to show it kind of like all the time, but I will just, I'll give you an overview of what I'll be working with as we work through stuff. So there's the cat and I'm going to use Catcam to fly over here and show you my desk. So the setup that I have here is I've got this salier and I was running these wires into the IO headers of the, of the, so this is a Raspberry Pi 4 CM IO board. And sorry, this, this Catcam is not the best cam. The overhead's better, but we'll use that next week. So here you can see there's this CM4 module that's set down onto this board that breaks a lot of stuff out. So CM4 is compute module. So this is like a Raspberry Pi 4, but in like a, put it on a different board sort of form factor. I had the focus reasonable. There we go. And so the regular Raspberry Pi header is over here. And what I've got going out is these, these three wires are UART to a UART to USB converter. So that's how we'll monitor your UART output. And then this bundle of wires here is to a J-Link there. And this is the new audio focus rate thing that I, that wasn't working. Um, I've got power on a switch. So I can turn the CM4 board off and on. And I've got this, it's an SD card reader. So if I need to flash a new SD card, that's what I'll be using. So that's, that's the setup that I've got. I haven't actually gotten to the point where I'm testing USB. So when I test USB, we'll be plugging it in there, but I'm not there yet. Um, unfortunately. So can you get a GPU to run with that PCIe header? There's a, look up Jeff Geerling. He's a YouTuber that does a lot of Raspberry Pi stuff. And he's tested multiple GPUs on this header. So yeah, I, I think some of them can, um, but I, that's not what I'm focused on. So yeah, check out, check out Jeff Geerling. He does a lot of stuff in that vein. Testing and things. Wow. Look at that white balance change. Okay. So that's the, there's the overview of my desk, as it is right now. And you'll notice there's no keyboard because I have the keyboards out here on these mounts. So yeah, that's what I'll be messing with. And we'll go back to spook cam now. And I'll stop making you ask Patrick. W asks, uh, what Mac, what macro pad shortcuts do you have on that? Um, I basically only have one, which is play and mute, um, play and mute the, uh, my audio that I'm listening to, like the music I'm playing. So yep. So we're back at cat cam and let's go to the desktop here. And I'll pull this up first. So yeah, I just wanted to give an overview of, um, you can see I have the notes in the background. So a lot of what I've been doing is, uh, trying to figure out just like the development workflow. So, um, they're more complicated. Um, they're a lot more complicated. So a Raspberry Pi, uh, proper, these are what are considered Cortex-A, A-class, um, microprocessors. So they have, they're microprocessors, I think largely because the RAM is actually a separate chip. Um, and it's four cores, um, for the Raspberry Pi 4. Um, and those cores are like fully capable of running Linux or anything. So, um, what I got here is I've got, this is the USB to serial, the UART to USB output. This is my debugger. Um, and let me pull up the code. So, um, I've been cribbing off a number of, a number of sources that I will have to pull out into this other browser. Um, what about peripherals? So I think the peripherals are pretty much the same. Um, so, uh, let me see. Sorry, I just got the text message. That's why my brain stopped. So there's these files that you can get that are these, they're not full data sheets. They don't like to disclose, particularly this stuff about, um, the GPU side of, um, the GPU side of, uh, of the Raspberry Pi, which is actually the main bit that, the main thing in the chip, uh, the BCM 2711 or 2835, like the main thing is actually the GPU. It's not the, the ARM cores. The ARM cores are just kind of like off on the side. So this is, uh, you can find data sheets for their peripheral trees. Um, but you can't kind of like find the thing overall. Um, but this will tell you like physical addresses and stuff like that. Um, and this is not for the right thing, but I thought I, I had it open. So I thought I'd pull it up. Um, yeah. So this is not for the one that we, we need, but, um, you could basically treat it like, like the peripheral side of things is, uh, pretty similar. Uh, it's pretty similar to, uh, like a microcontroller. It's just a memory bus with registers for different things. Um, the CPUs are actually the part that's a lot more difficult. Um, so doctor asks, so what's the big advantage you expect to have using a Pi with CircuitPython on bare metal? And the answer is, uh, HDMI. Like, hands down, that's the reason I'm doing this is because, uh, the way that it starts up is the GPU actually starts and gets everything going. And then it can, and then it loads stuff for the ARM cores and then runs the ARM cores. So the way that it works and let me, sorry, I have a ton of tabs open that are on this other Firefox window that I should drag over here. Um, because I'm sure that we will reference them. Maybe. Yeah. Oh, we want that. Some of these tabs I haven't had open for a while. CM4 data sheet. I have a lot of tabs. Yeah. Okay. Here. I think this is it. So there's two, two places I've been really referencing. So, um, I should give a shout out first to crowd supply. Um, the Pai Unora, which is probably not on the, oh, here it is. So this is one of the reasons I'm interested in it. And this is, uh, an idea that I came up with, uh, kind of in collaboration with Timon. Um, so this is a, it's a Metro shaped Arduino shaped, um, is the RPY4 essentially a GPU with a few ARM cores attached to it? Yes, I believe so. Yeah. Um, isn't that a bit against the whole open source spirit of the project? The fact that the GPU is closed? I mean, none of the stuff that we're doing either, like I don't have access to closed source stuff nor will any of the code that we write be closed source. Um, the GPU, yeah, is closed source, but it's documented enough to be able to spit stuff out. So, um, yeah. So Timon did this Pai Unora, which is really cool. And I, he sent me an early one that I've stashed away. Um, but the idea being that you can treat this, like Cortex A level thing, kind of like a, a regular like microcontroller. And, and you get this weird world of like a lot of power, but, and some things like HDMI and PCIe, but you could treat it like it's a circuit python thing. So I, I love like mashing those two things together. And this is why I'm really interested in it. Um, so check this out if you haven't already. Pai Unora is pretty awesome. Um, and then Timon was starting to work on circuit python. And one thing he linked me, linked to me too was this, uh, I sometimes, uh, Raspberry Pi 4 OS Dev kind of tutorial. And this is a really great reference for very simple bare metal things. Um, so you can see it's like 12 parts. It's sorted a little weird because of the last three. Um, hi, Johnny. Um, but this has kind of got me going. And you can see here that part five is frame buffer. And so it's like part five where they start to like poke things to the GPU to show things on the display. Um, which is awesome. Right. So like a bit confused by the Pai Foundation using a relatively closed thing for the pies. That's all, I think the reason that is is because like the folks that started the Pi Foundation used to work at Broadcom. Right. So like they had all the background on those chips to begin with. And I think they worked on those chips. So they, they they had access to the closed bits. Um, and this is why like Beagle Bone Black is meant to be a, an alternative that's more open. Right. You can use that if you like. Um, but the fact that the GPU actually starts up these chips is actually quite beneficial because it simplifies a lot of the work that we would have to do. Like we could potentially do like other Cortex 8 level, um, stuff once we kind of get it going for Circuit Python and tiny USB. But the startup stuff is different. So like Raspberry Pis are actually a bit simpler from my understanding because the GPU does a lot of that work for you. Um, yeah. So there's this tutorial that's been really helpful. I kind of picked, picked which ones I wanted to do. You could see that they have frame buffer and then they have Bluetooth as well. So Bluetooth would be cool. It's done by a separate chip. So maybe that would be something that we'd be able to do too. The other thing that would be really interesting is on the Pi 400. If we could do USB host, we could use the keyboard and you'd get like a self-contained Commodore 64 era style Circuit Python experience, which I think would be kind of wild as well. So I think bringing Circuit Python to your TV is like really interesting. And I'm really interested in it. So obviously, um, okay. So this is some USB stuff. So Blue Child did actually did a Micro Python port. Very much similar to what I was just talking about where it has USB host. Only if it looks like a C64. I mean, it looks like an updated C64. Good night, Felix. Yeah, well, there will be a recording and check the notes at the bottom for time codes and stuff. That way you can skip around. Can you use a VM and run Raspbian and Circuit Python? Folk knowledge, that's a great idea. That was one of the things I was thinking about doing on the stream is using QMU to figure out what's going wrong because it wasn't working. Let's see what else do I have up here? I have, so these are firmware files. So some of these files you need on the SD card. So basically what you do is you come up with this kernel image files, what you compile, and then that gets loaded by the GPU and then run on the on the ARM. Since the GPU starts up the CPU cores and all, could you have four instances of Circuit Python across the four cores run independent of each other? You could, but they would have to know which core they were on so that they wouldn't clobber each other. And then I don't know what that means for USB, right? Because there's only one USB peripheral still. But yeah, potentially. Circuit Python don't virtualize hardware while that's going a new direction. Well, Urish is actually like working on that. There's somebody in our community who wrote their own RP2040 simulator in JavaScript and they have Circuit Python booting it in the browser on it. So here's the peripherals data sheet for the 2711. Here is the USB source code for Linux as a reference. I just got JTAG working, which I'm very excited about. Although it's like half working. Here's this, this is the device tree that tells you like address ranges and stuff for different things. So I'll take a look at that. That's like, oh, once we get to the point where we're actually like implementing I squared C, we'll need that. If there are enough PCIe lanes, maybe each core could be given a USB controller on a PCIe lane. I think it only has one or two PCIe lanes. Yeah, I hadn't thought about like doing USB over PCIe is a whole other thing. Okay, so this is kind of like the state of my brain. Oh, this is the other thing I've been referencing. There's this Raspberry Pi OS repo. And they have this lesson about interrupts. So they talk more about interrupt stuff. So what I was doing is trying to get, yeah, so interrupts are different than Cortex-M. Because in this land in Cortex-A land, it's designed for operating systems. And so it has privileged levels. And when something happens, it raises what it calls an exception. And that gets handled like by a different, by a higher privilege, privileged level. So there's like this whole mechanic of exceptions. And then interrupts are like some subset of that. We can see here that like there's this synchronous exception, IRQ request, fast IRQ, and then the system error that can all happen. So, and then what you do is you, if you get this IRQ exception, then what you do is you read from the interrupt controller, which one it actually was, and then delegate. So I was working on that. That may be one of the things I have to do, but I actually had to do a little bit earlier work of just getting the UART running. So let me show you what I've got. So I've cribbed what you see here a lot from those two tutorials, the Pi OS 1 and then the bare metal Raspberry Pi 4.1 as well. So this is not all my code. This is code, they're liberally licensed. So I've been copying it. So this is, this is the code that starts. So when that kernel.image is loaded, it's loaded at a particular address, and it just jumps to it. So this is the first thing that you'll do. And here it's doing a check to make sure. So I think it must run this code on all four cores. So we make sure that if we're core, not core zero, then we just wait infinitely. This sets the stack pointer, and it loads us at 80,000 hex. So the stack actually lives lower than us, which is fine for now. This is me trying to set the vector table address. There's a similar thing in Cortex M zero. But I think there might be multiple of these. So I'm having some issues there. This set sets all the BSS section to zero, which is all of the variables that start at zero. And then it jumps to main. And in case we return, then it loops indefinitely. So that is kind of like this is all assembly. And then this is me trying to do the interrupt stuff, which I'm not sure is working yet, but it compiles. So that's okay. We'll look at that later. And then most of this is in tiny USB. There's two spots, three spots, two spots that we have to look at. So what I'm trying to do is this CDC mass storage example. And you can see the build artifacts end up here. But the things that I'm actually changing are in the board support package for the CM4. So family.c has most of the stuff family.make. And then there's a MCU support stuff. So that's where the boot startup assembly is interrupt stuff and IO stuff and the linker script. So that's kind of like all the stuff that I'm changing. And this is in tiny USB. This is not in circuit Python. This is all I'm trying to like get all the tiny USB stuff going before I we have like Timon and I have a branch that's starting to get circuit Python running on there. But this has been a really good lesson in with tiny USB because you're you're shrinking down the amount of code you're doing. It's easier to manage. And so I spent a couple of days this week just trying to get it all building. My gut is always to use clang. But it turned out that clang needed libraries anyway from GCC. And it was calling out to GCC. So I finally just switched it all to GCC and that went much better. So yeah. Simon says you could run circuit Python on three of the cores and then have the fourth core for a management and user interface core and the USB run on that. And then you can jump between circuit Python instances via there. Pia says looking at assembler is like looking at grains of sand and a brick that's part of a wall. Yeah. It's pretty short which is nice. One thing it doesn't have to do is loading all of the read-only data because it's already been everything's already been loaded into RAM. That's something the GPU does for us I think. Okay. So the main thing here is so the USB peripheral itself in the Raspberry Pi is a peripheral that is licensed from Synapse. No. What is it licensed from Synopsys. That's what it is. So in source portable Broadcom I just copied a Synopsys directory and that's straight out of ST. So ST uses the same USB peripheral in ST devices that Broadcom uses in its broad in these Cortex A class stuff which is great. So most of the interacting most of the difficulty of this will hopefully be finding the quirks and like getting everything running. It hopefully won't have to do with like actually interfacing with the peripheral because it will be ideally pretty much the same. But I haven't gotten that far. So the two things I've been trying to figure out first is just blinking an LED and getting the UR output because the UR output was not being very reliable for me. So in family.c here this is in Bordnet and this is Bordnet is like one of the very first things that is called by one of the very first things that's called once tiny USBs main for the example goods run. So here you can see this is me blinking an LED. So these these no ops here are weights. So that's just like making time go by and then setting true and false for 42 is the pin that the LEDs on an 18 is one of the pins that I have the CLA on. And then I have it doing UR prints and those weren't working and it took me a long time to figure out why which is why I was getting to the debugger. Yeah it's funny you say blink blinking an LED is square one but I thought it was hilarious that this Raspberry Pi for OS Dev tutorial doesn't actually blink an LED. It goes straight to UR. So I had to kind of like figure it out on my own and like none of the documentation is really good for like what pin number is that on like I had to dig into the device tree stuff from the kernel. It's a huge gripe of mine that all a lot of these Cortex A class chips are not very well documented because what the creators of those chips do is they just add they just add Linux support and they call that good right. This is the class where it's like Linux is the de facto thing that you run on it and therefore all the documentation is really not that great which just frustrates me to no end. So I have this example it's got hello to GDB and I actually the next step I wanted to do is just rebuild it reload it from the start and see if it works. I got it reloading somewhat over GDB like this is GDB here and I'm using using open OCD to connect to it but yeah let's shut that down. I wanted to give it a shot. I found this I was doing something really stupid so what what I was doing before and so here when I was saying const care start greeting blah blah blah I actually had it in the form const care greeting and then array but this is a problem because this uh this returns the pointer not exactly the same type so I was having crashes due to that and I think I finally figured out my problem which is I needed to do this so I want to kind of start from square one and build the example so it compiled family.o and it linked it together and now I have another kernel image. So the SD card is in I'm in the right directory so I'm going to copy that over and I'm having KDE is crashing if I eject it so I've been doing it that way so now I'm putting it microd yet SD card in and turning it back on and it takes about I was surprised by this it takes about seven seconds for the GPU to boot right so it still didn't work I saw the blink and then it stopped working so something is still funny yeah 30 kilobyte was the array also on the stack yeah like the address was on the stack it was it was not right um okay so now it's not working unfortunately um it stopped blinking but we never got any your output um so it definitely got somewhere down here yeah seven seconds that's a lifetime at this level um it's not running from the card so what happens is that the GPU copies the kernel image into memory um so this is non-interrupt ur output correct so it should just pull that there's space in the ur before it writes um okay but it didn't work so and we just loaded it so let's actually do the jlink um and then here we need to reconnect to open ocd load and back trace oh I think it reset us so I've been doing a break at what actually I think I have a break points um yeah so here we can do like info registers and this will give us the registers of core zero which is awesome so we have a break point at boarding it so and we're at the program counter here is at start so this is where it loads us in um so we're going to run it we break at boarding it and here you can see it's printing out information about the other three cores you can see that they're just halted um which is fine so here we are in boarding it and we can do info locals and we can see that the greeting here is correct um so let's just continue and it didn't blink or anything and now we're at this address 200 and there's like garbage in the stack so this is if somebody out there has worked with cortex a's and has seen this let me know so my working theory is that something is happening obviously and um I was thinking that maybe it was uh trying to so there's different levels of um of execution that's I think EL might be execution level um any watchdog timer is going off maybe um yeah so I think right now it's not set up so that all exceptions get caught by my code so there's there's three levels there's one two three and I think there's a there might be a level zero as well um so what I was just starting to look into is like uh yeah okay so here's there is these exception vectors so this is for a single thing oh phomy guy's pointing out that you can use blinca display i o to output to hgmi yeah populate all the other exception vectors yeah that's what I'm thinking um like there's this vector table base address um show invalid entry message like v bar el one I think is set let's see what this does but I wonder if there's like other v bars that we have to other system registers um exception vectors the exception vector exists in a vector table at the exception level the exception is taken to each exception level has an associated vector base address register right so that's the v bar thing we're only setting one of them yeah rufus it is funny that array and pointer made a difference it's it's a subtlety and like that's a common mistake I make with pointers it's just like you have one too many one too few um so this offset here this 200 seems awfully suspect um I wonder if somewhere in here there's so what if we just set all the v bars to the same thing reset vector address like is there v bar el I guess we could just see what the compiler thinks the compiler knows um s zero one two and then linux after it it has a it has an isb um which is a instruction boundary see I'm I'm not confident that if I set this now well let's see if it compiles I think I might want to like restart the device unknown or missing system register name okay so zero doesn't exist but I think there might be a three so we should be able to handle them all and what we would do is we would just end up in okay so that built um let's let's just do it the full way to make sure that we're in a known state I'm not sure how much of the CPU resets when we just do a mon reset so this is one of the things I knew would be this is probably one of the hardest parts I I expect for for getting Cortex A is going it's just like figuring out how interrupts work and there's two different interrupt controllers on the different Raspberry Pis there's like a classic one and then there's a standard ARM one um which actually and and these exceptions will vary with the CPU as well so watch this and I'll stop this OCD because that's going to be bad so I'm going to wait for the blink and we can actually see where it is this is so much fun we're still there nice well I don't know if that worked then is it's finally cold here she's like you you're taking my favorite bed you jerk okay she's left again um I don't know what do I print system registers don't sure I can see so we're the stack pointers there the program pointers there but if we do a mon reset the program counter doesn't always change which I think might be be maybe we're in an exception state already um how do other working demos and Linux initialize the registers so the working demos don't do interrupts at all and they seem to work um so I don't know what I did find is if I do jump start oh I still have the breakpoint that's gotta be an exception handler and it might be all right let's read more up on this there's gotta be a way to read this state okay exception classes and the esr el syndrome registers if the exception is a synchronous exception which I wouldn't expect or an s error interrupt information characterizing the reason for the exception is saved to the esr el at the exception level the exception is taken to the information saved is determined at the time the exception is taken and has not changed the result of the explicit synchronization that takes place at the start of taking the exception the additional use cases as well yeah I mean mainly for me it's just HDMI like I've looked and looked and looked for ways to do HDMI that are low cost and like just really hard to ignore the raspberry pies for that okay so esr el x those are we have those in if we do info registers we see that we have esr el zero esr el two so so one and two are empty but or yeah one and three are empty one and two has something in it so it's got let's see four and then 200 so let's see if that makes any sense compared to what we're reading I don't think so what bit is that two in is indicates the cause of the exception listing the valid ec field values okay so the esr el two esr el two has let's see this would be 36 bits esr el two is made unknown as a result of an exception return from el two like zeros is unknown reason and that's probably what it is let's see 24 bits each hex character is four oh so we do have a two in that next field not here but you see I guess would be one then huh trapped wf instruction execution does that make sense iss encoding like this the iss encoding the iss s is is blank i don't know what this is that too would be the 26th bit i am like gonna be toast after this but i can't find a lot of good resources for this so hopefully hopefully this video will have does the i o have different trust zones that need setting up i mean maybe but like the other examples i've seen for ur do not the 25th bit what is that what is that bit that i skipped over i l l is what instruction length on a warm reset this field resets to an architecturally unknown value pc alignment fault exception stack pointer alignment fault exception any debug exception except for breakpoint there is a breakpoint instruction um i mean that seems plausible to me that it's an alignment thing i don't know what else do we have here like this looks like junk but maybe it's not el r e l s p s r i think is that stack pointer for the particular level let's just see if we can see what el r el el r what was it it's not what it was el r el not found el r el to run code at non-secure hey set could you instruction trace in gdb until it crashes yeah we could try um i'm really like for some reason like reset doesn't work but like the program counter is still 200 which i don't understand why reset doesn't work um like the stack pointer is where we want it but not the program counter but if we do jump it still does it um it could be like a bad address what happens like i've gotten output from this though that's what throws me off is like i don't think i'm doing anything weird that i haven't done before um i mean maybe it's an interrupt maybe we should try to read the interrupt register like if it was an interrupt that we weren't servicing then we would definitely have a problem let's try to read this i appreciate the pain during debugging and trying to figure out how to make progress anyway well that yeah that's what this is all about okay so there's nothing pending at that register which is some magic address i pulled from somewhere um i mean there might be like i don't think there's like an svd file so it doesn't look like there's anything there yeah it feels like an instruction alignment problems to me um the other approach i was taking was i was and maybe this is worth doing too is the reason i have this alia out is i can have the code set pins high and low as it progresses so with this is like this is what i was doing before the debugger so that you could see like the sequence of things starting up which might be worth doing to figure out where it's stopping print to a pin debugging yeah the nice thing about using pins like that is that it means that your code can keep can keep running which should not be underrated same with printing it would be nice if we were printing but that might be our problem what did i change i don't know i don't know let's see if we can get the gdb2 grading out which is commenting that i feel like this print call has caused me a lot of headaches even though i thought i fixed here as well so let's just give that a shot um and let's make this a while true so we'll just hang out in this loop faster than printf to serial yeah 100% pins are pins will be faster okay so i'm gonna rebuild in this and again i'm gonna just do it without the debugger i just don't trust the state that the cpu that the debug debugger gets the cpu back in which is why i'm like starting fresh which is a pain but this will bring up stuff i'm looking for the blink that happens before the print nothing i mean maybe we're faulting sooner now that could be entirely possible like i wonder like we added these things if we go back to just the one this is all like i mean i'm learning like a new class of cpu so you can't expect it to go perfectly smoothly what does the logic analyzer show on pins i it's not hooked up right now um i will hook it up shortly i am curious how circle initializes we remove let everything crash and come back because you know that's good yeah i should do the there's the blank and there's the hello okay there's a startup 64 let's take a look at it armstub there's a start read write cache latency floating points in EL3 vbar setup gic so that's gic is the interrupt controller switched to EL2 oh boy haha startup 64 and live chain boot works oh it's from u-boot enable EL1 access to timers oprocessor traps init exception vector table i didn't realize there were so many bare metal rpi projects out there not enough uh start second area okay that's for the second core check if we're in EL1 t mode i don't want to actually take anything from uh gpl stuff though i mean it could be an exception level thing it would be nice just to figure out how to figure out where where the heck i am um let me just cross my fingers and hope i did have to add these knobs into here 42 is the led build again i wonder if the 200 is just like from the debugger but i've definitely had it before where it wasn't i uncommented something and it's smaller by 80 bytes like how does that make sense i should set the cv back up the led is off we did not get a second hello to gdb2 where are we where oh maybe this stopped us oh we're important it yeah see that's the problem is i can't really oh i mean that's where what is my stack pointer when i'm trying to do the stack trace the stack pointer is what i would expect it's 7 f f d0 so what is how is the stack initialized in the in the way the debugger expects that should be the compiler like the compiler should be doing all the proper stack stuff um when bordenet or when main is called right so we should see a main bordenet something else 2t 7 f f d0 i mean i guess these should be df0 should these be 64 bits no un64 that's weird i just wanted to print this out see like what's d four eight stack see so this is kind of weird like the back trace is getting it from somewhere else doesn't gdb have a way to hex dump memory yes i'm sure it does does that mean i remember how to do it no it does not um like where is it reading well this is this is interesting that this esr el 2 is pretty full like there's a bunch of bits set there sps r i don't know if forever i don't know i am out of my depth if el equals zero and cps r were you at el 2 i don't know i thought about that like the program counters here but the stack pointer is still kind of where i would expect it but why is back trace then giving me garbage it doesn't actually look like d0 e 0 8 55 5 done 3 i think this is out of the range of hardware watch point on the execution of 200 i've already got a break point there and that's what i just hit like we're on this break point for like that i think that's what you mean like a break uh watch point on execution is a break point so let's just see a arch 64 gdb el level arm what is the current execution mode this is handy depends on the execution mode current el once an exception comes can i read any register to determine whether i'm in s error synchronous rq if i q exception himler if i'm in el zero mode reading cps r causes an exception i don't think there i don't think i should be like that's the other thing we could try running this in q mu that might give us more information let's try that i want to play around with that let's see what q m uses i've never done this before let's do it in a different let's do it in here q mu a lot of this is things i haven't done before let's find that so there isn't a board definition for the pi 4 but the pi 3 is pretty similar oh that's what i wanted oh i'm in the root so it would be examples device cdc msc build raspberry pi kernel 8 my like cpu my my actual cpu like kicked on it's like oh i gotta emulate something okay so that's a start we don't need the graphical output is there a virtual jailing for q mu uh yes there is um you can have gdb you can have q mu do a gdb server um i was looking at that dash no graphic thank you bark does it emulate arm 74 l arch yes i think so i think you can do all the way yeah i think you could do zeros through threes and they just haven't added the four stuff for q mu um and in fact i think you can emulate usb host so i was thinking like for debugging usb host stuff this could be a good option okay where did i see that here we go this is the person that added it this is the compilation here's how to run it okay this is what i was thinking of dash s option makes q mu listen on port one two three four and s makes it stop at execution until you give it the continue command no graphic lowercase s capital s like that turn this off so we don't get confused let's turn this off and let's do the arch that and i have this i have i have the gdb startup that's not right so it times out but now we should do tar ext one two three four okay so now let's see what continue does and it kicks on so i know it's running and control c and hey we're in the same place the stack is slightly different but we got to 200 again that seems good that the emulation did the same thing we're in line 56 of main what is line 56 of main versus main 56 board in it okay so how do we do you art the arm docks are quite handy sometimes there's a lot of arm docs i think that's the challenge you can add virtual usb serial ports i don't want to tell that oh booting a bare metal system what for arm v7a but that's close enable interrupts so that's in the programmers guide for the seven booting a bare metal system boot code i think i have the this is the reference but i'm sure that there is a perfect you all are so helpful bare metal boot code for arm v8 processors in fore mode see what it says setting up vector tables there are vector tables at eat for each exception level can be read you must place boot code at this address i don't have any black fin experience see the problem is the gpu probably could actually be doing stuff before us like this is what i was trying to get set up i tried to do that with all the same thing only 53 pages or so i know right it's got example code ea irq and the fiq bits initializing registers system control registers so what do the other bare metal system demos do to freeze the gpu i don't know what you mean by freeze the gpu like these other simple demos they don't do a lot like i really don't it's probably going to be like oh when we get it but stop the emulation system reset can we like go back in time on qmu there's got to be a way to just have it print everything right oh i thought the gpu was interfering with our code yeah maybe dump guest memory reverse execution how do i reset is it mon reset i don't really need reverse execution i need like qmu to just tell me reverse step i wonder if it works i guess i could set a breakpoint how did i break how do i set a breakpoint on that no hey let's see let's also break it coordinate try to blink an led on a pie i got that far system reset continue okay so we did coordinate and now we continue and now we're here and we do reverse step what what sorry my my instinct is to like use my full monitor all right we got 20 more minutes qmu is pretty neat qmu pc logging and debugging for qmu virtual machines qmu monitor i mean that's what we're getting through mon info arm eel numbering uses a convention reverse from x86 rings well so i don't know either but that's good to know for the future info registers info block who there is temp qmu log and then save on help block remove all the logs show trace what do you think tb is log mmu related activities log when the guest os does something invalid got a delivery um what do you think tb stands for on log cpu sure why not and then oh oh you know what maybe we should oh that looks nice look there's our p state program counter why is our program counter that doesn't look great hmm i don't trust this this doesn't look like it's the right how do i turn it off just set the default cpu oh on help log hmm these don't look right this just looks like the same thing over and over again qmu never trust so many zeros exactly gdb usage let's take a look at that debugging multicore machines separate inferior info thread well that makes more sense that the program counter of the other three cpus is um what we're printing out how do we log the cpu we care about cpu zero show trace before log none this is pretty neat i'll give give it that trace that doesn't look nearly as helpful well that looks like program counters of everything else 81 84 81 88 that's it 81 88 like i don't care that there's four i don't care that there's four use a unix socket which i don't care about a single step behavior i don't get it why can't you just tell me what's going on debug slash expert options serial running emulation in single single step mode use dash d help for a list of log items it so bothers me that like the same thing happens translations blocks trace compile the simple log or f trace tracing back ends trace is what i want one log mon trace event what is single step mode oh maybe this is the trace output can i not control see it how do i stop it rabbit holes after rabbit holes it's very reassuring to me to see struggle as much as i do sometimes you're welcome how do i quit control c doesn't work system power control i'll delete that's not what i want i'm trying to quit qm you oh there's stop like if i i can't control see that control a x thank you it work um let's trace stuff tracing pattern why doesn't control c work trace that help this list really long gic is cool oh man i'm gonna like this once i figure out how to use it this list is like not sorted either this is like everything cpu in cpu out qm you trace arm how to use the simple trace back end oh control c is supposed to be sent to the emulated machine yeah it reminds me of screen tracing and profiling oh let's try that mm-hmm control c's copy the in asm okay and what is the um configure like no configuration file thing well that's pretty straightforward i still still see alt tab as scroll up so we're returning from where i mean that's super cool i guess we could look at the map there's gotta be a version that's a simple in it oh you know what is it it's an 81 like the stack is wrong 81 c cb cc cd ce i guess that's gpio call gpio issue hmm what more can we trace tracing qmu guest execution it's still not that useful like it must be like if we did the return then we return to the wrong place or this is just is in asm just printing everything out oh i'm over time where's that just telling you the stack is hosed i don't know it seems like i like what i keep expecting to find is just to like run it with these settings and you'll be able to see like all the all i guess i kind of want register state or like exception level changes in asm like that's definitely on the right track if you're lucky then one of the sample plugins might even be sufficient for your purposes the cpu and the exec traces which is what we looked at sounds like in asm is not actually what we want i wonder if there's a way to hook python in example plugins box hot pages i'm almost done i swear what is this i think i don't see a 200 this is just trace again isn't it can i only monitor one thing log one thing at a time it's gotta be in here it's just we're looking at all of the sorry folks i know this might be boring python hooks and gdb that's true i just want to log one cpu i really hate it when people come to me and say i just i just i just dry some nuts like it looks like this information would be helpful it's just not the right cores it's like all the other cores cool let's wrap it up thank you all i know i know i'm over time and you all are headed out too i just want to go to the moon exactly okay this has been another deep dive with scott um thank you all for hanging out and hanging in there with me as i explore cortex a and qmu and all of that stuff um pretty interesting hopefully like it may it makes me very happy that qmu can replicate it as well um that means that i don't have to use the the raspberry pi to figure it out so that's exciting check out next week we'll be uh at 2 p.m pacific next friday the week after that we will not be doing it um thanks to david for taking time codes thanks for patrick for getting everything in the uh notes repo if you want to support me and support aida fruit go to aidafruit.com purchase some hardware there um i'm playing around with the cm4 io more modules and boards and i think we do have some of those in stock um so you could play play around with that if you like and if you want to join us on the discord and talk about all time um you can go to adafru.it slash discord and jeff's asking off topic but does the stm 32 767 circuit python support work if the board's on there we we thought it would work but um not a lot of people are using it so it may have failed jeff i would suggest joining the discord uh and we can ask and chat there go to adafru.it slash discord to do that and i'll put it in the chat as well thank you all again and uh we'll see you next week i will put the cat since he's here all right have a great weekend everyone