dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
dzwdz has joined #osdev
mahmutov_ has quit [Ping timeout: 246 seconds]
alexander has quit [Quit: ZNC 1.8.2+deb2+b1 - https://znc.in]
alexander has joined #osdev
troseman has joined #osdev
pretty_dumm_guy has quit [Quit: WeeChat 3.5]
vin has joined #osdev
<Clockface>
wtf
<gog>
what
<Clockface>
the program is starting at RIP = 0 and then segfaulting because RIP is 0
<Mutabah>
Bad ELF parsing?
<Clockface>
i have a <_start>
<zid>
who's loading it?
<zid>
ld.so?
<Clockface>
gcc thing.c staticthing.a -o thing
<zid>
ld.so then
<zid>
any imports?
<Clockface>
#includes?
<zid>
nm
<Clockface>
C standard library stuff
<Clockface>
?
<Clockface>
oh
<zid>
the tool
<zid>
ldd
<Clockface>
no
<zid>
that's the tool I'm thinking of
<zid>
how are you verifying no instructions run before rip hits 0?
<Mutabah>
And important question: What are you trying to do?
<Clockface>
im calling printf, but i think some stuff happens before it dies because some of the registers are ending up with values in them
<zid>
yea you just lied :p
<zid>
you fucked the stack and returned to a null somewhere
<zid>
printf happens a few megainstructions after _start
<Clockface>
its calling printf before anything else happsn
<Clockface>
*happens
C-Man has quit [Ping timeout: 246 seconds]
<zid>
Refer to my previous statement
<Mutabah>
Unless you have defines `_start` somwhere, in which case - don't
<Mutabah>
`_start` is provided by the compiler/OS's crt0 library, and is very system-specific
<Mutabah>
Again: What are you trying to do
<Clockface>
i have some stuff from NASM i would like to use in my C program
<Clockface>
it admittedly probably does not work yet, and im expecting to segfault once i call it since i havent tested it at all
<Clockface>
but its dying before i even get to call any of it
<Mutabah>
And how do you know that? Have you tried putting a breakpoint on `main`?
<Clockface>
its failing before printf is able to write to STDOUT, which im calling first thing in main()
<zid>
stdout is buffered
<Clockface>
oh
<zid>
prints shortly before a crash can dissappear depending on the system
<zid>
you should use.. a debugger
<Clockface>
that is inconvinient
<Clockface>
ok
<Clockface>
ty
<Clockface>
its a problem with the code itself after all
<Clockface>
yay
troseman has quit [Ping timeout: 260 seconds]
troseman has joined #osdev
gog has quit [Ping timeout: 260 seconds]
dequbed has quit [Ping timeout: 260 seconds]
_xor has joined #osdev
dequbed has joined #osdev
<geist>
yay
<heat>
clang works on my OS woooooooooohooo
<geist>
oh wow. was porting it a pain?
<heat>
no, it's gcc-like as far as I can see
<heat>
but the build system is a big pain
<heat>
I got it to build using some top secret cmake variables that someone in #llvm told me about
<heat>
but I couldn't manage to build the runtime libs (so I don't know if lld works because I'm missing some libraries)
<heat>
but getting llvm ported is pretty important since any good software gl/vulkan implementation will use it
<geist>
i had heard ages ago that clang itself uses lots of dynamic dlopen stuff or whatnot, so it required a bit more runtime support than usual
<geist>
but that may have been either ages ago, or really not that big of a deal
<heat>
well that's not really a problem for me since I'm using musl
<heat>
and dlopen is just open + mmap really, nothing out of this world
* klange
grumbles something about cheating
<heat>
i imagine that its way worse to port if you're rolling your own libc
<heat>
because of all the c++
<heat>
:P
<klange>
I haven't found I've had issues with C++ stuff on top of my libc, I think the c++ standard lib implementations avoid as much as they can, and I've considered the whole thing out of scope.
<klange>
libstdcxx, for example, seems to be working fine - though I removed it from my standard build, it's available as a package instead.
<heat>
libtoaruc++ when? :P
<klange>
Probably after toarucc. Or probably even after toarucc++
zaquest has quit [Remote host closed the connection]
zaquest has joined #osdev
eddof13 has joined #osdev
eddof13 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
eddof13 has joined #osdev
eddof13 has quit [Client Quit]
heat has quit [Ping timeout: 252 seconds]
troseman has quit [Read error: Connection reset by peer]
<geist>
ah makes sense. maybe i should switch my user libc over to musl as well
<geist>
been prototyping on newlib but it clearly h as limitations
<geist>
OTOH, loading ELF files is half the fun
<geist>
there's something really pleasing about linking stuff together like that
<geist>
though... it's probably much more annoying nowadays
<Griwes>
Hmmm. What do OSes typically do if a user makes a blocking syscall with a buffer pointer, but unmaps the buffer before the syscall gets unblocked? Treat is as if it was invalid when the syscall was called (so return an error after it gets unblocked, or maybe even unblock it immediately and do that)? send it a signal? make unmap blocking pending the first syscall? something more exotic?
<Mutabah>
Probably the former
<Mutabah>
I.e. when the kernel goes to access that memory, it'll fault and propagate the fault to the user
<geist>
right, the mechanism to propagate the fault is somewhat OS specific, but in general it either completes or it fails. but usually kernels dont define precisely when it is guaranteed to complete in that situation
<geist>
same thing generally applies to two syscalls that say overlap a buffer
<geist>
ie, two simultaneous reads() with the same buffer. no guarantees that one completes before the other or they interleave
<Griwes>
I mean that one is a rather clear race and would be hell to track, but it's not particularly hard to detect the case I'm talking about without faulting
<geist>
well depends. lots of OSes do what Mutabah described (zircon does too) where when the kernel goes to access the buffer it simply tries and if it's a fatal location (ie, not mapped) it detects the failure and returns back
<geist>
so it doesn't 'preflight' the buffers at any point in the syscall
<geist>
that's pretty common, since the common case is it goes through
<Griwes>
But okay, it's not a break of user expectation to just tell them "those are invalid pointers" when that happens, then?
<geist>
right, so there are two differen ttopics here: how does the kernel detect that the buffers are bad (and when in the sycall precisely) and then how the error is returned
<geist>
the latter, if it's a posixy style thing, is probablky in the form of an error code returned
<geist>
ERR_INVALID_ARGS or something
<geist>
-EBADARGS etc
<klange>
-EFAULT
<geist>
yah
<geist>
but you could have, say some sort of comprehensive exception model
<klange>
probably also valid to set SIGSEGV pending and then back out
<geist>
yah
<Griwes>
Okay, so no strong feelings either way then, I like that
<geist>
zircon for example simply returns ZX_ERR_INVALID_ARGS, *or* hard kills the process, if a particular flag is set on it
<geist>
(for more tightly controlled processes)
<Griwes>
Gotcha
<klange>
"If I ever hand you bad memory, just shoot me."
<geist>
the latter is effectively like cranking up runtime asserts. there are a set of control bits like that to really tighten the screws
<Griwes>
I'm "preflighting" my buffers and lock their mappings for the syscall duration because I would like to not deal with reentrancy in the kernel, other than in a number of places specifically meant to run as threads and not as proper kernel mechnisms, so I do have a way to detect this pretty easily
<geist>
sure, i've seen systems do that. BeOS did it, for example
<geist>
harder to do for variable buffers
<geist>
would *highly* recommend not passing C style strings into the kernel, for example, since you can't preflight them
<geist>
zircon absolutely forbids it for this reason
<geist>
BeOS iirc would just pin the page the first byte was in, and if you passed a C style string that passed into bad memory it would crash the kernel. was a known issue
<Griwes>
The way I've done it initially was that at the entry to a blocking call I'd lock the mapping, and persist it until the syscall eventually completes
<Griwes>
But I got to an unmap syscall and arrived at the original question, because I either need to scope the locks to not persist across suspensions, or I need them to have thread queues for the unmap calls to put themselves on
<Griwes>
Oh yeah no, all buffers in kernel calls will always be either of a known type, or have an explicit size argument
<geist>
indeed. you potentially need some sort of pin count and some way to block the unmap call, etc as you say
<Griwes>
Yeah
<geist>
whcih is gtenerally why in the long run the 'copy and handle fault' is not a bad idea
lainon has joined #osdev
<geist>
or... look up the physical page and do IO there, and just hold the page in a pinned state
<geist>
so that the unmap can complete, but the buffer copy can still happen. when the copy ends it drops refs on the pages which then get freed to the PMM
<geist>
would need some sort of temporary pinned buffer structure holding a ref to all the pages the buffer crosses
<geist>
advantage of that scheme (though it's complicated) is if you really do a good job and optimize the wazoo out of it, you can remove the need to even have user space mapped at the same time as the kernel
<geist>
and that removes a whole pile of spectre/meltdown issues, etc
<geist>
and makes thingsl ike SMAP/SMEP completely moot
<Griwes>
But I think I'll just make the mapping locks more scoped, so that they don't persist, so while you can hit a contention when you have a wakeup on one core and an unmap call on another, the unmap call just spins for a short time (because syscalls that take buffers should be fairly quick)
<geist>
sure. can have some sort off lookaside buffer of range locks per address space and have other threads block behind it
<geist>
would have to be careful in case you have a syscall that grabs multiple buffers that you dont create a deadlock situation
<Griwes>
Yeah
<Griwes>
Well, at that point it's always a try_wait
<geist>
and also situations where the same syscall passes pointers to overlapping buffers
<geist>
which should be valid
<Griwes>
Yeah I've hit that already
<Griwes>
My stdlib gained <shared_mutex> because of it :D
<Griwes>
Cool. I know what I want to do now
<Griwes>
Thanks as always!
<geist>
yay
srjek has quit [Ping timeout: 240 seconds]
myon98 has quit [Ping timeout: 265 seconds]
Teukka has quit [Ping timeout: 240 seconds]
scripted has joined #osdev
lainon has quit [Quit: Konversation terminated!]
myon98 has joined #osdev
scoobydoo has quit [Ping timeout: 256 seconds]
<scripted>
mbd: not sure if you're here, but why don't you set your mbd global?
<scripted>
oops
<scripted>
I meant heat:
<scripted>
I discovered using a debugger it is NULL but why can't I pass it and then simply use it in another file?
<scripted>
oh I'm dumb as fuck, I set it to NULL!
<scripted>
Ok, I fixed it already but I still don't know why mmap_len is 0.
<scripted>
mbd->mmap_length
Optimus has joined #osdev
scoobydoo has joined #osdev
Teukka has joined #osdev
Optimus has quit [Read error: Connection reset by peer]
Optimus has joined #osdev
<gorgonical>
Is there some special format that USB uses to report numbers? Like what's the encoding? I am tinkering with this barcode scanner on an arduino and I'm seeing encodings like this:
<gorgonical>
I trimmed all-0 lines out and those results are the correct numbers, but I don't really understand the correspondence. 1E = 1, and it's like on a keyboard where 0 is after 9, not before 1.
<gorgonical>
Are they scancodes?
<gorgonical>
The wiki answered my question: they are scancodes
<klange>
Yeah, most barcode scanners speak keyboard - makes 'em really easy to plug-and-play with a POS system.
<gorgonical>
Yeah this library I'm using for this usb host shield is... not ideal, but it's what I bought and I don't think I have time for a new one
<gorgonical>
It looks like with some hacking the library will do what I want
<klange>
Hm, if it gets a repeat number, is it outputing a zero packet? USB doesn't do make-break, it does "this is what's held down right now"...
<gorgonical>
What do you mean by repeat number? It seems to output the whole 8-byte keyboard report
<gorgonical>
So (for me) anything with a first keypress of zero can be considered a null report
GeDaMo has joined #osdev
<klange>
though I guess maybe it depends on how fast it's sending, it could expect that just sending the same packet twice with sufficient gap will be accepted by the OS as two presses?
<gorgonical>
Though I'm polling at the max rate the device wants
<klange>
The format for the standard HID packet for keyboards is two bytes of modifiers (bit flags, and only the first byte is defined), then up to six scancodes that are currently down.
<puck>
i believe that you do need to send a HID report with the key depressed at least once
<gorgonical>
right
<gorgonical>
klange: yeah and the scanner sends a separate report for each digit of the barcode
<klange>
So for the pair of 2's, a regular keyboard would really need to send a "nothing is down now" packet between them
<klange>
Unless there's some configuration I'm unaware of where it says it ain't gonna do that.
<gorgonical>
I'm very unfamiliar with the whole HID spec so I have no idea, really. I'm like 80% sure this behavior I'm writing is not conforming
<puck>
gorgonical: try printing out a code39 barcode with letters btw, i wonder if it holds down shift where necessary
<gorgonical>
Seems to report the shift correctly in the first byte
<gorgonical>
02 I presume is shift modifier
<puck>
yeah, left shift, i think
<gorgonical>
This barcode scanner is wildly overspecced, though. The manual is full of barcodes that configure the scanner
<gorgonical>
I can have it report all-upcase, all-downcase, a mix, etc.
<gorgonical>
If I can count correctly the scanner has an RJ11 port on it and actually reports under certain configurations to be a USB CDC device
<klange>
In ascending bit order (LSb first): Left ctrl, left shift, left alt, left super ('gui' or 'the windows key'), then right ctrl, right shift, right alt, right super
<puck>
gorgonical: ooh, that might be easier to decode, if it shows up as a USB serial device
<gorgonical>
At this point I need to add a lookup table to convert the 1st byte scancode to the digit and that's probably fine for a prototype. I don't even think the scanner will duplicate faster than the ~20ms it takes to poll the whole barcode out
<klange>
How does USB serial work at the protocol level? Does the pipe just have the raw data, presumably after a configuration is chosen? Or is it encapsulated in some way?
<klange>
... I ask as if I don't have one attached right now that I can just spy on with wireshark...
<puck>
yeah, i think it's just raw data on the endpoints
<puck>
(presuming CDC-ACM, but)
<klange>
bulk transfer in and out with raw data, control endpoint for configuring baud it seems
<klange>
wireshark doesn't seem to actually have any analyzers for device protocols beyond the headers linux's monitor interface supplies
freakazoid343 has quit [Ping timeout: 240 seconds]
<zid>
you expect me to believe there's a magical vortex around the north pole, what is this, final fantasy vii?
<zid>
do we need to drive our airship over and defeat sephiroth
<GeDaMo>
I'm not sure that would help :P
<zid>
That's fair, if we stop the meteor we miss out on the world ending
<zid>
let's not bother
<GeDaMo>
What was the name of the big underwater monster between the two main land masses?
<GeDaMo>
Was it Leviathan?
<zid>
emerald weapon
<GeDaMo>
Ah
scripted has quit [Quit: WeeChat 3.5]
<bauen1>
zid: i don't think pic will solve all issues, or i'm probably misunderstanding what pic is supposed to do: https://godbolt.org/z/TYhzT5Goj if i put e.g. a function pointer in .data then the code will no longer be relocatable, as it will have the linked-at address in the .data section, and try to access it without going through the got
<bslsk05>
godbolt.org: Compiler Explorer
<zid>
you can't put it in statically but you can put it in at runtime just fine
<zid>
putting it in at compile time will need a relocation
<zid>
which isn't going to work
<zid>
can't cheat physics
<zid>
"I want to both burn the address of this code into the rom, and also have the code be movable". You can't have your cake and eat it, pick one.
heat has joined #osdev
heat has quit [Read error: Connection reset by peer]
<bslsk05>
blog.llvm.org: Generating relocatable code for ARM processors - The LLVM Project Blog
<zid>
what do you mean, yet
<zid>
It's not a solveable problem
<zid>
It's literally logically impossible for thing to be a thing and the antithesis of that thing simultaneously
<mrvn>
bauen1: anything that takes the address of something makes the code relocatable but not longer position independent.
<bauen1>
zid: i know i will need to adjust some addresses, i'm fine with adding the offset e.g. to the GOT before running the code, so i want exactly the same thing with the .data section while it is copied to ram
<mrvn>
bauen1: did you build with PIC/PIE?
<bauen1>
sadly there is not enough ram to copy the flash contents
<bauen1>
mrvn: see the godbolt above, with -fpic
<zid>
Time to implement a LUT
<zid>
enum FUNC_LIST { FUNC_F1, FUNC_F2, ..}; and your .data section gets FUNC_F1 FUNC_F2 etc references
<zid>
then you build a small array at runtime with lut[0] = test_f1; lut[1] = test_f2;
<zid>
and to dispatch you do lut[FUNC_F1]();
<mrvn>
zid: that isn't position independent.
<zid>
It's fully position independant.
<bauen1>
zid: sadly it's not that easy to adjust the existing code base, and it's in C++
<mrvn>
zid: it will hardcode the relocatable absolute address when you init the array
<mrvn>
function pointers aren't PC relative :(
<bauen1>
i think i'm basically looking for some way to get a "adjust offset" table of addresses in .data that need to be adjusted when copied to sram
<mrvn>
zid: line 2 gets the PC, like 3 finds the GOT, the rest loads a relocatable address from the GOT
<zid>
note how all it actually has to do is subtract 2 from eax
<zid>
to find f
<zid>
the codegen is just busted
<zid>
or 3, however big that call is
<mrvn>
zid: no, it's relocatable code.
<mrvn>
also totaly UB
<zid>
so you don't admit you can find f by subtracting the size of a call from eax on line 3?
<zid>
None of this is UB
<mrvn>
zid: The cast to uintptr_t is UB but that's beside the point.
<zid>
It is not UB
<mrvn>
function pointers have their own size that isn't necessarily uintptr_t
<zid>
it's also irrelevent, I was just too lazy to type out a function prototype
<zid>
it's idb
<zid>
*calling* the function is ub
<zid>
cus I may have truncated it
<mrvn>
And a and f can be p0retty much anywhere in memory. Subtracting 3 from a gets you nowhere near f.
<zid>
nobody is talking about a
<zid>
I am talking about *the location of f*
<zid>
which is eax-sizeof(call) avec line 3
<mrvn>
"subtract 2 from eax" what's eax then=
<mrvn>
?
<zid>
the value of [esp] inside the thunk
<zid>
which is eip
<zid>
of f+call
<mrvn>
Ahh, yes. You can do that. compilers don't do that.
<zid>
It is however, completely possible
<mrvn>
Usualy functions don't store their own address in global variables.
<zid>
I'm surprised it took 50 irc lines for you to read 2 lines of assembly
<mrvn>
zid: I was talking about what compilers do and you where talking about what humans would do. So we didn't talk about the same thing.
<zid>
I was talking about a code snippet.
<zid>
I never mentioned code, or compilers, or any of those things
<zid>
I made direct statements about line numbers and what the values of various registers were
<mrvn>
zid: the code sniplet is not PIC. your "Subtracting 3" is what a human would do,.
chibill[m] has quit [Quit: Reconnecting]
<GeDaMo>
bauen1: what are you trying to achieve?
<bauen1>
GeDaMo: a bootloader for a microcontroller with multiple images, so the code is read-only at a random address in flash, but ram is at a fixed address, and .data is in flash, but gets copied to ram before start
<bauen1>
GeDaMo: so basically a position independent .text, with a fixed .bss, .data section
<GeDaMo>
You can't run the code out of the Flash?
<bauen1>
GeDaMo: not enough RAM :(
<mrvn>
bauen1: if ysou can't do reloactions then you have to write everything in asm, or at least fix the compiler output to be 100% PIC.
<mrvn>
bauen1: do you have enough ram to copy the GOT?
<clever>
the esp32 line of chips, have an MMU to map the physical addr space onto the flash addr space
<bauen1>
mrvn: yes, enough ram for .got, .data and some more
<clever>
so you dont need PIC, but you can store multiple distinct binaries in flash
<mrvn>
bauen1: then you should be able to do the reloactions.
<GeDaMo>
I don't understand why lack of RAM means you can't run the code directly out of Flash
<clever>
GeDaMo: yeah, there are plenty of things with XIP, where it just directly runs out of flash
<bauen1>
GeDaMo: oh, i mean i run the code directly from flash, but not from ram
<mrvn>
GeDaMo: he want's one binary that runs on different controlers with different flash addresses
<mrvn>
bauen1: you are really better of just building a binary for each controller type.
<bauen1>
mrvn: but how do i get ld to only emit relocations for .data ?
<bauen1>
mrvn: yes, right now i'm mostly figuring out how i could go about this
<mrvn>
bauen1: you can't, you PIC/PIE and then deal with the GOT and trampolin.
<zid>
oh, fPIE does it, haha
<zid>
but only for amd64
Likorn has quit [Quit: WeeChat 3.4]
<zid>
f:
<zid>
mov QWORD PTR a[rip], rax
<zid>
lea rax, f[rip]
<zid>
the third line doesn't need to be PIE which is why I turned off PIE at first.. but it *does* make it work right..
<mrvn>
zid: unfortunately not always reliably
<GeDaMo>
Threaded code interpreter! :P
<mrvn>
Anyone know that the difference is between -fpie and -fPIE?
<zid>
for m32 it's still geborkt
<mrvn>
zid: small memory model?
<mrvn>
-fno-plt?
<gog>
all caps removes size limits on the GOT on some platforms
<zid>
I believe you mean, makes you look way cooler, like smoking
<zid>
caps lock is cruise control for cool
<bauen1>
i'ma actually really confused why -fpic would not go through the GOT for .data variables, because https://godbolt.org/z/c6h4e75Ec doesn't work anymore when you relocate it
<bslsk05>
godbolt.org: Compiler Explorer
<gog>
> If the GOT size for the linked executable exceeds a machine-specific maximum size, you get an error message from the linker indicating that -fpic does not work; in that case, recompile with -fPIC instead. (These maximums are 8k on the SPARC, 28k on AArch64 and 32k on the m68k and RS/6000. The x86 has no such limit.)
<zid>
THE ECKS EIGHTY SIX
<heat>
nerd
chibill[m] has joined #osdev
<gog>
i'm just your local documentation enjoyer
<zid>
chad*
<heat>
you're my local NERD
<heat>
reading is for NERDS
<gog>
that's fine
<mrvn>
bauen1: PIE is relocatable, not position independent. The PIC/PIE options are mis-named.
<heat>
PIE and PIC are best attempts at position independent code
<mrvn>
"best" is arguable. they follow a pretty primitive format no matter what.
<bauen1>
wtf, then why are there absolutely no relocations generated :(
<mrvn>
bauen1: because there are and you are looking in the wrong sections I blieve
<gog>
you need to link with -pic and include .rela.dyn
<mrvn>
bauen1: depending on linker compiler/options you get different relocations mechanisms from gcc. really sucks.
<gog>
or .rel.dyn
<heat>
fuck rel
<gog>
x86_64 is always .rela.*
<heat>
all my homies love rela
<gog>
yeh rela is better
<heat>
more letters = better
<mrvn>
oh yeah, it's different per arch too
<zid>
are we playing wordle
<gog>
basically it's annoying
* mrvn
want's position relative pointers.
<zid>
is the answer 'relactates'
<mrvn>
__rel__ void *p = __rel__ &x; should put "&x - &p" in p.
<gog>
__mew__
<mrvn>
(__)
<mrvn>
/------\/
<mrvn>
(oo)
<mrvn>
/ | ||
<mrvn>
* /\---/\
<mrvn>
~~ ~~
<mrvn>
..."Have you mooed today?"...
<heat>
nothing gets me going more than double underscores
<heat>
oh man
<mrvn>
slide code :)
<heat>
oh and single underscores followed by an uppercase letter
<heat>
omg
<mrvn>
heat: those are fun too
<bauen1>
thanks
<bauen1>
so .data.rel is a thing too
<gog>
yes
<gog>
you can just slap that into .data in your output
<bauen1>
well, no, it might just be exactly what i need
<mrvn>
bauen1: you should write your linker script to error for any unused section and specifically discard stuff you don't need.
<mrvn>
then see what remains and if you can use it
<bauen1>
mrvn: thanks, i will do that. the existing linker script had a catch-all *(.data.rel)
<mrvn>
bauen1: why can't you build a binary for each controller type?
<mrvn>
(or do you just don't want to, like me?)
<bauen1>
mrvn: it's a longer story, but this microcontroller will hopefully go to space, so the ability to copy one firmware image over another would be a very nice to have, so you don't have to upload an entire image if you need to replace a broken one
<gog>
space space wanna go to space
<mrvn>
that's not what you get from being position independent
<bslsk05>
heatd/Onyx - UNIX-like operating system written in C and C++ (2 forks/27 stargazers/MIT)
<heat>
you just use it
<mrvn>
bauen1: you need PIC when you want to upload the same image to different hardware.
<bauen1>
mrvn: why not ? the code is run directly from flash, and there's no mmu to remap things, so it's 0x00 [bootloader][image 1][image 2][image 3] 0xff ; and if you want to copy *image 1* over *image 2* you can only do that if they don't care about the address they will get executed at
<mrvn>
bauen1: you can only do that if image 1 <= image 2.
<mrvn>
bauen1: do you just want to have multiple revisions of your image so that you can fall back to a good one on failure?
<bauen1>
mrvn: the "slots" will be a fixed size
<clever>
mrvn: the esp32 i mentioned earlier manages to get that without pic, via a dedicated mmu between physical and flash
<zid>
if it's only for backups why not just have slot 0 be the 'current' slot and link everything for that location
<zid>
and copy it thre before it runs
<bauen1>
mrvn: yes, multiple images to fallback to a good one, and the ability to replace an image piece by piece until you can finally boot it
<mrvn>
clever: any arch with multiple flash/rom chips does that, yes.-
<clever>
i think it generally keeps 3 copies, factory, a, b, so you can both factory-reset, and have a/b booting for undo
<clever>
mrvn: but esp32 does it with a single flash chip
<zid>
or slot 1 and slot 0 is the recovery/bootloader, whatever works
<bauen1>
clever: the stm32l4 also has the ability to do that, but only for 2 images
<mrvn>
clever: it borrows one of the address lines to split the single chip in two.
<clever>
i think esp32 aims at having things work out of the box and having OTA updates, so the factory reset still needs to be functional
pretty_dumm_guy has quit [Quit: WeeChat 3.5]
<clever>
ive also seen this thing being screwed up recently
<clever>
a smart microwave thinks its an oven, so it is now a brick :P
<clever>
and there is no factory reset button
<mrvn>
clever: a ROM would have cost $0.01 more per unit.
<clever>
mrvn: yeah, but somebody demands OTA updates, lol
<mrvn>
clever: there is no AIR in SPACE. :)
<clever>
:D
gareppa has joined #osdev
gareppa has quit [Remote host closed the connection]
<mrvn>
bauen1: I recommend having a bootloader/fallback image that can flash images and never touch that.
<clever>
thats almost exactly what the factory image in esp32 stuff is
<clever>
its slightly more, because its both capable of re-flashing, and also doing the job you want from the device
<mrvn>
If it's up in space and some dummy accidentally flashes the wrong image destroying the last working copy then that really sucks.
<mrvn>
Make it really hard to destroy the flashing capability.
<bauen1>
mrvn: yes, the reason nobody wants a rescue image, is because that has the very high potential to diverge a lot from your normal image, and a previous mission has already shown that to not be a good idea
<heat>
see, this is why I would use a rpi + an sd card
<heat>
dummy proof
<gog>
you need a radiation-hardened rpi
<gog>
idk if that exists yet
<bauen1>
gog: there's a lot of rad-hardened hardware ... if you have a lot of money ;)
<zid>
rad hardened = make it on a big node and wrap it in tinfoil
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
elastic_dog has quit [Ping timeout: 240 seconds]
<gog>
that'll work for alpha and beta particles
<bauen1>
zid: ideally you would just wrap your satellite in a lot of mass, but that also results in some money and potentially launch vehicle problems
<zid>
and nothing works for gamma anyway, so whatever
<gog>
idk about the radometry of low-earth orbit but it'd probably be infrequent enough
<clever>
there was also a recent solar storm event, that ruined a whole batch of starlink sats
<clever>
not because of the radiation directly, but the radiation caused the upper atmosphere to expand, which caused extra drag on the sats on low orbit
<gog>
yeah charged plasma is a different problem
<clever>
and then there was too much drag for the gyro to point the main engine in the right direction
<zid>
yea, do you serve it with ketchup or hot sauce
<clever>
so it couldnt fire the engine and raise orbit
<zid>
I can never decide
<heat>
mustard
<gog>
alwawys hot sauce
<zid>
american french or british?
<sauce>
;)
<heat>
why not all three?
ZipCPU_ has joined #osdev
ZipCPU has quit [Ping timeout: 272 seconds]
ZipCPU_ is now known as ZipCPU
elastic_dog has joined #osdev
* geist
yawns
elastic_1 has joined #osdev
elastic_dog has quit [Ping timeout: 250 seconds]
elastic_1 has quit [Client Quit]
elastic_dog has joined #osdev
Likorn has joined #osdev
heat has quit [Read error: Connection reset by peer]
heat has joined #osdev
eroux has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
chibill[m] is now known as chibill
eroux has joined #osdev
chibill has quit [Quit: Reconnecting]
chibill has joined #osdev
eck has quit [Quit: PIRCH98:WIN 95/98/WIN NT:1.0 (build 1.0.1.1190)]
eck has joined #osdev
eddof13_ has joined #osdev
dzwdz has quit [Quit: I'm a quit message virus. Please replace your old line with this line and help me take over the world.]
freakazoid343 has joined #osdev
dzwdz has joined #osdev
heat has quit [Ping timeout: 260 seconds]
eddof13_ has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
mahmutov_ has joined #osdev
mahmutov_ is now known as mahmutov
gildasio1 has joined #osdev
gildasio has quit [Remote host closed the connection]
gog has quit [Ping timeout: 272 seconds]
mahmutov has quit [Ping timeout: 272 seconds]
phr3ak has quit [Quit: QUIT]
Likorn has quit [Quit: WeeChat 3.4]
gildasio1 has quit [Remote host closed the connection]
gildasio1 has joined #osdev
Likorn has joined #osdev
mahmutov has joined #osdev
vimal has quit [Ping timeout: 245 seconds]
vimal has joined #osdev
<bauen1>
and this took way to long to find, but i think -fpic for compiling and --shared when linking is what i need. -fpic: normally allows ld to get rid of all relocations in .text / .rodata, --shared to actually include the remaining relocations in the result for my bootloader or startup code to clean up when copying .data and .got
<zid>
ye
<zid>
that's more or less what I expected, but I was hoping for better codegen on .text
<bauen1>
zid: yes, sadly it still goes through the got when accessing sram, which isn't necessary since that location won't chang
<bauen1>
*change
<zid>
nod
<zid>
it's completely possible for it to elide it, it just doesn't bother for all arches or all possible caches
<bauen1>
zid: you mean to resolve the relocations i don't want to care about ahead of runtime ? or do you have some magic way in mind to get gcc to not go through the got if unnecessary
vimal has joined #osdev
vimal has quit [Max SendQ exceeded]
<zid>
no magic, but linking twice can stop you needing got stuff between things that will end up in memory together
vimal has joined #osdev
<zid>
you do a 'regular' link to turn a.o and b.o into ab.o
<zid>
to delete the got references between a and b
<zid>
then do your -shared link of ab.o into the final binary
mahmutov has quit [Ping timeout: 250 seconds]
<bauen1>
zid: thanks, i didn't even consider yet that was going to happen
<bauen1>
in other news, i made ld fail an assertion ...
mahmutov has joined #osdev
eddof13_ has joined #osdev
<chibill>
Question when writing a TTY style interface for putting text on the screen. Any suggestions on handling backspace? I am trying to figure out how to make it so after a new line the backspace can properly jump to the end of the text.
<chibill>
Or is it proper just to have it move to the end of the line before the newline
mahmutov has quit [Ping timeout: 246 seconds]
eddof13_ has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Optimus has quit [Remote host closed the connection]
<zid>
just treat \n as any other character
<zid>
your normal word wrapping should make it behave like you want
<zid>
i.e \n appears in the text buffer that gets printed to the screen, but is a control character that moves the cursor
dude12312414 has joined #osdev
<zid>
^H will now delete \n and undo the linebreak as expected
<chibill>
Yes but how will I find the correct column to move back to after the BS (backspace) character? For example. If I had some text then a new line then tried to use backspace to get back up to the end of the text on the first line how do I do that. Also my TTY style I mean I am displaying to the VGA output and I am able to print just text.
<chibill>
For example a new line is handled different then word wrapping.
simpl_e has joined #osdev
<chibill>
So how to I get the backspace character to handle that case properly without it just ending up at the far right edge of the screen instead of at the end of the line where the newline character existed.
<zid>
just redraw the entire screen
<zid>
or track dirty updates
<clever>
or save the current col to an array (one slot per line) when you print a \n
<zid>
you could also just walk the buffer backwards until the previous n or WIDTH characters
<zid>
previous \n
<zid>
whichever is smaller is the cursor position
<mrvn>
You keep all the text printed from the first line to last. Then on backspace you remove the last char and redraw from top to bottom.
<chibill>
Think is I have no real buffer. Other then whats on the display. Should I implement a double buffer or buffered IO?
<chibill>
thing*
<zid>
^R redraws so you need a buffer anyway
<mrvn>
and most people want to scroll back from time to time.
<zid>
unless you mean "an actual teletype", which has no real ^H either
<mrvn>
or have virtual consoles
ThinkT510 has quit [Quit: WeeChat 3.4.1]
<zid>
because you know, ink
<zid>
I actually use a ring buffer for mine
<clever>
zid: ive seen typewriters with an erase function
<chibill>
True. I just wanted to get my basic output working in a nice way. And actually they do have an ASCII 8 control character on real teletypes.
<clever>
it could swap between black and white ink
<zid>
clever: I bet it doesn't scroll the paper if you hit it on the left edge though
<clever>
and draw the glyph over in white
<chibill>
Its how they add the ' over a and stuff.
<clever>
no, i dont think it had that
<zid>
so it isn't a real backspace either, just print head left
<chibill>
Thats all the backspace character does anyways
<mrvn>
if you want to only use the VGA buffer then on \n fill the rest of the line with an invisible character so you undo them on ^H
<zid>
not on modern terminals anybody would actually use
<zid>
they support word wrap
<zid>
which means backspace should go from bottom left to y-- x=width-1
<chibill>
Word wrap doesn't have anything to do with the backspace character tho.
<zid>
it does if you want backspace not to suck
<mrvn>
I've seen enough TTYs that only go to x=0 on backspace.
<zid>
either they do 'virtual' long lines, where as you type more than 80 cols, it starts shifting the text off-screen
<mrvn>
no un-scrolling
<zid>
or they put a fake newline in
<zid>
aka wordwrap
<mrvn>
zid: or they just break in the middle of a word
<chibill>
Backspace where it moves back 1 character (which is what the spec for ASCII says it does) supports wordwrap.
<zid>
if backspace can only delete 'dwrap' then gets stuck, I'd be mad
<clever>
yeah, there are 2 seperate issues, crossing back because of wordwrap, and crossing after an intentional newline
<chibill>
The because of word wrap is easy. I have that working. Its getting back to the right places after a new line that I was trying to figure out.
<zid>
hence "whichever is smaller of 80 and counting characters backwards until the previous \n"
<zid>
tells you where the cursor goes
<chibill>
Also conventional Backspace keys on the computer actually use the 0x7f ASCII code.
<zid>
because there's two rasons the line could be split
<chibill>
Which is not the Backspace character
<zid>
As mentioned, we don't use actual teletypes for our vttys
<zid>
they have annoying practicallity quirks like print heads and ink
<chibill>
Still very useful for displaying information like updating a percent complete in text without re-drawing the whole display.
<zid>
You need to full redraw every time \n happens anyway if you're emulating it
<zid>
rather than using an infinite sheet of paper
<chibill>
Either way I was trying to make it so what I had was following what ASCII said it should do.
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
<chibill>
Still haven't done anything past a display and setting up my GDT. Working on my IDT now along side this display stuff.
<zid>
ring buffer also helps if you have multiple cpus wanting to kprintf
<chibill>
Want to try and get paging setup after that before I start doing anything fancy with running stuff not in the kernel it self.
ThinkT510 has joined #osdev
<zid>
stops stops yoyouu gettinggetting ththisis
GeDaMo has quit [Remote host closed the connection]
<chibill>
Right now I am not caring about multiple CPUs. :P Want to at least get part way working on one. Since I still haven't figured out the proper steps to get to 64-bit mode. (Sort of wanted to start at 64-bit but figured I should probably work my way up.)
<gorgonical>
I have just discovered a huge problem with this barcode scanner
<gorgonical>
Oh no
<zid>
I did 64bit first it's much easier
<zid>
other than the whole "nobody can boot it really" part
<gorgonical>
I can't read barcodes off a pho ne screen
<gorgonical>
B
<gorgonical>
Oh wait! sorry also
<chibill>
So I have heard. I just know the wiki suggest not even trying 64-bit untill you did at least some basic stuff in 32-bit
<zid>
most barcode scanners can't, I'd assume?
<zid>
they're looking at reflections
<zid>
only cameras would be able to do a screen
<gorgonical>
Yep. This had not occurred to me
<gorgonical>
This is the king of hangup I was really hoping would not happen
<clever>
QR codes are read more with a camera
<clever>
and can contain more data
<clever>
gorgonical: what about an e-ink screen?
<gorgonical>
Probably it would work there
<clever>
i think aws snowball uses e-ink for shipping labels
<chibill>
I know barcode scanners that can read phones exist, got 3 of them here at work.
<gorgonical>
The problem is that I'm hacking together a project as a security thing for a phd class
<gorgonical>
chibill: Then probably I gotta get one of those
<mrvn>
chibill: when someone prints \n just fill the remainder of the line with \n. Then on backspace with x=0 remove all \n in the line before.
<zid>
aka a camera
<zid>
just build a $10 android phone into it :P
<gorgonical>
My professor requires a "full system" to qualify as a good IoT project
<mrvn>
chibill: unless you don't have a 64bit cpu do 64bit.
<zid>
I mean.. an off the shelf barcode scanner is no different practically, but I can see the difference.. conceptually
<gorgonical>
It's not quite enough to do the important part. I have to wire up an arduino with barcode scanner, set up web endpoints... etc.
<gorgonical>
:) so hence the tinkering with usb barcode scanners and old libraries
<mrvn>
gorgonical: why do you need to read barcodes from a phone? They are everywhere. Go get a snack and use that barcode as test case. :)
<gorgonical>
mrvn: Err, the long and short of it is a shopping anonymizer. You get a barcode, go shopping, and trusted software (arm TZ stuff) strips private data off
<gorgonical>
Need a way to configure the bits and pieces without asking an esp8266 to do heartbeats or whatever
<chibill>
mrvn: Well I don't have a X86 based machine in my house that isn't 64-bit. Even my server I build in 2012 is 64-bit
<gorgonical>
And persistent configuration from a server, etc.
<mrvn>
chibill: Just get the boot.S from the wiki to get into 64bit mode and then go from there.
<chibill>
Have to have some sort of paging figured out already before you can go into Long Mode tho.
<gorgonical>
chibill: I've seen boot trampolines that have early paging built in by the assembler
<chibill>
Plus I have to setup the normal 32-bit protected mode stuff anyways to get to long mode aswell.
<gorgonical>
by "built in by the assembler" I mean with macros, etc.
<mrvn>
chibill: Just map the first 2GB of memory at 0 and -2GB
<mrvn>
chibill: there is some code out there to go from 16bit to 64bit directly. But better to go 32bit - 64bit with multiboot
<bslsk05>
zid/bootstrap - AMD64 bootstrap example. Sets up long mode and paging starting from a 32bit ELF booted by grub. (0 forks/0 stargazers)
<gorgonical>
chibill: yeah kind of like this. It's not this one, but the idea of using asm macros and stuff to directly stick them in
<gorgonical>
For our case the kernel might not be loaded at address zero so having these inline macros makes it a little easier to do the paging. The assembler does the offset computation for us
<mrvn>
gorgonical: you can do it in C, compile to asm and copy that to boot.S
<gorgonical>
oooooh. Yes that had not occurred to me
<chibill>
I already am using the multiboot header currently with grub. Hm Is that supposed to start my boot.S in 16-bit or 32-bit. I was under the impression I had to transition into protected mode myself.
<zid>
pmode
<zid>
if you wanted to boot into real mode, the bios already does that
<mrvn>
chibill: multiboot is already 32bit mode.
<zid>
and emulates the drives correctly for you to load them
<chibill>
Hm Wonder if I jsut messed that on the Wiki or if it doesn't mention it.
<zid>
It loads the kernel to 1MB, you'd struggle in real mode to you know
<zid>
have an IP value that refered to it
<chibill>
okay either way. I am going to mess if 64-bit stuff later.
<chibill>
So to recap. I followed the barebones setup and then once I got that working and understood what it was doing moved on to the Meaty Skeleton, which I have setup a GDT and loaded it and now I am working on setting my IDT before I move on to getting paging configured and turned on.
<zid>
I've never read any of them :D
freakazoid343 has quit [Read error: Connection reset by peer]
<chibill>
Eventually I plan on using what I learn writing an OS for x86 to write at least a basic kernel for my Homebrew CPU. (Granted it will be alot simpler since I don't have to deal with weird things x86 has going on for backward compatability.
<mrvn>
you have a homebrew cpu with MMU ?
<zid>
My homebrew cpu so far has a register
<zid>
and no ISA
<chibill>
Well its still in the design stage but yes. :P
<zid>
gog I want to call you "google" but that's already a word, sadge
<gog>
goggle
<zid>
also a word
<gorgonical>
gogol-mogol
<klange>
good queen goggle gog
<zid>
gween
<moon-child>
tbf, gog is _also_ a word
<moon-child>
sooo
<zid>
is it?
<moon-child>
ok, agog is at least
<moon-child>
close enough
<zid>
I know 'agog'
<zid>
gog is apparently not a word
<zid>
I wanna play scrabble against moon-child
<gog>
gog is a proper noun referenced in the bible
<moon-child>
proper nouns don't count in scrabble. Though idk why we're playing scrabble
* gog
plays the word 'bofa'
freakazoid343 has quit [Ping timeout: 252 seconds]
<kingoffrance>
bastard operator from antarctica?
<kingoffrance>
hell is cold?
<mrvn>
hell is other people
<mrvn>
kingoffrance: you are reading to much Bibel.
<gorgonical>
I've heard that chess in antarctica can be life or death, as can novels
<kingoffrance>
i was going say i learned hell is cold from video games but then i saw: Rubicante is a demon in the Inferno of Dante's Divine Comedy. He is one of the 13 Malebranche ("Evil Claws") who guard Bolgia Five of the eighth circle of Hell, Malebolge. so, thats where malbolge came from lol
* kingoffrance
the more you know *star*
<mrvn>
For those not versed in the Bibel: Seen from heaven the moon is 49 times brighter than a sunny day on earth. So direct sunlight in heaven is way more than 49 times what we get on earth. Gets terribly hot there. On the other hand hell has molten sulfur. That's is quite cool in comparison.
elastic_1 has joined #osdev
elastic_dog has quit [Ping timeout: 250 seconds]
elastic_1 is now known as elastic_dog
elastic_dog has quit [Client Quit]
elastic_dog has joined #osdev
Optimus has quit [Ping timeout: 272 seconds]
<kingoffrance>
im more amazed zid didnt make an iceland joke
Optimus has joined #osdev
freakazoid12345 has joined #osdev
<kingoffrance>
there used to be a guy named vendu who was designing a cpu, but he disappeared
dennis95 has quit [Quit: Leaving]
<chibill>
There you to be a group from here that started a cpudev wiki that sort of disappear
<chibill>
Use*
<gog>
they're gonna make their own cpu
<gog>
with real hardware task switching
srjek has quit [Ping timeout: 260 seconds]
<mrvn>
gog: what a waste.
<kingoffrance>
vendu meant wizard or something, i forget, i wanted to see what he came up with :)
pretty_dumm_guy has joined #osdev
JanC has quit [Remote host closed the connection]
JanC has joined #osdev
m3a has joined #osdev
<gog>
i'm gonna make my own operating system
<gog>
that doesn't operate
<gog>
and isn't even really a system
<moon-child>
I'm gonna make my own operating system
<moon-child>
with blackjack
<moon-child>
and hookers
<gog>
nah that's called saturday night
freakazoid12345 has quit [Read error: Connection reset by peer]
gildasio1 has quit [Remote host closed the connection]