<geist>
hmm, think i finally kinda grok the trait class stuff that some folks were using in the fuchsia inclusive template container classes
<geist>
basically had to plow through it in godbolt to figure out how it works together
Ali_A has joined #osdev
scoobydoo has quit [Ping timeout: 240 seconds]
Ali_A is now known as Aragami
the_lanetly_052 has quit [Remote host closed the connection]
<Aragami>
so, I wanna write UEFI applications, I am reading the spec (however it is 2.5K pages) I am not sure which parts are relevant? my aim is two things, 1- I write a bootloader from my x64 kernel. 2- write a small UEFI application game (I was inspired by someone who wrote a game in the boot sector, so I wanted to do the same), however I am not sure what
<Aragami>
is `gnu uefi` , `gnu-uefi reduced`, `tainocore` ? I supposed that UEFI is something in the motherboard, within the hardware itself, so why do I need gnu or something else? (yes, the headers, sure but I don't understand that each one of those mean)
<geist>
you dont. you can do it manually if you want
<geist>
the gnu uefi stuff is just an existing library for you so you dont have to type in a bunch of stuff
<geist>
think of it as just a library and some build system stuff to get you to a uefi main without needing to set it up for you
<Aragami>
geist great, so where can I read about doing it without all of this extra stuff?
<geist>
what extra stuff are you talking about specifically?
<Aragami>
I understood from your message that I don't need gnu/gnu-reduced uefi or taino core as they are just wrappes, to simply the development process.
<geist>
right
<Aragami>
to simplify* the development process
<geist>
right
<Aragami>
right, so I asked where can I read about booting/writing an application without using those (those refer to gnu-reduce/tainocore etc) because every single web-page I found online used them
<geist>
you mean you dont want to use them but you awnt to start from a completely blank slate?
<geist>
(just to be precisely clear what your'e tasking)
<geist>
asking
<kazinsal>
I'm guessing they mean they want to just make UEFI calls etc from C without needing the whole smattering of gnu-efi libraries etc
<geist>
yah agreed, just want to make sure
<Aragami>
yes, assuming I can get to that with less than 500 LOC then I am up for it
<geist>
there's a bunch of refedfence to 'i dont want this extra stuff' but in reality theres a *lot* more extra stuff if you go in clean slate
<geist>
since you now have to build up the EFI environment from scratch
<geist>
you can probably get a Uefi Main in 10 lines of code, maybe 50 lines of build system, and some toolchain work (need a toolchain that can generate PE binaries, etc)
<geist>
but then you'll immediately n eed to start building up an infrastructure to communicate with the uefi hooks to do anything
<geist>
not that bad, but basically the manual you have is everything: it defines the C functions, all the UUIDs you need to query, all the interfaces you need to implement
<geist>
and part of the reason it's 2.5k pages is there's a lot of it
<geist>
i personally dont really like the GNU EFI stuff really, but it does bootstrap you ahead a lot, because basically someone else has typed in a bunch of stuff you'll have to just type in yourself
<geist>
i haven't done it from scratchmyself though, so i think someone like klange may have better advise
<Aragami>
I just usually like to understand something but building it in a crappy code, then just use the `existing libraries`
<Aragami>
by building* in a crappy from scratch code*
<kazinsal>
ironically gnu-efi is kind of the lightweight option for UEFI application support
<kazinsal>
EDK2 is a complex nightmare
<Aragami>
I thought `gnu-reduced` was supposed to be the `lightweight` inferred from the name, I don't know what goes in there.
<geist>
yeah, gnu-efi is not terribly bad per se. we had a project for fuchsia called gigaboot20x6 that used to exist in a standalone form
<geist>
that was more or less what you seek, or an example of it
<geist>
but it has since been subsumed into the fuchsia tree and hard to tease apart
<kazinsal>
reduced-gnu-efi is a third party fork iirc
<geist>
i really can't use it because GNU, so when i finally do get around to doing this i'll probably end up typing in a bunch of crap
<geist>
but not really because i want to
<kazinsal>
yeah I have no idea what license gnu-efi is under
<kazinsal>
I would assume like LGPL or something
<geist>
possibly, yeah. i know we didn't use it at work precisely because of that
<geist>
so the author of gigaboot just typed in all the headers again we needed
<Aragami>
Well, I guess that I means I must start reading the spec (I need a documentation for the documentation)
<geist>
but it wans;lt a *lot* of work
<geist>
just a lot of tedious stuff
<geist>
Aragami: suggestion: start with gnu-uefi or whatnot and get things going
<geist>
and then if you want remove it later
<Aragami>
good suggestion actually,
<geist>
it's really not a good use of your time just typing in all that stuff so you can get to hello world. that's ag reat way to get super discouraged
<geist>
because then you dont get anything working until a long ways in. if you were already experienced in it it'd be one thing
<geist>
but if you're just getting started, you really need to get your bearings in the landscape, so using an existing framework that helps you is really not a bad idea
<Aragami>
the problem is I am terrible with gnu system, and whenever I see the name gnu, I get terrified, that I will have to use the `gnu echo system`
<geist>
at the end of the day it's still you and UEFI apis. i think all the gnu-efi stuff does is provide a lot of headers and the build system magic to drive the compiler
<geist>
which is frankly the least interesting and most tediuos part of it
<geist>
but again, i dont really know the specifics
<kazinsal>
yeah, it's really the skeleton
<Aragami>
sure, thanks for the advice, I will follow it, let's see how can I get a simple UEFI app using gnu efi
<geist>
yah play with that and then see if you want to rip it out after using it
<Aragami>
(y) thanks guys!
<kazinsal>
yep. get something working and booting first so you get used to how to build for UEFI
<geist>
may turn out it doesn't really help you much and once you have something working it's easier to remove it piece at a time until you're left with just your stuff
<geist>
exactly
<kazinsal>
then yank whatever you don't want
<kazinsal>
interesting. it looks like gnu-efi might not actually be a GNU project
<kazinsal>
its homepage is just a sourceforge project
<zid>
the gnu- didn't give it away?
<zid>
oh might *not* be
<zid>
reading comprehension is hard
<kazinsal>
license appears to be BSD-like and attributes a 1998-2000 copyright to Intel
<kazinsal>
yeah, might poke at that next time I feel inspired to do a UEFI
<geist>
and if the license is BSD like then sounds like a win-win
<kazinsal>
some of the specifics of that page concern me a bit like using your host system's native compiler but I bet you could substitute in x86_64-elf-* and it'd probably work fine with a bit of tweaking
bauen1 has joined #osdev
pretty_dumm_guy has joined #osdev
_xor has quit [Quit: WeeChat 3.4.1]
Vercas has quit [Remote host closed the connection]
Vercas has joined #osdev
sortie has quit [Ping timeout: 276 seconds]
<geist>
yah
Belxjander has joined #osdev
<geist>
it at least acknolwedges it
sortie has joined #osdev
duckworld has joined #osdev
duckworld has quit [Client Quit]
duckworld has joined #osdev
vimal has joined #osdev
GeDaMo has joined #osdev
Aragami has quit [Quit: Connection closed]
Burgundy has joined #osdev
gog has joined #osdev
pretty_dumm_guy has quit [Quit: WeeChat 3.5]
pretty_dumm_guy has joined #osdev
<corecode>
hi, i guess this is a bit OT here, still trying. For an embedded application I'm wondering about using a simple protocol on top of ethernet for enumerating and addressing nodes. ip/ip4 + udp + mdns is a bit heavy
<gog>
there's DHCP/BOOTP
<corecode>
yea, still IP etc tho
<gog>
true
<corecode>
i don't need routing
<gog>
i guess use case matters most
<gog>
there are benefits to having at least a partial IP stack
<corecode>
i agree, but i'm trying to do this on fpga without a soft core
<zid>
I mean, if what you wanna do is simple, and it won't sprawl to being "ip but I made it badly" then go for it imo
<zid>
ip is the easy bit though tbh
<zid>
It's just version, length, dest, source, checksum, and protocol number that it's carrying, afaik
<zid>
and arp is pretty braindead, someone sends "who has x" and they reply "I have x" and you write down the mac
<clever>
and also because of its braindead nature, there is basically no context involved, and no way to know if you should block it in a firewall
<clever>
so arp can also be used to detect if a machine is online, even if the firewall wants to block everything
gog has quit [Ping timeout: 250 seconds]
gog has joined #osdev
bauen1 has quit [Ping timeout: 250 seconds]
bauen1 has joined #osdev
nyah has joined #osdev
<corecode>
yea but then i need to assign IPs
pretty_dumm_guy has quit [Ping timeout: 276 seconds]
Vercas has quit [Remote host closed the connection]
Vercas has joined #osdev
pretty_dumm_guy has joined #osdev
<zid>
well you need to assign some kind of address
<corecode>
yes, i was hoping for some long unique ID i could use
PapaFrog has quit [Read error: Connection reset by peer]
LostFrog has joined #osdev
<zid>
they're called mac addresses
<zid>
and the routing of traffic between them is the ethernet layer
<zid>
honestly ip is sorta busted we could have just used mac addresses all over
<zid>
but it evolved from other systems in weird ways
XgF has quit [Ping timeout: 260 seconds]
XgF has joined #osdev
<clever>
zid: and do you want to manage a global routing table based on macs?
<clever>
IP and BGP mostly solve that problem
dennis95 has joined #osdev
heat has joined #osdev
Vercas has quit [Remote host closed the connection]
<corecode>
yea i think i'll have to generate local MACs from some unique ID
Vercas has joined #osdev
<corecode>
the FPGA doesn't have a mac address, because it isn't a MAC
<corecode>
i mean, i make it into a MAC
gwizon has joined #osdev
<heat>
corecode, ip isn't that big
<heat>
like, at all
<heat>
ip + udp is like the simplest thing you can have
<heat>
1) why would you need mdns?
<heat>
if you're already getting into a spot where "oh yeah I need mdns" then doing it all in fpga might not be the best idea
<corecode>
for enumeration
<corecode>
i guess i could run a dhcp server on my custom server side
<heat>
i feel like you're trying to do too much in FPGA
<corecode>
but it just feels like a network protocol is not what is needed in this case, because it doesn't have to be routed
<heat>
what are you trying to do exactly?
<corecode>
there is a set of devices that will be connected via ethernet, and a central source (running linux) needs to detect their presence and then send data to them
<clever>
ive had plans for the same thing in the past, and wanted to use mdns/avahi to solve it
<clever>
plus dhcp
<clever>
but i didnt look into the mac addr issue
<corecode>
yea if the things already run a system that supports these protocols, sure
<corecode>
but i wonder, is there a simpler way
<corecode>
for now i'll assume that i have some unique ID stashed somewhere
<heat>
you can run a budget mdns
<corecode>
and that i can manufacture a unique mac address
<corecode>
yea, but why go through IP + UDP + mDNS (which is multicast)
<heat>
ethernet broadcast discovery packets every X seconds, clients need to reply with their unique id and ethernet address
<corecode>
heat: yea exactly
<corecode>
that's why i was wondering, is there an existing protocol
srjek has joined #osdev
<heat>
no i don't think so
<corecode>
there are some ieee 802 link layer things
<corecode>
LLDP i think?
<heat>
everything's done on top of ip usually
<heat>
corecode, hmm that looks possible yes
<heat>
then again, you don't care about interoperability
<heat>
so you might save yourself some sanity if you don't go down that route
<corecode>
yes
<corecode>
but often other people have already addressed corner cases that i don't want to painfully figure out later
<corecode>
so at least checking what other things do is required
Likorn has joined #osdev
Likorn has quit [Client Quit]
gwizon has quit [Quit: leaving]
Starfoxxes has quit [Remote host closed the connection]
vdamewood has joined #osdev
<mrvn>
Check out the network console on linux. I think that is ethernet and not IP. Might be reusable for you.
Ali_A has joined #osdev
<mrvn>
Who still has a 32bit time_t?
dude12312414 has joined #osdev
<heat>
most 4.x linux 32-bit targets
jjuran has quit [Ping timeout: 256 seconds]
jjuran has joined #osdev
<mrvn>
"this time I assure you no good will be done with the money"
pretty_d1 has joined #osdev
pretty_d1 has quit [Client Quit]
pretty_dumm_guy has quit [Ping timeout: 250 seconds]
<geist>
well first i'd double check that the low level format is compatible with PC 720k
<hbag>
?
<geist>
there's also some general issue with using HD disk drives to format 720k floppies. also using HD disks in 720k mode
<geist>
sometimes that works, sometimes it doesn't
<geist>
(on PCs at least)
<geist>
then there's the second issue that i thin kthe atari FAT is subtly different from DOS/windows FAT
<geist>
maybe in incompatible ways?
<geist>
but yeah that link up there seems pretty good
<hbag>
idk, that atari forum link says it should work fine as long as my drive is able to format like that
<geist>
right, trouble with the USB based floppy drives is i think they only understand a very narrow set of things
<geist>
i've got one too and have had mixed success for this sort of thing
<geist>
are you using an older 720k disk or a HD one?
<geist>
that's also an issue i've bumped into. the smaller head of the HD (1.44) drives writes out a little bit 'less' data because it has to fit it in tighter, and sometimes 720k drives can't read that
<hbag>
i only got HD disks laying around
<geist>
also similar, i think HD disks have a different amount of flux or whatnot
<jimbzy>
Hallo
<geist>
hola jimbzy
<jimbzy>
What's the good word in your neck of the woods?
<GeDaMo>
Why do woods have a neck? :|
<jimbzy>
Why don't you have one, GeDaMo?
<jimbzy>
;)
<GeDaMo>
I'm not a woods as far as I know :|
<jimbzy>
:|
<jimbzy>
If a woods had a neck it would probably be their roots.
<geist>
well, it stopped being quite as cold and rainy for a bit
<bslsk05>
en.wiktionary.org: neck of the woods - Wiktionary
<kingoffrance>
old windows (perhaps xp) at least, can corrupt floppies and then complain the disk is unreadable. write protect them if disks are from elsewhere :)
<kingoffrance>
or they can silently quietly trash things
<geist>
yah re: low level formatting, i think a proper PC has more control of what happens if it has a real floppy conroller chip and a floppy drive. i think the USB based ones it's up to whatever the microcontroller in the drive does
<geist>
so i think windows has far less options
Starfoxxes has joined #osdev
<GeDaMo>
Can you try formatting it from Linux?
<geist>
but thats independent of the FAT format, which i think has deviated a bit with atari, amiga, etc. probably just because they forked off an early version of the FAT FS in the 80s and then went in slightly different directions
<geist>
i can absolutely see the dos/windows fat driver not giving a shit about any sort of compatibility. it most likely assumes there is One True FAT and has no interest in trying to play nice with any other variants
<kingoffrance>
i may be misremembering, i seem to recall usb floppy i could use differently depending on: 1) plugged in at boot, hence "usb emulation" versus plugged in later, but this would vary with hardware/bios/windows versions too....
<kingoffrance>
*versus 2)
<kingoffrance>
and i dont know modern stuff if it would even try that
<geist>
yah i'm actually kinda curious now precisely what the usb floppy protocol is. it seems to be standard enough
<geist>
my guess is when it comes to whatever the FORMAT command is it probably just takes an enum of disk type
<geist>
instead of something lower level like precise layout of the sectors
<geist>
all this aside if you have any floppy disks or want to work with one, i suggest picking up one of these usb floppy things. they're cheap and i dunno if they'll be on sale forever
<heat>
geist, wouldn't it be the mass storage protocol?
<geist>
possibly? dunno precisely how FORMAT would work in this case, but i guess scsi is sufficient to describe it
<geist>
but as kingoffrance was sayign i think there may be a simpler, boot time variant of it
<heat>
i bet that would depend on the BIOS to SMI the shit out of legacy floppy accesses
<heat>
like it happens for USB keyboards and mice
<gog>
fairly sure that it works like that, and that it's all translated to scsi-like commands for the mass storage protocol
pretty_dumm_guy has joined #osdev
<gog>
but what im reading is that most USB floppies can't format 720k
<gog>
they can read and write it fine, but are not equipped to format them ?
<gog>
idk seems weird
<heat>
btw I found out how linux invalidates routes
<heat>
they just keep a counter
<heat>
when something changes, they increment it. every route cached has the current counter at the time it got looked up. before using it, they check if its up to date
<heat>
geniusly simple mechanism
<sham1>
gog: I don't see how that would even happen. Formatting should just be writing should it not?
<gog>
sham1: i was mistaken, it was that attempting to write a 720k image to a 1440k floppy on a USB drive is likely to fail but apparently there's a way to do it
<gog>
and also that most USB floppies support 720k mode
<heat>
what's better? have a single API with a bit more complexity or two simpler APIs
<heat>
i'm rethinking my network configuration API and I need a way to pass both AF_INET and AF_INET6 addresses
<heat>
a struct sockaddr would work but that makes the API worse (variable struct sizes, and sockaddr is just worse to work with overall vs raw address types)
mahmutov has quit [Ping timeout: 276 seconds]
mahmutov has joined #osdev
GeDaMo has quit [Remote host closed the connection]
<mrvn>
gog: The 1.44 floppy head has a thinner track so it formats the middle of the magnetic strip but not the sides.