rmilecki has quit [Quit: Konversation terminated!]
rmilecki has joined #openwrt-devel
xback has quit [Remote host closed the connection]
xback has joined #openwrt-devel
minimal has quit [Quit: Leaving]
Daanct12 has joined #openwrt-devel
tSYS has quit [Quit: *squeak*]
tSYS has joined #openwrt-devel
philipp64 has joined #openwrt-devel
rua has quit [Quit: Leaving.]
rua has joined #openwrt-devel
rua has quit []
neggles has quit [Ping timeout: 480 seconds]
iocampomx has joined #openwrt-devel
neggles has joined #openwrt-devel
neggles has quit [Ping timeout: 480 seconds]
neggles has joined #openwrt-devel
<iocampomx>
Hi there, I've an OpenWRT version I compiled and want to flash to the device. So far, I've been playing with initramfs-kernel.bin via TFTP, now, I want to formally write it on the MTD. Which image type should I use? The same initramfs-kernel.bin?
<slh>
read the device page for your device, in general, no (but there are exceptions); in the absence of one, check the git history for the commit introducing support for your device, it should have that information (at least for devices added in recent years)
dangole has quit [Quit: Leaving]
<iocampomx>
Oh, I'm creating the image for this device for the first time, isn't yet oficially "supported"
<iocampomx>
I was able to make it work, now, I'm on the final stage of flashing it formally
<slh>
then you need to construct this very carefully, based on the OEM partitioning and in a way that can (ideally) be reversed to the OEM firmware
<iocampomx>
Given said that, how should I proceed on this stage?
<iocampomx>
So, I now exactly where to flash it, I figured the MTD partitions, etc
<iocampomx>
The specific question I've at this point is, which artifact created from OpenWRT should I write?
<iocampomx>
To the MTD on the specific location I've already identified
<slh>
it depends... NOR has different requirements than NAND and even more different ones with eMMC, sdhc, SSD, NVMe, etc
<iocampomx>
NOR
<slh>
that's usually the easiest
<iocampomx>
Super! What should I do then?
<slh>
in essence, what similar devices do ;)
<slh>
ideally with a dynamic kernel+rootfs split
<slh>
(not always possible, thanks to the OEM bootloader)
<iocampomx>
So, should I write the Kernel in one location, SquashFS in another, and a 3rd one for the Overlay FS?
<slh>
it really depends on what's supported by the device's bootloader
<iocampomx>
Could you please elaborate more_
<slh>
if you can, denx,uimage with a combined firmware partition is usually 'best'
<iocampomx>
If I analyze the stock firmware with binwalk, I see 4 blocks: 1) uImage, 2) LZMA compressed data, 3) Squashfs, 4) Squashfs
<slh>
you would usually look most at the bootlog of the OEM firmware and check how the mtds are laid out there
<iocampomx>
This is the layout: https://pastebin.com/bPqrTkdx. This device is using a lot of partitions that I won't need once I flash it with OpenWRT, the important think to notice here, is that the bootloader will try to boot the kernel at the start of the "Kernel" partition. That is the only rule I would like to follow.
<slh>
I will have to leave in under 10 minutes, but e.g. https://git.openwrt.org/?p=openwrt/openwrt.git;a=commitdiff;h=ff95f859ebf710d2914472a3feeeb0d187d14459 just taking a recent example with spi-nor and a merged firmware partition
<slh>
but that only works if kernel+rootfs+space_for_overlay are in order and without gaps inbetween
<iocampomx>
Got it, I saw the partitions table on the DTS file, thanks for sharing
<iocampomx>
This is what I was looking for: IMAGE/factory.bin := append-kernel | append-rootfs | pad-rootfs | check-size
<slh>
factory is only relevant if you have means to construct an OpenWrt image that is accepted by the OEM firmware
<slh>
otherwise you'd be rather looking for IMAGE/sysupgrade.bin/squashfs
<slh>
(but I really need to go now)
<iocampomx>
Thanks again!
hitech95 has joined #openwrt-devel
valku has quit [Quit: valku]
iocampomx has quit [Read error: Connection reset by peer]
iocampomx has joined #openwrt-devel
Kevinjil has joined #openwrt-devel
iocampomx has quit [Read error: No route to host]
iocampomx has joined #openwrt-devel
iocampomx has quit [Ping timeout: 480 seconds]
iocampomx has joined #openwrt-devel
<iocampomx>
So, I was able to manually flash my own image initramfs-kernel.bin on the specific MTR location that the bootloader of the device is loading the execution code
<iocampomx>
It's working!
<iocampomx>
Now the question is, is the initramfs-kernel.bin image the right one to be flashed on the device, as I just did?
<iocampomx>
I built two images, one "initramfs-kernel.bin" and one "squashfs-sysupgrade.bin". I used the first one to write directly to the MTD device. It's my understanding that the sysupgrade is just for subsequent updates.
<stintel>
initramfs is not the right image to flash, it is used to load openwrt in RAM
<stintel>
you need to make a "factory" image to flash. this _can_ be identical to the sysupgrade image
goliath has joined #openwrt-devel
mrkiko has quit [Quit: leaving]
Kevinjil has quit [Remote host closed the connection]
mrkiko has joined #openwrt-devel
robimarko has joined #openwrt-devel
Daanct12 has quit [Quit: WeeChat 4.0.5]
<iocampomx>
Great, that was the info I was looking for!
<iocampomx>
Can I do: IMAGE/factory.bin := $$(sysupgrade_bin) ?
<iocampomx>
And: IMAGES += factory.bin
<iocampomx>
I firs tried with squashfs-sysupgrade and it didn't work, with the two lines I just pased above, the factory.bin image is an exact copy of the sysupgrade, so it won't work either.
<iocampomx>
The difference between the sysupgrade and initramfs-kernel, is that the initramfs has an uImage included, and the sysupgrade doesn't. Should I include the uImage into the sysupgrade as well?
Daanct12 has joined #openwrt-devel
<iocampomx>
I realized the the KERNEL_INITFRAMFS has uImage lzma at the end. So, I'm asumming I will have to append uImage as well?
<KanjiMonster>
iocampomx: "uImage lzma" means and convert the kernel to uImage format and compress it with lzma, not append a uImage. uImage is the container format (older) U-Boot expects for the kernel
<iocampomx>
Got it! I'm building the images again... I also realized the declaration of converting should happen on KERNEL instead of KERNEL_INITFRAMFS so that sysupgrade and factory can inherit that config as well. Is that right?
<KanjiMonster>
sounds reasonable
<iocampomx>
Super! I can see uImage header on factory and sysupgrade, I will try to upgrade, this time using sysupgrade instead of writing directly on the MTD block
cmonroe has quit [Ping timeout: 480 seconds]
<iocampomx>
It worked, I have another problem: Please append a correct "root=" boot option
<KanjiMonster>
iocampomx: then you probably need to provide it via bootargs(-append) in your dts
<fioriceta>
KanjiMonster: what do you think of turning the buildroot into a bootstrap for another distro? :>
<fioriceta>
cause you'd just put in rootwait, etc., into the dt
<KanjiMonster>
it's being done before, boot with an OpenWrt kernel to a {arm,etc}bian rootfs.
<KanjiMonster>
since it is more or less a fix, it might
<iocampomx>
KanjiMonster: Do you mean on the chosen > bootargs param? If so, what specific value I should provide? The same mtd partition in which it was flashed? Or should I create a new MTD partition?
<KanjiMonster>
the mtd partiton that will end up being the rootfs. You should be able to determine this from the (failed) boot's bootlog. When probing the flash, it should list the partitons
<KanjiMonster>
is this NAND or NOR?
<iocampomx>
NOR
<iocampomx>
I previously defined the partitions on the DTS file
<iocampomx>
On this partition is where I flashed the firmware
<iocampomx>
Should I do root=LABEL=firmware?
<KanjiMonster>
no, labels won't work
<iocampomx>
Should I do root=/dev/mtd4?
<iocampomx>
Or actually mtdblock4
<\x>
robimarko: MR7350 with fw mode 2 is stable af. I think three of us are runnign it for like a month now.
<KanjiMonster>
iocampomx: if you have full control over the mtd layout, then you can probably just define a firmware partiton for the full image, and let the kernel do the rest via a partition parser. See the "denx,uimage" usage in dts files
<iocampomx>
Sounds good. I do have full-control. What does "denx" mean?
<KanjiMonster>
they developed U-Boot (and the uImage format), and compatibles are in the format "<vendor>,<partname>". therefore "denx,uimage"
<iocampomx>
Fantastic! I've added the compatible = "denx,uimage"; attribute to the firmware partition. Let me try again.
<KanjiMonster>
does this thing really have 4 firmware slots?
<iocampomx>
No, the first three are: ALL (I manually defined it to have access to the whole block), Bootloader & Factory. I've decided to keep bootloader & factory to have backward compatibility in case I want to revert back to stock firmware.
<iocampomx>
So, I just added partition #4, from which I know the existing bootloader is looking for the kernel, it works
<iocampomx>
Actually, originally the device had 13 partitions... I'm just ignoring few of those at the end, and using the block in the middle that was intended for firmware
<iocampomx>
Oops, with denx,uimage I don't have to add the root= parameter, right?
<KanjiMonster>
correct
<iocampomx>
It works!!!
<iocampomx>
KanjiMonster: Thank you very much for your support!
<KanjiMonster>
you're welcome :)
<robimarko>
\x: That is great to gear
iocampomx has quit [Ping timeout: 480 seconds]
<mrkiko>
hi robimarko !!
<mrkiko>
robimarko: my remote 7530 running fine still, no problems to signal and no messages in the dmesg
<mrkiko>
robimarko: connected over pppoe
<fioriceta>
mrkiko can't even read a register map tbh
<mrkiko>
robimarko: 6.1..56 kernel
<robimarko>
Nice to hear it works
<mrkiko>
robimarko: :D if I can do something to help, let me know. I have some 7530 locally as well
<robimarko>
Well, IPQ60xx is a dead end for more upstreaming until that craziness around Q6 clocks is sorted out
<fioriceta>
I don't get why people bother with qualcomm
<fioriceta>
work on sunxi or literally anything else
<robimarko>
Can you just stop interjecting into everything?
<fioriceta>
I'm doing that?
<fioriceta>
well, your client has an ignore feature built-in btw
<robimarko>
Well, I really dont want to have to ignore people
<stintel>
you're basically insulting people. stop doing that or you will be removed
<robimarko>
mrkiko: One day, we will get to sorting that mess out
<robimarko>
It would be a shame not to have ipq60xx in OpenWrt
<mrkiko>
robimarko: agreed.
<mrkiko>
robimarko: thanks a lot for your work
<mrkiko>
Ansuel: also you're helping a lot in ipq806x / R7800 I guess
<kabel>
Ansuel: replied to your questions on patch 2/2
<fioriceta>
there's another tls/crypto lib that is smaller than mbedtls
<fioriceta>
if I do some patches and upstream it, there should be no issues, right?
<fioriceta>
I assume uhttpd needs support?
<dwfreed>
a lot of things are going to need support
<fioriceta>
well, just the basic shit for luci, I guess
<dwfreed>
that's just the basics that's going to be on every device
<fioriceta>
well, uhttpd would be a start
<fioriceta>
hmm
<dwfreed>
the lib would not be useful without all 3 of those
<fioriceta>
I assume that hostapd, etc., needs it for AES?
<fioriceta>
need to take a look...
<dwfreed>
the actual encryption of WPA2/3 is handled in the kernel; wpa_supplicant/hostapd are only responsible for the handshakes
<fioriceta>
the part that worries me is that this lib is not good for importing public RSA keys or whatnot
<fioriceta>
the API really expects x509
<fioriceta>
hmm
<fioriceta>
I think it's doable for hostapd, etc
<fioriceta>
yep, for sure...
<fioriceta>
yeah, this is definitely doable
<fioriceta>
this lib has a smaller footprint than mbedtls, etc
rua has joined #openwrt-devel
<KanjiMonster>
linusw: looking into the max frame size, at least according to broadcom (gpl!) code, enetsw should support an mtu up to 2047
<fioriceta>
KanjiMonster: you want me to check? :S
xavifr has joined #openwrt-devel
<fioriceta>
which SoC, I guess?
<fioriceta>
I think it can do jumbo frames
<KanjiMonster>
fioriceta: no need to, I may or may not have seen the non-gpl code as well
<fioriceta>
yeah, well, jumbo frames is a bit weird
<linusw>
KanjiMonster: jumbo frame config? It just disappears if I send a package bigger than 1536 on my setup.
<fioriceta>
let me check
<linusw>
KanjiMonster: but I will try to do more tests...
<KanjiMonster>
linusw: I have a few devices here as well (even some without any external switches)
<fioriceta>
>Note: Frames longer than 1518 (untagged) and frames longer than 1522 (tagged) are considered oversized frames. However, only frames over 1536 bytes are treated as bad frames and dropped. When jumbo-frame mode is enabled, only the frames longer than 9728 bytes are bad frames and
<fioriceta>
KanjiMonster: which devices? just curious
<fioriceta>
though, tbh, not sure about jumbo support
<KanjiMonster>
fioriceta: 6318, 6328, 6362, 6368, 63268. no 63381, and no arm based
<fioriceta>
it is marked `internal`
<fioriceta>
oh, nice
<fioriceta>
you have anything 33xx based?
<KanjiMonster>
nope
<KanjiMonster>
(technically also 6358 and 6348, but these are without internal switches)
<fioriceta>
I did get u-boot going on that board that I bricked, but I never got the switch working
Daanct12 has quit [Ping timeout: 480 seconds]
<fioriceta>
only worked once I switched over to mainline openwrt, then DSA just worked out of the box
<fioriceta>
swconfig only worked when I forced all links to be up
<fioriceta>
KanjiMonster: I think the file structure should be cleaned up in the kernel tree
<fioriceta>
you have ARM files including stuff from arch/mips iirc
<KanjiMonster>
the max frame register is weird tho
<KanjiMonster>
53115 says "This register only allowed to be configured as 14'd1518 or 14'd2000. When jumbo is disabled, the content of this register is used to define good frame length."
<fioriceta>
yeah, I see that, too
<fioriceta>
hmm?
<fioriceta>
this switch IC can do ACLs?
<fioriceta>
though, guess that's irrelevant if this is robosw
<fioriceta>
KanjiMonster: did you look at those L2 bmips switches?
<fioriceta>
the bootloaders might be proprietary, but it is doable to build a new cfe build
<fioriceta>
tbh, I guess I am tempted to mess with it now
<KanjiMonster>
fioriceta: which l2 bmips switches?
<fioriceta>
I'd have to check, give me a moment
<KanjiMonster>
I'm not aware of the integrated switches supporting ACLS. 53115 (and family) have this CFP TCAM stuff though
<fioriceta>
`bcm5836`
<fioriceta>
this is a procurve board, I'd need to probe for jtag
<KanjiMonster>
mh, I maaaybe see an issue with jumbo setup on 63xx
<fioriceta>
I think jtag has a 10k pull downs, so hmm...
<fioriceta>
this SoC actually has USB
<KanjiMonster>
ah no, it's bug in the broadcom code
rua has quit [Quit: Leaving.]
rua has joined #openwrt-devel
rua is now known as Guest2042
rua has joined #openwrt-devel
Guest2042 has quit [Remote host closed the connection]
<fioriceta>
KanjiMonster: hmm
<fioriceta>
the 2nd row seems to be mostly gnd
<fioriceta>
I wonder if jtagenum will yield something on an SBC
<KanjiMonster>
linusw: currently in the middle of playing around with the settings and b53, so I don't have one ready. I would suggest moving the mtu setup to before the rx_buffer_size calculation, and then making it use the max_mtu, not default mtu (since we have no code for updating the rx_buffer sizes)
<linusw>
KanjiMonster: I'll look into it!
<fioriceta>
oh, yeah, when you're testing out changes against the tree, do you just edit the stuff in build dir, then turn it into a patch when it's done?
<fioriceta>
that's the only way I could see it working tbh, with that quilt system
<fioriceta>
at least that is what I have done
philipp64 has quit [Quit: philipp64]
<KanjiMonster>
depends on how confident I am with my changes
<KanjiMonster>
for stuff that are fixes for upstream code, I often create a patch for linux, then apply it later to the tree
<fioriceta>
got it working in openocd...
<fioriceta>
well, guess moment of truth
<fioriceta>
KanjiMonster: did you have issues with those other SoCs and jtag?
<fioriceta>
it finds the tap, etc., but hmm, target_read_u32(), etc., fail
cmonroe has joined #openwrt-devel
<fioriceta>
jtagenum program has no issues with running all sorts of scans, etc., so I wonder if it's a timing thing
xback has quit [Ping timeout: 480 seconds]
<fioriceta>
never mind :)
filimonic has quit [Read error: Connection reset by peer]
filimonic has joined #openwrt-devel
xavifr has quit [Ping timeout: 480 seconds]
goliath has quit [Quit: SIGSEGV]
<hauke>
Ansuel: if you have topics for the release notes please add them to the rc4 release notes wiki page
<fioriceta>
KanjiMonster: with bmips, new stuff goes into the bmips target, or if this is closer to 47xx, that target? hmm
<fioriceta>
DSA with 48 ports is going to be fun
<KanjiMonster>
fioriceta: bmips is quite different architecture wise from 47xx
<KanjiMonster>
I don't think DSA is currently made for 48 ports
<fioriceta>
hmm, shit
<KanjiMonster>
use switchdev in that case
<fioriceta>
I haven't looked at the register map yet, still trying to solve flash stuff
<fioriceta>
but from what I know, it should be similar to 47xx
<robimarko>
KanjiMonster: Port count doesnt matter to DSA
<fioriceta>
what would the memory overhead be like?
<robimarko>
It just a switchdev abstraction anyway
<fioriceta>
I can overclock the mips core to 350mhz or so
<fioriceta>
I'll bug you/think about it when I get linux booting tbh
<robimarko>
KanjiMonster: Well, that seems like a bug these days
<fioriceta>
I saw the rtl target with a lot of interfaces, that's for sure
<KanjiMonster>
also I'm not sure if dsa works with switches where the src/dst port is encoded in the dma descriptor instead of an ethernet header, AFAICT some broadcom switches do that
<robimarko>
It can work, that is what ipq40xx does
<robimarko>
But after a long discussion upstream doesnt like that for DSA
<fioriceta>
about the UART stuff, anyway, hmm
<fioriceta>
it is definitely closer to 47xx
<fioriceta>
even the flash address space stuff is the same
minimal has joined #openwrt-devel
<KanjiMonster>
that's because 0x1fc00000 is the MIPS boot/reset address according to the MIPS32 standard
<fioriceta>
no, no, 0xbc000000
<KanjiMonster>
but 47xx is based on ssb or bcma (axi), while bmips is based on ubus (e.g. no erom, no chipcommon core, etc)
<fioriceta>
well, from what I can tell, clock support will be missing
<fioriceta>
but there is backwards compatibility?
<KanjiMonster>
periphery on 47xx is at 0x18000000, on bmips/ubus it's 0x10000000
<KanjiMonster>
47xx uses bmips3300 or mips 74k cpu cores, bmips has bmips3300/4350/4380/5000
<fioriceta>
ic
<fioriceta>
I've never owned a 47xx device until now, so this is a surprise :S
<KanjiMonster>
when going more recent though bcm47xx/arm is much closer to bcm63xx/arm
<KanjiMonster>
at least AFAIK
<fioriceta>
is ubus worse than the other buses?
<fioriceta>
I guess it's cost saving
<KanjiMonster>
well, it has no discoverability like ssb/bcma has. and no "common" registers for the devices on it (i.e. clocking, reset, core id etc)
<fioriceta>
ah, alright, better get 47xx devices then :)
<KanjiMonster>
I wouldn't recommend getting bmips devices anyway except out of curiosity ;)
<fioriceta>
I remember when TLS would cause the thing to induce lag on my client
<fioriceta>
though, didn't have the SPU setup
<fioriceta>
(probably not worth it for that use case)
<KanjiMonster>
linusw: "18:46:58.221401 00:10:18:15:f6:a8 > d0:50:99:2f:54:41, ethertype IPv4 (0x0800), length 2010: (tos 0x0, ttl 64, id 9643, offset 0, flags [+], proto ICMP (1), length 1996) 192.168.1.1 > 192.168.1.2: ICMP echo request, id 1865, seq 3, length 1976" sending large frames works, but on rx they get dropped somewhere
<fioriceta>
you know, I was looking at autoselect and cfi
<fioriceta>
I can't tell, flash probe from within openocd is showing data
<fioriceta>
hmm, chip and bus should be 16-bit...
<linusw>
KanjiMonster: I can both send and receive I think, testing right now...
<fioriceta>
you know what's amazing?
<fioriceta>
writes just magically vanish, it's really fucking nice
<linusw>
jetm: I will try to help. Shall I review the PR?
<fioriceta>
KanjiMonster: you ever had this issue before?
<fioriceta>
I cannot find any strap, etc., that'd cause this
<linusw>
KanjiMonster: I sent a v4 of the MTU fix describing what I do and how it looks in tcpdump and all, 2048 byte frames work just fine both directions.
<fioriceta>
literally nothing outside of some sort of write protect feature as part of the NOR chip (when I tried to reprogram one of these ages ago, it failed)
<fioriceta>
hmm
<KanjiMonster>
linusw: so might be something missing or not supported for the embedded 10/100 ports
<jetm>
linusw: Yes, please. Review the PR. Thanks!
<PaulFertser>
jetm: if you still need wiki account please tell me your desired nick and e-mail.
<fioriceta>
I almost want to blow my head out, this is literally the worst platform ever...
<fioriceta>
nothing has ever made sense...
<jetm>
PaulFertser: Yes, I still need it to start documenting. nick -> jetm, email -> javier.tia@linaro.org. Thank you!
<PaulFertser>
jetm: sure, thank you for upstreaming efforts! You should get mail now.
<fioriceta>
KanjiMonster: smh, I tried loading in cfe into kseg0, nothing...
<fioriceta>
think I have had it...
<KanjiMonster>
fioriceta: but where in kseg0. also you might want to use kseg1
<fioriceta>
0x80000000
<fioriceta>
it's a ramboot build
<jetm>
PaulFertser: Access confirmed. Thank you!
<fioriceta>
I can't debug this when it takes 15+ mins for the bin to get loaded into memory
<KanjiMonster>
linusw: playing around with it, it looks like you can even go above 2k, and the limit is maximum value of the dma desc length field (0xfff / 4095)
Borromini has quit [Quit: Lost terminal]
<linusw>
KanjiMonster: which is PAGE_SIZE which makes a lot of sense.
<linusw>
I'll try this too, since we're at it we might as well make it perfect.
tidalf has quit [Remote host closed the connection]
tidalf has joined #openwrt-devel
<KanjiMonster>
linusw: the question is if we want to go that far. allocating 4k for each packet while only needing 1.5k in most cases seems wasteful