Differences

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

--- swarren_brain_dump [2011/11/20 05:11] – Removed comment intended for email swarren
+++ swarren_brain_dump [2012/12/26 07:01] (current) – [Using a GPT partition table] stuw
@@ Line 1: / Line 1: @@
 ====== Introduction ======
-So, I just got an AC100 and started hacking on it, intending to do stuff
+So, I (Stephen Warren/srwarren/swarren) just got an AC100 and started hacking on it, intending to do stuff
 like getting mainline U-Boot and a mainline kernel running. I learned a
 lot, and figured out some stuff that isn't in the wiki, even if it is in
@@ Line 52: / Line 52: @@
   sudo ./nvflash -r ${downloads}
-(For correctness, you should probably add "--odmdata 0x200c0000" to all
+(For correctness, you should probably add "--odmdata 0x800c0085" to all
 the nvflash commands. See
 http://nv-tegra.nvidia.com/gitweb/?p=linux-2.6.git;a=blob;f=arch/arm/mach-tegra/odm_kit/query/harmony/tegra_devkit_custopt.h;h=1ec7010911454f19a5018952fd245785a62c59ad;hb=0e52d7fe25b11a656c376a37890be219470661fb
@@ Line 75: / Line 75: @@
   cp ac100.bct ac100.bct.orig
-  dd if=/dev/zero of=ac100.bct seek=2704 bs=48 count=1 conv=notrunc
+  dd if=/dev/zero of=ac100.bct seek=2704 bs=1 count=48 conv=notrunc
 If you don't nvflash might fail later with e.g.:
@@ Line 87: / Line 87: @@
 (as of 2011/11/19)
+(2012/01/13 UPDATE: most of the patches mentioned are upstream now, see [[uboot]] for the temporary tree with a known working version -- paulf)
 Mainline U-Boot has some Tegra support now. There's quite a bit of
@@ Line 102: / Line 104: @@
 patchwork linked above.
+<code>
 tegra2: Add support for Paz00 (Toshiba AC100)
 tegra2: Fix conflicting pinmux for UARTA
@@ Line 128: / Line 131: @@
 tegra2: Move board_mmc_init into board files
 disk: part_efi: fix regression due to incorrect buffer usage
+</code>
 ====== Running an updated U-Boot from RAM ======
@@ Line 144: / Line 147: @@
 You can use this command:
-  sudo ./nvflash --bl bootloader.bin --bct ac100.bct --odmdata 0x200c0000 --download 4 ~/git_wa/u-boot/u-boot.bin
+  sudo ./nvflash --bl bootloader.bin --bct ac100.bct --odmdata 0x800c0085 --download 4 ~/git_wa/u-boot/u-boot.bin
 Note: This works for me now. It did not work for me before when ALL of
@@ Line 214: / Line 217: @@
 and ran the following nvflash command to write this to the AC100:
   bin=bootloader.bin
   cfg=flash.cfg
   bct=ac100.bct
-  odm=0x200c0000
+  odm=0x800c0085
   sudo ./nvflash \
@@ Line 241: / Line 244: @@
 The MMC device has two 1MiB "boot sectors" at the start.
+**Note** from stuw: some ac100 have two 2Mib "boot sectors"
 Note that the term "boot sectors" comes from a flash memory background,
@@ Line 260: / Line 264: @@
 In particular, the U-Boot command to read the first sector in the MMC:
+  mmc dev 0
   mmc read ${loadaddr} 0 1
 actually reads from the first sector of the "general" area /after/ the
-boot-sectors.
+boot-sectors. However, you can access the boot-sectors by providing an extra parameter to "mmc dev":
+  mmc dev 0 1 # First boot sector
+  mmc dev 0 2 # Second boot sector
+If an MMC device had "general purpose" partitions built-in, I imagine there would be more legal values for the second parameter to "mmc dev".
 Equally, when (mainline) Linux boots, it creates the following device nodes:
@@ Line 271: / Line 281: @@
   /dev/mmcblk1      # Everything else: 2..  MiB
-Bear this in mind when trying to validate Flash content from U-Boot or
+If an MMC device had "general purpose" partitions built-in, extra devices would be exposed:
-Linux!
+  /dev/mmcblk1gp0
+  /dev/mmcblk1gp1
+  /dev/mmcblk1gp2
+  /dev/mmcblk1gp3
+Any or all of those Linux devices may have partition tables, which would space device names such as /dev/mmcblk1p1, /dev/mmcblk1boot0p1, /dev/mmcblk1gp0p1.
+Bear this in mind when trying to validate Flash content written by nvflash from U-Boot or Linux!
 ====== Partition table support in U-Boot and the kernel ======
@@ Line 287: / Line 305: @@
 ====== Using a GPT partition table ======
-Given the existence of MMC boot-sectors, and the fact this limits the
+Given the existence of MMC boot-sectors, and the fact both U-Boot and Linux expose separate devices for each of the boot partitions and the rest of the MMC (the "main" partition), I suggest creating a GPT at 2M into the device (i.e. at the start of the main portion of the flash after the boot sectors and covering until the end of the device. Then, write the BCT, Tegra PT, and bootloader into the first (or both) bootsector(s). This keeps the GPT-based and Tegra-PT-based portions of the flash completely separate. An advantage here is that the BCT can be stored right at the start of flash, which is where it's supposed to be.
-flash accessed by U-Boot and splits the MMC into multiple devices in
-Linux, I suggest creating a GPT at 2M into the device and covering until
-the end of the device. Then, write the BCT, Tegra PT, and bootloader
-into the first (or both) bootsector(s). This keeps the GPT-based and
-Tegra-PT-based portions of the flash completely separate. An advantage
-here is that the BCT can be stored right at the start of flash, which is
-where it's supposed to be.
 A diagram:
@@ Line 306: / Line 317: @@
   |     |        | PT cover this area too.               |
   |     +--------+---------------------------------------+
-  |     | Rest   | Primary GPT                           |
+  |     | Main   | Primary GPT                           |
   |     |        | GPT partition 1                       |
   |     |        | ...                                   |
@@ Line 312: / Line 323: @@
   |     |        | Backup GPT                            |
   +-----+--------+---------------------------------------+
+Additional background: Some/many Tegra devices have a relatively small NAND or SPI flash that's laid out with just the BCT, Tegra PT, EBT sections, i.e. the content of "boot 0" above. Any Linux filesystems are then stored in MMC, and laid out in a standard fashion (e.g. GPT, MBR) without regard for the content of the NAND/SPI boot flash.
 You can create this by:
@@ Line 317: / Line 330: @@
 Write the BCT, Tegra PT, bootloader to flash as I described above.
-Create a disk image for the "Rest" by:
+Create a disk image for the main partition by:
   dd if=/dev/zero of=image.bin bs=16384 count=484864
@@ Line 331: / Line 344: @@
 The following writes the 34 GPT (512-byte) sectors to the start of the
-"rest" part of the MMC:
+main partition of the MMC:
   sudo ./nvflash --bl bootloader.bin --rawdevicewrite 1024 9 image.bin
@@ Line 345: / Line 358: @@
 directly into /dev/mmcblk1boot0 when updating from Linux. Of course,
 this is only for U-Boot updates from a running Linux system, which would
-probably be rare.
+probably be rare. In order to write to /dev/mmcblkXbootY, you'll need disable the "force readonly" flag for the boot partition(s) using "echo 0 > /sys/block/mmcblkXbootY/force_ro". See http://comments.gmane.org/gmane.linux.kernel.mmc/10115.
 If on other Tegra systems, the MMC doesn't have these boot sectors,
@@ Line 361: / Line 374: @@
   |     | GPT Partition 1 "BCT" at sector 256   |
   |     | GPT Partition 2 "BOOTLOADER"          |
-  |     | GPT partition 3 LINUX                 |
+  |     | GPT partition 3 "LINUX"               |
   |     | ...                                   |
   |     | Backup GPT                            |
@@ Line 369: / Line 382: @@
 into flash) to match the location that (the "trimslice" branch of)
 cbootimage uses when moving the BCT (search for
-MMC_SECONDARY_BCT_LOCATION_IN_BLOCKS). Also, I /think/ the Tegra boot
+MMC_SECONDARY_BCT_LOCATION_IN_BLOCKS in the code). Also, I /think/ the Tegra boot
 ROM searches for the BCT at the start of each "journal block" on the
 MMC, and apparently they're 128K in size.
@@ Line 379: / Line 392: @@
 a) Use bct_dump (from cbootimage) to create ac100-cboot.cfg.
-b) Edit ac100-cboot.cfg to add the following line at the end:
+b) Edit ac100-cboot.cfg to add the following line **at the end**:
   BootLoader    = u-boot.bin,0x00108000,0x00108000,Complete;