From 98360be0fefd58bf27df03c47d887dd676a31d73 Mon Sep 17 00:00:00 2001 From: Sascha Hauer Date: Tue, 17 Jun 2014 10:27:03 +0200 Subject: Documentation: remove doxygen documentation The doxygen documentation is long outdated. Remove it. It will be replaced with sphinx based documentation later. Signed-off-by: Sascha Hauer --- Documentation/barebox-main.dox | 126 -- Documentation/board.dox | 94 -- Documentation/boards.dox | 74 -- Documentation/building.dox | 60 - Documentation/commands.dox | 111 -- Documentation/developers_manual.dox | 24 - Documentation/first_steps.dox | 61 - Documentation/manual_org.dox | 27 - Documentation/users_manual.dox | 18 - Doxyfile | 1310 -------------------- Makefile | 10 - arch/architecture.dox | 175 --- arch/arm/boards/a9m2410/a9m2410.c | 68 - arch/arm/boards/a9m2440/a9m2440.c | 79 -- arch/arm/boards/beagle/board.c | 31 - arch/arm/boards/ccxmx51/ccxmx51.dox | 7 - arch/arm/boards/chumby_falconwing/falconwing.c | 138 --- arch/arm/boards/edb93xx/edb93xx.dox | 108 -- .../arm/boards/eukrea_cpuimx27/eukrea_cpuimx27.dox | 11 - .../arm/boards/eukrea_cpuimx35/eukrea_cpuimx35.dox | 4 - .../arm/boards/eukrea_cpuimx51/eukrea_cpuimx51.dox | 4 - arch/arm/boards/freescale-mx21-ads/imx21ads.dox | 5 - arch/arm/boards/freescale-mx23-evk/mx23-evk.c | 32 - arch/arm/boards/freescale-mx27-ads/imx27ads.dox | 5 - arch/arm/boards/freescale-mx35-3ds/3stack.dox | 4 - .../arm/boards/freescale-mx51-babbage/mx51-pdk.dox | 4 - arch/arm/boards/freescale-mx53-qsb/mx53-pdk.dox | 4 - arch/arm/boards/freescale-mx53-smd/mx53-smd.dox | 4 - arch/arm/boards/friendlyarm-mini2440/mini2440.c | 159 --- arch/arm/boards/guf-cupid/cupid.dox | 9 - arch/arm/boards/imx233-olinuxino/imx23-olinuxino.c | 59 - arch/arm/boards/karo-tx28/tx28.c | 52 - arch/arm/boards/karo-tx51/tx51.dox | 50 - arch/arm/boards/module-mb7707/module-mb7707.dox | 29 - arch/arm/boards/mx31moboard/mx31moboard.dox | 10 - arch/arm/boards/netx/netx.dox | 9 - arch/arm/boards/omap343xdsp/board.c | 26 - arch/arm/boards/phytec-phycard-imx27/pca100.dox | 8 - arch/arm/boards/phytec-phycard-omap3/pca-a-l1.dox | 16 - arch/arm/boards/phytec-phycore-imx27/pcm038.dox | 9 - arch/arm/boards/phytec-phycore-imx31/pcm037.dox | 11 - arch/arm/boards/phytec-phycore-imx35/pcm043.dox | 28 - arch/arm/boards/qil-a926x/qil-a9260.dox | 22 - arch/arm/boards/scb9328/scb9328.dox | 9 - arch/arm/boards/tny-a926x/tny-a9263.dox | 33 - arch/arm/boards/tny-a926x/tny-a9g20-lpw.dox | 37 - arch/arm/boards/toshiba-ac100/toshiba-ac100.dox | 37 - arch/arm/boards/usb-a926x/usb-a9263.dox | 30 - arch/arm/boards/usb-a926x/usb-a9g20-lpw.dox | 33 - arch/arm/boards/virt2real/virt2real.dox | 41 - arch/arm/mach-arm.dox | 67 - arch/arm/mach-davinci/mach-davinci.dox | 7 - arch/arm/mach-omap/arch-omap.dox | 96 -- arch/arm/mach-samsung/lowlevel-s3c24x0.S | 8 - arch/arm/mach-samsung/mem-s3c24x0.c | 57 - arch/blackfin/boards/ipe337/ipe337.dox | 10 - arch/blackfin/mach-bf.dox | 9 - arch/mips/boards/dlink-dir-320/dlink-dir-320.dox | 38 - arch/mips/boards/loongson-ls1b/loongson_ls1b.dox | 47 - arch/mips/boards/qemu-malta/qemu-malta.dox | 20 - arch/mips/boards/ritmix-rzx50/ritmix-rzx50.dox | 46 - arch/mips/boards/tplink-mr3020/tplink-mr3020.dox | 64 - arch/mips/mach-bcm47xx/mach-bcm47xx.dox | 7 - arch/mips/mach-loongson/mach-loongson.dox | 7 - arch/mips/mach-malta/mach-malta.dox | 7 - arch/mips/mach-mips.dox | 69 -- arch/mips/mach-xburst/mach-xburst.dox | 7 - arch/ppc/boards/pcm030/pcm030.dox | 8 - arch/ppc/mach-ppc.dox | 9 - arch/sandbox/os/common.c | 55 - arch/x86/boards/x86_generic/generic_pc.c | 34 - arch/x86/boot/bioscall.S | 4 - arch/x86/lib/bios_disk.S | 3 - arch/x86/lib/linux_start.S | 3 - arch/x86/mach-x86.dox | 128 -- commands/bootm.c | 17 - commands/cp.c | 14 - commands/devinfo.c | 28 - commands/dfu.c | 10 - commands/echo.c | 8 - commands/edit.c | 16 - commands/flash.c | 52 - commands/gpio.c | 62 - commands/led.c | 9 - commands/linux16.c | 66 - commands/loadenv.c | 9 - commands/miitool.c | 6 - commands/mount.c | 36 - commands/partition.c | 24 - commands/printenv.c | 14 - commands/saveenv.c | 18 - commands/setenv.c | 13 - commands/splash.c | 11 - commands/usbserial.c | 4 - common/kallsyms.c | 4 - include/command.h | 4 - include/driver.h | 26 - include/i2c/i2c.h | 4 - include/linux/mtd/mtd-abi.h | 4 - include/linux/mtd/mtd.h | 4 - include/spi/spi.h | 4 - include/usb/ch9.h | 4 - include/usb/composite.h | 4 - include/usb/gadget.h | 4 - include/usb/usb.h | 4 - net/netconsole.c | 28 - scripts/doxy_filter.awk | 103 -- 107 files changed, 4739 deletions(-) delete mode 100644 Documentation/barebox-main.dox delete mode 100644 Documentation/board.dox delete mode 100644 Documentation/boards.dox delete mode 100644 Documentation/building.dox delete mode 100644 Documentation/commands.dox delete mode 100644 Documentation/developers_manual.dox delete mode 100644 Documentation/first_steps.dox delete mode 100644 Documentation/manual_org.dox delete mode 100644 Documentation/users_manual.dox delete mode 100644 Doxyfile delete mode 100644 arch/architecture.dox delete mode 100644 arch/arm/boards/ccxmx51/ccxmx51.dox delete mode 100644 arch/arm/boards/edb93xx/edb93xx.dox delete mode 100644 arch/arm/boards/eukrea_cpuimx27/eukrea_cpuimx27.dox delete mode 100644 arch/arm/boards/eukrea_cpuimx35/eukrea_cpuimx35.dox delete mode 100644 arch/arm/boards/eukrea_cpuimx51/eukrea_cpuimx51.dox delete mode 100644 arch/arm/boards/freescale-mx21-ads/imx21ads.dox delete mode 100644 arch/arm/boards/freescale-mx27-ads/imx27ads.dox delete mode 100644 arch/arm/boards/freescale-mx35-3ds/3stack.dox delete mode 100644 arch/arm/boards/freescale-mx51-babbage/mx51-pdk.dox delete mode 100644 arch/arm/boards/freescale-mx53-qsb/mx53-pdk.dox delete mode 100644 arch/arm/boards/freescale-mx53-smd/mx53-smd.dox delete mode 100644 arch/arm/boards/guf-cupid/cupid.dox delete mode 100644 arch/arm/boards/karo-tx51/tx51.dox delete mode 100644 arch/arm/boards/module-mb7707/module-mb7707.dox delete mode 100644 arch/arm/boards/mx31moboard/mx31moboard.dox delete mode 100644 arch/arm/boards/netx/netx.dox delete mode 100644 arch/arm/boards/phytec-phycard-imx27/pca100.dox delete mode 100644 arch/arm/boards/phytec-phycard-omap3/pca-a-l1.dox delete mode 100644 arch/arm/boards/phytec-phycore-imx27/pcm038.dox delete mode 100644 arch/arm/boards/phytec-phycore-imx31/pcm037.dox delete mode 100644 arch/arm/boards/phytec-phycore-imx35/pcm043.dox delete mode 100644 arch/arm/boards/qil-a926x/qil-a9260.dox delete mode 100644 arch/arm/boards/scb9328/scb9328.dox delete mode 100644 arch/arm/boards/tny-a926x/tny-a9263.dox delete mode 100644 arch/arm/boards/tny-a926x/tny-a9g20-lpw.dox delete mode 100644 arch/arm/boards/toshiba-ac100/toshiba-ac100.dox delete mode 100644 arch/arm/boards/usb-a926x/usb-a9263.dox delete mode 100644 arch/arm/boards/usb-a926x/usb-a9g20-lpw.dox delete mode 100644 arch/arm/boards/virt2real/virt2real.dox delete mode 100644 arch/arm/mach-arm.dox delete mode 100644 arch/arm/mach-davinci/mach-davinci.dox delete mode 100644 arch/arm/mach-omap/arch-omap.dox delete mode 100644 arch/blackfin/boards/ipe337/ipe337.dox delete mode 100644 arch/blackfin/mach-bf.dox delete mode 100644 arch/mips/boards/dlink-dir-320/dlink-dir-320.dox delete mode 100644 arch/mips/boards/loongson-ls1b/loongson_ls1b.dox delete mode 100644 arch/mips/boards/qemu-malta/qemu-malta.dox delete mode 100644 arch/mips/boards/ritmix-rzx50/ritmix-rzx50.dox delete mode 100644 arch/mips/boards/tplink-mr3020/tplink-mr3020.dox delete mode 100644 arch/mips/mach-bcm47xx/mach-bcm47xx.dox delete mode 100644 arch/mips/mach-loongson/mach-loongson.dox delete mode 100644 arch/mips/mach-malta/mach-malta.dox delete mode 100644 arch/mips/mach-mips.dox delete mode 100644 arch/mips/mach-xburst/mach-xburst.dox delete mode 100644 arch/ppc/boards/pcm030/pcm030.dox delete mode 100644 arch/ppc/mach-ppc.dox delete mode 100644 arch/x86/mach-x86.dox delete mode 100644 scripts/doxy_filter.awk diff --git a/Documentation/barebox-main.dox b/Documentation/barebox-main.dox deleted file mode 100644 index c98c75fe6b..0000000000 --- a/Documentation/barebox-main.dox +++ /dev/null @@ -1,126 +0,0 @@ -/** @mainpage Barebox - -Barebox is a bootloader that initializes hardware and boots Linux and -maybe other operating systems or bare metal code on a variety of -processors. It was initially derived from U-Boot and retains several of -U-Boot's ideas, so users familiar with U-Boot should come into -production quickly with Barebox. - -However, as the Barebox developers are highly addicted to the Linux -kernel, its coding style and code quality, we try to stick as closely -as possible to the methodologies and techniques developed in Linux. In -addition we have a strong background in POSIX, so you'll find several -good old Unix traditions realized in Barebox as well. - -@par Highlights: - -- POSIX File API:
- @a Barebox uses the the well known open/close/read/write/lseek access - functions, together with a model of representing devices by files. This - makes the APIs familiar to everyone who has experience with Unix - systems. - -- Shell:
- We have the standard shell commands like ls/cd/mkdir/echo/cat,... - -- Environment Filesystem:
- In contrast to U-Boot, Barebox doesn't misuse the environment for - scripting. If you start the bootloader, it gives you a shell and - something that looks like a filesystem. In fact it isn't; it is a very - simple ar archive being extracted from flash into a ramdisk with 'loadenv' - and stored back with 'saveenv'. - -- Filesystem Support:
- When starting up, the environment is mounted to /, followed by a - device filesytem being mounted to /dev in order to make it possible to - access devices. Other filesystems can be mounted on demand. - -- Driver Model (borrowed from Linux):
- Barebox follows the Linux driver model: devices can be specified in a - hardware specific file, and drivers feel responsible for these devices - if they have the same name. - -- Clocksource:
- We use the standard clocksource API from Linux. - -- Kconfig/Kbuild:
- This gives us parallel builds and removes the need for lots of ifdefs. - -- Sandbox:
- If you develop features for @a Barebox, you can use the 'sandbox' - target which compiles @a Barebox as a POSIX application in the Linux - userspace: it can be started like a normal command and even has - network access (tun/tap). Files from the local filesytem can be used - to simulate devices. - -- Device Parameters:
- There is a parameter model in @a Barebox: each device can specify its - own parameters, which do exist for every instance. Parameters can be - changed on the command line with \.\="...". For - example, if you want to access the IPv4 address for eth0, this is done - with 'eth0.ip=192.168.0.7' and 'echo $eth0.ip'. - -- Getopt:
- @a Barebox has a lightweight getopt() implementation. This makes it - unnecessary to use positional parameters, which can be hard to read. - -- Integrated Editor:
- Scripts can be edited with a small integrated fullscreen editor. - This editor has no features except the ones really needed: moving - the cursor around, typing characters, exiting and saving. - - -@par Directory layout - -Most of the directory layout is based upon the Linux Kernel: - -@verbatim -arch / * / -> contains architecture specific parts -arch / * / mach-* / -> SoC specific code - -drivers / serial -> drivers -drivers / net -drivers / ... - -include / asm-* -> architecture specific includes -include / asm-* / arch-* -> SoC specific includes - -fs / -> filesystem support and filesystem drivers - -lib / -> generic library functions (getopt, readline and the - like) - -common / -> common stuff - -commands / -> many things previously in common/cmd_*, one command - per file - -net / -> Networking stuff - -scripts / -> Kconfig system - -Documentation / -> Parts of the documentation, also doxygen -@endverbatim - -@section license barebox's License - -@verbatim -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. - -This program is distributed in the hope that it will be useful, -but WITHOUT ANY WARRANTY; without even the implied warranty of -MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the -GNU General Public License for more details. - -@endverbatim - -@subpage users_manual - -@subpage developers_manual - -@subpage supported_boards - -*/ diff --git a/Documentation/board.dox b/Documentation/board.dox deleted file mode 100644 index e545709358..0000000000 --- a/Documentation/board.dox +++ /dev/null @@ -1,94 +0,0 @@ -/** @page dev_board Adapting a new Board - -To add a new board to @a barebox a few steps must be done, to extend and modify -the @a barebox source tree. - -@section board_add_files Files/Directories to be added - - - arch/\/boards/\ - - arch/\/boards/\/Makefile - - arch/\/boards/\/\.c - - arch/\/boards/\/\.dox - - include/configs/\.h - - arch/\/configs/\_defconfig - -@subsection board_makefile arch/\/boards/\Makefile - -@verbatim - obj-y += all files that builds the BSP (Assembler and/or C files) -@endverbatim - -@subsection board_basefile arch/\/boards/\\.c - -TBD - -@subsection board_doxygen arch/\/boards/\/\.dox - -This file should describe in short words your new board, what CPU -it uses, what resources are provided and features it supports. - -Use the doxygen style for this kind of documentation. Below you find a -template for this kind of file: - -@verbatim -/** @page - -This board uses an based CPU. The board is shipped with: - -- many MiB NOR type Flash Memory -- many MiB SDRAM -- a very special network controller - -and so on. - -*/ -@endverbatim - -To make your new shiny file visible in the automatically generated -documentation you must sort in the used page lable ("" in the -template above) into Documentation/boards.dox as: - -@verbatim - ... - @subpage - ... -@endverbatim - -at the right architecture. - -@note Consider to use an unique page lable. - -@subsection board_lscript arch/\/boards/\/barebox.lds.S - -If your board needs a special binary @a barebox layout, you can provide a local -board linker script file. This will replace the generic one provided by your -architecture or CPU support. - -Add this file with - -@verbatim - extra-y += -@endverbatim - -in your local \b Makefile to the list of files, forwarded to the last linking step. - -@section board_defconfig arch/\/configs/\_defconfig - -TBD - -@section board_mod_files These files needs to be modified: - - - modify Documentation/board.dox - - modify arch/\/Kconfig - - add your board (MACH_*) to the list - - add your default text base address for this architecture (ARCH_TEXT_BASE) - - modify arch/\/Makefile: - - add board-$(MACH_*) = \ - -First, the new board should be visible in the menu. - -@section board_specific_cpu Porting hints for specific CPUs - -@li @subpage dev_s3c24xx_mach - -*/ diff --git a/Documentation/boards.dox b/Documentation/boards.dox deleted file mode 100644 index 8d4fabbdd3..0000000000 --- a/Documentation/boards.dox +++ /dev/null @@ -1,74 +0,0 @@ -/** @page supported_boards Supported Boards - -This is a list of boards that are currently supported by @a barebox. - -PowerPC type: - -@li @subpage pcm030 - -ARM type: - - -@li @subpage pcm037 -@li @subpage pcm038 -@li @subpage pcm043 -@li @subpage imx21ads -@li @subpage imx27ads -@li @subpage tx28 -@li @subpage the3stack -@li @subpage mx23_evk -@li @subpage board_babage -@li @subpage board_loco -@li @subpage chumbyone -@li @subpage scb9328 -@li @subpage netx -@li @subpage dev_omap_arch -@li @subpage a9m2440 -@li @subpage a9m2410 -@li @subpage eukrea_cpuimx27 -@li @subpage eukrea_cpuimx35 -@li @subpage edb9301 -@li @subpage edb9302 -@li @subpage edb9302a -@li @subpage edb9307 -@li @subpage edb9307a -@li @subpage edb9312 -@li @subpage edb9315 -@li @subpage edb9315a -@li @subpage board_cupid -@li @subpage phycard-a-l1 -@li @subpage toshiba-ac100 -@li @subpage qil-a9260 -@li @subpage tny-a9g20-lpw -@li @subpage tny-a9263 -@li @subpage usb-a9g20-lpw -@li @subpage usb-a9263 -@li @subpage virt2real - -Blackfin type: - -@li @subpage ipe337 - -x86 type: - -@li @subpage generic_pc - - -MIPS type: - -@li @subpage dlink_dir_320 -@li @subpage loongson_ls1b -@li @subpage qemu_malta -@li @subpage ritmix-rzx50 -@li @subpage tplink-mr3020 - -*/ - -/* TODO - * - * Add documentation to your boardfile, forward it with doxygen's page - * feature (@page ) and include it here with: - * - * @subpage - * - */ diff --git a/Documentation/building.dox b/Documentation/building.dox deleted file mode 100644 index 527ca45d05..0000000000 --- a/Documentation/building.dox +++ /dev/null @@ -1,60 +0,0 @@ -/** @page building Building - -This section describes how to build the Barebox bootloader. - -@a Barebox uses Kconfig/Kbuild from the Linux kernel to build it's -sources. It consists of two parts: the makefile infrastructure (kbuild) -and a configuration system (kconfig). So building @a barebox is very -similar to building the Linux kernel. - -In the examples below we use the "sandbox" configuration, which is a -port of @a Barebox to the Linux userspace. This makes it possible to -test the code without having real hardware or even qemu. Note that the -sandbox architecture does only work well on x86 and has some issues on -x86_64. - -\todo Find out about issues on x86_64. - -Selecting the architecture and the corresponding cross compiler is done -by setting the following environment variables: - -- ARCH=\ -- CROSS_COMPILE=\ - -For @p ARCH=sandbox we do not need a cross compiler, so it is sufficient -to specify the architecture: - -@code -# export ARCH=sandbox -@endcode - -In order to configure the various aspects of @a barebox, start the -@a barebox configuration system: - -@code -# make menuconfig -@endcode - -This command starts a menu box and lets you select all the different -options available for the selected architecture. Once the configuration -is finished (you can simulate this by using the default config file with -'make sandbox_defconfig'), there is a .config file in the toplevel -directory of the sourcecode. - -After @a barebox is configured, we can start the compilation: - -@code -# make -@endcode - -You can use '-j \' in order to do a parallel build if you have more -than one cpus. - -If everything goes well, the result is a file called @p barebox: - -@code -# ls -l barebox --rwxr-xr-x 1 rsc ptx 114073 Jun 26 22:34 barebox -@endcode - -*/ diff --git a/Documentation/commands.dox b/Documentation/commands.dox deleted file mode 100644 index d8cfa6b8f0..0000000000 --- a/Documentation/commands.dox +++ /dev/null @@ -1,111 +0,0 @@ -/** - * @page command_reference Shell Commands - -This section describes the commands which are available on the @a -Barebox shell. - -@a Barebox, as a bootloader, usually shall start the Linux kernel right -away. However, there are several use cases around which make it -necessary to have some (customizable) logic and interactive scripting -possibilities. In order to achieve this, @a Barebox offers several -commands on it's integrated commandline shell. - -The following alphabetically sorted list documents all commands -available in @a Barebox: - -\todo Sort this by functionality? - -@li @subpage _name -@li @subpage addpart_command -@li @subpage alternate -@li @subpage bootm_command -@li @subpage bootu -@li @subpage bootz -@li @subpage cat_command -@li @subpage cd_command -@li @subpage clear_command -@li @subpage clko -@li @subpage cp_command -@li @subpage cpufreq -@li @subpage cpuinfo -@li @subpage crc_command -@li @subpage crc32 -@li @subpage delpart_command -@li @subpage devinfo_command -@li @subpage dfu_command -@li @subpage dhcp -@li @subpage dump_clocks -@li @subpage echo_command -@li @subpage edit_command -@li @subpage erase_command -@li @subpage ethact -@li @subpage exec -@li @subpage exit -@li @subpage export_command -@li @subpage false -@li @subpage getopt -@li @subpage gpio_get_value_command -@li @subpage gpio_set_value_command -@li @subpage gpio_direction_input_command -@li @subpage gpio_direction_output_command -@li @subpage go -@li @subpage help -@li @subpage host -@li @subpage i2c_probe -@li @subpage i2c_read -@li @subpage i2c_write -@li @subpage icache -@li @subpage iminfo -@li @subpage insmod -@li @subpage linux16_command -@li @subpage loadenv_command -@li @subpage loadb -@li @subpage loady -@li @subpage loadxc -@li @subpage login -@li @subpage ls_command -@li @subpage lsmod -@li @subpage md -@li @subpage memcmp -@li @subpage meminfo -@li @subpage memset -@li @subpage menu -@li @subpage mkdir -@li @subpage mount_command -@li @subpage mtest -@li @subpage mw -@li @subpage mycdev -@li @subpage nand -@li @subpage nand_boot_test -@li @subpage nfs -@li @subpage passwd -@li @subpage ping -@li @subpage printenv_command -@li @subpage protect_command -@li @subpage pwd -@li @subpage readline -@li @subpage reset -@li @subpage rarpboot -@li @subpage reginfo -@li @subpage rm -@li @subpage rmdir -@li @subpage saveenv_command -@li @subpage setenv_command -@li @subpage sh -@li @subpage sleep -@li @subpage source -@li @subpage splash_command -@li @subpage test -@li @subpage timeout -@li @subpage true -@li @subpage tftp_command -@li @subpage ubiattach -@li @subpage ubimkvol -@li @subpage ubirmvol -@li @subpage umount -@li @subpage unlzo -@li @subpage unprotect_command -@li @subpage usb -@li @subpage version - -*/ diff --git a/Documentation/developers_manual.dox b/Documentation/developers_manual.dox deleted file mode 100644 index 2f7d3605ef..0000000000 --- a/Documentation/developers_manual.dox +++ /dev/null @@ -1,24 +0,0 @@ -/** @page developers_manual Developer's Manual - -This part of the documentation is intended for developers of @a barebox. - -@section devel_backgrounds Some background knowledge for some frameworks barebox - -@li @subpage driver_model -@li @subpage dev_params - -@section devel_hints Hints and tips for simply adapting barebox - -@li @subpage dev_architecture -@li @subpage dev_cpu -@li @subpage dev_board - -@section devel_themes Various themes about barebox - -@li @subpage how_mount_works -@li @subpage boot_preparation -@li @subpage barebox_simul -@li @subpage io_access_functions -@li @subpage mcfv4e_MCDlib - -*/ diff --git a/Documentation/first_steps.dox b/Documentation/first_steps.dox deleted file mode 100644 index 17fdf3748c..0000000000 --- a/Documentation/first_steps.dox +++ /dev/null @@ -1,61 +0,0 @@ -/** @page first_steps First Steps - -This section demonstrates the first steps with the 'sandbox' -platform. - -@a barebox usually needs an environment for storing its configuration. -You can generate an environment using the example environment contained -in arch/sandbox/board/env: - -@code -# ./scripts/bareboxenv -s -p 0x10000 arch/sandbox/board/env/ env.bin -@endcode - -To get some files to play with you can generate a cramfs image: - -@code -# mkcramfs somedir/ cramfs.bin -@endcode - -The @a barebox image is a normal Linux executable, so it can be started -just like every other program: - -@code -# ./barebox -e env.bin -i cramfs.bin - -barebox 2010.10.0 (Oct 29 2010 - 13:47:17) - -loading environment from /dev/env0 -barebox\> / -@endcode - -Specifying -[ie] \ tells @a barebox to map the file as a device -under @p /dev. Files given with '-e' will appear as @p /dev/env[n]. Files -given with '-i' will appear as @p /dev/fd[n]. - -If @a barebox finds a valid configuration sector on @p /dev/env0, it -will be loaded into @p /env and executes @p /env/init if existing. -The default environment from the example above will show up a menu -asking for the relevant settings. - -If you have started @a barebox as root you will find a new tap device on -your host which you can configure using ifconfig. Once configured with -valid network addresses, barebox can be used to ping the host machine or -to fetch files with tftp. - -\todo Add more about tun/tap configuration - -If you have mapped a cramfs image, try mounting it with - -@code -# mkdir /cram -# mount /dev/fd0 cramfs /cram -@endcode - -Memory can be examined using @p md/mw commands. They both understand the --f \ option to tell the commands that they should work on the -specified files instead of @p /dev/mem (which holds the complete address -space). Note that if you call 'md /dev/fd0' (without -f), @a barebox will -segfault on the host, because it will interpret @p /dev/fd0 as a number. - -*/ diff --git a/Documentation/manual_org.dox b/Documentation/manual_org.dox deleted file mode 100644 index 17238f0847..0000000000 --- a/Documentation/manual_org.dox +++ /dev/null @@ -1,27 +0,0 @@ -/** @page manual_org Organisation of this Manual - -There is no fixed organisation in this manual, as various source files forwards -their content into different parts. So there are more visible menu entries, -than listed here. But these files are the main control files: - - - Documentation - - Documentation/Doxyfile - - Documentation/barebox-main.dox - - Documentation/users_manual.dox - - Documentation/commands.dox - - Documentation/developers_manual.dox - - Documentation/board.dox - - arch/architecture.dox - - arch/arm/mach-arm.dox - - arch/blackfin/mach-bf.dox - - arch/ppc/mach-ppc.dox - - Documentation/parameters.dox - - Documentation/boards.dox - - various documentation files from the board directory - -New commands should forward their content to Documentation/commands.dox, so -their pages should be listed in this file. - -New boards should forward their content to Documentation/boards.dox, so -their pages should be listed in this file. -*/ diff --git a/Documentation/users_manual.dox b/Documentation/users_manual.dox deleted file mode 100644 index ea47b18724..0000000000 --- a/Documentation/users_manual.dox +++ /dev/null @@ -1,18 +0,0 @@ -/** @page users_manual User's Manual - -This manual provides help for working with @a Barebox from the user's -point of view. So if you want to use @a Barebox for booting your target, -you find a lot of nice tricks on these pages to make your life easier. - -@li @subpage building -@li @subpage first_steps -@li @subpage command_reference -@li @subpage gpio_for_users - -\todo Rework the following sections -@li @subpage shell_notes -@li @subpage readline_parser -@li @subpage x86_bootloader -@li @subpage net_netconsole - -*/ diff --git a/Doxyfile b/Doxyfile deleted file mode 100644 index 89151e38e2..0000000000 --- a/Doxyfile +++ /dev/null @@ -1,1310 +0,0 @@ -# Doxyfile 1.5.3 - -# This file describes the settings to be used by the documentation system -# doxygen (www.doxygen.org) for a project -# -# All text after a hash (#) is considered a comment and will be ignored -# The format is: -# TAG = value [value, ...] -# For lists items can also be appended using: -# TAG += value [value, ...] -# Values that contain spaces should be placed between quotes (" ") - -#--------------------------------------------------------------------------- -# Project related configuration options -#--------------------------------------------------------------------------- - -# This tag specifies the encoding used for all characters in the config file that -# follow. The default is UTF-8 which is also the encoding used for all text before -# the first occurrence of this tag. Doxygen uses libiconv (or the iconv built into -# libc) for the transcoding. See http://www.gnu.org/software/libiconv for the list of -# possible encodings. - -DOXYFILE_ENCODING = UTF-8 - -# The PROJECT_NAME tag is a single word (or a sequence of words surrounded -# by quotes) that should identify the project. - -PROJECT_NAME = barebox - -# The PROJECT_NUMBER tag can be used to enter a project or revision number. -# This could be handy for archiving the generated documentation or -# if some version control system is used. - -@INCLUDE = Doxyfile.version - -# The OUTPUT_DIRECTORY tag is used to specify the (relative or absolute) -# base path where the generated documentation will be put. -# If a relative path is entered, it will be relative to the location -# where doxygen was started. If left blank the current directory will be used. - -OUTPUT_DIRECTORY = Documentation - -# If the CREATE_SUBDIRS tag is set to YES, then doxygen will create -# 4096 sub-directories (in 2 levels) under the output directory of each output -# format and will distribute the generated files over these directories. -# Enabling this option can be useful when feeding doxygen a huge amount of -# source files, where putting all generated files in the same directory would -# otherwise cause performance problems for the file system. - -CREATE_SUBDIRS = NO - -# The OUTPUT_LANGUAGE tag is used to specify the language in which all -# documentation generated by doxygen is written. Doxygen will use this -# information to generate all constant output in the proper language. -# The default language is English, other supported languages are: -# Afrikaans, Arabic, Brazilian, Catalan, Chinese, Chinese-Traditional, -# Croatian, Czech, Danish, Dutch, Finnish, French, German, Greek, Hungarian, -# Italian, Japanese, Japanese-en (Japanese with English messages), Korean, -# Korean-en, Lithuanian, Norwegian, Polish, Portuguese, Romanian, Russian, -# Serbian, Slovak, Slovene, Spanish, Swedish, and Ukrainian. - -OUTPUT_LANGUAGE = English - -# If the BRIEF_MEMBER_DESC tag is set to YES (the default) Doxygen will -# include brief member descriptions after the members that are listed in -# the file and class documentation (similar to JavaDoc). -# Set to NO to disable this. - -BRIEF_MEMBER_DESC = NO - -# If the REPEAT_BRIEF tag is set to YES (the default) Doxygen will prepend -# the brief description of a member or function before the detailed description. -# Note: if both HIDE_UNDOC_MEMBERS and BRIEF_MEMBER_DESC are set to NO, the -# brief descriptions will be completely suppressed. - -REPEAT_BRIEF = NO - -# This tag implements a quasi-intelligent brief description abbreviator -# that is used to form the text in various listings. Each string -# in this list, if found as the leading text of the brief description, will be -# stripped from the text and the result after processing the whole list, is -# used as the annotated text. Otherwise, the brief description is used as-is. -# If left blank, the following values are used ("$name" is automatically -# replaced with the name of the entity): "The $name class" "The $name widget" -# "The $name file" "is" "provides" "specifies" "contains" -# "represents" "a" "an" "the" - -ABBREVIATE_BRIEF = - -# If the ALWAYS_DETAILED_SEC and REPEAT_BRIEF tags are both set to YES then -# Doxygen will generate a detailed section even if there is only a brief -# description. - -ALWAYS_DETAILED_SEC = NO - -# If the INLINE_INHERITED_MEMB tag is set to YES, doxygen will show all -# inherited members of a class in the documentation of that class as if those -# members were ordinary class members. Constructors, destructors and assignment -# operators of the base classes will not be shown. - -INLINE_INHERITED_MEMB = NO - -# If the FULL_PATH_NAMES tag is set to YES then Doxygen will prepend the full -# path before files name in the file list and in the header files. If set -# to NO the shortest path that makes the file name unique will be used. - -FULL_PATH_NAMES = YES - -# If the FULL_PATH_NAMES tag is set to YES then the STRIP_FROM_PATH tag -# can be used to strip a user-defined part of the path. Stripping is -# only done if one of the specified strings matches the left-hand part of -# the path. The tag can be used to show relative paths in the file list. -# If left blank the directory from which doxygen is run is used as the -# path to strip. - -STRIP_FROM_PATH = - -# The STRIP_FROM_INC_PATH tag can be used to strip a user-defined part of -# the path mentioned in the documentation of a class, which tells -# the reader which header file to include in order to use a class. -# If left blank only the name of the header file containing the class -# definition is used. Otherwise one should specify the include paths that -# are normally passed to the compiler using the -I flag. - -STRIP_FROM_INC_PATH = - -# If the SHORT_NAMES tag is set to YES, doxygen will generate much shorter -# (but less readable) file names. This can be useful is your file systems -# doesn't support long names like on DOS, Mac, or CD-ROM. - -SHORT_NAMES = NO - -# If the JAVADOC_AUTOBRIEF tag is set to YES then Doxygen -# will interpret the first line (until the first dot) of a JavaDoc-style -# comment as the brief description. If set to NO, the JavaDoc -# comments will behave just like regular Qt-style comments -# (thus requiring an explicit @brief command for a brief description.) - -JAVADOC_AUTOBRIEF = YES - -# If the QT_AUTOBRIEF tag is set to YES then Doxygen will -# interpret the first line (until the first dot) of a Qt-style -# comment as the brief description. If set to NO, the comments -# will behave just like regular Qt-style comments (thus requiring -# an explicit \brief command for a brief description.) - -QT_AUTOBRIEF = YES - -# The MULTILINE_CPP_IS_BRIEF tag can be set to YES to make Doxygen -# treat a multi-line C++ special comment block (i.e. a block of //! or /// -# comments) as a brief description. This used to be the default behaviour. -# The new default is to treat a multi-line C++ comment block as a detailed -# description. Set this tag to YES if you prefer the old behaviour instead. - -MULTILINE_CPP_IS_BRIEF = NO - -# If the DETAILS_AT_TOP tag is set to YES then Doxygen -# will output the detailed description near the top, like JavaDoc. -# If set to NO, the detailed description appears after the member -# documentation. - -DETAILS_AT_TOP = YES - -# If the INHERIT_DOCS tag is set to YES (the default) then an undocumented -# member inherits the documentation from any documented member that it -# re-implements. - -INHERIT_DOCS = NO - -# If the SEPARATE_MEMBER_PAGES tag is set to YES, then doxygen will produce -# a new page for each member. If set to NO, the documentation of a member will -# be part of the file/class/namespace that contains it. - -SEPARATE_MEMBER_PAGES = NO - -# The TAB_SIZE tag can be used to set the number of spaces in a tab. -# Doxygen uses this value to replace tabs by spaces in code fragments. - -TAB_SIZE = 8 - -# This tag can be used to specify a number of aliases that acts -# as commands in the documentation. An alias has the form "name=value". -# For example adding "sideeffect=\par Side Effects:\n" will allow you to -# put the command \sideeffect (or @sideeffect) in the documentation, which -# will result in a user-defined paragraph with heading "Side Effects:". -# You can put \n's in the value part of an alias to insert newlines. - -ALIASES = - -# Set the OPTIMIZE_OUTPUT_FOR_C tag to YES if your project consists of C -# sources only. Doxygen will then generate output that is more tailored for C. -# For instance, some of the names that are used will be different. The list -# of all members will be omitted, etc. - -OPTIMIZE_OUTPUT_FOR_C = YES - -# Set the OPTIMIZE_OUTPUT_JAVA tag to YES if your project consists of Java -# sources only. Doxygen will then generate output that is more tailored for Java. -# For instance, namespaces will be presented as packages, qualified scopes -# will look different, etc. - -OPTIMIZE_OUTPUT_JAVA = NO - -# If you use STL classes (i.e. std::string, std::vector, etc.) but do not want to -# include (a tag file for) the STL sources as input, then you should -# set this tag to YES in order to let doxygen match functions declarations and -# definitions whose arguments contain STL classes (e.g. func(std::string); v.s. -# func(std::string) {}). This also make the inheritance and collaboration -# diagrams that involve STL classes more complete and accurate. - -BUILTIN_STL_SUPPORT = NO - -# If you use Microsoft's C++/CLI language, you should set this option to YES to -# enable parsing support. - -CPP_CLI_SUPPORT = NO - -# If member grouping is used in the documentation and the DISTRIBUTE_GROUP_DOC -# tag is set to YES, then doxygen will reuse the documentation of the first -# member in the group (if any) for the other members of the group. By default -# all members of a group must be documented explicitly. - -DISTRIBUTE_GROUP_DOC = NO - -# Set the SUBGROUPING tag to YES (the default) to allow class member groups of -# the same type (for instance a group of public functions) to be put as a -# subgroup of that type (e.g. under the Public Functions section). Set it to -# NO to prevent subgrouping. Alternatively, this can be done per class using -# the \nosubgrouping command. - -SUBGROUPING = YES - -#--------------------------------------------------------------------------- -# Build related configuration options -#--------------------------------------------------------------------------- - -# If the EXTRACT_ALL tag is set to YES doxygen will assume all entities in -# documentation are documented, even if no documentation was available. -# Private class members and static file members will be hidden unless -# the EXTRACT_PRIVATE and EXTRACT_STATIC tags are set to YES - -EXTRACT_ALL = NO - -# If the EXTRACT_PRIVATE tag is set to YES all private members of a class -# will be included in the documentation. - -EXTRACT_PRIVATE = NO - -# If the EXTRACT_STATIC tag is set to YES all static members of a file -# will be included in the documentation. - -EXTRACT_STATIC = NO - -# If the EXTRACT_LOCAL_CLASSES tag is set to YES classes (and structs) -# defined locally in source files will be included in the documentation. -# If set to NO only classes defined in header files are included. - -EXTRACT_LOCAL_CLASSES = NO - -# This flag is only useful for Objective-C code. When set to YES local -# methods, which are defined in the implementation section but not in -# the interface are included in the documentation. -# If set to NO (the default) only methods in the interface are included. - -EXTRACT_LOCAL_METHODS = NO - -# If this flag is set to YES, the members of anonymous namespaces will be extracted -# and appear in the documentation as a namespace called 'anonymous_namespace{file}', -# where file will be replaced with the base name of the file that contains the anonymous -# namespace. By default anonymous namespace are hidden. - -EXTRACT_ANON_NSPACES = NO - -# If the HIDE_UNDOC_MEMBERS tag is set to YES, Doxygen will hide all -# undocumented members of documented classes, files or namespaces. -# If set to NO (the default) these members will be included in the -# various overviews, but no documentation section is generated. -# This option has no effect if EXTRACT_ALL is enabled. - -HIDE_UNDOC_MEMBERS = YES - -# If the HIDE_UNDOC_CLASSES tag is set to YES, Doxygen will hide all -# undocumented classes that are normally visible in the class hierarchy. -# If set to NO (the default) these classes will be included in the various -# overviews. This option has no effect if EXTRACT_ALL is enabled. - -HIDE_UNDOC_CLASSES = YES - -# If the HIDE_FRIEND_COMPOUNDS tag is set to YES, Doxygen will hide all -# friend (class|struct|union) declarations. -# If set to NO (the default) these declarations will be included in the -# documentation. - -HIDE_FRIEND_COMPOUNDS = YES - -# If the HIDE_IN_BODY_DOCS tag is set to YES, Doxygen will hide any -# documentation blocks found inside the body of a function. -# If set to NO (the default) these blocks will be appended to the -# function's detailed documentation block. - -HIDE_IN_BODY_DOCS = YES - -# The INTERNAL_DOCS tag determines if documentation -# that is typed after a \internal command is included. If the tag is set -# to NO (the default) then the documentation will be excluded. -# Set it to YES to include the internal documentation. - -INTERNAL_DOCS = NO - -# If the CASE_SENSE_NAMES tag is set to NO then Doxygen will only generate -# file names in lower-case letters. If set to YES upper-case letters are also -# allowed. This is useful if you have classes or files whose names only differ -# in case and if your file system supports case sensitive file names. Windows -# and Mac users are advised to set this option to NO. - -CASE_SENSE_NAMES = YES - -# If the HIDE_SCOPE_NAMES tag is set to NO (the default) then Doxygen -# will show members with their full class and namespace scopes in the -# documentation. If set to YES the scope will be hidden. - -HIDE_SCOPE_NAMES = YES - -# If the SHOW_INCLUDE_FILES tag is set to YES (the default) then Doxygen -# will put a list of the files that are included by a file in the documentation -# of that file. - -SHOW_INCLUDE_FILES = NO - -# If the INLINE_INFO tag is set to YES (the default) then a tag [inline] -# is inserted in the documentation for inline members. - -INLINE_INFO = YES - -# If the SORT_MEMBER_DOCS tag is set to YES (the default) then doxygen -# will sort the (detailed) documentation of file and class members -# alphabetically by member name. If set to NO the members will appear in -# declaration order. - -SORT_MEMBER_DOCS = YES - -# If the SORT_BRIEF_DOCS tag is set to YES then doxygen will sort the -# brief documentation of file, namespace and class members alphabetically -# by member name. If set to NO (the default) the members will appear in -# declaration order. - -SORT_BRIEF_DOCS = NO - -# If the SORT_BY_SCOPE_NAME tag is set to YES, the class list will be -# sorted by fully-qualified names, including namespaces. If set to -# NO (the default), the class list will be sorted only by class name, -# not including the namespace part. -# Note: This option is not very useful if HIDE_SCOPE_NAMES is set to YES. -# Note: This option applies only to the class list, not to the -# alphabetical list. - -SORT_BY_SCOPE_NAME = NO - -# The GENERATE_TODOLIST tag can be used to enable (YES) or -# disable (NO) the todo list. This list is created by putting \todo -# commands in the documentation. - -GENERATE_TODOLIST = YES - -# The GENERATE_TESTLIST tag can be used to enable (YES) or -# disable (NO) the test list. This list is created by putting \test -# commands in the documentation. - -GENERATE_TESTLIST = YES - -# The GENERATE_BUGLIST tag can be used to enable (YES) or -# disable (NO) the bug list. This list is created by putting \bug -# commands in the documentation. - -GENERATE_BUGLIST = YES - -# The GENERATE_DEPRECATEDLIST tag can be used to enable (YES) or -# disable (NO) the deprecated list. This list is created by putting -# \deprecated commands in the documentation. - -GENERATE_DEPRECATEDLIST= YES - -# The ENABLED_SECTIONS tag can be used to enable conditional -# documentation sections, marked by \if sectionname ... \endif. - -ENABLED_SECTIONS = - -# The MAX_INITIALIZER_LINES tag determines the maximum number of lines -# the initial value of a variable or define consists of for it to appear in -# the documentation. If the initializer consists of more lines than specified -# here it will be hidden. Use a value of 0 to hide initializers completely. -# The appearance of the initializer of individual variables and defines in the -# documentation can be controlled using \showinitializer or \hideinitializer -# command in the documentation regardless of this setting. - -MAX_INITIALIZER_LINES = 30 - -# Set the SHOW_USED_FILES tag to NO to disable the list of files generated -# at the bottom of the documentation of classes and structs. If set to YES the -# list will mention the files that were used to generate the documentation. - -SHOW_USED_FILES = NO - -# If the sources in your project are distributed over multiple directories -# then setting the SHOW_DIRECTORIES tag to YES will show the directory hierarchy -# in the documentation. The default is NO. - -SHOW_DIRECTORIES = NO - -# The FILE_VERSION_FILTER tag can be used to specify a program or script that -# doxygen should invoke to get the current version for each file (typically from the -# version control system). Doxygen will invoke the program by executing (via -# popen()) the command , where is the value of -# the FILE_VERSION_FILTER tag, and is the name of an input file -# provided by doxygen. Whatever the program writes to standard output -# is used as the file version. See the manual for examples. - -FILE_VERSION_FILTER = - -#--------------------------------------------------------------------------- -# configuration options related to warning and progress messages -#--------------------------------------------------------------------------- - -# The QUIET tag can be used to turn on/off the messages that are generated -# by doxygen. Possible values are YES and NO. If left blank NO is used. - -QUIET = YES - -# The WARNINGS tag can be used to turn on/off the warning messages that are -# generated by doxygen. Possible values are YES and NO. If left blank -# NO is used. - -WARNINGS = YES - -# If WARN_IF_UNDOCUMENTED is set to YES, then doxygen will generate warnings -# for undocumented members. If EXTRACT_ALL is set to YES then this flag will -# automatically be disabled. - -WARN_IF_UNDOCUMENTED = NO - -# If WARN_IF_DOC_ERROR is set to YES, doxygen will generate warnings for -# potential errors in the documentation, such as not documenting some -# parameters in a documented function, or documenting parameters that -# don't exist or using markup commands wrongly. - -WARN_IF_DOC_ERROR = YES - -# This WARN_NO_PARAMDOC option can be abled to get warnings for -# functions that are documented, but have no documentation for their parameters -# or return value. If set to NO (the default) doxygen will only warn about -# wrong or incomplete parameter documentation, but not about the absence of -# documentation. - -WARN_NO_PARAMDOC = NO - -# The WARN_FORMAT tag determines the format of the warning messages that -# doxygen can produce. The string should contain the $file, $line, and $text -# tags, which will be replaced by the file and line number from which the -# warning originated and the warning text. Optionally the format may contain -# $version, which will be replaced by the version of the file (if it could -# be obtained via FILE_VERSION_FILTER) - -WARN_FORMAT = "$file:$line: $text " - -# The WARN_LOGFILE tag can be used to specify a file to which warning -# and error messages should be written. If left blank the output is written -# to stderr. - -WARN_LOGFILE = - -#--------------------------------------------------------------------------- -# configuration options related to the input files -#--------------------------------------------------------------------------- - -# The INPUT tag can be used to specify the files and/or directories that contain -# documented source files. You may enter file names like "myfile.cpp" or -# directories like "/usr/src/myproject". Separate the files or directories -# with spaces. - -INPUT = Documentation \ - include \ - arch \ - drivers \ - commands \ - common \ - lib \ - scripts/setupmbr \ - net - -# This tag can be used to specify the character encoding of the source files that -# doxygen parses. Internally doxygen uses the UTF-8 encoding, which is also the default -# input encoding. Doxygen uses libiconv (or the iconv built into libc) for the transcoding. -# See http://www.gnu.org/software/libiconv for the list of possible encodings. - -INPUT_ENCODING = UTF-8 - -# If the value of the INPUT tag contains directories, you can use the -# FILE_PATTERNS tag to specify one or more wildcard pattern (like *.cpp -# and *.h) to filter out the source-files in the directories. If left -# blank the following patterns are tested: -# *.c *.cc *.cxx *.cpp *.c++ *.java *.ii *.ixx *.ipp *.i++ *.inl *.h *.hh *.hxx -# *.hpp *.h++ *.idl *.odl *.cs *.php *.php3 *.inc *.m *.mm *.py - -FILE_PATTERNS = *.c \ - *.h \ - *.S \ - *.dox - -# The RECURSIVE tag can be used to turn specify whether or not subdirectories -# should be searched for input files as well. Possible values are YES and NO. -# If left blank NO is used. - -RECURSIVE = YES - -# The EXCLUDE tag can be used to specify files and/or directories that should -# excluded from the INPUT source files. This way you can easily exclude a -# subdirectory from a directory tree whose root is specified with the INPUT tag. - -EXCLUDE = drivers/mtd/ubi \ - include/mtd \ - include/linux/mtd - -# The EXCLUDE_SYMLINKS tag can be used select whether or not files or -# directories that are symbolic links (a Unix filesystem feature) are excluded -# from the input. - -EXCLUDE_SYMLINKS = YES - -# If the value of the INPUT tag contains directories, you can use the -# EXCLUDE_PATTERNS tag to specify one or more wildcard patterns to exclude -# certain files from those directories. Note that the wildcards are matched -# against the file with absolute path, so to exclude all test directories -# for example use the pattern */test/* - -EXCLUDE_PATTERNS = - -# The EXCLUDE_SYMBOLS tag can be used to specify one or more symbol names -# (namespaces, classes, functions, etc.) that should be excluded from the output. -# The symbol name can be a fully qualified name, a word, or if the wildcard * is used, -# a substring. Examples: ANamespace, AClass, AClass::ANamespace, ANamespace::*Test - -EXCLUDE_SYMBOLS = - -# The EXAMPLE_PATH tag can be used to specify one or more files or -# directories that contain example code fragments that are included (see -# the \include command). - -EXAMPLE_PATH = - -# If the value of the EXAMPLE_PATH tag contains directories, you can use the -# EXAMPLE_PATTERNS tag to specify one or more wildcard pattern (like *.cpp -# and *.h) to filter out the source-files in the directories. If left -# blank all files are included. - -EXAMPLE_PATTERNS = - -# If the EXAMPLE_RECURSIVE tag is set to YES then subdirectories will be -# searched for input files to be used with the \include or \dontinclude -# commands irrespective of the value of the RECURSIVE tag. -# Possible values are YES and NO. If left blank NO is used. - -EXAMPLE_RECURSIVE = NO - -# The IMAGE_PATH tag can be used to specify one or more files or -# directories that contain image that are included in the documentation (see -# the \image command). - -IMAGE_PATH = - -# The INPUT_FILTER tag can be used to specify a program that doxygen should -# invoke to filter for each input file. Doxygen will invoke the filter program -# by executing (via popen()) the command , where -# is the value of the INPUT_FILTER tag, and is the name of an -# input file. Doxygen will then use the output that the filter program writes -# to standard output. If FILTER_PATTERNS is specified, this tag will be -# ignored. - -INPUT_FILTER = "awk -f scripts/doxy_filter.awk" - -# The FILTER_PATTERNS tag can be used to specify filters on a per file pattern -# basis. Doxygen will compare the file name with each pattern and apply the -# filter if there is a match. The filters are a list of the form: -# pattern=filter (like *.cpp=my_cpp_filter). See INPUT_FILTER for further -# info on how filters are used. If FILTER_PATTERNS is empty, INPUT_FILTER -# is applied to all files. - -FILTER_PATTERNS = - -# If the FILTER_SOURCE_FILES tag is set to YES, the input filter (if set using -# INPUT_FILTER) will be used to filter the input files when producing source -# files to browse (i.e. when SOURCE_BROWSER is set to YES). - -FILTER_SOURCE_FILES = NO - -#--------------------------------------------------------------------------- -# configuration options related to source browsing -#--------------------------------------------------------------------------- - -# If the SOURCE_BROWSER tag is set to YES then a list of source files will -# be generated. Documented entities will be cross-referenced with these sources. -# Note: To get rid of all source code in the generated output, make sure also -# VERBATIM_HEADERS is set to NO. If you have enabled CALL_GRAPH or CALLER_GRAPH -# then you must also enable this option. If you don't then doxygen will produce -# a warning and turn it on anyway - -SOURCE_BROWSER = NO - -# Setting the INLINE_SOURCES tag to YES will include the body -# of functions and classes directly in the documentation. - -INLINE_SOURCES = NO - -# Setting the STRIP_CODE_COMMENTS tag to YES (the default) will instruct -# doxygen to hide any special comment blocks from generated source code -# fragments. Normal C and C++ comments will always remain visible. - -STRIP_CODE_COMMENTS = YES - -# If the REFERENCED_BY_RELATION tag is set to YES (the default) -# then for each documented function all documented -# functions referencing it will be listed. - -REFERENCED_BY_RELATION = YES - -# If the REFERENCES_RELATION tag is set to YES (the default) -# then for each documented function all documented entities -# called/used by that function will be listed. - -REFERENCES_RELATION = NO - -# If the REFERENCES_LINK_SOURCE tag is set to YES (the default) -# and SOURCE_BROWSER tag is set to YES, then the hyperlinks from -# functions in REFERENCES_RELATION and REFERENCED_BY_RELATION lists will -# link to the source code. Otherwise they will link to the documentstion. - -REFERENCES_LINK_SOURCE = NO - -# If the USE_HTAGS tag is set to YES then the references to source code -# will point to the HTML generated by the htags(1) tool instead of doxygen -# built-in source browser. The htags tool is part of GNU's global source -# tagging system (see http://www.gnu.org/software/global/global.html). You -# will need version 4.8.6 or higher. - -USE_HTAGS = NO - -# If the VERBATIM_HEADERS tag is set to YES (the default) then Doxygen -# will generate a verbatim copy of the header file for each class for -# which an include is specified. Set to NO to disable this. - -VERBATIM_HEADERS = NO - -#--------------------------------------------------------------------------- -# configuration options related to the alphabetical class index -#--------------------------------------------------------------------------- - -# If the ALPHABETICAL_INDEX tag is set to YES, an alphabetical index -# of all compounds will be generated. Enable this if the project -# contains a lot of classes, structs, unions or interfaces. - -ALPHABETICAL_INDEX = NO - -# If the alphabetical index is enabled (see ALPHABETICAL_INDEX) then -# the COLS_IN_ALPHA_INDEX tag can be used to specify the number of columns -# in which this list will be split (can be a number in the range [1..20]) - -COLS_IN_ALPHA_INDEX = 5 - -# In case all classes in a project start with a common prefix, all -# classes will be put under the same header in the alphabetical index. -# The IGNORE_PREFIX tag can be used to specify one or more prefixes that -# should be ignored while generating the index headers. - -IGNORE_PREFIX = - -#--------------------------------------------------------------------------- -# configuration options related to the HTML output -#--------------------------------------------------------------------------- - -# If the GENERATE_HTML tag is set to YES (the default) Doxygen will -# generate HTML output. - -GENERATE_HTML = YES - -# The HTML_OUTPUT tag is used to specify where the HTML docs will be put. -# If a relative path is entered the value of OUTPUT_DIRECTORY will be -# put in front of it. If left blank `html' will be used as the default path. - -HTML_OUTPUT = html - -# The HTML_FILE_EXTENSION tag can be used to specify the file extension for -# each generated HTML page (for example: .htm,.php,.asp). If it is left blank -# doxygen will generate files with .html extension. - -HTML_FILE_EXTENSION = .html - -# The HTML_HEADER tag can be used to specify a personal HTML header for -# each generated HTML page. If it is left blank doxygen will generate a -# standard header. - -HTML_HEADER = - -# The HTML_FOOTER tag can be used to specify a personal HTML footer for -# each generated HTML page. If it is left blank doxygen will generate a -# standard footer. - -HTML_FOOTER = - -# The HTML_STYLESHEET tag can be used to specify a user-defined cascading -# style sheet that is used by each HTML page. It can be used to -# fine-tune the look of the HTML output. If the tag is left blank doxygen -# will generate a default style sheet. Note that doxygen will try to copy -# the style sheet file to the HTML output directory, so don't put your own -# stylesheet in the HTML output directory as well, or it will be erased! - -HTML_STYLESHEET = - -# If the HTML_ALIGN_MEMBERS tag is set to YES, the members of classes, -# files or namespaces will be aligned in HTML using tables. If set to -# NO a bullet list will be used. - -HTML_ALIGN_MEMBERS = YES - -# If the GENERATE_HTMLHELP tag is set to YES, additional index files -# will be generated that can be used as input for tools like the -# Microsoft HTML help workshop to generate a compressed HTML help file (.chm) -# of the generated HTML documentation. - -GENERATE_HTMLHELP = NO - -# If the HTML_DYNAMIC_SECTIONS tag is set to YES then the generated HTML -# documentation will contain sections that can be hidden and shown after the -# page has loaded. For this to work a browser that supports -# JavaScript and DHTML is required (for instance Mozilla 1.0+, Firefox -# Netscape 6.0+, Internet explorer 5.0+, Konqueror, or Safari). - -HTML_DYNAMIC_SECTIONS = NO - -# If the GENERATE_HTMLHELP tag is set to YES, the CHM_FILE tag can -# be used to specify the file name of the resulting .chm file. You -# can add a path in front of the file if the result should not be -# written to the html output directory. - -CHM_FILE = - -# If the GENERATE_HTMLHELP tag is set to YES, the HHC_LOCATION tag can -# be used to specify the location (absolute path including file name) of -# the HTML help compiler (hhc.exe). If non-empty doxygen will try to run -# the HTML help compiler on the generated index.hhp. - -HHC_LOCATION = - -# If the GENERATE_HTMLHELP tag is set to YES, the GENERATE_CHI flag -# controls if a separate .chi index file is generated (YES) or that -# it should be included in the master .chm file (NO). - -GENERATE_CHI = NO - -# If the GENERATE_HTMLHELP tag is set to YES, the BINARY_TOC flag -# controls whether a binary table of contents is generated (YES) or a -# normal table of contents (NO) in the .chm file. - -BINARY_TOC = NO - -# The TOC_EXPAND flag can be set to YES to add extra items for group members -# to the contents of the HTML help documentation and to the tree view. - -TOC_EXPAND = NO - -# The DISABLE_INDEX tag can be used to turn on/off the condensed index at -# top of each HTML page. The value NO (the default) enables the index and -# the value YES disables it. - -DISABLE_INDEX = YES - -# This tag can be used to set the number of enum values (range [1..20]) -# that doxygen will group on one line in the generated HTML documentation. - -ENUM_VALUES_PER_LINE = 4 - -# If the GENERATE_TREEVIEW tag is set to YES, a side panel will be -# generated containing a tree-like index structure (just like the one that -# is generated for HTML Help). For this to work a browser that supports -# JavaScript, DHTML, CSS and frames is required (for instance Mozilla 1.0+, -# Netscape 6.0+, Internet explorer 5.0+, or Konqueror). Windows users are -# probably better off using the HTML help feature. - -GENERATE_TREEVIEW = YES - -# If the treeview is enabled (see GENERATE_TREEVIEW) then this tag can be -# used to set the initial width (in pixels) of the frame in which the tree -# is shown. - -TREEVIEW_WIDTH = 300 - -#--------------------------------------------------------------------------- -# configuration options related to the LaTeX output -#--------------------------------------------------------------------------- - -# If the GENERATE_LATEX tag is set to YES (the default) Doxygen will -# generate Latex output. - -GENERATE_LATEX = NO - -# The LATEX_OUTPUT tag is used to specify where the LaTeX docs will be put. -# If a relative path is entered the value of OUTPUT_DIRECTORY will be -# put in front of it. If left blank `latex' will be used as the default path. - -LATEX_OUTPUT = latex - -# The LATEX_CMD_NAME tag can be used to specify the LaTeX command name to be -# invoked. If left blank `latex' will be used as the default command name. - -LATEX_CMD_NAME = latex - -# The MAKEINDEX_CMD_NAME tag can be used to specify the command name to -# generate index for LaTeX. If left blank `makeindex' will be used as the -# default command name. - -MAKEINDEX_CMD_NAME = makeindex - -# If the COMPACT_LATEX tag is set to YES Doxygen generates more compact -# LaTeX documents. This may be useful for small projects and may help to -# save some trees in general. - -COMPACT_LATEX = NO - -# The PAPER_TYPE tag can be used to set the paper type that is used -# by the printer. Possible values are: a4, a4wide, letter, legal and -# executive. If left blank a4wide will be used. - -PAPER_TYPE = a4wide - -# The EXTRA_PACKAGES tag can be to specify one or more names of LaTeX -# packages that should be included in the LaTeX output. - -EXTRA_PACKAGES = - -# The LATEX_HEADER tag can be used to specify a personal LaTeX header for -# the generated latex document. The header should contain everything until -# the first chapter. If it is left blank doxygen will generate a -# standard header. Notice: only use this tag if you know what you are doing! - -LATEX_HEADER = - -# If the PDF_HYPERLINKS tag is set to YES, the LaTeX that is generated -# is prepared for conversion to pdf (using ps2pdf). The pdf file will -# contain links (just like the HTML output) instead of page references -# This makes the output suitable for online browsing using a pdf viewer. - -PDF_HYPERLINKS = NO - -# If the USE_PDFLATEX tag is set to YES, pdflatex will be used instead of -# plain latex in the generated Makefile. Set this option to YES to get a -# higher quality PDF documentation. - -USE_PDFLATEX = NO - -# If the LATEX_BATCHMODE tag is set to YES, doxygen will add the \\batchmode. -# command to the generated LaTeX files. This will instruct LaTeX to keep -# running if errors occur, instead of asking the user for help. -# This option is also used when generating formulas in HTML. - -LATEX_BATCHMODE = NO - -# If LATEX_HIDE_INDICES is set to YES then doxygen will not -# include the index chapters (such as File Index, Compound Index, etc.) -# in the output. - -LATEX_HIDE_INDICES = NO - -#--------------------------------------------------------------------------- -# configuration options related to the RTF output -#--------------------------------------------------------------------------- - -# If the GENERATE_RTF tag is set to YES Doxygen will generate RTF output -# The RTF output is optimized for Word 97 and may not look very pretty with -# other RTF readers or editors. - -GENERATE_RTF = NO - -# The RTF_OUTPUT tag is used to specify where the RTF docs will be put. -# If a relative path is entered the value of OUTPUT_DIRECTORY will be -# put in front of it. If left blank `rtf' will be used as the default path. - -RTF_OUTPUT = rtf - -# If the COMPACT_RTF tag is set to YES Doxygen generates more compact -# RTF documents. This may be useful for small projects and may help to -# save some trees in general. - -COMPACT_RTF = NO - -# If the RTF_HYPERLINKS tag is set to YES, the RTF that is generated -# will contain hyperlink fields. The RTF file will -# contain links (just like the HTML output) instead of page references. -# This makes the output suitable for online browsing using WORD or other -# programs which support those fields. -# Note: wordpad (write) and others do not support links. - -RTF_HYPERLINKS = NO - -# Load stylesheet definitions from file. Syntax is similar to doxygen's -# config file, i.e. a series of assignments. You only have to provide -# replacements, missing definitions are set to their default value. - -RTF_STYLESHEET_FILE = - -# Set optional variables used in the generation of an rtf document. -# Syntax is similar to doxygen's config file. - -RTF_EXTENSIONS_FILE = - -#--------------------------------------------------------------------------- -# configuration options related to the man page output -#--------------------------------------------------------------------------- - -# If the GENERATE_MAN tag is set to YES (the default) Doxygen will -# generate man pages - -GENERATE_MAN = NO - -# The MAN_OUTPUT tag is used to specify where the man pages will be put. -# If a relative path is entered the value of OUTPUT_DIRECTORY will be -# put in front of it. If left blank `man' will be used as the default path. - -MAN_OUTPUT = man - -# The MAN_EXTENSION tag determines the extension that is added to -# the generated man pages (default is the subroutine's section .3) - -MAN_EXTENSION = .3 - -# If the MAN_LINKS tag is set to YES and Doxygen generates man output, -# then it will generate one additional man file for each entity -# documented in the real man page(s). These additional files -# only source the real man page, but without them the man command -# would be unable to find the correct page. The default is NO. - -MAN_LINKS = NO - -#--------------------------------------------------------------------------- -# configuration options related to the XML output -#--------------------------------------------------------------------------- - -# If the GENERATE_XML tag is set to YES Doxygen will -# generate an XML file that captures the structure of -# the code including all documentation. - -GENERATE_XML = NO - -# The XML_OUTPUT tag is used to specify where the XML pages will be put. -# If a relative path is entered the value of OUTPUT_DIRECTORY will be -# put in front of it. If left blank `xml' will be used as the default path. - -XML_OUTPUT = xml - -# The XML_SCHEMA tag can be used to specify an XML schema, -# which can be used by a validating XML parser to check the -# syntax of the XML files. - -XML_SCHEMA = - -# The XML_DTD tag can be used to specify an XML DTD, -# which can be used by a validating XML parser to check the -# syntax of the XML files. - -XML_DTD = - -# If the XML_PROGRAMLISTING tag is set to YES Doxygen will -# dump the program listings (including syntax highlighting -# and cross-referencing information) to the XML output. Note that -# enabling this will significantly increase the size of the XML output. - -XML_PROGRAMLISTING = YES - -#--------------------------------------------------------------------------- -# configuration options for the AutoGen Definitions output -#--------------------------------------------------------------------------- - -# If the GENERATE_AUTOGEN_DEF tag is set to YES Doxygen will -# generate an AutoGen Definitions (see autogen.sf.net) file -# that captures the structure of the code including all -# documentation. Note that this feature is still experimental -# and incomplete at the moment. - -GENERATE_AUTOGEN_DEF = NO - -#--------------------------------------------------------------------------- -# configuration options related to the Perl module output -#--------------------------------------------------------------------------- - -# If the GENERATE_PERLMOD tag is set to YES Doxygen will -# generate a Perl module file that captures the structure of -# the code including all documentation. Note that this -# feature is still experimental and incomplete at the -# moment. - -GENERATE_PERLMOD = NO - -# If the PERLMOD_LATEX tag is set to YES Doxygen will generate -# the necessary Makefile rules, Perl scripts and LaTeX code to be able -# to generate PDF and DVI output from the Perl module output. - -PERLMOD_LATEX = NO - -# If the PERLMOD_PRETTY tag is set to YES the Perl module output will be -# nicely formatted so it can be parsed by a human reader. This is useful -# if you want to understand what is going on. On the other hand, if this -# tag is set to NO the size of the Perl module output will be much smaller -# and Perl will parse it just the same. - -PERLMOD_PRETTY = YES - -# The names of the make variables in the generated doxyrules.make file -# are prefixed with the string contained in PERLMOD_MAKEVAR_PREFIX. -# This is useful so different doxyrules.make files included by the same -# Makefile don't overwrite each other's variables. - -PERLMOD_MAKEVAR_PREFIX = - -#--------------------------------------------------------------------------- -# Configuration options related to the preprocessor -#--------------------------------------------------------------------------- - -# If the ENABLE_PREPROCESSING tag is set to YES (the default) Doxygen will -# evaluate all C-preprocessor directives found in the sources and include -# files. - -ENABLE_PREPROCESSING = YES - -# If the MACRO_EXPANSION tag is set to YES Doxygen will expand all macro -# names in the source code. If set to NO (the default) only conditional -# compilation will be performed. Macro expansion can be done in a controlled -# way by setting EXPAND_ONLY_PREDEF to YES. - -MACRO_EXPANSION = NO - -# If the EXPAND_ONLY_PREDEF and MACRO_EXPANSION tags are both set to YES -# then the macro expansion is limited to the macros specified with the -# PREDEFINED and EXPAND_AS_DEFINED tags. - -EXPAND_ONLY_PREDEF = NO - -# If the SEARCH_INCLUDES tag is set to YES (the default) the includes files -# in the INCLUDE_PATH (see below) will be search if a #include is found. - -SEARCH_INCLUDES = YES - -# The INCLUDE_PATH tag can be used to specify one or more directories that -# contain include files that are not input files but should be processed by -# the preprocessor. - -INCLUDE_PATH = - -# You can use the INCLUDE_FILE_PATTERNS tag to specify one or more wildcard -# patterns (like *.h and *.hpp) to filter out the header-files in the -# directories. If left blank, the patterns specified with FILE_PATTERNS will -# be used. - -INCLUDE_FILE_PATTERNS = - -# The PREDEFINED tag can be used to specify one or more macro names that -# are defined before the preprocessor is started (similar to the -D option of -# gcc). The argument of the tag is a list of macros of the form: name -# or name=definition (no spaces). If the definition and the = are -# omitted =1 is assumed. To prevent a macro definition from being -# undefined via #undef or recursively expanded use the := operator -# instead of the = operator. - -PREDEFINED = \ - DOXYGEN_SHOULD_SKIP_THIS \ - CONFIG_CMD_DEVINFO \ - CONFIG_NET_TFTP_PUSH - -# If the MACRO_EXPANSION and EXPAND_ONLY_PREDEF tags are set to YES then -# this tag can be used to specify a list of macro names that should be expanded. -# The macro definition that is found in the sources will be used. -# Use the PREDEFINED tag if you want to use a different macro definition. - -EXPAND_AS_DEFINED = - -# If the SKIP_FUNCTION_MACROS tag is set to YES (the default) then -# doxygen's preprocessor will remove all function-like macros that are alone -# on a line, have an all uppercase name, and do not end with a semicolon. Such -# function macros are typically used for boiler-plate code, and will confuse -# the parser if not removed. - -SKIP_FUNCTION_MACROS = YES - -#--------------------------------------------------------------------------- -# Configuration::additions related to external references -#--------------------------------------------------------------------------- - -# The TAGFILES option can be used to specify one or more tagfiles. -# Optionally an initial location of the external documentation -# can be added for each tagfile. The format of a tag file without -# this location is as follows: -# TAGFILES = file1 file2 ... -# Adding location for the tag files is done as follows: -# TAGFILES = file1=loc1 "file2 = loc2" ... -# where "loc1" and "loc2" can be relative or absolute paths or -# URLs. If a location is present for each tag, the installdox tool -# does not have to be run to correct the links. -# Note that each tag file must have a unique name -# (where the name does NOT include the path) -# If a tag file is not located in the directory in which doxygen -# is run, you must also specify the path to the tagfile here. - -TAGFILES = - -# When a file name is specified after GENERATE_TAGFILE, doxygen will create -# a tag file that is based on the input files it reads. - -GENERATE_TAGFILE = - -# If the ALLEXTERNALS tag is set to YES all external classes will be listed -# in the class index. If set to NO only the inherited external classes -# will be listed. - -ALLEXTERNALS = NO - -# If the EXTERNAL_GROUPS tag is set to YES all external groups will be listed -# in the modules index. If set to NO, only the current project's groups will -# be listed. - -EXTERNAL_GROUPS = YES - -# The PERL_PATH should be the absolute path and name of the perl script -# interpreter (i.e. the result of `which perl'). - -PERL_PATH = /usr/bin/perl - -#--------------------------------------------------------------------------- -# Configuration options related to the dot tool -#--------------------------------------------------------------------------- - -# If the CLASS_DIAGRAMS tag is set to YES (the default) Doxygen will -# generate a inheritance diagram (in HTML, RTF and LaTeX) for classes with base -# or super classes. Setting the tag to NO turns the diagrams off. Note that -# this option is superseded by the HAVE_DOT option below. This is only a -# fallback. It is recommended to install and use dot, since it yields more -# powerful graphs. - -CLASS_DIAGRAMS = NO - -# You can define message sequence charts within doxygen comments using the \msc -# command. Doxygen will then run the mscgen tool (see http://www.mcternan.me.uk/mscgen/) to -# produce the chart and insert it in the documentation. The MSCGEN_PATH tag allows you to -# specify the directory where the mscgen tool resides. If left empty the tool is assumed to -# be found in the default search path. - -MSCGEN_PATH = - -# If set to YES, the inheritance and collaboration graphs will hide -# inheritance and usage relations if the target is undocumented -# or is not a class. - -HIDE_UNDOC_RELATIONS = YES - -# If you set the HAVE_DOT tag to YES then doxygen will assume the dot tool is -# available from the path. This tool is part of Graphviz, a graph visualization -# toolkit from AT&T and Lucent Bell Labs. The other options in this section -# have no effect if this option is set to NO (the default) - -HAVE_DOT = NO - -# If the CLASS_GRAPH and HAVE_DOT tags are set to YES then doxygen -# will generate a graph for each documented class showing the direct and -# indirect inheritance relations. Setting this tag to YES will force the -# the CLASS_DIAGRAMS tag to NO. - -CLASS_GRAPH = YES - -# If the COLLABORATION_GRAPH and HAVE_DOT tags are set to YES then doxygen -# will generate a graph for each documented class showing the direct and -# indirect implementation dependencies (inheritance, containment, and -# class references variables) of the class with other documented classes. - -COLLABORATION_GRAPH = YES - -# If the GROUP_GRAPHS and HAVE_DOT tags are set to YES then doxygen -# will generate a graph for groups, showing the direct groups dependencies - -GROUP_GRAPHS = YES - -# If the UML_LOOK tag is set to YES doxygen will generate inheritance and -# collaboration diagrams in a style similar to the OMG's Unified Modeling -# Language. - -UML_LOOK = NO - -# If set to YES, the inheritance and collaboration graphs will show the -# relations between templates and their instances. - -TEMPLATE_RELATIONS = NO - -# If the ENABLE_PREPROCESSING, SEARCH_INCLUDES, INCLUDE_GRAPH, and HAVE_DOT -# tags are set to YES then doxygen will generate a graph for each documented -# file showing the direct and indirect include dependencies of the file with -# other documented files. - -INCLUDE_GRAPH = NO - -# If the ENABLE_PREPROCESSING, SEARCH_INCLUDES, INCLUDED_BY_GRAPH, and -# HAVE_DOT tags are set to YES then doxygen will generate a graph for each -# documented header file showing the documented files that directly or -# indirectly include this file. - -INCLUDED_BY_GRAPH = NO - -# If the CALL_GRAPH, SOURCE_BROWSER and HAVE_DOT tags are set to YES then doxygen will -# generate a call dependency graph for every global function or class method. -# Note that enabling this option will significantly increase the time of a run. -# So in most cases it will be better to enable call graphs for selected -# functions only using the \callgraph command. - -CALL_GRAPH = NO - -# If the CALLER_GRAPH, SOURCE_BROWSER and HAVE_DOT tags are set to YES then doxygen will -# generate a caller dependency graph for every global function or class method. -# Note that enabling this option will significantly increase the time of a run. -# So in most cases it will be better to enable caller graphs for selected -# functions only using the \callergraph command. - -CALLER_GRAPH = NO - -# If the GRAPHICAL_HIERARCHY and HAVE_DOT tags are set to YES then doxygen -# will graphical hierarchy of all classes instead of a textual one. - -GRAPHICAL_HIERARCHY = NO - -# If the DIRECTORY_GRAPH, SHOW_DIRECTORIES and HAVE_DOT tags are set to YES -# then doxygen will show the dependencies a directory has on other directories -# in a graphical way. The dependency relations are determined by the #include -# relations between the files in the directories. - -DIRECTORY_GRAPH = NO - -# The DOT_IMAGE_FORMAT tag can be used to set the image format of the images -# generated by dot. Possible values are png, jpg, or gif -# If left blank png will be used. - -DOT_IMAGE_FORMAT = png - -# The tag DOT_PATH can be used to specify the path where the dot tool can be -# found. If left blank, it is assumed the dot tool can be found in the path. - -DOT_PATH = - -# The DOTFILE_DIRS tag can be used to specify one or more directories that -# contain dot files that are included in the documentation (see the -# \dotfile command). - -DOTFILE_DIRS = - -# The MAX_DOT_GRAPH_MAX_NODES tag can be used to set the maximum number of -# nodes that will be shown in the graph. If the number of nodes in a graph -# becomes larger than this value, doxygen will truncate the graph, which is -# visualized by representing a node as a red box. Note that doxygen if the number -# of direct children of the root node in a graph is already larger than -# MAX_DOT_GRAPH_NOTES then the graph will not be shown at all. Also note -# that the size of a graph can be further restricted by MAX_DOT_GRAPH_DEPTH. - -DOT_GRAPH_MAX_NODES = 50 - -# The MAX_DOT_GRAPH_DEPTH tag can be used to set the maximum depth of the -# graphs generated by dot. A depth value of 3 means that only nodes reachable -# from the root by following a path via at most 3 edges will be shown. Nodes -# that lay further from the root node will be omitted. Note that setting this -# option to 1 or 2 may greatly reduce the computation time needed for large -# code bases. Also note that the size of a graph can be further restricted by -# DOT_GRAPH_MAX_NODES. Using a depth of 0 means no depth restriction. - -MAX_DOT_GRAPH_DEPTH = 0 - -# Set the DOT_TRANSPARENT tag to YES to generate images with a transparent -# background. This is disabled by default, which results in a white background. -# Warning: Depending on the platform used, enabling this option may lead to -# badly anti-aliased labels on the edges of a graph (i.e. they become hard to -# read). - -DOT_TRANSPARENT = YES - -# Set the DOT_MULTI_TARGETS tag to YES allow dot to generate multiple output -# files in one run (i.e. multiple -o and -T options on the command line). This -# makes dot run faster, but since only newer versions of dot (>1.8.10) -# support this, this feature is disabled by default. - -DOT_MULTI_TARGETS = YES - -# If the GENERATE_LEGEND tag is set to YES (the default) Doxygen will -# generate a legend page explaining the meaning of the various boxes and -# arrows in the dot generated graphs. - -GENERATE_LEGEND = NO - -# If the DOT_CLEANUP tag is set to YES (the default) Doxygen will -# remove the intermediate dot files that are used to generate -# the various graphs. - -DOT_CLEANUP = NO - -#--------------------------------------------------------------------------- -# Configuration::additions related to the search engine -#--------------------------------------------------------------------------- - -# The SEARCHENGINE tag specifies whether or not a search engine should be -# used. If set to NO the values of all tags below this one will be ignored. - -SEARCHENGINE = NO diff --git a/Makefile b/Makefile index 746f41252e..e7e1679163 100644 --- a/Makefile +++ b/Makefile @@ -1117,16 +1117,6 @@ help: @echo 'Execute "make" or "make all" to build all targets marked with [*] ' @echo 'For further info see the ./README file' -# Generate doxygen docs -# --------------------------------------------------------------------------- -.PHONY += docs htmldocs - -docs : htmldocs - -htmldocs: Doxyfile.version - @echo 'Running doxygen with local Doxyfile' - $(Q)doxygen Doxyfile - # Generate tags for editors # --------------------------------------------------------------------------- quiet_cmd_tags = GEN $@ diff --git a/arch/architecture.dox b/arch/architecture.dox deleted file mode 100644 index 2d2cf05aa7..0000000000 --- a/arch/architecture.dox +++ /dev/null @@ -1,175 +0,0 @@ -/** @page dev_architecture Integrate a new architecture (ARCH) - -@section linker_scripts Rules for the generic Linker Script File - -Never include an object file by name directly! Linker Script Files defines the -layout, not the content. Content is defined in objecfiles instead. - -Don't rely on the given object file order to create your binary @a barebox! This -may work, but is not relyable in all cases (and its a very bad style)! - -For the special case some layout contraints exists, use specific section -naming instead. Refer @ref reset_code how to define this specific section. - -@section reset_code Bring it up: The Reset Code - -The way a CPU wakes up after reset is very specific to its architecture. - -For example the ARM architecture starts its reset code at address 0x0000000, -the x86 architecture at 0x000FFFF0, PowerPC at 0x00000100 or 0xFFFFF100. - -So for the special reset code on all architectures it must be located at -architecture specific locations within the binary @a barebox image. - -All reset code uses section ".text_entry" for its localisation within the -binary @a barebox image. Its up to the linker script file to use this section name -to find the right place in whatever environment and @a barebox sizes. - -@code - .section ".text_entry","ax" -@endcode - -@section arch_files List of changes - - - create a new subdirectory in /arch -TODO - -*/ - -/** @page dev_cpu Integrate a new CPU (MACH) - -Features required for every CPU: - - - clocksource - - CPU reset function - -@section time_keeping Time keeping - -In @a barebox we are using the clocksource mechanism from the Linux Kernel. -This makes it fairly easy to add timer functionality for a new board or -architecture. - -Apart from initialization there is only one function to be registerd: -clocksource_read(). This function returns the current value of a free running -counter. Other functions like udelay() and get_time_ns() are derived from this -function. The only thing you have to implement is a clocksource driver and -to register it at runtime. - -@code -static uint64_t mycpu_clocksource_read(void) -{ - TODO -} - -static struct clocksource cs = { - .read = mycpu_clocksource_read, - .mask = 0xffffffff, - .shift = 10, -}; - -.... - init_clock(&cs); -.... -@endcode - -See arch/arm/mach-imx/clocksource.c for an example. clocksource drivers from -the Linux Kernel can be used nearly 1:1, except for the register accesses. - -Note: For clocksources the __lshrdi3 symbol is needed. You can find the -function for your architecture in the Linux Kernel or a libc of your choice. - -@note @a barebox expects an upward counting counter! - -@section reset_function Reset function - -TODO - -@li @subpage dev_arm_mach -@li @subpage dev_bf_mach -@li @subpage dev_mips_mach -@li @subpage dev_ppc_mach -@li @subpage dev_x86_mach - -*/ - -/** @page io_access_functions I/O access functions - -List of functions to be used for hardware register access (I/O). - -@section native_access Native IN/OUT access - -@note Native means: It uses the same endianess than the CPU. - -@subsection single_native_access Single access of various width - -The following functions are intended to be used for a single I/O access. - -To read a byte (8 bit) from a specific I/O address: -@code -uint8_t readb(unsigned long) -@endcode - -To read a word (16 bit) from a specific I/O address: -@code -uint16_t readw(unsigned long) -@endcode - -To read a long word (32 bit) from a specific I/O address: -@code -uint32_t readl(unsigned long) -@endcode - -To write a byte (8 bit) into a specific I/O address: -@code -void writeb(uint8_t val, unsigned long) -@endcode - -To write a word (16 bit) into a specific I/O address: -@code -void writew(uint16_t val, unsigned long) -@endcode - -To write a long word (32 bit) into a specific I/O address: -@code -void writel(uint32_t val, unsigned long) -@endcode - -@subsection string_native_access String native access of various width - -The following functions are intended to be used for string based I/O access. - -To read a string of bytes (8 bit) from one specific I/O address: -@code -void readsb(const void __iomem *addr, void *mem_buffer, int byte_count); -@endcode - -To read a string of words (16 bit) from one specific I/O address: -@code -void readsw(const void __iomem *addr, void *mem_buffer, int word_count); -@endcode - -To read a string of long words (32 bit) from one specific I/O address: -@code -void readsl(const void __iomem *addr, void *mem_buffer, int long_count); -@endcode - -To write a string of bytes (8 bit) to one specific I/O address: -@code -void writesb(void __iomem *addr, const void *mem_buffer, int byte_count); -@endcode - -To write a string of words (16 bit) to one specific I/O address: -@code -void writesw(void __iomem *addr, const void *mem_buffer, int word_count); -@endcode - -To write a string of long words (32 bit) to one specific I/O address: -@code -void writesl(void __iomem *addr, const void *mem_buffer, int long_count); -@endcode - -@section special_access Special IN/OUT access - -TBD - -*/ diff --git a/arch/arm/boards/a9m2410/a9m2410.c b/arch/arm/boards/a9m2410/a9m2410.c index 943b7709bf..44cf51b212 100644 --- a/arch/arm/boards/a9m2410/a9m2410.c +++ b/arch/arm/boards/a9m2410/a9m2410.c @@ -14,12 +14,6 @@ * */ -/** - * @file - * @brief a9m2410 Specific Board Initialization routines - * - */ - #include #include #include @@ -154,65 +148,3 @@ static int a9m2410_console_init(void) } console_initcall(a9m2410_console_init); - -/** @page a9m2410 DIGI's a9m2410 - -This CPU card is based on a Samsung S3C2410 CPU. The card is shipped with: - -- S3C2410\@200 MHz (ARM920T/ARMv4T) -- 12MHz crystal reference -- SDRAM 32 MiB - - Samsung K4M563233E-EE1H - - 2M x 32Bit x 4 Banks Mobile SDRAM - - 90 pin FBGA - - CL3\@133MHz, CL2\@100MHz (CAS/RAS delay 19ns) - - four banks - - 32 bit data bits - - row address size is 11 - - Row cycle time: 69ns - - collumn address size is 9 bits - - Extended temperature range (-25°C...85°C) - - 64ms refresh period (4k) -- NAND Flash 32 MiB - - Samsung KM29U256T - - 32MiB 3,3V 8-bit - - ID: 0xEC, 0x75, 0x??, 0xBD - - 30ns/40ns/20ns -- I2C interface, 100KHz and 400KHz - - Real Time Clock - - Dallas DS1337 - - address 0x68 - - EEPROM - - ST M24LC64 - - address 0x50 - - 16bit addressing -- LCD interface -- Touch Screen interface -- Camera interface -- I2S interface -- AC97 Audio-CODEC interface -- SD card interface -- 3 serial RS232 interfaces -- Host and device USB interface, USB1.1 compliant -- Ethernet interface - - 10Mbps, Cirrus Logic, CS8900A (on the CPU card) or - - 10/100Mbps, SMSC 91C111 (on the baseboard) -- SPI interface -- JTAG interface - -How to get the binary image: - -Using the default configuration: - -@code -make ARCH=arm a9m2410_defconfig -@endcode - -Build the binary image: - -@code -make ARCH=arm CROSS_COMPILE=armv4compiler -@endcode - -@note replace the armv4compiler with your ARM v4 cross compiler. -*/ diff --git a/arch/arm/boards/a9m2440/a9m2440.c b/arch/arm/boards/a9m2440/a9m2440.c index faac38a4e3..587baf6cfd 100644 --- a/arch/arm/boards/a9m2440/a9m2440.c +++ b/arch/arm/boards/a9m2440/a9m2440.c @@ -14,12 +14,6 @@ * */ -/** - * @file - * @brief a9m2440 Specific Board Initialization routines - * - */ - #include #include #include @@ -161,76 +155,3 @@ static int a9m2440_console_init(void) } console_initcall(a9m2440_console_init); - -/** @page a9m2440 DIGI's a9m2440 - -This CPU card is based on a Samsung S3C2440 CPU. The card is shipped with: - -- S3C2440\@400 MHz or 533 MHz (ARM920T/ARMv4T) -- 16.9344 MHz crystal reference -- SDRAM 32/64/128 MiB - - Samsung K4M563233E-EE1H (one or two devices for 32 MiB or 64 MiB) - - 2M x 32bit x 4 Banks Mobile SDRAM - - CL2\@100 MHz (CAS/RAS delay 19ns) - - 105 MHz max - - collumn address size is 9 bits - - Row cycle time: 69ns - - Samsung K4M513233C-DG75 (one or two devices for 64 MiB or 128 MiB) - - 4M x 32bit x 4 Banks Mobile SDRAM - - CL2\@100MHz (CAS/RAS delay 18ns) - - 111 MHz max - - collumn address size is 9 bits - - Row cycle time: 63ns - - 64ms refresh period (4k) - - 90 pin FBGA - - 32 bit data bits - - Extended temperature range (-25°C...85°C) -- NAND Flash 32/64/128 MiB - - Samsung KM29U512T (NAND01GW3A0AN6) - - 64 MiB 3,3V 8-bit - - ID: 0xEC, 0x76, 0x??, 0xBD - - Samsung KM29U256T - - 32 MiB 3,3V 8-bit - - ID: 0xEC, 0x75, 0x??, 0xBD - - ST Micro - - 128 MiB 3,3V 8-bit - - ID: 0x20, 0x79 - - 30ns/40ns/20ns -- I2C interface, 100 KHz and 400 KHz - - Real Time Clock - - Dallas DS1337 - - address 0x68 - - EEPROM - - ST M24LC64 - - address 0x50 - - 16bit addressing -- LCD interface -- Touch Screen interface -- Camera interface -- I2S interface -- AC97 Audio-CODEC interface -- SD card interface -- 3 serial RS232 interfaces -- Host and device USB interface, USB1.1 compliant -- Ethernet interface - - 10Mbps, Cirrus Logic, CS8900A (on the CPU card) -- SPI interface -- JTAG interface - -How to get the binary image: - -Using the default configuration: - -@code -make ARCH=arm a9m2440_defconfig -@endcode - -Build the binary image: - -@code -make ARCH=arm CROSS_COMPILE=armv4compiler -@endcode - -@note replace the armv4compiler with your ARM v4 cross compiler. - -*/ diff --git a/arch/arm/boards/beagle/board.c b/arch/arm/boards/beagle/board.c index 1899b1d846..4054960581 100644 --- a/arch/arm/boards/beagle/board.c +++ b/arch/arm/boards/beagle/board.c @@ -15,37 +15,6 @@ * */ -/** - * @file - * @brief Beagle Specific Board Initialization routines - */ - -/** - * @page ti_beagle Texas Instruments Beagle Board - * - * Beagle Board from Texas Instruments as described here: - * http://www.beagleboard.org - * - * This board is based on OMAP3530. - * More on OMAP3530 (including documentation can be found here): - * http://focus.ti.com/docs/prod/folders/print/omap3530.html - * - * This file provides initialization in two stages: - * @li boot time initialization - do basics required to get SDRAM working. - * This is run from SRAM - so no case constructs and global vars can be used. - * @li run time initialization - this is for the rest of the initializations - * such as flash, uart etc. - * - * Boot time initialization includes: - * @li SDRAM initialization. - * @li Pin Muxing relevant for Beagle. - * - * Run time initialization includes - * @li serial @ref serial_ns16550.c driver device definition - * - * Originally from arch/arm/boards/omap/board-sdp343x.c - */ - #include #include #include diff --git a/arch/arm/boards/ccxmx51/ccxmx51.dox b/arch/arm/boards/ccxmx51/ccxmx51.dox deleted file mode 100644 index cc28e8d66a..0000000000 --- a/arch/arm/boards/ccxmx51/ccxmx51.dox +++ /dev/null @@ -1,7 +0,0 @@ -/** @page ccxmx51 Digi ConnectCore board - -This boards is based on a Freescale i.MX51 CPU. The board is shipped with: -- Up to 8 GB NAND Flash. -- Up to 512 MB DDR2 RAM. - -*/ diff --git a/arch/arm/boards/chumby_falconwing/falconwing.c b/arch/arm/boards/chumby_falconwing/falconwing.c index 77581f668f..2e5fca5f50 100644 --- a/arch/arm/boards/chumby_falconwing/falconwing.c +++ b/arch/arm/boards/chumby_falconwing/falconwing.c @@ -318,141 +318,3 @@ static int falconwing_console_init(void) } console_initcall(falconwing_console_init); - -/** @page chumbyone Chumby Industrie's Falconwing - -This device is also known as "chumby one" (http://www.chumby.com/) - -This CPU card is based on a Freescale i.MX23 CPU. The card is shipped with: - -- 64 MiB synchronous dynamic RAM (DDR type) - -Memory layout when @b barebox is running: - -- 0x40000000 start of SDRAM -- 0x40000100 start of kernel's boot parameters - - below malloc area: stack area - - below barebox: malloc area -- 0x42000000 start of @b barebox - -@section get_falconwing_binary How to get the bootloader binary image: - -Using the default configuration: - -@verbatim -make ARCH=arm chumbyone_defconfig -@endverbatim - -Build the bootloader binary image: - -@verbatim -make ARCH=arm CROSS_COMPILE=armv5compiler -@endverbatim - -@note replace the armv5compiler with your ARM v5 cross compiler. - -@section setup_falconwing How to prepare an MCI card to boot the "chumby one" with barebox - -- Create four primary partitions on the MCI card - - the first one for the bootlets (about 256 kiB) - - the second one for the persistant environment (size is up to you, at least 256k) - - the third one for the kernel (2 MiB ... 4 MiB in size) - - the 4th one for the root filesystem which can fill the rest of the available space - -- Mark the first partition with the partition ID "53" and copy the bootlets - into this partition (currently not part of @b barebox!). - -- Copy the default @b barebox environment into the second partition (no filesystem required). - -- Copy the kernel into the third partition (no filesystem required). - -- Create the root filesystem in the 4th partition. You may copy an image into this - partition or you can do it in the classic way: mkfs on it, mount it and copy - all required data and programs into it. - -@section gpio_falconwing Available GPIOs - -The Falconwing uses some GPIOs to control various features. With the regular -GPIO commands these features can be controlled at @a barebox's runtime. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
NoDirectionFunctionResetSet
8OutputSwitch Audio AmplifierOffOn
11InputHead Phone DetectionTBDTBD
14InputUnused (J113)UserUser
15InputUnused (J114)UserUser
26OutputUSB PowerTBDTBD
27InputDisplay ConnectedDisplay
Attached		Display
Disconnected
29OutputUSB HUB ResetTBDTBD
50OutputDisplay ResetDisplay
Reset		Display
Running
60OutputDisplay BacklightBacklight
Off		Backlight
On (100 %)
62InputBendNot pressedPressed
- -*/ diff --git a/arch/arm/boards/edb93xx/edb93xx.dox b/arch/arm/boards/edb93xx/edb93xx.dox deleted file mode 100644 index 3964d55367..0000000000 --- a/arch/arm/boards/edb93xx/edb93xx.dox +++ /dev/null @@ -1,108 +0,0 @@ -/** @page edb9301 Cirrus Logic EDB9301 - -This boards is based on a Cirrus Logic EP9301 CPU. The board is shipped with: - -- 16MiB NOR type Flash Memory -- 32MiB synchronous dynamic RAM on CS3 -- 128kiB serial EEPROM -- MII 10/100 Ethernet PHY -- Stereo audio codec - -*/ - -/** @page edb9302 Cirrus Logic EDB9302 - -This board is based on a Cirrus Logic EP9302 CPU. The board is shipped with: - -- 16MiB NOR type Flash Memory -- 32MiB synchronous dynamic RAM on CS3 -- 128kiB serial EEPROM -- MII 10/100 Ethernet PHY -- Stereo audio codec - -*/ - -/** @page edb9302a Cirrus Logic EDB9302A - -This board is based on a Cirrus Logic EP9302 CPU. The board is shipped with: - -- 16MiB NOR type Flash Memory -- 32MiB synchronous dynamic RAM on CS0 -- 512kiB serial EEPROM -- MII 10/100 Ethernet PHY -- Stereo audio codec - -*/ - -/** @page edb9307 Cirrus Logic EDB9307 - -This board is based on a Cirrus Logic EP9307 CPU. The board is shipped with: - -- 32MiB NOR type Flash Memory -- 64MiB synchronous dynamic RAM on CS3 -- 512kiB asynchronous SRAM -- 128kiB serial EEPROM -- MII 10/100 Ethernet PHY -- Stereo audio codec -- Real-Time Clock -- IR receiver - -*/ - -/** @page edb9307a Cirrus Logic EDB9307A - -This board is based on a Cirrus Logic EP9307 CPU. The board is shipped with: - -- 32MiB NOR type Flash Memory -- 64MiB synchronous dynamic RAM on CS0 -- 512kiB serial EEPROM -- MII 10/100 Ethernet PHY -- Stereo audio codec -- Real-Time Clock -- IR receiver - -*/ - -/** @page edb9312 Cirrus Logic EDB9312 - -This board is based on a Cirrus Logic EP9312 CPU. The board is shipped with: - -- 32MiB NOR type Flash Memory -- 64MiB synchronous dynamic RAM on CS3 -- 512kiB asynchronous SRAM -- 128kiB serial EEPROM -- MII 10/100 Ethernet PHY -- Stereo audio codec -- Real-Time Clock -- IR receiver - -*/ - -/** @page edb9315 Cirrus Logic EDB9315 - -This board is based on a Cirrus Logic EP9315 CPU. The board is shipped with: - -- 32MiB NOR type Flash Memory -- 64MiB synchronous dynamic RAM on CS3 -- 512kiB asynchronous SRAM -- 128kiB serial EEPROM -- MII 10/100 Ethernet PHY -- Stereo audio codec -- Real-Time Clock -- IR receiver - -*/ - -/** @page edb9315a Cirrus Logic EDB9315A - -This board is based on a Cirrus Logic EP9315 CPU. The board is shipped with: - -- 32MiB NOR type Flash Memory -- 64MiB synchronous dynamic RAM on CS0 -- 128kiB serial EEPROM -- MII 10/100 Ethernet PHY -- Stereo audio codec -- Real-Time Clock -- IR receiver - -*/ \ No newline at end of file diff --git a/arch/arm/boards/eukrea_cpuimx27/eukrea_cpuimx27.dox b/arch/arm/boards/eukrea_cpuimx27/eukrea_cpuimx27.dox deleted file mode 100644 index 6c2bfede22..0000000000 --- a/arch/arm/boards/eukrea_cpuimx27/eukrea_cpuimx27.dox +++ /dev/null @@ -1,11 +0,0 @@ -/** @page eukrea_cpuimx27 Eukrea's CPUIMX27 - -This CPU card is based on a Freescale i.MX27 CPU. The card is shipped with: - -- up to 64MiB NOR type Flash Memory -- up to 256MiB synchronous dynamic RAM -- up to 512MiB NAND type Flash Memory -- MII 10/100 ethernet PHY -- optional 16554 Quad UART on CS3 - -*/ diff --git a/arch/arm/boards/eukrea_cpuimx35/eukrea_cpuimx35.dox b/arch/arm/boards/eukrea_cpuimx35/eukrea_cpuimx35.dox deleted file mode 100644 index cbdf69db35..0000000000 --- a/arch/arm/boards/eukrea_cpuimx35/eukrea_cpuimx35.dox +++ /dev/null @@ -1,4 +0,0 @@ -/** @page eukrea_cpuimx35 Eukrea's CPUIMX35 - - -*/ diff --git a/arch/arm/boards/eukrea_cpuimx51/eukrea_cpuimx51.dox b/arch/arm/boards/eukrea_cpuimx51/eukrea_cpuimx51.dox deleted file mode 100644 index 0f35e174ba..0000000000 --- a/arch/arm/boards/eukrea_cpuimx51/eukrea_cpuimx51.dox +++ /dev/null @@ -1,4 +0,0 @@ -/** @page eukrea_cpuimx51 Eukrea's CPUIMX51 - - -*/ diff --git a/arch/arm/boards/freescale-mx21-ads/imx21ads.dox b/arch/arm/boards/freescale-mx21-ads/imx21ads.dox deleted file mode 100644 index 9f11ffaa6e..0000000000 --- a/arch/arm/boards/freescale-mx21-ads/imx21ads.dox +++ /dev/null @@ -1,5 +0,0 @@ -/** @page imx21ads Freescale i.MX21ads - -This is the Freescale evaluation board for the i.MX21 Processor - -*/ diff --git a/arch/arm/boards/freescale-mx23-evk/mx23-evk.c b/arch/arm/boards/freescale-mx23-evk/mx23-evk.c index 1eae37722c..9f13fac6dd 100644 --- a/arch/arm/boards/freescale-mx23-evk/mx23-evk.c +++ b/arch/arm/boards/freescale-mx23-evk/mx23-evk.c @@ -144,35 +144,3 @@ static int mx23_evk_console_init(void) } console_initcall(mx23_evk_console_init); - -/** @page mx23_evk Freescale's i.MX23 evaluation kit - -This CPU card is based on an i.MX23 CPU. The card is shipped with: - -- 32 MiB synchronous dynamic RAM (mobile DDR type) -- ENC28j60 based network (over SPI) - -Memory layout when @b barebox is running: - -- 0x40000000 start of SDRAM -- 0x40000100 start of kernel's boot parameters - - below malloc area: stack area - - below barebox: malloc area -- 0x41000000 start of @b barebox - -@section get_imx23evk_binary How to get the bootloader binary image: - -Using the default configuration: - -@verbatim -make ARCH=arm imx23evk_defconfig -@endverbatim - -Build the bootloader binary image: - -@verbatim -make ARCH=arm CROSS_COMPILE=armv5compiler -@endverbatim - -@note replace the armv5compiler with your ARM v5 cross compiler. -*/ diff --git a/arch/arm/boards/freescale-mx27-ads/imx27ads.dox b/arch/arm/boards/freescale-mx27-ads/imx27ads.dox deleted file mode 100644 index e14d8e3fab..0000000000 --- a/arch/arm/boards/freescale-mx27-ads/imx27ads.dox +++ /dev/null @@ -1,5 +0,0 @@ -/** @page imx27ads Freescale i.MX27ads - -This is the Freescale evaluation board for the i.MX27 Processor - -*/ diff --git a/arch/arm/boards/freescale-mx35-3ds/3stack.dox b/arch/arm/boards/freescale-mx35-3ds/3stack.dox deleted file mode 100644 index 15c5b6e1ff..0000000000 --- a/arch/arm/boards/freescale-mx35-3ds/3stack.dox +++ /dev/null @@ -1,4 +0,0 @@ -/** @page the3stack Freescale MX35 3-Stack Board - - -*/ diff --git a/arch/arm/boards/freescale-mx51-babbage/mx51-pdk.dox b/arch/arm/boards/freescale-mx51-babbage/mx51-pdk.dox deleted file mode 100644 index d9ea823e5c..0000000000 --- a/arch/arm/boards/freescale-mx51-babbage/mx51-pdk.dox +++ /dev/null @@ -1,4 +0,0 @@ -/** @page board_babage Freescale i.MX51 PDK (Babbage) Board - - -*/ diff --git a/arch/arm/boards/freescale-mx53-qsb/mx53-pdk.dox b/arch/arm/boards/freescale-mx53-qsb/mx53-pdk.dox deleted file mode 100644 index 3a2c84fc3f..0000000000 --- a/arch/arm/boards/freescale-mx53-qsb/mx53-pdk.dox +++ /dev/null @@ -1,4 +0,0 @@ -/** @page board_loco Freescale i.MX53 PDK (Loco) Board - - -*/ diff --git a/arch/arm/boards/freescale-mx53-smd/mx53-smd.dox b/arch/arm/boards/freescale-mx53-smd/mx53-smd.dox deleted file mode 100644 index 19605088f6..0000000000 --- a/arch/arm/boards/freescale-mx53-smd/mx53-smd.dox +++ /dev/null @@ -1,4 +0,0 @@ -/** @page board_loco Freescale i.MX53 SMD Board - - -*/ diff --git a/arch/arm/boards/friendlyarm-mini2440/mini2440.c b/arch/arm/boards/friendlyarm-mini2440/mini2440.c index 86e22ad131..4034de5a52 100644 --- a/arch/arm/boards/friendlyarm-mini2440/mini2440.c +++ b/arch/arm/boards/friendlyarm-mini2440/mini2440.c @@ -16,12 +16,6 @@ * */ -/** - * @file - * @brief mini2440 Specific Board Initialization routines - * - */ - #include #include #include @@ -338,156 +332,3 @@ static int mini2440_console_init(void) } console_initcall(mini2440_console_init); - -/** @page mini2440 FriendlyARM's mini2440 - -This system is based on a Samsung S3C2440 CPU. The card is shipped with: - -- S3C2440\@400 MHz or 533 MHz (ARM920T/ARMv4T) -- 12 MHz crystal reference -- 32.768 kHz crystal reference -- SDRAM 64 MiB (one bank only) - - HY57V561620 (two devices for 64 MiB to form a 32 bit bus) - - 4M x 16bit x 4 Banks Mobile SDRAM - - 8192 refresh cycles / 64 ms - - CL2\@100 MHz - - 133 MHz max - - collumn address size is 9 bits - - row address size is 13 bits - - MT48LC16M16 (two devices for 64 MiB to form a 32 bit bus) - - 4M x 16bit x 4 Banks Mobile SDRAM - - commercial & industrial type - - 8192 refresh cycles / 64 ms - - CL2\@100 MHz - - 133 MHz max - - collumn address size is 9 bits - - row address size is 13 bits -- NAND Flash 128MiB...1GiB - - K9Fxx08 -- NOR Flash (up to 22 address lines available) - - AM29LV160DB, 2 MiB - - SST39VF1601, 2 MiB - - 16 bit data bus -- SD card interface, 3.3V (fixed voltage) -- Host and device USB interface, USB1.1 compliant -- UDA1341TS Audio -- DM9000 Ethernet interface - - uses CS#4 - - uses EINT7 - - 16 bit data bus -- I2C interface, 100 KHz and 400 KHz - - EEPROM - - ST M24C08 - - address 0x50 -- Speaker on GPB0 ("low" = inactive) -- LCD interface -- Touch Screen interface -- Camera interface -- I2S interface -- AC97 Audio-CODEC interface -- three serial RS232 interfaces (one with level converter) -- SPI interface -- JTAG interface - -How to get the binary image: - -Using the default configuration: - -@code -make ARCH=arm mini2440_defconfig -@endcode - -Build the binary image: - -@code -make ARCH=arm CROSS_COMPILE=armv4compiler -@endcode - -@note replace the armv4compiler with your ARM v4 cross compiler. - -How to bring in \a barebox ? - -First run it as a second stage bootloader. There are two known working ways to -do so: - -One way is to use the "device firmware update" feature of the 'supervivi'. - - connect a terminal application to the mini2440's serial connector - - switch S2 to 'boot from NOR' to boot into 'supervivi' - - connect your host to the usb device connector on the mini2440 - - switch on your mini2440 - - in 'supervivi' type q (command line) then: -@code -load ram 0x31000000 \ u -@endcode - - use a tool for DFU update (for example from openkomo) to transfer the 'barebox.bin' binary - - then in 'supervivi' just run -@code -go 0x31000000 -@endcode - -A second way is to use any kind of JTAG adapter. For this case I'm using the -'JTAKkey tiny' from Amontec and OpenOCD. First you need an adapter for this -kind of Dongle as it uses a 20 pin connector with 2.54 mm grid, and the -mini2440 uses a 10 pin connector with 2 mm grid. - -@code - Amontec JTAGkey tiny mini2440 - ------------------------------------------------------- - VREF 1 2 n.c. VREF 1 2 VREF - TRST_N 3 4 GND TRST_N 3 4 SRST_N - TDI 5 6 GND TDI 5 6 TDO - TMS 7 8 GND TMS 7 8 GND - TCK 9 10 GND TCK 9 10 GND - n.c. 11 12 GND - TDO 13 14 GND - SRST_N 15 16 GND - n.c. 17 18 GND - n.c. 19 20 GND -@endcode - -Create a simple board description file. I did it this way: - -@code -source [find interface/jtagkey-tiny.cfg] -source [find target/samsung_s3c2440.cfg] - -adapter_khz 12000 -@endcode - -And then the following steps: - - connect a terminal application to the mini2440's serial connector - - connect the mini2440 to a working network - - switch S2 to boot from NOR to boot into 'supervivi' - - switch on your mini2440 - - run the OpenOCD daemon configured with the file shown above - - connect to the OpenOCD daemon via 'telnet'. - - run the following commands to download @a barebox into your target -@code -> halt -> load_image \ 0x31000000 bin -> resume 0x31000000 -@endcode - -Now @a barebox is starting from an already initialized CPU and SDRAM (done by -'supervivi'). - -Change to your terminal console and configure the network first. Adapt the -following settings to your network: -@code -eth0.ipaddr=192.168.1.240 -eth0.netmask=255.255.255.0 -eth0.gateway=192.168.23.2 -eth0.serverip=192.168.1.7 -eth0.ethaddr=00:04:f3:00:06:35 -@endcode - -A 'ping' to your TFTP server should bring a "...is alive" message now. - -We are ready now to program @a barebox into the NAND flash: - -@code -erase /dev/nand0.barebox.bb -tftp barebox.bin /dev/nand0.barebox.bb -@endcode - -*/ diff --git a/arch/arm/boards/guf-cupid/cupid.dox b/arch/arm/boards/guf-cupid/cupid.dox deleted file mode 100644 index 45f0e0cc22..0000000000 --- a/arch/arm/boards/guf-cupid/cupid.dox +++ /dev/null @@ -1,9 +0,0 @@ -/** @page board_cupid Garz+Fricke Cupid - -This CPU card is based on a Freescale i.MX35 CPU. The card is shipped with: - -- 256MiB Nand flash -- 128MiB synchronous dynamic RAM - - -*/ diff --git a/arch/arm/boards/imx233-olinuxino/imx23-olinuxino.c b/arch/arm/boards/imx233-olinuxino/imx23-olinuxino.c index fae4d91469..fa95d72339 100644 --- a/arch/arm/boards/imx233-olinuxino/imx23-olinuxino.c +++ b/arch/arm/boards/imx233-olinuxino/imx23-olinuxino.c @@ -143,62 +143,3 @@ static int imx23_olinuxino_console_init(void) } console_initcall(imx23_olinuxino_console_init); - -/** @page olinuxino Olimex.ltd's i.MX23 evaluation kit - -This CPU card is based on an i.MX23 CPU. The card is shipped with: - -- 64 MiB synchronous dynamic RAM (mobile DDR type) - - -Memory layout when @b barebox is running: - -- 0x40000000 start of SDRAM -- 0x40000100 start of kernel's boot parameters - - below malloc area: stack area - - below barebox: malloc area -- 0x42000000 start of @b barebox - -@section get_imx23_olinuxino_binary How to get the bootloader binary image: - -Using the default configuration: - -@verbatim -make ARCH=arm imx23_olinuxino_defconfig -@endverbatim - -Build the bootloader binary image: - -@verbatim -make ARCH=arm CROSS_COMPILE=armv5compiler -@endverbatim - -@note replace the armv5compiler with your ARM v5 cross compiler. - -@section imx233-olinuxino How to prepare an MCI card to boot -the imx233-olinuxino with barebox - -- Create four primary partitions on the MCI card - - the first one for the bootlets (about 256 kiB) - - the second one for the persistant environment - (size is up to you, at least 256k) - - the third one for the kernel (2 MiB ... 4 MiB in size) - - the 4th one for the root filesystem which can fill the - rest of the available space - -- Mark the first partition with the partition ID "53" and copy the bootlets - into this partition (currently not part of @b barebox!). - -- @b barebox expect device tree blob file imx23-olinuxino.dtb - into directory env/oftree. At compile time, copy blob file into directory - arch/arm/boards/imx233-olinuxino/env/oftree/. - -- Copy the default @b barebox environment into the second partition - (no filesystem required). - -- Copy the kernel into the third partition (no filesystem required). - -- Create the root filesystem in the 4th partition. You may copy an - image into this partition or you can do it in the classic way: - mkfs on it, mount it and copy all required data and programs into it. -*/ diff --git a/arch/arm/boards/karo-tx28/tx28.c b/arch/arm/boards/karo-tx28/tx28.c index 3fb1fe9177..26dbc00790 100644 --- a/arch/arm/boards/karo-tx28/tx28.c +++ b/arch/arm/boards/karo-tx28/tx28.c @@ -99,55 +99,3 @@ static int tx28_devices_init(void) } device_initcall(tx28_devices_init); - -/** -@page tx28 KARO's TX28 CPU module - -@section tx28_cpu_card The CPU module - -http://www.karo-electronics.de/ - -This CPU card is based on a Freescale i.MX28 CPU. The card is shipped with: - -- 128 MiB synchronous dynamic RAM (DDR2 type), 200 MHz support -- 128 MiB NAND K9F1G08U0A (3.3V type) -- PCA9554 GPIO expander -- DS1339 RTC -- LAN8710 Phy - -@section tx28_basboards Supported baseboards - -Supported baseboards are: -- KARO's Starterkit 5 - -@section tx28_stk5_howto How to get barebox for 'KARO's Starterkit 5' - -Using the default configuration: - -@verbatim -make ARCH=arm tx28stk5_defconfig -@endverbatim - -Build the binary image: - -@verbatim -make ARCH=arm CROSS_COMPILE=armv5compiler -@endverbatim - -@note replace the armv5compiler with your ARM v5 cross compiler. - -@note To use the result, you also need the following resources from Freescale: -- the 'bootlets' archive -- the 'elftosb2' encryption tool -- in the case you want to start @b barebox from an attached SD card the - 'sdimage' tool from Freescale's 'uuc' archive. - -@section tx28_mlayout Memory layout when barebox is running: - -- 0x40000000 start of SDRAM -- 0x40000100 start of kernel's boot parameters - - below malloc area: stack area - - below barebox: malloc area -- 0x47000000 start of @b barebox - -*/ diff --git a/arch/arm/boards/karo-tx51/tx51.dox b/arch/arm/boards/karo-tx51/tx51.dox deleted file mode 100644 index 08268e0576..0000000000 --- a/arch/arm/boards/karo-tx51/tx51.dox +++ /dev/null @@ -1,50 +0,0 @@ -/** -@page tx51 KARO's TX51 CPU module - -@section tx51_cpu_card The CPU module - -http://www.karo-electronics.de/ - -This CPU card is based on a Freescale i.MX51 CPU. The card is shipped with: - -- 128 MiB synchronous dynamic RAM (DDR2 type), 200 MHz support -- 128 MiB NAND K9F1G08U0A (3.3V type) -- DS1339 RTC -- LAN8700 Phy - -@section tx51_baseboards Supported baseboards - -Supported baseboards are: -- KARO's Starterkit 5 (currently only SD1, FEC implemented but non-working) - -@section tx28_stk5_howto How to get barebox for 'KARO's Starterkit 5' - -Using the default configuration: - -@verbatim -make ARCH=arm tx51tk5_defconfig -@endverbatim - -Build the binary image: - -@verbatim -make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- -@endverbatim - -@note replace the arm-linux-gnueabi with your ARM v7 cross compiler. - -@note To use the result, you also need the following resources from Freescale: -- the 'bootlets' archive -- the 'elftosb2' encryption tool -- in the case you want to start @b barebox from an attached SD card the - 'sdimage' tool from Freescale's 'uuc' archive. - -@section tx28_mlayout Memory layout when barebox is running: - -- 0x90000000 start of SDRAM -- 0x90000100 start of kernel's boot parameters - - below malloc area: stack area - - below barebox: malloc area -- 0x97f00000 start of @b barebox - -*/ diff --git a/arch/arm/boards/module-mb7707/module-mb7707.dox b/arch/arm/boards/module-mb7707/module-mb7707.dox deleted file mode 100644 index c0dbc8a602..0000000000 --- a/arch/arm/boards/module-mb7707/module-mb7707.dox +++ /dev/null @@ -1,29 +0,0 @@ -/** @page module-mb7707 MB 77.07 board - -The board uses MBOOT as bootloader. - -Barebox mini-howto: - -1. Connect to the boards's UART (38400 8N1); - -2. Turn board's power on; - -3. Wait 'Hit any key (in 2 sec) to skip autoload...' prompt and press the space key; - -4. Compile zbarebox.bin image and upload it to the board via tftp -@verbatim - MBOOT # tftpboot zbarebox.bin - greth: greth_halt - TFTP Using GRETH_10/100 device - TFTP params: server 192.168.0.1 our_ip 192.168.0.7 - TFTP params: filename 'zbarebox.bin' load_address 0x40100000 - TFTP Loading: ################ - TFTP done -@endverbatim - -5. Run barebox -@verbatim - MBOOT # go 0x40100000 -@endverbatim - -*/ diff --git a/arch/arm/boards/mx31moboard/mx31moboard.dox b/arch/arm/boards/mx31moboard/mx31moboard.dox deleted file mode 100644 index 41c8bbb828..0000000000 --- a/arch/arm/boards/mx31moboard/mx31moboard.dox +++ /dev/null @@ -1,10 +0,0 @@ -/** @page mx31moboard EPFL mx31moboard - -This CPU card is based on a Freescale i.MX31 CPU. The card is shipped with: - -- 32MiB NOR type Flash Memory -- 128MiB LPDDR -- A least one SD slot -- A least one USB host (H2) - -*/ diff --git a/arch/arm/boards/netx/netx.dox b/arch/arm/boards/netx/netx.dox deleted file mode 100644 index e22c5e8554..0000000000 --- a/arch/arm/boards/netx/netx.dox +++ /dev/null @@ -1,9 +0,0 @@ -/** @page netx Hilscher's NetX card family - -This CPU card is based on a Hilscher's NetX ARM CPU. The card is shipped -in various incarnations: - -Specific to this CPU is, it does not require any setup code to bring the -SDRAM up and working. This is done in a pre bootloader. - -*/ \ No newline at end of file diff --git a/arch/arm/boards/omap343xdsp/board.c b/arch/arm/boards/omap343xdsp/board.c index 8329ace483..1b1cb79212 100644 --- a/arch/arm/boards/omap343xdsp/board.c +++ b/arch/arm/boards/omap343xdsp/board.c @@ -15,32 +15,6 @@ * */ -/** - * @file - * @brief SDP3430 Specific Board Initialization routines - */ - -/** - * @page ti_SDP3430 Texas Instruments SDP3430 - * - * SDP3430 from Texas Instruments as described here: - * http://www.ti.com/omap3430_devplatform - * This file provides initialization in two stages: - * @li boot time initialization - do basics required to get SDRAM working. - * This is run from SRAM - so no case constructs and global vars can be used. - * @li run time initialization - this is for the rest of the initializations - * such as flash, uart etc. - * - * Boot time initialization includes: - * @li SDRAM initialization. - * @li Pin Muxing relevant for SDP3430. - * - * Run time initialization includes - * @li serial @ref serial_ns16550.c driver device definition - * - * Originally from http://linux.omap.com/pub/bootloader/3430sdp/u-boot-v1.tar.gz - */ - #include #include #include diff --git a/arch/arm/boards/phytec-phycard-imx27/pca100.dox b/arch/arm/boards/phytec-phycard-imx27/pca100.dox deleted file mode 100644 index 9b17674a21..0000000000 --- a/arch/arm/boards/phytec-phycard-imx27/pca100.dox +++ /dev/null @@ -1,8 +0,0 @@ -/** @page pcm038 Phytec's phyCORE-i.MX27 - -This CPU card is based on a Freescale i.MX27 CPU. The card is shipped with: - -- up to 32MiB NOR type Flash Memory -- 32MiB synchronous dynamic RAM - -*/ diff --git a/arch/arm/boards/phytec-phycard-omap3/pca-a-l1.dox b/arch/arm/boards/phytec-phycard-omap3/pca-a-l1.dox deleted file mode 100644 index d93c57499b..0000000000 --- a/arch/arm/boards/phytec-phycard-omap3/pca-a-l1.dox +++ /dev/null @@ -1,16 +0,0 @@ -/** @page phycard-a-l1 Phytec's phyCARD-A-L1 (OMAP35xx) - -This phyCARD is based on a Texas Instruments OMAP35xx CPU. -The card is shipped with: - -- 256MiB DDR-RAM -- 256MiB NAND Flash Memory -- SMSC9221 ethernet controller -- USB-host interface -- USB-OTG interface -- LVDS camera interface -- LVDS display interface -- TPS65023 Power-Managmanet IC -- 4kB I2C EEPROM - -*/ diff --git a/arch/arm/boards/phytec-phycore-imx27/pcm038.dox b/arch/arm/boards/phytec-phycore-imx27/pcm038.dox deleted file mode 100644 index 85177d2eb1..0000000000 --- a/arch/arm/boards/phytec-phycore-imx27/pcm038.dox +++ /dev/null @@ -1,9 +0,0 @@ -/** @page pcm038 Phytec's phyCORE-i.MX27 - -This CPU card is based on a Freescale i.MX27 CPU. The card is shipped with: - -- up to 64MB NOR Flash Memory -- up to 1GB NAND Flash Memory -- up to 256MB DRAM - -*/ diff --git a/arch/arm/boards/phytec-phycore-imx31/pcm037.dox b/arch/arm/boards/phytec-phycore-imx31/pcm037.dox deleted file mode 100644 index b2afdd6acd..0000000000 --- a/arch/arm/boards/phytec-phycore-imx31/pcm037.dox +++ /dev/null @@ -1,11 +0,0 @@ -/** @page pcm037 Phytec's phyCORE-i.MX31 - -This CPU card is based on a Freescale i.MX31 CPU. The card is shipped with: - -- up to 64MiB NOR type Flash Memory -- up to 2MiB static RAM -- 64MiB NAND type Flash Memory -- SMSC 9217 network controller -- 128MiB synchronous dynamic RAM - -*/ diff --git a/arch/arm/boards/phytec-phycore-imx35/pcm043.dox b/arch/arm/boards/phytec-phycore-imx35/pcm043.dox deleted file mode 100644 index c6715fffcf..0000000000 --- a/arch/arm/boards/phytec-phycore-imx35/pcm043.dox +++ /dev/null @@ -1,28 +0,0 @@ -/** @page pcm043 Phytec's phyCORE-i.MX35 - -This CPU card is based on a Freescale i.MX35 CPU. The card is shipped with: - - -FIXME: -- up to 64 MiB NOR type Flash Memory -- up to 2 MiB static RAM -- 1 GiB or 2 GiB NAND type Flash Memory - - Micron NAND 1 GiB 3,3V 8-bit - - 256 kiB block size - - ? kiB page size - - Manufacturer ID: 0x2c - - Device ID: 0xd3 - - Samsung K9K8G08, 1 GiB - - 128 kiB block size - - 2 kiB page size - - Manufacturer ID: ? - - Device ID: ? - - ST NAND08G, 1 GiB - - 128 kiB block size - - 2 kiB page size - - Manufacturer ID: ? - - Device ID: ? -- 128MiB synchronous dynamic RAM - - -*/ diff --git a/arch/arm/boards/qil-a926x/qil-a9260.dox b/arch/arm/boards/qil-a926x/qil-a9260.dox deleted file mode 100644 index da5c197b34..0000000000 --- a/arch/arm/boards/qil-a926x/qil-a9260.dox +++ /dev/null @@ -1,22 +0,0 @@ -/** -@page qil-a9260 Calao-systems QIL-A9260 - -@section qil-a9260 The CPU module - -http://www.calao-systems.com - -This CPU module is based on an Atmel AT91SAM9260 CPU. The card is shipped with: - -- 64MiB or 128MiB SDRAM (3.3V) -- 256MiB NAND type Flash Memory (3.3V) -- 64Kib SPI EEPROM -- RMII 10/100 ethernet PHY -- Real Time Clock -- micro SD socket - -@section mob-qil-a9xxx Supported development board - -Supported development board is: -- MOB-QIL-A9xxx - -*/ diff --git a/arch/arm/boards/scb9328/scb9328.dox b/arch/arm/boards/scb9328/scb9328.dox deleted file mode 100644 index 75bc7c8c1a..0000000000 --- a/arch/arm/boards/scb9328/scb9328.dox +++ /dev/null @@ -1,9 +0,0 @@ -/** @page scb9328 Synertronixx's scb9328 - -This CPU card is based on a Freescale i.MX1 CPU. The card is shipped with: - -- up to 16MiB NOR type Flash Memory -- 16MiB synchronous dynamic RAM -- DM9000 network controller - -*/ diff --git a/arch/arm/boards/tny-a926x/tny-a9263.dox b/arch/arm/boards/tny-a926x/tny-a9263.dox deleted file mode 100644 index 68fcdd109c..0000000000 --- a/arch/arm/boards/tny-a926x/tny-a9263.dox +++ /dev/null @@ -1,33 +0,0 @@ -/** -@page tny-a9263 Calao-systems TNY-A9263 - -@section tny-a9263 The CPU module - -http://www.calao-systems.com - -This CPU module is based on an Atmel AT91SAM9263 CPU. The module is shipped with: - -- 64MiB SDRAM (3.3V) -- 256MiB NAND type Flash Memory (3.3V) -- USB device port -- Top expansion connector for daughter boards (GPS, WIFI/BT, GPRS, 3G, ZigBee, MBUS, ...) -- Bottom expansion connector for development boards - -@section mob-tny-a9xxx-md2 Supported development board - -Supported development board is: -- MOB-TNY-A9xxx-MD2 - -@section tny-db-boards Supported daughter boards - -Supported daughter boards are: -- DAB-GPI2-CXX -- DAB-GPS -- DAB-GPRS -- DAB-HSDPA -- DAB-WLAN-BT -- DAB-ZIGBEE -- DAB-MBUS -- DAB-KNX-RF - -*/ diff --git a/arch/arm/boards/tny-a926x/tny-a9g20-lpw.dox b/arch/arm/boards/tny-a926x/tny-a9g20-lpw.dox deleted file mode 100644 index e0021070b3..0000000000 --- a/arch/arm/boards/tny-a926x/tny-a9g20-lpw.dox +++ /dev/null @@ -1,37 +0,0 @@ -/** -@page tny-a9g20-lpw Calao-systems TNY-A9G20-LPW - -@section tny-a9g20-lpw The CPU module - -http://www.calao-systems.com - -This CPU module is based on an Atmel AT91SAM9G20 CPU. The module is shipped with: - -- 64MiB Low Power SDRAM (1.8V) -- 256MiB NAND type Flash Memory (1.8V) -- Real Time Clock (I2C) -- Micro SD socket -- USB device port -- JTAG connector -- Top expansion connector for daughter boards (GPS, WIFI/BT, GPRS, 3G, ZigBee, MBUS, ...) -- Bottom expansion connector for development boards - -@section mob-tny-a9xxx-md2 Supported development board - -Supported development board is: -- MOB-TNY-A9xxx-MD2 - -@section tny-db-boards Supported daughter boards - -Supported daughter boards are: -- DAB-GPI2-CXX -- DAB-GPS -- DAB-GPRS -- DAB-HSDPA -- DAB-WLAN-BT -- DAB-ZIGBEE -- DAB-MBUS -- DAB-KNX-RF - - -*/ diff --git a/arch/arm/boards/toshiba-ac100/toshiba-ac100.dox b/arch/arm/boards/toshiba-ac100/toshiba-ac100.dox deleted file mode 100644 index 7c50f3c1d9..0000000000 --- a/arch/arm/boards/toshiba-ac100/toshiba-ac100.dox +++ /dev/null @@ -1,37 +0,0 @@ -/** @page toshiba-ac100 Toshiba AC100 - -Toshiba AC100 is a Tegra2-based netbook. - -The netbook has -@li NVidia Tegra 250 SoC; -@li 512 MiB DDR2 RAM; -@li 8 GiB internal e-MMC Flash Memory (some models have 32 GiB); -@li RS232 serial interface (LV-TTL levels on the board!); -@li SD card slot; -@li 2xUSB interface (miniUSB-B and USB-A connectors); -@li 10" LCD display (1024x600); -@li HDMI-interface; -@li touchpad and keyboard connected via I2C; the ENE KB926QF keyboard controller is used; -@li web camera; -@li some models have 3G-modem. - -U-Boot master branch is working on AC100, but there's no support for the keyboard or the display. - -barebox-toshiba-ac100 mini-howto: - -1. Connect to the netbook's UART (see http://pecourt.ovh.org/wiki-tegra/doku.php?id=hardware); - -2. Start U-Boot loader. See http://ac100.grandou.net/uboot and http://ac100.grandou.net/swarren_brain_dump for details. - -3. If you use U-Boot with turned on display support, then switch to serial console: -@verbatim - Tegra2 (ac100) # setenv stdout serial -@endverbatim - -4. Upload barebox.bin via Ymodem and start it: -@verbatim - Tegra2 (ac100) # loady 0x01f00000 - Tegra2 (ac100) # go 0x01f00000 -@endverbatim - -*/ diff --git a/arch/arm/boards/usb-a926x/usb-a9263.dox b/arch/arm/boards/usb-a926x/usb-a9263.dox deleted file mode 100644 index 380a8e2d3d..0000000000 --- a/arch/arm/boards/usb-a926x/usb-a9263.dox +++ /dev/null @@ -1,30 +0,0 @@ -/** -@page usb-a9263 Calao-systems USB-A9263 - -@section usb-a9263 The CPU card - -http://www.calao-systems.com - -This CPU card is based on an Atmel AT91SAM9263 CPU. The card is shipped with: - -- 64MiB or 128MiB SDRAM (3.3V) -- 256MiB NAND type Flash Memory (3.3V) -- Ethernet 10/100M -- USB Host port 2.0 (FS) -- USB device port (FS) -- Top expansion connector for expansion boards (GPS, WIFI/BT, GPRS, 3G, ZigBee, MBUS, ...) -- Bottom expansion connector for development boards - -@section usb-db-boards Supported daughter boards - -Supported daughter boards are: -- DAB-GPI2-CXX -- DAB-GPS -- DAB-GPRS -- DAB-HSDPA -- DAB-WLAN-BT -- DAB-ZIGBEE -- DAB-MBUS -- DAB-KNX-RF - -*/ diff --git a/arch/arm/boards/usb-a926x/usb-a9g20-lpw.dox b/arch/arm/boards/usb-a926x/usb-a9g20-lpw.dox deleted file mode 100644 index 024a3cedda..0000000000 --- a/arch/arm/boards/usb-a926x/usb-a9g20-lpw.dox +++ /dev/null @@ -1,33 +0,0 @@ -/** -@page usb-a9g20-lpw Calao-systems USB-A9G20-LPW - -@section usb-a9g20-lpw The CPU card - -http://www.calao-systems.com - -This CPU card is based on an Atmel AT91SAM9G20 CPU. The card is shipped with: - -- 64MiB or 128MiB SDRAM (1.8V) -- 256MiB NAND type Flash Memory (1.8V) -- Ethernet 10/100M -- USB Host port 2.0 (FS) -- USB device port (FS) -- Micro SD socket -- JTAG connector -- RTC with battery backup -- Top expansion connector for daughter boards (GPS, WIFI/BT, GPRS, 3G, ZigBee, MBUS, ...) -- Bottom expansion connector for development boards - -@section usb-db-boards Supported daughter boards - -Supported daughter boards are: -- DAB-GPI2-CXX -- DAB-GPS -- DAB-GPRS -- DAB-HSDPA -- DAB-WLAN-BT -- DAB-ZIGBEE -- DAB-MBUS -- DAB-KNX-RF - -*/ diff --git a/arch/arm/boards/virt2real/virt2real.dox b/arch/arm/boards/virt2real/virt2real.dox deleted file mode 100644 index fc383216ec..0000000000 --- a/arch/arm/boards/virt2real/virt2real.dox +++ /dev/null @@ -1,41 +0,0 @@ -/** @page virt2real virt2real board - -virt2real is a is a miniature board for creation of WiFi -or internet controllable smart devices. - -The board has -@li TI DaVinchi DM365 running at 300 MHz -@li 128 MiB DDR2 SDRAM; -@li 256 MiB NAND Flash Memory; -@li 2 x UART serial interfaces; -@li 2 x Ethernet interfaces; -@li 1 x USB interface; -@li microSD card slot. - -The board uses U-Boot as bootloader. - -Barebox mini-howto: - -1. Connect to the boards's UART0 (115200 8N1); -Use J2.2 (GND), J2.4 (UART0_TXD), J2.6(UART0_RXD) pins. - -2. Turn board's power on; - -3. Wait 'Hit any key to stop autoboot' prompt and press the space key. - -4. Upload barebox.bin via Ymodem -@verbatim - virt2real ># loady -@endverbatim - -5. Run barebox -@verbatim - virt2real ># go 0x82000000 -@endverbatim - -virt2real links: -@li http://virt2real.com/ -@li http://wiki.virt2real.ru/ -@li https://github.com/virt2real - -*/ diff --git a/arch/arm/mach-arm.dox b/arch/arm/mach-arm.dox deleted file mode 100644 index 1d2de48df2..0000000000 --- a/arch/arm/mach-arm.dox +++ /dev/null @@ -1,67 +0,0 @@ -/* This document is intended to provide the developer with information - * how to integrate a new CPU (MACH) into this part of the barebox tree - */ - -/** @page dev_arm_mach ARM based CPU (MACH) into the tree - -FIXME - -@section mach_arm_reset What's happens when the reset signal is gone - -@note Code running immediately after reset runs at an address it is not linked - to: "runtime address != link address". You should only use branches and - do not refer to fixed data. This implies the use of assembler code only. - -The ARM CPU starts at lable \ in one of the corresponding start-*.S -files. After some basic hardware setup it can call a function -\ if not disabled. This call is intended to give all -developers a chance to use a standard reset vector file, but also do some -special things required only on their specific CPU. - -After handling some MMU related things \ can be called (if -not disabled). This is a board specific function for SDRAM setup for example. -As its board specific, your can do whatever you need to bring your board up. - -In the case the boot happens from NAND flash memory, further steps are required. -Most of the known processor devices are reading the first few blocks from the -NAND flash memory into some kind of internal SRAM. This small part must be able -to initialize the SDRAM controller and to read the remaining rest of the -barebox binary from the NAND flash memory prior returning from \. - -When \ returns it will be assumed there is now a working -RAM that can be used for all further steps. - -Next step is relocation of @a barebox itself (if not already done). It gets copied -to RAM and the last assembler instruction is a jump into start_barebox(). This -target address is the first C instruction in barebox. At this point of time:\n -"runtime address == link address". - -@section mach_arm_files List of changes - -Lets call the new MACH new_cpu. - - - create a new subdirectory in /arch/arm/mach-new_cpu - - create a new subdirectory in /arch/arm/mach-new_cpu/include - - add CPU specific definitions into /arch/arm/mach-new_cpu/include - - add /arch/arm/mach-new_cpu/Kconfig - - add /arch/arm/mach-new_cpu/Makfile - - add other CPU specific code into /arch/arm/mach-new_cpu/ - - modify /arch/arm/Kconfig - - modify /arch/arm/Makfile - -@section mach_arm_architecures Architectures using ARM processors -For details on specific architectures: - -@subsection mach_arm_omap_info OMAP CPUs - -@li @subpage dev_davinci_arch - -@li @subpage dev_omap_arch - -@subsection mach_arm_s3c24xx_info S3C24XX CPUs - -@li @subpage dev_s3c24xx_arch - -TODO add more details - -*/ diff --git a/arch/arm/mach-davinci/mach-davinci.dox b/arch/arm/mach-davinci/mach-davinci.dox deleted file mode 100644 index 789eacc42a..0000000000 --- a/arch/arm/mach-davinci/mach-davinci.dox +++ /dev/null @@ -1,7 +0,0 @@ -/** @page dev_davinci_arch TI DaVinci in barebox - -@section davinci_boards DaVinci-based boards - -@li @subpage virt2real - -*/ diff --git a/arch/arm/mach-omap/arch-omap.dox b/arch/arm/mach-omap/arch-omap.dox deleted file mode 100644 index 8c2b47d5a8..0000000000 --- a/arch/arm/mach-omap/arch-omap.dox +++ /dev/null @@ -1,96 +0,0 @@ -/* This document is intended to provide the developer with information - * how to integrate a new OMAP Architecture into this part of the barebox tree - */ - -/** @page dev_omap_arch Texas Instrument's OMAP Platforms in barebox - -This document highlights some of the factors for supporting Texas Instrument's OMAP platforms in @a barebox. - -@par Table of Contents -@li @ref omap_boards -@li @ref omap_code_arch -@li @ref mach_omap -@li @ref asm_arm -@li @ref board_omap -@li @ref omap_boot -@li @ref board_boot - -@section omap_boards Boards using OMAP processors - -@li @subpage ti_SDP3430 -@li @subpage ti_beagle - -@section omap_arch Documentation for OMAP Architectures files - -@li @subpage arch/arm/mach-omap/omap3_generic.c - -@section omap_code_arch How is barebox OMAP specific architecture code organized? - -To understand the architecture of @a barebox source code for OMAP processors, we need to understand a bit on OMAP itself. - -A typical Texas Instrument's Open Multimedia Application Processor (OMAP) solution is built around ARM core with multiple on-the-silicon peripherals. It also has a TI Digital Signal Processor(DSP) and few hardware accelerators to cater to computing intensive applications such as encoder/decoders. See http://focus.ti.com/general/docs/wtbu/wtbugencontent.tsp?templateId=6123&navigationId=11988&contentId=4638 for further details. - -Essentially, OMAP is modular with on-silicon peripherals being reused across multiple OMAP versions. @a Barebox code organization is driven by this fact. - -Motivation for code organization is driven from: -@li Clear distinction between architecture and board features. -@li Code should be re-usable accross OMAP variants AND board variants. - -Code is Organized into three main directories: -@li arch/arm/mach-omap -contains files for ALL peripherals which are present on board with very few exceptions. We will come to these exceptions in later sections. -@li include/asm-arm/arch-omap - contains files for ALL OMAP on-silicon peripherals. No Board specific files here please! -@li arch/arm/boards/omap - contains files for ALL boards using OMAP processors. - -@section mach_omap arch/arm/mach-omap directory guidelines -It is rather simple: All common peripherals should be isolated as separate driver libraries as far as possible. Exceptions such as clock configuration code may be isolated by the following naming convention: omapX_function_name.[cS], where X belongs to the OMAP variant. The exception is for devices who have existing code locations - potentially drivers/i2c/busses and the like. - -All basic devices you'd like to register should be put here with postcore_initcall from architecture files - -@section asm_arm include/asm-arm/arch-omap directory guidelines -All OMAP common headers are located here. Where we have to incorporate a OMAP variant specific header, add a omapX_function_name.h. -@warning Do not add board specific header files/information here. Put them in mach-omap. - -include/asm-arm/arch-omap/silicon.h contains includes for omapX-silicon.h which defines the base addresses for the peripherals on that platform. the usual convention is to use -@code -#define OMAP_SOMETHING_BASE -@endcode -to allow re-use. - -@section board_omap arch/arm/boards/omap directory guidelines -All Board specific files go here. In u-boot, we always had to use common config file which is shared by other drivers to get serial, ethernet baseaddress etc.. we can easily use the device_d structure to handle it with @a barebox. This is more like programming for Linux kernel - it is pretty easy. -Each specific board file has board-XYZ.c and potentially and equivalent h file. - -We'd potentially use device_initcall and console_initcalls as required. - -@section omap_boot The OMAP boot path -The normal flow is to look for arch_init_lowlevel in the required code. This would be the first function to be called after the ARM common code boots up(arch/arm/cpu/start-arm.S), the job of boot code on OMAP platform would be to preventing watchdog timer from kicking in and spoiling all the fun, setup OMAP clocks to the high performance mode, do other architecture specific initializations. There could be some additional stuff we may need to do based on the specific OMAP we support including setting up a usable interrupt vector table etc - some parts of the code may be desired to be in C code (to let normal humans understand without being an asm junkie), in such a case, @a barebox's stack setup is not ready yet, and we may need to setup a temporary SRAM based stack prior to execution. Some things to keep in mind while handling booting code, we might be executing in eXecute In Place (XIP) mode and that only an SRAM stack is setup. Using global variables or using constructs that create function jump tables is doomed to fail as the required area might not be writable or may not be even initialized. So code in this area tends to use lots of if conditions and local variables. Having C code doing the fun part is easy to maintain, so it is advisable to push as much as possible to C functions where possible. - -The responsibility of arch_init_lowlevel and related calls is to setup OMAP. No board specific initializations are to be done here. - -Once this is past, the code returns back to arm common code (cpu/start-arm.S). Here Instruction and Data caches are disabled. The execution proceeds to normal board initialization. - -@section board_boot The board boot path -Every Board in OMAP platform can potentially define a board_init and enable defconfig in arch/arm/configs directory. The responsibility here is to setup OMAP for board configurations - this includes SDRAM configuration and pin muxing configuration. - -Once this is complete, @a barebox boot process proceeds by calling init functions and finally entering shell prompt - -board-XYZ file may potentially register every device it is interested in. You can check out how the code is organized in other board directories also, esentially, the method is as simple as: -@code -static struct device_d my_little_device = { - .name = "driver_name", - .id = "some_unique_id", - .platform_data = &any_driver_specific_data, - .type = Type_of_device, - }; -static int my_board_devices_init(void) { - /* Do Blah Blah Blah */ - return platform_device_register(&my_little_device); -} - -device_initcall(my_board_devices_init); -@endcode - -You may probably be interested in calling console_initcall to get a console.. Modify arch/arm/boards/omap/Kconfig to add your OMAP board, create a defconfig, do a make C=2 to enable sparse warnings, you can potentially have a binary done in no time! if you remember to put doxygen comments in your code, you can do a make docs and get the documentation done too.. - - -*/ diff --git a/arch/arm/mach-samsung/lowlevel-s3c24x0.S b/arch/arm/mach-samsung/lowlevel-s3c24x0.S index e2efd86e8c..52079ffc7b 100644 --- a/arch/arm/mach-samsung/lowlevel-s3c24x0.S +++ b/arch/arm/mach-samsung/lowlevel-s3c24x0.S @@ -31,14 +31,6 @@ s3c24x0_disable_wd: str r1, [r0] mov pc, lr -/** -@page dev_s3c24xx_wd_handling Watchdog handling - -The watchdog must be disabled very early, because if it resets the system -it is still active and will continue to reset the system. So, call this -routine very early in your board_init_lowlevel routine. -*/ - /* * S3C2410 PLL configuration * ------------------------- diff --git a/arch/arm/mach-samsung/mem-s3c24x0.c b/arch/arm/mach-samsung/mem-s3c24x0.c index d40db14ff2..db61c63b64 100644 --- a/arch/arm/mach-samsung/mem-s3c24x0.c +++ b/arch/arm/mach-samsung/mem-s3c24x0.c @@ -80,60 +80,3 @@ void s3c24xx_disable_second_sdram_bank(void) writel(readl(S3C_BANKCON7) & ~(0x3 << 15), S3C_BANKCON7); writel(readl(S3C_MISCCR) | (1 << 18), S3C_MISCCR); /* disable its clock */ } - -/** - -@page dev_s3c24xx_arch Samsung's S3C24xx Platforms in barebox - -@section s3c24xx_boards Boards using S3C24xx Processors - -@li @subpage arch/arm/boards/a9m2410/a9m2410.c -@li @subpage arch/arm/boards/a9m2440/a9m2440.c - -@section s3c24xx_arch Documentation for S3C24xx Architectures Files - -@li @subpage arch/arm/mach-s3c24xx/generic.c - -@section s3c24xx_mem_map SDRAM Memory Map - -SDRAM starts at address 0x3000.0000 up to the available amount of connected -SDRAM memory. Physically this CPU can handle up to 256MiB (two areas with -up to 128MiB each). - -@subsection s3c24xx_mem_generic_map Generic Map -- 0x0000.0000 Start of the internal SRAM when booting from NAND flash memory or CS signal to a NOR flash memory. -- 0x0800.0000 Start of I/O space. -- 0x3000.0000 Start of SDRAM area. - - 0x3000.0100 Start of the TAG list area. - - 0x3000.8000 Start of the linux kernel (physical address). -- 0x4000.0000 Start of internal SRAM, when booting from NOR flash memory -- 0x4800.0000 Start of the internal I/O area - -@section s3c24xx_asm_arm include/asm-arm/arch-s3c24xx directory guidelines -All S3C24xx common headers are located here. - -@note Do not add board specific header files/information here. -*/ - -/** @page dev_s3c24xx_mach Samsung's S3C24xx based platforms - -@par barebox Map - -The location of the @a barebox itself depends on the available amount of -installed SDRAM memory: - -- 0x30fc.0000 Start of @a barebox when 16MiB SDRAM is available -- 0x31fc.0000 Start of @a barebox when 32MiB SDRAM is available -- 0x33fc.0000 Start of @a barebox when 64MiB SDRAM is available - -Adjust the @p CONFIG_TEXT_BASE/CONFIG_ARCH_TEXT_BASE symbol in accordance to -the available memory. - -@note The RAM based filesystem and the stack resides always below the -@a barebox start address. - -@li @subpage dev_s3c24xx_wd_handling -@li @subpage dev_s3c24xx_pll_handling -@li @subpage dev_s3c24xx_sdram_handling -@li @subpage dev_s3c24xx_nandboot_handling -*/ diff --git a/arch/blackfin/boards/ipe337/ipe337.dox b/arch/blackfin/boards/ipe337/ipe337.dox deleted file mode 100644 index 4d7925af94..0000000000 --- a/arch/blackfin/boards/ipe337/ipe337.dox +++ /dev/null @@ -1,10 +0,0 @@ -/** @page ipe337 ipe337 - -This CPU card is based on an Analog Device Blackfin CPU. The card is shipped -with: - -- 32MiB NOR type Flash Memory -- 128MiB synchronous dynamic RAM -- SMSC9xxx network controller - -*/ \ No newline at end of file diff --git a/arch/blackfin/mach-bf.dox b/arch/blackfin/mach-bf.dox deleted file mode 100644 index 4b3a3c12ea..0000000000 --- a/arch/blackfin/mach-bf.dox +++ /dev/null @@ -1,9 +0,0 @@ -/* This document is intended to provide the developer with information - * how to integrate a new CPU (MACH) into this part of the barebox tree - */ - -/** @page dev_bf_mach Blackfin based CPU (MACH) into the tree - -FIXME - -*/ diff --git a/arch/mips/boards/dlink-dir-320/dlink-dir-320.dox b/arch/mips/boards/dlink-dir-320/dlink-dir-320.dox deleted file mode 100644 index d0f5869340..0000000000 --- a/arch/mips/boards/dlink-dir-320/dlink-dir-320.dox +++ /dev/null @@ -1,38 +0,0 @@ -/** @page dlink_dir_320 D-Link DIR-320 wireless router - -The router has -@li BCM5354 SoC; -@li 32 MiB SDRAM; -@li 4 MiB NOR type Flash Memory; -@li RS232 serial interface (LV-TTL levels on board!); -@li 1xUSB interface; -@li 4 + 1 ethernet interfaces; -@li 802.11b/g (WiFi) interface; -@li JTAG interface; -@li 5 LEDs; -@li 2 buttons. - -The router uses CFE as firmware. - -Barebox can be started from CFE using tftp. -You must setup tftp-server on host 192.168.0.1. -Put your barebox.bin to tftp-server directory -(usual /tftpboot or /srv/tftp). -Connect your DIR-320 to your tftp-server network via -one of four sockets. - -Next, setup network on DIR-320 and run barebox.bin, e.g.: -@verbatim -CFE> ifconfig eth0 -addr=192.168.0.99 -CFE> boot -tftp -addr=a0800000 -raw 192.168.0.1:barebox.bin -@endverbatim - -DIR-320 links: -@li http://www.dlink.com.au/products/?pid=768 -@li http://wiki.openwrt.org/toh/d-link/dir-320 - -CFE links: -@li http://www.broadcom.com/support/communications_processors/downloads.php#cfe -@li http://www.linux-mips.org/wiki/CFE - -*/ diff --git a/arch/mips/boards/loongson-ls1b/loongson_ls1b.dox b/arch/mips/boards/loongson-ls1b/loongson_ls1b.dox deleted file mode 100644 index f96a3f88d1..0000000000 --- a/arch/mips/boards/loongson-ls1b/loongson_ls1b.dox +++ /dev/null @@ -1,47 +0,0 @@ -/** @page loongson_ls1b Loongson LS1B demo board - -The LS1B is a development board made by Loongson Technology Corp. Ltd. - -The board has -@li Loongson LS1B SoC 250 MHz; -@li 64 MiB SDRAM; -@li 512 KiB SPI boot ROM; -@li 128M x 8 Bit NAND Flash Memory; -@li 2 x RS232 serial interfaces (DB9 connectors); -@li 2 x Ethernet interfaces; -@li 4 x USB interfaces; -@li microSD card slot; -@li LCD display (480x272); -@li audio controller; -@li beeper; -@li buttons; -@li EJTAG 10-pin connector. - -The board uses PMON2000 as bootloader. - -Barebox mini-howto: - -1. Connect to the boards's UART2; - -2. Turn board's power on; - -3. Wait 'Press to execute loading image' prompt and press the space key. - -4. Upload zbarebox.bin via Ymodem -@verbatim - PMON> ymodem base=0xa0200000 -@endverbatim - -5. Run barebox -@verbatim - PMON> g -e 0xa0200000 -@endverbatim - -Loongson links: -@li http://en.wikipedia.org/wiki/Loongson -@li http://www.linux-mips.org/wiki/Loongson -@li https://github.com/loongson-gz -@li http://www.linux-mips.org/wiki/PMON_2000 -@li http://www.opsycon.se/PMON2000/Main - -*/ diff --git a/arch/mips/boards/qemu-malta/qemu-malta.dox b/arch/mips/boards/qemu-malta/qemu-malta.dox deleted file mode 100644 index bf10244585..0000000000 --- a/arch/mips/boards/qemu-malta/qemu-malta.dox +++ /dev/null @@ -1,20 +0,0 @@ -/** @page qemu_malta QEmu malta emulated board - -Specific to this emulated board is, it does not require any setup code to bring the SDRAM and RS232 up. - -Emulator run string: -@verbatim -qemu-system-mips -nodefaults -M malta -m 256 -nographic -serial stdio -monitor null -bios barebox-flash-image -@endverbatim - -Also you can use GXemul: -@verbatim -gxemul -Q -x -e maltabe -M 256 0xbfc00000:barebox-flash-image -@endverbatim - -Links: -@li http://www.linux-mips.org/wiki/Mips_Malta -@li http://www.qemu.org/ -@li http://gxemul.sourceforge.net/ - -*/ diff --git a/arch/mips/boards/ritmix-rzx50/ritmix-rzx50.dox b/arch/mips/boards/ritmix-rzx50/ritmix-rzx50.dox deleted file mode 100644 index 5ec819462b..0000000000 --- a/arch/mips/boards/ritmix-rzx50/ritmix-rzx50.dox +++ /dev/null @@ -1,46 +0,0 @@ -/** @page ritmix-rzx50 Ritmix RZX-50 game console - -Ritmix RZX-50 is a portable game console for the Russian market. - -The portable game console has -@li Ingenic JZ4755 SoC; -@li 64 MiB SDRAM; -@li 4 GiB microSDHC card / 4 GiB NAND type Flash Memory; -@li RS232 serial interface (LV-TTL levels on the board!); -@li LCD display (480x272); -@li Video out interface; -@li 1xUSB interface; -@li buttons. - -The game console uses U-Boot 1.1.6 as bootloader. - -barebox-rzx50 mini-howto: - -1. Connect to the game console's UART (see. http://a320.emulate.su/2012/01/19/uart-na-ritmix-rzx-50/); - -2. Unblock U-Boot console (see. http://a320.emulate.su/2012/01/25/rzx-50-dostup-k-konsoli-u-boot/); Please note that U-Boot's Zmodem support does not work; - -3. Boot Ritmix linux and login; - -4. Upload barebox.bin via Zmodem -@verbatim - # cd /tmp - # rz -@endverbatim - -5. Write barebox to onboard flash -@verbatim - # dd if=barebox.bin of=/dev/mmcblk0 seek=1048576 bs=1 count=262144 -@endverbatim - -6. Reboot RZX-50, next in U-Boot console start barebox: -@verbatim - CETUS # msc read 0xa0800000 0x100000 0x40000; g a0800000 -@endverbatim - -Ritmix RZX-50 links: -@li http://www.ritmixrussia.ru/products/252/entertainment/game/rzx-50 -@li ftp://ftp.ingenic.cn/2soc/4755/JZ4755_ds.pdf -@li ftp://ftp.ingenic.cn/3sw/01linux/01loader/u-boot/u-boot-1.1.6-jz-20110719-r1728-add-jz4770.patch.bz2 - -*/ diff --git a/arch/mips/boards/tplink-mr3020/tplink-mr3020.dox b/arch/mips/boards/tplink-mr3020/tplink-mr3020.dox deleted file mode 100644 index 16fe4653d8..0000000000 --- a/arch/mips/boards/tplink-mr3020/tplink-mr3020.dox +++ /dev/null @@ -1,64 +0,0 @@ -/** @page tplink-mr3020 TP-LINK MR3020 wireless router - -The router has -@li Atheros ar9331 SoC; -@li 32 MiB SDRAM; -@li 4 MiB NOR type SPI Flash Memory; -@li RS232 serial interface (LV-TTL levels on board!); -@li 1 USB interface; -@li 1 Ethernet interfaces; -@li 802.11b/g/n (WiFi) interface; -@li LEDs & buttons. - -The router uses U-Boot 1.1.4 as firmware. - -Barebox can be started from U-Boot using tftp. -But you have to encode barebox image in a very special way. - -First obtain 'lzma' and 'mktplinkfw' utilities. - -The 'lzma' utility can be obtained in Debian/Ubuntu -distro by installing lzma package. - -The 'mktplinkfw' utility can be obtained from openwrt, e.g.: - -@verbatim -$ OWRTPREF=https://raw.githubusercontent.com/mirrors/openwrt/master -$ curl -OL $OWRTPREF/tools/firmware-utils/src/mktplinkfw.c \ - -OL $OWRTPREF/tools/firmware-utils/src/md5.c \ - -OL $OWRTPREF/tools/firmware-utils/src/md5.h -$ cc -o mktplinkfw mktplinkfw.c md5.c -@endverbatim - -To convert your barebox.bin to U-Boot-loadable image (6F01A8C0.img) -use this command sequence: - -@verbatim -$ lzma -c -k barebox.bin > barebox.lzma -$ ./FW/mktplinkfw -c -H 0x07200103 -W 1 -N TL-WR720N-v3 \ - -s -F 4Mlzma -k barebox.lzma -o 6F01A8C0.img -@endverbatim - -You must setup tftp-server on host 192.168.0.1. -Put your 6F01A8C0.img to tftp-server directory -(usual /tftpboot or /srv/tftp). -Connect your board to your tftp-server network via Ethernet. - -Next, setup network on MR3020 and run 6F01A8C0.img, e.g.: -@verbatim -hornet> set ipaddr 192.168.0.2 -hornet> set serverip 192.168.0.1 -hornet> tftpboot 0x81000000 6F01A8C0.img -hornet> bootm 0x81000000 -@endverbatim - -TP-LINK MR3020 links: -@li http://www.tp-link.com/en/products/details/?model=TL-MR3020 -@li http://wiki.openwrt.org/toh/tp-link/tl-mr3020 -@li https://wikidevi.com/wiki/TP-LINK_TL-MR3020 - -See also: -@li http://www.eeboard.com/wp-content/uploads/downloads/2013/08/AR9331.pdf -@li http://squonk42.github.io/TL-WR703N/ - -*/ diff --git a/arch/mips/mach-bcm47xx/mach-bcm47xx.dox b/arch/mips/mach-bcm47xx/mach-bcm47xx.dox deleted file mode 100644 index 04ccf03fcb..0000000000 --- a/arch/mips/mach-bcm47xx/mach-bcm47xx.dox +++ /dev/null @@ -1,7 +0,0 @@ -/** @page dev_bcm47xx_mach BCM47xx in barebox - -@section bcm47xx_boards BCM47xx-based boards - -@li @subpage dlink_dir_320 - -*/ diff --git a/arch/mips/mach-loongson/mach-loongson.dox b/arch/mips/mach-loongson/mach-loongson.dox deleted file mode 100644 index 7838ce5a85..0000000000 --- a/arch/mips/mach-loongson/mach-loongson.dox +++ /dev/null @@ -1,7 +0,0 @@ -/** @page dev_loongson_mach Loongson in barebox - -@section loongson_boards Loongson-based boards - -@li @subpage loongson_ls1b - -*/ diff --git a/arch/mips/mach-malta/mach-malta.dox b/arch/mips/mach-malta/mach-malta.dox deleted file mode 100644 index 85351e10b7..0000000000 --- a/arch/mips/mach-malta/mach-malta.dox +++ /dev/null @@ -1,7 +0,0 @@ -/** @page dev_malta_mach MIPS Malta in barebox - -@section malta_boards MIPS Malta boards - -@li @subpage qemu_malta - -*/ diff --git a/arch/mips/mach-mips.dox b/arch/mips/mach-mips.dox deleted file mode 100644 index 1002b16e9e..0000000000 --- a/arch/mips/mach-mips.dox +++ /dev/null @@ -1,69 +0,0 @@ -/* This document is intended to provide the developer with information - * how to integrate a new CPU (MACH) into this part of the barebox tree - */ - -/** @page dev_mips_mach MIPS based CPU (MACH) into the tree - -@section mach_mips_reset What's happens when the reset signal is gone - -Barebox normally must be linked to RAM region, cached region KSEG0 is preferred. -This make possible to run fast (because cache used) and skip MMU support. - -After reset MIPS CPU starting to fetch instructions from 0xBFC00000. - -@note Code running immediately after reset runs at an address it is not linked - to: "runtime address != link address". You should only use branches and - do not refer to fixed data. This implies the use of assembler code only. - After MIPS CPU reset cache and MMU are in random state. They are unusable. - -barebox MIPS initialisation sequence: - - * set the CP0 STATUS register to some known and sensible state. -Now you can load and store reliably in uncached space. - - * call a function \ (if not disabled). -do some special things required only on specific CPU - (e. g. init RAM controller, disable watchdog) - - * call a function \ (if not disable). -do some special things required only on specific board - (e. g. setup GPIO to required state). - - ** It is desirable to have some debug code to make some contact - with the outside world from assembler code -(e.g. debug_ll-like functions to write to rs232 console). - - * check integrity of barebox RAM execute location; - * copy barebox to RAM execute location; - - * configure cache; - - * setup stack; - - ** after this point you can call a standard C routine. - - * setup exception vectors in RAM; - * setup CP0 STATUS to switch exception vector address to RAM; - - * call start_barebox() - -Further reading: - * Dominic Sweetman, See MIPS Run, Morgan Kaufmann, 2nd edition, 2006 -ISBN-13: 978-0120884216 - -@subsection mach_mips_malta_info Malta boards - -@li @subpage dev_malta_mach - -@subsection mach_bcm47xx_info BCM47xx-based boards - -@li @subpage dev_bcm47xx_mach - -@subsection mach_loongson_info Loongson-based boards - -@li @subpage dev_loongson_mach - -@subsection mach_xburst_info XBurst-based boards - -@li @subpage dev_xburst_mach -*/ diff --git a/arch/mips/mach-xburst/mach-xburst.dox b/arch/mips/mach-xburst/mach-xburst.dox deleted file mode 100644 index 052c05e7ae..0000000000 --- a/arch/mips/mach-xburst/mach-xburst.dox +++ /dev/null @@ -1,7 +0,0 @@ -/** @page dev_xburst_mach XBurst in barebox - -@section xburst_boards XBurst-based boards - -@li @subpage ritmix-rzx50 - -*/ diff --git a/arch/ppc/boards/pcm030/pcm030.dox b/arch/ppc/boards/pcm030/pcm030.dox deleted file mode 100644 index b9ada839f2..0000000000 --- a/arch/ppc/boards/pcm030/pcm030.dox +++ /dev/null @@ -1,8 +0,0 @@ -/** @page pcm030 Phytec's phyCORE-MPC5200B-tiny - -This CPU card is based on a Freescale MPC5200B CPU. The card is shipped with: - -- up to 16MiB NOR type Flash Memory -- 64MiB synchronous dynamic RAM - -*/ diff --git a/arch/ppc/mach-ppc.dox b/arch/ppc/mach-ppc.dox deleted file mode 100644 index f7191b9988..0000000000 --- a/arch/ppc/mach-ppc.dox +++ /dev/null @@ -1,9 +0,0 @@ -/* This document is intended to provide the developer with information - * how to integrate a new CPU (MACH) into this part of the barebox tree - */ - -/** @page dev_ppc_mach PowerPC based CPU into the tree - -FIXME - -*/ diff --git a/arch/sandbox/os/common.c b/arch/sandbox/os/common.c index 36c8d622b6..412393811e 100644 --- a/arch/sandbox/os/common.c +++ b/arch/sandbox/os/common.c @@ -18,10 +18,6 @@ * */ -/** - * @file - * @brief Common wrapper functions between barebox and the host - */ /* * These are host includes. Never include any barebox header * files here... @@ -421,54 +417,3 @@ static void print_usage(const char *prgname) prgname ); } - -/** - * @page barebox_simul barebox Simulator - * - * barebox can be run as a simulator on your host to check and debug new non - * hardware related features. - * - * @section simu_build How to build barebox for simulation - * - * @section simu_run How to run barebox simulator - * - * $ barebox [\] - * - * Options can be: - * - * -m, --malloc=\ - * - * Start sandbox with a specified malloc-space \ in bytes. - * - * -i \ - * - * Map a \ to barebox. This option can be given multiple times. The \s - * will show up as /dev/fd0 ... /dev/fdx in the barebox simulator. - * - * -e \ - * - * Map \ to barebox. With this option \s are mapped as /dev/env0 ... - * /dev/envx and thus are used as default environment. A clean file generated - * with dd will do to get started with an empty environment - * - * -O \ - * - * Register \ as a console capable of doing stdout. \ can be a - * regular file or a fifo. - * - * -I \ - * - * Register \ as a console capable of doing stdin. \ can be a regular - * file or a fifo. - * - * -x, --xres \ - * - * Specify SDL width - * - * -y, --yres \ - * - * Specify SDL height - * - * @section simu_dbg How to debug barebox simulator - * - */ diff --git a/arch/x86/boards/x86_generic/generic_pc.c b/arch/x86/boards/x86_generic/generic_pc.c index 5560efc889..482889f2d9 100644 --- a/arch/x86/boards/x86_generic/generic_pc.c +++ b/arch/x86/boards/x86_generic/generic_pc.c @@ -14,11 +14,6 @@ * */ -/** - * @file - * @brief Generic PC support to let barebox acting as a boot loader - */ - #include #include #include @@ -34,32 +29,3 @@ static int devices_init(void) return 0; } device_initcall(devices_init); - -/** @page generic_pc Generic PC based bootloader - -This platform acts as a generic PC based bootloader. It depends on at least -one boot media that is connected locally (no network boot) and can be -handled by the regular BIOS (any kind of hard disks for example). - -The created @a barebox image can be used to boot a standard x86 bzImage -Linux kernel. - -Refer section @ref x86_bootloader_preparations how to do so. - -How to get the binary image: - -Using the default configuration: - -@code -make ARCH=x86 generic_defconfig -@endcode - -Build the binary image: - -@code -make ARCH=x86 CROSS_COMPILE=x86compiler -@endcode - -@note replace the 'x86compiler' with your x86 (cross) compiler. - -*/ diff --git a/arch/x86/boot/bioscall.S b/arch/x86/boot/bioscall.S index 84d2577eb6..e60072992b 100644 --- a/arch/x86/boot/bioscall.S +++ b/arch/x86/boot/bioscall.S @@ -13,8 +13,6 @@ * touching registers they shouldn't be. */ -#ifndef DOXYGEN_SHOULD_SKIP_THIS - .file "bioscall.S" .code16 .section .boot.text.intcall, "ax" @@ -95,5 +93,3 @@ die: hlt jmp die .size die, .-die - -#endif /* DOXYGEN_SHOULD_SKIP_THIS */ diff --git a/arch/x86/lib/bios_disk.S b/arch/x86/lib/bios_disk.S index 121f440be5..cce33e67af 100644 --- a/arch/x86/lib/bios_disk.S +++ b/arch/x86/lib/bios_disk.S @@ -26,7 +26,6 @@ * space below 0x10000 */ -#ifndef DOXYGEN_SHOULD_SKIP_THIS /* * int bios_disk_rw_int13_extensions (int ah, int drive, void *dap) * @@ -69,5 +68,3 @@ bios_disk_rw_int13_extensions: popl %ebp ret - -#endif diff --git a/arch/x86/lib/linux_start.S b/arch/x86/lib/linux_start.S index f74e4e9c47..b9489b8e50 100644 --- a/arch/x86/lib/linux_start.S +++ b/arch/x86/lib/linux_start.S @@ -30,7 +30,6 @@ * void bios_start_linux(unsigned segment) * */ -#ifndef DOXYGEN_SHOULD_SKIP_THIS .section .boot.text.bios_start_linux, "ax" .code32 @@ -67,5 +66,3 @@ setup_seg: .word 0 .code32 - -#endif diff --git a/arch/x86/mach-x86.dox b/arch/x86/mach-x86.dox deleted file mode 100644 index 661e905bac..0000000000 --- a/arch/x86/mach-x86.dox +++ /dev/null @@ -1,128 +0,0 @@ -/* This document is intended to provide the developer with information - * how to integrate a new CPU (MACH) into this part of the barebox tree - */ - -/** @page dev_x86_mach barebox on x86 at runtime - -@section mach_x86_memory_layout barebox's memory layout (BIOS based) - -@a barebox uses the following memory layout at runtime when it still depends -on some kind of BIOS function: - -@verbatim - Addresses ------------------------- - - seg:off flat - -xxxx:xxxx 0x01xxxxxx end of barebox's malloc area - . . -xxxx:xxxx 0x01000000 start of barebox's malloc area - . . - . . (used while loading a Linux kernel of type 'bzImage') - . . -xxxx:xxxx 0x00100000 start of extended memory and malloc area - . . - . . (the big hole) - . . -9000:ffff 0x0009ffff end of expected real mode memory - . . - . . (used while loading a Linux kernel of type 'bzImage') - . . -9000:0000 0x00090000 end of used lower real mode memory - . . - . . - . . Flat mode stack (about 32 kiB) - . . bss - . . Data - . . Text -0000:7e00 0x00007e00 Real and flat mode barebox code -0000:7c00 0x00007c00 MBR initial boot loader code -0000:7a00 0x00007a00 location of the indirect sector (while booting only) - below: real mode stack -@endverbatim - -@note The start address of 0x0000:7c000 is a fixed one, defined by the BIOS. -So, for a BIOS based @a barebox this address can't be changed. - -While the @a barebox code is runnung in flat mode, all interrupts are disabled. -But in the CPU only. All other interrupt settings are still valid. This is -required to be able to call real mode code from inside @a barebox flat mode -code. Thats why not the PIC is touched nor the IDT. - -@todo Add some notes about drive numbers used by the BIOS. They may change -if one change orders in the BIOS setup. Drive orders and numbers may be -different at BIOS runtime and Linux runtime! But these numbers are required -at BIOS runtime for booting and the persistant environment storage. - -@attention Currently there is a 4 GiB limit for the disk sizes! - -@section mach_x86_image_layout barebox's image layout - -@a barebox's binary image layout - -@verbatim - Offset Content - - 0x????? - . 32 bit barebox code - . - . 16 bit bootstrap code, BIOS calling code - 0x00400 - 0x003ff - . indirect sector - 0x00200 - 0x001ff - . MBR - 0x00000 -@endverbatim - -The "indirect sector" is a free area in the image where the sector information -gets stored when this image will be written to a boot media. This information -is required to load all parts of the image from the boot media at runtime. - -The image gets installed in two ways onto the boot media, depending on the -need for a persistant storage. - -@subsection mach_x86_drive_layout_wops barebox's boot media layout without persistant storage - -In this case @a barebox's persistant storage is anywhere: - -@verbatim - Sector Content ---------------------------- - X start of first partition - . - ? end of the binary image - . 32 bit barebox code - 2 16 bit bootstrap code, BIOS calling code - 1 indirect sector - 0 MBR, Partition table, boot code -@endverbatim - -@subsection mach_x86_drive_layout_wps barebox's boot media layout with persistant storage - -@a barebox's persistant storage is part of the boot media (more -space required in front of the first partition) and interferes with the -boot loader image itself: - -@verbatim - Sector Content ---------------------------- - X start of first partition - . - n+? end of the binary image - . 32 bit barebox code - n+2 16 bit bootstrap code, BIOS calling code - n+1 indirect sector - n end of persistant environment storage - . - 1 start of persistant environment storage - 0 MBR, Partition table, boot code -@endverbatim - -The information where the persistant storage is located is also stored into -the MBR at specific locations by @p setupmbr. The @a barebox runtime will use -it to load and store all environment relevant data. - -*/ diff --git a/commands/bootm.c b/commands/bootm.c index d6625df460..617acd6169 100644 --- a/commands/bootm.c +++ b/commands/bootm.c @@ -194,20 +194,3 @@ static int binfmt_uimage_init(void) return binfmt_register(&binfmt_uimage_hook); } fs_initcall(binfmt_uimage_init); - -/** - * @file - * @brief Boot support for Linux - */ - -/** - * @page boot_preparation Preparing for Boot - * - * This chapter describes what's to be done to forward the control from - * barebox to Linux. This part describes the generic part, below you can find - * the architecture specific part. - * - * - @subpage arm_boot_preparation - * - @subpage ppc_boot_preparation - * - @subpage x86_boot_preparation - */ diff --git a/commands/cp.c b/commands/cp.c index 8ecde9101f..1a5675405e 100644 --- a/commands/cp.c +++ b/commands/cp.c @@ -17,10 +17,6 @@ * */ -/** - * @file - * @brief cp: copy file command - */ #include #include #include @@ -95,15 +91,6 @@ BAREBOX_CMD_HELP_TEXT("Options:") BAREBOX_CMD_HELP_OPT ("-v", "verbose") BAREBOX_CMD_HELP_END -/** - * @page cp_command -This command operates on files. - -If you want to copy between memory blocks, use 'memcpy'. - -\todo What does this mean? Add examples. - */ - BAREBOX_CMD_START(cp) .cmd = do_cp, BAREBOX_CMD_DESC("copy files") @@ -111,4 +98,3 @@ BAREBOX_CMD_START(cp) BAREBOX_CMD_GROUP(CMD_GRP_FILE) BAREBOX_CMD_HELP(cmd_cp_help) BAREBOX_CMD_END - diff --git a/commands/devinfo.c b/commands/devinfo.c index 052a4a017b..e61aaa24e8 100644 --- a/commands/devinfo.c +++ b/commands/devinfo.c @@ -118,34 +118,6 @@ static int do_devinfo(int argc, char *argv[]) return 0; } - -/** - * @page devinfo_command - -If called without arguments, devinfo shows a summary of the known -devices and drivers. - -If called with a device path being the argument, devinfo shows more -default information about this device and its parameters. - -Example from an MPC5200 based system: - -@verbatim - barebox:/ devinfo /dev/eth0 - base : 0x1002b000 - size : 0x00000000 - driver: fec_mpc5xxx - - no info available for eth0 - Parameters: - ipaddr = 192.168.23.197 - ethaddr = 80:81:82:83:84:86 - gateway = 192.168.23.1 - netmask = 255.255.255.0 - serverip = 192.168.23.2 -@endverbatim - */ - BAREBOX_CMD_HELP_START(devinfo) BAREBOX_CMD_HELP_TEXT("If called without arguments, devinfo shows a summary of the known") BAREBOX_CMD_HELP_TEXT("devices.") diff --git a/commands/dfu.c b/commands/dfu.c index b71cc16d26..354625260d 100644 --- a/commands/dfu.c +++ b/commands/dfu.c @@ -186,16 +186,6 @@ BAREBOX_CMD_HELP_OPT ("-V ID", "vendor id") BAREBOX_CMD_HELP_OPT ("-P ID", "product id") BAREBOX_CMD_HELP_END -/** - * @page dfu_command -\ has the following form: -device1(name1)[sr],device2(name2)[sr] -'s' means 'safe mode' (download the complete image before flashing) and -'r' that readback of the firmware is allowed. - -\todo Add example, how to use dfu from a Linux or Windows host. - */ - BAREBOX_CMD_START(dfu) .cmd = do_dfu, BAREBOX_CMD_DESC("device firmware update") diff --git a/commands/echo.c b/commands/echo.c index 9b3e21e4b1..7d47ab7ca7 100644 --- a/commands/echo.c +++ b/commands/echo.c @@ -113,13 +113,6 @@ BAREBOX_CMD_HELP_OPT ("-a FILE", "append to FILE instead of using stdout") BAREBOX_CMD_HELP_OPT ("-o FILE", "overwrite FILE instead of using stdout") BAREBOX_CMD_HELP_END -/** - * @page echo_command - -\todo Add documentation for -a, -o and -e. - - */ - BAREBOX_CMD_START(echo) .cmd = do_echo, BAREBOX_CMD_DESC("echo args to console") @@ -127,4 +120,3 @@ BAREBOX_CMD_START(echo) BAREBOX_CMD_GROUP(CMD_GRP_CONSOLE) BAREBOX_CMD_HELP(cmd_echo_help) BAREBOX_CMD_END - diff --git a/commands/edit.c b/commands/edit.c index f6b9d406e0..5a2da7d034 100644 --- a/commands/edit.c +++ b/commands/edit.c @@ -15,11 +15,6 @@ * */ -/** - * @file - * @brief A tiny editor implementation - */ - #include #include #include @@ -550,16 +545,6 @@ BAREBOX_CMD_HELP_START(edit) BAREBOX_CMD_HELP_TEXT("Use cursor keys, Ctrl-C to exit and Ctrl-D to exit-with-save.") BAREBOX_CMD_HELP_END -/** - * @page edit_command - -

Barebox contains a small text editor which can be used to edit -config files in /env. You can move the cursor around with the arrow keys -and type characters.

- -If called as sedit, the editor uses ansi codes to scroll the screen. - */ - BAREBOX_CMD_START(edit) .cmd = do_edit, .aliases = edit_aliases, @@ -568,4 +553,3 @@ BAREBOX_CMD_START(edit) BAREBOX_CMD_GROUP(CMD_GRP_CONSOLE) BAREBOX_CMD_HELP(cmd_edit_help) BAREBOX_CMD_END - diff --git a/commands/flash.c b/commands/flash.c index b50a32702e..99d3cb7c3f 100644 --- a/commands/flash.c +++ b/commands/flash.c @@ -19,11 +19,6 @@ * */ -/** - * @file - * @brief Flash memory support: erase, protect, unprotect - */ - #include #include #include @@ -92,20 +87,6 @@ BAREBOX_CMD_START(erase) BAREBOX_CMD_HELP(cmd_erase_help) BAREBOX_CMD_END -/** - * @page erase_command - -

Erase the flash memory handled by this device. Which area will be -erased depends on the device: If the device represents the whole flash -memory, the whole memory will be erased. If the device represents a -partition on a main flash memory, only this partition part will be -erased.

- -Refer to \ref addpart_command, \ref delpart_command and \ref -devinfo_command for partition handling. - - */ - static int do_protect(int argc, char *argv[]) { int fd; @@ -173,23 +154,6 @@ BAREBOX_CMD_START(protect) BAREBOX_CMD_HELP(cmd_protect_help) BAREBOX_CMD_END -/** - * @page protect_command - - -If the device represents the whole -flash memory the whole memory will be protected. If the device -represents a partition on a main flash memory, only this partition part -will be protected. - -Refer addpart_command, delpart_command and devinfo_command for partition -handling. - -\todo Rework this documentation, what is an 'area'? Explain more about -flashes here. - - */ - BAREBOX_CMD_HELP_START(unprotect) BAREBOX_CMD_HELP_TEXT("Unprotect the flash memory behind the device. It depends on the device") BAREBOX_CMD_HELP_TEXT("given, what area will be unprotected. If the device represents the whole") @@ -205,19 +169,3 @@ BAREBOX_CMD_START(unprotect) BAREBOX_CMD_GROUP(CMD_GRP_HWMANIP) BAREBOX_CMD_HELP(cmd_unprotect_help) BAREBOX_CMD_END - -/** - * @page unprotect_command - -It depends on the device given, -what area will be unprotected. If the device represents the whole flash memory -the whole memory will be unprotected. If the device represents a partition -on a main flash memory, only this partition part will be unprotected. - -Refer addpart_command, delpart_command and devinfo_command for partition -handling. - -\todo Rework this documentation, what does it mean? - - */ - diff --git a/commands/gpio.c b/commands/gpio.c index 4f2d93ee7d..08ecc152d9 100644 --- a/commands/gpio.c +++ b/commands/gpio.c @@ -107,65 +107,3 @@ BAREBOX_CMD_START(gpio_direction_output) BAREBOX_CMD_OPTS("GPIO VALUE") BAREBOX_CMD_GROUP(CMD_GRP_HWMANIP) BAREBOX_CMD_END - -/** - * @page gpio_for_users GPIO Handling - -@section regular_gpio General usage information - -These commands are available if the symbol @b CONFIG_GENERIC_GPIO and @b -CONFIG_CMD_GPIO are enabled in Kconfig. - -@note All gpio related commands take a number to identify the pad. This -number is architecture dependent and may not directly correlate with the -pad numbers. Due to this, it is also possible that the numbers changes -between @b barebox releases. - -@section gpio_dir_out Use Pad as GPIO Output -@verbatim -# gpio_direction_output -@endverbatim -- gpio_no: Architecture dependend GPIO number -- initial_value: Output value - -

To avoid glitches on the pad the routines will first set up the -pad's value and afterwards switch the pad to output (if the silicon is -able to do so). If the pad is already configured in non-GPIO mode (if -available), this command may silently fail.

- -@section gpio_dir_in Use Pad as GPIO Input -@verbatim -# gpio_direction_input -@endverbatim -- gpio_no: Architecture dependent GPIO number - -

If the pad is already configured in non-GPIO mode (if available), -this command may silently fail.

- -@section gpio_get_value Read Input Value from GPIO Pin -@verbatim -# gpio_get_value -@endverbatim - -

Reads the current value of a GPIO pin and return the value as a -shell return code. There is no visible output on stdout. You can check -the return value by using "echo $?".

- -

A return code other than '0' or '1' specifies an error code.

- -

If the pad is not configured in GPIO mode, this command may silently -fail and return garbage.

- -@section gpio_set_value Set Output Value on GPIO Pin -@verbatim -# gpio_set_value -@endverbatim -- gpio_no: Architecture dependent GPIO number -- value: Output value - -

Set a new output value on pad with GPIO number \.

- -

If the pad is not configured in GPIO-mode, this command may silently -fail.

- -*/ diff --git a/commands/led.c b/commands/led.c index 62c72a3315..354f74df8f 100644 --- a/commands/led.c +++ b/commands/led.c @@ -70,15 +70,6 @@ static int do_led(int argc, char *argv[]) return 0; } -/** - * @page led_command - -The exact meaning of is unspecified. It can be a color in case of rgb -LEDs or a brightness if this is controllable. In most cases only 1 for enabled -is allowed. - -*/ - BAREBOX_CMD_HELP_START(led) BAREBOX_CMD_HELP_TEXT("Control the value of a LED. The exact meaning of VALUE is unspecified,") BAREBOX_CMD_HELP_TEXT("it can be a brightness, or a color. Most often a value of '1' means on") diff --git a/commands/linux16.c b/commands/linux16.c index 65814f4ce7..594efc7dc2 100644 --- a/commands/linux16.c +++ b/commands/linux16.c @@ -330,18 +330,6 @@ BAREBOX_CMD_HELP_TEXT("Options:") BAREBOX_CMD_HELP_OPT ("-v VESAMODE", "set VESAMODE") BAREBOX_CMD_HELP_END -/** - * @page linux16_command - -

Only kernel images in bzImage format are supported by now. See \ref -x86_boot_preparation for more info about how to use this command.

- -

For the video mode refer the Linux kernel documentation -'Documentation/fb/vesafb.txt' for correct VESA mode numbers. If the keyword -'ask' instead of a number is given, the starting kernel will ask for a number. -

- */ - BAREBOX_CMD_START(linux16) .cmd = do_linux16, BAREBOX_CMD_DESC("boot a linux kernel on x86 via real-mode code") @@ -349,57 +337,3 @@ BAREBOX_CMD_START(linux16) BAREBOX_CMD_GROUP(CMD_GRP_BOOT) BAREBOX_CMD_HELP(cmd_linux16_help) BAREBOX_CMD_END - -/** - * @file - * @brief Boot support for Linux on x86 - */ - -/** - * @page x86_boot_preparation Linux Preparation on x86 - * - * Due to some real mode constraints, starting Linux is somehow tricky. - * Currently only @p bzImages are supported, because @p zImages would - * interfere with the @a barebox runtime. - * Also older load header versions than 2.00 aren't supported. - * - * The memory layout immediately before starting the Linux kernel: - * -@verbatim - real mode space hole extended memory - |---------------------------------------------->|----------->|------------------------------> - 0 0x7e00 0x90000 0xa0000 0x100000 - <-1-|----------2-----------><-3- | - <-4--|-5--> |---------6-------------> -@endverbatim - * - * @li 1 = @a barebox's real mode stack - * @li 2 = @a barebox's code - * @li 3 = @a barebox's flat mode stack - * @li 4 = real mode stack, when starting the Linux kernel - * @li 5 = Kernel's real mode setup code - * @li 6 = compressed kernel image - * - * A more detailed memory layout for kernel's real mode setup code - * -@verbatim - - 0x90000 0x97fff 0x99000 0x990ff - ---|------------------------------------------|----------------|--------------------| - |<-------- max setup code size ----------->|<--heap/stack-->|<-- command line -->| - -@endverbatim - * - * The regular entry point into the setup code is 0x90200 (2nd sector) - * - * To start the kernel, it's own setup code will be called. To do so, it - * must be called in real mode. So, @a barebox switches back to real mode - * a last time and does a jump to the setup code entry point. Now its up to - * the setup code to deflate the kernel, switching to its own protected mode - * setup and starting the kernel itself. - * - * @note This scenario only works, if a BIOS is still present. In this case - * there is no need for @a barebox to forward any system related information - * to the kernel. Everything is detected by kernel's setup code. - * - */ diff --git a/commands/loadenv.c b/commands/loadenv.c index ba92613396..8b15af49df 100644 --- a/commands/loadenv.c +++ b/commands/loadenv.c @@ -112,15 +112,6 @@ BAREBOX_CMD_HELP_OPT("-s", "scrub old environment") BAREBOX_CMD_HELP_OPT("-d", "load default environment") BAREBOX_CMD_HELP_END -/** - * @page loadenv_command - -ENVFS can only handle files, directories are skipped silently. - -\todo This needs proper documentation. What is ENVFS, why is it FS etc. Explain the concepts. - - */ - BAREBOX_CMD_START(loadenv) .cmd = do_loadenv, BAREBOX_CMD_DESC("load environment from ENVFS") diff --git a/commands/miitool.c b/commands/miitool.c index b08be9c683..40e34e93cc 100644 --- a/commands/miitool.c +++ b/commands/miitool.c @@ -293,12 +293,6 @@ BAREBOX_CMD_HELP_TEXT("Options:") BAREBOX_CMD_HELP_OPT("-v", "increase verbosity") BAREBOX_CMD_HELP_END -/** - * @page miitool_command -This utility checks or sets the status of a network interface's -Media Independent Interface (MII) unit. Most fast ethernet -adapters use an MII to autonegotiate link speed and duplex setting. - */ BAREBOX_CMD_START(miitool) .cmd = do_miitool, BAREBOX_CMD_DESC("view media-independent interface status") diff --git a/commands/mount.c b/commands/mount.c index 7aa155edbe..939e9bc853 100644 --- a/commands/mount.c +++ b/commands/mount.c @@ -17,11 +17,6 @@ * */ -/** - * @file - * @brief Filesystem mounting support - */ - #include #include #include @@ -130,37 +125,6 @@ BAREBOX_CMD_HELP_OPT("-o OPTIONS", "set file system OPTIONS") BAREBOX_CMD_HELP_OPT("-v\t", "verbose") BAREBOX_CMD_HELP_END -/** - * @page mount_command - -
    -
  • \ can be a device in /dev or some arbitrary string if no - device is needed for this driver, i.e. on ramfs.
    • -
  • \ is the filesystem driver. A list of available drivers can - be shown with the \ref devinfo_command command.
    • -
  • \ must be an empty directory, one level below the / - directory.
    • -
- - */ - -/** - * @page how_mount_works How mount works in barebox - -Mounting a filesystem ontop of a device is working like devices and -drivers are finding together. - -The mount command creates a new device with the filesystem name as the -driver for this "device". So the framework is able to merge both parts -together. - -By the way: With this feature its impossible to accidentely remove -partitions in use. A partition is internally also a device. If its -mounted it will be marked as busy, so an delpart command fails, until -the filesystem has been unmounted. - - */ - BAREBOX_CMD_START(mount) .cmd = do_mount, BAREBOX_CMD_DESC("mount a filesystem or list mounted filesystems") diff --git a/commands/partition.c b/commands/partition.c index 51988dfa7f..ef6d9c9e2c 100644 --- a/commands/partition.c +++ b/commands/partition.c @@ -180,18 +180,6 @@ BAREBOX_CMD_HELP_TEXT("The size of the last partition can be specified as '-' fo BAREBOX_CMD_HELP_TEXT("space on the device.") BAREBOX_CMD_HELP_END -/** - * @page addpart_command - -The size and the offset can be given in decimal (without any prefix) and -in hex (prefixed with 0x). Both can have an optional suffix K, M or G. -The size of the last partition can be specified as '-' for the remaining -space on the device. This format is the same as used by the Linux -kernel or cmdline mtd partitions. - -\todo This command has to be reworked and will probably change it's API. -*/ - BAREBOX_CMD_START(addpart) .cmd = do_addpart, BAREBOX_CMD_DESC("add a partition description to a device") @@ -219,17 +207,6 @@ BAREBOX_CMD_HELP_START(delpart) BAREBOX_CMD_HELP_TEXT("Delete partitions previously added to a device with addpart.") BAREBOX_CMD_HELP_END -/** - * @page delpart_command - -Partitions are created by adding their description with the addpart -command. If you want to get rid of a partition again, use delpart. The -argument list is taken as a list of partitions to be deleted. - -\todo Add an example - - */ - BAREBOX_CMD_START(delpart) .cmd = do_delpart, BAREBOX_CMD_DESC("delete partition(s)") @@ -238,4 +215,3 @@ BAREBOX_CMD_START(delpart) BAREBOX_CMD_HELP(cmd_delpart_help) BAREBOX_CMD_COMPLETE(devfs_partition_complete) BAREBOX_CMD_END - diff --git a/commands/printenv.c b/commands/printenv.c index 83353aeb32..161c214462 100644 --- a/commands/printenv.c +++ b/commands/printenv.c @@ -15,11 +15,6 @@ * */ -/** - * @file - * @brief printenv: Print out environment variables - */ - #include #include #include @@ -62,15 +57,6 @@ BAREBOX_CMD_HELP_TEXT("variable to the terminal. If no argument is specified, al BAREBOX_CMD_HELP_TEXT("printed.") BAREBOX_CMD_HELP_END -/** - * @page printenv_command - -

If an argument is given, printenv prints the content of an environment -variable to the terminal. If no argument is specified, all variables are -printed.

- - */ - BAREBOX_CMD_START(printenv) .cmd = do_printenv, BAREBOX_CMD_DESC("print value of environment variables") diff --git a/commands/saveenv.c b/commands/saveenv.c index d629a94c5d..54b6fa1b7b 100644 --- a/commands/saveenv.c +++ b/commands/saveenv.c @@ -15,11 +15,6 @@ * */ -/** - * @file - * @brief saveenv: Make the environment persistent - */ - #include #include #include @@ -64,16 +59,3 @@ BAREBOX_CMD_START(saveenv) BAREBOX_CMD_GROUP(CMD_GRP_ENV) BAREBOX_CMD_HELP(cmd_saveenv_help) BAREBOX_CMD_END - -/** - * @page saveenv_command - -

\ is usually a block in flash but can be any other file. If -omitted, \ defaults to /env and \ defaults to -/dev/env0. Note that envfs can only handle files, directories are being -skipped silently.

- -\todo What does 'block in flash' mean? Add example. - - */ - diff --git a/commands/setenv.c b/commands/setenv.c index 9e21ccec8c..af4dd29ac4 100644 --- a/commands/setenv.c +++ b/commands/setenv.c @@ -15,11 +15,6 @@ * */ -/** - * @file - * @brief setenv: Set an environment variables - */ - #include #include #include @@ -40,14 +35,6 @@ BAREBOX_CMD_HELP_TEXT("Set environment variable NAME to VALUE.") BAREBOX_CMD_HELP_TEXT("If VALUE is ommitted, then the variable is deleted.") BAREBOX_CMD_HELP_END -/** - * @page setenv_command - -

This command is only available if the simple command line parser is -in use. Within the hush shell, \c setenv is not required.

- - */ - BAREBOX_CMD_START(setenv) .cmd = do_setenv, BAREBOX_CMD_DESC("set environment variable") diff --git a/commands/splash.c b/commands/splash.c index c61a1d76a1..5d0c0ad188 100644 --- a/commands/splash.c +++ b/commands/splash.c @@ -89,17 +89,6 @@ BAREBOX_CMD_HELP_OPT ("-b COLOR", "background color in 0xttrrggbb") BAREBOX_CMD_HELP_OPT ("-o\t", "render offscreen") BAREBOX_CMD_HELP_END -/** - * @page bmp_command - -This command displays a graphics in the bitmap (.bmp) format on the -framebuffer. Currently the bmp command supports images with 8 and 24 bit -color depth. - -\todo What does the -o (offscreen) option do? - - */ - BAREBOX_CMD_START(splash) .cmd = do_splash, BAREBOX_CMD_DESC("display a BMP image") diff --git a/commands/usbserial.c b/commands/usbserial.c index 1c26246f7c..e4c2f18024 100644 --- a/commands/usbserial.c +++ b/commands/usbserial.c @@ -92,10 +92,6 @@ BAREBOX_CMD_HELP_OPT ("-s", "Generic Serial") BAREBOX_CMD_HELP_OPT ("-d", "Disable the serial gadget") BAREBOX_CMD_HELP_END -/** - * @page usbserial_command - */ - BAREBOX_CMD_START(usbserial) .cmd = do_usbserial, BAREBOX_CMD_DESC("serial gadget enable/disable") diff --git a/common/kallsyms.c b/common/kallsyms.c index 121b77cc8b..53e22cdc73 100644 --- a/common/kallsyms.c +++ b/common/kallsyms.c @@ -3,8 +3,6 @@ #include #include -#ifndef DOXYGEN_SHOULD_SKIP_THIS - /* These will be re-linked against their real values during the second link stage */ extern const unsigned long kallsyms_addresses[] __attribute__((weak)); extern const unsigned long kallsyms_num_syms __attribute__((weak)); @@ -15,8 +13,6 @@ extern const u16 kallsyms_token_index[] __attribute__((weak)); extern const unsigned long kallsyms_markers[] __attribute__((weak)); -#endif /* DOXYGEN_SHOULD_SKIP_THIS */ - static inline int is_kernel_text(unsigned long addr) { if ((addr >= (unsigned long)_stext && addr <= (unsigned long)_etext)) diff --git a/include/command.h b/include/command.h index 347ad2f3ec..5d5bf53544 100644 --- a/include/command.h +++ b/include/command.h @@ -90,8 +90,6 @@ void barebox_cmd_usage(struct command *cmdtp); #endif /* __ASSEMBLY__ */ -#ifndef DOXYGEN_SHOULD_SKIP_THIS - #define Struct_Section __attribute__ ((unused,section (".barebox_cmd"))) #define BAREBOX_CMD_START(_name) \ @@ -127,8 +125,6 @@ static const __maybe_unused char cmd_##_name##_help[] = #define BAREBOX_CMD_OPTS(text) .opts = text, -#endif /* DOXYGEN_SHOULD_SKIP_THIS */ - int register_command(struct command *); #endif /* __COMMAND_H */ diff --git a/include/driver.h b/include/driver.h index ffc0cbaf77..53e1000067 100644 --- a/include/driver.h +++ b/include/driver.h @@ -28,32 +28,6 @@ #include -/** - * @file - * @brief Main description of the device/driver model - */ - -/** @page driver_model Main description of the device/driver model - * - * We follow a rather simplistic driver model here. There is a - * @code struct device_d @endcode - * which describes a particular device present in the system. - * - * On the other side a - * @code struct driver_d @endcode - * represents a driver present in the system. - * - * Both structs find together via the members 'type' (int) and 'name' (char *). - * If both members match, the driver's probe function is called with the - * struct device_d as argument. - * - * People familiar with the Linux platform bus will recognize this behaviour - * and in fact many things were stolen from there. Some selected members of the - * structs will be described in this document. - */ - -/*@{*/ /* do not delete, doxygen relevant */ - struct filep; struct bus_type; diff --git a/include/i2c/i2c.h b/include/i2c/i2c.h index f89fefbb27..a107f5edb7 100644 --- a/include/i2c/i2c.h +++ b/include/i2c/i2c.h @@ -19,8 +19,6 @@ #include #include -#ifndef DOXYGEN_SHOULD_SKIP_THIS - /* * struct i2c_platform_data - structure of platform data for MXC I2C driver * @param bitrate Bus speed measured in Hz @@ -153,8 +151,6 @@ extern int i2c_master_recv(struct i2c_client *client, char *buf, int count); extern int i2c_read_reg(struct i2c_client *client, u32 addr, u8 *buf, u16 count); extern int i2c_write_reg(struct i2c_client *client, u32 addr, const u8 *buf, u16 count); -#endif /* DOXYGEN_SHOULD_SKIP_THIS */ - extern struct bus_type i2c_bus; static inline int i2c_driver_register(struct driver_d *drv) diff --git a/include/linux/mtd/mtd-abi.h b/include/linux/mtd/mtd-abi.h index c1ba55bd2d..c46605d5e3 100644 --- a/include/linux/mtd/mtd-abi.h +++ b/include/linux/mtd/mtd-abi.h @@ -7,8 +7,6 @@ #ifndef __MTD_ABI_H__ #define __MTD_ABI_H__ -#ifndef DOXYGEN_SHOULD_SKIP_THIS - #include struct erase_info_user { @@ -183,6 +181,4 @@ static inline uint32_t mtd_user_div_by_eb(uint64_t sz, return sz; } -#endif /* DOXYGEN_SHOULD_SKIP_THIS */ - #endif /* __MTD_ABI_H__ */ diff --git a/include/linux/mtd/mtd.h b/include/linux/mtd/mtd.h index 5f02aee2d6..1d33592fef 100644 --- a/include/linux/mtd/mtd.h +++ b/include/linux/mtd/mtd.h @@ -9,8 +9,6 @@ #ifndef __MTD_MTD_H__ #define __MTD_MTD_H__ -#ifndef DOXYGEN_SHOULD_SKIP_THIS - #include #include #include @@ -325,8 +323,6 @@ int mtd_all_ff(const void *buf, unsigned int len); #endif /* CONFIG_MTD_DEBUG */ -#endif /* DOXYGEN_SHOULD_SKIP_THIS */ - static inline int mtd_is_bitflip(int err) { return err == -EUCLEAN; } diff --git a/include/spi/spi.h b/include/spi/spi.h index b4358a84de..620e5e57b4 100644 --- a/include/spi/spi.h +++ b/include/spi/spi.h @@ -1,8 +1,6 @@ #ifndef __INCLUDE_SPI_H #define __INCLUDE_SPI_H -#ifndef DOXYGEN_SHOULD_SKIP_THIS - #include #include @@ -431,8 +429,6 @@ static inline ssize_t spi_w8r8(struct spi_device *spi, u8 cmd) return (status < 0) ? status : result; } -#endif /* DOXYGEN_SHOULD_SKIP_THIS */ - extern struct bus_type spi_bus; struct spi_master *spi_get_master(int bus); diff --git a/include/usb/ch9.h b/include/usb/ch9.h index adbe53341b..93223638f7 100644 --- a/include/usb/ch9.h +++ b/include/usb/ch9.h @@ -33,8 +33,6 @@ #ifndef __LINUX_USB_CH9_H #define __LINUX_USB_CH9_H -#ifndef DOXYGEN_SHOULD_SKIP_THIS - #include /* __u8 etc */ /*-------------------------------------------------------------------------*/ @@ -798,6 +796,4 @@ enum usb_device_state { */ }; -#endif /* DOXYGEN_SHOULD_SKIP_THIS */ - #endif /* __LINUX_USB_CH9_H */ diff --git a/include/usb/composite.h b/include/usb/composite.h index 798fa110e7..379927a07d 100644 --- a/include/usb/composite.h +++ b/include/usb/composite.h @@ -17,8 +17,6 @@ #ifndef __LINUX_USB_COMPOSITE_H #define __LINUX_USB_COMPOSITE_H -#ifndef DOXYGEN_SHOULD_SKIP_THIS - /* * This framework is an optional layer on top of the USB Gadget interface, * making it easier to build (a) Composite devices, supporting multiple @@ -343,6 +341,4 @@ extern int usb_string_id(struct usb_composite_dev *c); #define WARNING(d, fmt, args...) #define INFO(d, fmt, args...) -#endif /* DOXYGEN_SHOULD_SKIP_THIS */ - #endif /* __LINUX_USB_COMPOSITE_H */ diff --git a/include/usb/gadget.h b/include/usb/gadget.h index ff1509ca79..798b51b3ce 100644 --- a/include/usb/gadget.h +++ b/include/usb/gadget.h @@ -15,8 +15,6 @@ #ifndef __LINUX_USB_GADGET_H #define __LINUX_USB_GADGET_H -#ifndef DOXYGEN_SHOULD_SKIP_THIS - #include #include #include @@ -899,6 +897,4 @@ extern struct usb_ep *usb_ep_autoconfig(struct usb_gadget *, extern void usb_ep_autoconfig_reset(struct usb_gadget *); -#endif /* DOXYGEN_SHOULD_SKIP_THIS */ - #endif /* __LINUX_USB_GADGET_H */ diff --git a/include/usb/usb.h b/include/usb/usb.h index 1a369d2eeb..4877e321bd 100644 --- a/include/usb/usb.h +++ b/include/usb/usb.h @@ -22,8 +22,6 @@ #ifndef _USB_H_ #define _USB_H_ -#ifndef DOXYGEN_SHOULD_SKIP_THIS - #include #include #include @@ -516,8 +514,6 @@ struct usb_device_id { #define USB_CTRL_SET_TIMEOUT 5000 #define USB_CTRL_GET_TIMEOUT 5000 -#endif /* DOXYGEN_SHOULD_SKIP_THIS */ - enum usb_dr_mode of_usb_get_dr_mode(struct device_node *np, const char *propname); diff --git a/net/netconsole.c b/net/netconsole.c index 86a68e19d9..021820b13a 100644 --- a/net/netconsole.c +++ b/net/netconsole.c @@ -32,11 +32,6 @@ #include #include -/** - * @file - * @brief Network console support - */ - struct nc_priv { struct console_device cdev; struct kfifo *fifo; @@ -169,26 +164,3 @@ static int netconsole_init(void) } device_initcall(netconsole_init); - -/** @page net_netconsole Network console - -@section net_netconsole Using an UDP based network console - -If enabled barebox supports a console via udp networking. There is only -one network console supported registered during init time. It is deactivated -by default because it opens great security holes, so use with care. - -To use the network console you have to configure the remote ip and the local -and remote ports. Assuming the network console is registered as cs1, it can be -configured with: - -@code -cs1.ip= -cs1.port= -cs1.active=ioe -@endcode - -On the remote host call scripts/netconsole with bareboxes ip and port as -parameters. port is initialized to 6666 by default. - -*/ diff --git a/scripts/doxy_filter.awk b/scripts/doxy_filter.awk deleted file mode 100644 index 5ec0406298..0000000000 --- a/scripts/doxy_filter.awk +++ /dev/null @@ -1,103 +0,0 @@ -#!/usr/bin/awk - -/BAREBOX_CMD_HELP_START[[:space:]]*\((.*)\)/ { - - this_opt = 0; - my_usage = ""; - my_short = ""; - my_cmd = gensub("BAREBOX_CMD_HELP_START[[:space:]]*\\((.*)\\)", "\\1", "g"); - this_text = 0; - delete(my_text); - delete(my_opts); - next; -} - -/BAREBOX_CMD_HELP_USAGE[[:space:]]*\((.*)\)/ { - - $0 = gensub("<", "\\<", "g"); - $0 = gensub(">", "\\>", "g"); - $0 = gensub("BAREBOX_CMD_HELP_USAGE[[:space:]]*\\((.*)\\)", "\\1", "g"); - $0 = gensub("\\\\n", "", "g"); - my_usage = gensub("\"", "", "g"); - next; - -} - -/BAREBOX_CMD_HELP_SHORT[[:space:]]*\((.*)\)/ { - - $0 = gensub("<", "\\<", "g"); - $0 = gensub(">", "\\>", "g"); - $0 = gensub("BAREBOX_CMD_HELP_SHORT[[:space:]]*\\((.*)\\)", "\\1", "g"); - $0 = gensub("\\\\n", "", "g"); - my_short = gensub("\"", "", "g"); - next; - -} - -/BAREBOX_CMD_HELP_OPT[[:space:]]*\([[:space:]]*(.*)[[:space:]]*,[[:space:]]*(.*)[[:space:]]*\)/ { - - $0 = gensub("<", "\\<", "g"); - $0 = gensub(">", "\\>", "g"); - $0 = gensub("@", "\\\\@", "g"); - $0 = gensub("BAREBOX_CMD_HELP_OPT[[:space:]]*\\([[:space:]]*\"*(.*)\"[[:space:]]*,[[:space:]]*\"(.*)\"[[:space:]]*\\)", \ - " \\1 \\ \\ \\  \\2 ", "g"); - $0 = gensub("\\\\n", "", "g"); - my_opts[this_opt] = gensub("\"", "", "g"); - this_opt ++; - next; -} - -/BAREBOX_CMD_HELP_TEXT[[:space:]]*\((.*)\)/ { - - $0 = gensub("<", "\\<", "g"); - $0 = gensub(">", "\\>", "g"); - $0 = gensub("BAREBOX_CMD_HELP_TEXT[[:space:]]*\\((.*)\\)", "\\1", "g"); - $0 = gensub("\\\\n", "
", "g"); - my_text[this_text] = gensub("\"", "", "g"); - this_text ++; - next; -} - -/BAREBOX_CMD_HELP_END/ { - - printf "/**\n"; - printf " * @page " my_cmd "_command " my_cmd "\n"; - printf " *\n"; - printf " * \\par Usage:\n"; - printf " * " my_usage "\n"; - printf " *\n"; - - if (this_opt != 0) { - printf " * \\par Options:\n"; - printf " *\n"; - printf " * \n"; - n = asorti(my_opts, my_opts_sorted); - for (i=1; i<=n; i++) { - printf " * " my_opts[my_opts_sorted[i]] "\n"; - } - printf " *
\n"; - printf " *\n"; - } - - printf " * " my_short "\n"; - printf " *\n"; - - n = asorti(my_text, my_text_sorted); - if (n > 0) { - for (i=1; i<=n; i++) { - printf " * " my_text[my_text_sorted[i]] "\n"; - } - printf " *\n"; - } - - printf " */\n"; - - next; -} - -/^.*$/ { - - print $0; - -} - -- cgit v1.2.3