channel logs for 2004 - 2010 are archived at http://tunes.org/~nef/logs/old/ ·· can't be searched
#osdev2 = #osdev @ Libera from 23may2021 to present
#osdev @ OPN/FreeNode from 3apr2001 to 23may2021
all other channels are on OPN/FreeNode from 2004 to present
http://bespin.org/~qz/search/?view=1&c=osdev2&y=21&m=11&d=7
00:00:00 <geist> ah still down? seems to happen from time to time
00:00:00 <geist> reminds me, is it possible to take a snapshot of it when it's alive, with the idea that maybe it doesn't come back one of these times?
00:02:00 <vdamewood> wget -r? :P
00:02:00 <zid> archive.org may have it?
00:02:00 <geist> well, i mean some sort of download the contents. some wikis have that support, from what i remember
00:02:00 <geist> sure, could slurp the contents, but i'm thinking of something more fundamental
00:03:00 <vdamewood> You mean something more like ssh dbadmin@osdev.org pgsql dump osdevsite > osdev.sql
00:04:00 <vdamewood> ?
00:05:00 <geist> perhaps
00:06:00 <geist> was thinkingo f how at least at some point you could get a tarball of the contents of wikipedia
00:06:00 <geist> it was a feature of the wiki
00:07:00 <gog> send me $200 i'll get the site working again
00:10:00 <zid> $199 and I'll do a full replacement site hosted off a $2 vps
00:10:00 <vdamewood> gog: Will 26,000 króna work?
00:10:00 <gog> yes
00:10:00 * vdamewood has precicely 0 króna.
00:10:00 <gog> :<
00:11:00 <zid> http://hold.abuser.eu/ done
00:11:00 <gog> bitkróna
00:11:00 <bslsk05> hold.abuser.eu <no title>
00:11:00 * vdamewood gives gog a fishy
00:11:00 * gog chomps fishy
00:12:00 <zid> okay version 2 is up
00:13:00 <vdamewood> Oh, did someone snipe the domain after expiry?
00:14:00 <zid> If anybody wants to contribute to v3 I accept patches
00:16:00 <gog> lmao
00:17:00 <vdamewood> Dammit real life getting in the way of my IRCing.
00:18:00 <gog> booo
00:31:00 <brynet> o/ #osdev
00:42:00 <geist> lo
00:42:00 <gog> hæ
00:52:00 <geist> wiki seems back up but i can't log in
00:53:00 <geist> says my account is not valid :)
00:54:00 <gog> your account isn't valid but you are <3
00:55:00 <geist> awww
00:55:00 * geist feels the luv
00:57:00 <geist> also digging around there is a osdev wiki dump file: http://files.osdev.org/osdev_wiki.zip
00:57:00 <geist> unclear if it's updated frequently but it's linked off the About page of the wiki
00:57:00 <geist> judging from the time stamps of the files inside it....it's not up to date
00:57:00 <geist> everything seems to be dated 2018-01-21
01:09:00 <Maka_Albarn> I just thought about this, but can you edit inactive descriptors in the GDT/LDT? that is, descriptors that are not pointed to by the segment selectors?
01:09:00 <Maka_Albarn> or do you need to flush the gdt each time to make a change?
01:10:00 <zid> depends if it's cached or not and I'm not sure you can tell
01:12:00 <Maka_Albarn> zid: soooo.... flush anyway to be sure?
01:18:00 <Maka_Albarn> hmm. gotta go. see ya
03:04:00 <eryjus> geist: do you know if chase hosts osdev dot org on his own equipment or in a data center?
03:04:00 <junon> eryjus: it's a linode instance IIRC.
03:05:00 <junon> It's dog slow. Is it getting DOSed?
03:05:00 <junon> Was down a few days ago entirely too :/
03:13:00 <eryjus> junon: thx
04:32:00 <kazinsal> it is kind of bizarre that we don't really have any way to get a hold of the guy who has the keys to the site, but then again, for the longest time we were at most unofficially tangentially related to the site
04:41:00 <junon> yeah.
04:41:00 <junon> I wonder how much it costs. I'd be willing to contribute.
04:42:00 <kazinsal> my suspicion is it's not really a cost problem, but more likely something on the linode box ate 100% of the CPU and is choking out nginx or whatever
05:33:00 <Ameisen> Did any company (I don't think that Motorola did) ever make a 64-bit variant of the 68k?
05:34:00 <zid> I'm not sure there are many 64bit cpus in general
05:34:00 <Ameisen> apparnetly Apollo was supposedly making a 64-bit version, the AC-68080?
05:35:00 <Ameisen> that or they _did_?
05:35:00 <wleslie> if you were going to, why not start from the m88k?
05:39:00 <Ameisen> I mean
05:39:00 <Ameisen> they're pretty different ISAs
05:43:00 <wleslie> sure, I guess it depends on why you're doing that
08:34:00 <klange> sortie, graphitemaster, zid: `ld -r -o thing.o --format=binary thing.bin`
08:35:00 <klange> results in an object with symbols _binary_thing_bin_start, _binary_thing_bin_end, _binary_thing_bin_size
08:43:00 <clever> ive tried using that, but when using relative paths, the entire path winds up in the symbol name
08:43:00 <clever> and it gets ugly rather fast
08:44:00 <clever> but .incbin is far simpler to use, and you can even generate private symbols and pre-fill a table for C usage: https://github.com/librerpi/lk-overlay/blob/master/platform/bcm28xx/arm/payload.S
08:44:00 <bslsk05> github.com: lk-overlay/payload.S at master · librerpi/lk-overlay · GitHub
08:44:00 <clever> this will embed 2 binaries, but the symbols arent global, it then generates a fixed-size struct array, containing each start+size
08:45:00 <clever> which you can then just lookup as normal: https://github.com/librerpi/lk-overlay/blob/master/platform/bcm28xx/arm/arm.c#L25-L31
08:45:00 <bslsk05> github.com: lk-overlay/arm.c at master · librerpi/lk-overlay · GitHub
08:45:00 <klange> I'm not really sure that's easier to use? You have to write an assembly shell, vs. this single command.
08:46:00 <clever> when you do ../../foo/binary.bin, you wind up with a _binary_foo_binary_bin_start symbol
08:46:00 <clever> and if your path was dynamically generated at build time, your symbol is now dynamic
08:46:00 <clever> so you need to replace every special character with an _ to create a matching symbol
08:46:00 <Mutabah> A workaround is to copy (or symlink) to a known location
08:46:00 <clever> yeah, a symlink could solve that
08:47:00 <klange> You can also eliminate the path prefix by shoving it in -L
08:48:00 <clever> ahhh, `-L custom_symbol`, that solves pretty much everything
08:48:00 <klange> More like `-L my/stupid/dynamically/generated/path`
08:50:00 <klange> This is ld, after all - it's just interpreting your binary payload as a library to link with the "binary" bfd format handler, so it'll happily search for it in the `-L` path.
08:51:00 <clever> the man page says -L is `[-L symbolname|--localize-symbol=symbolname]`
08:52:00 <klange> Uh, what? -L is searchdir
08:52:00 <extern> why this Makefile generates all.o first... foo.o is the first target
08:52:00 <extern> https://paste.ofcode.org/wUJ4MgVv9Fa7rYpVHLhiBq
08:52:00 <bslsk05> paste.ofcode.org: Paste ofCode
08:52:00 <klange> There is no other -L in my local ld manpage...
08:52:00 <clever> not according to the man page in objcopy, https://linux.die.net/man/1/objcopy
08:52:00 <bslsk05> linux.die.net: objcopy(1): copy/translate object files - Linux man page
08:52:00 <klange> objcopy was not mentioned
08:53:00 <clever> ahh, i misread your original msg
08:53:00 <clever> ive seen nearly identical advice before, but with objcopy, to create a .o
08:53:00 <klange> objcopy _can_ change symbol names, so that's a viable next step - it can probably also take the 'binary' bfd input.
08:53:00 <clever> but your using ld -r, to create a .o
08:55:00 <klange> extern: Make doesn't care about the order of inputs.
09:09:00 <extern> klange: so what am i missing
09:11:00 <klange> Nothing in your Makefile imbues an ordering upon the creation of the three .o targets.
09:12:00 <extern> why the first statement that this Makefile is running is echo "int main() { return 0; }" > all.c
09:12:00 <klange> Why shouldn't it be?
09:12:00 <klange> Make only cares about dependency graphs.
09:13:00 <extern> foo.o is the first prerequisite that Makefile is checking which is not yet created
09:13:00 <klange> Why do you think it's first?
09:13:00 <klange> Because you wrote it first?
09:13:00 <klange> That doesn't matter.
09:13:00 <extern> yes..
09:13:00 <klange> Make doesn't care.
09:14:00 <extern> ok so why does it decided that all.o is created first
09:14:00 <klange> You have three leaf nodes in your dependency graph - the three C files - and Make will perform the rules to make those files in an indeterminate order.
09:14:00 <extern> it is determined order if on every run and on every permutation of 'objects' all.o is always created first
09:14:00 <extern> so there must be something to that
09:15:00 <klange> Indeterminate does not mean inconsistent.
10:27:00 <geist> also if you run make with any sort of -j option, it'll just do them in whatever order
10:27:00 <geist> but i guess they left
10:28:00 <klange> Must have been something I said.
10:28:00 <geist> well, you were being a bit harsh, but yeah
10:29:00 <geist> my take on precisely why it was doing all.o first is it built a graph and then either solved it from the bottom up, deepest nodes first
10:29:00 <geist> or it literally ran it backwards, like last thing added
10:29:00 <geist> though as yuo were pointing out it doesn't care
10:30:00 <geist> i have always meant to look into precisely how gnu make tracks things internally. is it a big tree? if so how does it choose to solve it?
10:30:00 <machinecode> Hi, are chrome apps really dead and do I make a Node or other server/game? I think I should use web tech. Asking here, because everywhere else is desolate.
10:31:00 <sortie> Unfortunately operating systems development is also dead
10:31:00 <klange> We're all dead, on the inside at least.
10:31:00 <geist> also we get to relive this hour in a few minutes
10:31:00 <klange> My magic eightball says you should invest in JPEGs.
10:31:00 <Affliction> brb, writing an OS with Electron
10:31:00 <sortie> It's all empty developers going through the motions of a Unix system with no light inside
10:33:00 <geist> all hail unix
10:33:00 <geist> at least until multics becomes retro enough
10:37:00 <machinecode> Gentlemen, install Debian 11 and then p0wn it. Trust me, I'm an android.
10:37:00 <machinecode> Also, vector interrupt table is a function struct between the kernel and bios.
10:38:00 <Affliction> Now my brain is working through the incredible amount of infrastructure required so the bootloader can start the kernel with an <iframe src="kernel.html" />
10:38:00 <sortie> Sir, this is a Wendy's
10:39:00 <machinecode> Not so fast. Node runs as a kernel.
10:39:00 <machinecode> real talk
10:40:00 <Mutabah> Overloaded terms
10:44:00 <machinecode> invisible bytecode
11:38:00 <Arsen> want a chuckle guys
11:38:00 <Arsen> https://ebpf.io/
11:38:00 <bslsk05> ebpf.io: eBPF - Introduction, Tutorials & Community Resources
11:38:00 <Arsen> >eBPF is a revolutionary technology with origins in the Linux kernel that can run sandboxed programs in an operating system kernel. It is used to safely and efficiently extend the capabilities of the kernel without requiring to change kernel source code or load kernel modules.
11:39:00 <Affliction> yeah, it really has caught on, hasn't it
11:39:00 <Arsen> a revolutionary technology! because linux is the first to invent bytecode!
11:39:00 <Arsen> Affliction: nah not even ebpf, I'm just laughing at the website
11:39:00 <Affliction> heh
11:40:00 <Affliction> That said, there are some fancy things that would be more difficult without it
11:40:00 <Affliction> I understand there are network cards that can run eBPF bytecode, for instance
11:40:00 <Arsen> I can understand why ebpf is handy, we even have something similar (https://github.com/managarm/managarm/blob/8250ae9110703e5db796011078d8d856b8119f3c/kernel/thor/generic/thor-internal/kernlet.hpp), and I'll be using it in the near future for some syscall filtering, but that website just hilariously overstates how innovative it is
11:40:00 <bslsk05> github.com: managarm/kernlet.hpp at 8250ae9110703e5db796011078d8d856b8119f3c · managarm/managarm · GitHub
11:50:00 <kingoffrance> yeah...bpf did not originate there
11:51:00 <Arsen> indeed
11:51:00 <kingoffrance> ebpf maybe, but "there is nothing new under the sun" "only old things we dont know yet" -- ambrose bierce :)
11:51:00 <j`ey> it's just marketing material :P
11:51:00 <Arsen> ebpf did yeah, but it's "just" bpf with a negative jump
12:34:00 <sikkiladho> is it possible in raspberry pi 4 to load two binaries and transition from one binary(at el2) to another binary(at1)?
12:35:00 <j`ey> i think the firmware loads a kernel and an 'armstub' (as they call it)
12:35:00 <j`ey> so you could do that
12:40:00 <sikkiladho> in the armstub, I have loaded Trusted-firmware-A. Can there be a way to load the standard kernel using initramfs configuration. https://www.raspberrypi.com/documentation/computers/config_txt.html#initramfs
12:40:00 <bslsk05> www.raspberrypi.com: Raspberry Pi Documentation - The config.txt file
12:41:00 <j`ey> well that seems to load to a specified address, so tf-a could know about that address I guess
12:43:00 <sikkiladho> let me explain: I have a simple hypervisor binary, which prints hello world to UART and should transition to standard kernel.
12:44:00 <sikkiladho> I load hypervisor with config, kernel=el1-hypervisor.img and it succesfully prints hello world.
12:45:00 <sikkiladho> this is flow. tf-a at el0 -> hypervisor at el1 -> standard kernel at el2
12:45:00 <j`ey> uh
12:46:00 <sikkiladho> I have a problem transition from hypervisor to standarad kernel.
12:46:00 <j`ey> el0 is the least priveleged
12:46:00 <j`ey> it's tf-a EL3 -> hyp EL2 -> kernel EL1
12:46:00 <sikkiladho> ooopsss
12:46:00 <sikkiladho> yess
12:46:00 <sikkiladho> you are right
12:47:00 <j`ey> the hypervisor needs to load the kernel off the disk
12:47:00 <sikkiladho> but if I load the kernel device tree kernel8.img using initramfs at some specified address
12:48:00 <sikkiladho> and in the hypervisor, I would eret to that address in el1 level, it should work.
12:48:00 <j`ey> yes that might work
12:49:00 <sikkiladho> I have tried it. But somehow transition from hypervisor to kernel doesn't happen. It is stuck after printing Hello World to UART.
12:50:00 <sikkiladho> https://github.com/SikkiLadho/Leo/issues/1
12:50:00 <bslsk05> github.com: Cannot transition from hypervisor el2_kernel.img to standard kernel · Issue #1 · SikkiLadho/Leo · GitHub
12:50:00 <j`ey> you should print the contents of the address the kernel is loaded at
12:50:00 <j`ey> you can try see if it loaded properly
12:51:00 <j`ey> sikkiladho: you arent setting the device tree anywhere
12:53:00 <sikkiladho> here's the config. https://github.com/SikkiLadho/Leo/blob/2e3b8e9e5339f3f544b4bd6d00c5ce4883ddf63c/raspberrypi_config.txt#L12
12:53:00 <bslsk05> github.com: Leo/raspberrypi_config.txt at 2e3b8e9e5339f3f544b4bd6d00c5ce4883ddf63c · SikkiLadho/Leo · GitHub
12:54:00 <j`ey> I mean before booting
12:54:00 <j`ey> before booting linux
12:54:00 <j`ey> when linux boots it needs the device tree of the rpi
12:56:00 <sikkiladho> so I am loading the device tree at some address using initramfs. el1-kernel.img is the device tree for linux.
12:56:00 <j`ey> that's a kernel, not a device tree?
12:57:00 <j`ey> or it has the device tree inside of it?
13:00:00 <sikkiladho> that's the kernel, usually kernel8.img. .dts is the device tree. It seems I am just loading the kernel at some address but I'm not loading the device tree? I'm really a beginner and trying to learn while building the project so bear me please.
13:01:00 <sikkiladho> * .dtb
13:07:00 <j`ey> yes, that's what im saying, you need a device tree too
13:13:00 <j`ey> you could load one like you did with initramfs
13:13:00 <sikkiladho> How can I set the device tree? We can also build a kernel with appended device tree.
13:14:00 <sikkiladho> So, I would first load device tree. and then following it, the kernel image?
13:14:00 <j`ey> yep
13:14:00 <j`ey> you can get a device tree from the linux kernel, or from the rpi firmware repo
13:14:00 <sikkiladho> Let me try it right now.
14:19:00 <sikkiladho> j`ey: won't it be easier to merge the device tree with the kernel image so that device tree comes first. and load it as a signle image?
14:21:00 <j`ey> you could do that, make sure you pad the end of the DT
14:21:00 <j`ey> so the kernel is aligned properly
14:26:00 <sikkiladho> j`ey then we will have to build kernel using CONFIG_ARM_APPENDED_DTB=y https://cateee.net/lkddb/web-lkddb/ARM_APPENDED_DTB.html
14:26:00 <bslsk05> cateee.net: Linux Kernel Driver DataBase: CONFIG_ARM_APPENDED_DTB: Use appended device tree blob to zImage (EXPERIMENTAL)
14:26:00 <sikkiladho> would it be necessary
14:27:00 <j`ey> thats a 32-bit option
14:27:00 <j`ey> you have a 64-bit kernel
14:28:00 <j`ey> (so you cant use it)
14:29:00 <sikkiladho> Thank you.
14:33:00 <sikkiladho> about alignment, kernel is 8-byte aligned. I have to add the padding in a way, that [size of dtb + padding] is divisible by 8. right?
14:34:00 <j`ey> no, the kernel address should be 2MB aligned
14:39:00 <j`ey> SikkiLadho: you can look at Documentation/arm64/booting.rst in the linux repo
14:40:00 <sikkiladho> Thank you. I am looking into it.
20:02:00 <ad__> hi, brief question you may know: calling an assembly func as "void func() " that is func: bx lr
20:03:00 <ad__> (arm of course) but systyem does not return, why ?
20:04:00 <GeDaMo> You're calling an assembly language function from C?
20:04:00 <GeDaMo> Doesn't bx switch between ARM and Thumb mode?
20:05:00 <j`ey> GeDaMo: if the lsb of the function addr is set
20:08:00 <ad__> GeDaMo, yes, calling from C.
20:08:00 <zid> also you mean void func(void);
20:08:00 <zid> () means unspecified number of arguments, (void) means no arguments
20:08:00 <ad__> yes ai am testing just a void func(void);
20:09:00 <zid> what does your debugger say happens?
20:09:00 <ad__> actually cannot use it, running on embedded board
20:09:00 <j`ey> ad__: does the asm save lr?
20:10:00 <ad__> j`ey, mm i am calling the function from C, supposing yes
20:10:00 <GeDaMo> What should happen in the C program after func returns?
20:10:00 <j`ey> ad__: is this your code?
20:10:00 <ad__> i call a printf
20:11:00 <heat> printfs are more complex and it's possible you're corrupting the stack
20:11:00 <GeDaMo> Can you show your whole program?
20:11:00 <zid> ideally you'd have 'turn off LED with mmio' f(); 'turn on LED with mmio' :P
20:12:00 <GeDaMo> Does printf work before calling func?
20:12:00 <ad__> mm the whole program is u-boot i am modifying, so not small. Btw, what i do is:
20:12:00 <ad__> yes printf works before
20:12:00 <ad__> so i di:
20:13:00 <ad__> from c : extern void _func(void); printf("before call\n"); func(); printf("acter call\n");
20:13:00 <ad__> in assembly i just do
20:14:00 <ad__> .pushsection ._special.text, "ax"
20:14:00 <ad__> .globl _func
20:14:00 <ad__> bx lr
20:14:00 <ad__> .popsection
20:14:00 <ad__> _func:
20:14:00 <zid> blexr.
20:14:00 <heat> please use gists/pastebins
20:14:00 <zid> My favourite instruction
20:14:00 <j`ey> ad__: comment out the func call, do you see the 'after' message?
20:15:00 <ad__> yes
20:15:00 <j`ey> objdump uboot, is it getting the right address for func?
20:15:00 <zid> and what does the callsite look look
20:15:00 <zid> look like*
20:15:00 <ad__> ok i can objdump and see what it would do
20:16:00 <zid> *proceeds to paste the entire disassembly of uboot to irc*
20:19:00 <heat> pasting code to irc is based
20:47:00 <Ameisen> wleslie: since everyone likes the 68k
20:47:00 <Ameisen> so making a 64-bit 68k workstation would be fun
20:47:00 <Ameisen> as said, there does appear to be _one_ kind of 64-bit 68k (the 68080), but it's only really distributed in a form meant for Amigas
20:47:00 <Ameisen> and I'm not sure what Amigas are doing with a 64-bit chip
21:15:00 <Maka_Albarn> IT'S BACK!!!
21:49:00 <wleslie> cool I guess. I did look recently at m68k prices online as I'd love to upgrade my LC to have an MMU; they are still several hundred dollars new, unfortunately
21:53:00 <wleslie> my intuition (which may not be very good) is that people like the m68k because it was reasonably popular and there's plenty of software for it, but the ISA itself is mostly nothing special and has a lot of inconveniences
22:16:00 <geist> oh i dunno, i kinda enjoy working with 68k
22:17:00 <zid> yea I thought the consensus is that 68k is nice
22:17:00 <geist> at least if you're into older stuff it's one of the nicer older things to work with
22:17:00 <zid> pretty clean and orthogonal and 'modern' ish
22:17:00 <geist> yah
22:17:00 <geist> and kinda 386 level complexity in terms of mmu/etc (though cleaner designed) so it's a bit of a 'powerful retro' feel to play with
22:18:00 <j`ey> geist: https://twitter.com/olofj/status/1454536954180030465
22:18:00 <bslsk05> twitter: <olofj> Modern OS on legacy hardware requires patience. https://video.twimg.com/ext_tw_video/1454536892515438593/pu/vid/720x1280/M_Fcwuc97liuvQ-f.mp4?tag=12
22:19:00 <geist> yah i got a fairly modernish copy of netbsd on this microvax here and it's definitely an exercise in patience
22:21:00 <geist> wleslie: re 68k do you mean on some sort of card? I managed to buy a few 68030s off ebay fairly recently (3 or 4 months ago) and they ended up about $20 a piece
22:35:00 <Ameisen> IIRC, you cannot use 68060s with macs because of missing instructions?
22:37:00 <geist> that'd be my guess yeah