Re: kwboot: Marvell Dove UART booting

["Pali Rohár" <pali@kernel.org>]

On Saturday 01 January 2022 16:00:27 Tony Dinh wrote:
> Hi Pali
> 
> On Sat, Jan 1, 2022 at 3:12 PM Pali Rohár <pali@kernel.org> wrote:
> >
> > On Saturday 01 January 2022 14:54:34 Tony Dinh wrote:
> > > Hi Pali,
> > >
> > > On Sat, Jan 1, 2022 at 1:53 PM Pali Rohár <pali@kernel.org> wrote:
> > > >
> > > > On Sunday 26 December 2021 13:41:03 Tony Dinh wrote:
> > > > > Follow up on the UART booting session before.
> > > > >
> > > > > Thanks for the advice about the Reset Strapping documentation. I've
> > > > > extracted the attachment 88AP510_Reset_Strapping.xls from the HW Spec
> > > > > for Dove at:
> > > > > https://www.kernel.org/doc/html/latest/arm/marvell.html
> > > > >
> > > > > Listed below are the Boot Modes that are relevant to this subject
> > > > > (there are other Boot Modes for SATA, NAND but we are not interested
> > > > > in those):
> > > > >
> > > > > 0x00 Direct boot from SPI
> > > > > 0x01 Boot from SPI with 3 address cycles
> > > > > 0x02 Boot from SPI with 4 address cycles
> > > > > 0x0E Boot from UART0 using Xmodem
> > > > > 0x0F Boot from UART1 using Xmodem
> > > > > 0x10 Open BootROM debug prompt on UART0
> > > > > 0x11 Open BootROM debug prompt on UART1
> > > > >
> > > > > So it does look like the jumper on this HP T5335z is actually to put
> > > > > the box into BootROM debug mode using 0x10. And from there, we can use
> > > > > 0x0E to put the BootROM into UART0 booting mode.
> > > > >
> > > > > Oddly, I've also tried booting from SPI while at the BootROM debug
> > > > > prompt, but have not been successful with either 0x00, 0x01, or 0x02.
> > > > > I was hoping that it would make testing easier if I could run "Boot
> > > > > from SPI" to boot into Linux without having to remove the jumper.
> > > >
> > > > And which hex mode is activated when jumper is not set to that Debug
> > > > prompt UART mode? You should be able to check current mode by reading
> > > > 0xD00D0214 address which should contain latched sample at reset value.
> > > > E.g. in U-Boot by 'md 0xD00D0214 1' command.
> > >
> > > Without the jumper inserted, it was set to 0x00.
> > >
> > > HP>> md 0xD00D0214 1
> > > d00d0214: 00000000    ....
> >
> > Sample at reset register should not be zero. So it is located at
> > different address. You could try to look into the functional
> > specification...
> 
> It must have been the liquor yesterday :) of course there are other
> settings in this register... it cannot be zero.
> 
> >
> > Maybe internal registers are at space 0xf1000000? Then register is 0xf10d0214
> 
> I think 0xf1000000 is more like it. I've double checked, the Kirkwood
> SatR is 0xF1010030.
> 
> Functional Spec:
> "The BootROM firmware is located on the device’s Read Only Memory
> (ROM), and is executed according to the sample at reset configuration
> bits[4:0] in the Sample at Reset 0 Register (Table 976 p. 959)"
> 
> HP>> md f10D0214 1
> f10d0214: b40a24a1    .$..
> 
> So it looks like the boot mode is 00001?

Seems yes. 30th bit in 0xb40a24a1 is unset, so first boot mode table
from 88AP510_Reset_Strapping.xls applies. Bits [4:0] are 0b00001, so
bootmode is 0x01 - Boot from SPI with 3 address cycles. Which should
correspondent to 'x 0x01' command. If it does not work then BootROM is
broken.

Note that 'x' command is broken in A385 BootROM, so I would not be
surprised if it does not work in other SoCs too...

You can try to figure out at which address is mapped this sample at
reset register when CPU is running that debug boot prompt. Sometimes
this register is R/W, so bootrom can use it as a "cache" for its own
purposes (it does not update hardware). And in case you figure out how
to update it, you could try to invoke BootROM reset to just re-enter
boot sequence... and maybe bootrom starts booting from SPI. Just idea.

> Thanks,
> Tony