Re: [LEDE-DEV] [PATCH v2 0/4] sunxi: rework image build and sysupgrade support

[Yousong Zhou]

On 2 January 2017 at 02:55, Zoltan HERPAI  wrote:
> Hi Yousong,
>
> Yousong Zhou wrote:
>>
>> This series mainly tries achieve the following goals
>>
>>  - use new image generation method
>>  - squashfs sdcard image support
>>  - mkfs.f2fs or mkfs.ext4 remaining space within squashfs rootfs partition
>> and
>>mount it as rw overlay
>>  - sysupgrade with fwtool check support
>>
>> Device profiles are automatically generated with a helper makefile.  Names
>> for
>> image files, board_names, etc. are changed to try to use basename of
>> kernel dts
>> file for the specific device.  Names for uboot-sunxi is not touched
>> though.
>>
>
> [snip]
>
> I'm OK with what these patches want to achieve. I had several patches
> prepared for similar purposes in sunxi (apart from the new image building
> code), but were never finalized due to responsibilities elsewhere, as one of
> the "obvious reasons" mentioned earlier (by Daniel IIRC). Whether you are
> merging these into trunk before or after your release and/or the merge, is
> obviously at your discretion.
>
> Having said that, if such major target reworks happen, and we seem to be
> geared towards a merge, it would be appreciated if you cc the openwrt-devel
> list so people over there would be aware.
>
> Thanks,
> Zoltan H
>

Well, posting to OpenWrt-devel with news about LEDE seems to me like
an act of propaganda/advertising/boasting or whatever the word could
be.  I do not think I have the role/hat/intention to play that...
Sorry

Besides, I do not think the extra mail will do much help anyway as
it's very likely those concerned with the merge are already subscribed
to both mailing lists.

The better plan could be there were two guys volunteered to each watch
activities of a single side and prepare a digest/summary/brief or any
such thing together with emphasis on their possible effects on
possible future merge and cross-post it to both openwrt-devel and
lede-dev.  That way we will have a written down records/checklist to
review for the merge to happen.

But I probably have talked too much and will digress if going any further...

Regards,
yousong

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH 04/11] build: image.mk: don't install-images for devices not selected

[Yousong Zhou]

On 2 January 2017 at 03:27, Felix Fietkau  wrote:
> On 2017-01-01 19:07, Yousong Zhou wrote:
>> If the default device profile is meant to be used to make a single
>> image that can run on all device, then in the case of sunxi, it is not
>> possible at least with regard to uboot.
>>
>> Or if the default device profile is meant to be selected as the
>> default just to implicitly enable all other profiles of the same
>> target/subtarget, then again in the case of sunxi it has the
>> dependency problem as illustrated above.  Besides, the build system
>> can already select multiple devices and enable all profiles (devices)
>> with explicit config symbols.  Can this goal of the default profile be
>> dropped?
> There are targets that have multiple default profiles for all devices
> (with just different package selection). Because of that, I think for
> now it is better to have one default profile as well.

So these default profiles are intended more for defining packages set
or flavours, and along with that have the side effect of
install-images for all devices?

The other thing is that Device/Default of ar71xx has Minimal as member
of the PROFILES and it seems to be just missing in the code.  Just a
random finding and you may fix that later if that's the case

>
>> My current understanding is that the profiles/*.mk thing is part of
>> the old code and is to be replaced with the Device/xxx thing.  Correct
>> me if I am wrong ;)
>>
>> The conclusion is that for sunxi at least, I do not know how to make a
>> default profile or device to make it easier for users.  At the moment
>> we have the alphabetically first one selected as the default but that
>> is just a little bit not easy for all other devices' users ;)
> You can do this like on other targets as well. Make a profile called
> 'Default', select all packages needed to build images for all devices,
> set PROFILES:=Default and it should work.

This will be ugly because this default profile will need to select all
current and future uboot-sunxi variants.  I myself certainly do not
like that.  But if default profile is a must, you know I am all ears
to receive better plans ;)

The current menuconfig arrangement for sunxi target in my opinion is
not that difficult for users anyway.  For people building images on
their own, it is very likely that want build for a single or selected
set of devices.  I still remember the first time I played with ar71xx
target and selected default profile by chance, and viola the
bin/ar71xx directory had so many images for so many different
devices...

yousong

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] newbie opkg upgrading questions..

[Yousong Zhou]

On 2 January 2017 at 11:30, B. Cook  wrote:
> This worked for me the last time, but now - not so much..
>
> opkg list-upgradable | cut -f1 -d\ | xargs opkg upgrade
>
> root@wzr-ag300h:~# df -h
> FilesystemSize  Used Available Use% Mounted on
> tmpfs61.2M  1.1M 60.1M   2% /tmp
> overlayfs:/overlay   28.4M  2.6M 25.9M   9% /
> tmpfs   512.0K 0512.0K   0% /dev
>
> root@wzr-ag300h:~# mount
> proc on /proc type proc (ro,noatime)
> tmpfs on /tmp type tmpfs (rw,nosuid,nodev,noatime)
> overlayfs:/overlay on / type overlay
> (ro,noatime,lowerdir=/,upperdir=/overlay/upper,workdir=/overlay/work)
> tmpfs on /dev type tmpfs (ro,relatime,size=512k,mode=755)
> devpts on /dev/pts type devpts (ro,relatime,mode=600)
>

/overlay on / was mounted as ro.  That should explain the error
message, but we need to find out how it is so.  Maybe checking dmesg
log will reveal some info.  Try remounting it as rw for the moment
should also work and if not the command should also reveal some useful
info ;)

yousong

> The error is the same with all.. Just showing one.
>
> opkg upgrade luci-theme-bootstrap
> Upgrading luci-theme-bootstrap on root from git-16.363.68908-f12fdba-1
> to git-17.001.43128-3366c25-1...
> Downloading 
> http://downloads.lede-project.org/snapshots/packages/mips_24kc/luci/luci-theme-bootstrap_git-17.001.43128-3366c25-1_all.ipk.
> Collected errors:
>  * wfopen: //usr/lib/opkg/info/luci-theme-bootstrap.control: Read-only
> file system.
>  * wfopen: //usr/lib/opkg/info/luci-theme-bootstrap.postinst:
> Read-only file system.
>  * wfopen: //usr/lib/opkg/info/luci-theme-bootstrap.postinst-pkg:
> Read-only file system.
>  * wfopen: //usr/lib/opkg/info/luci-theme-bootstrap.prerm: Read-only
> file system.
>  * wfopen: /etc/uci-defaults/30_luci-theme-bootstrap: Read-only file system.
>  * wfopen: /usr/lib/lua/luci/view/themes/bootstrap/footer.htm:
> Read-only file system.
>  * wfopen: /usr/lib/lua/luci/view/themes/bootstrap/header.htm:
> Read-only file system.
>  * wfopen: /www/luci-static/bootstrap/cascade.css: Read-only file system.
>  * wfopen: /www/luci-static/bootstrap/favicon.ico: Read-only file system.
>  * wfopen: /www/luci-static/bootstrap/html5.js: Read-only file system.
>  * wfopen: /www/luci-static/bootstrap/mobile.css: Read-only file system.
>  * pkg_write_filelist: Failed to open
> //usr/lib/opkg/info/luci-theme-bootstrap.list: Read-only file system.
>  * opkg_install_pkg: Failed to extract data files for
> luci-theme-bootstrap. Package debris may remain!
>  * pkg_write_filelist: Failed to open
> //usr/lib/opkg/info/luci-theme-bootstrap.list: Read-only file system.
>
> root@wzr-ag300h:~# df -h /usr/
> FilesystemSize  Used Available Use% Mounted on
> overlayfs:/overlay   28.4M  2.6M 25.9M   9% /
>
>  mount | grep overlay
> overlayfs:/overlay on / type overlay
> (ro,noatime,lowerdir=/,upperdir=/overlay/upper,workdir=/overlay/work)
>
> My son is doing 'homework' currently, which involves much cursing and
> keyboard mashing :P so I can not reboot the unit.
>
> Is that all I need to do? (and if so, how come? what did I do wrong?
> either now or before..)
>
> root@wzr-ag300h:~# uptime
>  22:29:19 up 5 days,  1:10,  load average: 0.00, 0.00, 0.00
>
> root@wzr-ag300h:~# uname -a
> Linux wzr-ag300h 4.4.39 #0 Sat Dec 24 13:55:45 2016 mips GNU/Linux
>
> Should I have left something useful please let me know.
>
> Thanks in advance.
>
> ___
> Lede-dev mailing list
> Lede-dev@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] newbie opkg upgrading questions..

[B. Cook]

This worked for me the last time, but now - not so much..

opkg list-upgradable | cut -f1 -d\ | xargs opkg upgrade

root@wzr-ag300h:~# df -h
FilesystemSize  Used Available Use% Mounted on
tmpfs61.2M  1.1M 60.1M   2% /tmp
overlayfs:/overlay   28.4M  2.6M 25.9M   9% /
tmpfs   512.0K 0512.0K   0% /dev

root@wzr-ag300h:~# mount
proc on /proc type proc (ro,noatime)
tmpfs on /tmp type tmpfs (rw,nosuid,nodev,noatime)
overlayfs:/overlay on / type overlay
(ro,noatime,lowerdir=/,upperdir=/overlay/upper,workdir=/overlay/work)
tmpfs on /dev type tmpfs (ro,relatime,size=512k,mode=755)
devpts on /dev/pts type devpts (ro,relatime,mode=600)

The error is the same with all.. Just showing one.

opkg upgrade luci-theme-bootstrap
Upgrading luci-theme-bootstrap on root from git-16.363.68908-f12fdba-1
to git-17.001.43128-3366c25-1...
Downloading 
http://downloads.lede-project.org/snapshots/packages/mips_24kc/luci/luci-theme-bootstrap_git-17.001.43128-3366c25-1_all.ipk.
Collected errors:
 * wfopen: //usr/lib/opkg/info/luci-theme-bootstrap.control: Read-only
file system.
 * wfopen: //usr/lib/opkg/info/luci-theme-bootstrap.postinst:
Read-only file system.
 * wfopen: //usr/lib/opkg/info/luci-theme-bootstrap.postinst-pkg:
Read-only file system.
 * wfopen: //usr/lib/opkg/info/luci-theme-bootstrap.prerm: Read-only
file system.
 * wfopen: /etc/uci-defaults/30_luci-theme-bootstrap: Read-only file system.
 * wfopen: /usr/lib/lua/luci/view/themes/bootstrap/footer.htm:
Read-only file system.
 * wfopen: /usr/lib/lua/luci/view/themes/bootstrap/header.htm:
Read-only file system.
 * wfopen: /www/luci-static/bootstrap/cascade.css: Read-only file system.
 * wfopen: /www/luci-static/bootstrap/favicon.ico: Read-only file system.
 * wfopen: /www/luci-static/bootstrap/html5.js: Read-only file system.
 * wfopen: /www/luci-static/bootstrap/mobile.css: Read-only file system.
 * pkg_write_filelist: Failed to open
//usr/lib/opkg/info/luci-theme-bootstrap.list: Read-only file system.
 * opkg_install_pkg: Failed to extract data files for
luci-theme-bootstrap. Package debris may remain!
 * pkg_write_filelist: Failed to open
//usr/lib/opkg/info/luci-theme-bootstrap.list: Read-only file system.

root@wzr-ag300h:~# df -h /usr/
FilesystemSize  Used Available Use% Mounted on
overlayfs:/overlay   28.4M  2.6M 25.9M   9% /

 mount | grep overlay
overlayfs:/overlay on / type overlay
(ro,noatime,lowerdir=/,upperdir=/overlay/upper,workdir=/overlay/work)

My son is doing 'homework' currently, which involves much cursing and
keyboard mashing :P so I can not reboot the unit.

Is that all I need to do? (and if so, how come? what did I do wrong?
either now or before..)

root@wzr-ag300h:~# uptime
 22:29:19 up 5 days,  1:10,  load average: 0.00, 0.00, 0.00

root@wzr-ag300h:~# uname -a
Linux wzr-ag300h 4.4.39 #0 Sat Dec 24 13:55:45 2016 mips GNU/Linux

Should I have left something useful please let me know.

Thanks in advance.

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] Adding new targets/subtargets

[Philip Prindeville]

> On Jan 1, 2017, at 8:34 AM, Weedy  wrote:
> 
> On 31 December 2016 at 20:23, Philip Prindeville
>  wrote:
>> 
>> 
>> Pruning useful subtargets to solve a buildbot resource shortage seems like 
>> taking a sledgehammer to kill a fly.
>> 
>> Why not instead just add a profile attribute like:
>> 
>> BUILDBOT_BUILD_ME:=no
>> 
>> Whether it’s still useful to *build* a subtarget is a different question 
>> that whether it’s still useful (from a pedagogical perspective) to *keep* a 
>> subtarget in the SCM… and these questions shouldn’t be conflated.
>> 
>> -Philip
> 
> 
> If this is going to be the road we travel down (I'm bikeshedding here)
> wouldn't a  BUILDBOT_INTERVAL:=daily/3d/7d/14d make more sense?
> 
> We have more then a few full on targets that for the most part are
> much less popular then say ar71xx.


That’s an even better idea.

-Philip


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH v2 0/4] sunxi: rework image build and sysupgrade support

[Zoltan HERPAI]

Hi Yousong,

Yousong Zhou wrote:

This series mainly tries achieve the following goals

 - use new image generation method
 - squashfs sdcard image support
 - mkfs.f2fs or mkfs.ext4 remaining space within squashfs rootfs partition and
   mount it as rw overlay
 - sysupgrade with fwtool check support

Device profiles are automatically generated with a helper makefile.  Names for
image files, board_names, etc. are changed to try to use basename of kernel dts
file for the specific device.  Names for uboot-sunxi is not touched though.
  

[snip]

I'm OK with what these patches want to achieve. I had several patches 
prepared for similar purposes in sunxi (apart from the new image 
building code), but were never finalized due to responsibilities 
elsewhere, as one of the "obvious reasons" mentioned earlier (by Daniel 
IIRC). Whether you are merging these into trunk before or after your 
release and/or the merge, is obviously at your discretion.


Having said that, if such major target reworks happen, and we seem to be 
geared towards a merge, it would be appreciated if you cc the 
openwrt-devel list so people over there would be aware.


Thanks,
Zoltan H


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH 04/11] build: image.mk: don't install-images for devices not selected

[Yousong Zhou]

On 1 January 2017 at 20:26, Felix Fietkau  wrote:
> On 2016-12-31 19:06, Yousong Zhou wrote:
>> On 1 January 2017 at 01:11, Felix Fietkau  wrote:
>>> On 2016-12-31 18:06, Yousong Zhou wrote:
 This commit tries to fix the following situation

  - CONFIG_TARGET_MULTIPLE_PROFILE is not set
  - CONFIG_TARGET_sunxi_DEVICE_sun7i-a20-cubieboard2=y
  - All other devices are not selected

 The build system will still try to install-images for those other
 devices as PROFILES and PROFILE has value DEVICE_sun7i-a20-cubieboard2

 Signed-off-by: Yousong Zhou 
>>> This is wrong and breaks using generic profiles. Please just set
>>> PROFILES:=  in Device/Default in the sunxi
>>> image makefile.
>>>
>>> - Felix
>>>
>>
>> Am I right that if there is no such generic profile for a target,
>> PROFILES should be set to a non-existent value in Device/Default, just
>> to override what's set in Device/InitProfile?
> Correct, but I'd prefer having a default profile to make it easier for
> users.
>
> - Felix
>

If the default device profile is meant to be used to make a single
image that can run on all device, then in the case of sunxi, it is not
possible at least with regard to uboot.

Or if the default device profile is meant to be selected as the
default just to implicitly enable all other profiles of the same
target/subtarget, then again in the case of sunxi it has the
dependency problem as illustrated above.  Besides, the build system
can already select multiple devices and enable all profiles (devices)
with explicit config symbols.  Can this goal of the default profile be
dropped?

My current understanding is that the profiles/*.mk thing is part of
the old code and is to be replaced with the Device/xxx thing.  Correct
me if I am wrong ;)

The conclusion is that for sunxi at least, I do not know how to make a
default profile or device to make it easier for users.  At the moment
we have the alphabetically first one selected as the default but that
is just a little bit not easy for all other devices' users ;)

yousong

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] LEDE Fails to build

[Magnus Kroken]

Hi Mauro

On 01.01.2017 16.10, Mauro M. wrote:

Collected errors:
 * check_data_file_clashes: Package libustream-polarssl wants to install
file
/net2/router/lede/trunk-ipvs/build_dir/target-mips_24kc_musl-1.1.15/root-ar71xx/lib/libustream-ssl.so

But that file is already provided by package  * libustream-mbedtls
 * opkg_install_cmd: Cannot install package libustream-polarssl.


Try updating all LEDE code as well as all enabled package feeds, and 
updating your configuration (backup, then make defconfig). This is 
probably caused by LEDE and feeds moving to mbed TLS 2.x as default TLS 
library.


If it still fails, run make menuconfig and find out which package 
selects libustream-polarssl. Grepping my tree, cshark (in 
feeds/packages) is the only package that depends on libustream-polarssl 
at this point.


Regards
/Magnus

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] Scripting builds... how to?

[Petr Štetiar]

Philip Prindeville  [2016-12-31 16:12:21]:

Hi,

> cp ../my-saved-config .config
> make defconfig

I use the same steps also.

> to generate the .config file in a completely scripted way, by seeding it with 
> the minimum set of relevant parameters (the deltas) per the steps described 
> here:
> 
> https://wiki.openwrt.org/doc/howto/build
> 
> Is there an equivalent way to generate the kernel config by seeding it with 
> minimum state?

Look at the scripts/diffconfig file for details, probably at the kconfig.pl 
usage.

> I don’t want to save the complete .config because that changes from release 
> to release, so there wouldn’t be any point… all I care about is how I’m 
> differentiating my build from the defaults.

You can just do:

  scripts/diffconfig > ../my-saved-config

it should contain everything needed to build the image.

-- ynezz

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] Scripting builds... how to?

[Sven Roederer]

Am Samstag, 31. Dezember 2016, 16:12:21 CET schrieb Philip Prindeville:
> Hi.
> 
> I wanted to be able to script building images completely.

> Is there an equivalent way to generate the kernel config by seeding it with
> minimum state?
> 
> I don’t want to save the complete .config because that changes from release
> to release, so there wouldn’t be any point… all I care about is how I’m
> differentiating my build from the defaults.
> 

Philip,

maybe you will have a look on the buildscripts for Berlin-Freifunk [1].
We use OpenWrt inside our buildscripts and having a "config"-directory with a 
common config and an additional config for each build.
We use this all to have diferent configurations per architecture and dan even 
build different images with a individual set to packages included.

Sven

[1] - https://github.com/freifunk-berlin/firmware

I think 

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH] lantiq: set the usb clock source

[Hauke Mehrtens]

On 01/01/2017 11:21 AM, Mathias Kresin wrote:
> The clock source is set by the ltq-hcd driver but are not by the
> dwc2 driver. Without having the correct clock set the dwc driver
> fails to reset the usb core and errors out. The values for supported
> lantiq targets are exactly the same as set by the ltq-hcd driver and
> should not cause any regressions.
> 
> Fixes FS#351
> 
> Signed-off-by: Mathias Kresin 
> ---
> 
> Well the code works but is not really a beauty. But I need some input
> to _possibly_ improve the code or at least the commit message.
> 
> Based on the disabled code in the ltq-hcd driver I guess for all
> targets two bits are used to set the clock source.
> 
> I know that on vr9 the bits set to 00 or 11 means "XTAL 36 MHz input
> devide by 3" where 00 is the default value.
> 
> After playing a bit with the bits, I'm the opinion the same applies to
> Danube a well.
> 
> It's kinda strange that for Amazon only one bit is cleared within the
> ltq-hcd driver. It looks more like an error or yet unknown workaround.
> Setting the interface clock bits to 00 (default) does make more sense
> to me. I've changed this in contrast to the ltq-hcd driver but do not
> have any hardware to check this change or the dwc2 at all on Amazon.
> 
> For some reason the usb clock source has already the correct value on
> vr9. I'm not sure if any vr9 board uses a clock source different than
> the default "XTAL 36 MHz input devide by 3". For completeness I tend to
> add the clock source for vr9 as well. Any opinions?
> 
> Albeit we obviously don't have an alien board which need a different
> clock source than the others, setting the clock source to a fixed value
> seams to me a really bad idea. And since it is the second time I had to
> touch the CGU_IFCCR register [0][1] I've somehow the impression we need
> some glue code to set the different clock sources via some kind of glue
> code. I'm not sure what is the best way to do this. Should I add
> something similar to the lantiq,phy-clk-src? Is there any chance that
> this code is accepted upstream or should we consider it as LEDE hack?
> Is the common clock framework maybe the saviour?
> 
> Would anyone with access to the datasheets be so kind to confirm:
> 
> - all lantiq targets are using two bits to set the clock source
> - the meaning of the usbclk bit combinations are the same for all
>   lantiq targets (including 00 == 11)
> - it is safe to set the usb clock to 00 or 11 for Amazon
> 
> If 00 == 11 on Amazon/Danube, the lantiq,ase and lantiq,danube
> conditions can be merged.
> 
> The lantiq,ar9 can be extended to cover vr9 as well.
> 
> [0] https://git.lede-project.org/44cace4dabe186a486d6713de6196bc7cea2228b
> [1] https://git.lede-project.org/d4de9f72f31c4716f78fea8950261a3bdafdbccb

This is copied from the different documentations:

On Danube it looks like this:

USB Clock Source
Clock config is configured to:
00 B Internal, 12 MHz internal
01 B External, from USB XTAL (default)
10 B External/4, from USB XTAL then divided by 4
11 B 12, special internal clock generated from 36 MHz source

Bit 5:4 on reg 0x0018, reset value of this bit is 01 B


On Amazon SE it looks like this:

12 MHz USB Clock Source
Clock config is configured to:
0 B Divider after divider
1 B XTALInput From XTAL only

Bit 5 on reg 0x0018, reset value of this bit is 0 B


On xRX200 (VR9) it looke like this:

USB 12 MHz Clock Source
Clock config is configured to:
00 B 12 MHz XTAL 36 MHz input divide by 3 (default)
01 B 12 MHz XTAL 36 MHz input is directly provided to USB (This is
reserved for running with 12 MHz XTAL)
10 B 12 MHz 12 MHz USB clock derived from PLL0 300 MHz output as
divide by 25 (for 25 MHz XTAL input, this is only valid option)
11 B 12 MHz XTAL 36 MHz input divide by 3

Bit 1:0 on reg 0x0024, reset value of this bit is 00 B

On xRX200 this depends on the confiuration of the CLK_OUT0, CLK_OUT1 and
CLK_OUT3.


Currently I do not have the documentation of the AR9 at hand, will
search for it later.

>  .../0032-lantiq-set-the-usb-clock-source.patch | 52 
> ++
>  ...MIPS-lantiq-danube-initialize-usb-on-boot.patch |  2 +-
>  .../linux/lantiq/patches-4.4/0047-poweroff.patch   |  4 +-
>  3 files changed, 55 insertions(+), 3 deletions(-)
>  create mode 100644 
> target/linux/lantiq/patches-4.4/0032-lantiq-set-the-usb-clock-source.patch
> 
> diff --git 
> a/target/linux/lantiq/patches-4.4/0032-lantiq-set-the-usb-clock-source.patch 
> b/target/linux/lantiq/patches-4.4/0032-lantiq-set-the-usb-clock-source.patch
> new file mode 100644
> index 000..bfc41aa
> --- /dev/null
> +++ 
> b/target/linux/lantiq/patches-4.4/0032-lantiq-set-the-usb-clock-source.patch
> @@ -0,0 +1,52 @@
> +From 6e6569954319ef5f3e8c6a2c56056a90dd3c4ca0 Mon Sep 17 00:00:00 2001
> +From: Mathias Kresin 
> +Date: Sat, 31 Dec 2016 10:46:18 +0100
> +Subject: [PATCH] MIPS: lantiq: set the usb clock source
> +
> +The clock source is set by the ltq-hcd driver but 

Re: [LEDE-DEV] Adding new targets/subtargets

[Weedy]

On 31 December 2016 at 20:23, Philip Prindeville
 wrote:
>
>> On Dec 31, 2016, at 9:32 AM, Yousong Zhou  wrote:
>>
>> On 31 December 2016 at 06:13, Philip Prindeville
>>  wrote:
>>>
>>> I noticed that in Openwrt a lot of the x86 subtargets (alix, geos, net5501) 
>>> had gone away (well, been combined into a generic “geode” image).
>>>
>>> -Philip
>>
>> I can only guess it's very likely for the purpose of saving buildbot
>> resources.  But I never played those subtargets myself and have no
>> idea whether they still work (they should though)
>>
>>yousong
>
> Pruning useful subtargets to solve a buildbot resource shortage seems like 
> taking a sledgehammer to kill a fly.
>
> Why not instead just add a profile attribute like:
>
> BUILDBOT_BUILD_ME:=no
>
> Whether it’s still useful to *build* a subtarget is a different question that 
> whether it’s still useful (from a pedagogical perspective) to *keep* a 
> subtarget in the SCM… and these questions shouldn’t be conflated.
>
> -Philip


If this is going to be the road we travel down (I'm bikeshedding here)
wouldn't a  BUILDBOT_INTERVAL:=daily/3d/7d/14d make more sense?

We have more then a few full on targets that for the most part are
much less popular then say ar71xx.

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] LEDE Fails to build

[Mauro M.]

Hi All,

All the updates from git after r2449 fail to build with the following error:

Configuring zip.
Configuring luci-app-hd-idle.
Configuring ppp-mod-pppoe.
Configuring luci-app-openvpn.
Configuring ipvsadm.
Configuring kmod-ledtrig-netdev.
Collected errors:
 * check_data_file_clashes: Package libustream-polarssl wants to 
install file 
/net2/router/lede/trunk-ipvs/build_dir/target-mips_24kc_musl-1.1.15/root-ar71xx/lib/libustream-ssl.so

But that file is already provided by package  * libustream-mbedtls
 * opkg_install_cmd: Cannot install package libustream-polarssl.
package/Makefile:60: recipe for target 'package/install' failed
make[2]: *** [package/install] Error 255
make[2]: Leaving directory '/net2/router/lede/trunk-ipvs'
package/Makefile:130: recipe for target 
'/net2/router/lede/trunk-ipvs/staging_dir/target-mips_24kc_musl-1.1.15/stamp/.package_install' 
failed
make[1]: *** 
[/net2/router/lede/trunk-ipvs/staging_dir/target-mips_24kc_musl-1.1.15/stamp/.package_install] 
Error 2

make[1]: Leaving directory '/net2/router/lede/trunk-ipvs'
/net2/router/lede/trunk-ipvs/include/toplevel.mk:197: recipe for target 
'world' failed

make: *** [world] Error 2

Is this happening to everyone?

Thanks!

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH 04/11] build: image.mk: don't install-images for devices not selected

[Felix Fietkau]

On 2016-12-31 19:06, Yousong Zhou wrote:
> On 1 January 2017 at 01:11, Felix Fietkau  wrote:
>> On 2016-12-31 18:06, Yousong Zhou wrote:
>>> This commit tries to fix the following situation
>>>
>>>  - CONFIG_TARGET_MULTIPLE_PROFILE is not set
>>>  - CONFIG_TARGET_sunxi_DEVICE_sun7i-a20-cubieboard2=y
>>>  - All other devices are not selected
>>>
>>> The build system will still try to install-images for those other
>>> devices as PROFILES and PROFILE has value DEVICE_sun7i-a20-cubieboard2
>>>
>>> Signed-off-by: Yousong Zhou 
>> This is wrong and breaks using generic profiles. Please just set
>> PROFILES:=  in Device/Default in the sunxi
>> image makefile.
>>
>> - Felix
>>
> 
> Am I right that if there is no such generic profile for a target,
> PROFILES should be set to a non-existent value in Device/Default, just
> to override what's set in Device/InitProfile?
Correct, but I'd prefer having a default profile to make it easier for
users.

- Felix


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] Blackhole routes and other tidbits on the network configuration wiki page

[Alberto Bursi]

On 12/31/2016 11:33 PM, Philip Prindeville wrote:
> I was going over the “Network configuration” page on the wiki and it’s a 
> little thin on routes.  In particular, it implies that for a route you always 
> need interface/target/netmask/gateway… but in the case of type=blackhole, a 
> gateway doesn’t really seem applicable.
>
> So would you have:
>
> config route
>   option interface ‘lan’
>   option target ‘192.168.1.99’
>   option netmask ‘255.255.255.255’
>   option type ‘blackhole'
>
>
> instead?  For that matter, do you really even need the “interface” part?
>
> Who owns that wiki page?  I was trying to figure that out using the wiki 
> itself but couldn’t figure out how.
>
> -Philip
>

There is no "owner", although you can see the people that modified it if 
you click on the little clock icon on the right.

I'm "bobafetthotmail" wiki user, I ported that wiki page more or less 
as-is from OpenWRT wiki.
Since I know little of routing (in LEDE or otherwise) I just gave it its 
own article, splitting it from a larger page with many networking 
topics, but I could not really change it or add anything to it.

If you want to improve it, please register/login in the wiki and do so.

-Alberto
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH] lantiq: set the usb clock source

[Mathias Kresin]

01.01.2017 11:21, Mathias Kresin:

The clock source is set by the ltq-hcd driver but are not by the
dwc2 driver. Without having the correct clock set the dwc driver
fails to reset the usb core and errors out. The values for supported
lantiq targets are exactly the same as set by the ltq-hcd driver and
should not cause any regressions.

Fixes FS#351

Signed-off-by: Mathias Kresin 


Failed to set the correct subject prefix. This one is a RFC.

Mathias

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] [PATCH] lantiq: set the usb clock source

[Mathias Kresin]

The clock source is set by the ltq-hcd driver but are not by the
dwc2 driver. Without having the correct clock set the dwc driver
fails to reset the usb core and errors out. The values for supported
lantiq targets are exactly the same as set by the ltq-hcd driver and
should not cause any regressions.

Fixes FS#351

Signed-off-by: Mathias Kresin 
---

Well the code works but is not really a beauty. But I need some input
to _possibly_ improve the code or at least the commit message.

Based on the disabled code in the ltq-hcd driver I guess for all
targets two bits are used to set the clock source.

I know that on vr9 the bits set to 00 or 11 means "XTAL 36 MHz input
devide by 3" where 00 is the default value.

After playing a bit with the bits, I'm the opinion the same applies to
Danube a well.

It's kinda strange that for Amazon only one bit is cleared within the
ltq-hcd driver. It looks more like an error or yet unknown workaround.
Setting the interface clock bits to 00 (default) does make more sense
to me. I've changed this in contrast to the ltq-hcd driver but do not
have any hardware to check this change or the dwc2 at all on Amazon.

For some reason the usb clock source has already the correct value on
vr9. I'm not sure if any vr9 board uses a clock source different than
the default "XTAL 36 MHz input devide by 3". For completeness I tend to
add the clock source for vr9 as well. Any opinions?

Albeit we obviously don't have an alien board which need a different
clock source than the others, setting the clock source to a fixed value
seams to me a really bad idea. And since it is the second time I had to
touch the CGU_IFCCR register [0][1] I've somehow the impression we need
some glue code to set the different clock sources via some kind of glue
code. I'm not sure what is the best way to do this. Should I add
something similar to the lantiq,phy-clk-src? Is there any chance that
this code is accepted upstream or should we consider it as LEDE hack?
Is the common clock framework maybe the saviour?

Would anyone with access to the datasheets be so kind to confirm:

- all lantiq targets are using two bits to set the clock source
- the meaning of the usbclk bit combinations are the same for all
  lantiq targets (including 00 == 11)
- it is safe to set the usb clock to 00 or 11 for Amazon

If 00 == 11 on Amazon/Danube, the lantiq,ase and lantiq,danube
conditions can be merged.

The lantiq,ar9 can be extended to cover vr9 as well.

[0] https://git.lede-project.org/44cace4dabe186a486d6713de6196bc7cea2228b
[1] https://git.lede-project.org/d4de9f72f31c4716f78fea8950261a3bdafdbccb

 .../0032-lantiq-set-the-usb-clock-source.patch | 52 ++
 ...MIPS-lantiq-danube-initialize-usb-on-boot.patch |  2 +-
 .../linux/lantiq/patches-4.4/0047-poweroff.patch   |  4 +-
 3 files changed, 55 insertions(+), 3 deletions(-)
 create mode 100644 
target/linux/lantiq/patches-4.4/0032-lantiq-set-the-usb-clock-source.patch

diff --git 
a/target/linux/lantiq/patches-4.4/0032-lantiq-set-the-usb-clock-source.patch 
b/target/linux/lantiq/patches-4.4/0032-lantiq-set-the-usb-clock-source.patch
new file mode 100644
index 000..bfc41aa
--- /dev/null
+++ b/target/linux/lantiq/patches-4.4/0032-lantiq-set-the-usb-clock-source.patch
@@ -0,0 +1,52 @@
+From 6e6569954319ef5f3e8c6a2c56056a90dd3c4ca0 Mon Sep 17 00:00:00 2001
+From: Mathias Kresin 
+Date: Sat, 31 Dec 2016 10:46:18 +0100
+Subject: [PATCH] MIPS: lantiq: set the usb clock source
+
+The clock source is set by the ltq-hcd driver but are not by the
+dwc2 driver. Without having the correct clock set the dwc driver
+fails to reset the usb core and errors out. The values for supported
+lantiq targets are exactly the same as set by the ltq-hcd driver and
+should not cause any regressions.
+
+Signed-off-by: Mathias Kresin 
+---
+
+ arch/mips/lantiq/xway/reset.c | 14 ++
+ 1 file changed, 14 insertions(+)
+
+--- a/arch/mips/lantiq/xway/reset.c
 b/arch/mips/lantiq/xway/reset.c
+@@ -95,6 +95,14 @@
+ #define PMU_USB0_PBIT(0)
+ #define PMU_USB1_PBIT(26)
+ 
++/* USB clock */
++#define CGU_IFCCR 0x0018
++#define CGU_USBCLK_MASK   0x3
++#define CGU_USBCLK_DEFAULT0x0
++#define CGU_USBCLK_DIRECT 0x1
++#define CGU_USBCLK_PPL0   0x2
++#define CGU_USBCLK_XTAL   0x3
++
+ /* remapped base addr of the reset control unit */
+ static void __iomem *ltq_rcu_membase;
+ static struct device_node *ltq_rcu_np;
+@@ -317,6 +325,17 @@ static void ltq_usb_init(void)
+   ltq_rcu_w32(ltq_rcu_r32(RCU_CFG1A) | BIT(0), RCU_CFG1A);
+   ltq_rcu_w32(ltq_rcu_r32(RCU_CFG1B) | BIT(0), RCU_CFG1B);
+ 
++  /* set usb clock source */
++  if (of_machine_is_compatible("lantiq,ase"))
++  ltq_cgu_w32((ltq_cgu_r32(CGU_IFCCR) & ~(CGU_USBCLK_MASK << 4))
++  | (CGU_USBCLK_DEFAULT << 4), CGU_IFCCR);
++  else if