On Fri, Aug 27, 2021 at 1:39 PM Marek Behún marek.behun@nic.cz wrote:
On Fri, 27 Aug 2021 13:16:25 +1200 Chris Packham judge.packham@gmail.com wrote:
On Thu, Aug 26, 2021 at 1:46 AM Marek Behún marek.behun@nic.cz wrote:
Hello Stefan and others,
this series adds support for booting Marvell platforms via UART (those bootable with kwboot) at higher baudrates.
Tested on Turris Omnia up to 5.15 MBd, which is 44x faster than 115200 Bd.
The user can direct kwboot to use higher baudrate via the -B option. (BTW this option was there before but did not work with the -b option.)
Only the payload part of the KWB image is uploaded at this higher baudrate. The header part is still uploaded at 115200 Bd, since the code that changes baudrate is injected into header as a binary extension. (The payload part makes up majority of the binary, though. On Turris Omnia the payload currently makes ~87%.)
The series also contains various other fixes, refactors and improvements of the code, upon which the main change is done.
Marek & Pali
What tree/sha is this series based on. I've tried to apply them out of patchwork and it fails at "tools: kwbimage: Simplify iteration over version 1 optional headers"
Applies to master and to u-boot-marvell, but you need the 6 additional patches for kwbimage/kwboot that are on patchwork but not yet applied to u-boot-marvell: https://patchwork.ozlabs.org/project/uboot/list/?series=257577 https://patchwork.ozlabs.org/project/uboot/patch/20210817050320.11983-1-xypr... https://patchwork.ozlabs.org/project/uboot/patch/20210817051158.13283-1-xypr...
Also some more fixes were yet needed, which I will sent in v2.
To make it simpler for you I pushed v2 into https://gitlab.nic.cz/turris/turris-omnia-uboot branch kwboot-baudrate-improvements
Thanks. I took it for a spin on the x530. In terms of regression testing the default behaviour is good.
The higher speed settings weren't so good. I started with 3125000 and that doesn't get onto the 2nd part of the download, same for 1152000 and 4000000 (I stopped trying higher speeds at that point). Using 230400 and 460800 it does make it through the 2nd part of the download but when I go back on to the console it appears to be unresponsive.
All of this could be down to the serial hardware in my system (the x530 uses a real RS232 interface not a TTL) and I have had problems with the MosChip USB-Serial adapter in my test PC in the past. I wouldn't reject this series based on me not being able to get it working, the important thing for me is the default behaviour at the standard baudrate which is good.
One usability thing I'd like to see is retaining support for -t (I use that quite a lot when recovering a system). Ideally we'd still be able to drop into the console at 115200 once the download is complete.
Marek