ChanServ changed the topic of #asahi to: Asahi Linux: porting Linux to Apple Silicon macs | General project discussion | GitHub: https://alx.sh/g | Wiki: https://alx.sh/w | Topics: #asahi-dev #asahi-re #asahi-gpu #asahi-offtopic | Keep things on topic | Logs: https://alx.sh/l/asahi
skipwich has joined #asahi
pinskia has quit [Read error: Connection reset by peer]
<amw>
It would be nice to have a linux with nvme, dart and a fresher upstream update as a basis for new work
pinskia has joined #asahi
_whitelogger has joined #asahi
lethalbit has quit [Read error: Connection reset by peer]
chadmed has quit [Ping timeout: 480 seconds]
chadmed has joined #asahi
null has quit [Quit: oh no.]
null has joined #asahi
phiologe has joined #asahi
PhilippvK has quit [Ping timeout: 480 seconds]
marvin24_ has joined #asahi
marvin24 has quit [Ping timeout: 480 seconds]
marvin24 has joined #asahi
marvin24_ has quit [Ping timeout: 480 seconds]
<sven>
yeah, and i think it's also nice to be able to do some kind of early internal review while we still iterate. we can probably catch lots of common gotcha long before we need to annoy maintainers on the mailing lists ;)
DarkShadow4444 has quit [Ping timeout: 480 seconds]
<pipcet[m]>
sven: please keep bringing on the "nits", they're great :-)
DarkShadow44 has joined #asahi
<sven>
sure! i would've been happy to get those before my first upstream submission as well :)
marvin24_ has joined #asahi
marvin24 has quit [Ping timeout: 480 seconds]
<pipcet[m]>
well, certainly the first ones since that new-fangled DT stuff happened ;-)
<sven>
no idea if it still works. i last touched this in march or so
<sven>
anyway, back to $work for me
<arnd>
marcan: do you have any DT updates for 5.15 that you can send? This week would be great so I don't have to queue it into a 'late' branch. I haven't kept track of which drivers got merged since the original version that would need DT nodes
<marcan>
arnd: I *think* with DART that means USB should work, but there was a PHY binding thing, I think sven knows more
<marcan>
I've been neglecting the kernel side, I'll catch up this week
<marcan>
also I might have to prioritize the clock stuff because even though nobody cares it's kind of important for DT correctness :)
<marcan>
I've been doing all the fun DCP/HV/etc reversing and alyssa wants me to look into graphics ASAP, but I think I need to spend some time getting all the non-fun stuff done for a change :p
<arnd>
Ok, good. Having USB working would already turn it from barely working into something one can actually play around with on an upstream kernel. I was originally hoping we could get PCI and NVMe in 5.15, but since NVMe certainly isn't getting in this time, I guess it will be 5.16 at the earliest for a mostly functioning system
<marcan>
yeah, sounds like it
<arnd>
http://phb-crystal-ball.org/ tells me that 5.15 is the next LTS kernel that next year's distros will ship
<marcan>
tbh I think it's wishful thinking to expect much from distros this early, but if we can get things in real nice shape for the *next* LTS, that's definitely something to aim for... :-)
<arnd>
right, even if we had basic functionality in the kernel, there is not much point if distros don't come with an working installation method for the machine
<marcan>
yeah
<sven>
USB would work, but just once per port because dwc3 only sees a single "device connected" event. to use a port twice we need to hook up something from SMC or the USB-PD chip to the not-yet-existing usb phy driver to issue a reset there :/
<marcan>
we're mostly going to be handling installation for distros, at least initially, I expect
<marcan>
i.e. dumping out a rootfs
<pipcet[m]>
sven: if the SMC knows...
<marcan>
arnd: how important is it to get the DT updates in for this round for whatever works so far, vs waiting until the other pieces fall in place a bit better?
<marcan>
keep in mind we have a backwards compat break ahead of us anyway in the power/clock driver stuff, which is why I really should push for that
<marcan>
until that's done we can't really hope for smooth upgrades
<marcan>
which is probably another reason why we shouldn't worry too much about distros shipping 5.15, too late for that
<arnd>
marcan: it's not important to me to have it in there now, I'm mainly interested in not getting a large pull request just before the merge window
<marcan>
ah nah, if you're okay with leaving it for 5.16 we can just do it like that
<marcan>
I'd rather get back in kernel mode and start putting together pieces, maybe write a few drivers
<marcan>
and seeing how much of that I can get into 5.16
<marcan>
there's lots of little loose ends to be tied
<marcan>
sven: no i2c still either, right?
<marcan>
(upstream I mean)
<sven>
uh.. i have some WIP i2c somewhere, but i never event sent that for review anywhere
<marcan>
I can take over that if you want
<sven>
sure
<marcan>
i2c and spi are dumb things we should tick off
<marcan>
that then makes the keyboard work, and the USB-PD stuff doable
<sven>
yeah, i think i2c, spi and at least the clocks-gates would be very useful
<marcan>
yup
<marcan>
alright, if nobody else wants to take those, after I get the installer PoC done I'll get in kernel mode for a while and work on that
<marcan>
should get there this week
<sven>
there's also gpio/pinctrl iirc
<marcan>
we never settled on the issue of the clock dependencies, right?
<sven>
nope :(
<sven>
and it gets more fun: some clocks have two parents
<marcan>
alright, then it's gonna be whatever I can come up with :p
<sven>
sounds good!
<marcan>
we've had enough chitchat, time to throw implementations at people and figure out if they stick
<marcan>
did we ever figure out if spi is a thing that already has a similar driver? IIRC it was "samsung stuff" but I wonder if it's like UART or not
<sven>
iirc there are two kexts: samsung and apple. no idea if the apple is just a new variant of the samsung one or a completely new thing
<marcan>
heh, ok
<marcan>
strings suggests it does dma, but there's no DART... I'm going to assume they don't actually use that here
<pipcet[m]>
not for the keyboard, no.
<jannau>
I have time this week and will continue working on pinctrl/gpio
<marcan>
spi-s3c24xx.c matches at least *one* of the register names
<marcan>
I'll just hvtrace it and see how close it is
<marcan>
jannau: cool!
<chadmed>
when i said the other day that we should "force" everyone to just use gentoo, i was only half joking. it might be a good idea to try and get gentoo's arm team on board wrt testing and general liason work. it's an easy starting point since rn the only userspace changes needed would be to add an "agx" VIDEO_CARDS flag for mesa
<marcan>
that driver has a bunch of fake FIQ DMA stuff we are definitely not using, and doesn't mention FIFOs which apple's controller has, so this might be a good case for writing a new driver rather than trying to shoehorn apple mode into that one
<marcan>
but we'll see
<marcan>
chadmed: I'm a gentoo user fwiw :)
<chadmed>
likewise, its why im shamelessly shilling for early gentoo integration heh
<marcan>
but gentoo is easy, just have an overlay
<chadmed>
well yeah of course, but having the
<chadmed>
"blessing" of a big distro and the eyes of the arm maintainers might encourage the binary titans to sit down at the table sooner too
<marcan>
is gentoo even "big" any more? :-)
<marcan>
but sure, I'd be happy to have some of the gentoo ARM folks around
<TheLink>
Isn‘t ChromeOS based on Gentoo?
<marcan>
kind of
<marcan>
it's basically a fork IIRC
<TheLink>
That would make it huge 😊
<chadmed>
yeah but its like calling android linux. sure, it uses the linux kernel but its pretty philosophically incompatible with what one would call a linux system
<chadmed>
that GNU/Linux copypasta unironically makes a pretty salient point lmao
<chadmed>
chromeos might use portage or whatever but do you really have all the tools and power at your disposal that distinguishes gentoo from any other distro? i would argue that having those tools in the first place would be ridiculous on a chromebook, building a vanilla gentoo install with plasma is sad enough on a pi4 8gb let alone a chromebook
<ar>
chadmed: it might be an unpopular opinion here, but I'm kinda glad I no longer use gentoo (despite using it for ~15 years)
<chadmed>
yeah its not for everyone, and most would probably become fatigued by it. fwiw samba's hard dependency on libunwind still breaks my clang-only portage setup every time i sync the repos, meaning i have to manually edit the ebuild to accept llvm-libunwind at least once a week :P
<chadmed>
thats starting to wear on my nerves
<ar>
i recently even considered trying gentoo out again, but then i learned that on a friends pc that's mostly similiar to mine in terms of specs, chrome still (or rather, again) takes a bit over an hour to compile
<chadmed>
three things a certain in life; death, taxes, and chrome taking over an hour to build from source
<ar>
for a while, on a ryzen 2700x and enough ram (for tmpfs), it took around 40-50 minutes
<tophevich[m]>
how long for firefox?
<ar>
tophevich[m]: when i stopped using gentoo, it was about 15 minutes
<ar>
(on a 2700x)
<chadmed>
firefox takes me about 15-25 mins on a 5600x with 16gb 3400mbps 14-14-14-14-28
<ar>
on a 5950x i have now, i'd expect it to still take around 10-15 minutes, because huge parts of the firefox build don't parallelize well
<chadmed>
yeah, plus the amount of rust that now makes up firefox
<chadmed>
rustc is not very good
<tophevich[m]>
can't live without chrome? or why take that compile time penalty all the time?
<chadmed>
yea idk youd willingly use chrome let alone build it but such is the beauty of gentoo, the "to each his own" principle taken to comical heights
<chadmed>
s/idk/idk why/
<pipcet[m]>
alyssa: FWIW, with the asahi/devel branch I have both a usb gadget console and a usb keyboard now, simultaneously. was it just eem that was broken?
jeff_miw has joined #asahi
<jeff_miw>
marcan: regarding spi and i2c, I'll be happy to help with some guidance, I need to catch-up to bring something useful. Is the devel branch the right one to start from ?
jeff_miw has quit [Remote host closed the connection]
<amw>
For what it's worth I was trying to use shell to test pinctrl + spi3 to get to the keyboard
<amw>
But I found the keyboard uses large 256 byte, crc'ed messages so it's quite a lot of work to get some keyboard input via that
<amw>
I was just trying to use info in the corellium drivers and I think it was kind of talking to the spi3 and possibly pinctrl - no interrupts
<amw>
Pretty useless mess at the moment, but with a few more days of work might do some non-interrupt driven transfers, proof concept
<amw>
I don't really understand how to get the interrupts to report under shell.py so I ignored them - but that might be a good way to check things are working
<amw>
Time for bed and see if anything happens by tomorrow...
Andalu30 has joined #asahi
yuyichao has quit [Ping timeout: 480 seconds]
<arnd>
marcan: for the spi driver, I see some resemblance between its registers and both the s3c24xx and s3c64xx drivers, but it does seem different enough to need a third driver.
yuyichao has joined #asahi
<arnd>
If someone wants to push corellium's driver, that might actually work in this case, it seems well written, and fairly simple, much smaller than the two samsung drivers that implement DMA mode
<arnd>
I just looked at all the other spi drivers to see if there was a closer match: it looks like half the drivers in the kernel have roughly the same design, with config/status/transmit/receive registers in that order, but they all have them at slightly different offsets, and with slightly different bit definitions, so the similarity to the s3c driver may just be coincidence
<arnd>
or the hardware designers all read the same book on the topic
skipwich has quit [Quit: DISCONNECT]
skipwich has joined #asahi
Andalu30 has quit [Remote host closed the connection]
Andalu30 has joined #asahi
skipwich has quit [Ping timeout: 480 seconds]
Raito_Bezarius has quit [Ping timeout: 480 seconds]
<arnd>
sven: well, duplicating that nvme driver at least makes it easier to get the initial version merged
DarkShadow44 has joined #asahi
<arnd>
I guess you can start with a copy of the code you already have, and then remove everything that isn't currently getting used.
DarkShadow44 has quit []
DarkShadow44 has joined #asahi
<sven>
yeah. the bigger issue is probably that i'm not really sure how to handle that mailbox part yet.
<sven>
essentially there's a low-level dumb mailbox interface backed by some hardware FIFO.
<sven>
and then most of these sub-processors have some shared endpoints (management to boot them, syslog, etc.). the code to handle that doesn't seem to really fit into drivers/mailbox
<sven>
and because that's not fun enough these endpoints require shared memory buffers that sometimes go through a DART IOMMU, other times through a simple DMA address filter Apple calls SART (that's where these HMB buffers are configured) and other times the shared memory is just exposed on the MMIO bus
<arnd>
sven: what is the mailbox needed for in case of nvme?
<sven>
just to boot the co-processor
jeffmiw has joined #asahi
<sven>
which requires syslog, etc. to be up.
<sven>
the nvme mmio interface we see is emulated by the firmware running on that processor
<pipcet[m]>
(I think it requires just the panic EP, but that's bad enough)
<sven>
in my current hack those endpoints are just implemented in my mailbox driver and that 0x20 channel i request in the nvme code is a lie
<jeffmiw>
just lost a couple of hours fixing my python install to get correct python 3.9 and latest construct module ... to chainload latest m1n1 mainly because I'm using an old ubuntu 18.04 distrib :). I thought it is a good time to ask: which distrib are you using for your dev for M1 ?
<marcan>
sven: honestly I'm leaning towards ignoring mailbox/etc and just doing our own driver
<marcan>
it doesn't seem useful to use an abstraction for us
<marcan>
nothing says we have to use kernel abstractions
<marcan>
those abstractions are only useful when they either provide enough useful primitives to reduce code, or existing higher level drivers can hook into the interface
<marcan>
neither seems to be the case here
Andalu30 has joined #asahi
<marcan>
nothing other than apple stuff is ever going to use the ASC driver
<marcan>
and apple stuff is never going to use another mailbox driver
<sven>
SEPOS uses the same dumb mailbox HW but not the RTKit stuff. and iirc acio or something uses a slightly different dumb mailbox interface but the same RTKit stuff again
<marcan>
yeah, so all those can be variations in one driver
<sven>
so it might make sense to reuse the mailbox interface but build some custom abstraction for the RTKit stuff, but dunno
<marcan>
like, we can have the core mailbox/ep handling stuff, that is instantiated by downstream drivers that actually handle devices like DCP
<marcan>
and as part of that they instantiate the default endpoints, or not
<marcan>
it doesn't even really need to be a driver
<marcan>
it would just be a library
<marcan>
the drivers would be DCP, ANS, etc
<sven>
sure, that's also fine
<sven>
ANS could also just special-case that SART stuff then and SMC the MMIO shmem buffers
<marcan>
exactly
<marcan>
just tell the library not to use a DART but something else instead
<marcan>
there's many ways to do this once it's our own code everywhere
<sven>
DART is transparent through the dma_map_ops anyway
<marcan>
yeah, we justr need a separate hook for SART
<pipcet[m]>
I think a basic (tiny) mailbox driver exposing the dumb 128-bit mailbox still makes sense, marcan's library or whatever can talk to that.
<sven>
and those MMIO shmem buffer need special treatment as well
<sven>
pipcet[m]: maybe, but i'm not 100% convinced about that. the mailbox driver implements a fifo and is usually used for even dumber mailboxes. apple's hw at least has a HW fifo that's 16 messages or so deep
<j_ey>
marcan: wow, i seem to be doing really dumb stuff all the time. earlier I was passing the uncompressed initramfs, now I was passing: Image dtb dtb-from-m1n1 initramfs, and getting very confused why none of my dtb changes were doing anything :||
<sven>
and the mailbox driver also assumes that all endpoints are separate, but on the m1 they all go to the same FIFO anyway. now that can all be worked around and maybe that's worth it
<sven>
i'm just not convinced it's a good fit
<pipcet[m]>
sven: no, the mailbox driver would not know anything about endpoints.
<pipcet[m]>
it'll expose a single channel for the library to use.
<sven>
ok, sure
<sven>
that only leaves the fifo thing then. might be worth it, dunno
<pipcet[m]>
my driver only queues one message at a time at the hw level, I'm not sure it's worth it to do something more complicated.
<pipcet[m]>
so then the FIFO becomes useful because it makes writing the library easier, as long as MBOX_TX_QUEUE_LENGTH is greater than the number of endpoints used in parallel.
<sven>
but then we always need to wait for an interrupt to deliver every single message, don't we?
DarkShadow44 has joined #asahi
Andalu30 has quit [Ping timeout: 480 seconds]
<pipcet[m]>
only to tell us transmission is done
<pipcet[m]>
which we need to know because some messages have no response.
<marcan>
what is the benefit of using the mailbox interface?
<marcan>
just the FIFO?
<marcan>
might make sense to use, but I need to look at the framework to convince myself
<marcan>
also, if it's instantiated separately, that still leaves the issue of the cpu boot and other things we might need to do, which might end up outside of the mailbox driver's API
<marcan>
pipcet[m]: is there any case where we need to know that message transmission is done? that sounds wrong.
<pipcet[m]>
they should, yes. this just takes away the tiny part that we have a good abstraction for, but it's a clear fit
<pipcet[m]>
marcan: endpoint startup
<marcan>
yes but why do we need to wait for anything?
<marcan>
it's a fire and forget message
<pipcet[m]>
>16 endpoints?
<pipcet[m]>
more than, sorry.
<marcan>
well sure, but that's just a standard FIFO thing, nothing about specific messages
<marcan>
if the FIFO is full we block until IRQ
<marcan>
standard queueing stuff
<arnd>
the mailbox framework is a little strange in the way it works, but for this particular use case it actually sounds like a good fit to me, just exposing a fixed-length message fifo
<marcan>
messages would be 64+8 bits, probably 64+64 in practice
<pipcet[m]>
yes.
<arnd>
the main advantage of the mailbox framework is that there is an existing DT binding to describe how the various endpoints related to the shared mailbox driver
<marcan>
but we can't use those endpoints
<marcan>
there will be a single endpoint
<marcan>
due to the architecture mismatch
<pipcet[m]>
(I'm also hoping for some debug features to make their way into the mailbox framework.)
<marcan>
so it's going to be 1:1 an RTKit-lib driver and the mailbox, in every case
<marcan>
(except SEP which won't use that lib probably)
<marcan>
the endpoints are at a level that is the driver's responsibility
<marcan>
if we want separate drivers for this, which we might, that will have to be our own thing with another layer
<marcan>
I'm not sure yet if we do though
<marcan>
Apple certainly does things that way
<marcan>
and DCP has a pile of endpoints for different drivers
<marcan>
so that might be a good argument for a bespoke driver, if we actually want to have this be a DT node with multiple clients, the same way apple does it
<pipcet[m]>
marcan: well, what I did, but you're going to hate it and I haven't decided whether I do, is have a funnelling driver that provides one mailbox per endpoint and consumes the single-channel mailbox (with its two different implementations), providing infallible FIFO'd mailboxes to the endpoint drivers.
<marcan>
yeeeeah let's not do that :p
<marcan>
the thing is, at some point we might have ordering requirements between endpoints
<marcan>
or some bullshit bug to work around related to that
<marcan>
and if we do it like that that's just too many layers to the onion
<marcan>
and do we even need the FIFOs? honestly I think the hardware FIFO is sufficient
<marcan>
things will block if they need to and that's okay
<marcan>
the kernel knows how to block
<pipcet[m]>
the main point for me is not to hide in the DT the fact that communication uses a piece of hardware clearly identified as a mailbox, which behaves like a mailbox. The secondary aspect is that the mailbox abstraction might evolve to actually be useful, by including debug facilities.
<pipcet[m]>
and for debugging and performance analysis, we need to know when a message has arrived at the ASC end...
<sven>
fwiw, it's also not too bad to have the mailbox driver already correctly expose the channels and mux them into the single fifo
<sven>
it's just.. a little bit awkward
<sven>
regarding debug feature for the mailbox framework: i used tracepoints because i was sick of spamming dmesg with every single message and that worked out quite nicely
<sven>
and either way i'd move the cpu control register (which is like a page or so away from the mailbox regs) out of that mailbox driver
<pipcet[m]>
you need to have an endpoint to know how many endpoints there are, though :-)
<marcan>
does the CPU need to be running for the mailbox to work?
<pipcet[m]>
no, mailbox just queues stuff
<sven>
uh, why do i need an endpoint to know how many endpoints there are?
<pipcet[m]>
because the endpoint map comes in over endpoint 0?
<marcan>
the endpoint map is not useful
<sven>
^-- that
<marcan>
either we have a driver that wants an endpoint, or we don't
<sven>
the endpoint map would be the responsibility of the rtkit lib
<sven>
the mailbox driver would be very dumb
<sven>
literally just "take this message, get the endpoint from the client priv data, stuff it to the fifo"
<marcan>
anyway, I'm talking out of my ass right now since I haven't even looked at any of the code
<marcan>
and I need to go to sleep
<marcan>
once I get a look at that mailbox framework I might have to start shouting the right answer :p
<sven>
yeah, right
<pipcet[m]>
marcan: good night, then, and thank you. I think you've actually convinced me with the rtkit library stuff :-)
<tophevich[m]>
marcan: Have a good refreshing night sleep, vax side-effects all gone?
<marcan>
ah, yeah, that was only the t+[12h, 36h] interval
<pipcet[m]>
sven: speaking of mailboxes (not dumb ones though) and queue depth, how many PRs does it make sense to keep open on asahi/devel at once? I'm not planning to open more unless you explicitly request it
<marcan>
we really shouldn't have any PRs on asahi/devel
<marcan>
that branch ought to become an auto-merge
<sven>
dunno, but i think that first one could actually be sent to the 'real' upstream at this point
<marcan>
instead features should be developed on feature branches and upstreamed from there
<sven>
we should have PRs somewhere though for quicker internal review
<sven>
to catch common mistakes, etc.
<marcan>
yes, but against the feature branches
<sven>
sure, but for now devel works.
<marcan>
and we can have a stupid fixes branch if we need one for things that don't fit nicely anywhere else
<marcan>
sure, but I'm about to change that, likely this week :-)
<sven>
sounds good :)
<tophevich[m]>
"asahi-next"
<marcan>
exactly
<sven>
then i guess we'll keep the PRs open for now
<marcan>
it'll be a new branch, but devel will probably be deprecated
<marcan>
might end up moving those PRs elsewhere, depends
<marcan>
I reserve the right to tear apart the branch scheme of that repo :D
<sven>
we just created that branch yesterday, feel free to remove it again :D
<marcan>
ahaha
<sven>
it's literally just rc3 + dart or so
<marcan>
yeah, so that should be asahi-next :) (once I have the automation)
<sven>
sounds good
<pipcet[m]>
I'm happy any way, just let me know what you decide on
<marcan>
(which *grumble* is going to involve a stupid webhook reflector hosted on my server, because github seems to have no way to point webhooks at itself, nor to have actions run *without* the workflow file in the current branch)
<marcan>
(and I don't want to pollute our kernel trees with github workflows)
<sven>
pipcet[m]: anyways, feel free to open more PRs for now
<sven>
maybe i should actually open one with the dumb mailbox with N channels things so that we have some actual code to discuss and see how things fit
<marcan>
sure
<marcan>
if y'all want to prototype a few of the approaches, that will give us more data
<marcan>
and this all seems simple enough anyway
<sven>
pipcet[m]: might make sense to open one with the "0 channels as well"
<marcan>
meanwhile I'll work on the installer, merge infra, and tying up i2c/spi/clocks
<sven>
yeah, it's like 1 fix for the aic-irqchip (if you disable irq N while you're in the handler for N you can never enable it again) + 300 lines of code or so
<marcan>
the aic fix is probably a good thing to send upstream asap anyway
<marcan>
but anyway, I should sleep :)
<sven>
i'm not sure it's correct yet, but yeah :D
<sven>
(as in, i haven't traced through all the code to know why it works. i just have a good guess)
<pipcet[m]>
marcan: I started writing pseudocode and stopped when I ended up with a working brightness backlight driver, but it's, uhm, prototype quality code at best and totally faked its way around the dcp dart.
<tophevich[m]>
marcan: any plans to stream your endeavours again in the near future? (Your streams are currently my fav. procrastination excuse, and I feel like I need that or a holiday :D)
<marcan>
tophevich[m]: I'm still streaming, I did some last week
<marcan>
likely one tomorrow
<tophevich[m]>
nice, I'm gonna watch out for it, realy enjoing those!
<marcan>
I'm still amazed people like watching me hmm and haw while spending hour trying to make stuff work :-)
<marcan>
*hours
<j_ey>
talking about marcans streams, is there a way to increase the font size on the simple-framebuffer?
<marcan>
ah, like the m1n1 console?
<j_ey>
no, once Linux takes over
<marcan>
ah
<marcan>
haven't done that recently though
<marcan>
but there are several built in fonts, yes
<marcan>
I think there's a larger one for retina stuff these days?
<tophevich[m]>
you are good at narrating, and thus it makes it realy nice to follow along your workflow/thinking. also you have a good narration voice :)
<j_ey>
hm ok, I'll have a poke around, I keep having to squint to read it
<j_ey>
(locally I mean)
<marcan>
in the stream?
<marcan>
ahh
<pipcet[m]>
j_ey: the retina font is nice and large, should be easy enough to use that :-)
<marcan>
j_ey: CONFIG_FONTS and descendants
<j_ey>
pipcet[m]: is that in menuconfig?
<marcan>
CONFIG_FONT_TER16x32 perhaps
<pipcet[m]>
oh, you meant the linux framebuffer, sorry. For the kernel just compile in a large font and you'll be fine, it's what my .config does.
<sven>
https://github.com/AsahiLinux/linux/pull/6 so that's essentially the mailbox thing that just exposes N endpoints and muxes them to the single FIFO + some (maybe) hack to the mailbox core to introduce a fast-path for submission
<j_ey>
oh I see it now, ty, will try it
<j_ey>
when I try `bt` I never get an actual backtrace :/ even after loading the system map and setting the pac mask, I always get _end. amw have you had any recent success with bt?
<JTL>
> 18:23 <@marcan> I'm still amazed people like watching me hmm and haw while spending hour trying to make stuff work :-)
<JTL>
sudoku for nerds :D
<tophevich[m]>
marcan: your streams are very educational and also are most likely very good for growing a support for the project, I think SerenityOS and Zig (lang) are good examples of projects, where (main) contributers streaming/showing of the work gives the project a nice "human face" that gives supporters a greater (closer) sense of community.
<tophevich[m]>
Also they give ppl confidence to try stuff they thought impossible, as they see them being done infront of their eyes. If you see that mount of work only as a finished product, it seems impossible.
<marcan>
I guess that's true :)
<marcan>
also I don't know about my voice, but at least I can be reasonably proud of my audio quality :p
<JTL>
I like your accent
DarkShadow44 has quit [Remote host closed the connection]
<marcan>
you mean my american-spanish-irish-plus-alpha accent?
<eta>
itt: everyone crushing on marcan
<eta>
(in all seriousness though, the streams are indeed awesome!)
<JTL>
eta: no u
DarkShadow44 has joined #asahi
<marcan>
well I'm glad everyone enjoys them then :)
<marcan>
alright, really though, zz
<tophevich[m]>
good night
<tophevich[m]>
alyssa: Btw. I enjoy your streams also quite a lot. Wouldn't mind to see you stream more often. Also very educational, good at narrating along, plus a good sense of humor :)
<marcan>
tophevich[m]: is she in here? if so, one of us is desynced...
marcan has left #asahi [#asahi]
marcan has joined #asahi
<marcan>
... not me I think :)
<marcan>
she's in -dev though
<eta>
that kind of desync would be impressiv
<eta>
e
alyssa has joined #asahi
<marcan>
it happens sometimes with IRC clients, especially with a bouncer in the way to muck things up
<krbtgt>
i like the fact there's videos for audiovisual people but i do like projects with like a good progress report too
<krbtgt>
as someone who doesnt want to watch a video zig and serenity putting out videos is harder for me
<alyssa>
marcan: she's omnipresent and omniscient
<tophevich[m]>
yes, yes she is xD
<alyssa>
pipcet[m]: hm, will try again. maybe I botched something with my config
<tophevich[m]>
marcan: sorry for the confusion, I was not looking if she is online, I was just counting on her reading it at some point
<jix>
after trying to stream coding (completely unrelated to asahi) myself, I have even more respect for both of you for your streams
erincandescent has quit [Remote host closed the connection]
erincandescent has joined #asahi
<sven>
yeah, i couldn't even imagine to code and stream at the same time
<sven>
and then make it all seem to effortless like you two
<jix>
the coding part works for me... the debugging part also works for me... the "oh shit this approach won't work, I need to think about what to do instead" part doesn't work at all ^^
<j_ey>
pipcet[m]: hmm I'm getting a data abort in gpio_set_reg, when i try to enable the keyboard :/
<j_ey>
(using your branch, and a cut down dtb)
<pipcet[m]>
using which branch? Probably some clock that's not enabled...
<j_ey>
'pearl'
<j_ey>
I have the spi3/keyboard node, and all clocks and pinctrls that those reference
<pipcet[m]>
oh, sorry. not really asahi, but you need to pass clk_ignore_unused I think
<pipcet[m]>
(in the kernel command line .. this is where we all give marcan a hand for wanting to look at the clk stuff :-) )
<j_ey>
hm ok, I'll try that!
<pipcet[m]>
(I'm running pearl right now and it works, but then I booted through the .macho and the first thing that does is (try and fail to) enable all the clocks :-) )
PhilippvK has joined #asahi
phiologe has quit [Ping timeout: 480 seconds]
quarkyalice has joined #asahi
quarkyalice has quit [Remote host closed the connection]
quarkyalice has joined #asahi
skipwich has quit [Quit: DISCONNECT]
skipwich has joined #asahi
jeffmiw has quit [Ping timeout: 480 seconds]
phiologe has joined #asahi
PhilippvK has quit [Ping timeout: 480 seconds]
<amw>
j_ey: bt under run_guest has worked for me - except when I had CONFIG_RANDOMIZE
<amw>
You can look at bt() in proxyclient/m1n1/hv.py around line 821 and try dumping out the registers it mentions
<j_ey>
ah, I'll turn that off then
<amw>
e.g. hv.ctx.regs[29] et cetera to see what's actually go on