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=osdev&y=19&m=8&d=4
05:13:13 <klys> i would code but i'm lying down and it'd kink my neck to look at the screen that long... =)
05:14:37 <klys> so I have this abdroid fablet, not so easy to dev for.
05:14:53 <klys> android*
05:18:33 <klys> would be nice to have a cintiq pro, though they're pretty expensive i guess
06:20:31 <klys> i'm pretty stuck on wanting an ips 1920x1200 24" display. reason 1) 96 dpi standard, reason 2) 384x240, 25 of them, reason 3) most led things aren't ips yet. con) there's no stylus.
06:21:49 <Mutabah> Dell make/made a pretty darn good one
06:22:44 <klys> yeah, think i've run across some for ~200.00
06:23:34 <Mutabah> U2412M (I have two, got them cheap a few years ago)
06:24:50 <klys> as far as reason 2) goes, I was trying to pull 1152x864 (3x3), except crts are going for 100.00 now.
06:26:16 <klys> as for the neck thing, there are some fancy adjustable mounts available
06:28:15 <klys> and about the stylus, perhaps a light pen is available
11:25:43 <squaremelon> it seems Xscale based processors may have similar debug facilities
11:26:07 <squaremelon> embedded ice with DCC debug channels and trace buffers
11:28:38 <squaremelon> and the thing with loops on i486 is that: the risc opcodes from cisc are stored in the prefetch cache, which will accelerate stuff, indeed there is an amd patent about this
11:29:00 <squaremelon> pre-decoded presentation of variable length cisc instructions
11:29:56 <squaremelon> on i486 when it finds out that it uses memory operands then operand fetch is redirected via segmentation unit to data cache
11:30:17 <bcos_> klys: I wonder if you can buy some kind of spring loaded arm support, so the arm holding the stylus (that's extended out to the monitor) doesn't get sore and fall off after 2 minutes
11:30:34 <squaremelon> and it very much seems that branches are async too, so it looks like even i486 and xscale stuff can be accelerated quite a bit
11:30:46 <klys> bcos_, cool idea dude
11:36:07 <squaremelon> Otherwise i am unsure why the branches would be said to behave as zero-cycle delayed
11:43:54 <squaremelon> I vaguely remember the 486 dx2 days, docs say this one also has a floating point unit, i was 10years old back then did not know much about programming and used floppies to copy games to play
11:44:26 <squaremelon> microsoft systems on the other hand namely 95 and 98 windows releases however worked solidly there
11:46:43 <squaremelon> i remember those CPUs as very solid even on video formats on the web, uncompressed formats like mpeg1-2 and such maybe
11:47:08 <squaremelon> all in all pentium II and 486dx2 was good experience
11:47:37 <squaremelon> dad bought those machines, they cost fortune too back then though
11:52:48 <squaremelon> I was constantly worried about needing more computer time to make faster progress, but was oftenly exausted caus of training back then, so i also needed a laptop, but most of estonia did not even have desktop those days when i started
11:53:37 <squaremelon> hence it also seems i am reasonably experienced compared to late starters and smartphone users of today
11:59:53 <squaremelon> Well i still even with my all paranoias present about how stupid mankind can be, do not see major troubles with all the worlds hw arsenal, it just it requires proper work to be done quite so much from sw side
12:00:54 <squaremelon> generally there is still very much left to be done around different hw optimizing
12:09:16 <squaremelon> and when talking about new arch as stanford GENESIS 2 based garnet and such, those look to be as sane as possible to me, it has static tile scheduler and missing arbiters, the last ones which i'd like to add
12:10:01 <squaremelon> i am not sure if noculated versions are good for deterministic placement into the tiles for later execution on chip
12:10:35 <squaremelon> but the arbiter similar to miaow is not very difficult to be added
12:20:02 <nova99> Hi, I tried to perform full disk encryption on an arm linux install and failed. It seems there is no easy way to do it at the moment unlike desktop linux distros.
12:20:41 <nova99> I was wondering if I could get away with encrypting just the home directory post-install. I'm sorry if this is not the right place to ask.
12:21:03 <Mutabah> It's not the right place to ask - maybe ask in ##linux?
12:21:30 <nova99> Ok, sorry. I'll go there.
12:21:49 <nova99> exit
12:39:27 <squaremelon> but i even think the dynamic scheduling is also easily done with just adding memory tiles colliding the PE tiles and branching in hw, you can add software commands to parse the cache and ridrect anything on chip
12:40:37 <squaremelon> procedure is just that you map some functional units as from a sceleton bitstream, then parse memtiles to redirect them minor logic, can be coded arbitrarily instead of hw fixed
12:41:20 <squaremelon> so basically i do not think they can not do it, but rather left it out cause sw based schedulers are more flexible
12:51:54 <aalm> .theo
12:51:55 <glenda> You bought some plastic.
12:52:58 <squaremelon> I think the procedure which i described for checksummed buffers can be much more flexible controller from sw side though in hw
13:08:30 <squaremelon> i have final issue to cover how the comparator is implemented for binary numbers in hw, since some gpus do not have bitwise ops
13:08:46 <squaremelon> CMP instruction that is and SLT and those
13:09:16 <aalm> .theo
13:09:16 <glenda> Yeah, you sure are the cool dude.
13:30:23 <squaremelon> 2.5 + 1.5 + 4= 8 gate delays, pretty slow, i do not like the comparison stuff to be done
13:30:44 <squaremelon> this is for parallel prefix tree comparator
14:37:00 <j`ey> I installed qemu-aarch64. it doesnt seem to support the -M option that I have seen mentioned
14:37:24 <j`ey> and the help says: "Linux CPU emulator (compiled for aarch64 emulation)".. do I have the right build of qemu?
14:38:03 <zid> what is -M
14:38:23 <j`ey> apparently it's how you set the 'machine'
14:38:29 <zid> no that's -machine
14:38:32 <j`ey> Ive seen people suggest -M virt
14:38:48 <zid> might be an alias, i'd have to check
14:39:48 <j`ey> it also doesnt support -kernel
14:39:56 <j`ey> (qemu: unknown option 'kernel')
14:39:59 <zid> aarch64 isn't good enough to run kernels ;P
14:41:04 <j`ey> heh
14:42:04 <zid> anyway, best guess is that someone configured your ./configure weirdly
14:42:38 <j`ey> I may build it myself, if I find out that it was
14:43:34 <zid> there's a vhost-kernel configure option, no idea what it does
14:43:52 <zid> might be worth finding the getopt code in qemu itself
14:50:12 <j`ey> oh hm, I have qemu-aarch64 and qemu-system-aarch64
14:50:26 <j`ey> now Im confused what the difference is
14:50:44 <zid> I knew but forgot, I think it's whether it's running a kernel or a program
14:52:05 <j`ey> ok, I want the -ssytem version
15:17:19 <geist> j`ey: yes you want to use -system
15:17:29 <geist> the -system version emulates a machine, a 'system'
15:17:55 <geist> the non system one is for user space emulation, where in some cases you can run a arm64 (or other arch) for linux
15:18:01 <geist> it's basicallt a user space emulator
15:18:33 <j`ey> yeah. Im making some progress
15:18:38 <j`ey> not much. but it shows a QEMU window now
15:19:04 <geist> note that graphics on qemu-system-arm* is not nearly as straightforward as PC
15:19:13 <geist> since there's no 'standard' framebuffer for arm
15:19:33 <geist> but for getting code running, doing serial io, it's quite straightforward
15:19:49 <geist> the 'virt' machine emulates a single pl011 serial port, which is an ARM standard serial. can get docs to it
15:20:01 <j`ey> yeah, Im just trying to get it to exeucte a brk first :P
15:20:08 <geist> word.
15:20:38 <j`ey> cos I guess my build system stuff isnt setup yet
15:20:48 <geist> i usually start with -nographic
15:21:05 <geist> which then doesn't try to start a window, and you can get into the qemu monitor with ctrl-a c
15:21:27 <geist> https://github.com/littlekernel/lk/blob/master/scripts/do-qemuarm#L75 for some hints
15:21:29 <j`ey> the PC is at 0x200
15:22:07 <geist> potentially. memory starts at 0x4000.0000 for machine virt for arm*
15:22:19 <geist> but i think it may punch out a teensy 'rom' to branch into the code
15:22:40 <geist> as in the cpu emulation i believe may start in a little 10 instruction or so sequence before branching into your code
15:22:54 <j`ey> at least that's what info registers told me
15:23:23 <geist> if you stopped it right away (-S i belive) then that's potentially correct
15:23:27 <geist> i forget precisely the details
15:23:40 <geist> but the first 64K or so of address space on the virt machine is i believe 'rom'
15:24:12 <geist> anyway, made it into UK. had tea, going to go out and about and wander a bit
15:24:19 <j`ey> oh, welcome
15:24:27 <j`ey> wanna meet up and help me get this runnng? :P
15:25:16 <geist> hah, if you'd like
15:25:28 <geist> i literally have the rest of the afternoon and most of tomorrow to just futz around
15:28:38 <geist> you almost have it working, it's pretty straightforward
15:28:49 <geist> simplest thing you can do is just feed it a .bin file with a single instruction in it
15:29:02 <geist> oh... i just remembered (brain is still foggy from travel)
15:29:07 <geist> 0x200 means it *did* run your brk
15:29:26 <geist> 0x200 is the exception vector offset for the synchronous exception that brk will trigger
15:29:56 <j`ey> I was expecting some kind of output message!
15:30:10 <j`ey> I guess that Im meant to register some exception vectors myself eventually?
15:30:12 <geist> nope. it's a cpu emulation. BRK is just another instruction
15:30:18 <geist> no reason for the emulator to tell you
15:30:24 <geist> but here's a fun thing: run with -d int
15:30:35 <geist> it'll dump a debug message on every interrupt (or exception)
15:30:44 <geist> and yes, you want to register your own vectors
15:30:55 <geist> replace your brk with a jmp . and you can validate that it made it into your code
15:31:08 <geist> by startin git, breaking into it (ctrl-a c) and then dumping the state of the cpu (info registers)
15:31:12 <geist> rejoice
15:32:03 <j`ey> I got a continuous stream of: Taking exception 1 [Undefined Instruction]
15:32:33 <j`ey> ESR 0x0/0x2000000 ELR 0x200
15:33:15 <geist> yep. there ya go!
15:33:36 <geist> the very first one might have an ELR of your instruction
15:33:47 <j`ey> I havent yet worked out with ELR is :P
15:33:56 <j`ey> or ESR
15:34:05 <geist> then it gets stuck in an exception loop. tries to deliver exception, then faults probably ecause the instruction at 0x200 is another brk, then a loop
15:34:07 <j`ey> with just an infinite loop, the PC seems to be at 0x248
15:34:25 <geist> there is no equivalent of triple fault on arm64 so it's just stuck in an exception loop
15:34:28 <geist> grats
15:35:07 <geist> ESR = exception syndrome register. a bit field encoded register telling you what the exception is (break, page fault, undefined instruction, etc)
15:35:25 <geist> ELR = exception link register. where PC is saved when it delivers an exception
15:35:47 <j`ey> can qemu disassemble for me?
15:35:52 <geist> no
15:36:11 <geist> you can stop it and inspect memory yourself houthg
15:36:20 <geist> though, so it should be easy to verify
15:36:26 <j`ey> 0000000000000248: 0x14000000
15:36:45 <geist> it's garbage most likely
15:36:54 <j`ey> that seems to be what is in my binary
15:36:55 <geist> that is almost assurednly not a 'real' instruction
15:37:14 <j`ey> Im confused why I cant get llvm's objdump to dump aarch64
15:37:20 <geist> remember < 0x4000.0000 is not where you can load
15:37:32 <geist> you need to link your code to run up there
15:37:45 <geist> do *not* assume that memory starts at 0, like it generally does on PC
15:37:57 <j`ey> let me rebuild
15:38:35 <j`ey> rebuilt with changing my linker script: 0000000040000048: 0x14000000
15:39:06 <zid> oh geist is here
15:39:10 <zid> I missed my chance to swoon
15:39:11 <geist> get a functional dissassembler
15:39:27 <geist> but that's almost assuredly just plain data
15:39:42 * geist presents the ring
15:40:00 <j`ey> geist: my objdump shows that as the start of my main
15:40:26 <zid> geist: Not sure if we're getting married or you're mooning me
15:40:56 <j`ey> 40000048: 00 00 00 14 b #0 <main>
15:42:11 <geist> j`ey: ah, kay then
15:42:24 <geist> guess that is an instruction
15:42:35 <zid> I've heard of b before
15:45:40 <j`ey> b for 'add'
15:45:57 <zid> b is for add!? I think your children's picture book has some mistakes
15:50:36 <j`ey> neat, got some output from the pl011
15:51:44 <geist> woot
15:51:53 <geist> yah 'b' is branch
15:52:26 <zid> I thought it was for bounce
15:53:18 <zid> (I didn't)
15:55:32 <geist> cheeky monkey
16:16:28 <Ameisen> It's difficult to build freebsd on linux
16:16:33 <Ameisen> I'm not entirely sure why I'm doing it
16:36:06 <arjob89> I am building a Real Mode Operating System. I have completed just the bootloader and the 2nd stage loader is in the making. I want this OS of mine really be a system that I can work with.
16:37:14 <arjob89> I want to write applications for it and 10 years down the line, I want use it as a system I can really work wih.
16:40:14 <arjob89> However, with the inexperience as I have with developing an OS. I am little confused as to how the memory model it should be. Should I go by the small memory model of DOS, where all the segment registers DS = SS = CS, or should I build one where all the segments are independent.
16:41:32 <arjob89> Because it will clutter he chat here, I have a gist link to the white paper (so to speak}. I would like to know your thoughts.
16:41:41 <arjob89> https://gist.github.com/coderarjob/f69d56b4d89a9cf26b86d173add9df45
16:41:49 <bcos_> In 10 years BIOS will be dead and your system will be unusable; and the idea of a "usable system" in real mode (where a tiny photo of your butt consumes 10 times more memory than you can access) is ludicrous.
16:42:28 <j`ey> cant UEFI boot into real mode?
16:42:35 <arjob89> I do not intend to use bios calls.
16:43:09 <bcos_> My advice is to spend the time learning how to use 64-bit long mode (especially if you don't intend to use BIOS functions, which are the only real reason to use real mode)
16:43:25 <arjob89> I will have UEFI. But still a real mode OS.
16:43:52 <bcos_> j`ey: No. In theory you can switch from long mode back to real mode (if UEFI left any free RAM in that area)
16:44:08 <bcos_> ^ after you've booted
16:45:39 <arjob89> I do not want to build a 64 bit system for now. I know no one in their right mind will program a real mode OS. But that's what I want. I want to get my feet grounded and learn the old concepts before moving on to new shiny stuff.
16:46:13 <j`ey> "new"
16:46:26 <bcos_> arjob89: Other than not being able to use any modern compiler, not being able to use 99% of your RAM, not being able to use 87.5% of your CPUs, not being able to use basic things like timers (HPET now that PIT is dead) or any PCI device; what "benefits" do you think there will be in using real mode?
16:46:26 <arjob89> Newer
16:48:23 <bcos_> ..whatever those "old concepts" are; you can still implement them in without real mode
16:51:02 <arjob89> It is difficult to present a use case. Think of it like a tribute to the DOS days. In time I will change my ways and upgrade to protected mode or real mode.
16:51:42 <zid> or you could not bother :P
16:52:10 <bcos_> Given that modern UEFI firmware comes with more features than DOS did; I don't see any point wallowing in trash that was discarded decades ago before you start writing an OS
16:52:27 <arjob89> It is my start not the end of the journey. I like deal with obsolete technology, and understand why it became so.
16:53:47 <bcos_> So.. 10 years of "standing next to the swimming pool while being afraid to get wet" before you never write an OS? Great...
17:03:48 <bcos_> arjob89: I know I sound harsh; but I've played this game before. The fact is that the more time a person spends going down that pointless path the more "loss aversion" ( https://en.wikipedia.org/wiki/Loss_aversion ) effects them. Usually they never escape (usually work, spouse, kids, ... comes along and their goal of writing an OS dies).
17:04:27 <squaremelon> I was seeing horror dreams, I guess i needed something to laugh about, funny is especially bcos_ comments, but little bit the other guy too.
17:04:32 <zid> If you want obsolete use a gameboy or something
17:04:38 <zid> at least it isn't a moving target
17:07:14 <arjob89> Guys it is a hobby project - to build a usable real mode OS. If I wanted to build anything else I would have. It seems everyone is trying to save my soul.
17:07:31 <j`ey> arjob89: yes. good point. do what you will have fun with!
17:07:38 <zid> you *did* come here to argue though
17:07:43 <zid> so don't be too surprised :P
17:09:40 <squaremelon> I was quiet since i do not like to humiliate people who do not diserve it anyways or just start flaming, though i find such needs to suffer a bit funny
17:14:30 <squaremelon> and i think real mode should not work highly well for doing anything useful, i understand the memory it can target is in bytes this time
17:14:50 <squaremelon> it is just 2 in power of 16 probably
17:15:46 <squaremelon> so in some think kb's then
17:17:02 <squaremelon> the more important was that anything for compiling won't work out nicely
17:28:35 <squaremelon> I have my fresh meds in my ass and i fell to sleep, i should finish optimizing the procedure/routine , maybe that is not possible to do without bitwise ops
17:31:28 <squaremelon> currently i woke from horror, and it almost may seem, additional cache is needed but those values in lines apply to all programs and do not need to be context switched out
17:36:20 <squaremelon> sign bit is something to yet research, on ones complement there is +0 and -0 , two's complement has highest bit for the sign
17:46:57 <squaremelon> those are modifiers on gpu isa, however there maybe a method to flip a sign and get away with quite fast
18:04:41 <squaremelon> now i can not put this into words without embarrassing myself, however it needs to subtract from power of two with all less significant bits enabled, this would get to a hole size
18:05:13 <squaremelon> by rounding to closes power of two with other bits that are smaller all toggled
18:18:54 <geist> hello my Estonian friend
18:20:14 <squaremelon> hello. well anyways sign bit can be handled all bits in is -1, when the subtracter does not have highest bit in
18:20:27 <squaremelon> the chip can handle such case with masks
18:25:03 <squaremelon> i gotta look it would be very sane thing to do imo in hw design to save cycles, and very likely they do this this way
18:33:45 <squaremelon> yeah it appears to be so: neat
19:10:42 <squaremelon> i got tired, but very much seems i had talked about it before and it works, but back then i was on stronger meds, and inconsistent abit. some turkey uni info http://eem.eskisehir.edu.tr/egermen/EEM%20232/icerik/Week%206%20Arithmetic%20Functions.pdf
19:12:45 <aalm> .theo
19:12:45 <glenda> Pick a damn position, and declare it.
19:17:00 <squaremelon> aalm: it is on page 32
19:17:05 <heat_> .theo
19:17:05 <glenda> It ends badly.
19:17:12 <heat_> spoiler alert glenda!
19:17:28 <aalm> .theo
19:17:29 <glenda> That's nice.
19:17:56 <aalm> squaremelon, i thought it was 42
19:18:46 <aalm> but, tbh. i don't care :]
19:21:25 <heat_> .theo
19:21:25 <glenda> I believe something is not being understood here.
19:26:19 <zid> sigh, can we *not* talk to the mental patients as though they are people
19:29:49 <heat> .theo
19:29:49 <glenda> Why???
19:36:30 <squaremelon> zid: same goes to shithoses like you
19:37:17 <squaremelon> so the final algorithm is very easy, as the subtract operations are fast on
19:37:36 <squaremelon> twos complement, all that needs is -2 and compare to zero in the end
19:40:28 <squaremelon> i prefer not to practice anymore talking to future dead people indeed, so long dead shithose.
19:56:38 <j`ey> when building my arm64 kernel.. how do I know what load address to put in the linkerscript?
19:56:54 <j`ey> is there a valid address for all CPUs/things
19:56:58 <geist> nope
19:57:18 <j`ey> ok, so if you were to build it for a specific computer, itd need to change?
19:57:23 <geist> well, it's more complicated. basically once you get mmu up and running you can pick the address to link the binary to
19:57:35 <geist> ie, something like 0xffff.ffff.0000.0000
19:57:43 <j`ey> you mean the virtual address?
19:57:53 <geist> early on when you're not messing with the mmu you have to just know the right address for the machine you're on
19:58:06 <geist> but once you have gotten far enough along you can link it to a consistent virtual address
19:58:16 <j`ey> right
19:58:19 <geist> but then you still have to handle being loaded to essentially 'random' physical addresses
19:58:41 <geist> but that usually means some assembly at the beginning of the code that sets up the page tables and gets you into virtual address space
19:58:49 <geist> not too much unlike setting up page tables on x86
20:00:18 <j`ey> I found this https://github.com/qemu/qemu/blob/master/hw/arm/boot.c#L37
20:00:30 <johnjay> qemu rears its head once again
20:01:01 <geist> j`ey: yes, if you trace through that code it's basically used when it has no other info to go on
20:01:15 <geist> ie, you give it a raw .bin file, it has no other way to know where to load it
20:01:21 <geist> so it loads it at that offset into main memory
20:01:33 <j`ey> ah
20:01:40 <geist> which mean sin practice it'll put your code at 0x4008.0000 physically
20:01:53 <zid> and on a real machine that might just be 'where the rom is mapped' or something, which you might well know in advance
20:01:58 <j`ey> I was trying to find out where the 0x40000000 number you gave came from?
20:02:17 <geist> j`ey: it's in another spot. where it defines the VIRT machine
20:02:29 <johnjay> can we write 4000:0000? or is that something else
20:02:30 <geist> hw/arm/virt.c maybe? i dont have the code in front of me
20:02:47 <geist> but basically it has at the top of the file the memory map for it
20:03:10 <geist> https://github.com/qemu/qemu/blob/master/hw/arm/virt.c#L117
20:03:58 <j`ey> ah line 145
20:04:12 <geist> johnjay: hmm?
20:05:52 <geist> when just getting started, it's usually much simpler to just compile your kernel for a particular machine, with particular offsets compiled into it, etc
20:06:11 <geist> but later on a true multi machine kernel (on arm) requires a fair amount of dynamic detection of stuff
20:06:30 <geist> PC is a little simpler with memory detection sinc eyou can usually get away with assuming that there's memory free at 1MB or 16MB or so
20:06:37 <geist> up till at least the size of your kernel
20:06:46 <geist> essentially there's only one x86 'machine'
20:07:21 <j`ey> I was starting with x86.. but decided to switch to arm64
20:07:26 <j`ey> think it will be a little more helpful
20:08:41 <geist> yep
20:09:08 <geist> we're dealing with it a lot in fuchsia since we're trying to have a single kernel image for all arm64 machines
20:09:30 <geist> but it means having to deal with among many things having the kernel be physically relocatable
20:09:48 <geist> ie, wherever you load it in physical space it tries to run from by dynamically constructing a page table to map it where it landed
20:10:16 <j`ey> that helps you from having to do lots of different arm64 builds?
20:10:33 <geist> right
20:10:47 <geist> and since most of the drivers are user space, it can choose which ones to load
20:10:50 <geist> at runtime
20:13:36 <heat> geist: oh right, I have a question about arm64
20:13:45 <j`ey> I need to setup a stack now
20:13:46 <heat> why did you go with UEFI for arm64 as well?
20:13:53 <geist> why did i?
20:13:59 <j`ey> I think that's one of the reasons my debug kernel wont work
20:14:02 <geist> i had no input into that
20:14:05 <heat> you = fuchsia folks
20:14:12 <geist> heat: we haven't
20:14:17 <heat> you haven't?
20:14:27 <geist> well, i mean there are some arm machines with uefi, and some without
20:14:39 <geist> we have to eventually support them all, so for ones that have uefi we need a boot method
20:15:29 <heat> ahh okay thanks
20:15:34 <geist> but actually the uefi arm support doesn't currently work, ostly because there's not a good platform to test with right now, but i will eventually get to it
20:15:53 <geist> our uefi bootloader (gigaboot) is fairly trivially portable to arm and i have it working in a branch
20:16:09 <geist> managed to boot the kernel on a uefi arm machine, but haven't mainlined it yet
20:16:27 <heat> Also how do you recommend booting in arm64(qemu's virt machine)?
20:16:37 <geist> using -kernel
20:16:58 <heat> I've tried -kernel but it doesn't pass me the dtb
20:17:00 <geist> note you can get a uefi rom image for the virt machine and it does work
20:17:12 <geist> heat: it should, i think it's inone of the registers
20:17:40 <heat> geist: from what i've searched, it doesn't pass the dtb when it's a regular elf image
20:17:58 <geist> oh that may be true
20:18:16 <geist> or that may be one of the handful of local patches we have on our qemu tree
20:18:24 <geist> which we need to upstream, but no one has gotten around to it
20:18:52 <geist> haven't looked at that in a few years, but i can work
20:19:01 <geist> otoh, i think we switched to loading a .bin file anyway
20:19:22 <geist> since we didn't want to have to have a separate elf kernel image for just running on qemu. should be the same .bin for all platforms, etc
20:19:27 <geist> and none of the other platforms use elf
20:19:47 * j`ey unsure how to use .skip with arm64
20:20:01 <geist> try and see
20:20:13 <geist> also get your disassembler working
20:20:26 <geist> required tool, full stop, make it go before making any further progress
20:20:32 <geist> or you're just flying blind
20:20:47 <j`ey> I got objdump working
20:20:48 <heat> geist, ooooh, like wrapping an elf64 file in a .bin with bootstrap code at the start of it?
20:20:50 <geist> good
20:21:00 <geist> heat: or any number of ways
20:21:05 <j`ey> it turns out you cant put a comment on the same line as the .skip
20:21:33 <j`ey> yay, the stack works, so my debug-built kernel works
20:21:37 <geist> j`ey: also make sure the stack is 16 byte aligned. must always be 16 byte aligned on arm64
20:21:46 <geist> .balign 16 or .align 4
20:21:50 * heat hasn't used anything except elf64 cuz x86
20:22:21 <geist> heat: the -kernel logic is a little different on the different arches, but in general you can get a flat bin into memory much easier than anything else
20:22:44 <geist> loading an elf is nice if it works, but its one of those things that's not really worth spending too much effort in, since most *real* loaders on real hardware dont do ELF
20:23:06 <j`ey> hm, I have .align 16
20:23:12 <heat> hmmm
20:23:19 <heat> how does virt know where to load the .bin?
20:23:20 <geist> that's probably too much, though it's safe anyway
20:23:28 <heat> Since virt isn't a real machine
20:23:36 <geist> on arm?
20:23:42 <heat> yeah
20:23:50 <geist> (there are 'virts' for other platforms, just being clear)
20:23:55 <geist> fixed address
20:23:59 <geist> there's no multiboot outside of x86
20:24:01 <heat> does it also have a default load address like real hardware?
20:24:02 <heat> ah okay
20:24:08 <geist> that's the 0x80000 thing that j`ey linked a while ago
20:24:18 <geist> basically 'start of main memory bank + 0x80000'
20:24:34 <heat> actually I think grub2 and multiboot2 work on arm64
20:24:34 <geist> 0x8000 or 0x80000 is a semi standard for linux arm things, for reasons lost in antiquity
20:24:51 <geist> i've seen it show up on multiple loaders on multiple arm socs
20:25:19 <geist> the general idea is the loader (grub, coreboot, etc) put the DTB in front of the kernel, then the kernel afterwards aligned on this boundary
20:25:26 <geist> for fairly arbitrary purposes
20:25:49 <geist> for memory allocation purposes in thebootloader it is i guess just simple to do
20:26:23 <geist> iirc, RPI loader does exactly the same thing. kernel is defaulted to be 0x8000 or 0x80000 into main memory
20:26:48 <geist> i think 0x8000 (32k) was the legacy address and i think someone copy-pasted it and i've seen it be 0x80000 (512KB)
20:27:04 <geist> it shouldn't matter, except it tends to be a number i've seen again and again in multiple loaders so it's kind of defacto
20:27:47 <geist> my guess is someone a long time ago thought 32KB was enough space for the DTB, then at some point it grew and someone just added another 0 to it and now it's 80000
20:28:02 <heat> just to be sure, in real hardware would I be stuck with whatever bootloader the manufacturer decided to flash in rom?
20:28:05 <j`ey> pretty reasonable
20:28:11 <geist> heat: mostly
20:28:30 <geist> UEFI is a standard that ARM is trying to push everyone to use, but i dont think it's getting a lot of uptick outside of ARM server space
20:28:35 <geist> where it's mandated
20:28:48 <geist> (ARM server base specification or something like that)
20:29:05 <heat> yeah
20:29:07 <j`ey> also the EBRP
20:29:08 <heat> ACPI also
20:29:10 <j`ey> or something
20:29:25 <geist> most random ARM socs are still using either uboot or some hand rolled thing. Qualcomm seems to be moving towards uefi, but of course it's either own hand-rolled, proprietary, buggy implementation
20:29:45 <geist> s/either/their
20:30:33 <geist> but all is not lost, for the low level power management stuff ARM has specified a thing called PSCI (power state something interface) that does seem to be getting uptick
20:30:45 <geist> virtually all socs implement it (except the broadcomm cpus in raspberry pis)
20:30:55 <geist> and that greatly simplfies things like booting secondary processors
20:31:32 <j`ey> geist: trying to find some docs where .align N == 2^N
20:31:51 <heat> I think it's the oposite
20:32:08 <heat> .balign N = .align 2^N
20:32:31 <geist> heat: fairly certain that's not the case, the b stands for byte
20:32:32 <j`ey> I meant .align N, means 2^N byte alignment
20:33:22 <zid> I accidentally crashed nasm doing that once
20:33:30 <zid> wrote align 32 and it thought I meant 4GB
20:33:36 <heat> https://sourceware.org/binutils/docs/as/Align.html#Align
20:33:40 <heat> it says it's the same thing
20:34:17 <heat> waiiiit, it doesn't do that for arm
20:34:25 <heat> for arm it's actually 2^n
20:34:27 <heat> so you're right, my bad
20:34:50 <zid> yea .align is "whatever assembler we're emulating did" apparently
20:35:04 <heat> geist: Does anyone use ACPI in arm space?
20:35:26 <j`ey> "The end of the file was unexpectedly encountered" thanks objdump :|
20:35:43 <heat> sounds like your file was truncated
20:43:42 <j`ey> I wonder if qemu checks the stack slignment
20:43:54 <j`ey> SP=0000000040001461, seems like it doesnt?
20:44:24 <geist> heat: yes
20:44:24 <mrvn> j`ey: that's fine if you don't use it.
20:44:40 <geist> in fact qemu virt also has a pointer to the ACPI tree in the DTB
20:44:55 <geist> i haven't actually looked at it, but if you boot linux on it you can do a acpidump
20:45:06 <geist> j`ey: yah it doesn't tend to, unless you're running on KVM (real hardware)
20:45:07 <j`ey> mrvn: I think I am, lemme check the disassembly again
20:45:31 <geist> and the stack alignment exception is i believe needed to be enabled. may or may not be by default
20:45:42 <geist> i believe it's a bit in the SCTLR
20:46:03 <mrvn> j`ey: only a few things on x86 care about stack alignment. Bad alignment makes things slower only mostly.
20:46:19 <j`ey> mrvn: this is arm64
20:46:20 <geist> mrvn: they're on arm64
20:46:33 <mrvn> ups, sorry.
20:46:39 <zid> geist: Should I get an arm dev board off a friend? he has shit loads for work
20:46:48 <geist> if you'd like
20:46:50 <zid> just gets whatever the new one is and tests it out and then throws it out
20:46:58 <geist> but of course not all are created equal
20:47:12 <geist> getting a crappy undocumented board and throwing yourself at it isn't necessarily a good use of time
20:47:38 <mrvn> zid: take the bin and sort out which boards have docs
20:47:54 <geist> yah
20:47:58 <mrvn> zid: and ask your friend why he threw it out, e.g because its crap
20:48:40 <geist> also i'd only really bother with recent things. older designs like beagleboards and pandaboards and whatnot which are now in surplus are probably not worth fiddling with
20:48:46 <geist> since they're older armv7 designs
20:48:51 <geist> documented, but old, pre 64bit
20:49:21 <zid> I think they're all fairly modern
20:49:30 <zid> like, the new board from every company
20:49:32 <zid> every few months
20:49:58 <j`ey> im just going to stick with qemu for a while
20:50:28 <geist> j`ey: good idea. once you get this working you can switch over and do risc-v
20:50:39 <geist> there's a virt machine there too, similar amount of work to bring up
20:50:45 <kpel> are 64bit raspberry pis worth the trouble or are they too capricious/old/unsuitable?
20:50:58 <geist> kpel: depends on what you want to do
20:51:09 <geist> for bare metal i'm not a huge fan, since they're a bit nonstandard
20:51:19 <geist> otoh they're at this point pretty well documented
20:51:22 <mrvn> kpel: it has the Geist seal of "not totally crap".
20:51:23 <geist> even if they're funky
20:51:31 <zid> geist: when is our wedding btw?
20:51:39 <kpel> geist: for starters, build linux kernels and load them
20:51:54 <geist> note the new rpi4 is ifferent in what looks like good ways, but ii havne't had time to dig into it
20:52:15 <geist> as far as having horsepower to actually do stuff, the rpi4 is lightyears ahead of older stuff
20:52:26 <geist> if you want a decent single board linux machine it's far better than the older ones
20:52:53 <kpel> I have a couple of rpi3s lying around
20:53:09 <kpel> geist: ok, thanks
20:56:21 <heat> https://static.docs.arm.com/100898/0100/the_a64_Instruction_set_100898_0100.pdf
20:56:27 <heat> I found this a while back, might be useful for someone
20:56:35 <heat> has a nice overview of the instruction set
20:57:11 <mrvn> j`ey: to test the stack throw an exception / do a syscall and load a the largest data types you can think of. On 32bit there is a load for 2 registers (2x32=64bit) that faults when the stack isn't aligned.
20:58:14 <j`ey> I havent gotten that far yet
20:58:55 <kpel> heat: thanks
21:05:16 <heat> :)