u-boot.git/drivers/misc, branch v2013.01

x86: Add console command to display CBMEM console buffer

2012-11-30T21:44:03+00:00

This command is useful to allow to observe messages generated by
coreboot and u-boot until present. In particular it is handy when
u-boot is instrumented to fall through into console mode on startup
errors.

Signed-off-by: Vadim Bendebury 
Signed-off-by: Simon Glass

x86: Add CBMEM console driver for coreboot

2012-11-30T21:44:03+00:00

This patch builds upon the recently introduced CBMEM console
feature of coreboot.

CBMEM console uses a memry area allocated by coreboot to store
the console output. The memory area has a certain structure,
which allows to determine where the buffer is, the buffer size
and the location of the pointer in the buffer. This allows
different phases of the firmware (rom based coreboot, ram based
coreboot, u-boot after relocation with this change) to keep
adding text to the same buffer.

Note that this patch introduces a new console driver and adds the
driver to the list of drivers to be used for console output, i.e.
it engages only after u-boot relocates. Usiong CBMEM console for
capturing the pre-relocation console output will be done under a
separate change.

>From Linux, run the cbmem.py utility (which is a part of the coreboot
package) to see the output, e.g.:

vvvvvvvvvvvvvvvvv
SCSI:  AHCI 0001.0300 32 slots 6 ports ? Gbps 0xf impl SATA mode
flags: 64bit ilck stag led pmp pio
...
Magic signature found
Kernel command line: "cros_secure  quiet loglevel=1 console=tty2...
^^^^^^^^^^^^^^^^^

Note that the entire u-boot output fits into the buffer only if
the coreboot log level is reduced from the most verbose. Ether
the buffer size will have to be increased, or the coreboot
verbosity permanently reduced.

Signed-off-by: Vadim Bendebury 
Signed-off-by: Simon Glass

powerpc/mpc8xxx: move LAW code into arch/powerpc/cpu/mpc8xxx

2012-11-26T21:41:22+00:00

It's arch code and not a driver, so move it where it belongs.  When it
originally went into drivers/misc there was no 8xxx CPU directory.

This will make new-SPL support a little easier since we can keep the CPU
stuff together and not need to pull stuff in from drivers/misc.

Signed-off-by: Scott Wood 
Cc: Andy Fleming

pmic: Move pmic related code to ./drivers/power directory

2012-11-14T10:21:09+00:00

The PMIC framework has been moved to its more natural place
./drivers/power from ./drivers/misc directory.

Signed-off-by: Lukasz Majewski 
Signed-off-by: Kyungmin Park

pmic: Extend PMIC framework to support multiple instances of PMIC devices

2012-11-14T10:21:09+00:00

The PMIC framework has been extended to support multiple instances of
the variety of devices responsible for power management.
This change allows supporting of e.g. fuel gauge, charger, MUIC (Micro USB
Interface Circuit).
Power related includes have been moved to ./include/power directory.
This is a first of a series of patches - in the future "pmic" will be
replaced with "power".

Two important issues:
1. The PMIC needs to be initialized just after malloc is configured
2. It uses list to hold information about available PMIC devices

Signed-off-by: Lukasz Majewski 
Signed-off-by: Kyungmin Park 
Cc: Stefano Babic

pmic:max8997: Switch the MAX8997 PMIC to be used with multibus I2C

2012-11-14T10:21:07+00:00

PMIC MAX8997 is now ready to work with single and multibus soft I2C
implementation.

Signed-off-by: Lukasz Majewski 
Signed-off-by: Kyungmin Park

pmic:i2c: Add I2C sensor byte order (big/little) to PMIC framework

2012-11-14T10:21:07+00:00

Since the pmic_reg_read is the u32 value, the order in which bytes
are placed to form u32 value is important.

Support for big and little sensor endianess is added.

Moreover calls to [leXX|beXX]_to_cpu have been added to support
little and big endian SoCs.

Signed-off-by: Lukasz Majewski 
Signed-off-by: Kyungmin Park

pmic:i2c: Handle PMIC I2C transmission comprising of two bytes

2012-11-14T10:21:07+00:00

This patch adds support for proper handling of a PMIC I2C transmission
comprising of two bytes.

Signed-off-by: Lukasz Majewski 
Signed-off-by: Kyungmin Park 
Cc: Stefano Babic

powerpc/corenet_ds: Slave module for boot from PCIE

2012-08-23T15:24:15+00:00

When boot from PCIE, slave's core should be in holdoff after powered on for
some specific requirements. Master will release the slave's core at the
right time by PCIE interface.

Slave's ucode and ENV can be stored in master's memory space, then slave
can fetch them through PCIE interface. For the corenet platform, ucode is
for Fman.

NOTE: Because the slave can not erase, write master's NOR flash by
	  PCIE interface, so it can not modify the ENV parameters stored
	  in master's NOR flash using "saveenv" or other commands.

environment and requirement:

master:
	1. NOR flash for its own u-boot image, ucode and ENV space.
	2. Slave's u-boot image is in master NOR flash.
	3. Put the slave's ucode and ENV into it's own memory space.
	4. Normally boot from local NOR flash.
	5. Configure PCIE system if needed.
slave:
	1. Just has EEPROM for RCW. No flash for u-boot image, ucode and ENV.
	2. Boot location should be set to one PCIE interface by RCW.
	3. RCW should configure the SerDes, PCIE interfaces correctly.
	4. Must set all the cores in holdoff by RCW.
	5. Must be powered on before master's boot.

For the slave module, need to finish these processes:
	1. Set the boot location to one PCIE interface by RCW.
    2. Set a specific TLB entry for the boot process.
	3. Set a LAW entry with the TargetID of one PCIE for the boot.
	4. Set a specific TLB entry in order to fetch ucode and ENV from
	   master.
	5. Set a LAW entry with the TargetID one of the PCIE ports for
	   ucode and ENV.
	6. Slave's u-boot image should be generated specifically by
	   make xxxx_SRIO_PCIE_BOOT_config.
	   This will set SYS_TEXT_BASE=0xFFF80000 and other configurations.

In addition, the processes are very similar between boot from SRIO and
boot from PCIE. Some configurations like the address spaces can be set to
the same. So the module of boot from PCIE was added based on the existing
module of boot from SRIO, and the following changes were needed:
	1. Updated the README.srio-boot-corenet to add descriptions about
	   boot from PCIE, and change the name to
	   README.srio-pcie-boot-corenet.
	2. Changed the compile config "xxxx_SRIOBOOT_SLAVE" to
	   "xxxx_SRIO_PCIE_BOOT", and the image builded with
	   "xxxx_SRIO_PCIE_BOOT" can support both the boot from SRIO and
	   from PCIE.
	3. Updated other macros and documents if needed to add information
	   about boot from PCIE.

Signed-off-by: Liu Gang 
Signed-off-by: Andy Fleming

powerpc/corenet_ds: Get rid of the CONFIG_SRIOBOOT_SLAVE_PORTx macro

2012-08-23T15:24:14+00:00

When compile the slave image for boot from SRIO, no longer need to
specify which SRIO port it will boot from. The code will get this
information from RCW and then finishes corresponding configurations.

This has the following advantages:
	1. No longer need to rebuild an image when change the SRIO port for
	   boot from SRIO, just rewrite the new RCW with selected port,
	   then the code will get the port information by reading new RCW.
	2. It will be easier to support other boot location options, for
	   example, boot from PCIE.

Signed-off-by: Liu Gang 
Signed-off-by: Andy Fleming