Re: [LEDE-DEV] NAND JFFS2 question

[Mathias Kresin]

08.03.2017 23:01, hams...@freenet.de:

Hi!

I currently work to assembly a fullimage.img for the Easybox 904xdsl.
Actually there are some differences to upstream made by the vendor.
I take over some code and now I'm able to update the firmware, or at
least the kernel via the recovery method within the uboot.

As I wrote, the kernel and also the rootfs is flashed without errors.
When I try to boot the image, or mount the partition it is not possible
due some strange ECC errors.

So I did some investigations: When I boot into the target system
via sdcard as rootfs and then I perform a


 flash_eraseall /dev/mtd1
 nand_write /dev/mtd1 /root/image.jffs2

 mkdir /tmp/disk
 mount -t jffs2 /dev/mtdblock1 /tmp/disk




Using jffs2 on NAND flash isn't the best idea. jffs2 doesn't work that 
good with NAND flash. Use ubi instead!


I worked on the Easybox 904xdsl as well but stopped after realising that:

- Arcadian decided to use their own bad block table patterns instead of 
the ones which are used by the kernel and an unmodified u-boots. Means a 
kernel patch is required just for this board.


- to support the wireless a complete protocol needs to be reverse 
engineered and a lot of missing code needs to be added to the rt2x00 driver


The rt3883 wireless chip of the Easybox 904xdsl is not a usual wireless 
chip, it is a full SoC which is supported as own suptarget in LEDE 
(ramips/rt3883). In case of the 904 a complete realtime operating system 
is uploaded/runs on the rt3883 instead of a "normal" Operating System 
like OpenWrt/LEDE. Since it is a full SoC it has subsystems like PCI and 
so on. The rt5392 wireless is attached via PCI to the rt3883 SoC.


The internal ethernet of the rt3883 SoC is connected to the internal 
lantiq switch via MDIO/RGMII. The whole communication and configuration 
of the rt3883/rt5392 is done via a proprietary protocol, which is based 
on ethernet frames. The way the protocol really works is unknown and 
there is no support for that protocol in the rt2x00 wireless driver.


Vitaly Chekryzhev send patch to add MDIO support to the rtl8367b used by 
the 904 [0]. This patch wasn't merged since it caused issues. My last 
update about this was that he is going to fix the issues and will send a 
new patch.


Long story short, I got the following working:

- LAN
- ethernet WAN (the DSL port is ethernet and dsl at the same time)
- LEDs
- Buttons
- Flash without bad block support
- usb port on the back
- ram boot u-boot for recovery

You can find my code at https://github.com/mkresin/lede/tree/904xdsl.

Feel free to use it or to rebase your work on it. Would be nice if you 
publish what you have so far as well.


Supporting the build in display should be possible. The driver for the 
display is in the staging section of the kernel for a while now [1].


Mathias

[0] https://github.com/lede-project/source/pull/537
[1] 
https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/drivers/staging/fbtft?h=linux-4.4.y


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

Re: [LEDE-DEV] QCA Dakota support

[John Crispin]

Hi Matthew,

can you point me at the tree to use on codeaurora ? i am also looking 
for the AP145 dts file. this is ipq8062 based


John


On 08/03/17 15:49, Matthew McClintock wrote:

Most of the support for the SoC should be in place, the various Dakota
boards dk0{1,4,7}-c{1,2,3,4} are very similar. You could look at the
device tree's on codeaurora.org to compare the differences from a
supported platform and this variant.

-M

On Wed, Mar 8, 2017 at 2:47 AM, K.Mani  wrote:

I have a target board based on IPQ40xx, I want to port LEDE on it.
Does LEDE has support for the following type:

Model: Qualcomm Technologies, Inc. IPQ40xx/AP-DK04.1-C2
Compatible: qcom,ipq40xx-apdk04.1qcom,ipq40xx
SF: MX25L25635E

Thanks
Mani

___
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 mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] using sata-port-specific led triggers

[Mathias Kresin]

08.03.2017 22:59, Alberto Bursi:

Hi, I'm trying to use the functionality added by this patch [1] (it
should generate different led triggers for each Sata port) for a few
kirkwood device that have multiple Sata Leds.

This patch is currently used only by some oxnas NAS devices, that seem
to have not been fully ported to device tree.

After reading its description and the oxnas files I have added

CONFIG_ARCH_WANT_LIBATA_LEDS=y
CONFIG_ATA_LEDS=y

to the target/linux/kirkwood/config-4.4

but after I made a distclean, recompiled and booted the initramfs image,
I can't see any sata trigger
---
root@LEDE:/# cat
/sys/devices/platform/gpio-leds/leds/nsa310:green:esata/trigger
[none] nand-disk timer default-on netdev usbport
---

Does anyone have some ideas on why this does not work?

[1]
https://git.lede-project.org/?p=source.git;a=blob;f=target/linux/generic/patches-4.9/834-ledtrig-libata.patch


In my opinion it would makes more sense to switch kirkwood to kernel 4.9 
and use the upstream LED Disk Trigger [0][1] which was introduced with 
kernel 4.8.


Mathias


[0] https://git.lede-project.org/3d0bd150565767f395eae333bcbca7bbe89edf48
[1] https://git.lede-project.org/2261c9cc7715e6d590952989ebef96e08cc019fc

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

[LEDE-DEV] Using Conflicts:

[Philip Prindeville]

Is there a reason we don’t use Conflicts: information from the packaging to 
stop overlapping installs from being selected when doing a build?

I understand that the buildbots build everything…  but it should be possible to 
differentiate between ’y’ and ‘m’ and detect to packages providing the same 
paths as both being combined into the same image/ISO (for example, below, 
/sbin/insmod being provided by “kmod” and “ubox” both)?

Right?  Or am I missing something?

-Philip


Collected errors:
 * check_data_file_clashes: Package bridge wants to install file 
/home/philipp/bertram/lede/build_dir/target-x86_64_westmere_musl_powercode-bmu/root-x86/usr/sbin/brctl
But that file is already provided by package  * busybox
 * opkg_install_cmd: Cannot install package bridge.
 * check_data_file_clashes: Package isc-dhcp-server-ipv4 wants to install file 
/home/philipp/bertram/lede/build_dir/target-x86_64_westmere_musl_powercode-bmu/root-x86/etc/init.d/dhcpd
But that file is already provided by package  * isc-dhcp-server-ipv6
 * check_data_file_clashes: Package isc-dhcp-server-ipv4 wants to install file 
/home/philipp/bertram/lede/build_dir/target-x86_64_westmere_musl_powercode-bmu/root-x86/usr/sbin/dhcpd
But that file is already provided by package  * isc-dhcp-server-ipv6
 * opkg_install_cmd: Cannot install package isc-dhcp-server-ipv4.
 * check_data_file_clashes: Package kmod wants to install file 
/home/philipp/bertram/lede/build_dir/target-x86_64_westmere_musl_powercode-bmu/root-x86/sbin/insmod
But that file is already provided by package  * ubox
 * check_data_file_clashes: Package kmod wants to install file 
/home/philipp/bertram/lede/build_dir/target-x86_64_westmere_musl_powercode-bmu/root-x86/sbin/lsmod
But that file is already provided by package  * ubox
 * check_data_file_clashes: Package kmod wants to install file 
/home/philipp/bertram/lede/build_dir/target-x86_64_westmere_musl_powercode-bmu/root-x86/sbin/modinfo
But that file is already provided by package  * ubox
 * check_data_file_clashes: Package kmod wants to install file 
/home/philipp/bertram/lede/build_dir/target-x86_64_westmere_musl_powercode-bmu/root-x86/sbin/modprobe
But that file is already provided by package  * ubox
 * check_data_file_clashes: Package kmod wants to install file 
/home/philipp/bertram/lede/build_dir/target-x86_64_westmere_musl_powercode-bmu/root-x86/sbin/rmmod
But that file is already provided by package  * ubox
 * opkg_install_cmd: Cannot install package kmod.
 * check_data_file_clashes: Package shadow-passwd wants to install file 
/home/philipp/bertram/lede/build_dir/target-x86_64_westmere_musl_powercode-bmu/root-x86/usr/bin/passwd
But that file is already provided by package  * busybox
 * opkg_install_cmd: Cannot install package shadow-passwd.
 * check_data_file_clashes: Package shadow-passwd wants to install file 
/home/philipp/bertram/lede/build_dir/target-x86_64_westmere_musl_powercode-bmu/root-x86/usr/bin/passwd
But that file is already provided by package  * busybox
 * opkg_install_cmd: Cannot install package shadow.
 * check_data_file_clashes: Package powercode-misc wants to install file 
/home/philipp/bertram/lede/build_dir/target-x86_64_westmere_musl_powercode-bmu/root-x86/etc/banner
But that file is already provided by package  * base-files
 * check_data_file_clashes: Package powercode-misc wants to install file 
/home/philipp/bertram/lede/build_dir/target-x86_64_westmere_musl_powercode-bmu/root-x86/etc/collectd.conf
But that file is already provided by package  * collectd
 * check_data_file_clashes: Package powercode-misc wants to install file 
/home/philipp/bertram/lede/build_dir/target-x86_64_westmere_musl_powercode-bmu/root-x86/etc/config/snmpd
But that file is already provided by package  * snmpd
 * check_data_file_clashes: Package powercode-misc wants to install file 
/home/philipp/bertram/lede/build_dir/target-x86_64_westmere_musl_powercode-bmu/root-x86/etc/inittab
But that file is already provided by package  * base-files
 * check_data_file_clashes: Package powercode-misc wants to install file 
/home/philipp/bertram/lede/build_dir/target-x86_64_westmere_musl_powercode-bmu/root-x86/etc/lighttpd/lighttpd.conf
But that file is already provided by package  * lighttpd
 * check_data_file_clashes: Package powercode-misc wants to install file 
/home/philipp/bertram/lede/build_dir/target-x86_64_westmere_musl_powercode-bmu/root-x86/etc/php.ini
But that file is already provided by package  * php7
 * check_data_file_clashes: Package powercode-misc wants to install file 
/home/philipp/bertram/lede/build_dir/target-x86_64_westmere_musl_powercode-bmu/root-x86/etc/rc.local
But that file is already provided by package  * base-files
 * check_data_file_clashes: Package powercode-misc wants to install file 

Re: [LEDE-DEV] Support for more than a single overlay, which is selected at boot time

[Philip Prindeville]

> On Mar 7, 2017, at 6:15 AM, Jurgen Van Ham  wrote:
> 
> Hi all,
> 
> I want to support multiple (currently just two) configurations on a
> single device. One of these configurations is chosen at boot time.
> Instead of saving and restoring the configuration each time, I came up
> with a solution that relies on extending the overlay by splitting it
> into two banks. There can be more than two, but I only need two called
> 'bank_0' and 'bank_1'
> 
> This relies on splitting the overlay file system into two (or more)
> different banks, which are implemented as directories in the root of
> the overlay file system. Separate file systems would require a
> decision how to split the size of the single overlay into two overlays
> that do not always have the same size.

Um…. maybe I’m missing something but you could also have:

/etc/config1/
/etc/config2/

and have /etc/config/ be a symlink to ../config1 or ../config2.

Or is that too simple to possibly work?

-Philip


> 
> Until now the writable /overlay (jffs2 or other) partition is mounted
> as the upperdir over the /rom squashfs partition as its lowerdir.
> Instead, I consider to replace this /overlay mount by the subdirs
> /overlay/bank_1 or /overlay_bank_2 by modifying the code of mount_root
> from the fstools package.
> 
> The mount_root program read the environment variable 'OVERLAY_BANK'
> that is set by modifying two files:  /lib/preinit/80_mount_root' and
> '/etc/init.d/done'  base-files/files. Using an environment variable
> keeps the selection of the overlay bank in scripts. The alternative
> would be require to integrate the selection of the bank at boot time
> into the mount_root program, but that ties the implementation to
> specific hardware.
> 
> At a high level, I modified the mount_root program to use
> '/overlay/${OVERLAY_BANK}/' instead of '/overlay/'. When /overlay does
> not yet contain the directory ${OVERLAY_BANK}, it creates this
> directory.
> 
> I can imagine that this can also be useful to test new firmware and
> make it possible to revert the upgrade by moving back to the previous
> overlay bank.
> 
> Before polishing my experimental implementation and sending it as a
> patch to the mailinglist, I'd like to know whether someone else had to
> deal with such requirement, or sees different ways to create a device
> that can boot with one out of several configurations.
> 
> Regards,
> 
> Jurgen


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

Re: [LEDE-DEV] Supporting crashdumps w/ kexec

[Luiz Angelo Daros de Luca]

1st: Is where does /boot get unmounted, and is there an easy way to
keep it around a bit longer, at least until the init.d scripts have
finished running?
A: /boot (aka sda1) is never mounted on x86/x86_64. It could but it is
simply unnecessary. grub is the only one that reads it (for loading
grub confs and the kernel)

2nd: Or what if I want to configure an extra menuentry in /boot/grub/grub.cfg?
A: If you need to add extra kernel parameters, you simply need to
mount sda1 somewhere (like /boot) and do as you would in a normal
linux. You can edit grub conf there.

3rd: how does a regular package force these kernel options?
A: you can depend on a kernel config just like you depend on any other
kernel config. CONFIG_KERNEL_XXX becomes CONFIG_XXX in kernel config.
See procd makefile for reference. However, note that any selecting the
package is enough to enable the config for any kernel compiled, even
those that do not install your package.

4th:  Is there an easy way to have the image include a 3rd partition
for collecting crash dumps?
A: your kexec package could configure the mounting. I don't know where
is the best place for mounting, if /etc/fstab, /etc/config/fstab or
mounting with a custom /etc/init.d/kexec service

5th: what would be involved in mashing /dev/sda1 into the root unionfs?
A: kernel could live inside rootfs. There is even an existing menu
option (TARGET_ROOTFS_INCLUDE_KERNEL) for it (but not for x86). I
guess grub2 can read files both from squashfs and ext4. Grub just need
to look for the kernel there (you need to change the target partition
from sda1 to sda2) and you must put the kernel inside sda2 and not
sda1 during image build. The only drawback is that even if you change
the kernel (writing to overlayfs), grub would still read from pristine
squashfs. I don't know if this is really a problem because in
LEDE/OpenWRT, you normally change kernel reflashing your system and
not updating kernel.

I did some code (CC era) in order to put the kernel inside rootfs. It
was used for a A/B upgrade strategy. grub conf was changed to boot
either sda2 or sda3 rootfs. sysupgade could replace only the other
rootfs partition or the whole system (boot+rootfs). It still misses
some kind of hardware watchdog (I used a human watchdog). If there is
interest for this particular A/B image solution (only for x86/x86_64
and no watchdog), I can spend some time to bring it to LEDE trunk,

Regards,

---
 Luiz Angelo Daros de Luca, Me.
luizl...@gmail.com

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

Re: [LEDE-DEV] [RFC] sysntpd: restore support for peer-less (standalone) mode

[Piotr Dymacz]

Hello Philip,

On 09.03.2017 00:40, Philip Prindeville wrote:



On Mar 6, 2017, at 3:20 PM, Piotr Dymacz  wrote:

ntpd from Busybox supports peer-less (standalone) mode when it's
started with option -l and without any peer provided with option
-p. In this mode ntpd uses local time as reference and acts as
stratum 1 server.

This mode can be used in isolated networks, where Internet access
and/or other NTP server/s are not available, but the device has
some other way of getting correct time, like e.g. GPS (ugps
supports setting local time by default).



It’s not enough to have your clock set to the correct time initially:
you also need to assure the accuracy of your clock as time goes by,
i.e. ensuring that it’s not running too fast or head or too slow
behind.


Fully agree.


All clocks will have some inherent inaccuracy (due to thermal noise,
age, inconsistent power, etc).  But comparing them regularly to other
clocks (i.e. peers or servers) allows you to understand how your own
clock is behaving and to adjust it (i.e. “discipline it”)
accordingly.


Agree.


I don’t think that lying about the accuracy of your clock by
declaring it stratum 1 is a good thing.

At least “fudge” the local clock and downgrade its stratum (however
busybox does that).


This is only an optional, already included "feature" of Busybox ntpd 
applet (if it's built with support for server mode/-l option which is 
true in our case), which was just disabled in our sysntpd init script, 
probably by a mistake. Related Busybox change is here: [1].


By default, we use ntpd in client-only mode, with our upstream servers 
listed with -p option.


As far as I can see in code [2], there is no way to change default 
stratum value for for this "standalone" mode, but it was discussed on 
Busybox mailing list: [3].


[1] 
https://git.busybox.net/busybox/commit/?id=d678257c26e0993efc48ac4433d153e1e9dfc954


[2] https://git.busybox.net/busybox/tree/networking/ntpd.c?h=1_26_stable

[3] http://lists.busybox.net/pipermail/busybox/2010-October/073518.html

--
Cheers,
Piotr



Support for this mode was incorrectly disabled/removed in:
1527f96ca6e196fa17c96fdb3ae520158fa5943f

Signed-off-by: Piotr Dymacz  ---
package/utils/busybox/files/sysntpd | 2 +- 1 file changed, 1
insertion(+), 1 deletion(-)

diff --git a/package/utils/busybox/files/sysntpd
b/package/utils/busybox/files/sysntpd index 98260be..e693e40
100755 --- a/package/utils/busybox/files/sysntpd +++
b/package/utils/busybox/files/sysntpd @@ -45,7 +45,7 @@
start_service() {

[ $use_dhcp = 1 ] && get_dhcp_ntp_servers "$dhcp_interface"

-   [ -z "$server" ] && return +  [ -z "$server" -a "$enable_server" =
"0" ] && return

procd_open_instance procd_set_param command "$PROG" -n -N -- 2.7.4


___ 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

Re: [LEDE-DEV] [RFC] sysntpd: restore support for peer-less (standalone) mode

[Philip Prindeville]

> On Mar 6, 2017, at 3:20 PM, Piotr Dymacz  wrote:
> 
> ntpd from Busybox supports peer-less (standalone) mode when it's started
> with option -l and without any peer provided with option -p. In this
> mode ntpd uses local time as reference and acts as stratum 1 server.
> 
> This mode can be used in isolated networks, where Internet access and/or
> other NTP server/s are not available, but the device has some other way
> of getting correct time, like e.g. GPS (ugps supports setting local time
> by default).


It’s not enough to have your clock set to the correct time initially: you also 
need to assure the accuracy of your clock as time goes by, i.e. ensuring that 
it’s not running too fast or head or too slow behind.

All clocks will have some inherent inaccuracy (due to thermal noise, age, 
inconsistent power, etc).  But comparing them regularly to other clocks (i.e. 
peers or servers) allows you to understand how your own clock is behaving and 
to adjust it (i.e. “discipline it”) accordingly.

I don’t think that lying about the accuracy of your clock by declaring it 
stratum 1 is a good thing.

At least “fudge” the local clock and downgrade its stratum (however busybox 
does that).



> 
> Support for this mode was incorrectly disabled/removed in:
> 1527f96ca6e196fa17c96fdb3ae520158fa5943f
> 
> Signed-off-by: Piotr Dymacz 
> ---
> package/utils/busybox/files/sysntpd | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/package/utils/busybox/files/sysntpd 
> b/package/utils/busybox/files/sysntpd
> index 98260be..e693e40 100755
> --- a/package/utils/busybox/files/sysntpd
> +++ b/package/utils/busybox/files/sysntpd
> @@ -45,7 +45,7 @@ start_service() {
> 
>   [ $use_dhcp = 1 ] && get_dhcp_ntp_servers "$dhcp_interface"
> 
> - [ -z "$server" ] && return
> + [ -z "$server" -a "$enable_server" = "0" ] && return
> 
>   procd_open_instance
>   procd_set_param command "$PROG" -n -N
> -- 
> 2.7.4
> 
> 
> ___
> 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

Re: [LEDE-DEV] Supporting crashdumps w/ kexec

[Philip Prindeville]

> On Mar 8, 2017, at 10:23 AM, David Woodhouse  wrote:
> 
> On Wed, 2017-03-08 at 10:20 -0700, Philip Prindeville wrote:
>> 
>> Then…  grub reads the raw file system? 
> 
> Well, grub has to load the kernel before the kernel is running….


So, what would be involved in mashing /dev/sda1 into the root unionfs?

I’m looking at /lib/functions/preinit.sh trying to understand the delta to get 
this to happen, but it’s a little voodoo to me.

I’m thinking that the ramoverlay stuff in preinit.sh along with 
/lib/preinit/20_check_iso is similar to what we want to do.  Crispin?  Daniel?  
Felix?  Florian? Can you provide some guidance here, please?

-Philip


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

Re: [LEDE-DEV] using sata-port-specific led triggers

[Daniel Golle]

Hi Alberto,

On Wed, Mar 08, 2017 at 09:59:10PM +, Alberto Bursi wrote:
> Hi, I'm trying to use the functionality added by this patch [1] (it 
> should generate different led triggers for each Sata port) for a few 
> kirkwood device that have multiple Sata Leds.
> 
> This patch is currently used only by some oxnas NAS devices, that seem 
> to have not been fully ported to device tree.
> 
> After reading its description and the oxnas files I have added
> 
> CONFIG_ARCH_WANT_LIBATA_LEDS=y
> CONFIG_ATA_LEDS=y
> 
> to the target/linux/kirkwood/config-4.4
> 
> but after I made a distclean, recompiled and booted the initramfs image, 
> I can't see any sata trigger
> ---
> root@LEDE:/# cat 
> /sys/devices/platform/gpio-leds/leds/nsa310:green:esata/trigger
> [none] nand-disk timer default-on netdev usbport
> ---
> 
> Does anyone have some ideas on why this does not work?

The ARCH_WANT_LIBATA_LEDS is a hidden symbol which needs to be selected
by the mach code in the kernel. I did this to minimize the risk of the
ledtrig code being included by accident (because it can hurt
performance, at least in theory. In practise in turned out that it
doesn't).
Try adding this patch to target/linux/kirkwood/patches-4.4 in addition
to the changes in target/linux/kirkwood/config-4.4:

--- a/arch/arm/mach-mvebu/Kconfig   2016-12-29 02:45:26.510509646 +0100
+++ b/arch/arm/mach-mvebu/Kconfig   2017-03-08 23:50:16.924096508 +0100
@@ -117,6 +117,7 @@
 config MACH_KIRKWOOD
bool "Marvell Kirkwood boards"
depends on ARCH_MULTI_V5
+   select ARCH_WANT_LIBATA_LEDS
select CPU_FEROCEON
select GPIOLIB
select KIRKWOOD_CLK
---

> 
> [1] 
> https://git.lede-project.org/?p=source.git;a=blob;f=target/linux/generic/patches-4.9/834-ledtrig-libata.patch
> 
> -Alberto
> ___
> 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] NAND JFFS2 question

[hamsi2k]

Hi!

I currently work to assembly a fullimage.img for the Easybox 904xdsl.
Actually there are some differences to upstream made by the vendor.
I take over some code and now I'm able to update the firmware, or at
least the kernel via the recovery method within the uboot.

As I wrote, the kernel and also the rootfs is flashed without errors.
When I try to boot the image, or mount the partition it is not possible
due some strange ECC errors.

So I did some investigations: When I boot into the target system
via sdcard as rootfs and then I perform a


 flash_eraseall /dev/mtd1
 nand_write /dev/mtd1 /root/image.jffs2

 mkdir /tmp/disk
 mount -t jffs2 /dev/mtdblock1 /tmp/disk


The parition is mounted as expected.

When I perform a manual update within the u-boot cmdline
(mostly the same as the automated update mechanismn does):


Bytes transferred = 23334912 (1641000 hex)
VR9 # nand erase $(f_rootfs_addr) $(f_rootfs_size) clean

NAND erase: device 0 offset 0x0004, size 0x03c0
Erasing at 0x3c2 -- 100% complete. Cleanmarker written at 0x3c2.
OK

VR9 # nand write.jffs2 $(loadaddr) $(f_rootfs_addr) $(filesize)

NAND write: device 0 offset 0x0004, size 0x01641000
 0x1641000 bytes written: OK
VR9 #


After that, I tried to mount the image, I got errors, errors and errors (and 
errors).

root@LEDE:/# mount -t jffs2 /dev/mtdblock1 /tmp/disk/1 /tmp/disk/
[  131.607779] __nand_correct_data: uncorrectable ECC error
[  131.611745] jffs2: mtd->read(0x100 bytes from 0x0) returned ECC error
[  131.618502] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found 
at 0x0008: 0x instead
[  131.627858] jffs2: Empty flash at 0x000c ends at 0x0010
[  131.633824] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found 
at 0x0018: 0x instead
[  131.643704] __nand_correct_data: uncorrectable ECC error


It must have something to do with the jffs-format when erasing the image.
( clean flag of "nand erase $(f_rootfs_addr) $(f_rootfs_size) clean" )

If I dump the first block after flashing the image, it looks completely
different from the source file. If I erase without the clean flag and flash
the file - it looks the same. It is so weird :-(

Maybe someone has an explanation for this?

Thanks,
Quallenauge





---
https://email.freenet.de/emig/index.html?utm_medium=Text_source=Footersatz_campaign=Footersatz_Sicherheit170207=e990699_content=Text
 Wir garantieren Ihnen verschlüsselte Datenübertragung & Datenspeicherung auf 
deutschen Servern - E-Mail made in Germany!


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

[LEDE-DEV] using sata-port-specific led triggers

[Alberto Bursi]

Hi, I'm trying to use the functionality added by this patch [1] (it 
should generate different led triggers for each Sata port) for a few 
kirkwood device that have multiple Sata Leds.

This patch is currently used only by some oxnas NAS devices, that seem 
to have not been fully ported to device tree.

After reading its description and the oxnas files I have added

CONFIG_ARCH_WANT_LIBATA_LEDS=y
CONFIG_ATA_LEDS=y

to the target/linux/kirkwood/config-4.4

but after I made a distclean, recompiled and booted the initramfs image, 
I can't see any sata trigger
---
root@LEDE:/# cat 
/sys/devices/platform/gpio-leds/leds/nsa310:green:esata/trigger
[none] nand-disk timer default-on netdev usbport
---

Does anyone have some ideas on why this does not work?

[1] 
https://git.lede-project.org/?p=source.git;a=blob;f=target/linux/generic/patches-4.9/834-ledtrig-libata.patch

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

Re: [LEDE-DEV] [RFC] au1000: drop support

[Florian Fainelli]

On 03/08/2017 03:19 AM, Bastian Bittorf wrote:
> * John Crispin  [26.02.2017 20:20]:
>> ok, send your v4.9 series when it is ready.
> 
> after some trial and error: the (ram-)kernel boots without issues,
> but flashing is not possible, because we have only 0x2c kernel
> partition size, which is 44 blocks and ~2816 kilobytes. Our kernel
> is around 3,3mb...ofcourse i can reduce the size, is that an option
> for that target?

Is that already a compressed kernel, seems like you could easily get it
down to 1-2MiB with compression.
-- 
Florian

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

Re: [LEDE-DEV] Supporting crashdumps w/ kexec

[David Woodhouse]

On Wed, 2017-03-08 at 10:20 -0700, Philip Prindeville wrote:
> 
> Then…  grub reads the raw file system? 

Well, grub has to load the kernel before the kernel is running


smime.p7s
Description: S/MIME cryptographic signature
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] Supporting crashdumps w/ kexec

[Philip Prindeville]

> On Mar 8, 2017, at 1:12 AM, David Woodhouse  wrote:
> 
> On Tue, 2017-03-07 at 17:40 -0700, Philip Prindeville wrote:
>> 
>> First, obviously, is that kexec needs access to the boot partition to
>> reuse the kernel (since most of our architectures support relocatable
>> images, there’s no reason that the system kernel and the crash dump
>> kernel can’t be one in the same).  Is where does /boot get unmounted,
>> and is there an easy way to keep it around a bit longer, at least
>> until the init.d scripts have finished running?
> 
> Hm, /boot doesn't ever get mounted at all, does it?


Then…  grub reads the raw file system?  Hmm…  Okay, that would explain why I 
couldn’t find references to /boot in preinit, etc.

What do I do to make /boot be mounted then?

Thanks,

-Philip


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

[LEDE-DEV] phy distance error (ath5k atleast)

[Denis Periša]

Hi all,

I seem to have all weird problems, sorry for that.

If I do `iw phy phy0 set distance 300` or anything less than 500 it
seems that it's ok, hostapd runs, I have dev in the air as access
point.. only.. association is denied.. it's just like rejected.. Lost
whole day until I dissected this.

Could there be some error on `iw` so it doesen't allow this in first
place? or is this ath5k specific? I cannot test atm with other cards
but I think I had ath9k with same issue and I think I even tried
rt61pci

I presume I'm in wrong place but, can someone test himself, maybe
direct me more?

Thank you!

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

Re: [LEDE-DEV] [RFC] au1000: drop support

[Bastian Bittorf]

* John Crispin  [26.02.2017 20:20]:
> ok, send your v4.9 series when it is ready.

after some trial and error: the (ram-)kernel boots without issues,
but flashing is not possible, because we have only 0x2c kernel
partition size, which is 44 blocks and ~2816 kilobytes. Our kernel
is around 3,3mb...ofcourse i can reduce the size, is that an option
for that target?

bye, bastian

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

Re: [LEDE-DEV] [RFC] sysntpd: restore support for peer-less (standalone) mode

[Jo-Philipp Wich]

On 03/06/2017 11:20 PM, Piotr Dymacz wrote:
> ntpd from Busybox supports peer-less (standalone) mode when it's started
> with option -l and without any peer provided with option -p. In this
> mode ntpd uses local time as reference and acts as stratum 1 server.
> 
> This mode can be used in isolated networks, where Internet access and/or
> other NTP server/s are not available, but the device has some other way
> of getting correct time, like e.g. GPS (ugps supports setting local time
> by default).
> 
> Support for this mode was incorrectly disabled/removed in:
> 1527f96ca6e196fa17c96fdb3ae520158fa5943f
> 
> Signed-off-by: Piotr Dymacz 

Acked-by: Jo-Philipp Wich 

> ---
>  package/utils/busybox/files/sysntpd | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/package/utils/busybox/files/sysntpd 
> b/package/utils/busybox/files/sysntpd
> index 98260be..e693e40 100755
> --- a/package/utils/busybox/files/sysntpd
> +++ b/package/utils/busybox/files/sysntpd
> @@ -45,7 +45,7 @@ start_service() {
>  
>   [ $use_dhcp = 1 ] && get_dhcp_ntp_servers "$dhcp_interface"
>  
> - [ -z "$server" ] && return
> + [ -z "$server" -a "$enable_server" = "0" ] && return
>  
>   procd_open_instance
>   procd_set_param command "$PROG" -n -N
> 


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

[LEDE-DEV] QCA Dakota support

[K.Mani]

I have a target board based on IPQ40xx, I want to port LEDE on it.
Does LEDE has support for the following type:

Model: Qualcomm Technologies, Inc. IPQ40xx/AP-DK04.1-C2
Compatible: qcom,ipq40xx-apdk04.1qcom,ipq40xx
SF: MX25L25635E

Thanks
Mani

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

Re: [LEDE-DEV] [OpenWrt-Devel] [PATCH 4/8] caldata-utils: new package to manipulate ath10k

[Sven Eckelmann]

On Donnerstag, 31. März 2016 19:48:20 CET Adrian Panella wrote:
> >From df9a676bb3ba225f0fd6621dbaeec945baf3153d Mon Sep 17 00:00:00 2001
> From: Adrian Panella 
> Date: Wed, 30 Mar 2016 23:31:06 -0600
> Subject: [PATCH 12/15] caldata-utils: new package to manipulate ath10k
>   calibration data
> 
> Signed-off-by: Adrian Panella 
> ---
>   package/utils/caldata-utils/Makefile  |  60 +
>   package/utils/caldata-utils/src/Makefile  |   8 ++
>   package/utils/caldata-utils/src/caldata.c | 213 
> ++
>   package/utils/caldata-utils/src/caldata.h |  42 ++
>   package/utils/caldata-utils/src/utils.c   |  72 ++
>   5 files changed, 395 insertions(+)
>   create mode 100644 package/utils/caldata-utils/Makefile
>   create mode 100644 package/utils/caldata-utils/src/Makefile
>   create mode 100644 package/utils/caldata-utils/src/caldata.c
>   create mode 100644 package/utils/caldata-utils/src/caldata.h
>   create mode 100644 package/utils/caldata-utils/src/utils.c

I know that the patch submitted here is in a broken state. But was there any
decision made what will be done about this problem in general?

This will become a problem again on IPQ4019 when somebody must patch the mac 
address in the pre-cal data. The OTP firmware binary of ath10k will simply 
reject its content when the checksum in the pre-cal data is incorrect.

This reject will happen when the PARAM_FLASH_SECTION_ALL parameter is sent to 
the OTP [1] (step 4). Instead it will then use the boarddata from board-2.bin 
which was send to the device in step 3. It is then missing most calibration 
data which is specific to this single board.

Kind regards,
Sven

[1] 
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=3d9195ea19e4854d7daa11688b01905e244aead9

signature.asc
Description: This is a digitally signed message part.
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] Supporting crashdumps w/ kexec

[David Woodhouse]

On Tue, 2017-03-07 at 17:40 -0700, Philip Prindeville wrote:
> 
> First, obviously, is that kexec needs access to the boot partition to
> reuse the kernel (since most of our architectures support relocatable
> images, there’s no reason that the system kernel and the crash dump
> kernel can’t be one in the same).  Is where does /boot get unmounted,
> and is there an easy way to keep it around a bit longer, at least
> until the init.d scripts have finished running?

Hm, /boot doesn't ever get mounted at all, does it?

smime.p7s
Description: S/MIME cryptographic signature
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev