On Wednesday 22 February 2023 15:16:06 Tony Dinh wrote:
Hi Pali,
On Wed, Feb 22, 2023 at 3:06 PM Pali Rohár pali@kernel.org wrote:
On Wednesday 22 February 2023 14:16:36 Tony Dinh wrote:
Hi Pali,
On Tue, Feb 21, 2023 at 11:58 PM Pali Rohár pali@kernel.org wrote:
On Tuesday 21 February 2023 21:45:07 Tony Dinh wrote:
Hi Pali,
On Tue, Feb 21, 2023 at 3:14 PM Pali Rohár pali@kernel.org wrote:
On Tuesday 21 February 2023 15:06:16 Tony Dinh wrote: > Hi Pali, > > On Tue, Feb 21, 2023 at 12:22 PM Pali Rohár pali@kernel.org wrote: > > > > This patch series contains various improvements and fixes for existing > > logical errors. Boot phase was adjusted to match behavior of Armada 385 > > BootROM by inspecting and disassembling of BootROM binary dump itself. > > Important information are included in documentation patch for kwboot. > > Most of the changes are untested, hence this patch series is just RFC. > > So please test changes before applying, idealy on SPI, SATA and SD/MMC. > > Nevertheless all patches on github passed CI testing in this PR: > > https://github.com/u-boot/u-boot/pull/275 ... > I went to patchwork and downloaded the series. > https://patchwork.ozlabs.org/project/uboot/patch/20230221201925.9644-2-pali@... > > When I applied the patches set there were some rejections. > <BEGIN LOG> > # patch -p1 < /usr/src/builds-u-boot-marvell/pali_patches/arm-mvebu-Various-fixes.patch > ... FAILED ... > <END LOG> > > I'm on the latest master branch (just did a git pull today). Could > some patches be out of order? > > Thanks, > Tony
Well, that is because DENX mail server is broken and it crashed during processing antispam filter on my some of my patches. So some patches are missing in archive and then applying dependent patches failed.
So ignore patchwork and email patches. Rather fetch changes from the mentioned github pull request https://github.com/u-boot/u-boot/pull/275
You can do it via git command (it fetch it to the new mvebu branch):
git fetch https://github.com/u-boot/u-boot.git refs/pull/275/merge:mvebu
Indeed! That pull request was applied without problem.
So I did a general regression test running rebuilt kwboot binary, and rebuilt u-boot images for these 2 Marvell boards:
Thecus N2350 (Armada 385) Pogo V4 (Kirkwood 88F6192).
So for that part: Tested-by: Tony Dinh mibodhi@gmail.com
All the best, Tony
Thanks for testing! Anyway do you have some A38x board which can boot from SD/MMC, SATA or NAND? This is what is needed to test too. I see that Pogo boots from NAND but it does not use SPL.
I have only one A38x board with NAND: the Thecus N2350. I am creating a new defconfig and will see if I can boot it from the NAND flash.
Ok. And do you have some switch on this board which instruct BootROM to really boot from NAND?
No switch that I can see. So I'm going to erase the u-boot image in SPI to let the BootROM try booting from NAND.
BootROM on 32-bit mvebu SoCs always boots from the location configured by strapping pins. So if you do not have any switch (or possible soldered zero-ohm resistors) on the board then I doubt that BootROM will try to boot from NAND.
By the way, I'm having this build error that CFG_SYS_NAND_BASE is not defined. What should it be for A38x? is it the same for Kirkwood?
All the best, Tony
Is SYS_NAND_BASE really needed? If yet then I think it should be macro MVEBU_NAND_BASE.
The build error looks like this: drivers/mtd/nand/raw/nand.c:15:34: error: ‘CFG_SYS_NAND_BASE’ undeclared here (not in a function); did you mean ‘CFG_SYS_PL310_BASE’? 15 | #define CFG_SYS_NAND_BASE_LIST { CFG_SYS_NAND_BASE }
I see... Maybe you can try to enable SYS_NAND_SELF_INIT.
But on Kirkwood is SYS_NAND_BASE set to the DEFADR_NANDF value which is memory mapping of NAND device via mbus. On Armada devices is not NAND device mbus mapped at all and MVEBU_NAND_BASE points to internal mvebu registers. So I'm quite not sure if it would work.
So lets try with MVEBU_NAND_BASE.
OK.
Thanks, Tony