[RFC] new board VoCore2
I am trying to extend support to a new board "VoCore2" whose specs can be found here: https://vocore.io/v2.html Port is concerning the "ultimate" board which has all connectors in place for SD, USB and Ethernet. This board comes with a paleolithic (1.3.0) version of u-boot and I'm trying to upgrade to a recent one also because I need to implement "automatic upgrade" (possibly using RAUC, but that is another story).
Port is working and able to boot Linuz, but it is not ready for inclusion for several reasons and I would like to have expert advice on how to tackle shortcomings, as advised by stefanro on IRC:
6:49:14 AM - stefanro: mcon: Please submit the patches directly to the list, with me (and other MIPS / MT7628/88 experts - Daniel etc) on Cc. If you feel the patches are not ready for integration, then you can mark them as "RFC" in the subject.
Problematic areas I see (side from possible code style issues) are: 1) I added support for a new SPI NOR Flash and that should, probably, be a separate patch. 2) I added support for SPI NOR partitioning and I'm unsure if that should be in the "board definition". 3) SPI NOR partitioning is actually duplicated in ENV var (mtdparts) and in Device Tree; I didn't find how to read it directly from DT. 4) Board also has SD, handled via MTK_SD driver, but I've been unable to make it work. 5) Current binary is rather big and I would like to shrink it a bit, if possible.
Any hint/criticism/advice would be VERY welcome. Thanks in Advance Mauro Condarelli
Hi Mauro,
On 15.12.19 11:20, Mauro Condarelli wrote:
I am trying to extend support to a new board "VoCore2" whose specs can be found here: https://vocore.io/v2.html
Nice. Thanks for working on this.
Port is concerning the "ultimate" board which has all connectors in place for SD, USB and Ethernet. This board comes with a paleolithic (1.3.0) version of u-boot and I'm trying to upgrade to a recent one also because I need to implement "automatic upgrade" (possibly using RAUC, but that is another story).
Port is working and able to boot Linuz, but it is not ready for inclusion for several reasons and I would like to have expert advice on how to tackle shortcomings, as advised by stefanro on IRC:
6:49:14 AM - stefanro: mcon: Please submit the patches directly to the list, with me (and other MIPS / MT7628/88 experts - Daniel etc) on Cc. If you feel the patches are not ready for integration, then you can mark them as "RFC" in the subject.
Problematic areas I see (side from possible code style issues) are:
- I added support for a new SPI NOR Flash and that should, probably, be
a separate patch.
Yes, please.
- I added support for SPI NOR partitioning and I'm unsure if that
should be in the "board definition". 3) SPI NOR partitioning is actually duplicated in ENV var (mtdparts) and in Device Tree; I didn't find how to read it directly from DT.
When you pass the MTD partitioning via kernel cmdline "mtdparts=...", which can be generated by U-Boot, then there is no need for the DT partitioning.
- Board also has SD, handled via MTK_SD driver, but I've been unable to
make it work.
Then I suggest to exclude it for now.
- Current binary is rather big and I would like to shrink it a bit, if
possible.
Any hint/criticism/advice would be VERY welcome.
The most important comment I have is, please post the patch inline, so that we can easily comment on it. Please also take a look at this page for hints about patch submission:
http://www.denx.de/wiki/view/U-Boot/Patches
Thanks, Stefan
On 12/16/19 8:20 AM, Stefan Roese wrote:
Hi Mauro,
On 15.12.19 11:20, Mauro Condarelli wrote:
I am trying to extend support to a new board "VoCore2" whose specs can be found here: https://vocore.io/v2.html
Nice. Thanks for working on this.
Port is concerning the "ultimate" board which has all connectors in place for SD, USB and Ethernet. This board comes with a paleolithic (1.3.0) version of u-boot and I'm trying to upgrade to a recent one also because I need to implement "automatic upgrade" (possibly using RAUC, but that is another story).
Port is working and able to boot Linuz, but it is not ready for inclusion for several reasons and I would like to have expert advice on how to tackle shortcomings, as advised by stefanro on IRC:
6:49:14 AM - stefanro: mcon: Please submit the patches directly to the list, with me (and other MIPS / MT7628/88 experts - Daniel etc) on Cc. If you feel the patches are not ready for integration, then you can mark them as "RFC" in the subject.
Problematic areas I see (side from possible code style issues) are:
- I added support for a new SPI NOR Flash and that should, probably, be
a separate patch.
Yes, please.
Done.
- I added support for SPI NOR partitioning and I'm unsure if that
should be in the "board definition". 3) SPI NOR partitioning is actually duplicated in ENV var (mtdparts) and in Device Tree; I didn't find how to read it directly from DT.
When you pass the MTD partitioning via kernel cmdline "mtdparts=...", which can be generated by U-Boot, then there is no need for the DT partitioning.
If I understand You correctly this means to completely remove DT partitioning information and purely rely on "mtdparts" information. I was unaware of this possibility. I'll cross check. Thanks.
- Board also has SD, handled via MTK_SD driver, but I've been unable to
make it work.
Then I suggest to exclude it for now.
I strongly suspect the failure is due to complete inability of VoCore2 to handle MMC/SD power (SD-VCC is hardwired to +3.3V, no way to hard reset SD card other than complete power-down) and clock. I had to patch kernel (5.3.0) mtk_sd.c to disable clock gating (msdc_gate_clock(), msdc_ungate_clock() and msdc_drv_probe(); a rather ugly patch I won't try to send upstream; unfortunately u-boot mtk_sd.c looks very different I think I'll need some help there...) and to add a "regulator-fixed" to DT, but I'm unsure if and how it is supported by u-boot.
I will exclude all this from current patch-set (but it is vital for my project as I will need to save Environment to MMC to enable boot-counters without burning the SPI NOR).
- Current binary is rather big and I would like to shrink it a bit, if
possible.
Any hint/criticism/advice would be VERY welcome.
The most important comment I have is, please post the patch inline, so that we can easily comment on it. Please also take a look at this page for hints about patch submission:
Reading it now. I will reformat patches using a different branch and condensing them into logically coherent lumps. It will take some time.
Thanks, Stefan
Regards Mauro
participants (2)
-
Mauro Condarelli -
Stefan Roese