ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
rcf has joined #dri-devel
warpme_____ has quit []
iive has quit [Quit: They came for me...]
pcercuei has quit [Quit: dodo]
luc4 has joined #dri-devel
jernej- has quit []
jernej has joined #dri-devel
co1umbarius has joined #dri-devel
columbarius has quit [Ping timeout: 480 seconds]
luc4 has quit [Ping timeout: 480 seconds]
camus has joined #dri-devel
camus1 has quit [Read error: Connection reset by peer]
YuGiOhJCJ has joined #dri-devel
heat has quit [Remote host closed the connection]
heat has joined #dri-devel
heat has quit [Remote host closed the connection]
YuGiOhJCJ has quit [Remote host closed the connection]
YuGiOhJCJ has joined #dri-devel
TMM has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
TMM has joined #dri-devel
Company has quit [Quit: Leaving]
aravind has joined #dri-devel
bmodem has joined #dri-devel
anholt has joined #dri-devel
JohnnyonF has quit [Ping timeout: 480 seconds]
aravind has quit [Ping timeout: 480 seconds]
aravind has joined #dri-devel
aravind has quit [Ping timeout: 480 seconds]
srslypascal has quit [Ping timeout: 480 seconds]
srslypascal has joined #dri-devel
srslypascal has quit [Remote host closed the connection]
srslypascal has joined #dri-devel
rcf has quit [Ping timeout: 480 seconds]
shankaru has joined #dri-devel
aravind has joined #dri-devel
rcf has joined #dri-devel
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
rcf has quit [Ping timeout: 480 seconds]
Akari has quit [Quit: segmentation fault (core dumped)]
Danct12 has joined #dri-devel
Daanct12 has quit [Remote host closed the connection]
rasterman has joined #dri-devel
rcf has joined #dri-devel
srslypascal is now known as Guest450
srslypascal has joined #dri-devel
srslypascal has joined #dri-devel
Guest450 has quit [Ping timeout: 480 seconds]
maxzor has joined #dri-devel
Daanct12 has joined #dri-devel
robertfoss[m] has quit []
kts has joined #dri-devel
srslypascal has quit [Quit: Leaving]
JohnnyonFlame has joined #dri-devel
srslypascal has joined #dri-devel
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
gouchi has joined #dri-devel
Duke`` has joined #dri-devel
aravind has quit [Ping timeout: 480 seconds]
luc4 has joined #dri-devel
rasterman has quit [Quit: Gettin' stinky!]
vyivel has quit [Remote host closed the connection]
vyivel has joined #dri-devel
bgs has joined #dri-devel
karolherbst has joined #dri-devel
Thymo has quit [Quit: ZNC - http://znc.in]
maxzor has quit [Ping timeout: 480 seconds]
Thymo has joined #dri-devel
karolherbst has quit [Remote host closed the connection]
pcercuei has joined #dri-devel
warpme_____ has joined #dri-devel
lemonzest has joined #dri-devel
Danct12 has quit [Read error: No route to host]
karolherbst has joined #dri-devel
maxzor has joined #dri-devel
Akari has joined #dri-devel
maxzor has quit [Ping timeout: 480 seconds]
maxzor has joined #dri-devel
psykose has quit [Ping timeout: 480 seconds]
maxzor has quit [Ping timeout: 480 seconds]
djbw has quit [Read error: Connection reset by peer]
tobiasjakobi has joined #dri-devel
tobiasjakobi has quit []
maxzor has joined #dri-devel
maxzor has quit [Remote host closed the connection]
maxzor has joined #dri-devel
kts has quit [Quit: Leaving]
rsalvaterra has quit []
rsalvaterra has joined #dri-devel
psykose has joined #dri-devel
psykose_ has joined #dri-devel
psykose_ has quit [Remote host closed the connection]
psykose_ has joined #dri-devel
psykose has quit [Ping timeout: 480 seconds]
Company has joined #dri-devel
maxzor has quit [Ping timeout: 480 seconds]
digetx has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
heat has joined #dri-devel
gouchi has quit [Remote host closed the connection]
kts has joined #dri-devel
kts has quit [Quit: Leaving]
tobiasjakobi has joined #dri-devel
warpme_____ has quit []
paulk has quit [Ping timeout: 480 seconds]
paulk has joined #dri-devel
freemint has joined #dri-devel
<freemint> I got an PCIe device whose region 0 is supposed to be 64G big but it is only 128M big on the machine according to lspci -vvv. On a machine where the PCIe device works lspci does not mention Resizeable Bar. Is: https://pastebin.com/5agyjmtv Should be: https://pastebin.com/us1gsHdn The vendor does not officially support my older processor and some error analysis tool by the vendor suspects a PCIe related error. Do you have any
<freemint> suggestions how i can begin to narrow down this issue?
kts has joined #dri-devel
bmodem has quit [Ping timeout: 480 seconds]
warpme_____ has joined #dri-devel
<Mis012[m]> I'd assume you don't need to resize the BAR if the space dedicated for that device was large enough already, but that seems unlikely
<freemint> I am utterly lost. So far i learned that the Haswell generation of Xeon CPUs has a bugged Above4g support which is necessary for 64 Gigabytes. I loaded a patched ACPI table (similar to this one https://winraid.level1techs.com/t/request-above-4g-decoding-for-asrock-z97-extreme-9-and-asus-p8p67-evo/89575/30 ) every boot but that has not fixed the problem.
<Mis012[m]> and presumably the BIOS (or ACPI code) would be the one dealing with that, because that's totally not something that doesn't belong there
<Mis012[m]> just write a Linux driver for the root bridge instead of letting bios/acpi manage it :P
<freemint> that double negation confuses. If i am in the wrong channel i welcome pointers to more appropriate channels.
<freemint> Mis012[m] your advice is not actionable for me as i do not know where to start with that. If this is humor it went over my head.
<Mis012[m]> it's not necessarily on-topic in this channel, but I'm not sure there's a better place so hopefully someone here can help you
<Mis012[m]> my point was that sadly, this stuff seems to be handled by bios/acpi, rather than by Linux (which in my personal opinion would be saner)
<Mis012[m]> worst case you can ask on LKML
kts has quit [Quit: Leaving]
<Mis012[m]> freemint: it seems confusing to say that a generation of SoCs has a bug if that bug is actually in the ACPI tables the motherboard supplies
<freemint> The PCIe device in question has an open source kernel driver https://github.com/veos-sxarr-NEC/ve_drv-kmod however the bring up involves an proprietary userland binary. This bring up fails. I hope that Linux kernel development tooling could atleast brings some visibility into this problem.
<freemint> Mis012[m], Sure that was phrased badly. Let me rephrase.
<Mis012[m]> so I gather the kernel driver is not exactly upstream?
<Mis012[m]> would probably not fly with hard dependency on magic userspace binary
<freemint> The kernel driver it out of tree but open source.
<Mis012[m]> well, you could also call certain downstream drivers open source, but at some point they are not drivers but rather condoms for talking to the userspace code
<freemint> Mis012[m], I would not either but i just got the card powered up this week and ... i am still far from replacing that magic binary
<Mis012[m]> so it's certainly important to evaluate if it's a driver or a "driver"
<Mis012[m]> freemint: do you have some large VRAM GPU that supports having it's full VRAM mapped?
<Mis012[m]> if you could reproduce the issue with that, it would sure be easier to debug
<freemint> I only have a 960 handy which i do not think qualifies.
<Mis012[m]> well, how much VRAM it has is presumably documented :P
<Mis012[m]> whether you can make it map it directly might not be
<freemint> Resizeable Bar and above4g support are things PCIe3.0 motherboards should support. Yet many or all motherboards with AMI BIOSes of this and also some later generations come without ReBar support and broken above4g support.
<freemint> The GTX 960 has 4 GB of RAM which might qualify as large. By default it maps 256M in one of its regions.
epoll has quit [Ping timeout: 480 seconds]
<freemint> It looks like NVIDIA has to provide an explicit firmware update for Resizeable Bar support which they did not do for this old an generation. AFAIK
rcf has quit [Ping timeout: 480 seconds]
<Mis012[m]> >Copied from drivers/pci/pci.c
<Mis012[m]> wow, that's some quality code right there
<Mis012[m]> could maybe explain why they thought that was a good idea
* freemint is confused whether copying and adapting from working things is a bad thing.
<Mis012[m]> it's a layering violation
<Mis012[m]> so they should at least explain why they thought it was appropriate
<Mis012[m]> drivers/pci/pci.c is not a driver for a PCI(E) device
<Mis012[m]> it's the framework this driver is using to do pci(e) stuff
epoll has joined #dri-devel
* freemint nods
<freemint> Is there a way to listen to what dev_err gets called with or if it gets called?
maxzor has joined #dri-devel
<Mis012[m]> dev_err should print stuff to kernel log
<Mis012[m]> so it ought to be quite obvious if it was called xD
<Mis012[m]> it's literally a logging function
<Mis012[m]> Region 0: Memory at e8000000 (64-bit, prefetchable) [size=128M]
<Mis012[m]> this is certainly below 4G
<Mis012[m]> but why would it not be if it fits in the pre-allocated BAR space
<freemint> at the risk of being so dumb that i get kicked form the room. How do i do find that in the logs?
<Mis012[m]> I don't think this room kicks people out for being dumb
<Mis012[m]> either `dmesg | grep <stuff>` or `dmesg -H` and scroll through manually
<Mis012[m]> dev_err should prefix the message with the name of the driver
rcf has joined #dri-devel
<Mis012[m]> actually this is the dev room, there should be a more user-friendly companion room that's supposed to be where people ask for help
<Mis012[m]> (with non-dev issues)
<Mis012[m]> presumably development of an upstream-quality driver that doesn't need a proprietary userspace blob would be desirable, but not sure that's dri-adjacent :P
<freemint> I am a bit worried about the binary too and if i think it is within my grasp i would like to atleast document what it does. However i first got to get the card working. In half a month a might have access to a supported machine. ... But that is in half a month.
tobiasjakobi has quit []
thaytan has quit [Ping timeout: 480 seconds]
<freemint> no dev_err in dmesg.
<Mis012[m]> 🤨
<Mis012[m]> it doesn't print the name of the logging function
<Mis012[m]> you can filter by severity if you only want errors
<Mis012[m]> not like I remember which level is "error" :P
<Mis012[m]> dmesg -l err
<Mis012[m]> nice, proper dmesg doesn't need a number
<freemint> nope nothing from the ve driver in there.
<Mis012[m]> I assume it enumarates as 128MB initially, then you run the userspace blob, and if that works, it magically becomes 64GB?
<Mis012[m]> I'm not sure I saw anywhere in the "driver" that was doing that, but at the same time surely that can't be done fully from userspace
<freemint> That is an hypothesis compatible with what i know.
<freemint> There is ARM chip on the PCIe device which is controlled by the user space binary and is suppossedly involved with initialisation process.
<Mis012[m]> should just run Linux on that :P
<Mis012[m]> do I even want to know what this does
<freemint> I have an idea.
<freemint> Do you want to stay ignorant why that exists?
caef^ has quit [Remote host closed the connection]
<Mis012[m]> well, it sounds like they're mapping something to userspace that they probably should not
<Mis012[m]> but I can't parse that code...
<freemint> Okay on these card there a 8 fancy CPU cores. This CPU ISA has non system ring. So what they do instead is have the PCIe host interupt CPU cores over PCIes, reading and writing the processors state. From an userland perspective running on the card, you are a userland binary and all system calls are handled or emulated by the host CPU. An user process has access to the normal file system and so on. This includes memory
<freemint> protection between multiple users and i guess that part does takes care that the memory protection unit on the pcie card is in sync with memory protextions on the x86_64 host running Linux.
<freemint> or that is my best idea given my limited knowledge of linux
<Mis012[m]> well, that's a fun architecure that I would love to exist, but realistically having the cores only connected via PCIE is way too slow for that to actually be viable :P
<Mis012[m]> it's supposed to be an accelerator I assume?
<Mis012[m]> won't be very fast if it context switches over PCIE
<freemint> Actually they manage that by having the scheduling interval being 1 second.
<freemint> It is an accelerator and that exists.
<freemint> They do the context switches over PCIe.
<Mis012[m]> really?
<Mis012[m]> like really really?
<freemint> I have it in writing from someone who works at NEC on those cards.
<Mis012[m]> wow, I'd sure love to implement that in a generic way in mainline :P
<Mis012[m]> I'd assume you would need to have the two cores be on the same die for this to be anywhere near viable
<freemint> Awesome. I give you as much access to the card under my desk remotely as as you want.
<Mis012[m]> well, I do prefer to work with docs :P
<mareko> who knows how shared-glapi works?
<freemint> I got one more card i could lend out in theory but given how hard they are to get i am a bit cautious with sending it out.
<Mis012[m]> freemint: schematics of the card would be nice, and fingers crossed there are docs for the SoC they plopped on there
<Mis012[m]> ideally they wouldn't use secure boot and one could have foss fw on that as well
<freemint> They have 8 cores with 64 16384 bit register one can crunch on with vector operations..
<freemint> yes that is a lot of registers bits
<Mis012[m]> freemint: is that some custom SoC?
<Mis012[m]> Sony did some fun stuff with PS4 using an arm SoC for it's peripherals over PCIE
<Mis012[m]> freemint: ideally one would have the docs for that thingy
<freemint> Here is a lot of software documentation https://sxauroratsubasa.sakura.ne.jp/Documentation
<Mis012[m]> I would prefer hw documentations :P
<Mis012[m]> s/s//
<Mis012[m]> I'm a "bring your own software" kind of guy
<freemint> Mis012[m], Vendor slides at HPC events is as good as it is going to get with public hardware docs i fear. https://devcal.obspm.fr/attachments/NEC_SX-Aurora_TSUBASA_2021_obspm.pdf might get interesting after slide 17
<freemint> Wait that is for the 2.0 gen let me see if i find something 1.0 although 2.0 was mostly a refresh and tweak from 1.0
<mareko> olv__: is there any reason to have shared-glapi now that we have glvnd and only one *_dri.so file? Can shared-glapi be moved into libgallium_dri.so?
<freemint> Mis012[m], Is slide 8 of https://blog.rwth-aachen.de/itc-events/files/2021/10/01_SX_Aurora_DeepDive_Introduction_EF.pdf what you mean by schematic?
<mareko> olv__: can shared-glapi be simplified considering that libgallium_dri.so, libGL, and libEGL must come from the same Mesa version/commit?
<Mis012[m]> freemint: a schematic is something like this
Akari has quit [Quit: segmentation fault (core dumped)]
<Mis012[m]> but I guess there won't be much besides the SoC
<freemint> I have not even seen a clear die shot of the ASIC on that card.
<freemint> nope nothing like that is public
<freemint> (AFAIK)
<Mis012[m]> typical...
<freemint> I want to open that up as much as you do. I just got my hands on a used card and am trying to walk the walk from there
lemonzest has quit [Quit: WeeChat 3.6]
<freemint> Yes, it does.
<freemint> A really orthogonal and competent ISA which is fun to assembly program for (I tried when i had access to a running card)
<Mis012[m]> this is a nice block diagram
<freemint> I tried to implement this years advent of code 1st problem in vector assembly but i ran out of time. https://pastebin.com/6vKBHszR
<freemint> yes it is
flto has quit [Read error: Connection reset by peer]
flto has joined #dri-devel
<Mis012[m]> seems suspiciously simple
<Mis012[m]> the "driver" did talk about some firmware
<freemint> The small arm chip runnning firmware is probably on the xiu, peu or dgu . I do not have the legend to that handy to see what those shorthands mean Mis012[m]
<Mis012[m]> neither sounded like it should have fw
<Mis012[m]> freemint: do you have the fw binary
<freemint> I have some binary files called firmware.
<freemint> Firmware is userupdateable
<freemint> Repo with drivers is and stuff is here https://sxauroratsubasa.sakura.ne.jp/repos/TSUBASA-repo_el8.6 FyI
<DemiMarie> Mis012 freemint: if only there was a way to get good performance on the kinds of code that mere mortals can actually write 🤣
<freemint> DemiMarie, There is performance for mere mortal code. It just needs to have long loops it can vectorize
<freemint> Mis012[m], Firmware image: http://bashupload.com/xVp00/aurora_MK10.bin
<DemiMarie> freemint: I have not written such code in years. The code I write is usually dealing with either branchy logic or protocol handling.
<DemiMarie> Very little number-crunching
<freemint> Yeah those cards are not meant for that. I am already what the card should be able to do with the that ASM code. Implementing a vector state machine using vector mask registers to parse things is not something you are gonna get the compiler to do for you.
<freemint> Mis012[m], my looks like files can only be downloaded once. give me a sec
<DemiMarie> freemint: my point is that CPUs are not good at this kind of code either
* freemint nods
<freemint> are the branches performance critical?
<Mis012[m]> freemint: you know there are file sharing sites that are not such blatant adware that they don't even work in a browser with adblocker type stuff?
* freemint ducks
<freemint> Name a name.
<Mis012[m]> https://gofile.io
<Mis012[m]> but I got it to download with chromium, after splashing a nice ad
psykose_ has quit [Remote host closed the connection]
psykose has joined #dri-devel
* freemint will try to remember that site and is sorry.
<DemiMarie> freemint: branching is most of what the code I write does, I believe.
<DemiMarie> I suspect the same is true for e.g. compilers.
<freemint> Mis012[m] DGU it is then.
Haaninjo has joined #dri-devel
<Mis012[m]> doesn't sound like it
iive has joined #dri-devel
<freemint> Mis012[m], I was told by someone from NEC that there is an arm chip on there which is involved with device bring up and monitoring.
<freemint> I know no more than that.
<Mis012[m]> sad
<freemint> Actually maybe also good.
<freemint> It one can run code on it, the card becomes a bit more powerful. One could run the a standalone OS on it and have it no longer need to do context switch over PCIe or so is my pet theory.
<freemint> The most public admission that it exists is maybe https://sxauroratsubasa.sakura.ne.jp/documents/mmm/en/MMM_VMCFW_history_en.txt although it does not saz ARM either
<Mis012[m]> freemint: can one run code on it thouh
<Mis012[m]> *tough
<Mis012[m]> *though
digetx has joined #dri-devel
<freemint> it is firmware updateable. how much effort it takes to run code there i do not know yet.
<Mis012[m]> well, it's not about effor
<Mis012[m]> t
<Mis012[m]> it's about "do they use cryptographically secure assymetric cipher for signature verification"
<Mis012[m]> also known as "wait, that's legal?"
Akari has joined #dri-devel
<freemint> I mean one could always swap out the chip with one controlls. Whether there are non hardware modding ways i do not know. I would be shocked if unsigned firmware updates are done in hardware developed 2017 but i honestly do not know. Whether the firmware can be exploited from the Vector cores, from the x86 host behind PCIe or if a hard mod is needed i do not know.
<freemint> Hey do you sign your firmware images with asymmetric keys is not something you get an answer to if you ask nicely i think.
<freemint> I know symmetric encryption is used somewhere though from binwalking some files.
krushia has joined #dri-devel
<clever> freemint: on what device?
<Mis012[m]> freemint: the chip is the full thing
<Mis012[m]> you can't only swap out the part that you don't like :P
<freemint> Where-ever "fw_ve_sbus_00.bin" gets installed to.
<Mis012[m]> you can shoot it with a particle accelerator beam but then it will have a very sad EOL
<freemint> Mis012[m], I have not taken the card apart but my impression was that the ARM controller was external. I could be mistaken.
<Mis012[m]> 🤨
<Mis012[m]> how would that work
<Mis012[m]> "it's basically planned obsolescence, they're forcing us to shoot particles at it which massively reduces it's lifespan"
<Mis012[m]> freemint: that block diagram doesn't show any GPIO interface either
<freemint> Good point.
<Mis012[m]> so how does it communicate with the supposed chip to update the fw
<freemint> maybe in an undocumented way?
<Mis012[m]> or it has an undocumented arm core
<Mis012[m]> which is more likely :P
<Mis012[m]> or the arm core is inside one of those things from the block diagram
<freemint> or parts of the block diagram are outside the chip
<Mis012[m]> that's not how block diagrams work
<Mis012[m]> the fw mentions i2c and spi xD
<Mis012[m]> they could technically use the smbus interface on PCIE slots
<Mis012[m]> but I don't think that's mandatory?
<freemint> Well blockdiagrams can be lies for childreen.
<Mis012[m]> :doubt:
<Mis012[m]> there might be stuff missing or it might be slightly incorrect, but for sure it's all on die
<freemint> Is NEC even arm license holder?
<freemint> If it is not i can not print arm cores on silicon at tsmc i think
<Mis012[m]> why would they not be
<Mis012[m]> uhm, it does mention smbus as well
<freemint> mhh they were atleast in 2000
<Mis012[m]> there is a lot of suspicious stuff in here that the block diagram doesn't show
<Mis012[m]> it also mentions "eFuse", fun
nirmoy_ has joined #dri-devel
<freemint> Mis012[m], Yeah it is an electronic device made in this decade.
<Mis012[m]> a lot of companies just use "totally-OTP"
nirmoy_ has quit []
<Mis012[m]> maybe it was SBus and not smbus :/
<Mis012[m]> but it mentions UART
nirmoy_ has joined #dri-devel
<Mis012[m]> maybe you can get these debug messages on that
<Mis012[m]> the fw looks scrambled
<Mis012[m]> petty
djbw has joined #dri-devel
<freemint> Yep.
<freemint> From what i heard even getting this much driver open sourced was a big internal struggle
<freemint> A different kernel module https://github.com/veos-sxarr-NEC/vp-kmod
<freemint> but pretty boring
<Mis012[m]> yep
<freemint> where did you fund efuses mentioned?
<Mis012[m]> strings on the fw file
<Mis012[m]> also makes it quite clear that it's probably scrambled
<freemint> I mean those chips are binned into 3 tiers i would expect some fuses for that alone.
<Mis012[m]> now I found a mention of GPIO as well
<Mis012[m]> so yeah, it's clearly a full blown SoC :P
nirmoy_ has quit []
<freemint> If you see strings like B02D16 or B02F those refer to board components
nirmoy has joined #dri-devel
<Mis012[m]> I saw ir3580
<Mis012[m]> which is definitely some IC on the board
<Mis012[m]> would be fun if the i2c/spi/uart/gpio controllers are exposed over pcie
<freemint> would that show up on lscpi -vvv ?
<Mis012[m]> that's not how that works...
<freemint> There are definetly some 4k Regions which could be some controller
<freemint> Oh you mean they are exposed as part of some existing region. Get it
<Mis012[m]> I mean, they would have to be part of some BAR presumably
<Mis012[m]> and it's not like lspci knows what those are used for, it just knows how large they are and where they got mapped
<Mis012[m]> freemint: you could try to poke them to put all the registers in here, not just ones they use :P
<Mis012[m]> I certainly would do that if I had the docs with the register map
<freemint> That poking should work even if there is no driver.
<Mis012[m]> well, you can poke...
<freemint> Would you say given how unpopular the card is that this a better or worse open source and public doc situation compared to other accelarators by Nvidia or AMD?
<freemint> want login to the machine the card is in so you can poke too?
<Mis012[m]> AMD doesn't exactly share register maps, but sometimes they leak
<Mis012[m]> fwiw they do seem to auto-generate the headers from them
<Mis012[m]> which are public
<Mis012[m]> so unless they really want to hide something, that should be quite exhaustive
<Mis012[m]> freemint: open source situation regarding AMD cards is pretty much as good as it's going to get
<freemint> would https://github.com/veos-sxarr-NEC/pci_mmio be a good poking tool?
<Mis012[m]> I guess...
<Mis012[m]> do you want to correlate a dump of the unknown register values with LED blinking?
<Mis012[m]> or whatever it has hooked up to GPIOs
<freemint> What LEDs are you talking about? There are three externally visible once.
<Mis012[m]> amgpu is somewhat solid (though I'd still love to convince mainline to let me refactor the i2c/gpio/irq stuff into separate drivers), Mesa drivers are nice...
<Mis012[m]> freemint: the fw mentioned LEDs
<freemint> I would not want to do potentially destructive stuff to the card. I do not have good screw drivers.
<Mis012[m]> >implying that a die can be fixed with screwdrivers
<Mis012[m]> freemint: you wanted to poke, the only thing that I can think of that might be visible just by looking at the mmio dump is if there are bits which change depending on if the LEDs are on
<freemint> Mis012[m], Implying that GPIO is behind a screw driver
<Mis012[m]> well, LEDs are presumably connected to GPIOs
<Mis012[m]> I somewhat doubt a large BGA will have pins labeled on silkscreen
<freemint> Given how high level their information i doubt they can be written to easily.
Duke`` has quit [Ping timeout: 480 seconds]
<Mis012[m]> freemint: well, the LEDs are presumably connected to GPIOs
<Mis012[m]> and the GPIO controller is presumably in the address space of the MCU that runs the fw
<Mis012[m]> the question is if the GPIO controller is also in the address space that gets exposed over PCIE
<Mis012[m]> I don't see why it shouldn't be, unified address space best address space :P
<freemint> Mis012[m], I just wanted to read a pcie bar ... and the computer shut off.
pcercuei has quit [Quit: dodo]
<Mis012[m]> fun
<Mis012[m]> freemint: another thing to do would be to make a disassembler for `MMM_Script_Language V01.0200`
<freemint> Mis012[m], I also stumbled across that. Did you see anything which comes close to documentation that byte code?
<Mis012[m]> nope
<Mis012[m]> but presumably there is some interpreter for it
<Mis012[m]> freemint: there is help for some commands which are possibly written in that bytecode
<Mis012[m]> freemint: in any case, I'd run those commands with `strace` and see what you get
<Mis012[m]> freemint: hmmm
<Mis012[m]> maybe this can convert it to readable form?
<freemint> lol all the region to file dumps come out at a different size
<Mis012[m]> are you using some auto-compressing filesystem? :P
Jeremy_Rand_Talos has quit [Remote host closed the connection]
Jeremy_Rand_Talos has joined #dri-devel
<Mis012[m]> freemint: I don't feel like installing all those packages, can you try running that `signature` command?
<Mis012[m]> (on some MMM script)
<freemint> Sure. Can you give me a path to that command?
<Mis012[m]> opt/nec/ve/bin/vecmd possibly
<Mis012[m]> yeah, it shows as much
<Mis012[m]> and -h should show you the help files that I've found
<freemint> Do you have preference between YouTube, twitch or jitsi?
<freemint> jitsi be easiest.
bgs has quit [Remote host closed the connection]
<freemint> /opt/nec/ve/bin/vecmd signature -> "VE? can not execute "unknown command""
<Mis012[m]> /opt/nec/ve/bin/vecmd -h?
<Mis012[m]> opt/nec/ve/bin/vecmd -h signature?
<freemint> at the moment it knows about info and topo.
<freemint> nothing help-file: signature
<Mis012[m]> > ls etc/opt/nec/ve/mmm/help/
<Mis012[m]> cmd_list0 cmd_list1 cmd_list2 flsrd flswt fwup i2crd i2cwt info mconfig regrd regwt reset run signature state tdctl topo vconfig vmcrd vmcwt
<freemint> jup those files are there
<freemint> Ah help at the moment only shows cmd_list0
<freemint> I guess 1 requires an active vector engine because i executed fwup before
<Mis012[m]> maybe 2 is supposed to be internal only? :P
<freemint> I hope so
<Mis012[m]> does it matter? :P
<Mis012[m]> as long as the support is in the shipped binary
<Mis012[m]> which it hopefully is
<freemint> with it you read and write register, i2c, vmc flash or vmc sram
<Mis012[m]> well, there are two things that I care about
<Mis012[m]> one is the singature command which might make the MMM scripts readable
<Mis012[m]> the other is just using strace to see what it's doing when you use those commands
<Mis012[m]> freemint: maybe ve_monitor has to be running
luc4 has quit []
<daniels> can you please take this to another channel?
JohnnyonF has joined #dri-devel
Johnny has joined #dri-devel
JohnnyonFlame has quit [Ping timeout: 480 seconds]
JohnnyonF has quit [Ping timeout: 480 seconds]
cphealy_ has joined #dri-devel
cphealy has quit [Ping timeout: 480 seconds]
freemin7 has joined #dri-devel
jernej has quit [Quit: Free ZNC ~ Powered by LunarBNC: https://LunarBNC.net]
jernej has joined #dri-devel
ppascher has quit [Ping timeout: 480 seconds]
Haaninjo has quit [Quit: Ex-Chat]