HACK: Pass data from firmware to kernel

HACK: Pass data from firmware to kernel

Changes here is an urgent workaround for factory bring up, and should be
reverted or significantly rewritten after the protocol specification between
Chrome OS firmware and kernel is finalized.

R=rongchang@chromium.org
BUG=chromium-os:13609
TEST=none

Committed: http://chrome-svn/viewvc/chromeos?view=rev&revision=0544e9a

[Che-Liang Chiou, 2011-04-06 11:13:21]

This is a preliminarily CL not ready for review yet.

[rongchang, 2011-04-06 11:52:03]

CL, thanks. Before protocol been finalized, the workaround looks fine to me.

http://codereview.chromium.org/6804009/diff/1/lib/chromeos/os_storage.c
File lib/chromeos/os_storage.c (right):

http://codereview.chromium.org/6804009/diff/1/lib/chromeos/os_storage.c#newco...
lib/chromeos/os_storage.c:230: uint32_t	fwid;
fwid & frid are asciiz too

http://codereview.chromium.org/6804009/diff/1/lib/chromeos/os_storage.c#newco...
lib/chromeos/os_storage.c:232: uint32_t	binf[4];
binf[5]

http://codereview.chromium.org/6804009/diff/1/lib/chromeos/os_storage.c#newco...
lib/chromeos/os_storage.c:233: uint32_t	gpio;
gpio[11]

[Che-Liang Chiou, 2011-04-07 11:17:31]

Hi Rong,

I filled in details, and it is ready for review now. PTAL.

http://codereview.chromium.org/6804009/diff/1/lib/chromeos/os_storage.c
File lib/chromeos/os_storage.c (right):

http://codereview.chromium.org/6804009/diff/1/lib/chromeos/os_storage.c#newco...
lib/chromeos/os_storage.c:230: uint32_t	fwid;
On 2011/04/06 11:52:04, rongchang wrote:
> fwid & frid are asciiz too

Done.

http://codereview.chromium.org/6804009/diff/1/lib/chromeos/os_storage.c#newco...
lib/chromeos/os_storage.c:232: uint32_t	binf[4];
On 2011/04/06 11:52:04, rongchang wrote:
> binf[5]

Done.

http://codereview.chromium.org/6804009/diff/1/lib/chromeos/os_storage.c#newco...
lib/chromeos/os_storage.c:233: uint32_t	gpio;
On 2011/04/06 11:52:04, rongchang wrote:
> gpio[11]

Done.

[Vincent Palatin, 2011-04-07 13:26:56]

http://codereview.chromium.org/6804009/diff/4001/arch/arm/lib/bootm.c
File arch/arm/lib/bootm.c (right):

http://codereview.chromium.org/6804009/diff/4001/arch/arm/lib/bootm.c#newcode41
arch/arm/lib/bootm.c:41: #define CONFIG_SETUP_MEMORY_TAGS
As we are also using "mem=" command line parameter, this will declare all memory
banks twice in the meminfo kernel structure.
Does this really work ?

http://codereview.chromium.org/6804009/diff/4001/arch/arm/lib/bootm.c#newcode289
arch/arm/lib/bootm.c:289: if (i == CONFIG_NR_DRAM_BANKS - 1)
IMHO it would be as easy and less hackish to add a custom tag with your custom
firmware information in the atag chained list.

[Che-Liang Chiou, 2011-04-08 07:41:15]

Hi Vincent,

Thanks for comments. Please take a look.

http://codereview.chromium.org/6804009/diff/4001/arch/arm/lib/bootm.c
File arch/arm/lib/bootm.c (right):

http://codereview.chromium.org/6804009/diff/4001/arch/arm/lib/bootm.c#newcode41
arch/arm/lib/bootm.c:41: #define CONFIG_SETUP_MEMORY_TAGS
On 2011/04/07 13:26:56, Vincent Palatin wrote:
> As we are also using "mem=" command line parameter, this will declare all
memory
> banks twice in the meminfo kernel structure.
> Does this really work ?

Good point. Thanks a lot. I will use "mem=" then.

By the way, I have another question:
We setup "mem=" twice in bootargs "mem=384M@0M nvmem=128M@384M mem=512M@512M"
when booting kernel. Does that mean the kernel will try the first and then the
second?

http://codereview.chromium.org/6804009/diff/4001/arch/arm/lib/bootm.c#newcode289
arch/arm/lib/bootm.c:289: if (i == CONFIG_NR_DRAM_BANKS - 1)
On 2011/04/07 13:26:56, Vincent Palatin wrote:
> IMHO it would be as easy and less hackish to add a custom tag with your custom
> firmware information in the atag chained list.

I was not sure whether kernel treat unrecognized ATAGs (drop it or ignore it?).
Do you have an idea about that?

[Vincent Palatin, 2011-04-08 12:34:13]

> By the way, I have another question:
> We setup "mem=" twice in bootargs "mem=384M@0M nvmem=128M@384M mem=512M@512M"
> when booting kernel. Does that mean the kernel will try the first and then the
> second?

No, this means the 1GB of RAM of the Tegra platform is split into 3 areas :
- 384 MB for the kernel heap
- then, 128MB for the display framebuffer
- and the remaining 512MB as a second bank for the kernel heap

http://codereview.chromium.org/6804009/diff/4001/arch/arm/lib/bootm.c#newcode289
> arch/arm/lib/bootm.c:289: if (i == CONFIG_NR_DRAM_BANKS - 1)
> On 2011/04/07 13:26:56, Vincent Palatin wrote:
> > IMHO it would be as easy and less hackish to add a custom tag with your
custom
> > firmware information in the atag chained list.
> 
> I was not sure whether kernel treat unrecognized ATAGs (drop it or ignore
it?).
> Do you have an idea about that?

The kernel will ignore them.
By the way, for both method (reserved memory at the end of RAM or ATAGs), I
think you will end up doing a kernel patch to read back the data of the kernel
side. So the ATAG implementation is easier, you just need to add the
"__tagtable" declaration with its corresponding callback.