<Tusker>
something weird is happening with ath79 target and mtd-split... the sysupgrade image has the rootfs offset at 0x210000 but mtd-split sets it at 0x740000, and then the kernel can't find the root filesystem... any ideas on what has changed?
<russell-->
Tusker: what device?
<Tusker>
ruckus r500 - I have a PR open, and I did a git reset to head and cherry-pick, and now the image generation doesn't seem to match the partition layout anymore
<Tusker>
it definitely worked prior to the rebase, so a bit confused :)
rmilecki has joined #openwrt-devel
<Tusker>
i suppose I need to look at all commits between June and now to see if anything has changed related to that
<Tusker>
i can work around it by making the sysupgrade image with lots more padding... but that seems like a dodgy fix
dedeckeh has joined #openwrt-devel
<mrkiko>
Tusker: wow! I was reading about the header stuff. Nice.
<Tusker>
not as much progress as I would like...
<Tusker>
tried brute forcing it with various parts of the header, but I can't find out how it is calculating
<russell-->
i think three times now i've lost NAND blocks in ubi on a ubnt-erx's squashfs and got a device that won't boot cleanly, recover by tftpbooting
<Tusker>
i don't understand where that 740000 is coming from and why mtdsplit wants to use that value :(
<Tusker>
both 210000 and 740000 fall on an erase boundary, so it's not like it can't find it.
<Tusker>
so, if I switch back the sysupgrade image to the default 210000 it doesn't find it still, and still boots from the previously written rootfs at 740000 - https://pastebin.com/Pmk50XLw
dangole has joined #openwrt-devel
pmelange has joined #openwrt-devel
danitool has joined #openwrt-devel
t4h4[m] has joined #openwrt-devel
dangole has quit [Remote host closed the connection]
dangole has joined #openwrt-devel
pmelange has quit [Quit: Leaving.]
<Tusker>
how I can turn on debugging for mtdsplit ?
paper_ has quit [Ping timeout: 480 seconds]
paper_ has joined #openwrt-devel
gladiac is now known as Guest6876
gladiac has joined #openwrt-devel
Guest6876 has quit [Ping timeout: 480 seconds]
dedeckeh has quit [Remote host closed the connection]
Borromini has joined #openwrt-devel
lemmi has quit [Remote host closed the connection]
<karlp>
be a lot less featureful if it ran openwrt :)
<Habbie>
hehe
danitool has quit [Quit: Cubum autem in duos cubos, aut quadratoquadratum in duos quadratoquadratos]
kenny2 has joined #openwrt-devel
dedeckeh has quit [Remote host closed the connection]
aleksander has quit [Quit: Leaving]
Tapper has joined #openwrt-devel
Tusker has quit [Quit: Time wasted on IRC: 14 hours 34 minutes 41 seconds]
Tapper1 has joined #openwrt-devel
Tapper has quit [Read error: Connection reset by peer]
Vexisu has joined #openwrt-devel
<Vexisu>
Hi everyone, I'm new here. I'm looking for help with porting OpenWrt 19.07.08 on Phicomm KE 2M. I'm stuck on finding informations about ROM partition table and configuring .dts file.
<PaulFertser>
Vexisu: hi
<PaulFertser>
Vexisu: two points: 1. You port head of master branch first, get it accepted, then you can try backporting to the latest release;
fda has quit [Ping timeout: 480 seconds]
<PaulFertser>
Vexisu: 2. Following vendor bootlog you learn where the essential partitions are located, and you put that in dts in a way so that OpenWrt could work and also one would be able to restore vendor firmware.
minimal has quit [Remote host closed the connection]
minimal has joined #openwrt-devel
<Vexisu>
PaulFertser: So in the end I have to use JTag to get a partitions table or is there another option?
fda has joined #openwrt-devel
<PaulFertser>
Vexisu: of course not, why you mention JTAG at all?
<PaulFertser>
Vexisu: doesn't the vendor software just print it on boot?
fda has quit []
fda has joined #openwrt-devel
<Vexisu>
PaulFertser: I've tried to connect to ssh, telnet etc, but everything is locked, that's why I'm asking about other options. On the PCB is no Serial connector, only JTag. Also the only thing I know that this router works on modified version of OpenWrt 14.07
<PaulFertser>
Vexisu: why are you sure there's JTAG available? And why do you think there's no way to get to serial UART?
<PaulFertser>
Vexisu: getting serial access is the thing number 0 you need to do if you plan a port.
<Vexisu>
PaulFertser: I also thought about finding traces that are connected to UART in the processor, but it would require removeing a solder mask.
fda has joined #openwrt-devel
<Vexisu>
removing* (sorry for the mistype)
<PaulFertser>
Vexisu: serial is almost always routed somewhere. What package is the SoC in?
<kenny2>
Looking at tplink recovery images, I see it's common for them to include uboot. The C2V5 model has `erase tplink 0x20000` then `cp.b ... 0x20000`. To mean this seems to indicate it's not overwriting uboot and I should skip adding the prefix. Anyone disagree?
<Vexisu>
PaulFertser: MT7628NN
<PaulFertser>
Vexisu: I do not have its datasheet handy
<PaulFertser>
So my question is not answered.
<PaulFertser>
Vexisu: is it BGA? If yes, how would removing the solder mask help?
<PaulFertser>
kenny2: tplink is a mess. Some of their software really expects u-boot and always overwrites it when upgrading, some not.
<kenny2>
PaulFertser: okay, thank you. As long as it's not unusual I'll believe what the gpl source bundle says
routerfix has joined #openwrt-devel
<Vexisu>
PaulFertser: It's DR-QFN
<PaulFertser>
Vexisu: so you can trace the uart signals visually probably
<PaulFertser>
Vexisu: and scratching a bit of solder mask in certain places for probing. Doesn't seem to be too hard.
<PaulFertser>
Vexisu: so how did you figure it had JTAG?
<Vexisu>
PaulFertser: Funny enough, vias on the board are named
<PaulFertser>
Vexisu: can you show a picture please?
<PaulFertser>
Vexisu: ok, that's called testpoints and the names look like JTAG indeed.
<PaulFertser>
Vexisu: I expect UART to be available too in a similar fashion
<Vexisu>
PaulFertser: There are also four similar testpoints, but they look like they are connected to a ROM
<Vexisu>
And are named J1
<PaulFertser>
Vexisu: btw, JTAG needs these signals: TMS, TCK, TDO, TDI, can't work with less than that.
routerfix has joined #openwrt-devel
routerfix has quit []
<PaulFertser>
Vexisu: so have you tried to follow the UART0 signals visually right from the QFN pad?
<PaulFertser>
From pad 31
<Vexisu>
PaulFertser: Yeah, but I'ts hard. Can't even see traces because of printings on the board. Btw. does the firmware update file contain memory mappings where partitions are mounted?
<PaulFertser>
Vexisu: in case it is DTB based, of course. In case it's using machine files you'll probably have to disassemble the code that specifies the partitions.
<PaulFertser>
Vexisu: but even if you know the partitioning you won't be able to easily port anything without serial.
<Vexisu>
PaulFertser: I decompressed it with binwalk. From that I also know where uboot and kernel are located
<Vexisu>
The firmware updater uses OpenWrt tool to flash the firmware. In any case I can backup a firmware directly from the ROM
Tapper1 has quit [Ping timeout: 480 seconds]
victhor has quit [Ping timeout: 480 seconds]
pmelange has quit [Quit: Leaving.]
<PaulFertser>
Vexisu: how can you do that?
Tapper has joined #openwrt-devel
<Vexisu>
PaulFertser: Desoldering the ROM and reading it with a programmer
<PaulFertser>
Vexisu: is it a regular SPI NOR? Then you can also probably use a SOIC clip to avoid desoldering it. Handy for testing.
<PaulFertser>
Vexisu: did you already dump it?
<Habbie>
PaulFertser, btw, what software (and hardware?) do you use for reading SPI NORs with a clip?
victhor has joined #openwrt-devel
<Vexisu>
PaulFertse: No, I'm not at home rn. I'll probably dump it in the next week
<PaulFertser>
Habbie: of all hardware I have handy I would prefer TUMPA with flashrom. There's a certain aspect of accessing the chip without desoldering: you need to somehow make the target SoC not interfere.
<Habbie>
PaulFertser, yep, i picked up on the SoC interference earlier, somebody mentioned lifting the 5V pin for example
<Habbie>
PaulFertser, and if i don't have tumpa - how about a Pi + flashrom?
<PaulFertser>
Habbie: in some cases the SoC's reset pin is obvious/available and you can pull it down externally. In some cases it helps to use a lab PSU to limit the voltage to something which allows the flash to work while SoC considers it not enough (sometimes even crude methods like limiting Vcc power with resistors or just using weak power supplies help)
<Habbie>
oh that's clever
<Habbie>
how about running 'halt' on the SoC? :)
<PaulFertser>
Habbie: I'm the one who wrote the initial flashrom instructions for raspberrypi on their wiki.
<PaulFertser>
Habbie: halt (assuming JTAG access) would not probably work, it just halts the CPU but GPIO peripheral is going to be powered and keeping the previous state so it would be driving the MOSI and SCK and CS probably.
<Habbie>
right, driving them to some level, not necessarily talking actively
<Habbie>
i keep running into this, one day the idea will stick
<Habbie>
thanks for the insights
<PaulFertser>
Habbie: regarding the power limiting, that's what I infer from reading OpenWrt forum topic where people were flashing mir3g-v2 in place connecting ch341 power pins to Vcc.
<Habbie>
right - because that had no business actually working, unless the SoC somehow was unhappy with that?
<PaulFertser>
People found that by accident but I guess the right way would be to use a lab PSU and to undervolt the target.
<PaulFertser>
The SoC likely has an integrated brown-out detector and keeps itself in reset unless the voltage gets to a certain level.
<PaulFertser>
So if you feed Vcc with less than that, the SoC should Z-state the GPIOs.
<PaulFertser>
Habbie: that's why I'd prefer TUMPA, it has an output buffer that can go down to 1.8 V. And with raspberrypi you'd be injecting more than Vcc via the MOSI and SCK lines.
<PaulFertser>
Habbie: of course if the chip is desoldered then raspberrypi will just work.
<Habbie>
injecting more than Vcc - compared to the undervolted supply you mean in that case?
<PaulFertser>
Yep
<Habbie>
got it - information per square character is super high for me in these conversations so sometimes i need to theck :)
<Habbie>
*check
<Habbie>
level shifter would do the trick too, i guess, but lots of fiddling
<PaulFertser>
Habbie: and TUMPA already has the level shifter, sturdy and fast one.
<PaulFertser>
That's why I'd use it. Or some other JTAG adapter based on FT*232H with decent buffer.
<PaulFertser>
Such as BusBlaster, Olimex, Flyswatter etc.
<PaulFertser>
jlink (even a clone) should work too
<Habbie>
makes sense
<Habbie>
thanks!
<Habbie>
TUMPA is what you'd buy today?
<PaulFertser>
Habbie: not the light version but yes, that's the cheapest relatively sane FTDI-based adapter anyway. I do not like certain decisions made by the designers (push-pull srst, SWD resistor hack before rather than after the buffer, lack of level switching for the UART on second port) but the price is right and it's really multi-functional.
<PaulFertser>
Habbie: full disclosure: I got TUMPAv1 and TUMPAv2 for free from the manufacturer
<Habbie>
ok :)
<PaulFertser>
Habbie: I was contacted regarding OpenOCD config file for TUMPAv1 and so they sent me a sample. Some of my feedback was incorporated in v2.
<Habbie>
neat
<Habbie>
oh $20 for lite, $30 for non-lite, that's very doable
<PaulFertser>
I haven't tried 1.8 V operation personally but I do not see why it shouldn't work judging by the datasheets for the parts used.
<PaulFertser>
Lite is trash, useless break-out for ft232h, not even series termination resistors present.
<Habbie>
right
<PaulFertser>
You can probably buy jlink clone for ten bucks but it won't have RS-232 and a clone is a clone, so a bit random I guess.
<Habbie>
yeah i don't mind a lot of cheap stuff, but i'm working towards toying with the SPI NOR on a more expensive device, hence me asking what the good stuff is
danitool has joined #openwrt-devel
jbowen_ has quit [Ping timeout: 480 seconds]
jbowen has joined #openwrt-devel
jbowen has quit [Ping timeout: 480 seconds]
victhor has quit [Ping timeout: 480 seconds]
floof58 has quit []
victhor has joined #openwrt-devel
floof58 has joined #openwrt-devel
<will[m]>
heya anyone know why i'm getting all these "invalid revision range" git errors when trying to run 19.07 buildroot compilation?
Vexisu has quit [Quit: Page closed]
jbowen has joined #openwrt-devel
Borromini has joined #openwrt-devel
wvdakker has joined #openwrt-devel
Acinonyx has joined #openwrt-devel
Acinonyx_ has quit [Ping timeout: 480 seconds]
wvdakker has quit [Remote host closed the connection]
wvdakker has joined #openwrt-devel
Tapper has quit [Ping timeout: 480 seconds]
jbowen has quit [Ping timeout: 480 seconds]
wvdakker has quit [Remote host closed the connection]
jbowen has joined #openwrt-devel
PaulFertser has quit [Read error: Connection reset by peer]
<aparcar[m]>
will yes to determine package releases, try to get a full copy
<will[m]>
bleh
<will[m]>
i'm trying to not have a 40 gig buildroot lugging around that gets corrupted every time i sneeze, but...
<aparcar[m]>
estimate about 10G per target, the source itself isn't terribly big
<will[m]>
ugh
<will[m]>
it also takes forever to build, and seems to get corrupted super easily. i was trying to build a kernel package on 19.07 the other day and no matter what i did short of rm -rfing it failed on a gzip symlink
<will[m]>
after like 30 mins
<aparcar[m]>
will the build system is complex and we work every day to make it a bit better. Please try a full clone of the openwrt-21.02 branch. Commands like make clean, make dirclean etc should help you avoiding new full clonings
wvdakker has quit []
wvdakker has joined #openwrt-devel
wvdakker has quit []
<will[m]>
will do, thanks for the shallow clone tip
Borromini has quit [Quit: Lost terminal]
wvdakker has joined #openwrt-devel
fda- has joined #openwrt-devel
wvdakker has quit []
wvdakker has joined #openwrt-devel
fda has quit [Ping timeout: 480 seconds]
wvdakker has quit []
wvdakker has joined #openwrt-devel
wvdakker has quit []
wvdakker has joined #openwrt-devel
wvdakker has quit []
wvdakker has joined #openwrt-devel
shibboleth has joined #openwrt-devel
dangole has quit [Remote host closed the connection]
dangole has joined #openwrt-devel
minimal has quit []
<aparcar[m]>
will please let me know if there are isues, happy to help
wvdakker has quit []
wvdakker has joined #openwrt-devel
rmilecki has quit [Ping timeout: 480 seconds]
xback has quit [Ping timeout: 480 seconds]
floof58_ has joined #openwrt-devel
floof58_ has quit []
floof58_ has joined #openwrt-devel
floof58_ has quit []
floof58_ has joined #openwrt-devel
floof58 has quit []
shibboleth has quit [Quit: shibboleth]
wvdakker has quit []
<mangix>
Ansuel's working on ath79 DSA. Great.
Grommish_ has joined #openwrt-devel
Grommish__ has joined #openwrt-devel
<slh>
I've seen two attempts for archer c7 v2 and tl-wdr4300, but afaik neither of those were successful so far
<fda>
on odhcpd restart i see 5 outgoing RAs. each of the 5 RA has correct br-lan.XX interface (the mac ends the same as the vlan ids, ipv4 too.) but clients get all 5
<dwfreed>
are clients directly connected to the device, or are they going through a switch?
floof58 has quit [Ping timeout: 480 seconds]
<fda>
dwfreed: i have only 1 lan connected on e8450 to a unmanaged 16port switch which forwards vlans
<dwfreed>
can you plug a vlan-aware device into another port on the 8450 and tcpdump the traffic? to ensure the outgoing packets are properly tagged
floof58 has joined #openwrt-devel
<fda>
dwfreed: good idea! a device could remove/change the vlan tags. i test this tomorrow as its a long way to router...
<fda>
i'll use an old notebook with windows7+wireshare, should work for the untagged