[PATCH 10/11] Add MPC8360EMDS board support

[PATCH 10/11] Add MPC8360EMDS board support

[Li Yang]

The patch adds MPC8360EMDS board support.

Signed-off-by: Li Yang <leoli@freescale.com>
Signed-off-by: Yin Olivia <hong-hua.yin@freescale.com>
Signed-off-by: Kim Phillips <kim.phillips@freescale.com>

---
 arch/powerpc/configs/mpc8360emds_defconfig | 1018 ++++++++++++++++++++++++++++
 arch/powerpc/platforms/83xx/Kconfig        |   17 
 arch/powerpc/platforms/83xx/Makefile       |    1 
 arch/powerpc/platforms/83xx/mpc8360e_pb.c  |  204 ++++++
 arch/powerpc/platforms/83xx/mpc8360e_pb.h  |   31 +
 5 files changed, 1271 insertions(+), 0 deletions(-)

diff --git a/arch/powerpc/configs/mpc8360emds_defconfig b/arch/powerpc/configs/mpc8360emds_defconfig
new file mode 100644
index 0000000..eedbd2d
--- /dev/null
+++ b/arch/powerpc/configs/mpc8360emds_defconfig
@@ -0,0 +1,1018 @@
+#
+# Automatically generated make config: don't edit
+# Linux kernel version: 2.6.18
+# Thu Sep 21 18:14:27 2006
+#
+# CONFIG_PPC64 is not set
+CONFIG_PPC32=y
+CONFIG_PPC_MERGE=y
+CONFIG_MMU=y
+CONFIG_GENERIC_HARDIRQS=y
+CONFIG_IRQ_PER_CPU=y
+CONFIG_RWSEM_XCHGADD_ALGORITHM=y
+CONFIG_GENERIC_HWEIGHT=y
+CONFIG_GENERIC_CALIBRATE_DELAY=y
+CONFIG_GENERIC_FIND_NEXT_BIT=y
+CONFIG_PPC=y
+CONFIG_EARLY_PRINTK=y
+CONFIG_GENERIC_NVRAM=y
+CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER=y
+CONFIG_ARCH_MAY_HAVE_PC_FDC=y
+CONFIG_PPC_OF=y
+CONFIG_PPC_UDBG_16550=y
+# CONFIG_GENERIC_TBSYNC is not set
+CONFIG_AUDIT_ARCH=y
+CONFIG_DEFAULT_UIMAGE=y
+
+#
+# Processor support
+#
+# CONFIG_CLASSIC32 is not set
+# CONFIG_PPC_52xx is not set
+# CONFIG_PPC_82xx is not set
+CONFIG_PPC_83xx=y
+# CONFIG_PPC_85xx is not set
+# CONFIG_PPC_86xx is not set
+# CONFIG_40x is not set
+# CONFIG_44x is not set
+# CONFIG_8xx is not set
+# CONFIG_E200 is not set
+CONFIG_6xx=y
+CONFIG_83xx=y
+CONFIG_PPC_FPU=y
+CONFIG_PPC_STD_MMU=y
+CONFIG_PPC_STD_MMU_32=y
+# CONFIG_SMP is not set
+CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
+
+#
+# Code maturity level options
+#
+CONFIG_EXPERIMENTAL=y
+CONFIG_BROKEN_ON_SMP=y
+CONFIG_INIT_ENV_ARG_LIMIT=32
+
+#
+# General setup
+#
+CONFIG_LOCALVERSION=""
+CONFIG_LOCALVERSION_AUTO=y
+CONFIG_SWAP=y
+CONFIG_SYSVIPC=y
+# CONFIG_POSIX_MQUEUE is not set
+# CONFIG_BSD_PROCESS_ACCT is not set
+# CONFIG_TASKSTATS is not set
+# CONFIG_AUDIT is not set
+# CONFIG_IKCONFIG is not set
+# CONFIG_RELAY is not set
+CONFIG_INITRAMFS_SOURCE=""
+# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
+CONFIG_EMBEDDED=y
+CONFIG_SYSCTL=y
+# CONFIG_KALLSYMS is not set
+CONFIG_HOTPLUG=y
+CONFIG_PRINTK=y
+CONFIG_BUG=y
+CONFIG_ELF_CORE=y
+CONFIG_BASE_FULL=y
+CONFIG_FUTEX=y
+# CONFIG_EPOLL is not set
+CONFIG_SHMEM=y
+CONFIG_SLAB=y
+CONFIG_VM_EVENT_COUNTERS=y
+CONFIG_RT_MUTEXES=y
+# CONFIG_TINY_SHMEM is not set
+CONFIG_BASE_SMALL=0
+# CONFIG_SLOB is not set
+
+#
+# Loadable module support
+#
+CONFIG_MODULES=y
+CONFIG_MODULE_UNLOAD=y
+# CONFIG_MODULE_FORCE_UNLOAD is not set
+# CONFIG_MODVERSIONS is not set
+# CONFIG_MODULE_SRCVERSION_ALL is not set
+# CONFIG_KMOD is not set
+
+#
+# Block layer
+#
+# CONFIG_LBD is not set
+# CONFIG_BLK_DEV_IO_TRACE is not set
+# CONFIG_LSF is not set
+
+#
+# IO Schedulers
+#
+CONFIG_IOSCHED_NOOP=y
+CONFIG_IOSCHED_AS=y
+CONFIG_IOSCHED_DEADLINE=y
+CONFIG_IOSCHED_CFQ=y
+CONFIG_DEFAULT_AS=y
+# CONFIG_DEFAULT_DEADLINE is not set
+# CONFIG_DEFAULT_CFQ is not set
+# CONFIG_DEFAULT_NOOP is not set
+CONFIG_DEFAULT_IOSCHED="anticipatory"
+CONFIG_QUICC_ENGINE=y
+CONFIG_PPC_GEN550=y
+# CONFIG_WANT_EARLY_SERIAL is not set
+
+#
+# Platform support
+#
+# CONFIG_MPC834x_SYS is not set
+# CONFIG_MPC834x_ITX is not set
+CONFIG_MPC8360E_PB=y
+CONFIG_MPC836x=y
+# CONFIG_MPIC is not set
+
+#
+# Kernel options
+#
+# CONFIG_HIGHMEM is not set
+# CONFIG_HZ_100 is not set
+CONFIG_HZ_250=y
+# CONFIG_HZ_1000 is not set
+CONFIG_HZ=250
+CONFIG_PREEMPT_NONE=y
+# CONFIG_PREEMPT_VOLUNTARY is not set
+# CONFIG_PREEMPT is not set
+CONFIG_BINFMT_ELF=y
+# CONFIG_BINFMT_MISC is not set
+CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y
+CONFIG_ARCH_FLATMEM_ENABLE=y
+CONFIG_SELECT_MEMORY_MODEL=y
+CONFIG_FLATMEM_MANUAL=y
+# CONFIG_DISCONTIGMEM_MANUAL is not set
+# CONFIG_SPARSEMEM_MANUAL is not set
+CONFIG_FLATMEM=y
+CONFIG_FLAT_NODE_MEM_MAP=y
+# CONFIG_SPARSEMEM_STATIC is not set
+CONFIG_SPLIT_PTLOCK_CPUS=4
+# CONFIG_RESOURCES_64BIT is not set
+CONFIG_PROC_DEVICETREE=y
+# CONFIG_CMDLINE_BOOL is not set
+# CONFIG_PM is not set
+CONFIG_SECCOMP=y
+CONFIG_ISA_DMA_API=y
+
+#
+# Bus options
+#
+CONFIG_GENERIC_ISA_DMA=y
+# CONFIG_MPIC_WEIRD is not set
+# CONFIG_PPC_I8259 is not set
+CONFIG_PPC_INDIRECT_PCI=y
+CONFIG_FSL_SOC=y
+CONFIG_PCI=y
+CONFIG_PCI_DOMAINS=y
+# CONFIG_PCIEPORTBUS is not set
+
+#
+# PCCARD (PCMCIA/CardBus) support
+#
+# CONFIG_PCCARD is not set
+
+#
+# PCI Hotplug Support
+#
+# CONFIG_HOTPLUG_PCI is not set
+
+#
+# Advanced setup
+#
+# CONFIG_ADVANCED_OPTIONS is not set
+
+#
+# Default settings for advanced configuration options are used
+#
+CONFIG_HIGHMEM_START=0xfe000000
+CONFIG_LOWMEM_SIZE=0x30000000
+CONFIG_KERNEL_START=0xc0000000
+CONFIG_TASK_SIZE=0x80000000
+CONFIG_BOOT_LOAD=0x00800000
+
+#
+# Networking
+#
+CONFIG_NET=y
+
+#
+# Networking options
+#
+# CONFIG_NETDEBUG is not set
+CONFIG_PACKET=y
+# CONFIG_PACKET_MMAP is not set
+CONFIG_UNIX=y
+CONFIG_XFRM=y
+# CONFIG_XFRM_USER is not set
+# CONFIG_NET_KEY is not set
+CONFIG_INET=y
+CONFIG_IP_MULTICAST=y
+# CONFIG_IP_ADVANCED_ROUTER is not set
+CONFIG_IP_FIB_HASH=y
+CONFIG_IP_PNP=y
+CONFIG_IP_PNP_DHCP=y
+CONFIG_IP_PNP_BOOTP=y
+# CONFIG_IP_PNP_RARP is not set
+# CONFIG_NET_IPIP is not set
+# CONFIG_NET_IPGRE is not set
+# CONFIG_IP_MROUTE is not set
+# CONFIG_ARPD is not set
+CONFIG_SYN_COOKIES=y
+# CONFIG_INET_AH is not set
+# CONFIG_INET_ESP is not set
+# CONFIG_INET_IPCOMP is not set
+# CONFIG_INET_XFRM_TUNNEL is not set
+# CONFIG_INET_TUNNEL is not set
+CONFIG_INET_XFRM_MODE_TRANSPORT=y
+CONFIG_INET_XFRM_MODE_TUNNEL=y
+CONFIG_INET_DIAG=y
+CONFIG_INET_TCP_DIAG=y
+# CONFIG_TCP_CONG_ADVANCED is not set
+CONFIG_TCP_CONG_BIC=y
+# CONFIG_IPV6 is not set
+# CONFIG_INET6_XFRM_TUNNEL is not set
+# CONFIG_INET6_TUNNEL is not set
+# CONFIG_NETWORK_SECMARK is not set
+# CONFIG_NETFILTER is not set
+
+#
+# DCCP Configuration (EXPERIMENTAL)
+#
+# CONFIG_IP_DCCP is not set
+
+#
+# SCTP Configuration (EXPERIMENTAL)
+#
+# CONFIG_IP_SCTP is not set
+
+#
+# TIPC Configuration (EXPERIMENTAL)
+#
+# CONFIG_TIPC is not set
+# CONFIG_ATM is not set
+# CONFIG_BRIDGE is not set
+# CONFIG_VLAN_8021Q is not set
+# CONFIG_DECNET is not set
+# CONFIG_LLC2 is not set
+# CONFIG_IPX is not set
+# CONFIG_ATALK is not set
+# CONFIG_X25 is not set
+# CONFIG_LAPB is not set
+# CONFIG_ECONET is not set
+# CONFIG_WAN_ROUTER is not set
+
+#
+# QoS and/or fair queueing
+#
+# CONFIG_NET_SCHED is not set
+
+#
+# Network testing
+#
+# CONFIG_NET_PKTGEN is not set
+# CONFIG_HAMRADIO is not set
+# CONFIG_IRDA is not set
+# CONFIG_BT is not set
+# CONFIG_IEEE80211 is not set
+
+#
+# Device Drivers
+#
+
+#
+# Generic Driver Options
+#
+CONFIG_STANDALONE=y
+CONFIG_PREVENT_FIRMWARE_BUILD=y
+# CONFIG_FW_LOADER is not set
+# CONFIG_SYS_HYPERVISOR is not set
+
+#
+# Connector - unified userspace <-> kernelspace linker
+#
+# CONFIG_CONNECTOR is not set
+
+#
+# Memory Technology Devices (MTD)
+#
+# CONFIG_MTD is not set
+
+#
+# Parallel port support
+#
+# CONFIG_PARPORT is not set
+
+#
+# Plug and Play support
+#
+
+#
+# Block devices
+#
+# CONFIG_BLK_DEV_FD is not set
+# CONFIG_BLK_CPQ_DA is not set
+# CONFIG_BLK_CPQ_CISS_DA is not set
+# CONFIG_BLK_DEV_DAC960 is not set
+# CONFIG_BLK_DEV_UMEM is not set
+# CONFIG_BLK_DEV_COW_COMMON is not set
+CONFIG_BLK_DEV_LOOP=y
+# CONFIG_BLK_DEV_CRYPTOLOOP is not set
+# CONFIG_BLK_DEV_NBD is not set
+# CONFIG_BLK_DEV_SX8 is not set
+CONFIG_BLK_DEV_RAM=y
+CONFIG_BLK_DEV_RAM_COUNT=16
+CONFIG_BLK_DEV_RAM_SIZE=32768
+CONFIG_BLK_DEV_RAM_BLOCKSIZE=1024
+CONFIG_BLK_DEV_INITRD=y
+# CONFIG_CDROM_PKTCDVD is not set
+# CONFIG_ATA_OVER_ETH is not set
+
+#
+# ATA/ATAPI/MFM/RLL support
+#
+# CONFIG_IDE is not set
+
+#
+# SCSI device support
+#
+# CONFIG_RAID_ATTRS is not set
+CONFIG_SCSI=y
+CONFIG_SCSI_PROC_FS=y
+
+#
+# SCSI support type (disk, tape, CD-ROM)
+#
+# CONFIG_BLK_DEV_SD is not set
+# CONFIG_CHR_DEV_ST is not set
+# CONFIG_CHR_DEV_OSST is not set
+# CONFIG_BLK_DEV_SR is not set
+# CONFIG_CHR_DEV_SG is not set
+# CONFIG_CHR_DEV_SCH is not set
+
+#
+# Some SCSI devices (e.g. CD jukebox) support multiple LUNs
+#
+# CONFIG_SCSI_MULTI_LUN is not set
+# CONFIG_SCSI_CONSTANTS is not set
+# CONFIG_SCSI_LOGGING is not set
+
+#
+# SCSI Transport Attributes
+#
+# CONFIG_SCSI_SPI_ATTRS is not set
+# CONFIG_SCSI_FC_ATTRS is not set
+# CONFIG_SCSI_ISCSI_ATTRS is not set
+# CONFIG_SCSI_SAS_ATTRS is not set
+
+#
+# SCSI low-level drivers
+#
+# CONFIG_ISCSI_TCP is not set
+# CONFIG_BLK_DEV_3W_XXXX_RAID is not set
+# CONFIG_SCSI_3W_9XXX is not set
+# CONFIG_SCSI_ACARD is not set
+# CONFIG_SCSI_AACRAID is not set
+# CONFIG_SCSI_AIC7XXX is not set
+# CONFIG_SCSI_AIC7XXX_OLD is not set
+# CONFIG_SCSI_AIC79XX is not set
+# CONFIG_SCSI_DPT_I2O is not set
+# CONFIG_MEGARAID_NEWGEN is not set
+# CONFIG_MEGARAID_LEGACY is not set
+# CONFIG_MEGARAID_SAS is not set
+# CONFIG_SCSI_SATA is not set
+# CONFIG_SCSI_HPTIOP is not set
+# CONFIG_SCSI_BUSLOGIC is not set
+# CONFIG_SCSI_DMX3191D is not set
+# CONFIG_SCSI_EATA is not set
+# CONFIG_SCSI_FUTURE_DOMAIN is not set
+# CONFIG_SCSI_GDTH is not set
+# CONFIG_SCSI_IPS is not set
+# CONFIG_SCSI_INITIO is not set
+# CONFIG_SCSI_INIA100 is not set
+# CONFIG_SCSI_SYM53C8XX_2 is not set
+# CONFIG_SCSI_IPR is not set
+# CONFIG_SCSI_QLOGIC_1280 is not set
+# CONFIG_SCSI_QLA_FC is not set
+# CONFIG_SCSI_LPFC is not set
+# CONFIG_SCSI_DC395x is not set
+# CONFIG_SCSI_DC390T is not set
+# CONFIG_SCSI_NSP32 is not set
+# CONFIG_SCSI_DEBUG is not set
+
+#
+# Multi-device support (RAID and LVM)
+#
+# CONFIG_MD is not set
+
+#
+# Fusion MPT device support
+#
+# CONFIG_FUSION is not set
+# CONFIG_FUSION_SPI is not set
+# CONFIG_FUSION_FC is not set
+# CONFIG_FUSION_SAS is not set
+
+#
+# IEEE 1394 (FireWire) support
+#
+# CONFIG_IEEE1394 is not set
+
+#
+# I2O device support
+#
+# CONFIG_I2O is not set
+
+#
+# Macintosh device drivers
+#
+# CONFIG_WINDFARM is not set
+
+#
+# Network device support
+#
+CONFIG_NETDEVICES=y
+# CONFIG_DUMMY is not set
+# CONFIG_BONDING is not set
+# CONFIG_EQUALIZER is not set
+# CONFIG_TUN is not set
+
+#
+# ARCnet devices
+#
+# CONFIG_ARCNET is not set
+
+#
+# PHY device support
+#
+# CONFIG_PHYLIB is not set
+
+#
+# Ethernet (10 or 100Mbit)
+#
+CONFIG_NET_ETHERNET=y
+CONFIG_MII=y
+# CONFIG_HAPPYMEAL is not set
+# CONFIG_SUNGEM is not set
+# CONFIG_CASSINI is not set
+# CONFIG_NET_VENDOR_3COM is not set
+
+#
+# Tulip family network device support
+#
+# CONFIG_NET_TULIP is not set
+# CONFIG_HP100 is not set
+# CONFIG_NET_PCI is not set
+
+#
+# Ethernet (1000 Mbit)
+#
+# CONFIG_ACENIC is not set
+# CONFIG_DL2K is not set
+# CONFIG_E1000 is not set
+# CONFIG_NS83820 is not set
+# CONFIG_HAMACHI is not set
+# CONFIG_YELLOWFIN is not set
+# CONFIG_R8169 is not set
+# CONFIG_SIS190 is not set
+# CONFIG_SKGE is not set
+# CONFIG_SKY2 is not set
+# CONFIG_SK98LIN is not set
+# CONFIG_TIGON3 is not set
+# CONFIG_BNX2 is not set
+# CONFIG_GIANFAR is not set
+CONFIG_UCC_GETH=y
+# CONFIG_UGETH_NAPI is not set
+# CONFIG_UGETH_MAGIC_PACKET is not set
+# CONFIG_UGETH_FILTERING is not set
+# CONFIG_UGETH_TX_ON_DEMOND is not set
+
+#
+# Ethernet (10000 Mbit)
+#
+# CONFIG_CHELSIO_T1 is not set
+# CONFIG_IXGB is not set
+# CONFIG_S2IO is not set
+# CONFIG_MYRI10GE is not set
+
+#
+# Token Ring devices
+#
+# CONFIG_TR is not set
+
+#
+# Wireless LAN (non-hamradio)
+#
+# CONFIG_NET_RADIO is not set
+
+#
+# Wan interfaces
+#
+# CONFIG_WAN is not set
+# CONFIG_FDDI is not set
+# CONFIG_HIPPI is not set
+# CONFIG_PPP is not set
+# CONFIG_SLIP is not set
+# CONFIG_NET_FC is not set
+# CONFIG_SHAPER is not set
+# CONFIG_NETCONSOLE is not set
+# CONFIG_NETPOLL is not set
+# CONFIG_NET_POLL_CONTROLLER is not set
+
+#
+# ISDN subsystem
+#
+# CONFIG_ISDN is not set
+
+#
+# Telephony Support
+#
+# CONFIG_PHONE is not set
+
+#
+# Input device support
+#
+CONFIG_INPUT=y
+
+#
+# Userland interfaces
+#
+# CONFIG_INPUT_MOUSEDEV is not set
+# CONFIG_INPUT_JOYDEV is not set
+# CONFIG_INPUT_TSDEV is not set
+# CONFIG_INPUT_EVDEV is not set
+# CONFIG_INPUT_EVBUG is not set
+
+#
+# Input Device Drivers
+#
+# CONFIG_INPUT_KEYBOARD is not set
+# CONFIG_INPUT_MOUSE is not set
+# CONFIG_INPUT_JOYSTICK is not set
+# CONFIG_INPUT_TOUCHSCREEN is not set
+# CONFIG_INPUT_MISC is not set
+
+#
+# Hardware I/O ports
+#
+# CONFIG_SERIO is not set
+# CONFIG_GAMEPORT is not set
+
+#
+# Character devices
+#
+# CONFIG_VT is not set
+# CONFIG_SERIAL_NONSTANDARD is not set
+
+#
+# Serial drivers
+#
+CONFIG_SERIAL_8250=y
+CONFIG_SERIAL_8250_CONSOLE=y
+CONFIG_SERIAL_8250_PCI=y
+CONFIG_SERIAL_8250_NR_UARTS=4
+CONFIG_SERIAL_8250_RUNTIME_UARTS=4
+# CONFIG_SERIAL_8250_EXTENDED is not set
+
+#
+# Non-8250 serial port support
+#
+CONFIG_SERIAL_CORE=y
+CONFIG_SERIAL_CORE_CONSOLE=y
+# CONFIG_SERIAL_JSM is not set
+CONFIG_UNIX98_PTYS=y
+CONFIG_LEGACY_PTYS=y
+CONFIG_LEGACY_PTY_COUNT=256
+
+#
+# IPMI
+#
+# CONFIG_IPMI_HANDLER is not set
+
+#
+# Watchdog Cards
+#
+CONFIG_WATCHDOG=y
+# CONFIG_WATCHDOG_NOWAYOUT is not set
+
+#
+# Watchdog Device Drivers
+#
+# CONFIG_SOFT_WATCHDOG is not set
+CONFIG_83xx_WDT=y
+
+#
+# PCI-based Watchdog Cards
+#
+# CONFIG_PCIPCWATCHDOG is not set
+# CONFIG_WDTPCI is not set
+CONFIG_HW_RANDOM=y
+# CONFIG_NVRAM is not set
+CONFIG_GEN_RTC=y
+# CONFIG_GEN_RTC_X is not set
+# CONFIG_DTLK is not set
+# CONFIG_R3964 is not set
+# CONFIG_APPLICOM is not set
+
+#
+# Ftape, the floppy tape device driver
+#
+# CONFIG_AGP is not set
+# CONFIG_DRM is not set
+# CONFIG_RAW_DRIVER is not set
+
+#
+# TPM devices
+#
+# CONFIG_TCG_TPM is not set
+# CONFIG_TELCLOCK is not set
+
+#
+# I2C support
+#
+CONFIG_I2C=y
+CONFIG_I2C_CHARDEV=y
+
+#
+# I2C Algorithms
+#
+# CONFIG_I2C_ALGOBIT is not set
+# CONFIG_I2C_ALGOPCF is not set
+# CONFIG_I2C_ALGOPCA is not set
+
+#
+# I2C Hardware Bus support
+#
+# CONFIG_I2C_ALI1535 is not set
+# CONFIG_I2C_ALI1563 is not set
+# CONFIG_I2C_ALI15X3 is not set
+# CONFIG_I2C_AMD756 is not set
+# CONFIG_I2C_AMD8111 is not set
+# CONFIG_I2C_I801 is not set
+# CONFIG_I2C_I810 is not set
+# CONFIG_I2C_PIIX4 is not set
+CONFIG_I2C_MPC=y
+# CONFIG_I2C_NFORCE2 is not set
+# CONFIG_I2C_OCORES is not set
+# CONFIG_I2C_PARPORT_LIGHT is not set
+# CONFIG_I2C_PROSAVAGE is not set
+# CONFIG_I2C_SAVAGE4 is not set
+# CONFIG_I2C_SIS5595 is not set
+# CONFIG_I2C_SIS630 is not set
+# CONFIG_I2C_SIS96X is not set
+# CONFIG_I2C_STUB is not set
+# CONFIG_I2C_VIA is not set
+# CONFIG_I2C_VIAPRO is not set
+# CONFIG_I2C_VOODOO3 is not set
+# CONFIG_I2C_PCA_ISA is not set
+
+#
+# Miscellaneous I2C Chip support
+#
+# CONFIG_SENSORS_DS1337 is not set
+# CONFIG_SENSORS_DS1374 is not set
+# CONFIG_SENSORS_EEPROM is not set
+# CONFIG_SENSORS_PCF8574 is not set
+# CONFIG_SENSORS_PCA9539 is not set
+# CONFIG_SENSORS_PCF8591 is not set
+# CONFIG_SENSORS_M41T00 is not set
+# CONFIG_SENSORS_MAX6875 is not set
+# CONFIG_I2C_DEBUG_CORE is not set
+# CONFIG_I2C_DEBUG_ALGO is not set
+# CONFIG_I2C_DEBUG_BUS is not set
+# CONFIG_I2C_DEBUG_CHIP is not set
+
+#
+# SPI support
+#
+# CONFIG_SPI is not set
+# CONFIG_SPI_MASTER is not set
+
+#
+# Dallas's 1-wire bus
+#
+
+#
+# Hardware Monitoring support
+#
+CONFIG_HWMON=y
+# CONFIG_HWMON_VID is not set
+# CONFIG_SENSORS_ABITUGURU is not set
+# CONFIG_SENSORS_ADM1021 is not set
+# CONFIG_SENSORS_ADM1025 is not set
+# CONFIG_SENSORS_ADM1026 is not set
+# CONFIG_SENSORS_ADM1031 is not set
+# CONFIG_SENSORS_ADM9240 is not set
+# CONFIG_SENSORS_ASB100 is not set
+# CONFIG_SENSORS_ATXP1 is not set
+# CONFIG_SENSORS_DS1621 is not set
+# CONFIG_SENSORS_F71805F is not set
+# CONFIG_SENSORS_FSCHER is not set
+# CONFIG_SENSORS_FSCPOS is not set
+# CONFIG_SENSORS_GL518SM is not set
+# CONFIG_SENSORS_GL520SM is not set
+# CONFIG_SENSORS_IT87 is not set
+# CONFIG_SENSORS_LM63 is not set
+# CONFIG_SENSORS_LM75 is not set
+# CONFIG_SENSORS_LM77 is not set
+# CONFIG_SENSORS_LM78 is not set
+# CONFIG_SENSORS_LM80 is not set
+# CONFIG_SENSORS_LM83 is not set
+# CONFIG_SENSORS_LM85 is not set
+# CONFIG_SENSORS_LM87 is not set
+# CONFIG_SENSORS_LM90 is not set
+# CONFIG_SENSORS_LM92 is not set
+# CONFIG_SENSORS_MAX1619 is not set
+# CONFIG_SENSORS_PC87360 is not set
+# CONFIG_SENSORS_SIS5595 is not set
+# CONFIG_SENSORS_SMSC47M1 is not set
+# CONFIG_SENSORS_SMSC47M192 is not set
+# CONFIG_SENSORS_SMSC47B397 is not set
+# CONFIG_SENSORS_VIA686A is not set
+# CONFIG_SENSORS_VT8231 is not set
+# CONFIG_SENSORS_W83781D is not set
+# CONFIG_SENSORS_W83791D is not set
+# CONFIG_SENSORS_W83792D is not set
+# CONFIG_SENSORS_W83L785TS is not set
+# CONFIG_SENSORS_W83627HF is not set
+# CONFIG_SENSORS_W83627EHF is not set
+# CONFIG_HWMON_DEBUG_CHIP is not set
+
+#
+# Misc devices
+#
+
+#
+# Multimedia devices
+#
+# CONFIG_VIDEO_DEV is not set
+CONFIG_VIDEO_V4L2=y
+
+#
+# Digital Video Broadcasting Devices
+#
+# CONFIG_DVB is not set
+
+#
+# Graphics support
+#
+CONFIG_FIRMWARE_EDID=y
+# CONFIG_FB is not set
+# CONFIG_BACKLIGHT_LCD_SUPPORT is not set
+
+#
+# Sound
+#
+# CONFIG_SOUND is not set
+
+#
+# USB support
+#
+CONFIG_USB_ARCH_HAS_HCD=y
+CONFIG_USB_ARCH_HAS_OHCI=y
+CONFIG_USB_ARCH_HAS_EHCI=y
+# CONFIG_USB is not set
+
+#
+# NOTE: USB_STORAGE enables SCSI, and 'SCSI disk support'
+#
+
+#
+# USB Gadget Support
+#
+# CONFIG_USB_GADGET is not set
+
+#
+# MMC/SD Card support
+#
+# CONFIG_MMC is not set
+
+#
+# LED devices
+#
+# CONFIG_NEW_LEDS is not set
+
+#
+# LED drivers
+#
+
+#
+# LED Triggers
+#
+
+#
+# InfiniBand support
+#
+# CONFIG_INFINIBAND is not set
+
+#
+# EDAC - error detection and reporting (RAS) (EXPERIMENTAL)
+#
+
+#
+# Real Time Clock
+#
+# CONFIG_RTC_CLASS is not set
+
+#
+# DMA Engine support
+#
+# CONFIG_DMA_ENGINE is not set
+
+#
+# DMA Clients
+#
+
+#
+# DMA Devices
+#
+
+#
+# File systems
+#
+CONFIG_EXT2_FS=y
+# CONFIG_EXT2_FS_XATTR is not set
+# CONFIG_EXT2_FS_XIP is not set
+CONFIG_EXT3_FS=y
+CONFIG_EXT3_FS_XATTR=y
+# CONFIG_EXT3_FS_POSIX_ACL is not set
+# CONFIG_EXT3_FS_SECURITY is not set
+CONFIG_JBD=y
+# CONFIG_JBD_DEBUG is not set
+CONFIG_FS_MBCACHE=y
+# CONFIG_REISERFS_FS is not set
+# CONFIG_JFS_FS is not set
+# CONFIG_FS_POSIX_ACL is not set
+# CONFIG_XFS_FS is not set
+# CONFIG_OCFS2_FS is not set
+# CONFIG_MINIX_FS is not set
+# CONFIG_ROMFS_FS is not set
+CONFIG_INOTIFY=y
+CONFIG_INOTIFY_USER=y
+# CONFIG_QUOTA is not set
+CONFIG_DNOTIFY=y
+# CONFIG_AUTOFS_FS is not set
+# CONFIG_AUTOFS4_FS is not set
+# CONFIG_FUSE_FS is not set
+
+#
+# CD-ROM/DVD Filesystems
+#
+# CONFIG_ISO9660_FS is not set
+# CONFIG_UDF_FS is not set
+
+#
+# DOS/FAT/NT Filesystems
+#
+# CONFIG_MSDOS_FS is not set
+# CONFIG_VFAT_FS is not set
+# CONFIG_NTFS_FS is not set
+
+#
+# Pseudo filesystems
+#
+CONFIG_PROC_FS=y
+CONFIG_PROC_KCORE=y
+CONFIG_SYSFS=y
+CONFIG_TMPFS=y
+# CONFIG_HUGETLB_PAGE is not set
+CONFIG_RAMFS=y
+# CONFIG_CONFIGFS_FS is not set
+
+#
+# Miscellaneous filesystems
+#
+# CONFIG_ADFS_FS is not set
+# CONFIG_AFFS_FS is not set
+# CONFIG_HFS_FS is not set
+# CONFIG_HFSPLUS_FS is not set
+# CONFIG_BEFS_FS is not set
+# CONFIG_BFS_FS is not set
+# CONFIG_EFS_FS is not set
+# CONFIG_CRAMFS is not set
+# CONFIG_VXFS_FS is not set
+# CONFIG_HPFS_FS is not set
+# CONFIG_QNX4FS_FS is not set
+# CONFIG_SYSV_FS is not set
+# CONFIG_UFS_FS is not set
+
+#
+# Network File Systems
+#
+CONFIG_NFS_FS=y
+CONFIG_NFS_V3=y
+# CONFIG_NFS_V3_ACL is not set
+CONFIG_NFS_V4=y
+# CONFIG_NFS_DIRECTIO is not set
+# CONFIG_NFSD is not set
+CONFIG_ROOT_NFS=y
+CONFIG_LOCKD=y
+CONFIG_LOCKD_V4=y
+CONFIG_NFS_COMMON=y
+CONFIG_SUNRPC=y
+CONFIG_SUNRPC_GSS=y
+CONFIG_RPCSEC_GSS_KRB5=y
+# CONFIG_RPCSEC_GSS_SPKM3 is not set
+# CONFIG_SMB_FS is not set
+# CONFIG_CIFS is not set
+# CONFIG_NCP_FS is not set
+# CONFIG_CODA_FS is not set
+# CONFIG_AFS_FS is not set
+# CONFIG_9P_FS is not set
+
+#
+# Partition Types
+#
+CONFIG_PARTITION_ADVANCED=y
+# CONFIG_ACORN_PARTITION is not set
+# CONFIG_OSF_PARTITION is not set
+# CONFIG_AMIGA_PARTITION is not set
+# CONFIG_ATARI_PARTITION is not set
+# CONFIG_MAC_PARTITION is not set
+# CONFIG_MSDOS_PARTITION is not set
+# CONFIG_LDM_PARTITION is not set
+# CONFIG_SGI_PARTITION is not set
+# CONFIG_ULTRIX_PARTITION is not set
+# CONFIG_SUN_PARTITION is not set
+# CONFIG_KARMA_PARTITION is not set
+# CONFIG_EFI_PARTITION is not set
+
+#
+# Native Language Support
+#
+# CONFIG_NLS is not set
+
+#
+# QE Options
+#
+# CONFIG_UCC_SLOW is not set
+CONFIG_UCC_FAST=y
+CONFIG_UCC=y
+
+#
+# Library routines
+#
+# CONFIG_CRC_CCITT is not set
+# CONFIG_CRC16 is not set
+CONFIG_CRC32=y
+# CONFIG_LIBCRC32C is not set
+CONFIG_PLIST=y
+
+#
+# Instrumentation Support
+#
+# CONFIG_PROFILING is not set
+
+#
+# Kernel hacking
+#
+# CONFIG_PRINTK_TIME is not set
+# CONFIG_MAGIC_SYSRQ is not set
+# CONFIG_UNUSED_SYMBOLS is not set
+# CONFIG_DEBUG_KERNEL is not set
+CONFIG_LOG_BUF_SHIFT=14
+# CONFIG_DEBUG_FS is not set
+# CONFIG_BOOTX_TEXT is not set
+# CONFIG_SERIAL_TEXT_DEBUG is not set
+# CONFIG_PPC_EARLY_DEBUG is not set
+
+#
+# Security options
+#
+# CONFIG_KEYS is not set
+# CONFIG_SECURITY is not set
+
+#
+# Cryptographic options
+#
+CONFIG_CRYPTO=y
+# CONFIG_CRYPTO_HMAC is not set
+# CONFIG_CRYPTO_NULL is not set
+# CONFIG_CRYPTO_MD4 is not set
+CONFIG_CRYPTO_MD5=y
+# CONFIG_CRYPTO_SHA1 is not set
+# CONFIG_CRYPTO_SHA256 is not set
+# CONFIG_CRYPTO_SHA512 is not set
+# CONFIG_CRYPTO_WP512 is not set
+# CONFIG_CRYPTO_TGR192 is not set
+CONFIG_CRYPTO_DES=y
+# CONFIG_CRYPTO_BLOWFISH is not set
+# CONFIG_CRYPTO_TWOFISH is not set
+# CONFIG_CRYPTO_SERPENT is not set
+# CONFIG_CRYPTO_AES is not set
+# CONFIG_CRYPTO_CAST5 is not set
+# CONFIG_CRYPTO_CAST6 is not set
+# CONFIG_CRYPTO_TEA is not set
+# CONFIG_CRYPTO_ARC4 is not set
+# CONFIG_CRYPTO_KHAZAD is not set
+# CONFIG_CRYPTO_ANUBIS is not set
+# CONFIG_CRYPTO_DEFLATE is not set
+# CONFIG_CRYPTO_MICHAEL_MIC is not set
+# CONFIG_CRYPTO_CRC32C is not set
+# CONFIG_CRYPTO_TEST is not set
+
+#
+# Hardware crypto devices
+#
diff --git a/arch/powerpc/platforms/83xx/Kconfig b/arch/powerpc/platforms/83xx/Kconfig
index 5fe7b7f..a5d349b 100644
--- a/arch/powerpc/platforms/83xx/Kconfig
+++ b/arch/powerpc/platforms/83xx/Kconfig
@@ -25,6 +25,13 @@ config MPC834x_ITX
 	  Be aware that PCI initialization is the bootloader's
 	  responsiblilty.
 
+config MPC8360E_PB
+	bool "Freescale MPC8360E PB"
+	select DEFAULT_UIMAGE
+	select QUICC_ENGINE
+	help
+	  This option enables support for the MPC836x EMDS Processor Board.
+
 endchoice
 
 config MPC834x
@@ -33,4 +40,14 @@ config MPC834x
 	select PPC_INDIRECT_PCI
 	default y if MPC834x_SYS || MPC834x_ITX
 
+config MPC836x
+	bool
+	select PPC_UDBG_16550
+	select PPC_INDIRECT_PCI
+	default y if MPC8360E_PB
+
+config 834x_USB_SUPPORT
+	bool
+	default y if MPC834x_SYS && (USB || USB_GADGET)
+	
 endmenu
diff --git a/arch/powerpc/platforms/83xx/Makefile b/arch/powerpc/platforms/83xx/Makefile
index 9387a11..0da2d0d 100644
--- a/arch/powerpc/platforms/83xx/Makefile
+++ b/arch/powerpc/platforms/83xx/Makefile
@@ -5,3 +5,4 @@ obj-y				:= misc.o
 obj-$(CONFIG_PCI)		+= pci.o
 obj-$(CONFIG_MPC834x_SYS)	+= mpc834x_sys.o
 obj-$(CONFIG_MPC834x_ITX)	+= mpc834x_itx.o
+obj-$(CONFIG_MPC8360E_PB)	+= mpc8360e_pb.o
diff --git a/arch/powerpc/platforms/83xx/mpc8360e_pb.c b/arch/powerpc/platforms/83xx/mpc8360e_pb.c
new file mode 100644
index 0000000..b4692d7
--- /dev/null
+++ b/arch/powerpc/platforms/83xx/mpc8360e_pb.c
@@ -0,0 +1,204 @@
+/*
+ * Copyright (C) Freescale Semicondutor, Inc. 2006. All rights reserved.
+ *
+ * Author: Li Yang <LeoLi@freescale.com>
+ *	   Yin Olivia <Hong-hua.Yin@freescale.com>
+ *
+ * Description:
+ * MPC8360E MDS PB board specific routines. 
+ *
+ * Changelog: 
+ * Jun 21, 2006	Initial version
+ *
+ * This program is free software; you can redistribute  it and/or modify it
+ * under  the terms of  the GNU General  Public License as published by the
+ * Free Software Foundation;  either version 2 of the  License, or (at your
+ * option) any later version.
+ */
+
+#include <linux/config.h>
+#include <linux/stddef.h>
+#include <linux/kernel.h>
+#include <linux/init.h>
+#include <linux/errno.h>
+#include <linux/reboot.h>
+#include <linux/pci.h>
+#include <linux/kdev_t.h>
+#include <linux/major.h>
+#include <linux/console.h>
+#include <linux/delay.h>
+#include <linux/seq_file.h>
+#include <linux/root_dev.h>
+#include <linux/initrd.h>
+
+#include <asm/system.h>
+#include <asm/atomic.h>
+#include <asm/time.h>
+#include <asm/io.h>
+#include <asm/machdep.h>
+#include <asm/ipic.h>
+#include <asm/bootinfo.h>
+#include <asm/irq.h>
+#include <asm/prom.h>
+#include <asm/udbg.h>
+#include <sysdev/fsl_soc.h>
+#ifdef CONFIG_QUICC_ENGINE
+#include <asm/immap_qe.h>
+#include <asm/qe_ic.h>
+#endif				/* CONFIG_QUICC_ENGINE */
+#include "mpc83xx.h"
+#include "mpc8360e_pb.h"
+
+#undef DEBUG
+#ifdef DEBUG
+#define DBG(fmt...) udbg_printf(fmt)
+#else
+#define DBG(fmt...)
+#endif
+
+#ifndef CONFIG_PCI
+unsigned long isa_io_base = 0;
+unsigned long isa_mem_base = 0;
+#endif
+
+/* ************************************************************************
+ *
+ * Setup the architecture
+ *
+ */
+static void __init mpc8360_sys_setup_arch(void)
+{
+	struct device_node *np;
+	
+#ifdef CONFIG_QUICC_ENGINE
+	u8 *bcsr_regs;
+#endif
+
+	if (ppc_md.progress)
+		ppc_md.progress("mpc8360_sys_setup_arch()", 0);
+
+	np = of_find_node_by_type(NULL, "cpu");
+	if (np != 0) {
+		unsigned int *fp =
+		    (int *)get_property(np, "clock-frequency", NULL);
+		if (fp != 0)
+			loops_per_jiffy = *fp / HZ;
+		else
+			loops_per_jiffy = 50000000 / HZ;
+		of_node_put(np);
+	}
+#ifdef CONFIG_PCI
+	for (np = NULL; (np = of_find_node_by_type(np, "pci")) != NULL;)
+		add_bridge(np);
+
+	ppc_md.pci_swizzle = common_swizzle;
+	ppc_md.pci_exclude_device = mpc83xx_exclude_device;
+#endif
+
+#ifdef CONFIG_QUICC_ENGINE
+	qe_reset();
+
+	for (np = NULL; (np = of_find_node_by_name(np, "ucc")) != NULL;)
+		par_io_of_config(np);
+	
+	if ((np = of_find_compatible_node(NULL, "network", "ucc_geth")) 
+			!= NULL){
+		/* Reset the Ethernet PHY */
+		bcsr_regs = (u8 *) ioremap(BCSR_PHYS_ADDR, BCSR_SIZE);
+		bcsr_regs[9] &= ~0x20;
+		udelay(1000);
+		bcsr_regs[9] |= 0x20;
+		iounmap(bcsr_regs);
+		of_node_put(np);
+	}
+
+#endif				/* CONFIG_QUICC_ENGINE */
+
+#ifdef CONFIG_BLK_DEV_INITRD
+	if (initrd_start)
+		ROOT_DEV = Root_RAM0;
+	else
+#endif
+#ifdef  CONFIG_ROOT_NFS
+		ROOT_DEV = Root_NFS;
+#else
+		ROOT_DEV = Root_HDA1;
+#endif
+}
+
+void __init mpc8360_sys_init_IRQ(void)
+{
+
+	struct device_node *np;
+
+	np = of_find_node_by_type(NULL, "ipic");
+	if (!np)
+		return;
+
+	ipic_init(np, 0);
+
+	/* Initialize the default interrupt mapping priorities,
+	 * in case the boot rom changed something on us.
+	 */
+	ipic_set_default_priority();
+	of_node_put(np);
+
+#ifdef CONFIG_QUICC_ENGINE
+	np = of_find_node_by_type(NULL, "qeic");
+	if (!np)
+		return;
+
+	qe_ic_init(np, 0); 
+	of_node_put(np);
+#endif				/* CONFIG_QUICC_ENGINE */
+}
+
+#if defined(CONFIG_I2C_MPC) && defined(CONFIG_SENSORS_DS1374)
+extern ulong ds1374_get_rtc_time(void);
+extern int ds1374_set_rtc_time(ulong);
+
+static int __init mpc8360_rtc_hookup(void)
+{
+	struct timespec tv;
+
+	ppc_md.get_rtc_time = ds1374_get_rtc_time;
+	ppc_md.set_rtc_time = ds1374_set_rtc_time;
+
+	tv.tv_nsec = 0;
+	tv.tv_sec = (ppc_md.get_rtc_time) ();
+	do_settimeofday(&tv);
+
+	return 0;
+}
+
+late_initcall(mpc8360_rtc_hookup);
+#endif
+
+/*
+ * Called very early, MMU is off, device-tree isn't unflattened
+ */
+static int __init mpc8360_sys_probe(void)
+{
+	char *model = of_get_flat_dt_prop(of_get_flat_dt_root(),
+					  "model", NULL);
+	if (model == NULL)
+		return 0;
+	if (strcmp(model, "MPC8360EPB"))
+		return 0;
+
+	DBG("MPC8360EMDS-PB found\n");
+
+	return 1;
+}
+
+define_machine(mpc8360_sys) {
+	.name 		= "MPC8360E PB",
+	.probe 		= mpc8360_sys_probe,
+	.setup_arch 	= mpc8360_sys_setup_arch,
+	.init_IRQ 	= mpc8360_sys_init_IRQ,
+	.get_irq 	= ipic_get_irq,
+	.restart 	= mpc83xx_restart,
+	.time_init 	= mpc83xx_time_init,
+	.calibrate_decr	= generic_calibrate_decr,
+	.progress 	= udbg_progress,
+};
diff --git a/arch/powerpc/platforms/83xx/mpc8360e_pb.h b/arch/powerpc/platforms/83xx/mpc8360e_pb.h
new file mode 100644
index 0000000..84282e5
--- /dev/null
+++ b/arch/powerpc/platforms/83xx/mpc8360e_pb.h
@@ -0,0 +1,31 @@
+/*
+ * Copyright (C) Freescale Semicondutor, Inc. 2006. All rights reserved.
+ *
+ * Author: Li Yang <LeoLi@freescale.com>
+ *	   Yin Olivia <Hong-hua.Yin@freescale.com>
+ *
+ * Description:
+ * MPC8360E MDS PB board specific header. 
+ *
+ * Changelog: 
+ * Jun 21, 2006	Initial version
+ *
+ * This program is free software; you can redistribute  it and/or modify it
+ * under  the terms of  the GNU General  Public License as published by the
+ * Free Software Foundation;  either version 2 of the  License, or (at your
+ * option) any later version.
+ *
+ */
+
+#ifndef __MACH_MPC83XX_SYS_H__
+#define __MACH_MPC83XX_SYS_H__
+
+#define BCSR_PHYS_ADDR		((uint)0xf8000000)
+#define BCSR_SIZE		((uint)(32 * 1024))
+
+#ifdef CONFIG_QUICC_ENGINE
+extern void qe_reset(void);
+extern int par_io_of_config(struct device_node *np);
+#endif  /* CONFIG_QUICC_ENGINE */
+
+#endif				/* __MACH_MPC83XX_SYS_H__ */

Re: [PATCH 10/11] Add MPC8360EMDS board support

[Paul Mackerras]

Li Yang writes:

> +#define BCSR_PHYS_ADDR		((uint)0xf8000000)
> +#define BCSR_SIZE		((uint)(32 * 1024))

This sort of thing should really be in the device tree.

Paul.

Re: [PATCH 10/11] Add MPC8360EMDS board support

[Vitaly Bordug]

On Wed, 27 Sep 2006 16:39:11 +1000
Paul Mackerras <paulus@samba.org> wrote:

> Li Yang writes:
> 
> > +#define BCSR_PHYS_ADDR		((uint)0xf8000000)
> > +#define BCSR_SIZE		((uint)(32 * 1024))
> 
> This sort of thing should really be in the device tree.
> 
Just a suggestion, but for the similar aim in pq2 I have those stuff in memory node :

+memory {
+               device_type = "memory";
+               linux,phandle = <300>;
+               reg = <00000000 4000000 f4500000 00000020>;
+       };
the second pair is about bcsr and its size.

Just in case this may help (and wondering if I'm not violating something :) ) 
-- 
Sincerely, 
Vitaly

RE: [PATCH 10/11] Add MPC8360EMDS board support

[Li Yang-r58472]

> -----Original Message-----
> From: Vitaly Bordug [mailto:vbordug@ru.mvista.com]
> Sent: Wednesday, September 27, 2006 7:56 PM
> To: Paul Mackerras
> Cc: Li Yang-r58472; linuxppc-dev@ozlabs.org
> Subject: Re: [PATCH 10/11] Add MPC8360EMDS board support
>=20
> On Wed, 27 Sep 2006 16:39:11 +1000
> Paul Mackerras <paulus@samba.org> wrote:
>=20
> > Li Yang writes:
> >
> > > +#define BCSR_PHYS_ADDR		((uint)0xf8000000)
> > > +#define BCSR_SIZE		((uint)(32 * 1024))
> >
> > This sort of thing should really be in the device tree.
> >
> Just a suggestion, but for the similar aim in pq2 I have those stuff
in memory node :
>=20
> +memory {
> +               device_type =3D "memory";
> +               linux,phandle =3D <300>;
> +               reg =3D <00000000 4000000 f4500000 00000020>;
> +       };
> the second pair is about bcsr and its size.
>=20
> Just in case this may help (and wondering if I'm not violating
something :) )

Well, this can make it work.  But I would prefer to use a new node
because the BCSR is by no means a memory type of device.  I have made my
change to use node like this:

        bcsr@f8000000 {
                device_type =3D "board-control";
                reg =3D <f8000000 8000>;
        };

- Leo

Re: [PATCH 10/11] Add MPC8360EMDS board support

[Vitaly Bordug]

On Wed, 27 Sep 2006 20:02:56 +0800
"Li Yang-r58472" <LeoLi@freescale.com> wrote:

> > -----Original Message-----
> > From: Vitaly Bordug [mailto:vbordug@ru.mvista.com]
> > Sent: Wednesday, September 27, 2006 7:56 PM
> > To: Paul Mackerras
> > Cc: Li Yang-r58472; linuxppc-dev@ozlabs.org
> > Subject: Re: [PATCH 10/11] Add MPC8360EMDS board support
> > 
> > On Wed, 27 Sep 2006 16:39:11 +1000
> > Paul Mackerras <paulus@samba.org> wrote:
> > 
> > > Li Yang writes:
> > >
> > > > +#define BCSR_PHYS_ADDR		((uint)0xf8000000)
> > > > +#define BCSR_SIZE		((uint)(32 * 1024))
> > >
> > > This sort of thing should really be in the device tree.
> > >
> > Just a suggestion, but for the similar aim in pq2 I have those stuff
> in memory node :
> > 
> > +memory {
> > +               device_type = "memory";
> > +               linux,phandle = <300>;
> > +               reg = <00000000 4000000 f4500000 00000020>;
> > +       };
> > the second pair is about bcsr and its size.
> > 
> > Just in case this may help (and wondering if I'm not violating
> something :) )
> 
> Well, this can make it work.  But I would prefer to use a new node
> because the BCSR is by no means a memory type of device.  I have made my
> change to use node like this:
> 
>         bcsr@f8000000 {
>                 device_type = "board-control";
>                 reg = <f8000000 8000>;
>         };
> 

I though about that approach, but saw somewhere a reference that we should not summon new node types without utter necessity, and utilized memory because bcsr is memory-mapped stuff. I can hardly imagine bcsr as a device (which would require respective spec inclusion btw).

hence let's open a discussion what others think about that. The problem seems common (and for some boards 
is called somewhat else apparently), but at this point we should come to some conclusion, document it, and use it.

-- 
Sincerely, 
Vitaly

Re: [PATCH 10/11] Add MPC8360EMDS board support

[Ben Warren]

On Wed, 2006-09-27 at 16:55 +0400, Vitaly Bordug wrote:

> 
> I though about that approach, but saw somewhere a reference that we should not summon new node types without utter necessity, and utilized memory because bcsr is memory-mapped stuff. I can hardly imagine bcsr as a device (which would require respective spec inclusion btw).
> 
> hence let's open a discussion what others think about that. The problem seems common (and for some boards 
> is called somewhat else apparently), but at this point we should come to some conclusion, document it, and use it.
> 
Since "memory" is not quite specific enough, but "board-control" is a
little bit Freescale and application-centric, how about
"memmapped-device", or something like that.  This could encompass FPGAs,
ASICs, CPLDs or anything else that is memory mapped.  Many custom
embedded boards have lots of such devices and could benefit from this
approach.

regards,
Ben

RE: [PATCH 10/11] Add MPC8360EMDS board support

[Li Yang-r58472]

> -----Original Message-----
> From: Vitaly Bordug [mailto:vbordug@ru.mvista.com]
> Sent: Wednesday, September 27, 2006 8:56 PM
> To: Li Yang-r58472
> Cc: Paul Mackerras; linuxppc-dev@ozlabs.org
> Subject: Re: [PATCH 10/11] Add MPC8360EMDS board support
>=20
> On Wed, 27 Sep 2006 20:02:56 +0800
> "Li Yang-r58472" <LeoLi@freescale.com> wrote:
>=20
> > > -----Original Message-----
> > > From: Vitaly Bordug [mailto:vbordug@ru.mvista.com]
> > > Sent: Wednesday, September 27, 2006 7:56 PM
> > > To: Paul Mackerras
> > > Cc: Li Yang-r58472; linuxppc-dev@ozlabs.org
> > > Subject: Re: [PATCH 10/11] Add MPC8360EMDS board support
> > >
> > > On Wed, 27 Sep 2006 16:39:11 +1000
> > > Paul Mackerras <paulus@samba.org> wrote:
> > >
> > > > Li Yang writes:
> > > >
> > > > > +#define BCSR_PHYS_ADDR		((uint)0xf8000000)
> > > > > +#define BCSR_SIZE		((uint)(32 * 1024))
> > > >
> > > > This sort of thing should really be in the device tree.
> > > >
> > > Just a suggestion, but for the similar aim in pq2 I have those
stuff
> > in memory node :
> > >
> > > +memory {
> > > +               device_type =3D "memory";
> > > +               linux,phandle =3D <300>;
> > > +               reg =3D <00000000 4000000 f4500000 00000020>;
> > > +       };
> > > the second pair is about bcsr and its size.
> > >
> > > Just in case this may help (and wondering if I'm not violating
> > something :) )
> >
> > Well, this can make it work.  But I would prefer to use a new node
> > because the BCSR is by no means a memory type of device.  I have
made my
> > change to use node like this:
> >
> >         bcsr@f8000000 {
> >                 device_type =3D "board-control";
> >                 reg =3D <f8000000 8000>;
> >         };
> >
>=20
> I though about that approach, but saw somewhere a reference that we
should not summon
> new node types without utter necessity, and utilized memory because
bcsr is
> memory-mapped stuff. I can hardly imagine bcsr as a device (which
would require
> respective spec inclusion btw).

Well I didn't see such a guideline.  However BCSR is truly a device like
any other peripherals on board.  Usually it is an FPGA on local bus to
control the board.
>=20
> hence let's open a discussion what others think about that. The
problem seems common
> (and for some boards
> is called somewhat else apparently), but at this point we should come
to some
> conclusion, document it, and use it.

Agreed.  As we are adding more devices to the device tree, we should
also have a guideline clearly stated for adding new nodes. =20

I'm adding MURAM as a new node under QE bus.  Please comment.
                muram@10000 {
                        device_type =3D "memory";
                        ranges =3D <0 00010000 0000c000>;

                        data-only@0{
                                reg =3D <0 c000>;
                        };
                };

- Leo

Re: [PATCH 10/11] Add MPC8360EMDS board support

[Kumar Gala]

>>>> +memory {
>>>> +               device_type = "memory";
>>>> +               linux,phandle = <300>;
>>>> +               reg = <00000000 4000000 f4500000 00000020>;
>>>> +       };
>>>> the second pair is about bcsr and its size.
>>>>
>>>> Just in case this may help (and wondering if I'm not violating
>>> something :) )
>>>
>>> Well, this can make it work.  But I would prefer to use a new node
>>> because the BCSR is by no means a memory type of device.  I have
> made my
>>> change to use node like this:
>>>
>>>         bcsr@f8000000 {
>>>                 device_type = "board-control";
>>>                 reg = <f8000000 8000>;
>>>         };
>>>
>>
>> I though about that approach, but saw somewhere a reference that we
> should not summon
>> new node types without utter necessity, and utilized memory because
> bcsr is
>> memory-mapped stuff. I can hardly imagine bcsr as a device (which
> would require
>> respective spec inclusion btw).
>
> Well I didn't see such a guideline.  However BCSR is truly a device  
> like
> any other peripherals on board.  Usually it is an FPGA on local bus to
> control the board.

Agree that a new node is better, calling it memory isn't right.   
However, I'm not sure this really needs a node in the device tree.  
The BCSR isn't really the same from board to board last time I  
checked.  I'd be interested in Paul's thinking about why it should be  
in the tree.

>> hence let's open a discussion what others think about that. The
> problem seems common
>> (and for some boards
>> is called somewhat else apparently), but at this point we should come
> to some
>> conclusion, document it, and use it.
>
> Agreed.  As we are adding more devices to the device tree, we should
> also have a guideline clearly stated for adding new nodes.
>
> I'm adding MURAM as a new node under QE bus.  Please comment.
>                 muram@10000 {
>                         device_type = "memory";
>                         ranges = <0 00010000 0000c000>;
>
>                         data-only@0{
>                                 reg = <0 c000>;
>                         };
>                 };

What was the need for this?

- kumar

RE: [PATCH 10/11] Add MPC8360EMDS board support

[Joakim Tjernlund]

 >=20
> I'm adding MURAM as a new node under QE bus.  Please comment.
>                 muram@10000 {
>                         device_type =3D "memory";
>                         ranges =3D <0 00010000 0000c000>;
>=20
>                         data-only@0{
>                                 reg =3D <0 c000>;
>                         };
>                 };

while you are at it, I think you should add support for the ASSIGN PAGE
command that can relocate
the parameter RAM used by UCC, SPI etc. As it is now the third(8400) and
fourth(100) value
in reg below is ignored.
	ucc@2000 {
		device_type =3D "network";
		compatible =3D "ucc_geth";
		model =3D "UCC";
		device-id =3D <1>;
		reg =3D <2000 200 8400 100>;
MPC832x only has 16KB of parameter RAM and needs to move this to lower
addresses.=20

Re: [PATCH 10/11] Add MPC8360EMDS board support

[Jon Loeliger]

So, like, the other day "Li Yang-r58472" mumbled:

> Agreed.  As we are adding more devices to the device tree, we should
> also have a guideline clearly stated for adding new nodes.  
> 
> I'm adding MURAM as a new node under QE bus.  Please comment.
>                 muram@10000 {
>                         device_type = "memory";
>                         ranges = <0 00010000 0000c000>;
> 
>                         data-only@0{
>                                 reg = <0 c000>;
>                         };
>                 };
> 
> - Leo

So, does it make sense for this node to participate in the early scan
of memory available during the early_init_dt_scan_memory() pass?

Out of curiosity, is "data-only" a standard thing, or did you make
that up too?  What's it mean?	

And your patch for this new node introduction will contain
proposed additions to the QE section of the booting-without-of
documentation, right?

Thanks,
jdl

Re: [PATCH 10/11] Add MPC8360EMDS board support

[Dan Malek]

On Sep 27, 2006, at 8:55 AM, Vitaly Bordug wrote:

> hence let's open a discussion what others think about that. The  
> problem seems common (and for some boards
> is called somewhat else apparently), but at this point we should  
> come to some conclusion, document it, and use it.

Well, I haven't voiced my opinion lately..........  :-)

I think this is totally out of control.  I don't even know what
we are trying to create here any more.  We took a reasonable
idea to express some configuration flexibility and are running
off into into some world that we think we need to create
something infinitely flexible that anyone can use for anything
they wish.  I could expect this from a university research
project, but not from seasoned developers that are trying
to create products where only a few real configuration
combinations make sense.

Since BCSRs are board specific, does anyone remember
the day when a simple #define, ioremap, and a few lines
of code in the board setup file was all that was needed? :-)
What wrong with still doing that?  It seems everyone is
obsessed with device tree syntax and forget that a
few lines of code may still be a reasonable solution.

I still think an embedded_feature_call() support in a
board port would be the best solution to many of these
complex things we are trying to define in this device
tree information.  In the places where we need some
kind of board specific support, like hardware set up for
some peripheral, just do the feature_call, passing enough
information to indicate what is needed, and let the
board support do what is necessary.  This could be
setting bits in a BCSR, setting up the processor IO
ports, enabling power to external logic, etc.  This has
been proven to work well on the PMAC, just extend it
to be used on embedded boards.

Thanks.

	-- Dan

Re: [PATCH 10/11] Add MPC8360EMDS board support

[Sergei Shtylyov]

Hello.

Vitaly Bordug wrote:

>>>>>+#define BCSR_PHYS_ADDR		((uint)0xf8000000)
>>>>>+#define BCSR_SIZE		((uint)(32 * 1024))

>>>>This sort of thing should really be in the device tree.

>>>Just a suggestion, but for the similar aim in pq2 I have those stuff

>>in memory node :

>>>+memory {
>>>+               device_type = "memory";
>>>+               linux,phandle = <300>;
>>>+               reg = <00000000 4000000 f4500000 00000020>;
>>>+       };
>>>the second pair is about bcsr and its size.

>>>Just in case this may help (and wondering if I'm not violating

>>something :) )

>>Well, this can make it work.  But I would prefer to use a new node
>>because the BCSR is by no means a memory type of device.  I have made my
>>change to use node like this:

>>        bcsr@f8000000 {
>>                device_type = "board-control";
>>                reg = <f8000000 8000>;
>>        };

> I though about that approach, but saw somewhere a reference that we should not summon new node types without utter necessity, and utilized memory because bcsr is memory-mapped stuff.

    You might have utilized "memory" even for the Ethernet controllers guided 
by such logic. Of course, that was a wrong criterion -- "memory" is for RAM, 
otherwise you'd be fooling the kernel device tree scanner which looks for the 
"memory" nodes.

> I can hardly imagine bcsr as a device (which would require respective spec inclusion btw).

    And this is hardly a memory, neverthless.

WBR, Sergei

Re: [PATCH 10/11] Add MPC8360EMDS board support

[Olof Johansson]

On Wed, 27 Sep 2006 10:42:17 -0400 Dan Malek <dan@embeddedalley.com> wrote:

> Since BCSRs are board specific, does anyone remember
> the day when a simple #define, ioremap, and a few lines
> of code in the board setup file was all that was needed? :-)

Yes, also called "board port hell". One of the major points with the
device tree is that the needed information for the system is in there,
not compiled into the kernel. So you can boot the same kernel binary on
several boards, as long as the drivers are built in and the correct
device tree is used. Has everyone missed/forgotten that objective
completely?

> What wrong with still doing that?  It seems everyone is
> obsessed with device tree syntax and forget that a
> few lines of code may still be a reasonable solution.

The device tree describes the system, not how to program it. I think
that's where the confusion might be.

I.e. create a generic "board-controller" device node, and put a
suitable "compatible" property in there, so the right board controller
driver can be chosen based on it. Having the address of the controller
in there helps too, especially if there are two boards out there with
the same controller but at different memory location.


-Olof

Re: [PATCH 10/11] Add MPC8360EMDS board support

[Dan Malek]

On Sep 27, 2006, at 12:22 PM, Olof Johansson wrote:

> Yes, also called "board port hell".

I tend to think people skilled to do a board port
will still create something elegant and functional
given whatever the existing model.

> ....   So you can boot the same kernel binary on
> several boards, as long as the drivers are built in and the correct
> device tree is used. Has everyone missed/forgotten that objective
> completely?

That was never an objective when we started, although
it seems some people involved in the implementation
think it's the only objective.  It just happens to be a side
effect when convenient.

If you could look back over the eight or more years
of embedded Linux development with PowerPC, this
discussion of supporting multiple boards with
single binaries has occurred.  In all cases, we never
considered it a requirement, there are many others
more important in embedded systems.  Our greatest
concern was sharing code among all platforms, but
in a way we could still configure the most compact
and highest performance code for a particular
processor and board.

Although processors are faster and memory is larger
today, embedded systems are still trying to do more with
less.  We still try to run the slowest processor speed to
conserve power and meet environmental requirements.
Memory still costs money, and designs try to use the
minimum amount to be cost competitive.  IMHO, the same
requirements for compact and efficient code are just
as important today as they were when we had the first
discussion years ago.  Conversion of the information,
kernel code just hanging around in case it may be used
on some board but not another and reliance on a
particular version of boot code are things we have
always tried to avoid.  We are competing against other
processor architectures that are more compact and
resource friendly, it would be nice to not lose in
those product designs.

> The device tree describes the system, not how to program it. I think
> that's where the confusion might be.

There is no confusion.  This device tree discussion was started
several years ago by a couple of us trying to find a way to better
describe the wide variety of PowerPC SOC processor peripheral
variants.  Kumar and I had many discussions about this, since
my old static internal memory maps weren't going to work well.
The IBM microelectronics folks were also looking for something
similar.  We thought a _simple_ flat device tree along with
the platform data would be sufficient to define this internal
peripheral mapping.  I wasn't too keen on the idea, but didn't
have the time to provide any alternative implementation
against the Freescale coding machine :-)

Now, we have something that is way more complex than
we initially thought was necessary, trying to describe nearly
everything addressable in the system instead of just the
internal memory map.  I suspect the software to attain
(IMHO the useless) goal of a single binary for multiple
boards will create exponentially complex software,
something that highly reliable embedded systems
are trying to avoid.

> I.e. create a generic "board-controller" device node, and put a
> suitable "compatible" property in there, so the right board controller
> driver can be chosen based on it. Having the address of the controller
> in there helps too, especially if there are two boards out there with
> the same controller but at different memory location.

What value does this provide to my client trying
to create a cost effective wireless home networking
device?  It certainly doesn't make the board port
from hell any easier, since cramming the software
into 4M of flash will likely cause the choice of a
processor other than PowerPC that can configure
a smaller kernel and use a tiny custom piece of
boot code.  Highly configurable development/evaluation
boards running a single binary aren't high volume
products, and the additional resources required
by such software could ensure real products aren't
developed with PPCs.  We need to be sensitive
to this.

Thanks.

	-- Dan

RE: [PATCH 10/11] Add MPC8360EMDS board support

[Li Yang-r58472]

> -----Original Message-----
> From: Kumar Gala [mailto:galak@kernel.crashing.org]
> Sent: Wednesday, September 27, 2006 9:34 PM
> To: Li Yang-r58472
> Cc: Vitaly Bordug; linuxppc-dev@ozlabs.org; Paul Mackerras
> Subject: Re: [PATCH 10/11] Add MPC8360EMDS board support
>=20
> >>>> +memory {
> >>>> +               device_type =3D "memory";
> >>>> +               linux,phandle =3D <300>;
> >>>> +               reg =3D <00000000 4000000 f4500000 00000020>;
> >>>> +       };
> >>>> the second pair is about bcsr and its size.
> >>>>
> >>>> Just in case this may help (and wondering if I'm not violating
> >>> something :) )
> >>>
> >>> Well, this can make it work.  But I would prefer to use a new node
> >>> because the BCSR is by no means a memory type of device.  I have
> > made my
> >>> change to use node like this:
> >>>
> >>>         bcsr@f8000000 {
> >>>                 device_type =3D "board-control";
> >>>                 reg =3D <f8000000 8000>;
> >>>         };
> >>>
> >>
> >> I though about that approach, but saw somewhere a reference that we
> > should not summon
> >> new node types without utter necessity, and utilized memory because
> > bcsr is
> >> memory-mapped stuff. I can hardly imagine bcsr as a device (which
> > would require
> >> respective spec inclusion btw).
> >
> > Well I didn't see such a guideline.  However BCSR is truly a device
> > like
> > any other peripherals on board.  Usually it is an FPGA on local bus
to
> > control the board.
>=20
> Agree that a new node is better, calling it memory isn't right.
> However, I'm not sure this really needs a node in the device tree.
> The BCSR isn't really the same from board to board last time I
> checked.  I'd be interested in Paul's thinking about why it should be
> in the tree.
>=20
> >> hence let's open a discussion what others think about that. The
> > problem seems common
> >> (and for some boards
> >> is called somewhat else apparently), but at this point we should
come
> > to some
> >> conclusion, document it, and use it.
> >
> > Agreed.  As we are adding more devices to the device tree, we should
> > also have a guideline clearly stated for adding new nodes.
> >
> > I'm adding MURAM as a new node under QE bus.  Please comment.
> >                 muram@10000 {
> >                         device_type =3D "memory";
> >                         ranges =3D <0 00010000 0000c000>;
> >
> >                         data-only@0{
> >                                 reg =3D <0 c000>;
> >                         };
> >                 };
>=20
> What was the need for this?


Data-only defines MURAM area which can be allocated for data and
parameter ram.  Some MURAM space can be occupied by microcode or
microcode patch, and should be excluded from allocation.

- Leo

RE: [PATCH 10/11] Add MPC8360EMDS board support

[Li Yang-r58472]

> -----Original Message-----
> From: Jon Loeliger [mailto:jdl@jdl.com]
> Sent: Wednesday, September 27, 2006 10:14 PM
> To: Li Yang-r58472
> Cc: Vitaly Bordug; linuxppc-dev@ozlabs.org; Paul Mackerras
> Subject: Re: [PATCH 10/11] Add MPC8360EMDS board support
>=20
> So, like, the other day "Li Yang-r58472" mumbled:
>=20
> > Agreed.  As we are adding more devices to the device tree, we should
> > also have a guideline clearly stated for adding new nodes.
> >
> > I'm adding MURAM as a new node under QE bus.  Please comment.
> >                 muram@10000 {
> >                         device_type =3D "memory";
> >                         ranges =3D <0 00010000 0000c000>;
> >
> >                         data-only@0{
> >                                 reg =3D <0 c000>;
> >                         };
> >                 };
> >
> > - Leo
>=20
> So, does it make sense for this node to participate in the early scan
> of memory available during the early_init_dt_scan_memory() pass?
>=20

Are all "memory" type nodes regarded as system memory during the early
scan?  If so, it needs to use a new device_type "muram" I think.

> Out of curiosity, is "data-only" a standard thing, or did you make
> that up too?  What's it mean?

Well, it is from kernel code of cpm/cpm2 era.  It defines the MURAM area
which can be freely allocated.  The base and size of such area vary
between chips and revisions, even boards.

- Leo

Re: [PATCH 10/11] Add MPC8360EMDS board support

[Paul Mackerras]

Kumar Gala writes:

> However, I'm not sure this really needs a node in the device tree.  
> The BCSR isn't really the same from board to board last time I  
> checked.  I'd be interested in Paul's thinking about why it should be  
> in the tree.

I just have a general preference for putting device addresses in the
device tree, because it increases the chance that you can reuse code
for multiple boards.  If the BCSR is always completely unique on every
board then there isn't so much of an argument for it, I agree.

Paul.

Re: [PATCH 10/11] Add MPC8360EMDS board support

[Li Yang]

Dan,

I do share the same concern as you.  Single image for multiple
platforms is a great feature for server and desktop, but not as
valuable to embedded devices.  Response time and footprint are more
important concerns.  However, OTOH, OF device tree is a good
architecture for code reuse and porting.  It is better for reuse as it
enables code sharing between embedded and desktop devices.  It is more
and more popular to use peripherals from desktop on embedded systems.
Better for porting because:  from the single DTS file, we can get/set
all the information about the system, instead of hacking into dozens
of drivers.  It is a tough choice to make.

Well, I have an idea.  Maybe it can relief the side effect of DT to
embedded systems, but I'm even not sure if it is feasible or not.  If
we can rework the prom APIs, make them to have two modes, embedded and
non-embedded.  It should be switched using a configuration option.
For non-embedded mode, they just act the same as what we have now,
which get properties from looking up the tree at runtime.  While in
embedded mode, the prom APIs actually compile the properties to be
looked up in tree into the code as const values.  Thus save the
time/space consumed by look-up.  Well.  The implementation maybe too
complex, maybe needs overhaul to dtc.  I'm just sharing the idea to
see what others think about it.  ;)

- Leo

On 9/28/06, Dan Malek <dan@embeddedalley.com> wrote:
>
> On Sep 27, 2006, at 12:22 PM, Olof Johansson wrote:
>
> > Yes, also called "board port hell".
>
> I tend to think people skilled to do a board port
> will still create something elegant and functional
> given whatever the existing model.
>
> > ....   So you can boot the same kernel binary on
> > several boards, as long as the drivers are built in and the correct
> > device tree is used. Has everyone missed/forgotten that objective
> > completely?
>
> That was never an objective when we started, although
> it seems some people involved in the implementation
> think it's the only objective.  It just happens to be a side
> effect when convenient.
>
> If you could look back over the eight or more years
> of embedded Linux development with PowerPC, this
> discussion of supporting multiple boards with
> single binaries has occurred.  In all cases, we never
> considered it a requirement, there are many others
> more important in embedded systems.  Our greatest
> concern was sharing code among all platforms, but
> in a way we could still configure the most compact
> and highest performance code for a particular
> processor and board.
>
> Although processors are faster and memory is larger
> today, embedded systems are still trying to do more with
> less.  We still try to run the slowest processor speed to
> conserve power and meet environmental requirements.
> Memory still costs money, and designs try to use the
> minimum amount to be cost competitive.  IMHO, the same
> requirements for compact and efficient code are just
> as important today as they were when we had the first
> discussion years ago.  Conversion of the information,
> kernel code just hanging around in case it may be used
> on some board but not another and reliance on a
> particular version of boot code are things we have
> always tried to avoid.  We are competing against other
> processor architectures that are more compact and
> resource friendly, it would be nice to not lose in
> those product designs.
>
> > The device tree describes the system, not how to program it. I think
> > that's where the confusion might be.
>
> There is no confusion.  This device tree discussion was started
> several years ago by a couple of us trying to find a way to better
> describe the wide variety of PowerPC SOC processor peripheral
> variants.  Kumar and I had many discussions about this, since
> my old static internal memory maps weren't going to work well.
> The IBM microelectronics folks were also looking for something
> similar.  We thought a _simple_ flat device tree along with
> the platform data would be sufficient to define this internal
> peripheral mapping.  I wasn't too keen on the idea, but didn't
> have the time to provide any alternative implementation
> against the Freescale coding machine :-)
>
> Now, we have something that is way more complex than
> we initially thought was necessary, trying to describe nearly
> everything addressable in the system instead of just the
> internal memory map.  I suspect the software to attain
> (IMHO the useless) goal of a single binary for multiple
> boards will create exponentially complex software,
> something that highly reliable embedded systems
> are trying to avoid.
>
> > I.e. create a generic "board-controller" device node, and put a
> > suitable "compatible" property in there, so the right board controller
> > driver can be chosen based on it. Having the address of the controller
> > in there helps too, especially if there are two boards out there with
> > the same controller but at different memory location.
>
> What value does this provide to my client trying
> to create a cost effective wireless home networking
> device?  It certainly doesn't make the board port
> from hell any easier, since cramming the software
> into 4M of flash will likely cause the choice of a
> processor other than PowerPC that can configure
> a smaller kernel and use a tiny custom piece of
> boot code.  Highly configurable development/evaluation
> boards running a single binary aren't high volume
> products, and the additional resources required
> by such software could ensure real products aren't
> developed with PPCs.  We need to be sensitive
> to this.
>
> Thanks.
>
>        -- Dan
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>

Re: [PATCH 10/11] Add MPC8360EMDS board support

[Paul Mackerras]

Dan Malek writes:

> > ....   So you can boot the same kernel binary on
> > several boards, as long as the drivers are built in and the correct
> > device tree is used. Has everyone missed/forgotten that objective
> > completely?
> 
> That was never an objective when we started, although
> it seems some people involved in the implementation
> think it's the only objective.  It just happens to be a side
> effect when convenient.

I tend to look at it not as a direct objective in itself for the
embedded platforms, but more as something that will just happen
naturally when the code is written well.

I also don't think it's the role of the upstream kernel sources to
support every single embedded board out there.  I think stuff should
be upstream if it is either (a) useful to a lot of people as-is, or
(b) useful as a starting point for making a kernel that will work on a
specific board.

Most of the embedded stuff falls into category (b), which means that
it needs to be understandable and reusable, rather than being
specifically optimized for a particular board.  That means that ifdefs
are evil, because they obfuscate the code.  Also, ifdefs are often a
sign that a driver is only written to support one instance of a
particular device, which is a limitation on its reusability - it will
have to be modified when someone makes a chip or board that has two of
its device on it.

I have no problem whatever with someone taking the upstream sources
and optimizing it to the nth degree for their particular embedded
board.  I don't think that's appropriate for the upstream sources
though.

The device-tree concept offers a way to make drivers more readable and
reusable, by separating out the board-specific configuration
information (thus reducing ifdefs) and by encouraging the style of
code that naturally copes with any number of device instances.

> Now, we have something that is way more complex than
> we initially thought was necessary, trying to describe nearly
> everything addressable in the system instead of just the
> internal memory map.  I suspect the software to attain

How does the "internal memory map" differ from "everything addressable
in the system"?  I think it is useful if the device tree describes the
non-discoverable devices in the system; we have never said the device
tree has to contain devices that the kernel can discover for itself,
such as PCI devices.

> Highly configurable development/evaluation
> boards running a single binary aren't high volume
> products, and the additional resources required
> by such software could ensure real products aren't
> developed with PPCs.  We need to be sensitive
> to this.

Leo Li had an interesting idea, which is a preprocessor that would
take kernel code written to use the device tree, plus the specific
device tree for a board, and emit a version of the code with
everything hard-coded.  That would assist with getting the
uber-optimized version that you want for a product.

Paul.

Re: [PATCH 10/11] Add MPC8360EMDS board support

[Benjamin Herrenschmidt]

> I still think an embedded_feature_call() support in a
> board port would be the best solution to many of these
> complex things we are trying to define in this device
> tree information.  In the places where we need some
> kind of board specific support, like hardware set up for
> some peripheral, just do the feature_call, passing enough
> information to indicate what is needed, and let the
> board support do what is necessary.  This could be
> setting bits in a BCSR, setting up the processor IO
> ports, enabling power to external logic, etc.  This has
> been proven to work well on the PMAC, just extend it
> to be used on embedded boards.

I don't see how a mecanism of feature call at the board support level is
in any way incompatible with the device-tree thing. I'm happy mixing
both on powermac :)

Ben.

Re: [PATCH 10/11] Add MPC8360EMDS board support

[Benjamin Herrenschmidt]

> Now, we have something that is way more complex than
> we initially thought was necessary, trying to describe nearly
> everything addressable in the system instead of just the
> internal memory map.  I suspect the software to attain
> (IMHO the useless) goal of a single binary for multiple
> boards will create exponentially complex software,
> something that highly reliable embedded systems
> are trying to avoid.

It's not that complex and the single binary is not necessarily the main
objective (it's a good practice as it enforce avoiding ugly #ifdef hacks
where not necessary, often not in performance critical code anyway).
There is fundamentally little difference between the OCP tables we had
before and the device-tree. In both cases, the choice was made to not
hard-code the device-infos in the drivers, not only because of the
possible booting-multiple-board stuff (which could have been acheived
with the OCP tables with simple tricks too), but also to make it easier
to have several instances of a given device (very common) etc...

The new device-tree model provides a more flexible and richer semantic
for adding all sort of driver or BSP private infos, and for dealing with
address mapping and interrupt mapping.

When done right, it does simplify the matter. An example that I've seen
internally is embedded boards with all sorts of variety of dodgy
interrupt controllers cascaded on each other. The interrupt tree
mecanism along with the new interrupt code in the powerpc architecture
makes it very easy to handle that, by completely separating the domain
number between the various controllers and using the device-tree to
express the relationship between the devices and interrupt controllers.

It simplifies the code, both on the driver and the platform side, and
keep the whole interrupt tree resresentation in one place: the
device-tree.

I agree that too complex trees are not a good idea, but so far, the
definition we provided for a minimum tree is fairly slim. You do not
-have- to put all your devices in there, but in many case, doing so
makes it simpler for your own code/driver to retreive informations such
as base addresses, interrupts (see above), and all sort of auxilliary
infos you may which to pass to a given driver (MAC address, serial
number, default clock, whatever).

There is a great flexibility of putting whatever you want in there... or
not. It's up to the embedded developper to use that tool, it can be used
in a bloated way, or in a smart way, we aren't enforcing any direction
here.

> What value does this provide to my client trying
> to create a cost effective wireless home networking
> device?  It certainly doesn't make the board port
> from hell any easier, since cramming the software
> into 4M of flash will likely cause the choice of a
> processor other than PowerPC that can configure
> a smaller kernel and use a tiny custom piece of
> boot code.  Highly configurable development/evaluation
> boards running a single binary aren't high volume
> products, and the additional resources required
> by such software could ensure real products aren't
> developed with PPCs.  We need to be sensitive
> to this.

I think you are a bit too dismissive here. The approach has always been
to provide the choice, and I've been fairly careful when designing the
flattened device tree format to keep it as compact as possible. Thus I
expect little overhead of using that mecanism to discover and
instanciate drivers and provide them with configuration informations. 

The value provided to your client, once we have fully sorted out the
matter (some things are still being ironed out and developped, for
example, I'm working on a more generic way to instanciate drivers for
devices probed from the device-tree outside of the well-known realm of
PCI) is hopefully an easier way to create the BSP in the first place, a
central and more maintainable location where what is on his board is
defined, the ability to more easily maintain multiple revisions of the
board, with very little overhead. For such a client, I wouldn't expect
him to build a heavily multi-board kernel nor use a massive bootloader,
and neither are made necessary. The -ability- to build multi-board
kernels is made mandatory for code to be merged upstream, as it enforces
a certain level of quality, but you don't have to actually do it on the
field. In fact, you client may be happy, once it's done rev 3 of the
board with a 3rd type of wifi chip or a 2nd type of ethernet HUB to have
the ability to easily build, maintain, distribute and test a single
kernel image, and just at install (or download) time slap the right
device-tree to form a zImage with embedded device-tree using paulus
latest tool.

Ben.

Re: [PATCH 10/11] Add MPC8360EMDS board support

[Dan Malek]

On Oct 3, 2006, at 8:40 PM, Paul Mackerras wrote:

> ....   That means that ifdefs
> are evil, because they obfuscate the code....

This is not an #ifdefs discussion.  We've had those
discussions many years ago and have done many
things to eliminate that :-)

It's just a discussion about the purpose of placing
things that are quite static about a board port in
the board specific include file with a #define, rather
than trying to add it as a device tree node.

If I:
	#define MY_BOARD_BCSR 0xf00

and then,

	bcsr = ioremap(MY_BOARD_BCSR);

I think it's pretty clear what I'm doing.
In all of my experience, something like a BCSR
is quite board specific and I honestly don't
see any "generic BCSR code" that's going
to exist and actually take advantage of
representing this in a device tree.


> The device-tree concept offers a way to make drivers more readable and
> reusable, by separating out the board-specific configuration
> information (thus reducing ifdefs) and by encouraging the style of
> code that naturally copes with any number of device instances.

Again, it's not a discussion of #ifdefs.  Most of the
drivers we are discussing that take advantage of this
have long since been properly written to use board
specific information without them.  Initially, we just
used #defines in a board specific file, then we had
platform data, now we have device tree.  That "progress"
didn't make a driver any more readable or reusable,
it's just someone's personal preference for yet another
implementation to do the same thing.  The people with
the most time to waste on this are just able to push
that in over the rest of us that don't.

> How does the "internal memory map" differ from "everything addressable
> in the system"?

By quite a bit.  If you look at the Freescale SOC parts,
many have the very same or quite similar functional
units, they may just appear at different addresses
in the memory map for the different variants of
processor.  Again, proper use of #defines in a board
specific file or platform data solved this problem just
as nicely as device tree.  The real progress was using
the smaller addressable units individually rather than
dereference from the large structure.  The way we get
those addresses and information (#defines, platform
data, device tree) wasn't the enabler to this flexibility.

When you venture off the SOC, you not only have
board specific addresses, but also the register
format and even the logic to access these devices
varies greatly from one board to another.  Yeah,
the BCSR address and maybe something about its
size is in the device tree....BFD, what do I do with it?

As we have seen in some e-mail exchanges already,
people have tracking down "bugs" that eventually
ended up in an improper device tree configuration.
I don't see how this makes board ports any easier,
it's just a different way of representing the information
that has been needed all along.....  and adding
additional steps to the process.

> Leo Li had an interesting idea, which is a preprocessor that would
> take kernel code ...

Ummmm,  I'm going to pretend I didn't even hear this
suggestion :-)  Please, no, I really don't see any value
in this.  Talk about obfuscation......  At least I have a
chance at finding my way though #ifdefs :-)

I'm not against using the device tree (or platform data
or #defines) when it's appropriate to do so.  I think our
obsession to represent everything there is what is
creating the complexity.  If a #define in a board
specific port file makes sense, then just do that,
even if it is a BSCR address.  The device tree just
seems like the new toy that everyone wants to play
with, and we are forgetting that the old fashioned way
of just writing some C code may be the way
to implement what we need.

Thanks.

	-- Dan

Re: [PATCH 10/11] Add MPC8360EMDS board support

[Dan Malek]

On Oct 4, 2006, at 2:08 AM, Benjamin Herrenschmidt wrote:

> It's not that complex and the single binary is not necessarily the  
> main
> objective (it's a good practice as it enforce avoiding ugly #ifdef  
> hacks

Would you guys please get off of this #ifdefs discussion! :-)
That's not what this is about.

> There is fundamentally little difference between the OCP tables we had
> before and the device-tree.

Exactly!  So why has it become such a desire to represent
stuff in the device tree that was never necessary to represent
in other table formats before?

> The new device-tree model provides a more flexible and richer semantic
> for adding all sort of driver or BSP private infos, and for dealing  
> with
> address mapping and interrupt mapping.

Not really, we had all of this before.....  and in a way
that I didn't have to learn a new syntax to represent.

> When done right, it does simplify the matter. An example that I've  
> seen
> internally is embedded boards with all sorts of variety of dodgy
> interrupt controllers cascaded on each other.

Good example.  Cascaded interrupt controllers are always
a challenge.  :-)  It doesn't matter how you present the
information about their configuration if you don't have
the code written properly to manage them.  It's the
_code_ you write the solves the problem, not the
device tree.

> It simplifies the code, both on the driver and the platform side,

I don't see that.  If I look at drivers we've had around for
a while that have survived all of these evolutions, the
core of them hasn't changed one bit.  The initialization
functions have gone from simply stuffing an information
data structure with #defined board information to lengthy
process of performing (the once hated) OF searches
and conversion of information, to stuff into the data
structures.


> ....   doing so
> makes it simpler for your own code/driver to retreive informations  
> such
> as base addresses, interrupts (see above), and all sort of auxilliary
> infos you may which to pass to a given driver (MAC address, serial
> number, default clock, whatever).

It doesn't really make it any simpler for the driver, because
they have always retrieved that information in some way that
has been consistent, usually from the old board descriptor
or platform data.  The method of converting that information,
usually a concern of the boot rom or the boot wrapper or
compiled in, is what we are changing now.

> There is a great flexibility of putting whatever you want in  
> there... or
> not.

It's the 'or not' part that I am worried about.  Things like
you mention above make sense.  I'm starting to worry about
some of this other stuff, and the bscr example is what
woke me up :-)  I think that's an example of things that
should be considered not necessary.

> It's up to the embedded developper to use that tool, it can be used
> in a bloated way, or in a smart way, we aren't enforcing any direction
> here.

Not really.  To use a particular driver you are going to have
to provide the proper amount of information.  It's not up to
me as a consumer of something already written.  I can
only control that if I'm the developer of the code.

> I think you are a bit too dismissive here. The approach has always  
> been
> to provide the choice,

There isn't a choice.  If I want to use a particular driver
I have to provide the proper and necessary information
using a device tree, period.  If I want to change my
board design for some reason that is advantageous
to me, and the driver doesn't support it, no possible
convolution of device tree information is going to make
that happen.

> ...  is hopefully an easier way to create the BSP in the first place,

Sorry, but I don't see that.  You are either skilled at
creating a BSP or you are not.  The device tree just adds
another dimension of information in a syntax and structure
that you have to learn.

> .... The -ability- to build multi-board
> kernels is made mandatory for code to be merged upstream,

Why?  When are people going to realize that the
ratio of Linux on custom embedded systems to a standard
workstation is about a million to one?  So what if I
can boot the same kernel on a couple of obsolete
PowerPC workstations using drivers that aren't used
anywhere else?  Or, on a couple of embedded eval
boards that don't represent how people build products?
Hell, I tried to build an x86 kernel the other day
for a PC and still don't have one that boots.  I can't
seem to figure out what processor configuration
options or compiler options to use.  Linux doesn't
even support this on a "standard" PC. :-)

> ... as it enforces
> a certain level of quality,

That's BS and you know it :-)


> ....  In fact, you client may be happy, once it's done rev 3 of the
> board with a 3rd type of wifi chip or a 2nd type of ethernet HUB to  
> have
> the ability to easily build, maintain, distribute and test a single
> kernel image,

That's not very important.  For high volume products that
are already in the field, the way the binary image is created
or if they need different ones on different versions, isn't
important.  The whole process of tracking, testing, distributing,
installing, upgrading, reverting makes our development
tools insignificant to them.  All that is desired is an image
that when upgraded doesn't turn a million boxes into
bricks.  If it does, our cleverness to use a device tree to
support multiple boards better not be the problem, because
if it is it will never be used again.

Thanks.

	-- Dan

Re: [PATCH 10/11] Add MPC8360EMDS board support

[Dan Malek]

On Oct 4, 2006, at 1:52 AM, Benjamin Herrenschmidt wrote:

> I don't see how a mecanism of feature call at the board support  
> level is
> in any way incompatible with the device-tree thing.

It isn't.

> ...  I'm happy mixing
> both on powermac :)

I know.  This was just an opportunity to make people
realize that a board port does require the writing of
some board specific code.  Using the feature call is
an excellent model of portability and flexibility.  My
point was that any BCSR access is necessary to be
hidden behind such a function, because it is truly
board specific.  You can't require the drivers to
have this kind of logic in them, they must call out
to board support functions for assistance.

Just like the powermac ports, embedded drivers
will need a feature call at some points during
their processing (set up clock routing, IO pin
configuration, board specific bus connections,
power management, etc).  Some board ports
may do nothing, others may do lots of work.

Therefore, I see no reason why a BSCR address
and all of it's associated format can't simply
be a #define in a board specific file.  There is no
need for this in the device tree.


	-- Dan

Re: [PATCH 10/11] Add MPC8360EMDS board support

[Jerry Van Baren]

Dan Malek wrote:
> On Oct 4, 2006, at 1:52 AM, Benjamin Herrenschmidt wrote:
> 
>> I don't see how a mecanism of feature call at the board support  
>> level is
>> in any way incompatible with the device-tree thing.
> 
> It isn't.
> 
>> ...  I'm happy mixing
>> both on powermac :)
> 
> I know.  This was just an opportunity to make people
> realize that a board port does require the writing of
> some board specific code.  Using the feature call is
> an excellent model of portability and flexibility.  My
> point was that any BCSR access is necessary to be
> hidden behind such a function, because it is truly
> board specific.  You can't require the drivers to
> have this kind of logic in them, they must call out
> to board support functions for assistance.
> 
> Just like the powermac ports, embedded drivers
> will need a feature call at some points during
> their processing (set up clock routing, IO pin
> configuration, board specific bus connections,
> power management, etc).  Some board ports
> may do nothing, others may do lots of work.
> 
> Therefore, I see no reason why a BSCR address
> and all of it's associated format can't simply
> be a #define in a board specific file.  There is no
> need for this in the device tree.
> 
> 
> 	-- Dan

The promise of OF for me is that it promises to keep configuration 
information in _one place_.  My experience to date is that my u-boot has 
a bunch of semi-hardcoded constants, my linux drivers have a bunch of 
semi-hardcoded constants that likely do not match 1:1 (name and 
definitely not location) with the equivalent u-boot constants, and some 
constants are passed from u-boot to linux using the BD structure, which 
is never defined the same (for me) in u-boot and linux.

The result is that, when I upgrade my u-boot and/or linux sources, I end 
up having to re-find all the places where the constants live (and find 
some new places), fix them, and then make the u-boot and linux BD 
structures match.  Granted, this isn't insurmountable, but it is a major 
hassle and should be unnecessary.

In a perfect world perhaps we would have one (set of) #include file(s) 
that had all the configuration information necessary to build u-boot and 
linux.  In the current world, u-boot and linux are in different 
repositories with different people with different machines (and agendas) 
doing different development on them, and the result is disjoint.

I look at OF to be the /lingua franca/ of PowerPC bootloaders and linux.

gvb

Re: [PATCH 10/11] Add MPC8360EMDS board support

[Tim Bird]

Dan Malek wrote:
> I'm not against using the device tree (or platform data
> or #defines) when it's appropriate to do so.  I think our
> obsession to represent everything there is what is
> creating the complexity.  If a #define in a board
> specific port file makes sense, then just do that,
> even if it is a BSCR address.  The device tree just
> seems like the new toy that everyone wants to play
> with, and we are forgetting that the old fashioned way
> of just writing some C code may be the way
> to implement what we need.

I'd like to "second" a lot of what Dan is saying.

Linux increasingly drifts away from simple, adequate
solutions (that admittedly require a bit of embedded
developer elbow grease), towards these types of
"grand unification" schemes, which actually interfere
with goals in the embedded space.

=============================
Tim Bird
Architecture Group Chair, CE Linux Forum
Senior Staff Engineer, Sony Electronics
=============================

Re: [PATCH 10/11] Add MPC8360EMDS board support

[Benjamin Herrenschmidt]

On Wed, 2006-10-04 at 10:48 -0400, Dan Malek wrote:
> On Oct 4, 2006, at 2:08 AM, Benjamin Herrenschmidt wrote:
> 
> > It's not that complex and the single binary is not necessarily the  
> > main
> > objective (it's a good practice as it enforce avoiding ugly #ifdef  
> > hacks
> 
> Would you guys please get off of this #ifdefs discussion! :-)
> That's not what this is about.

But it _IS_ in large part ! #ifdefs are ugly and evil. So it's about
that and having a central repository for board specific informations
instead of hacks cluttered around 20 drivers....

> > There is fundamentally little difference between the OCP tables we had
> > before and the device-tree.
> 
> Exactly!  So why has it become such a desire to represent
> stuff in the device tree that was never necessary to represent
> in other table formats before?

For several reasons. One of them is the fact that the previous tables
were too limited, another is that we are converging using the same
mecanism for all platforms.
 
> > The new device-tree model provides a more flexible and richer semantic
> > for adding all sort of driver or BSP private infos, and for dealing  
> > with
> > address mapping and interrupt mapping.
> 
> Not really, we had all of this before.....  and in a way
> that I didn't have to learn a new syntax to represent.

Ugh ? Look at the #ifdef mess in ibm_emac...

> > When done right, it does simplify the matter. An example that I've  
> > seen
> > internally is embedded boards with all sorts of variety of dodgy
> > interrupt controllers cascaded on each other.
> 
> Good example.  Cascaded interrupt controllers are always
> a challenge.  :-)  It doesn't matter how you present the
> information about their configuration if you don't have
> the code written properly to manage them.  It's the
> _code_ you write the solves the problem, not the
> device tree.

The device-tree allows the code to be much simpler. The -code- becomes
what it should be in the first place: purely a driver for each actual
chip with no need for much knowledge if the general layout. Layout
related (and in general board related) informations are in the
device-tree and the board setup file(s). It's cleaner and simpler.

> It doesn't really make it any simpler for the driver, because
> they have always retrieved that information in some way that
> has been consistent, usually from the old board descriptor
> or platform data. 

No, it's never been consistent.

>  The method of converting that information,
> usually a concern of the boot rom or the boot wrapper or
> compiled in, is what we are changing now.

We are changing the method to make it consistent. Providing the
information is still a concern of the boot rom or the wrapper.
 
> > There is a great flexibility of putting whatever you want in  
> > there... or
> > not.
> 
> It's the 'or not' part that I am worried about.  Things like
> you mention above make sense.  I'm starting to worry about
> some of this other stuff, and the bscr example is what
> woke me up :-)  I think that's an example of things that
> should be considered not necessary.

I haven't looked at this specific example. I'll try to have a look
later. I jumped into the discussion pointed by somebody else :)

> > It's up to the embedded developper to use that tool, it can be used
> > in a bloated way, or in a smart way, we aren't enforcing any direction
> > here.
> 
> Not really.  To use a particular driver you are going to have
> to provide the proper amount of information.  It's not up to
> me as a consumer of something already written.  I can
> only control that if I'm the developer of the code.

Oh sure, existing drivers will require some amount of information, and
that's good. Better have it in that central place than having board
specific junk in every driver. However, you can use it to add your own
stuffs as well if you feel the need. And when I say used in a simple vs.
a bloated way, it's also up to the driver writer to not require too
much...

> > I think you are a bit too dismissive here. The approach has always  
> > been
> > to provide the choice,
> 
> There isn't a choice.  If I want to use a particular driver
> I have to provide the proper and necessary information
> using a device tree, period.  If I want to change my
> board design for some reason that is advantageous
> to me, and the driver doesn't support it, no possible
> convolution of device tree information is going to make
> that happen.

Then you fix the driver. We are not solving world hunger but we are at
least trying to improve our own food quality here.

> > ...  is hopefully an easier way to create the BSP in the first place,
> 
> Sorry, but I don't see that.  You are either skilled at
> creating a BSP or you are not.  The device tree just adds
> another dimension of information in a syntax and structure
> that you have to learn.

To re-use your own answer to one of my points, I'd say that's
bullshit :) It's easier to have a central place with well defined
bindings to express things like your interrupt routing, device layout
and addresses etc...

> > .... The -ability- to build multi-board
> > kernels is made mandatory for code to be merged upstream,
> 
> Why?  When are people going to realize that the
> ratio of Linux on custom embedded systems to a standard
> workstation is about a million to one?

And ?

>   So what if I
> can boot the same kernel on a couple of obsolete
> PowerPC workstations using drivers that aren't used
> anywhere else?  Or, on a couple of embedded eval
> boards that don't represent how people build products?
> Hell, I tried to build an x86 kernel the other day
> for a PC and still don't have one that boots.  I can't
> seem to figure out what processor configuration
> options or compiler options to use.  Linux doesn't
> even support this on a "standard" PC. :-)

That's what defconfigs are for.

> > ... as it enforces
> > a certain level of quality,
> 
> That's BS and you know it :-)

No, it's not. Look at the inextricable mess arch/ppc is in. We are
trying hard to avoid that for arch/powerpc. If you let people just do
hacks with #ifdef's all over the place for every single board, you end
up with something mostly unmaintainable. Your point would be valid if
the linux kernel was a frozen thing that didn't evolve. However, it
evolves and needs to be actively devleopped/maintained. Having a sane
infrastructure to hook board support in makes it easier and cleaner.

Also, most of the code for embedded that actually gets merged upstream
is code for evaluation boards provided by chip vendors, not end-user
embedded code, you know very well that the actual embedded developpers
never submit anything upstream, they don't care. That means that what
gets merged upstream is what will be used as example code and base for
new board supports. Thus it's important that is has as much flexibility
as possible, including the ability to build kernels with multiple board
supports in a single image. Embedded customers are the end of the chain
might chose to not use that capability, but it shall be provided by the
base/example code in the upstream repository.
 
> > ....  In fact, you client may be happy, once it's done rev 3 of the
> > board with a 3rd type of wifi chip or a 2nd type of ethernet HUB to  
> > have
> > the ability to easily build, maintain, distribute and test a single
> > kernel image,
> 
> That's not very important.  For high volume products that
> are already in the field, the way the binary image is created
> or if they need different ones on different versions, isn't
> important.  The whole process of tracking, testing, distributing,
> installing, upgrading, reverting makes our development
> tools insignificant to them.  All that is desired is an image
> that when upgraded doesn't turn a million boxes into
> bricks.  If it does, our cleverness to use a device tree to
> support multiple boards better not be the problem, because
> if it is it will never be used again.

That argument too is BS and you know it :)

Ben.

Re: [PATCH 10/11] Add MPC8360EMDS board support

[Paul Mackerras]

Benjamin Herrenschmidt writes:

> > It's the 'or not' part that I am worried about.  Things like
> > you mention above make sense.  I'm starting to worry about
> > some of this other stuff, and the bscr example is what
> > woke me up :-)  I think that's an example of things that
> > should be considered not necessary.
> 
> I haven't looked at this specific example. I'll try to have a look
> later. I jumped into the discussion pointed by somebody else :)

That one was interesting - the bcsr was being referenced from an
ethernet driver that looked to me like it would be useful on any board
based on an 836x chip (I think).  Yet it was claimed that the bcsr was
so specific and unique to each board that there was no point putting
it in the device tree - which implies that we would have to have a
separate lump of code in the tree to drive it for every single
board. :P  I asked why the ethernet driver was accessing it directly
if that was the case, but didn't get an answer (well, only an indirect
answer in that the bcsr access code got removed from the ethernet
driver).

Paul.

Re: [PATCH 10/11] Add MPC8360EMDS board support

[Benjamin Herrenschmidt]

On Thu, 2006-10-05 at 10:03 +1000, Paul Mackerras wrote:
> Benjamin Herrenschmidt writes:
> 
> > > It's the 'or not' part that I am worried about.  Things like
> > > you mention above make sense.  I'm starting to worry about
> > > some of this other stuff, and the bscr example is what
> > > woke me up :-)  I think that's an example of things that
> > > should be considered not necessary.
> > 
> > I haven't looked at this specific example. I'll try to have a look
> > later. I jumped into the discussion pointed by somebody else :)
> 
> That one was interesting - the bcsr was being referenced from an
> ethernet driver that looked to me like it would be useful on any board
> based on an 836x chip (I think).  Yet it was claimed that the bcsr was
> so specific and unique to each board that there was no point putting
> it in the device tree - which implies that we would have to have a
> separate lump of code in the tree to drive it for every single
> board. :P  I asked why the ethernet driver was accessing it directly
> if that was the case, but didn't get an answer (well, only an indirect
> answer in that the bcsr access code got removed from the ethernet
> driver).

Well, feature calls might be the answer there... at least to move the
problem out of the driver to the platform code. They are after all just
a way to do random calls into the BSP from drivers, though they have
some issues too (you gotta hope you are running the right platform code
that understands your calls, in which case, why not just call an
exported function ...)

Ben.

Re: [PATCH 10/11] Add MPC8360EMDS board support

[Vitaly Bordug]

[-- Attachment #1: Type: text/plain, Size: 2142 bytes --]

On Thu, 5 Oct 2006 10:03:34 +1000
Paul Mackerras wrote:

> Benjamin Herrenschmidt writes:
> 
> > > It's the 'or not' part that I am worried about.  Things like
> > > you mention above make sense.  I'm starting to worry about
> > > some of this other stuff, and the bscr example is what
> > > woke me up :-)  I think that's an example of things that
> > > should be considered not necessary.
> > 
> > I haven't looked at this specific example. I'll try to have a look
> > later. I jumped into the discussion pointed by somebody else :)
> 
> That one was interesting - the bcsr was being referenced from an
> ethernet driver that looked to me like it would be useful on any board
> based on an 836x chip (I think).  Yet it was claimed that the bcsr was
> so specific and unique to each board that there was no point putting
> it in the device tree - which implies that we would have to have a
> separate lump of code in the tree to drive it for every single
> board. :P  I asked why the ethernet driver was accessing it directly
> if that was the case, but didn't get an answer (well, only an indirect
> answer in that the bcsr access code got removed from the ethernet
> driver).
> 

Well that's because accessing bcsr in generic code is just odd. Yes, there are some places with 
such a stuff still. bcsr is something like a sw jumper to enable/disable stuff, configure things, etc. 
which may vary up to the hw design even if it's following the reference closely.

It's unique across the boards, and should be touched in BSP code only to keep the base sane.

Such a thing in the eth driver directly was sort of "nice" because takes care of enabling network "physically"
on board. For the same aim, I used to have board-specific callback to set up some bits if needed(speaking about
fs_enet/ppc). IOW, upon network driver init, it triggers callback function (passed in there via platform data) that's intended to do the bsp setup (or may be unset if nothing needed). In powerpc, only sane solution seems to be Dan's proposed 
feature_call thing. I wish I'd have some time for that ...

Thanks, 
-Vitaly

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [PATCH 10/11] Add MPC8360EMDS board support

[Paul Mackerras]

Dan Malek writes:

> I'm not against using the device tree (or platform data
> or #defines) when it's appropriate to do so.  I think our
> obsession to represent everything there is what is
> creating the complexity.  If a #define in a board
> specific port file makes sense, then just do that,
> even if it is a BSCR address.

So, where this discussion started was that I saw an ioremap in an
ethernet driver using a physical address defined with #define, and I
said "that should go in the device tree".  And I would still say that
if the ioremap was still there, since the driver is one that is useful
across a range of boards and chips.

My other point would be that what you say is valid *until* the
hardware engineers come to you and say "we're doing rev 2 of the
board, and we had to move the BCSR a bit.  That's OK with you, isn't
it?".

If you have the BCSR address in the device tree, you don't even need
to recompile your kernel.  You can just copy your board.dts to
board-rev2.dts, change the address in there, and rerun the wrapper
script to create the flash image to put on the new board.  Or if you
are using a bootloader that knows how to supply a device-tree blob,
you just put board-rev2.dtb into flash along with your existing kernel
image.

Paul.

Re: [PATCH 10/11] Add MPC8360EMDS board support

[Eugene Surovegin]

On Thu, Oct 05, 2006 at 09:36:59AM +1000, Benjamin Herrenschmidt wrote:
> Ugh ? Look at the #ifdef mess in ibm_emac...

Ugh?

I think you have to thank IBM/AMCC designers which keep changing bit 
layout of some registers, sometimes just changing polarity for no 
reason.

And with all due respect, Ben. Current ibm_emac despite of all "mess" 
is actually usable in production environment, which cannot be said 
about initial Armin version and second version you started but never 
got time to actually finish.

-- 
Eugene

Re: [PATCH 10/11] Add MPC8360EMDS board support

[Benjamin Herrenschmidt]

On Wed, 2006-10-04 at 23:21 -0700, Eugene Surovegin wrote:
> On Thu, Oct 05, 2006 at 09:36:59AM +1000, Benjamin Herrenschmidt wrote:
> > Ugh ? Look at the #ifdef mess in ibm_emac...
> 
> Ugh?
> 
> I think you have to thank IBM/AMCC designers which keep changing bit 
> layout of some registers, sometimes just changing polarity for no 
> reason.
> 
> And with all due respect, Ben. Current ibm_emac despite of all "mess" 
> is actually usable in production environment, which cannot be said 
> about initial Armin version and second version you started but never 
> got time to actually finish.

That second version was working fine... on the limited available
variations of EMAC back then.

Regarding the "mess", it's the whole #ifdef junk in there that is
driving me nuts and that I'll rip appart probably next week. A lot of
this could be soft-tests or the ifdefs could be resolved at Kconfig
instead of having a list of processors in 3 different headers if you
really want to compile the changes in rather than do soft-tests.

Ben.

Re: [PATCH 10/11] Add MPC8360EMDS board support

[Eugene Surovegin]

On Thu, Oct 05, 2006 at 10:27:14AM +1000, Paul Mackerras wrote:
> Dan Malek writes:
> 
> > I'm not against using the device tree (or platform data
> > or #defines) when it's appropriate to do so.  I think our
> > obsession to represent everything there is what is
> > creating the complexity.  If a #define in a board
> > specific port file makes sense, then just do that,
> > even if it is a BSCR address.
> 
> So, where this discussion started was that I saw an ioremap in an
> ethernet driver using a physical address defined with #define, and I
> said "that should go in the device tree".  And I would still say that
> if the ioremap was still there, since the driver is one that is useful
> across a range of boards and chips.
> 
> My other point would be that what you say is valid *until* the
> hardware engineers come to you and say "we're doing rev 2 of the
> board, and we had to move the BCSR a bit.  That's OK with you, isn't
> it?".
> 
> If you have the BCSR address in the device tree, you don't even need
> to recompile your kernel.  You can just copy your board.dts to
> board-rev2.dts, change the address in there, and rerun the wrapper
> script to create the flash image to put on the new board.  Or if you
> are using a bootloader that knows how to supply a device-tree blob,
> you just put board-rev2.dtb into flash along with your existing kernel
> image.

Paul,

it doesn't really matter if you have to rebuild a kernel or some 
other blob and have it re-flashed in the actual board.

Having something in device tree doesn't change a simple fact that you 
have to update some firmware component, be it boot code, kernel or 
some dts blob. You still have to prepare new flash image, period.

-- 
Eugene

Re: [PATCH 10/11] Add MPC8360EMDS board support

[Eugene Surovegin]

On Thu, Oct 05, 2006 at 04:26:34PM +1000, Benjamin Herrenschmidt wrote:
> On Wed, 2006-10-04 at 23:21 -0700, Eugene Surovegin wrote:
> > On Thu, Oct 05, 2006 at 09:36:59AM +1000, Benjamin Herrenschmidt wrote:
> > > Ugh ? Look at the #ifdef mess in ibm_emac...
> > 
> > Ugh?
> > 
> > I think you have to thank IBM/AMCC designers which keep changing bit 
> > layout of some registers, sometimes just changing polarity for no 
> > reason.
> > 
> > And with all due respect, Ben. Current ibm_emac despite of all "mess" 
> > is actually usable in production environment, which cannot be said 
> > about initial Armin version and second version you started but never 
> > got time to actually finish.
> 
> That second version was working fine... on the limited available
> variations of EMAC back then.

No it wasn't. If it were I would have never wasted my time re-writing 
this driver.

-- 
Eugene

Re: [PATCH 10/11] Add MPC8360EMDS board support

[Eugene Surovegin]

On Thu, Oct 05, 2006 at 04:26:34PM +1000, Benjamin Herrenschmidt wrote:
> 
> Regarding the "mess", it's the whole #ifdef junk in there that is
> driving me nuts and that I'll rip appart probably next week. A lot of
> this could be soft-tests or the ifdefs could be resolved at Kconfig
> instead of having a list of processors in 3 different headers if you
> really want to compile the changes in rather than do soft-tests.

Well, sent me changes for review, or become a maintainer, but this 
time _real_ maintainer, not like last time when you touched this code.

-- 
Eugene

Re: [PATCH 10/11] Add MPC8360EMDS board support

[Benjamin Herrenschmidt]

On Wed, 2006-10-04 at 23:33 -0700, Eugene Surovegin wrote:
> On Thu, Oct 05, 2006 at 04:26:34PM +1000, Benjamin Herrenschmidt wrote:
> > 
> > Regarding the "mess", it's the whole #ifdef junk in there that is
> > driving me nuts and that I'll rip appart probably next week. A lot of
> > this could be soft-tests or the ifdefs could be resolved at Kconfig
> > instead of having a list of processors in 3 different headers if you
> > really want to compile the changes in rather than do soft-tests.
> 
> Well, sent me changes for review, or become a maintainer, but this 
> time _real_ maintainer, not like last time when you touched this code.

Well, last time I touched this code, I took something that was not
working at all and made it work for me and a couple of other people that
were working on it at the same time. If it had issues, they were never
reported to me back then. However, I never intended to do long term
maintainership of this driver and that was clear from the very
beginning. If you ran into other issues and fixed them afterward, that's
fine, but don't blame me for not fixing issues I didn't encounter nor
was told about for the short time while I was taking care of it.

Anyway, my point is, the per-processor ifdef lists are just fugly and
need to be turned into "soft" changes. The driver also needs to get some
OF probing and use the new DCR accessors to move over to powerpc and to
work with the EMAC cell within the new Cell southbridge.

I have some preliminary patches doing just the OF probing and DCR
changes. I still want to do some serious change of the #ifdef mess into
something more flexible to allow for runtime choice of the type of EMAC
and MAL.

I'll post patches (and possibly incremental "cleanup") to the list,
CC'ing you, as expected for a driver you maintain.

Ben.