00:29 <StereoRocker> Label MAC address on FAP221B is stored as text, but without colons. To get running I've made a new function in base-files/files/lib/functions/system.sh that does the same as mtd_get_mac_text() but with 12 characters instead of 17. What would be preferred to maintain sanity in the tree; new function, or modify mtd_get_mac_text to accept a parameter that makes it do a shorter read? Or perhaps have I missed another function that would do what

00:29 <StereoRocker> I'm looking for anyway?

03:17 <jayk> /win 2

08:00 <Znevna> hello, can anyone chip in to make this into an option like we have for ath10k / ath10k-ct ? https://github.com/openwrt/openwrt/pull/11601/files#diff-5c604c6d1ee7a8a1830c2c1bb5e67e70324db4352c4c2bc402e09910df06f3be

08:01 <Znevna> I've added this into the Makefile, https://paste.debian.net/plainh/22c7fe3a but I don't know how to make it appear as an option x.x

08:15 <owrt-snap-builds> Build [#746](https://buildbot.openwrt.org/master/images/#builders/32/builds/746) of `omap/generic` completed successfully.

10:11 <neggles> nkko: ah, if you're going to desolder it then you can use a T48 :P but the T56 is more capable overall

10:12 <neggles> they're definitely not garbage, they've been around for ages and are quite well-respected all things considered

10:13 <nkko> hmm, T48 also has emmc support

10:13 <nkko> yeah, the T56 must just have the 56 pin socket with a faster microcontroller?

10:13 <neggles> it has an FPGA

10:14 <neggles> hence the massive price difference

10:14 <nkko> ah

10:15 <neggles> I believe the T48 is a GigaDevice chip that's a Not-A-Clone of an STM32F4 series chip

10:15 <neggles> it's the third generation of the TL866 series

10:15 <nkko> I might as well just get the T56 if I come across a 56-pin chip

10:16 <nkko> *in case I

10:16 <neggles> tbh knowing what I know now

10:16 <neggles> I'd have just bought the T56 probably

10:16 <neggles> T48's name is a bit of a misnomer. it's only got a 40 pin socket, T56 only has a 48P

10:17 <neggles> but there's adapters for 56-pin; 56P parallel NOR has a significant number of dead/optional pins

10:18 <nkko> huh, 48 pins? hmm

10:18 <neggles> most of the chips can run with a 16-bit-wide data bus, but they all support 8-bit, so programmers just run in that mode

10:18 <nkko> listing says 56 pins

10:18 <neggles> it supports 56-pin chips via adapters https://lounge.neggl.es/uploads/4766ad5419d46f40/AD_T48_E3..jpg

10:19 <neggles> but that's from the vendor ^

10:19 <neggles> the T48 supports 56p parallel NOR also

10:19 <neggles> you just can't use a straight-through adapter

10:19 <nkko> ah, well, I bought two of those adaptors, so I better just get the T56

10:21 <neggles> yeah, I messaged their aliexpress store & the rep said they have an FFC adapter for 48p NAND in production, but they don't think it'll be available till after new year

10:22 <neggles> so far I've been able to get away with just using JTAG to mess with parallel NOR, thankfully

10:25 <neggles> it's also veeeeeery uncommon on modern things. very thankful that most stuff is SPI NOR/NAND and/or eMMC now. still too much parallel NAND in broadcom town, but them's the breaks

10:29 <PaulFertser> neggles: how do you use that T56, I mean I didn't see any software for GNU/Linux host that supports it?

10:29 <neggles> I have a T48 and I just use the windows software

10:29 <neggles> most of the time I'm using flashrom with a ch341a thing or a vserprog'd XTW100

10:30 <PaulFertser> So they do not even publish the USB protocol specs? Nasty, such a company shouldn't be supported :/

10:30 <neggles> but I went poking around inside the T48 software and didn't find anything sus, checked network traffic and all it does is ping a url at startup which responds with the latest version

10:30 <nkko> well, it doesn't matter to me

10:30 <neggles> I don't think it would be super useful even if they did

10:31 <PaulFertser> Parallel NOR is relatively easy when you have JTAG as it's just sitting there on the bus and supports CFI commands.

10:31 <neggles> it seems like most of the code is downloaded into ram at runtime depending on what you're accessing

10:32 <neggles> and yeah, ideally i'd use something less locked up / proprietary, but you can add chip definitions in the software yourself, it's not doing anything malicious as far as I can see, none of the code's really obfuscated; my main complaint is that T48 has little "DRM chips" on some of the adapters - T56 does not, however

10:32 <neggles> but they charge completely reasonable prices for the adapters in question, and it's only for the eMMC and parallel NAND/NOR really

10:33 <nkko> I don't like the idea of vendor lock-ins, so T56 ftw

10:33 <neggles> yeah totally fair

10:33 <nkko> I remember getting burned on HP H/W RAID controllers

10:34 <neggles> I got a T48 with all the adapters I could conceivably need (except for 360clip FFC but those are coming) for about the price of a bare T56 unit, so i'm not really complaining

10:34 <neggles> it was a much better deal than the #@$%@ing FlashcatUSB XPort

10:35 <neggles> which claims to support SPI NAND, but what they *don't* mention is that the *read* speed is 17KB/sec.

10:35 <neggles> yes. 17.

10:35 <neggles> it took *four hours* to dump a 1Gbit SPI NAND

10:36 <neggles> it also can't read parallel NAND over 2Gbit *sigh*

12:08 <owrt-snap-builds> Build [#741](https://buildbot.openwrt.org/master/images/#builders/62/builds/741) of `tegra/generic` completed successfully.

22:54 <mrkiko> Anyone of you having experience with an Intel NUC? I would need to boot it from USB but without the screen, so without interacting with the BIOS. Google turns up no useful results so far

22:57 <minimal> mrkiko: you'd need a display and keyboard to set up the BIOS/UEFI initially though wouldn't you? Also I think some NUC's might not boot without a display (or is it older Mac Minis I'm thinking of?) where you can get dongles to plug into HDMI/DVI to pretend there is a display attached

22:59 <karlp> aiyion: can't sunxi just use a default mac based on the SID in the chip itself instead of looking for one from the sd card or emmc?

22:59 <karlp> that's what uboot does iirc?

23:01 <slh> mrkiko: it mostly depends on how the UEFI boot order is set up - and that's kind of unspecified, as it's both configurable from the 'BIOS', as well as efibootmgr/ bcdedit and friends, which are commonly used to modify the respective UEFI variables determining boot entries and their order

23:02 <slh> the only thing that might work, is at least connecting a (USB-) keyboard temporarily, to override this 'unknown' default and test the various boot overrides one by one, until it boots from the expected medium (and then using efibootmgr to make that permanent)

23:03 <Habbie> speaking of dongles, a friend needed to fake a VGA display last week and did it with a few resistors instead of buying a dongle; i understand the same trick may work for DVI and even HDMI

23:04 <slh> I seriously hope that old bug with mainboards not booting in UEFI mode if no monitor is attached to be a thing of the past (I'm seeing it on a 2013 vintage ASRock Q1900DC-ITX myself, but fortunately not any other of my systems - and even that ASRock board ignores the issue with CSM being enabled for display initialization)

23:05 <aiyion> karlp: I think you are right. A friend of mine suggested it on christmas eve I think.

23:05 <slh> yes, that's what those dongles do - just a connector with one- or two resistors

23:06 <slh> fooling the screen present detection (only very high-end ones fake the i2c connections for full display detection)

23:06 <mrkiko> slh: thanks

23:06 <mrkiko> and thanks to all

23:07 <mrkiko> slh: yes, the problem is - I tried ESC key but seems to not work

23:07 <mrkiko> I'll have to reach for a display

23:07 <slh> mrkiko: it's usually F10, F11 or F12

23:07 <slh> depending on the vendor (should be specified in the manual)

23:07 <karlp> aiyion: I mean, code to generate from sd/mmc is interesting and all, but it just seems unnecessary

23:08 <aiyion> full ack. I learnt about it too late.

23:08 <aiyion> I'll hand in the revised patch tomorrow or so.

23:09 <mrkiko> slh: yeah, but trying it out this way is risky - I wouldn't like to change a bios option without knowing

23:09 <mrkiko> but ok, I'll wait until I can do this...

23:11 <slh> ...and then there are the faulty UEFI implementations, ASRock (H77 Pro4-M) again, which forget their boot order on BIOS updates or empty CMOS batteries, which play silent brick if just the CMOS battery empty or where just booting windows once will reset the configured UEFI boot order to windows every time...

23:12 <slh> mrkiko: google suggests F10 to open the boot menu

23:13 <slh> How to boot from USB NUC?

23:13 <slh> Insert the USB flash drive in the NUC. Start the NUC and push F10 to enter the boot menu. Select the USB flash drive as a boot option.

23:17 <slh> if you can get some kind of desktop linux booted, efibootmgr is rather easy to use - bcdedit on windows is more an act of masochism

23:18 <minimal> slh: you don't necessarily need efibootmgr if the bootable image setup up the EFI fallback boot name ESP/BOOT/BOOTX64.EFI

23:18 <minimal> that's assuming it tried to boot off a device in the 1st place

23:20 <slh> minimal: I'm aware of that, but I assume that the system in question was previously configured for some other installed OS (at least windows) - and the removable media path is ignored in the presence of a differently configured UEFI boot order

23:21 <slh> so you either need to override it while booting, from the boot menu (F10 in this case) - or change the boot order permanently with a tool /like/ efibootmgr

23:21 <slh> and I just assume that efibootmgr is easiest to use with a screen reader

23:22 <slh> at least bcdedit is not user friendly at all (the GUID based approach alone is already hostile, but its user interface is pretty bad even assuming normal usage)

23:23 <slh> and I wouldn't expect the in-BIOS selection to be forthcoming to a screenreader

23:23 <minimal> slh: that all assumes its not a machine that won't boot at all if it can't get EDID info from a display

23:23 <slh> correct

23:24 <slh> but I sincerely hope that this kind of brokeness is in the past, now

23:25 <slh> but BIOS/ UEFI implementations being on crack isn't uncommon, News at 11

23:26 <minimal> slh: I would'nt necessarily call that "brokeness" but rather a "strange requirement decided upon by the vendor"

23:30 <slh> sorry, but I can't find any excuse for that kind of behaviour - systems are used headless, might not be the most common usage for desktop centric systems, but it's not strange either

23:31 <slh> even more so small form factor devices

23:39 <mrkiko> infact I tried f10 but ... who knows. I'll reach for a screen. Little bit annoying... but that's how it goes

23:43 <slh> f10, followed by cursor down (unspecified amount of times) and space or enter, I'd venture - but, unless you know the system, hard to guess without a monitor attached

23:49 <mrkiko> howeever, an HDMI to braille "converter" would be so usefultriny :D

23:53 <slh> I wonder if things like google lense might do part of the job

23:53 <slh> it wouldn't be that far away from their current feature set