<neggles>
given broadcom's unnatural fetish for parallel NAND, yes :P
<neggles>
as a general rule, don't go overwriting bootloaders if you don't have a way to manually reflash the chip they're on out-of-band
<nkko>
I wish I had a JTAG pinout for the newer bcm63xx SoCs
<neggles>
you're assuming they haven't fused off JTAG
<neggles>
broadcom just really hate fun.
<nkko>
well, I've been reading through the cfe source, I have to wait on a board to arrive (bricked all of them because, but the last one was bricked because of an invalid cferam) to test my latest theory
<nkko>
I think I know how to make mainline run, I just need to provide the dtb on the jffs2 FS and it might just work as long as atag support is built into the kernel
<neggles>
if it's booting off a TSOP-48 NAND and you've killed more than one, it's probably worth buying a flash clip and an XGECU T48 :P
<nkko>
I'll check, that is a great idea
<neggles>
the T48 is really good for the price. my only complaint is there doesn't seem to be an 11x10mm limit frame available for the eMMC reader module
<neggles>
the software's even properly english translated (a few minor errors, no big deal)
<neggles>
have been having some trouble finding one of the newer FFC-type clips in 48-pin, though. annoying.
<nkko>
yeah, it's in that form factor
<nkko>
I'll get the programmer, thanks, I didn't think of that
<neggles>
just make sure you don't end up with a 56-pin clip by accident
<nkko>
well, I'll look up the chip part number to be sure, I suppose
<neggles>
ah sorry, the little clip on socket thing
<neggles>
the 48's PDIP adapter *should* plug right into the T48
<nkko>
yeah, this is 48 pin
<neggles>
though it's worth noting that I haven't actually tried a clip on mine yet, and the TSOP NAND adapter for the thing *does* have some electronics on it. hm.
<neggles>
and the guy who makes those is really helpful/responsive with issues
<nkko>
I'll probably just get the cheapest flasher I can find that has alright support under linux
<neggles>
tbh that's pretty much none of them >.>
<neggles>
it's really annoying
<nkko>
well, I don't mind running a windows VM
<nkko>
as long as flashrom or the like can be used, it'd be fine
<neggles>
flashrom is exclusively an SPI NOR type deal
<nkko>
oh, interesting
<neggles>
NAND is... *difficult*
<neggles>
because ECC stuff.
<neggles>
I know the u-link will work, have a friend who has one and used it with that exact clip last week to dump a few things
<nkko>
well, I'm glad I didn't bin the boards, I cannot believe I did not think of that
<neggles>
one of the chips wasn't supported, he emailed the guy who makes the u-link, got a reply in half an hour with an updated chip library file
<neggles>
heh :P big TSOP NAND chips are intimidating
<neggles>
the "best" solution i've seen so far was this one weird old BT router that has SPI NOR and parallel NAND footprints on the board, but the manufacturer only used the NOR
<neggles>
so you can hook up some FFCs to the pads and connect it to a flash clip or a ZIF socket, then access it as an mtd in linux
<neggles>
but that's a bit iffy to get working right and a lot of very fine soldering
<nkko>
does the u-link flasher have support for esmt nand chips?
<neggles>
should do
<nkko>
alright
<neggles>
the chip defs are just an xml file
<neggles>
it's not hard to add missing ones yourself, or you can just email the dude a datasheet and he'll get it sorted
<nkko>
yeah, I don't mind keying in data from the datasheet
<neggles>
the T48 is much more flexible, but I hadn't noticed the probably-DRM chip on its TSOP-48 ZIF adapter until now, so i'm a bit suspicious that it might not work with a clip
<neggles>
:/
<neggles>
ah. yeah, definitely will not. adapter doesn't fit. I have played myself. u-link it is :P
srslypascal is now known as Guest323
srslypascal has joined #openwrt-devel
Guest323 has quit [Ping timeout: 480 seconds]
<nkko>
neggles: is that ic2005 shop legitimate? I have mixed feelings on this
<neggles>
nkko: quite legitimate, shady as heck but technically they're the OEM
<nkko>
HK might as well be part of China now
<neggles>
theyve been around for *ages*
<neggles>
site looks dodgy because it's basically not changed for a decade
<nkko>
hmm
<neggles>
otherwise i think the u-link guy has clips too
<nkko>
I'm just concerned that if it's zencart or the like, then it might get one day exploited
<nkko>
hmm, I'll check
<neggles>
you might have to email
<neggles>
unsure
torv has quit [Remote host closed the connection]
robimarko has joined #openwrt-devel
SamantazFox has joined #openwrt-devel
gladiac has joined #openwrt-devel
f00b4r0 has joined #openwrt-devel
danitool has joined #openwrt-devel
torv has joined #openwrt-devel
dangole has joined #openwrt-devel
StereoRocker has joined #openwrt-devel
schwicht has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
SamantazFox has quit [Ping timeout: 480 seconds]
minimal has joined #openwrt-devel
schwicht has joined #openwrt-devel
schwicht has quit [Read error: Connection reset by peer]
schwicht_ has joined #openwrt-devel
robimarko has quit [Remote host closed the connection]
robimarko has joined #openwrt-devel
schwicht_ has quit [Ping timeout: 480 seconds]
schwicht has joined #openwrt-devel
SamantazFox has joined #openwrt-devel
SamantazFox has quit [Max SendQ exceeded]
SamantazFox has joined #openwrt-devel
SamantazFox has quit [Max SendQ exceeded]
SamantazFox has joined #openwrt-devel
schwicht has quit [Read error: Connection reset by peer]
schwicht_ has joined #openwrt-devel
valku has joined #openwrt-devel
valku has quit []
<SlimeyX>
merry xmas!
Luke-Jr has quit [Ping timeout: 480 seconds]
damex has joined #openwrt-devel
csrf has joined #openwrt-devel
Luke-Jr has joined #openwrt-devel
lmore377 has quit [Remote host closed the connection]
lmore377 has joined #openwrt-devel
minimal has quit [Quit: Leaving]
Luke-Jr has quit [Ping timeout: 480 seconds]
<StereoRocker>
Hey y'all. I'm trying to port to an AR9344 rev 2 device. I've got myself into a bit of a bind where kernel is failing to find working init. At some point earlier today, it worked, and I can't figure out what I changed to break it. Anyone willing to have a look with me please? I'll post relevant output and my changes momentarily.
<PaulFertser>
StereoRocker: when possible it's often nice to start experimenting by using initramfs images, there the kernel has no problems finding init because flash memory isn't used at all.
<nkko>
I don't even use openwrt for testing anymore, the build system is too cumbersome for me
<nkko>
well, less about that, but a lot of it is unable to produce the image format that I want (definitely not incompetence)
<StereoRocker>
I wish I could boot initramfs. The u-boot is so locked down on this device, all I can do is flash the NOR from TFTP. Fortinet does not like us.
<nkko>
jffs2? what is the FS layout?
<nkko>
s/FS/image/
<StereoRocker>
Side note, I think they've encrypted parts of the u-boot. There's certificates and an RSA key at the end of that partition.
<nkko>
well, start looking through their vendor gpl source
<nkko>
find the version that they based the kernel off and run diff on it
<PaulFertser>
StereoRocker: somehow this happens: "VFS: Mounted root (jffs2 filesystem) ". Your "root" partition should start with regular squashfs, so probably you somehow misflashed it.
<StereoRocker>
That's what I thought too. My command in makefile to generate the image is "append-rootfs | pad-rootfs | pad-to 9216k | append-kernel"
<PaulFertser>
StereoRocker: oh, kernel at the end? Nasty, that inherently limits the size it can take...
<StereoRocker>
Basically the TFTP accepts a binary and starts flashing it to 0x40000, expecting a uImage to live at 0x940000
<PaulFertser>
StereoRocker: but your u-boot lines contradict that idea.
<StereoRocker>
There is a ~5MB partition after the kernel that, in stock firmware, was used exclusively for kernel crash logs.
<PaulFertser>
Hm, no, I misread, it's indeed 940000
<StereoRocker>
In my DTS I combine the kernel partition and crash log partition.
<PaulFertser>
StereoRocker: yes, it all makes sense
<PaulFertser>
StereoRocker: can you check with "binwalk" the image you're flashing just in case? There must be some reason why the kernel doesn't mount it as squashfs...
<StereoRocker>
Broadcom did something that doesn't appeal exclusively to their top 100 cash cows, I mean customers? I'm not salty about the direction they're taking VMware...
<PaulFertser>
What you're doing all looks sane.
<Habbie>
StereoRocker, are you sure? all snails in a 20km radius just dried up and died
<StereoRocker>
PaulFertser: I will, though I have quite a few times already.
<StereoRocker>
Habbie: :D
<nkko>
I think I'll be upstreaming support for a bunch of MIPS bcm63xx boards in a week or two, heh
<StereoRocker>
Sweet!
<nkko>
I do need to read into lzma-loader more, but I don't think it's needed for the newer cfe versions (?)
<Habbie>
oh, now i know who to poke when i go back to my old CFE device :D
<StereoRocker>
I included the flashing process as well.
<nkko>
what does binwalk show for the stock firmware (assuming you have an image, I couldn't find one)?
<nkko>
but yeah, jffs2 seems odd if it's supposed to be squashfs
<PaulFertser>
And the splitter thinks it's squashfs...
<Luke-Jr>
dnsmasq keeps segfaulting randomly (not at startup) - how can I get a stack trace? :/
<StereoRocker>
nkko: I do have one, it took quite some digging to find. Fortinet don't allow you to download binaries without active support on the device, or at least the specified device being registered to your account.
<StereoRocker>
Is there a place that the intermediate images are output before they get combined? I'm noticing the creation date on my uImage header is wrong.
<PaulFertser>
StereoRocker: 5 MiB after the kernel you say? You can flash full initramfs there then :)
<PaulFertser>
(starting from the beginning of the kernel partition of course)
<PaulFertser>
Luke-Jr: is installing gdbserver and connecting to it with gdb from host and letting it run like this for a while an option for you? That would be easier than enabling core dumps etc.
<nkko>
PaulFertser: I was going to suggest ulimit -c unlimited, and then to just run dnsmasq
<PaulFertser>
nkko: it used to be not enough some years ago, but probably it's indeed working these days, not sure.
<StereoRocker>
PaulFertser: I have to make a dummy rootfs to trick u-boot, but yes that's a good point. I'm flashing an initramfs test now.
<StereoRocker>
The initramfs was able to boot. And I learned my LED definitions aren't working.
<PaulFertser>
StereoRocker: my idea is to use this initramfs to check hexdump -C -n 1024 /dev/mtdblock1 etc.
minimal has joined #openwrt-devel
<StereoRocker>
Good idea. I need to get the rootfs image that the build system wants to make, before it dumps it into an assembled image, so I can manually assemble it. Do you know if it's stored in a temporary directory during build, or is there something I can define to get that output?
<nkko>
StereoRocker: you can select the tarball target from the TUI menu
<StereoRocker>
While I'm here, can I make the default config grab a DHCP address for br-lan? The default causes an IP conflict on my network. Honestly, if anyone else were using these, they wouldn't be routing, so it's probably not an insane default for this particular device.
<nkko>
StereoRocker: yeah, modify the files in base-files/
<nkko>
I think there's a better way, but that will work
<StereoRocker>
That'll do for debug. Thanks.
<PaulFertser>
StereoRocker: it's all there in the build_dir
<PaulFertser>
StereoRocker: e.g. in my build: build_dir/target-mips_24kc_musl/linux-ath79_tiny/root.squashfs
<PaulFertser>
It's most likely in your case your sysupgrade image starts exactly with that, I do not expect any surprises there.
<PaulFertser>
StereoRocker: what do you mean by "grab a DHCP address for br-lan"? br-lan should be running a DHCP server by default.
<nkko>
PaulFertser: WAN replacement?
<StereoRocker>
PaulFertser: I want it to not run a DHCP server, and instead obtain a DHCP lease from the network. The device is an access point, only 1 ethernet port.
<StereoRocker>
These things, on their stock firmware, are useless without a Fortinet router/firewall. While I might be able to, I don't want to run one. That's the reason I'm porting openwrt.
<StereoRocker>
Thinking about it, I should've grabbed the firewalls too, they might've made interesting targets.
<PaulFertser>
StereoRocker: oh, then it's what the wiki docs call "dumb AP", you can create an appropriate uci-defaults script and put it in files/
<nkko>
PaulFertser: imo, it's faster to just modify base-files/
<nkko>
uci is too cumbersome, it breaks the unix mentality
<StereoRocker>
So I've run hexdump on mtdblock1 and it shows squashfs header.
<PaulFertser>
StereoRocker: are you able to mount it manually with "mount -t squashfs ..."?
<StereoRocker>
Yep!
<PaulFertser>
nkko: that's an option of course, but it's not the way OpenWrt devs recommend. It's also an additional patch to apply and rebase while with files/ you just write a uci script once and keep it there.
<PaulFertser>
StereoRocker: can you compare this initramfs output with what you had before, were the partitions split the same?
<nkko>
well, I'm curious as to how the patches are rebased for every kernel update
<PaulFertser>
StereoRocker: it's a really puzzling problem you got there, would be very interesting to know the final answer.
<nkko>
I assume manual intervention would be required if I were to, let's say, revert to v4.x.x
<StereoRocker>
PaulFertset: Yeah, it's the same MTD device output.
<StereoRocker>
I'm almost glad it's an interesting problem, and not me being dumb. :P I'm still puzzled as to what I changed from when I was able to flash and boot the images being built previously.
<PaulFertser>
The next thing I would try probably changing CONFIG_CMDLINE="rootfstype=squashfs,jffs2" to CONFIG_CMDLINE="rootfstype=squashfs"
<PaulFertser>
Where's 9600 from btw, I didn't see it your diff?
<StereoRocker>
I'll try lowering SPI freq now. The 9600 comes from chosen bootargs in DTS.
<StereoRocker>
I've set it to 9600 because that's what u-boot runs at, just a convenience really.
<Luke-Jr>
PaulFertser: then I need a whole toolchain on the host? :/
<PaulFertser>
Luke-Jr: even if you get a core dump you still need full build system to get a back trace out of it.
<Luke-Jr>
PaulFertser: there's no way to get libbacktrace or strace to dump a nicely formatted stack on the device itself?
<PaulFertser>
Userspace has everything stripped, no debug info.
<Luke-Jr>
surely there's at least function names?
<PaulFertser>
For kernel, yes. For userspace, only for the shared libaries external symbols I think.
<Luke-Jr>
:/
<PaulFertser>
gdbserver worked wonders for me.
<Luke-Jr>
it's strange how it runs for months just fine, but today it was crashing every few minutes
<Luke-Jr>
now stable again
floof58 has quit [Ping timeout: 480 seconds]
<StereoRocker>
PaulFertser: It's booting a factory.bin again after halving SPI frequency. I think that might've been it.
schwicht_ has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
schwicht has joined #openwrt-devel
schwicht has quit []
floof58 has joined #openwrt-devel
<StereoRocker>
PaulFertser: I've reflashed and it's still working after setting lower SPI frequency. I do believe it's resolved. Thanks for the help! :)
<PaulFertser>
StereoRocker: cool! :)
<nkko>
nearly done with my openwrt port for another boring mips bcm63xx device
<nkko>
just need to create the patch in a bit, but I want to get the LEDs done
<StereoRocker>
How do you figure out the LEDs?
<nkko>
StereoRocker: I think I probe the GPIO pins as exposed in sysfs, but I think I also have to configure the device tree
<Namidairo>
option a: poke gpio randomly and hope you don't factory reset your device. b: look at the stock dtb
<nkko>
Namidairo: yeah, I'd do the former
<Habbie>
Namidairo, is resetting a real risk if your pokes are short?
<nkko>
Habbie: I've never had that happen
<Namidairo>
someone managed it at some point
<Habbie>
ack
<Habbie>
i assume this is just a "ugh now i have to flash it again", not a real problem?
<Namidairo>
depends on the device but it's not typically more than an annoyance
<Habbie>
ack, thanks
<PaulFertser>
I know those realtek switches have one GPIO connected to reset but it literally resets the SoC, so just a reboot.
<nkko>
is it wrong to not bother with all of the LEDs?
<nkko>
I'll get the essential done, though, but I don't feel like figuring out why the LEDs for the switch, are not toggling off when I pull it up high
<Namidairo>
switch leds may be handled by the switch driver or the switch itself
<Namidairo>
not exposed as a gpio
<SlimeyX>
ledD
<nkko>
nvm, I mistook the LED
<Namidairo>
or are you talking front leds that are labelled for the port
<nkko>
Namidairo: front LEDs
gladiac has quit [Quit: k thx bye]
<Namidairo>
well if/when you submit the patch to the list/github/etc people will want the leds
<nkko>
no, I figured it out
<nkko>
well, this device is extremely obscure
<SlimeyX>
i have obscure waps :P
minimal has quit [Quit: Leaving]
<nkko>
nice, I found the reset button gpio pin
<SlimeyX>
this one model wap has a reset button on the baord but a hole was never drilled outside the case for it
<nkko>
are 8/32MB devices uncommon? I'm seeing a lot of them, which feels weird
<slh>
they have been common in the past, pre ~2014
<slh>
but 32 MB RAM have become extremely limiting, if not 'impossible' for normal usage
<slh>
(impossible is a bit strong, but close to)
<nkko>
weird, it's always been fine for me
<nkko>
I mean, znc used to eventually crash on one of them
<nkko>
but I was doing iscsi as well
DLange has quit [Quit: \o/]
DLange has joined #openwrt-devel
<nkko>
I've got the LEDs defined as blue_lan1, etc., but what do I put into 01_leds?
<nkko>
can ucidef_set_led_netdev accept switch ports as an argument?