Re: [LEDE-DEV] [PATCH v2 0/4] sunxi: rework image build and sysupgrade support
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
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..
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..
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
> 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 04/11] build: image.mk: don't install-images for devices not selected
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. > 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. - Felix ___ 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
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
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
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?
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?
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
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 are not by the > +dwc2 driver. Wit
Re: [LEDE-DEV] Adding new targets/subtargets
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
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
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
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
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
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 (of_machine_is_compatible("lantiq,danube")) ++ ltq_cgu_w32(