Sunday, 2022-05-29

*** tpb <[email protected]> has joined #litex00:00
*** _embargo_ <_embargo_!embargo@user/embargo> has joined #litex01:21
*** embargo <embargo!embargo@user/embargo> has quit IRC (Ping timeout: 260 seconds)01:24
*** Degi <[email protected]> has quit IRC (Ping timeout: 258 seconds)03:28
*** Degi <[email protected]> has joined #litex03:29
*** Quarka35 <[email protected]> has joined #litex07:46
*** Quarka35 <[email protected]> has quit IRC (Quit: Client closed)08:06
*** lambda <[email protected]> has quit IRC (Quit: WeeChat 3.5)12:09
*** lambda <[email protected]> has joined #litex12:10
*** Degi <[email protected]> has quit IRC (Ping timeout: 258 seconds)14:16
somlogeertu: 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:15:49
somlo[linux]$ grep -r lv1_storage_read15:56
somlodrivers/scsi/ps3rom.c:res = lv1_storage_read(dev->sbd.dev_id,15:56
somlodrivers/block/ps3disk.c:res = lv1_storage_read(dev->sbd.dev_id, region_id,15:56
somlodrivers/ps3/ps3stor_lib.c:    : lv1_storage_read(dev->sbd.dev_id, region_id,15:56
somloarch/powerpc/platforms/ps3/device-init.c:    : lv1_storage_read(dev->sbd.dev_id, 0, 0, 1, 0, lpar,15:56
somloso what am I missing, and where does `lv1_storage_read()` actually come from ?15:56
geertusomlo: They're defined using macros in arch/powerpc/include/asm/lv1call.h18:58
geertuThese are all calls into the lv1 hypervisor, for which no documentation is publicly available.18:58
jevinskie[m]Heh let me find some RE docs. It’s a nice HV interface tbh19:02
jevinskie[m]https://www.psdevwiki.com/ps3/HV_Syscall_Reference#lv1_storage_read19:03
jevinskie[m]Wasn’t expecting to find lv1 references here :P19:04
somlogeertu: 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 :)20:05
somloI'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 :)20:07
somloso 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 drivers20:09
somlomaybe 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 :)20:11
*** zjason` <zjason`[email protected]> has joined #litex20:28
*** zjason <[email protected]> has quit IRC (Ping timeout: 276 seconds)20:30
*** tedh_ <[email protected]> has quit IRC (Remote host closed the connection)21:14
*** tedh_ <[email protected]> has joined #litex21:14
somlosuccessfully mount a liteSATA partition in linux (read-only for now, driver still contains crazy hacks): https://pastebin.com/eEt4LXsM22:43
tpbTitle: [...][ 0.967604] Unpacking initramfs...[ 1.238658] LiteX SoC Controlle - Pastebin.com (at pastebin.com)22:43

Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!