Hello all,
I am looking for a open source database designed for embedded devices, I google
the problem and I found different solutions :
1 - Embedded InnoDB
2 - Empress Embedded Database
3 - Firebird embedded
They are the more interesting, I found them from
[http://en.wikipedia.org/wiki/Embedde
On Apr 3, 2013, at 4:30 PM, Jay Carlson wrote:
> In addition, touching errno means touching a TLS model symbol, and
> that's not supported in gcc 4.6.
OK, that's starting to look like a bug.
At the toplevel .config, the default is CONFIG_TLS_SUPPORT off. This triggers
toolchain/gcc/final/Makef
On Apr 3, 2013, at 4:47 PM, Florian Fainelli wrote:
> Did you also enable a MIPS16 build of the kernel or just user-space for now?
Just user-space. I think there may be large parts of the kernel which can be
built in mips16.
Because the rest of the mailing list probably doesn't read all the tic
Hello Jay,
Le 03/04/2013 22:30, Jay Carlson a écrit :
I've wanted to do userspace mips16 since around 2002. I've generated a
minimum changeset needed to get basic OpenWrt+luci running. This boots
and runs on mips/mipsel malta qemu, mipsel malta Imperas sim, and a
D-Link DIR-601-A1. It has not be
For now, build uclibc without -mips16. There's no mips16 syscall
support AFAIK and uclibc uses inline assembly syscalls a lot.
In addition, touching errno means touching a TLS model symbol, and
that's not supported in gcc 4.6.
The __set_errno macro can be put back to calling
errno_location(). Th
I've wanted to do userspace mips16 since around 2002. I've generated a
minimum changeset needed to get basic OpenWrt+luci running. This boots
and runs on mips/mipsel malta qemu, mipsel malta Imperas sim, and a
D-Link DIR-601-A1. It has not been tested on non-mips32r2
(i.e. non-mips16e) at all.
The
Packages not picking up the regular TARGET_AS need their openwrt
Makefiles tweaked. For a basic build, that's just openssl.
This depends on patch 1/5.
Signed-off-by: Jay Carlson
---
package/openssl/Makefile |2 ++
1 file changed, 2 insertions(+)
diff --git a/package/openssl/Makefile b/pack
The .init and .fini sections are built by concatenating code
fragments. Putting mips16 code in the middle of a mips32 code block
doesn't work. Make gcc built the magic crt stuff in no-mips16 mode.
This is specific to 4.6-linaro but is probably portable to other gcc
flavors. Adding this to the t-li
Create and use a TARGET_ASFLAGS, defaulting to TARGET_CFLAGS.
MIPS .S files reasonably assume they are not in mips16 mode. Because
"-mips16 -mno-mips16" results in -mno-mips16, I can append that to the
TARGET_ASFLAGS. This should be done with $(filter-out)?
Signed-off-by: Jay Carlson
---
rules.
To be safe, build "m16" into the toolchain and target architecture the
same way mips32r2 does:
target-mips_r2_m16_uClibc-0.9.33.2
toolchain-mips_r2_m16_gcc-4.6-linaro_uClibc-0.9.33.2
Signed-off-by: Jay Carlson
---
rules.mk |1 +
1 file changed, 1 insertion(+)
diff --git a/rules.mk b/rules.
On 03/04/13 17:36, Jonathan Bither wrote:
May be the completely wrong idea, but what if there was an
OpenWRT-Kernel GIT repository holding the branches and modifications
required for each arch. Would allow easy updates and backports from a
Trunk branch to an LTS one.
Anyone is entitled to setup
On 04/03/2013 01:44 PM, Nick Podolak wrote:
On Wed, Apr 3, 2013 at 12:36 PM, Jonathan Bither mailto:jonbit...@gmail.com>> wrote:
May be the completely wrong idea, but what if there was an
OpenWRT-Kernel GIT repository holding the branches and modifications
required for each arch. Wo
On Wed, Apr 3, 2013 at 12:36 PM, Jonathan Bither wrote:
> May be the completely wrong idea, but what if there was an OpenWRT-Kernel
> GIT repository holding the branches and modifications required for each
> arch. Would allow easy updates and backports from a Trunk branch to an LTS
> one.
>
>
> On
May be the completely wrong idea, but what if there was an
OpenWRT-Kernel GIT repository holding the branches and modifications
required for each arch. Would allow easy updates and backports from a
Trunk branch to an LTS one.
On 04/03/2013 12:31 PM, Bruno Wolff III wrote:
On Wed, Apr 03, 2013
On Wed, Apr 03, 2013 at 18:16:05 +0200,
Rafał Miłecki wrote:
Ohh, so there is policy of *not* doing *fixes* updates of the kernel?
So we don't update for example from 3.4.30 to 3.4.38 after branching?
If so, I had no idea about that, but it sounds pretty wrong. Minor
(fixes) updates usually
2013/4/3 Bruno Wolff III :
> On Wed, Apr 03, 2013 at 17:32:43 +0200,
> Rafał Miłecki wrote:
>>
>>
>> Not really. Even if AA isn't going to be LTS, at the moment of
>> releasing it, 3.3 is already EOL. LTS kernel (Linux) would help in
>> that case. So I think it's generally a good idea to base Op
On Wed, Apr 03, 2013 at 17:32:43 +0200,
Rafał Miłecki wrote:
Not really. Even if AA isn't going to be LTS, at the moment of
releasing it, 3.3 is already EOL. LTS kernel (Linux) would help in
that case. So I think it's generally a good idea to base OpenWrt
releases on LTS kernels, especially i
2013/4/3 Bruno Wolff III :
> On Wed, Apr 03, 2013 at 09:23:13 -0400,
> Nick Podolak wrote:
>>
>>
>> Additionally, the historical data points out that there hasn't ever been
>> more than one active maintenance branch at a time. (the last update to
>> 8.09 happened before 10.03 and the last updat
On Wed, 03 Apr 2013 13:03:15 +0200, Rafał Miłecki wrote:
2013/4/3 Imre Kaloz :
On Wed, 03 Apr 2013 10:45:01 +0200, Rafał Miłecki wrote:
3.3 has been chosen as AA was meant to be released those days..
Well, so it seems we assumed two things:
1) AA quick release, according to the plan
On Wednesday 03 April 2013 10:12:52 Graham Cobb wrote:
> I can see how it should all work if preinit included a non-blank assignment
> to fs_failsafe_ifname. But I haven't been able to work out how that is
> normally set during a build or if there is some other mechanism which is
> normally used.
On Wed, Apr 03, 2013 at 09:23:13 -0400,
Nick Podolak wrote:
Additionally, the historical data points out that there hasn't ever been
more than one active maintenance branch at a time. (the last update to
8.09 happened before 10.03 and the last update to 10.03 was before 12.10)
Is this due to
>
> I'm not going to reinvent the wheel analyzing how hard it is to say
> how many features make it worth releasing new version. A lot of big
> (and actively developed) projects are using cycling releases now
> (including Linux kernel). And come one, OpenWrt is getting a lot of
> patches almost dai
Il 29/03/2013 12:20, Rafał Miłecki ha scritto:
> I'll try to fix this over weekend.
Hi, I don't want to hurry you, but I would need to know the day the
patch will be relased because I could buy a cheap router to use until we
get the Linksys working again.
Best regards
__
2013/4/3 Imre Kaloz :
> On Wed, 03 Apr 2013 10:45:01 +0200, Rafał Miłecki wrote:
>
>
>
>
>>>
>>> 3.3 has been chosen as AA was meant to be released those days..
>>
>>
>> Well, so it seems we assumed two things:
>> 1) AA quick release, according to the plan
>> 2) BB release quick enough to replace
Patch based on Attitude Adjustement 12.09, svn 36141
Signed-off-by: Gianluca A.
Index: a/arch/mips/bcm63xx/boards/board_bcm963xx.c
===
--- a/arch/mips/bcm63xx/boards/board_bcm963xx.c
+++ b/arch/mips/bcm63xx/boards/board_bcm963xx.c
@
On Wed, 03 Apr 2013 10:45:01 +0200, Rafał Miłecki wrote:
3.3 has been chosen as AA was meant to be released those days..
Well, so it seems we assumed two things:
1) AA quick release, according to the plan
2) BB release quick enough to replace AA before 3.3 gets EOL
I'm afraid both assumpt
On Wednesday 03 April 2013 09:21:18 Bastian Bittorf wrote:
> Have you tried the WAN-Interface? On some devices only the WAN-port
> is reachable via 192.168.1.1 - or are really no interfaces up? (empty
> ifconfig?)
Thanks for the reply Bastian. I did try all that -- before I went to the
effort of
2013/4/3 Imre Kaloz :
> On Wed, 03 Apr 2013 10:08:53 +0200, Rafał Miłecki wrote:
>
>> 2013/4/3 Bastian Bittorf :
>>>
>>> * sylvain roger rieunier [03.04.2013
>>> 09:08]:
maybe it'is a stupid question, but some one why Openwrt didn't use LTS
kernel like in
http://git.kernel.org
* Graham Cobb [03.04.2013 09:08]:
> discovered that failsafe mode doesn't seem to work. I can enter it, but no
> interfaces are configured (I have confirmed this using console access).
Have you tried the WAN-Interface? On some devices only the WAN-port
is reachable via 192.168.1.1 - or are real
On Wed, 03 Apr 2013 10:08:53 +0200, Rafał Miłecki wrote:
2013/4/3 Bastian Bittorf :
* sylvain roger rieunier [03.04.2013 09:08]:
maybe it'is a stupid question, but some one why Openwrt didn't use LTS
kernel like in
http://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git
At the
2013/4/3 Bastian Bittorf :
> * sylvain roger rieunier [03.04.2013
> 09:08]:
>> maybe it'is a stupid question, but some one why Openwrt didn't use LTS
>> kernel like in
>> http://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git
>
> At the moment the version is raised manually.
> Do you
* sylvain roger rieunier [03.04.2013 09:08]:
> maybe it'is a stupid question, but some one why Openwrt didn't use LTS
> kernel like in
> http://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git
At the moment the version is raised manually.
Do you want to automatically apply a new Kerne
32 matches
Mail list logo
