froggey has quit [Remote host closed the connection]
froggey has joined #osdev
novasharper has quit [Ping timeout: 265 seconds]
divine has quit [Ping timeout: 265 seconds]
divine has joined #osdev
novasharper has joined #osdev
dutch has quit [Ping timeout: 245 seconds]
[itchyjunk] has quit [Read error: Connection reset by peer]
Burgundy has joined #osdev
dutch has joined #osdev
noircode has left #osdev [#osdev]
mahmutov has quit [Ping timeout: 245 seconds]
kuler has joined #osdev
kuler has quit [Remote host closed the connection]
sdfgsdfgDropBear has joined #osdev
sdfgsdfg has joined #osdev
sdfgsdfgDropBear has quit [Quit: sdfgsdfgDropBear]
sdfgsdfgDropBear has joined #osdev
sdfgsdfgDropBear has quit [Client Quit]
sdfgsdfgDropBear has joined #osdev
ElectronApps has joined #osdev
sdfgsdfgDropBear has quit [Quit: sdfgsdfgDropBear]
sdfgsdfgDropBear has joined #osdev
nyah has joined #osdev
vdamewood has quit [Quit: Life beckons]
GeDaMo has joined #osdev
pretty_dumm_guy has joined #osdev
arahael has joined #osdev
dormito has quit [Quit: WeeChat 3.1]
sm2n_ is now known as sm2n
Vercas has quit [Remote host closed the connection]
Vercas has joined #osdev
dormito has joined #osdev
Vercas has quit [Quit: buh bye]
sdfgsdfgDropBear has quit [Quit: sdfgsdfgDropBear]
edro is now known as edr
sdfgsdfgDropBear has joined #osdev
junon has quit [Ping timeout: 245 seconds]
darkstardevx has quit [Ping timeout: 245 seconds]
darkstardevx has joined #osdev
junon has joined #osdev
Mutabah has quit [Ping timeout: 252 seconds]
sdfgsdfgDropBear has quit [Quit: sdfgsdfgDropBear]
Mutabah has joined #osdev
dutch has quit [Ping timeout: 265 seconds]
Obscenity has joined #osdev
sdfgsdfgDropBear has joined #osdev
[itchyjunk] has joined #osdev
[itchyjunk] has quit [Remote host closed the connection]
[itchyjunk] has joined #osdev
Vercas has joined #osdev
MiningMarsh has quit [Ping timeout: 252 seconds]
junon has quit [Ping timeout: 265 seconds]
elastic_dog has quit [Ping timeout: 246 seconds]
dutch has joined #osdev
MiningMarsh has joined #osdev
ahalaney has joined #osdev
elastic_dog has joined #osdev
dutch has quit [Ping timeout: 265 seconds]
dutch has joined #osdev
NeoCron has joined #osdev
<Affliction>
Only time I flashed my BIOS was to fix a rare refusal-to-post if ambient temperature was relatively low.
<Affliction>
I suspect it was memory related
<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
<Affliction>
no idea if I can flash the chip with a programmer, don't really want to have to find out
sdfgsdfgDropBear has quit [Quit: sdfgsdfgDropBear]
<zid>
I m ean, you definitely can
<zid>
the question is how easy it'd be
dude12312414 has joined #osdev
<Affliction>
Yeah, I've not looked into it.
dude12312414 has quit [Client Quit]
<Affliction>
No plans to update right now, anyway. Got a stable system, let's not change that.
<Affliction>
Though I did have an old core2 era intel board seemingly corrupt itself
<Affliction>
Rewriting the chip brought it back
<zid>
I had a board not posting once, I reseated the rom chip it was socketed
<zid>
but accidentally twisted it 90 degrees, it got very hot, whoops
<zid>
...then posted completely fine after I rotated it back
<clever>
ive heard that at least with the rpi soc, that causes physical damage to the silicon that will spread over time
<clever>
and eventually, the chip will just entirely die
Vercas has quit [Remote host closed the connection]
Vercas has joined #osdev
<Affliction>
latchup perhaps?
<Affliction>
if VCC was unpowered and you have power connected to a data line, it could probably find a path to ground
<zid>
That's why you're supposed to make the power pins shorter, so they disconenct first
<zid>
everybody knows that
* zid
pictures ICs mounted at funny angles
<Affliction>
Any PCB layout engineers here want to comment on that? :)
Arthuria has joined #osdev
<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.
<Mutabah>
ground should be longest iirc, then signal, then power?
<zid>
sounds like a conspiracy by big copper to sell you more traces to me mutabah
<__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
<Affliction>
SATA power cable is a good example there, with its 3 tiers
<zid>
don't forget that it should have a violent snapping action, so that you don't get arcing that damages the contact
<zid>
it should be like a mouse trap
<Affliction>
ground connects first, then there's leading power pins with a resistance on them, then power connected directly
<Affliction>
Oli: on some chips, if you have a voltage above vcc, that can cause latch up
<Affliction>
which is, due to the layers of silicon doping, where a 'parasitic transistor' is formed that passes current until power is removed
<Affliction>
it's a problem with electronics in space too, xrays can trigger it
<Affliction>
so, that could be a situation where you want power to connect before data, which USB does for instance
<Affliction>
And that's why, on systems with multiple voltages, power sequencing is a thing
sprock has quit [Ping timeout: 268 seconds]
<Affliction>
that is, a voltage above vcc on data lines
<zid>
Affliction did you remember to connect your usb by firing it out of a usb connector canon
<zid>
cannon
<Affliction>
and, it does depend on the chip
<Affliction>
(am I missing a joke?)
<Affliction>
I have the same problem everyone else does with USB A - having to flip the connector 3 times. Damn 4 dimensional connector keying!
<zid>
Affliction: ctrl-f mousetrap
<Affliction>
oic!
h4zel has joined #osdev
<h4zel>
osdev in theory > osdev in practice
<h4zel>
I wanted to write drivers not debug an itoa implementatin
<h4zel>
implementation*
<Affliction>
Incidentally, that USB-PD standard that runs 48V 5A - that's going to be interesting.
<zid>
You can steal my %d if you want :p
<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
<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
<Affliction>
transmitter would have to survive 48V being driven back too
<Oli>
Thank you, Affliction, for bringing up about: I wasn't aware about the phenomenon regarding latch up caused by voltage above vcc itself.
<h4zel>
but thank you! I might take you up on that :p
<geist>
was it cooked from the heat of Fagradalsfjall?
<geist>
or maybe Eyjafjallajökull
<gog>
in a sense
<geist>
yay volcano pasta is best pasta
<gog>
about 1/4 of our electric power is geothermal so it cooked 1/4 of the pasta
Oli has joined #osdev
<geist>
we have a volcano here but sadly it's dormant right now, so no volcano pasta
<gog>
you have the kind of volcanoes that explode violently tho
<geist>
yah kinda hard to make pasta in a violent eruption
<gog>
yes
<Bitweasil>
It's light and fluffy, though!
<gog>
a delicate flavor from an indelicate geophysical process
<geist>
hah once again looked at the wikipedia side on mt rainier and how bad it would be if it went off
* geist
closes the page quietly and tries to think of something else
<Bitweasil>
How about the subduction zone and earthquakes? :D
<gog>
everybody loves a good megathrust
<gog>
and the tsunami that follows
<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
<geist>
though my house is about 80m elevation and maybe 300m in from the water
<geist>
more like 500 or so
<gog>
i'm pretty close to the dead center of the peninsula that reykjavík sits on so a tsunami would spare me
<gog>
but also destroy the majority of the city
<geist>
yah a month or two of ash would super suck too
<geist>
apparently it was pretty bad after st helens, even as far north as seattle
<Bitweasil>
IIRC even places like Nebraska had heavy ash fall from it.
<geist>
reading up on it, apparently most of the st helens ash went to the east, makes sense
<geist>
so actually seattle was probably mostly spared
<geist>
so yeah nebraska and whatnot would have gotten a lot of it
<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
<geist>
but you take a picture and it's tiny
<gog>
yeah the mountains around the city are all like that
unmanbearpig has joined #osdev
<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
<gog>
a good camera from a distance would, but nothing at ground level shows it
<geist>
yah that's the real problem. the phone cameras cant do it
<geist>
even if you zoom in it's doing a digital zoom, etc
<geist>
need a proper telephoto or whatnot
<geist>
or at least on like a 70mm or so lens
mmohammadi9812 has quit [Remote host closed the connection]
GeDaMo has quit [Quit: Leaving.]
terrorjack has joined #osdev
dormito has quit [Quit: WeeChat 3.1]
h4zel has quit [Ping timeout: 245 seconds]
h4zel has joined #osdev
sprock has quit [Ping timeout: 245 seconds]
noircode has joined #osdev
<noircode>
Is power management/efficiency outside of OS control?
<Bitweasil>
It *can* be, but... usually it's under OS control. And you want it under OS control.
<Bitweasil>
There are typically various valid setpoints for frequency/voltage that the OS ought obey.
<Bitweasil>
Dynamic voltage and frequency scaling (DVFS) <-- Might do some searching for that too.
<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
<clever>
when thermal throttling, the firmware will just ignore linux, and use a lower freq, without telling anybody
<Bitweasil>
Yes, but that's because the Raspberry Pi is an abomination. :p
<clever>
yep
<clever>
ive also done some extensive testing with a pi0, and found that the freq has almost zero impact on the heat generation
<clever>
its all about voltage
<clever>
ive also found, that the firmware is very dumb about its freq/voltage pairs
<clever>
the lowest freq, gets the lowest voltage
<clever>
and if you tell it to underclock things, that same freq, now gets a higher voltage
<clever>
because that freq isnt the lowest freq anymore
<Bitweasil>
That surprises me exactly zero. :(
<clever>
i filed a bug, and i think the answer was basically "working as intended"
<clever>
your supposed to also change the voltage range when you change the freq
<clever>
but i dont think the config allows setting a voltage at each freq in the curve
<clever>
and it just blindly creates 100mhz steps
<clever>
in my mind, you should instead step the voltage up, in small increments, and then find the max freq for each voltage
<clever>
changing the freq but not voltage, is a zero-gain change
Burgundy has quit [Ping timeout: 252 seconds]
<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
mahmutov has quit [Ping timeout: 265 seconds]
<clever>
Bitweasil: i think the pi2, uses i2c to the pmic for that task, but ive not confirmed that
nostalgia has joined #osdev
freakazoid12345 has quit [Ping timeout: 246 seconds]
EtherNet has quit [Ping timeout: 245 seconds]
EtherNet has joined #osdev
MummyMarsh is now known as MohrgMarsh
eremitah has joined #osdev
<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
ZetItUp_ is now known as ZetItUp
ahalaney has quit [Quit: Leaving]
noircode has left #osdev [#osdev]
<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?