d/freebsd-dev
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
64cb5e2a26
freebsd-dev/sys/mips/conf/TP-WN1043ND.hints

134 lines
3.2 KiB
Plaintext
Raw Normal View History

Commit configuration files for the AR913x SoC and the TP-Link WR-1043ND. The AR91XX_BASE{,.hints} files define all the common parameters for the AR913x SoC systems. The TP-1043ND config file adds local parameters.
2011-04-03 13:19:58 +00:00
#
# This file adds to the values in AR91XX_BASE.hints.
#
# $FreeBSD$
# Hard-code the PHY for now, until there's switch phy support.
In the new world order, multiphy is now when the phymask is 0x0. This makes the TP-WN1043ND (ar913x based) work again.
2012-05-03 07:48:19 +00:00
# hint.arge.0.phymask=0x000c
hint.arge.0.phymask=0x0000
Commit configuration files for the AR913x SoC and the TP-Link WR-1043ND. The AR91XX_BASE{,.hints} files define all the common parameters for the AR913x SoC systems. The TP-1043ND config file adds local parameters.
2011-04-03 13:19:58 +00:00
hint.arge.0.media=1000
hint.arge.0.fduplex=1
# Where is the MAC address stored in flash for this particular unit.
hint.arge.0.eeprommac=0x1f01fc00
# This isn't used, but configure it anyway.
# This should eventually just not be configured, but the if then
# needs to be properly disabled or spurious interrupts occur.
hint.arge.1.phymask=0x0
# Where the ART is
hint.ath.0.eepromaddr=0x1fff1000
Flesh out a geom_map setup, so the kernel can be squeezed _onto_ the device. The default flash layout gives only 1 megabyte for the kernel, gzipped. The uboot firmware running on this device only supports gzip, not lzma, so we actually _do_ have to try and slim the kernel down a bit. But, since I can't actually do that at the present, I'm opting to: * extend the kernel from 1mb to 2mb; * have rootfs fill the rest of that, save 64k; * eventually I'll hide a 64k config partition at the end, between the end of rootfs and the ART (radio configuration data.) The uboot firmware doesn't care about the partition layout. It just expects the kernel application image to sit at 0xbf020000 (right after the 128k uboot image.) The uboot header isn't actually read either - it's "faked" from a "tplink" flash image header. So as long as the map configuration here matches what is being written out via the tplink firmware generator, everything is a-ok.
2011-11-24 04:39:01 +00:00
#
# Define a slightly custom flash layout.
# The default flash layout:
#
# 128k: uboot
# 1024k: kernel
# 4096k: rootfs
Now that I've brought up FreeBSD via flash, I've discovered that the second-last 64k seems to be the default firmware board configuration area. Since I have no idea whether uboot uses it or not - and it's prefixed with an atheros eeprom signature (0xaa55), I figure the safest thing to do is mark it as read-only. I've modified my local tplink firmware building program to generate a board configuration section - which is separate to this partition. It's located in the 64k _before_ this particular 64k. The firmware build program from OpenWRT never initialises those values and the firmware images from tplink also leave it 0x0, so I don't currently know what the exact, correct details should be.
2011-11-24 07:37:19 +00:00
# 2816: unknown
# 64k: board config?
Flesh out a geom_map setup, so the kernel can be squeezed _onto_ the device. The default flash layout gives only 1 megabyte for the kernel, gzipped. The uboot firmware running on this device only supports gzip, not lzma, so we actually _do_ have to try and slim the kernel down a bit. But, since I can't actually do that at the present, I'm opting to: * extend the kernel from 1mb to 2mb; * have rootfs fill the rest of that, save 64k; * eventually I'll hide a 64k config partition at the end, between the end of rootfs and the ART (radio configuration data.) The uboot firmware doesn't care about the partition layout. It just expects the kernel application image to sit at 0xbf020000 (right after the 128k uboot image.) The uboot header isn't actually read either - it's "faked" from a "tplink" flash image header. So as long as the map configuration here matches what is being written out via the tplink firmware generator, everything is a-ok.
2011-11-24 04:39:01 +00:00
# 64k: ART
#
# from printenv:
# bootargs=console=ttyS0,115200 root=31:02 rootfstype=jffs2 init=/sbin/init
# mtdparts=ar9100-nor0:128k(u-boot),1024k(kernel),4096k(rootfs),64k(art)
# This isn't a lot of space!
# So:
# 128k: uboot
# 2048k: kernel
I've had verification that the second-last 64k is actually used by the tplink firmware to store configuration data. It's safe to overwrite it.
2011-11-24 15:12:57 +00:00
# 5888k: rootfs
Now that I've brought up FreeBSD via flash, I've discovered that the second-last 64k seems to be the default firmware board configuration area. Since I have no idea whether uboot uses it or not - and it's prefixed with an atheros eeprom signature (0xaa55), I figure the safest thing to do is mark it as read-only. I've modified my local tplink firmware building program to generate a board configuration section - which is separate to this partition. It's located in the 64k _before_ this particular 64k. The firmware build program from OpenWRT never initialises those values and the firmware images from tplink also leave it 0x0, so I don't currently know what the exact, correct details should be.
2011-11-24 07:37:19 +00:00
# 64k: config
Flesh out a geom_map setup, so the kernel can be squeezed _onto_ the device. The default flash layout gives only 1 megabyte for the kernel, gzipped. The uboot firmware running on this device only supports gzip, not lzma, so we actually _do_ have to try and slim the kernel down a bit. But, since I can't actually do that at the present, I'm opting to: * extend the kernel from 1mb to 2mb; * have rootfs fill the rest of that, save 64k; * eventually I'll hide a 64k config partition at the end, between the end of rootfs and the ART (radio configuration data.) The uboot firmware doesn't care about the partition layout. It just expects the kernel application image to sit at 0xbf020000 (right after the 128k uboot image.) The uboot header isn't actually read either - it's "faked" from a "tplink" flash image header. So as long as the map configuration here matches what is being written out via the tplink firmware generator, everything is a-ok.
2011-11-24 04:39:01 +00:00
# 64k: ART
hint.map.0.at="flash/spi0"
hint.map.0.start=0x00000000
Fix the geom mappings for WR1043ND. The uboot mapping is only 128KiB (0x20000) and not 2MiB (0x200000). Dynamically adjust kernel and rootfs mappings based on the geom_uncompress(4) magic. This makes the built images more reliable by accepting changes on kernel size transparently and matches the images built with zrouter and freebsd-wifi-build. Tested by: gjb Approved by: adrian (mentor) Obtained from: Zrouter
2014-01-07 13:09:35 +00:00
hint.map.0.end=0x00020000
Flesh out a geom_map setup, so the kernel can be squeezed _onto_ the device. The default flash layout gives only 1 megabyte for the kernel, gzipped. The uboot firmware running on this device only supports gzip, not lzma, so we actually _do_ have to try and slim the kernel down a bit. But, since I can't actually do that at the present, I'm opting to: * extend the kernel from 1mb to 2mb; * have rootfs fill the rest of that, save 64k; * eventually I'll hide a 64k config partition at the end, between the end of rootfs and the ART (radio configuration data.) The uboot firmware doesn't care about the partition layout. It just expects the kernel application image to sit at 0xbf020000 (right after the 128k uboot image.) The uboot header isn't actually read either - it's "faked" from a "tplink" flash image header. So as long as the map configuration here matches what is being written out via the tplink firmware generator, everything is a-ok.
2011-11-24 04:39:01 +00:00
hint.map.0.name="uboot"
hint.map.0.readonly=1
hint.map.1.at="flash/spi0"
hint.map.1.start=0x00020000
Fix the geom mappings for WR1043ND. The uboot mapping is only 128KiB (0x20000) and not 2MiB (0x200000). Dynamically adjust kernel and rootfs mappings based on the geom_uncompress(4) magic. This makes the built images more reliable by accepting changes on kernel size transparently and matches the images built with zrouter and freebsd-wifi-build. Tested by: gjb Approved by: adrian (mentor) Obtained from: Zrouter
2014-01-07 13:09:35 +00:00
hint.map.1.end="search:0x00100000:0x10000:.!/bin/sh"
Flesh out a geom_map setup, so the kernel can be squeezed _onto_ the device. The default flash layout gives only 1 megabyte for the kernel, gzipped. The uboot firmware running on this device only supports gzip, not lzma, so we actually _do_ have to try and slim the kernel down a bit. But, since I can't actually do that at the present, I'm opting to: * extend the kernel from 1mb to 2mb; * have rootfs fill the rest of that, save 64k; * eventually I'll hide a 64k config partition at the end, between the end of rootfs and the ART (radio configuration data.) The uboot firmware doesn't care about the partition layout. It just expects the kernel application image to sit at 0xbf020000 (right after the 128k uboot image.) The uboot header isn't actually read either - it's "faked" from a "tplink" flash image header. So as long as the map configuration here matches what is being written out via the tplink firmware generator, everything is a-ok.
2011-11-24 04:39:01 +00:00
hint.map.1.name="kernel"
hint.map.1.readonly=1
hint.map.2.at="flash/spi0"
Fix the geom mappings for WR1043ND. The uboot mapping is only 128KiB (0x20000) and not 2MiB (0x200000). Dynamically adjust kernel and rootfs mappings based on the geom_uncompress(4) magic. This makes the built images more reliable by accepting changes on kernel size transparently and matches the images built with zrouter and freebsd-wifi-build. Tested by: gjb Approved by: adrian (mentor) Obtained from: Zrouter
2014-01-07 13:09:35 +00:00
hint.map.2.start="search:0x00100000:0x10000:.!/bin/sh"
I've had verification that the second-last 64k is actually used by the tplink firmware to store configuration data. It's safe to overwrite it.
2011-11-24 15:12:57 +00:00
hint.map.2.end=0x007e0000
Flesh out a geom_map setup, so the kernel can be squeezed _onto_ the device. The default flash layout gives only 1 megabyte for the kernel, gzipped. The uboot firmware running on this device only supports gzip, not lzma, so we actually _do_ have to try and slim the kernel down a bit. But, since I can't actually do that at the present, I'm opting to: * extend the kernel from 1mb to 2mb; * have rootfs fill the rest of that, save 64k; * eventually I'll hide a 64k config partition at the end, between the end of rootfs and the ART (radio configuration data.) The uboot firmware doesn't care about the partition layout. It just expects the kernel application image to sit at 0xbf020000 (right after the 128k uboot image.) The uboot header isn't actually read either - it's "faked" from a "tplink" flash image header. So as long as the map configuration here matches what is being written out via the tplink firmware generator, everything is a-ok.
2011-11-24 04:39:01 +00:00
hint.map.2.name="rootfs"
hint.map.2.readonly=1
Now that I've brought up FreeBSD via flash, I've discovered that the second-last 64k seems to be the default firmware board configuration area. Since I have no idea whether uboot uses it or not - and it's prefixed with an atheros eeprom signature (0xaa55), I figure the safest thing to do is mark it as read-only. I've modified my local tplink firmware building program to generate a board configuration section - which is separate to this partition. It's located in the 64k _before_ this particular 64k. The firmware build program from OpenWRT never initialises those values and the firmware images from tplink also leave it 0x0, so I don't currently know what the exact, correct details should be.
2011-11-24 07:37:19 +00:00
hint.map.3.at="flash/spi0"
I've had verification that the second-last 64k is actually used by the tplink firmware to store configuration data. It's safe to overwrite it.
2011-11-24 15:12:57 +00:00
hint.map.3.start=0x007e0000
hint.map.3.end=0x007f0000
Now that I've brought up FreeBSD via flash, I've discovered that the second-last 64k seems to be the default firmware board configuration area. Since I have no idea whether uboot uses it or not - and it's prefixed with an atheros eeprom signature (0xaa55), I figure the safest thing to do is mark it as read-only. I've modified my local tplink firmware building program to generate a board configuration section - which is separate to this partition. It's located in the 64k _before_ this particular 64k. The firmware build program from OpenWRT never initialises those values and the firmware images from tplink also leave it 0x0, so I don't currently know what the exact, correct details should be.
2011-11-24 07:37:19 +00:00
hint.map.3.name="cfg"
hint.map.3.readonly=0
Flesh out a geom_map setup, so the kernel can be squeezed _onto_ the device. The default flash layout gives only 1 megabyte for the kernel, gzipped. The uboot firmware running on this device only supports gzip, not lzma, so we actually _do_ have to try and slim the kernel down a bit. But, since I can't actually do that at the present, I'm opting to: * extend the kernel from 1mb to 2mb; * have rootfs fill the rest of that, save 64k; * eventually I'll hide a 64k config partition at the end, between the end of rootfs and the ART (radio configuration data.) The uboot firmware doesn't care about the partition layout. It just expects the kernel application image to sit at 0xbf020000 (right after the 128k uboot image.) The uboot header isn't actually read either - it's "faked" from a "tplink" flash image header. So as long as the map configuration here matches what is being written out via the tplink firmware generator, everything is a-ok.
2011-11-24 04:39:01 +00:00
Now that I've brought up FreeBSD via flash, I've discovered that the second-last 64k seems to be the default firmware board configuration area. Since I have no idea whether uboot uses it or not - and it's prefixed with an atheros eeprom signature (0xaa55), I figure the safest thing to do is mark it as read-only. I've modified my local tplink firmware building program to generate a board configuration section - which is separate to this partition. It's located in the 64k _before_ this particular 64k. The firmware build program from OpenWRT never initialises those values and the firmware images from tplink also leave it 0x0, so I don't currently know what the exact, correct details should be.
2011-11-24 07:37:19 +00:00
# This is radio calibration section. It is (or should be!) unique
# for each board, to take into account thermal and electrical differences
# as well as the regulatory compliance data.
#
I've had verification that the second-last 64k is actually used by the tplink firmware to store configuration data. It's safe to overwrite it.
2011-11-24 15:12:57 +00:00
hint.map.4.at="flash/spi0"
hint.map.4.start=0x007f0000
hint.map.4.end=0x00800000
hint.map.4.name="art"
hint.map.4.readonly=1
* Add in the gpio/gpioled drivers into AR91XX_BASE. * Add in a default GPIO section for AR91XX_BASE.hints, which doesn't define the GPIO function masks or any GPIO pines. * Add in the GPIO line definitions for LEDs and GPIO pins for the TP-WR1043nd. I've verified the LEDs work fine using gpioset.
2011-12-15 01:05:38 +00:00
# GPIO specific configuration block
# Don't flip on anything that isn't already enabled.
# This includes leaving the SPI CS1/CS2 pins as GPIO pins as they're
# not used here.
Flip on WN1043ND switch PHY support. * Add the i2c bitbang bus; * Add the etherswitch/rtl8366rb drivers; * "fix" the USB GPIO configuration so USB actually works. Submitted by: Stefan Bethke <stb@lassitu.de>
2012-05-12 17:41:42 +00:00
hint.gpio.0.function_set=0x00002000
* Add in the gpio/gpioled drivers into AR91XX_BASE. * Add in a default GPIO section for AR91XX_BASE.hints, which doesn't define the GPIO function masks or any GPIO pines. * Add in the GPIO line definitions for LEDs and GPIO pins for the TP-WR1043nd. I've verified the LEDs work fine using gpioset.
2011-12-15 01:05:38 +00:00
hint.gpio.0.function_clear=0x00000000
# These are the GPIO LEDs and buttons which can be software controlled.
hint.gpio.0.pinmask=0x001c02ae
# pin 1 - USB (LED)
# pin 2 - System (LED)
# Pin 3 - Reset (input)
# Pin 5 - QSS (LED)
# Pin 7 - QSS Button (input)
# Pin 8 - wired into the chip reset line
# Pin 9 - WLAN
# Pin 10 - UART TX (not GPIO)
# Pin 13 - UART RX (not GPIO)
# Pin 18 - RTL8366RB switch data line
# Pin 19 - RTL8366RB switch clock line
# Pin 20 - "GPIO20"
# LEDs are configured separately and driven by the LED device
Flip on WN1043ND switch PHY support. * Add the i2c bitbang bus; * Add the etherswitch/rtl8366rb drivers; * "fix" the USB GPIO configuration so USB actually works. Submitted by: Stefan Bethke <stb@lassitu.de>
2012-05-12 17:41:42 +00:00
#hint.gpioled.0.at="gpiobus0"
#hint.gpioled.0.name="usb"
#hint.gpioled.0.pins=0x0002
* Add in the gpio/gpioled drivers into AR91XX_BASE. * Add in a default GPIO section for AR91XX_BASE.hints, which doesn't define the GPIO function masks or any GPIO pines. * Add in the GPIO line definitions for LEDs and GPIO pins for the TP-WR1043nd. I've verified the LEDs work fine using gpioset.
2011-12-15 01:05:38 +00:00
hint.gpioled.1.at="gpiobus0"
hint.gpioled.1.name="system"
hint.gpioled.1.pins=0x0004
hint.gpioled.2.at="gpiobus0"
hint.gpioled.2.name="qss"
hint.gpioled.2.pins=0x0020
hint.gpioled.3.at="gpiobus0"
hint.gpioled.3.name="wlan"
hint.gpioled.3.pins=0x0200
Flip on WN1043ND switch PHY support. * Add the i2c bitbang bus; * Add the etherswitch/rtl8366rb drivers; * "fix" the USB GPIO configuration so USB actually works. Submitted by: Stefan Bethke <stb@lassitu.de>
2012-05-12 17:41:42 +00:00
# GPIO I2C bus
hint.gpioiic.0.at="gpiobus0"
hint.gpioiic.0.pins=0xc0000
hint.gpioiic.0.scl=1
hint.gpioiic.0.sda=0
# I2C bus
# Don't be strict about I2C protocol - the relaxed semantics are required
# by the realtek switch PHY.
hint.iicbus.0.strict=0
# Bit bang bus - override default delay
#hint.iicbb.0.udelay=3
Reference in New Issue Copy Permalink