channel logs for 2004 - 2010 are archived at http://tunes.org/~nef/logs/old/ ·· can't be searched
#osdev2 = #osdev @ Libera from 23may2021 to present
#osdev @ OPN/FreeNode from 3apr2001 to 23may2021
all other channels are on OPN/FreeNode from 2004 to present
http://bespin.org/~qz/search/?view=1&c=osdev2&y=21&m=10&d=6
13:09:00 <Affliction> Only time I flashed my BIOS was to fix a rare refusal-to-post if ambient temperature was relatively low.
13:09:00 <Affliction> I suspect it was memory related
13:10:00 <Affliction> This board doesn't have top swap or USB flashing so, it's fun watching the progress bar advance painfully slowly while anticipating the many ways something could fail
13:12:00 <Affliction> no idea if I can flash the chip with a programmer, don't really want to have to find out
13:17:00 <clever> Affliction: https://libreboot.org/docs/install/spi.html
13:26:00 <zid> I m ean, you definitely can
13:26:00 <zid> the question is how easy it'd be
13:28:00 <Affliction> Yeah, I've not looked into it.
13:32:00 <Affliction> No plans to update right now, anyway. Got a stable system, let's not change that.
13:32:00 <Affliction> Though I did have an old core2 era intel board seemingly corrupt itself
13:33:00 <Affliction> Rewriting the chip brought it back
13:34:00 <zid> I had a board not posting once, I reseated the rom chip it was socketed
13:34:00 <zid> but accidentally twisted it 90 degrees, it got very hot, whoops
13:35:00 <zid> ...then posted completely fine after I rotated it back
13:35:00 <clever> ive heard that at least with the rpi soc, that causes physical damage to the silicon that will spread over time
13:35:00 <clever> and eventually, the chip will just entirely die
13:42:00 <Affliction> latchup perhaps?
13:43:00 <Affliction> if VCC was unpowered and you have power connected to a data line, it could probably find a path to ground
13:45:00 <zid> That's why you're supposed to make the power pins shorter, so they disconenct first
13:45:00 <zid> everybody knows that
13:45:00 * zid pictures ICs mounted at funny angles
13:46:00 <Affliction> Any PCB layout engineers here want to comment on that? :)
13:51:00 <Oli> I find myself learning about, and appreciate anyone to expand in regards to making power pins shorter, for them to disconnect first, in context of power connected to a data line finding a path to ground.
13:53:00 <Mutabah> ground should be longest iirc, then signal, then power?
13:54:00 <zid> sounds like a conspiracy by big copper to sell you more traces to me mutabah
13:55:00 <__sen> yep, gnd-signal-power, and depending on power use you may want a pre-charge power pin to connect through a resistor and bring the power rail up slowly before the main power pin connects as well
13:55:00 <Affliction> SATA power cable is a good example there, with its 3 tiers
13:55:00 <zid> don't forget that it should have a violent snapping action, so that you don't get arcing that damages the contact
13:55:00 <zid> it should be like a mouse trap
13:55:00 <Affliction> ground connects first, then there's leading power pins with a resistance on them, then power connected directly
13:56:00 <Affliction> Oli: on some chips, if you have a voltage above vcc, that can cause latch up
13:57:00 <Affliction> which is, due to the layers of silicon doping, where a 'parasitic transistor' is formed that passes current until power is removed
13:58:00 <Affliction> it's a problem with electronics in space too, xrays can trigger it
13:58:00 <Affliction> so, that could be a situation where you want power to connect before data, which USB does for instance
13:59:00 <Affliction> And that's why, on systems with multiple voltages, power sequencing is a thing
14:00:00 <Affliction> that is, a voltage above vcc on data lines
14:00:00 <zid> Affliction did you remember to connect your usb by firing it out of a usb connector canon
14:00:00 <zid> cannon
14:00:00 <Affliction> and, it does depend on the chip
14:01:00 <Affliction> (am I missing a joke?)
14:01:00 <Affliction> I have the same problem everyone else does with USB A - having to flip the connector 3 times. Damn 4 dimensional connector keying!
14:02:00 <zid> Affliction: ctrl-f mousetrap
14:03:00 <Affliction> oic!
14:04:00 <h4zel> osdev in theory > osdev in practice
14:04:00 <h4zel> I wanted to write drivers not debug an itoa implementatin
14:04:00 <h4zel> implementation*
14:04:00 <Affliction> Incidentally, that USB-PD standard that runs 48V 5A - that's going to be interesting.
14:05:00 <zid> You can steal my %d if you want :p
14:05:00 <Affliction> I'm pretty sure USB devices have to deal with supply voltage on the data lines, I'm sure there's fun challenges getting 20gbps through 48V-tolerant receivers
14:05:00 <h4zel> lol I've tried multiple and they all have the same weird issue of not printing '0', so I'm thinking it's an issue with my tty_print function
14:05:00 <Affliction> transmitter would have to survive 48V being driven back too
14:05:00 <Oli> Thank you, Affliction, for bringing up about: I wasn't aware about the phenomenon regarding latch up caused by voltage above vcc itself.
14:05:00 <h4zel> but thank you! I might take you up on that :p
14:06:00 <Affliction> and I'll bet it'll arc on disconnect
14:06:00 <zid> https://github.com/zid/boros/blob/master/print.c#L48
14:07:00 <zid> that was fast
14:07:00 <Affliction> you solved all his problems!
14:09:00 <zid> oh they a back
14:10:00 <h4zel> I'm back! Sorry
14:11:00 <h4zel> It's weird, I just can't get a leading "0". It's converting "10" to "1", 500 to "5", etc
14:11:00 <zid> show yours
14:11:00 <h4zel> I'll just have to mess around with it :p
14:11:00 <zid> I showed you mine, show me yours
14:12:00 <h4zel> I stole the one from the interwebs when mine didn't work, http://www.strudel.org.uk/itoa/
14:12:00 <h4zel> also tried the osdev wiki one
14:13:00 <zid> wtf
14:13:00 <zid> I thought I was the only person silly enough to do the indexing backwards
14:13:00 <zid> oh I guess theirs isn't backwards, nevermind
14:13:00 <zid> yea you need a do while otherwise it's going to have issues with 0
14:14:00 <zid> also they have their * on the wrong side, and they're off by one on the initializer for i, and they're clearing the entire string for no reason
14:14:00 <zid> other than that, perfect
14:14:00 <h4zel> I'm using v4, not the first one
14:14:00 <h4zel> but ahh, I'll look into that, ty
14:15:00 <zid> "An idiot golfs a simple library function badly" should be the <title> of that page
14:16:00 <h4zel> Honestly I'll take the worst itoa impl if I can get something that works at this point
14:16:00 <h4zel> i'm assuming it's definetly something I'm doing wrong considering multiple have had this issue
14:16:00 <h4zel> also yeah, the mirrored alphabet is pretty stupid lol
14:17:00 <zid> mine works fine, and works enough for %d
14:17:00 <zid> (%.8ld etc is why it takes so many params)
14:17:00 <zid> also works for %x
14:17:00 <h4zel> Would you send your implementation?
14:17:00 <h4zel> It'd be a huge help to get to steal it lol
14:19:00 <zid> I already linked it
14:19:00 <zid> https://github.com/zid/boros/blob/master/print.c#L48
14:19:00 <zid> you apparently missed it when you quit
14:19:00 <h4zel> Oh yup, I missed it, whoops
14:19:00 <h4zel> Thank you so much!
14:20:00 <zid> You could guard against base being >16 but that code doesn't have a good way to signal errors like that so it doesn't
14:21:00 <zid> and as long as you use a constant for the base the compiler will warn about it anyway ;)
14:22:00 <h4zel> what's the argument `width`, btw?
14:22:00 <h4zel> just out of curiosity
14:22:00 <zid> %.8d
14:22:00 <zid> pads to 8
14:22:00 <zid> err 8d even
14:22:00 <h4zel> Ohhh, thats cool
14:22:00 <zid> and either with spaces or 0s
14:22:00 <zid> depending on 08 or 8
14:22:00 <zid> so that's why it takes the args it does
14:23:00 <h4zel> Same issue with no 0s!!
14:23:00 <h4zel> So it DEFINETLY is something on my end
14:23:00 <zid> your putchar is checking for *p == '0' or something for no reason?
14:23:00 <h4zel> It doesn't even have 0s through a serial port, so I'm not sure where the point of failure is
14:24:00 <h4zel> printf impl loops with while (*strptr), and incs the pointer, so I'm not sure
14:24:00 <zid> sounds like you're confusing 0 and \0 *somewhere*
14:24:00 <h4zel> I have no idea how, the serial send function is litterally just three lines and the issue is still there
14:24:00 <h4zel> But yeah, that would be the simplest answer
14:25:00 <zid> so if you print "abc0123" what happens?
14:25:00 <h4zel> prints normally
14:25:00 <h4zel> "abc0123"
14:25:00 <zid> and "0" ?
14:26:00 <h4zel> Also normal
14:26:00 <h4zel> Just "0"
14:26:00 <zid> time for a debugger then
14:26:00 <h4zel> Yup, haven't written a GDB stub yet
14:27:00 <h4zel> I tried isolating the code and building on my OS, and it works fine then lol
14:27:00 <zid> qemu has one
14:27:00 <h4zel> so this won't be fun
14:27:00 <h4zel> qemu monitor is useful for asm, but I cant print C variables (I don't think)
14:37:00 <h4zel> huh, when looking at the memory, itoa is converting "10" to ['1','6'], but printing "1"
14:44:00 <h4zel> wow. it's only printing the first character. that's why it doesn't include 0s
17:46:00 <dzwdz> is it just me or is the wiki page on ATA PIO mode a mess
17:53:00 <sortie> We'll DMA a better page out momentarily
17:55:00 <dzwdz> i'd fix it myself, i just don't know enough about ATA yet
17:55:00 <dzwdz> so i don't want to mess it up
17:55:00 <Bitweasil> ATA PIO being a mess seems somehow appropriate...
18:03:00 <dzwdz> is it only an x86 thing? or do other archs use ata too
18:05:00 <Bitweasil> I can't imagine you're going to find it many other places, but I believe at least some Compact Flash cards support ATA commands as well.
18:15:00 <zid> the wiki pages are all a mess tbh
18:21:00 <clever> my rough understanding, is that in the OLD days, PATA was just an extension of ISA
18:21:00 <clever> it just exposed a single IO port to each drive, with some buffer gates to boost the signal and cut it off when its not being spoken to
18:22:00 <clever> and PIO mode is still using the same protocol as back then? even if the bus has radically changed since
18:23:00 <Bitweasil> Sounds familiar, but I've not dealt with ATA at that level.
18:23:00 <clever> > When the CPU accessed a disk IO port, there was a chip that shorted the CPU's IO bus pins directly onto the IDE cable
18:23:00 <clever> yeah, the wiki agrees with me on some of that
18:38:00 <gog> i make pasta
18:39:00 <gog> wrong channel but i guess y'all can have some pasta too
19:02:00 <geist> mmm pasta
19:22:00 <dzwdz> oh no, i missed the pasta :(
19:22:00 <dzwdz> how was it?
19:22:00 <gog> delicious
19:28:00 <geist> was it cooked from the heat of Fagradalsfjall?
19:29:00 <geist> or maybe Eyjafjallajökull
19:29:00 <gog> in a sense
19:30:00 <geist> yay volcano pasta is best pasta
19:30:00 <gog> about 1/4 of our electric power is geothermal so it cooked 1/4 of the pasta
19:30:00 <geist> we have a volcano here but sadly it's dormant right now, so no volcano pasta
19:31:00 <gog> you have the kind of volcanoes that explode violently tho
19:31:00 <geist> yah kinda hard to make pasta in a violent eruption
19:31:00 <gog> yes
19:32:00 <Bitweasil> It's light and fluffy, though!
19:32:00 <gog> a delicate flavor from an indelicate geophysical process
19:37:00 <geist> hah once again looked at the wikipedia side on mt rainier and how bad it would be if it went off
19:37:00 * geist closes the page quietly and tries to think of something else
19:38:00 <Bitweasil> How about the subduction zone and earthquakes? :D
19:38:00 <gog> everybody loves a good megathrust
19:38:00 <gog> and the tsunami that follows
19:39:00 <geist> yah i'm far enough away that i wont get swept up in a lahore, but a tsunami on the puget sound would be Real Bad
19:39:00 <geist> though my house is about 80m elevation and maybe 300m in from the water
19:40:00 <geist> more like 500 or so
19:40:00 <gog> i'm pretty close to the dead center of the peninsula that reykjavík sits on so a tsunami would spare me
19:40:00 <gog> but also destroy the majority of the city
19:41:00 <geist> yah a month or two of ash would super suck too
19:41:00 <geist> apparently it was pretty bad after st helens, even as far north as seattle
19:42:00 <Bitweasil> IIRC even places like Nebraska had heavy ash fall from it.
19:42:00 <geist> reading up on it, apparently most of the st helens ash went to the east, makes sense
19:42:00 <geist> so actually seattle was probably mostly spared
19:42:00 <geist> so yeah nebraska and whatnot would have gotten a lot of it
19:43:00 <geist> well either way, mt rainier is really pretty... but it has that effect where i just dont know how to take a picture of it. your brain does this thing where it makes mountains and whatnot look so much more impressive in person. same effect as the moon near the horizon
19:43:00 <geist> but you take a picture and it's tiny
19:47:00 <gog> yeah the mountains around the city are all like that
19:49:00 <gog> they look very imposing because they are, they're like 4x taller than the height of any structure from sea level but pictures don't really tell that story, especially phone cameras with their digital focus trickery
19:49:00 <gog> a good camera from a distance would, but nothing at ground level shows it
19:53:00 <geist> yah that's the real problem. the phone cameras cant do it
19:53:00 <geist> even if you zoom in it's doing a digital zoom, etc
19:53:00 <geist> need a proper telephoto or whatnot
19:54:00 <geist> or at least on like a 70mm or so lens
21:08:00 <noircode> Is power management/efficiency outside of OS control?
21:10:00 <mjg> no
21:10:00 <mjg> for example https://www.kernel.org/doc/Documentation/cpu-freq/governors.txt
21:11:00 <noircode> ah yeah that's pretty useful
21:11:00 <noircode> thanks
21:38:00 <Bitweasil> It *can* be, but... usually it's under OS control. And you want it under OS control.
21:39:00 <Bitweasil> There are typically various valid setpoints for frequency/voltage that the OS ought obey.
21:39:00 <Bitweasil> Dynamic voltage and frequency scaling (DVFS) <-- Might do some searching for that too.
21:41:00 <clever> Bitweasil: however, on the rpi, the freq/voltage pairings are hidden in the firmware blob, and linux just asks the firmware for a given freq, and maybe the firmware will listen
21:41:00 <clever> when thermal throttling, the firmware will just ignore linux, and use a lower freq, without telling anybody
21:42:00 <Bitweasil> Yes, but that's because the Raspberry Pi is an abomination. :p
21:42:00 <clever> yep
21:43:00 <clever> ive also done some extensive testing with a pi0, and found that the freq has almost zero impact on the heat generation
21:43:00 <clever> its all about voltage
21:44:00 <clever> ive also found, that the firmware is very dumb about its freq/voltage pairs
21:44:00 <clever> the lowest freq, gets the lowest voltage
21:44:00 <clever> and if you tell it to underclock things, that same freq, now gets a higher voltage
21:45:00 <clever> because that freq isnt the lowest freq anymore
21:48:00 <Bitweasil> That surprises me exactly zero. :(
21:48:00 <clever> i filed a bug, and i think the answer was basically "working as intended"
21:48:00 <clever> your supposed to also change the voltage range when you change the freq
21:49:00 <clever> but i dont think the config allows setting a voltage at each freq in the curve
21:49:00 <clever> and it just blindly creates 100mhz steps
21:49:00 <clever> in my mind, you should instead step the voltage up, in small increments, and then find the max freq for each voltage
21:50:00 <clever> changing the freq but not voltage, is a zero-gain change
21:52:00 <clever> Bitweasil: for the bcm2835, the core voltage is generated by a SMPS built into the SoC itself, so a simple MMIO write can change the voltage freely
21:56:00 <clever> Bitweasil: i think the pi2, uses i2c to the pmic for that task, but ive not confirmed that
22:30:00 <ZetItUp_> sigh my ata driver seems messed up :( reading from position 0 seems to work, but if i jump to a sector, it gets stuck waiting for the poll to complete hmm :P
22:49:00 <ZetItUp> should i keep the polling in an infinite loop for the ata driver and poll every tick, or should i do the 400 ns wait before doing another status check?
22:50:00 <ZetItUp> does it matter i guess the question is