marcan changed the topic of #asahi-dev to: Asahi Linux: porting Linux to Apple Silicon macs | General development | GitHub: https://alx.sh/g | Wiki: https://alx.sh/w | Logs: https://alx.sh/l/asahi-dev
ch3sh1r3c4t has quit [Quit: ZNC - https://znc.in]
ch3sh1r3c4t has joined #asahi-dev
ch3sh1r3c4t has joined #asahi-dev
DanB91 has quit [Remote host closed the connection]
DanB91 has joined #asahi-dev
DanB91 has quit [Remote host closed the connection]
DanB91 has joined #asahi-dev
DanB91 has quit [Remote host closed the connection]
DanB91 has joined #asahi-dev
DanB91 has quit [Ping timeout: 246 seconds]
DanB91 has joined #asahi-dev
DanB91 has quit [Client Quit]
riker77_ has joined #asahi-dev
riker77 has quit [Ping timeout: 240 seconds]
riker77_ is now known as riker77
jhartzell42 has quit [Ping timeout: 264 seconds]
phiologe has quit [Ping timeout: 260 seconds]
phiologe has joined #asahi-dev
jn__ has quit [Ping timeout: 272 seconds]
jn__ has joined #asahi-dev
ah-[m] has quit [*.net *.split]
skillfulman23[m] has quit [*.net *.split]
stylefish[m] has quit [*.net *.split]
os[m] has quit [*.net *.split]
fried_dede[m] has quit [*.net *.split]
numa[m] has quit [*.net *.split]
Jamie[m] has quit [*.net *.split]
hypergenesis[m] has quit [*.net *.split]
TellowKrinkle[m] has quit [*.net *.split]
randohacker[m] has quit [*.net *.split]
mofux[m] has quit [*.net *.split]
crafteck[m] has quit [*.net *.split]
Jasper[m] has quit [*.net *.split]
jinen[m] has quit [*.net *.split]
CamdenB[m] has quit [*.net *.split]
smist08[m] has quit [*.net *.split]
nhlism[m] has quit [*.net *.split]
ConeOfAttack[m] has quit [*.net *.split]
foxlet has quit [*.net *.split]
bastilian has quit [*.net *.split]
Avion[m] has quit [*.net *.split]
bjornjulander[m] has quit [*.net *.split]
blazra has quit [*.net *.split]
clayfreeman has quit [*.net *.split]
ConeOfAttack[m] has joined #asahi-dev
jinen[m] has joined #asahi-dev
nhlism[m] has joined #asahi-dev
Avion[m] has joined #asahi-dev
blazra has joined #asahi-dev
smist08[m] has joined #asahi-dev
CamdenB[m] has joined #asahi-dev
bjornjulander[m] has joined #asahi-dev
bastilian has joined #asahi-dev
clayfreeman has joined #asahi-dev
foxlet has joined #asahi-dev
shawnj2[m] has quit [Ping timeout: 246 seconds]
wolf511[m] has quit [Ping timeout: 246 seconds]
mellotron1[m] has quit [Ping timeout: 246 seconds]
jamesmunns[m] has quit [Ping timeout: 246 seconds]
svenpeter has quit [Ping timeout: 246 seconds]
Florian[m]2 has quit [Ping timeout: 240 seconds]
ts170[m] has quit [Ping timeout: 240 seconds]
khronokernel[m] has quit [Ping timeout: 240 seconds]
mcnight[m] has quit [Ping timeout: 240 seconds]
liur[m] has quit [Ping timeout: 240 seconds]
jevinskie[m] has quit [Ping timeout: 240 seconds]
josiahmendes[m] has quit [Ping timeout: 240 seconds]
izzyisles[m] has quit [Ping timeout: 240 seconds]
enverb[m] has quit [Ping timeout: 240 seconds]
nufflee[m] has quit [Ping timeout: 240 seconds]
redbluescreen[m] has quit [Ping timeout: 240 seconds]
Bastian[m] has quit [Ping timeout: 240 seconds]
_alice has quit [Ping timeout: 240 seconds]
reispflanze[m] has quit [Ping timeout: 248 seconds]
ldhacker[m] has quit [Ping timeout: 248 seconds]
alexanderwillner has quit [Ping timeout: 248 seconds]
davidrysk[m] has quit [Ping timeout: 248 seconds]
m1kr0[m] has quit [Ping timeout: 248 seconds]
asmon[m] has quit [Ping timeout: 248 seconds]
bylaws has quit [Ping timeout: 248 seconds]
winocm has quit [Ping timeout: 248 seconds]
emily has quit [Ping timeout: 248 seconds]
Eighth_Doctor has quit [Ping timeout: 248 seconds]
nirusu[m] has quit [Ping timeout: 246 seconds]
Alex[m]1 has quit [Ping timeout: 246 seconds]
botoxparty[m] has quit [Ping timeout: 265 seconds]
flokk[m] has quit [Ping timeout: 265 seconds]
ronyrus[m] has quit [Ping timeout: 265 seconds]
brentr123[m] has quit [Ping timeout: 265 seconds]
assusdan[m] has quit [Ping timeout: 265 seconds]
ryanhrob[m] has quit [Ping timeout: 265 seconds]
konradybcio has quit [Ping timeout: 265 seconds]
thecake21[m] has quit [Ping timeout: 265 seconds]
nhlism[m] has quit [Ping timeout: 258 seconds]
CamdenB[m] has quit [Ping timeout: 258 seconds]
smist08[m] has quit [Ping timeout: 258 seconds]
ConeOfAttack[m] has quit [Ping timeout: 258 seconds]
Avion[m] has quit [Ping timeout: 258 seconds]
foxlet has quit [Ping timeout: 258 seconds]
jinen[m] has quit [Ping timeout: 258 seconds]
bastilian has quit [Ping timeout: 258 seconds]
bjornjulander[m] has quit [Ping timeout: 258 seconds]
blazra has quit [Ping timeout: 258 seconds]
jrmuizel[m] has quit [Ping timeout: 260 seconds]
ndom91[m] has quit [Ping timeout: 260 seconds]
samumartinf[m] has quit [Ping timeout: 260 seconds]
hipboi[m] has quit [Ping timeout: 260 seconds]
fl35[m] has quit [Ping timeout: 260 seconds]
sumoon[m] has quit [Ping timeout: 260 seconds]
PedroAraujo[m] has quit [Ping timeout: 260 seconds]
nutmanja[m] has quit [Ping timeout: 260 seconds]
citruscitrus[m] has quit [Ping timeout: 260 seconds]
Alice[m] has quit [Ping timeout: 260 seconds]
fridtjof[m] has quit [Ping timeout: 260 seconds]
rockinrobstar[m] has quit [Ping timeout: 268 seconds]
tarik02[m] has quit [Ping timeout: 268 seconds]
undvasistas[m] has quit [Ping timeout: 268 seconds]
dancer[m] has quit [Ping timeout: 268 seconds]
delroth[m] has quit [Ping timeout: 268 seconds]
xerpi[m] has quit [Ping timeout: 268 seconds]
ewlsh[m] has quit [Ping timeout: 268 seconds]
bastilian has joined #asahi-dev
foxlet has joined #asahi-dev
emily has joined #asahi-dev
jamesmunns[m] has joined #asahi-dev
svenpeter has joined #asahi-dev
flokk[m] has joined #asahi-dev
ryanhrob[m] has joined #asahi-dev
ronyrus[m] has joined #asahi-dev
brentr123[m] has joined #asahi-dev
assusdan[m] has joined #asahi-dev
jamesmunns[m] has quit [*.net *.split]
tarik02[m] has joined #asahi-dev
ewlsh[m] has joined #asahi-dev
dancer[m] has joined #asahi-dev
shawnj2[m] has joined #asahi-dev
wolf511[m] has joined #asahi-dev
mellotron1[m] has joined #asahi-dev
jamesmunns[m] has joined #asahi-dev
rockinrobstar[m] has joined #asahi-dev
jamesmunns[m] has joined #asahi-dev
jamesmunns[m] has quit [Changing host]
svenpeter has quit [Ping timeout: 240 seconds]
bastilian has quit [Ping timeout: 246 seconds]
jamesmunns[m] has quit [Ping timeout: 244 seconds]
emily has quit [Ping timeout: 265 seconds]
ewlsh[m] has quit [Ping timeout: 240 seconds]
foxlet has quit [Ping timeout: 260 seconds]
dancer[m] has quit [Ping timeout: 258 seconds]
rockinrobstar[m] has quit [Ping timeout: 246 seconds]
brentr123[m] has quit [Ping timeout: 246 seconds]
mellotron1[m] has quit [Ping timeout: 240 seconds]
shawnj2[m] has quit [Ping timeout: 240 seconds]
assusdan[m] has quit [Ping timeout: 260 seconds]
ronyrus[m] has quit [Ping timeout: 260 seconds]
flokk[m] has quit [Ping timeout: 258 seconds]
wolf511[m] has quit [Ping timeout: 268 seconds]
tarik02[m] has quit [Ping timeout: 240 seconds]
ryanhrob[m] has quit [Ping timeout: 240 seconds]
artemist has quit [Ping timeout: 264 seconds]
artemist has joined #asahi-dev
taziden has quit [Ping timeout: 260 seconds]
enverb[m] has joined #asahi-dev
Bastian[m] has joined #asahi-dev
khronokernel[m] has joined #asahi-dev
liur[m] has joined #asahi-dev
nufflee[m] has joined #asahi-dev
josiahmendes[m] has joined #asahi-dev
thecake21[m] has joined #asahi-dev
izzyisles[m] has joined #asahi-dev
jevinskie[m] has joined #asahi-dev
bylaws has joined #asahi-dev
m1kr0[m] has joined #asahi-dev
konradybcio has joined #asahi-dev
botoxparty[m] has joined #asahi-dev
Alex[m]1 has joined #asahi-dev
ndom91[m] has joined #asahi-dev
jrmuizel[m] has joined #asahi-dev
sumoon[m] has joined #asahi-dev
hipboi[m] has joined #asahi-dev
citruscitrus[m] has joined #asahi-dev
alexanderwillner has joined #asahi-dev
nirusu[m] has joined #asahi-dev
delroth[m] has joined #asahi-dev
os[m] has joined #asahi-dev
ah-[m] has joined #asahi-dev
skillfulman23[m] has joined #asahi-dev
fried_dede[m] has joined #asahi-dev
ldhacker[m] has joined #asahi-dev
winocm has joined #asahi-dev
Alice[m] has joined #asahi-dev
_alice has joined #asahi-dev
fl35[m] has joined #asahi-dev
asmon[m] has joined #asahi-dev
stylefish[m] has joined #asahi-dev
reispflanze[m] has joined #asahi-dev
Florian[m]2 has joined #asahi-dev
davidrysk[m] has joined #asahi-dev
samumartinf[m] has joined #asahi-dev
fridtjof[m] has joined #asahi-dev
taziden has joined #asahi-dev
xerpi[m] has joined #asahi-dev
redbluescreen[m] has joined #asahi-dev
PedroAraujo[m] has joined #asahi-dev
nutmanja[m] has joined #asahi-dev
mcnight[m] has joined #asahi-dev
Avion[m] has joined #asahi-dev
blazra has joined #asahi-dev
Eighth_Doctor has joined #asahi-dev
bjornjulander[m] has joined #asahi-dev
jinen[m] has joined #asahi-dev
ConeOfAttack[m] has joined #asahi-dev
CamdenB[m] has joined #asahi-dev
smist08[m] has joined #asahi-dev
nhlism[m] has joined #asahi-dev
Jasper[m] has joined #asahi-dev
undvasistas[m] has joined #asahi-dev
numa[m] has joined #asahi-dev
TellowKrinkle[m] has joined #asahi-dev
mofux[m] has joined #asahi-dev
crafteck[m] has joined #asahi-dev
Jamie[m] has joined #asahi-dev
randohacker[m] has joined #asahi-dev
hypergenesis[m] has joined #asahi-dev
rockinrobstar[m] has joined #asahi-dev
bastilian has joined #asahi-dev
brentr123[m] has joined #asahi-dev
emily has joined #asahi-dev
ronyrus[m] has joined #asahi-dev
foxlet has joined #asahi-dev
artemist has quit [Ping timeout: 246 seconds]
dancer[m] has joined #asahi-dev
flokk[m] has joined #asahi-dev
artemist has joined #asahi-dev
assusdan[m] has joined #asahi-dev
ts170[m] has joined #asahi-dev
svenpeter has joined #asahi-dev
jamesmunns[m] has joined #asahi-dev
ewlsh[m] has joined #asahi-dev
ryanhrob[m] has joined #asahi-dev
tarik02[m] has joined #asahi-dev
mellotron1[m] has joined #asahi-dev
shawnj2[m] has joined #asahi-dev
wolf511[m] has joined #asahi-dev
VinDuv has joined #asahi-dev
maor26 has joined #asahi-dev
Esmil has quit [Ping timeout: 256 seconds]
Esmil has joined #asahi-dev
rwhitby has quit [Quit: ZNC - http://znc.in]
rwhitby has joined #asahi-dev
VinDuv has quit [Quit: Leaving.]
Bluerise has joined #asahi-dev
<Bluerise> Hi. Just wondering, has anyone here ever talked about porting U-Boot?
<Bluerise> I see agraf is here
<Bluerise> Just don't want to start duplicate efforts.
<jn__> Bluerise: the (IMO) interesting parts of uboot, like raminit, are handled by iboot and AFAIUI you can't replace it
kettenis has joined #asahi-dev
<j`ey> jn__: isnt the interesting bit being able to load a kernel? :P
<jn__> porting uboot for non- hardware specific parts would be possible, i suppose. haven't seen talk of that.
<kettenis> yeah, the context here is loading an OpenBSD kernel
<Bluerise> no, the interesting part is: u-boot provides nvme + usb drivers and an EFI interface to boot other OSes
<kettenis> OpenBSD/arm64 uses UEFI
<Bluerise> yup
<j`ey> it *needs* uefi?
<kettenis> well, not really
<dhewg> it also makes sense for linux. the distro needs a way to tell the bootloader which kernel version to boot, and the infrastructure is there for u-boot
<jn__> oh, i remember some uefi talk in here, where uboot was mentioned
<kettenis> however, the bootloader needs full device access to load random stuff
<dhewg> it also has filesystem drivers to load a kernel off those
<kettenis> and UEFI makes that very easy
<Bluerise> yup
<Bluerise> and for the user: he'd have to supply u-boot as "macos kernel" once
<Bluerise> and can then boot whatever distro he likes from usb or hard drive
<Bluerise> since u-boot can basically boot anything
<j`ey> it's been discussed, but I dont think anyone has started on it
<Bluerise> ok
<kettenis> I'll probably see if I can make a start on that
<kettenis> 'cause I'm getting tired of reinstalling the macho bundled OpenBSD kernel over and over again ;)
<j`ey> kettenis: have you got a fork with your changes?
<j`ey> kettenis: you could also try use m1n1, if you have the right hardware, or can make/get one
<kettenis> don't have the right hardware unfortunately
<j`ey> could ask marcan, he was going to make some
<kettenis> I'm past the point where I really need something like m1n1 ;)
<Bluerise> hehe
<kettenis> although a remote reset would be nice ;)
<Bluerise> kettenis: if you do u-boot, I do the pmgr clock gate (should be simple)
<kettenis> cheat!
<Bluerise> :P
<Bluerise> I can also try u-boot, but only one of us should
<Bluerise> Need pmgr for dwc3
<j`ey> kettenis: well m1n1 gets you a way to reset and reflash without the macho stuff
<j`ey> kettenis: so is there a fork of OpenBSD somewhere?
<Bluerise> no, we just use plain openbsd
<kettenis> we don't do forks ;)
<j`ey> well fork as in, somewhere you have changes
<j`ey> branch, not fork
<kettenis> currently it needs one tiny little patch to fake a Linux kernel header
<marcan> Bluerise: m1n1 is already going to be a bootloader
<marcan> that's the entire point
<marcan> it'll load a kernel from FAT32 (just because that's easy)
<Bluerise> will mini gain efi support?
<j`ey> kettenis: so you made no changes to openbsd?
<marcan> no, I'm definitely not going to reimplement EFI
<marcan> if OpenBSD needs UEFI, then it should use a second stage chained loader that does that
<marcan> m1n1 could be taught to boot u-boot in whatever format it gets built in, quite easily
<kettenis> @marcan: we need an API to access raw disk such that we can read files from an OpenBSD UFS/FFS filesystem
<marcan> and if u-boot reaches the point where it supersedes m1n1 for typical users then that's fine too, that depends on how things go in the long term
<Bluerise> j`ey: a) the only diff is an assembly header that fakes a linux kernel header b) the rest does either not exist yet or is/will be committed straight to openbsd
<kettenis> anyway, nothing exciting yet
<kettenis> the OpenBSD kernel boots and has a framebuffer console
<marcan> basically my current approach is: m1n1 is the first stage loader, and I want to shove as much M1-specific junk in there as possible. I'm fine teaching it to load multiple binary formats, and it will certainly have a boot picker menu and config file, like any other simple linux/OS loader
<kettenis> but no device drivers yet, so you don't get to run a shell
<j`ey> Bluerise: but is there a repo containing a)?
<marcan> how does the openbsd loader interface with firmware to load files from disk?
<marcan> does it require UEFI or can it use a simpler interface?
<j`ey> marcan: Oh, I thought m1n1 was intending to be a much more temporary thing!
<Bluerise> j`ey: http://ix.io/2Nsw
<kettenis> @marcan it depends on the architecture
<kettenis> on armv7 and arm64 it currently uses UEFI
<Bluerise> which everyone else does as well.
<kettenis> but it really only needs a sensible interface to access raw disk blocks and send/receive network packets
<marcan> j`ey: the final direction isn't set yet, but for example, we could wind up with m1n1 embedding u-boot as a built-in second stage, if it makes sense; but OTOH u-boot is mostly an embedded device bootloader, not a boot picker AFAIK
<marcan> so it's not exactly that useful for linux
<kettenis> (whether UEFI can be called a sensible interface is debatable)
<marcan> kettenis: well linux can be booted by just putting a kernel and a ramdisk in ram :)
<marcan> e.g. no UEFI on android arm64
<marcan> nor on raspberry pi
<marcan> so how does openbsd work on the rpi?
<Bluerise> UEFI EDK2
<marcan> heh
<kettenis> you can either use u-boot or the EDK2 on the rpi
<kettenis> loading the OpenBSD kernel in RAM and exuting it works as well
<kettenis> that's what I'm currently doing
<marcan> so the thing about m1n1 is it'll handle CPU init and making a sane linux devicetree, which AIUI u-boot can also use?
<marcan> if the openbsd kernel can be loaded like a linux kernel and booted directly, then doing that directly from m1n1 would probably be the least-effort path
<kettenis> yes, so u-boot as a relatively simple payload would work fine
<marcan> yeah, that too
<marcan> this isn't uncommon
<marcan> e.g. I think the boot chain for the google pixel c has like 4 stages
<kettenis> so what we really want on OpenBSD is to have as much the same boot flow as possible across architectures
<kettenis> some essential bits in that picture are:
<kettenis> 1. bootloader reads some entropy from a file in an UFS filesystem and passes that to the kernel in a special ELF segment
<kettenis> 2. the kernel gets loaded from an UFS filesystem such that you can simply copy it into /. and reboot
<marcan> arch linux arm does something like that, but the kernel can be in /boot (e.g. on the rpi), which means I can just make that FAT32 and not have to have a full ext4/whatever driver in m1n1
<marcan> there isn't a terribly good reason to use a fancy filesystem for the boot partition, e.g. this setup is one fairly common option on PCs (making /boot the ESP)
<marcan> (I use it on a few machines)
<marcan> does openbsd support devicetrees?
<kettenis> yup
<marcan> how does that fit in with UEFI - one or the other?
<kettenis> UEFI has support for device trees
<marcan> ah, heh
<marcan> (I've never used UEFI on ARM)
<marcan> how much of the UEFI API does it need? e.g. if all I need are protocol stubs for disk I/O (read/write sector) and console write (for text output to the framebuffer) then that could conceivably be added to m1n1
<kettenis> ARM (the company) keeps pushing ACPI and some of the newer server systems only support that
<marcan> but I certainly don't want to go down the path of deep hardware info stuff, ACPI, etc
<Bluerise> there's no need for ACPI
<marcan> yeah, ARM also keeps pushing PSCI and there will never be PSCI on M1
<marcan> so we're already diverging there by necessity
<marcan> :)
<kettenis> PSCI isn't a bad idea
<marcan> PSCI needs trustzone, which does not exist on M1
<marcan> so good luck with that
<marcan> there is no EL3
<kettenis> PSCI doesn't really require trustzone
<marcan> aren't PSCI calls monitor calls?
<kettenis> yes, but you can choose between smc and hvc
<marcan> heh, didn't know hvc was an option
<marcan> in that case it could be done, but then you lose virtualization support
<marcan> which is also not something I want to lose
<kettenis> downside of course is that then your kernel would run in EL1 instead of EL2 which means you lose virtualisation
<kettenis> heh
<kettenis> anyway, PSCI isn't essential for OpenBSD
<kettenis> and I don't think Linux cares as much either
<marcan> can you do the same spintable thing Linux supports?
<marcan> that's the other option Linux has
<marcan> and what we will use a priori
<marcan> (I'm going to write support for that in the next day or two)
<kettenis> yes, cause the rpi doesn't have PSCI either if you use u-boot ;)
<marcan> :)
<kettenis> full-disclosure, I'm currently using corelliums preloader-m1 to load the kernel
<marcan> yeah, no offense but I'm not touching that thing
<marcan> in that case it looks like for testing you could and probably should get away with loading openbsd kernels into m1n1, even via serial like I do for linux for development
<kettenis> but I'm interested in seeing what I can do with m1n1
<marcan> and then for production, decide on how you want to hook up the support for loading kernels the normal way
<marcan> either by making m1n1 do enough of UEFI for you guys, if it's really a minimal part; or by chaining u-boot and teaching it about disk I/O
<marcan> how does openbsd get loaded in the u-boot path?
<marcan> just UEFI?
<kettenis> just UEFI
<marcan> fair
<kettenis> we adopted the stuff that agraf did really early on
<marcan> also, if there is a simple enough read-only UFS2/etc implementation I can drop into m1n1 that's fine too
<kettenis> so it really needs a minimal set
<marcan> I'm not opposed to adding FS support as long as it's not NTFS levels of junk
<marcan> as long as the licensing is not a problem
<marcan> the only reason I like FAT32 is that elm-chan fatfs is just so damn easy to use and works everywhere
<kettenis> we have our own ufs/ufs2 implementation in the shared bootloader code
<kettenis> so we only really need raw disk access
<kettenis> note that the BSDs have their own cross-architecture "partition table" called disklabel
<marcan> obviously that's not going to fly on M1
<marcan> apple requires GPT and APFS volumes to boot from
<marcan> so if you want disklabels, they'll have to be inside a GPT partition
<marcan> in there you can do whatever you want
<kettenis> yes, disklabels can live in a GPT partition
<marcan> no problem then
<kettenis> anyway, these are not really details you need to care about
<kettenis> but another reason why we really need raw disk access instead of filesystem access
<marcan> sure
<j`ey> kettenis: OpenBSD runs/can run at EL2?
<marcan> once I have the disk I/O code in here we can revisit, but basically if there is a way I can load your bootloader and give you hooks to get disk I/O - be it via UEFI or some bespoke mechanism - without it being too much useless overhead, that works perfectly fine for me
<kettenis> j'ey: it'll drop down to EL1; no virtualization support yet
<marcan> m1n1 is relocatable and basically standalone, so I don't see why you couldn't just call into its disk I/O as long as you have some sort of sane stack going on
<j`ey> kettenis: ah
<marcan> and actually I think at least a portion of m1n1 needs to stay in RAM after OS boot anyway, to handle resume from sleep scenarios, though that part isn't clear yet
<marcan> has to do with CPU init chicken bits and the resume vector being locked down
<marcan> though obviously that does not include the FS code
<marcan> but to a first approximation we could leave all of m1n1 in reserved RAM, it's not like it's big anyway
<kettenis> anyway, I'll look at using u-boot as a payload
<marcan> well right now u-boot can't talk to the disk anyway, so not sure how much benefit that would be other than for fun :)
<marcan> also depends on the spintable thing, whether u-boot can chain from that to the next stage or whether it reimplements it and thus needs its own CPU init code
<marcan> I haven't looked into any of this in u-boot yet
<kettenis> u-boot doesn't spin up the other CPUs
<agraf> Bluerise: sorry, was asleep until just now :)
<marcan> ah, so it just passes spintable info from the devicetree it gets?
<agraf> Bluerise: I think porting U-Boot is an amazing idea
<marcan> in that case that would work fine in principle
<kettenis> it would just leave them spinning, so as long as it doesn't toch the memory where they're spinning it should be fine
<marcan> yeah
<agraf> Bluerise: It also solves the update problem nicely. The current Corellium blobs require you to go into recovery mode on update, because the kernel checksum is stored in the firmware
<kettenis> things get interesting for suspend/resume of course as you say
<marcan> wonder how much porting it really needs then... probably just the same stuff I did for linux, IRQs and the FIQ timer thing, a patch or two to serial or maybe not even that, and that's about it
<marcan> plus the disk I/O
<kettenis> I think u-boot only uses polled I/O
<agraf> yes, and a bit of startup code
<agraf> IRQs are optional
<marcan> agraf: m1n1 will solve that anyway, as I said I'm adding disk support :p
<agraf> exactly :)
<marcan> the corellium preloader stuff is a terrible idea
<agraf> marcan: why reinvent the wheel?
<marcan> m1n1 was never intended to go that way
<marcan> agraf: because it's easy
<agraf> Haha :)
<marcan> we need to work out disk I/O anyway, so I'll be writing that code for testing purposes
<marcan> once you have that, throwing in fatfs and a simple config file parser is stupid easy
<marcan> and I already did that for asbestos anyway
<agraf> yeah, and then you have distros that are going to curse at you for the rest of your life because they now have to treat M1 special ;)
<agraf> if you want to target distros, you want *one* boot protocol, not 50
<marcan> ALARM already treats every platform as special anyway
<marcan> :p
<agraf> That's the whole reason I built the UEFI support in U-Boot
<agraf> What is ALARM?
<marcan> arch linux arm
<agraf> Alpine?
<agraf> Ah
<marcan> anyway I'm saying you will be *able* to use m1n1 for this, not that distros won't want to chain u-boot
<marcan> chaining u-boot was always one path I had in mind :)
<marcan> we'll see in the long term what ends up being used
<marcan> so yes, someone should port u-boot anyway
<marcan> how do those platforms boot anyway, as far as distros go?
<marcan> do they have tooling to mess with u-boot configs?
<marcan> or is it EFI style bootXXX.EFI?
<agraf> No, U-Boot just implements the UEFI removable protocol
<agraf> yes :)
<marcan> lol ok
<agraf> it even implements bootmgr support these days
<agraf> so in theory you can store an actual boot order
<marcan> store it where?
<marcan> some nvram file?
<agraf> That's implementation dependent
<marcan> how do you pick kernels?
<marcan> ala grub
<agraf> There's a module that does it via OP-TEE, IIRC there's also one that just does it only at boot time via the UEFI env code, so could be anywhere, even on disk
<agraf> you boot grub
<agraf> :)
<marcan> lol
<marcan> yeah as I said, crazy boot chains on ARM
<agraf> or the OpenBSD loader for that matter
<marcan> this is totally going to end up being SecureROM -> iBoot1 -> iBoot2 -> m1n1 -> u-boot -> grub -> linux, isn't it
<agraf> That wouldn't be too far off from the usual boot chains on ARM, yeah
<agraf> I'm still not sure why we would need m1n1 in the picture though
<Bluerise> agraf: heh, that's what I thought as well
<marcan> anyway, one thing I was going to write was embedded second stage support in m1n1, both for testing self-contained boot a la corellium now (which sucks, but has its uses), and for embedding e.g. u-boot
<marcan> well, really the point is m1n1 will spin up the CPUs and apply chicken bits
<Bluerise> agraf: thanks for the EFI support in U-Boot, I'm really happy that we have it :)
<agraf> Sure, absolutely :)
<marcan> if u-boot does not do SMP spinup then we need that
<agraf> Bluerise: I'm super happy it's been useful beyond my own use case ;)
<marcan> and it might make sense not to pollute u-boot with all that junk
<agraf> marcan: U-Boot does SMP spinup on some platforms
<agraf> marcan: There are special per-SoC directories that are basically just dumpsters for exactly that type of code
<agraf> :)
<marcan> also, dealing with ADTs and FDTs
<Bluerise> agraf: it's been a blessing for OpenBSD, and also for $work
<marcan> I mean if u-boot wants to copy and paste all the m1n1 code for this and make m1n1 unnecessary then sure
<agraf> Again, it has special hooks for exactly that type of purpose
<kettenis> turtles all the way down
<marcan> but does it gain anything from that, vs just wrapping it in m1n1?
<agraf> Yeah, let's just see what Bluerise comes up with :)
<marcan> and getting a nice standard devicetree and SMP spintable passed to it?
<Bluerise> marcan: only one binary to install
<agraf> I'd be curious to see which way actually ends up easier / more maintainable down the road
<marcan> Bluerise: m1n1 would embed u-boot as a second stage
<marcan> (again this is common)
<agraf> Bluerise: if you embed U-Boot into the m1n1 binary, you only have one binary too
<agraf> It's more about one source of reference ;)
<Bluerise> for us u-boot is really nice since it does *everything*. so we have one port for u-boot, which depends on the atf port, and the resulting binaries from the u-boot build is all that's needed to be distributed
<marcan> no atf here so :)
<agraf> Bluerise: you could treat m1n1 like ATF, no?
<Bluerise> agraf: hehe, yes
<agraf> Bluerise: just do the linking step with m1n1 instead of ATF
<kettenis> so in this case I would have U-Boot just use the device tree set up by m1n1
<marcan> fwiw I want to see if iBoot2 will just dump whole macho files in RAM or not
<marcan> if it does we could literally do cat m1n1.macho u-boot.elf (or whatever format) > boot.macho
<marcan> not sure yet though
<Bluerise> agraf: compile u-boot, bundle with m1n1 as atf, boot u-boot which first runs m1n1 and jumps back into u-boot or so?
<marcan> if not it would need a trivial tool to embed
<agraf> marcan: You can easily provide a tool to patch the Mach-O header accordingly as part of m1n1 ;)
<kettenis> @marcan: that is essentially what the corellium guys do in their bootloader
<marcan> ^^
<agraf> Bluerise: yup
<marcan> kettenis: yes, but they have a tool
<kettenis> it isn't a simple cat
<marcan> actually let me try this right now
<marcan> actually this won't work
<marcan> because IIRC iBoot2 puts data after the macho
<marcan> so yeah, it'd need a little tool
<marcan> but not a big deal
<marcan> probably just patching a single number in the macho with the payload size
<marcan> actually, I wonder if that works as intended, let me try something
<never_released> agraf: I have a TianoCore port around
<never_released> why use u-boot even
vimal has quit [Remote host closed the connection]
<never_released> (targeted at iPhone 7, but can carry it to the Mac if needed)
<kettenis> tianocore would work as well, but I suspect it isn't as lightweight as u-boot
<Bluerise> oh that's nice, never_released
<kettenis> too much complexity for my liking
<Bluerise> heh.
<never_released> kettenis: u-boot is just as complex :P
<kettenis> but if I don't have to figure it out myself I don't care ;)
<j`ey> never_released: I'd be interested to look at that, if it's online somewhere
<never_released> and I'm kinda interested in running Windows later on
<never_released> j`ey: not touched since a year now
<j`ey> never_released: even so
<Bluerise> Hm, can u-boot boot windows with the EIF API? shouldn't that work? (not questioning, just wondering)
<never_released> Bluerise: don't think so
<agraf> Bluerise: IIRC there were a few things missing for Windows support
<Bluerise> I know my arm64 workstation can boot windows
<Bluerise> (HoneyComb LX2K)
<agraf> Bluerise: that one is using edk2 :)
<Bluerise> heh, yes
<never_released> Windows requirements aren't that big
<agraf> There were a few UEFI protocols that Windows relied on that U-Boot didn't implement last time I looked
<Bluerise> though lx2k can do both edk2 and u-boot, the windows that booted on lx2k was with edk2
<never_released> just UEFI + ACPI + GICv2 minimum :P
<never_released> no FIQ too
<kettenis> a few challenges there ;)
<never_released> kettenis: have been thinking about two horrific ways to achieve a Windows boot
<never_released> first one, getting functional nested virtualisation (because I want the guest to see EL2 too) and have a thin adaptation layer
<never_released> second one, VMSA lock register, to control VBAR
<never_released> (and third-one, which is a no-man's-land, GXF)
<marcan> the m1 does not support nested VM as far as I know
<marcan> ohh this is *excellent*!
<marcan> so it turns out
<marcan> 1) iBoot does indeed do proper mach-o loading, and supports noncontiguous segment loads
<marcan> 2) iBoot does not panic if a segment load overlaps the end of the file
<marcan> 3) instead, it helpfully behaves as if the load filesize was truncated to the end of the machofile, and zeroes out the rest of the buffer
<marcan> that means our payload insertion tool is now officially `cat`
<marcan> I tested up to a 64MB dummy segment off the end of the file and iBoot is perfectly happy with it (and it does not impact boot times visibly)
<marcan> so we can have up to a 64MB payload with that, no problem
<marcan> just cat it on
<marcan> this also means I can have a lot of fun with payload formats, e.g. embed a command script by cating it on, very very convenient for end users
<marcan> should be able to have a single binary build that does everything this way
<marcan> file layout is [m1n1 macho text/rodata/data][payload], memory layout is [firmwares and stuff iBoot puts in RAM][ASLR padding][m1n1 macho text/rodata/data][m1n1 bss][payload..... pad to 64MB][things iBoot passes us, cmdline, adt, etc][free memory.......][framebuffer and maybe other things][top of RAM]
<kettenis> any way to force alignment of [payload]?
<marcan> KASLR alignment from iBoot is 64K as far as I can tell, and we can preserve that in the mach-o
<marcan> maybe 16K? definitely no smaller than that
<marcan> ah yeah 16K
<marcan> but m1n1 can copy it out to a more-aligned buffer if we need that for something
<marcan> as long as whatever file format it is has a length (though since the memory is padded with zeroes, we could heuristically use that too, but we should probably not go there)
<kettenis> so an ELF header or a linux kernel header would work (could do either for a u-boot payload)
<never_released> marcan: what I'd do is concatenating the macOS kernelcache
<never_released> personally
<never_released> to have a Continue to macOS option
<never_released> but it might be "why not both?"
<marcan> kettenis: yup
<marcan> never_released: well, we need to do that every update anyway, unless we implement APFS support; at that point it makes more sense to just copy the macOS kernelcache to the linux boot partition as part of the install process I think
<marcan> also I intend to use a different APFS boot structure for linux anyway
<marcan> not reuse a single macos one
<marcan> because people will want to be able to do secure macos boot, we should't mix the OSes
<marcan> I think the only people interested in this should be people who want to mess around with the darwin kernelcache
<never_released> marcan: when you have FS access
<never_released> the macOS kernel cache is easily query-able anyway
<marcan> as long as you can read APFS, yes, but I'm not putting APFS into m1n1 :p
<marcan> from linux though, sure
<marcan> so you could copy out updates from there
<never_released> marcan: I want to use Linux as a bootloader here :P
<marcan> if you really wanted to do this
<never_released> think that I said it before
<marcan> well... that's not the approach I'm interested in but have fun :p
<marcan> the problem is you're running multiple OSes under one OS context from the firmware's point of view then
<marcan> which isn't really how things are intended to work
<never_released> just don't load the FW-dependent stuff
<dhewg> sounds like ps3 petitloader
<never_released> not communicating with SEP for example
<marcan> well yes, but macos does that, and I intend to do that too
<marcan> because it's useful
<marcan> I don't want to have to buy typeC yubikeys and have them eat one port on these macs
<never_released> I mean
<marcan> when there is a perfectly fine embedded secure element
<never_released> for a bootloader kernel
<never_released> not needed
<marcan> yes but you can't *switch* contexts
<never_released> you have a Linux build without those
<marcan> so then whatever you bootload ends up in the same context
<never_released> marcan: hmmm... but you have to pay the 15GB for each macOS install cost
<never_released> then
<marcan> no
<marcan> I will be doing minimal stub boot partitions without a full macos
<never_released> marcan: and how will you authentify then?
<never_released> to demote
<never_released> remember, your new OS context is at full security
<marcan> right *now*, you'd have to install macos, make a user, then remove all the garbage and shrink the partition once demoted
<marcan> however, we can build tooling to avoid that
<never_released> you think?
<never_released> it's by design
<marcan> yes and no
<marcan> there are APIs for importing user stuff to a new install, or for adopted installs
<marcan> there's just lots of bugs because apple rushed this all out
<never_released> you suppose that python exec will stay in macOS Recovery forever
<never_released> to call those funcs though ctypes
<marcan> I'm 99% sure we will be able to build good tooling to do this
<never_released> I think that's going away
<marcan> I disagree
<marcan> :)
<never_released> I wouldn't bet on that :)
<marcan> and I will
<marcan> :)
<j`ey> never_released: why do you think it's going away?
<never_released> j`ey: macOS Recovery is supposed to be a secure env with code signing enforced
<marcan> for starters, we could do the install and all this stuff from macos itself, not doing anything from 1TR except calling bputil/kmutil
<never_released> today, you can copy for example Python from macOS because that's Apple signed
<marcan> because installing macos from macos is supported
<never_released> having a hole in the door
<marcan> never_released: you're making assumptions about apple's security model that don't make sense
<marcan> 1TR lets you run unsigned code on the machine
<marcan> *after* you authenticate
<marcan> apple doesn't care what you do in 1TR as long as you assert physical presence and, for OS-impacting operations, provide credentials
<marcan> to guarantee data security
<never_released> marcan: 1TR itself is tightly locked down, with an Apple-only CS policy
<marcan> but you have a root shell
<marcan> anyway, you can have your opinion and I can have mine :)
<marcan> we'll see what apple does
<never_released> yep, and Apple-only CS + can freely run any Apple-signed code at the same time
<never_released> it's a contradiction by itself
<marcan> 1TR has *perl*
<marcan> like in 1TR itself
<never_released> yep
<never_released> it's a walking set of contradictions
<marcan> and you're assuming it resolves one way
<marcan> and I'm betting it resolves another way
<marcan> only time will tell
<marcan> :)
<never_released> I mean, I have a set of bugs to disable AMFI in 1TR
<never_released> but I'd prefer to not _have_ to use them
<marcan> we will not be using any bugs
<marcan> we will be using APIs and features Apple builds
<marcan> I have several possible plans depending on what they do
<marcan> to avoid having to have full macos installs
<never_released> hopefully it matures quickly enough
<never_released> I also want to run Linux from APFS eventually
<marcan> but I'm sure our users will appreaciate being able to run iOS apps in macos while they have a separate linux install
<marcan> so I will not be pushing the shared-context use case
<marcan> if people want to do that that's up to them
<marcan> but there are many pitfalls with that approach
<marcan> not in the least that it's going to break macos updates in some ways
<never_released> about iOS apps on macOS, did you know that they are decrypted?
<never_released> lol
<marcan> and make it impossible for Linux to use the SEP properly
<marcan> *that* part of Apple's grand plan is obvious
<marcan> one OS, one bootpolicy, one context, one data encryption setup, one user auth db, etc
<marcan> so while you can certainly overlap things, that's definitely not how they intend this to be done
flying_sausages has quit [Quit: You just lost the game. Peace Out.]
acelogic2 has quit [Ping timeout: 260 seconds]
flying_sausages has joined #asahi-dev
taziden has quit [Ping timeout: 240 seconds]
taziden has joined #asahi-dev
robinp_ is now known as robinp
JTL has quit [Ping timeout: 264 seconds]
JTL has joined #asahi-dev
<kettenis> Â/window 1
<kettenis> oops, sorry
sirn has quit [Ping timeout: 264 seconds]
narmstrong has quit [Ping timeout: 264 seconds]
nkaretnikov has quit [Ping timeout: 265 seconds]
HeN has quit [Ping timeout: 265 seconds]
eric_engestrom has quit [Ping timeout: 272 seconds]
rann has quit [Read error: Connection reset by peer]
sferrini has quit [Read error: Connection reset by peer]
austriancoder has quit [Write error: Connection reset by peer]
jkkm has quit [Read error: Connection reset by peer]
doof has quit [Write error: Connection reset by peer]
WhyNotHugo has quit [Write error: Connection reset by peer]
brinly has quit [Read error: Connection reset by peer]
tardyp has quit [Read error: Connection reset by peer]
jabashque has quit [Read error: Connection reset by peer]
hatf0 has quit [Read error: Connection reset by peer]
titanous_ has quit [Read error: Connection reset by peer]
r1fl has quit [Read error: Connection reset by peer]
NekomimiScience has quit [Read error: Connection reset by peer]
rjeli has quit [Read error: Connection reset by peer]
myfreeweb has quit [Read error: Connection reset by peer]
diddledan has quit [Read error: Connection reset by peer]
robher has quit [Write error: Connection reset by peer]
puhitaku has quit [Read error: Connection reset by peer]
modmuss50 has quit [Read error: Connection reset by peer]
prusnak has quit [Write error: Connection reset by peer]
WhyNotHugo has joined #asahi-dev
myfreeweb has joined #asahi-dev
eric_engestrom has joined #asahi-dev
nkaretnikov has joined #asahi-dev
hatf0 has joined #asahi-dev
rjeli has joined #asahi-dev
brinly has joined #asahi-dev
jabashque has joined #asahi-dev
narmstrong has joined #asahi-dev
sferrini has joined #asahi-dev
modmuss50 has joined #asahi-dev
robher has joined #asahi-dev
diddledan has joined #asahi-dev
NekomimiScience has joined #asahi-dev
puhitaku has joined #asahi-dev
doof has joined #asahi-dev
jkkm has joined #asahi-dev
HeN has joined #asahi-dev
HeN has quit [Ping timeout: 272 seconds]
sirn has joined #asahi-dev
r1fl has joined #asahi-dev
tardyp has joined #asahi-dev
prusnak has joined #asahi-dev
rann has joined #asahi-dev
titanous_ has joined #asahi-dev
titanous_ is now known as titanous
titanous has quit [Changing host]
titanous has joined #asahi-dev
HeN has joined #asahi-dev
titanous has joined #asahi-dev
titanous has quit [Changing host]
austriancoder has joined #asahi-dev
<davidrysk[m]> marcan: nested virtualization is a base feature of ARMv8.3
acelogic has joined #asahi-dev
<krbtgt> could also just force a hypervisor above everything even with a single VM
<krbtgt> that's what IBM HW does
<krbtgt> even a system without LPARs (IBM for VM) is still running a dom0 and the "bare metal" host as dom1 on top of an HV
<davidrysk[m]> I can see why shared-context may be appealing to security researchers, but that is not whom Asahi Linux is for, and that's not what upstream caters for either
<marcan> davidrysk[m]: ID_AA64MMFR2_EL1[NV] == 0
jkkm has quit [Read error: Connection reset by peer]
HeN has quit [Read error: Connection reset by peer]
jkkm has joined #asahi-dev
HeN has joined #asahi-dev
<davidrysk[m]> marcan: boo apple, that's disappointing
Florian[m]2 has left #asahi-dev ["User left"]
sirn has quit [Read error: Connection reset by peer]
<modwizcode> Wow that's actually fairly surprising
hir0 has quit [Quit: leaving]
hir0 has joined #asahi-dev
VinDuv has joined #asahi-dev
phofe has joined #asahi-dev
hir0 has quit [Quit: leaving]
sirn has joined #asahi-dev
jabashque has quit [Read error: Connection reset by peer]
jabashque has joined #asahi-dev
tardyp has quit [Read error: Connection reset by peer]
NekomimiScience has quit [Read error: Connection reset by peer]
rjeli has quit [Read error: Connection reset by peer]
NekomimiScience has joined #asahi-dev
tardyp has joined #asahi-dev
rjeli has joined #asahi-dev
hir0 has joined #asahi-dev
WhyNotHugo has quit [Ping timeout: 256 seconds]
doof has quit [Read error: Connection reset by peer]
rann has quit [Read error: Connection reset by peer]
doof has joined #asahi-dev
WhyNotHugo has joined #asahi-dev
rann has joined #asahi-dev
jabashque has quit [Read error: Connection reset by peer]
NekomimiScience has quit [Read error: Connection reset by peer]
tardyp has quit [Read error: Connection reset by peer]
doof has quit [Read error: Connection reset by peer]
WhyNotHugo has quit [Read error: Connection reset by peer]
sirn has quit [Read error: Connection reset by peer]
rjeli has quit [Read error: Connection reset by peer]
rann has quit [Ping timeout: 264 seconds]
robher has quit [Read error: Connection reset by peer]
prusnak has quit [Read error: Connection reset by peer]
jabashque has joined #asahi-dev
tardyp has joined #asahi-dev
WhyNotHugo has joined #asahi-dev
doof has joined #asahi-dev
rjeli has joined #asahi-dev
NekomimiScience has joined #asahi-dev
robher has joined #asahi-dev
prusnak has joined #asahi-dev
sirn has joined #asahi-dev
rann has joined #asahi-dev
NekomimiScience has quit [Ping timeout: 260 seconds]
tardyp has quit [Read error: Connection reset by peer]
prusnak has quit [Read error: Connection reset by peer]
jabashque has quit [Read error: Connection reset by peer]
robher has quit [Read error: Connection reset by peer]
doof has quit [Read error: Connection reset by peer]
WhyNotHugo has quit [Read error: Connection reset by peer]
rjeli has quit [Read error: Connection reset by peer]
sirn has quit [Read error: Connection reset by peer]
doof has joined #asahi-dev
rann has quit [Ping timeout: 260 seconds]
jabashque has joined #asahi-dev
robher has joined #asahi-dev
NekomimiScience has joined #asahi-dev
rjeli has joined #asahi-dev
tardyp has joined #asahi-dev
sirn has joined #asahi-dev
WhyNotHugo has joined #asahi-dev
prusnak has joined #asahi-dev
rann has joined #asahi-dev
<kettenis> pwd
<Bluerise> kettenis: wrong chan :)
<j`ey> kettenis: /home/kettneis
<Bluerise> Would be funny if kettenis home was actually mistyped :D
<kettenis> yeah mouse focus issue :(
NekomimiScience has quit [Read error: Connection reset by peer]
prusnak has quit [Read error: Connection reset by peer]
sirn has quit [Read error: Connection reset by peer]
rann has quit [Ping timeout: 272 seconds]
tardyp has quit [Read error: Connection reset by peer]
robher has quit [Read error: Connection reset by peer]
WhyNotHugo has quit [Ping timeout: 260 seconds]
rjeli has quit [Read error: Connection reset by peer]
acelogic has quit [Remote host closed the connection]
hir0 has quit [Ping timeout: 256 seconds]
sirn has joined #asahi-dev
jamesmunns[m] has quit [Ping timeout: 260 seconds]
_alice has quit [Ping timeout: 260 seconds]
nirusu[m] has quit [Ping timeout: 260 seconds]
tardyp has joined #asahi-dev
ewlsh[m] has quit [Ping timeout: 260 seconds]
ConeOfAttack[m] has quit [Ping timeout: 260 seconds]
winocm has quit [Ping timeout: 260 seconds]
Hakon has quit [Ping timeout: 260 seconds]
acelogic has joined #asahi-dev
jamesmunns[m] has joined #asahi-dev
nirusu[m] has joined #asahi-dev
_alice has joined #asahi-dev
Hakon has joined #asahi-dev
ewlsh[m] has joined #asahi-dev
winocm has joined #asahi-dev
ConeOfAttack[m] has joined #asahi-dev
rjeli has joined #asahi-dev
hir0 has joined #asahi-dev
solarkraft_ has joined #asahi-dev
solarkraft has quit [Ping timeout: 240 seconds]
rann has joined #asahi-dev
prusnak has joined #asahi-dev
NekomimiScience has joined #asahi-dev
WhyNotHugo has joined #asahi-dev
robher has joined #asahi-dev
commandoline has joined #asahi-dev
NekomimiScience has quit [Read error: Connection reset by peer]
robher has quit [Read error: Connection reset by peer]
prusnak has quit [Read error: Connection reset by peer]
WhyNotHugo has quit [Read error: Connection reset by peer]
NekomimiScience has joined #asahi-dev
WhyNotHugo has joined #asahi-dev
robher has joined #asahi-dev
prusnak has joined #asahi-dev
phofe has quit [Quit: brb]
phofe has joined #asahi-dev
dstzd has quit [Quit: ZNC - https://znc.in]
dstzd has joined #asahi-dev
WhyNotHugo has quit [Read error: Connection reset by peer]
WhyNotHugo has joined #asahi-dev
acelogic has quit [Ping timeout: 264 seconds]
hir0 has quit [Ping timeout: 272 seconds]
<never_released> davidrysk[m]: nope, not a base feature
<never_released> just an extension
<davidrysk[m]> never_released: I see.
jamesmunns[m] has quit [Ping timeout: 240 seconds]
shawnj2[m] has quit [Ping timeout: 244 seconds]
nutmanja[m] has quit [Ping timeout: 246 seconds]
fried_dede[m] has quit [Ping timeout: 246 seconds]
ldhacker[m] has quit [Ping timeout: 246 seconds]
thecake21[m] has quit [Ping timeout: 246 seconds]
ConeOfAttack[m] has quit [Ping timeout: 240 seconds]
samumartinf[m] has quit [Ping timeout: 240 seconds]
os[m] has quit [Ping timeout: 240 seconds]
ah-[m] has quit [Ping timeout: 240 seconds]
konradybcio has quit [Ping timeout: 240 seconds]
enverb[m] has quit [Ping timeout: 240 seconds]
ewlsh[m] has quit [Ping timeout: 260 seconds]
bylaws has quit [Ping timeout: 258 seconds]
assusdan[m] has quit [Ping timeout: 240 seconds]
rockinrobstar[m] has quit [Ping timeout: 240 seconds]
undvasistas[m] has quit [Ping timeout: 240 seconds]
Jasper[m] has quit [Ping timeout: 240 seconds]
redbluescreen[m] has quit [Ping timeout: 240 seconds]
ndom91[m] has quit [Ping timeout: 240 seconds]
izzyisles[m] has quit [Ping timeout: 240 seconds]
Bastian[m] has quit [Ping timeout: 240 seconds]
nirusu[m] has quit [Ping timeout: 246 seconds]
foxlet has quit [Ping timeout: 240 seconds]
xerpi[m] has quit [Ping timeout: 240 seconds]
ryanhrob[m] has quit [Ping timeout: 244 seconds]
ts170[m] has quit [Ping timeout: 244 seconds]
ronyrus[m] has quit [Ping timeout: 244 seconds]
brentr123[m] has quit [Ping timeout: 244 seconds]
numa[m] has quit [Ping timeout: 244 seconds]
Eighth_Doctor has quit [Ping timeout: 244 seconds]
reispflanze[m] has quit [Ping timeout: 244 seconds]
asmon[m] has quit [Ping timeout: 244 seconds]
hipboi[m] has quit [Ping timeout: 244 seconds]
Alex[m]1 has quit [Ping timeout: 244 seconds]
jevinskie[m] has quit [Ping timeout: 244 seconds]
bastilian has quit [Ping timeout: 258 seconds]
stylefish[m] has quit [Ping timeout: 258 seconds]
PedroAraujo[m] has quit [Ping timeout: 258 seconds]
sumoon[m] has quit [Ping timeout: 258 seconds]
wolf511[m] has quit [Ping timeout: 268 seconds]
Alice[m] has quit [Ping timeout: 268 seconds]
khronokernel[m] has quit [Ping timeout: 268 seconds]
nufflee[m] has quit [Ping timeout: 258 seconds]
liur[m] has quit [Ping timeout: 258 seconds]
mcnight[m] has quit [Ping timeout: 260 seconds]
fl35[m] has quit [Ping timeout: 260 seconds]
skillfulman23[m] has quit [Ping timeout: 260 seconds]
citruscitrus[m] has quit [Ping timeout: 260 seconds]
jrmuizel[m] has quit [Ping timeout: 260 seconds]
josiahmendes[m] has quit [Ping timeout: 260 seconds]
mofux[m] has quit [Ping timeout: 240 seconds]
smist08[m] has quit [Ping timeout: 240 seconds]
winocm has quit [Ping timeout: 264 seconds]
hypergenesis[m] has quit [Ping timeout: 240 seconds]
tarik02[m] has quit [Ping timeout: 265 seconds]
flokk[m] has quit [Ping timeout: 265 seconds]
fridtjof[m] has quit [Ping timeout: 265 seconds]
delroth[m] has quit [Ping timeout: 265 seconds]
alexanderwillner has quit [Ping timeout: 265 seconds]
botoxparty[m] has quit [Ping timeout: 265 seconds]
m1kr0[m] has quit [Ping timeout: 265 seconds]
Jamie[m] has quit [Ping timeout: 246 seconds]
crafteck[m] has quit [Ping timeout: 246 seconds]
CamdenB[m] has quit [Ping timeout: 246 seconds]
emily has quit [Ping timeout: 258 seconds]
randohacker[m] has quit [Ping timeout: 258 seconds]
blazra has quit [Ping timeout: 258 seconds]
mellotron1[m] has quit [Ping timeout: 260 seconds]
jinen[m] has quit [Ping timeout: 260 seconds]
nhlism[m] has quit [Ping timeout: 260 seconds]
Avion[m] has quit [Ping timeout: 260 seconds]
svenpeter has quit [Ping timeout: 268 seconds]
TellowKrinkle[m] has quit [Ping timeout: 268 seconds]
davidrysk[m] has quit [Ping timeout: 268 seconds]
dancer[m] has quit [Ping timeout: 265 seconds]
bjornjulander[m] has quit [Ping timeout: 265 seconds]
_alice has quit [Ping timeout: 264 seconds]
hatf0 has quit [Ping timeout: 264 seconds]
NekomimiScience has quit [Ping timeout: 246 seconds]
hatf0 has joined #asahi-dev
NekomimiScience has joined #asahi-dev
VinDuv has quit [Quit: Leaving.]
dstzd has quit [Quit: ZNC - https://znc.in]
dstzd_ has joined #asahi-dev
dstzd_ is now known as dstzd
maor26 has quit [Ping timeout: 246 seconds]
clayfreeman has quit [*.net *.split]
clayfreeman has joined #asahi-dev
dstzd has quit [Quit: ZNC - https://znc.in]
dstzd has joined #asahi-dev
ldhacker[m] has joined #asahi-dev
fried_dede[m] has joined #asahi-dev
thecake21[m] has joined #asahi-dev
jamesmunns[m] has joined #asahi-dev
nutmanja[m] has joined #asahi-dev
nirusu[m] has joined #asahi-dev
redbluescreen[m] has joined #asahi-dev
shawnj2[m] has joined #asahi-dev
ndom91[m] has joined #asahi-dev
izzyisles[m] has joined #asahi-dev
undvasistas[m] has joined #asahi-dev
Jasper[m] has joined #asahi-dev
konradybcio has joined #asahi-dev
ldhacker[m] has quit [Quit: Bridge terminating on SIGTERM]
jamesmunns[m] has quit [Quit: Bridge terminating on SIGTERM]
fried_dede[m] has quit [Quit: Bridge terminating on SIGTERM]
nirusu[m] has quit [Quit: Bridge terminating on SIGTERM]
thecake21[m] has quit [Quit: Bridge terminating on SIGTERM]
redbluescreen[m] has quit [Quit: Bridge terminating on SIGTERM]
shawnj2[m] has quit [Quit: Bridge terminating on SIGTERM]
ndom91[m] has quit [Client Quit]
undvasistas[m] has quit [Client Quit]
nutmanja[m] has quit [Quit: Bridge terminating on SIGTERM]
konradybcio has quit [Client Quit]
Jasper[m] has quit [Client Quit]
izzyisles[m] has quit [Client Quit]
fridtjof[m] has joined #asahi-dev
alexanderwillner has joined #asahi-dev
botoxparty[m] has joined #asahi-dev
delroth[m] has joined #asahi-dev
m1kr0[m] has joined #asahi-dev
botoxparty[m] has quit [Remote host closed the connection]
delroth[m] has quit [Remote host closed the connection]
m1kr0[m] has quit [Remote host closed the connection]
fridtjof[m] has quit [Remote host closed the connection]
alexanderwillner has quit [Remote host closed the connection]
PhilippvK has joined #asahi-dev
PhilippvK has quit [Client Quit]
PedroAraujo[m] has joined #asahi-dev