ARC port of GDB is not yet upstream so we need to use
sources from Synopsys GitHub repo.
Given Synopys' commitment to upstream ARC support in GDB
in the nearest future it might be simpler to add a separate
package for ARC GDB instead of patching generic GDB package.
This way once ARC GDB stuff get
John,
I took a look at the dtsi file and see how the dts is updating the
settings. I have
a dts that builds, but I would like a sanity check before submitting the
patch again.
http://pastebin.com/EunNmAf4
If this looks good I will update the 16M DTS and then submit again.
Thanks,
Drew
On
John,
This target was built for OpenWRT CC so the dts matches that format. I
am not very familiar with the dts format, can you provide a resource to
get up to speed on the latest format?
This is a board with the RT5350 SOC, very similar to other boards
supported. The dts has some settings
On 06/07/2016 11:00 AM, Claudio Leite wrote:
On 06/07/2016 10:48 AM, Dheeran Senthilvel wrote:
[snip]
===> Step 3: Reboot <==
After the above procedures, I don’t have the error anymore.
Great -- so you're all set, as far as you can tell?
Wonder what really caused the problem in f
On 06/07/2016 10:48 AM, Dheeran Senthilvel wrote:
[snip]
===> Step 3: Reboot <==
After the above procedures, I don’t have the error anymore.
Great -- so you're all set, as far as you can tell?
Wonder what really caused the problem in first place.
Given the date when you init
===> Step 1 : resetenv & reset <===
__ __ _ _
| \/ | __ _ _ _| | |
| |\/| |/ _` | '__\ \ / / _ \ | |
| | | | (_| | | \ V / __/ | |
|_| |_|\__,_|_|\_/ \___|_|_|
_ _ _
| | | | | __ ) ___ ___ | |_
Thanks for the clear output.
* Dheeran Senthilvel (dheeranm...@gmail.com) wrote:
[snip]
> ===> Step 3: Intrupt boot into failsafe <===
>
> Press the [f] key and hit [enter] to enter failsafe mode
> Press the [1], [2], [3] or [4] key and hit [enter] to select the debug level
> f
> - failsa
===> Step 1: Reboot <===
BusyBox v1.24.2 () built-in shell (ash)
_
//\ ____ ___ ___
/ LE/ \| | | __| \| __|
/DE /\ | |__| _|| |) | _|
// LE \ ||___|___/|___| lede-project.org
\\
Hello Dheeran,
* Dheeran Senthilvel (dheeranm...@gmail.com) wrote:
> Hi,
> Yes even after I run resetenv followed by a reset command, the
> fw_printenv produces the same output every time.
>
> > On 07-Jun-2016, at 3:54 PM, Claudio Leite wrote:
> >
> > Hi,
> >
> > * Dheeran Senthilvel (
On 7 June 2016 at 06:11, Xinxing Hu wrote:
> Hi Guys,
>
> I have another idea about this issue. Maybe it is not kernel, but uloop
> related. I read procd and libubox code a little bit, and it seems there is a
> potential issue existing in uloop_run().
>
> In general, uloop_run() is running in a wh
Eric, all,
Eric Schultz wrote:
> I'm excited to see so many people interested in TR-069 support! As a follow up
> to the previous TR-069 email, I've set up a meeting on TR-069 support for
> OpenWrt. The meeting is on Friday, June 10 at 7 AM PT.
We have prepared a short presentation giving a hig
Hi,
Yes even after I run resetenv followed by a reset command, the
fw_printenv produces the same output every time.
> On 07-Jun-2016, at 3:54 PM, Claudio Leite wrote:
>
> Hi,
>
> * Dheeran Senthilvel (dheeranm...@gmail.com) wrote:
>> Hi,
>> Thanks for the reply. But I already do
Hi all,
Chaoscalmer has a lot less wifi bandwidth when coverage class is increased.
Even when 2 devices are only a few meters apart.
In Barrierbreaker release, the rates were a lot higher in this usecase.
When doing Iperf benchmarks (~ 30 sec);
* The barrierbreaker 14.07 release is able to hi
On 07/06/2016 11:02, Daniel Curran-Dickinson wrote:
> iVBORw0KGgoNSUhEUgAAADAwAQMAAABtzGvEBlBMVEX///8AAABVwtN+eklEQVQY04XQzQ2EIBAF4IdMDIc5UAIlUIKlWMr0ZiMm28jOj+6iMXEOfBBmXgJAVLGlBkU3wcZ9I3Q7EdrAveowx6hZ0q6QJDsRnHlJwr+W4CHF7vLqTEenXABeUnSssbP8SdwdjTHEwcFDtQGKFuWjH8Lna8vAmfEF3NMPdAO
From: Dan Bugnar
The next message needs to be written after the data of current message.
This was adding "sizeof(struct log_head)" bytes between messages.
Signed-off-by: Dan Bugnar
---
log/syslog.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/log/syslog.c b/log/syslog.c
Add ubus method to set the buffer size.
Example:
ubus call log reload "{\"log_buffer_size\":size}"
Signed-off-by: Dan Bugnar
---
log/logd.c | 25 +
1 file changed, 25 insertions(+)
diff --git a/log/logd.c b/log/logd.c
index 27d3cac..563c545 100644
--- a/log/logd.
Change the log buffer size and copy the messages.
Copy the messages from the oldest to newest using the log_list.
First time we calculate the size of the all entries. The log_entries_size
calculates the size indifferent of the positions of the newest and oldest.
If we want to increase the log buff
iVBORw0KGgoNSUhEUgAAADAwAQMAAABtzGvEBlBMVEX///8AAABVwtN+eklEQVQY04XQzQ2EIBAF4IdMDIc5UAIlUIKlWMr0ZiMm28jOj+6iMXEOfBBmXgJAVLGlBkU3wcZ9I3Q7EdrAveowx6hZ0q6QJDsRnHlJwr+W4CHF7vLqTEenXABeUnSssbP8SdwdjTHEwcFDtQGKFuWjH8Lna8vAmfEF3NMPdAOsBscASUVORK5CYII=
Content-Type: text/plain; charset=
* Dheeran Senthilvel (dheeranm...@gmail.com) wrote:
> Hi,
> Compiled build r504 followed by clean build. Still not clear what is
> causing the boot error mentioned previously in mailing list - May 2016.
[snip]
>
> auto_recovery_check changes bootcmd: run nandboot
> Hit any key to stop autob
Hi,
Compiled build r504 followed by clean build. Still not clear what is
causing the boot error mentioned previously in mailing list - May 2016.
• [LEDE-DEV] WRT1900ACS - Kernel 4.4.11 boot failure Dheeran
Senthilvel
• [LEDE-DEV] WRT1900ACS - Kernel 4.4.11 boot
On 19/05/2016 14:57, Alin Nastac wrote:
> There is already a CONFIGURE_VAR set in here that seem
> to have the same purpose, but it doesn't do the trick
> in my cause (autoconf 2.69).
> ---
> libs/libnet-1.2.x/Makefile | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/libs/libnet-1.2.x/M
>if (entries_size < size) {
>memcpy(start, l, copy_len);
>start = (struct log_head *)
> &start->data[l->size];
>} else{
>entries_size -= copy_len;
>
22 matches
Mail list logo
