<radens>
Hello. I'm having trouble getting the timer interrupt to work on qemu emulating an rpi3 (BCM2837, a quad core 64 bit arm machine)
phy1729 has left #osdev [#osdev]
<radens>
If I understand correctly I need to: 0. Set VBAR_EL1 to my vector table. 1. enable the timer IRQ in the INTERRUPT_BASIC_ENABLE register in the interrupt controller by setting bit 0, 2. Enable the arm architectural timer by setting bit 0 in CNTP_CTL_EL0. 3. Set the deadline/count down register to a value larger than the timer physical count value. This can be done by a. punching a number into CNTP_TVAL_EL0, or b. setting CNTP_CVAL_EL0
<radens>
to be a value greater than the physical timer value. 4. Do wfi to wait for an interrupt and the timer to expire.
<radens>
Oh also doing msr daifrclr, #2 to clear the interrupts mask
<clever>
radens: you could try enabling the uart irq first, to confirm most of the other irq stuff is working?
<radens>
I'm doing all of that but the IRQ isn't triggering
<radens>
clever: yeah I could program the UART instead, but I figured I'd ask here first in case I'm missing something obvious
<_eryjus>
radens: I remember having trouble with the rpi2b and the solution was far simpler than I expected. looking for an example if that will help
<radens>
_eryjus: thanks
tacco has quit [Remote host closed the connection]
<bslsk05>
github.com: century-os/PicInit.cc at master · eryjus/century-os · GitHub
<vai>
Does IDE0, IDE1, etc. or SATA0, SATA1 respectfully - support simultaneous access on all hardware available in the markets?
<vai>
Is copying from IDE0 to IDE1, reading sametime as wriiting supported, or is it just mym Qemu/VirtualBox emulated hardware supporting this?
<vai>
E.g. might at least some interrupt violations, have to share, etc. Very dirty!
<vai>
morning from Finland :-)
<Affliction>
with IDE, devices on the same cable can't communicate simultaneously, if you have two channels, they're independent. SATA ports are independent, and most vaguely modern drives support command queuing.
<Affliction>
With interrupts, either way you have to ask the controller about why the interrupt was raised, so you can establish which disk caused it.
<zid>
one last random thought, clear out any pending irqs? maybe it was edge triggered and you missed it while it was masked at boot
eryjus has joined #osdev
<clever>
zid: i think the timer irqs are level triggered, when i didnt mask every interrupt in my bootloader, it causes linux to just deadlock
<zid>
shame
<clever>
because linux wasnt expecting the timer to be in that mode, and when the irq's got enabled, it immediately got stuck in a loop for an irq it wasnt prepared for
_eryjus has quit [Ping timeout: 268 seconds]
_eryjus has joined #osdev
eryjus has quit [Ping timeout: 260 seconds]
eryjus has joined #osdev
_eryjus has quit [Ping timeout: 264 seconds]
Belxjander has joined #osdev
mctpyt has joined #osdev
Vercas has quit [Ping timeout: 276 seconds]
Vercas has joined #osdev
ElectronApps has joined #osdev
vdamewood has joined #osdev
gog has quit [Ping timeout: 264 seconds]
dutch has quit [Quit: WeeChat 3.3]
dutch has joined #osdev
_eryjus has joined #osdev
eryjus has quit [Ping timeout: 245 seconds]
[_] has joined #osdev
_eryjus is now known as eryjus
[itchyjunk] has quit [Ping timeout: 264 seconds]
radens has quit [Quit: Connection closed for inactivity]
<eryjus>
klange you around?
skipwich has quit [Read error: Connection reset by peer]
vdamewood has quit [Ping timeout: 245 seconds]
vinleod has joined #osdev
srjek|home has quit [Ping timeout: 264 seconds]
[_] is now known as [itchyjunk]
Oli has quit [Quit: leaving]
Oli has joined #osdev
<klange>
eryjus: 'sup?
vinleod is now known as vdamewood
Oli has quit [Quit: leaving]
<klange>
I think I will do one more beta for November, 1.99.9, and 2.0's final release will be holiday gift.
radens has joined #osdev
[itchyjunk] has quit [Remote host closed the connection]
ElectronApps has quit [Remote host closed the connection]
ElectronApps has joined #osdev
C-Man has quit [Ping timeout: 264 seconds]
GeDaMo has joined #osdev
Electron has joined #osdev
ElectronApps has quit [Ping timeout: 260 seconds]
ravan has quit [Remote host closed the connection]
radens has quit [Quit: Connection closed for inactivity]
zaquest has quit [Remote host closed the connection]
<graphitemaster>
> The requested URL was not found on this server.
<klange>
My original compositor - the one before Yutani - had a window switcher that showed the window texture. With Yutani, the window switcher was moved to the panel and it lost that.
<klange>
graphitemaster: Check that your IRC client isn't incorrectly double-encoding %'s or something silly.
<graphitemaster>
ToaruOS already better than Windows 11 because you can put your taskbar at the top
<klange>
Funny you say that since there's still a silly quirk in the compositor where the way it maximizes / tiles windows is entirely based on the bottom edge of the "top z" window (if one exists), so it can _only_ be at the top.
<klange>
No reason I can't make that logic a bit smarter, of course - the real blocker for the panel being elsehwere is the menus that currently open down.
<klange>
Anyway, while I had to tweak some of the protocol for Yutani, this isn't really doing anything special, it's just the panel taking window buffer IDs and quietly mapping them to use as a texture source. The only thing I had to change was telling the panel those buffer IDs... and the sizes of the windows.
srjek|home has quit [Ping timeout: 245 seconds]
<klange>
Previously it just got window ID, some flag bits (focused, etc.), and the title/icon name.
srjek has joined #osdev
<sortie>
klange, sweet alt tab view
dennis95 has joined #osdev
gog has joined #osdev
<zid>
klange: I take it you implemented the full jpeg spec and all existing out of spec variants now?
<bslsk05>
wiki.osdev.org: User:Sortie/Yes Another Unix Clone - OSDev Wiki
<MelMalik>
junon: nobody uses 6502
<jeaye>
sortie: I agree with your sentiment. I think that your "innovation" section ends with a contradiction, though.
<eryjus>
sortie: people who can't criticize those who can
<jeaye>
sortie: "A custom design should at least be an order magnitude better than POSIX to be worthwhile." contradicts your previous point that people can build whatever they want.
<jeaye>
Just building it makes it worthwhile.
mahmutov has quit [Ping timeout: 260 seconds]
<jeaye>
Since there is not objective "worthwhile".
<sortie>
I am not telling people to do anything worthwhile :)
<zid>
Nothing's stopping anybody supporting.. two APIs
<zid>
windows also supports a subset of posix, and you know, WSL
<sortie>
Just saying that if they do want it to be worthwhile, it has to solve a problem an order of magnitude better to compete
<zid>
and win32 and .net etc
<sortie>
Mostly this thing is just about shutting up the pointless discussions unrelated to the actual topic
<zid>
The only gripe I have with posix is sort of just, inertia, that nobody cares enough about getting into a huge war between the drives, the fs layer and posxi to make the filesystem apis more reliable
<MelMalik>
even plan 9 has limited posix in the form of ape
<zid>
so I end up using sqlite for it instead of native code
<jeaye>
"When you are finally done, you are an expert in a custom operating system, and all that knowledge is useless unless you managed to gain market share. " => Do you really think it's useless knowledge, building a custom OS which nobody uses?
<zid>
it's useless to build your own house
<zid>
all you know is the framing style you used to build it
<jeaye>
Seems like it's a huge learning opportunity and a good test of one's design, motivation, and planning.
<Ameisen_>
my main gripe with unixy systems is they've already been done to hell and back
<Ameisen_>
and I think more work needs to be done in more structured systems
<junon>
MelMalik: was a joke ;)
<zid>
so have gameboy emulators but I'd still recommend writing one
<Ameisen_>
I wrote a MIPS emulator instead
Ameisen_ is now known as Ameisen
<Ameisen>
Though my name is finally on an LLVM CL (though not as the author)
<j`ey>
Ameisen: gj
<zid>
I just moan at people on irc to fix things it's way easier
<MelMalik>
zid: but then you didn't do it
<zid>
I did a lot of moaning, trust me
Vidius has joined #osdev
<MelMalik>
but no fixing
<Ameisen>
;}
<zid>
it gets it fixed, through my actions
<zid>
ergo I fixed it
<Ameisen>
well, there was literally a (popular) blog post about a performance bug
<Ameisen>
I actually, you know, wrote test cases and _reported_ it
<Qubasa>
So how do I know where grub 2 places the memory map before executing the kernel? Because I discovered that I placed my stack where the grub 2 memory map lies
<geist>
that's kinda a toughy. i've generally solved that by putting the initial stack inside the kernel itself
<Qubasa>
ahh i see ^^
<geist>
ie, in the data or bss segment, then it's part of the kernel's footprint that grub should have taken into account when it loaded it
<Qubasa>
Sweet thanks~
<zid>
yea I copy mine to 'kernel memory'
<zid>
and use a stack in .bss
<Qubasa>
Hmm I will do the same then
* kingoffrance
blinks "I just moan at people on irc to fix things it's way easier" zid == sky :)
wootehfoot has quit [Read error: Connection reset by peer]
CryptoDavid has joined #osdev
[itchyjunk] has quit [Remote host closed the connection]
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
<geist>
huh TIL that SMB supports a file duplicate op
<geist>
dunno when that got added but if you copy a file with explorer on a SMB3 samba server w/btrfs it just instantly returns
<geist>
and it does a straight up COW copy of the file, verified with filefrag -v
<Ameisen>
ReFS on NT supports copy-on-write, except that _nothing_ exposes it
<geist>
been there for a while it looks, i just never had a server backed by a COW filesystem i guess
<MelMalik>
oh my
<Ameisen>
there's some WinAPIs to handle COW of specific blocks
<Ameisen>
it's very frustrating. I'm guessing that they only want it for data deduplication on Windows Server.
<geist>
Ameisen: yeah that was my guess why they added the SMB op, they were planning on using refs or whatnot
<Ameisen>
but none of the tools at all support COW
<geist>
though i guess also having the server do a local copy even without cow is still faster
<Ameisen>
What is the fundamental reason that they couldn't add Copy-on-Write support to, say, NTFS?
<Ameisen>
Any time I've read on that, people say it's because it's journalled, but I fail to see how that causes an incompatibility.
<geist>
well it's just pretty intrinsic to the way extents are recorded and whatnot
<geist>
it'd be like adding COW to ext4 or something, would require a fairly fundamental rethinking of how extents and inodes work
<Ameisen>
I suppose; my stupid primate brain keeps thinking of a dumb COW implementation as equivalent to just... being a really fancy hard link
<geist>
COW fses like WAFL and ZFS and BTRFS are pretty fundamentally designed around it
<junon>
Why hasn't BTRFS been more widely adopted?
<Ameisen>
I'm not entirely sure why it oculdn't be implemented as a really fancy hard-link, actually
<junon>
Or ZFS for that matter
<geist>
COW for the whole file yeah, but then the instant you touch it you have to dup it
<Ameisen>
because BTRFS somehow manages to have random bouts of instability and data loss
<geist>
real COW does it at the extent level
<Ameisen>
even whole-file COW would be better than no COW, though
<geist>
Ameisen: in the past yes, but i think it's quite stable now
<Ameisen>
yeah, but the people who would otherwise be in a position to choose BTRFS have very long memories, to the point that they don't invalidate old/useless data :)
<junon>
BTRFS is supposed to be more efficient with write degradation on SSDs right?
<geist>
not sure, whole file would be, since you'd now suddenly be signing up for some point in the future suddenly needing to duplicate a shit-ton of data
<Ameisen>
Technically, file systems _meant_ for flash memory should be more efficient on SSDs
<junon>
Yeah. Imagine an MMAPed file with COW.
<Ameisen>
but I've never seen that actually be the case.
<geist>
Ameisen: well also people like you just repeat old things like 'its sometimes unstable'
<junon>
Any accidental writes to the address space would trigger a full clone, and MMAP is often used to map in gigabytes of data
<Ameisen>
I didn't exclude myself from my statement.
<Ameisen>
:)
<geist>
heh
<Ameisen>
though I'm not really in a position to choose BTRFS except on my personal stuff
<Ameisen>
I will point out that a big reason it isn't used is that most Linux distro installers don't offer it.
<geist>
yah. i use it on personal stuff, and my synology NAS box uses it
<Ameisen>
They set up EXT4 (and not really with the ideal flags)
<geist>
which is why i suddenly noticed it, like 'wait why did that copy take zero time?'
<Ameisen>
I actually was using ReFS on Windows for my development drive
<Ameisen>
I switched it back to NTFS, though
<Ameisen>
there are just... a lot of issues with using ReFS in such a case
<geist>
i wouldn't say most distros dont offer it, they just default to ext4
<geist>
and yeha i'm sure most people take the default
<Ameisen>
ReFS has issues with hard links, most software that cares about the file system outright does not support ReFS...
<Ameisen>
and they made it so you cannot create or repair ReFS partitions unless you have Pro for Workstation or whatever they call it
<geist>
yah fundamentally refs is abandoned so that alone kills it
<Ameisen>
They are still updating it
<Ameisen>
it's just... not used
<geist>
same way that reiserfs may still be lovely or whatnot, but it's abandoned AFAICT
<Ameisen>
WinBTRFS works, though
<geist>
due to prison and whatnot
<Ameisen>
though the code is... not great, and it makes me wary of its stability
<Ameisen>
it's also slower than NTFS
<Bitweasil>
WinBTRFS as a name scares the crap out of me. :p
<Ameisen>
hah
<Ameisen>
it does work.
<Bitweasil>
I don't even want to see the code.
<Bitweasil>
I'm sure it does.
<Ameisen>
it's... umm...
<Bitweasil>
So do many things that ought not work.
<Ameisen>
very C-like C++
<Ameisen>
but bad C and bad C++
<geist>
what are we talking about? nftfs, refs?
<Ameisen>
I've also found odd things in it like, in order to zero an extent, they do a bunch of WriteFile ops instead of mapping the extent and memseting it, which is faster.
<klange>
gods damned orange site
<geist>
welll.. not sure about that (mapping)
GeDaMo has quit [Remote host closed the connection]
<geist>
mappig/unmapping may have substantial cost
<Ameisen>
in my tests it was
<Ameisen>
the kernel is already going to map/unmap for the WriteFile
<geist>
sure, but kernel can optimize the wazoo out of that
<Ameisen>
it can optimize the wazoo out of a write-only sequential memory map as well
<Ameisen>
one less layer
<Ameisen>
since you can specify usage parameters for memory maps in WinAPI
* geist
shrugs
<geist>
alright, you da boss
Oli has quit [Ping timeout: 264 seconds]
<Ameisen>
it does depend on what you're doing though
<Ameisen>
I've never found plain ol' ReadFile/WriteFile to be faster, though, than the alternatives
<Ameisen>
_overlapped_ ReadFile/WriteFile is competitive with memory mapping, though
<Ameisen>
but in different ways
<Ameisen>
NT just... sort of doesn't do well with normal file ops.
Oli has joined #osdev
<geist>
yah possibly true. depends on exactly how it shuffles data from user space to the backing pages
<Ameisen>
overlapped ones it does - it knows it can reorder/optimize/merge ops. The non-concurrent ones it cannot.
<geist>
also some of that 'needs to map/unmap in kernel' stuff may be obsolete for x86-64?
<geist>
perhaps they have much more address space such that defacto it ends up mapped always?
<Ameisen>
Might be. They don't really go into detail about the underlying implementation in NT.
<Ameisen>
And it might differ betwee XP-64, Vista, 7, 8, 10, and 11
<geist>
since lots of systems one way or another have basically all physical ram mapped in the kernel you can fairly easily indirect to the backing page and directly copy
<Ameisen>
My knowledge is mostly from my own testing in various environments
<Ameisen>
but it might not apply to the usage patterns in a file system
<Ameisen>
I do know that I loved using memory mapping on the XB1.
<geist>
my usual experience is that mmap/unmap on pretty much all oses has substantial cost so there's a crossover point where it becomes more efficient
<Ameisen>
I basically had infinite address space, so it made little sense to not just map every file (in archives)
<geist>
like, if you're accessing things many times or the size of the copy is substantial
<geist>
we're dealing with this in fuchsia/zircon a lot, since the VM gives user space substantial control over what it does with its memory
<geist>
so educating folks on the right way to do things (or finding them in the first place) is fun
<Ameisen>
WinAPI memory mapping is a bit different in function than POSIX mmap
<Ameisen>
they accomplish the same goals, but WinAPI's is a bit more... 'structured'
<Ameisen>
It's a two step process - you create a file mapping object, and then you create file views into it.
<Ameisen>
the file view is what gives you a pointer.
<Ameisen>
after creating the mapping object, creating file views (should) be relatively cheap
<Ameisen>
But, as always, WinAPI stuff is effectively a black box performance-wise
<klange>
wheee
<Ameisen>
I'd actually have to profile that exact case. I don't normally, in my own stuff, memory map stuff on the fly for temporary ops
<Ameisen>
I do recall a somewhat interesting test I did, but it's an odd one.
<Ameisen>
I was comparing reading a file, block-decompressing it, and sending it to the GPU, vs mapping the file, passing it through my VEX/page fault-based decompressor, and giving the pointer to D3D11.
<Ameisen>
The latter was faster despite the sheer number of page faults
<Ameisen>
I write a lot after taking stuff for migraines
<Ameisen>
I blame the caffeine
<geist>
yah we have some fairly exotic stuff like taht in fuchsia due to EXTREME SANDBOXING
<Ameisen>
The bigger issue with WinBTRFS, though, was that it used C-style object cleanup for the various handles/objects, but it did so inconsistently.
<geist>
like decompressor processes that are standalone from regular FS server, etc
<Ameisen>
I actually gave an example PR that used C++-style RAII to do cleanup, but they didn't want such a significant change... even though I was able to show several memory leaks.
<geist>
all moving data through this complex scheme of shared mappings
<Ameisen>
I actually still cannot account for -why- it was faster to do it using the fault-based decompressor.
<Ameisen>
everything in my head tells me that it should have been slower.
Emil has joined #osdev
m3a has left #osdev [#osdev]
Maka_Albarn has joined #osdev
<Maka_Albarn>
I've been digging through the GCC manual, can anyone tell me what section GCC puts the debugging info from -g into? And is it possible to define it in the linker script?
<Maka_Albarn>
...
<Maka_Albarn>
scratch the second question.
<zid>
.debug_*
<Maka_Albarn>
final question: what format would the debugging info be in for i686-elf-gcc?
* Maka_Albarn
rubs head sheepishly
mctpyt has quit [Ping timeout: 260 seconds]
<j`ey>
DWARF?
<zid>
dwarf
* Maka_Albarn
beams
<Maka_Albarn>
thank you
m3a has joined #osdev
ahlk has quit [Read error: Connection reset by peer]
ahlk has joined #osdev
pretty_dumm_guy has quit [Quit: WeeChat 3.3]
Sos has quit [Quit: Leaving]
tacco has quit [Remote host closed the connection]
elderK has joined #osdev
hbag has joined #osdev
<klange>
Well, the orange site brought me over 4k stars, so that's nice I guess.
<junon>
Holy shit
<klange>
not 4k new, just made the total go over 4k
<junon>
OH
<junon>
Gotcha, what was it before?
<klange>
Last month it was ~3690. This morning it was 3960. Currently at 4003.
<junon>
Incredible
tacco has joined #osdev
<junon>
Alright just finished the first version of the C compiler configurator for the build system I wrote
<junon>
That was actually a lot of fun. Good mix of C and Lua.
CryptoDavid has quit [Quit: Connection closed for inactivity]
<junon>
Now I have to configure the link rules and I'll be ready to add it to the kernel repository and replace CMake, thankfully.
X-Scale` has joined #osdev
<gog>
i remember trying cmake and running as fast as i could back to my little makefile setup lol
X-Scale has quit [Ping timeout: 260 seconds]
<gog>
it works for my purposes. certainly not anything larger tho
<MelMalik>
merp
<junon>
This build system is more like Make than it is CMake, and it's super modular which I like.
<gog>
nice
<gog>
so is it like the build script is a lua module?
X-Scale` is now known as X-Scale
<junon>
I might rip it out of the commons submodule that it currently lives in and release it as its own thing since it's getting quite large now.
<MelMalik>
meow
<junon>
Yeah, you configure with Lua but using a shebang script basically. The shebang starts the actual build system, which bootstraps itself (looks for a C compiler and compiles the Lua runtime along with some extra C functions), sets up all the paths and everything, then runs the main configuration script.
<gog>
oh wow
<gog>
MelMalik: mew
<MelMalik>
sup gag
<MelMalik>
gog*
<junon>
The C runtime exposes a number of extra functions, such as running programs during configure-time (to e.g. detect compiler versions and stuff). There's also a standard/internal Lua runtime that bootstraps itself too, which implements all of the path construction and the ultimate Ninja build file generation.