elastic_dog has quit [Remote host closed the connection]
elastic_dog has joined #osdev
<kof123>
"your BMC onboard and the HDD / SSD have their internal on device microcontroller that is a full SoC with its own operating system " not going to defend pike or cantrill, but how is this the fault of "software people" ?
<kof123>
if anything this implies multiple layers of "software people" not coordinating, if "holisticness" was the goal
<kof123>
which is roughly what cantrill seems to have said from the blurb: "why we believe that this approach is increasingly viable in an all-open world -- and what we need out of CPU vendors to support such systems"
<kof123>
likewise pike's paper was about commercialization taking over research
<kof123>
it seems like disagreement for the sake of disagreement, because someone on wrong "team" said something, even if i "agree" with it, aka tribalism
<kof123>
the sw people blame the hw, the hw people blame the sw, the app people blame the os vendor, round and round it goes
<kof123>
no wonder nothing gets fixed
smeso has quit [Quit: smeso]
<Clockface>
in linux user mode processes, how do the events work when an event happens while another event is being handled
<Clockface>
i know on some microcontrollers, it que's up the interrupts and handles it after its done with the first one
<Clockface>
and i hope linux has the same behavior
<Clockface>
with its events
<Clockface>
if windows does that as well, it would be ideal, but i can live with it only being linux
<Clockface>
oh, sorry
<Clockface>
"signals"
<Clockface>
sorry
<Clockface>
finally found decent post on WWW
<Clockface>
it does
<Clockface>
:D
smeso has joined #osdev
bradd has joined #osdev
GreaseMonkey has quit [Remote host closed the connection]
gildasio2 has quit [Remote host closed the connection]
gildasio2 has joined #osdev
<geist>
yeah
<geist>
you pretty much got it
gorgonical has quit [Remote host closed the connection]
heat has joined #osdev
hmmmm has quit [Ping timeout: 255 seconds]
gildasio2 has quit [Ping timeout: 255 seconds]
gildasio2 has joined #osdev
hmmmm has joined #osdev
<Jari--_>
hi
heat has quit [Ping timeout: 248 seconds]
* geist
waves
danilogondolfo has joined #osdev
GreaseMonkey has joined #osdev
* sham1
particles
gog has joined #osdev
jeaye has quit [Ping timeout: 260 seconds]
<dinkelhacker>
Is there a way to detect the start of physical memory on boards like the pi where you don't have a bios?
<dinkelhacker>
Or do you just assume that if the kernel got loaded to 0x800000 that it starts at 0x0?
<gog>
i think device tree has that information?
<gog>
there's also UEFI tables
<gog>
for firmwares that implement UEFI
jeaye has joined #osdev
<epony>
kof123, the point is.. software people believe they are programming the computer, while they are programming part of a complex CPU-series, so.. believing that it's an OS is strongly contended as an application that behaves like on aoperating system on a part of a CPU, with partial functionality.. thus losing the machine, and that's your providers and your software people, not talking to each other.. and not being able to talk to each other, non-standard and
<epony>
non-modular but "unique" and "complex-bundle-as-a-unit" componentisation.. the whole or partial system is orthogonal, does not addess anything, and is therefore completely stupid of an argument in favour of the SoC and Uni-Vendor lock-in/permit-some view, which is what proprietary and business middleware vendors want and do, but that is absolutely the OPPOSITE of what is open and standards and interchangeable and reliable long term → so is not no tribalism
<epony>
, but "take your corporate approach and see what you can do with it, because the rest of the wolrd said it's WRONG"
<dinkelhacker>
gog: You're right. I got a memory field in the device tree. Is it "normal" that it doesn't tell how big it is reg = <0x00 0x40000000 0x01 0x00>;
<kof123>
thank you for reply. i actually agree with that but: "take your corporate approach" "rest of the world" -- where is this imaginary "rest of the world" ?
* kof123
<cricket sounds>
<kof123>
there was a guy who came in here about designing a CPU IIRC ...got told he was crazy IIRC
<epony>
this said the Cantrill is not anything of a factor what systems are doing, and neither is the Pike, they are both "commercial vendor lock-in Sun fail / Google fail" on independent and sustainable computing
<epony>
that kind of views are "in the commerce for our variant of commerce" and not about "systems design"
<epony>
such teachings can not be accepted
<kof123>
i dont know where i sit on that, but i respect if you want to make a sharp divide
<epony>
well, the rest of the world is the so called "open architecture" and "standards" rather than "vendors", which eliminates the need to "control the entire system" or the "holistic approach" is probably more of a "we want to be able to program it all" which is not happening with the SoC approach on a hardware level.. the point is to have standards and modular-composable independent replacement parts which can be prgorammed fully, so that means basically what "open
<epony>
architecture" and "standards" could and definitely should provide
<kof123>
yeah, makes sense
<epony>
no, the divide is made by companies like Sun and Apple who create slightly incompatible hardare and take it all "holistic" but in the end disappear
<kof123>
well, chicken and egg. do things start out "incompatible" or "compatible"
<epony>
that's what standards and modularity address
<epony>
licensing and proprietary cores and IP protected and firmware secrets are the opposite of that, despite being able to co-exist, that gets "bundle-used" and at the hardware level.. results in inability to program such computers, breaking them off the standards and compliance with the efforts of "many" independents
<epony>
so holistic means "non-standard" in the end
<epony>
and who gets to set the standards.. are decisions between academic and implementer (which are clients of the academic) cooperation
slidercrank has joined #osdev
<kof123>
dont want to get too far off-topic, i think is fine for now, reminds me of: https://www.wired.com/story/tiktok-platforms-cory-doctorow/ (i.e. his theory seems to be there is, or develops, a contradiction between 1) what user requests voluntarily 2) what people paying for primary placement want the user to see ) and that eventually such things destroy themselves, as it were (at least from POV of some users, yet might still linger f
<kof123>
a long while)
<bslsk05>
www.wired.com: The ‘Enshittification’ of TikTok | WIRED
<epony>
cory is a writer of fiction ;-)
<kof123>
well, not familiar with him, i vaguely recall something else he wrote that i thought was "wrong"
<kof123>
any link or person i quote should not be considered an endorsement ;)
<epony>
reasoning and rationale for social and related to technical aspects are interesting interpretations in the fictional and literary domain..
<dinkelhacker>
gog: nvm I should have read how the memory node is constructed in device tree^^
GeDaMo has joined #osdev
<epony>
proselitising on the "we want full control at the software level" is fine too, but it misses the point completely and turns it into "pleading for support for full-stack commercial ownage", which is an anti-solution
<epony>
open being 'accessible' and 'independent implementation' suitable
Sos has joined #osdev
<gog>
mew
* moon-child
pets gog
* kof123
gives gog coffee
bauen1 has quit [Ping timeout: 248 seconds]
fedorafan has joined #osdev
Burgundy has joined #osdev
* epony
puts on vader's welding mask
Burgundy has left #osdev [#osdev]
* epony
awards standards manuals (can't take the shit blowback from kids not eating their serials any more without an fully operational armory)
heat has joined #osdev
<heat>
dinkelhacker, you're supposed to interpret reg according to address-cells and size-cells
<kof123>
"which are clients of the academic" that is fine, but i think american education is 180. there's $, and $, and $. which universities run on all open hw and sw ? <crickets>
<kof123>
*at any level
<epony>
DDT solves cricket problems..
<epony>
^ the holistic approach
<epony>
(gene modified seeds and specialised herbicides for them)
<epony>
what focking education, people are left with YT and commerce handing them marketing leaflets
<epony>
complete and utter idiocracy at a late stage development
<epony>
so.. the standards are never going away ;-) they become more important with each "battle of incompatible whole foods whole moods"
<kof123>
i thought UEFI *was* sold as the "holistic" solution
<epony>
it's a BIOS replacement.. into a BIOSv2 etc
<epony>
there are going to be iterative stages for these components, but the architecture and separation of tasks and stages is not getting suddently changed or replaced outside miniaturisation and retained capability
<heat>
EFI is everything but holistic
<epony>
more like, there are experimental proposals and embedded systems here and there, but the big organisation of computing retains the modular-composable machine construction principles
<epony>
it's just part of a system
<heat>
it's designed for proprietary IP blocks and tiny modules from many vendors
<epony>
have no fear, with time, shortcomings and closed / proprietary prats open up or get replaced by better designs
<epony>
there are recurring "trials" to "re-grab" part of the system components and "own more of it all" at least in small chunks that are ordered and aligned together as "vendor secret sauce platform of superiority"
<epony>
and sell that as holistic programming "platform" but in reality it's just a 1 model
<epony>
bundled-in-as-a-platform which it isn't.. sales confirm
<kof123>
i guess it is difficult for me to take any hard stance because i see 1) "openness" sufficient for whoever 2) language things are written in 3) toolchain , ... and then equivalents on hw side
<kof123>
or those are all things i would think about, anyways
<epony>
it starts from the hardware, then this hardware is used to design new hardware, then software makes a case improvements are needed, it repeats
<kof123>
e.g. rust rightly or wrongly saying C is no ABI etc.
<kof123>
is what i mean by 2) as well
<epony>
in the matrix spoon-fed universe there is no rust
<kof123>
everything can be all "open" and some ppl still wont want to touch it
<epony>
fluidity is achieved by standardly interchangeable components and systems componentisation and modular-composable compatible / standards units
<epony>
that's how modelling and simulation works (from the universe to mathematics)
<epony>
better modelling, better utilisation of resources and energy
<epony>
such inefficiencies are self-stabilising when it is put into perspective of getting technological pogress forward
<epony>
an entirely "machine programming" problem in the software capacity to solve it.. and the hardware never stops as people really work on hardware as a priority.. software trails back if it can ever catch up (mostly it saturates immediately and wants more)
<epony>
now, if you think about it for a moment, firmware is a software "tooling" brought lower to the hardware and at the same time creating a new "optimisation series of tasks" to solve again, properly and accurately
<epony>
that's from the premises of minuaturisation and integration
bauen1 has joined #osdev
<kof123>
am i wrong to understand that as you seem to be saying non-open things are mathematically, fundamentally doomed?
<epony>
I think you're reading well into it
<epony>
it just gets less support and repetitive reuse / improvements and is left behind
<heat>
what res can you expect the arm64 timer to have?
<heat>
nanosecond?
<epony>
it's a modern process chip
<epony>
should be in the ps range
<epony>
it trails back by 10 years on average but now these get earlier access to smaller feature sizes
<epony>
one metric is the frequency and the other is the isntructions per cycle, the counters and their timing values should be in the CPU spec and probably are the external quartz stabilised frequency multiplied to its resolution.. and then running independently of the throttling CPU circuitry
<epony>
ns are the system memory timing ranges
<epony>
ms are the storage ranges
<epony>
some newer networking is µs range but it has high "lead wait" taime, so.. is lower than storage typically
<epony>
on the social and mass effects of production technology https://en.wikipedia.org/wiki/Technological_revolution?useskin=vector#History (which is totally calling smart phones a modern rubber books with printed images for children as toys kind of technology, addressing the pints that social writers are concerned about.. it's like radio, magazines, television, and mail order catalogues, and ads with heuristics)
<epony>
:points:
<epony>
but the actual technology gets reused in the production facilities back first and immediately, and then mass produced for the "benefits" of humanity
<epony>
treating it as "social" and "economic" is applied function and modelling, but not the actual technical aspects
antranigv has quit [Remote host closed the connection]
zhiayang has quit [Quit: oof.]
dude12312414 has joined #osdev
zhiayang has joined #osdev
Vercas has quit [Ping timeout: 255 seconds]
Vercas has joined #osdev
terminalpusher has joined #osdev
Vercas has quit [Quit: Ping timeout (120 seconds)]
Vercas has joined #osdev
craigo has joined #osdev
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
bgs has joined #osdev
gog has quit [Quit: Konversation terminated!]
rwxr-xr-x has joined #osdev
clever has quit [Ping timeout: 246 seconds]
craigo has quit [Ping timeout: 252 seconds]
elastic_dog has quit [Ping timeout: 255 seconds]
elastic_dog has joined #osdev
bgs has quit [Ping timeout: 260 seconds]
bgs has joined #osdev
xenos1984 has quit [Ping timeout: 248 seconds]
xenos1984 has joined #osdev
<mrvn>
heat: no more than 1 cycle
<mrvn>
dinkelhacker: beware that the DT has inheritance and both child and parent values, sometimes in the same line.
<rwxr-xr-x>
Anyone here familiar with Limine? I'm trying to get a framebuffer from limine using the request for it, but the issue here is I'm tyring to do it in asm. This is the current code: https://github.com/srwxr-xr-x/MinimaOS , but it isn't working, it boots and reaches line 49, and fails
qubasa has quit [Remote host closed the connection]
terminalpusher has quit [Remote host closed the connection]
<zid>
well the one thing I found out about limine and you're seemigly not doing it? heh
<zid>
which was that you request things like fb through a null terminated list in a section called .limine_reqs
Vercas has quit [Ping timeout: 255 seconds]
terminalpusher has quit [Remote host closed the connection]
terminalpusher has joined #osdev
<geist>
heat: re: arm64 timer its generally in the tens of nanoseconds to hundred nanosecond range
<geist>
ie, say 10-100mhz
<heat>
think the jitter is going to be good enough for some randomness?
<gog>
heat: heathet
<heat>
gog, grog, grozinga
<gog>
hvað segirðu
<heat>
jaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
<mrvn>
how do you want to measure the jitter?
<heat>
you don't, just take the lower bits or something
<mrvn>
lower bits of what?
<heat>
of the measurement
<heat>
it seems that our favourite GPLv2 kernel really likes using high res timers as entropy so
<mrvn>
then generating random numbers will result in increasing numbers.
<heat>
no
<heat>
this is entropy gathering, not literal get_random() {return rdtsc();}
<mrvn>
linux uses any number of potential entropy sources to churn the random bits pool.
<heat>
as of $now linux uses primarily timer jitter and CPU hw rng
<heat>
as far as I can see, at least
<heat>
definitely at early boot
<mrvn>
Not sure mixing in the timer adds any entropy. I would think it's a bit like "srand(time());" so repeated runs are different without being any more random then the last.
<heat>
it does, it's a high resolution timer, it will capture nanosecond-level jitter
<mrvn>
heat: when you request random bits and random / jittered times then adding in the timer will create entropy.
<mrvn>
But I would argue that entropy comes from the request time and not the timer.
<mrvn>
==> If you timer is a lot faster than your requests and requests intervals have jitter then you gain something.
<geist>
there is that library that uses pipeline jitter to generate entropy
<geist>
we actually use it in zircon, it's kinda neat
<raggi>
why don't you test it? patch rdtsc to return non-random thigns, see if you can demonstrate entropy loss
<mrvn>
geist: havegd?
<geist>
no idea what that is. jitterentropy
<heat>
raggi, i think the general wisedom is that adding entropy never damages things, even if that entropy is not random
<heat>
you can only get better randomness by mixing, not worse
<mrvn>
heat: entropy is always random. But adding non-entropy doesn't remove entropy.
<heat>
the deal is that Jason Donenfeld (the linux randomness guy) swore that linux did Great Mixing on randomness but then arm64 EFI KASLR has a bunch of places where it blindly trusts EFI_RNG_PROTOCOL without mixing in anything else
<heat>
this is *after he told me it would be ok to have RNG_PROTOCOL give you garbage results because linux does Great Mixing*
<heat>
so it does not and a borken RNG_PROTOCOL will give you entirely predictable KASLR
<mrvn>
PRNG doesn't work at boot. entropy has to collect first.
<zid>
heat are we playing ds rando
<zid>
I need gps
<geist>
yeah entropy at boot is a tough issue
<geist>
i've always been worried about trusting the bootloader/firmware to give you entropy that you can't verify
<heat>
linux seems to think high res timer/cycles timer + rdrand is good enough
<zid>
more entropy is always more though
<mrvn>
heat: no, it doesn't.
<zid>
you can't make an rng worse by xoring in more dubious sources
<heat>
yes it fucking does mrvn
<heat>
i was reading that code earlier this morning
<mrvn>
heat: linux estimates entropy and after it has collected a certain amount it says the randomness pool is initialized. That's way past when the kernel boots.
<froggey>
(holding out a bowl) please sir, may I have some early entropy?
<geist>
if you're willing to spend some time, something like jitterentropy like i was mentionining and hypothettically create some jitter out of air
<heat>
mrvn, question: where do you think KASLR randomness comes from?
<heat>
(hint: the entropy pool)
<epony>
a file on disk
<epony>
or NVRAM
<mrvn>
heat: the uninitiliazed, non random entropy pool and it's still marked as such.
<epony>
or just timings of pseudo-stochastic events
<heat>
that is not a thing
<epony>
heat noise and such
<mrvn>
heat: KASLR surely doesn't use the blocking randomness functions.
<heat>
random = urandom in remotely recent linux
<mrvn>
heat: and you are right, if you don't have any early source of randomness (e.g. SoCs without real time chip) then KASLR easily becomes constant.
<heat>
geist, yeah they do some of that waiting + jitter measurement if they really need more secure stuff. iirc when giving randomness to userspace
<raggi>
the only reason userspace needs more is because userspace needs more, it's greedy af
<mrvn>
and because userspace can wait
<mrvn>
Takes some 40-60s in my KVMs before the blocking randomness functions work at boot here.
<raggi>
virtio-rand ftw
<raggi>
mrvn: x86? are you also blocking rdtsc, that's a long time to wait
<mrvn>
raggi: not doing anything, ubuntu or centos kernels.
<raggi>
mrvn: that's about the qemu config, not the kernels, if you remove all entropy sources of course it takes forever, but well, don't do that, give it access to rdtsc and/or a virtio rng or whatever
terminalpusher has quit [Remote host closed the connection]
terminalpusher has joined #osdev
gorgonical has joined #osdev
<gorgonical>
I've improvised a standing desk out of boxes and spare boards for the last two weeks and I have to say while I feel more active on my feet, it sure disincentivizes you spending a lot of uninterrupted time at the screen
<geist>
yah it's a tradeoff. i like standing desks, but it really makes you want to take a break
<geist>
good for your body, less so for focus
<geist>
but then if you're at work where you're not really alowed to focus ona nything anyway, and you're just sitting around in meetings and chat and writing docs, then thumbs up
<gorgonical>
Though I definitely don't want to stand and watch youtube or listen to music here, so if I'm standing I'm gonna be working, you know? I wouldn't be standing if I didn't have to lol
joe9 has quit [Quit: leaving]
Vercas has joined #osdev
<geist>
the real trick is a more expensive sitting/standing desk
<geist>
where you can lower and raise it. then you can switch throughout the day. they're great if you take advantage of it
<geist>
but pricy
joe9 has joined #osdev
<gorgonical>
This solution is board game boxes and stuff piled on each other so I can actually take them off the desk, but it is a little weird
<gorgonical>
I saw one of those at IKEA and was shocked that even the cheap IKEA version is nearly $800
<mrvn>
You have to strap yourself into a chair that repositions your body.
<gorgonical>
Like one of those reclined chairs where the monitors are angled at you like in cyberpunk stuff?
<gorgonical>
a "
<gorgonical>
a "cockpit" of sorts?
<mrvn>
kind of.
<mrvn>
but then it should stand you up every now and then
<gorgonical>
An alternative ergonomic enforcer: you have a hardware key plugged into a powered USB bus. You have an exercise bike that powers the hub. If you stop pedaling hard enough the key powers off and your computer locks
<gorgonical>
This one's a serious question and not shitposting: I have a bunch of sd cards for the various boards. How do I keep track of which one is which? Anyone have solutions they've cooked up?
<geist>
get a little labeler and label them
<geist>
but if they're microSD it's a bit difficut
<geist>
you could put a number on each one maybe, and keep a spreadsheet
clever has joined #osdev
<gorgonical>
That's not a bad idea. Right now I have tape flags stuck to each one and I write on the tape
<gorgonical>
They have to be stuck to the very end of the card to avoid interfering with the fit
<geist>
yah i use a little labeller for various usb sticks so i can just classify them as scratch or 'os install' or whatnot
<geist>
i used to recycle them for various tasks but after a while they're so cheap may as well just get a handful and then assign each of them a different task
<geist>
so you dont have to keep digging through them to find one that's free
<gorgonical>
Exactly. I have three right now and if I get anymore I have the secondary problem of not losing all of them
<gog>
plastic box just for them
<gog>
put stickers on the box
<mrvn>
I'm thinking of making a ESP + wifi act like a SD card but download the data over the net.
<gorgonical>
You can kinda do this with u-boot tftpboot
<mrvn>
Then you can just select the content for the card via browser and boot the system.
<gorgonical>
But not if I need to actually bundle the image with u-boot
<gorgonical>
mrvn your idea is better
chibill has joined #osdev
<mrvn>
only works if you have space for the esp though.
<gog>
make the body of an sd card like a tab on the end of a cable
<gorgonical>
yes that
<gorgonical>
I was just saying they have physical sd card switchers that have these ribbon-y sdcard inserts
<geist>
oh random thing, found another riscv board that you can get ahold of that seems to immediately ship: sipeed nezha
<geist>
allwinner D1 based, ships off alibaba
<gog>
probably better than making one if you can get one
<mrvn>
gog: absolutely. but how do you fit that into a tablet?
<clever>
mrvn: ive looked into that kind of thing recently, configuring a pi0 to emulate an MSD, and then iscsi the disk from somewhere else
<gog>
ah if it has a drawer
<gorgonical>
the d1 is what's in the clockwork pi I've got
<gog>
uh idk
<clever>
mrvn: but i went a little crazy, and tried using a 128tb sparse disk image, just because i thought i could
<clever>
then i discovered that the msd-gadget in linux, only supported (at the time) the older scsi protocol, with a 32bit sector count
<geist>
gorgonical: yeah it's pretty slow, i assume, but it's a real rv64gc so can take what can get
<gorgonical>
the d1 is the ultimate target for this asm forth I won't stop talking about
<clever>
the gadget end of the msd link, truncated the size to 32bits
<gorgonical>
and I'm getting dangerously close to it working
<clever>
and 128tb is a multiple of the limit, so it claimed to be 0 sectors long
<mrvn>
clever: how did you connect the pi0 to the micor-sdcard slot?
dude12312414 has joined #osdev
<clever>
mrvn: the pi0 was emulating just a normal usb drive, with its micro-usb port
<mrvn>
clever: ahh. That I do too. but I want the same for (micro)SD
<clever>
yeah, i also want it for SD
GeDaMo has quit [Quit: That's it, you people have stood in my way long enough! I'm going to clown college!]
<clever>
most solutions i see, is just a mux to switch 1 SD between 2 hosts
<clever>
and then re-flash the card
<gorgonical>
I see sdcard extenders on adafruit
<clever>
gorgonical: but an extender doesnt let you programmatically change what is on the card
<gorgonical>
oh you mean the whole thing
<gorgonical>
yeah
<mrvn>
take the extender, cut it in the middle and wire it to some GPIO pins.
<clever>
mrvn: but emulating the SD protocol then becomes an issue
<clever>
the top speeds are either 50mhz sdr, or 50mhz ddr, on 4 pins at once
<mrvn>
clever: yes. I don't think there are cheap microcontrolers that have a controler for that.
<gorgonical>
So I'm thinking what you really want is a controller that will retarget sdcard reads to some other device
<mrvn>
you can probably build some FIFO with a few shift registers
<mrvn>
feed it 16 byte at a time via IRQ or something.
<clever>
the SD protocol is both serial and parallel at the same time
<clever>
commands are sent serialy over the CMD pin, 1 bit per clock, and expect a response within a set number of clocks
<clever>
data is sent parallel over 4 pins, either 4 bits/clock, or 8bits/clock (rising and falling)
<clever>
data does allow stalling at the start of each block
<clever>
and command replies also come back over CMD
<clever>
and similar to dram, you can send command and data in parallel i believe
<clever>
mostly just the abort command, i think
<clever>
pico would have trouble with 50mhz ddr mode, because you need to sample on the rising&falling edge, not wait for an edge, then sample on the next cycle of a desynced 125mhz clock
<mrvn>
clever: that's easily solved with a FIFO
<clever>
would either need to run at 200-400mhz?, or have proper async logic fed by an external clock
<mrvn>
you probably want to to 16x oversampling like you do for UART.
<mrvn>
s/to to/to do/
<clever>
mrvn: yeah, you could have a 4bit fifo, fed by the SD clock pin, but all of these signals are also bi-directional
rwxr-xr-x has quit [Remote host closed the connection]
<clever>
oversampling is simpler, just overclock it to death, and fix it in software
<mrvn>
too much work. better to add a few chips and then just get an IRQ every 16 byte or so.
<clever>
but that doesnt solve the CMD pin
<clever>
which needs a reply to the command within a set number of clock cycles
<mrvn>
clever: a command is 8 bit? You collect them and fire an IRQ.
<clever>
i forget how big the command is, would need to check the specs
<mrvn>
point is you get an IRQ when the command is fully there. you read it, you write the reply and the output shift register feeds the bits back.
<clever>
but that has to fully happen, within 1 cycle of a 50mhz clock
<bslsk05>
hackaday.com: The In-Circuit SD Card Switch | Hackaday
<clever>
gorgonical: thats what i refered to before, its just a mux to switch an existing card between 2 hosts
<gorgonical>
I thought so
<clever>
so you have to re-flash the card each time
<clever>
what i want, is to just point the emulator at a .img file on my nvme drive
<mrvn>
clever: you said "set number of clock cycles", not just 1,
<clever>
mrvn: i'm assuming worst case
<clever>
spi flash chips work similarly, a lot of commands respond within either 0 or 8 clocks, right after the cmd
<clever>
it would be simpler to just have an fpga to do the raw protocol, and then fifo it back to a host
<mrvn>
clever: You could make a pass through adaptor where you report a smaller card and select the upper bits of the address. So your 64GB card becomes 8 8GB cards of which you can select one at a time.
<clever>
then the fpga can hold a set of pre-configured replies, and answer instantly on its own
<mrvn>
SD to nvme adaptor should be fairly easy too
<clever>
i meant more, the nvme that a live os is running from
<clever>
build products from a CI system
<clever>
so CI can generate a disk image, and then i can immediately boot it on something
<clever>
without having to flash it to a dummy card, that is going to die after 1000 builds
<mrvn>
if in doubt just lower the clock
<clever>
yeah, some of my cards only work at 25mhz, there must be some flag bits to define that
<clever>
so i could just emulate a 25mhz card, but then performance will suffer
<clever>
have you seen the ios file in /sys, for sd cards?
<clever>
with this, you can confirm what speed any card is running at
<gorgonical>
Let's pretend that we have a microcontroller that knows SD card protocol. A read from block 0 at the slot-end (target board) needs to be transformed into a read from block 0 at sdcard.img on some other storage. If the other end is a SBC of some sort, you could have a device driver that serves the requests from whatever memory you want, right?
<clever>
gorgonical: exactly
<gorgonical>
I know this is simplifying enormously, but it seems like you should be able to get whatever SD card controllers are on the market and kind of re-route stuff
<mrvn>
does it really have to be files on an FS? partitions would be so much simpler.
<clever>
mrvn: i would want it to run under a linux based os, so it has network, and can swap images out behind the scenes
<clever>
and once linux is involved, there is no difference between files and partitions
<mrvn>
clever: linux on partition 0, partitions 1-n SD cards.
<clever>
what benefit does that have?
<mrvn>
that you can read directly from the storage, pausing the linux access to the storage for that.
<clever>
that could work, if it was some kind of smart mux, turning it into a dual-port sd card
<gorgonical>
Wow the only full-featured chip I can find is a TI chip that's on mouser for $32
<clever>
then it would show up to both systems at once, and the target gets a sub-section
<mrvn>
or just have 2 cards. one for the OS to flash the other via network.
<clever>
gorgonical: main issue i can see with that idea, is that those chips tend to expect raw nand flash, and also implement flash sector mapping (wear leveling)
<mrvn>
or keep the OS on flash
<clever>
mrvn: but thats still back to the same problem, your burning the CI image to an SD card on every build, and its going to die eventually
<gorgonical>
I have just got the datasheet but it looks like this chip is just a controller SOC. I don't know how it expects to serve reads
<clever>
where, if it was just a file on linux, you could use a mechanical hdd, or nvme, something with a longer lifespan
<mrvn>
clever: you can fit a ton of CI images on a big SD card and then just select the one you need. Or keep the image in ram.
<clever>
yeah, but images in ram are basically the same as files
<mrvn>
ram the SD controler can read from directly.
<clever>
ah, thats diff
<mrvn>
No need to have non-volatile storage for CI images. Just load the image into some ram and have that be the SD card while the power is on.
<clever>
yeah
<mrvn>
or is there a cmd reply "working on it, I need some more time"?
<clever>
i just think an fpga would be a far cheaper way of emulating an sd card, vs trying to get one of those controllers with limited documentation to co-operate
<clever>
data blocks (storage read/write) have a stall phase at the start
<clever>
where the card can delay as long as it wants
<mrvn>
ahh, that solves the problem.
<clever>
commands however, must reply in a fixed time
<mrvn>
So you just need a FIQ handler that handles normal commands and stalls on data. Add FIFO for one whole block and the FIQ handler tells linux when to load/store blocks from the FS into the FIFO.-
<clever>
an fpga could be pre-programmed with all possible replies, and then forward read/write to the host
<mrvn>
an fpga probably has enough internal storage to cache blocks.
<clever>
they often have about 500kbyte of ram
<mrvn>
plenty for a small cache
<clever>
and support dram
<mrvn>
So yeah, you can stuff it all into the fpga and have linux just fill in cache misses.
<clever>
yep
<clever>
and you could just have usb2/3 back to linux
<mrvn>
I have a dozen FIPS fpgas that could probably do that.