Re: [LEDE-DEV] Drumming up more interest in LEDE

[Alberto Bursi]

On 03/08/2017 02:12 AM, Mauro Mozzarelli wrote:
>
> To date still no progress and thus I do not see that giant step Philip
> mentions.
> I made another attempt today via git.
>
> Mauro
>

Wait times can be short but also quite long, up to months depending on 
when the core devs have some free time to look at your stuff.

So far most of what was sent on github (and made sense) was merged 
eventually. I don't track patchwork so I don't know about that.

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

Re: [LEDE-DEV] Need fix / advice / idea

[Alberto Bursi]

On 03/07/2017 11:09 PM, Denis Periša wrote:
> Alberto , thank you for insight!
>
> This device in latest "RouterBOOT" (as they call it) supports
> repartitioning to two partitions. But openwrt/LEDE (kernel actually)
> doesent support that - as per say -
>
> RouterBOOT booter 3.24
>
> RouterBoard 435G
>
> CPU frequency: 680 MHz
>   Memory size: 256 MiB
> NAND size:  64 MiB
> NAND partitions: 2
>
> Press any key within 1 seconds to enter setup.
> writing settings to flash... OK
>
> loading kernel from nand partition 1... kernel not found
> writing settings to flash... OK
>
> loading kernel from nand partition 0... OK
> setting up elf image... not an elf header
> kernel loading failed
> trying bootp protocol OK
> Got IP address: 192.168.111.91
> resolved mac address 00:XX:XX:00:06:XX
> Gateway: 192.168.111.2
> transfer started  transfer ok, time=1.24s
> setting up elf image... OK
> kernel loading failed - kernel does not support NAND partitions
>
>

No, that log says it didn't find a kernel in NAND in either partition 0 
or 1.

The repartitioning changes partitions in bootloader, but you need to 
erase the flash of these new partitions, then flash a new LEDE firmware 
in these new partitions. The bootloader should be able to do this.

Did you also edit that source file and recompile as I pointed out? That 
is needed for LEDE to actually recognize the new partitions once it is 
booted successfully.

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

Re: [LEDE-DEV] [PATCH 00/12] alternatives support

[Philip Prindeville]

> On Mar 7, 2017, at 6:47 PM, Yousong Zhou  wrote:
> 
> The usefulness of such availability only makes sense when it is going
> to at least have an actual user.  Feel free to bring it up in another
> occasion if you find it necessary to achieve your goals there ;)

The "user" in this case is any developer who packages multiple images for 
families of platforms, etc.

-Philip

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

Re: [LEDE-DEV] [PATCH 00/12] alternatives support

[Yousong Zhou]

On 8 March 2017 at 08:52, Philip Prindeville
 wrote:
>
>> On Mar 5, 2017, at 8:06 AM, Matthias Schiffer 
>>  wrote:
>>
>> This could also avoid adding host UCI support to the build system, making 
>> the whole patchset a lot smaller.
>
>
> Host support for UCI is useful to have anyway, for other reasons… not 
> something to avoid doing (not clear if you were against the principle of 
> having UCI be on the host, or just trying to keep this particular patchset 
> down to the bare minimum).
>
> For instance, you could have platform-specific scripts that dynamically 
> generate the initial configuration in the target image by doing UCI 
> batch/add/commit sequences…
>
> -Philip
>

The usefulness of such availability only makes sense when it is going
to at least have an actual user.  Feel free to bring it up in another
occasion if you find it necessary to achieve your goals there ;)

We always have a choice to introduce new features when there is no
other way around.  But the addition will add to the maintenance
burden, and they will only be removed or replaced if we decide to make
a hard choice to abandon backward-compatibility and this is really
bad...

yousong

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

Re: [LEDE-DEV] Need fix / advice / idea

[Sergey Ryazanov]

On Wed, Mar 8, 2017 at 3:19 AM, Denis Periša  wrote:
>>> Just curious, this bad sectors appeared during regular device
>>> operation or just after sysupgrade?
>
>
> Sysupgrade. I had to get to roof and replace device as I could no
> longer get firmware on it. Btw. I wrote that it would be nice to first
> check nand than write if possible.

Before sysupgrade starts checking NAND it should know target flash
type, but image does not contain this info now. Image name contains
tiny hint: "64m" is for chips with 512-bytes pages and "large" is for
chips with 2048-bytes pages. Your flash type could be revealed by:

# dmesg | grep "page size"

> sysupgrade told me that firmware
> was flashed successfully but on reboot no kernel was found.
>

Yep. sysupgrade uses nandwrite utility, which could only report data
write result but could not predict kernel reaction to such "data".

>>> I am asking because it could be "false positive" bad sectors. Couple
>>> of weeks ago I flash one rb411 with wrong image. I used image for
>>> flash chips with 512-bytes pages, while the board was equipped with
>>> flash chip with 2048-bytes pages. And after reboot kernel printed a
>>> lot of "bad sector" messages. Actually sectors was fine, but using of
>>> the wrong firmware image lead to corruption of OOB data of several
>>> pages.
>>>
>>> I solved this issue by flashing back the vendor's firmware with help
>>> of netinstall, this action had recover flash OOB. Then I flash the
>>> device again, but now with the correct LEDE image and it works! Looks
>>> like that the similar results could be reached with _nandwrite_
>>> utility, but I did not try it.
>
> You might be on to something there, I had same device and it was brand
> new out of box.. Flashed firmware once, flashed twice, lot more bad
> sectors, next time whole nand was bad. That time I experimented with
> yaffs1 and yaffs2, had lot of issues there. Returned it as RMA same
> day, got another device. I actually tried to find how I could from
> linux re-detect or re-check how to put it, those bad sectors but
> didn't find any info. This yours is very helpful info, I'll try that
> and return here, but question stays, maybe in future some NANDs will
> begin to fail. This could be helpful in future.
>

Even 2Mb kernel partition contains enough spare space to overcome rise
of few bad sectors. To get more bad sectors you should reflash your
board a couple of time per day for several years. So IMHO there are
nothing to worry about.

-- 
Sergey

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

Re: [LEDE-DEV] [PATCH 00/12] alternatives support

[Philip Prindeville]

> On Mar 5, 2017, at 8:06 AM, Matthias Schiffer 
>  wrote:
> 
> This could also avoid adding host UCI support to the build system, making the 
> whole patchset a lot smaller.


Host support for UCI is useful to have anyway, for other reasons… not something 
to avoid doing (not clear if you were against the principle of having UCI be on 
the host, or just trying to keep this particular patchset down to the bare 
minimum).

For instance, you could have platform-specific scripts that dynamically 
generate the initial configuration in the target image by doing UCI 
batch/add/commit sequences…

-Philip


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

[LEDE-DEV] Supporting crashdumps w/ kexec

[Philip Prindeville]

Hi.

I’m trying to add scripting to support crashdumps.  I’m on an x86_64 and 
haven’t been able to get crashlog to work, so this seems like the next best 
thing.

I’ve a few related questions I was hoping I could get answered.

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?

2nd, how to pass in extra GRUB arguments to the kernel build when a package has 
been selected?  For instance, if I wanted to do "CONFIG_GRUB_BOOTOPTS += 
crashkernel=64M”  Or what if I want to configure an extra menuentry in 
/boot/grub/grub.cfg?

Or would I do:

Image/cmdline/squashfs += crashkernel=64m

(which seems to only be relevant for x86 hardware…)

3rd question, when I build kexec-tools, I need to make sure that the 
corresponding kernel has been built with:

# CONFIG_SMP is not set
CONFIG_KEXEC=y
CONFIG_CRASH_DUMP=y
CONFIG_PHYSICAL_START=0x100
CONFIG_RELOCATABLE=y
# CONFIG_RANDOMIZE_BASE is not set
CONFIG_PROC_KCORE=y
CONFIG_PROC_VMCORE=y
CONFIG_SYSFS=y
CONFIG_DEBUG_INFO=y

I know that kmod packages can have KCONFIG's for specific .config symbols, but 
how does a regular package force these kernel options?

4th question, and this is more general: I need a place where I can copy 
/proc/vmcore to persistent storage, but I don’t want to risk filling up the 
root partition, etc.  Is there an easy way to have the image include a 3rd 
partition for collecting crash dumps?  Or should I just count on /etc/fstab 
containing a magic entry?  Or look for a partition with a predefined label 
(like “CRASHDUMP”)?

Thanks,

-Philip


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

Re: [LEDE-DEV] Need fix / advice / idea

[Denis Periša]

>> Just curious, this bad sectors appeared during regular device
>> operation or just after sysupgrade?


Sysupgrade. I had to get to roof and replace device as I could no
longer get firmware on it. Btw. I wrote that it would be nice to first
check nand than write if possible. sysupgrade told me that firmware
was flashed successfully but on reboot no kernel was found.

>> I am asking because it could be "false positive" bad sectors. Couple
>> of weeks ago I flash one rb411 with wrong image. I used image for
>> flash chips with 512-bytes pages, while the board was equipped with
>> flash chip with 2048-bytes pages. And after reboot kernel printed a
>> lot of "bad sector" messages. Actually sectors was fine, but using of
>> the wrong firmware image lead to corruption of OOB data of several
>> pages.
>>
>> I solved this issue by flashing back the vendor's firmware with help
>> of netinstall, this action had recover flash OOB. Then I flash the
>> device again, but now with the correct LEDE image and it works! Looks
>> like that the similar results could be reached with _nandwrite_
>> utility, but I did not try it.

You might be on to something there, I had same device and it was brand
new out of box.. Flashed firmware once, flashed twice, lot more bad
sectors, next time whole nand was bad. That time I experimented with
yaffs1 and yaffs2, had lot of issues there. Returned it as RMA same
day, got another device. I actually tried to find how I could from
linux re-detect or re-check how to put it, those bad sectors but
didn't find any info. This yours is very helpful info, I'll try that
and return here, but question stays, maybe in future some NANDs will
begin to fail. This could be helpful in future.

Thank you!

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

Re: [LEDE-DEV] Need fix / advice / idea

[Sergey Ryazanov]

On Sun, Mar 5, 2017 at 6:25 PM, Denis Periša  wrote:
> I have situation where one of my devices (rb435g) has lot of bad
> sectors on (NAND) kernel partition.

Just curious, this bad sectors appeared during regular device
operation or just after sysupgrade?

I am asking because it could be "false positive" bad sectors. Couple
of weeks ago I flash one rb411 with wrong image. I used image for
flash chips with 512-bytes pages, while the board was equipped with
flash chip with 2048-bytes pages. And after reboot kernel printed a
lot of "bad sector" messages. Actually sectors was fine, but using of
the wrong firmware image lead to corruption of OOB data of several
pages.

I solved this issue by flashing back the vendor's firmware with help
of netinstall, this action had recover flash OOB. Then I flash the
device again, but now with the correct LEDE image and it works! Looks
like that the similar results could be reached with _nandwrite_
utility, but I did not try it.

-- 
Sergey

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

Re: [LEDE-DEV] Need fix / advice / idea

[Denis Periša]

Alberto , thank you for insight!

This device in latest "RouterBOOT" (as they call it) supports
repartitioning to two partitions. But openwrt/LEDE (kernel actually)
doesent support that - as per say -

RouterBOOT booter 3.24

RouterBoard 435G

CPU frequency: 680 MHz
  Memory size: 256 MiB
NAND size:  64 MiB
NAND partitions: 2

Press any key within 1 seconds to enter setup.
writing settings to flash... OK

loading kernel from nand partition 1... kernel not found
writing settings to flash... OK

loading kernel from nand partition 0... OK
setting up elf image... not an elf header
kernel loading failed
trying bootp protocol OK
Got IP address: 192.168.111.91
resolved mac address 00:XX:XX:00:06:XX
Gateway: 192.168.111.2
transfer started  transfer ok, time=1.24s
setting up elf image... OK
kernel loading failed - kernel does not support NAND partitions


Board is rb4xx .. rb433 and rb435g are almost same thing.

Thank you!


On Sun, Mar 5, 2017 at 7:31 PM, Alberto Bursi  wrote:
>
>
> On 03/05/2017 04:25 PM, Denis Periša wrote:
>> Hi all,
>>
>> I have situation where one of my devices (rb435g) has lot of bad
>> sectors on (NAND) kernel partition.
>>
>> First of all, are those partitions physical? Can they be somehow
>> re-partitioned by kernel cmd line or? I'm left with only under 1mb of
>> usable space so I need to make kernel that fits that available space.
>>
>> Currently `make kernel_menuconfig` does not work, any news on that?
>> Any ideas on how could I salvage this device to be usable?
>>
>> Network boot is a option, but that's last resort.
>>
>> Thank you!
>>
>
> You can try repartitioning through bootloader if you have serial
> console, see here
> https://wiki.mikrotik.com/wiki/Manual:RouterBOOT
>
> Then you may need to patch this file's partition list too and compile
> your own firmware, so LEDE actually uses the new partitions you have set
> up in the bootloader.
> https://github.com/lede-project/source/blob/master/target/linux/ar71xx/files/arch/mips/ath79/mach-rb4xx.c#L148
>
> The kernel is compiled by default to add this
> https://github.com/lede-project/source/blob/master/target/linux/ar71xx/config-4.4#L245
>
> to the kernel command line added from bootloader.
>
> I don't know that device so I can't tell you more specific info.
>
> Note that in most devices there are hardware setup or bootloader
> partitions that should not be touched.
>
> -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

Re: [LEDE-DEV] [PATCH v3 1/2] ar71xx: Add support for TP-Link MR6400

[Piotr Dymacz]

Hello Filip,

On 05.03.2017 18:03, Filip Moc wrote:

You can flash via u-boot tftp (serve factory image as /mr6400_tp_recovery.bin
on 192.168.0.66/24, connect to any ethernet port and power on device while
holding the reset button).


[...]

Is there any problem with upgrade under vendor gui on this device?

Could you please also include more information about the device in 
commit message, like e.g. in [1], [2], [3].


There is no strict format or requirements (at least for now) how it 
should look like or what should be included, feel free to follow any of 
the examples below.


These information could be then used by people working on the Wiki or 
just as reference.


[1] 
https://github.com/lede-project/source/commit/f9278337cf4b9c699a41dfc1e4c448213be53e61
[2] 
https://github.com/lede-project/source/commit/edae3479e64e93275dce4a928ea70279282eef9d
[3] 
https://github.com/lede-project/source/commit/9b35815f0f0e10125d144c82595bbccbc83d6812


--
Cheers,
Piotr

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

Re: [LEDE-DEV] [PATCH] Lantiq Amazon-SE SoC / ADSL Modem Allnet All0333CJ Rev.C

[Tino Reichardt]

* Bastian Bittorf  wrote:
> * Bastian Bittorf  [07.03.2017 11:07]:
> > * Tino Reichardt  [06.03.2017 08:24]:
> > > BE AWARE:
> > > My patch seems to work fine, even the dsl modem seems to be correctly
> > > loaded. But it's not tested currently... so please do not flash your
> > > modems, when they are needed currently ;)
> > 
> > Impressive! i will check if pppoe works later and report.
> 
> it seems, that the modem is not initialised correctly,
> there is e.g. no blinking of the led and 'nas0' will not
> come up and so no pppoe...if somebody has an idea, i can test.

This is my current bootlog:

[...]
[0.531727] 0x0001-0x003ff200 : "firmware"
[0.555144] 2 uimage-fw partitions found on MTD device firmware
[0.559815] 0x0001-0x00110874 : "kernel"
[0.571102] 0x00110874-0x003ff200 : "rootfs"
[0.582522] mtd: device 3 (rootfs) set to be root filesystem
[0.586987] 1 squashfs-split partitions found on MTD device rootfs
[0.593060] 0x002d-0x003f : "rootfs_data"
[0.606262] 0x003ff200-0x003ffe00 : "uboot_env"
[0.618026] 0x003ffe00-0x0040 : "dummy_rootfs"
[0.631843] Selected EPHY mode
[0.634260] etop: invalid MAC, using random
[0.648022] libphy: ltq_mii: probed
[0.650592] eth0: attached PHY [Generic PHY] (phy_addr=1e18.etop-ff:08, 
irq=-1)
[0.662138] wdt 1f8803f0.watchdog: Init done
[0.670421] NET: Registered protocol family 17
[0.673865] bridge: automatic filtering via arp/ip/ip6tables has been 
deprecated. Update your scripts to load br_netfilter if you need this.
[0.686115] 8021q: 802.1Q VLAN Support v1.8
[0.723045] VFS: Mounted root (squashfs filesystem) readonly on device 31:3.
[0.735002] Freeing unused kernel memory: 1200K (80314000 - 8044)
[3.127473] init: Console is alive
[3.130483] init: - watchdog -
[3.859264] kmodloader: loading kernel modules from /etc/modules-boot.d/*
[4.063814] kmodloader: done loading kernel modules from 
/etc/modules-boot.d/*
[4.080946] init: - preinit -
[8.068482] jffs2: notice: (277) jffs2_build_xattr_subsystem: complete 
building xattr subsystem, 0 of xdatum (0 unchecked, 0 orphan) and 0 of xref (0 
dead, 0 orphan) found.
[8.087572] mount_root: switching to jffs2 overlay
[8.152790] urandom-seed: Seeding with /etc/urandom.seed
[8.716110] procd: - early -
[8.718146] procd: - watchdog -
[9.593213] procd: - ubus -
[9.961355] random: ubusd: uninitialized urandom read (4 bytes read, 39 bits 
of entropy available)
[9.972503] random: ubusd: uninitialized urandom read (4 bytes read, 39 bits 
of entropy available)
[9.981601] random: ubusd: uninitialized urandom read (4 bytes read, 39 bits 
of entropy available)
[9.989488] random: ubusd: uninitialized urandom read (4 bytes read, 39 bits 
of entropy available)
[9.19] random: ubusd: uninitialized urandom read (4 bytes read, 39 bits 
of entropy available)
[   10.007788] random: ubusd: uninitialized urandom read (4 bytes read, 39 bits 
of entropy available)
[   10.019285] random: ubusd: uninitialized urandom read (4 bytes read, 39 bits 
of entropy available)
[   10.028188] random: ubusd: uninitialized urandom read (4 bytes read, 39 bits 
of entropy available)
[   10.038213] procd: - init -
[   11.040310] kmodloader: loading kernel modules from /etc/modules.d/*
[   11.055903] NET: Registered protocol family 8
[   11.058993] NET: Registered protocol family 20
[   11.075693] IFX MEI Version 5.00.00
[   11.099774] Infineon CPE API Driver version: DSL CPE API V3.24.4.4
[   11.128356] ATM1.0.26ATM (A1) firmware version 0.16
[   11.132296] ifxmips_atm: ATM init succeed
[   11.330351] nf_conntrack version 0.5.0 (200 buckets, 800 max)
[   11.466418] xt_time: kernel timezone is -
[   11.475272] ip_tables: (C) 2000-2006 Netfilter Core Team
[   11.506448] PPP generic driver version 2.4.2
[   11.517892] NET: Registered protocol family 24
[   11.531936] kmodloader: done loading kernel modules from /etc/modules.d/*
[   11.628832] random: ubusd: uninitialized urandom read (4 bytes read, 46 bits 
of entropy available)
[   11.637421] random: ubus: uninitialized urandom read (4 bytes read, 46 bits 
of entropy available)
[   24.951827] [DSL_BSP_FWDownload 1615]: 
[   25.125895] [IFX_MEI_DFEMemoryAlloc 1498]: image_size = 322840
[   25.183263] [DSL_BSP_FWDownload 1683]: -> IFX_MEI_BarUpdate()
[   25.404145] [DSL_BSP_FWDownload 1615]: 
[   25.428137] [DSL_BSP_FWDownload 1615]: 
[   25.647045] [DSL_BSP_FWDownload 1615]: 
[   25.659983] [DSL_BSP_FWDownload 1615]: 
[   25.666015] [IFX_MEI_Ioctls 2560]: DSL_FIO_BSP_DSL_START
[   25.670095] [IFX_MEI_RunAdslModem 1318]: allocate 32KB swap buff memory at: 
0x807c
[   25.927207] [IFX_MEI_IrqHandle 1856]: Got MODEM_READY_MSG
[   25.931446] [IFX_MEI_IrqHandle 1856]: Got MODEM_READY_MSG
[   26.145547] [IFX_MEI_RunAdslModem 1371]: Modem is ready.
[   

Re: [LEDE-DEV] Please help with submitting contributions

[Mauro Mozzarelli]

I did, but it isn't there, so something has not worked.

I have now created a pull request.

It isn't perfect in its form as I meant originally to create one request 
each for the kernel and for the tool, but I couldn't tame git to do what 
I wanted.


I hope this one finally goes through:


https://github.com/lede-project/source/pull/928


Mauro


On 07/03/17 19:11, Stijn Segers wrote:

Hi Mauro,

If you send your patch in with git send-email, you can track your 
patch here:


https://patchwork.ozlabs.org/project/lede/list/

I have no idea how long you waited, if you feel it is taking too long 
or your patch is getting lost in the pile, you can always nudge a 
developer (which imho works best on IRC).


If you check the list above, you'll see you're not the only one 
waiting for feedback (and then there's also the pull requests on 
Github) - so... You will need some patience, resources are a bit 
stretched.


So... Chin up, all beginnings are difficult!

Cheers

Stijn




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

Re: [LEDE-DEV] Please help with submitting contributions

[Stijn Segers]

Hi Mauro,

If you send your patch in with git send-email, you can track your patch 
here:


https://patchwork.ozlabs.org/project/lede/list/

I have no idea how long you waited, if you feel it is taking too long 
or your patch is getting lost in the pile, you can always nudge a 
developer (which imho works best on IRC).


If you check the list above, you'll see you're not the only one waiting 
for feedback (and then there's also the pull requests on Github) - 
so... You will need some patience, resources are a bit stretched.


So... Chin up, all beginnings are difficult!

Cheers

Stijn


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

Re: [LEDE-DEV] Please help with submitting contributions

[Alberto Bursi]

On 03/07/2017 05:48 PM, Mauro Mozzarelli wrote:
> Hello,
>
>
> I would like to make contributions to lede, but so far I bumped into a
> series of obstacles.
>
> So far I tried the following:
>
>
> git format-patch, then copy and paste into email -> was not accepted
>
> git send-email -> I do not know whether the patch was accepted, I did
> not receive any feedback
>
>
> Now I am trying also to follow what is on this page:
>
> https://lede-project.org/submitting-patches
>
> Under "Working with github"
>
> git clone https://github.com/lede-project/source.git
> git checkout -b 
>   
> git commit --signoff
> git push --all
>

That should be done on your account's fork of LEDE source, not on the 
lede repo directly. But the wiki paragraph is rather short and unclear.

I've just edited that paragraph to be actually useful.

https://lede-project.org/submitting-patches#working_with_github

-Alberto

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

Re: [LEDE-DEV] Please help with submitting contributions

[Weedy]

On 7 March 2017 11:48:51 GMT-05:00, Mauro Mozzarelli  wrote:
>mauro@sirius:/net2/router/lede/trunk$ git push --all
>Username for 'https://github.com': ezplanet
>Password for 'https://ezpla...@github.com':
>remote: Permission to lede-project/source.git denied to ezplanet.
>fatal: unable to access 'https://github.com/lede-project/source.git/': 
>The requested URL returned error: 403
>
>And this is where I am stuck now.

You need to fork the repo to your own account and commit your changes there. 
You can do that from the website.

Then you'll have the option of making a PR again on the site.

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

[LEDE-DEV] Please help with submitting contributions

[Mauro Mozzarelli]

Hello,


I would like to make contributions to lede, but so far I bumped into a 
series of obstacles.


So far I tried the following:


git format-patch, then copy and paste into email -> was not accepted

git send-email -> I do not know whether the patch was accepted, I did 
not receive any feedback



Now I am trying also to follow what is on this page:

https://lede-project.org/submitting-patches

Under "Working with github"

git clone https://github.com/lede-project/source.git
git checkout -b 
  
git commit --signoff
git push --all


As follows:
mauro@sirius:/net2/router/lede$ git clone 
https://github.com/lede-project/source.git trunk

Cloning into 'trunk'...
remote: Counting objects: 381348, done.
remote: Compressing objects: 100% (13/13), done.
remote: Total 381348 (delta 1), reused 0 (delta 0), pack-reused 381335
Receiving objects: 100% (381348/381348), 134.77 MiB | 823.00 KiB/s, done.
Resolving deltas: 100% (258216/258216), done.
Checking connectivity... done.
mauro@sirius:/net2/router/lede$ cd trunk
mauro@sirius:/net2/router/lede/trunk$ git checkout -b kernel-ipvs
Switched to a new branch 'kernel-ipvs'
mauro@sirius:/net2/router/lede/trunk$ patch -p1 < 
../submitted/0001-Add-ip_vs-kernel-netfilter-modules-to-enable-load-ba.patch 


patching file package/kernel/linux/modules/netfilter.mk
mauro@sirius:/net2/router/lede/trunk$ git commit --signoff
On branch kernel-ipvs
Changes not staged for commit:
modified:   package/kernel/linux/modules/netfilter.mk

no changes added to commit
mauro@sirius:/net2/router/lede/trunk$ git add 
package/kernel/linux/modules/netfilter.mk

mauro@sirius:/net2/router/lede/trunk$ git commit --signoff
[kernel-ipvs 9d168cc] Add ip_vs kernel nf modules to enable load balancer
 1 file changed, 89 insertions(+)
mauro@sirius:/net2/router/lede/trunk$ git push --all
Username for 'https://github.com': ezplanet
Password for 'https://ezpla...@github.com':
remote: Permission to lede-project/source.git denied to ezplanet.
fatal: unable to access 'https://github.com/lede-project/source.git/': 
The requested URL returned error: 403


And this is where I am stuck now.

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

Re: [LEDE-DEV] [PATCH 00/12] alternatives support

[Matthias Schiffer]

On 03/06/2017 05:27 PM, Yousong Zhou wrote:
> On 5 March 2017 at 23:06, Matthias Schiffer
>  wrote:
>> On 03/05/2017 10:31 AM, Yousong Zhou wrote:
>>> This patch set tries to make it possible that files serving the same purpose
>>> and installed to different locations can be available under the same name
>>> through a symbolic link
>>>
>>> The idea is from alternatives of debian system [1,2].  "ip" command is a 
>>> good
>>> example of the problem it tries to solve [3].   Files provided by different
>>> packages cannot be installed to the same location, so we have busybox ip,
>>> ip-tiny, ip-full all installed to different locations
>>>
>>> It works by first adding to CONTROL file of each ipkg a new field 
>>> "Alternatives",
>>> which is a list of specs of the following form seprated by commas to 
>>> describe
>>> alternatives provided by this package
>>>
>>> ::
>>>
>>> The new field will be interpreted by postinst and prerm script.   
>>> will be
>>> a symbolic link to  of the highest , and updates will be 
>>> made to
>>> UCI config "opkg"
>>>
>>> Several patches for uci are also included here to support usage at 
>>> build-time.
>>> The whole series is available in my staging tree [4]
>>>
>>>  [1] https://wiki.debian.org/DebianAlternatives
>>>  [2] 
>>> https://debian-administration.org/article/91/Using_the_Debian_alternatives_system
>>>  [3] https://bugs.lede-project.org/index.php?do=details_id=428
>>>  [4] https://git.lede-project.org/?p=lede/yousong/staging.git;a=summary
>>
>> First of all, thank you very much for working on this, I've been missing
>> this feature for a long time. I have some comments though:
>>
>> I see that the opkg UCI config contains a lot of redundant data when many
>> alternatives are installed (for example, many busybox applets and their
>> corresponding coreutils/util-linux/... variants); AFAICT, the same
>> information is also available in the opkg status files.
>>
>> I think I'd opt for not making this list of alternatives configurable
>> independently of opkg. Adding configuration to UCI would only be necessary
>> when a user overrides the automatic selection. This could also avoid adding
>> host UCI support to the build system, making the whole patchset a lot 
>> smaller.
>>
>> Matthias
>>
> 
> Thanks for the feedback.  I agree that it should be sealed inside opkg
> and could be more neat that way.  Probably I decided to code it with
> shell scripting just because the task seemed to be a more "low-hanging
> fruit" with that approach ;)  Lazy me!
> 
> Anyway, I will investigate the opkg-lede codebase and report back at a
> later time.
> 
> Cheers,
> yousong
> 

I wouldn't say it can't be implemented in shell. Our user creation logic is
part of our default postinst script, but the data is uses is contained in
the opkg database. I would try implementing it in a similar way.

Matthias





signature.asc
Description: OpenPGP digital signature
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH] Lantiq Amazon-SE SoC / ADSL Modem Allnet All0333CJ Rev.C

[Bastian Bittorf]

* Bastian Bittorf  [07.03.2017 11:07]:
> * Tino Reichardt  [06.03.2017 08:24]:
> > BE AWARE:
> > My patch seems to work fine, even the dsl modem seems to be correctly
> > loaded. But it's not tested currently... so please do not flash your
> > modems, when they are needed currently ;)
> 
> Impressive! i will check if pppoe works later and report.

it seems, that the modem is not initialised correctly,
there is e.g. no blinking of the led and 'nas0' will not
come up and so no pppoe...if somebody has an idea, i can test.

bye, bastian

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

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

[Jurgen Van Ham]

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.

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] [PATCH] Lantiq Amazon-SE SoC / ADSL Modem Allnet All0333CJ Rev.C

[Bastian Bittorf]

* Tino Reichardt  [06.03.2017 08:24]:
> BE AWARE:
> My patch seems to work fine, even the dsl modem seems to be correctly
> loaded. But it's not tested currently... so please do not flash your
> modems, when they are needed currently ;)

Impressive! i will check if pppoe works later and report.
here a small walktrough when unboxing and reflashing a thing:

# telnet with root/admin into original firmware...:

BusyBox v1.00 (2012.03.02-08:09+) Built-in shell (ash)
Enter 'help' for a list of built-in commands.

# killall dsl_cpe_control
# ps
  PID  Uid VmSize Stat Command
1 root336 S   init
2 rootSW  [keventd]
3 rootSWN [ksoftirqd_CPU0]
4 rootSW  [kswapd]
5 rootSW  [bdflush]
6 rootSW  [kupdated]
7 rootSW  [swapper]
8 rootSW  [mtdblockd]
   18 root 60 S   /usr/sbin/swreset
  137 root296 S   /sbin/syslogd -s 8 -b 2 -l 8
  186 rootSW  [autbtex]
  187 rootSW  [atm_led_complet]
  188 rootSW  [pmex_ne]
  191 rootSW  [pmex_fe]
  854 root232 S   ./devm
  855 root   1000 S   /usr/sbin/devmapp
  905 root320 S   /usr/sbin/inetd /etc/inetd.conf
 1044 root328 S   /sbin/getty 115200 ttyS0
 1207 root304 S   /usr/sbin/br2684ctld
 1249 root364 S   /usr/sbin/dnrd
 1332 root300 S   telnetd
 1333 root312 S   -sh
 1335 root336 R   ps

# cd /ramdisk/tftp_upload

# tftp -g -r uImage 172.16.1.1
# tftp -g -r flashwrite 172.16.1.1
# tftp -g -r fw_setenv 172.16.1.1
# tftp -g -r fw.conf 172.16.1.1
# ln -s fw_setenv fw_printenv
# chmod +x *

# ls -l
-rwxr-xr-x1 root root38200 Mar  2 16:44 flashwrite
-rwxr-xr-x1 root root  972 Mar  2 16:44 fw.conf
lrwxrwxrwx1 root root9 Mar  2 16:44 fw_printenv -> fw_setenv
-rwxrwxrwx1 root root58012 Mar  2 16:44 fw_setenv
-rwxr-xr-x1 root root  2883758 Mar  2 16:42 uImage

# ./fw_setenv disable_recovery y
[crc0 data:3d744984 flash:3d744984!]

# ./fw_setenv kernel_addr 0xb001
[crc0 data:  9b028f flash:  9b028f!]

# ./flashwrite /dev/mtd/1 uImage 0
Performing Flash Erase of length 65536 at offset 0
Performing Flash Erase of length 65536 at offset 65536
Performing Flash Erase of length 65536 at offset 131072
Performing Flash Erase of length 65536 at offset 196608
Performing Flash Erase of length 65536 at offset 262144
Performing Flash Erase of length 65536 at offset 327680
Performing Flash Erase of length 65536 at offset 393216
Performing Flash Erase of length 65536 at offset 458752
Performing Flash Erase of length 65536 at offset 524288
Performing Flash Erase of length 65536 at offset 589824
Performing Flash Erase of length 65536 at offset 655360
Performing Flash Erase of length 65536 at offset 720896
Performing Flash Erase of length 65536 at offset 786432
Performing Flash Erase of length 65536 at offset 851968
Performing Flash Erase of length 65536 at offset 917504
Performing Flash Erase of length 65536 at offset 983040
Performing Flash Erase of length 65536 at offset 1048576
Performing Flash Erase of length 65536 at offset 1114112
Performing Flash Erase of length 65536 at offset 1179648
Performing Flash Erase of length 65536 at offset 1245184
Performing Flash Erase of length 65536 at offset 1310720
Performing Flash Erase of length 65536 at offset 1376256
Performing Flash Erase of length 65536 at offset 1441792
Performing Flash Erase of length 65536 at offset 1507328
Performing Flash Erase of length 65536 at offset 1572864
Performing Flash Erase of length 65536 at offset 1638400
Performing Flash Erase of length 65536 at offset 1703936
Performing Flash Erase of length 65536 at offset 1769472
Performing Flash Erase of length 65536 at offset 1835008
Performing Flash Erase of length 65536 at offset 1900544
Performing Flash Erase of length 65536 at offset 1966080
Performing Flash Erase of length 65536 at offset 2031616
Performing Flash Erase of length 65536 at offset 2097152
Performing Flash Erase of length 65536 at offset 2162688
Performing Flash Erase of length 65536 at offset 2228224
Performing Flash Erase of length 65536 at offset 2293760
Performing Flash Erase of length 65536 at offset 2359296
Performing Flash Erase of length 65536 at offset 2424832
Performing Flash Erase of length 65536 at offset 2490368
Performing Flash Erase of length 65536 at offset 2555904
Performing Flash Erase of length 65536 at offset 2621440
Performing Flash Erase of length 65536 at offset 2686976
Performing Flash Erase of length 65536 at offset 2752512
Performing Flash Erase of length 65536 at offset 2818048
Performing Flash Erase of length 65536 at offset 2883584
Writing the firmware of length 2883758 at 0...