Hi everyone,
I just finished porting Coreboot v4 to the PC Engines Alix.2d3 board ( http://www.pcengines.ch/alix2d3.htm), using the sources for alix.2c3 from coreboot-v3 and alix.1c from coreboot-v4. It boots Linux correctly using the FILO payload. So far everything's okay.
For reviews, I attached a patch which should be applied against the current coreboot [r5738] trunk. Please tell me what you think.
Known issue with Voyage Linux 0.6 (http://linux.voyage.hk/): The front LEDs won't work out of the box. That's because the Voyage Linux kernel (2.6.26) uses a hard-coded GPIO address, instead of looking at the right one on the PCI bus. Please update this particular driver to a more recent (and correct) version and you should be ok.
Board support information for the wiki:
Vendor: PC Engines Mainboard: ALIX.2D3 Northbridge: AMD Geode LX Southbridge: AMD Geode CS5536 Super I/O: - CPU: AMD Geode LX Socket: - Status: OK ROM Chip Package: TSOP ROM Chip Protocol: LPC ROM Chip Socketed: N Supported by flashrom: Y VCS: 4
Best regards,
Am 24.08.2010 01:09, schrieb Aurélien:
I just finished porting Coreboot v4 to the PC Engines Alix.2d3 board (http://www.pcengines.ch/alix2d3.htm), using the sources for alix.2c3 from coreboot-v3 and alix.1c from coreboot-v4. It boots Linux correctly using the FILO payload. So far everything's okay.
Thank you for improving coreboot!
For reviews, I attached a patch which should be applied against the current coreboot [r5738] trunk. Please tell me what you think.
Please note that for legal reasons we require contributors to sign the Developer's Certificate of Origin. The procedure can be found at http://www.coreboot.org/Development_Guidelines#Sign-off_Procedure
Regards, Patrick
On Tue, Aug 24, 2010 at 7:51 AM, Patrick Georgi patrick@georgi-clan.dewrote:
For reviews, I attached a patch which should be applied against the current coreboot [r5738] trunk. Please tell me what you think.
Please note that for legal reasons we require contributors to sign the Developer's Certificate of Origin. The procedure can be found at http://www.coreboot.org/Development_Guidelines#Sign-off_Procedure
Ok, so here it is:
* Adds support for PC Engines Alix.2D(1)3 board to Coreboot. * DRAM initialization done message is now printed in debug-mode only, rather than everytime. --- Signed-off-by: Aurélien Guillaume aurelien@iwi.me
The attached patch is different from the first one (enabled secondary COM port, since it is wired on Alix.2D13, and does not seem to impact Alix.2D3)
Notes: - Between Alix.2D3 and Alix.2D13, internal COM, I2C headers, USB headers and RTC battery were added. The board is the same. I think nothing should be changed, except perhaps enabling/disabling COM2, but it seems too complex to be justified for now. - Alix.2D2 seems to be the same board with one less LAN and one more miniPCI slot, and should be quite easy to support (just change IRQ routing), but I have no means to test it. Does anyone own this board/is willing to test it ? - Based on PC Engine's changelog, this _may_ work on Alix.2C3. Again, anyone willing to test ?
Best regards,
Am 24.08.2010 10:10, schrieb Aurélien:
- Adds support for PC Engines Alix.2D(1)3 board to Coreboot.
- DRAM initialization done message is now printed in debug-mode only,
rather than everytime.
Signed-off-by: Aurélien Guillaume aurelien@iwi.me
Acked-by: Patrick Georgi patrick.georgi@coresystems.de
and committed in r5739, with some minor whitespace changes in devicetree.cb.
Thank you for this contribution. If you want to solve a little (but very useful) problem, could you please try to run coreboot without the RAMBASE definition in your mainboard's Kconfig? Maybe it works as is, maybe it requires further changes in the chipset code, but even knowing that would be helpful.
Thanks, Patrick
On Tue, Aug 24, 2010 at 2:59 PM, Patrick Georgi patrick@georgi-clan.dewrote:
Am 24.08.2010 10:10, schrieb Aurélien:
- Adds support for PC Engines Alix.2D(1)3 board to Coreboot.
- DRAM initialization done message is now printed in debug-mode only,
rather than everytime.
Signed-off-by: Aurélien Guillaume aurelien@iwi.me
Acked-by: Patrick Georgi patrick.georgi@coresystems.de
and committed in r5739, with some minor whitespace changes in devicetree.cb.
Thanks :)
Thank you for this contribution. If you want to solve a little (but very useful) problem, could you please try to run coreboot without the RAMBASE definition in your mainboard's Kconfig? Maybe it works as is, maybe it requires further changes in the chipset code, but even knowing that would be helpful.
Does not work for the moment. RAMBASE got overwritten to 0x100000 by the config scripts (i think that's intended).
Booting with this image leaves me with: [...] POST: 0x02 POST 02 Past wbinvd Loading stage image. Stage: loading fallback/coreboot_ram @ 0x100000 (114688 bytes), entry @ 0x100000 lzma: Decoding error = 1 CBFS: LZMA decompression failed! Loading stage failed! --- hangs here ---
POST card shows 0x11.
Could you explain me what is the exact problem with RAMBASE @0x4000 and why should/should'nt this work ?
Am 25.08.2010 14:43, schrieb Aurélien:
Does not work for the moment. RAMBASE got overwritten to 0x100000 by the config scripts (i think that's intended).
Thank you for testing. Yes, 1MB is the default value for RAMBASE.
Booting with this image leaves me with: [...] POST: 0x02 POST 02 Past wbinvd Loading stage image. Stage: loading fallback/coreboot_ram @ 0x100000 (114688 bytes), entry @ 0x100000 lzma: Decoding error = 1 CBFS: LZMA decompression failed! Loading stage failed! --- hangs here ---
This is the first time that RAM beyond 1MB is seriously used. On other Geode boards, some MSRs weren't set up early enough, so >1MB wasn't reachable. http://patchwork.coreboot.org/patch/1485/ provides a partial fix, but I suspect that the LX code has similar issues.
POST card shows 0x11.
Could you explain me what is the exact problem with RAMBASE @0x4000 and why should/should'nt this work ?
Since there are chipsets for which coreboot just don't fit below 1MB, we moved everything to 1MB where possible. We're trying to cut down on configuration options, to make boards more uniform, so I'm using every chance I see to ask people to try if we can get rid of their "non-standard" configurations.
Having less options helps with maintenance, as there are less surprises when changes are made (and suddenly a class of boards, eg. those with RAMBASE=0x4000, break - that already happened). It should also help with new boards, as there are fewer things to take care of, if such options are removed.
Regards, Patrick
On Wed, Aug 25, 2010 at 5:27 PM, Patrick Georgi patrick@georgi-clan.dewrote:
Am 25.08.2010 14:43, schrieb Aurélien:
Stage: loading fallback/coreboot_ram @ 0x100000 (114688 bytes), entry @ 0x100000 lzma: Decoding error = 1 CBFS: LZMA decompression failed! Loading stage failed! --- hangs here ---
This is the first time that RAM beyond 1MB is seriously used. On other Geode boards, some MSRs weren't set up early enough, so >1MB wasn't reachable. http://patchwork.coreboot.org/patch/1485/ provides a partial fix, but I suspect that the LX code has similar issues.
Hum, i'm not yet able to help here, I don't know sufficiently the LX chipset, nor do I have the time to dwell on this particular topic.
I have in mind a particular application for this board, and I want to be able to catch very early events (like a press on the only button on the mainboard and/or a series of power cycle (4 power cycles without booting the kernel for example) to trigger the boot of an alternate kernel/partition. I think of implementing this in a filo-derivative, which I should happily contribute, if it happens to interest someone.
For now, coreboot boots this board correctly.
Ah, one last thing: I posted the board support details for the Wiki in a previous post. Can someone with the rights to do so update it to reflect the support ?
Thanks.
On Wed, Aug 25, 2010 at 5:27 PM, Patrick Georgi patrick@georgi-clan.dewrote:
Loading stage image. Stage: loading fallback/coreboot_ram @ 0x100000 (114688 bytes), entry @ 0x100000 lzma: Decoding error = 1 CBFS: LZMA decompression failed! Loading stage failed! --- hangs here ---
This is the first time that RAM beyond 1MB is seriously used. On other Geode boards, some MSRs weren't set up early enough, so >1MB wasn't reachable. http://patchwork.coreboot.org/patch/1485/ provides a partial fix, but I suspect that the LX code has similar issues.
In fact, I just realized that this patch works just fine on my board (though this code has been moved to src/cpu/model_lx, which confused me.
~~~ Loading stage image. Stage: loading fallback/coreboot_ram @ 0x100000 (114688 bytes), entry @ 0x100000 Stage: done loading. Jumping to image. ~~~
So, here's the patch. I suppose the RAM may be incorrectly setup initially (size...), but it is re-setup just after by the northbridge init code, so I think it's just fine.
Also, who's responsible for updating the wiki ? Since this is a newly supported board, I think it should appear in v4 support list. I gave the details in a previous post. I can update it myself, but I'll need an account, and I don't think it's really worth the trouble, just for one board.
Signed-off-by: Aurélien Guillaume aurelien@iwi.me
Thanks :)
On Mon, Aug 30, 2010 at 8:29 PM, Aurélien footplus@gmail.com wrote:
In fact, I just realized that this patch works just fine on my board (though this code has been moved to src/cpu/model_lx, which confused me.
Please also note that, since the updates have been made into model_lx, they apply to all the boards based on Geode LX.
Unfortunately, I do not have the means to test every board. So, there's two solutions:
a) apply the patch as it is, and also remove RAMBASE 0x4000 to all the Geode LX based boards, at the risk of maybe breaking coreboot on them.
b) Place this code in the mainboard-specific romstage.c (if you prefer this, I can make a different patch)
Regards,
Am 30.08.2010 20:37, schrieb Aurélien:
a) apply the patch as it is, and also remove RAMBASE 0x4000 to all the Geode LX based boards, at the risk of maybe breaking coreboot on them.
I think the problem is that it hardcodes assumptions about the installed RAM - which _might_ go wrong if there's less memory installed (or maybe not, because it's never touched). At least if we're talking about the same patch :-)
Maybe it's enough to add a big, fat comment to the line in question "WARNING/TODO/FIXME/XXX: hardcodes assumptions about installed RAM. If romstage fails, look here!" ;-)
b) Place this code in the mainboard-specific romstage.c (if you prefer this, I can make a different patch)
I'd prefer global code.
Patrick
On Mon, Aug 30, 2010 at 9:39 PM, Patrick Georgi patrick@georgi-clan.dewrote:
Am 30.08.2010 20:37, schrieb Aurélien:
a) apply the patch as it is, and also remove RAMBASE 0x4000 to all the Geode LX based boards, at the risk of maybe breaking coreboot on them.
I think the problem is that it hardcodes assumptions about the installed RAM - which _might_ go wrong if there's less memory installed (or maybe not, because it's never touched). At least if we're talking about the same patch :-)
I was talking about the patch attached to my message, which is derived from the patch you mentioned before. But, mine does not removes the RAMBASE setting from other LX-based boards' Kconfig, so do not commit it yet, please. Furthermore, I have another idea, which I think is cleaner. I'll check if it's possible to implement.
Maybe it's enough to add a big, fat comment to the line in question
"WARNING/TODO/FIXME/XXX: hardcodes assumptions about installed RAM. If romstage fails, look here!" ;-)
b) Place this code in the mainboard-specific romstage.c (if you prefer this, I can make a different patch)
I'd prefer global code.
Ok, I'll try to make a patch following these guidelines and resubmit it after some testing. I'll also remove the RAMBASE @0x4000 from the Kconfig of LX-based boards, if mine works.
Best regards,
-
Aurélien -
Patrick Georgi