tizen-distro: remove Poky documentationmaster

We inherited some documentation from the merged Poky repository
when re-creating tizen-distro. This documentation does not apply
to tizen-distro, so better remove it.

The hardware guide and sections about reporting problems need to be
re-written later, once Tizen reference hardware and procedures are
better defined.

Change-Id: If0ad5cc5f6a0776f7e3c6dfadd585de586f9b64d
Signed-off-by: Patrick Ohly <patrick.ohly@intel.com>
(cherry picked from commit 43408c8418d8ab3642f1eb7ef191d33071cd59f0)
Signed-off-by: Patrick Ohly <patrick.ohly@intel.com>

3 files changed, 48 insertions, 596 deletions

diff --git a/README b/README
index 0a18c9c70a..e32ce5cf0d 100644
--- a/README
+++ b/README
@@ -1,49 +1,50 @@
-Poky
-====
-
-Poky is an integration of various components to form a complete prepackaged
-build system and development environment. It features support for building
-customised embedded device style images. There are reference demo images
-featuring a X11/Matchbox/GTK themed UI called Sato. The system supports
-cross-architecture application development using QEMU emulation and a
-standalone toolchain and SDK with IDE integration.
-
-Additional information on the specifics of hardware that Poky supports
-is available in README.hardware. Further hardware support can easily be added
-in the form of layers which extend the systems capabilities in a modular way.
-
-As an integration layer Poky consists of several upstream projects such as 
-BitBake, OpenEmbedded-Core, Yocto documentation and various sources of information 
-e.g. for the hardware support. Poky is in turn a component of the Yocto Project.
-
-The Yocto Project has extensive documentation about the system including a 
-reference manual which can be found at:
-    http://yoctoproject.org/documentation
-
-OpenEmbedded-Core is a layer containing the core metadata for current versions
-of OpenEmbedded. It is distro-less (can build a functional image with
-DISTRO = "nodistro") and contains only emulated machine support.
-
-For information about OpenEmbedded, see the OpenEmbedded website:
-    http://www.openembedded.org/
-
-Where to Send Patches
+About tizen-distro
+==================
+
+tizen-distro is a combination of several different components in a
+single repository:
+- bitbake
+- openembedded-core
+- meta-openembedded
+- meta-qt5
+- meta-tizen
+
+The top-level directory comes from openembedded-core, everything else
+is in its own sub-directory. tizen-distro gets updated by copying
+importing patches from the component's repostories. Please submit
+patches against those instead of tizen-distro.
+
+Updating tizen-distro
 =====================
 
-As Poky is an integration repository, patches against the various components
-should be sent to their respective upstreams.
-
-bitbake:
-    bitbake-devel@lists.openembedded.org
-
-meta-yocto:
-    poky@yoctoproject.org
-
-Most everything else should be sent to the OpenEmbedded Core mailing list.  If
-in doubt, check the oe-core git repository for the content you intend to modify.
-Before sending, be sure the patches apply cleanly to the current oe-core git
-repository.
-    openembedded-core@lists.openembedded.org
-
-Note: The scripts directory should be treated with extra care as it is a mix
-      of oe-core and poky-specific files.
+Everyone with a copy of the tizen-distro repository can use
+scripts/combo-layer to import patches from the components. That works
+because the "last_revision" property which gets changed after each
+import gets committed to the combined repostory.
+
+First, copy conf/combo-layer-local-sample.conf into
+conf/combo-layer-local.conf and set the paths for each component
+repository to a suitable location.
+
+Then run:
+- "scripts/combo-layer init" (only once)
+- "scripts/combo-layer update <component>" where <component> is either one of
+  components above (for updating just that one) or empty (for updating all)
+
+Branching tizen-distro
+======================
+
+Each branch in tizen-distro tracks one branch in each component. To
+create a new branch:
+- checkout a new branch in tizen-component
+- change the "branch" properties in conf/combo-layer.conf
+- change the branch part in the last_revision sections
+- commit
+- continue as before
+
+This works best if the last imported revision from each component is
+the branching point of that component. Ensure that by updating before
+the components branch. If it is too late, either select patches
+interactively or import too many patches and then drop unwanted ones
+via "git rebase" or "git reset --hard". Remember to keep
+"last_revision" correct when doing that.
diff --git a/README.hardware b/README.hardware
deleted file mode 100644
index d8faaa3bdb..0000000000
--- a/README.hardware
+++ /dev/null
@@ -1,499 +0,0 @@
-                          Poky Hardware README
-                          ====================
-
-This file gives details about using Poky with the reference machines
-supported out of the box. A full list of supported reference target machines
-can be found by looking in the following directories:
-
-   meta/conf/machine/
-   meta-yocto-bsp/conf/machine/
-
-If you are in doubt about using Poky/OpenEmbedded with your hardware, consult
-the documentation for your board/device.
-
-Support for additional devices is normally added by creating BSP layers - for
-more information please see the Yocto Board Support Package (BSP) Developer's
-Guide - documentation source is in documentation/bspguide or download the PDF
-from:
-
-   http://yoctoproject.org/documentation
-
-Support for physical reference hardware has now been split out into a
-meta-yocto-bsp layer which can be removed separately from other layers if not
-needed.
-
-
-QEMU Emulation Targets
-======================
-
-To simplify development, the build system supports building images to
-work with the QEMU emulator in system emulation mode. Several architectures
-are currently supported:
-
-  * ARM (qemuarm)
-  * x86 (qemux86)
-  * x86-64 (qemux86-64)
-  * PowerPC (qemuppc)
-  * MIPS (qemumips)
-
-Use of the QEMU images is covered in the Yocto Project Reference Manual.
-The appropriate MACHINE variable value corresponding to the target is given
-in brackets.
-
-
-Hardware Reference Boards
-=========================
-
-The following boards are supported by the meta-yocto-bsp layer:
-
-  * Texas Instruments Beaglebone (beaglebone)
-  * Freescale MPC8315E-RDB (mpc8315e-rdb)
-
-For more information see the board's section below. The appropriate MACHINE
-variable value corresponding to the board is given in brackets.
-
-Reference Board Maintenance
-===========================
-
-Send pull requests, patches, comments or questions about meta-yocto-bsps to poky@yoctoproject.org
-
-Maintainers: Kevin Hao <kexin.hao@windriver.com>
-             Bruce Ashfield <bruce.ashfield@windriver.com>
-
-Consumer Devices
-================
-
-The following consumer devices are supported by the meta-yocto-bsp layer:
-
-  * Intel x86 based PCs and devices (genericx86)
-  * Ubiquiti Networks EdgeRouter Lite (edgerouter)
-
-For more information see the device's section below. The appropriate MACHINE
-variable value corresponding to the device is given in brackets.
-
-
-
-                      Specific Hardware Documentation
-                      ===============================
-
-
-Intel x86 based PCs and devices (genericx86)
-==========================================
-
-The genericx86 MACHINE is tested on the following platforms:
-
-Intel Xeon/Core i-Series:
-  + Intel Romley Server: Sandy Bridge Xeon processor, C600 PCH (Patsburg), (Canoe Pass CRB)
-  + Intel Romley Server: Ivy Bridge Xeon processor, C600 PCH (Patsburg), (Intel SDP S2R3)
-  + Intel Crystal Forest Server: Sandy Bridge Xeon processor, DH89xx PCH (Cave Creek), (Stargo CRB)
-  + Intel Chief River Mobile: Ivy Bridge Mobile processor, QM77 PCH (Panther Point-M), (Emerald Lake II CRB, Sabino Canyon CRB)
-  + Intel Huron River Mobile: Sandy Bridge processor, QM67 PCH (Cougar Point), (Emerald Lake CRB, EVOC EC7-1817LNAR board)
-  + Intel Calpella Platform: Core i7 processor, QM57 PCH (Ibex Peak-M), (Red Fort CRB, Emerson MATXM CORE-411-B)
-  + Intel Nehalem/Westmere-EP Server: Xeon 56xx/55xx processors, 5520 chipset, ICH10R IOH (82801), (Hanlan Creek CRB)
-  + Intel Nehalem Workstation: Xeon 56xx/55xx processors, System SC5650SCWS (Greencity CRB)
-  + Intel Picket Post Server: Xeon 56xx/55xx processors (Jasper Forest), 3420 chipset (Ibex Peak), (Osage CRB)
-  + Intel Storage Platform: Sandy Bridge Xeon processor, C600 PCH (Patsburg), (Oak Creek Canyon CRB)
-  + Intel Shark Bay Client Platform: Haswell processor, LynxPoint PCH, (Walnut Canyon CRB, Lava Canyon CRB, Basking Ridge CRB, Flathead Creek CRB)
-  + Intel Shark Bay Ultrabook Platform: Haswell ULT processor, Lynx Point-LP PCH, (WhiteTip Mountain 1 CRB)
-
-Intel Atom platforms:
-  + Intel embedded Menlow: Intel Atom Z510/530 CPU, System Controller Hub US15W (Portwell NANO-8044)
-  + Intel Luna Pier: Intel Atom N4xx/D5xx series CPU (aka: Pineview-D & -M), 82801HM I/O Hub (ICH8M), (Advantech AIMB-212, Moon Creek CRB)
-  + Intel Queens Bay platform: Intel Atom E6xx CPU (aka: Tunnel Creek), Topcliff EG20T I/O Hub (Emerson NITX-315, Crown Bay CRB, Minnow Board)
-  + Intel Fish River Island platform: Intel Atom E6xx CPU (aka: Tunnel Creek), Topcliff EG20T I/O Hub (Kontron KM2M806)
-  + Intel Cedar Trail platform: Intel Atom N2000 & D2000 series CPU (aka: Cedarview), NM10 Express Chipset (Norco kit BIS-6630, Cedar Rock CRB)
-
-and is likely to work on many unlisted Atom/Core/Xeon based devices. The MACHINE
-type supports ethernet, wifi, sound, and Intel/vesa graphics by default in
-addition to common PC input devices, busses, and so on.  Note that it does not
-included the binary-only graphic drivers used on some Atom platforms, for
-accelerated graphics on these machines please refer to meta-intel.
-
-Depending on the device, it can boot from a traditional hard-disk, a USB device,
-or over the network. Writing generated images to physical media is
-straightforward with a caveat for USB devices. The following examples assume the
-target boot device is /dev/sdb, be sure to verify this and use the correct
-device as the following commands are run as root and are not reversable.
-
-USB Device:
-  1. Build a live image. This image type consists of a simple filesystem
-     without a partition table, which is suitable for USB keys, and with the
-     default setup for the genericx86 machine, this image type is built
-     automatically for any image you build. For example:
-
-     $ bitbake core-image-minimal
-
-  2. Use the "dd" utility to write the image to the raw block device. For
-     example:
-
-     # dd if=core-image-minimal-genericx86.hddimg of=/dev/sdb
-
-  If the device fails to boot with "Boot error" displayed, or apparently
-  stops just after the SYSLINUX version banner, it is likely the BIOS cannot
-  understand the physical layout of the disk (or rather it expects a
-  particular layout and cannot handle anything else). There are two possible
-  solutions to this problem:
-
-  1. Change the BIOS USB Device setting to HDD mode. The label will vary by
-     device, but the idea is to force BIOS to read the Cylinder/Head/Sector
-     geometry from the device.
-
-  2. Without such an option, the BIOS generally boots the device in USB-ZIP
-     mode. To write an image to a USB device that will be bootable in
-     USB-ZIP mode, carry out the following actions:
-
-     a. Determine the geometry of your USB device using fdisk:
-
-     # fdisk /dev/sdb
-     Command (m for help): p
-
-     Disk /dev/sdb: 4011 MB, 4011491328 bytes
-     124 heads, 62 sectors/track, 1019 cylinders, total 7834944 sectors
-     ...
-
-     Command (m for help): q
-
-     b. Configure the USB device for USB-ZIP mode:
-     
-     # mkdiskimage -4 /dev/sdb 1019 124 62
-
-     Where 1019, 124 and 62 are the cylinder, head and sectors/track counts
-     as reported by fdisk (substitute the values reported for your device).
-     When the operation has finished and the access LED (if any) on the
-     device stops flashing, remove and reinsert the device to allow the
-     kernel to detect the new partition layout.
-
-     c. Copy the contents of the image to the USB-ZIP mode device:
-
-     # mkdir /tmp/image
-     # mkdir /tmp/usbkey
-     # mount -o loop core-image-minimal-genericx86.hddimg  /tmp/image
-     # mount /dev/sdb4 /tmp/usbkey
-     # cp -rf /tmp/image/* /tmp/usbkey
-
-     d. Install the syslinux boot loader:
-
-     # syslinux /dev/sdb4
-
-     e. Unmount everything:
-
-     # umount /tmp/image
-     # umount /tmp/usbkey
-
-  Install the boot device in the target board and configure the BIOS to boot
-  from it.
-
-  For more details on the USB-ZIP scenario, see the syslinux documentation:
-  http://git.kernel.org/?p=boot/syslinux/syslinux.git;a=blob_plain;f=doc/usbkey.txt;hb=HEAD
-
-
-Texas Instruments Beaglebone (beaglebone)
-=========================================
-
-The Beaglebone is an ARM Cortex-A8 development board with USB, Ethernet, 2D/3D
-accelerated graphics, audio, serial, JTAG, and SD/MMC. The Black adds a faster
-CPU, more RAM, eMMC flash and a micro HDMI port. The beaglebone MACHINE is
-tested on the following platforms:
-
-  o Beaglebone Black A6
-  o Beaglebone A6 (the original "White" model)
-
-The Beaglebone Black has eMMC, while the White does not. Pressing the USER/BOOT
-button when powering on will temporarily change the boot order. But for the sake
-of simplicity, these instructions assume you have erased the eMMC on the Black,
-so its boot behavior matches that of the White and boots off of SD card. To do
-this, issue the following commands from the u-boot prompt:
-
-    # mmc dev 1
-    # mmc erase 0 512
-
-To further tailor these instructions for your board, please refer to the
-documentation at http://www.beagleboard.org/bone and http://www.beagleboard.org/black
-
-From a Linux system with access to the image files perform the following steps
-as root, replacing mmcblk0* with the SD card device on your machine (such as sdc
-if used via a usb card reader):
-
-  1. Partition and format an SD card:
-     # fdisk -lu /dev/mmcblk0
-
-     Disk /dev/mmcblk0: 3951 MB, 3951034368 bytes
-     255 heads, 63 sectors/track, 480 cylinders, total 7716864 sectors
-     Units = sectors of 1 * 512 = 512 bytes
-
-             Device Boot      Start         End      Blocks  Id System
-     /dev/mmcblk0p1   *          63      144584       72261   c Win95 FAT32 (LBA)
-     /dev/mmcblk0p2          144585      465884      160650  83 Linux
-
-     # mkfs.vfat -F 16 -n "boot" /dev/mmcblk0p1
-     # mke2fs -j -L "root" /dev/mmcblk0p2
-
-  The following assumes the SD card partitions 1 and 2 are mounted at
-  /media/boot and /media/root respectively. Removing the card and reinserting
-  it will do just that on most modern Linux desktop environments.
-
-  The files referenced below are made available after the build in
-  build/tmp/deploy/images.
-
-  2. Install the boot loaders
-     # cp MLO-beaglebone /media/boot/MLO
-     # cp u-boot-beaglebone.img /media/boot/u-boot.img
-
-  3. Install the root filesystem
-     # tar x -C /media/root -f core-image-$IMAGE_TYPE-beaglebone.tar.bz2
-
-  4. If using core-image-base or core-image-sato images, the SD card is ready
-     and rootfs already contains the kernel, modules and device tree (DTB)
-     files necessary to be booted with U-boot's default configuration, so
-     skip directly to step 8.
-     For core-image-minimal, proceed through next steps.
-
-  5. If using core-image-minimal rootfs, install the modules
-     # tar x -C /media/root -f modules-beaglebone.tgz
-
-  6. If using core-image-minimal rootfs, install the kernel uImage into /boot
-     directory of rootfs
-     # cp uImage-beaglebone.bin /media/root/boot/uImage
-
-  7. If using core-image-minimal rootfs, also install device tree (DTB) files
-     into /boot directory of rootfs
-     # cp uImage-am335x-bone.dtb /media/root/boot/am335x-bone.dtb
-     # cp uImage-am335x-boneblack.dtb /media/root/boot/am335x-boneblack.dtb
-
-  8. Unmount the SD partitions, insert the SD card into the Beaglebone, and
-     boot the Beaglebone
-
-
-Freescale MPC8315E-RDB (mpc8315e-rdb)
-=====================================
-
-The MPC8315 PowerPC reference platform (MPC8315E-RDB) is aimed at hardware and
-software development of network attached storage (NAS) and digital media server
-applications. The MPC8315E-RDB features the PowerQUICC II Pro processor, which
-includes a built-in security accelerator.
-
-(Note: you may find it easier to order MPC8315E-RDBA; this appears to be the
-same board in an enclosure with accessories. In any case it is fully
-compatible with the instructions given here.)
-
-Setup instructions
-------------------
-
-You will need the following:
-* NFS root setup on your workstation
-* TFTP server installed on your workstation
-* Straight-thru 9-conductor serial cable (DB9, M/F) connected from your 
-  PC to UART1
-* Ethernet connected to the first ethernet port on the board
-
---- Preparation ---
-
-Note: if you have altered your board's ethernet MAC address(es) from the
-defaults, or you need to do so because you want multiple boards on the same
-network, then you will need to change the values in the dts file (patch
-linux/arch/powerpc/boot/dts/mpc8315erdb.dts within the kernel source). If
-you have left them at the factory default then you shouldn't need to do
-anything here.
-
---- Booting from NFS root ---
-
-Load the kernel and dtb (device tree blob), and boot the system as follows:
-
- 1. Get the kernel (uImage-mpc8315e-rdb.bin) and dtb (uImage-mpc8315e-rdb.dtb)
-    files from the tmp/deploy directory, and make them available on your TFTP
-    server.
-
- 2. Connect the board's first serial port to your workstation and then start up
-    your favourite serial terminal so that you will be able to interact with
-    the serial console. If you don't have a favourite, picocom is suggested:
-
-  $ picocom /dev/ttyUSB0 -b 115200
-
- 3. Power up or reset the board and press a key on the terminal when prompted
-    to get to the U-Boot command line
-
- 4. Set up the environment in U-Boot:
-
- => setenv ipaddr <board ip>
- => setenv serverip <tftp server ip>
- => setenv bootargs root=/dev/nfs rw nfsroot=<nfsroot ip>:<rootfs path> ip=<board ip>:<server ip>:<gateway ip>:255.255.255.0:mpc8315e:eth0:off console=ttyS0,115200
-
- 5. Download the kernel and dtb, and boot:
-
- => tftp 1000000 uImage-mpc8315e-rdb.bin
- => tftp 2000000 uImage-mpc8315e-rdb.dtb
- => bootm 1000000 - 2000000
-
---- Booting from JFFS2 root ---
-
- 1. First boot the board with NFS root.
-
- 2. Erase the MTD partition which will be used as root:
-
-    $ flash_eraseall  /dev/mtd3
-
- 3. Copy the JFFS2 image to the MTD partition:
-
-    $ flashcp core-image-minimal-mpc8315e-rdb.jffs2 /dev/mtd3
-
- 4. Then reboot the board and set up the environment in U-Boot:
-
-    => setenv bootargs root=/dev/mtdblock3 rootfstype=jffs2 console=ttyS0,115200
-
-
-Ubiquiti Networks EdgeRouter Lite (edgerouter)
-==============================================
-
-The EdgeRouter Lite is part of the EdgeMax series. It is a MIPS64 router
-(based on the Cavium Octeon processor) with 512MB of RAM, which uses an
-internal USB pendrive for storage.
-
-Setup instructions
-------------------
-
-You will need the following:
-* NFS root setup on your workstation
-* TFTP server installed on your workstation
-* RJ45 -> serial ("rollover") cable connected from your PC to the CONSOLE
-  port on the board
-* Ethernet connected to the first ethernet port on the board
-
---- Preparation ---
-
-Build an image (e.g. core-image-minimal) using "edgerouter" as the MACHINE.
-In the following instruction it is based on core-image-minimal. Another target
-may be similiar with it.
-
---- Booting from NFS root ---
-
-Load the kernel, and boot the system as follows:
-
- 1. Get the kernel (vmlinux) file from the tmp/deploy/images/edgerouter
-    directory, and make them available on your TFTP server.
-
- 2. Connect the board's first serial port to your workstation and then start up
-    your favourite serial terminal so that you will be able to interact with
-    the serial console. If you don't have a favourite, picocom is suggested:
-
-  $ picocom /dev/ttyS0 -b 115200
-
- 3. Power up or reset the board and press a key on the terminal when prompted
-    to get to the U-Boot command line
-
- 4. Set up the environment in U-Boot:
-
- => setenv ipaddr <board ip>
- => setenv serverip <tftp server ip>
-
- 5. Download the kernel and boot:
-
- => tftp tftp $loadaddr vmlinux
- => bootoctlinux $loadaddr coremask=0x3 root=/dev/nfs rw nfsroot=<nfsroot ip>:<rootfs path> ip=<board ip>:<server ip>:<gateway ip>:<netmask>:edgerouter:eth0:off mtdparts=phys_mapped_flash:512k(boot0),512k(boot1),64k@3072k(eeprom)
-
---- Booting from USB root ---
-
-To boot from the USB disk, you either need to remove it from the edgerouter
-box and populate it from another computer, or use a previously booted NFS
-image and populate from the edgerouter itself.
-
-Type 1: Mounted USB disk
-------------------------
-
-To boot from the USB disk there are two available partitions on the factory
-USB storage. The rest of this guide assumes that these partitions are left
-intact. If you change the partition scheme, you must update your boot method
-appropriately.
-
-The standard partitions are:
-
-  - 1: vfat partition containing factory kernels
-  - 2: ext3 partition for the root filesystem.
-
-You can place the kernel on either partition 1, or partition 2, but the roofs
-must go on partition 2 (due to its size).
-
-Note: If you place the kernel on the ext3 partition, you must re-create the
-      ext3 filesystem, since the factory u-boot can only handle 128 byte inodes and
-      cannot read the partition otherwise.
-
-Steps:
-
- 1. Remove the USB disk from the edgerouter and insert it into a computer
-    that has access to your build artifacts.
-
- 2. Copy the kernel image to the USB storage (assuming discovered as 'sdb' on
-    the development machine):
-
-    2a) if booting from vfat
- 
-        # mount /dev/sdb1 /mnt
-        # cp tmp/deploy/images/edgerouter/vmlinux /mnt
-        # umount /mnt
-
-    2b) if booting from ext3
-
-        # mkfs.ext3 -I 128 /dev/sdb2
-        # mount /dev/sdb2 /mnt
-        # mkdir /mnt/boot
-        # cp tmp/deploy/images/edgerouter/vmlinux /mnt/boot
-        # umount /mnt
-
- 3. Extract the rootfs to the USB storage ext3 partition
-
-        # mount /dev/sdb2 /mnt
-        # tar -xvjpf core-image-minimal-XXX.tar.bz2 -C /mnt
-        # umount /mnt
-
- 4. Reboot the board and press a key on the terminal when prompted to get to the U-Boot
-    command line:
-
- 5. Load the kernel and boot:
-
-    5a) vfat boot
-
-         => fatload usb 0:1 $loadaddr vmlinux
-
-    5b) ext3 boot
-
-         => ext2load usb 0:2 $loadaddr boot/vmlinux
- 
-    => bootoctlinux $loadaddr coremask=0x3 root=/dev/sda2 rw rootwait mtdparts=phys_mapped_flash:512k(boot0),512k(boot1),64k@3072k(eeprom)
- 
-
-Type 2: NFS
------------
-
-Note: If you place the kernel on the ext3 partition, you must re-create the
-      ext3 filesystem, since the factory u-boot can only handle 128 byte inodes and
-      cannot read the partition otherwise.
-
-      These boot instructions assume that you have recreated the ext3 filesystem with
-      128 byte inodes, you have an updated uboot or you are running and image capable
-      of making the filesystem on the board itself.
-
-
- 1. Boot from NFS root
-
- 2. Mount the USB disk partition 2 and then extract the contents of
-    tmp/deploy/core-image-XXXX.tar.bz2 into it.
-
-    Before starting, copy core-image-minimal-xxx.tar.bz2 and vmlinux into
-    rootfs path on your workstation.
-
-    and then,
-  
-      # mount /dev/sda2 /media/sda2
-      # tar -xvjpf core-image-minimal-XXX.tar.bz2 -C /media/sda2
-      # cp vmlinux /media/sda2/boot/vmlinux
-      # umount /media/sda2
-      # reboot
-
- 3. Reboot the board and press a key on the terminal when prompted to get to the U-Boot
-    command line:
-
-    # reboot
-
- 4. Load the kernel and boot:
-
-      => ext2load usb 0:2 $loadaddr boot/vmlinux
-      => bootoctlinux $loadaddr coremask=0x3 root=/dev/sda2 rw rootwait mtdparts=phys_mapped_flash:512k(boot0),512k(boot1),64k@3072k(eeprom)
diff --git a/README.tizen-distro b/README.tizen-distro
deleted file mode 100644
index e32ce5cf0d..0000000000
--- a/README.tizen-distro
+++ /dev/null
@@ -1,50 +0,0 @@
-About tizen-distro
-==================
-
-tizen-distro is a combination of several different components in a
-single repository:
-- bitbake
-- openembedded-core
-- meta-openembedded
-- meta-qt5
-- meta-tizen
-
-The top-level directory comes from openembedded-core, everything else
-is in its own sub-directory. tizen-distro gets updated by copying
-importing patches from the component's repostories. Please submit
-patches against those instead of tizen-distro.
-
-Updating tizen-distro
-=====================
-
-Everyone with a copy of the tizen-distro repository can use
-scripts/combo-layer to import patches from the components. That works
-because the "last_revision" property which gets changed after each
-import gets committed to the combined repostory.
-
-First, copy conf/combo-layer-local-sample.conf into
-conf/combo-layer-local.conf and set the paths for each component
-repository to a suitable location.
-
-Then run:
-- "scripts/combo-layer init" (only once)
-- "scripts/combo-layer update <component>" where <component> is either one of
-  components above (for updating just that one) or empty (for updating all)
-
-Branching tizen-distro
-======================
-
-Each branch in tizen-distro tracks one branch in each component. To
-create a new branch:
-- checkout a new branch in tizen-component
-- change the "branch" properties in conf/combo-layer.conf
-- change the branch part in the last_revision sections
-- commit
-- continue as before
-
-This works best if the last imported revision from each component is
-the branching point of that component. Ensure that by updating before
-the components branch. If it is too late, either select patches
-interactively or import too many patches and then drop unwanted ones
-via "git rebase" or "git reset --hard". Remember to keep
-"last_revision" correct when doing that.