<Werner>
Applied and built against megi's orangepi-5.10 branch though
<diego71>
Craphunzio: good job indeed, the photo of the board is quite low res, but it looks it have a serial port, probably near the vga port
cmeerw has joined #linux-sunxi
<plaes>
diego71: ...and JTAG for FPGA
apritzel has joined #linux-sunxi
ldevulder_ has joined #linux-sunxi
matthias_bgg has joined #linux-sunxi
Craphunzio has quit [Quit: Leaving]
Craphunzio has joined #linux-sunxi
<Craphunzio>
Thankx plaes and diego71, good morning everybody. I am going to take a few more pics today. Also I tried to fill in the "Images" section by uploading the content of the boot partition of the two images I got, but the wiki does not allow me to upload files other than pictures and patches.
ldevulder has quit [Ping timeout: 246 seconds]
<apritzel>
Craphunzio: this section is just for *links* to images
lkcl has quit [Ping timeout: 264 seconds]
laurentC has quit [Remote host closed the connection]
tuxd3v has quit [Ping timeout: 256 seconds]
cmeerw has quit [Ping timeout: 258 seconds]
ldevulder_ is now known as ldevulder
laurentC has joined #linux-sunxi
<Craphunzio>
apritzel deal. Going to put links then, and some better pictures.
kaspter has quit [Ping timeout: 256 seconds]
kaspter has joined #linux-sunxi
laurentC has quit [Quit: Leaving.]
laurentC has joined #linux-sunxi
t3st3rV2 has joined #linux-sunxi
lkcl has joined #linux-sunxi
t3st3r is now known as Guest70603
t3st3rV2 is now known as t3st3r
Guest70603 has quit [Ping timeout: 240 seconds]
<Craphunzio>
gasp, I am saving some edits but the browser is "waiting for linux-sunxi.org..." since a while... hope not to have to retype that :panic:
<KotCzarny>
maybe they got good price on that chip
<Craphunzio>
aren't there any specialized chips for HDMI output though? But indeed that must have been a good deal overall for _sure_
<Craphunzio>
For what matters identifying the UART pins, unfortunately measuring resistance between GND and VCC on those candidates is paradoxically difficult. I get different readings if I swap the probes (!!) and if I change multimeter as well, for a total of four different readings!
<diego71>
Craphunzio: it's powerful enough that can be used to emulate retro hw
kaspter has quit [Ping timeout: 256 seconds]
kaspter has joined #linux-sunxi
<Craphunzio>
diego71 indeed, but I'm confident it is not used for that, and the CPU is used instead.
<Craphunzio>
there are very few systems that are used to reproduce retro hardware so far. And the original image on that SD card uses MAME, which is a CPU emulator.
<KotCzarny>
maybe they also do some postprocessing on it, who knows
<Craphunzio>
* I mean there are very few FPGA system for retro simulation lol. There is a billion of CPU based alternatives
<Craphunzio>
do you have any clue about why I get very different RESISTANCE readings across two points of the powered off board according to the device I use and the orientation of the probes (that for resistance, makes no sense?) The multimeters have been tested against known resistors and they work just fine and accurately with them
<Craphunzio>
I think there __might__ be some capacitors that still need to discharge and that may get in the way somehow
<Craphunzio>
is that possible?
<plaes>
A13 does not have HDMI output
<plaes>
and lines from ECP3 go straight to HDMI output
<diego71>
Craphunzio: yes is normal if there is some capacitors, you need to wait for capacitor to be fully charged before having a useful reading about pure resistance
<paulk-leonov>
hi
<paulk-leonov>
does anyone know of the layout of axp209 register 0x81 ?
<paulk-leonov>
some BSP calls it BOOT_POWER20_VOUT_MONITOR
<paulk-leonov>
I suspect it has to do with over-current limitsd
<paulk-leonov>
ah it's in the axp152 datasheet
<Craphunzio>
thanks plaes your knowledge is amazing.
<paulk-leonov>
also AXP288
<Craphunzio>
thanks diego71, I tried to discharge the capacitors but I have not been able to.
Mangy_Dog has joined #linux-sunxi
<diego71>
discharging is not a solution, because when you tried to measure the resistance your meter it will charge them again, and you measure also the resistance of the capacitor
<apritzel>
Craphunzio: you are probably not measuring purely ohmic resistances
<apritzel>
Craphunzio: why do you actually care about measuring those pins? They are clearly labelled, and I would just try out which one carries the debug UART
<Craphunzio>
apritzel: well, to learn something in the process. I am following along an youtube tutorial series and that suggests to measure resistance that way to identify potential candidates (especially when they are NOT labeled although that is not my case) https://www.youtube.com/watch?v=6_Q663YkyXE
<Craphunzio>
can't wait for the darn adaptor to reach the inbox, but it could take days or even weeks :-(
<Craphunzio>
(cause I'm a cheapskate and I ordered from china lol)
<Craphunzio>
it's actually THREE adapters lol cause I didn't know which one would work better. all three of them cost 1/5 of a single one on Amazon
<Craphunzio>
*all together
<apritzel>
Craphunzio: ebay.it gives me offers of around 3 EUR incl. shipping, from Italy
<Craphunzio>
crap, I did not consider ebay :-(.
<KotCzarny>
never enough of those little buggers
<KotCzarny>
having more than one is useful
<Craphunzio>
which one would you recommend?
<apritzel>
for 115200 bps doesn't matter, really
<KotCzarny>
some say the 'not fake ones' have crystal on board
<MoeIcenowy>
jernej: when will you send out H616 U-Boot patches?
<MoeIcenowy>
I did some V831 work on top of your H616 work on GitHub
<apritzel>
MoeIcenowy: that's a Cortex-A7, right? how did "letting a 32-bit build use CONFIG_SUN50I_H6_GEN" work out for you?
<apritzel>
were there any hidden assumptions about arm64?
<MoeIcenowy>
apritzel: I moved FIT-related options to H6/H616
<MoeIcenowy>
using FIT is the biggest assumption
<apritzel>
right, makes sense
<MoeIcenowy>
but other than this, few
<MoeIcenowy>
and for CCU PLL configuration, V831 is more close to H616 than H6
<MoeIcenowy>
BTW I hope this option to be renamed CONFIG_SUNXI_GEN_SUN50I_H6
<MoeIcenowy>
because we have CONFIG_SUNXI_GEN_SUN[46]I
<apritzel>
yeah, please feel free to reply to jernej's patch once he posts that
<MoeIcenowy>
BTW the V831 DRAM controller seems to be mostly similar to our sunxi_dw one, but the mctl_com part is similar to H6
<MoeIcenowy>
and there are some magics that are known by REing boot0
<apritzel>
they are really eager to try all possible combinations of COM, CTL and PHY ;-)
<MoeIcenowy>
well this one is CTL+PHY combo
<MoeIcenowy>
but at least we got 3 situations now for 3 chips
<MoeIcenowy>
(maybe V831 selects to use old controller because of it expects legacy memory (DDR2)
<apritzel>
good point
<apritzel>
eventually we might think of modularising the DRAM controller code, so that a chip can mix and match COM, CTL and PHY code
<MoeIcenowy>
well, this is a big work
<apritzel>
indeed ;-)
<MoeIcenowy>
and sometimes operations interleaves
JohnDoe_71Rus has joined #linux-sunxi
<Craphunzio>
guys. While I am waiting for the USB-to-Serial adaptor, is there any way I could reverse-engineer the boot partitions I got so to discover more about how that kernel is built and how to build mine (and the userspace tools too) accordingly?
<Craphunzio>
Ehm, back to this morning. Does the fact that the FPGA is likely used for HDMI output relevant to me? Should I use this information to build a kernel or the way the video output is processed is transparent to the building process? Thanks!
<apritzel>
Craphunzio: we don't know if this "HDMI bridge" is really transparent, or needs some spoon-feeding first to get going
<apritzel>
but for the build process this would be mostly irrelevant
<Craphunzio>
ok. Thank you. Her, what would that spoon-feeding be eventually?
<apritzel>
dunno, could be anything
<jernej>
MoeIcenowy: I plan to send patches once Linux DT patches are acked
<apritzel>
jernej: not sure you should really wait for that, though
<jernej>
apritzel: DM clock driver depends on bindings
<apritzel>
I mean we have a lot to review already, and for now can ignore the details of the DT (in the first post, at least)
<smaeul>
there's a lot of duplication because the boot process is so different. It would be easier if U-Boot secure monitor was built as a separate image...
tuxd3v has quit [Remote host closed the connection]
bantu has quit [Quit: bantu]
<apritzel>
smaeul: you mean the SPL?
bantu has joined #linux-sunxi
<apritzel>
smaeul: or the PSCI runtime part?
<smaeul>
apritzel: the PSCI runtime part, that's currently memcpy()d to SRAM
<apritzel>
right
<apritzel>
I probably don't make many friends with that, but TF-A supports ARMv7 as well, Rockchip uses that for their 32-bit RK3288 SoC
<smaeul>
H3 SRAM A2 is only 32k, so fitting TF-A in 16k...
<smaeul>
apritzel: you're right, it is a possible option
<smaeul>
I have suspend on H3 working except for one thing: I cannot write the CPU0 hotplug flag register
<smaeul>
I verified that NBROM is reading 0x1f01dac, but that location seems to be RAZ/WI
<apritzel>
writing from the ARISC?
<smaeul>
yes, or from u-boot either one
<smaeul>
is there any other way to keep BROM from running when I turn CPU0 on?
<apritzel>
does the BSP stack support suspend on the H3, and does it actually use the ARISC for that?
<smaeul>
yes, and yes, and the blob appears to load an eGON image into SRAM A1 and use the super standby path (which is later in the BROM) to boot it
<apritzel>
I see, but it doesn't use the CPU hotplug mechanism at all?
<apritzel>
maybe they screwed it up on the H3, and are using super standby as a workaround?
<smaeul>
I don't think it lets you do CPU0 hotplug (nor does mainline). for other CPUs hotplug works fine
<apritzel>
so the H3 defines hotplug registers for each core, and the BROM checks them?
<smaeul>
no, the logic is "if mpidr != CPU0, goto hotplug; if CPU0 hotplug flag == 0xfa50392f, goto hotplug; goto normal_boot"