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=23&m=1&d=7
00:01:00 <epony> from the newspeak mellow soft rainbow gender reveal cyanobacteria pop-culture politically correct when it is in the interest of our_own_secret_world_domination_plans_which_everyone_knows_too_but_we_all_pretend_is_conspiracy
00:01:00 <zid> jimbzy: he needs to turn it after so he doesn't want hard spots, and he's building material up not just joining bits
00:02:00 <jimbzy> Yeah, I figured as much. I've seen it used for refacing parts.
00:03:00 <zid> yea it needs an o-ring to seal nicely afterwards
00:03:00 <zid> and it's gouged to shit
00:03:00 <zid> so build back up, flush cut back on lathe
00:10:00 <gog> heat
00:10:00 <zid> heat is spying on us
00:10:00 <heat> heat
00:10:00 <epony> waste heat
00:10:00 <epony> https://en.wikipedia.org/wiki/System_on_a_chip#Waste_heat
00:10:00 <bslsk05> en.wikipedia.org: System on a chip - Wikipedia
00:13:00 <epony> System_an_a_chatGPL
00:50:00 <kaichiuchi> hi
00:50:00 <gog> hi
00:50:00 <kaichiuchi> may i pet you
00:50:00 <gog> yes
00:51:00 * kaichiuchi pets gog
00:51:00 * gog prr
00:55:00 <epony> "this is the beginning of a long and beautiful friendship" --Donald Minuteman about the Rocketman Kim1
00:56:00 <gog> who
00:59:00 <epony> https://en.wikipedia.org/wiki/KIM-1 vs https://en.wikipedia.org/wiki/Kim_Jong-un#Personality "I learned he was a talented man. I also learned he loves his country very much." He added that Kim had a "great personality" and was "very smart"
00:59:00 <bslsk05> en.wikipedia.org: KIM-1 - Wikipedia
00:59:00 <bslsk05> en.wikipedia.org: Kim Jong-un - Wikipedia
01:00:00 <gog> ohh
01:00:00 <gog> ok
01:01:00 <epony> modern designs.. special trimming
01:01:00 <epony> bugs and built-in flaws, but still better than the Donald hairpiece
01:01:00 <heat> wtf
01:02:00 <epony> petting vs pecking
01:02:00 <epony> Western vs Eastern state capitalism etc
01:04:00 <epony> to the tune of 2½Men "Kim-kim-kim KIM, kimly kiim-ki-kim"
01:04:00 <gog> idgi
01:04:00 <gog> but i'm glad you're having fun
01:04:00 <gog> :)
01:05:00 <epony> we're all having fun, right / left / center for advanced system programming etc
01:05:00 <gog> operating systems development
01:05:00 <epony> uhm yeah, something like KIM-1
01:05:00 <gog> why don't we all work on an operating system together? because NIH is that strong
01:05:00 <gog> it's NIBM
01:06:00 <gog> Not Invented By Me
01:06:00 <epony> it's called OpenIBMSD
01:06:00 <epony> we're all working on it
01:06:00 <epony> have to advance it forward to the HD epoch
01:07:00 <gog> how can it be a software distribution if it's many software distributions in varying states of completeness and correctness
01:07:00 <gog> it's more like GNU
01:07:00 <epony> the difference between a system and a distribution is.. who does what
01:09:00 <gog> it's the system, maaaan
01:09:00 <epony> GNU and BSD the Chinese and the Warmerican twins from a different mother https://upload.wikimedia.org/wikipedia/commons/4/46/2018_inter-Korean_summit_01.jpg
01:11:00 <epony> behind them is a mural of the userland standards compliance
01:14:00 <heat> gog, im waiting for contributions
01:14:00 <epony> from which country? ;-)
01:15:00 <epony> Taiwan is sending half of TSMC in Arizona, USA
01:15:00 <epony> Samsung is doing the same.. only a different half
01:16:00 <epony> (new halflength feature sizes but also not really halves)
01:19:00 <gog> heat: rm -rf
01:19:00 <gog> send tweet
01:19:00 <klange> we don't do that any more
01:19:00 <heat> no tweet
01:19:00 <klange> send toot instead
01:19:00 <heat> send me a mastodon
01:19:00 <heat> i'll truthsocial you
01:20:00 <epony> and newfs is faster, and even faster is clear your decryption keyfile
05:12:00 <zid> https://i.redd.it/82o5avenbo9a1.jpg Nice that you waited until the berlin wall fell to open your first mcdonalds heat, solidarity!
06:35:00 <klys> finally bought the 12 gauge extension cable and 1800w psu for my rig. the 1800w ups has been in my rack since december. next up might be a disk or something. started studying blender a bit today.
08:02:00 <zid> klys: now overload it with SSD power draw by collecting pictures of cats
08:03:00 <klys> well the attached network is not so super. a few days ago i made a w10pro vm just to get itunes.
08:04:00 <klys> today I made a debian vm to get blender going
08:05:00 <zid> you can probably buy hdds preloaded with cats
08:05:00 <zid> you just need to power them
08:05:00 <klys> cat power
10:55:00 <ddevault> rpi4 online :D
10:55:00 <ddevault> but why doesn't my exception vector work
10:55:00 <ddevault> dereference null pointer in qemu => goes to my fault handler
10:55:00 <ddevault> same thing on rpi4 => hangs
10:56:00 <ddevault> actually it doesn't hang, it just werks, then it hangs later in the code I wanted to debug via the fault handler
11:07:00 <zid> you should debugger your debugger
11:08:00 <Ermine> Either qemu or rpi4 is broken
11:09:00 <GeDaMo> Is it possible the fault handler is not saving / restoring something properly and qemu just gets away with it?
11:10:00 <ddevault> I don't think so
11:10:00 <ddevault> in any case my fucking serial port is broken again
11:10:00 <ddevault> so I have to solve bullshit problems before I can solve real problems
11:12:00 <froggey> there are no real problems, it's bullshit all the way down
11:13:00 <ddevault> serial ports are the bane of my fucking existence
11:13:00 <ddevault> remember back when every PC had one and you didn't need a godawful janky USB adapter plugged into random pins on a fucking SoC
11:13:00 <froggey> make sure your exception vector is properly aligned. I misread the docs and had mine 1k aligned but it needed to be 4k aligned (or something like that), worked fine in qemu but not real hardware
11:13:00 <ddevault> thanks for the tip, will check that
11:14:00 <Ermine> tfw my motherboard has serial port but it is basically unreachable
11:17:00 <ddevault> well, good news is I got it to halt when I dereference a null pointer
11:17:00 <ddevault> still exception no worky though
11:19:00 <Ermine> Btw is step-by-step execution possible on rpi?
11:21:00 <GeDaMo> Is that something you could do with JTAG?
11:22:00 <Ermine> Idk. I mean, I would do that in that situation to compare what qemu does and what rpi does
11:25:00 <zid> I don't know if I have a serial port without doing any soldering
11:25:00 <ddevault> hunch is that my EL2 => EL1 code is wrong
11:25:00 <zid> The nuvoton chip has literally everything on it
11:25:00 <ddevault> maybe I should try to set up vbar in my EL2 bootloader and see if it works to verify this hunch
11:25:00 <zid> it probably has like 18 serial po`rts
11:27:00 <zid> yea just need to wire up.. 14 pins
11:27:00 <zid> sorry 16, it goes onto another page..
11:31:00 <Ermine> That white guy behind the wire is my serial port :] https://i.imgur.com/Pq0dAk4.jpeg
11:32:00 <zid> idk if mine is wired up, it's a similar board but mine is micro
11:32:00 * zid grabs the manual
11:34:00 <zid> ya no serial, aafp, spdif, power, reset, go, fan2, usb, usb, sata, panel on the bottom of the board
11:34:00 <Ermine> Who needs spdif stuff I wonder
11:34:00 <zid> people who want digital audio?
11:35:00 <zid> no point doing analogue until the final step
11:35:00 <zid> if you don't have to
11:35:00 <Ermine> Aren't jacks about digital audio?
11:35:00 <zid> 'jacks about' ?
11:35:00 <Ermine> 3.5mm ports
11:35:00 <zid> never ever?
11:35:00 <Ermine> ?
11:36:00 <zid> 3.5mm ring connectors have always been used for analogue
11:36:00 <Ermine> Ah
11:36:00 <zid> I've never seen anybody put anything digital over it ever, despite the 60 years or whatever they've had the chance to
11:36:00 <zid> maybe you could count like, loading programs off tape drives?
11:36:00 <Ermine> Well, isn't digital audio something niche?
11:37:00 <zid> not if you do audio
11:37:00 <zid> if you're just a home gamer you'll just plug your headphones into your mobo
11:37:00 <Ermine> For home analogue seems to be okay. I can listen to music and play games
11:37:00 <zid> if you just have your PC as part of a complicated audio setup and you have nice digital gear you'd absolutely use the digital output instead
11:38:00 <zid> a lot of people do digital audio just by virtue of using USB headsets these days though
11:38:00 <zid> the headphones themselves have a DAC
11:38:00 <Ermine> So it would make sense to put spdifs in specialized hardware for audio people, but I have it in rather consumer hardware
11:39:00 <zid> digital is consumer af
11:39:00 <zid> spdif is from the 80s
11:40:00 <zid> It's also basically free to provide
11:40:00 <zid> given it's digital already to begin with at the source
11:41:00 <zid> the whole bottom left corner of your mobo could be removed if they didn't offer analogue, all spdif removal gets you is the little black header above your aafp header removed
11:41:00 <zid> (the three pin with 1 pin missing guy)
11:50:00 <ddevault> hrmph
11:50:00 <zid> ddevault: Remember to add a serial port output after every line of code that spits out a couple of meg of debug info
11:51:00 <zid> you'll find it eventually
11:51:00 <ddevault> serial port works
11:51:00 <ddevault> back to dealing with the other problems
11:51:00 <ddevault> though I do have one more bullshit problem, but I can ignore it for now
11:51:00 <zid> is it that your lighter sucks shit and it's tearing the skin off your finger
11:51:00 <zid> that's my problem I am ignoring
11:51:00 <ddevault> no, my lighter is fine
11:52:00 <ddevault> though it does enable problematic behaviors
11:52:00 <ddevault> the other bullshit problem is that edk2 does not autoboot my kernel anymore
11:52:00 <ddevault> have to go to the shell
11:56:00 <ddevault> bleh
11:56:00 <ddevault> anyone ever had issues with vbar not working on rpi?
11:56:00 <ddevault> no good leads yet
11:57:00 <ddevault> aligned on 4096
11:58:00 <ddevault> ooh ooh
11:58:00 <ddevault> can reproduce in qemu if booting from EL2
11:59:00 <zid> quick, assert(el == 8)
11:59:00 <ddevault> good call
12:01:00 <gog> zid: cricket
12:01:00 <gog> stop buying the cheap chinese ones
12:01:00 <gog> or bic
12:01:00 <Ermine> cheap chinese cheese
12:01:00 <ddevault> okay I am in EL1
12:01:00 <gog> but also i am no longer smoking
12:01:00 <ddevault> in any case that's not surprising since I'm using EL1 page tables and it does not blow up too early
12:03:00 <ddevault> hm
12:03:00 <ddevault> that seems interesting
12:05:00 <ddevault> sp is zero
12:06:00 <ddevault> so double faults all day when it tries to push the CPU state
12:06:00 <zid> gog: I bought a fucking clipper
12:06:00 <zid> but CAPITALISM
12:06:00 <gog> lmao
12:06:00 <zid> so it ran out of flint in 4 strokes and out of gas in 8 seconds
12:07:00 <zid> cus you can't SEE that they've been reducing those by 10% every year since 2008
12:07:00 <gog> bics never run out of flint
12:07:00 <zid> so you're like "fuck it, clippers are good, I'll pay"
12:07:00 <gog> they have like 4cm of flint
12:07:00 <gog> they always have more than half left when the gas is gone
12:07:00 <zid> I bought a pack of flints after it ran out
12:07:00 <zid> "fuck it, clipper can change flints easy, I paid for this privledge"
12:07:00 <gog> can they refill?
12:07:00 <zid> and then it ran out of gas after 2 strikes on the new flint
12:07:00 <zid> so now I need more gas
12:08:00 <gog> if you can refill them then maybe the cost is worth it
12:08:00 <zid> https://cdn.shopify.com/s/files/1/1796/9825/products/clipper-lighter-delivery-service.jpg?v=1487654088
12:08:00 <zid> that's a clipper, in case they don't sell them there idk
12:08:00 <gog> yeh i've seen them
12:08:00 <zid> the flint is on a plastic stem that pulls out
12:08:00 <zid> you can unscrew the bottom of the stem and remove the spring
12:09:00 <gog> they probably sell them but most palces sell cheap ones or crickets
12:09:00 <zid> https://i.ebayimg.com/images/g/E1IAAOSwnq5jh-X1/s-l1600.jpg
12:09:00 <gog> crickets are like bics, they're fully disposable and not refillable
12:09:00 <gog> which is not very environmentally responsible
12:09:00 <zid> I can't actually find the clipper atm so I haven't even attempted to order some gas
12:10:00 <gog> the key difference between a cricket and a bic is that a cricket is designed to fit in cigarette packs
12:10:00 <zid> also the flint that came with it was not infact, a clipper flint, it like turned to mush and made the wheel dirty
12:10:00 <gog> oops
12:10:00 <zid> I have a lithium polymer electric lighter somewhere for this very reason
12:10:00 <zid> but I can't find that either
12:11:00 <zid> I'm looking on my desk and I found some.. corsair vengeance, a xeon
12:12:00 <zid> hot sauce
12:12:00 <zid> a 6800 Ultra
12:12:00 <zid> a wii
12:12:00 <gog> neat
12:12:00 <zid> AHA, a nice orange disposable that sparks nicely
12:13:00 <zid> I can at least light a different lighter off that one, and not bleed afterwards
12:13:00 <gog> what are you smoking
12:14:00 <zid> idk, brown stringy stuff
12:14:00 <ddevault> SP_EL1 is 0, SP_EL1 is the stack pointer I expect to be using
12:14:00 <gog> i want to smoke cigarettes but i will die
12:14:00 <ddevault> SP_EL0 is the sp I want, rather
12:14:00 <ddevault> so why is sp suddenly zero...
12:15:00 <zid> cigarettes are gross
12:16:00 <zid> also I'd have to sell my solid gold ferrari to be able to afford a pack these days
12:16:00 <zid> everybody smokes tobacco smuggled in from belgium instead
12:19:00 <Ermine> ddevault: dumb conjecture, maybe rpi zeroes it on some event?
12:19:00 <ddevault> can repro in qemu now
12:21:00 <zid> I get credit in the patch notes right
12:21:00 <ddevault> j`ey: why might sp become zero during an exception entry from EL1 => EL1, where SP_EL1 is 0 and SP_EL0 is the desired stack pointer?
12:22:00 <ddevault> j`ey: this only occurs when my system boots from EL2
12:32:00 <j`ey> so you have set SPSel?
12:32:00 <ddevault> yeah okay this is it
12:32:00 <ddevault> it should be 1
12:32:00 <ddevault> but is zero when coming from EL2
12:33:00 <sham1> That's odd
12:33:00 <sham1> :set paste should work just fine
12:33:00 <j`ey> what does coming from EL2 mean?
12:33:00 <j`ey> is EL2 your code?
12:34:00 <ddevault> short answer is "coming from EL2" means qemu -M virt,virtualization=on
12:34:00 <ddevault> then my bootloader drops to EL1
12:38:00 <ddevault> okay now I'm fucking confused
12:40:00 <ddevault> according to gdb
12:40:00 <ddevault> spsel = 1
12:40:00 <ddevault> sp = 0xffff800000023bc0
12:40:00 <ddevault> sp_el1 = 0x7f7fc1e0
12:40:00 <ddevault> o_O
12:41:00 <j`ey> you want to set spsel to 0 I thought?
12:41:00 <j`ey> you want to always use sp_el0?
12:42:00 <ddevault> I want my code to work ;_;
12:42:00 <ddevault> now that I have a stronger lead I'll come back later when I better understand the problem space
12:42:00 <j`ey> lol
12:42:00 <j`ey> '0b0 Use SP_EL0 at all Exception levels'
13:17:00 <zid> That seems like a very important bit for managing yer stacks
13:30:00 <ddevault> well, got my fault handler to execute
13:30:00 <ddevault> problem is that the code which faults is the code that prints numbers for printf :<
13:31:00 <ddevault> not reproducible in qemu, naturally
13:32:00 <ddevault> interestingly, same logging code works in the EFI stuff
13:33:00 <zid> printf is naughty and needs the stack
13:33:00 <zid> stack pointer is overlapped with your .data is my wild guess for now
13:33:00 <zid> printf is the only thing with enough depth so far to overwrite anything important
13:33:00 <zid> or .text
13:34:00 <ddevault> well, I could just increase the stack size for a cheap test
13:34:00 <ddevault> but I would expect this to fail in qemu as well if that were the cause
13:45:00 <ddevault> hrm, how am I going to get useful information out of this thing
13:48:00 * ddevault writes "fn stupid_log"
13:54:00 <ddevault> I have successfully extracted a number from my device https://paste.sr.ht/~sircmpwn/619b5c90f02a4161ea2eb5e210e77aeaa5a67fb8
13:54:00 <bslsk05> paste.sr.ht: paste.ha — paste.sr.ht
13:56:00 <ddevault> translation fault! FAR is bogus though
13:56:00 <ddevault> wonder what causes this
13:59:00 <ddevault> hrm
14:00:00 <ddevault> should solve this logging problem first though
14:00:00 <ddevault> PC alignment fault? wut
14:12:00 <ddevault> jtag would be nice
14:13:00 <zid> pootag is cheating, find an LED to flash
14:13:00 <ddevault> well, I can get output from it
14:14:00 <ddevault> hmm...
14:14:00 <ddevault> I wonder if my bss is not zeroed
14:15:00 <Ermine> Is it supposed to be?
14:15:00 <ddevault> yes
14:16:00 <zid> it's one of the very few requirements C expects from its environment
14:16:00 <zid> that static storage duration stuff is zero'd
14:17:00 <ddevault> yes that was it
14:17:00 <Ermine> But this is Hare, not C
14:17:00 <ddevault> hare has the same bss constraint
14:19:00 <ddevault> wew now we're cooking
14:19:00 <ddevault> landed on an assertion with // TODO on it
14:19:00 <ddevault> that's what I like to see
14:40:00 <geist> ddevault: i'm sure you've figured it out since then, but in general most of those things (like SPSel) are banked by EL
14:40:00 <ddevault> yeah
14:40:00 <geist> so when you drop from EL2 to EL1 a bunch of things (like all the bits in PSTATE) you have to re-configure
14:40:00 <ddevault> aye
14:40:00 <geist> or configure the EL1 one from EL2 before you drop
14:40:00 <geist> cool
14:40:00 <ddevault> thankfully I did get past this point
14:41:00 <geist> gneeral rules being that in a higher EL you can access banked copies of registers in lower ELs, but not vice versa
14:41:00 <ddevault> going to have to revisit this once I'm ready to do scheduling
14:41:00 <ddevault> for now it's Good Enough(TM)
14:42:00 <geist> :thumbs up:
14:43:00 <geist> in general the usual thing to do with SPSel is to use the banked version of SP (i forget the polarity of the register)
14:43:00 <ddevault> ideally I'd like to be able to replicate what I do on x86_64
14:43:00 <geist> ie, SP = SP_EL1 when in EL1, etc
14:43:00 <ddevault> which is set the interrupt stack to the current process's context structure
14:43:00 <geist> the other mode is pretty weird, but useful in very specific situation
14:43:00 <ddevault> but I suspect I won't be able to do that, we'll see
14:43:00 <ddevault> well, maybe I can do that
14:43:00 <geist> yah that's probably not what you want to do. the banked SP is much more useful and flexible than x86-64, you probably want it
14:43:00 <ddevault> anyway, problem for future me
14:44:00 <ddevault> oh I'm going to use the banked registers for sure
14:44:00 <geist> ie, when in user space you can just leave the kernel stack loaded up, and thus dont need any of that TSS nonsense
14:44:00 <ddevault> unrelated probem
14:44:00 <ddevault> problem*
14:44:00 <geist> for anchors you want to look into TPIDR_EL1
14:44:00 <geist> just a 'free' register you can put whatever you want into
14:44:00 <ddevault> aye
14:44:00 <ddevault> single threaded system for now though
14:45:00 <ddevault> not in scope for the demo I'm working on
14:45:00 <geist> yah and really TPIDR only really is necessary when doing SMP, because without it you can just anchor the global state in some global register
14:45:00 <ddevault> or literally in a global
14:45:00 <geist> er i mean globla variable yes
14:47:00 <ddevault> SMP is the main "big feature" left for my kernel
14:47:00 <ddevault> I mean setting aside things like ports
14:48:00 <ddevault> other remaining tasks are relatively small
14:48:00 <geist> yeah you'll want to so SMP relatively soon
14:48:00 <geist> but definitely get interrupts and context switching working first
14:48:00 <ddevault> yeah preemptive multitasking is already in for x86_64
14:48:00 <ddevault> just thinking in terms of aarch64 port atm
14:48:00 * geist nods
14:49:00 <Ermine> Maybe it's high time to sum up how this stuff works
14:49:00 <ddevault> on x86_64 the kernel is mature enough that I would soon call it 1.0 if I were a bit stupider than I seem to be
14:50:00 <Ermine> What about userspace? Or you aren't in business of providing userland besides the testing one?
14:50:00 <ddevault> I am in the business of providing a userspace
14:50:00 <ddevault> but almost all of the work so far has gone into the kernel
14:50:00 <ddevault> userspace development will really kick off once I finish the IPC codegen tooling
14:50:00 <Ermine> Ah
14:50:00 <geist> you'll find that arm64 is about as complex as x86-64 but in different ways
14:50:00 <ddevault> which is what I was working on before I put everything on hold to do this demo
14:51:00 <geist> it's more straightforward in terms of having less nonsense crap you have to set up Just Because
14:51:00 <geist> but then it's also in a lot of ways much more complex and powerful and subtle
14:51:00 <ddevault> yes, I have found that arm64 is just as much of a nightmare as anything else
14:51:00 <geist> so also easy to screw up
14:51:00 <ddevault> my browser can only open the manual if my computer has had its coffee that morning
14:51:00 <geist> once you grok it it's kinda pleasant to work with, but in the way that driving a high performance car that's finiky and wants to kill you is more fun
14:52:00 <ddevault> tbh though kernel hacking is a problem like any other
14:52:00 <Ermine> Now I want to ask heat if he still thinks aarch64 is good, but he isn't here
14:53:00 <geist> or another metaphor is x86 is more like driving a powerful Harley motorcycle that leaks oil but just sort of powers through it
14:53:00 <ddevault> work on it iteratively and persistently and eventually it works
14:53:00 <geist> vs more of a ducati crotch rocket
14:53:00 <geist> and riscv is like one of those little scooters with a 5hp briggs and stratton motor you have to start with a pull cord
14:53:00 <gog> yes
14:53:00 <gog> i want that
14:54:00 <geist> but requires zero training
14:54:00 <ddevault> I'm doing riscv64 next
14:54:00 <ddevault> looking forward to it
14:55:00 <geist> yeah its refreshingly simple
14:55:00 <gog> me too
14:57:00 <zid> can't let those casio watch devs get too confused
15:04:00 <ddevault> want pizza
15:04:00 <ddevault> erp, wrong buffer
15:04:00 <ddevault> still: want pizza
15:15:00 <zid> oh man a pizza would be unreal rn
15:40:00 <ddevault> screen, picocom, and minicom are all annoying
15:40:00 <ddevault> what's the least shitty way to plug my terminal into a serial port
15:41:00 <Ermine> write your own I guess
15:41:00 <ddevault> saw that one coming
15:42:00 <Ermine> If you don't mind GUI apparently PuTTY is ported to linux. Not that this is perfect though...
15:42:00 <ddevault> hard pass
15:43:00 <Ermine> as you wish
15:43:00 <ddevault> it can't be that hard to implement it myself
15:43:00 <ddevault> open the file, use termios to set baud rate et al, plug into stdin/stdout
15:45:00 <geist> are yo on linux? i usually do screen
15:45:00 <geist> though depends on exactly wat you mean terminal i guess
15:45:00 <ddevault> yeah I'm on linux
15:45:00 <ddevault> I'm using screen now
15:45:00 <ddevault> maybe I'll get fed up enough to write my own, we'll see
15:45:00 <geist> yeah either that or minicom
15:46:00 <Ermine> Maybe it's worth it to write something refreshingly simple and get some dopamine for working on something harder
15:46:00 <ddevault> I'll probably end up spending a couple of hours on it and if it ends up being more work than that, set it aside until the demo is done
15:47:00 <ddevault> have to flesh out termios support for hare first
15:48:00 <geist> yah it's quite simple to just use ttyios to open the serial port, turn off all cooking, and pass it directly through
15:49:00 <ddevault> I foresee a minor annoyance in that I'll have to use nonblocking I/O to handle both directions
15:51:00 <Ermine> I was at sysadmin competition some time ago and I failed to figure out which tty out of /dev/tty* I should use to get to cisco switch through serial line. What a shame.
15:51:00 <ddevault> I hope you learned your lesson
15:51:00 <ddevault> which is that there are better things to do than enter sysadmin competitions
15:53:00 <Ermine> Yeah, but it was fun to me back then
16:00:00 <Ermine> Also fuck dlink for not soldering serial line pins to their router's PCB
16:01:00 <zid> I'd like one of those logic analyzer bulldog clip things
16:04:00 <zid> https://m.media-amazon.com/images/I/81I-P9Kd2kL.jpg
16:04:00 <zid> whole pack of theese in diff sizes'd be cool
16:17:00 <geist> This is a case where the systems/etc whatever named dev nodes in modern linux distros is great
16:17:00 <geist> Ie, /dev/serial/by-uuid., etc
16:17:00 <geist> Great when you have a pile of usb serial ports that can show up in any order
16:17:00 <geist> For raw disk access i use this almost exclusively so i dont accidentally the wrong drive
16:20:00 <ddevault> I do dmesg | tail after hotplugging a disk of some kind
16:50:00 <Ermine> uuid stuff annoys me. So windowsy. However, it seems to be useful for identifying partitions
17:18:00 <gog> no no microsoft has GLOBALLY unique ID's
17:18:00 <gog> the non-MS world are UNIVERSALLY unique
17:19:00 <gog> :)
17:20:00 <jafarlihi> How hard would it be to add SMP support to OpenBSD's vmm and get it to perform as well as KVM? Is there work being done on it?
17:26:00 <gog> openbsd has smp
17:27:00 <jafarlihi> gog I mean for vmm
17:27:00 <gog> oh ok i see
17:27:00 <gog> kernel mode is still single threaded
17:27:00 <gog> uhhh
17:27:00 <gog> probably pretty hard
17:28:00 <gog> there's a lot of moving parts and action at a distance in kernel land
17:29:00 <gog> and then you run into the problem of big locks where you prevent other threads from being scheduled on any cpu while a kernel thread is in a critical section
17:29:00 <gog> or small locks where you need to find every spot where concurrent data access is a problem
17:29:00 <gog> but you also have shorter critical sections
17:29:00 <jafarlihi> Does kernel have to be multi-threaded before vmm can be made multi-threaded for guest OSes?
17:30:00 <gog> i don't know enough about that
17:30:00 <gog> most likely
17:30:00 <jafarlihi> Is there any book or anything I can read if I want to contribute to vmm?
17:30:00 <gog> i don't know
17:31:00 <jafarlihi> OpenBSD would be perfect host OS as daily driver, just do development in Linux VM, but vmm performance sucks
17:31:00 <gog> why not host on linux?
17:31:00 <jafarlihi> Security concerns
17:31:00 <gog> develop on an airgapped system
17:31:00 <jafarlihi> Not practical
17:32:00 <gog> is it more practical to develop on openbsd?
17:32:00 <jafarlihi> I already have host Linux where I don't install shit but develop in VMs where I install shit
17:32:00 <gog> with its performance constraints
17:32:00 <jafarlihi> Well, if it was better performer and vmm supported smp then it would be perfect
17:33:00 <gog> you'll need to weigh the practical considerations against the security considerations
17:33:00 <gog> if you're that paranoid but performance is a problem then an airgapped linux system is your option
17:33:00 <gog> it sounds less practical to work on openbsd to improve its vmm
17:34:00 <gog> and introducing unknown security concerns
17:34:00 <gog> inadvertently
18:31:00 <ddevault> I am confuse about this device tree
18:32:00 <ddevault> #address-cells = <0x01>; #size-cells = <0x01>;
18:32:00 <ddevault> ranges = <0x7e000000 0x00 0xfe000000>;
18:32:00 <ddevault> then the serial device is defined at reg = <0x7e201000 0x200>;
18:32:00 <ddevault> I happen to know that the real address is 0xfe201000
18:32:00 <ddevault> but... uh
18:33:00 <ddevault> I am assuming by my reading of the device tree spec that I determine if a translation range applies by testing if min-child <= addr < max-child
18:33:00 <ddevault> in which case I subtract the child address and add the parent address
18:33:00 <ddevault> but that won't get me 0xfe201000
18:34:00 <ddevault> s/subtract the child address and //
18:39:00 <ddevault> the device tree https://paste.sr.ht/~sircmpwn/f88bf8bef82a9d9a59b29196b5706d18850f98f1
18:39:00 <ddevault> nodes of interest are soc @ 110 and serial @ 1168
18:44:00 <qookie> [19:32:06] <ddevault> ranges = <0x7e000000 0x00 0xfe000000>;
18:44:00 <qookie> you're missing the size here? each entry of ranges is <child-base parent-base size>, perhaps you're misparsing it?
18:44:00 <qookie> for one of the two addresses (idr which) you use the #address-cells value of the parent and for the other one you use the #address-cells of the current node
18:44:00 <ddevault> addr cells and size cells are both 1, though
18:44:00 <qookie> both on soc and on parent of soc?
18:45:00 <ddevault> oh wait the /parents/ addr-cells/size-cells applies
18:45:00 <ddevault> not the node's
18:45:00 <ddevault> that makes sense, thanks!
18:45:00 <qookie> both apply, one for the child-base, one for the parent-base
18:45:00 <ddevault> yeah
18:49:00 <ddevault> hm
18:49:00 <ddevault> so the range is
18:50:00 <ddevault> ranges = <0x7e000000 0x00 0xfe000000 0x1800000 0x7c000000>;
18:50:00 <qookie> it should be <0x7e000000 0x00 0xfe000000 0x1800000>;
18:50:00 <ddevault> which is child(0x7e000000 0x00), parent(0xfe000000 0x1800000), size(0x7c000000); where addr-cells = 2 and size-cells = 1
18:50:00 <ddevault> which... still does not make sense
18:51:00 <qookie> with child = <0x7e000000> parent = <0x00 0xfe000000> size = <0x1800000>
18:51:00 <ddevault> ...
18:51:00 <ddevault> okay, got it
18:51:00 <ddevault> the spec could be a lot better -_-
18:51:00 <ddevault> or I could be a lot less dumb
18:51:00 <ddevault> either way
18:53:00 <qookie> also as a side note i recommend getting acquainted with Documentation/devicetree/bindings in the linux source tree, since that's where all the device-specific properties are described
18:54:00 <ddevault> yeah, been there
18:54:00 <ddevault> not particularly well organized but hey
18:54:00 <qookie> better than having to look at the driver code that parses the properties :^)
18:55:00 <ddevault> in theory, yes!
18:55:00 <ddevault> in practice, the docs suck
18:55:00 <ddevault> so you'll read the code anyway
18:56:00 <qookie> although they aren't always grep-able since some files use a regex pattern to describe the "compatible" values
18:56:00 <ddevault> and it's not like the devices themselves ever have vendor docs, so if you want to know how they work... back to the linux code
18:56:00 <qookie> yeah that's also true
18:56:00 <qookie> and quite unfortunate
18:56:00 <ddevault> agreed.
19:00:00 <ddevault> well
19:00:00 <ddevault> at least it's better than ACPI
19:03:00 <ddevault> most recursion heavy code in my kernel is probably not printf, but the FDT prober
19:24:00 <ddevault> \o/
19:24:00 <ddevault> rpi4 now gets as far as qemu
19:24:00 <ddevault> /without/ an SoC-specific build, same kernel binary as qemu
19:25:00 <ddevault> err, I say that, but now qemu doesn't boot
19:25:00 <ddevault> broke it somewhere along the way I guess
19:25:00 <qookie> nice
19:27:00 <qookie> managarm is in a similar position, except there's separate prekernels for virt and rpi4 (mainly due to the base addresses since i haven't bothered with pic/pie yet)
19:27:00 <ddevault> https://git.sr.ht/~sircmpwn/helios/commit/730adc000ccf5d967fcc3b704f3eaf3b90bd0d04
19:27:00 <bslsk05> git.sr.ht: ~sircmpwn/helios: fdt: implement address space translation - sourcehut git
19:28:00 <qookie> and on my fork i also have a prekernel for exynos 7870 :^)
19:29:00 <ddevault> well, qemu is a problem for tomorrow me
19:30:00 <gog> i have pic working
19:30:00 <gog> well, it runs, who can say whether all of my relocations are always going to be right
19:55:00 * vdamewood relocates a fishy to gog
19:55:00 <vdamewood> hmm... PIF position-independent fishy
19:56:00 * gog memmove(fishy, gog->mouth, fishy_size);
19:57:00 <gog> wait no
19:57:00 <gog> gog->mouth, fishy
19:57:00 <gog> i never get that right
19:58:00 <mjg> do these overlap? :O
19:58:00 <mjg> as the name suggests, move does not actually *move*
20:01:00 <dh`> all the standard functions are the same order as assignment (memcpy, memmove, strcpy, etc.)
20:01:00 <heat> ddevault, do you want me to ruin your day?
20:01:00 <dh`> the legacy ones are the same as cp(1): bcopy, copyin/out
20:01:00 <ddevault> uh
20:01:00 <ddevault> no?
20:01:00 <heat> the ranges property doesn't have the same format across the device tree
20:02:00 <ddevault> you're right
20:02:00 <ddevault> you have ruined my day
20:02:00 <heat> as in, it's not always address : size
20:02:00 <heat> an easy example is the pci nodes
20:02:00 <ddevault> it's not always (addr, addr, size)...?
20:02:00 <qookie> pci is still child parent size, the child just has an address-size=3
20:02:00 <ddevault> re-reading the device tree spec and it does not look like this is the case
20:02:00 <ddevault> unless there is behavior outside of the spec in the wild
20:02:00 <heat> where it's #address-cells=3 and the actual format is "random pci-specific-data, address, size"
20:03:00 <ddevault> erph
20:03:00 <ddevault> I see
20:03:00 <ddevault> well, it could be worse
20:03:00 <qookie> the child address is a 64-bit addr + 32 bits of pci goop
20:03:00 <heat> yes, and that's nuts
20:03:00 <ddevault> don't need to deal with that right now
20:03:00 <ddevault> none of my targets are affected by it
20:03:00 <qookie> rpi4 has pcie
20:03:00 <qookie> and xhci behind pci
20:04:00 <heat> my original idea was to go down the device tree and generically decode ranges myself
20:04:00 <ddevault> ah, so it does
20:04:00 * ddevault shrugs
20:04:00 <ddevault> still, don't need a PCI driver for this device right now
20:04:00 <heat> can't happen because pci will burn and crash
20:04:00 <qookie> heat: the managarm code does that, but only if the nod that contains ranges is compatible with "simple-bus"
20:04:00 <qookie> node*
20:05:00 <heat> and is that the case? what if that isn't the case, bus-specific decode?
20:06:00 <qookie> er, it decodes them always (it has an extra fields for the upper 32 bits of a 96 bit child addr), but it translates the addresses of children automatically if it's compatible with "simple-bus"
20:06:00 <ddevault> that seems like a reasonable solution
20:06:00 * heat nods
20:07:00 <vdamewood> salt water is also a reasonable solution.
20:07:00 <qookie> so far it has not fallen apart but i only tested on qemu virt, rpi4 and exynos7870 :^)
20:08:00 <heat> <jafarlihi> OpenBSD would be perfect host OS as daily driver
20:08:00 <heat> mjg, found theo
20:09:00 <mjg> lemme share an anecdote real kuik
20:10:00 <mjg> a friend of mine, who happened to be a freebsd developer at some point, was attending a bsd conf
20:10:00 <mjg> on a bus to the venue some dude approached him and said +/- "i'm an openbsd user, so i wont greet you"
20:11:00 <mjg> :d
20:11:00 <mjg> it was NOT theo
20:12:00 <qookie> lmao
20:12:00 <heat> hahahahaha
20:15:00 <heat> openbsd would be the perfect host OS under a hypervisor
20:15:00 <heat> a single openbsd instance per CPU
20:15:00 <heat> who says no?
20:17:00 <mjg> there is someone who did it
20:17:00 <mjg> except the hypervisor is also openbsd :d
20:20:00 <heat> ddevault, how are you getting around acpi?
20:21:00 <heat> do you load your device tree manually?
20:23:00 <ddevault> right now I'm loading it manually
20:23:00 <ddevault> but there's a flag in edk2 to make it pass a device tree over EFI that I intend to set up at some point
20:24:00 <ddevault> had it working as a proof of concept with RISC-V via u-boot EFI a while back
20:24:00 <heat> a flag in the platform config?
20:25:00 <ddevault> nah, runtime flag
20:25:00 <ddevault> you can toggle it in the boot manager
20:25:00 <heat> hm, can you toggle it in boot services?
20:25:00 <ddevault> not sure, doubt it
20:25:00 <ddevault> it's controlled by an EFI variable iirc
20:25:00 <ddevault> so runtime services probably
20:26:00 <qookie> solution: use the linux boot proto instead of efi /s
20:26:00 <ddevault> no thanks
20:27:00 <ddevault> did consider it when I was at my lowest point in trying to prepare an EFI stub though :P
20:28:00 <heat> why the /s?
20:28:00 <heat> it's literally the sanest idea
20:28:00 <heat> EFI is only good for booting windows
20:29:00 <heat> you're able to discard around 8MB of compressed code and data for the loss of... absolutely nothing
20:29:00 <ddevault> I just want a standard man
20:30:00 <heat> the linux boot protocol is the defacto standard
20:30:00 <heat> which you will need to use for riscv64 because the EFI support for that is still very alpha
20:31:00 <heat> it's not like this is some kind of x86 linux boot protocol thing where everything is bad and old and horrible with many many fields
20:33:00 <ddevault> also
20:33:00 <ddevault> I need to load shit from the filesystem during boot
20:34:00 <heat> what shit?
20:35:00 <ddevault> boot modules, ala multiboot
20:35:00 <ddevault> at least two files
20:35:00 <heat> the linux bootloaders can just load your initrd if that's what you need, the address even gets tucked away in the device tree
20:35:00 <ddevault> >two files
20:35:00 <ddevault> yes I can cat them together
20:35:00 <ddevault> no I won't
20:35:00 <heat> is there a difference between two files and a cpio/tar? :v
20:36:00 <ddevault> well the first file needs to be an ELF executable
20:36:00 <ddevault> I could cram the second file into an object and stuff it into the executable
20:36:00 <ddevault> but I will not
20:37:00 <heat> you could also just use cpio or tar
20:37:00 <ddevault> or I could not do that
20:37:00 <ddevault> I don't want a cpio or tar parser in my kernel
20:37:00 <heat> ok
20:38:00 <ddevault> nor do I want my "prepare an initramfs" process to involve a linker
20:38:00 <heat> but you will need to fwiw
20:38:00 <ddevault> why?
20:38:00 <heat> because edk2 riscv support is still very early on and in-progress
20:38:00 <ddevault> nah
20:38:00 <heat> yah
20:38:00 <ddevault> I have played with u-boot UEFI on risc-v and it was sufficient for my needs
20:38:00 <ddevault> dunno about edk2 but w/e
20:38:00 <ddevault> I got a working setup
20:39:00 <ddevault> in any case I can just work on the EFI implementation if need be
20:39:00 <heat> >work on the EFI implementation
20:39:00 <heat> ohno!
20:39:00 <ddevault> I've seen scarier domains
20:39:00 <ddevault> life is a series of problems, solve one after another and you eventually run out
20:39:00 <ddevault> or die
20:39:00 <heat> have you?
20:39:00 <ddevault> but hey!
20:40:00 <ddevault> no, but the list keeps shrinking
20:42:00 <heat> i've seen MADT cpu sorting code that called sort() multiple times instead of, erm, calling sort once with a proper compare function
20:43:00 <heat> that code was also subsequently patched to not sort CPUs, and then to sort cpus with a different criteria
20:44:00 <heat> why? who knows, the commit message was something like "We must sort CPUs according to X" with no further explanation of the problem
20:44:00 <heat> i pressed to know why and then the patch stalled and AFAIK never got pushed
20:45:00 <ddevault> this one time I saw a lepoard
20:47:00 <dh`> 99 problems of code on the wall / 99 problems of code / take one down, pass it around ...
20:47:00 <heat> https://raw.githubusercontent.com/tianocore/edk2-platforms/master/Platform/RISC-V/PlatformPkg/Documents/Media/RiscVEdk2BootProcess.svg
20:47:00 <heat> maaaaaaaaaaaaaaaa, they're overengineering riscv again
20:48:00 <ddevault> there's a special place in hell for people who make flowcharts
20:48:00 <heat> the UEFI standards body?
20:48:00 <ddevault> in any case yes they are fucking up our boy
20:48:00 <qookie> [21:28:29] <heat> why the /s?
20:48:00 <qookie> well the linux boot proto is at least somewhat being replaced with uefi due to the arm systemready specs, although if one believes that soc/sbc manufacturers are going to actually follow them is another thing
20:48:00 <ddevault> ACPI is coming
20:49:00 <ddevault> my solution to soc vendors not doing the right thing is to not give a shit about their soc
20:49:00 <heat> qookie, i know, they're destroying fucking booting
20:49:00 <ddevault> booting has not been good for like 40 years
20:49:00 <heat> arm's was simple at least
20:49:00 <ddevault> arm was a fucking nightmare
20:49:00 <heat> now it's overengineered as nuts
20:50:00 <heat> EFI firmware sizes are fucking nuts
20:50:00 <ddevault> I'd rather have too much than literally nothing
20:50:00 <qookie> well at least now we (hopefully, fingers crossed) have a consistenet way of configuring booting though
20:50:00 <heat> they're literally 8MB COMPRESSED
20:50:00 <ddevault> custom kernel build and a custom bootloader for every SoC!@!
20:50:00 <heat> COM FUCKING PRESSED
20:50:00 <heat> the code quality is at best dubious
20:50:00 <qookie> ddevault: linux boot proto didn't require that
20:50:00 <ddevault> which kernel? fuck you! here's a fork of linux 2.7 with a bunch of garbage in it
20:51:00 <qookie> i don't think efi is going to make manufacturers stop maintaining downstream forks instead of upstreaming
20:51:00 <ddevault> well at least there's a standard and I can mail them nasty letters about all of the ways they don't implement it
20:51:00 <heat> things you do not need for arm64 and riscv: the EFI PI spec, the EFI spec, ACPI
20:51:00 <ddevault> instead of just doing my very best to stay as far away from arm as possible
20:51:00 <heat> in fact, their ACPI isn't even real
20:52:00 <heat> it's just a shitty platform description bytecode
20:52:00 <ddevault> whenever some new "hacker" hardware comes out
20:52:00 <heat> the actual do-magic-stuff bits don't do any! because they're "reduced platforms" in the ACPI sense
20:52:00 <ddevault> grep for ARM
20:52:00 <ddevault> close tab
20:53:00 <heat> i can confidently tell you that nobody needs this shit except windows
20:53:00 <qookie> acpi is a double edged sword for me, it's nice that you don't need drivers for every chipset imaginable to shutdown, but then the fact you need a whole bytecode interpreter (where the real world follows what windows/acpica implements and not the spec) is a pain as well
20:54:00 <heat> shutdown is not a hard thing to standardize on
20:54:00 <qookie> that's true
20:55:00 <heat> you know how shutdown works in literally all of Intel's chipsets? outb(CHIPSET_PORT (0xcf9 right?), SHUTDOWN_VAL)
20:55:00 <heat> where both of these values have been stable for the past 20 YEARS at least
20:55:00 <qookie> although i think acpi has a few more things standardized, or at least thermal stuff
20:56:00 <ddevault> what we need is to place a bomb in every vendor's factory
20:56:00 <qookie> as in reading the sensor temps if they're exposeed via aml
20:56:00 <heat> qookie, yes, and they could've just standardized on some interface
20:56:00 <ddevault> which triggers automatically when they design something vendor-specific which could have been a standard
20:56:00 <heat> as would be done in a sane world
20:56:00 <qookie> that's also true yeah
20:56:00 <qookie> sadly neither microsoft or vendors are
20:56:00 <heat> ACPI turned out to be an SMI fest
20:57:00 <heat> where you call a method and boom, now you're in SMI land doing who knows what
20:57:00 <heat> this sucks so hard microsoft had to create ANOTHER STANDARD for reducing SMI usage
20:58:00 <heat> and let me be 100% clear, SMM is also 3000000% nuts
20:58:00 <qookie> oh yeah i'm not denying that
20:58:00 <heat> interrupts disabled and serializes the whole system
20:58:00 <heat> I would love to see how a 128-thread chip enters SMM
21:00:00 <heat> this kind of shitty ACPI and EFI world is what was made the fuck up to solve the "how do we blackbox our IP" thing
21:00:00 <heat> ARM and riscv64 have historically not needed this
21:00:00 <heat> will they start having shitty IP blackboxes now? or is this all for nothing?
21:00:00 <ddevault> aaaaand my FOSDEM submission was rejected without explanation
21:00:00 <ddevault> guess I can stop working on all of the shit I've been doing for the past 6 weeks
21:00:00 <heat> :((
21:01:00 <qookie> idea: just bring a projector and set it up in a hallway and start talking
21:01:00 <ddevault> highly tempting
21:16:00 <ddevault> 136 files changed, 5797 insertions(+), 691 deletions(-)
21:16:00 <ddevault> into the bin it goes
21:23:00 <heat> don't actually throw it in the bin
21:23:00 <ddevault> I mean it's committed to master
22:21:00 <zid> In the days of spinning disks it was important to run a defragmenter to reduce latency spikes in the middle of reading files
22:21:00 <zid> Modern flash memory wear leveling means we now run files through a refragmenter
22:25:00 * vdamewood frgments
22:25:00 * vdamewood fragments
22:32:00 <amj> ddevault: you makes me feel guilty, a year I didn't even sent a email to the people we rejected :(
22:32:00 <Ermine> At least you habe now enough experience to tell the tale of bringing up aarch64 system I guess
22:41:00 <geist> yay seemed like only last year i was the only one trying to get people to do !x86
22:41:00 <geist> (though really it was about 10 years ago. i think mrvn was the first person still here that was pro-arm)
22:43:00 <geist> i remember even arguing with someone here about how portability was good, etc. they were of of the opinion that it was all a waste of time, etc
22:45:00 <epony> portability is paramount
22:45:00 <epony> and then comes standardisation on some layer
22:45:00 <epony> that's the power of C, machine independent machine specific programming
22:46:00 <Ermine> geist: ARM got more traction over the years. I think that introduction ARM machines boosted that process.
22:46:00 <geist> yep
22:47:00 <epony> we call that Berkeley RISC
22:47:00 <geist> but also the availabilty to Regular People of actual interesting ARM machines to run their hobby os on
22:47:00 <ddevault> amj: I didn't get an email, I just logged into penta and it says rejected
22:47:00 <epony> and it's been with the commerce and idustrial controllers programming all along
22:47:00 <geist> 10 years ago or so it was more like 'yeah but i dont have one except this smartphone i can't do anything with'
22:48:00 <epony> the "affordable" RISC has been a long term goal with many, and it's part of the CISC internals too
22:48:00 <geist> ARM has of course been important for a long time, it was more that it wasn't really in the wheelhouse of the average hobby osdevers
22:48:00 <epony> it's been a falsely sustained artificial high pricing on RISC
22:49:00 <epony> the fabless model and the restructuring of the semiconductor industry in the 80ies and 90ies results in more freeform processor design competitive entries
22:49:00 <Ermine> s/introduction ARM/introduction of Apple ARM/
22:50:00 <epony> RISC is from the early 80ies but the designs are theoretic from the earlier machine specification attempts Knuth et all
22:52:00 <epony> it's not very "RISC" when it's realised though, so mostly the register-register and shorter width instructions and more non-specific registers are characteristic (and smaller use of instruction opcodes as an intended design)
22:53:00 <geist> i think of it as a continuum (much like microkernels). you get to pick from a selection of 'risc-like' or 'cisc-like' features and based on what you pick you land somewhere between 1 and 10
22:53:00 <geist> that sometimes upsets folks that like to put things in clear bins but so it goes. the real world is messy
22:53:00 <epony> the trouble with the System on Chip designs is their complexity and incompatible realisations between models and implementers which leaves mostly the machine unprogrammed fully except in reference implementation from the designer-programmer studio company
22:54:00 <Ermine> ARM boot process needs unification. That would bring closer the day when we can declare x86 obsolete
22:54:00 <geist> yes but it's faaaaar better than it was before
22:54:00 <epony> that's where it should be in the programming model.. a selection of feature sets, eventually realised in families of processors that are providing programming interfaces for both models
22:54:00 <geist> just the introduction of PSCI really helped immensely
22:54:00 <geist> it's still a few choices but the boot situation on ARM is more like one of 2 or 3 open solutions
22:55:00 <geist> and a couple closed ones
22:55:00 <geist> vs 100% everything is propretary and bespoke
22:55:00 <Ermine> That's way better
22:59:00 <epony> it is not better if the product is very short lived as huge investments are used in the programming so the native and full SoC programming remains unachievable for independent software developers most of the time on fast paced "non-platforms" but "product bundles"
23:01:00 <epony> it's for the goals and objectives of the embedded appliances and consumer electronics and microcontrollers that these proprietary designs find their realisation, previously in the extremely overpriced RISC workstations that got displaced by much more affordable lower priced and mass produced CISC in personal computers (more universal computing designs)
23:02:00 <epony> it's a specialisation and efficiency model of microprocessor and microcontroller and application specific and generally programmable integrated circuits that produce these different "implementation" conventions / families
23:15:00 <epony> it's just become more mass produced for the mobile market and accessible for consumer and software development kits too, not a major replacement or conversion of the computing principles ;-)
23:16:00 <epony> the need for high performance and efficient machines of all form factors and classes is still there
23:17:00 <epony> imrpovement in the design and programming of smaller classes can improve (and should) the larger middle class machines too
23:18:00 <epony> supercomputers are an interesting class too, if their designs can be brought in size to the middle classes of machines
23:18:00 <epony> that's the directions thngs are moving in, from large into smaller machines, with miniaturisation and efficiency / optimisation on each iteration / generation
23:20:00 <epony> it's very interesting that small form factor machines have now advanced capabilities comparable to the middle class and larger higher energetic machinery
23:20:00 <epony> obviously advances in their designs get propagated to portable and stationary business computing too
23:22:00 <epony> they are not very different as semiconductor technology, just their organisation and fabrication process is more specialised to the needs of integration and consumer bundling sectors
23:25:00 <epony> better programming aims to bring the capabilities and functionally modular-composable machine properties from the larger machines into the system-on-chip variants too, for now it's mostly as small appliances, not yet the modular and interchangeable apparatuses to replace the middle class machines but if that improves the applications, it's a net improvement in general (so portability is paramount)
23:26:00 <epony> the negative results are from non-open and portable backend infrastructure that small computing classes need to support their competitive operation (with the larger machines)
23:27:00 <epony> on compiler toolkits and programming it is accessible, on self-hosted compilation the machinery is too small / needs specialised development kits or retargetting on a larger machine, for aplications.. most of them rely on the backend server farms which is non-portable and non-open
23:28:00 <epony> for educational and hobby and research projects they are quite fine, but limited in performance and programming their proprietary and fast changing specifics
23:30:00 <epony> so they are much more elaborate modern microprocessor-bundling achievements and use the latest processes and most advanced lithography, but in net result are comparable ot the reduced capability of the first portable/personal computers (the 8bit PCs anew)
23:31:00 <epony> mostly the result of the battery operation and thermal design and still "large feature" sizes for that compact device form factor
23:32:00 <epony> it's probably a good 20-30 years ahead for that to improve, and it's possible, the feature sizes of semiconductors are going to shrink 10-100 fold more and these machines will improve in both accessiblity / programming and also capability or at least thermal and energetic for a more continuous operation
23:33:00 <epony> but the middle class and large class machines are not going to stand still too ;-)
23:34:00 <epony> the fabless model allows more competition, it's a real shame to have only one proprietary technology design reused by all competitors, standards are needed and multiple sources
23:38:00 <epony> negative reactions to semiconductors adoption in consumer appliances is not realistic, it's very important and happening (already happened in televisions in the 80ies and early 90ies with reuse of specialised and general chip-compuers), same happened with modems and other consumer electronics, and networking appliances are the primary candidates for more and better semiconductors
23:38:00 <epony> so these designs are really oriented towards microcontrollers and network class machine nodes
23:39:00 <epony> entry level computing and portable and wearable is their real specialty
23:39:00 <epony> better programming is an important achievement
23:42:00 <epony> we're in the epoch of always on networking and collaborative computing due to advancements in communications use of computerised elecrtonics, that is the small computers becoming microcontroller and microprocessors in modems and network infrastructure
23:43:00 <epony> when these achieve the capabilities of the modern smart-phones, we're all advancing our portability and networking (and energy utilisaion / efficiency of computing)
23:44:00 <epony> when their improved efficiency propagate to the middle class machines we're achieving localised and independent computing as the infrastructure for the roaming appliances
23:47:00 <epony> it's entirely feasible and possible even today (and for the last 2 decades since the 64bit epoch, when microntrollers raised their capabilities with minaturisation and more logic gates in them comparable to the middle class machines) that our devices which we perceive as storage and networking and memory units in the computer, are computers on their own with their internal operating systems, much alike the system-on-chip appliances
23:48:00 <epony> so, we can even begin having software defined networking and storage and.. memory architectures propagating to the middle class machines
23:49:00 <epony> that's advancements from the large supercomputer brought in the middle class with componentry from the small class machines
23:49:00 <epony> it's going to be much fun programming and achieving heterogenous systems designs with on processor service oriented applications
23:50:00 <epony> that's why it's important to get more open, standardised and competitive programming and portability for applications and their organisation
23:52:00 <epony> programming and networking models success on the middle class bring utility to the small class machines, their designs need to be improved so they are portable and standardised and their utility can be retrofitted in middle class machines as well
23:54:00 <epony> the important application for efficient and highly integrated systems is in application specific extensions to general programmability machines, so their extensions modules need general programmability too
23:54:00 <epony> https://en.wikipedia.org/wiki/Hardware_acceleration lists these in detail
23:54:00 <bslsk05> en.wikipedia.org: Hardware acceleration - Wikipedia
23:55:00 <epony> and the other important advancement https://en.wikipedia.org/wiki/Reconfigurable_computing#High-performance_computing
23:55:00 <bslsk05> en.wikipedia.org: Reconfigurable computing - Wikipedia
23:57:00 <epony> the middle class machines need these so they can be the next class of machines on which to service and facilitate the small class machines in local affinity much more evenly distributed (thus achieving reliability) edge and uniform computing
23:59:00 <heat> Ermine, why do you need a unified boot process?
23:59:00 <heat> is that something you *actually* want?