Re: [OpenWrt-Devel] [PATCH] ar71xx: enable building of ramdisk images for WZRHPG30XNH boards
2013.03.04. 1:32 keltezéssel, Luka Perkov írta: Signed-off-by: Luka Perkov l...@openwrt.org ACK. -Gabor ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Option GlobeSurfer II 7.2 NVRAM contents
On Fri, Mar 1, 2013 at 8:20 PM, Rafał Miłecki zaj...@gmail.com wrote:
2013/3/1 Tijs Van Buggenhout t...@able.be:
On Friday 01 March 2013 19:44:28 Fiach Antaw wrote:
Maybe you can try a tftp boot of the new openwrt (elf) image via CFE,
avoiding
to flash the device?
http://wiki.openwrt.org/doc/hardware/soc/soc.broadcom.bcm47xx#network.boot
Try that and verify if partition board_data was detected by the
Linux. I suggest building 3.8 based bcm47xx firmware, as it uses
bcm47xxpart driver which should handle board_data (detect it).
I've previously tried booting a standard kernel image (generic BCM47XX
with b44/all profile, no changes) via CFE, but CFE on this system
locates itself at 0x8030 whilst the kernel ELF is loaded at
0x8000, and the kernel generated by that profile was slightly over
3MB (overlapping the CFE code region and causing it to refuse to load
the ELF). I imagine a kernel built with fewer statically linked
modules would fit, but I didn't test that. I have flashed working
images onto the device through the CFE and booted them without issue,
though.
The flash layout used by this device (and perhaps other OpenRG-based
platforms) is different from what I understand to be the normal
broadcom layout: It's divided into partitions by a (possibly
hard-coded) partition table, and each partition starts with a header
containing a magic number ('0xFEEDBABE') and details about the
partition contents (checksum, length, et cetera). The partitions
themselves contain the CFE, primary and backup kernel/rootfs images
(TRX format), a cramfs image containing some (probably
carrier-specific) image and other static files for the web interface,
OpenRG configuration data and the NVRAM. Booting a mostly functional
OpenWRT image was just a matter of adding code to skip over the
partition header and fix the boot partition checksum after first boot,
and flashing the image to the primary/backup boot partitions.
As far as I can tell, none of these partitions contain the
'board_data' magic number used by the bcm47xxpart driver to detect the
board_data partition (it doesn't seem to appear anywhere in the entire
flash). I'm not sure this device even has a board_data partition, it
looks like only the CFE and probably NVRAM partitions seem to be
important for initial bootstrapping (at least, I've erased everything
but those without issue).
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 001/003] [ar71xx] add kernel support for dir-835-a1
03.03.2013 13:58, schrieb Gabor Juhos:
2013.02.27. 12:49 keltezéssel, Alexander Stadler írta:
From: Alexander Stadler sa.mailli...@univie.ac.at
kernel support for dir-835-a1
Signed-off-by: Alexander Stadler sa.mailli...@univie.ac.at
---
diff -urN a/target/linux/ar71xx/config-3.7 b/target/linux/ar71xx/config-3.7
--- a/target/linux/ar71xx/config-3.7 2013-02-24 18:43:51.0 +0100
+++ b/target/linux/ar71xx/config-3.7 2013-02-24 18:47:45.0 +0100
@@ -40,6 +40,7 @@
CONFIG_ATH79_MACH_DIR_615_C1=y
CONFIG_ATH79_MACH_DIR_825_B1=y
CONFIG_ATH79_MACH_DIR_825_C1=y
+CONFIG_ATH79_MACH_DIR_835_A1=y
CONFIG_ATH79_MACH_EAP7660D=y
CONFIG_ATH79_MACH_EW_DORIN=y
CONFIG_ATH79_MACH_HORNET_UB=y
diff -urN a/target/linux/ar71xx/files/arch/mips/ath79/mach-dir-835-a1.c
b/target/linux/ar71xx/files/arch/mips/ath79/mach-dir-835-a1.c
--- a/target/linux/ar71xx/files/arch/mips/ath79/mach-dir-835-a1.c
1970-01-01 01:00:00.0 +0100
+++ b/target/linux/ar71xx/files/arch/mips/ath79/mach-dir-835-a1.c
2013-02-24 18:46:24.0 +0100
@@ -0,0 +1,179 @@
+/*
+ * D-Link DIR-835 rev. A1 board support
+ *
+ * Copyright (C) 2013 Alexander Stadler
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published
+ * by the Free Software Foundation.
+ */
+
+#include linux/pci.h
+#include linux/phy.h
+#include linux/gpio.h
+#include linux/platform_device.h
+#include linux/ath9k_platform.h
+#include linux/ar8216_platform.h
+
+#include asm/mach-ath79/ar71xx_regs.h
+
+#include common.h
+#include dev-ap9x-pci.h
+#include dev-eth.h
+#include dev-gpio-buttons.h
+#include dev-leds-gpio.h
+#include dev-m25p80.h
+#include dev-spi.h
+#include dev-usb.h
+#include dev-wmac.h
+#include machtypes.h
+
+#define DIR835A1_GPIO_LED_ORANGE_POWER 14
+#define DIR835A1_GPIO_LED_GREEN_POWER 22
+#define DIR835A1_GPIO_LED_BLUE_WPS 15
+#define DIR835A1_GPIO_LED_ORANGE_PLANET 19
+#define DIR835A1_GPIO_LED_GREEN_PLANET 18
+
+#define DIR835A1_GPIO_BTN_RESET 17
+#define DIR835A1_GPIO_BTN_WPS 16
+
+#define DIR835A1_KEYS_POLL_INTERVAL 20 /* msecs */
+#define DIR835A1_KEYS_DEBOUNCE_INTERVAL (3 *
DIR835A1_KEYS_POLL_INTERVAL)
+
+#define DIR835A1_MAC0_OFFSET0x4
+#define DIR835A1_MAC1_OFFSET0x18
+#define DIR835A1_WMAC_CALDATA_OFFSET0x1000
+#define DIR835A1_PCIE_CALDATA_OFFSET0x5000
+
+static struct gpio_led dir835a1_leds_gpio[] __initdata = {
+{
+.name = d-link:orange:power,
+.gpio = DIR835A1_GPIO_LED_ORANGE_POWER,
+.active_low = 1,
+},
+{
+.name = d-link:green:power,
+.gpio = DIR835A1_GPIO_LED_GREEN_POWER,
+.active_low = 1,
+},
+{
+.name = d-link:blue:wps,
+.gpio = DIR835A1_GPIO_LED_BLUE_WPS,
+.active_low = 1,
+},
+{
+.name = d-link:orange:planet,
+.gpio = DIR835A1_GPIO_LED_ORANGE_PLANET,
+.active_low = 1,
+},
+{
+.name = d-link:green:planet,
+.gpio = DIR835A1_GPIO_LED_GREEN_PLANET,
+.active_low = 1,
+},
+};
+
+static struct gpio_keys_button dir835a1_gpio_keys[] __initdata = {
+{
+.desc = reset,
+.type = EV_KEY,
+.code = KEY_RESTART,
+.debounce_interval = DIR835A1_KEYS_DEBOUNCE_INTERVAL,
+.gpio = DIR835A1_GPIO_BTN_RESET,
+.active_low = 1,
+},
+{
+.desc = wps,
+.type = EV_KEY,
+.code = KEY_WPS_BUTTON,
+.debounce_interval = DIR835A1_KEYS_DEBOUNCE_INTERVAL,
+.gpio = DIR835A1_GPIO_BTN_WPS,
+.active_low = 1,
+},
+};
+
+static struct ar8327_pad_cfg dir835a1_ar8327_pad0_cfg = {
+.mode = AR8327_PAD_MAC_RGMII,
+.txclk_delay_en = true,
+.rxclk_delay_en = true,
+.txclk_delay_sel = AR8327_CLK_DELAY_SEL1,
+.rxclk_delay_sel = AR8327_CLK_DELAY_SEL2,
+};
+
+static struct ar8327_platform_data dir835a1_ar8327_data = {
+.pad0_cfg = dir835a1_ar8327_pad0_cfg,
+.port0_cfg = {
+.force_link = 1,
+.speed = AR8327_PORT_SPEED_1000,
+.duplex = 1,
+.txpause = 1,
+.rxpause = 1,
+},
+};
+
+static struct mdio_board_info dir835a1_mdio0_info[] = {
+{
+.bus_id = ag71xx-mdio.0,
+.phy_addr = 0,
+.platform_data = dir835a1_ar8327_data,
+},
+};
Re: [OpenWrt-Devel] [PATCH 001/003] [ar71xx] add kernel support for dir-835-a1
Hi Alex, I also thought on this for a moment. But: I found no examples which did this like it shoud be done here. But could be that I've overseen such one. The leds have different colors so names so the struct gpio_led will be different (besides fewer leds in general..). To not get confused about the names (which include color..) also the defines for them could or should be additional ones. Having two structs for the leds, two dirxxx_setup's with the different ath79_register_leds_gpio calls, and to be exact without the usb led and switch leds (so a second different struct) didn't seem a small change for the .c file. More like two of them done in one. After that, I thought its more straightforward to make an own one. Don't u think so too? Adding another structure with five LEDs is not a big deal. Alternatively the LED names can be changed from the setup routine. For the switch LED configuration, you don't need another structure. Simply set the led_cfg field to NULL. Else, how have the MIPS_MACHINE(ATH79_MACH_DIR_835_A1, DIR-835-A1, D-Link DIR-835 rev. A1, dir835a1_setup); part(s) to look like in the 825-c1.c to be able to decide which function to call for each model? And this will be enough? You can create a common setup function for the generic parts and then call that from the model specific setup routine. See how it is done in the 'mach-tl-mr3x20.c' and in the 'mach-rb4xx.c' files for example. -Gabor ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 001/003] [ar71xx] add kernel support for dir-835-a1
Am 04.03.2013 14:56, schrieb Gabor Juhos: Hi Alex, I also thought on this for a moment. But: I found no examples which did this like it shoud be done here. But could be that I've overseen such one. The leds have different colors so names so the struct gpio_led will be different (besides fewer leds in general..). To not get confused about the names (which include color..) also the defines for them could or should be additional ones. Having two structs for the leds, two dirxxx_setup's with the different ath79_register_leds_gpio calls, and to be exact without the usb led and switch leds (so a second different struct) didn't seem a small change for the .c file. More like two of them done in one. After that, I thought its more straightforward to make an own one. Don't u think so too? Adding another structure with five LEDs is not a big deal. Alternatively the LED names can be changed from the setup routine. For the switch LED configuration, you don't need another structure. Simply set the led_cfg field to NULL. Else, how have the MIPS_MACHINE(ATH79_MACH_DIR_835_A1, DIR-835-A1, D-Link DIR-835 rev. A1, dir835a1_setup); part(s) to look like in the 825-c1.c to be able to decide which function to call for each model? And this will be enough? You can create a common setup function for the generic parts and then call that from the model specific setup routine. See how it is done in the 'mach-tl-mr3x20.c' and in the 'mach-rb4xx.c' files for example. -Gabor So as far as I can see the name needs to be generalized in target/linux/ar71xx/config-3.7 (in target/linux/ar71xx/patches-3.7/6xx-MIPS-ath79-add-) arch/mips/ath79/Kconfig arch/mips/ath79/Makefile and could stay splitted like it is for the rest? But I still don't really see the benefit of this added complexity.. . As I also could say all db120's should go into one .c . Alex ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Nokia n810 rebirth
--- Hi, I've just finished the job of learning the OpenWRT environment enough to fix the various build problems with the Nokia N810 support in OpenWRT. I worked against the trunk, and submitted the necessary fixes as tickets. Is there a dev for this target any more? Thanks, Andy Valencia ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Compile linux with tracing support
On Sat, 2013-03-02 at 15:55 +0100, Luca Dariz wrote: Hi, i'm trying to build the kernel with tracing support for a lantiq target on svn r35820. I enabled tracing options in menuconfig (Global build settings) and it's ok, but if i enable some additional tracers in kernel_menuconfig (Kernel hacking - Tracers) it fails with errors like: CC init/main.o init/main.c:1:0: warning: -ffunction-sections disabled; it makes profiling impossible [enabled by default] Am i missing some config option? Thanks, Luca There was discussion recently on MIPS kernel list about a problem with 32 bit function tracing. I had made a mental note to follow it up, but haven't got there yet. [PATCH] mips: function tracer: Fix broken function tracing http://thread.gmane.org/gmane.linux.kernel/1420616 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
