<kettenis>
This boots up to a prompt on the framebuffer console when used as a "kernel" with preloader-m1
<kettenis>
Should be usable as a payload for m1n1 as well
<kettenis>
use u-boot-nodtb.bin as the payload
DarthCloud has quit [Remote host closed the connection]
DarthCloud has joined #asahi-dev
<marcan>
I'll test it as soon as I'm done with the current oddysey
<marcan>
it's a fun one: leaving that register enabled, I get SError faults (after a few times, an endless loop) after normal page faults - but not always
<marcan>
and whether it happens depends on the load address of m1n1
<marcan>
that screams like a cache/TLB problem to me
<Bluerise>
marcan: how did you get 1.2v uart? I have a
<Bluerise>
but then I still need to provide 1.2V to it
<marcan>
glasgow in 1.65V mode and a resistor divider for the TX side
<Bluerise>
do you happen to have a write down of the components to...
<Bluerise>
ah
<marcan>
Bluerise: do you have the USB-PD stuff?
<Bluerise>
I have >=3 machines where I can program USB-PD easily.
<marcan>
including sending SOP'DEBUG VDMs?
<marcan>
also you need to be a DFP
<Bluerise>
so bascially I could do USB-PD-Machine -> breakout -> (intercept D+/D- right here) -> breakout -> M1
<marcan>
actually one thing I need to try out, if I find some time tomorrow, is to make this work with a simple M1 - M1
<marcan>
pretty sure it should be possible with a standard type C cable
<Bluerise>
I have one machine that can be DFP :)
<marcan>
but yeah, if you can do compliant DFP negotiation and send SOP'DEBUG/SOP''DEBUG VDMs it should work
<marcan>
that UART you linked does down to 1.8V
<marcan>
so you would need to run it at 1.8V and use a resistor divider on the TX direction
<marcan>
1.8V converters are fine (3.3V won't work, threshold is too high) if you do that
<Bluerise>
usb-typec@50 {
<Bluerise>
compatible = "nxp,ptn5110";
<Bluerise>
let's check if that can do VDM..
<marcan>
with SOP'DEBUG
<marcan>
that part is critical
<Bluerise>
SOP* Configurable: Register programmable to generate and receive SOP, SOP’,
<Bluerise>
SOP’-debug, SOP”, SOP”-debug”
<Bluerise>
looks like it
<arnd>
marcan: are you running with 4KB pages when you get the SError faults? I've been wondering whether there is a register that changes the cache between a mode that is faster on 16KB pages and one that works correctly on 4KB. I was mostly thinking of the L1 cache that appears as though they designed it as a non-aliasing VIPT 8-way set-associative L1d, which would make it aliasing for 4K
<marcan>
arnd: 16K right now (in m1n1)
<arnd>
ok
<marcan>
I have it running in a loop incrementing base addresses by 64K, I'll leave it overnight and see if I see patterns tomorrow :)
<marcan>
Bluerise: cool :)
<marcan>
then I guess all you need is some 1.8V reference voltage from somewhere
<Bluerise>
the more I think about it the easiest might really be hummingboard pulse -> cheap breakout board -> intercept data lines to -> cheap breakout board -> m1
<marcan>
Bluerise: a 220 ohm + 470 ohm divider will give you ~1.2V out of a 1.8V signal
<Bluerise>
and then I only need to a) add code to my tcpci(4) driver to send VDM on port attach b) somehow get to 1.2V
<Bluerise>
I don't have a 1.8V signal either ;)
<marcan>
well, you need a 1.8V supply for the muart, right? :p
<Bluerise>
well, the thing works like this: you supply the voltage you want to use on tx/rx
<Bluerise>
like the turris mox has a 1.8V pin that you connect to the muart, which the muart will use as basline for tx/rx
<kettenis>
marcan: one thing to note is that u-boot only allows x8r8g8b8 and r5g6b5 framebuffers
<Bluerise>
ah, I see. then I need to apply 1.2V to VCCa, and 1.8V / 3.3V to VCCb
<Bluerise>
and then it would translate from 1.2 to 1.8/3.3
<Bluerise>
marcan: does that make sense?
<Bluerise>
usb 5v -> resistor to 1.2V -> level shifter, and usb 5v -> resistor to 3.3v -> level shifter. and then connect d-/d+ to the level shifter and a regular 3.3v ttl uart?
<kettenis>
marcan: if you don't care about the actual colors I think there is a quick hack I think
<jix>
Bluerise: I assume the level shifter would also need a proper supply, not a resistor divider
<marcan>
yes, you can't use resistor dividers for power supplies unless you use really low value resistors :p
<marcan>
also, I would avoid "bidirectional" level translators
<marcan>
though they will *probably* work for this
<marcan>
but they suck in many ways
<Bluerise>
sigh :/
<Bluerise>
damn electronics :-)
<kettenis>
in drivers/video/simplefb.c change one of the 32-bit format strings to match "x2r10g10b10"
<marcan>
kettenis: yeah, figured that would work (or I can just make m1n1 lie about it)
<marcan>
anyway, going to call it a day
<marcan>
I'll leave this pulling crash/nocrash bits overnight
<marcan>
wonder if I'll get a pretty picture in the morning
<Jan[m]1>
with 470 ohm + 220 ohm your TX will have to drive additional 2.6 mA
<Bluerise>
and that's... a lot? not much?
<Bluerise>
looks like an ftdi has max 24mA output
<marcan>
I picked the values to be in the range of any sane driver from the standard E6 list
<Bluerise>
and 0,25W 1% is fine?
<modwizcode>
should be
<Bluerise>
ok, then I'll but those
<Bluerise>
*buy
<marcan>
what, you mean you don't have the whole E6 range of resistors handy already? :-)
<marcan>
1/8W 10% would be fine too, by the way ;)
<modwizcode>
marcan: Then I'd have to buy something to store them in?
<marcan>
hah :)
<modwizcode>
The other day I bought like 10-20 smd tiny little ones to fix a eval board. I have no use for more than 1
<marcan>
I have resistor books with all of E24? I think it was? in 0803 and 0604
<modwizcode>
I should probably get something like that.
<marcan>
*08056
<marcan>
*0806
<modwizcode>
I cannot remember the exact size (I went to go look but it's unmarked) but it was small enough that I accidentally knocked other things off the board and almost broke it completely
<modwizcode>
Should go fix it right now that I have hot air to use.
<modwizcode>
Incidientally I have improved the qemu code a bit. I now load things at 0x10 instead of 0x0 to not confuse code.
<modwizcode>
And i cleaned up the code handling boot args and the stub device tree a bit
<modwizcode>
Unforutnately there's no easy clean way to get qemu to define a function as the "final" reset handler, so stuff like initializing the HCR_EL2 reg before jumping in and pointing it to the boot args is only certain if you have the cpu itself execute it as a sort of bootloader blob. You can hook reset but if you use any built-in loader code it will hook reset and break :/
<Bluerise>
marcan: I do embedded drivers, but I do not do electronics :/
<milek7>
so 1.8x0.7=1.26
<milek7>
probably will work, but slightly out of spec ;p
<milek7>
*Vih
<Bluerise>
I told a friend that sometimes I wished I had studied electronics so that I knew how to design pcbs etc. he then told me that's not what you learn there...
<marcan>
I'm going to be designing a proper m1 serial cable soonish, will stream most of it
<Bluerise>
"soonish"?
<marcan>
maybe starting within a week?
<Bluerise>
I guess those "order your m1 serial adapter here" options won't arrive for another month? :D
<marcan>
uhh if I'm fast enough I might have *prototypes* to send out to some people within a month :p
<j`ey>
marcan: that sounds like a cool stream. Ive designed some MCU pcbs before, but I had no idea what I was doing. totally surprised they worked
zopieux has quit [Ping timeout: 260 seconds]
zopieux has joined #asahi-dev
<opticron>
Bluerise, as a degreed EE, I can vouch for that. You learn electromagnetics and signal/noise theory
<opticron>
pcb design and electronics rework is a trade skill for the most part