Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision		 Previous revision
docs:guide-developer:add.new.device [2018/02/17 17:18] – ↷ Links adapted because of a move operation bobafetthotmaildocs:guide-developer:add.new.device [2022/03/23 12:00] (current) – adding filename for scripts, so that when users post their result they will be able to refer a specific output associated with which script aterik
Line 1: Line 1:
 ====== Adding new device support ====== ====== Adding new device support ======
  
-This article assumes your device is based on a platform already supported by OpenWrt. If you need to add a new platform, see ->[[doc/devel/add.new.platform]]+This article assumes your device is based on a platform already supported by OpenWrt. If you need to add a new platform, see ->[[docs:guide-developer:add.new.platform]]
  
 +If you already solved the puzzle and are looking for device support submission guidelines, check out [[docs:guide-developer:device-support-policies|Device support policies / best practices]]
 ===== General Approach ===== ===== General Approach =====
  
-  - Make a detailed list of chips on the device and find info about support for them. Focus on processor, flash, ethernet and wireless. Some helpful tips are available on [[doc:devel:hw.hacking.first.steps]]+  - Make a detailed list of chips on the device and find info about support for them. Focus on processor, flash, ethernet and wireless. Some helpful tips are available on [[docs:guide-developer:hw.hacking.first.steps]]
   - Make sure you have working serial console and access to the bootloader.   - Make sure you have working serial console and access to the bootloader.
   - Prepare and install firmware, watch the bootlog for problems and errors.   - Prepare and install firmware, watch the bootlog for problems and errors.
Line 12: Line 13:
 ===== GPIOs ===== ===== GPIOs =====
  
-Most of devices use [[doc/hardware/port.gpio|GPIOs]] for controlling LEDs and buttons. There aren't any generic GPIOs numbers, so OpenWrt has to use device specific mappings. It means we need to find out GPIOs for every controllable LED and button on every supported device.+Most of devices use [[docs:techref:hardware:port.gpio|GPIOs]] for controlling LEDs and buttons. There aren't any generic GPIOs numbers, so OpenWrt has to use device specific mappings. It means we need to find out GPIOs for every controllable LED and button on every supported device.
  
 ==== GPIO LEDs ==== ==== GPIO LEDs ====
Line 43: Line 44:
 To speed up testing all GPIOs one by one you can use following bash script. Please note you have to follow LEDs state and console output. If the USB LED turns on and the last console message is ''[GPIO12] Trying value 0'' it means USB LED uses GPIO 12 and is active low. To speed up testing all GPIOs one by one you can use following bash script. Please note you have to follow LEDs state and console output. If the USB LED turns on and the last console message is ''[GPIO12] Trying value 0'' it means USB LED uses GPIO 12 and is active low.
  
-<code>#!/bin/sh+<file bash gpio-test.sh>#!/bin/sh
 GPIOCHIP=0 GPIOCHIP=0
 BASE=$(cat /sys/class/gpio/gpiochip${GPIOCHIP}/base) BASE=$(cat /sys/class/gpio/gpiochip${GPIOCHIP}/base)
Line 65: Line 66:
  }  }
  gpio=$((gpio+1))  gpio=$((gpio+1))
-done</code>+done 
 +</file> 
 +  * Save the above content as a file ''gpio-test.sh'' & then transfer inside router's ''/tmp'' directory, or copy above content & paste inside ''vi'' editor in router & save as ''gpio-test.sh'' file. 
 +  * to make it executable, run: ''chmod +x /tmp/gpio-test.sh''
  
 ==== GPIO buttons ==== ==== GPIO buttons ====
Line 77: Line 81:
 For dumping GPIO values following script can be used: For dumping GPIO values following script can be used:
  
-<code>#!/bin/sh+<file bash gpio-dump.sh>#!/bin/sh
 GPIOCHIP=0 GPIOCHIP=0
 BASE=$(cat /sys/class/gpio/gpiochip${GPIOCHIP}/base) BASE=$(cat /sys/class/gpio/gpiochip${GPIOCHIP}/base)
Line 91: Line 95:
  }  }
  gpio=$((gpio+1))  gpio=$((gpio+1))
-done</code>+done 
 +</file> 
 +  * Save the above content as a file ''gpio-dump.sh'' & then transfer inside router's ''/tmp'' directory, or copy above content & paste inside ''vi'' editor in router & save as ''gpio-dump.sh'' file 
 +  * to make it executable, run: ''chmod +x /tmp/gpio-dump.sh''
  
 If GPIO value changes from 1 to 0 while pressing the button, it's active low. Otherwise it's active high. If GPIO value changes from 1 to 0 while pressing the button, it's active low. Otherwise it's active high.
Line 102: Line 109:
  
 ==== KSEG1ADDR() and accessing NOR flash ==== ==== KSEG1ADDR() and accessing NOR flash ====
-For getting MAC addresses, EEPROM and other calibration data for your board, you may need to read from flash in the kernel. In the case of many Atheros chips using NOR flash, done using the KSEG1ADDR() macro which translates the hardware address of the flash to the virtual address for the process context which is executing your init function. If you are reviewing the code for initializing a board similar to your own and you see this idium: KSEG1ADDR(0x1fff0000), the number at first appears to be magic but it is logical if you understand two things. Firstly, Atheros SoCs using NOR flash wire it to the physical address 0x1f000000 (there are no guarantees about where the flash will be wired for your board but this is a common location). You cannot rely on the address given in the bootloader, you might see 0xbf000000 but this is probably also a virtual address. If your board wires flash to these memory locations, you may obviously access flash using KSEG1ADDR(0x1f000000 + OFFSET_FROM_BEGIN) but in the event that you have to access data which you know will exist at the very end of the flash, you can use a trick to make your code compatible with multiple sizes of flash memory. Often flash will be mapped to a full 16MB of address space no matter whether it is 4MB, 8MB or 16MB so in this case KSEG1ADDR(0x20000000 - OFFSET_FROM_END) will work for accessing things which you know to be a certain distance from the end of the flash memory. When you see KSEG1ADDR(0x1fff0000), on devices with 4MB or 8MB of flash, it's fair to guess that it's using this trick to reference the flash which resides 64k below the end of the flash (where Atheros Radio Test data is stored).+For getting MAC addresses, EEPROM and other calibration data for your board, you may need to read from flash in the kernel. In the case of many Atheros chips using NOR flash, done using the KSEG1ADDR() macro which translates the hardware address of the flash to the virtual address for the process context which is executing your init function.  
 + 
 +If you are reviewing the code for initializing a board similar to your own and you see this idium: KSEG1ADDR(0x1fff0000), the number at first appears to be magic but it is logical if you understand two things. Firstly, Atheros SoCs using NOR flash wire it to the physical address 0x1f000000 (there are no guarantees about where the flash will be wired for your board but this is a common location). You cannot rely on the address given in the bootloader, you might see 0xbf000000 but this is probably also a virtual address. If your board wires flash to these memory locations, you may obviously access flash using KSEG1ADDR(0x1f000000 + OFFSET_FROM_BEGIN) but in the event that you have to access data which you know will exist at the very end of the flash, you can use a trick to make your code compatible with multiple sizes of flash memory.  
 + 
 +Often flash will be mapped to a full 16MB of address space no matter whether it is 4MB, 8MB or 16MB so in this case KSEG1ADDR(0x20000000 - OFFSET_FROM_END) will work for accessing things which you know to be a certain distance from the end of the flash memory. When you see KSEG1ADDR(0x1fff0000), on devices with 4MB or 8MB of flash, it's fair to guess that it's using this trick to reference the flash which resides 64k below the end of the flash (where Atheros Radio Test data is stored).
  
 ===== Examples ===== ===== Examples =====
  
 ==== Brcm63xx Platform ==== ==== Brcm63xx Platform ====
-If you have the OEM sourcecode for your [[doc/hardware/soc/soc.broadcom.bcm63xx|bcm63xx]] specific device, it may be useful some things for later adding the OpenWrt support:+If you have the OEM sourcecode for your [[docs:techref:hardware:soc:soc.broadcom.bcm63xx|bcm63xx]] specific device, it may be useful some things for later adding the OpenWrt support:
   * Look for your Board Id at ''shared/opensource/boardparms/boardparms.c''   * Look for your Board Id at ''shared/opensource/boardparms/boardparms.c''
   * Adapt the ''imagetag.c'' to create a different tag (see ''shared/opensource/inlude/bcm963xx/bcmTag.h'' in the GPL tar for the layout)   * Adapt the ''imagetag.c'' to create a different tag (see ''shared/opensource/inlude/bcm963xx/bcmTag.h'' in the GPL tar for the layout)
Line 113: Line 124:
 (from [[https://forum.openwrt.org/viewtopic.php?pid=123105#p123105]]) (from [[https://forum.openwrt.org/viewtopic.php?pid=123105#p123105]])
  
-For creating the OpenWrt firmware your [[doc/hardware/soc/soc.broadcom.bcm63xx|bcm63xx]] device, you can follow the following steps:+For creating the OpenWrt firmware your [[docs:techref:hardware:soc:soc.broadcom.bcm63xx|bcm63xx]] device, you can follow the following steps:
  
-  - Obtain the [[doc:howto:build|source and follow the compile procedure]] with the make menuconfig as last step.+  - Obtain the [[docs:guide-developer:toolchain:start|source and follow the compile procedure]] with the make menuconfig as last step.
   - During **menuconfig** select the correct target system.   - During **menuconfig** select the correct target system.
   - Next generate the board_bcm963xx.c file for the selected platform with all board parameters execute the following command: \\ <code>make kernel_menuconfig</code>   - Next generate the board_bcm963xx.c file for the selected platform with all board parameters execute the following command: \\ <code>make kernel_menuconfig</code>
Line 146: Line 157:
  &board_DV2020,  &board_DV2020,
 </code> </code>
-  - Finish the [[doc:howto:build|compile instructions]] according the procedure from the make step.+  - Finish the [[docs:guide-developer:toolchain:start|compile instructions]] according the procedure from the make step.
  
 ==== Ramips Platform ==== ==== Ramips Platform ====
  • Last modified: 2018/02/17 17:18
  • by bobafetthotmail