11:26 <marc|gonzalez> narmstrong: xdarklight: Hello! Is it possible that a node uart-a-ao-c is missing in arch/arm64/boot/dts/amlogic/meson-g12-common.dtsi ?

11:27 <marc|gonzalez> (inside the ao_pinctrl: pinctrl@14 node)

11:27 <narmstrong> marc|gonzalez: it’s probable if none of the current board used it

11:27 <narmstrong> Or exposed it

11:28 <marc|gonzalez> AFAIU, my board muxes the console & the SDcard slot, and apparently the pin setup depends on uart-a-ao-c

11:28 <marc|gonzalez> (I must say that I know very little about this topic)

11:29 <marc|gonzalez> If I'm not mainlining support for a board that uses these pins, there is no point in submitting a patch for the node?

11:30 <marc|gonzalez> narmstrong: also, did you see my email about the typo in the 3rd patch? I don't know if there are git fixups at this stage?

11:31 <narmstrong> marc|gonzalez: you can but if it’s untestable there’s little point in doing this

11:32 <narmstrong> marc|gonzalez: I saw this, I haven’t sent the pr yet so I can fix stuff

11:34 <marc|gonzalez> narmstrong: untestable = on a non-public board?

11:34 <narmstrong> marc|gonzalez: whatever board, if you can validate it then yes it’s ok to be upstreamed

11:35 <marc|gonzalez> I have validated it on the sei530 board. I tried using a different pin config, and the console stopped working :)

11:37 <marc|gonzalez> Maybe some baylibre devs have an sei530 board to test with

11:43 <phh> [13:28:40] <marc|gonzalez> AFAIU, my board muxes the console & the SDcard slot, and apparently the pin setup depends on uart-a-ao-c <--- they all do

11:44 <marc|gonzalez> phh: OK then I am confused why the pin setup is different than on the sei510 board?

11:44 <marc|gonzalez> Is it a minor tweak from SEI?

11:44 <phh> marc|gonzalez: because "normal" people solder serial port, and we're lazy, we just use the sdcard connector rather than dismantling the box

11:45 <phh> but we do have the same non-sd "debug" uarts test points as sei510

11:45 <marc|gonzalez> phh: you mean the data path are muxed, but our board goes further and muxes the physical slot?

11:45 <phh> marc|gonzalez: our board doesn't do anything specific

11:45 <phh> it's the way we use it

11:45 <marc|gonzalez> My confusion stems from the different pin setup required for the sei530 board

11:46 <marc|gonzalez> specifically uart_AO { pinctrl-0 = <&uart_ao_a_c_pins>; }

11:46 <phh> it's not related to the board, it's only related to the fact that the serial port you're using is over serial port, but you could just dismantle the box and solder the serial port on the PCB, and you'd be using same device-tree as SEI510

11:46 <phh> amlogic bootloader automatically detects on boot whether you have the uart-over-sd-connector adapter, and changes pinmux based on that

11:47 <phh> vendor kernel also does that auto-detection

11:48 <marc|gonzalez> For the record, mainline reports "meson-g12a-pinctrl ff634400.bus:pinctrl@40: pin GPIOC_2 already requested by ff803000.serial; cannot claim for ffe05000.sd"

12:14 <narmstrong> this auto detection could be done by u-boot, and DT altered to enabled the UART instead of the SD port, but to far this isn't needed on the public SBC boards

12:14 <narmstrong> we have access to debug uart over headers

13:04 <hays> has anyone had the issue where occasionally boot gets stuck at uboot prompt for some reason without hitting a key or even having serial console connected?

13:05 <hays> i wonder if there is noise on the pin header

13:05 <hays> seeing it with n2-plus

13:05 <hays> somewhere between 2-5% of the time

13:17 <narmstrong> yep it must be noise on the uart

13:22 <hays> i wonder if i can patch or configure uboot to require a specific key

13:30 <hays> hmm you know what i bet this is just happening because i have that long serial uart attached to it and it is disconnected on the other end. basically i've made an antenna

13:41 <xdarklight> you have to make a better antenna for UART over the air ;-)

13:42 <xdarklight> just joking, chewitt recently found CONFIG_AUTOBOOT_STOP_STR, CONFIG_AUTOBOOT_DELAY_STR and CONFIG_AUTOBOOT_KEYED

13:42 <xdarklight> I think these (in some combination) can be used to make u-boot only pause for a specific string

17:01 <chewitt> hays I attempted to implement this the other day https://github.com/BrianAdams/Bootloader-Builder/blob/fix/autoboot/patches/next/0003-Autoboot-keyboard-beaglebone-fixes.patch

17:02 <chewitt> it didn't work, but that's probably due to my non-coding skills more than anything

22:23 <Cheaterman> Bliblibli buddiez I hope y'all doing goodie ^__^

22:23 <Cheaterman> Thanks again chew and neil for the help making me part of history, really appreciated

22:24 <Cheaterman> I suggested N2+ to a pal who does similar things to me and they say they need the equivalent of a Pi4 compute module

22:24 <Cheaterman> So they found this on Aliexpress https://www.aliexpress.us/item/3256803453407727.html

22:24 <Cheaterman> It seems really good from what I can see and really compatible with their usage ; I was wondering if you'd have some comments

22:25 <Cheaterman> It's worth noting they're a company too, not an individual maker, so if you have alternatives for sourcing that might be more reliable than Aliexpress (if more expensive) please let me know

22:38 <leadf00t> <waves> Hello!

22:38 <Cheaterman> Welcome leadf00t :-) they're the pal in question hehe

22:40 <leadf00t> I ordered an S922X SOM + carrier board that has a MIPI DSI conenctor. I was wondering if there was a chance at all I'd be able to get an LCD panel working with it :)

22:40 <leadf00t> I'm working with Waveshare and their panels, so hopefully they might have some tips.

22:41 <leadf00t> Is the S922X known to work with MIPI DSI panels already ?