<iocampomx>
Hi there, I'm trying to build an image for an un-supported device (Cambium cnPilot R190), but a supported platform (MT7628). I know how to build the image for a supported device, but this is the first time building for a non-supported device. I've access to the bootloader via serial port. Is creating the Device Tree file the first step?
<slh>
more or less, after gathering as much information from the OEM firmware and how it uses the hardware as possible
<iocampomx>
Do you have more specific recommendations?
<slh>
check the git history what needed to be done to support similar devices, beyond that as an example, it's going to be original development without guides or handrails
<aparcar>
seems like a change of packages so some wifi related stuff wasn't installed via the upgrade server. dangole I guess the service never fully works until we add some kind of package tracking...
<colo>
it would need to be able to derive upgrade paths for currently installed packages when crossing certain release boundaries, I think
<colo>
but I am not sure what these upgrade path rules/inputs would have to look like... maybe a 3-tuple of (commit-sha at which this rule becomes effective)-(list of old packages to trigger the rule and be replaced)-(list of packages to replace them with) ?
<colo>
I think it's a very hard problem to solve for 100% of possible upgrade scenarios, but I think it could be quite easy to solve it for proper releases only, and for the majority of "important" (i.e., very commonly installed) packages
Danct12 has quit [Quit: What if we rewrite the code?]
Danct12 has joined #openwrt-devel
rua has joined #openwrt-devel
robimarko has quit [Remote host closed the connection]
robimarko has joined #openwrt-devel
hitech95 has joined #openwrt-devel
floof58 has quit [Quit: floof58]
floof58 has joined #openwrt-devel
rua has quit [Remote host closed the connection]
rua has joined #openwrt-devel
<hitech95>
is there any way to test an uboot-mtk image without flashing it?
rua is now known as Guest1150
rua has joined #openwrt-devel
<lu_zero>
hitech95: short of having a qemu config matching the hardware you care about, no
Guest1150 has quit [Ping timeout: 480 seconds]
<hitech95>
lu_zero, so there is no way to boot uboot from uboot using the same HW?
rua has quit [Remote host closed the connection]
rua has joined #openwrt-devel
<lu_zero>
depends on what you want to test and what is the hardware
<hitech95>
lu_zero, I want to be shure that it does not crash and test its bootflow. (I'm still trying to understand how it works). The main goal is to avoid having a brick while testing.
<hitech95>
I have to add support of overlays to the uboot so we can load the correct one based on a gpio
g___ has quit [Remote host closed the connection]
<lu_zero>
hitech95: you can probably chainload a second uboot from uboot
<lu_zero>
but depends on the hw and what's the first loader that loads the first uboot
<hitech95>
lu_zero, the hw is mt7986a, the first uboot should be in FIP and is loaded by a bl31 preloader of some kind.
<lu_zero>
I assume chainloading or playing with the boot priority
<lu_zero>
booting from a remote storage might also be easier
<hitech95>
yea I was booting openwrt from tftp with the bootm command
<hitech95>
so I'm not sure if I can do the same
<hitech95>
lu_zero, do you know if there is a command that called or a way to intercept that an user has entered the uboot console?
<lu_zero>
I do not, sadly :/
rua has quit [Ping timeout: 480 seconds]
rua has joined #openwrt-devel
rua is now known as Guest1155
rua has joined #openwrt-devel
Guest1155 has quit [Ping timeout: 480 seconds]
raenye has joined #openwrt-devel
raenye has quit [Ping timeout: 480 seconds]
<hitech95>
lu_zero, no problem
<hitech95>
Now I'm trying to understand how the baords .c is imported based on the config
dgcampea has quit [Remote host closed the connection]
<hitech95>
I think that I can do what I want with C
rua has quit [Remote host closed the connection]
dgcampea has joined #openwrt-devel
rua has joined #openwrt-devel
cmonroe has quit [Read error: No route to host]
cmonroe has joined #openwrt-devel
rua has quit [Quit: Leaving.]
rua has joined #openwrt-devel
<hitech95>
does anyone know how the uboot board files (.c) in included from the configuration? I want to add some custom logic on the device patch but I cannot figure out how a board file is build based on which device I'm choosing
<schmars[m]>
is there a separate channel for luci development?
<iocampomx>
If I want to bring a new device, should I only focus on the Device Tree + building the OpenWRT image, or, should I also rewrite the bootloader (UBoot)?
<Habbie>
iocampomx, it is my impression many openwrt ports leave uboot untouched
<iocampomx>
There seems to be a custom code after "Board: Ralink APSoC DRAM: 128 MB", which I guess was inserted on the bootloader from a propietary firmware, should I be worried about it? I mean, is that something that will block the OpenWRT image or execution?
<Habbie>
that looks quite useful
<Habbie>
1: Load system code to SDRAM via TFTP.
<Habbie>
this is great for testing the openwrt image that you built without breaking anything
<iocampomx>
Habbie, should I select "ramdisk" on the target image to load and run in SDRAM via TFTP?
Guest1170 has quit [Ping timeout: 480 seconds]
<Habbie>
iocampomx, that's a good question! but i don't know
<Habbie>
i used 'load to SDRAM via TFTP' for some image i got from the wiki, so a normal install image, once
<Habbie>
and that mostly worked
<Habbie>
but that's not enough experience to tell you what to do
<iocampomx>
Got it, anyway, I can easily test both kind of images and see if it works.
<Habbie>
indeed
<iocampomx>
The biggest challenge I've at this point, is to define the Device Tree, based on the information I can see from the UART & from /proc in the running device.
gladiac is now known as Guest1173
gladiac has joined #openwrt-devel
enyc has joined #openwrt-devel
Guest1173 has quit [Ping timeout: 480 seconds]
<iocampomx>
Anybody here that can help me to understand how to build the Device Tree?
raenye has joined #openwrt-devel
<raenye>
Hya. is there a known regression affecting wired connections on bcm53xx somewhere between -rc2 and -rc3?
<raenye>
I get nothing on lan1-4 and wan on Linksys EA9200
<raenye>
22.03.5 and 23.5-rc2 are good
<raenye>
-rc3 and snapshot are not
robimarko has quit [Remote host closed the connection]
<iocampomx>
It's using an old kernel version, and it doesn't have the Device Tree anywhere, I'm asumming the device configuration was compiled into the old kernel
<raenye>
try to boot an initramfs kernel (without touching flash)
<raenye>
you could take any m7628a device, even the one you linked before
<raenye>
just grab a precompiled initramfs from firmware selector
<raenye>
iocampomx: are you familiar with tftp
<raenye>
?
<iocampomx>
Yes, I'm. Just to recap, your recommendation is to: 1) build an ramfs image for another similar device, 2) run an TFTP server on my laptop, and 3) use the bootloader option to load the image from there?
<raenye>
iocampomx: for starters, yes. but no need to build
<iocampomx>
Are those images build somewhere, or why I shouldn't build it?
<raenye>
do you have mtd backups? if not, you could do it from openwrt
<raenye>
this sometimes appears in the original firmware bootlog
<raenye>
(kernel, not the uboot you uploaded)
<raenye>
better to use snapshot than 22.03.5
<raenye>
you could also download GPL sources from the vendor
<raenye>
look for GPIO assignment and for flash layout
<iocampomx>
Sounds good, I will use the kernel snapshop. I didn't have any luck with the vendor. I'm asumming GPIOs can be the last thing to setup, right? I mean, if the system is working, leds are the last cosmetic thing to setup.
<raenye>
iocampomx: reset button is nice to have
<raenye>
what is the device?
<iocampomx>
Cambium cnPilot 190W - By the way, before going further, is this thing about personalizing my hardware a legal thing?
<iocampomx>
raenye, here the full output of the bootloader: https://pastebin.com/br8UyWhx, it should have more info about the flash layout. Are you refering to the MTD?
<raenye>
Unless you live in an awkward country, it's legal :)
<raenye>
yes, mtd
<raenye>
iocampomx: great, so the flash layout is quite clear. 3 bootloader blocks, 1 mac (probably addresses), 1 factory (probably default SSID names and passwords, etc), 244 blocks for you ("image_all"), 2 config, 2 config backup, 1 mac backup
<raenye>
openwrt should only touch the image_all region
<raenye>
this will be part of the DTS you'll write
<raenye>
I see usb, you'll need the standard kernel modules for that
<iocampomx>
The board doesn't have any physical device port, not sure if it was just not solded, should I skip it?
<raenye>
maybe it's just part of their kernel
<raenye>
I also see you get shell access with original firmware
<raenye>
that's good, you could perhaps discover GPIO assignment
<iocampomx>
Yes, I did that a little bit, 11 = power led, 45 = system led. I just need to find the reset one.
<iocampomx>
What about the leds for lan, wan and wlan? should I also find the GPIOs?
<raenye>
45 seems high
<raenye>
most GPIOs are in the range 0-30
<iocampomx>
It's high, but it does work. I rested it with the "gpio" binary inside the shell. And I was able to turn it on/off.
<raenye>
the gpio binary accepts a number?
<raenye>
or it has names for leds
<iocampomx>
Number. Here the instructions: gpio l <gpio> <on> <off> <blinks> <rests> <times>
<iocampomx>
So I used: gpio l 45 1 0 0 0 0 - To turn off/on the system led, and it works.
<raenye>
so this won't help with buttons
<raenye>
anything in /sys/class/leds ?
<raenye>
even better if there's /sys/kernel/debug/gpio
<iocampomx>
No, the path "leds" doesn't exist. But, I remember I saw a "reset" GPIO somewhere in a config file, one sec.
<raenye>
is there a WPS button?
<iocampomx>
No
<iocampomx>
I think the only missing for now is the reset one, and maybe the lan, wlan & wan, shoul I also map those?
<raenye>
it's nice to have
<raenye>
but definitely not crucial
<raenye>
did you take backups of flash partitions?
<iocampomx>
key_reset_gpio=5, led_power_gpio 11
<iocampomx>
So, 5 should be reset.
<raenye>
there you have it
goliath has quit [Quit: SIGSEGV]
<raenye>
you still need to know whether it's active-high or active-low
<iocampomx>
FYI. I did the experiment with the initramfs-kernel image, and it didn't work, I guess. I was able to load the image but at the end I got this message: Bad Magic Number,03000000
<iocampomx>
And kind of started the boot process again (reset)
<raenye>
is the image large?
xback has quit [Ping timeout: 480 seconds]
<raenye>
It took me a while with one device, I has to remove many features to get down the size
xback has joined #openwrt-devel
<iocampomx>
Bytes transferred = 5524435 (544bd3 hex). LoadAddr=84000000 NetBootFileXferSize= 00544bd3. Erasing SPI Flash... Writing to SPI Flash... done. Automatic boot of image at addr 0x84000000 ... Automatic boot of image at addr 0x84000000 ... ## Booting image at 84000000 ... Bad Magic Number,03000000
<iocampomx>
Image size on my hard disk: 5.3M
<raenye>
the original kernel is smaller
<raenye>
try an older version, maybe the 22.3
<iocampomx>
Trying...
<iocampomx>
Same result with version 21.02.7 4.9M
<iocampomx>
Version 19 on firmware-selector doesn't provide the Kernel image, only Sysupgrade & TFTP-Recovery ones
<iocampomx>
If I enter to the System Enter Boot Command Line Interface, and "printenv", I see a bunch of variables, including this one: fw_checksum0=DD4DC5C5,5812224. I'm wondering if the bootloader has been modified and is doing a checksum when loading the image
raenye has quit [Ping timeout: 480 seconds]
hitech95 has quit [Read error: Connection reset by peer]