_florent_ changed the topic of #litex to: LiteX FPGA SoC builder and Cores / Github : https://github.com/enjoy-digital, https://github.com/litex-hub / Logs: https://libera.irclog.whitequark.org/litex
tpb has quit [Remote host closed the connection]
tpb has joined #litex
_embargo_ has joined #litex
embargo has quit [Ping timeout: 260 seconds]
Degi has quit [Ping timeout: 258 seconds]
Degi has joined #litex
Quarka35 has joined #litex
Quarka35 has quit [Quit: Client closed]
lambda has quit [Quit: WeeChat 3.5]
lambda has joined #litex
Degi has quit [Ping timeout: 258 seconds]
<somlo> geertu: reading through drivers/block/ps3disk.c for possible inspiration for litesata... If I `grep -r lv1_storage_read` in the top-level kernel source directory, I can't find the place where it's actually defined:
<somlo> [linux]$ grep -r lv1_storage_read
<somlo> drivers/scsi/ps3rom.c:res = lv1_storage_read(dev->sbd.dev_id,
<somlo> drivers/block/ps3disk.c:res = lv1_storage_read(dev->sbd.dev_id, region_id,
<somlo> arch/powerpc/platforms/ps3/device-init.c: : lv1_storage_read(dev->sbd.dev_id, 0, 0, 1, 0, lpar,
<somlo> drivers/ps3/ps3stor_lib.c: : lv1_storage_read(dev->sbd.dev_id, region_id,
<somlo> so what am I missing, and where does `lv1_storage_read()` actually come from ?
<geertu> somlo: They're defined using macros in arch/powerpc/include/asm/lv1call.h
<geertu> These are all calls into the lv1 hypervisor, for which no documentation is publicly available.
<jevinskie[m]> Heh let me find some RE docs. It’s a nice HV interface tbh
<jevinskie[m]> Wasn’t expecting to find lv1 references here :P
<somlo> geertu: ok, thanks! I was trying to figure out the distinction between implementing a block device using `blk_mq_alloc_sq_tag_set()` and a `queue_rq()` method as part of a `blk_mq_ops()` structure (the way ps3disk.c does it) and using `disk->fops` and the `submit_bio` method like e.g. n64cart.c and brd.c, but got lost in all the black magic :)
<somlo> I'm currently doing the latter, and it kinda sorta works *sometimes* -- but dd-ing things from the disk returns data with weird sector-sized offsets from where it *should* be :)
<somlo> so the current job is to decide whether to debug (figure out what's wrong with my current approach) or whether to comprehend the distinction between what I'm currently trying to do and the `queue_rq` method employed by a bunch of other drivers
<somlo> maybe if I find a device that uses `queue_rq` where I can also get an obvious example of where it all boils down to DMA-ing sectors to/from the actual disk :)
zjason` has joined #litex
zjason has quit [Ping timeout: 276 seconds]
tedh_ has quit [Remote host closed the connection]
tedh_ has joined #litex
<somlo> successfully mount a liteSATA partition in linux (read-only for now, driver still contains crazy hacks): https://pastebin.com/eEt4LXsM
<tpb> Title: [...][ 0.967604] Unpacking initramfs...[ 1.238658] LiteX SoC Controlle - Pastebin.com (at pastebin.com)