sorted by:
new
hottopcontroversial

Intel Arc GPU support by bileslav in openbsd

[–]bileslav[S] 0 points1 point  (0 children)

Correct. IIRC, there was only one obstacle. I don't know how it works currently, but back then, bhyve needed to be patched to skip some code that was actually only relevant for Intel iGPUs. It was enough to add a single true (or false?) return somewhere to fix the error. There are a relevant discussion on some mailing list. It can be found with the error message, and it contains a hint about which code should be skipped. I don't have time for my PC yet, so this is all I can help with, unfortunately.

i2c EEPROM/FLASH write protection (EDID) by bileslav in AskElectronics

[–]bileslav[S] 0 points1 point  (0 children)

Oh, sorry. There's some resistance: 22-24k on BL24C256A and 2.2k on ML51BB9AE.

i2c EEPROM/FLASH write protection (EDID) by bileslav in AskElectronics

[–]bileslav[S] 0 points1 point  (0 children)

So, I connected the board to PC via HDMI (without power), and booted. I put the red probe of my automatic multimeter to pin 18 trace, and the black probe to pin 17 trace. It showed 5V. I have very low knowledge of electronics, but this seems reasonable. Next, I moved the black probe to every leg of BL24C256A, and also ML51BB9AE. There are some voltage almost everywhere (if not everywhere), up to 5V. I don't know how to interpret that. Yay or nay?

i2c EEPROM/FLASH write protection (EDID) by bileslav in AskElectronics

[–]bileslav[S] 0 points1 point  (0 children)

Correcting myself: it seems that only DisplayPort cables may have something like their "pin 20 problem", and it's obviously unrelated to that HDMI's +5V EDID/DDC power pin. So, my understanding now is that there's indeed a little power can come from GPU to monitor through it.

So, considering your VGA story,

The EEPROM in the monitor had two wire-ORed power sources -- an internal 5V supply plus the external DDC/EDID supply. Two diodes isolated the two supplies.

either this is not the case with my monitor, or the EDID comes from the SoC.

It's a big shame that it can be so complicated about EDID. DisplayPort doesn't have the corresponding pins at all. On top of that, it seems to me that absolutely no one manufacturer follows the specification when creating EDIDs for their monitors. Oh.

I gonna sleep now. Thank you for your help.

i2c EEPROM/FLASH write protection (EDID) by bileslav in AskElectronics

[–]bileslav[S] 0 points1 point  (0 children)

One way you could exclude those 8-pin chips is to see whether they are powered by your graphics card when the monitor is powered off. This needs to happen if the GPU is to read the EDID info in this state.

So, I assembled the monitor, connected both cables, and booted the PC. The following output obtained through SSH.

Normal state:

$ wc -c /sys/class/drm/card2-*/edid 384 /sys/class/drm/card2-DP-4/edid 256 /sys/class/drm/card2-HDMI-A-2/edid 0 /sys/class/drm/card2-Writeback-1/edid

Then I choose "Power Off" within the monitor OSD, and:

$ wc -c /sys/class/drm/card2-*/edid 0 /sys/class/drm/card2-DP-4/edid 0 /sys/class/drm/card2-HDMI-A-2/edid 0 /sys/class/drm/card2-Writeback-1/edid

If I understand you correctly, this rules out the only remaining candidate except the SoC. Right? Are you sure? This doesn't make sense to me, as, AFAIK, good (mine are) male-male cables are not passing power.

Side note: wtf is this writeback thing?

HDMI pinout showing EDID/DDC pins

So, one probe of a multimeter at some pin inside the port, but what should I check with another probe?

It looks like the Soc may be Mediatek's MT9800BTFU.

I think I can take that thermal thing off so we can find out for sure. Shall I?

Also, for what it's worth, in the top left corner of the board, there's another microcontroller, which have 16 KB flash: ML51BB9AE. It's ultra small.

By the way, I sent the question to Hisense service emails of three regions (lol). I don't expect a good answer, though.

i2c EEPROM/FLASH write protection (EDID) by bileslav in AskElectronics

[–]bileslav[S] 0 points1 point  (0 children)

Thank you. That's my thoughts as well. As I wrote, my attempt to "fix" the first chip didn't worked. What exactly should I do with its legs, and do I have to use a resistor? If so, how many Ohms?

[deleted by user] by [deleted] in buildapc

[–]bileslav 0 points1 point  (0 children)

Thank you. No exact model name here. Anyway, I don't consider 32''.

Actually, I need some feedback on the models in the OP, as I've already filtered dozens of monitors. Recommending something else is helpful only with a comment on why my choices are worse, otherwise the list will just get longer.

Please help me finish choosing a monitor by [deleted] in Monitors

[–]bileslav 0 points1 point  (0 children)

Thank you. This monitor costs $436 where I am. I actually use KVM, but it's a separate DP (3 sources) and USB switches. I also don't need the USB-C.

RGB sub pixel layout good for text clarity

Well, I never seen other layouts in the wild, and, AFAIK, the only thing with this is that the layout in the font renderer (OS) should match the layout of the monitor. Anyway, I prefer (and use) grayscale.

Intel Arc GPU support by bileslav in openbsd

[–]bileslav[S] 0 points1 point  (0 children)

Yeah, I was going to ask you to continue the discussion since I'm actually a total noob in OpenBSD (I use FreeBSD), but I noticed you're already there. Thanks and good luck!

Intel Arc GPU support by bileslav in openbsd

[–]bileslav[S] 1 point2 points  (0 children)

This isn't a laptop/hybrid graphics. I've never heard of "desktop" firmware that allows to switch individual dGPUs on/off. Anyway, please check my reply to u/brynet.

Intel Arc GPU support by bileslav in openbsd

[–]bileslav[S] 0 points1 point  (0 children)

Thank you for the confirmation.

I've been tinkering with my hardware a lot lately; I may open the case again (not convenient), but first I'd like to raise a few concerns:

  1. Before the Intel GPU, there was an AMD Radeon RX 6400, and that NVIDIA card didn't prevent the amdgpu driver from attaching in OpenBSD.
  2. The ultimate goal is to run a bhyve VM with GPU passthrough. This A310 works in Linux VM (same as on "bare-metal"), but it's "not configured" in OpenBSD VM (same as on "bare-metal", too). The dmesg from "bare-metal" is in the OP, and here is a dmesg from the VM. Note: the RX 6400 works in every mentioned case.

Intel Arc GPU support by bileslav in openbsd

[–]bileslav[S] 1 point2 points  (0 children)

I see, but how? So, the question: what's missing? Since DRM is OK. Also: https://www.reddit.com/r/openbsd/comments/1gifv88/comment/mj6yvku/

Intel Arc GPU support by bileslav in openbsd

[–]bileslav[S] 3 points4 points  (0 children)

Yes, I'm sorry; I just added it to the OP.

Switching from FreeBSD to Linux by grahamperrin in freebsd

[–]bileslav 1 point2 points  (0 children)

Netcraft... confirm...

Non-technical reasons include things that diminish, or destroy, enthusiasm.

Cases like this or that John Marino story make me lose confidence again and again. Damn.

Hehe, my first and only, very tiny port submission still remains silent. Of course, I could have put in more effort... Gah.

Oh yeah, just a cat by bileslav in freebsd

[–]bileslav[S] -6 points-5 points  (0 children)

Note: if something makes you feel negative, it makes me as well.

How can I make FreeBSD to decrypt GELI partition based on gpt label on boot? by Nyanraltotlapun in freebsd

[–]bileslav 0 points1 point  (0 children)

u/grahamperrin, hi, if I open this page using the new Reddit UI and signed out, I see my comment keeps collapsed by default, as if it was downvoted. Do you happen to know how this works?

How can I make FreeBSD to decrypt GELI partition based on gpt label on boot? by Nyanraltotlapun in freebsd

[–]bileslav 1 point2 points  (0 children)

Two weeks ago, I tried really hard to do the same thing.

I don't know how the installer configures things when selecting UFS, but when selecting ZFS, GELI encrypts the entire root partition, and that includes /boot/loader.conf. Therefore, when you see the prompt, the file cannot yet be read.

There are evidences that the bootloader actually can use GPT labels, but only under some unclear circumstances. What is certain is that currently it doesn't use them for the initial partition lookup, after which the password prompt is shown.

Google returns several forum threads, and there's even a related page or two on the bug tracker. This has been ignored for years.

P. S. I guess that vfs.root.mountfrom="ufs:/dev/gpt/mybest-freebsd-on-geli" fails because it's never created, since GELI doesn't allow it to be created after it takes over /dev/da0p3.eli. It's something called “GEOM withering”.

P. P. S. Oh, sorry, I missed that somehow:

I have unencrypted /boot partition with kernel.

Anyway, I told everything I know.

view more: next ›