Blame view

doc/README.korat 3.39 KB
6433fa202   Larry Johnson   ppc4xx: Updates t...
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
  The Korat board has two NOR flashes, FLASH0 and FLASH1, which are connected to
  chip select 0 and 1, respectively.  FLASH0 contains 16 MiB, and is mapped to
  addresses 0xFF000000 - 0xFFFFFFFF as U-Boot Flash Bank #2.  FLASH1 contains
  from 16 to 128 MiB, and is mapped to 0xF?000000 - 0xF7FFFFFF as U-Boot Flash
  Bank #1 (with the starting address depending on the flash size detected at
  runtime).  The write-enable pin on FLASH0 is disabled, so the contents of FLASH0
  cannot be modified in the field.  This also prevents FLASH0 from executing
  commands to return chip information, so its configuration is hard-coded in
  U-Boot.
  
  There are two versions of U-Boot for Korat: "permanent" and "upgradable".  The
  permanent U-Boot is pre-programmed at the top of FLASH0, e.g., at addresses
  0xFFFA0000 - 0xFFFFFFFF for the current 384 KiB size.  The upgradable U-Boot is
  located 256 KiB from the top of FLASH1, e.g. at addresses 0xF7F6000 - 0xF7FC0000
  for the current 384 KiB size.  FLASH1 addresses 0xF7FE0000 - 0xF7FF0000 are
  used for the U-Boot environmental parameters, and addresses 0xF7FC0000 -
  0xF7FDFFFF are used for the redundant copy of the parameters.  These locations
  are used by both versions of U-Boot.
  
  On booting, the permanent U-Boot in FLASH0 begins executing.  After performing
  minimal setup, it monitors the state of the board's Reset switch (GPIO47).  If
  the switch is sensed as open before a timeout period, then U-Boot branches to
  address 0xF7FBFFFC.  This causes the upgradable U-Boot to execute from the
  beginning.  If the switch remains closed thoughout the timeout period, the
  permanent U-Boot activates the on-board buzzer until the switch is sensed as
  opened.  It then continues to execute without branching to FLASH1.  The effect
  of this is that normally the Korat board boots its upgradable U-Boot, but, if
  this has been corrupted, the user can boot the permanent U-Boot, which can then
  be used to erase and reload FLASH1 as needed.
  
  Note that it is not necessary for the permanent U-Boot to have all the latest
  features, but only that it have sufficient functionality (working "tftp",
  "erase", "cp.b", etc.) to repair FLASH1.  Also, the permanent U-Boot makes no
  assumptions about the size of FLASH1 or the size of the upgradable U-Boot: it is
  sufficient that the upgradable U-Boot can be started by a branch to 0xF7FBFFFC.
  
  The build sequence:
2ae182419   Wolfgang Denk   Makefile: move al...
38
39
  	make korat_perm_config
  	make all
6433fa202   Larry Johnson   ppc4xx: Updates t...
40
41
42
43
44
45
  
  builds the permanent U-Boot by selecting loader file "u-boot.lds" and defining
  preprocessor symbol "CONFIG_KORAT_PERMANENT".  The default build:
  
  	make korat_config
  	make all
2ae182419   Wolfgang Denk   Makefile: move al...
46
  creates the upgradable U-Boot by selecting loader file "u-boot-F7FC.lds" and
6433fa202   Larry Johnson   ppc4xx: Updates t...
47
48
49
  leaving preprocessor symbol "CONFIG_KORAT_PERMANENT" undefined.
  
  2008-02-22, Larry Johnson <lrj@acm.org>
f20405e31   Larry Johnson   ppc4xx: Add varia...
50

f20405e31   Larry Johnson   ppc4xx: Add varia...
51
52
53
54
55
56
57
58
59
60
61
  The CompactFlash(R) controller on the Korat board provides a hi-speed USB
  interface.  This may be connected to either a dedicated port on the on-board
  USB controller, or to a USB port on the PowerPC 440EPx processor.  The U-Boot
  environment variable "korat_usbcf" can be used to specify which of these two
  USB host ports is used for CompactFlash.  The valid setting for the variable are
  the strings "pci" and "ppc".  If the variable defined and set to "ppc", then the
  PowerPC USB port is used.  In all other cases the on-board USB controller is
  used, but if "korat_usbcf" is defined but is set to a string other than the two
  valid options, a warning is also issued.
  
  2009-01-28, Larry Johnson <lrj@acm.org>