06:12 <narmstrong> xdarklight: nice!

06:12 <narmstrong> f_: sure go ahead

09:05 <CounterPillow> xdarklight: thank you for working on the ch348 driver, I have some ch348 boards I made (and did find that the proposed mainline driver didn't block on full buffer) so the issue getting attention from someone is fantastic to see :)

09:07 <CounterPillow> Let me know if I can help out in some way, I still have all the boards around

09:11 <minute> ok,

09:11 <minute> oh, there is some initial a311d2 work?https://lore.kernel.org/linux-arm-kernel/20230629073419.207886-4-tanure@linux.com/T/

11:17 <xdarklight> CounterPillow: ah, you're here as well :-) maybe you can give https://github.com/xdarklight/ch348 a try on your board. I'm unable to reproduce the instability that I saw yesterday anymore (I've been testing with montjoie's python script so far and the 2048 byte case was the one that gave me trouble)

11:17 <f_> minute: yes, work led by LucasTanure

11:19 <f_> IIRC it boots now

11:27 <rockosov> narmstrong: Hello Neil,

11:27 <rockosov> Hope you are doing well. Our current focus involves the development of Amlogic bootloader write operations within the Linux kernel and U-Boot for the rawnand meson driver. This involves a unique format for storing bootloader copies using "info_pages". The primary architectural challenge lies in the fact that "info_pages" are written using SCRAMBLING MODE and a special 384-bit ECC SHORT MODE.

11:27 <rockosov> We find ourselves confused regarding the implementation of this in the upstream driver. While it's true that Amlogic combines data format and NAND driver, we are unable to ignore it as the BootROM expects to encounter this specific data format for the bootloader.

11:27 <rockosov> Do you have any suggestions or ideas that we could explore in addressing this issue? Appreciate any help on that...

11:28 <rockosov> We tried to think about separate nandchips for bootloader partition and other partitions, but it doesn't work, because only info_pages (a part of bootloader partition) are written using such special modes..

11:31 <xdarklight> rockosov: there's the NAND_IS_BOOT_MEDIUM flag (and I think there's also a corresponding dt-flag): https://elixir.bootlin.com/linux/v6.7/source/include/linux/mtd/rawnand.h#L187 - it's used (for example) by the rockchip driver to use a special ECC mode when writing: https://elixir.bootlin.com/linux/v6.7/source/drivers/mtd/nand/raw/rockchip-nand-controller.c#L635

11:33 <rockosov> xdarklight: Does it support optional ECC mode switching in runtime?

11:33 <rockosov> Because looks like other bootloaders chunks should be written without SHORT and SCRAMBLING MODE

11:34 <rockosov> Amazing architectual solutions from Amlogic :-)

11:35 <xdarklight> rockosov: at least the rockchip driver is setting up the ECC engine here if it detects that it's writing to the boot area: https://elixir.bootlin.com/linux/v6.7/source/drivers/mtd/nand/raw/rockchip-nand-controller.c#L639

11:36 <rockosov> Ahhh, I see. You suggest to create two nand chips, the first one with boot_medium for bootloaders things and the second one for the general partitions..

11:37 <rockosov> And implement boot_medium mode with the special ECC and SCRAMBLING handling

11:39 <xdarklight> rockosov: I haven't done much with NAND drivers yet (and most things I have attempted didn't work). so I'm just saying that the rockchip driver does something special for the bootloader ;-) from what I've seen in the past the NAND maintainers are helpful, so I think it's worth checking with them

11:40 <rockosov> xdarklight: Thanks a lot for this flag, we will try to figure out deeper! Do you know any IRC channel with nand core team?

11:41 <xdarklight> rockosov: according to http://www.linux-mtd.infradead.org/mail.html (at the bottom) there's an IRC channel on OFTC

11:41 <xdarklight> rockosov: and you're welcome - it's always great to see things being upstreamed :)

11:42 <rockosov> Sure, more strong upstream solutions = better firmare quality for production devices! :-)

12:01 <narmstrong> too late, but thx xdarklight for the hint!

19:37 <xdarklight> montjoie: I pushed an update to https://github.com/xdarklight/ch348 earlier (now with more documentation and history cleaned up). I'm using your python script for testing and ALL tests are now passing, even with: BAUDS = [50, 75, 110, 150, 200, 300, 600, 1200, 1800, 2400, 4800, 9600, 19200, 38400, 57600, 115200, 230400, 921600, 1500000, 2000000, 6000000, 12000000]

19:39 <xdarklight> CounterPillow: I also ran your test tool for a little bit. it reports 0.000% error rate - which I assume is good :)

19:39 <CounterPillow> \o/

21:16 <xdarklight> narmstrong: I need to test on the Le Potato board in the next days but I got a report of display output not working on the 32-bit SoCs if the board enables the CVBS output. the kernel log shows "Failed to find CVBS Connector bridge" and then doesn't even initialize HDMI. this is just a heads up to let you know that there may be issues on boards with CVBS output enabled (those without CVBS output may be fine) - or if the 64-bit SoCs are fine that

21:16 <xdarklight> I did something wrong

22:05 <xdarklight> narmstrong: ...and we have a patch: https://lore.kernel.org/linux-amlogic/20240215220442.1343152-1-martin.blumenstingl@googlemail.com/T/#u