00:05 <cyrozap> Oh, I see.

00:09 <cyrozap> apritzel: What's the code located at lr=53ad8 when returning to FEL? Is that loaded by sunxi-fel or from somewhere else?

00:17 <apritzel> that's the trampoline code injected by sunxi-fel, to save and restore the FEL stack(s)

00:22 <apritzel> cyrozap: that corresponds to .thunk_addr = 0x53a00, .thunk_size = 0x200 in sunxi-fel's soc_info.c

00:34 <cyrozap> I see, thanks!

00:38 <cyrozap> With so many moving parts (boot ROM, stack-saving thunk, 32-to-64 bit transition, 64-bit to 32-bit transition), it's no wonder that a compiler change ended up breaking something. That's not a criticism of the software architecture--obviously it has to be this way to accomodate the quirks of the hardware--it just kind of explains why a small change like this ended up breaking some functionality.

02:18 <smaeul> any idea where in DE 2.0 between the UI layer and the TCON_LCD could add a blue tint to the image?

02:20 <smaeul> context: I'm bringing up an LCD panel on D1. all of the TCON test patterns (LCD_SRC_CEL) have correct colors

02:20 <smaeul> but the image from the framebuffer, or the UI layer fill color (LAY_FILLCOLOR_EN) always gets output with the blue channel >50%

02:41 <smaeul> https://distfiles.smaeul.xyz/distfiles/tmp/lcd_color_issue.jpg -- Top is the D1 with LCD. Bottom is a PinePhone for comparison.

02:41 <smaeul> all of the colors are affected, but it's most obvious that gray becomes blue as it gets darker

02:50 <smaeul> the normal-looking TCON test patterns: https://distfiles.smaeul.xyz/distfiles/tmp/lcd_color_pattern_1.jpg https://distfiles.smaeul.xyz/distfiles/tmp/lcd_color_pattern_7.jpg

10:09 <apritzel> cyrozap: I wouldn't say that it's "expected" to break: Yes, this whole code is tricky and somewhat cumbersome, due to the design, but it shouldn't be fragile.

10:11 <apritzel> as we just rely on architecture (32/64 transition) and the BROM behaviour, both of which are not changing

10:25 <mripard> smaeul: I'm not sure if you noticed, but it looks like your pixels are shifted by one or two pixels to the right

10:25 <mripard> if you look on the left, the blue rectangle has a white band on its left

10:25 <mripard> most likely coming from the right most, white, rectangle

10:25 <mripard> so it might be some offset somewhere?

10:26 <mripard> or a clock polarity issue between the TCON TOP and the TCON?

10:34 <apritzel> jernej: re AC200> so I think that making the MFD EPHY device also a reset controller, and referring to that from the actual PHY (MDIO) DT node, should solve the order issue, no?

10:36 <apritzel> jernej: and to avoid confusion, we should probably pitch the MFD EPHY device more as some kind of EPHY *control* device

10:39 <apritzel> another thing: you fixed the LED polarity and PHY address, should this be controllable via DT properties?

10:43 <apritzel> but I guess this can come later ...

11:21 <cyrozap> apritzel: What I mean is that if the SoC was simpler (boots in 64-bit mode instead of 32-bit mode, contiguous SRAM space, more SRAM space, FOSS BROM, etc.), there would be fewer points of potential failure. Like, if space for the SPL was contiguous, there wouldn't be a need to swap buffers around. And if it booted in 64-bit mode, we wouldn't ever have to switch back to 32-bit mode. And relying on

11:21 <cyrozap> BROM behavior can be troublesome, because the BROM is closed-source and our understanding of it is likely incomplete.

11:24 <cyrozap> Even FEL mode itself is not completely understood, as evidenced by this chunk of code (and others): https://github.com/linux-sunxi/sunxi-tools/blob/76089c82d0e1616aeb3b289790204dce98296477/fel.c#L855-L857

11:28 <cyrozap> So while the underlying functions aren't changing out from under us, if we don't have a complete understanding, we can make technical decisions that only apply in certain circumstances but not others, while being completely unaware of that.

11:30 <cyrozap> I guess the more concrete example would be, if some of the U-Boot code was relying on undefined behavior and only tested as working with an older compiler, a newer compiler that takes advantage of UB to perform more optimizations might break things.

11:31 <cyrozap> Like that instance where a newer version of GCC generated DRAM init code that would fault because the NEON instructions would perform unaligned accesses.

12:50 <apritzel> Well, yes, U-Boot is full of those assumptions, and it's not the most architecture compliant piece of software. But with people testing, we find those issues, and we fix them.

12:52 <apritzel> but to be honest: it could be much worse, when we could only boot signed code, or we would need to rely on magic blobs

12:56 <apritzel> cyrozap: and keep in mind: Allwinner SoCs were not designed to be nice to software people, actually they were never designed to be "general purpose computers" in the first place

12:56 <apritzel> some crazy people just decided to ignore that and make it work anyway, which comes at a price

13:59 <jernej> apritzel: that's actually pretty neat idea. will you work on that?

14:01 <apritzel> jernej: yes

14:02 <jernej> great, let me know if you need some help with testing

14:02 <apritzel> jernej: did you address the comments from the reviewers on that RFC post?

14:02 <jernej> no

14:02 <apritzel> ok, no worries, will take care of that

14:02 <jernej> because I didn't get no ideas for my main issue

14:02 <jernej> s/no/any/

14:04 <apritzel> sure, can see that

14:04 <apritzel> jernej: one other thing: to some degree this syscon register we already use has some similarities to that I2C register (I think you mentioned that already somewhere)

14:05 <apritzel> do we need to skip this syscon code in the MAC driver then?

14:05 <jernej> I don't remember talking about that

14:05 <jernej> ah, that

14:06 <jernej> I only said it doesn't make sense to check for default value

14:07 <jernej> wait

14:08 <jernej> yes, AC200 EPHY control register is basically the same as in syscon

14:09 <apritzel> I guess this syscon register will be ignored when we use the internal PHY?

14:10 <jernej> what if we link it to AC200?

14:10 <apritzel> yeah, that was the other idea I had

14:11 <apritzel> but it sounds tricky, as the format is different, so the MAC would need to know?

14:11 <jernej> is it really different? let me check

14:11 <apritzel> and also we would need both, depending on which PHY (external or internal) is in use

14:11 <jernej> that can be taken care of in DT

14:11 <apritzel> or the board .dts would overwrite the syscon link, depending on the PHY to use?

14:13 <apritzel> cyrozap: getting somewhere: when I enable both CONFIG_DRAM_SUN50I_H616_READ_CALIBRATION and CONFIG_DRAM_SUN50I_H616_READ_TRAINING, but turn off the other two, I see the same behaviour

14:14 <apritzel> cyrozap: but when I disable CONFIG_DRAM_SUN50I_H616_READ_TRAINING, it works with both compilers

14:14 <apritzel> (not really sure the DRAM actually works, or is stable, but at the least the code runs through)

14:14 <apritzel> so I will look at the generated code for CONFIG_DRAM_SUN50I_H616_READ_TRAINING

14:15 <jernej> apritzel: yes, I had in mind "overwriting syscon phandle in DT"

14:15 <apritzel> cyrozap: (I moved BSS into SRAM, to avoid the SPL touching DRAM at all)

14:15 <jernej> apritzel: that would also avoid need to have I2C regmap handle in PHY driver, which was one of the complaints

14:16 <jernej> but unfortunately, as you said, registers are not compatible

14:16 <apritzel> jernej: cool, I will play with both those options, and see where it takes me

14:17 <apritzel> jernej: I actually have an actual AC200 in the Remix Mini PC

14:17 <jernej> btw, PHY driver would also get loaded for older SoCs, because it has same ID as internal PHY on H3 and probably others

14:18 <jernej> so doing it totally independent of I2C would make a lot of sense

14:21 <jernej> apritzel: actually, AC200 EPHY register 6000h layout corresponds to upper 16 bit in syscon

14:22 <apritzel> yeah, I saw that, just not sure whether that's good or bad ;-)

14:33 <jernej> apritzel: I actually see easy solution, although some might say it's hacky

14:34 <jernej> apritzel: AC200 EPHY should export regmap, same as syscon

14:34 <apritzel> and convert the value written there?

14:34 <jernej> but you can implement reg_write callback, where you can shift value there

14:35 <jernej> yes

14:36 <jernej> and of course fake it to be on offset 0x30

14:36 <apritzel> worth a try, I guess, we should just be prepared that it could be shot down

14:37 <jernej> another way is to check compatible of phandle and select based on that

14:38 <jernej> s/select/use appropriate values/

14:39 <apritzel> in the MAC driver, you mean?

14:39 <jernej> yes

14:42 <jernej> faking it in regmap isn't really future proof. h616 and h6 have fortunatelly same layout, but that's not really guaranted

14:45 <jernej> checking compatible in MAC driver seems much cleaner solution, although not ideal

14:45 <apritzel> let me see how this ties in with the H616 double syscon problem, I had this patch to add an offset after the phandle: https://github.com/apritzel/linux/commit/0f6bf629c8c819552a16ff3dd4066a14f171806d

14:48 <jernej> well, you can't add that to H6, since DT is already out

14:48 <jernej> and layout is still different

14:50 <jernej> uh, I just hope we don't actually need both registers - syscon for lower 16 bits and AC200 EPHY ctrl for upper 16 bits

15:08 <cyrozap> apritzel: I appreciate you looking into this issue I've been having with FEL. I took a look at the BinDiff for the "read training" code, but unfortunately nothing obviously wrong jumped out at me. The compiler definitely made a _lot_ of changes to that code, though.

15:09 <cyrozap> Mostly instruction ordering and control flow.

19:19 <apritzel> cyrozap: I found one big issue: we put the initial SPL stack at the end of SRAM C, where it grows downwards into the buffer that the BROM uses

19:20 <apritzel> cyrozap: and just from simply looking at stack reservations at the beginning of each function, it looks like GCC 12 uses *slightly* more stack than GCC 10

19:21 <apritzel> but annoyingly this alone doesn't seem to fix it: I moved the stack below sunxi-fel's thunk and buffer, but it still hangs

19:52 <jernej> smaeul: you can also try setting LCD_RB_SWAP bit (23) in LCD control register (0x40)

19:52 <jernej> and also resetting fifo with bit 21 in the same register (assert and then deassert)

20:10 <jernej> apritzel: I did some tests, and lower 16 bits of H6 syscon for EMAC are still relevant, even with AC200 EPHY.

20:11 <jernej> If I set bit 15 (means internal PHY), ethernet stops working

20:48 <apritzel> jernej: ah, thanks, that's good info

22:07 <disctanger> configfs error: ``` [ 2035.636565] configfs-gadget gadget: uvc: uvc_function_bind() [ 2035.636608] configfs-gadget gadget: uvc: Unable to allocate streaming EP [ 2035.636647] udc musb-hdrc.2.auto: failed to start g1: -22 ```

22:07 <disctanger> My question: Is there any way to get UVC working on this device? Maybe something like recompiling kernel with additional options etc...

22:07 <disctanger> By the way, i have tried USB Ethernet on OTG port and it is working fine without issues. I can connect to PineCube from host device after setting up the network.

22:08 <disctanger> OS: Armbian focal (22.02.0-trunk.0003) armv7l

22:08 <disctanger> Kernel: 5.15.35-sunxi

22:08 <disctanger> CPU: Allwinner sun8i Family (1)

22:09 <disctanger> lsmod output usb_f_uvc 49152 6 videobuf2_vmalloc 20480 1 usb_f_uvc videobuf2_dma_sg 16384 1 usb_f_uvc libcomposite 45056 14 usb_f_uvc 8189es 1380352 0 cfg80211 495616 1 8189es sun6i_csi 32768 0 axp20x_adc 16384 0 videobuf2_dma_contig 20480 1 sun6i_csi industrialio 57344 1 axp20x_adc ov5640 28672 1 videobuf2

22:15 <disctanger> lsmot output: usb_f_uvc, videobuf2_vmalloc, videobuf2_dma_sg, libcomposite, 8189es, cfg80211, sun6i_csi, axp20x_adc, videobuf2_dma_contig, industrialio, ov5640, videobuf2_memops, v4l2_fwnode, videobuf2_v4l2, videobuf2_common, v4l2_async, evdev, rfkill, zram, uio_pdrv_genirq, uio, sch_fq_codel, ip_tables, x_tables, autofs4, pinctrl_axp209, pwrseq_simple, sun4i_lradc_keys, sunxi, phy_generic

22:28 <apritzel> disctanger: have you removed the Ethernet gadget configuration before setting up UVC? Each Soc has only a limited number of endpoints, and having multiple gadgets configured at once might exceed this number

22:29 <cyrozap> apritzel: I love those kinds of issues--where you find and fix *a* bug but it's not *the* bug that's causing the problem :P

22:30 <apritzel> cyrozap: yeah, at the end we might have fixed more than one bug, so it's an even bigger win! ;-)

22:31 <apritzel> atm I am trying to figure out what part of SRAM the NBROM is using exactly during FEL operation

22:32 <apritzel> and see if I can set up a trap to catch the SPL red-handed when it's clobbering it

23:00 <disctanger> apritzel: Yes, there was no ethernet gadged configuration during UVC setup.

23:34 <disctanger> The OS is freshly installed and i did UVC set up on fresh reboot(while no any other gadgets loaded).