On Wednesday 22 February 2023 16:17:32 Tony Dinh wrote:
> Hi Pali,
>
> On Wed, Feb 22, 2023 at 3:40 PM Pali Rohár <p...@kernel.org> wrote:
> >
> > 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 <p...@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 <p...@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 <p...@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 <p...@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-p...@kernel.org
> > > > > > > > >
> > > > > > > > > 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 <mibo...@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.
> >
> Argh! I misremember that boot flow, it must have been for another SoC.
> Then I guess I have to look at the board again to see if there is any
> jumper/switch... Perhaps the other way is to run in the BootROM
> debugging prompt and set the boot device to NAND?
Hm... You can try it. But when I tried on A385 to set boot device to
SPI-NOR from debugging prompt it did not work and I suspect bug in
BootROM. But maybe setting boot device to NAND would work. Who knows.
> > > >
> > > > > 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.
>
> Thanks, that was it. I did configure the board incorrectly :) I need
> CONFIG_NAND_PXA3XX which selects SYS_NAND_SELF_INIT.
Perfect! Anyway for booting from NAND you do not have CONFIG_NAND_PXA3XX
support. You need CONFIG_NAND_PXA3XX if you want to access NAND from
u-boot (e.g. for writing bootloder there; so you need it at least once).
> Thanks,
> Tony
>
> > > >
> > > > 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
