Dear lists, I have be studying CBFS filesystem these days. Since coreboot only supports IA32 architecture now, the CBFS has hard-coded boot address and all the boot-related code and master header are located at around 0xFFFFFFF0. But as ARM read their first instruction at 0x0, we need change the CBFS filesystem but not destroy IA32 support. When porting to ARM, how should the rom be organized? I have 2 ideas: 1. Totally rewrite the CBFS structure on ARM according to that one on IA32 to meet the requirement of ARM architecture, including move the reset code and bootblock to the start of ROM(at address 0x0) and put all the other components follow them. In this way, we should rewrite the CBFStool and add a new option to CBFStool to tell it the architecture we are using. 2. Use the same structure on IA32 architecture but set the master header's offset to other value than 0x0 so that we can put boot code at the start of rom. Which one should I take or Do we have any better choice? Hope for your help.
Hi Hamo,
I wrote a CBFS design change proposal ~2 years ago which handled such issues just fine, but IIRC nobody had time to comment. I can try to dig it up again.
Regards, Carl-Daniel
Am 10.04.2011 14:49 schrieb Hamo:
Dear lists, I have be studying CBFS filesystem these days. Since coreboot only supports IA32 architecture now, the CBFS has hard-coded boot address and all the boot-related code and master header are located at around 0xFFFFFFF0. But as ARM read their first instruction at 0x0, we need change the CBFS filesystem but not destroy IA32 support. When porting to ARM, how should the rom be organized? I have 2 ideas:
- Totally rewrite the CBFS structure on ARM according to that one on
IA32 to meet the requirement of ARM architecture, including move the reset code and bootblock to the start of ROM(at address 0x0) and put all the other components follow them. In this way, we should rewrite the CBFStool and add a new option to CBFStool to tell it the architecture we are using. 2. Use the same structure on IA32 architecture but set the master header's offset to other value than 0x0 so that we can put boot code at the start of rom. Which one should I take or Do we have any better choice? Hope for your help.
On Sun, Apr 10, 2011 at 11:40 PM, Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
Hi Hamo,
I wrote a CBFS design change proposal ~2 years ago which handled such issues just fine, but IIRC nobody had time to comment. I can try to dig it up again.
Regards, Carl-Daniel
Can you send your change to me? Thanks.
Am 10.04.2011 14:49 schrieb Hamo:
Dear lists, I have be studying CBFS filesystem these days. Since coreboot only supports IA32 architecture now, the CBFS has hard-coded boot address and all the boot-related code and master header are located at around 0xFFFFFFF0. But as ARM read their first instruction at 0x0, we need change the CBFS filesystem but not destroy IA32 support. When porting to ARM, how should the rom be organized? I have 2 ideas:
- Totally rewrite the CBFS structure on ARM according to that one on
IA32 to meet the requirement of ARM architecture, including move the reset code and bootblock to the start of ROM(at address 0x0) and put all the other components follow them. In this way, we should rewrite the CBFStool and add a new option to CBFStool to tell it the architecture we are using. 2. Use the same structure on IA32 architecture but set the master header's offset to other value than 0x0 so that we can put boot code at the start of rom. Which one should I take or Do we have any better choice? Hope for your help.
On 04/10/2011 08:49 AM, Hamo wrote:
Dear lists, I have be studying CBFS filesystem these days. Since coreboot only supports IA32 architecture now, the CBFS has hard-coded boot address and all the boot-related code and master header are located at around 0xFFFFFFF0. But as ARM read their first instruction at 0x0, we need change the CBFS filesystem but not destroy IA32 support. When porting to ARM, how should the rom be organized? I have 2 ideas:
- Totally rewrite the CBFS structure on ARM according to that one on
IA32 to meet the requirement of ARM architecture, including move the reset code and bootblock to the start of ROM(at address 0x0) and put all the other components follow them. In this way, we should rewrite the CBFStool and add a new option to CBFStool to tell it the architecture we are using. 2. Use the same structure on IA32 architecture but set the master header's offset to other value than 0x0 so that we can put boot code at the start of rom. Which one should I take or Do we have any better choice? Hope for your help.
How about spitting up the code using pre-processing directives? One for arm and one for IA32? Just a thought.
Am 10.04.2011 18:10, schrieb Joseph Smith:
How about spitting up the code using pre-processing directives? One for arm and one for IA32? Just a thought.
AHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH
please. not. more. compile. time. options.
Patrick
On 04/10/2011 12:25 PM, Patrick Georgi wrote:
Am 10.04.2011 18:10, schrieb Joseph Smith:
How about spitting up the code using pre-processing directives? One for arm and one for IA32? Just a thought.
AHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH
please. not. more. compile. time. options.
sorry I guess that is not a good idea then...
-
Carl-Daniel Hailfinger -
Hamo -
Joseph Smith -
Patrick Georgi