> While I have seen the "size" listed in lsmod and /proc/modules, I don't
> really know what it represents. I am assuming that it means code size
> and not memory.
I suspect so as well. Still, it may point to an opportunity.
> Make sure that you are counting the size of the files in /lib/module
On 5/12/2010 11:34 AM, Stefan Monnier wrote:
>> Less file system overhead on the flash side and no memory used to manage
>> the structures needed to insmod / rmmod.
>>
> Exactly. Maybe also a tighter memory layout since each module doesn't
> have to be in its own set of ELF sections, IIUC.
>
> Less file system overhead on the flash side and no memory used to manage
> the structures needed to insmod / rmmod.
Exactly. Maybe also a tighter memory layout since each module doesn't
have to be in its own set of ELF sections, IIUC.
Also, the linkage would be (presumably) static rather than
On 5/11/2010 11:27 AM, edgar.sol...@web.de wrote:
> On 11.05.2010 17:25, Stefan Monnier wrote:
>>> but wouldn't the increase in the kernel image actually equal the
>>> decrease in the squash image and therefore the size of the rootfs_data
>>> stay the same? Both are lzma compressed.
>>
>> I expect
> but wouldn't the increase in the kernel image actually equal the
> decrease in the squash image and therefore the size of the rootfs_data
> stay the same? Both are lzma compressed.
I expect that a kernel with some modules built-in will be smaller
(both in terms of flash space and in terms of RAM
On 11.05.2010 17:25, Stefan Monnier wrote:
but wouldn't the increase in the kernel image actually equal the
decrease in the squash image and therefore the size of the rootfs_data
stay the same? Both are lzma compressed.
I expect that a kernel with some modules built-in will be smaller
(both in
Hi,
I wonder IF linux can be made small enough for some of the
embedded chips to boot and then attach an SD card as the file system?
warm regards,
wiz
On Mon, 10 May 2010 edgar.sol...@web.de wrote:
> On 10.05.2010 23:47, Bernhard Loos wrote:
> > 2010/5/10 Bernhard Loos :
> >> 2010/5/1
On 10.05.2010 23:47, Bernhard Loos wrote:
> 2010/5/10 Bernhard Loos :
>> 2010/5/10 Matthias Buecher / Germany :
>>> The "linux" partition spans over the kernel and the complete rootfs for
>>> flashing.
>>> The maximum kernel size is 0x000bc000 (begin of "rootfs") minus
>>> 0x0004 (begin of "lin
On 10.05.2010 23:47, Bernhard Loos wrote:
> 2010/5/10 Bernhard Loos :
>> 2010/5/10 Matthias Buecher / Germany :
>>> The "linux" partition spans over the kernel and the complete rootfs for
>>> flashing.
>>> The maximum kernel size is 0x000bc000 (begin of "rootfs") minus
>>> 0x0004 (begin of "lin
2010/5/10 Bernhard Loos :
> 2010/5/10 Matthias Buecher / Germany :
>> The "linux" partition spans over the kernel and the complete rootfs for
>> flashing.
>> The maximum kernel size is 0x000bc000 (begin of "rootfs") minus
>> 0x0004 (begin of "linux") equals 0x0007c000 (496KB).
>>
>> Maddes
>
>
Then it'd make total sense to stuff in whatever fits there .. thanks for
the enlightenment, ede
On 10.05.2010 23:38, Matthias Buecher / Germany wrote:
> The "linux" partition spans over the kernel and the complete rootfs for
> flashing.
> The maximum kernel size is 0x000bc000 (begin of "rootfs") m
2010/5/10 Matthias Buecher / Germany :
> The "linux" partition spans over the kernel and the complete rootfs for
> flashing.
> The maximum kernel size is 0x000bc000 (begin of "rootfs") minus
> 0x0004 (begin of "linux") equals 0x0007c000 (496KB).
>
> Maddes
This is not the maximum kernel size,
The "linux" partition spans over the kernel and the complete rootfs for
flashing.
The maximum kernel size is 0x000bc000 (begin of "rootfs") minus
0x0004 (begin of "linux") equals 0x0007c000 (496KB).
Maddes
On 10.05.2010 23:34, edgar.sol...@web.de wrote:
> are these sizes fixed or calculated a
are these sizes fixed or calculated according the space requirement?
Looks like the linux size is fixed, what is the maximum size for a
kernel on wrt54g?
.. ede
On 10.05.2010 23:28, Matthias Buecher / Germany wrote:
> Kernel and rootfs are in two different mtd partitions on the WRT54G:
>
> # dme
Kernel and rootfs are in two different mtd partitions on the WRT54G:
# dmesg
...
Creating 5 MTD partitions on "Physically mapped flash":
0x-0x0004 : "cfe"
0x0004-0x003f : "linux"
0x000bc000-0x0021 : "rootfs"
mtd: partition "rootfs" doesn't start on an erase block boundary -
but wouldn't the increase in the kernel image actually equal the
decrease in the squash image and therefore the size of the rootfs_data
stay the same? Both are lzma compressed.
..ede
On 10.05.2010 19:16, Matthias Buecher / Germany wrote:
> It may not downsize the packages themselves, but moving
It may not downsize the packages themselves, but moving kernel mods from
rootfs to the kernel image will reduce the rootfs size. Leaving more
space for JFFS2 rootfs_data.
Having a "K" setting for kernel options would be great.
Will try to have a look at it during the next weeks.
Thanks for all yo
there is partly in
https://dev.openwrt.org/browser/trunk/include/kernel-defaults.mk
line 101
you can actually add
CONFIG_KERNEL_*
entries to your .config and they are copied over as CONFIG_* to the
kernel config. All that's missing is a menuconfig interface for that.
But at least for routers u
> In 'make menuconfig' I included them with 'Y' instead of 'M'.
> According to my (newbie) knowledge that adds them to the kernel image.
> Can somebody please confirm my understanding? Or at least prove me wrong? :D
Damn! I thought you had found a clever way to get them compiled into
the kernel.
I
Re-checked the configs from my last build (available at
ftp://ftp.maddes.net/openwrt/backfire/brcm-2.4/build_21402/squashfs/)
In the menu config it is "CONFIG_PACKAGE_kmod-tun=y", but in the kernel
and final/used config it is "CONFIG_TUN=m".
So the better squashfs compression was what helped me.
T
If you are really bored, you could use gcc 4.5 and link time optimization.
Support for it is already enabled in the openwrt gcc, but you have to
add the compiler flags to use it to packages and/or the kernel. In
theory, it could reduce the binary size, but I have no idea how well
this will work in
Sorry, my description was inaccurate.
In 'make menuconfig' the sign is '*' when pressing 'Y' and in the
resulting config file it is '=Y'.
@Bernhard:
So this adds kernel modules to the squashfs image and not to the kernel
image, and therefore I only benefitted from the better squashfs compression?
true, my bad, actually one can see it in the end of a make run, how the
packages (incl. kmods) are installed to the image filesystem.
thanks ede
On 09.05.2010 18:19, Bernhard Loos wrote:
> Actually, Y in menuconfig doesn't add the modules into the kernel,
> they will still be kernel modules. It o
Actually, Y in menuconfig doesn't add the modules into the kernel,
they will still be kernel modules. It only places the modules directly
in the image and is in no way different from Y for programs. M creates
packages for the modules/program without placing it in the image.
If you want to compile a
That's how it works. Y adds kernel modules to the kernel, and programs
to the image.
..ede
On 09.05.2010 18:10, Matthias Buecher / Germany wrote:
> In 'make menuconfig' I included them with 'Y' instead of 'M'.
> According to my (newbie) knowledge that adds them to the kernel image.
> Can somebody
In 'make menuconfig' I included them with 'Y' instead of 'M'.
According to my (newbie) knowledge that adds them to the kernel image.
Can somebody please confirm my understanding? Or at least prove me wrong? :D
Maddes
On 09.05.2010 17:56, Stefan Monnier wrote:
>> Put all kmods (2) I needed into th
> Put all kmods (2) I needed into the kernel.
How?
Stefan
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
I could finally install everything onto my 4MB WRT54g v2.2.
Avoided ntpclient plus dependencies with the patch from #7316.
Added BusyBox's ether-wake to the build.
Put all kmods (2) I needed into the kernel.
This freed up enough JFFS2 space to normally install OpenVPN and a
web-interface (here web
* Matthias Buecher / Germany [04.05.2010 16:30]:
> Can I save space in the flash mem when I add all needed packages
> directly to the image?
yes.
> Or is the JFFS2 compression as good as the compression of the read-only
> squashfs?
no. bye, Bastian.
signature.asc
Description: Digital signatur
Can I save space in the flash mem when I add all needed packages
directly to the image?
Or is the JFFS2 compression as good as the compression of the read-only
squashfs?
I'm also going to replace ntpclient with rdate.
As the clock of the WRT54G is very inaccurate it will not be sufficient
to updat
* Matthias Buecher / Germany [30.04.2010 22:30]:
> Can OpenVPN be compiled to a smaller size?
nossl/nolzo - phew!
bye, Bastian
signature.asc
Description: Digital signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.
31 matches
Mail list logo
