Re: [PATCH v3 2/2] command-nas: fix json output
Hi Jan,
The comments are below.
On 18.3.2022 13.33, Jan-Niklas Burfeind wrote:
> Hello Henrik,
>
> I think changing the print_system_info function would require us to
> change its signature, wouldn't it?
>
> The function is called with similar parameters from 2g,3g and 4g
> pendants. As the calculation and target values differ we'd need to add
> a uint for geneneration.
>
> If that info is already extractable from another parameter let me know.
> Else I'd implement a modified print function this weekend, that meets
> your reccomendation.
>
> Any suggestions on the other two commits?
>
> Jan-Niklas
>
>
> On 3/16/22 22:00, Henrik Ginstmark wrote:
>> Hi
>>
>> You can break down LTE global-cell-id to enodeb_id and cell_id like
>> this:
>>
>> "intrafrequency_lte_info": {
>> "tracking_area_code": 14000,
>> "global_cell_id": 10498829,
>> =
>> "enodeb_id": 41011,
>> "cell_id": 13,
>>
I was thinking about this, but since computing and terms vary between
technologies, I didn’t implement it
I also recommend leaving global_cell_id and only adding extra fields.
For example, the public cellmapper.net uses these global cell IDs for
different sectors.
>> blobmsg_add_u32(,
>> "enodeb_id",res.data.intrafrequency_lte_info_v2.global_cell_id/256);
>> blobmsg_add_u32(,
>> "cell_id",res.data.intrafrequency_lte_info_v2.global_cell_id%256);
>>
>> Same in nas_get_system_info and for UMTS global_cell_id you can break
>> down to rnc_id and
>> cell_id.
>>
>> blobmsg_add_u32(,
>> "rnc_id",res.data.wcdma_system_info_v2.cid/65536);
>> blobmsg_add_u32(,
>> "cell_id",res.data.wcdma_system_info_v2.cid%65536);
>>
>>
>> Henrik
>>
>> Den mån 14 mars 2022 kl 17:00 skrev Jan-Niklas Burfeind
>> :
>>>
>>> Hey everyone,
>>> I attached the current output of my patched uqmi.
>>> Please let me know if you think the arrays should be named differently
>>> or if you spot an error.
>>>
>>> Thanks and have a nice day
>>> Aiyion
>>>
>>> On 3/8/22 16:01, Jan-Niklas Burfeind wrote:
>>>> Output the cells from --get-cell-location-info in an array "cells",
>>>> "geran" entries as an array called alike,
>>>> and wrap output for different "frequencies" as such.
>>>>
>>>> Reported-by: Cezary Jackiewicz
>>>> Suggested-by: Oskari Lemmelä
>>>> Signed-off-by: Jan-Niklas Burfeind
>>>> ---
>>>> Hey Oskari and Cezary,
>>>> Please have a thorough look at this, as I do not have the matching
>>>> equipment at hand to test all cases.
>>>> Let me know if you rather would see `frequencies` become `channels`
>>>> and if the `geran`-array does make sense.
>>>>
These res.data.umts_info_v2.neighboring_geran_n are only GSM channels
adjacent to UTMS.
Perhaps the use of channels is a better term because frequencies can be
a little misleading.
frequency_bands would be more accurate than just frequencies.
So I would use the term channels. I would replace geran with channels, too.
>>>> I just compiled this series without errors and will have a look at the
>>>> LTE-related json-outputs.
>>>>
>>>> Thanks for your time
>>>> Jan-Niklas
>>>>
>>>> commands-nas.c | 46 +-
>>>> 1 file changed, 37 insertions(+), 9 deletions(-)
>>>>
>>>> diff --git a/commands-nas.c b/commands-nas.c
>>>> index 275c53f..b99767f 100644
>>>> --- a/commands-nas.c
>>>> +++ b/commands-nas.c
>>>> @@ -708,7 +708,7 @@ static void
>>>> cmd_nas_get_cell_location_info_cb(struct qmi_dev *qmi, struct
>>>> qmi_request *req, struct qmi_msg *msg)
>>>> {
>>>> struct qmi_nas_get_cell_location_info_response res;
>>>> - void *c, *t, *cell, *freq;
>>>> + void *c, *t, *cell, *cells, *freq, *frequencies, *geran;
>>>> int i, j;
>>>>
>>>> qmi_parse_nas_get_cell_location_info_response(msg, );
>>>> @@ -724,6 +724,7 @@ cmd_nas_get_cell_location_info_cb(struct
>>>> qmi_dev *qmi, struct qmi_request *req,
>>>>
>>>> res.data.umts_info_v2.primary_scrambling_code);
>>>> blobmsg_add_u32(, "rscp",
>>>> res.data.umts_info_v2.rsc
Re: [PATCH v2 2/2] command-nas: fix json output
Hi Jan-Niklas,
On 7.3.2022 14.14, Jan-Niklas Burfeind wrote:
> Output the cells from --get-cell-location-info in an array "cells".
>
> Signed-off-by: Jan-Niklas Burfeind
> ---
> Hey Oskari,
> I think you original author would be you?
> Have you got any suggestions how to name the cells array, or whether there's
> a cleaner way to fix the json output thats more how you intended it to be in
> the first place?
I did not validate then json after adding this feature. I should have
done it :)
I think the array is the best. At least I don't know a better solution.
Another similar problem is with multiple channels. One example in
interfrequency_lte_info.
That, too, should be fixed. In the qmi-service-nas.json file, they are
called frequency and cell arrays.
Maybe the plurals of the words frequencies or channels and cells are
good names for them.
Thanks,
Oskari
>
> Thanks
> Aiyion
>
> commands-nas.c | 6 +-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/commands-nas.c b/commands-nas.c
> index ff7a6c3..4b86304 100644
> --- a/commands-nas.c
> +++ b/commands-nas.c
> @@ -708,7 +708,7 @@ static void
> cmd_nas_get_cell_location_info_cb(struct qmi_dev *qmi, struct qmi_request
> *req, struct qmi_msg *msg)
> {
> struct qmi_nas_get_cell_location_info_response res;
> - void *c, *t, *cell, *freq;
> + void *c, *t, *cell, *cells, *freq;
> int i, j;
>
> qmi_parse_nas_get_cell_location_info_response(msg, );
> @@ -769,6 +769,7 @@ cmd_nas_get_cell_location_info_cb(struct qmi_dev *qmi,
> struct qmi_request *req,
> blobmsg_add_u32(, "s_intra_search_threshold",
>
> res.data.intrafrequency_lte_info_v2.s_intra_search_threshold);
> }
> + cells = blobmsg_open_array(, "cells");
> for (i = 0; i < res.data.intrafrequency_lte_info_v2.cell_n;
> i++) {
> cell = blobmsg_open_table(, NULL);
>
> print_lte_info(res.data.intrafrequency_lte_info_v2.cell[i].physical_cell_id,
> @@ -780,6 +781,7 @@ cmd_nas_get_cell_location_info_cb(struct qmi_dev *qmi,
> struct qmi_request *req,
>
> res.data.intrafrequency_lte_info_v2.cell[i].cell_selection_rx_level);
> blobmsg_close_table(, cell);
> }
> + blobmsg_close_array(, cells);
> blobmsg_close_table(, c);
> }
> if (res.set.interfrequency_lte_info) {
> @@ -795,6 +797,7 @@ cmd_nas_get_cell_location_info_cb(struct qmi_dev *qmi,
> struct qmi_request *req,
>
> res.data.interfrequency_lte_info.frequency[i].cell_selection_rx_level_high_threshold,
>
> res.data.interfrequency_lte_info.frequency[i].cell_selection_rx_level_low_threshold);
> }
> + cells = blobmsg_open_array(, "cells");
> for (j = 0; j <
> res.data.interfrequency_lte_info.frequency[i].cell_n; j++) {
> cell = blobmsg_open_table(, NULL);
>
> print_lte_info(res.data.interfrequency_lte_info.frequency[i].cell[j].physical_cell_id,
> @@ -806,6 +809,7 @@ cmd_nas_get_cell_location_info_cb(struct qmi_dev *qmi,
> struct qmi_request *req,
>
> res.data.interfrequency_lte_info.frequency[i].cell[j].cell_selection_rx_level);
> blobmsg_close_table(, cell);
> }
> + blobmsg_close_array(, cells);
> blobmsg_close_table(, freq);
> }
> if (res.data.interfrequency_lte_info.frequency_n > 0)
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v2 1/2] command-nas: fix cmd_nas_get_cell_location_info_cb
Hi Jan-Niklas,
On 7.3.2022 14.14, Jan-Niklas Burfeind wrote:
> Correct order of rsrp and rsrq parameters for print_lte_info.
Good catch. I didn’t check those similar variable names carefully enough.
I think my typo is in the print_lte_info parameters. This could also be
corrected
by swapping the order of the rsrp and rsrq variables in the function
definition.
Then the print order is also the same as the order of the function
parameters.
Thanks,
Oskari
>
> Signed-off-by: Jan-Niklas Burfeind
> ---
> commands-nas.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/commands-nas.c b/commands-nas.c
> index 01ca3b8..ff7a6c3 100644
> --- a/commands-nas.c
> +++ b/commands-nas.c
> @@ -772,8 +772,8 @@ cmd_nas_get_cell_location_info_cb(struct qmi_dev *qmi,
> struct qmi_request *req,
> for (i = 0; i < res.data.intrafrequency_lte_info_v2.cell_n;
> i++) {
> cell = blobmsg_open_table(, NULL);
>
> print_lte_info(res.data.intrafrequency_lte_info_v2.cell[i].physical_cell_id,
> -
> res.data.intrafrequency_lte_info_v2.cell[i].rsrq,
>
> res.data.intrafrequency_lte_info_v2.cell[i].rsrp,
> +
> res.data.intrafrequency_lte_info_v2.cell[i].rsrq,
>
> res.data.intrafrequency_lte_info_v2.cell[i].rssi);
> if (res.data.intrafrequency_lte_info_v2.ue_in_idle)
> blobmsg_add_u32(,
> "cell_selection_rx_level",
> @@ -798,8 +798,8 @@ cmd_nas_get_cell_location_info_cb(struct qmi_dev *qmi,
> struct qmi_request *req,
> for (j = 0; j <
> res.data.interfrequency_lte_info.frequency[i].cell_n; j++) {
> cell = blobmsg_open_table(, NULL);
>
> print_lte_info(res.data.interfrequency_lte_info.frequency[i].cell[j].physical_cell_id,
> -
> res.data.interfrequency_lte_info.frequency[i].cell[j].rsrq,
>
> res.data.interfrequency_lte_info.frequency[i].cell[j].rsrp,
> +
> res.data.interfrequency_lte_info.frequency[i].cell[j].rsrq,
>
> res.data.interfrequency_lte_info.frequency[i].cell[j].rssi);
> if (res.data.interfrequency_lte_info.ue_in_idle)
> blobmsg_add_u32(,
> "cell_selection_rx_level",
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [RFC PATCH 0/5] add support mikrotik routerboard hex poe
Hi, On 1/4/22 23:28, Sander Vanheule wrote: Hi, On Sun, 2021-12-26 at 20:41 +0200, Oskari Lemmela wrote: RFC patchset because of following open questions: --- [...] POE driver is implemented as a kernel module. Every port is separate hwmon device with same label as the DSA port. [...] Should this be implemented in Realtek POE switches as well? I haven't created any userspace tools for ubus integration yet Because I'm not sure if this is the right way to go. The hwmon part should be upstremable. Only thing is two non-standard sysfs controls (force_enable, port_state). They are also possible to implement as debugfs files if they are not accepted by the upstream. A short general comment, as this would be at least the fourth way to manage PoE devices in OpenWrt (GPIO controlled, realtek poe tool, ubiquiti poe tool). So this is more related to how OpenWrt could interface with PoE hardware in a more generic way, rather than this specific implementation (and I'm certainly not asking you to rewrite anything, Oskari). For controlling the outputs of PoE PSE ports, I had actually been thinking of using the the regulator framework in some way. This could range from simple GPIO controlled PoE ports (fixed-regulator), to actual PoE-controllers with current limits (PoE, PoE+...) and overload detection. That way existing interfaces could be used to manage (regulator) and monitor (regulator or hwmon) the outputs. I fear that adding custom hwmon interfaces for every type of PoE PSE out there just won't scale very well. I do not think the regulatory framework is the best for PoE control. It is more for displaying power dependencies and controlling power for power saving purposes. The best option could be to extend the netlink ethtool interface to support PoE standard data. This is quite similar to what SFP support has today. Ethtool is used to read EEPROM / FEC statistics and hwmon to display monitoring data. A GPIO controlled passive POE could only implement some parts of the ethtool netlink interface. IMHO, passive POE should never have been introduced, but I understand that the price of a product is more important than safety. Oskari Not that I've ever actually worked with a regulator driver, so maybe I'm just talking nonsense. I would be happy to hear other opinions about this. :-) Best, Sander ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 0/3] mikrotik: make soft_config partition writable
Hi, On 21.12.2021 15.19, Stefan Hellermann wrote: > Hi, > > I tested the series on a Mikrotik LHG 2. > > # cat /proc/mtd > dev:size erasesize name > mtd0: 0002 0001 "RouterBoot" > mtd1: e000 0001 "bootloader1" > mtd2: 1000 0001 "hard_config" > mtd3: 1000 0001 "bios" > mtd4: f000 0001 "bootloader2" > mtd5: 1000 1000 "soft_config" > mtd6: 00fe 0001 "firmware" > mtd7: 0029 0001 "kernel" > mtd8: 00d5 0001 "rootfs" > mtd9: 009e 0001 "rootfs_data" > > => erasesize of soft_config is smaller > > # cat /sys/firmware/mikrotik/soft_config/boot_proto > [bootp] dhcp > # echo dhcp > /sys/firmware/mikrotik/soft_config/boot_proto > # cat /sys/firmware/mikrotik/soft_config/commit > dirty > # echo 1 > /sys/firmware/mikrotik/soft_config/commit > # cat /sys/firmware/mikrotik/soft_config/boot_proto > bootp [dhcp] > # cat /sys/firmware/mikrotik/soft_config/commit > clean > > => No error, change is written to flash > > sysupgrade is also ok, configuration ist saved. > > Tested-by: Stefan Hellermann Thanks for testing! I will send v2 series with updated tags. Oskari ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 1/6] kernel: import dt-overlay configfs patches for 5.10
Hi, On 27.11.2021 13.55, Daniel Golle wrote: > On Sat, Nov 27, 2021 at 11:28:05AM +0200, Oskari Lemmelä wrote: >> Hi, >> >> On 25.11.2021 3.06, Daniel Golle wrote: >>> Import patchset allowing loading and applying device tree overlays at >>> run-time via configfs. >>> >>> This will allow for packaging DTOs for hardware add-ons such as the >>> various HATs (Hardware Attached on Top) common for SBCs. >>> A new kernel config option CONFIG_OF_CONFIGFS is introduced and some >>> additional sysfs attributes are added in case CONFIG_OF_OVERLAY is >>> enabled. >> >> Is this something that did not get accepted by upstream linux? >> Those patches seem to be almost 8 years old. > > I didn't investigate the full history of that patchset, I just found > it to be the default and only way available to modify DT from > user-space (and hence useful for SBC targets). > If I remember correctly dynamic runtime DT loading was rejected by linux community. Many SBC distros used them, but when it did not make to mainline they have changed strategy. U-boot dynamic device tree loading have been implemented after that to do same thing before Linux kernel is loaded. Oskari > Quite a few trees on git.kernel.org come with that patch on top and > when looking for DT overlay documentation, the docs assume you got that > patch applied [1], [2]... > > [1]: https://elinux.org/R-Car/DT-Overlays > [2]: > https://www.96boards.org/documentation/consumer/dragonboard/dragonboard410c/guides/dt-overlays.md.html#3-load-overlays-dynamically > ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 1/6] kernel: import dt-overlay configfs patches for 5.10
Hi,
On 25.11.2021 3.06, Daniel Golle wrote:
> Import patchset allowing loading and applying device tree overlays at
> run-time via configfs.
>
> This will allow for packaging DTOs for hardware add-ons such as the
> various HATs (Hardware Attached on Top) common for SBCs.
> A new kernel config option CONFIG_OF_CONFIGFS is introduced and some
> additional sysfs attributes are added in case CONFIG_OF_OVERLAY is
> enabled.
Is this something that did not get accepted by upstream linux?
Those patches seem to be almost 8 years old.
>
> To make use of this feature, both CONFIG_OF_CONFIGFS and
> CONFIG_OF_OVERLAY need to be enabled in a targets kernel config.
> This is currently already the case for mediatek/mt7622 and
> mediatek/mt7623 as it has already been enabled by commit 401d7ebf2c
> ("mediatek: enable configfs for DT overlay on mt7622 and mt7623").
>
> Signed-off-by: Daniel Golle
Oskari
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 0/3] uqmi: sync libqmi and add more diagnostic commands;
On 8.11.2021 12.47, Koen Vandeputte wrote:
>
> On 08.11.21 09:36, Koen Vandeputte wrote:
>>
>> On 24.10.21 17:05, Oskari Lemmela wrote:
>>> First patch updates dynamic code generator to handle newer data from
>>> libqmi project. After data is synced from libqmi project, more
>>> connection
>>> diagnostic commands are added to uqmi.
>>>
>>> Oskari Lemmela (3):
>>> uqmi: update code generator
>>> uqmi: sync data from libqmi project
>>> uqmi: add more diagnostics commands
>>>
>>> commands-nas.c | 663 +++-
>>> commands-nas.h | 10 +-
>>> commands-uim.c | 8 +-
>>> commands-wda.c | 3 +-
>>> commands-wds.c | 16 +-
>>> commands-wds.h | 2 +-
>>> data/gen-code.pl | 11 +-
>>> data/gen-common.pm | 10 +
>>> data/gen-error-list.pl | 2 +-
>>> data/gen-header.pl | 5 +-
>>> data/qmi-service-ctl.json | 40 +-
>>> data/qmi-service-dms.json | 533 +++---
>>> data/qmi-service-nas.json | 1703 +--
>>> data/qmi-service-oma.json | 52 +-
>>> data/qmi-service-pbm.json | 47 +-
>>> data/qmi-service-pds.json | 104 +-
>>> data/qmi-service-uim.json | 746 ++
>>> data/qmi-service-wda.json | 144 ++-
>>> data/qmi-service-wds.json | 2039
>>> +
>>> data/qmi-service-wms.json | 218 ++--
>>
>> I noticed the JSON files here seem edited compared to upstream to
>> avoid following original compile issue: (variables starting with a
>> number)
>>
There is 5 variables starting with number so I did took short cut and
just renamed them.
https://github.com/olemmela/uqmi/commit/ab6d00ac0f4fa22956f5c1dc9266d89d3ade983e
>>
>> /Tools/QMI/qmi-message-nas.h:820:19: error: invalid suffix
>> "gpp_eons_plmn_name" on integer constant
>> 820 | } 3gpp_eons_plmn_name;
>> | ^~~
>>
>> Maybe the perl scripts could be edited to simply prepend a "_" to
>> these vars to avoid the problem.
>> This would allow to use unmodified upstream json files which is a lot
>> less work to update it in the future.
>>
You are right. Better try keep files as close to upstream ones as
possible. There is still glib related lines
in headers files to be changed after syncing.
https://github.com/olemmela/uqmi/commit/5ee729f571e7ceab54cf33d27ef936a41c576255
https://github.com/olemmela/uqmi/commit/8d95a06037d572b5f31634fa50d4202006d5e8b4
>>
>> Regards,
>>
>> Koen
>>
>
> Patch proposal:
>
>
> diff --git a/data/gen-common.pm b/data/gen-common.pm
> index e951776..278afce 100644
> --- a/data/gen-common.pm
> +++ b/data/gen-common.pm
> @@ -32,6 +32,7 @@ sub gen_cname($) {
> my $name = shift;
>
> $name =~ s/[^a-zA-Z0-9_]/_/g;
> + $name = "_${name}" if $name =~ /^\d/;
> return lc($name);
> }
>
Thanks. I squashed it to parser commit and dropped json file modification.
Updated patches are in same upstream branch
https://github.com/olemmela/uqmi.git
>
> Regards,
>
> Koen
>
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 0/3] uqmi: sync libqmi and add more diagnostic commands
On 24.10.2021 18.05, Oskari Lemmela wrote: > First patch updates dynamic code generator to handle newer data from > libqmi project. After data is synced from libqmi project, more connection > diagnostic commands are added to uqmi. > > Oskari Lemmela (3): > uqmi: update code generator > uqmi: sync data from libqmi project > uqmi: add more diagnostics commands > > commands-nas.c| 663 +++- > commands-nas.h| 10 +- > commands-uim.c|8 +- > commands-wda.c|3 +- > commands-wds.c| 16 +- > commands-wds.h|2 +- > data/gen-code.pl | 11 +- > data/gen-common.pm| 10 + > data/gen-error-list.pl|2 +- > data/gen-header.pl|5 +- > data/qmi-service-ctl.json | 40 +- > data/qmi-service-dms.json | 533 +++--- > data/qmi-service-nas.json | 1703 +-- > data/qmi-service-oma.json | 52 +- > data/qmi-service-pbm.json | 47 +- > data/qmi-service-pds.json | 104 +- > data/qmi-service-uim.json | 746 ++ > data/qmi-service-wda.json | 144 ++- > data/qmi-service-wds.json | 2039 + > data/qmi-service-wms.json | 218 ++-- > qmi-enums-dms.h | 234 - > qmi-enums-nas.h | 856 +++- > qmi-enums-pds.h | 34 +- > qmi-enums-private.h |3 + > qmi-enums-uim.h | 246 - > qmi-enums-wda.h | 19 +- > qmi-enums-wds.h | 1286 +++ > qmi-enums-wms.h | 215 ++-- > qmi-enums.h | 228 +++-- > qmi-errors.h | 197 ++-- > qmi-flags64-dms.h | 28 +- > qmi-flags64-nas.h | 34 +- > 32 files changed, 7878 insertions(+), 1858 deletions(-) > Second patch was too big for mailing list. Patches are also available in https://github.com/olemmela/uqmi.git upstream branch. Oskari ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] build: artifacts add dependency for builded images
Hi, On 21.3.2021 11.55, Paul Spooren wrote: On Sat Mar 20, 2021 at 10:58 PM HST, Oskari Lemmela wrote: Add possibility to use images and initramfs in artifacts. Signed-off-by: Oskari Lemmela --- Hi, could you please elaborate on your use-case? One use case is build full sdcard image for Bananapi R64. Currently fit and initramfs images need to be copied over tftp/serial after booting from sdcard. Oskari include/image.mk | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/include/image.mk b/include/image.mk index 29df0938bc..8b7b2b9740 100644 --- a/include/image.mk +++ b/include/image.mk @@ -478,6 +478,7 @@ define Device/Build/initramfs $$(if $$(CONFIG_JSON_OVERVIEW_IMAGE_INFO), $(BUILD_DIR)/json_info_files/$$(KERNEL_INITRAMFS_IMAGE).json,)) $(KDIR)/$$(KERNEL_INITRAMFS_NAME):: image_prepare + $(1)-images: $(BIN_DIR)/$$(KERNEL_INITRAMFS_IMAGE) $(BIN_DIR)/$$(KERNEL_INITRAMFS_IMAGE): $(KDIR)/tmp/$$(KERNEL_INITRAMFS_IMAGE) cp $$^ $$@ @@ -570,6 +571,7 @@ define Device/Build/image $(BUILD_DIR)/json_info_files/$(call DEVICE_IMG_NAME,$(1),$(2)).json, \ $(BIN_DIR)/$(call DEVICE_IMG_NAME,$(1),$(2))$$(GZ_SUFFIX)) $(eval $(call Device/Export,$(KDIR)/tmp/$(call DEVICE_IMG_NAME,$(1),$(2)),$(1))) + $(3)-images: $(BIN_DIR)/$(call DEVICE_IMG_NAME,$(1),$(2))$$(GZ_SUFFIX) ROOTFS/$(1)/$(3) := \ $(KDIR)/root.$(1)$$(strip \ @@ -628,7 +630,7 @@ endef define Device/Build/artifact $$(_TARGET): $(BIN_DIR)/$(DEVICE_IMG_PREFIX)-$(1) $(eval $(call Device/Export,$(KDIR)/tmp/$(DEVICE_IMG_PREFIX)-$(1))) - $(KDIR)/tmp/$(DEVICE_IMG_PREFIX)-$(1): $$(KDIR_KERNEL_IMAGE) + $(KDIR)/tmp/$(DEVICE_IMG_PREFIX)-$(1): $$(KDIR_KERNEL_IMAGE) $(2)-images @rm -f $$@ $$(call concat_cmd,$(ARTIFACT/$(1))) @@ -651,7 +653,7 @@ define Device/Build $$(call Device/Build/image,$$(fs),$$(image),$(1) $$(eval $$(foreach artifact,$$(ARTIFACTS), \ - $$(call Device/Build/artifact,$$(artifact + $$(call Device/Build/artifact,$$(artifact),$(1 endef -- 2.25.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 5/5] mediatek: fix bpi-r64 default switch config
On 24.2.2021 22.12, Daniel Golle wrote: > On Wed, Feb 24, 2021 at 09:10:39PM +0200, Oskari Lemmela wrote: >> bananapi r64 uses mediatek,mt753x gsw switch device. >> configure network defaults accordingly. >> >> Signed-off-by: Oskari Lemmela >> --- >> target/linux/mediatek/image/mt7622.mk | 6 -- >> .../linux/mediatek/mt7622/base-files/etc/board.d/02_network | 3 ++- >> 2 files changed, 6 insertions(+), 3 deletions(-) >> >> diff --git a/target/linux/mediatek/image/mt7622.mk >> b/target/linux/mediatek/image/mt7622.mk >> index 1d1c2f8a80..50d319ba5c 100644 >> --- a/target/linux/mediatek/image/mt7622.mk >> +++ b/target/linux/mediatek/image/mt7622.mk >> @@ -6,7 +6,8 @@ define Device/bpi_bananapi-r64 >>DEVICE_MODEL := Banana Pi R64 >>DEVICE_DTS := mt7622-bananapi-bpi-r64 >>SUPPORTED_DEVICES := bananapi,bpi-r64 >> - DEVICE_PACKAGES := kmod-usb-ohci kmod-usb2 kmod-usb3 kmod-ata-ahci-mtk >> + DEVICE_PACKAGES := kmod-usb-ohci kmod-usb2 kmod-usb3 kmod-ata-ahci-mtk \ >> +swconfig > This will be obsolete with 5.10 and using DSA where the previous > defaults are just fine. > Let's not introduce swconfig now just to drop it again in a few days > when Linux 5.10 support will be in openwrt.git as well. > > The other 4 patches look good, I'll merge them after a round of > testing. Thanks for merging patches. Should these other four patches also merged to 21.02 branch? I suppose DSA is recommended way also for 21.02 branch? I'll send one more patch to drop gsw from mt7622-bananapi-bpi-r64.dts. Then network defaults are matching to dts. Oskari >> endef >> TARGET_DEVICES += bpi_bananapi-r64 >> >> @@ -17,7 +18,8 @@ define Device/bpi_bananapi-r64-rootdisk >>DEVICE_DTS_DIR := ../dts >>SUPPORTED_DEVICES := bananapi,bpi-r64 >>DEVICE_PACKAGES := kmod-fs-vfat kmod-nls-cp437 kmod-nls-iso8859-1 \ >> -mkf2fs e2fsprogs kmod-usb-ohci kmod-usb2 kmod-usb3 kmod-ata-ahci-mtk >> +mkf2fs e2fsprogs kmod-usb-ohci kmod-usb2 kmod-usb3 kmod-ata-ahci-mtk \ >> +swconfig >>IMAGES := sysupgrade-emmc.bin.gz >>IMAGE/sysupgrade-emmc.bin.gz := sysupgrade-emmc | gzip | append-metadata >> endef >> diff --git a/target/linux/mediatek/mt7622/base-files/etc/board.d/02_network >> b/target/linux/mediatek/mt7622/base-files/etc/board.d/02_network >> index 3a409c8ec9..88a22dfb74 100755 >> --- a/target/linux/mediatek/mt7622/base-files/etc/board.d/02_network >> +++ b/target/linux/mediatek/mt7622/base-files/etc/board.d/02_network >> @@ -11,7 +11,8 @@ mediatek_setup_interfaces() >> case $board in >> bananapi,bpi-r64-rootdisk|\ >> bananapi,bpi-r64) >> -ucidef_set_interfaces_lan_wan "lan0 lan1 lan2 lan3" wan >> +ucidef_add_switch "switch0" \ >> + "1:lan" "2:lan" "3:lan" "4:lan" "6u@eth0" >> "0:wan" "5u@eth1" >> ;; >> mediatek,mt7622-rfb1) >> ucidef_set_interfaces_lan_wan "lan1 lan2 lan3 lan4" wan >> -- >> 2.25.1 >> >> >> ___ >> openwrt-devel mailing list >> openwrt-devel@lists.openwrt.org >> https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 4/9] sunxi: switch to lzma compressed fit image
Hi, On 27.1.2019 1.13, Hauke Mehrtens wrote: > On 1/14/19 6:54 PM, Oskari Lemmela wrote: >> Use LZMA compressed fit image to load kernel and dtb. >> Fit image can be used load kernel and dtb from SPI flash. >> >> Signed-off-by: Oskari Lemmela >> --- >> package/boot/uboot-sunxi/uEnv-a64.txt | 5 ++- >> package/boot/uboot-sunxi/uEnv-default.txt | 5 ++- >> package/boot/uboot-sunxi/uEnv-pangolin.txt | 5 ++- >> target/linux/sunxi/Makefile| 2 +- >> target/linux/sunxi/cortexa53/target.mk | 1 - >> target/linux/sunxi/image/Makefile | 17 +++--- >> target/linux/sunxi/image/cortex-a53.mk | 25 --- >> target/linux/sunxi/image/cortex-a7.mk | 36 +++--- >> target/linux/sunxi/image/cortex-a8.mk | 11 --- >> 9 files changed, 49 insertions(+), 58 deletions(-) >> > My H3 Xunlong Orange Pi R1 does not boot fit images, CONFIG_FIT is not > set in my U-Boot configuration. > > I am getting this error: > --- > Scanning mmc 0:1... > Found U-Boot script /boot.scr > 301 bytes read in 1 ms (293.9 KiB/s) > ## Executing script at 4310 > 2770296 bytes read in 125 ms (21.1 MiB/s) > Wrong Image Format for bootm command > ERROR: can't get kernel image! > SCRIPT FAILED: continuing... > > Device 0: device type unknown > ... is now current device > ethernet@1c3 Waiting for PHY auto negotiation to complete.. done > BOOTP broadcast 1 > --- > > I activated these U-Boot configuration options: > CONFIG_FIT=y > CONFIG_LZMA=y > and now I am hitting the next problem: > --- > Found U-Boot script /boot.scr > 301 bytes read in 2 ms (146.5 KiB/s) > ## Executing script at 4310 > 2772324 bytes read in 126 ms (21 MiB/s) > ## Loading kernel from FIT Image at 4330 ... >Using 'config@1' configuration >Trying 'kernel@1' kernel subimage > Description: ARM OpenWrt Linux-4.14.95 > Type: Kernel Image > Compression: lzma compressed > Data Start: 0x433000e4 > Data Size:2755114 Bytes = 2.6 MiB > Architecture: ARM > OS: Linux > Load Address: 0x4200 > Entry Point: 0x4200 > Hash algo:crc32 > Hash value: 62b0495d > Hash algo:sha1 > Hash value: ca607078b06de248018641320577e910a1967dab >Verifying Hash Integrity ... crc32+ sha1+ OK > ## Loading fdt from FIT Image at 4330 ... >Using 'config@1' configuration >Trying 'fdt@1' fdt subimage > Description: ARM OpenWrt sun8i-h2-plus-orangepi-r1 device tree blob > Type: Flat Device Tree > Compression: uncompressed > Data Start: 0x435a0c54 > Data Size:15325 Bytes = 15 KiB > Architecture: ARM > Hash algo:crc32 > Hash value: c9c29924 > Hash algo:sha1 > Hash value: 6f4bee23444eb246cc8287c40ebb240cdf45aa9d >Verifying Hash Integrity ... crc32+ sha1+ OK >Booting using the fdt blob at 0x435a0c54 > EHCI failed to shut down host controller. > EHCI failed to shut down host controller. >Uncompressing Kernel Image ... Image too large: increase > CONFIG_SYS_BOOTM_LEN > Must RESET board to recover > resetting ... > --- > > My H5 Xunlong Orange Pi Zero Plus works fine. > > Hauke Thanks for testing. I did not expect that some of targets does not have CONFIG_FIT enabled. I'll modify patch so that only cortex-a53 platforms use this lzma and fit image boot. U-boot is not currently updated while running sysupgrade. That has to implemented before FIT boot can be enabled to other sunxi targets. Thanks, Oskari ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 5/9] sunxi: add support for pine64 lts
Hi, On 14.1.2019 21.03, Petr Štetiar wrote: > Oskari Lemmela [2019-01-14 19:54:25]: > > Hi, > >> CPU: R18 High Performance Quad-core 64-bit Cortex-A53 >> GPU: Mali400MP2 OpenGL ES 2.0/1.1/1.0, OpenVG 1.1, EGL >> Memory: 2GB LPDDR3 (shared with GPU) >> Onboard Storage: TF card / NOR flash(16MB) >> Onboard Network: 1000M/100M Ethernet RJ45 > can you please add flashing instructions here? > > From https://openwrt.org/submitting-patches > > "If you add support for new hardware: Include in your commit message a short > description of the hardware and how to install OpenWrt on it. Have a look at > the recent additions for some examples." Here is flashing instructions which I added to commit message: Flash instruction: 1. Uncompress sdcard.img.gz image and write it to SD-card $ zcat | dd of=/dev/sdX bs=1M 2. Connect ethernet cable and boot Pine64 LTS with SD-card 3. Copy u-boot-with-spl.bin to 192.168.1.1:/tmp 4. Write u-boot image to the SPI flash $ mtd write /dev/mtd0 5. Copy squashfs-sysupgrade.bin image to 192.168.1.1:/tmp 6. Run sysupgrade to copy the image and current configuration to the SPI flash $ sysupgrade >> + IMAGES += sysupgrade.bin u-boot-with-spl.bin >> + IMAGE/u-boot-with-spl.bin := sunxi-uboot | check-size 896k > Please use ARTIFACTS[1] for u-boot-with-spl.bin image. Thanks, I did not notice this one. Already updated commit to use it. > 1. > https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=493c9a35516c27a8ec412d97e63c8cf6f41a57ea > > -- ynezz Oskari ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
