marcan changed the topic of #asahi to: Asahi Linux: porting Linux to Apple Silicon macs | Not ready for end users / self contained install yet. Soon. | General project discussion | GitHub: https://alx.sh/g | Wiki: https://alx.sh/w | Topics: #asahi-dev #asahi-re #asahi-gpu #asahi-stream #asahi-offtopic | Keep things on topic | Logs: https://alx.sh/l/asahi
<j`ey>
chadmed: paste dmesg?
<chadmed>
ill see if i can grab it from picocom, it wouldnt let me interact with it before (except with the debian installer)
Latrina has quit [Quit: Powered by AlpineLinux under the supervision of Docker.]
<j`ey>
[ 0.353376] [drm] Initialized simpledrm 1.0.0 20200625 for 103dfe58000.framebuffer on minor 2
willemml has quit [Quit: willemml]
<chadmed>
checked if it was seeing the hdmi output too, nothing
willemml has joined #asahi
Latrina has quit [Quit: Powered by AlpineLinux under the supervision of Docker.]
Latrina has joined #asahi
<j`ey>
not sure, and it's time to sleep, maybe someone else will have some ideas
<chadmed>
yeah no problem thanks anyway
<chadmed>
ill figure it out eventually
Latrina has quit [Quit: Powered by AlpineLinux under the supervision of Docker.]
Latrina has joined #asahi
jx0 has quit []
<chadmed>
got it
willemml has quit [Quit: willemml]
willemml has joined #asahi
willemml has quit []
willemml has joined #asahi
willemml has quit []
ciggi has quit [Ping timeout: 480 seconds]
pent1ckel has quit [Ping timeout: 480 seconds]
popo has joined #asahi
balrog has quit [Quit: Bye]
balrog has joined #asahi
tomtastic_ has joined #asahi
tomtastic has quit [Ping timeout: 480 seconds]
suricato_ has joined #asahi
suricato has quit [Ping timeout: 480 seconds]
willemml has joined #asahi
willemml has quit []
ciggi has joined #asahi
yuyichao_ has quit [Ping timeout: 480 seconds]
tmlind has quit [Remote host closed the connection]
jx0 has joined #asahi
PhilippvK has quit [Ping timeout: 480 seconds]
chadmed has quit [Ping timeout: 480 seconds]
chadmed has joined #asahi
yuyichao_ has joined #asahi
<tpw_rules>
how can i tell what version of recoveryOS i am in?
<jevinskie[m]>
sw_vers?
<tpw_rules>
that seems to be it, thank you
<tpw_rules>
marcan: would it be possible to add a temporary --wifi flag to the install.sh in the installer which just writes the tar to the passed file? i can submit a PR
willemml has joined #asahi
<Glanzmann>
chadmed: What was it?
<Glanzmann>
tpw_rules: Please do it. I was thinking about writing a small shell script, which downloads and extract the installer from githubt, extracts python the way marcan does it in the installer and thn run it.
<chadmed>
Glanzmann: i didnt keep the old config so i cant diff them but im assuming simplefb and simpledrm were clashing or something. i disabled all framebuffer/grpahics drivers except for simpledrm and it worked. no idea why it didnt work the first time i had it set up like that though.
<chadmed>
im using armtix right now, and my config has all those options enabled. ill build a newer version of libinput and see whats going on
<Glanzmann>
chadmed: I see.
<Glanzmann>
newchima[m]: Btw. deleting the only the stub partition works. I just tried that on my air. It reboots three times but than I get the dialog.
<Glanzmann>
s/the//
the_lanetly_052__ has quit [Ping timeout: 480 seconds]
<chadmed>
i believe marcan is working on a blog post in the coming few days/next week
<klaus>
chadmed: thanks for telling, i'll be eagerly waiting to read it then
<Glanzmann>
klaus: We have working wifi, the hdmi works on the mini again, jannau frontported and fixed dcp, marcan is working on smd, povic made the audiojack working on more devices, Sven Peter is working on debuging nvme flush problem and implemeneted nvme in m1n1. Marcan updated the installer to support version 12.1 yesterday. I think that's it.
<chadmed>
Tasks seems pretty up to date afaict, might be worth ticking off multitouch and keyboard, both of which work OOB with the latest libinput
<Glanzmann>
s/smd/smc/
<chadmed>
im about to head out but if no ones updated tasks by the time i get back ill sort it out
<Glanzmann>
klaus: Oh and most importantly the debian installer now works more or less with u-boot.
<klaus>
Glanzmann: thanks for the quick summary, that's very nice
<Glanzmann>
Oh and marcan wrote a document explaining our boot chain, which will me m1n1, u-boot, grub, kernel.
<Jbun>
Will the new post contain any updates on the GPU end?
<Glanzmann>
On the gpu nothing was done, IIRC. Other than jannau getting the dcp back in shape.
<chadmed>
dont think anyone's been game to tackle anything gpu related lately. jannau cleaned up the dcp driver a bit and alyssa's been chipping away at the agx compiler but its been slow progress
<Glanzmann>
I mean the dcp is very nice to have, because you can run monitor resolutions on the mini, do rotation and have hdmi hotplug. But ... no graphics peformance improvement.
<klaus>
i'm following marcan's videos and twitter posts, and also update on kernel mailing list so i can figure a bit what's going on, but a real blog and task list update provide better feedback and details, to be sure what i thought was going on, actualy made it, or was still wip, it help get a better sense of what's going on
<Jbun>
alyssa seemed to have gotten quite far from her blog posts and sounded quite close.
<chadmed>
its not really a priority i dont think since we can already boot to a desktop and it works incredibly well. stuff like cpufreq and the smc are far more important in terms of getting the machines fully featured (and also a lot easier)
<chadmed>
jbun: close in terms of it being GLES2 compliant but not close as in "works out of the box in linux" or even close as in "is as fast as Metal in macOS". thats still a little while off. we still need a kernel driver for starters, i dont think anyones even attempted one yet
<klaus>
( following marcan's twitter, but also sven's and alyssa's too of course .. that's the only ones i know of, if there's others to look at, i'd be happy to hear about them)
espo has joined #asahi
<Glanzmann>
chadmed: We need to talk marcan into using a m1 machine as his primary desktop, than we will have it in one day.
<klaus>
chadmed: yes, keyboard and mouse and also sound, if those points in the task list could be checked as done (if that's correctly the current state) that would be great
<chadmed>
klaus: yeah ill tick em off when i get back to my desk in a couple hours. they work with linux-asahi, theyre just not ticked off on the wiki
<chadmed>
Glanzmann: shame on marcan for making us eat his dogfood for him :P
<klaus>
chadmed: great then, thank you for that
<Glanzmann>
klaus: Keyboard and mouse work.
<Glanzmann>
klaus: Sound, only the audiojack. But povik is working on it.
<chadmed>
its pretty tasty as far as dog food goes though, far from the worst ive had to eat. that honour goes to broadcom and the raspberry pi foundation
<klaus>
i believe too that eating own dogfood is important step, it helps in seeing more accurately what users experience is like
<klaus>
many thanks for all the replies and details by the way, i'm rereading them all again :)
<Jbun>
why the hate on rpi and broadcom if i may ask?
<mps>
Jbun: broadcom is not open source friendly
<mps>
granted, most company also aren't, but broadcom especially
<chadmed>
jbun: most of what they release is restrictively licensed or distributed as binary blobs, and what isnt is usually code of subpar quality and rarely ever upstreamed while its still useful
<Jbun>
its kinda funny when companies go along that direction . opensource at best has always helped in gaining more users or at worst done revealed some internally workings that dont come close to hurting the core business
<chadmed>
raspberry pi foundation is complicit in this by using broadcom hardware, and keeping whatever open source stuff they do produce downstream for as long as possible. a good example of this is their fork of chromium, which is the only browser that actually runs somewhat smoothly on the rpi
<chadmed>
it contains a bunch of patches that they refuse to upstream, and is only available on raspbian to boot
<chadmed>
this is getting off topic tho
<_jannau_>
keyboard + trackpad work but that is far away from done. It's not in a state which can be submitted upstream
the_lanetly_052__ has joined #asahi
<mps>
klaus: I use MBP as primary workstation for two months (earlier with usb wifi and audio dongles, but now without them)
Jbun has quit [Quit: Page closed]
<klaus>
i hope i can install linux as standalone on internal ssd, and macos on external ssd (usb-c). having two OSes on internal ssd waste too much space, i have only 512gb and macos with a few needed apps installed eats up way too much space. so that would be my ideal usecase
<klaus>
also nice to hear above that debian installer works
<Glanzmann>
klaus: Works is maybe a little bit to much, grub and kernel needs to be installed manually, but otherwise it works.
<Glanzmann>
And the asahi bits need to be upstreamed, the kernel imported into debian and than we can use it out of the box.
<klaus>
i'm just an user (loosy sunday coder actualy, but my level is terribly bad :) but, from what i see, asahi should be more or less ready for a general public beta, just the install step would need to make it nice and easy for end users to test it out more simply. that would help in getting more feedback too. right now it seems a bit too rough around the edges on that step
<klaus>
the install step
<klaus>
i mean, having to juggle with git branches and install kernels and other bits manualy
<klaus>
with just one small improvement on the installing part, that would be good enough for a general public beta release
<klaus>
unless i'm mistaken.. that's the feeling i get
MajorBiscuit has joined #asahi
<Glanzmann>
klaus: Marcan thinks like you, but I assume he will release the first version soonish. I don't know what his list of blockers are, but probably smc.
the_lanetly_052__ has quit [Remote host closed the connection]
<klaus>
Glanzmann: very nice to hear, thank you for telling
<Glanzmann>
klaus: I also build live debian version that could be used for 'testing'.
<klaus>
Glanzmann: i'm curious, where are located these builds ? and is there install steps listed ?
<klaus>
debian isn't usualy my distro of choice, but that's already nice, and would be a major improvement to be able to run debian instead of "prison-bsd" (macos).
<Glanzmann>
klaus: You can install any software on it, including gnome as long as you don't run out of RAM.
<Glanzmann>
klaus: Btw. The same I did for Debian you can probably do for any other distribution very easily.
<klaus>
what's the problem with ram? doesn't it support swap file of partition ?
<Glanzmann>
I took a rootfs and put it in a initrd, that's it.
<Glanzmann>
klaus: you could do that, but I didn't do it, because I have 16GB of ram in my devices and even the smaller ones have 8gb which is sufficient to run a desktop environment from ram if you want to.
<Glanzmann>
klaus: I mainly build the live system as rescue system and to do installation.
<klaus>
i have the 8gb model, sure it's enough to run desktops and most apps too, but i just wondered about your comment, and thought 'if he runs into ram issues, why is he not adding a swap then ?' i mean i haven't ran into out of memory problems for ages.. because swap.. the only problem i may run too is performance because swaping a lot makes things go slower but that's about it
<Glanzmann>
klaus: You can add a swap file or partition if you want, it is just a command or two.
<klaus>
yes
<klaus>
fdisk and mkfs and swapon
<klaus>
not sure about mkfs?
<klaus>
but yes, fdisk and swapon, editing fstab too
<klaus>
i don't know what's going on with apple lately, but they are doing very badly with macos, introducing lots of bugs and nuisance, annoyance, questionable choices forced on users etc .. they are making switching to linux an even more desirable choice than it usualy is
<klaus>
basicaly their hardware is great, but their software is degrading a lot
<mps>
heh, I run alpine on chromebooks with 4GB RAM quite fine, and don't need swap
<mps>
I mean, xorg and firefox and sometimes other GUI apps
<klaus>
indeed i don't remember running into an out of memory problem since ages too
<j`ey>
that was about a live usb stick, where youre installing into a tmpfs
<j`ey>
*that comment
<mps>
sometimes I set some zram swap when building firefox and similar big software, but on M1 swap is not needed, at least till now
<klaus>
j`ey: ah i must have missed that detail then, i thought he was talking about installed OS not live install session, i understand better then
espo has quit [Quit: Leaving]
<mps>
klaus: if you prefer small and simple linux distro (as I do) I prepared script which installs alpine linux on usb stick or ssd disk
<mps>
it would be easy if one follow Glanzmanns first part guide about setting partitions, installing u-boot and firmware
<klaus>
macos eats through ram like a famished bulimic introduced to a 'all you can eat' event
<klaus>
the other day i saw its windowserver process eating up to 900mb (and kept climbing) it's their process for just handling windows around on the desktop
<Glanzmann>
mps: My primary workstation has 8 GB ...
<Glanzmann>
mps: I build on other machines.
<mps>
Glanzmann: what arch it is?
<Glanzmann>
mps: At least the big stuff.
<Glanzmann>
mps: Intel Nuc with a AMD GPU.
<Glanzmann>
mps: And my build hosts are AMD Ryzen 5950X with 128 GB, 10 Gbit/s and SSDs, sometimes NVMes.
<mps>
Glanzmann: I remember that I had to add swap space on my i7 with 8GB ram when building firefox, crystal, clang and similar things two years ago
<Glanzmann>
mps: Yeah sometimes I also ran out of RAM. I initial bought the nuc for my tv and repurposed it after noticing that I don't watch TV. :-)
<Glanzmann>
But when I do, I simply use another machine.
<mps>
Glanzmann: I don't own TV for more than 15 years ;-)
<mps>
never measured or made benchmarks but I think that arm arch uses memory more efficiently than x86 especially with musl libc
espo has joined #asahi
<dottedmag>
klaus: to be fair, a framebuffer for laptop screen and a framebuffer for external screen together eat 60MB. That's one buffer per screen, and there is definitely swapchain, and buffers for applications. So 900MB sounds gross, but 200-300MB is the lower bound of data it manages.
<klaus>
dottedmag: apple introduced a few memory leaks in their latest releases of macos, many things apple does lately feels like unfinished betas released to the public as final, but in practice lots of quality testing and proper debug were bypassed. OS version goes up and up, many new features introduced, most badly finished (more like unfinished), previous bug were not corrected, and in some cases ended up worse
<klaus>
with each new release, as i were saying above, they are doing very badly with macos lately. not to mention their horrible new theme and interface design going through the toilet and of course being forced on users with no workaround or mitigation possible
<klaus>
hum, irssi ate part of my reply it seems ;)
<dottedmag>
Not sure what this has to do with memory usage in WindowServer. Yeah, probably there is an inefficiency of factor 2-3, but it's not inconceivable that the compositor on high-DPI screens eats a gig.
<dottedmag>
(looking at gnome-shell connected to two high-DPI screens, it's got 500MB RSS)
<klaus>
the connection with memory usage in windowserver, is that like many other os component, their memory usage keep growing and growing as long as the os stays up. a reboot fixes it, but that's not a good solution of course
kloenk has joined #asahi
<TellowKrinkle[m]>
klaus: introduced recently? The window server memory leak has been around for ages
<TellowKrinkle[m]>
tbh I'm not sure if it was ever not been a thing on my retina MBP
<TellowKrinkle[m]>
Definitely was a thing in Catalina, and I'm pretty sure it was in Mavericks as well
<klaus>
TellowKrinkle[m]: ah you're the one helping port ps2 emu on macos ? nice one :)
<klaus>
i hope i'll be able to enjoy it more on linux, if the graphic stack get sorted out fine, being able to run full vulkan and all at some point down the road
<klaus>
but yes, just as you were saying .. each new release not solving problems, and they keep pilling up indeed.. apple touting new features, but not solving previous problems, and even new features aren't correctly implemented either. very bad..
<TellowKrinkle[m]>
M1 should be great for PS2 emulation
<TellowKrinkle[m]>
(I say that but I haven't implemented use of that feature in the Metal renderer yet... coming soon I promise)
<TellowKrinkle[m]>
The amount of weird stuff we try to work around the lack of a feature that's native in the M1 GPU (software blending) is crazy
<klaus>
i hope marcan and alyssa come up with better situation than what moltenvk team did come up with so far.. many feature missing and render problems. M1 gpu seems lacking some functionalities. last time i heard marcan talking about that he hinted they may come up with workaround and glue code to get full featured vulkan in the end, but that's was planned for later down the road, i hope they will succeed at that
<ChaosPrincess>
there is already some interesting progress, m1 gpu has more features than exported via metal
<klaus>
ChaosPrincess: i didn't know that, it's interesting to hear, so the problem is more with metal and the gpu itself ?
<ChaosPrincess>
oh, there is probably some eldritch monsters in hardware too
<klaus>
*more with metal than the gpu itself
<klaus>
:)
espo has quit [Quit: Leaving]
klaus has quit [Quit: leaving]
nsklaus has joined #asahi
<chadmed>
the windowserver memory leak has been around since big sur i think
<chadmed>
or whatever the one before catalina was
<TellowKrinkle[m]>
Mavericks
<TellowKrinkle[m]>
Big Sur is 11.0
<chadmed>
basically everything in macos started going to sh when they started trying to integrate ios apis into the main os instead of focusing on desktop features
<chadmed>
macos has sucked since about lion/mountain lion by that metric
<Glanzmann>
mps: I did not own a TV for over 22 years, than I met my wife ...
<Glanzmann>
Now I own three, not that I use it for other than hiding access points behind them.
<mps>
Glanzmann: :-)
espo has joined #asahi
the_lanetly_052 has joined #asahi
ChristianvonElm[m] has joined #asahi
<ChristianvonElm[m]>
I have a problem i would need to diagnose using earlycon, is there another option besides getting a second M1 or the Arduino Breakout thingy?
<chadmed>
m1n1 exposes two serial devices to the host machine. you can run your kernel as a guest in m1n1's hypervisor and get its console output via serial on ttyACM1
<mps>
ChristianvonElm[m]: you can use any machine with usb, not strictly M1 as host
<chadmed>
added a page to the wiki nicely detailing which features are supported on which devices. should be easy enough to maintain
<ChristianvonElm[m]>
Could you tell me how that works? Running under hypervisor is not ideal because i suspect that the panic could be related to the kernel running in EL2
<j`ey>
ChristianvonElm[m]: it only works for the HV
<j`ey>
ChristianvonElm[m]: are you trying to run a ""normal"" kernel or trying something new?
<kloenk>
Could anyone test this PR for me, Can't install m1n1 on my m1 right now, as I'm to dependent on it at this moment, but would love to know if it works
<j`ey>
ChristianvonElm[m]: heres an example of using the hv, worth a try: http://sprunge.us/G3kAqD
<j`ey>
ChristianvonElm[m]: then picocom/screen/etc to ttyACAM1
<kloenk>
[j"ey](https://matrix.to/#/@irc_oftc_j=60ey:petabyte.dev): like this with "core::ptr::write`?
<j`ey>
kloenk: somethin weird happened there with matrix, all I said was "like this with "core::ptr::write`?"
<sven>
nice!
<j`ey>
kloenk: you probably want write_volatile
roxiun[m] has joined #asahi
<kloenk>
Oh yeah, forgott the volatile. Pushed now
<chadmed>
i dont need to reboot into macos for this thing to charge, right?
<j`ey>
kloenk: marcan replied, but dont let that stop you!
<kloenk>
I still have to fix the Makefile, it does not detect the change in the rs files
<j`ey>
kloenk: fork m1n1 and make m1r1
<j`ey>
kloenk: in the makefile you have to add the deps after: build/$(RUST_LIB):
<j`ey>
oh, you have it PHONY for now
<sven>
doesn't build here fwiw, cp: build/aarch64-unknown-none/release/librust.a: No such file or directory but the library is in aarch64-unknown-none-softfloat here
<Glanzmann>
chadmed: Nope.
<kloenk>
j'ey: yes, have to learn for uni right now, Will add later
<j`ey>
kloenk: see what sven said, have to update the cp command now youre using softfloat
<j`ey>
sven: does it work after thats fixed?
<sven>
crashes with an unhandled exception
<j`ey>
impossible, rust doesnt crash!
<sven>
no time to debug that now though, sorry
<j`ey>
I wish I had a mac mini instead of mba, to have a more permanent setup
<Glanzmann>
j`ey: Yeah, its typesafe nothing can happen.
<kloenk>
sven: no worries, thanks for testing. Will fix the makefile stuff later
<sven>
once this works it would be nice to hook it up with nvme and add gpt and fat32 support :>
<kloenk>
yeah, currently the barest metal I did is linux kernel. So would have to see a bit more how to do that without the kernel :)
<j`ey>
that and psci could be interesting
<sven>
once we figured out however psci will look like ;)
<sven>
but yeah, i think the GPT/Fat32 stuff is the only attack surface we actually care about
<espo>
j`ey i know that feeling :), sometimes i wish i have bought a mini back then :P
<Glanzmann>
sven: Besides USB that is. :-)
<j`ey>
espo: mine was a gift, so I had no choice!
chadmed has quit [Ping timeout: 480 seconds]
<sven>
our usb support give you full read/write _by design_
<sven>
i'm sure there is an exploitable bug in the stack but why bother when it already gives you read32/write32 via the proxy?
<espo>
j`ey ah okay :D
<Glanzmann>
j`ey: For me, my mini is just sitting on the desk. The air I use every day. After marcan blessed us with wifi and povic made the audio jack work, mostly on Linux ...
<Glanzmann>
sven: No but m1n1 is one piece of fine software that is for sur. I even considered if I go back to m1n1 to get rid of the delay of u-boot and grub when booting.
<Glanzmann>
What I wondered, does someone know if there is a limit on the boot object. So for example could I run m1n1 with a 200 MB payload using kmutil?
<j`ey>
yes I believe so
<Glanzmann>
I mean there must be a limit but I wonder what it is.
<j`ey>
I think pipcet had a huuuge payload
<Glanzmann>
You mean it is possible?
<j`ey>
not sure what the limit is, but multiple MB is fine I think
<espo>
Glanzmann, i played a bit more with the displaylink. Will try it on a x86 maschine to see if its workable at all :D
<Glanzmann>
espo: If you mention what you tried in the channel, they will tell you why it can't work at the moment.
<espo>
I tried a usb2 displayconnector ( one of this fancy dell dockingstations laying around here ). And gets recognized and shows a device but when i use that device :) the complete macbook freezes :) ( thats more or less what i did ) :)
<kloenk>
Does anyone build m1n1 on macOS? for me it failes to build on macOS, but I can build it on a aarch64-linux builder (only with clang, as gcc want's this prefix that I don't have)
<j`ey>
support was added to make it possible to build on macOS
<j`ey>
(see e19e74be8b7d5f3643cbb4237ee6b8ba2a7d8578 and other commits)
<sven>
i only build it on macos
<kloenk>
I tried to build it today, but it complained about type redefinition, and that ".type" is unknown in the S files
<j`ey>
sven: youre using a gcc toolchain though, right?
<Glanzmann>
j`ey: I added the config option (CONFIG_FONT_TER16x32=y) biggest kernel font to my config, so I should do another recording, you can actually read something. (I could not read yesterday myself). I also upgrade all the build artefacts with the kernel.
<j`ey>
Glanzmann: thats the font im using too
<Glanzmann>
Before yesterday I never really cared about the kernel font, because I work on X. But yesterday was really a hell. I could not read, but I knew what I was typing ...
MajorBiscuit has quit [Ping timeout: 480 seconds]
<mps>
Glanzmann: I can send you my patch which add 12x24 terminus fonts for console, looks better and nice on my MBP, you probably saw it in video I posted few days ago
<Glanzmann>
mps: I see, but I'll probably will keep this font because it is in the kernel and honestly, I never see the console other than during boot because I start lightdm which logs me in automatically.
<tpw_rules>
it doesn't use flakes yet and it doesn't work on macOS yet. but you can install nixos in a UTM VM for aaarch64 and just nix-build m1n1 and the complete installer image
<kloenk>
yeah, Installing nixos in a UTM VM is still planned, never got around to it :)
<tpw_rules>
it's pretty easy and achieves almost native performance
<kloenk>
a flake would be so great for "nix develop"
<kloenk>
Yeah, just didn't get around to write a config yet :)
<tpw_rules>
but you should probably be doing this from a separate computer anyway. what if you accidentally zorch the mac?
<kloenk>
using the aarch64-community-builder at the moment
<tpw_rules>
all the stuff there can be cross-compiled from x86_64-linux
<kloenk>
Currently just coding. I have a really really big problem if I brick my mac. so I just test if it compiles ATM
<tpw_rules>
do you not have another computer
dyd64 has joined #asahi
<kloenk>
not a laptop with sufiicent battery size. Have like 10 servers laying around xD
<tpw_rules>
well you can cross compile everything on one of them
dyd64 has quit []
<tpw_rules>
kloenk: if you want to submit a PR to fix my m1n1 derivation so it compiles under macos, i would be grateful. unfortunately i think it's a lot of nontrivial work to get u-boot and the linux kernel working too, plus basically the whole stdenv. but i will soon™ start publishing prebuilt images. just waiting on some PRs to nixpkgs to land
<kloenk>
which prs on nixpkgs? maybe I can poke some maintainers over there to make it faster :)
<tpw_rules>
they are actually merged, just waiting for them to make their way from staging and be cached
<kloenk>
ah okay, I always use master, so always forget that :)
<tpw_rules>
there is a hydra job which runs every few days that builds a cross-compiled stdenv which reduces the time to build the installer from like 2 hours to 10 minutes. and the PRs fix some reproducibility issues
<tpw_rules>
but everything will work fine and only take 10 minutes if you do it yourself now (and have a sufficiently fast computer). i'm just waiting to start publishing pre-built stuff
<tpw_rules>
and you might have to suffer a bit of an old nixpkgs :)
yuyichao_ has joined #asahi
MajorBiscuit has joined #asahi
<Glanzmann>
tpw_rules: Or just run it in a VM under MacOS with near native performance.
<Glanzmann>
Now that we have the shiny new qemu.
<Glanzmann>
Actually I know at least one company which bought a m1 mini directly after release to have linux running in a vm as build target for arm64. And it runs that way ever since used by git lab.
<mps>
Glanzmann: my son built qemu with patches for HVF right when he bought it about year and a half ago, qemu is really fast on M1
<mps>
it was in autumn 2020 I think in october or november
<mps>
I was fascinated how it is fast
<mps>
that started me to contemplate to buy m1
<pimeys[m]>
I'm waiting to replace my raspberry pi with an m1 running nixos natively
<pimeys[m]>
a good build server for arm linux too
<mini>
Glanzmann: I have been using a mac mini for that for a few months now
<mps>
as alpine developer I have access to Neoverse-N1 with 160 cores with two NUMA nodes each with 80 cores, but building kernel on M1 is lot faster than on this neoverse-n1
<mini>
absolutely wonderful to build arm64 containers etc on
<mps>
well instead of 'lot faster' I should say substantially faster
<pimeys[m]>
also I still think having a self-built workstation serves a better purpose for me than a soldered system where you can't replace anything, and a fast ryzen still is quite a lot faster than M1
<pimeys[m]>
waiting for an arm cpu I can just buy separately and plug to my system, keeping the gpu and all that
<kettenis>
but x86 is so boring!
ChristianvonElm[m] has left #asahi [#asahi]
<pimeys[m]>
but testing arm builds is definitely something I need
<pimeys[m]>
using macos even remotely is a horrible experience, but with linux...
<pimeys[m]>
amazon is either very slow or you get a surprise bill if you forget some of your faster instances running
<mps>
kettenis: right, and in 2012 I decided to not buy intel anymore
<Glanzmann>
mps: Hrhr. Funny.
<Glanzmann>
pimeys[m]: Of course the ryzen is faster, and I like it as build server, but sometimes you don't want to cross compile and also don't look at the power bill.
<pimeys[m]>
yep!
<Glanzmann>
Hetzner announced today that they have to increase power prices in Germany due to rising power costs.
<pimeys[m]>
I'm super happy with my 3950x still, it's extremely fast, but I also need to test ARM stuff for work
<Glanzmann>
I also have two 3950x and I'm also happy with them but the 5950x are like 30% faster when compiling kernels. I benchmarked it ...
<pimeys[m]>
it is, about the same for our work project too
<pimeys[m]>
still I don't want to pay for that, waiting for 7950x and then upgrading :)
<mps>
heh, in 2014 I bought samsung peach pi (exynos 5800 arm32) chromebook and first days installed debian in bare metal mode, used it few years as workstation
<pimeys[m]>
with rust, whatever CPU power you can give to the compiler the better...
<mps>
OT sorry, but rust is not what I would like to use, started learning for few months and concluded it is not worth for me
<pimeys[m]>
not wanting to go to OT here, so ending my ramble by saying I need rust for work and there whatever CPU power is all good. hopefully I can by an ARM cpu to my machine one day that runs faster than my ryzen
<j`ey>
kloenk: there's something wrong with the printing
<kloenk>
oh?
<j`ey>
kloenk: well that causes some kinda fault/exception
<j`ey>
I removed all the adt/printing stuff, and it works
<kloenk>
I wonder if it's adt or printing. Not 100% sure of the adt code
<j`ey>
its printing, i have adt commented out and just prints
ciggi has quit [Ping timeout: 480 seconds]
<kloenk>
hmm, ok. Thanks, will have to look at it again
<j`ey>
kloenk: it's probably a relocation problem, or something like that
<j`ey>
kloenk: rust's format stuff uses vtable kinda things
<j`ey>
kloenk: crate::print::write("hi from rust!"); works fine
<kloenk>
maybe removing the inline stuff could help. but not sure right now. Will have to look into core for that
Sellerie6 has joined #asahi
Sellerie has quit [Remote host closed the connection]
Sellerie6 is now known as Sellerie
jhnsn has joined #asahi
jhnsn has quit []
jhnsn has joined #asahi
<j`ey>
kloenk: got it working
jx0 has quit [Ping timeout: 480 seconds]
<kloenk>
mind sending me a patch as a mail (or push to the branch if you have access to it)?
<j`ey>
kloenk: yeah I will do soon, going to add adt back in
jhns0n has joined #asahi
jhns0n has quit []
jx0 has joined #asahi
jhnsn has quit [Ping timeout: 480 seconds]
<j`ey>
kloenk: the adt is getting 0 as the address of the watchdog
<kloenk>
Well, that does not sound right?
<j`ey>
kloenk: not quite!
<j`ey>
just a few thousand off :P
<kloenk>
what size does int have?
<kloenk>
maybe that's the problem
<j`ey>
int is 32, thats another thing I fixed
<j`ey>
using isize instead of i32
<kloenk>
yeah, was unsure of what to use. But fixing that did't help?
<j`ey>
not immediately
aleasto has quit [Quit: Konversation terminated!]
aleasto has joined #asahi
<j`ey>
found it, null terminated issues of course!
<kloenk>
yeah, maybe I should create an alloc, and use CString. but that does require nightly
<kloenk>
or some very special (undocumented) rust tricks. rust-for-linux uses those
Latrina has quit [Quit: Powered by AlpineLinux under the supervision of Docker.]
aleasto has quit [Remote host closed the connection]
aleasto has joined #asahi
Latrina has joined #asahi
the_lanetly_052 has quit [Ping timeout: 480 seconds]
<j`ey>
kloenk: and move the [profile] stuff from rust/Cargo.toml to ./Cargo.toml
<kloenk>
j`ey: oh yeah, sounds good. Added the workspace later so forgot that.
<kloenk>
j`ey: is panic = "abort" the best idea? do you know that? I have a panic handle with wdt_reboot, so maybe this is not required, as it would reboot?
<Glanzmann>
I wrote a stupid small script to extract the firmware by utilizing the installer and put it in /tmp until marcan does that in the installer on macos: curl -sL tg.st/u/fwx.sh | sh
<Glanzmann>
I ended up installing 20 GB of xcode multiple times to extract the firmware ...
<mps>
Glanzmann: when I exported firmware from macos I made tar file and put it on usb disk, then from linux run python from installer
jhnsn has joined #asahi
<mps>
didn't installed installer on macos
<Glanzmann>
mps: This is more or less what I also want, so I think in the end marcan will copy the firmware in the installer to the stub partition and step2.sh can than copy it to esp partition. From there everyone who needs it can pick it up.
jhns0n has joined #asahi
jeffmiw has quit [Remote host closed the connection]