05:31 <KGB-2> https://tests.reproducible-builds.org/openwrt/openwrt_mpc85xx.html has been updated. (100.0% images and 100.0% packages reproducible in our current test framework.)

06:40 <KanjiMonster> there was an interesting patch posted yesterday that could help reduce the kernel size a bit: https://patchwork.kernel.org/project/linux-wireless/patch/20241009181339.0b1a6eaef573.Ia80b55e934bbfc45ce0df42a3233d34b35508046@changeid/

06:44 <owrt-images-builds> Build [#383](https://buildbot.openwrt.org/images/#/builders/115/builds/383) of `master_x86/64` failed.

06:44 <owrt-images-builds> Build [#400](https://buildbot.openwrt.org/images/#/builders/13/builds/400) of `master_lantiq/xrx200` failed.

08:54 <russell--> hmm. that's weird. restarting log and dnsmasq and it starts logging

09:01 <Svanto24> hello, is this channel strictly for development of the openwrt Linux distribution or porting it to new devices as well?

09:04 <russell--> from a quick test, apparently if the log service is restarted, but dnsmasq is not restarted, dnsmasq logging gets lost

09:16 <schmars[m]> Svanto24 porting is also fine

09:21 <Svanto24> schmars[m]: oh okay sweet! I'm currently trying to get a Huawei ap7050de on openwrt, which is an IPQ8068-based target. I posted the boot logs here 'm trying to figure out what to do next. Should I just flash stock openwrt and see if I am held back by the same 1.6s watchdog and PHY suspension, that von Rosenberg was with the AP5030DN, trial and error?

09:21 <Svanto24> oops, sent that prematurely sorry

09:22 <Svanto24> https://forum.openwrt.org/t/ipq8068-support-for-huawei-ap7050de/212519

09:22 <Svanto24> but yeah. it seems to have the same broadcom PHYs as the AP5030DN that is already supported but I cannot find any info on if there is a hardware watchdog or not.

09:23 <Svanto24> Let alone secure boot, worse yet efuse

09:23 <schmars[m]> u-boot is also very very stipped down

09:23 <schmars[m]> good luck i gotta go :-)

09:23 <schmars[m]> *stripped down

09:24 <Svanto24> OK bye!

09:28 <schmars[m]> you can try booting an initramfs image of a similar device with the `update` u-boot cmd

09:28 <schmars[m]> and see how far that gets you. i did the same yesterday for a mediatek device, but the internals were nearly 1:1 identical

09:32 <Svanto24> schmars[m]: similar as in same manufacturer or same target? also it has tftp if that helps

09:39 <schmars[m]> same target, same amount of ram, same number of ethernet ports, something like that, the closer the better. just try, sometimes that works decently

09:40 <schmars[m]> and see if that boots you can see if you can extract a device tree definition

09:42 <Svanto24> there isn't much of an equivalent but I can try to build an image. main issue is not blowing any hardware fuse that may or may not be present, like Cisco has.

09:46 <Svanto24> I think it also has this sort of two step bootloader?

09:57 <Svanto24> if it's bricked via hardware fuse, is it still possible to save it by desoldering NAND? or are hardware fuses an on-fie thing?

09:57 <robimarko> Its on the SoC die

10:00 <Svanto24> robimarko: Thank you! Are these fuses present on the IPQ806x SoC?

10:01 <robimarko> All of the QCA ARM SoC-s have secure boot and thus fuses for it

10:06 <Svanto24> robimarko: Ah okay. So basically I have to sacrifice the device to test if secureboot is present or no?

10:07 <robimarko> Usually there is a command in U-Boot to check for state of secure boot

10:10 <KanjiMonster> Svanto24: do you have any links about these cisco devices bricking themselves?

10:10 <KanjiMonster> meh

10:10 <KanjiMonster> Svanto24: do you have any links about these cisco devices bricking themselves?

10:14 <Svanto24> KanjiMonster: sure, here https://github.com/riptidewave93/LEDE-MR33/issues/13#issuecomment-449849255

10:14 <KanjiMonster> thanks

10:31 <Svanto24> robimarko: I mighr be in the clear rhen... what does the secureboot command look like? Here's my Uboot output. Does one replace the original uboot when flashing OpenWRT? aging - aging cmd

10:31 <Svanto24> apmode - apmode {fit|fat|cloud}

10:31 <Svanto24> clear_emt- clear_emt: clear emt file

10:31 <Svanto24> clear_passwd- clear boot password

10:31 <Svanto24> defaultuser- use the default user(admin) or the custom user

10:31 <Svanto24> format_fs- file system format bit will be set

10:31 <Svanto24> h2f - setting the flag to decide whether to write the data in highmem to flash or not

10:31 <Svanto24> help - print command description/usage

10:31 <Svanto24> passwd - modify boot password following prompts

10:31 <Svanto24> pdinfo - show product information

10:31 <Svanto24> pdmac - set MAC addresses of product

10:31 <Svanto24> ping - send ICMP ECHO_REQUEST to network host

10:31 <Svanto24> printenv- print environment variables

10:31 <Svanto24> reset - Perform RESET of the CPU

10:31 <Svanto24> run - run commands in an environment variable

10:32 <Svanto24> saveenv - save environment variables to persistent storage

10:32 <Svanto24> setenv - set environment variables

10:32 <Svanto24> update - update boot or system from tftp

10:32 <Svanto24> version - show boot and system version

10:32 <robimarko> Oh they modified it severely

10:33 <robimarko> Do you have the SBL log?

10:33 <robimarko> Though I think it only prints secure boot status on AX SoC-s

10:34 <Svanto24> I do yeah, no secureboot status in the log: https://forum.openwrt.org/t/ipq8068-support-for-huawei-ap7050de/212519/5

10:34 <robimarko> Not that, SBL is before U-Boot

10:36 <Svanto24> oh. This is the earliest log the device prints after power on

10:39 <robimarko> Then they disabled that (Ugh), sadly I am out of ideas

10:40 <Svanto24> that's okay, thank you. when flashing openwrt, do we keep the stock uboot?

10:40 <robimarko> No idea about your device, but usually yes

10:40 <Svanto24> I can probably just risk it. if I *do* brick it, would desoldering and resoldering the NAND circumvent secureboot issues due to blown fuses or do the fuses just kill the SoC altogether?

10:42 <KanjiMonster> why does the uboot prompt say "ar7240>"???

10:44 <Svanto24> good question. there's sort of a two console thing. if I interrupt the boot I go to the console with the prompt >ar7240. if I go all the way and long into the huawei serial interface the prompt says Huawei>

10:45 <Svanto24> *log

10:46 <\x> maybe the bootloader is in nor, not nand

10:46 <\x> atleast from that 4M + 128M setup

10:47 <\x> its likely soic8, look around

10:49 <Svanto24> \x: nor flash chip? I see, thank you. but how does that factor into porting the device?

10:53 <Svanto24> ohh I see, I need to map the flash storage eight?

10:53 <Svanto24> *right

11:06 <Svanto24> it doesn't look like von Rosenberg has changed the bootloader for the 5030dn, which has the same PHYs, instead using kernel patches...

11:06 <Svanto24> Also from his patch notes for that device: "The stock firmware has a semi dual boot concept where the primary kernel uses a squashfs as root partition and the secondary kernel uses an initramfs. This dual boot concept is circumvented on purpose to gain more flash space and since the stock firmware's flash layout isn't compatible with mtdsplit." That might be why I have two consoles, per

11:06 <Svanto24> previous question. This is probably so that the AP can switch between FIT/FAT/AP modes easily. "The external watchdog's timeout of 1.6s is very hard to satisfy during bootup." Idk wheter this watchdog is present. if it is, and I flash openwrt, will I screw myself or can I just go back to uboot?

11:10 <KGB-0> https://tests.reproducible-builds.org/openwrt/openwrt_bcm47xx.html has been updated. (100.0% images and 100.0% packages reproducible in our current test framework.)

11:27 <russell--> is there a way of telling that a sysupgrade command is being executed (e.g. so i can program some hotplug scripts not to fire)?

11:35 <schmars[m]> doesnt literally everything non-essential get killed before sysupgrade really starts

11:39 <Svanto24> \x: do you have any info on how I may be able to analyze the device's flash layout or how to flash openwrt for a 4M NOR + 128M NAND device?

11:39 <Svanto24> I don't think I ever had another device with such a setup

11:50 <Svanto24> it looks like there's a primary and secondary CPU in the bootlog too? god damn this is complex.

11:50 <\x> Svanto24: you can check on how R619AC is implemented

12:00 <Svanto24> \x: I'll try to look if I can see some info on where the uboot is and how everything is partitioned. Thanks!

12:05 <Svanto24> technically I shouldn't be touching anything in the 4mb NOR right? maybe that's the point, prevent corruption by limiting the flashable portion to the NAND. We will see. Hopefully there's no secureboot shenanigans to blow my fuses, or I'll be back to ask if replacing the NOR can fix that

12:13 <\x> yup

12:15 <Svanto24> let's try to just slip in stock openwrt through the tftp interface and see what happens then.

12:21 <Svanto24> I do have a suspicion I may run into trouble dealing with the heavily modified uboot but I'll cross that river when I get there.

12:22 <Svanto24> as it probably loads different setups based in the mode it is running in.

12:22 <Svanto24> but so does the 5030dn and it looks like von Rosenberg dealt with that somehow.

12:34 <Svanto24> Either way x/ does it look like uboot or something proprietary??

12:34 <Svanto24> sorry, didn't mean to type two question marks

13:01 <Svanto24> I need to map flash memory to flash openwrt right? How would I do that?

17:01 <Slimey> https://nvd.nist.gov/vuln/detail/CVE-2024-43047#match-13330122

17:02 <Slimey> Qualcomm Multiple Chipsets Use-After-Free Vulnerability

17:21 <robimarko> Luckily for us, all mobile SoC-s

17:22 <robimarko> Ugh, some hit WLAN SoC-s as well

17:56 <Stat_headcrabbed> Seems maybe only exists in downstream android driver?