alexander has quit [Quit: ZNC 1.8.2+deb3.1 - https://znc.in]
alexander has joined #osdev
netbsduser has quit [Ping timeout: 250 seconds]
pieguy128 has joined #osdev
Left_Turn has joined #osdev
tomith has quit [Read error: Connection reset by peer]
zxrom has quit [Quit: Leaving]
[itchyjunk] has joined #osdev
goliath has joined #osdev
Left_Turn has quit [Remote host closed the connection]
Left_Turn has joined #osdev
gildasio has quit [Quit: WeeChat 4.0.2]
wootehfoot has joined #osdev
netbsduser has joined #osdev
mahk has quit [Ping timeout: 244 seconds]
kfv has joined #osdev
kfv has quit [Client Quit]
wootehfoot has quit [Read error: Connection reset by peer]
gog has joined #osdev
Hammdist has quit [Ping timeout: 246 seconds]
stolen has quit [Quit: Connection closed for inactivity]
antranigv has quit [Ping timeout: 246 seconds]
Hammdist has joined #osdev
antranigv has joined #osdev
lg has joined #osdev
k0valski188916 has quit [Quit: Peace out !]
netbsduser has quit [Read error: Connection reset by peer]
Hammdist has quit [Ping timeout: 246 seconds]
Hammdist has joined #osdev
<mcrod>
hi
<Ermine>
hi
<Ermine>
gog: may I pet you
<gog>
yes
* Ermine
pets gog
* gog
prr
<mcrod>
gog may I also pet you
mahk has joined #osdev
terminalpusher has joined #osdev
<gog>
mcrod: yes
* mcrod
pets gog
Hammdist has quit [Ping timeout: 246 seconds]
Nixkernal has joined #osdev
apokryptein has joined #osdev
Jackneill has joined #osdev
SGautam has quit [Quit: Connection closed for inactivity]
Hammdist has joined #osdev
alexander has quit [Quit: ZNC 1.8.2+deb3.1 - https://znc.in]
Mikaku has joined #osdev
wootehfoot has joined #osdev
alexander has joined #osdev
dude12312414 has joined #osdev
dude12312414 has quit [Remote host closed the connection]
<Hammdist>
I'm finding the need to add a gdb stub to my hobby kernel, to be able to debug it more efficiently. anyone have recommendations for something I can just link in and it will simply work? aarch64 platform
<heat>
zid, 2day i saw all the british lads in the algarve pubs drinking pints and watching footie
<heat>
and i realised i've been british all along
<mcrod>
heat: hi
<heat>
hi hi
<heat>
linux kernel operating system!!
<sham1>
GNU+Linux kernel operating system
<heat>
GNU SLASH LINUX KERNEL
<moon-child>
develope kernal
<heat>
operating syste
<heat>
operate system proletariat vs kernal bourgeoisie
GeDaMo has quit [Quit: That's it, you people have stood in my way long enough! I'm going to clown college!]
<flom84>
in weekend I only believe in SteamOS from Saint Gaben
SGautam has joined #osdev
pyzozord has joined #osdev
<pyzozord>
heh, does anyone know how can i disassemble this kernel image? https://bellard.org/jslinux/kernel-x86.bin I tried with objdump -D, but I'm getting "file format not recognized"
antranigv has quit [Ping timeout: 245 seconds]
<pyzozord>
*hey
<heat>
pyzozord, is that a linux kernel image?
<pyzozord>
I think so
<heat>
those images have a special compressed format
<heat>
doing objdump over a "flat binary" will only disassemble the decompressor
<pyzozord>
file says "kernel-x86.bin: Linux kernel x86 boot executable bzImage, version 4.12.0-rc6-g48ec1f0-dirty (bellard@localhost.localdomain) #21 Fri Aug 4 21:02:28 CEST 2017, RO-rootFS, swap_dev 0X4, Normal VGA"
<heat>
there's a script in linux.git named extract-vmlinux that /may/ help
<pyzozord>
I'm not even sure what "decompressor" is tbh
<clever>
yeah, its basically a self-extracting binary
<clever>
there is some PIC assembly, that will decompress the real kernel, setup the mmu, turn it on, and then jump to the real kernel entry-point
<heat>
what clever said, in a slightly portuguese accent
<clever>
aarch64 linux just banned that mess, the bootloader is responsible for undoing the compression, which tends to just be regular old gzip or bzip2
<bslsk05>
bellard.org: Analog and Digital TV (DVB-T) Signal Generation
<pyzozord>
he's the guy responsible for ffmpeg, qemu, tcc and bunch of other stuff
<clever>
dang
<clever>
he's started basically everything :P
<pyzozord>
yeah, his stuff is really good, but his tinyemu project sort of feels like a weekend entertainment because it's basically lacking any documentation
<pyzozord>
i'm sure it's good, it always is, but i can't figure it out without digging deep into the code. I know c, but i'm not not experienced enough with the os/lowlevel stuff to read this code fluently
<heat>
i started everything
<heat>
worship me
* moon-child
turns on stove
<moon-child>
i started heat
<heat>
but heat started the moon
<heat>
what now old man
<heat>
*moon
<pyzozord>
so i thought maybe if i'd look at the disassembly of the kernel it would give me an idea what's the next step, but that's probably a long shot
<heat>
why
<pyzozord>
any advice how to figure out how this tinyemu project works? Essentially I wanna just make a small LFS to be used with tinyemu
<heat>
that's completely orthogonal to tinyemu
<pyzozord>
yeah i don't know, i was wondering what was it and how it worked
<heat>
looks like an emulator alright
<pyzozord>
i mean that bin file, since then i learned it was actually a linux kernel, but i never looked at kernel images and have no clue how they work, beyond some very vague idea about lookup tables for memory, files and pretty much everything
<heat>
i dont know what kind of info you want
<pyzozord>
i looked at the source, but it's not clear what fields and avlues can go into the cfg file
<heat>
the kernel is an important privileged program on which all other programs rely
<bslsk05>
github.com: seabios/src/hw/virtio-blk.c at master · coreboot/seabios · GitHub
<clever>
pyzozord: allows access to a virtio disk drive under an emulator
<pyzozord>
i figured, but what does "allow access" mean specifically, this is not device driver is it? Device driver are os level things, and this is bios, before an os loads
<heat>
it is a driver
<pyzozord>
interesting
<clever>
the bios still needs drivers
<heat>
BIOSes are like kernels but lower level
<pyzozord>
so drivers are loaded in bios and then another driver for the same device is loaded in os?
<clever>
yeah
<pyzozord>
oh it's just a driver for the internal usage of the bios?
<clever>
yeah
<heat>
yes
<pyzozord>
the os will not talk to bios's drivers?
<heat>
not usually
<pyzozord>
does the os talk to bios at all?
<heat>
sometimes
<heat>
Depends(tm)
<pyzozord>
how and why, and when?
<clever>
windows 95 did a lot, when it lacked its own drivers
<heat>
EFI systems use it for variable services and some other small details
<clever>
but it had to switch back to realmode for every action
<heat>
using some arcane mechanisms and function calls
<heat>
also what clever said
<heat>
arm does it for a lot of stuff too, PSCI at least
<heat>
oh and a lot of x86 power management is basically the BIOS's doing
<pyzozord>
so can i think of bios like an os's os?
<clever>
efi runtime services are just regular old function calls (with the MS ABI), they should already be mapped into the kernels virtual space
<heat>
pyzozord, sometimes
<heat>
<heat> sometimes
<heat>
<heat> Depends(tm)
<pyzozord>
like bios has some "kernel" and "user" modes and the bios user mode is where the linux kernel runs
<heat>
no
<heat>
i mean yes
<heat>
and no
<heat>
fucking hell this is complicated
<heat>
some firmware has some ideas of privilege and you actively need to use it
<heat>
some firmware has some ideas of hiding hardware details for you and you actively need to use it
<pyzozord>
can you rephrase that? i couldn't quite understand it
<heat>
what bit?
<pyzozord>
last two messages
<clever>
pyzozord: x86 is a giant tangled mess of legacy ontop of legacy
<heat>
and arm
<heat>
its the same shit there
<clever>
heat: arm isnt as much of a mess, from what ive seen
<heat>
what firmware does or doesn't do isn't a static idea
<clever>
you arent booting in 8086 emulation mode, lol
<pyzozord>
i know it's mess and it has rings like tree trunks :P
<clever>
an aarch64 cpu just boots directly in aarch64 mode
<heat>
back in the days it just initialized some minimal stuff and loaded the kernel from disk and that was it
<heat>
in x86
<pyzozord>
i'm just looking for some very general intuition because i have none
<heat>
the "BIOS"
<pyzozord>
what do you mean by "initialied stuff"
<heat>
now it's a huge many-MB mess that completely initializes your very complicated motherboard and memory and CPU and disk controller, loads your kernel from disk, can read filesystems, access the network, and store data in flash
<heat>
pyzozord, configures
<pyzozord>
do you mean it sent messages on the device bus to wake devices up?
<clever>
arm PSCI, is basically a protocol for talking to a hypervisor or secure-monitor (similar to x86 smm), and doing certain operations
<heat>
that's not exactly how things work but in principle yes
<heat>
much of your hardware isn't usable exactly on RESET
<clever>
ive been having trouble with hdmi bringup, one whole bank of control registers are just missing from the bus
<clever>
all 32bit reads return "dbus", all writes are ignored
<heat>
like if you assert your RESET# from a cold boot, your chipset isn't usable, none of your PCI devices and buses are usable, your RAM isn't usable
<pyzozord>
i know it's got a brain damage, it needs a reset signal after it got power to clean the memory and stuff
<heat>
heck, your CPU isn't usable
<heat>
you need a simpler co-processor for your CPU to become fucking usable
<pyzozord>
yeah i know, because caches and ram are random
<clever>
older x86 cpu's could run code from rom, and use a register only compiler, to bringup ram
<heat>
no, not random
<heat>
it just doesn't work
<clever>
newer x86 need a whole co-processor with its own sram
<heat>
it needs configuration and calibration using arcane methods
<heat>
huge blobs of code
<heat>
clever, no, you just need the cache
<pyzozord>
i'm lost, what needs a coprocess, the processor?
<heat>
yes
<heat>
to boot itself
<heat>
you have several processors in your mobo btw
<heat>
probably 5 or 6
<pyzozord>
ok, what does the coprocessor do when it boots the processor?
<heat>
INTEL(R) CONFIDENTIAL
<pyzozord>
i know there are many chips
<pyzozord>
oh so it's unclear huh
<heat>
yes
<pyzozord>
there ought to be completey open hardware that explains what it does somewhere, no?
<clever>
the rpi is similar, but ive been working on discovering and documenting all of that
<heat>
no
<heat>
open technology is usually simple and boring
<heat>
complex technology is closed
<pyzozord>
simple and boring sounds great to me, but we digress
<heat>
no its horrendous
<pyzozord>
it's ok, i like horrendous
<pyzozord>
anyway I'm trying to understand what does bios do a bit more indepth than just words "sets up stuff"
<mjg>
ey heat, guess what DOES NOT SCALE
<pyzozord>
if you guys have some better intuitions about it, i'd appriciate it
<pyzozord>
heat: hmm ok, then before that, what is the difference between bios and uefi?
<geist>
pyzozord: we generally do, in the sense that a lot of us know about what it needs to do, but the details are exactly that, detail
<geist>
and what it's precisely doing is highly hardware dependent, but that's the point: it abstracts a lot o those details so that you dont have to
<heat>
BIOS and UEFI are both firmware (or coloquially, BIOSes)
<heat>
BIOS is a huge horrendous blob of various messy copy-pasted-over-time-reverse-engineered shit
<heat>
UEFI is a huger less-horrendous blob of various messy copy-pasted-over-time-very-overengineered shit
<heat>
EFI is modern, BIOS is very obsolete
<geist>
at a distance they both do basically the same thing, however
<heat>
yeah
<heat>
if "haha it booooooooootz" is your PoV, then they both do the same thing
<geist>
yeah, i mean that just to establish the parameters
<pyzozord>
that's the thing I'd like to shorten the distance a bit, not all the way though with a magnifing glass
<pyzozord>
just do the next step
<pyzozord>
heat: i know this much, i'm looking for a bit more
<pyzozord>
is it safe to say that BIOS had similar stages to UEFI?
<heat>
probably
<heat>
coreboot also has stages
<heat>
it had to evolve out of something innit
<geist>
yah ad keep in mind early bioses versus later bioses were probably much more complicated
Hammdist has quit [Ping timeout: 246 seconds]
<geist>
if nothing else because there was a lot more hardware to set up, more complicated hardware, and the inevitable march of time lead to more complicated implementations
<geist>
er i mean later bioses were more complicated (had the original backwards)
<pyzozord>
what is PEI?
<pyzozord>
oh nevermind it's just "Pre-EFI Initialization"
<geist>
yah PEI is probably a black box of 'get hardware to some known state so more generic EFI bits can run'
<heat>
yes
<heat>
conventionally PEI trained RAM and did some really early chipset init
<heat>
PCIe link training, etc
<geist>
and that particular black box may be largely written by intel or AMD
<heat>
yes, exactly
<geist>
like AMD AEGSA, and intels thing
<heat>
yeah
<pyzozord>
Oh ok cool "The UEFI hands off to the operating system (OS) after ExitBootServices() is executed. A UEFI compatible OS is now responsible for exiting boot services triggering the firmware to unload all no longer needed code and data, leaving only runtime services code/data, e.g. SMM and ACPI.[86] A typical modern OS will prefer to use its own programs (such as kernel drivers) to control hardware devices. "
<heat>
"nowadays" since DXE never runs on e.g S3 resume, you need to run a lot of stuff in PEI
<pyzozord>
so it's sort of like i said it's os's os, except there is no super special mode for kernel's kernel
hrberg has quit [Ping timeout: 256 seconds]
<pyzozord>
both uefi and os kernel run simply in the processor's kernel mode
<heat>
S3 resume is basically SEC -> PEI -> unlock lockbox, resume according to boot script
<pyzozord>
the 0 ring or whatever it's called
<heat>
ohno!
<heat>
there's a special mode for the firmware that's always resident
<heat>
SMM
<heat>
it does $magic but now also does $security
<pyzozord>
what are SMM and ACPI?
<heat>
hey you should google this stuff
<heat>
im not against answering questions but if you're going to go on a question tangent this becomes really tiring
<pyzozord>
google says "Social Media Marketing"
<heat>
SMM x86
<heat>
SMM firmware
<pyzozord>
ok thank you
<pyzozord>
when you say "question tangent" what do you mean? not sure which part is tiring and i should avoid
<pyzozord>
do you mean "too many questoins" or "too many questions out unrelated to the main problem"
<pyzozord>
ok i take it as "too many questions" in general. Thanks for help. I'll come back later
pyzozord has left #osdev [#osdev]
<PapaFrog>
I'm trying to use int 13, 2 to load 576k from a floppy into memory from 0x10000 to 0xa0000, but BIOS refuses to write to the memory from 126k to 128k.
<PapaFrog>
Any ideas on why this would happen?
<zid>
Your numbers don't add up
<PapaFrog>
Which number?
<PapaFrog>
64k to 640k is 576k
<heat>
fuck he left
stolen has quit [Quit: Connection closed for inactivity]
<heat>
well pyzozord, if you're reading the log, i meant that asking really generic questions and asking for MOAR DETAIL isn't particularly easy
[itchyjunk] has quit [Ping timeout: 256 seconds]
<heat>
and if the answer gives you terms like ACPI or SMM I'd expect you to search for them real quick before just asking what they are
<heat>
like, it's not helpful and it's actively exhausting to explain *everything*
<zid>
heat have you seen my lighter
<heat>
like, you're popping up here and asking "explain firmware" which is, erm, time consuming and hard
<heat>
zid, no
<heat>
don't smoke
<heat>
thanks
<heat>
bad for your health
<zid>
not what I asked
<heat>
well i did answer
saberia has joined #osdev
[itchyjunk] has joined #osdev
Vercas has quit [Remote host closed the connection]
Vercas has joined #osdev
<sham1>
You can use a lighter for things other than just smoking
Gooberpatrol66 has quit [Ping timeout: 244 seconds]