Re: [OpenWrt-Devel] Bounty: /overlay on x86
On 03/07/12 19:37, Kristian Kielhofner wrote: Is /overlay supported on x86? Am I missing something here? Yes they are and I have a confirmed working setup on x86 with a squashfs rootfs and an ext4 overlay, however as someone else has pointed out initramfs is different. The way that overlays work from reading the bash scripts requires pivot_root changing the mount point of the rootfs to /rom and then mounting up the overlay, however initramfs doesn't have the concept of pivot_root and so you can't pivot it to make the overlay work. Also I'm not sure how the overlay mechanics interact with initramfs as initramfs is part of the blockcaching layer but from reading the kernel documentation file ramfs-rootfs-initramfs.txt I think that what you can do it is copy the contents of your initramfs into the partition you want to use to store state and then switch with switch_root to that partition. -- Tim Fletcher t...@night-shade.org.uk ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Bounty: /overlay on x86
Dear Sirs: Pardon, I know I am a rookie here. I just wanna say that I found There is overlayfs implement in Ubuntu 12.04 install Disk. And of course it's for x86. Best Rgds, anton -- refered: http://askubuntu.com/questions/109413/how-do-i-use-overlayfs 2012/7/11 Tim Fletcher t...@night-shade.org.uk On 03/07/12 19:37, Kristian Kielhofner wrote: Is /overlay supported on x86? Am I missing something here? Yes they are and I have a confirmed working setup on x86 with a squashfs rootfs and an ext4 overlay, however as someone else has pointed out initramfs is different. The way that overlays work from reading the bash scripts requires pivot_root changing the mount point of the rootfs to /rom and then mounting up the overlay, however initramfs doesn't have the concept of pivot_root and so you can't pivot it to make the overlay work. Also I'm not sure how the overlay mechanics interact with initramfs as initramfs is part of the blockcaching layer but from reading the kernel documentation file ramfs-rootfs-initramfs.txt I think that what you can do it is copy the contents of your initramfs into the partition you want to use to store state and then switch with switch_root to that partition. -- Tim Fletcher t...@night-shade.org.uk __**_ openwrt-devel mailing list openwrt-devel@lists.openwrt.**org openwrt-devel@lists.openwrt.org https://lists.openwrt.org/**mailman/listinfo/openwrt-develhttps://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Build problems with Eglibc and curl
Travis Felix: I can't get Curl to build with eglibc 2.14 (and if I remember, 2.15): OpenWrt-libtool: compile: i486-openwrt-linux-gnu-gcc -DHAVE_CONFIG_H -I../include/curl -I../include -I../include -I../lib -I../lib -isystem /home/philipp/openwrt-alix/staging_dir/target-i386_eglibc-2.14.1/usr/include -isystem /home/philipp/openwrt-alix/staging_dir/target-i386_eglibc-2.14.1/include -isystem /home/philipp/openwrt-alix/staging_dir/toolchain-i386_gcc-4.6-linaro_eglibc-2.14.1/usr/include -isystem /home/philipp/openwrt-alix/staging_dir/toolchain-i386_gcc-4.6-linaro_eglibc-2.14.1/include -I/home/philipp/openwrt-alix/staging_dir/target-i386_eglibc-2.14.1/usr/include -I/home/philipp/openwrt-alix/staging_dir/target-i386_eglibc-2.14.1/usr/include/openssl -I/home/philipp/openwrt-alix/staging_dir/target-i386_eglibc-2.14.1/usr/include -march=geode -Os -mmmx -m3dnow -fno-align-jumps -fno-align-functions -fno-align-labels -fno-align-loops -pipe -fomit-frame-pointer -fhonour-copts -Wno-error=unused-but-set-variable -fpic -g0 -Wno-system-headers -MT curl_addrinfo.lo -MD -MP -MF .deps/curl_addrinfo.Tpo -c curl_addrinfo.c -fPIC -DPIC -o .libs/curl_addrinfo.o In file included from curl_addrinfo.c:50:0: curl_addrinfo.h:78:25: warning: 'struct hostent' declared inside parameter list [enabled by default] curl_addrinfo.c:274:25: warning: 'struct hostent' declared inside parameter list [enabled by default] curl_addrinfo.c:274:1: error: conflicting types for 'Curl_he2ai' curl_addrinfo.h:78:1: note: previous declaration of 'Curl_he2ai' was here curl_addrinfo.c: In function 'Curl_he2ai': curl_addrinfo.c:293:22: error: dereferencing pointer to incomplete type curl_addrinfo.c:307:28: error: dereferencing pointer to incomplete type curl_addrinfo.c:327:23: error: dereferencing pointer to incomplete type curl_addrinfo.c:342:45: error: dereferencing pointer to incomplete type curl_addrinfo.c: At top level: curl_addrinfo.c:370:18: error: field 'hostentry' has incomplete type curl_addrinfo.c: In function 'Curl_ip2addr': curl_addrinfo.c:440:4: error: dereferencing pointer to incomplete type curl_addrinfo.c:441:4: error: dereferencing pointer to incomplete type curl_addrinfo.c:442:4: error: dereferencing pointer to incomplete type curl_addrinfo.c:443:4: error: dereferencing pointer to incomplete type curl_addrinfo.c:444:4: error: dereferencing pointer to incomplete type curl_addrinfo.c:445:4: error: dereferencing pointer to incomplete type curl_addrinfo.c:446:4: error: dereferencing pointer to incomplete type curl_addrinfo.c:454:3: warning: passing argument 1 of 'Curl_he2ai' from incompatible pointer type [enabled by default] curl_addrinfo.c:274:1: note: expected 'const struct hostent *' but argument is of type 'struct hostent *' make[5]: *** [curl_addrinfo.lo] Error 1 make[5]: Leaving directory `/home/philipp/openwrt-alix/build_dir/target-i386_eglibc-2.14.1/curl-7.23.1/lib' make[4]: *** [install-recursive] Error 1 make[4]: Leaving directory `/home/philipp/openwrt-alix/build_dir/target-i386_eglibc-2.14.1/curl-7.23.1' make[3]: *** [/home/philipp/openwrt-alix/build_dir/target-i386_eglibc-2.14.1/curl-7.23.1/.built] Error 2 make[3]: Leaving directory `/home/philipp/openwrt-alix/feeds/packages/libs/curl' make[2]: *** [package/feeds/packages/curl/compile] Error 2 make[2]: Leaving directory `/home/philipp/openwrt-alix' make[1]: *** [/home/philipp/openwrt-alix/staging_dir/target-i386_eglibc-2.14.1/stamp/.package_compile] Error 2 make[1]: Leaving directory `/home/philipp/openwrt-alix' make: *** [world] Error 2 This is from updating trunk yesterday afternoon. Any idea what's going on? And are we building x86 + eglibc as a builbot target now so that commit damage turns up more quickly? Thanks, -Philip ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] BCM4706 and bcma: Skipping PCI bus scan due to resource conflict
On 07/11/2012 03:25 PM, Rafał Miłecki wrote: 2012/7/11 Rafał Miłecki zaj...@gmail.com: My main bcma bus has 2 PCIe slots with 2 802.11 cards. The problem is that only one card can be registered at the time. Function responsible for registering PCI controller is: void __devinit bcma_core_pci_hostmode_init(struct bcma_drv_pci *pc) The problem is that bcma uses the same IO resource for both controllers: pc_host-io_resource.name = BCMA PCIcore external I/O, pc_host-io_resource.start = 0x100; pc_host-io_resource.end = 0x7FF; pc_host-io_resource.flags = IORESOURCE_IO | IORESOURCE_PCI_FIXED; My root io_resource is 0x to 0x but kernel doesn't allow to register two controllers with overlapping IO resource (0x100 to 0x7FF). When bcma calls register_pci_controller, it fails at: if (request_resource(ioport_resource, hose-io_resource) 0) for the second controller. I haven't thought about this problem when having two PCIe controllers. Any idea how to find out, what IO resource we should set for second controller? I've hacked bcma to set (some random start, just over 0x7FF): pc_host-io_resource.start = 0x850; pc_host-io_resource.end = 0xF4F; for second PCIe controller. Card connected to that controller was successfully detected and initialized. I do not know if that is a valid way to got, I do not have much knowledge about PCI and was happy that this code worked with my device. Hauke: how did you find out that pc_host-io_resource.start = 0x100; This is from static u32 pci_iobase = 0x100; in src-rt-6.x/linux/linux-2.6/arch/mips/brcm-boards/bcm947xx/pcibios.c from the Broadcom SDK. When looking into that file be aware that the pci bus number 0 is the main sb/ai bus in that code. pc_host-io_resource.end = 0x7FF; I do not know where I got the size from any more. ? ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [Patch] 64 bit network interface stats in luci
One thing that has annoyed me for a long time on Linux systems is when the network interface stats overflow at 32bit. Later versions of the kernel support 64 bit stats on a 32 bit system to fix this. However the current trunk version of openwrt and luci truncate the stats back to 32 bit. Not all kernel drivers are updated to support the new APIs but many are such as the bridge and vlan drivers. On a typical router with a just a DHCP connection for the WAN interface this is enough to get 64 bit stats on your LAN (bridge) and WAN (vlan) interface. Unfortunately the PPPOE driver still only supports 32 bit stats. To get the luci interface to show 64 bit stats I had to make a couple small changes to the netifd and luci packages. For netifd I basically just changed blobmsg_add_u32 to blobmsg_add_u64 in the system_if_stats function and modified types and such accordingly. luci was using a function in network.lua named uint on the stats data from netifd. However, I think blobmsg_add_u64 actually passes the data as a string which the uint function cannot handle. I replaced the contents of the uint function with simply return tonumber(x) or 0 to make it work. This is probably not the best way to fix it but I know almost nothing about lua. In the future I plan to look into patching some of the kernel drivers such as b43, b44 and PPPOE to also support 64 bits stats... but I might never actually get around to it. b44 looked like it might be relatively easy, PPPOE looked a lot more confusing and I haven't looked at b43 at all yet. I am not sure exactly how I am supposed to include the patch files in this message. I know the preferred method is to inline the patch but this is actually two patches to two different packages. Maybe I should send them in two separate posts? For now I will just attached them to this post. These patches were tested on x86 and a wrt54gs with a recent trunk version of openwrt. Signed-off-by: Kevin Groeneveld kgroenev...@gmail.com --- netifd_64_bit_stats.patch Description: Binary data luci_64_bit_stats.patch Description: Binary data ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [Patch] 64 bit network interface stats in luci
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 The LuCI patch will not properly work that way, OpenWrt Lua does not handle numeric integer values 2^31 bit. A somewhat larger range can be stored as float but the precision is not enough: # lua -e 'print(string.format(%d, tonumber(18446744073709551615)))' lua: (command line):1: bad argument #2 to 'format' (integer expected, got number) # lua -e 'print(string.format(%f, tonumber(18446744073709551615)))' 18446744073709553000.00 Probably needs to be divided into two 32bit hi and lo parts on the Lua side. ~ Jow -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/+KGYACgkQdputYINPTPMnkwCeKu0D429ZS7HO7CfQvZ07lAgW ZP0An0J/UK8Tt9OEQHl3pBA+vPE0P/mU =TaHG -END PGP SIGNATURE- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
