Re: [PATCH] cmd: go: Flush cache before jumping to app/image
Hi Mauro, On 12.02.20 14:50, Mauro Condarelli wrote: Hi Stefan, On 2/12/20 2:22 PM, Stefan wrote: Hi Mauro, On 12.02.20 14:09, Mauro Condarelli wrote: Hi Daniel, Hi Stefan, I'll test this ASAP, but, in the meantime, please have a look at the strange (and perhaps related) code in arch/mips/mach-mtmips/cpu.c You are most likely referring to the code in last_stage_init() that also deals with a potential cache issue. Its still unresolved and this "hack" is still needed for a working U-Boot image (e.g. no timeouts in tftp). Yes, I was referring to that strange "D-cache" cleanup. Why not just a cache-flush()? Frankly, I don't remember the exact details. I definitely tested also with cache_flush() but either it introduced too much boot delay or it simply didn't work. This d-cache issue was (is) pretty nasty. Its only partly related to the current issue though as it also deals with "cache" but addresses a different issue. Please test and report back. Done. Confirmed. With new version in SPI NOR I could load (and execute successfully) all versions I had saved on my tftp server. Good. :) If some further testing is useful don't hesitate to ask. I'll send v2 in a minute. Please re-test it and send your tested-by, if this also works for you. Thanks, Stefan
Re: [PATCH v5] Add support for SoM "VoCore2".
On 12.02.20 16:30, Mauro Condarelli wrote: Small patch series to add support for VoCore/VoCore2 board. VoCore is open hardware and runs OpenWrt/LEDE. It has WIFI, USB, UART, 20+ GPIOs but is only one inch square. It will help you to make a smart house, study embedded system or even make the tiniest router in the world. Details about this SoM can be found at "https://vocore.io/v2.html";. Signed-off-by: Mauro Condarelli --- Changes in v5: - Removed unneeded (and wrong) UART2 initialization in board.c - Added network setup. - Removed project-specific code. - Move back environment to SPI NOR. - Changes to environment default settings. - Rebase on current u-boot-mips/testing Changes in v4: - Reverted some overzealous DTS cleaning. - Added support for bootcount Changes in v3: - based on top of Weijie Gao patchset: "[v3,xx/20]Refactor the architecture parts of mt7628" Changes in v2: - Removed some dead code - Changed Author to my full name (no nick) - Removed unwanted fixup to .dts generation (not my call). - Fixed commit message - Fixed various variables/filenames to include Vendor name - Changed Vendor name (Vonger -> Vocore) arch/mips/dts/Makefile | 1 + arch/mips/dts/mt7628a.dtsi | 5 ++ arch/mips/dts/vocore_vocore2.dts | 78 arch/mips/mach-mtmips/Kconfig| 8 +++ board/vocore/vocore2/Kconfig | 12 board/vocore/vocore2/Makefile| 3 + board/vocore/vocore2/board.c | 6 ++ configs/vocore2_defconfig| 103 ++ configs/vocore2_defconfig_ENV_IN_FAT | 104 +++ include/configs/vocore2.h| 61 10 files changed, 381 insertions(+) create mode 100644 arch/mips/dts/vocore_vocore2.dts create mode 100644 board/vocore/vocore2/Kconfig create mode 100644 board/vocore/vocore2/Makefile create mode 100644 board/vocore/vocore2/board.c create mode 100644 configs/vocore2_defconfig create mode 100644 configs/vocore2_defconfig_ENV_IN_FAT create mode 100644 include/configs/vocore2.h Apart from the other comments, the MAINTAINERS file is missing. Please add it in the next patch version. Thanks, Stefan
Re: [PATCH v4 17/20] spl: nor: add lzma decompression support for legacy image
Hi Simon, On 13.02.20 08:40, Simon Goldschmidt wrote: Sorry if it seems I ignored this mail yesterday, I just found it now :) On Wed, Feb 12, 2020 at 10:05 AM Stefan Roese wrote: On 12.02.20 09:57, Weijie Gao wrote: And more general: why do we need to code this in every loader? I think it would be preferrable to have the loader load the binary data and do the decompression (and entry_point assignment) in a central place so that all loaders can benefit from compression. As it is now, we are duplicating code when implementing LZMA in the next loader. I agree with Simon, that it would make sense to move this code into a even more generic location, so that other "loaders" can also use this feature. I know, that I suggested to add it here and I think we can make this move into the common SPL interface at a later point, after this patch set has been integrated. My concern is that we add poor code now and that cleanup at a "later point" just gets forgotten. I understand. To me, this patch looks like another "get the stuff I need in fast" thing, without thinking about overall code quality. Yes it might be more work to do it properly, but in my opinion, the result will be code that is easier to maintain in the long run. I fully agree. But I already pushed Weijie to make many enhancements to the code and I fear that this work gets just too complex (time consuming) right now. As this type of generalization is not restricted on this new lzma implementation, but will very likely touch other features as well. So again, I'm still okay with adding this feature for spi_nor only right now. But if Weijie volunteers to move it to a even more generic location, that would be very welcome of course. ;) Thanks, Stefan
Re: [PATCH v5] Add support for SoM "VoCore2".
On 13.02.20 10:18, Mauro Condarelli wrote: Thanks Stefan. On 2/13/20 7:50 AM, Stefan wrote: On 12.02.20 16:30, Mauro Condarelli wrote: Small patch series to add support for VoCore/VoCore2 board. VoCore is open hardware and runs OpenWrt/LEDE. It has WIFI, USB, UART, 20+ GPIOs but is only one inch square. It will help you to make a smart house, study embedded system or even make the tiniest router in the world. Details about this SoM can be found at "https://vocore.io/v2.html";. Signed-off-by: Mauro Condarelli --- Changes in v5: - Removed unneeded (and wrong) UART2 initialization in board.c - Added network setup. - Removed project-specific code. - Move back environment to SPI NOR. - Changes to environment default settings. - Rebase on current u-boot-mips/testing Changes in v4: - Reverted some overzealous DTS cleaning. - Added support for bootcount Changes in v3: - based on top of Weijie Gao patchset: "[v3,xx/20]Refactor the architecture parts of mt7628" Changes in v2: - Removed some dead code - Changed Author to my full name (no nick) - Removed unwanted fixup to .dts generation (not my call). - Fixed commit message - Fixed various variables/filenames to include Vendor name - Changed Vendor name (Vonger -> Vocore) arch/mips/dts/Makefile | 1 + arch/mips/dts/mt7628a.dtsi | 5 ++ arch/mips/dts/vocore_vocore2.dts | 78 arch/mips/mach-mtmips/Kconfig | 8 +++ board/vocore/vocore2/Kconfig | 12 board/vocore/vocore2/Makefile | 3 + board/vocore/vocore2/board.c | 6 ++ configs/vocore2_defconfig | 103 ++ configs/vocore2_defconfig_ENV_IN_FAT | 104 +++ include/configs/vocore2.h | 61 10 files changed, 381 insertions(+) create mode 100644 arch/mips/dts/vocore_vocore2.dts create mode 100644 board/vocore/vocore2/Kconfig create mode 100644 board/vocore/vocore2/Makefile create mode 100644 board/vocore/vocore2/board.c create mode 100644 configs/vocore2_defconfig create mode 100644 configs/vocore2_defconfig_ENV_IN_FAT create mode 100644 include/configs/vocore2.h Apart from the other comments, the MAINTAINERS file is missing. Please add it in the next patch version. Yes, I know. Also patman was complaining. I perused MAINTAINERS and it didn't look like specific board maintainers are in. I have no problems adding me to the list, but I'm unsure I have the privilege and it's unclear where I should add myself. I was not referring to the global MAINTAINERS file but the one located in the board directory. Please see: board/gardena/smart-gateway-mt7688/MAINTAINERS Thanks, Stefan
Fixing low-speed USB keyboard detection
Hello!
I own a D-Link DBT-120 Bluetooth Adapter, which has a CSR firmware running in a
so called “HID proxy mode”. This firmware pretends to be a USB keyboard (and
mouse) and thus allows to use a Bluetooth keyboard in U-Boot.
Unfortunately it acts as a low-speed device and there seems to be some well
known troubles about low-speed USB keyboards. There is a FAQ entry for openSUSE
about this:
https://en.opensuse.org/HCL:Raspberry_Pi3#I_cannot_use_keyboard_in_U-Boot_and_Grub_but_it_works_in_Linux
I spend some effort to solve this issue. There are three tiny changes to get my
Bluetooth keyboard working reliably as a low-speed USB keyboard.
Sometimes the Bluetooth adapter needs a bit longer to power on and send its
descriptor. As I use a Raspberry Pi 3b, I modified include/configs/rpi.h to add
"usb_pgood_delay=100\0" to the CONFIG_EXTRA_ENV_SETTINGS define. However this
is actually not a necessary change, even without it, most of the time there is
no issue.
Then the Bluetooth adapter needs one millisecond delay before accepting a new
address, to avoid the error “USB device not accepting new address”. This is in
common/usb.c at line 1047:
https://github.com/u-boot/u-boot/blob/master/common/usb.c#L1047
dev->devnum = addr;
mdelay(1);
err = usb_set_address(dev); /* set address */
And finally, assuming the use of CONFIG_SYS_USB_EVENT_POLL=y (which is the
default), in common/usb_kbd.c at line 520 this first interrupt IN message must
not be send:
https://github.com/u-boot/u-boot/blob/master/common/usb_kbd.c#L520
if (usb_int_msg(dev, data->intpipe, data->new, data->intpktsize,
data->intinterval, false) < 0) {
#endif
printf("Failed to get keyboard state from device %04x:%04x\n",
dev->descriptor.idVendor, dev->descriptor.idProduct);
/* Abort, we don't want to use that non-functional keyboard. */
return 0;
}
Due to the #if stuff around, its a bit ugly. I solved it simply by modifying
the if-statement in line 520:
if (0) {
With these two fixes my keyboard is working reliably. There is no need to press
a key upfront and no error message any longer, as described for openSUSE. A
chain-loaded GRUB-EFI is always usable now. I’m pretty sure that these changes
will solve the issues for other low-speed USB keyboards as well.
However, with that first interrupt IN message still sent, it seemed to me that
there was a NYET loop in chunk_msg() in drivers/usb/host/dwc.c once
complete_split got set. I guessed that “done += actual_len;” happens to often
and possibly to early for an unfinished split transaction. With the recent fix
9dcab2c4d2cb50ab1864c818b82a72393c160236 introducing the nonblock argument, a
split transfer gets restarted at a higher level, once there were to many NYET
responses. But for this first interrupt IN message this nonblock argument is
set to false, and in _submit_int_msg() we run into the timeout.
If I understand it correctly, once a NYET message is received, it may take up
to a millisecond before a response from a low-speed device is received (one
low-speed frame). And a high-speed host has a frame length of 125 ms. That
means that it can take up to 8 high-speed frames before a response from a
low-speed device is received. Bit chunk_msg() returns already after > 4
high-speed frames. I would expect to wait at least 8 frames.
The check after that first interrupt IN message got added by
5da2dc9789abecb1b018beb0c93f4c38c2985bc6 to workaround non-working keyboards.
My suggested change will kind of revert that workaround. So there is some
trade-off.
Stefan
Re: Fixing low-speed USB keyboard detection
Hello Soeren! It will take me some time to prepare a proper patch, I just found the documentation of your patman tool. I am using Guix and created a package definition for U-Boot with these three fixes using regexp substitutions. My time is quite limited for this weekend. I guess that you would be much faster preparing these three simple changes as a patch. So I would be glad, if you prepare a patch. A proper commit message could be this: “This patch works around issues of low-speed USB keyboards with the dwc2 USB interface. There was a need to press a key when "USB0: scanning bus 0 for devices..." was printed or otherwise there was the error "Timeout poll on interrupt endpoint" and the keyboard was not usable. This patch reverts the workaround from 5da2dc9789abecb1b018beb0c93f4c38c2985bc6 for non-working keyboards.” Stefan > Am 29.02.2020 um 13:04 schrieb Soeren Moch : > > > > On 29.02.20 00:46, Marek Vasut wrote: >> On 2/26/20 12:04 PM, Soeren Moch wrote: >>> Adding Marek as USB maintainer. Otherwise this non-patch-email may get >>> lost when sent to the mailing list only. >> Well, can you send these as proper patches ? > Well, I can try to make a proposal for patches. But I cannot test > something since I neither own such D-Link DBT-120 Bluetooth Adapter, nor > a Raspberry Pi 3b as host system. I'm also not familiar with the details > of event polling / interrupt message NYET handling in u-boot, so > probably will not come up with a good commit message about this. I also > cannot judge which workaround or revert of such is appropriate. > > Stefan, can you convert your fixes to proper patches yourself, or do you > want me to send a first proposal? > > Thanks, > Soeren >> >>> Soeren >>> >>> On 25.02.20 18:45, Stefan wrote: >>>> Hello! >>>> >>>> I own a D-Link DBT-120 Bluetooth Adapter, which has a CSR firmware running >>>> in a so called “HID proxy mode”. This firmware pretends to be a USB >>>> keyboard (and mouse) and thus allows to use a Bluetooth keyboard in U-Boot. >>>> >>>> Unfortunately it acts as a low-speed device and there seems to be some >>>> well known troubles about low-speed USB keyboards. There is a FAQ entry >>>> for openSUSE about this: >>>> https://en.opensuse.org/HCL:Raspberry_Pi3#I_cannot_use_keyboard_in_U-Boot_and_Grub_but_it_works_in_Linux >>>> >>>> I spend some effort to solve this issue. There are three tiny changes to >>>> get my Bluetooth keyboard working reliably as a low-speed USB keyboard. >> [...] > >
Re: [PATCH v3 00/20] Refactor the architecture parts of mt7628
Hi Mauro, On 11.02.20 11:58, Mauro Condarelli wrote: Thanks Daniel. On 2/10/20 10:28 PM, Daniel Schwierzeck wrote: Hi Mauro, Am 10.02.20 um 21:20 schrieb Mauro Condarelli: FYI I've been using this patchset for over a week without any adverse effect. It allowed me to port to VoCore2 board. Should I add a "Tested-by" flag? If so: how should I do it? Regards Mauro Codarelli sorry that I could respond to your questions earlier. I've pushed the complete patch set from Weijie to: https://gitlab.denx.de/u-boot/custodians/u-boot-mips/commits/testing I tried to use this repo/branch, but something is wrong (or I goofed badly). Just a quick reply: I tested u-boot-mips/testing today and it works just fine on both LinkIt and the GARDENA board. So there is nothing wrong with this repository AFAICT. You might need to rebase your patch on top of this branch, as some files might have changes in the meantime. Thanks, Stefan Maybe this helps you with development. If you have a bootable patch set (you can do MMC later) for your VoCore2 board, please submit a regular patch series based on that branch so that we can review again. I *do* have a bootable patchset built on top of master + Nemirovsky "reconfigurable cpu clocks" + Weijie v3. Result is fully working, including net and mmc/SD. This patchset applies cleanly to uboot-mips/testing and compile apparently without errors, but resulting u-boot.bin does not work. By "does not work" I mean it does not utter a single char on debug serial. I tried to do a complete diff between my working tree and this non-working one and there are tons of differences, but I couldn't spot anything that might be relevant. I am unsure on how to proceed; please advise. ===8< Many thanks Mauro Condarelli My complete patchset follows: This includes some project-specific settings I need to remove before actual submission, but I left them in because *this* is working for me. == From f1828bcacbd3fc3bc8aa9243b302ab2b7a509d88 Mon Sep 17 00:00:00 2001 From: Mauro Condarelli Date: Tue, 17 Dec 2019 10:54:21 +0100 Subject: [PATCH] Add support for SoM "VoCore2". Small patch series to add support for VoCore/VoCore2 board. VoCore is open hardware and runs OpenWrt/LEDE. It has WIFI, USB, UART, 20+ GPIOs but is only one inch square. It will help you to make a smart house, study embedded system or even make the tiniest router in the world. Details about this SoM can be found at "https://vocore.io/v2.html";. Series-notes: This port is working for me and able to boot Linux v5.0. Standard subsystems are enabled (SPI NOR, MMC/SD and USB). Network is not currently enabled as my Vocore2 board networking relies essentially on WiFi (which works under Linux). END Series-to: uboot Series-name: VoCore2 Series-cc: danielschwierzeck Series-cc: stroese Series-cc: Weijie Gao Series-version: 5 Series-changes: 2 - Removed some dead code - Changed Author to my full name (no nick) - Removed unwanted fixup to .dts generation (not my call). - Fixed commit message - Fixed various variables/filenames to include Vendor name - Changed Vendor name (Vonger -> Vocore) Series-changes: 3 - based on top of Weijie Gao patchset: "[v3,xx/20]Refactor the architecture parts of mt7628" Series-changes: 4 - Reverted some overzealous DTS cleaning. - Added support for bootcount Series-changes: 5 - Added network setup. - Move back environment to SPI NOR. - Changes to environment default settings. Signed-off-by: Mauro Condarelli --- arch/mips/dts/Makefile | 1 + arch/mips/dts/mt7628a.dtsi | 5 ++ arch/mips/dts/vocore_vocore2.dts | 78 arch/mips/mach-mtmips/Kconfig | 8 ++ board/vocore/vocore2/Kconfig | 12 +++ board/vocore/vocore2/Makefile | 3 + board/vocore/vocore2/board.c | 33 + configs/vocore2_defconfig | 105 +++ configs/vocore2_defconfig_ENV_IN_FAT | 104 ++ include/configs/vocore2.h | 76 +++ 10 files changed, 425 insertions(+) create mode 100644 arch/mips/dts/vocore_vocore2.dts create mode 100644 board/vocore/vocore2/Kconfig create mode 100644 board/vocore/vocore2/Makefile create mode 100644 board/vocore/vocore2/board.c create mode 100644 configs/vocore2_defconfig create mode 100644 configs/vocore2_defconfig_ENV_IN_FAT create mode 100644 include/configs/vocore2.h diff --git a/arch/mips/dts/Makefile b/arch/mips/dts/Makefile index cbd0c8bc8b..f711e9fb59 100644 --- a/arch/mips/dts/Makefile +++ b/arch/mips/dts/Makefile @@ -23,6 +23,7 @@ dtb-$(CONFIG_BOARD_NETGEAR_DGND3700V2) += netgear,dgnd3700v2.dtb dtb-$(CONFIG_BOARD_SAGEM_FAST1704) += sagem,f...@st1704.dtb dtb-$(CONFIG_BOARD_SFR_NB4_SER) += sfr,nb4-ser.dtb dtb-$(CONFIG_BOARD_TPLINK_WDR4300) += tplink_wdr4300.dtb +dt
Re: [PATCH v3 00/20] Refactor the architecture parts of mt7628
On 11.02.20 13:34, Mauro Condarelli wrote:
Thanks for the fast answer, Stefan.
On 2/11/20 12:16 PM, Stefan wrote:
Hi Mauro,
===8<
https://gitlab.denx.de/u-boot/custodians/u-boot-mips/commits/testing
I tried to use this repo/branch, but something is wrong (or I goofed
badly).
Just a quick reply: I tested u-boot-mips/testing today and it works just
fine on both LinkIt and the GARDENA board. So there is nothing wrong
with this repository AFAICT.
Suspect is there's something wrong with handling of SPL_UART2_SPIS_PINMUX
(that's where our boards are different), but I couldn't spot any relevant
difference.
Correct, I have not selected this one. You need to select it via "make
menuconfig" for your board and save it to your defconfig by "make
savedefconfig".
If this does not work, then please double-check, if the correct code is
called in this pinx-mux case.
You might need to rebase your patch on top of this branch, as some files
might have changes in the meantime.
What is the recommended procedure, in this case?
I did a:
git format-patch --full-index -o ../transport weijie.v3
on old branch ("weijie.v3" is the branch on which I added Weijie's patches,
of course), an then I tried simply (on u-boot-mips):
git checkout -b vocore2 testing
git am -3 ../transport/*
This sounds like a valid approach.
There are many ways. I usually use "git rebase" for this:
In your case:
- Check out your current working branch
- git checkout -b new-version
- git rebase u-boot-mips/testing
The rebase command will most likely issue some warnings or errors on
files that you need to manually fix. After this "git rebase --continue".
But the output will tell you, what to do.
But again, your approach looks also fine.
Thanks,
Stefan
Re: [PATCH v3 00/20] Refactor the architecture parts of mt7628
On 11.02.20 14:54, Daniel Schwierzeck wrote: On Tue, Feb 11, 2020 at 11:58 AM Mauro Condarelli wrote: Thanks Daniel. On 2/10/20 10:28 PM, Daniel Schwierzeck wrote: Hi Mauro, Am 10.02.20 um 21:20 schrieb Mauro Condarelli: FYI I've been using this patchset for over a week without any adverse effect. It allowed me to port to VoCore2 board. Should I add a "Tested-by" flag? If so: how should I do it? Regards Mauro Codarelli sorry that I could respond to your questions earlier. I've pushed the complete patch set from Weijie to: https://gitlab.denx.de/u-boot/custodians/u-boot-mips/commits/testing I tried to use this repo/branch, but something is wrong (or I goofed badly). Maybe this helps you with development. If you have a bootable patch set (you can do MMC later) for your VoCore2 board, please submit a regular patch series based on that branch so that we can review again. I *do* have a bootable patchset built on top of master + Nemirovsky "reconfigurable cpu clocks" + Weijie v3. Result is fully working, including net and mmc/SD. This patchset applies cleanly to uboot-mips/testing and compile apparently without errors, but resulting u-boot.bin does not work. By "does not work" I mean it does not utter a single char on debug serial. I tried to do a complete diff between my working tree and this non-working one and there are tons of differences, but I couldn't spot anything that might be relevant. I am unsure on how to proceed; please advise. but do you reach the U-Boot prompt? If I apply your patch and build it, I need to be able to program the resulting U-Boot image to SPI flash and boot to U-Boot prompt. Also note that the final U-Boot image with SPL is now called u-boot-mtmips.bin. Don't try to use u-boot.bin. A quick remark on this, as I've forgotten to write about this: I would like to change the resulting image name from this specific "u-boot-mips.bin" to the already known "u-boot-with-spl.bin" name. There is no need to introduce a new name here and there is nothing "mtmips" specific in this image type. Thanks, Stefan
Re: [PATCH v3 00/20] Refactor the architecture parts of mt7628
Hi Mauro,
Hi Daniel,
On 11.02.20 19:05, Mauro Condarelli wrote:
Thanks Daniel.
On 2/11/20 5:49 PM, Daniel Schwierzeck wrote:
On Tue, Feb 11, 2020 at 5:11 PM Mauro Condarelli wrote:
===8<
Hit any key to stop autoboot: 0
=>
ok, booting from RAM works. But what I meant with bootable is, that
you can write the
the u-boot-mtmips.bin to SPI flash and do a cold boot. Only then we
can merge your patch.
It *does* work.
The U-Boot I have flashed is essentially the same as the one built
in the "master" directory, just a few days old (I changed essentially
my project-specific CONFIG_EXTRA_ENV_SETTINGS).
... which reminds me of something...
... it turns out that flashing *does* work:
=> setenv autoload no; dhcp; tftpboot 8500
192.168.7.101:u-boot-mtmips.bin; sf probe; sf update ${fileaddr} 0
${filesize}
BOOTP broadcast 1
BOOTP broadcast 2
BOOTP broadcast 3
BOOTP broadcast 4
DHCP client bound to address 192.168.7.110 (2953 ms)
Using eth@1011 device
TFTP from server 192.168.7.101; our IP address is 192.168.7.110
Filename 'u-boot-mtmips.bin'.
Load address: 0x8500
Loading: #
762.7 KiB/s
done
Bytes transferred = 244458 (3baea hex)
device 0 offset 0x0, size 0x3baea
240362 bytes written, 4096 bytes skipped in 2.232s, speed 111952 B/s
=> reset
resetting ...
U-Boot SPL 2020.04-rc1-01620-gcd23ee2179 (Feb 11 2020 - 18:33:48 +0100)
Trying to boot from NOR
U-Boot 2020.04-rc1-01620-gcd23ee2179 (Feb 11 2020 - 18:33:48 +0100)
CPU: MediaTek MT7628A ver:1 eco:2
Boot: DDR2, SPI-NOR 3-Byte Addr, CPU clock from XTAL
Clock: CPU: 580MHz, Bus: 193MHz, XTAL: 40MHz
Model: VoCore2
DRAM: 128 MiB
WDT: Started with servicing (60s timeout)
MMC: mmc@1013: 0
Loading Environment from SPI Flash... SF: Detected w25q128 with page
size 256 Bytes, erase size 4 KiB, total 16 MiB
OK
Model: VoCore2
Net:
Warning: eth@1011 (eth0) using random MAC address - 8a:fb:d0:3b:d1:93
eth0: eth@1011
Hit any key to stop autoboot: 0
=>
What *does NOT* work is loading RAM version or, to be more precise:
It works IF (and only if) you load the same code already running.
I *think* this is because current Weijie code unpacks to this same location
(8020) before relocating. If you are rewriting the same code in the
same location any cache inconsistencies are unimportant, otherwise
Bad Things happen.
I spoke with Stephan about this, but we never found a fix.
Now that I reflashed "u-boot-mips/testing" version I can run it also
"from RAM", while trying to load "master" hangs (I tried just now).
If this is considered "acceptable" (probably it has nothing to do with my
vocore2 port) I can clean-up my patches and resubmit.
I'm not a mips expert and I don't know how to debug this "RAM load"
misbehavior, but I'm available for testing, if useful.
I also noticed that "RAM loading" the U-Boot proper does not work all
the time on my MT7688 targets. It seems to depend on the image size
and some other factors (moon phase...). ;)
So there is very likely a bug somewhere hidden - perhaps in the
relocaton code. I will probably try to dig into this in sometime soon.
But I need a reproducable "bad" image for this. Right now, RAM loading
is working just fine.
BTW: I noticed that RAM loading does work even when loading into a
different address than TEXT_BASE. On the new MTMIPS targets TEXT_BASE is
0x8020 and loadind to e.g. 0x8100 does also work.
Daniel, perhaps a dumb question, but is the MIPS U-Boot code position
independant?
Mauro, please try loading into a different address on your non-working
setup and report back if RAM loading works in this case.
===8<---
I *do* have a bootable patchset built on top of master + Nemirovsky
"reconfigurable cpu clocks" + Weijie v3.
Result is fully working, including net and mmc/SD.
This patchset applies cleanly to uboot-mips/testing and compile
apparently without errors, but resulting u-boot.bin does not work.
By "does not work" I mean it does not utter a single char on debug
serial.
I tried to do a complete diff between my working tree and this
non-working one and there are tons of differences, but I couldn't
spot anything that might be relevant.
I am unsure on how to proceed; please advise.
maybe you have a big diff because you are not on the latest master
branch. I currently
have ae347120eed8204b1fdf018ddf79131964e57016. The u-boot-mips/testing is based
on u-boot-mips/next and only contains Weijie's v3 patches from 14/20
to 20/20. For
u-boot-mips/next I intend to create a pull request soon. The existing
mtmips boards should
still work without SPL support. Maybe Stefan could give it a quick test.
Maybe I messed something up in u-boot-mips/testing. There were some
merge conflicts.
I don't think so.
As said problem is with RAM loading.
I also have this problem (sometimes). Please see above.
Coul
Re: [PATCH v3 00/20] Refactor the architecture parts of mt7628
Hi Mauro,
On 12.02.20 10:23, Mauro Condarelli wrote:
Hi Stefan,
Hi Daniel,
On 2/12/20 7:39 AM, Stefan wrote:
Hi Mauro,
Hi Daniel,
On 11.02.20 19:05, Mauro Condarelli wrote:
===8<---
What *does NOT* work is loading RAM version or, to be more precise:
It works IF (and only if) you load the same code already running.
I *think* this is because current Weijie code unpacks to this same
location
(8020) before relocating. If you are rewriting the same code in the
same location any cache inconsistencies are unimportant, otherwise
Bad Things happen.
I spoke with Stephan about this, but we never found a fix.
===8<---
I also noticed that "RAM loading" the U-Boot proper does not work all
the time on my MT7688 targets. It seems to depend on the image size
and some other factors (moon phase...). ;)
So there is very likely a bug somewhere hidden - perhaps in the
relocaton code. I will probably try to dig into this in sometime soon.
But I need a reproducable "bad" image for this. Right now, RAM loading
is working just fine.
As said: In my setup RAM loading is consistently failing if I try to load
an u-boot build consistently different from the one currently running.
OTOH loading the same (or very similar, a rebuild is considered "the
same") version is _always_ working for me.
To rephrase: I have two setups; one based on master+weijiev3 and
the other based on plain mtmips/testing.
I can flash either one and it works from SPI NOR. no problems here.
I can always RAM load successfully the same kernel as flashed.
If I RAM load the "other" setup it always fails.
I did a few tests:
- erasing download area (mw.b 8020 0 8).
- do some other loading (e.g.: the Linux kernel) between RAM load and
"go" (attempt to clean caches, but I suspect this would only effectively
clear D-cache, not I-cache).
The above behavior does not change.
BTW: I noticed that RAM loading does work even when loading into a
different address than TEXT_BASE. On the new MTMIPS targets TEXT_BASE is
0x8020 and loadind to e.g. 0x8100 does also work.
I do confirm this:
setenv autoload no; dhcp; tftpboot 8100
192.168.7.101:u-boot.bin-mips.testing; go ${fileaddr}
works as expected (loading same-as-flashed)
Daniel, perhaps a dumb question, but is the MIPS U-Boot code position
independant?
Mauro, please try loading into a different address on your non-working
setup and report back if RAM loading works in this case.
Attempt to load, even at different address, the "other" u-boot fails:
setenv autoload no; dhcp; tftpboot 8100
192.168.7.101:u-boot.bin-weijie.v3.vocore2; go ${fileaddr}
hangs after "## Starting application at 0x8100 ..." (I currently have
in SPI NOR the u-boot-mtmips.bin-mips.testing built together
u-boot.bin-mips.testing).
Could you please apply the new cmd/boot.c patch I've sent just a few
minutes ago [1] and burn this image into flash. And please test with
this image, if RAM booting of other, different images does work for you
now.
And sorry, using a different TEXT_BASE does not seem to work. Somehow
I seem to have goofed up this morning in my tests. Please use always the
correct TEXT_BASE as load address for the RAM image.
Thanks,
Stefan
[1] http://patchwork.ozlabs.org/patch/1236810/
Re: [PATCH] cmd: go: Flush cache before jumping to app/image
Hi Daniel,
On 12.02.20 14:00, Daniel Schwierzeck wrote:
On Wed, Feb 12, 2020 at 1:21 PM Stefan Roese wrote:
It has been noticed on MT7628/88 platforms, that booting the RAM image
does not work reliably. Sometimes it works and sometimes not. Debugging
showed that this "might" be a cache related issue as very strange
errors occured (output corrupted etc).
This patch adds a cache flush for the complete SDRAM area to the go cmd
before jumping to the entry point. The complete area is flushed as we
don't know at this point, how big the area of the "application" really
is.
Signed-off-by: Stefan Roese
Cc: Daniel Schwierzeck
Cc: Mauro Condarelli
Cc: Weijie Gao
---
cmd/boot.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/cmd/boot.c b/cmd/boot.c
index 9150fce80b..968522face 100644
--- a/cmd/boot.c
+++ b/cmd/boot.c
@@ -9,10 +9,13 @@
*/
#include
#include
+#include
#include
#ifdef CONFIG_CMD_GO
+DECLARE_GLOBAL_DATA_PTR;
+
/* Allow ports to override the default behavior */
__attribute__((weak))
unsigned long do_go_exec(ulong (*entry)(int, char * const []), int argc,
@@ -33,6 +36,13 @@ static int do_go(cmd_tbl_t *cmdtp, int flag, int argc, char
* const argv[])
printf ("## Starting application at 0x%08lX ...\n", addr);
+ /*
+* Flush cache before jumping to application. Let's flush the
+* whole SDRAM area, since we don't know the size of the image
+* that was loaded.
+*/
+ flush_cache(gd->bd->bi_memstart, gd->bd->bi_memsize);
+
/*
* pass address parameter as argv[0] (aka command name),
* and all remaining args
--
2.25.0
I think that's not right for all architectures or cache-coherent
systems. It would be better
to implement do_go_exec() in arch/mips/libs/bootm.c because this function is
already annotated as weak.
Good idea. I'll change it accordingly in v2 once its been tested and
confirmed by Mauro.
Thanks,
Stefan
Re: [PATCH] cmd: go: Flush cache before jumping to app/image
Hi Mauro, On 12.02.20 14:09, Mauro Condarelli wrote: Hi Daniel, Hi Stefan, I'll test this ASAP, but, in the meantime, please have a look at the strange (and perhaps related) code in arch/mips/mach-mtmips/cpu.c You are most likely referring to the code in last_stage_init() that also deals with a potential cache issue. Its still unresolved and this "hack" is still needed for a working U-Boot image (e.g. no timeouts in tftp). Its only partly related to the current issue though as it also deals with "cache" but addresses a different issue. Please test and report back. Thanks, Stefan
Re: [PATCH v3 00/20] Refactor the architecture parts of mt7628
Hi Daniel, On 12.02.20 13:48, Daniel Schwierzeck wrote: Daniel, perhaps a dumb question, but is the MIPS U-Boot code position independant? from your tests I can only conclude that RAM loading doesn't work at all. If you see it "working" than you simply junp to the old copy which the SPL created. A MIPS U-Boot is always built with position-dependant code. To make the U-Boot binary relocatable, we use the tools/mips-relocs.c which was ported from Linux. During linking we let gcc emit relocation entries which are post-processed by the mips-relocs tool. The output is then inserted into u-boot.bin in section ".data.reloc". Those reloc entries are then used by the MIPS relocation code to patch all symbols with the relative offset to the new text address. If you build for example the Gardena Smart Gateway and disassemble the u-boot binary (which becomes the SPL payload), the very first instruction is this: 8020 <_start>: #endif .endm ENTRY(_start) /* U-Boot entry point */ b reset 8020: 113fb 80200500 mtc0 zero, CP0_COUNT # clear cp0 count for most accurate boot timing 8024: 40804800mtc0zero,c0_count So if you load u-boot.bin to a different address than 0x8020 and jump to it, the first instruction is a jump back to address 0x80200500. If the old SPL copy of u-boot.bin is still there, you'll see a "working" RAM boot. Thanks for this analysis. This is exactly what happened in my test this morning. Actually Mauro already did the right thing with erasing the load area at 0x8020 before downloading a new binary. A stable approach to a RAM boot binary (which I use in my out-of-tree boards) would be to use a KSEG1 text address e.g. 0xa020 and explicitely switch the CPU to non-caching mode (this is normally skipped with CONFIG_SKIP_LOWLEVEL_INIT in the SPL payload). This approach always worked for me for booting via UART or EJTAG without getting messed up by cache effects. So either we officially drop RAM boot support for mtmips platform (respectively don't use the u-boot.bin intended for SPL payload as RAM boot binary) or we keep the special RAM boot configs. I assume that you are also okay with the cache flush approach? I'll send v2 of this patch pretty soon if nobody objects. Thanks, Stefan
Re: [U-Boot] [PATCH] drivers/net/4xx_enet.c: Fix build warning
On Mon, 21 May 2012 22:48:18 +0200, Anatolij Gustschin wrote: Fix: 4xx_enet.c: In function 'ppc_4xx_eth_initialize': 4xx_enet.c:2029: warning: assignment from incompatible pointer type Tested on sequoia board. Signed-off-by: Anatolij Gustschin Tested-by: Anatolij Gustschin Cc: Joe Hershberger Acked-by: Stefan Roese Thanks, Stefan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] NAND: Remove ONFI detection message to from bootup log
On Fri, 18 May 2012 18:19:34 -0500, Scott Wood wrote: On Mon, May 07, 2012 at 09:29:30PM -, Stefan Roese wrote: Without this patch, boot shows this messages upon NAND detection: NAND: ONFI flash detected ONFI param page 0 valid ONFI flash detected ONFI param page 0 valid 128 MiB With this patch, its back to the U-Boot "standard": NAND: 128 MiB Tested on x600 (SPEAr600). Signed-off-by: Stefan Roese Cc: Amit Virdi Cc: Vipin Kumar Cc: Scott Wood Acked-by: Amit Virdi --- drivers/mtd/nand/nand_base.c |5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) Applied to u-boot-nand-flash. Thanks. BTW, I don't see any boards enabling the ONFI code at the moment... The pending (already posted) SPEAr patches will use it. Thanks, Stefan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V5 RESEND 0/3] mtd/NAND: Support for FSMC controller
Hi Scott, On Thu, 24 May 2012 10:58:09 +0530, Amit Virdi wrote: This patchset adds support for ST's FSMC controller. In the current u-boot, a SPEAr specific driver exists for FSMC controller. This patchset adds a full fledged driver that can be used across multiple platforms and removes the obsolete SPEAr specific driver. Are you okay with this patchset version? If yes, please go ahead and push it upstream via your repository. There are some other SPEAr related patches depending on this set that I would like to push. Thanks, Stefan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/4] vybrid/tower fixes and enhancements
From: Stefan Agner This patch series addresses several fixes and enhancements for the vybrid tower. The patches are originally by Marcel Ziswiler which should remain the Author of the patches, I picked them up since some changes I'm going to submit are building upon them. Changes v3: - Merged patches to reflect one logical change on a pheripherial device level. Changes v2: - Memory offset based reserved ANADIG field naming scheme. - Fixed mux_ctrl_ofs in secondary RMII1 iomux definitions. Marcel Ziswiler (4): arm: vf610: fix anadig register struct arm: vf610: add uart0 clock/iomux definitions arm: vf610: add enet1 support arm: vf610: fix double iomux configuration for vf610twr board arch/arm/include/asm/arch-vf610/crm_regs.h| 57 +++ arch/arm/include/asm/arch-vf610/imx-regs.h| 1 + arch/arm/include/asm/arch-vf610/iomux-vf610.h | 12 ++ board/freescale/vf610twr/vf610twr.c | 1 - 4 files changed, 45 insertions(+), 26 deletions(-) -- 1.9.0 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/4] arm: vf610: add uart0 clock/iomux definitions
From: Marcel Ziswiler
Add CCM_CCGR0_UART0_CTRL_MASK clock definition and add TX/RX iomux
definitions for UART0 (aka. SCI0).
Signed-off-by: Marcel Ziswiler
[ste...@agner.ch: regrouped patch]
Signed-off-by: Stefan Agner
---
arch/arm/include/asm/arch-vf610/crm_regs.h| 1 +
arch/arm/include/asm/arch-vf610/iomux-vf610.h | 2 ++
2 files changed, 3 insertions(+)
diff --git a/arch/arm/include/asm/arch-vf610/crm_regs.h
b/arch/arm/include/asm/arch-vf610/crm_regs.h
index 2d7a32d..04cc5bc 100644
--- a/arch/arm/include/asm/arch-vf610/crm_regs.h
+++ b/arch/arm/include/asm/arch-vf610/crm_regs.h
@@ -166,6 +166,7 @@ struct anadig_reg {
#define CCM_CSCMR2_RMII_CLK_SEL(v) (((v) & 0x3) << 4)
#define CCM_REG_CTRL_MASK 0x
+#define CCM_CCGR0_UART0_CTRL_MASK (0x3 << 14)
#define CCM_CCGR0_UART1_CTRL_MASK (0x3 << 16)
#define CCM_CCGR1_PIT_CTRL_MASK(0x3 << 14)
#define CCM_CCGR1_WDOGA5_CTRL_MASK (0x3 << 28)
diff --git a/arch/arm/include/asm/arch-vf610/iomux-vf610.h
b/arch/arm/include/asm/arch-vf610/iomux-vf610.h
index 4a39eb0..f3c201d 100644
--- a/arch/arm/include/asm/arch-vf610/iomux-vf610.h
+++ b/arch/arm/include/asm/arch-vf610/iomux-vf610.h
@@ -24,6 +24,8 @@ enum {
VF610_PAD_PTA6__RMII0_CLKIN = IOMUX_PAD(0x, 0x, 2,
__NA_, 0, VF610_ENET_PAD_CTRL),
VF610_PAD_PTB4__UART1_TX= IOMUX_PAD(0x0068, 0x0068, 2,
0x0380, 0, VF610_UART_PAD_CTRL),
VF610_PAD_PTB5__UART1_RX= IOMUX_PAD(0x006c, 0x006c, 2,
0x037c, 0, VF610_UART_PAD_CTRL),
+ VF610_PAD_PTB10__UART0_TX = IOMUX_PAD(0x0080, 0x0080, 1,
__NA_, 0, VF610_UART_PAD_CTRL),
+ VF610_PAD_PTB11__UART0_RX = IOMUX_PAD(0x0084, 0x0084, 1,
__NA_, 0, VF610_UART_PAD_CTRL),
VF610_PAD_PTC1__RMII0_MDIO = IOMUX_PAD(0x00b8, 0x00b8, 1,
__NA_, 0, VF610_ENET_PAD_CTRL),
VF610_PAD_PTC0__RMII0_MDC = IOMUX_PAD(0x00b4, 0x00b4, 1,
__NA_, 0, VF610_ENET_PAD_CTRL),
VF610_PAD_PTC2__RMII0_CRS_DV= IOMUX_PAD(0x00bc, 0x00bc, 1,
__NA_, 0, VF610_ENET_PAD_CTRL),
--
1.9.0
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/4] arm: vf610: fix anadig register struct
From: Marcel Ziswiler
The anadig_reg structure started at the wrong offset (fixed by adding
reserved_0x000[4]), was missing some reserved field required for
alignment purpose (reserved_0x094[3] between pll4_denom and pll6_ctrl)
and further contained a too short reserved field causing further miss-
alignment (reserved_0x0C4[7]). Also, rename all the reserved fields
and using a memory offset based scheme for.
Discovered and tested by temporarily putting the following debug
instrumentation into board_init():
struct anadig_reg *anadig = (struct anadig_reg *)ANADIG_BASE_ADDR;
printf("&anadig->pll3_ctrl=0x%p\n", &anadig->pll3_ctrl);
printf("&anadig->pll5_ctrl=0x%p\n", &anadig->pll5_ctrl);
Signed-off-by: Marcel Ziswiler
[ste...@agner.ch: regrouped patch]
Signed-off-by: Stefan Agner
---
arch/arm/include/asm/arch-vf610/crm_regs.h | 52 --
1 file changed, 27 insertions(+), 25 deletions(-)
diff --git a/arch/arm/include/asm/arch-vf610/crm_regs.h
b/arch/arm/include/asm/arch-vf610/crm_regs.h
index 85f1fda..2d7a32d 100644
--- a/arch/arm/include/asm/arch-vf610/crm_regs.h
+++ b/arch/arm/include/asm/arch-vf610/crm_regs.h
@@ -55,57 +55,59 @@ struct ccm_reg {
/* Analog components control digital interface (ANADIG) */
struct anadig_reg {
+ u32 reserved_0x000[4];
u32 pll3_ctrl;
- u32 resv0[3];
+ u32 reserved_0x014[3];
u32 pll7_ctrl;
- u32 resv1[3];
+ u32 reserved_0x024[3];
u32 pll2_ctrl;
- u32 resv2[3];
+ u32 reserved_0x034[3];
u32 pll2_ss;
- u32 resv3[3];
+ u32 reserved_0x044[3];
u32 pll2_num;
- u32 resv4[3];
+ u32 reserved_0x054[3];
u32 pll2_denom;
- u32 resv5[3];
+ u32 reserved_0x064[3];
u32 pll4_ctrl;
- u32 resv6[3];
+ u32 reserved_0x074[3];
u32 pll4_num;
- u32 resv7[3];
+ u32 reserved_0x084[3];
u32 pll4_denom;
+ u32 reserved_0x094[3];
u32 pll6_ctrl;
- u32 resv8[3];
+ u32 reserved_0x0A4[3];
u32 pll6_num;
- u32 resv9[3];
+ u32 reserved_0x0B4[3];
u32 pll6_denom;
- u32 resv10[3];
+ u32 reserved_0x0C4[7];
u32 pll5_ctrl;
- u32 resv11[3];
+ u32 reserved_0x0E4[3];
u32 pll3_pfd;
- u32 resv12[3];
+ u32 reserved_0x0F4[3];
u32 pll2_pfd;
- u32 resv13[3];
+ u32 reserved_0x104[3];
u32 reg_1p1;
- u32 resv14[3];
+ u32 reserved_0x114[3];
u32 reg_3p0;
- u32 resv15[3];
+ u32 reserved_0x124[3];
u32 reg_2p5;
- u32 resv16[7];
+ u32 reserved_0x134[7];
u32 ana_misc0;
- u32 resv17[3];
+ u32 reserved_0x154[3];
u32 ana_misc1;
- u32 resv18[63];
+ u32 reserved_0x164[63];
u32 anadig_digprog;
- u32 resv19[3];
+ u32 reserved_0x264[3];
u32 pll1_ctrl;
- u32 resv20[3];
+ u32 reserved_0x274[3];
u32 pll1_ss;
- u32 resv21[3];
+ u32 reserved_0x284[3];
u32 pll1_num;
- u32 resv22[3];
+ u32 reserved_0x294[3];
u32 pll1_denom;
- u32 resv23[3];
+ u32 reserved_0x2A4[3];
u32 pll1_pdf;
- u32 resv24[3];
+ u32 reserved_0x2B4[3];
u32 pll_lock;
};
#endif
--
1.9.0
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 4/4] arm: vf610: fix double iomux configuration for vf610twr board
From: Marcel Ziswiler
Get rid of double VF610_PAD_DDR_A15__DDR_A_15 iomux configuration.
Signed-off-by: Marcel Ziswiler
---
board/freescale/vf610twr/vf610twr.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/board/freescale/vf610twr/vf610twr.c
b/board/freescale/vf610twr/vf610twr.c
index 699ea7f..4ee74c0 100644
--- a/board/freescale/vf610twr/vf610twr.c
+++ b/board/freescale/vf610twr/vf610twr.c
@@ -31,7 +31,6 @@ void setup_iomux_ddr(void)
{
static const iomux_v3_cfg_t ddr_pads[] = {
VF610_PAD_DDR_A15__DDR_A_15,
- VF610_PAD_DDR_A15__DDR_A_15,
VF610_PAD_DDR_A14__DDR_A_14,
VF610_PAD_DDR_A13__DDR_A_13,
VF610_PAD_DDR_A12__DDR_A_12,
--
1.9.0
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/4] arm: vf610: add enet1 support
From: Marcel Ziswiler
This patch contains several changes required for second Ethernet
(enet1/RMII1) port on vf610
- ANADIG PLL5 control definitions required for Ethernet RMII1 clock
- Secondary Ethernet (enet1) MAC RMII1 base address definition
- RMII1 iomux definitions
- VF610_PAD_PTA6__RMII0_CLKOUT iomux definition required for
internal (e.g. crystal-less) Ethernet clocking.
Signed-off-by: Marcel Ziswiler
[ste...@agner.ch: regrouped patch]
Signed-off-by: Stefan Agner
---
arch/arm/include/asm/arch-vf610/crm_regs.h| 4
arch/arm/include/asm/arch-vf610/imx-regs.h| 1 +
arch/arm/include/asm/arch-vf610/iomux-vf610.h | 10 ++
3 files changed, 15 insertions(+)
diff --git a/arch/arm/include/asm/arch-vf610/crm_regs.h
b/arch/arm/include/asm/arch-vf610/crm_regs.h
index 04cc5bc..e17c7d1 100644
--- a/arch/arm/include/asm/arch-vf610/crm_regs.h
+++ b/arch/arm/include/asm/arch-vf610/crm_regs.h
@@ -187,6 +187,10 @@ struct anadig_reg {
#define CCM_CCGR9_FEC0_CTRL_MASK 0x3
#define CCM_CCGR9_FEC1_CTRL_MASK (0x3 << 2)
+#define ANADIG_PLL5_CTRL_BYPASS (1 << 16)
+#define ANADIG_PLL5_CTRL_ENABLE (1 << 13)
+#define ANADIG_PLL5_CTRL_POWERDOWN (1 << 12)
+#define ANADIG_PLL5_CTRL_DIV_SELECT1
#define ANADIG_PLL2_CTRL_ENABLE(1 << 13)
#define ANADIG_PLL2_CTRL_POWERDOWN (1 << 12)
#define ANADIG_PLL2_CTRL_DIV_SELECT1
diff --git a/arch/arm/include/asm/arch-vf610/imx-regs.h
b/arch/arm/include/asm/arch-vf610/imx-regs.h
index b8c877f..c2f9761 100644
--- a/arch/arm/include/asm/arch-vf610/imx-regs.h
+++ b/arch/arm/include/asm/arch-vf610/imx-regs.h
@@ -85,6 +85,7 @@
#define ESDHC0_BASE_ADDR (AIPS1_BASE_ADDR + 0x00031000)
#define ESDHC1_BASE_ADDR (AIPS1_BASE_ADDR + 0x00032000)
#define ENET_BASE_ADDR (AIPS1_BASE_ADDR + 0x0005)
+#define ENET1_BASE_ADDR(AIPS1_BASE_ADDR + 0x00051000)
/* MUX mode and PAD ctrl are in one register */
#define CONFIG_IOMUX_SHARE_CONF_REG
diff --git a/arch/arm/include/asm/arch-vf610/iomux-vf610.h
b/arch/arm/include/asm/arch-vf610/iomux-vf610.h
index f3c201d..88807d8 100644
--- a/arch/arm/include/asm/arch-vf610/iomux-vf610.h
+++ b/arch/arm/include/asm/arch-vf610/iomux-vf610.h
@@ -22,6 +22,7 @@
enum {
VF610_PAD_PTA6__RMII0_CLKIN = IOMUX_PAD(0x, 0x, 2,
__NA_, 0, VF610_ENET_PAD_CTRL),
+ VF610_PAD_PTA6__RMII0_CLKOUT= IOMUX_PAD(0x, 0x, 1,
__NA_, 0, VF610_ENET_PAD_CTRL),
VF610_PAD_PTB4__UART1_TX= IOMUX_PAD(0x0068, 0x0068, 2,
0x0380, 0, VF610_UART_PAD_CTRL),
VF610_PAD_PTB5__UART1_RX= IOMUX_PAD(0x006c, 0x006c, 2,
0x037c, 0, VF610_UART_PAD_CTRL),
VF610_PAD_PTB10__UART0_TX = IOMUX_PAD(0x0080, 0x0080, 1,
__NA_, 0, VF610_UART_PAD_CTRL),
@@ -35,6 +36,15 @@ enum {
VF610_PAD_PTC6__RMII0_TD1 = IOMUX_PAD(0x00cc, 0x00cc, 1,
__NA_, 0, VF610_ENET_PAD_CTRL),
VF610_PAD_PTC7__RMII0_TD0 = IOMUX_PAD(0x00D0, 0x00D0, 1,
__NA_, 0, VF610_ENET_PAD_CTRL),
VF610_PAD_PTC8__RMII0_TXEN = IOMUX_PAD(0x00D4, 0x00D4, 1,
__NA_, 0, VF610_ENET_PAD_CTRL),
+ VF610_PAD_PTC10__RMII1_MDIO = IOMUX_PAD(0x00dc, 0x00dc, 1,
__NA_, 0, VF610_ENET_PAD_CTRL),
+ VF610_PAD_PTC9__RMII1_MDC = IOMUX_PAD(0x00d8, 0x00d8, 1,
__NA_, 0, VF610_ENET_PAD_CTRL),
+ VF610_PAD_PTC11__RMII1_CRS_DV = IOMUX_PAD(0x00e0, 0x00e0, 1,
__NA_, 0, VF610_ENET_PAD_CTRL),
+ VF610_PAD_PTC12__RMII1_RD1 = IOMUX_PAD(0x00e4, 0x00e4, 1,
__NA_, 0, VF610_ENET_PAD_CTRL),
+ VF610_PAD_PTC13__RMII1_RD0 = IOMUX_PAD(0x00e8, 0x00e8, 1,
__NA_, 0, VF610_ENET_PAD_CTRL),
+ VF610_PAD_PTC14__RMII1_RXER = IOMUX_PAD(0x00ec, 0x00ec, 1,
__NA_, 0, VF610_ENET_PAD_CTRL),
+ VF610_PAD_PTC15__RMII1_TD1 = IOMUX_PAD(0x00f0, 0x00f0, 1,
__NA_, 0, VF610_ENET_PAD_CTRL),
+ VF610_PAD_PTC16__RMII1_TD0 = IOMUX_PAD(0x00f4, 0x00f4, 1,
__NA_, 0, VF610_ENET_PAD_CTRL),
+ VF610_PAD_PTC17__RMII1_TXEN = IOMUX_PAD(0x00f8, 0x00f8, 1,
__NA_, 0, VF610_ENET_PAD_CTRL),
VF610_PAD_PTA24__ESDHC1_CLK = IOMUX_PAD(0x0038, 0x0038, 5,
__NA_, 0, VF610_SDHC_PAD_CTRL),
VF610_PAD_PTA25__ESDHC1_CMD = IOMUX_PAD(0x003c, 0x003c, 5,
__NA_, 0, VF610_SDHC_PAD_CTRL),
VF610_PAD_PTA26__ESDHC1_DAT0= IOMUX_PAD(0x0040, 0x0040, 5,
__NA_, 0, VF610_SDHC_PAD_CTRL),
--
1.9.0
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v1 3/9] sunxi: initial sun7i dram setup support
> Unfortunately the only documentation we have on the sun7i DRAM > controller is Allwinner boot0 + boot1 code, and that code uses.. magic > numbers & shifts with no explanations. To avoid having to explain this over-and-over again, the code could include some comment(s) pointing out that these are unexplained magic constants from Allwinner's code. Stefan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] tools: make imxheader size align on page size
From: Stefan Agner
The i.MX V2 headers total size is 0x7fc. The header is placed
in front of the U-Boot binary which of course is aligned to
text base. Hence the header starting point is not page
aligned (e.g. at 0x3f400404). This is still a valid header,
which boots fine using serial loader. However, the image
fails to boot from NAND (tested on a VF61x SoC).
Most parts of the header have a length of a multiply of 16
bytes.The rest of the header is filled with 8 bytes long DCD
data. Only the boot data header is 3 word long (12 bytes).
This patch makes sure the whole image is exactly 0x800 by
adding one padding word after the boot data header. Since
the individual data structures are referenced by pointers,
this still results in a valid i.MX V2 header while
maintaining page alignment.
Signed-off-by: Stefan Agner
---
I'm not 100% sure wheather this is the right approach solving
this issue. This works for me, also tested with DCD data.
tools/imximage.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/tools/imximage.h b/tools/imximage.h
index 01f861e..b596fb1 100644
--- a/tools/imximage.h
+++ b/tools/imximage.h
@@ -149,6 +149,7 @@ typedef struct {
typedef struct {
flash_header_v2_t fhdr;
boot_data_t boot_data;
+ uint32_t reserved1;
dcd_v2_t dcd_table;
} imx_header_v2_t;
--
1.9.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] arm: vf610: add DDR_SEL_PAD_CONTR register
From: Stefan Agner Set DDR_SEL_PAD_CONTR register explicitly to DDR3 which solves RAM issues with newer silicon (1.1). This register was added in revision 4 of the Vybrid Reference Manual. Signed-off-by: Stefan Agner --- arch/arm/include/asm/arch-vf610/imx-regs.h | 1 + board/freescale/vf610twr/vf610twr.c| 3 ++- 2 files changed, 3 insertions(+), 1 deletion(-) diff --git a/arch/arm/include/asm/arch-vf610/imx-regs.h b/arch/arm/include/asm/arch-vf610/imx-regs.h index c2f9761..0c28e1b 100644 --- a/arch/arm/include/asm/arch-vf610/imx-regs.h +++ b/arch/arm/include/asm/arch-vf610/imx-regs.h @@ -215,6 +215,7 @@ #define DDRMC_CR139_PHY_WRLV_EN(v) ((v) & 0xff) #define DDRMC_CR154_PAD_ZQ_EARLY_CMP_EN_TIMER(v) (((v) & 0x1f) << 27) #define DDRMC_CR154_PAD_ZQ_MODE(v) (((v) & 0x3) << 21) +#define DDRMC_CR154_DDR_SEL_PAD_CONTR(v) (((v) & 0x3) << 18) #define DDRMC_CR155_AXI0_AWCACHE (1 << 10) #define DDRMC_CR155_PAD_ODT_BYTE1(v) ((v) & 0x7) #define DDRMC_CR158_TWR(v) ((v) & 0x3f) diff --git a/board/freescale/vf610twr/vf610twr.c b/board/freescale/vf610twr/vf610twr.c index 4ee74c0..d64d3aa 100644 --- a/board/freescale/vf610twr/vf610twr.c +++ b/board/freescale/vf610twr/vf610twr.c @@ -217,7 +217,8 @@ void ddr_ctrl_init(void) &ddrmr->cr[139]); writel(DDRMC_CR154_PAD_ZQ_EARLY_CMP_EN_TIMER(13) | - DDRMC_CR154_PAD_ZQ_MODE(1), &ddrmr->cr[154]); + DDRMC_CR154_PAD_ZQ_MODE(1) | + DDRMC_CR154_DDR_SEL_PAD_CONTR(3), &ddrmr->cr[154]); writel(DDRMC_CR155_AXI0_AWCACHE | DDRMC_CR155_PAD_ODT_BYTE1(2), &ddrmr->cr[155]); writel(DDRMC_CR158_TWR(6), &ddrmr->cr[158]); -- 1.9.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v7 02/13] lib: strto: fix metric suffix parsing in strtoul[l]
On 03.09.2018 08:49, Miquel Raynal wrote:
Hi Stefan,
Stefan Roese wrote on Sat, 1 Sep 2018 10:48:25 +0200:
On 31.08.2018 16:57, Miquel Raynal wrote:
While 1kB or 1kiB will be parsed correctly, 1k will return the right
amount, but the metric suffix will not be escaped once the char
pointer updated. Fix this situation by simplifying the move of the
endp pointer.
Signed-off-by: Miquel Raynal
---
lib/strto.c | 22 ++
1 file changed, 10 insertions(+), 12 deletions(-)
diff --git a/lib/strto.c b/lib/strto.c
index 84f8d92d57..502a0153e7 100644
--- a/lib/strto.c
+++ b/lib/strto.c
@@ -97,12 +97,11 @@ unsigned long ustrtoul(const char *cp, char **endp,
unsigned int base)
case 'K':
case 'k':
result *= 1024;
- if ((*endp)[1] == 'i') {
- if ((*endp)[2] == 'B')
- (*endp) += 3;
- else
- (*endp) += 2;
- }
+ (*endp)++;
+ if (**endp == 'i')
+ (*endp)++;
+ if (**endp == 'B')
+ (*endp)++;
}
return result;
}
@@ -122,12 +121,11 @@ unsigned long long ustrtoull(const char *cp, char **endp,
unsigned int base)
case 'K':
case 'k':
result *= 1024;
- if ((*endp)[1] == 'i') {
- if ((*endp)[2] == 'B')
- (*endp) += 3;
- else
- (*endp) += 2;
- }
+ (*endp)++;
+ if (**endp == 'i')
+ (*endp)++;
+ if (**endp == 'B')
+ (*endp)++;
}
return result;
}
Even though KiB is not equal to KB in general (at least in Linux
userspace AFAIK), lets not change this in U-Boot and always use
KiB and KB as a representation for 1024 (instead of 1000). So:
That's right I did not mentioned it in the commit log. I could
update it to reflect that it is intentional to mix 'k' and 'kiB' as a
representation of '* 12014' (already the case, but being clarified in
the above change).
If you will send a new version of these patches, then this would be
great to clarify this usage.
Thanks,
Stefan
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v7 10/13] cmd: mtd: add 'mtd' command
On 03.09.2018 08:54, Miquel Raynal wrote:
Hi Stefan,
Stefan Roese wrote on Sat, 1 Sep 2018 10:59:56 +0200:
On 31.08.2018 16:57, Miquel Raynal wrote:
There should not be a 'nand' command, a 'sf' command and certainly not
a new 'spi-nand' command. Write a 'mtd' command instead to manage all
MTD devices/partitions at once. This should be the preferred way to
access any MTD device.
Signed-off-by: Miquel Raynal
Acked-by: Jagan Teki
---
cmd/Kconfig | 10 +-
cmd/Makefile | 1 +
cmd/mtd.c| 517 +++
drivers/mtd/Makefile | 2 +-
include/mtd.h| 1 +
5 files changed, 528 insertions(+), 3 deletions(-)
create mode 100644 cmd/mtd.c
diff --git a/cmd/Kconfig b/cmd/Kconfig
index ef43ed8dda..0778d2ecff 100644
--- a/cmd/Kconfig
+++ b/cmd/Kconfig
@@ -847,6 +847,12 @@ config CMD_MMC_SWRITE
Enable support for the "mmc swrite" command to write Android sparse
images to eMMC.
> +config CMD_MTD
+ bool "mtd"
+ select MTD_PARTITIONS
+ help
+ MTD commands support.
+
config CMD_NAND
bool "nand"
default y if NAND_SUNXI
@@ -1671,14 +1677,14 @@ config CMD_MTDPARTS
> config MTDIDS_DEFAULT
string "Default MTD IDs"
- depends on CMD_MTDPARTS || CMD_NAND || CMD_FLASH
+ depends on CMD_MTD || CMD_MTDPARTS || CMD_NAND || CMD_FLASH
help
Defines a default MTD IDs list for use with MTD partitions in the
Linux MTD command line partitions format.
> config MTDPARTS_DEFAULT
string "Default MTD partition scheme"
- depends on CMD_MTDPARTS || CMD_NAND || CMD_FLASH
+ depends on CMD_MTD || CMD_MTDPARTS || CMD_NAND || CMD_FLASH
help
Defines a default MTD partitioning scheme in the Linux MTD command
line partitions format
diff --git a/cmd/Makefile b/cmd/Makefile
index 323f1fd2c7..32fd102189 100644
--- a/cmd/Makefile
+++ b/cmd/Makefile
@@ -90,6 +90,7 @@ obj-$(CONFIG_CMD_MISC) += misc.o
obj-$(CONFIG_CMD_MMC) += mmc.o
obj-$(CONFIG_CMD_MMC_SPI) += mmc_spi.o
obj-$(CONFIG_MP) += mp.o
+obj-$(CONFIG_CMD_MTD) += mtd.o
obj-$(CONFIG_CMD_MTDPARTS) += mtdparts.o
obj-$(CONFIG_CMD_NAND) += nand.o
obj-$(CONFIG_CMD_NET) += net.o
diff --git a/cmd/mtd.c b/cmd/mtd.c
new file mode 100644
index 00..32295fe86c
--- /dev/null
+++ b/cmd/mtd.c
@@ -0,0 +1,517 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * mtd.c
+ *
+ * Generic command to handle basic operations on any memory device.
+ *
+ * Copyright: Bootlin, 2018
+ * Author: Miquèl Raynal
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define MTD_NAME_MAX_LEN 20
+
+static char *old_mtdparts;
+
+static void mtd_dump_buf(u8 *buf, uint len, uint offset)
+{
+ int i, j;
+
+ for (i = 0; i < len; ) {
+ printf("0x%08x:\t", offset + i);
+ for (j = 0; j < 8; j++)
+ printf("%02x ", buf[i + j]);
+ printf(" ");
+ i += 8;
+ for (j = 0; j < 8; j++)
+ printf("%02x ", buf[i + j]);
+ printf("\n");
+ i += 8;
+ }
+}
+
+static void mtd_show_parts(struct mtd_info *mtd, int level)
+{
+ struct mtd_info *part;
+ int i;
+
+ if (list_empty(&mtd->partitions))
+ return;
+
+ list_for_each_entry(part, &mtd->partitions, node) {
+ for (i = 0; i < level; i++)
+ printf("\t");
+ printf("* %s\n", part->name);
+ for (i = 0; i < level; i++)
+ printf("\t");
+ printf(" > Offset: 0x%llx bytes\n", part->offset);
+ for (i = 0; i < level; i++)
+ printf("\t");
+ printf(" > Size: 0x%llx bytes\n", part->size);
+
+ mtd_show_parts(part, level + 1);
+ }
+}
+
+static void mtd_show_device(struct mtd_info *mtd)
+{
+ /* Device */
+ printf("* %s", mtd->name);
+ if (mtd->dev)
+ printf(" [device: %s] [parent: %s] [driver: %s]",
+ mtd->dev->name, mtd->dev->parent->name,
+ mtd->dev->driver->name);
+ printf("\n");
+
+ /* MTD device information */
+ printf(" > type: ");
+ switch (mtd->type) {
+ case MTD_RAM:
+ printf("RAM\n");
+ break;
+ case MTD_ROM:
+ printf("ROM\n");
+ break;
+ case MTD_NORFLASH:
+ printf("NOR fla
Re: [U-Boot] [PATCH 2/4] serial: protect access to serial rx buffer
Hi Patrick,
On 03.09.2018 15:35, Patrick DELAUNAY wrote:
Hi Simon and Stefan,
Sorry for my late answer (I just come back from my summer holiday)
From: s...@google.com On Behalf Of Simon Glass
Sent: mercredi 8 août 2018 11:56
On 3 August 2018 at 05:38, Patrick Delaunay wrote:
Add test to avoid access to rx buffer when this buffer is empty.
In this case directly call getc() function to avoid issue when tstc()
is not called.
Signed-off-by: Patrick Delaunay
---
drivers/serial/serial-uclass.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/serial/serial-uclass.c
b/drivers/serial/serial-uclass.c index 321d23e..4121a37 100644
--- a/drivers/serial/serial-uclass.c
+++ b/drivers/serial/serial-uclass.c
@@ -228,6 +228,9 @@ static int _serial_getc(struct udevice *dev)
struct serial_dev_priv *upriv = dev_get_uclass_priv(dev);
char val;
+ if (upriv->rd_ptr == upriv->wr_ptr)
+ return __serial_getc(dev);
+
val = upriv->buf[upriv->rd_ptr++];
upriv->rd_ptr %= CONFIG_SERIAL_RX_BUFFER_SIZE;
--
2.7.4
Reviewed-by: Simon Glass
BTW I think the code in _serial_tstc() is wrong, or at least sub-optimal:
/* Read all available chars into the RX buffer */ while (__serial_tstc(dev)) {
upriv->buf[upriv->wr_ptr++] = __serial_getc(dev);
upriv->wr_ptr %= CONFIG_SERIAL_RX_BUFFER_SIZE; }
It should call serial_getc() until it returns -EAGAIN. There should be no need
to
call __serial_tstc() first,
This part had be added by Stefan Roese in
SHA1 3ca7a06afb7cbc867b7861a8b9aada74e5bbb559
But I check again the code, and I think the code is correct
I really hope so. I did test this implementation quite heavily at
that time.
but I agree it is not optimal.
we can directly ops->getc(dev) and no more __serial_getc() or
__serial_tstc() :
the behavior don't change but the access to serial driver is reduced.
When no char is available, ops->getc witll return -EAGAIN
static int _serial_tstc(struct udevice *dev)
{
struct dm_serial_ops *ops = serial_get_ops(dev);
struct serial_dev_priv *upriv = dev_get_uclass_priv(dev);
int err;
/* Read all available chars into the RX buffer */
while(1) {
err = ops->getc(dev);
if (err < 0)
break;
upriv->buf[upriv->wr_ptr++] = err;
upriv->wr_ptr %= CONFIG_SERIAL_RX_BUFFER_SIZE;
}
return upriv->rd_ptr != upriv->wr_ptr ? 1 : 0;
}
If you are OK I will push a other patchset for these otpimisation.
I'm not 100% sure, if this new implementation is "better". Lets
compare the code:
Current version:
static int _serial_tstc(struct udevice *dev)
{
struct serial_dev_priv *upriv = dev_get_uclass_priv(dev);
/* Read all available chars into the RX buffer */
while (__serial_tstc(dev)) {
upriv->buf[upriv->wr_ptr++] = __serial_getc(dev);
upriv->wr_ptr %= CONFIG_SERIAL_RX_BUFFER_SIZE;
}
return upriv->rd_ptr != upriv->wr_ptr ? 1 : 0;
}
New version:
static int _serial_tstc(struct udevice *dev)
{
struct dm_serial_ops *ops = serial_get_ops(dev);
struct serial_dev_priv *upriv = dev_get_uclass_priv(dev);
int err;
/* Read all available chars into the RX buffer */
while(1) {
err = ops->getc(dev);
if (err < 0)
break;
upriv->buf[upriv->wr_ptr++] = err;
upriv->wr_ptr %= CONFIG_SERIAL_RX_BUFFER_SIZE;
}
return upriv->rd_ptr != upriv->wr_ptr ? 1 : 0;
}
The new version has more code and will most likely produce
a larger binary. You are removing the calls to the __foo()
functions - making the call chain a bit smaller. But this
will only affect the performance which is most likely negligible
in this case.
I any case, I don't object against any "optimizations" here.
But please make sure to test any changes very thorough - please
also on platforms with limited RX FIFO sizes.
Thanks,
Stefan
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/4] serial: protect access to serial rx buffer
Hi Patrick,
On 04.09.2018 09:56, Patrick DELAUNAY wrote:
Hi Stefan
From: Stefan
Sent: lundi 3 septembre 2018 16:03
Hi Patrick,
On 03.09.2018 15:35, Patrick DELAUNAY wrote:
Hi Simon and Stefan,
Sorry for my late answer (I just come back from my summer holiday)
From: s...@google.com On Behalf Of Simon Glass
Sent: mercredi 8 août 2018 11:56
On 3 August 2018 at 05:38, Patrick Delaunay
wrote:
Add test to avoid access to rx buffer when this buffer is empty.
In this case directly call getc() function to avoid issue when
tstc() is not called.
Signed-off-by: Patrick Delaunay
---
drivers/serial/serial-uclass.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/serial/serial-uclass.c
b/drivers/serial/serial-uclass.c index 321d23e..4121a37 100644
--- a/drivers/serial/serial-uclass.c
+++ b/drivers/serial/serial-uclass.c
@@ -228,6 +228,9 @@ static int _serial_getc(struct udevice *dev)
struct serial_dev_priv *upriv = dev_get_uclass_priv(dev);
char val;
+ if (upriv->rd_ptr == upriv->wr_ptr)
+ return __serial_getc(dev);
+
val = upriv->buf[upriv->rd_ptr++];
upriv->rd_ptr %= CONFIG_SERIAL_RX_BUFFER_SIZE;
--
2.7.4
Reviewed-by: Simon Glass
BTW I think the code in _serial_tstc() is wrong, or at least sub-optimal:
/* Read all available chars into the RX buffer */ while (__serial_tstc(dev)) {
upriv->buf[upriv->wr_ptr++] = __serial_getc(dev);
upriv->wr_ptr %= CONFIG_SERIAL_RX_BUFFER_SIZE; }
It should call serial_getc() until it returns -EAGAIN. There should
be no need to call __serial_tstc() first,
This part had be added by Stefan Roese in
SHA1 3ca7a06afb7cbc867b7861a8b9aada74e5bbb559
But I check again the code, and I think the code is correct
I really hope so. I did test this implementation quite heavily at that time.
but I agree it is not optimal.
we can directly ops->getc(dev) and no more __serial_getc() or
__serial_tstc() :
the behavior don't change but the access to serial driver is reduced.
When no char is available, ops->getc witll return -EAGAIN
static int _serial_tstc(struct udevice *dev) {
struct dm_serial_ops *ops = serial_get_ops(dev);
struct serial_dev_priv *upriv = dev_get_uclass_priv(dev);
int err;
/* Read all available chars into the RX buffer */
while(1) {
err = ops->getc(dev);
if (err < 0)
break;
upriv->buf[upriv->wr_ptr++] = err;
upriv->wr_ptr %= CONFIG_SERIAL_RX_BUFFER_SIZE;
}
return upriv->rd_ptr != upriv->wr_ptr ? 1 : 0; }
If you are OK I will push a other patchset for these otpimisation.
I'm not 100% sure, if this new implementation is "better". Lets compare the
code:
Current version:
static int _serial_tstc(struct udevice *dev) {
struct serial_dev_priv *upriv = dev_get_uclass_priv(dev);
/* Read all available chars into the RX buffer */
while (__serial_tstc(dev)) {
upriv->buf[upriv->wr_ptr++] = __serial_getc(dev);
upriv->wr_ptr %= CONFIG_SERIAL_RX_BUFFER_SIZE;
}
return upriv->rd_ptr != upriv->wr_ptr ? 1 : 0; }
New version:
static int _serial_tstc(struct udevice *dev) {
struct dm_serial_ops *ops = serial_get_ops(dev);
struct serial_dev_priv *upriv = dev_get_uclass_priv(dev);
int err;
/* Read all available chars into the RX buffer */
while(1) {
err = ops->getc(dev);
if (err < 0)
break;
upriv->buf[upriv->wr_ptr++] = err;
upriv->wr_ptr %= CONFIG_SERIAL_RX_BUFFER_SIZE;
}
return upriv->rd_ptr != upriv->wr_ptr ? 1 : 0; }
The new version has more code and will most likely produce a larger binary. You
are removing the calls to the __foo() functions - making the call chain a bit
smaller. But this will only affect the performance which is most likely
negligible
in this case.
Yes, perhaps a larger code but no more "pending" ops call of serial driver.
I only directly use getc ops => that avoid one access to HW register I think.
Than can improve the execution time, but I agree that seems marginal in most
the case.
I any case, I don't object against any "optimizations" here.
But please make sure to test any changes very thorough - please also on
platforms with limited RX FIFO sizes.
Unfortunately I have no platform with limited FIFO size, So I don't known how
test it deeply.
And the impact depends also how is implemented the serial driver (gets and
pending ops can use several HW register access and is depending on the access
time to the IP).
But if you and Simon think that "optimization" is not needed, you can forget
this proposal because I think also the gain shou
Re: [U-Boot] [PATCH 1/6 v3] mips: Add basic MediaTek MT7620/88 support
Hi Daniel,
On 05.09.2018 13:45, Daniel Schwierzeck wrote:
On 16.08.2018 15:27, Stefan Roese wrote:
This patch adds basic support for the MediaTek MT7620/88 SoCs. Parts of
the code is copied from the MediaTek GitHub repository:
https://github.com/MediaTek-Labs/linkit-smart-uboot.git
The mt7628a.dtsi file is imported from Linux v4.17.
Support for the LinkIt Smart 7688 module and the Gardena Smart Gateway
both based on the MT7688 will be added in further patches.
Signed-off-by: Stefan Roese
Cc: Daniel Schwierzeck
---
v3:
- Added dtsi file with this platforms support as suggested by Daniel
- Rebased on top of Daniels I-cache startup patches -> removed magic
with KSEG0 call of ddr_calibrate. Its now called directly and the
bootup is much faster
- Some improvements to print_cpuinfo(), use ioremap_nocache etc
- Added .set noreorder to lowlevel_init.S
- Multiple improvements to lowlevel_init.S as suggested by Daniel
v2:
- Sort Kconfig symbols alphabetically
- Use MIPS_TUNE_24KC
- Use imply for SPI support
- Dont' add LinkIt module support yet (is added with the board support)
- Move SKIP_LOWLEVEL_INIT from Kconfig to config header
- Use DT to get the base address of the system controller (for
display_cpuinfo)
- Remove _machine_restart - a separate driver is provided in a new patch
- Remove cachop_op() and cal_invalidate_dcache_range and use the
generic invalidate_dcache_range function instead
arch/mips/Kconfig | 16 +
arch/mips/Makefile| 1 +
arch/mips/dts/mt7628a.dtsi| 135 +
arch/mips/mach-mt7620/Kconfig | 113 +++
arch/mips/mach-mt7620/Makefile| 8 +
arch/mips/mach-mt7620/cpu.c | 69 +
arch/mips/mach-mt7620/ddr_calibrate.c | 308 +++
arch/mips/mach-mt7620/lowlevel_init.S | 406 ++
arch/mips/mach-mt7620/mt76xx.h| 32 ++
9 files changed, 1088 insertions(+)
create mode 100644 arch/mips/dts/mt7628a.dtsi
create mode 100644 arch/mips/mach-mt7620/Kconfig
create mode 100644 arch/mips/mach-mt7620/Makefile
create mode 100644 arch/mips/mach-mt7620/cpu.c
create mode 100644 arch/mips/mach-mt7620/ddr_calibrate.c
create mode 100644 arch/mips/mach-mt7620/lowlevel_init.S
create mode 100644 arch/mips/mach-mt7620/mt76xx.h
diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index 6e5e0ffe65..b3981ef2e6 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -68,6 +68,21 @@ config ARCH_BMIPS
select SYSRESET
imply CMD_DM
+config ARCH_MT7620
+ bool "Support MT7620/7688 SoCs"
+ imply CMD_DM
+ select DISPLAY_CPUINFO
+ select DM
+ select DM_SERIAL
+ imply DM_SPI
+ imply DM_SPI_FLASH
+ select MIPS_TUNE_24KC
+ select OF_CONTROL
+ select ROM_EXCEPTION_VECTORS
+ select SUPPORTS_CPU_MIPS32_R1
+ select SUPPORTS_CPU_MIPS32_R2
+ select SUPPORTS_LITTLE_ENDIAN
+
config MACH_PIC32
bool "Support Microchip PIC32"
select DM
@@ -120,6 +135,7 @@ source "board/qemu-mips/Kconfig"
source "arch/mips/mach-ath79/Kconfig"
source "arch/mips/mach-bmips/Kconfig"
source "arch/mips/mach-pic32/Kconfig"
+source "arch/mips/mach-mt7620/Kconfig"
if MIPS
diff --git a/arch/mips/Makefile b/arch/mips/Makefile
index a36f5f1fb6..802244a06e 100644
--- a/arch/mips/Makefile
+++ b/arch/mips/Makefile
@@ -14,6 +14,7 @@ libs-y += arch/mips/lib/
machine-$(CONFIG_ARCH_ATH79) += ath79
machine-$(CONFIG_ARCH_BMIPS) += bmips
machine-$(CONFIG_MACH_PIC32) += pic32
+machine-$(CONFIG_ARCH_MT7620) += mt7620
machdirs := $(patsubst %,arch/mips/mach-%/,$(machine-y))
libs-y += $(machdirs)
diff --git a/arch/mips/dts/mt7628a.dtsi b/arch/mips/dts/mt7628a.dtsi
new file mode 100644
index 00..d00f528e1f
--- /dev/null
+++ b/arch/mips/dts/mt7628a.dtsi
@@ -0,0 +1,135 @@
+// SPDX-License-Identifier: GPL-2.0
+
+/ {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "ralink,mt7628a-soc";
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cpu@0 {
+ compatible = "mti,mips24KEc";
+ device_type = "cpu";
+ reg = <0>;
+ };
+ };
+
+ resetc: reset-controller {
+ compatible = "ralink,rt2880-reset";
+ #reset-cells = <1>;
+ };
+
+ cpuintc: interrupt-controller {
+ #address-cells = <0>;
+ #interrupt-cells = <1>;
+ interrupt-controller;
+ compatible = "mti,cpu-interrupt-controller";
+ };
+
+ palmbus@1000 {
+ compatible = "palmbus", "simple-bus";
+ reg
Re: [U-Boot] [RFC PATCH v1] mips: add atomic operations
Hi Chris,
(added Daniel)
On 07.09.2018 10:24, Chris Packham wrote:
Add mips version of atomic.h and basic atomic operations. These aren't
the optimised versions from the Linux kernel, just basic stubs that
satisfy users that need something to define atomic_inc() etc.
Signed-off-by: Chris Packham
---
At $dayjob we have a mips target that we want to run UBIFS on. UBIFS
requires atomic.h. This is my naive attempt to supply enough of atomic.h
to satisfy UBIFS.
It's no coincidence that this looks like the arm version. I am
wondering if it's worth a asm-generic version leaving architectures that
actually need true atomic operations able to define them.
I did a pretty similar job and copied the files from xtensa a few
weeks ago:
https://patchwork.ozlabs.org/patch/958286/
It would be better of course, to have some generic version of this
file. But frankly, I don't have the time right now for this.
Thanks,
Stefan
arch/mips/include/asm/atomic.h | 151 +
1 file changed, 151 insertions(+)
create mode 100644 arch/mips/include/asm/atomic.h
diff --git a/arch/mips/include/asm/atomic.h b/arch/mips/include/asm/atomic.h
new file mode 100644
index ..3ab5684fdef4
--- /dev/null
+++ b/arch/mips/include/asm/atomic.h
@@ -0,0 +1,151 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+#ifndef _ASM_ATOMIC_H
+#define _ASM_ATOMIC_H
+
+#include
+
+typedef struct { volatile int counter; } atomic_t;
+#if BITS_PER_LONG == 32
+typedef struct { volatile long long counter; } atomic64_t;
+#else /* BIT_PER_LONG == 32 */
+typedef struct { volatile long counter; } atomic64_t;
+#endif
+
+#define ATOMIC_INIT(i) { (i) }
+
+#define atomic_read(v) ((v)->counter)
+#define atomic_set(v, i) (((v)->counter) = (i))
+#define atomic64_read(v) atomic_read(v)
+#define atomic64_set(v, i) atomic_set(v, i)
+
+static inline void atomic_add(int i, volatile atomic_t *v)
+{
+ unsigned long flags = 0;
+
+ local_irq_save(flags);
+ v->counter += i;
+ local_irq_restore(flags);
+}
+
+static inline void atomic_sub(int i, volatile atomic_t *v)
+{
+ unsigned long flags = 0;
+
+ local_irq_save(flags);
+ v->counter -= i;
+ local_irq_restore(flags);
+}
+
+static inline void atomic_inc(volatile atomic_t *v)
+{
+ unsigned long flags = 0;
+
+ local_irq_save(flags);
+ v->counter += 1;
+ local_irq_restore(flags);
+}
+
+static inline void atomic_dec(volatile atomic_t *v)
+{
+ unsigned long flags = 0;
+
+ local_irq_save(flags);
+ v->counter -= 1;
+ local_irq_restore(flags);
+}
+
+static inline int atomic_dec_and_test(volatile atomic_t *v)
+{
+ unsigned long flags = 0;
+ int val;
+
+ local_irq_save(flags);
+ val = v->counter;
+ v->counter = val -= 1;
+ local_irq_restore(flags);
+
+ return val == 0;
+}
+
+static inline int atomic_add_negative(int i, volatile atomic_t *v)
+{
+ unsigned long flags = 0;
+ int val;
+
+ local_irq_save(flags);
+ val = v->counter;
+ v->counter = val += i;
+ local_irq_restore(flags);
+
+ return val < 0;
+}
+
+static inline void atomic_clear_mask(unsigned long mask, unsigned long *addr)
+{
+ unsigned long flags = 0;
+
+ local_irq_save(flags);
+ *addr &= ~mask;
+ local_irq_restore(flags);
+}
+
+#if BITS_PER_LONG == 32
+
+static inline void atomic64_add(long long i, volatile atomic64_t *v)
+{
+ unsigned long flags = 0;
+
+ local_irq_save(flags);
+ v->counter += i;
+ local_irq_restore(flags);
+}
+
+static inline void atomic64_sub(long long i, volatile atomic64_t *v)
+{
+ unsigned long flags = 0;
+
+ local_irq_save(flags);
+ v->counter -= i;
+ local_irq_restore(flags);
+}
+
+#else /* BIT_PER_LONG == 32 */
+
+static inline void atomic64_add(long i, volatile atomic64_t *v)
+{
+ unsigned long flags = 0;
+
+ local_irq_save(flags);
+ v->counter += i;
+ local_irq_restore(flags);
+}
+
+static inline void atomic64_sub(long i, volatile atomic64_t *v)
+{
+ unsigned long flags = 0;
+
+ local_irq_save(flags);
+ v->counter -= i;
+ local_irq_restore(flags);
+}
+#endif /* BIT_PER_LONG == 32 */
+
+static inline void atomic64_inc(volatile atomic64_t *v)
+{
+ unsigned long flags = 0;
+
+ local_irq_save(flags);
+ v->counter += 1;
+ local_irq_restore(flags);
+}
+
+static inline void atomic64_dec(volatile atomic64_t *v)
+{
+ unsigned long flags = 0;
+
+ local_irq_save(flags);
+ v->counter -= 1;
+ local_irq_restore(flags);
+}
+
+#endif
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [RFC PATCH] fpga: zynq: Add encrypted bitstream support with auto detect
From: Stefan Herbrechtsmeier
Signed-off-by: Stefan Herbrechtsmeier
---
drivers/fpga/zynqpl.c | 73 ---
1 file changed, 57 insertions(+), 16 deletions(-)
diff --git a/drivers/fpga/zynqpl.c b/drivers/fpga/zynqpl.c
index fd37d18..6622750 100644
--- a/drivers/fpga/zynqpl.c
+++ b/drivers/fpga/zynqpl.c
@@ -17,6 +17,7 @@
#define DEVCFG_CTRL_PCFG_PROG_B0x4000
#define DEVCFG_CTRL_PCFG_AES_EFUSE_MASK0x1000
+#define DEVCFG_CTRL_PCAP_RATE_EN_MASK 0x0200
#define DEVCFG_ISR_FATAL_ERROR_MASK0x00740040
#define DEVCFG_ISR_ERROR_FLAGS_MASK0x00340840
#define DEVCFG_ISR_RX_FIFO_OV 0x0004
@@ -38,18 +39,16 @@
#define CONFIG_SYS_FPGA_PROG_TIME (CONFIG_SYS_HZ * 4) /* 4 s */
#endif
+#define NOP_WORD 0x2000
+#define CTRL0_WORD 0x3000a001
+#define MASK_WORD 0x3000c001
#define DUMMY_WORD 0x
+#define CTRL0_DEC_MASK BIT(6)
+
/* Xilinx binary format header */
+#define MAX_DUMMY_WORD_COUNT 8
static const u32 bin_format[] = {
- DUMMY_WORD, /* Dummy words */
- DUMMY_WORD,
- DUMMY_WORD,
- DUMMY_WORD,
- DUMMY_WORD,
- DUMMY_WORD,
- DUMMY_WORD,
- DUMMY_WORD,
0x00bb, /* Sync word */
0x11220044, /* Sync word */
DUMMY_WORD,
@@ -85,7 +84,23 @@ static u32 load_word(const void *buf, u32 swap)
return word;
}
-static u32 check_header(const void *buf)
+static void *skip_dummy_words(const void *buf)
+{
+ u32 *test = (u32 *)buf;
+ u32 i;
+
+ for (i = 0; i < MAX_DUMMY_WORD_COUNT; i++) {
+ if (load_word(&test[i], SWAP_NO) != DUMMY_WORD) {
+ debug("%s: Found no dummy word at position %d/%x\n",
+ __func__, i, (u32)&test[i]);
+ return &test[i];
+ }
+ }
+
+ return &test[i];
+}
+
+static u32 check_header(const void *buf, bool *encrypted)
{
u32 i, pattern;
int swap = SWAP_NO;
@@ -93,6 +108,8 @@ static u32 check_header(const void *buf)
debug("%s: Let's check bitstream header\n", __func__);
+ test = (u32 *)skip_dummy_words(buf);
+
/* Checking that passing bin is not a bitstream */
for (i = 0; i < ARRAY_SIZE(bin_format); i++) {
pattern = load_word(&test[i], swap);
@@ -112,18 +129,34 @@ static u32 check_header(const void *buf)
debug("%s: %d/%x: pattern %x/%x bin_format\n", __func__, i,
(u32)&test[i], pattern, bin_format[i]);
+
if (pattern != bin_format[i]) {
debug("%s: Bitstream is not recognized\n", __func__);
return 0;
}
}
- debug("%s: Found bitstream header at %x %s swapinng\n", __func__,
- (u32)buf, swap == SWAP_NO ? "without" : "with");
+
+ test = &test[i];
+
+ /* Checking if passing bin is an encrypted bitstream */
+ if ((load_word(&test[0], swap) == NOP_WORD) &&
+ (load_word(&test[1], swap) == MASK_WORD) &&
+ (load_word(&test[2], swap) & CTRL0_DEC_MASK) &&
+ (load_word(&test[3], swap) == CTRL0_WORD) &&
+ (load_word(&test[4], swap) & CTRL0_DEC_MASK) &&
+ (load_word(&test[5], swap) == NOP_WORD))
+ *encrypted = true;
+ else
+ *encrypted = false;
+
+ debug("%s: Found %sencrypted bitstream header at %x %s swapping\n",
+ __func__, *encrypted ? "" : "un", (u32)buf,
+ swap == SWAP_NO ? "without" : "with");
return swap;
}
-static void *check_data(u8 *buf, size_t bsize, u32 *swap)
+static void *check_data(u8 *buf, size_t bsize, u32 *swap, bool *encrypted)
{
u32 word, p = 0; /* possition */
@@ -136,7 +169,7 @@ static void *check_data(u8 *buf, size_t bsize, u32 *swap)
if (word == DUMMY_WORD) {
debug("%s: Found dummy word at position %x/%x\n",
__func__, p, (u32)&buf[p]);
- *swap = check_header(&buf[p]);
+ *swap = check_header(&buf[p], encrypted);
if (*swap) {
/* FIXME add full bitstream checking here */
return &buf[p];
@@ -191,7 +224,7 @@ static int zynq_dma_transfer(u32 srcbuf, u32 srclen, u32
dstbuf, u32 dstlen)
return FPGA_SUCCESS;
}
-static int zynq_dma_xfer_init(bitstream_type bstype)
+static int zynq_dma_xfer_init(bitstream_type bstype, bool encrypted)
{
u32 status, control, isr_status;
unsigned long ts;
@@ -291,6 +324,13 @@ static int
Re: [U-Boot] [PATCH 0/4] Rationalise atomic.h implementations
On 08.09.2018 11:39, Chris Packham wrote: This series applies on top of https://patchwork.ozlabs.org/patch/958286/ The intention is to rationalise most of the current implementations of atomic.h. x86 remains as having an arch specific implementation which I don't intend to touch. Chris Packham (4): Add include/asm-generic/atomic.h ARM: use asm-generic/atomic.h mips: use asm-generic/atomic.h xtensa: use asm-generic/atomic.h arch/arm/include/asm/atomic.h| 147 +- arch/mips/include/asm/atomic.h | 44 + arch/xtensa/include/asm/atomic.h | 44 + include/asm-generic/atomic.h | 150 +++ 4 files changed, 153 insertions(+), 232 deletions(-) create mode 100644 include/asm-generic/atomic.h Thanks Chris for taking care of this. For the whole series: Reviewed-by: Stefan Roese Thanks, Stefan ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] Fix --noheader on fw_printenv
On 08.02.2018 10:35, Alex Kiernan wrote:
> Using fw_printenv with --noheader fails:
>
> root@nrr-922:~# fw_printenv --noheader arch
> ## Error: `-n' option requires exactly one argument
I think it would work with --noheader=arch
>
> Whereas -n works:
>
> root@nrr-922:~# fw_printenv -n arch
> arm
>
> The single argument it's expecting isn't taken from getopt parsing,
> but instead from the remaining argv arguments.
That makes sense. But the commit log text above is kind of unrelated/not
relevant, I would just use this two lines as git message.
--
Stefan
>
> Signed-off-by: Alex Kiernan
> ---
>
> tools/env/fw_env_main.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/tools/env/fw_env_main.c b/tools/env/fw_env_main.c
> index 6fdf41c..d93a915 100644
> --- a/tools/env/fw_env_main.c
> +++ b/tools/env/fw_env_main.c
> @@ -46,7 +46,7 @@ static struct option long_options[] = {
> {"config", required_argument, NULL, 'c'},
> {"help", no_argument, NULL, 'h'},
> {"script", required_argument, NULL, 's'},
> - {"noheader", required_argument, NULL, 'n'},
> + {"noheader", no_argument, NULL, 'n'},
> {"lock", required_argument, NULL, 'l'},
> {"version", no_argument, NULL, 'v'},
> {NULL, 0, NULL, 0}
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] mtd: nand: mxs_nand: use self init
On 29.01.2018 17:01, Stefan Agner wrote:
> From: Stefan Agner
>
> Instead of completing initialization via scan_bbt callback use
> NAND self init to initialize the GPMI (MXS) NAND controller.
>
> Signed-off-by: Stefan Agner
> ---
>
> drivers/mtd/nand/Kconfig| 1 +
> drivers/mtd/nand/mxs_nand.c | 52
> +
> 2 files changed, 30 insertions(+), 23 deletions(-)
>
> diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
> index 78a39abf75..1ca86925dc 100644
> --- a/drivers/mtd/nand/Kconfig
> +++ b/drivers/mtd/nand/Kconfig
> @@ -140,6 +140,7 @@ config NAND_MXC
> config NAND_MXS
> bool "MXS NAND support"
> depends on MX6 || MX7
> + select SYS_NAND_SELF_INIT
Just realized while NAND_MXS is available in Kconfig since commit
df10a850c5e3 ("mtd: nand: Kconfig: Add NAND_MXS entry") several boards
still select CONFIG_NAND_MXS in the old config header. Those need to be
updated to use Kconfig first before we can add this select.
Will send a v2 with the move to Kconfig before this patch.
--
Stefan
> imply CMD_NAND
> help
> This enables NAND driver for the NAND flash controller on the
> diff --git a/drivers/mtd/nand/mxs_nand.c b/drivers/mtd/nand/mxs_nand.c
> index bed9b65ef4..cf96584fa8 100644
> --- a/drivers/mtd/nand/mxs_nand.c
> +++ b/drivers/mtd/nand/mxs_nand.c
> @@ -18,6 +18,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -47,6 +48,7 @@
> #define MXS_NAND_BCH_TIMEOUT1
>
> struct mxs_nand_info {
> + struct nand_chip chip;
> int cur_chip;
>
> uint32_tcmd_queue_len;
> @@ -972,20 +974,15 @@ static int mxs_nand_block_bad(struct mtd_info
> *mtd, loff_t ofs)
> }
>
> /*
> - * Nominally, the purpose of this function is to look for or create the bad
> - * block table. In fact, since the we call this function at the very end of
> - * the initialization process started by nand_scan(), and we doesn't have a
> - * more formal mechanism, we "hook" this function to continue init process.
> - *
> * At this point, the physical NAND Flash chips have been identified and
> * counted, so we know the physical geometry. This enables us to make some
> * important configuration decisions.
> *
> * The return value of this function propagates directly back to this
> driver's
> - * call to nand_scan(). Anything other than zero will cause this driver to
> + * board_nand_init(). Anything other than zero will cause this driver to
> * tear everything down and declare failure.
> */
> -static int mxs_nand_scan_bbt(struct mtd_info *mtd)
> +static int mxs_nand_setup_ecc(struct mtd_info *mtd)
> {
> struct nand_chip *nand = mtd_to_nand(mtd);
> struct mxs_nand_info *nand_info = nand_get_controller_data(nand);
> @@ -1047,8 +1044,7 @@ static int mxs_nand_scan_bbt(struct mtd_info *mtd)
> mtd->_block_markbad = mxs_nand_hook_block_markbad;
> }
>
> - /* We use the reference implementation for bad block management. */
> - return nand_default_bbt(mtd);
> + return 0;
> }
>
> /*
> @@ -1150,27 +1146,22 @@ err1:
> return ret;
> }
>
> -/*!
> - * This function is called during the driver binding process.
> - *
> - * @param pdev the device structure used to store device specific
> - *information that is used by the suspend, resume and
> - *remove functions
> - *
> - * @return The function always returns 0.
> - */
> -int board_nand_init(struct nand_chip *nand)
> +void board_nand_init(void)
> {
> + struct mtd_info *mtd;
> struct mxs_nand_info *nand_info;
> + struct nand_chip *nand;
> int err;
>
> nand_info = malloc(sizeof(struct mxs_nand_info));
> if (!nand_info) {
> printf("MXS NAND: Failed to allocate private data\n");
> - return -ENOMEM;
> + return;
> }
> memset(nand_info, 0, sizeof(struct mxs_nand_info));
>
> + nand = &nand_info->chip;
> + mtd = nand_to_mtd(nand);
> err = mxs_nand_alloc_buffers(nand_info);
> if (err)
> goto err1;
> @@ -1189,13 +1180,19 @@ int board_nand_init(struct nand_chip *nand)
> nand->dev_ready = mxs_nand_device_ready;
> nand->select_chip = mxs_nand_select_chip;
> nand->block_bad = mxs_nand_block_bad;
> - nand->scan_bbt = mxs_nand_scan_bbt;
>
> nand->read_byte = mxs_nand_read_by
Re: [U-Boot] [PATCH] Convert CONFIG_APBH_DMA et al to Kconfig
Hi Adam, On 04.02.2018 15:46, Adam Ford wrote: > This converts the following to Kconfig: >CONFIG_APBH_DMA >CONFIG_APBH_DMA_BURST >CONFIG_APBH_DMA_BURST8 I recently sent a patch which completely converts NAND_MXS to Kconfig https://patchwork.ozlabs.org/patch/868797/ Can you rebase ontop of it? Since APBH DMA is used for the GPMI NAND block only (afaict) we can easily let Kconfig handle the dependency. E.g. in drivers/mtd/nand/Kconfig, add: config NAND_MXS ... select APBH_DMA select APBH_DMA_BURST if ARCH_MX6 || ARCH_MX7 select APBH_DMA_BURST8 if ARCH_MX6 || ARCH_MX7 With that, you should be able to implement your change with just removing APBH_DMA from the headers and adding the dependency to Kconfig files without any defconfig changes. -- Stefan > > Signed-off-by: Adam Ford > --- > configs/apx4devkit_defconfig| 1 + > configs/aristainetos2_defconfig | 3 +++ > configs/aristainetos2b_defconfig| 3 +++ > configs/aristainetos_defconfig | 3 +++ > configs/bg0900_defconfig| 1 + > configs/cm_fx6_defconfig| 11 +++ > configs/colibri_imx7_defconfig | 3 +++ > configs/gwventana_nand_defconfig| 3 +++ > configs/imx6q_logic_defconfig | 3 +++ > configs/imx6qdl_icore_nand_defconfig| 3 +++ > configs/imx6ul_geam_nand_defconfig | 3 +++ > configs/imx6ul_isiot_nand_defconfig | 3 +++ > configs/m28evk_defconfig| 1 + > configs/mx23_olinuxino_defconfig| 1 + > configs/mx23evk_defconfig | 1 + > configs/mx28evk_auart_console_defconfig | 1 + > configs/mx28evk_defconfig | 1 + > configs/mx28evk_nand_defconfig | 1 + > configs/mx28evk_spi_defconfig | 1 + > configs/mx6sabreauto_defconfig | 3 +++ > configs/mx6sxsabreauto_defconfig| 3 +++ > configs/pcm058_defconfig| 3 +++ > configs/pfla02_defconfig| 3 +++ > configs/platinum_picon_defconfig| 3 +++ > configs/platinum_titanium_defconfig | 3 +++ > configs/sansa_fuze_plus_defconfig | 1 + > configs/sc_sps_1_defconfig | 1 + > configs/titanium_defconfig | 3 +++ > configs/ts4600_defconfig| 1 + > configs/xfi3_defconfig | 1 + > drivers/dma/Kconfig | 14 ++ > include/configs/aristainetos-common.h | 3 --- > include/configs/cm_fx6.h| 3 --- > include/configs/colibri_imx7.h | 3 --- > include/configs/gw_ventana.h| 3 --- > include/configs/imx6-engicam.h | 4 > include/configs/imx6_logic.h| 3 --- > include/configs/mx6sabreauto.h | 3 --- > include/configs/mx6sxsabreauto.h| 3 --- > include/configs/mx7dsabresd.h | 3 --- > include/configs/mxs.h | 1 - > include/configs/pcm058.h| 3 --- > include/configs/pfla02.h| 3 --- > include/configs/platinum.h | 3 --- > include/configs/titanium.h | 3 --- > scripts/config_whitelist.txt| 3 --- > 46 files changed, 78 insertions(+), 52 deletions(-) > > diff --git a/configs/apx4devkit_defconfig b/configs/apx4devkit_defconfig > index 47a4ee9..f7d868d 100644 > --- a/configs/apx4devkit_defconfig > +++ b/configs/apx4devkit_defconfig > @@ -26,6 +26,7 @@ CONFIG_MTDIDS_DEFAULT="nand0=gpmi-nand" > > CONFIG_MTDPARTS_DEFAULT="mtdparts=gpmi-nand:128k(bootstrap),1024k(boot),768k(env),-(root)" > CONFIG_CMD_UBI=y > CONFIG_ENV_IS_IN_NAND=y > +CONFIG_APBH_DMA=y > CONFIG_MMC_MXS=y > CONFIG_USB=y > CONFIG_USB_EHCI_HCD=y > diff --git a/configs/aristainetos2_defconfig b/configs/aristainetos2_defconfig > index 288dab0..926f07f 100644 > --- a/configs/aristainetos2_defconfig > +++ b/configs/aristainetos2_defconfig > @@ -31,6 +31,9 @@ CONFIG_CMD_FAT=y > CONFIG_CMD_FS_GENERIC=y > CONFIG_CMD_UBI=y > CONFIG_ENV_IS_IN_SPI_FLASH=y > +CONFIG_APBH_DMA=y > +CONFIG_APBH_DMA_BURST=y > +CONFIG_APBH_DMA_BURST8=y > CONFIG_SPI_FLASH=y > CONFIG_SPI_FLASH_STMICRO=y > CONFIG_MTD_UBI_FASTMAP=y > diff --git a/configs/aristainetos2b_defconfig > b/configs/aristainetos2b_defconfig > index 115ae07..9ab7002 100644 > --- a/configs/aristainetos2b_defconfig > +++ b/configs/aristainetos2b_defconfig > @@ -31,6 +31,9 @@ CONFIG_CMD_FAT=y > CONFIG_CMD_FS_GENERIC=y > CONFIG_CMD_UBI=y > CONFIG_ENV_IS_IN_SPI_FLASH=y > +CONFIG_APBH_DMA=y > +CONFIG_APBH_DMA_BURST=y > +CONFIG_APBH_DMA_BURST8=y > CONFIG_SPI_FLASH=y > CONFIG_SPI_FLASH_STMICRO=y > CONFIG_MTD_UBI_FAS
Re: [U-Boot] [PATCH V2] Convert CONFIG_APBH_DMA et al to Kconfig
On 05.02.2018 14:33, Adam Ford wrote: > This converts the following to Kconfig: >CONFIG_APBH_DMA >CONFIG_APBH_DMA_BURST >CONFIG_APBH_DMA_BURST8 > > Signed-off-by: Adam Ford > --- > Changes in V2: > Rebase on [U-Boot,v2,1/6] Convert CONFIG_NAND_MXS to Kconfig > Make the NAND controller in MX6 MX7 autoselect the DMA options > > configs/bg0900_defconfig| 1 + > configs/mx23_olinuxino_defconfig| 1 + > configs/mx23evk_defconfig | 1 + > configs/mx28evk_auart_console_defconfig | 3 +-- > configs/mx28evk_defconfig | 3 +-- > configs/mx28evk_spi_defconfig | 3 +-- > configs/sansa_fuze_plus_defconfig | 1 + > configs/sc_sps_1_defconfig | 1 + > configs/ts4600_defconfig| 1 + > configs/xfi3_defconfig | 1 + There should be really no defconfig change since CONFIG_NAND_MXS should select CONFIG_APBH_DMA automatically. It seems that my patchset did not handle i.MX 23/28 correctly. Will fix this first. > drivers/dma/Kconfig | 14 ++ > drivers/mtd/nand/Kconfig| 3 +++ > include/configs/aristainetos-common.h | 3 --- > include/configs/cm_fx6.h| 3 --- > include/configs/colibri_imx7.h | 3 --- > include/configs/gw_ventana.h| 3 --- > include/configs/imx6-engicam.h | 4 > include/configs/imx6_logic.h| 3 --- > include/configs/mx6sabreauto.h | 3 --- > include/configs/mx6sxsabreauto.h| 3 --- > include/configs/mx7dsabresd.h | 3 --- > include/configs/mxs.h | 1 - > include/configs/pcm058.h| 3 --- > include/configs/pfla02.h| 3 --- > include/configs/platinum.h | 3 --- > include/configs/titanium.h | 3 --- > scripts/config_whitelist.txt| 3 --- > 27 files changed, 27 insertions(+), 50 deletions(-) > > diff --git a/configs/bg0900_defconfig b/configs/bg0900_defconfig > index 72616ae..7314eff 100644 > --- a/configs/bg0900_defconfig > +++ b/configs/bg0900_defconfig > @@ -25,6 +25,7 @@ CONFIG_CMD_MII=y > CONFIG_CMD_PING=y > CONFIG_CMD_CACHE=y > CONFIG_DOS_PARTITION=y > +CONFIG_APBH_DMA=y > # CONFIG_MMC is not set > CONFIG_SPI_FLASH=y > CONFIG_SPI_FLASH_BAR=y > diff --git a/configs/mx23_olinuxino_defconfig > b/configs/mx23_olinuxino_defconfig > index 628c11d..2c80c3b 100644 > --- a/configs/mx23_olinuxino_defconfig > +++ b/configs/mx23_olinuxino_defconfig > @@ -20,6 +20,7 @@ CONFIG_CMD_CACHE=y > CONFIG_CMD_EXT2=y > CONFIG_CMD_FAT=y > CONFIG_ENV_IS_IN_MMC=y > +CONFIG_APBH_DMA=y > CONFIG_LED_STATUS=y > CONFIG_LED_STATUS_GPIO=y > CONFIG_LED_STATUS0=y > diff --git a/configs/mx23evk_defconfig b/configs/mx23evk_defconfig > index 6ad7f2c..09f3611 100644 > --- a/configs/mx23evk_defconfig > +++ b/configs/mx23evk_defconfig > @@ -24,6 +24,7 @@ CONFIG_CMD_CACHE=y > CONFIG_CMD_EXT2=y > CONFIG_CMD_FAT=y > CONFIG_ENV_IS_IN_MMC=y > +CONFIG_APBH_DMA=y > CONFIG_MMC_MXS=y > CONFIG_USB=y > CONFIG_USB_EHCI_HCD=y > diff --git a/configs/mx28evk_auart_console_defconfig > b/configs/mx28evk_auart_console_defconfig > index 0927333..7bdb905 100644 > --- a/configs/mx28evk_auart_console_defconfig > +++ b/configs/mx28evk_auart_console_defconfig > @@ -16,7 +16,6 @@ CONFIG_CMD_BOOTZ=y > # CONFIG_CMD_FLASH is not set > CONFIG_CMD_GPIO=y > CONFIG_CMD_MMC=y > -CONFIG_CMD_NAND_TRIMFFS=y > CONFIG_CMD_SF=y > CONFIG_CMD_SPI=y > CONFIG_CMD_USB=y > @@ -34,9 +33,9 @@ CONFIG_MTDIDS_DEFAULT="nand0=gpmi-nand" > > CONFIG_MTDPARTS_DEFAULT="mtdparts=gpmi-nand:3m(bootloader)ro,512k(environment),512k(redundant-environment),4m(kernel),512k(fdt),8m(ramdisk),-(filesystem)" > CONFIG_CMD_UBI=y > CONFIG_ENV_IS_IN_MMC=y > +CONFIG_APBH_DMA=y > CONFIG_MMC_MXS=y > CONFIG_NAND=y > -CONFIG_NAND_MXS=y > CONFIG_SPI_FLASH=y > CONFIG_SPI_FLASH_SST=y > CONFIG_USB=y > diff --git a/configs/mx28evk_defconfig b/configs/mx28evk_defconfig > index 21d01bc..d36ad0e 100644 > --- a/configs/mx28evk_defconfig > +++ b/configs/mx28evk_defconfig > @@ -16,7 +16,6 @@ CONFIG_CMD_BOOTZ=y > # CONFIG_CMD_FLASH is not set > CONFIG_CMD_GPIO=y > CONFIG_CMD_MMC=y > -CONFIG_CMD_NAND_TRIMFFS=y > CONFIG_CMD_SF=y > CONFIG_CMD_SPI=y > CONFIG_CMD_USB=y > @@ -34,9 +33,9 @@ CONFIG_MTDIDS_DEFAULT="nand0=gpmi-nand" > > CONFIG_MTDPARTS_DEFAULT="mtdparts=gpmi-nand:3m(bootloader)ro,512k(environment),512k(redundant-environment),4m(kernel),512k(fdt),8m(ramdisk),-(filesystem)" > CONFIG_CMD_UBI=y > CONFIG_ENV_IS_IN_MMC=y > +CONFIG_APBH_DMA=y > CONFIG_MMC_MXS=y > CONFIG_NAND=y > -CONFIG_NAND_MXS=y > CONFIG_SPI_FLASH=y > CONFIG_SPI_FLASH_SST=y > CONFIG_USB=y > diff --git a/configs/mx28evk_spi_defconfig b/configs/mx28evk_spi_defconfig > index dab5394..7bf1d6e 100644 > --- a/configs/mx28evk_spi_defconfig > +++ b/configs/mx28evk_spi_defconfig > @@ -15,7 +15,6 @@ CONFIG_CMD_BOOTZ=y > # CONFIG_CMD_FLASH is not set > CON
Re: [U-Boot] [PATCH v2 1/6] Convert CONFIG_NAND_MXS to Kconfig
On 02.02.2018 22:44, Stefan Agner wrote: > From: Stefan Agner > > This converts CONFIG_NAND_MXS to Kconfig. > > Signed-off-by: Stefan Agner > --- > > Changes in v2: > - Extend the patchset with "Convert CONFIG_NAND_MXS to Kconfig" patch > > configs/apx4devkit_defconfig| 3 ++- > configs/aristainetos2_defconfig | 3 ++- > configs/aristainetos2b_defconfig| 3 ++- > configs/aristainetos_defconfig | 3 ++- > configs/cm_fx6_defconfig| 11 ++- > configs/colibri_imx7_defconfig | 3 ++- > configs/gwventana_nand_defconfig| 3 ++- > configs/m28evk_defconfig| 3 ++- > configs/mx28evk_auart_console_defconfig | 3 ++- > configs/mx28evk_defconfig | 3 ++- > configs/mx28evk_nand_defconfig | 3 ++- > configs/mx28evk_spi_defconfig | 3 ++- > configs/mx6sabreauto_defconfig | 3 ++- > configs/mx6sxsabreauto_defconfig| 3 ++- > configs/pcm058_defconfig| 3 ++- > configs/pfla02_defconfig| 3 +++ > configs/platinum_picon_defconfig| 3 ++- > configs/platinum_titanium_defconfig | 3 ++- > configs/titanium_defconfig | 3 ++- > include/configs/aristainetos-common.h | 1 - > include/configs/cm_fx6.h| 1 - > include/configs/colibri_imx7.h | 2 -- > include/configs/gw_ventana.h| 1 - > include/configs/mx6sabreauto.h | 1 - > include/configs/mx6sxsabreauto.h| 1 - > include/configs/mxs.h | 1 - > include/configs/pcm058.h| 1 - > include/configs/pfla02.h| 1 - > include/configs/platinum.h | 1 - > include/configs/titanium.h | 1 - > 30 files changed, 39 insertions(+), 38 deletions(-) > > diff --git a/configs/apx4devkit_defconfig b/configs/apx4devkit_defconfig > index 47a4ee9e26..cc6da42066 100644 > --- a/configs/apx4devkit_defconfig > +++ b/configs/apx4devkit_defconfig > @@ -13,7 +13,6 @@ CONFIG_SPL=y > CONFIG_HUSH_PARSER=y > # CONFIG_CMD_FLASH is not set > CONFIG_CMD_MMC=y > -CONFIG_CMD_NAND=y > CONFIG_CMD_USB=y > # CONFIG_CMD_SETEXPR is not set > CONFIG_CMD_DHCP=y > @@ -27,6 +26,8 @@ > CONFIG_MTDPARTS_DEFAULT="mtdparts=gpmi-nand:128k(bootstrap),1024k(boot),768k(env > CONFIG_CMD_UBI=y > CONFIG_ENV_IS_IN_NAND=y > CONFIG_MMC_MXS=y > +CONFIG_NAND=y > +CONFIG_NAND_MXS=y This needs NAND_MXS to be selectable for MX23/28 architectures, however with the current Kconfig this is not possible. I have a patchset ready which converts MX23/28 to Kconfig.. I will move this patch ontop of that patchset, and send a v3 for the driver related changes. -- Stefan > CONFIG_USB=y > CONFIG_USB_EHCI_HCD=y > CONFIG_USB_STORAGE=y > diff --git a/configs/aristainetos2_defconfig b/configs/aristainetos2_defconfig > index 288dab0d3c..c0daed6b22 100644 > --- a/configs/aristainetos2_defconfig > +++ b/configs/aristainetos2_defconfig > @@ -14,7 +14,6 @@ CONFIG_CMD_BOOTZ=y > CONFIG_CMD_GPIO=y > CONFIG_CMD_I2C=y > CONFIG_CMD_MMC=y > -CONFIG_CMD_NAND=y > CONFIG_CMD_NAND_TRIMFFS=y > CONFIG_CMD_SF=y > CONFIG_CMD_USB=y > @@ -31,6 +30,8 @@ CONFIG_CMD_FAT=y > CONFIG_CMD_FS_GENERIC=y > CONFIG_CMD_UBI=y > CONFIG_ENV_IS_IN_SPI_FLASH=y > +CONFIG_NAND=y > +CONFIG_NAND_MXS=y > CONFIG_SPI_FLASH=y > CONFIG_SPI_FLASH_STMICRO=y > CONFIG_MTD_UBI_FASTMAP=y > diff --git a/configs/aristainetos2b_defconfig > b/configs/aristainetos2b_defconfig > index 115ae07ad6..fbb2c1c38d 100644 > --- a/configs/aristainetos2b_defconfig > +++ b/configs/aristainetos2b_defconfig > @@ -14,7 +14,6 @@ CONFIG_CMD_BOOTZ=y > CONFIG_CMD_GPIO=y > CONFIG_CMD_I2C=y > CONFIG_CMD_MMC=y > -CONFIG_CMD_NAND=y > CONFIG_CMD_NAND_TRIMFFS=y > CONFIG_CMD_SF=y > CONFIG_CMD_USB=y > @@ -31,6 +30,8 @@ CONFIG_CMD_FAT=y > CONFIG_CMD_FS_GENERIC=y > CONFIG_CMD_UBI=y > CONFIG_ENV_IS_IN_SPI_FLASH=y > +CONFIG_NAND=y > +CONFIG_NAND_MXS=y > CONFIG_SPI_FLASH=y > CONFIG_SPI_FLASH_STMICRO=y > CONFIG_MTD_UBI_FASTMAP=y > diff --git a/configs/aristainetos_defconfig b/configs/aristainetos_defconfig > index cad8b4af8a..13f4d6eb52 100644 > --- a/configs/aristainetos_defconfig > +++ b/configs/aristainetos_defconfig > @@ -14,7 +14,6 @@ CONFIG_CMD_BOOTZ=y > CONFIG_CMD_GPIO=y > CONFIG_CMD_I2C=y > CONFIG_CMD_MMC=y > -CONFIG_CMD_NAND=y > CONFIG_CMD_NAND_TRIMFFS=y > CONFIG_CMD_SF=y > CONFIG_CMD_USB=y > @@ -31,6 +30,8 @@ CONFIG_CMD_FAT=y > CONFIG_CMD_FS_GENERIC=y > CONFIG_CMD_UBI=y > CONFIG_ENV_IS_IN_SPI_FLASH=y > +CONFIG_NAND=y > +CONFIG_NAND_MXS=y > CONFIG_S
Re: [U-Boot] [PATCH V2] Convert CONFIG_APBH_DMA et al to Kconfig
On 05.02.2018 14:33, Adam Ford wrote:
> This converts the following to Kconfig:
>CONFIG_APBH_DMA
>CONFIG_APBH_DMA_BURST
>CONFIG_APBH_DMA_BURST8
>
> Signed-off-by: Adam Ford
> ---
> Changes in V2:
> Rebase on [U-Boot,v2,1/6] Convert CONFIG_NAND_MXS to Kconfig
> Make the NAND controller in MX6 MX7 autoselect the DMA options
>
> configs/bg0900_defconfig| 1 +
> configs/mx23_olinuxino_defconfig| 1 +
> configs/mx23evk_defconfig | 1 +
> configs/mx28evk_auart_console_defconfig | 3 +--
> configs/mx28evk_defconfig | 3 +--
> configs/mx28evk_spi_defconfig | 3 +--
> configs/sansa_fuze_plus_defconfig | 1 +
> configs/sc_sps_1_defconfig | 1 +
> configs/ts4600_defconfig| 1 +
> configs/xfi3_defconfig | 1 +
Just sent out a patchset ("arm: imx: convert MX23/28 and MXS NAND to
Kconfig") which should properly convert NAND MXS to Kconfig. Can you
rebase again? It really lead to no defconfig changes.
Can you add me to cc in v3? Sorry for the hassle.
--
Stefan
> drivers/dma/Kconfig | 14 ++
> drivers/mtd/nand/Kconfig| 3 +++
> include/configs/aristainetos-common.h | 3 ---
> include/configs/cm_fx6.h| 3 ---
> include/configs/colibri_imx7.h | 3 ---
> include/configs/gw_ventana.h| 3 ---
> include/configs/imx6-engicam.h | 4
> include/configs/imx6_logic.h| 3 ---
> include/configs/mx6sabreauto.h | 3 ---
> include/configs/mx6sxsabreauto.h| 3 ---
> include/configs/mx7dsabresd.h | 3 ---
> include/configs/mxs.h | 1 -
> include/configs/pcm058.h| 3 ---
> include/configs/pfla02.h| 3 ---
> include/configs/platinum.h | 3 ---
> include/configs/titanium.h | 3 ---
> scripts/config_whitelist.txt| 3 ---
> 27 files changed, 27 insertions(+), 50 deletions(-)
>
> diff --git a/configs/bg0900_defconfig b/configs/bg0900_defconfig
> index 72616ae..7314eff 100644
> --- a/configs/bg0900_defconfig
> +++ b/configs/bg0900_defconfig
> @@ -25,6 +25,7 @@ CONFIG_CMD_MII=y
> CONFIG_CMD_PING=y
> CONFIG_CMD_CACHE=y
> CONFIG_DOS_PARTITION=y
> +CONFIG_APBH_DMA=y
> # CONFIG_MMC is not set
> CONFIG_SPI_FLASH=y
> CONFIG_SPI_FLASH_BAR=y
> diff --git a/configs/mx23_olinuxino_defconfig
> b/configs/mx23_olinuxino_defconfig
> index 628c11d..2c80c3b 100644
> --- a/configs/mx23_olinuxino_defconfig
> +++ b/configs/mx23_olinuxino_defconfig
> @@ -20,6 +20,7 @@ CONFIG_CMD_CACHE=y
> CONFIG_CMD_EXT2=y
> CONFIG_CMD_FAT=y
> CONFIG_ENV_IS_IN_MMC=y
> +CONFIG_APBH_DMA=y
> CONFIG_LED_STATUS=y
> CONFIG_LED_STATUS_GPIO=y
> CONFIG_LED_STATUS0=y
> diff --git a/configs/mx23evk_defconfig b/configs/mx23evk_defconfig
> index 6ad7f2c..09f3611 100644
> --- a/configs/mx23evk_defconfig
> +++ b/configs/mx23evk_defconfig
> @@ -24,6 +24,7 @@ CONFIG_CMD_CACHE=y
> CONFIG_CMD_EXT2=y
> CONFIG_CMD_FAT=y
> CONFIG_ENV_IS_IN_MMC=y
> +CONFIG_APBH_DMA=y
> CONFIG_MMC_MXS=y
> CONFIG_USB=y
> CONFIG_USB_EHCI_HCD=y
> diff --git a/configs/mx28evk_auart_console_defconfig
> b/configs/mx28evk_auart_console_defconfig
> index 0927333..7bdb905 100644
> --- a/configs/mx28evk_auart_console_defconfig
> +++ b/configs/mx28evk_auart_console_defconfig
> @@ -16,7 +16,6 @@ CONFIG_CMD_BOOTZ=y
> # CONFIG_CMD_FLASH is not set
> CONFIG_CMD_GPIO=y
> CONFIG_CMD_MMC=y
> -CONFIG_CMD_NAND_TRIMFFS=y
> CONFIG_CMD_SF=y
> CONFIG_CMD_SPI=y
> CONFIG_CMD_USB=y
> @@ -34,9 +33,9 @@ CONFIG_MTDIDS_DEFAULT="nand0=gpmi-nand"
>
> CONFIG_MTDPARTS_DEFAULT="mtdparts=gpmi-nand:3m(bootloader)ro,512k(environment),512k(redundant-environment),4m(kernel),512k(fdt),8m(ramdisk),-(filesystem)"
> CONFIG_CMD_UBI=y
> CONFIG_ENV_IS_IN_MMC=y
> +CONFIG_APBH_DMA=y
> CONFIG_MMC_MXS=y
> CONFIG_NAND=y
> -CONFIG_NAND_MXS=y
> CONFIG_SPI_FLASH=y
> CONFIG_SPI_FLASH_SST=y
> CONFIG_USB=y
> diff --git a/configs/mx28evk_defconfig b/configs/mx28evk_defconfig
> index 21d01bc..d36ad0e 100644
> --- a/configs/mx28evk_defconfig
> +++ b/configs/mx28evk_defconfig
> @@ -16,7 +16,6 @@ CONFIG_CMD_BOOTZ=y
> # CONFIG_CMD_FLASH is not set
> CONFIG_CMD_GPIO=y
> CONFIG_CMD_MMC=y
> -CONFIG_CMD_NAND_TRIMFFS=y
> CONFIG_CMD_SF=y
> CONFIG_CMD_SPI=y
> CONFIG_CMD_USB=y
> @@ -34,9 +33,9 @@ CONFIG_MTDIDS_DEFAULT="nand0=gpmi-nand"
>
> CONFIG_MTDPARTS_DEFAULT="mtdparts=gpmi-nand:3m(bootloader)ro,512k(environment),512k(redundant-environment),4m(kernel),512k(fdt),8m(ramdisk),-(filesys
Re: [U-Boot] [PATCH 1/4] arm: imx: mx23: Move MX23 selection to Kconfig
On 05.02.2018 23:05, Fabio Estevam wrote: > On Mon, Feb 5, 2018 at 7:33 PM, Stefan Agner wrote: > >> --- a/arch/arm/mach-imx/mx2/Kconfig >> +++ b/arch/arm/mach-imx/mx2/Kconfig > > mx23 and mx28 fits better into /arch/arm/mach-imx/mxs/Kconfig > >> @@ -1,3 +1,39 @@ >> +if ARCH_MX23 >> + >> +config MX23 >> + bool >> + default y >> + >> +choice >> + prompt "MX25 board select" > > Wrong SoC. This should be MX23 :-) Ok, will send v2 fixing those issues. -- Stefan ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH V3] Convert CONFIG_APBH_DMA et al to Kconfig
On 06.02.2018 15:34, Adam Ford wrote: > This converts the following to Kconfig: >CONFIG_APBH_DMA >CONFIG_APBH_DMA_BURST >CONFIG_APBH_DMA_BURST8 > > Signed-off-by: Adam Ford Thanks, that looks good to me! Reviewed-by: Stefan Agner -- Stefan > --- > V3: Rebased on "arm: imx: convert MX23/28 and MXS NAND to Kconfig" > Make APBH_DMA depend on NAND_MXS since it appears to be the only > driver using DMA. This keeps the defconfig files from changing > V2: Rebase on [U-Boot,v2,1/6] Convert CONFIG_NAND_MXS to Kconfig > Make the NAND controller in MX6 MX7 autoselect the DMA options > > drivers/dma/Kconfig | 15 +++ > drivers/mtd/nand/Kconfig | 3 +++ > include/configs/aristainetos-common.h | 3 --- > include/configs/cm_fx6.h | 3 --- > include/configs/colibri_imx7.h| 3 --- > include/configs/gw_ventana.h | 3 --- > include/configs/imx6-engicam.h| 4 > include/configs/imx6_logic.h | 3 --- > include/configs/mx6sabreauto.h| 3 --- > include/configs/mx6sxsabreauto.h | 3 --- > include/configs/mx7dsabresd.h | 3 --- > include/configs/mxs.h | 1 - > include/configs/pcm058.h | 3 --- > include/configs/pfla02.h | 3 --- > include/configs/platinum.h| 3 --- > include/configs/titanium.h| 3 --- > scripts/config_whitelist.txt | 3 --- > 17 files changed, 18 insertions(+), 44 deletions(-) > > diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig > index 1b92c77..4b96bda 100644 > --- a/drivers/dma/Kconfig > +++ b/drivers/dma/Kconfig > @@ -19,4 +19,19 @@ config TI_EDMA3 > This driver support data transfer between memory > regions. > > +config APBH_DMA > + bool "Support APBH DMA" > + depends on NAND_MXS > + help > + Enable APBH DMA driver. > + > +if APBH_DMA > +config APBH_DMA_BURST > + bool "Enable DMA BURST" > + > +config APBH_DMA_BURST8 > + bool "Enable DMA BURST8" > + > +endif > + > endmenu # menu "DMA Support" > diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig > index 57d2757..a820af6 100644 > --- a/drivers/mtd/nand/Kconfig > +++ b/drivers/mtd/nand/Kconfig > @@ -142,6 +142,9 @@ config NAND_MXS > bool "MXS NAND support" > depends on MX23 || MX28 || MX6 || MX7 > imply CMD_NAND > + select APBH_DMA > + select APBH_DMA_BURST if ARCH_MX6 || ARCH_MX7 > + select APBH_DMA_BURST8 if ARCH_MX6 || ARCH_MX7 > help > This enables NAND driver for the NAND flash controller on the > MXS processors. > diff --git a/include/configs/aristainetos-common.h > b/include/configs/aristainetos-common.h > index 9b1a39d..69de44a 100644 > --- a/include/configs/aristainetos-common.h > +++ b/include/configs/aristainetos-common.h > @@ -182,9 +182,6 @@ > #define CONFIG_SYS_NAND_ONFI_DETECTION > > /* DMA stuff, needed for GPMI/MXS NAND support */ > -#define CONFIG_APBH_DMA > -#define CONFIG_APBH_DMA_BURST > -#define CONFIG_APBH_DMA_BURST8 > > /* RTC */ > #define CONFIG_SYS_I2C_RTC_ADDR 0x68 > diff --git a/include/configs/cm_fx6.h b/include/configs/cm_fx6.h > index 90cf024..39d166a 100644 > --- a/include/configs/cm_fx6.h > +++ b/include/configs/cm_fx6.h > @@ -184,9 +184,6 @@ > #define CONFIG_SYS_MAX_NAND_DEVICE 1 > #define CONFIG_SYS_NAND_ONFI_DETECTION > /* APBH DMA is required for NAND support */ > -#define CONFIG_APBH_DMA > -#define CONFIG_APBH_DMA_BURST > -#define CONFIG_APBH_DMA_BURST8 > #endif > > /* Ethernet */ > diff --git a/include/configs/colibri_imx7.h b/include/configs/colibri_imx7.h > index d4aaff6..5d9b212 100644 > --- a/include/configs/colibri_imx7.h > +++ b/include/configs/colibri_imx7.h > @@ -170,9 +170,6 @@ > #define CONFIG_MTD_DEVICE/* needed for mtdparts commands */ > > /* DMA stuff, needed for GPMI/MXS NAND support */ > -#define CONFIG_APBH_DMA > -#define CONFIG_APBH_DMA_BURST > -#define CONFIG_APBH_DMA_BURST8 > > /* USB Configs */ > #define CONFIG_EHCI_HCD_INIT_AFTER_RESET > diff --git a/include/configs/gw_ventana.h b/include/configs/gw_ventana.h > index 517ad08..6e994b5 100644 > --- a/include/configs/gw_ventana.h > +++ b/include/configs/gw_ventana.h > @@ -73,9 +73,6 @@ >#define CONFIG_SYS_NAND_ONFI_DETECTION > >/* DMA stuff, needed for GPMI/MXS NAND support */ > - #define CONFIG_APBH_DMA > - #define CONFIG_APBH_DMA_BURST > - #define CONFIG_APBH_DMA_BURST8 > #endif > > #endif /* CONFIG_SPI_FLASH */ &g
Re: [U-Boot] [PATCH v3 1/2] i.MX6: nand: add nandbcb update command
Hi Jagan,
On 07.02.2018 17:03, Jagan Teki wrote:
> Writing/updating boot image in nand device is not
> straight forward in i.MX6 platform and it requires
> boot control block(BCB) to be configured.
>
> It becomes difficult to use uboot 'nand' command to
> write BCB since it requires platform specific attributes
> need to be taken care of.
>
> It is even difficult to use existing msx-nand.c driver by
> incorporating BCB attributes like mxs_dma_desc does
> because it requires change in mtd and nand command.
>
> So, cmd_nandbcb implemented in arch/arm/mach-imx
>
> BCB contains two data structures, Firmware Configuration Block(FCB)
> and Discovered Bad Block Table(DBBT). FCB has nand timings,
> DBBT search area, page address of primary and secondary firmware.
Thanks for working on that! We carry a similar command since a while
downstream and I hoped since quite a while to get some time to upstream
it:
http://git.toradex.com/cgit/u-boot-toradex.git/tree/arch/arm/imx-common/cmd_writebcb_mx7.c?h=2016.11-toradex
>
> On summary, nandbcb update will
> - erase the entire partition
> - create BCB by creating 4 FCB/BDDT block followed by
> 2 FW blocks based on partition size and erasesize.
> - fill FCB/DBBT structures
> - write FW/SPL in FW0 and FW1(same image in two times)
> - write FCB/DBBT in first 4 blocks
We used a simpler, more unix like design in that we only do the minimal
thing in that command. Maybe we should consider that upstream too:
writebcb takes one or optionally two firmware offsets and writes the
BCB/FCB/DTTB only. This allows to support one or two firmware images and
makes rewriting of the BCB unnecessary when updating the firmware (most
NAND chips guarantee only a few write cycles on the first NAND
block...). We then use U-Boot to write the firmware itself.
It seems that firmware size in the BCB is not strictly required.
Presumably the boot ROM uses the imx header to determine the size...
Any thoughts?
--
Stefan
>
> for nand boot, up on reset bootrom look for FCB structure in
> first block's if FCB found the nand timings are loaded for
> further reads. once FCB read done, DTTB will load and
> finally primary or secondary firmware will load which is boot image.
>
> See Section 4 from doc/README.imx6 for more usage information.
>
> Signed-off-by: Jagan Teki
> Signed-off-by: Sergey Kubushyn
> ---
> Changes for v3:
> - Fixed multi-line comments
> - Better error handling for failed allocations
> Changes for v2:
> - Fixed commit message notes
> - Updated proper commit message
> - Update doc/README.imx6 with NAND boot details
> - Fixed long length variable names.
> - Fixed Gigantic variable name.
> - NULL checks for kzalloc
> - Move Kconfig option in separate patch
> - Fixed checkpatch warninigs
>
> arch/arm/include/asm/mach-imx/imx-nandbcb.h | 111
> arch/arm/include/asm/mach-imx/mxs-nand.h| 15 ++
> arch/arm/mach-imx/Makefile | 1 +
> arch/arm/mach-imx/cmd_nandbcb.c | 379
>
> doc/README.imx6 | 77 ++
> drivers/mtd/nand/mxs_nand.c | 8 +-
> 6 files changed, 587 insertions(+), 4 deletions(-)
> create mode 100644 arch/arm/include/asm/mach-imx/imx-nandbcb.h
> create mode 100644 arch/arm/include/asm/mach-imx/mxs-nand.h
> create mode 100644 arch/arm/mach-imx/cmd_nandbcb.c
>
> diff --git a/arch/arm/include/asm/mach-imx/imx-nandbcb.h
> b/arch/arm/include/asm/mach-imx/imx-nandbcb.h
> new file mode 100644
> index 000..759b588
> --- /dev/null
> +++ b/arch/arm/include/asm/mach-imx/imx-nandbcb.h
> @@ -0,0 +1,111 @@
> +/*
> + * Copyright (C) 2017 Jagan Teki
> + *
> + * SPDX-License-Identifier: GPL-2.0+
> + */
> +
> +#ifndef _IMX_NAND_BCB_H_
> +#define _IMX_NAND_BCB_H_
> +
> +#define FCB_FINGERPRINT 0x20424346 /* 'FCB' */
> +#define FCB_VERSION_10x0100
> +
> +#define DBBT_FINGERPRINT20x54424244 /* 'DBBT' */
> +#define DBBT_VERSION_1 0x0100
> +
> +struct dbbt_block {
> + u32 checksum; /* reserved on i.MX6 */
> + u32 fingerprint;
> + u32 version;
> + u32 numberbb; /* reserved on i.MX6 */
> + u32 dbbtnumofpages;
> +};
> +
> +struct fcb_block {
> + u32 checksum; /* First fingerprint in first byte */
> + u32 fingerprint;/* 2nd fingerprint at byte 4 */
> + u32 version;/* 3rd fingerprint at byte 8 */
> + u8 datasetup;
> + u8 datahold;
> + u8 addresssetup;
> + u8 dsample_time;
> +
> + /* These are for application use only and not for ROM. */
> + u8 nandtiming;
> + u8 rea;
Re: [PATCH RFC u-boot-mvebu 20/59] cmd: mvebu/bubt: Add support for selecting eMMC HW partition
Hi Pali,
On 2/21/23 21:18, Pali Rohár wrote:
Support for burning into the correct eMMC HW boot partition was broken and
removed in commit 96be2f072768 ("mvebu: bubt: Drop dead code"). Reimplement
this functionality and bring it back again.
Fixes: 96be2f072768 ("mvebu: bubt: Drop dead code")
Signed-off-by: Pali Rohár
---
cmd/mvebu/bubt.c | 53 ++
doc/mvebu/cmd/bubt.txt | 21 -
2 files changed, 63 insertions(+), 11 deletions(-)
diff --git a/cmd/mvebu/bubt.c b/cmd/mvebu/bubt.c
index 2bcdf145f64a..4bad9a69527c 100644
--- a/cmd/mvebu/bubt.c
+++ b/cmd/mvebu/bubt.c
@@ -189,6 +189,11 @@ static int mmc_burn_image(size_t image_size)
#ifdef CONFIG_BLK
struct blk_desc *blk_desc;
#endif
+#ifdef CONFIG_SUPPORT_EMMC_BOOT
+ u8 part;
+ u8 orig_part;
+#endif
+
mmc = find_mmc_device(mmc_dev_num);
if (!mmc) {
printf("No SD/MMC/eMMC card found\n");
@@ -202,6 +207,38 @@ static int mmc_burn_image(size_t image_size)
return err;
}
+#ifdef CONFIG_BLK
+ blk_desc = mmc_get_blk_desc(mmc);
+ if (!blk_desc) {
+ printf("Error - failed to obtain block descriptor\n");
+ return -ENODEV;
+ }
+#endif
This #ifdef usage really gets out of hand IMHO. Yes I know, you did not
introduce it here. Still, perhaps some of this can be moved to using
IS_ENABLED or CONFIG_IS_ENABLED instead?
And I just checked that "bubt" is not compiled for CONFIG_BLK not
defined. So please depend this file on CONFIG_BLK in Kconfig and remove
the non CONFIG_BLK code here.
Thanks,
Stefan
+
+#ifdef CONFIG_SUPPORT_EMMC_BOOT
+#ifdef CONFIG_BLK
+ orig_part = blk_desc->hwpart;
+#else
+ orig_part = mmc->block_dev.hwpart;
+#endif
+
+ part = (mmc->part_config >> 3) & PART_ACCESS_MASK;
+
+ if (part == 7)
+ part = 0;
+
+#ifdef CONFIG_BLK
+ err = blk_dselect_hwpart(blk_desc, part);
+#else
+ err = mmc_switch_part(mmc, part);
+#endif
+
+ if (err) {
+ printf("Error - MMC partition switch failed\n");
+ return err;
+ }
+#endif
+
/* SD reserves LBA-0 for MBR and boots from LBA-1,
* MMC/eMMC boots from LBA-0
*/
@@ -211,11 +248,6 @@ static int mmc_burn_image(size_t image_size)
if (image_size % mmc->write_bl_len)
blk_count += 1;
- blk_desc = mmc_get_blk_desc(mmc);
- if (!blk_desc) {
- printf("Error - failed to obtain block descriptor\n");
- return -ENODEV;
- }
blk_written = blk_dwrite(blk_desc, start_lba, blk_count,
(void *)get_load_addr());
#else
@@ -227,6 +259,17 @@ static int mmc_burn_image(size_t image_size)
start_lba, blk_count,
(void *)get_load_addr());
#endif /* CONFIG_BLK */
+
+#ifdef CONFIG_SUPPORT_EMMC_BOOT
+#ifdef CONFIG_BLK
+ err = blk_dselect_hwpart(blk_desc, orig_part);
+#else
+ err = mmc_switch_part(mmc, orig_part);
+#endif
+ if (err)
+ printf("Error - MMC failed to switch back to original
partition\n");
+#endif
+
if (blk_written != blk_count) {
printf("Error - written %#lx blocks\n", blk_written);
return -ENOSPC;
diff --git a/doc/mvebu/cmd/bubt.txt b/doc/mvebu/cmd/bubt.txt
index 6051243f1165..1fe1f07dd187 100644
--- a/doc/mvebu/cmd/bubt.txt
+++ b/doc/mvebu/cmd/bubt.txt
@@ -14,8 +14,7 @@ Examples:
Notes:
- For the TFTP interface set serverip and ipaddr.
-- To burn image to SD/eMMC device, the target is defined
- by parameters CONFIG_SYS_MMC_ENV_DEV and CONFIG_SYS_MMC_ENV_PART.
+- To burn image to SD/eMMC device, the target is defined by HW partition.
Bubt command details (burn image step by-step)
--
@@ -40,10 +39,20 @@ Notes:
Number 0 is used for user data partition and should not be utilized for
storing
boot images and U-Boot environment in RAW mode since it will break file
system
structures usually located here.
- The default boot partition is BOOT0. It is selected by the following
parameter:
- CONFIG_SYS_MMC_ENV_PART=1
- Valid values for this parameter are 1 for BOOT0 and 2 for BOOT1.
- Please never use partition number 0 here!
+
+ Currently configured boot partition can be printed by command:
+ # mmc partconf 0
+ (search for BOOT_PARTITION_ACCESS output, number 7 is user data)
+
+ Change it to BOOT0:
+ # mmc partconf 0 0 1 1
+
+ Change it to BOOT1:
+ # mmc partconf 0 0 2 2
+
+ Change it to user data:
+ # mmc partconf 0 0 7 0
+
- The partition number is ignored if the target device is SD card.
- The boot image offset starts at block 0 for eMM
Re: [PATCH RFC u-boot-mvebu 20/59] cmd: mvebu/bubt: Add support for selecting eMMC HW partition
Hi Pali,
On 2/22/23 19:06, Pali Rohár wrote:
On Wednesday 22 February 2023 10:55:54 Stefan Roese wrote:
Hi Pali,
On 2/21/23 21:18, Pali Rohár wrote:
Support for burning into the correct eMMC HW boot partition was broken and
removed in commit 96be2f072768 ("mvebu: bubt: Drop dead code"). Reimplement
this functionality and bring it back again.
Fixes: 96be2f072768 ("mvebu: bubt: Drop dead code")
Signed-off-by: Pali Rohár
---
cmd/mvebu/bubt.c | 53 ++
doc/mvebu/cmd/bubt.txt | 21 -
2 files changed, 63 insertions(+), 11 deletions(-)
diff --git a/cmd/mvebu/bubt.c b/cmd/mvebu/bubt.c
index 2bcdf145f64a..4bad9a69527c 100644
--- a/cmd/mvebu/bubt.c
+++ b/cmd/mvebu/bubt.c
@@ -189,6 +189,11 @@ static int mmc_burn_image(size_t image_size)
#ifdef CONFIG_BLK
struct blk_desc *blk_desc;
#endif
+#ifdef CONFIG_SUPPORT_EMMC_BOOT
+ u8 part;
+ u8 orig_part;
+#endif
+
mmc = find_mmc_device(mmc_dev_num);
if (!mmc) {
printf("No SD/MMC/eMMC card found\n");
@@ -202,6 +207,38 @@ static int mmc_burn_image(size_t image_size)
return err;
}
+#ifdef CONFIG_BLK
+ blk_desc = mmc_get_blk_desc(mmc);
+ if (!blk_desc) {
+ printf("Error - failed to obtain block descriptor\n");
+ return -ENODEV;
+ }
+#endif
This #ifdef usage really gets out of hand IMHO. Yes I know, you did not
introduce it here. Still, perhaps some of this can be moved to using
IS_ENABLED or CONFIG_IS_ENABLED instead?
And I just checked that "bubt" is not compiled for CONFIG_BLK not
defined. So please depend this file on CONFIG_BLK in Kconfig and remove
the non CONFIG_BLK code here.
bubt is used for at least 4 different mvebu platforms (AXP, A38x, A3720,
A7K) and every one has slightly different code and configuration.
I really do not know if all those configurations support CONFIG_BLK, so
I decided to let it as it was before to eliminate possible issues.
As mentioned above, I've checked this myself before sending the
suggestion yesterday. No platform compiling this cmd has CONFIG_BLK
disabled.
My understanding is that CONFIG_BLK will be required at some time and
all non CONFIG_BLK code will get dropped.
Still, if you feel you don't want to make this change, as it's not
really related to your current patchset, then this is no showstopper.
Thanks,
Stefan
Thanks,
Stefan
+
+#ifdef CONFIG_SUPPORT_EMMC_BOOT
+#ifdef CONFIG_BLK
+ orig_part = blk_desc->hwpart;
+#else
+ orig_part = mmc->block_dev.hwpart;
+#endif
+
+ part = (mmc->part_config >> 3) & PART_ACCESS_MASK;
+
+ if (part == 7)
+ part = 0;
+
+#ifdef CONFIG_BLK
+ err = blk_dselect_hwpart(blk_desc, part);
+#else
+ err = mmc_switch_part(mmc, part);
+#endif
+
+ if (err) {
+ printf("Error - MMC partition switch failed\n");
+ return err;
+ }
+#endif
+
/* SD reserves LBA-0 for MBR and boots from LBA-1,
* MMC/eMMC boots from LBA-0
*/
@@ -211,11 +248,6 @@ static int mmc_burn_image(size_t image_size)
if (image_size % mmc->write_bl_len)
blk_count += 1;
- blk_desc = mmc_get_blk_desc(mmc);
- if (!blk_desc) {
- printf("Error - failed to obtain block descriptor\n");
- return -ENODEV;
- }
blk_written = blk_dwrite(blk_desc, start_lba, blk_count,
(void *)get_load_addr());
#else
@@ -227,6 +259,17 @@ static int mmc_burn_image(size_t image_size)
start_lba, blk_count,
(void *)get_load_addr());
#endif /* CONFIG_BLK */
+
+#ifdef CONFIG_SUPPORT_EMMC_BOOT
+#ifdef CONFIG_BLK
+ err = blk_dselect_hwpart(blk_desc, orig_part);
+#else
+ err = mmc_switch_part(mmc, orig_part);
+#endif
+ if (err)
+ printf("Error - MMC failed to switch back to original
partition\n");
+#endif
+
if (blk_written != blk_count) {
printf("Error - written %#lx blocks\n", blk_written);
return -ENOSPC;
diff --git a/doc/mvebu/cmd/bubt.txt b/doc/mvebu/cmd/bubt.txt
index 6051243f1165..1fe1f07dd187 100644
--- a/doc/mvebu/cmd/bubt.txt
+++ b/doc/mvebu/cmd/bubt.txt
@@ -14,8 +14,7 @@ Examples:
Notes:
- For the TFTP interface set serverip and ipaddr.
-- To burn image to SD/eMMC device, the target is defined
- by parameters CONFIG_SYS_MMC_ENV_DEV and CONFIG_SYS_MMC_ENV_PART.
+- To burn image to SD/eMMC device, the target is defined by HW partition.
Bubt command details (burn image step by-step)
--
@@ -40,10 +39,20 @@ Notes:
Number 0 is used for user data partition and should no
Re: [PATCH v3 65/95] omap: Correct an SPL build error with watchdog
Hi Simon & Tom, On 2/22/23 20:16, Simon Glass wrote: Hi Tom, On Tue, 14 Feb 2023 at 09:43, Tom Rini wrote: On Tue, Feb 14, 2023 at 11:34:47AM -0500, Tom Rini wrote: On Sun, Feb 12, 2023 at 04:16:08PM -0700, Simon Glass wrote: The logic here is strange since the call to hw_watchdog_init() depends on CONFIG_HW_WATCHDOG || CONFIG_WATCHDOG but the code it calls is only enabled if !CONFIG_IS_ENABLED(WDT). This seems to work, but with split config we get a build error in SPL with CONFIG_WATCHDOG, since it is interpreted as CONFIG_SPL_WATCHDOG. To mimic the behaviour before split config takes effect, use the PPL_WATCHDOG symbol. Signed-off-by: Simon Glass --- (no changes since v1) arch/arm/mach-omap2/boot-common.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/mach-omap2/boot-common.c b/arch/arm/mach-omap2/boot-common.c index 9a342a1bf95..401d12c6ca3 100644 --- a/arch/arm/mach-omap2/boot-common.c +++ b/arch/arm/mach-omap2/boot-common.c @@ -302,7 +302,7 @@ void spl_board_init(void) #if defined(CONFIG_AM33XX) && defined(CONFIG_SPL_MUSB_NEW) arch_misc_init(); #endif -#if defined(CONFIG_HW_WATCHDOG) || defined(CONFIG_WATCHDOG) +#if defined(CONFIG_HW_WATCHDOG) || defined(CONFIG_PPL_WATCHDOG) hw_watchdog_init(); #endif #ifdef CONFIG_AM33XX No, we want watchdog enabled in SPL. Or perhaps, the same question as in the socfpga patch also applies here. Yes and with a similar answer. By using PPL_WATCHDOG we ensure that the code is enabled in SPL as well as PPL. I am not sure what the plan is for getting rid of the old watchdog stuff. +Stefan Roese for that Frankly, I don't know what PPL_WATCHDOG is. Searching the current code base shows nothing. As to the plans of getting rid of the old watchdog stuff (HW_WATCHDOG): My understanding is that this can't easily be removed. HW_WATCHDOG mostly addresses platforms which use (need to use) a very early watchdog driver. This can't be solved (easily) with the normal WDT UCLASS driver. This problem is similar to the early timer functionality AFAIU. Perhaps it makes sense to at least rename all this HW_WATCHDOG stuff to some "early" names instead. I'm not 100% sure here though. Ideas and comments are welcome. Thanks, Stefan
Re: [PATCH RFC u-boot-mvebu 20/59] cmd: mvebu/bubt: Add support for selecting eMMC HW partition
Hi Pali, On 2/23/23 08:55, Pali Rohár wrote: This #ifdef usage really gets out of hand IMHO. Yes I know, you did not introduce it here. Still, perhaps some of this can be moved to using IS_ENABLED or CONFIG_IS_ENABLED instead? And I just checked that "bubt" is not compiled for CONFIG_BLK not defined. So please depend this file on CONFIG_BLK in Kconfig and remove the non CONFIG_BLK code here. bubt is used for at least 4 different mvebu platforms (AXP, A38x, A3720, A7K) and every one has slightly different code and configuration. I really do not know if all those configurations support CONFIG_BLK, so I decided to let it as it was before to eliminate possible issues. As mentioned above, I've checked this myself before sending the suggestion yesterday. No platform compiling this cmd has CONFIG_BLK disabled. OK! In this case I would rather send an additional cleanup patch which removes usage of non-CONFIG_BLK code from the whole command. As it does not make sense to not-have it in MMC and have it in SATA. Handling this via a follow-up patch is even better. Thanks for working on this. Thanks, Stefan
Re: [PATCH RFC u-boot-mvebu 00/59] arm: mvebu: Various fixes
Hi Martin, On 2/24/23 16:07, Martin Rowe wrote: [PATCH 1/2] arm: mvebu: clearfog: Fix MMC detection A388 Clearfog MMC is either SD Card or eMMC with different behaviour for both. Setting MMC_BROKEN_CD allows both to correctly detect MMC. Signed-off-by: Martin Rowe Please note that this patch is sent to the list a s reply to the RFC patchset from Pali. Something went wrong here, so that the commit subject was not used. Also for the 2nd patch. Another comment below. --- configs/clearfog_defconfig | 3 +-- configs/clearfog_sata_defconfig | 8 2 files changed, 5 insertions(+), 6 deletions(-) diff --git a/configs/clearfog_defconfig b/configs/clearfog_defconfig index 8cd35f9f1a..24e7c16ac7 100644 --- a/configs/clearfog_defconfig +++ b/configs/clearfog_defconfig @@ -46,7 +46,6 @@ CONFIG_CMD_USB=y CONFIG_CMD_TFTPPUT=y CONFIG_CMD_CACHE=y CONFIG_CMD_TIME=y -CONFIG_CMD_MVEBU_BUBT=y You are removing the bubt cmd here. This is most likely a mistake. So please re-send the patches with a correct subject and also without removing the bubt cmd support. Thanks, Stefan CONFIG_ENV_OVERWRITE=y CONFIG_ENV_MIN_ENTRIES=128 CONFIG_ARP_TIMEOUT=200 @@ -59,7 +58,7 @@ CONFIG_DM_I2C=y CONFIG_SYS_I2C_MVTWSI=y CONFIG_I2C_EEPROM=y CONFIG_SPL_I2C_EEPROM=y -CONFIG_SUPPORT_EMMC_BOOT=y +CONFIG_MMC_BROKEN_CD=y CONFIG_MMC_SDHCI=y CONFIG_MMC_SDHCI_SDMA=y CONFIG_MMC_SDHCI_MV=y diff --git a/configs/clearfog_sata_defconfig b/configs/clearfog_sata_defconfig index e9b36150ea..84f900bf50 100644 --- a/configs/clearfog_sata_defconfig +++ b/configs/clearfog_sata_defconfig @@ -6,11 +6,14 @@ CONFIG_TEXT_BASE=0x0080 CONFIG_SPL_LIBCOMMON_SUPPORT=y CONFIG_SPL_LIBGENERIC_SUPPORT=y CONFIG_NR_DRAM_BANKS=2 +CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y +CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0xff CONFIG_TARGET_CLEARFOG=y CONFIG_MVEBU_SPL_BOOT_DEVICE_SATA=y CONFIG_DEFAULT_DEVICE_TREE="armada-388-clearfog" CONFIG_SPL_TEXT_BASE=0x4030 CONFIG_SPL_SERIAL=y +CONFIG_SPL_STACK=0x4002c000 CONFIG_SPL=y CONFIG_DEBUG_UART_BASE=0xf1012000 CONFIG_DEBUG_UART_CLOCK=25000 @@ -18,8 +21,6 @@ CONFIG_SYS_LOAD_ADDR=0x80 CONFIG_DEBUG_UART=y CONFIG_AHCI=y CONFIG_DISTRO_DEFAULTS=y -CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y -CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0xff CONFIG_BOOTDELAY=3 CONFIG_USE_PREBOOT=y CONFIG_SYS_CONSOLE_INFO_QUIET=y @@ -31,7 +32,6 @@ CONFIG_SPL_BSS_START_ADDR=0x40023000 CONFIG_SPL_BSS_MAX_SIZE=0x4000 CONFIG_SPL_SYS_MALLOC_SIMPLE=y # CONFIG_SPL_SHARES_INIT_SP_ADDR is not set -CONFIG_SPL_STACK=0x4002c000 CONFIG_SPL_I2C=y CONFIG_SYS_MAXARGS=32 CONFIG_CMD_TLV_EEPROM=y @@ -46,7 +46,6 @@ CONFIG_CMD_USB=y CONFIG_CMD_TFTPPUT=y CONFIG_CMD_CACHE=y CONFIG_CMD_TIME=y -CONFIG_CMD_MVEBU_BUBT=y CONFIG_ENV_OVERWRITE=y CONFIG_ENV_MIN_ENTRIES=128 CONFIG_ARP_TIMEOUT=200 @@ -59,6 +58,7 @@ CONFIG_DM_I2C=y CONFIG_SYS_I2C_MVTWSI=y CONFIG_I2C_EEPROM=y CONFIG_SPL_I2C_EEPROM=y +CONFIG_MMC_BROKEN_CD=y CONFIG_SUPPORT_EMMC_BOOT=y CONFIG_MMC_SDHCI=y CONFIG_MMC_SDHCI_SDMA=y Viele Grüße, Stefan Roese -- DENX Software Engineering GmbH, Managing Director: Erika Unter HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de
Re: [PATCH 2/2] arm: mvebu: clearfog: Add defconfig for SPI booting
Hi Tony, On 2/27/23 01:11, Tony Dinh wrote: Hi Pali, On Sun, Feb 26, 2023 at 2:52 AM Pali Rohár wrote: On Saturday 25 February 2023 20:56:10 Tony Dinh wrote: Hi Martin, On Sat, Feb 25, 2023 at 6:17 PM Martin Rowe wrote: I'm not sure how to run proper timing tests on the process, but stopwatch timing just between seeing "Trying to boot" and "U-Boot 2023.04-rc2" showed the return to BootROM under 1 second, and the direct from SPI around 4 seconds. I thought the goal of loading from SPI directly was speed, but returning to BootROM is significantly faster on this board. You should check SPI speed in DTS file and also in the defconfig. I think we have probably seen this slowdown before. There is a TODO in the way the DTS nodes are parsed by DM uclass. So this config must be set in defconfig to get around that bug: CONFIG_SF_DEFAULT_SPEED=5000 That works and is much faster now. I'll submit it in a V2 for these two patches once Pali's mvebu changes are accepted. Only question I have is: should the faster speed be applied to all three defconfigs? CONFIG_SF_DEFAULT_SPEED=100 (50x less) is implicitly added to the MMC and SATA configs at the moment. This is only a workaround to get the SPI probe to work correctly. The real fix should be in spi_flash_probe() ./common/spl/spl_spi.c flash = spi_flash_probe(sf_bus, sf_cs, CONFIG_SF_DEFAULT_SPEED, CONFIG_SF_DEFAULT_MODE); If spi_flash_probe() failed to get SPI max_hz from the DTS, the fallback is CONFIG_SF_DEFAULT_SPEED. IMO, perhaps we could add CONFIG_SF_DEFAULT_SPEED and CONFIG_SF_DEFAULT_MODE selection to arch/arm/mach-mvebu/Kconfig or some other common place. And when we will have fixed the DTS parsing problem, they can be removed. I'd like to hear from Stefan and Pali if this approach sounds good. All the best, Tony Well, the maximal SPI speed depends on the wiring. You can have on the board some SPI device which does not support high frequency. But having some sane defaults in Kconfig for mvebu makes sense. Agreed. The CONFIG_SF_DEFAULT_SPEED is set to 1_000_000 if the board defconfig does not specify it. I think the sane default value is 10_000_000 (grepping the Armada* DTS files showing the slowest spi-max-frequency is 10_000_000). While a big improvement, it is not fast enough for many other boards. So we still need to define it in those board defconfigs (before fixing that bug), or use return to BootROM. I'm fine with setting CONFIG_SF_DEFAULT_SPEED to 10.000.000 for MVEBU. Not sure if this should be done in drivers/mtd/spi/Kconfig, as this currently has no platform- / board- specific configurations. Perhaps it can be done in a mach-mvebu Kconfig file instead? Thanks, Stefan
Re: [PATCH RFC u-boot-mvebu 00/59] arm: mvebu: Various fixes
Hi Pali, On 2/25/23 23:00, Pali Rohár wrote: On Tuesday 21 February 2023 21:18:26 Pali Rohár 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 Patches were tested on more boards and seems there is no reported issue, but other improvements. So do you need something to modify in this relatively big patch series? If it is not really needed I would like to not send it again because denx servers are not able to handle it. And it take me lot of time to send patches over emails to denx servers. I'm fine with applying the series as-is. I'm a bit hesitant though, if it should be applied to master or to next. As Tom clearly noticed, that only fixes should be added after rc2 this time. What is your thinking on this? Thanks, Stefan Pali Rohár (59): tools: kwbimage: Fix generating, verifying and extracting SDIO kwbimage tools: kwboot: Fix parsing SDIO kwbimage arm: mvebu: spl: Fix parsing SDIO kwbimage cmd: mvebu/bubt: Fix parsing SDIO kwbimage tools: kwbimage: Fix generating, verifying and extracting SATA kwbimage tools: kwboot: Fix parsing SATA kwbimage arm: mvebu: spl: Fix parsing SATA kwbimage cmd: mvebu/bubt: Fix parsing SATA kwbimage arm: mvebu: spl: Remove checks for BOOT_DEVICE_MMC2 and BOOT_DEVICE_MMC2_2 arm: mvebu: spl: Load proper U-Boot from selected eMMC boot partition spl: mmc: Allow to disable SYS_MMCSD_FS_BOOT_PARTITION arm: mvebu: spl: Fix support for loading U-Boot proper from SD card tools: kwboot: Add more documentation references tools: kwboot: Add image type documentation tools: kwboot: Fix parsing UART image without data checksum tools: kwboot: Validate optional kwbimage v1 headers tools: kwboot: Add check that kwbimage contains DDR init code tools: kwboot: Fix patching of SPI/NOR XIP images tools: kwboot: Show image type and error parsing reasons cmd: mvebu/bubt: Add support for selecting eMMC HW partition cmd: mvebu/bubt: Add support for writing image to SATA disk cmd: mvebu/bubt: Add support for reading image from the SATA disk partition cmd: mvebu/bubt: Rename variable image_size to hdr_size cmd: mvebu/bubt: Mark all local symbols as static cmd: mvebu/bubt: Do not modify image in A8K check_image_header() cmd: mvebu/bubt: Check also A8K boot image checksum cmd: mvebu/bubt: Set correct default image name for 32-bit Armada SoCs cmd: mvebu/bubt: Better guess default MVEBU_*_BOOT option cmd: mvebu/bubt: Fix warnings: unused variable 'secure_mode' and 'fuse_read_u64' defined but not used cmd: mvebu/bubt: Enable command by default tools: kwbimage: Fix dumping register set / DATA commands tools: kwbimage: Fix endianity when dumping NAND_PAGE_SIZE tools: kwbimage: Fix dumping NAND_BADBLK_LOCATION tools: kwbimage: Fix dumping NAND_BLKSZ tools: kwbimage: Fix generating of kwbimage v0 header checksum tools: kwbimage: Fix endianity when printing kwbimage header tools: kwbimage: Reject mkimage -F option tools: kwbimage: Add support for dumping NAND_BLKSZ for v0 images tools: kwbimage: Print binary image offset as size tools: kwbimage: Print image data offset when printing kwbimage header tools: kwbimage: Simplify add_secure_header_v1() tools: kwbimage: Rename imagesz to dataoff tools: kwbimage: Fix generating secure boot data image signature tools: kwbimage: Fix invalid secure boot header signature tools: mkimage: Do not fill legacy_img_hdr for non-legacy XIP images tools: kwbimage: Add support for XIP SPI/NOR images tools: mkimage: Print human readable error when -d is not specified tools: mkimage: Do not try to open datafile when it is skipped tools: kwbimage: Add support for creating an image with no data arm: mvebu: Add support for generating NAND kwbimage arm: mvebu: Add support for generating PEX kwbimage arm: mvebu: Fix description of MVEBU_SPL_BOOT_DEVICE_(SPI|MMC) options arm: mvebu: db-88f6820-amc: Add defconfig for NAND booting arm: mvebu: clearfog: Add defconfig for SATA booting arm: mvebu: Remove A39x relicts arm: mvebu: Fix comment about CPU_ATTR_BOOTROM mapping arm: mvebu: Define env_sf_get_env_addr() also for Proper U-Boot arm: mvebu: Define SPL memory maps doc/kwboot.1: Update example description arch/arm/mach-mvebu/Kconfig | 23 +- arch/arm/mach-mvebu/Makefile | 13 + arch/arm/mach-mvebu/cpu.c | 11 +-
Re: [PATCH RFC u-boot-mvebu 00/59] arm: mvebu: Various fixes
Hi Martin, Hi Pali, On 2/27/23 12:29, Martin Rowe wrote: On Mon, 27 Feb 2023 at 08:04, Pali Rohár <mailto:p...@kernel.org>> wrote: On Monday 27 February 2023 08:44:30 Stefan Roese wrote: > Hi Pali, > > On 2/25/23 23:00, Pali Rohár wrote: > > On Tuesday 21 February 2023 21:18:26 Pali Rohár 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 <https://github.com/u-boot/u-boot/pull/275> > > > > Patches were tested on more boards and seems there is no reported issue, > > but other improvements. > > > > So do you need something to modify in this relatively big patch series? > > If it is not really needed I would like to not send it again because > > denx servers are not able to handle it. And it take me lot of time to > > send patches over emails to denx servers. > > I'm fine with applying the series as-is. I'm a bit hesitant though, if > it should be applied to master or to next. As Tom clearly noticed, that > only fixes should be added after rc2 this time. > > What is your thinking on this? Well, I do not know. AFAIK more patches here are fixing broken mvebu boards (e.g. eMMC or SATA parts). Maybe Martin or Josua could comment? A388 Clearfog was definitely broken prior to this patchset. There is quite a bit of churn that this has caused for some OpenWRT users [1] as well as for me. It would be nice to have a stable build for these boards. [1] https://github.com/openwrt/openwrt/issues/11661 <https://github.com/openwrt/openwrt/issues/11661> Okay. Thanks for the explanation. So it makes sense to pull this patchset at this stage IMHO. BUT: While trying to apply the patches sent to me directly this fails at this patch: tools: kwbimage: Add support for XIP SPI/NOR images I tried to fix this merge problem manually, but this looks a bit bogus. That's why I followed your instruction to pull the patches directly from github: git fetch https://github.com/u-boot/u-boot.git refs/pull/275/merge:mvebu This works and all patches apply clean. But looking into the patches I noticed, that these patches from github do not include all patches sent to the list. refs/pull/275/merge:mvebu stops after tools: mkimage: Do not fill legacy_img_hdr for non-legacy XIP images This is the patch directly before the failing patch mentioned above. Pali, could you please explain what went wrong here? Maybe I'm missing something? Thanks, Stefan > Thanks, > Stefan > > > > > > > > > Pali Rohár (59): > > > tools: kwbimage: Fix generating, verifying and extracting SDIO > > > kwbimage > > > tools: kwboot: Fix parsing SDIO kwbimage > > > arm: mvebu: spl: Fix parsing SDIO kwbimage > > > cmd: mvebu/bubt: Fix parsing SDIO kwbimage > > > tools: kwbimage: Fix generating, verifying and extracting SATA > > > kwbimage > > > tools: kwboot: Fix parsing SATA kwbimage > > > arm: mvebu: spl: Fix parsing SATA kwbimage > > > cmd: mvebu/bubt: Fix parsing SATA kwbimage > > > arm: mvebu: spl: Remove checks for BOOT_DEVICE_MMC2 and > > > BOOT_DEVICE_MMC2_2 > > > arm: mvebu: spl: Load proper U-Boot from selected eMMC boot partition > > > spl: mmc: Allow to disable SYS_MMCSD_FS_BOOT_PARTITION > > > arm: mvebu: spl: Fix support for loading U-Boot proper from SD card > > > tools: kwboot: Add more documentation references > > > tools: kwboot: Add image type documentation > > > tools: kwboot: Fix parsing UART image without data checksum > > > tools: kwboot: Validate optional kwbimage v1 headers > > > tools: kwboot: Add check that kwbimage contains DDR init code > > > tools: kwboot: Fix patching of SPI/NOR XIP images > > > tools: kwboot: Show image type and error parsing reasons > > >
Re: [PATCH RFC u-boot-mvebu 00/59] arm: mvebu: Various fixes
Hi Pali, On 2/28/23 08:03, Stefan Roese wrote: Hi Martin, Hi Pali, On 2/27/23 12:29, Martin Rowe wrote: On Mon, 27 Feb 2023 at 08:04, Pali Rohár <mailto:p...@kernel.org>> wrote: On Monday 27 February 2023 08:44:30 Stefan Roese wrote: > Hi Pali, > > On 2/25/23 23:00, Pali Rohár wrote: > > On Tuesday 21 February 2023 21:18:26 Pali Rohár 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 <https://github.com/u-boot/u-boot/pull/275> > > > > Patches were tested on more boards and seems there is no reported issue, > > but other improvements. > > > > So do you need something to modify in this relatively big patch series? > > If it is not really needed I would like to not send it again because > > denx servers are not able to handle it. And it take me lot of time to > > send patches over emails to denx servers. > > I'm fine with applying the series as-is. I'm a bit hesitant though, if > it should be applied to master or to next. As Tom clearly noticed, that > only fixes should be added after rc2 this time. > > What is your thinking on this? Well, I do not know. AFAIK more patches here are fixing broken mvebu boards (e.g. eMMC or SATA parts). Maybe Martin or Josua could comment? A388 Clearfog was definitely broken prior to this patchset. There is quite a bit of churn that this has caused for some OpenWRT users [1] as well as for me. It would be nice to have a stable build for these boards. [1] https://github.com/openwrt/openwrt/issues/11661 <https://github.com/openwrt/openwrt/issues/11661> Okay. Thanks for the explanation. So it makes sense to pull this patchset at this stage IMHO. Short update: I've just now seen that rc3 has been released. And Tom explicitly mentioned, that bigger pull requests are "not very welcome" any more from now on. I'll push this patchset to "next" now instead, once the problems mentioned below are resolved. Thanks, Stefan BUT: While trying to apply the patches sent to me directly this fails at this patch: tools: kwbimage: Add support for XIP SPI/NOR images I tried to fix this merge problem manually, but this looks a bit bogus. That's why I followed your instruction to pull the patches directly from github: git fetch https://github.com/u-boot/u-boot.git refs/pull/275/merge:mvebu This works and all patches apply clean. But looking into the patches I noticed, that these patches from github do not include all patches sent to the list. refs/pull/275/merge:mvebu stops after tools: mkimage: Do not fill legacy_img_hdr for non-legacy XIP images This is the patch directly before the failing patch mentioned above. Pali, could you please explain what went wrong here? Maybe I'm missing something? Thanks, Stefan > Thanks, > Stefan > > > > > > > > > Pali Rohár (59): > > > tools: kwbimage: Fix generating, verifying and extracting SDIO > > > kwbimage > > > tools: kwboot: Fix parsing SDIO kwbimage > > > arm: mvebu: spl: Fix parsing SDIO kwbimage > > > cmd: mvebu/bubt: Fix parsing SDIO kwbimage > > > tools: kwbimage: Fix generating, verifying and extracting SATA > > > kwbimage > > > tools: kwboot: Fix parsing SATA kwbimage > > > arm: mvebu: spl: Fix parsing SATA kwbimage > > > cmd: mvebu/bubt: Fix parsing SATA kwbimage > > > arm: mvebu: spl: Remove checks for BOOT_DEVICE_MMC2 and > > > BOOT_DEVICE_MMC2_2 > > > arm: mvebu: spl: Load proper U-Boot from selected eMMC boot partition > > > spl: mmc: Allow to disable SYS_MMCSD_FS_BOOT_PARTITION > > > arm: mvebu: spl: Fix support for loading U-Boot proper from SD card > > > tools: kwboot: Add more documentation references > > > tools: kwboot: Add image type documentation > > > tools: kwboot: Fix parsing UART
Re: [PATCH RFC u-boot-mvebu 00/59] arm: mvebu: Various fixes
Hi Pali, On 2/28/23 10:54, Pali Rohár wrote: On Tuesday 28 February 2023 08:03:47 Stefan Roese wrote: Hi Martin, Hi Pali, On 2/27/23 12:29, Martin Rowe wrote: On Mon, 27 Feb 2023 at 08:04, Pali Rohár mailto:p...@kernel.org>> wrote: On Monday 27 February 2023 08:44:30 Stefan Roese wrote: > Hi Pali, > > On 2/25/23 23:00, Pali Rohár wrote: > > On Tuesday 21 February 2023 21:18:26 Pali Rohár 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 <https://github.com/u-boot/u-boot/pull/275> > > > > Patches were tested on more boards and seems there is no reported issue, > > but other improvements. > > > > So do you need something to modify in this relatively big patch series? > > If it is not really needed I would like to not send it again because > > denx servers are not able to handle it. And it take me lot of time to > > send patches over emails to denx servers. > > I'm fine with applying the series as-is. I'm a bit hesitant though, if > it should be applied to master or to next. As Tom clearly noticed, that > only fixes should be added after rc2 this time. > > What is your thinking on this? Well, I do not know. AFAIK more patches here are fixing broken mvebu boards (e.g. eMMC or SATA parts). Maybe Martin or Josua could comment? A388 Clearfog was definitely broken prior to this patchset. There is quite a bit of churn that this has caused for some OpenWRT users [1] as well as for me. It would be nice to have a stable build for these boards. [1] https://github.com/openwrt/openwrt/issues/11661 <https://github.com/openwrt/openwrt/issues/11661> Okay. Thanks for the explanation. So it makes sense to pull this patchset at this stage IMHO. BUT: While trying to apply the patches sent to me directly this fails at this patch: tools: kwbimage: Add support for XIP SPI/NOR images I tried to fix this merge problem manually, but this looks a bit bogus. That's why I followed your instruction to pull the patches directly from github: git fetch https://github.com/u-boot/u-boot.git refs/pull/275/merge:mvebu This works and all patches apply clean. But looking into the patches I noticed, that these patches from github do not include all patches sent to the list. refs/pull/275/merge:mvebu stops after tools: mkimage: Do not fill legacy_img_hdr for non-legacy XIP images This is the patch directly before the failing patch mentioned above. Pali, could you please explain what went wrong here? Maybe I'm missing something? Yes, denx mail server is broken and randomly crashes when receiving / processing email. It just bounce back with server stacktrace or what. I tried to resend patches to ML which did not appeared on patchwork. But I cannot do more. So you can try to download patches from patchwork or from github. Okay, I understood the issues with the DENX mail server. Sorry about this. But: Please re-read my lines above. The patches on github are less than the patches sent to the list. There are *more* patches sent to the list (or to me directly) than in your github branch. So my question is, why are less patches in your github branch? Or did you try to re-send with this smaller amount of patches and this did not work because of the crashing mail server? Thanks, Stefan Thanks, Stefan > Thanks, > Stefan > > > > > > > > > Pali Rohár (59): > > > tools: kwbimage: Fix generating, verifying and extracting SDIO > > > kwbimage > > > tools: kwboot: Fix parsing SDIO kwbimage > > > arm: mvebu: spl: Fix parsing SDIO kwbimage > > > cmd: mvebu/bubt: Fix parsing SDIO kwbimage > > > tools: kwbimage: Fix generating, verifying and extracting SATA > > > kwbimage > > > tools: kwboot: Fix parsing SATA kwbimage > > > arm: mvebu: spl: Fix parsing SATA kwbimage > > > cmd: mvebu/bubt: Fix parsing SATA kwbimage > > >
Re: [PATCH RFC u-boot-mvebu 00/59] arm: mvebu: Various fixes
Hi Pali, On 2/28/23 11:10, Pali Rohár wrote: On Tuesday 28 February 2023 11:01:55 Stefan Roese wrote: Hi Pali, On 2/28/23 10:54, Pali Rohár wrote: On Tuesday 28 February 2023 08:03:47 Stefan Roese wrote: Hi Martin, Hi Pali, On 2/27/23 12:29, Martin Rowe wrote: On Mon, 27 Feb 2023 at 08:04, Pali Rohár mailto:p...@kernel.org>> wrote: On Monday 27 February 2023 08:44:30 Stefan Roese wrote: > Hi Pali, > > On 2/25/23 23:00, Pali Rohár wrote: > > On Tuesday 21 February 2023 21:18:26 Pali Rohár 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 <https://github.com/u-boot/u-boot/pull/275> > > > > Patches were tested on more boards and seems there is no reported issue, > > but other improvements. > > > > So do you need something to modify in this relatively big patch series? > > If it is not really needed I would like to not send it again because > > denx servers are not able to handle it. And it take me lot of time to > > send patches over emails to denx servers. > > I'm fine with applying the series as-is. I'm a bit hesitant though, if > it should be applied to master or to next. As Tom clearly noticed, that > only fixes should be added after rc2 this time. > > What is your thinking on this? Well, I do not know. AFAIK more patches here are fixing broken mvebu boards (e.g. eMMC or SATA parts). Maybe Martin or Josua could comment? A388 Clearfog was definitely broken prior to this patchset. There is quite a bit of churn that this has caused for some OpenWRT users [1] as well as for me. It would be nice to have a stable build for these boards. [1] https://github.com/openwrt/openwrt/issues/11661 <https://github.com/openwrt/openwrt/issues/11661> Okay. Thanks for the explanation. So it makes sense to pull this patchset at this stage IMHO. BUT: While trying to apply the patches sent to me directly this fails at this patch: tools: kwbimage: Add support for XIP SPI/NOR images I tried to fix this merge problem manually, but this looks a bit bogus. That's why I followed your instruction to pull the patches directly from github: git fetch https://github.com/u-boot/u-boot.git refs/pull/275/merge:mvebu This works and all patches apply clean. But looking into the patches I noticed, that these patches from github do not include all patches sent to the list. refs/pull/275/merge:mvebu stops after tools: mkimage: Do not fill legacy_img_hdr for non-legacy XIP images This is the patch directly before the failing patch mentioned above. Pali, could you please explain what went wrong here? Maybe I'm missing something? Yes, denx mail server is broken and randomly crashes when receiving / processing email. It just bounce back with server stacktrace or what. I tried to resend patches to ML which did not appeared on patchwork. But I cannot do more. So you can try to download patches from patchwork or from github. Okay, I understood the issues with the DENX mail server. Sorry about this. But: Please re-read my lines above. The patches on github are less than the patches sent to the list. There are *more* patches sent to the list (or to me directly) than in your github branch. Ou, so there are more patches on the list than on github? Strange because I sent exactly same patches to ML and on github and some patches were not correctly delivered to mail, therefore number of mail patches could be less than on github. So my question is, why are less patches in your github branch? Or did you try to re-send with this smaller amount of patches and this did not work because of the crashing mail server? I cannot understand how it is possible. There should be 59 patches. I have not created / sent more patches. If there is missing some patch on Github I can double check it... Most likely I have fat-fingered myself something here. Please forget about this. My fault. Thanks, Stefan Thanks, Stefan Thanks, Stefan > Thanks, > Stefan > > > > > > > > >
Re: [PATCH RFC u-boot-mvebu 00/59] arm: mvebu: Various fixes
Hi Pali,
On 2/28/23 23:41, Pali Rohár wrote:
So my question is, why are less patches in your github branch? Or did
you try to re-send with this smaller amount of patches and this did not
work because of the crashing mail server?
I cannot understand how it is possible. There should be 59 patches. I
have not created / sent more patches. If there is missing some patch on
Github I can double check it...
Most likely I have fat-fingered myself something here. Please forget
about this. My fault.
Ok. So do you have all patches in the correct form?
Yes. All fine.
Thanks,
Stefan
Thanks,
Stefan
Thanks,
Stefan
Thanks,
Stefan
> Thanks,
> Stefan
>
> >
> > >
> > > Pali Rohár (59):
> > > tools: kwbimage: Fix generating, verifying and extracting SDIO
> > > kwbimage
> > > tools: kwboot: Fix parsing SDIO kwbimage
> > > arm: mvebu: spl: Fix parsing SDIO kwbimage
> > > cmd: mvebu/bubt: Fix parsing SDIO kwbimage
> > > tools: kwbimage: Fix generating, verifying and extracting SATA
> > > kwbimage
> > > tools: kwboot: Fix parsing SATA kwbimage
> > > arm: mvebu: spl: Fix parsing SATA kwbimage
> > > cmd: mvebu/bubt: Fix parsing SATA kwbimage
> > > arm: mvebu: spl: Remove checks for BOOT_DEVICE_MMC2 and
> > > BOOT_DEVICE_MMC2_2
> > > arm: mvebu: spl: Load proper U-Boot from selected eMMC
boot partition
> > > spl: mmc: Allow to disable SYS_MMCSD_FS_BOOT_PARTITION
> > > arm: mvebu: spl: Fix support for loading U-Boot proper
from SD card
> > > tools: kwboot: Add more documentation references
> > > tools: kwboot: Add image type documentation
> > > tools: kwboot: Fix parsing UART image without data checksum
> > > tools: kwboot: Validate optional kwbimage v1 headers
> > > tools: kwboot: Add check that kwbimage contains DDR init code
> > > tools: kwboot: Fix patching of SPI/NOR XIP images
> > > tools: kwboot: Show image type and error parsing reasons
> > > cmd: mvebu/bubt: Add support for selecting eMMC HW partition
> > > cmd: mvebu/bubt: Add support for writing image to SATA disk
> > > cmd: mvebu/bubt: Add support for reading image from the
SATA disk
> > > partition
> > > cmd: mvebu/bubt: Rename variable image_size to hdr_size
> > > cmd: mvebu/bubt: Mark all local symbols as static
> > > cmd: mvebu/bubt: Do not modify image in A8K
check_image_header()
> > > cmd: mvebu/bubt: Check also A8K boot image checksum
> > > cmd: mvebu/bubt: Set correct default image name for 32-bit
Armada SoCs
> > > cmd: mvebu/bubt: Better guess default MVEBU_*_BOOT option
> > > cmd: mvebu/bubt: Fix warnings: unused variable
'secure_mode' and
> > > 'fuse_read_u64' defined but not used
> > > cmd: mvebu/bubt: Enable command by default
> > > tools: kwbimage: Fix dumping register set / DATA commands
> > > tools: kwbimage: Fix endianity when dumping NAND_PAGE_SIZE
> > > tools: kwbimage: Fix dumping NAND_BADBLK_LOCATION
> > > tools: kwbimage: Fix dumping NAND_BLKSZ
> > > tools: kwbimage: Fix generating of kwbimage v0 header checksum
> > > tools: kwbimage: Fix endianity when printing kwbimage header
> > > tools: kwbimage: Reject mkimage -F option
> > > tools: kwbimage: Add support for dumping NAND_BLKSZ for v0
images
> > > tools: kwbimage: Print binary image offset as size
> > > tools: kwbimage: Print image data offset when printing
kwbimage header
> > > tools: kwbimage: Simplify add_secure_header_v1()
> > > tools: kwbimage: Rename imagesz to dataoff
> > > tools: kwbimage: Fix generating secure boot data image
signature
> > > tools: kwbimage: Fix invalid secure boot header signature
> > > tools: mkimage: Do not fill legacy_img_hdr for non-legacy
XIP images
> > > tools: kwbimage: Add support for XIP SPI/NOR images
> > > tools: mkimage: Print human readable error when -d is not
specified
> > > tools: mkimage: Do not try t
Re: [PATCH RFC u-boot-mvebu 00/59] arm: mvebu: Various fixes
clearfog_sata_defconfig} | 2 +-
...efconfig => db-88f6820-amc_nand_defconfig} | 6 +-
doc/kwboot.1 | 3 +-
doc/mvebu/cmd/bubt.txt| 25 +-
drivers/mtd/nand/raw/Kconfig | 4 +-
tools/kwbimage.c | 297 +++---
tools/kwboot.c| 200 +++-
tools/mkimage.c | 11 +-
22 files changed, 768 insertions(+), 281 deletions(-)
copy configs/{clearfog_defconfig => clearfog_sata_defconfig} (98%)
copy configs/{db-88f6820-amc_defconfig => db-88f6820-amc_nand_defconfig} (92%)
Applied to u-boot-marvell/next
Thanks,
Stefan
Please pull u-boot-marvell/next
Hi Tom, please pull the following Marvell MVEBU related patches into next: - mvebu: Various fixes in SPL / kwboot / kwbimage (Pali) Here the Azure build, without any issues: https://dev.azure.com/sr0718/u-boot/_build/results?buildId=286&view=results Thanks, Stefan The following changes since commit f10905b4b7b9b6888e2532cdfb3536d2244676cb: Merge tag 'tpm-next-28022023' of https://source.denx.de/u-boot/custodians/u-boot-tpm into next (2023-02-28 09:50:16 -0500) are available in the Git repository at: g...@source.denx.de:u-boot/custodians/u-boot-marvell.git next for you to fetch changes up to 1dbeade84e6cb4666bd72a31317c5758e275a1c5: doc/kwboot.1: Update example description (2023-03-01 06:39:18 +0100) Pali Rohár (59): tools: kwbimage: Fix generating, verifying and extracting SDIO kwbimage tools: kwboot: Fix parsing SDIO kwbimage arm: mvebu: spl: Fix parsing SDIO kwbimage cmd: mvebu/bubt: Fix parsing SDIO kwbimage tools: kwbimage: Fix generating, verifying and extracting SATA kwbimage tools: kwboot: Fix parsing SATA kwbimage arm: mvebu: spl: Fix parsing SATA kwbimage cmd: mvebu/bubt: Fix parsing SATA kwbimage arm: mvebu: spl: Remove checks for BOOT_DEVICE_MMC2 and BOOT_DEVICE_MMC2_2 arm: mvebu: spl: Load proper U-Boot from selected eMMC boot partition spl: mmc: Allow to disable SYS_MMCSD_FS_BOOT_PARTITION arm: mvebu: spl: Fix support for loading U-Boot proper from SD card tools: kwboot: Add more documentation references tools: kwboot: Add image type documentation tools: kwboot: Fix parsing UART image without data checksum tools: kwboot: Validate optional kwbimage v1 headers tools: kwboot: Add check that kwbimage contains DDR init code tools: kwboot: Fix patching of SPI/NOR XIP images tools: kwboot: Show image type and error parsing reasons cmd: mvebu/bubt: Add support for selecting eMMC HW partition cmd: mvebu/bubt: Add support for writing image to SATA disk cmd: mvebu/bubt: Add support for reading image from the SATA disk partition cmd: mvebu/bubt: Rename variable image_size to hdr_size cmd: mvebu/bubt: Mark all local symbols as static cmd: mvebu/bubt: Do not modify image in A8K check_image_header() cmd: mvebu/bubt: Check also A8K boot image checksum cmd: mvebu/bubt: Set correct default image name for 32-bit Armada SoCs cmd: mvebu/bubt: Better guess default MVEBU_*_BOOT option cmd: mvebu/bubt: Fix warnings: unused variable 'secure_mode' and 'fuse_read_u64' defined but not used cmd: mvebu/bubt: Enable command by default tools: kwbimage: Fix dumping register set / DATA commands tools: kwbimage: Fix endianity when dumping NAND_PAGE_SIZE tools: kwbimage: Fix dumping NAND_BADBLK_LOCATION tools: kwbimage: Fix dumping NAND_BLKSZ tools: kwbimage: Fix generating of kwbimage v0 header checksum tools: kwbimage: Fix endianity when printing kwbimage header tools: kwbimage: Reject mkimage -F option tools: kwbimage: Add support for dumping NAND_BLKSZ for v0 images tools: kwbimage: Print binary image offset as size tools: kwbimage: Print image data offset when printing kwbimage header tools: kwbimage: Simplify add_secure_header_v1() tools: kwbimage: Rename imagesz to dataoff tools: kwbimage: Fix generating secure boot data image signature tools: kwbimage: Fix invalid secure boot header signature tools: mkimage: Do not fill legacy_img_hdr for non-legacy XIP images tools: kwbimage: Add support for XIP SPI/NOR images tools: mkimage: Print human readable error when -d is not specified tools: mkimage: Do not try to open datafile when it is skipped tools: kwbimage: Add support for creating an image with no data arm: mvebu: Add support for generating NAND kwbimage arm: mvebu: Add support for generating PEX kwbimage arm: mvebu: Fix description of MVEBU_SPL_BOOT_DEVICE_(SPI|MMC) options arm: mvebu: db-88f6820-amc: Add defconfig for NAND booting arm: mvebu: clearfog: Add defconfig for SATA booting arm: mvebu: Remove A39x relicts arm: mvebu: Fix comment about CPU_ATTR_BOOTROM mapping arm: mvebu: Define env_sf_get_env_addr() also for Proper U-Boot arm: mvebu: Define SPL memory maps doc/kwboot.1: Update example description arch/arm/mach-mvebu/Kconfig| 23 +- arch/arm/mach-mvebu/Makefile | 13 + arch/arm/mach-mvebu/cpu.c | 11 +- arch/arm/mach-mvebu/include/mach/cpu.h | 21 ++ arch/arm/mach-mvebu/kwbimage.cfg.in|
Re: [PATCH RFC u-boot-mvebu 0/6] arm: mvebu: Fix boot mode detection
Hi Pali, On 3/4/23 11:50, Pali Rohár wrote: Improve code for checking strapping pins which specifies boot mode source. Martin, could you test if Clearfog can be still configured into UART booting mode via HW switches and if it still works correctly? First patch is reverting UART related commit for Clearfog which I think it not needed anymore. Also could you check if SATA booting is still working correctly? Tony, should address problems with SPI booting when it is configured to different configuration. In fourth commit I added all possible boot mode strapping pin configurations which are recognized by A385 bootrom (and not the only one described in the HW spec, which is incomplete). Stefan, do you have some AXP board with SATA boot source? Because I'm adding it for completeness in the last sixth patch. No, theadorable only boots from SPI NOR. Thanks, Stefan
Re: [PATCH u-boot-mvebu] ddr: marvell: a38x: Remove unused file seq_exec.h
On 3/4/23 13:26, Pali Rohár wrote: DDR code does not use seq_exec.h, so remove it. Signed-off-by: Pali Rohár Reviewed-by: Stefan Roese Thanks, Stefan --- drivers/ddr/marvell/a38x/ddr3_init.h | 1 - drivers/ddr/marvell/a38x/seq_exec.h | 64 2 files changed, 65 deletions(-) delete mode 100644 drivers/ddr/marvell/a38x/seq_exec.h diff --git a/drivers/ddr/marvell/a38x/ddr3_init.h b/drivers/ddr/marvell/a38x/ddr3_init.h index 055516b67e9c..f41a732e9a37 100644 --- a/drivers/ddr/marvell/a38x/ddr3_init.h +++ b/drivers/ddr/marvell/a38x/ddr3_init.h @@ -9,7 +9,6 @@ #include "ddr_ml_wrapper.h" #include "mv_ddr_plat.h" -#include "seq_exec.h" #include "ddr3_logging_def.h" #include "ddr3_training_hw_algo.h" #include "ddr3_training_ip.h" diff --git a/drivers/ddr/marvell/a38x/seq_exec.h b/drivers/ddr/marvell/a38x/seq_exec.h deleted file mode 100644 index fe0cb8f75df2.. Viele Grüße, Stefan Roese -- DENX Software Engineering GmbH, Managing Director: Erika Unter HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de
Re: [RESEND PATCH] arm: mvebu: Set common SPI flash default speed and mode
On 3/3/23 04:27, Tony Dinh wrote: CONFIG_SF_DEFAULT_SPEED is used in SPL SPI to configure and probe the flash device during DM SPI uclass probing process, if the spi-max-frequency is not available in the DTB. Currently the max frequency is not available, because of the probing mechanism in SPI uclass has not been fully updated to DM. The CONFIG_SF_DEFAULT_SPEED is set to 1Mhz if a board defconfig does not specify it. This speed is too slow and result in a few seconds delay while the u-boot image is loaded from flash. Based on a survey of the device tree specifications for MVEBU boards, a sane default value should be 10Mhz. The default of 10Mhz enables an almost instantaneously loading of the u-boot image. Note that this patch depends on this patch series (has been merged to u-boot-marvell/next): https://lists.denx.de/pipermail/u-boot/2023-March/511038.html - RESEND: correct spelling of SF_DEFAULT_MODE Signed-off-by: Tony Dinh Reviewed-by: Stefan Roese Thanks, Stefan --- arch/arm/mach-mvebu/Kconfig | 10 ++ 1 file changed, 10 insertions(+) diff --git a/arch/arm/mach-mvebu/Kconfig b/arch/arm/mach-mvebu/Kconfig index cdb1776a66..8f744e2177 100644 --- a/arch/arm/mach-mvebu/Kconfig +++ b/arch/arm/mach-mvebu/Kconfig @@ -424,6 +424,16 @@ config SECURED_MODE_CSK_INDEX default 0 depends on SECURED_MODE_IMAGE +config SF_DEFAULT_SPEED + int "Default speed for SPI flash in Hz" + default 1000 + depends on MVEBU_SPL_BOOT_DEVICE_SPI + +config SF_DEFAULT_MODE + hex "Default mode for SPI flash" + default 0x0 + depends on MVEBU_SPL_BOOT_DEVICE_SPI + source "board/solidrun/clearfog/Kconfig" source "board/kobol/helios4/Kconfig" Viele Grüße, Stefan Roese -- DENX Software Engineering GmbH, Managing Director: Erika Unter HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de
Re: [PATCH] arm: mvebu: Use 4K sector for Thecus N2350 SPI flash
On 2/17/23 04:34, Tony Dinh wrote: Since the SPI flash chip mx25l3205d on this board has 4K-sector capability, enable it for the envs. Signed-off-by: Tony Dinh Applied to u-boot-marvell/master Thanks, Stefan --- configs/n2350_defconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configs/n2350_defconfig b/configs/n2350_defconfig index dcb2c96791..b85ef0dfeb 100644 --- a/configs/n2350_defconfig +++ b/configs/n2350_defconfig @@ -14,7 +14,7 @@ CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0xff CONFIG_TARGET_N2350=y CONFIG_ENV_SIZE=0x1 CONFIG_ENV_OFFSET=0x10 -CONFIG_ENV_SECT_SIZE=0x1 +CONFIG_ENV_SECT_SIZE=0x1000 CONFIG_DEFAULT_DEVICE_TREE="armada-385-thecus-n2350" CONFIG_SPL_TEXT_BASE=0x4030 CONFIG_SYS_PROMPT="N2350 > " Viele Grüße, Stefan Roese -- DENX Software Engineering GmbH, Managing Director: Erika Unter HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de
Please pull u-boot-marvell/master
Hi Tom, please pull this small Marvell related fix: - mvebu: Use 4K sector for Thecus N2350 SPI flash (Tony) Here the Azure build, without any issues: https://dev.azure.com/sr0718/u-boot/_build/results?buildId=287&view=results Thanks, Stefan The following changes since commit 33fb2d130e28982b488c2a54978031835ed2aa71: Merge tag 'dm-pull-29feb23' of https://source.denx.de/u-boot/custodians/u-boot-dm (2023-03-01 16:07:24 -0500) are available in the Git repository at: g...@source.denx.de:u-boot/custodians/u-boot-marvell.git for you to fetch changes up to aed49a05c71897f787f54a204bb5bf5e620c81fc: arm: mvebu: Use 4K sector for Thecus N2350 SPI flash (2023-03-06 10:16:07 +0100) Tony Dinh (1): arm: mvebu: Use 4K sector for Thecus N2350 SPI flash configs/n2350_defconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
Re: [GIT PULL] Please pull u-boot-mmc master
On 3/10/23 17:28, Marek Vasut wrote: On 3/10/23 16:44, Tom Rini wrote: On Fri, Mar 10, 2023 at 01:22:15PM +0900, Jaehoon Chung wrote: Dear Tom, Please pull u-boot-mmc master into u-boot master branch. If there is any problem, let me know, plz. At this point in the cycle I have to ask, are these all fixes of specific issues? If not, I'd rather take this to -next. Thanks! The stuff from me can easily go into next. Same for my patches. Thanks, Stefan
Default value for bootcmd not defined
Hello, I followed the official documentation [1] to build U-Boot for my Rock Pi 4, instead of evb-rk3399_defconfig I used the config file for my board (rock-pi-4-rk3399_defconfig). After I flashed the single boot image to an SD card and put it in I got stuck with the error message: "distro_bootcmd" not defined. Since I have no idea of U-Boot it took me some time to find out that all I needed was to set a different default value for bootcmd. Now I use CONFIG_BOOTCOMMAND="bootflow scan" and it boots my OS as expected. The official documentation looks straightforward for simple users like me, so I thought it might not be intended that the default value for the bootcmd entry is (still) distro_bootcmd. Regards, Stefan. [1] https://u-boot.readthedocs.io/en/latest/board/rockchip/rockchip.html -- E-Mails signieren & verschlüsseln · https://emailselfdefense.fsf.org/de/ signature.asc Description: This is a digitally signed message part
Re: [PATCH] console: Use flush() before panic and reset
On 3/15/23 21:29, Tony Dinh wrote:
Hi Simon,
On Wed, Mar 15, 2023 at 12:43 PM Simon Glass wrote:
On Tue, 14 Mar 2023 at 18:24, Tony Dinh wrote:
To make sure the panic and the reset messages will go out, console flush()
should be used.
Sleep periods do not work in early u-boot phase when timer driver is not
initialized yet.
Reference: https://lists.denx.de/pipermail/u-boot/2023-March/512233.html
Signed-off-by: Tony Dinh
---
arch/arm/lib/reset.c | 4 ++--
lib/panic.c | 4 +++-
2 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/arch/arm/lib/reset.c b/arch/arm/lib/reset.c
index 95169bae1c..3e051e36f1 100644
--- a/arch/arm/lib/reset.c
+++ b/arch/arm/lib/reset.c
@@ -25,6 +25,7 @@
#include
#include
#include
+#include
Reviewed-by: Simon Glass
Is flush implemented widely?
Pali wrote that flush function and here was his comment on the
referenced thread:
"Moreover there is already new function named flush() which
does "wait until stdout message was sent" and can be used instead of
those sleeps. I have already did it on some places (see git history for
flush function) but seems that you find some more."
So I think the answer is not yet widely implemented.
I just checked and it seems it's supported for all platforms using
DM_SERIAL when the serial driver supports the pending() function:
drivers/serial/serial-uclass.c:
#ifdef CONFIG_CONSOLE_FLUSH_SUPPORT
static void _serial_flush(struct udevice *dev)
{
struct dm_serial_ops *ops = serial_get_ops(dev);
if (!ops->pending)
return;
while (ops->pending(dev, false) > 0)
;
}
#endif
So AFAICT it's implemented widely. Not sure, why
CONFIG_CONSOLE_FLUSH_SUPPORT was introduced. It's enabled by default
and should be available in all cases IMHO.
Thanks,
Stefan
Re: [PATCH v3 3/5] x86: conga-qeval20-qa3-e3845: Fix up adjustment of CONFIG_TEXT_BASE
On 3/15/23 00:59, Simon Glass wrote:
With recent CONFIG_TEXT_BASE changes, there are inconsistencies between
several settings.
Adjust CONFIG_SYS_MONITOR_LEN to allow more code space. Move the MRC
cache out of the way too.
Signed-off-by: Simon Glass
Fixes: 388f93f9635 ("x86: conga-qeval20-qa3-e3845: Adjust CONFIG_TEXT_BASE")
Reviewed-by: Stefan Roese
Thanks,
Stefan
---
Changes in v3:
- Add new patch
arch/x86/dts/conga-qeval20-qa3-e3845.dts | 2 +-
configs/conga-qeval20-qa3-e3845-internal-uart_defconfig | 1 +
configs/conga-qeval20-qa3-e3845_defconfig | 1 +
configs/theadorable-x86-conga-qa3-e3845-pcie-x4_defconfig | 1 +
configs/theadorable-x86-conga-qa3-e3845_defconfig | 1 +
5 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/arch/x86/dts/conga-qeval20-qa3-e3845.dts
b/arch/x86/dts/conga-qeval20-qa3-e3845.dts
index 705157ceaa33..d11e789945ac 100644
--- a/arch/x86/dts/conga-qeval20-qa3-e3845.dts
+++ b/arch/x86/dts/conga-qeval20-qa3-e3845.dts
@@ -193,7 +193,7 @@
memory-map = <0xff80 0x0080>;
rw-mrc-cache {
label = "rw-mrc-cache";
- reg = <0x006f 0x0001>;
+ reg = <0x005f 0x0001>;
};
};
};
diff --git a/configs/conga-qeval20-qa3-e3845-internal-uart_defconfig
b/configs/conga-qeval20-qa3-e3845-internal-uart_defconfig
index 3a84190bbfdc..f1bfc9653ca7 100644
--- a/configs/conga-qeval20-qa3-e3845-internal-uart_defconfig
+++ b/configs/conga-qeval20-qa3-e3845-internal-uart_defconfig
@@ -18,6 +18,7 @@ CONFIG_GENERATE_PIRQ_TABLE=y
CONFIG_GENERATE_MP_TABLE=y
CONFIG_HAVE_ACPI_RESUME=y
CONFIG_SEABIOS=y
+CONFIG_SYS_MONITOR_LEN=2097152
CONFIG_FIT=y
CONFIG_FIT_SIGNATURE=y
CONFIG_BOOTSTAGE=y
diff --git a/configs/conga-qeval20-qa3-e3845_defconfig
b/configs/conga-qeval20-qa3-e3845_defconfig
index bb8b9ef312a6..09d08a842f09 100644
--- a/configs/conga-qeval20-qa3-e3845_defconfig
+++ b/configs/conga-qeval20-qa3-e3845_defconfig
@@ -14,6 +14,7 @@ CONFIG_GENERATE_PIRQ_TABLE=y
CONFIG_GENERATE_MP_TABLE=y
CONFIG_HAVE_ACPI_RESUME=y
CONFIG_SEABIOS=y
+CONFIG_SYS_MONITOR_LEN=2097152
CONFIG_FIT=y
CONFIG_FIT_SIGNATURE=y
CONFIG_BOOTSTAGE=y
diff --git a/configs/theadorable-x86-conga-qa3-e3845-pcie-x4_defconfig
b/configs/theadorable-x86-conga-qa3-e3845-pcie-x4_defconfig
index 74c4a4967d0f..00fa3544bd10 100644
--- a/configs/theadorable-x86-conga-qa3-e3845-pcie-x4_defconfig
+++ b/configs/theadorable-x86-conga-qa3-e3845-pcie-x4_defconfig
@@ -17,6 +17,7 @@ CONFIG_GENERATE_PIRQ_TABLE=y
CONFIG_GENERATE_MP_TABLE=y
CONFIG_HAVE_ACPI_RESUME=y
CONFIG_SEABIOS=y
+CONFIG_SYS_MONITOR_LEN=2097152
CONFIG_FIT=y
CONFIG_FIT_SIGNATURE=y
CONFIG_BOOTSTAGE=y
diff --git a/configs/theadorable-x86-conga-qa3-e3845_defconfig
b/configs/theadorable-x86-conga-qa3-e3845_defconfig
index 194b0519ea22..7cf8c551451e 100644
--- a/configs/theadorable-x86-conga-qa3-e3845_defconfig
+++ b/configs/theadorable-x86-conga-qa3-e3845_defconfig
@@ -16,6 +16,7 @@ CONFIG_GENERATE_PIRQ_TABLE=y
CONFIG_GENERATE_MP_TABLE=y
CONFIG_HAVE_ACPI_RESUME=y
CONFIG_SEABIOS=y
+CONFIG_SYS_MONITOR_LEN=2097152
CONFIG_FIT=y
CONFIG_FIT_SIGNATURE=y
CONFIG_BOOTSTAGE=y
Viele Grüße,
Stefan Roese
--
DENX Software Engineering GmbH, Managing Director: Erika Unter
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de
Re: [PATCH v3 4/5] x86: dfi-bt700: Fix up adjustment of CONFIG_TEXT_BASE
On 3/15/23 00:59, Simon Glass wrote:
With recent CONFIG_TEXT_BASE changes, there are inconsistencies between
several settings.
Adjust CONFIG_SYS_MONITOR_LEN to allow more code space. Move the MRC
cache out of the way too.
Signed-off-by: Simon Glass
Fixes: 5d1c8342aea ("x86: dfi-bt700: Adjust CONFIG_TEXT_BASE")
Reviewed-by: Stefan Roese
Thanks,
Stefan
---
Changes in v3:
- Add new patch
arch/x86/dts/dfi-bt700.dtsi | 2 +-
configs/dfi-bt700-q7x-151_defconfig | 1 +
configs/theadorable-x86-dfi-bt700_defconfig | 1 +
3 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/x86/dts/dfi-bt700.dtsi b/arch/x86/dts/dfi-bt700.dtsi
index dff2345d60d0..c077a84574f1 100644
--- a/arch/x86/dts/dfi-bt700.dtsi
+++ b/arch/x86/dts/dfi-bt700.dtsi
@@ -204,7 +204,7 @@
memory-map = <0xff80 0x0080>;
rw-mrc-cache {
label = "rw-mrc-cache";
- reg = <0x006f 0x0001>;
+ reg = <0x005f 0x0001>;
};
};
};
diff --git a/configs/dfi-bt700-q7x-151_defconfig
b/configs/dfi-bt700-q7x-151_defconfig
index bd8b2e1155d4..a48f7c25134c 100644
--- a/configs/dfi-bt700-q7x-151_defconfig
+++ b/configs/dfi-bt700-q7x-151_defconfig
@@ -13,6 +13,7 @@ CONFIG_GENERATE_PIRQ_TABLE=y
CONFIG_GENERATE_MP_TABLE=y
CONFIG_HAVE_ACPI_RESUME=y
CONFIG_SEABIOS=y
+CONFIG_SYS_MONITOR_LEN=2097152
CONFIG_FIT=y
CONFIG_FIT_SIGNATURE=y
CONFIG_BOOTSTAGE=y
diff --git a/configs/theadorable-x86-dfi-bt700_defconfig
b/configs/theadorable-x86-dfi-bt700_defconfig
index 39c8a87fbeea..82c348884559 100644
--- a/configs/theadorable-x86-dfi-bt700_defconfig
+++ b/configs/theadorable-x86-dfi-bt700_defconfig
@@ -15,6 +15,7 @@ CONFIG_GENERATE_PIRQ_TABLE=y
CONFIG_GENERATE_MP_TABLE=y
CONFIG_HAVE_ACPI_RESUME=y
CONFIG_SEABIOS=y
+CONFIG_SYS_MONITOR_LEN=2097152
CONFIG_FIT=y
CONFIG_FIT_SIGNATURE=y
CONFIG_BOOTSTAGE=y
Viele Grüße,
Stefan Roese
--
DENX Software Engineering GmbH, Managing Director: Erika Unter
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de
Re: [PATCH] console: Use flush() before panic and reset
On 3/15/23 20:43, Simon Glass wrote: On Tue, 14 Mar 2023 at 18:24, Tony Dinh wrote: To make sure the panic and the reset messages will go out, console flush() should be used. Sleep periods do not work in early u-boot phase when timer driver is not initialized yet. Reference: https://lists.denx.de/pipermail/u-boot/2023-March/512233.html Signed-off-by: Tony Dinh --- arch/arm/lib/reset.c | 4 ++-- lib/panic.c | 4 +++- 2 files changed, 5 insertions(+), 3 deletions(-) diff --git a/arch/arm/lib/reset.c b/arch/arm/lib/reset.c index 95169bae1c..3e051e36f1 100644 --- a/arch/arm/lib/reset.c +++ b/arch/arm/lib/reset.c @@ -25,6 +25,7 @@ #include #include #include +#include Reviewed-by: Simon Glass Reviewed-by: Stefan Roese Thanks, Stefan
Re: [PATCH] arm: kirkwood: Enable Debug UART for Zyxel NSA310S
On 3/13/23 04:35, Tony Dinh wrote: It's useful to enable Debug UART for future DM Serial regression tests for Kirkwood boards. Also, see background discussion in this thread: https://lists.denx.de/pipermail/u-boot/2023-March/512010.html Signed-off-by: Tony Dinh Reviewed-by: Stefan Roese Thanks, Stefan --- configs/nsa310s_defconfig | 4 1 file changed, 4 insertions(+) diff --git a/configs/nsa310s_defconfig b/configs/nsa310s_defconfig index 76839e62dd..b936ae1b25 100644 --- a/configs/nsa310s_defconfig +++ b/configs/nsa310s_defconfig @@ -15,8 +15,11 @@ CONFIG_ENV_SIZE=0x2 CONFIG_ENV_OFFSET=0xE CONFIG_DEFAULT_DEVICE_TREE="kirkwood-nsa310s" CONFIG_SYS_PROMPT="NSA310s> " +CONFIG_DEBUG_UART_BASE=0xf1012000 +CONFIG_DEBUG_UART_CLOCK=16667 CONFIG_IDENT_STRING="\nZyXEL NSA310S/320S 1/2-Bay Power Media Server" CONFIG_SYS_LOAD_ADDR=0x80 +CONFIG_DEBUG_UART=y CONFIG_DISTRO_DEFAULTS=y CONFIG_BOOTDELAY=3 CONFIG_USE_PREBOOT=y @@ -50,6 +53,7 @@ CONFIG_MTD_RAW_NAND=y CONFIG_PHY_MARVELL=y CONFIG_MVGBE=y CONFIG_MII=y +CONFIG_DEBUG_UART_SHIFT=2 CONFIG_USB=y CONFIG_USB_EHCI_HCD=y CONFIG_UBIFS_SILENCE_MSG=y Viele Grüße, Stefan Roese -- DENX Software Engineering GmbH, Managing Director: Erika Unter HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de
Re: [PATCH RFC u-boot-mvebu] arm: kirkwood: Move internal registers in arch_very_early_init() function
On 3/11/23 11:57, Pali Rohár wrote:
Same change as was done for mvebu in commit 5bb2c550b11e ("arm: mvebu: Move
internal registers in arch_very_early_init() function") but for kirkwood.
Signed-off-by: Pali Rohár
Reviewed-by: Stefan Roese
Thanks,
Stefan
---
Hello! Please test this RFC patch on more Kirkwood boards if there is
any issue with it.
---
arch/arm/mach-kirkwood/Kconfig| 2 ++
arch/arm/mach-kirkwood/Makefile | 1 +
arch/arm/mach-kirkwood/cpu.c | 3 ---
arch/arm/mach-kirkwood/lowlevel.S | 12
4 files changed, 15 insertions(+), 3 deletions(-)
create mode 100644 arch/arm/mach-kirkwood/lowlevel.S
diff --git a/arch/arm/mach-kirkwood/Kconfig b/arch/arm/mach-kirkwood/Kconfig
index c8a193dd4cdf..ba39e9ae416e 100644
--- a/arch/arm/mach-kirkwood/Kconfig
+++ b/arch/arm/mach-kirkwood/Kconfig
@@ -5,9 +5,11 @@ config FEROCEON_88FR131
config KW88F6192
bool
+ select ARCH_VERY_EARLY_INIT
config KW88F6281
bool
+ select ARCH_VERY_EARLY_INIT
config SHEEVA_88SV131
bool
diff --git a/arch/arm/mach-kirkwood/Makefile b/arch/arm/mach-kirkwood/Makefile
index 3b2eef8d5419..0fb5a2326f5f 100644
--- a/arch/arm/mach-kirkwood/Makefile
+++ b/arch/arm/mach-kirkwood/Makefile
@@ -6,6 +6,7 @@
obj-y = cpu.o
obj-y += cache.o
+obj-y += lowlevel.o
obj-y += mpp.o
# cpu.o and cache.o contain CP15 instructions which cannot be run in
diff --git a/arch/arm/mach-kirkwood/cpu.c b/arch/arm/mach-kirkwood/cpu.c
index df3e8f11782a..2b493b36c20d 100644
--- a/arch/arm/mach-kirkwood/cpu.c
+++ b/arch/arm/mach-kirkwood/cpu.c
@@ -189,9 +189,6 @@ int arch_cpu_init(void)
struct kwcpu_registers *cpureg =
(struct kwcpu_registers *)KW_CPU_REG_BASE;
- /* Linux expects the internal registers to be at 0xf100 */
- writel(KW_REGS_PHY_BASE, KW_OFFSET_REG);
-
/* Enable and invalidate L2 cache in write through mode */
writel(readl(&cpureg->l2_cfg) | 0x18, &cpureg->l2_cfg);
invalidate_l2_cache();
diff --git a/arch/arm/mach-kirkwood/lowlevel.S
b/arch/arm/mach-kirkwood/lowlevel.S
new file mode 100644
index ..3b339f97f056
--- /dev/null
+++ b/arch/arm/mach-kirkwood/lowlevel.S
@@ -0,0 +1,12 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+
+#include
+#include
+
+ENTRY(arch_very_early_init)
+ /* Move internal registers from KW_OFFSET_REG to KW_REGS_PHY_BASE */
+ ldr r0, =KW_REGS_PHY_BASE
+ ldr r1, =KW_OFFSET_REG
+ str r0, [r1]
+ bx lr
+ENDPROC(arch_very_early_init)
Viele Grüße,
Stefan Roese
--
DENX Software Engineering GmbH, Managing Director: Erika Unter
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de
[QUESTION] Device tree for gmii-to-rgmii phy driver
Hi Siva Durga Prasad Paladugu,
we want to add rgmii-id support to the gmiitorgmii phy driver. How does
the correct device tree for the gmiitorgmii looks like? The converter
sits between the MAC and the external PHY (MAC <==> GMII2RGMII <==>
RGMII_PHY) which would mean that the phy-handle of the MAC should point
to the GMII2RGMII and the GMII2RGMII to RGMII_PHY:
&gem0 {
phy-handle = <&gmiitorgmii0>;
phy-mode = "gmii";
mdio {
ethphy0: ethernet-phy@1 {
};
gmiitorgmii0: gmiitorgmii@8 {
compatible = "xlnx,gmii-to-rgmii-1.0";
phy-handle = <ðphy0>;
phy-mode = "rgmii-id";
};
};
};
This device tree snippet does not work in the kernel. The kernel
gmii2rgmii driver does not use a phy driver as base and manipulates the
functions of the external phy object instead. It requires the following
device tree snippet:
&gem0 {
phy-handle = <ðphy0>;
phy-mode = "rgmii-id";
mdio {
ethphy0: ethernet-phy@1 {
};
gmiitorgmii0: gmiitorgmii@8 {
compatible = "xlnx,gmii-to-rgmii-1.0";
phy-handle = <ðphy0>;
phy-mode = "rgmii-id";
};
};
};
This does not work in u-boot because the phy framework ignores the
phy-handle of the MAC for the gmii2rgmii but the gmii2rgmii driver
itself checks the phy-mode of the MAC.
What is the correct device tree and thereby proper implementation?
Regards
Stefan
[PATCH] fs: fat: do not mangle short filenames
From: Stefan Herbrechtsmeier
Do not mangle lower or mixed case filenames which fit into the upper
case 8.3 short filename. This ensures FAT standard compatible short
filenames (SFN) to support systems without long filename (LFN) support
like boot roms (ex. SFN BOOT.BIN instead of BOOT~1.BIN for LFN
boot.bin).
Signed-off-by: Stefan Herbrechtsmeier
---
fs/fat/fat_write.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/fs/fat/fat_write.c b/fs/fat/fat_write.c
index 00541ebc3a..413fc432eb 100644
--- a/fs/fat/fat_write.c
+++ b/fs/fat/fat_write.c
@@ -141,6 +141,8 @@ static int set_name(fat_itr *itr, const char *filename,
char *shortname)
if (!strcmp(buf, filename)) {
ret = 1;
goto out;
+ } else if (!strcasecmp(buf, filename)) {
+ goto out_ret;
}
/* Construct an indexed short name */
@@ -177,12 +179,13 @@ static int set_name(fat_itr *itr, const char *filename,
char *shortname)
if (find_directory_entry(itr, buf))
continue;
- debug("chosen short name: %s\n", buf);
- /* Each long name directory entry takes 13 characters. */
- ret = (strlen(filename) + 25) / 13;
- goto out;
+ goto out_ret;
}
return -EIO;
+out_ret:
+ debug("chosen short name: %s\n", buf);
+ /* Each long name directory entry takes 13 characters. */
+ ret = (strlen(filename) + 25) / 13;
out:
memcpy(shortname, &dirent, SHORT_NAME_SIZE);
return ret;
--
2.30.2
[PATCH] net: phy: gmii2rgmii: Support external rgmii-id phy
From: Stefan Herbrechtsmeier Read the phy mode of the external phy from the device tree if available. Signed-off-by: Stefan Herbrechtsmeier --- drivers/net/phy/xilinx_gmii2rgmii.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/net/phy/xilinx_gmii2rgmii.c b/drivers/net/phy/xilinx_gmii2rgmii.c index 7376283956..12519a8d57 100644 --- a/drivers/net/phy/xilinx_gmii2rgmii.c +++ b/drivers/net/phy/xilinx_gmii2rgmii.c @@ -48,7 +48,10 @@ static int xilinxgmiitorgmii_config(struct phy_device *phydev) return -EINVAL; } - ext_phydev->interface = PHY_INTERFACE_MODE_RGMII; + ext_phydev->interface = ofnode_read_phy_mode(node); + if (ext_phydev->interface == PHY_INTERFACE_MODE_NA) + ext_phydev->interface = PHY_INTERFACE_MODE_RGMII; + ext_phydev->node = phandle.node; phydev->priv = ext_phydev; -- 2.30.2
Re: [PATCH] fs: fat: do not mangle short filenames
Am 20.03.2023 um 18:01 schrieb Tom Rini: On Fri, Mar 17, 2023 at 01:04:13PM +0100, Stefan Herbrechtsmeier wrote: From: Stefan Herbrechtsmeier Do not mangle lower or mixed case filenames which fit into the upper case 8.3 short filename. This ensures FAT standard compatible short filenames (SFN) to support systems without long filename (LFN) support like boot roms (ex. SFN BOOT.BIN instead of BOOT~1.BIN for LFN boot.bin). Signed-off-by: Stefan Herbrechtsmeier --- fs/fat/fat_write.c | 11 +++ 1 file changed, 7 insertions(+), 4 deletions(-) Can we update test/py/tests/test_fs/ somewhere to have a test for this case? Thanks. What is the recommended approach to test internal behavior? The short name isn't avialable at the terminal because u-boot support VFAT.
Re: [PATCH] fs: fat: do not mangle short filenames
Am 21.03.2023 um 16:35 schrieb Tom Rini: On Tue, Mar 21, 2023 at 08:43:07AM +0100, Stefan Herbrechtsmeier wrote: Am 20.03.2023 um 18:01 schrieb Tom Rini: On Fri, Mar 17, 2023 at 01:04:13PM +0100, Stefan Herbrechtsmeier wrote: From: Stefan Herbrechtsmeier Do not mangle lower or mixed case filenames which fit into the upper case 8.3 short filename. This ensures FAT standard compatible short filenames (SFN) to support systems without long filename (LFN) support like boot roms (ex. SFN BOOT.BIN instead of BOOT~1.BIN for LFN boot.bin). Signed-off-by: Stefan Herbrechtsmeier --- fs/fat/fat_write.c | 11 +++ 1 file changed, 7 insertions(+), 4 deletions(-) Can we update test/py/tests/test_fs/ somewhere to have a test for this case? Thanks. What is the recommended approach to test internal behavior? The short name isn't avialable at the terminal because u-boot support VFAT. Well, you triggered this problem with a filesystem that had contents that were "just so" and then didn't work as expected, yes? No, I write a file to a file system and the boot rom do not find the file because the name was wrong (BOOT~1.BIN instead of BOOT.BIN). The mdir command shows the short and long file name. I will add a test_fat.py with a test. Regards Stefan
[PATCH v2] net: phy: gmii2rgmii: Support external rgmii-id phy
From: Stefan Herbrechtsmeier
Read the phy mode of the external phy from the device tree if available
and check that it is a RGMII variant.
Signed-off-by: Stefan Herbrechtsmeier
---
Changes in v2:
- Check that the external phy mode is a RGMII variant
drivers/net/phy/xilinx_gmii2rgmii.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/net/phy/xilinx_gmii2rgmii.c
b/drivers/net/phy/xilinx_gmii2rgmii.c
index 7376283956..853a0df659 100644
--- a/drivers/net/phy/xilinx_gmii2rgmii.c
+++ b/drivers/net/phy/xilinx_gmii2rgmii.c
@@ -48,7 +48,14 @@ static int xilinxgmiitorgmii_config(struct phy_device
*phydev)
return -EINVAL;
}
- ext_phydev->interface = PHY_INTERFACE_MODE_RGMII;
+ ext_phydev->interface = ofnode_read_phy_mode(node);
+ if (ext_phydev->interface == PHY_INTERFACE_MODE_NA) {
+ ext_phydev->interface = PHY_INTERFACE_MODE_RGMII;
+ } else if (!phy_interface_is_rgmii(ext_phydev)) {
+ printf("Incorrect external interface type\n");
+ return -EINVAL;
+ }
+
ext_phydev->node = phandle.node;
phydev->priv = ext_phydev;
--
2.30.2
[PATCH] test: fs: Check fat short file name
From: Stefan Herbrechtsmeier
Ensure that a freshly written fat file with a lower case filename which
fits into the upper case 8.3 short filename is not mangeled with a tilde
and number.
Signed-off-by: Stefan Herbrechtsmeier
---
test/py/tests/test_fs/test_ext.py | 36 +++
1 file changed, 36 insertions(+)
diff --git a/test/py/tests/test_fs/test_ext.py
b/test/py/tests/test_fs/test_ext.py
index dba874fc59..05fefa53a0 100644
--- a/test/py/tests/test_fs/test_ext.py
+++ b/test/py/tests/test_fs/test_ext.py
@@ -8,11 +8,24 @@
This test verifies extended write operation on file system.
"""
+import os.path
import pytest
import re
+from subprocess import check_output
from fstest_defs import *
from fstest_helpers import assert_fs_integrity
+PLAIN_FILE='abcdefgh.txt'
+MANGLE_FILE='abcdefghi.txt'
+
+def str2fat(long_filename):
+splitext = os.path.splitext(long_filename.upper())
+name = splitext[0]
+ext = splitext[1][1:]
+if len(name) > 8:
+name = '%s~1' % name[:6]
+return '%-8s %s' % (name, ext)
+
@pytest.mark.boardspec('sandbox')
@pytest.mark.slow
class TestFsExt(object):
@@ -317,3 +330,26 @@ class TestFsExt(object):
assert('FILE0123456789_79' in output)
assert_fs_integrity(fs_type, fs_img)
+
+def test_fs_ext12(self, u_boot_console, fs_obj_ext):
+"""
+Test Case 12 - write plain and mangle file
+"""
+fs_type,fs_img,md5val = fs_obj_ext
+with u_boot_console.log.section('Test Case 12 - write plain and mangle
file'):
+# Test Case 12a - Check if command successfully returned
+output = u_boot_console.run_command_list([
+'host bind 0 %s' % fs_img,
+'%swrite host 0:0 %x /%s 0'
+% (fs_type, ADDR, PLAIN_FILE),
+'%swrite host 0:0 %x /%s 0'
+% (fs_type, ADDR, MANGLE_FILE)])
+assert('0 bytes written' in ''.join(output))
+# Test Case 12b - Read file system content
+output = check_output('mdir -i %s' % fs_img, shell=True).decode()
+# Test Case 12c - Check if short filename is not mangled
+assert(str2fat(PLAIN_FILE) in ''.join(output))
+# Test Case 12d - Check if long filename is mangled
+assert(str2fat(MANGLE_FILE) in ''.join(output))
+
+assert_fs_integrity(fs_type, fs_img)
--
2.30.2
Re: [PATCH] fs: fat: do not mangle short filenames
Am 21.03.2023 um 16:54 schrieb Tom Rini: On Tue, Mar 21, 2023 at 04:53:22PM +0100, Stefan Herbrechtsmeier wrote: Am 21.03.2023 um 16:35 schrieb Tom Rini: On Tue, Mar 21, 2023 at 08:43:07AM +0100, Stefan Herbrechtsmeier wrote: Am 20.03.2023 um 18:01 schrieb Tom Rini: On Fri, Mar 17, 2023 at 01:04:13PM +0100, Stefan Herbrechtsmeier wrote: From: Stefan Herbrechtsmeier Do not mangle lower or mixed case filenames which fit into the upper case 8.3 short filename. This ensures FAT standard compatible short filenames (SFN) to support systems without long filename (LFN) support like boot roms (ex. SFN BOOT.BIN instead of BOOT~1.BIN for LFN boot.bin). Signed-off-by: Stefan Herbrechtsmeier --- fs/fat/fat_write.c | 11 +++ 1 file changed, 7 insertions(+), 4 deletions(-) Can we update test/py/tests/test_fs/ somewhere to have a test for this case? Thanks. What is the recommended approach to test internal behavior? The short name isn't avialable at the terminal because u-boot support VFAT. Well, you triggered this problem with a filesystem that had contents that were "just so" and then didn't work as expected, yes? No, I write a file to a file system and the boot rom do not find the file because the name was wrong (BOOT~1.BIN instead of BOOT.BIN). The mdir command shows the short and long file name. I will add a test_fat.py with a test. Ah, ok, and great, thanks! I have send a separate patch `test: fs: Check fat short file name` or should I send a new series with both patches? Regards Stefan
[PATCH] arm64: dts: rockchip: rk3568: Add ODROID-M1 board support
Add ODROID-M1 board support. Board device tree rk3568-odroid-m1.dts
from v6.4.
Signed-off-by: Stefan Agner
---
arch/arm/dts/Makefile | 1 +
arch/arm/dts/rk3568-odroid-m1-u-boot.dtsi | 29 +
arch/arm/dts/rk3568-odroid-m1.dts | 744 ++
configs/odroid-m1_defconfig | 84 +++
4 files changed, 858 insertions(+)
create mode 100644 arch/arm/dts/rk3568-odroid-m1-u-boot.dtsi
create mode 100644 arch/arm/dts/rk3568-odroid-m1.dts
create mode 100644 configs/odroid-m1_defconfig
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 480269fa60..11028c3a5e 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -169,6 +169,7 @@ dtb-$(CONFIG_ROCKCHIP_RK3568) += \
rk3566-anbernic-rgxx3.dtb \
rk3566-radxa-cm3-io.dtb \
rk3568-evb.dtb \
+ rk3568-odroid-m1.dts \
rk3568-rock-3a.dtb
dtb-$(CONFIG_ROCKCHIP_RK3588) += \
diff --git a/arch/arm/dts/rk3568-odroid-m1-u-boot.dtsi
b/arch/arm/dts/rk3568-odroid-m1-u-boot.dtsi
new file mode 100644
index 00..3d75dd403b
--- /dev/null
+++ b/arch/arm/dts/rk3568-odroid-m1-u-boot.dtsi
@@ -0,0 +1,29 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * (C) Copyright 2021 Rockchip Electronics Co., Ltd
+ * (C) Copyright 2023 Akash Gajjar
+ * (C) Copyright 2023 Stefan Agner
+ */
+
+#include "rk356x-u-boot.dtsi"
+
+/ {
+ chosen {
+ stdout-path = &uart2;
+ u-boot,spl-boot-order = "same-as-spl", &sdhci, &sdmmc0;
+ };
+};
+
+&sdmmc0 {
+ status = "okay";
+};
+
+&sdhci {
+ status = "okay";
+};
+
+&uart2 {
+ clock-frequency = <2400>;
+ bootph-all;
+ u-boot,dm-pre-reloc;
+};
diff --git a/arch/arm/dts/rk3568-odroid-m1.dts
b/arch/arm/dts/rk3568-odroid-m1.dts
new file mode 100644
index 00..59ecf868db
--- /dev/null
+++ b/arch/arm/dts/rk3568-odroid-m1.dts
@@ -0,0 +1,744 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2022 Hardkernel Co., Ltd.
+ *
+ */
+
+/dts-v1/;
+#include
+#include
+#include
+#include
+#include "rk3568.dtsi"
+
+/ {
+ model = "Hardkernel ODROID-M1";
+ compatible = "rockchip,rk3568-odroid-m1", "rockchip,rk3568";
+
+ aliases {
+ ethernet0 = &gmac0;
+ i2c0 = &i2c3;
+ i2c3 = &i2c0;
+ mmc0 = &sdhci;
+ mmc1 = &sdmmc0;
+ serial0 = &uart1;
+ serial1 = &uart0;
+ };
+
+ chosen {
+ stdout-path = "serial2:150n8";
+ };
+
+ dc_12v: dc-12v-regulator {
+ compatible = "regulator-fixed";
+ regulator-name = "dc_12v";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1200>;
+ regulator-max-microvolt = <1200>;
+ };
+
+ hdmi-con {
+ compatible = "hdmi-connector";
+ type = "a";
+
+ port {
+ hdmi_con_in: endpoint {
+ remote-endpoint = <&hdmi_out_con>;
+ };
+ };
+ };
+
+ ir-receiver {
+ compatible = "gpio-ir-receiver";
+ gpios = <&gpio0 RK_PC2 GPIO_ACTIVE_LOW>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&ir_receiver_pin>;
+ };
+
+ leds {
+ compatible = "gpio-leds";
+
+ led_power: led-0 {
+ gpios = <&gpio0 RK_PC6 GPIO_ACTIVE_HIGH>;
+ function = LED_FUNCTION_POWER;
+ color = ;
+ default-state = "keep";
+ linux,default-trigger = "default-on";
+ pinctrl-names = "default";
+ pinctrl-0 = <&led_power_pin>;
+ };
+ led_work: led-1 {
+ gpios = <&gpio0 RK_PB7 GPIO_ACTIVE_HIGH>;
+ function = LED_FUNCTION_HEARTBEAT;
+ color = ;
+ linux,default-trigger = "heartbeat";
+ pinctrl-names = "default";
+ pinctrl-0 = <&led_work_pin>;
+ };
+ };
+
+ rk809-sound {
+ compatible = "simple-audio-card";
+ pinctrl-names = "default";
+ pinctrl-0 = <&hp_det_pin>;
+ simple-audio-card,name = "Analog RK817";
+ simple-audio-card,format = "i2s";
+ simple-audio-card,hp-det-gpio = <
Re: [PATCH] arm64: dts: rockchip: rk3568: Add ODROID-M1 board support
On 2023-07-05 18:24, Jonas Karlman wrote: > Hi Stefan, > On 2023-07-05 18:16, Stefan Agner wrote: >> Add ODROID-M1 board support. Board device tree rk3568-odroid-m1.dts >> from v6.4. > > I sent out a series that add support for ODROID-M1 a few days ago. > Please see https://patchwork.ozlabs.org/project/uboot/list/?series=362045 Cool, thanks for the hint! I've checked master branch but not the ML :) -- Stefan > > Regards, > Jonas > >> >> Signed-off-by: Stefan Agner >> --- >> arch/arm/dts/Makefile | 1 + >> arch/arm/dts/rk3568-odroid-m1-u-boot.dtsi | 29 + >> arch/arm/dts/rk3568-odroid-m1.dts | 744 ++ >> configs/odroid-m1_defconfig | 84 +++ >> 4 files changed, 858 insertions(+) >> create mode 100644 arch/arm/dts/rk3568-odroid-m1-u-boot.dtsi >> create mode 100644 arch/arm/dts/rk3568-odroid-m1.dts >> create mode 100644 configs/odroid-m1_defconfig >> > > [...]
Re: [PATCH 2/2] board: rockchip: Add Hardkernel ODROID-M1
On 2023-07-02 22:47, Jonas Karlman wrote:
> Hardkernel ODROID-M1 is a single board computer with a RK3568B2 SoC,
> a slightly modified version of the RK3568 SoC.
>
> Features tested on a ODROID-M1 8GB v1.0 2022-06-13:
> - SD-card boot
> - eMMC boot
> - SPI Flash boot
> - PCIe/NVMe/AHCI
> - SATA port
> - USB host
>
> Device tree is imported from linux v6.4.
>
> Signed-off-by: Jonas Karlman
Thanks for you patch! I've compared it to my version, and did not notice
any downside/anything missing. If anything, your version is more feature
complete. I've also tested it on an ODORID-M1 with 8GB of memory, it
boots fine from SD card.
Reviewed-by: Stefan Agner
Tested-by: Stefan Agner
One thing I've noticed is that USB isn't working when I use the stock
SPL (2017.09) running from the SPI RAM and upstream U-Boot (by writing
u-boot.itb to a raw GPT partition named "uboot" to the SD-card). That is
the same in my patchset. If the upstream SPL is used, things work. It
seems that something is not (re)initialized in U-Boot. Not sure if we
typically rely on the state the SPL leaves the HW at, but it would be
nice if we are able to make that combination work. This allows to boot
an upstream U-Boot from an SD-card without having to reflash the onboard
SPI.
On a different note: Do you know if PCIe/NVMe support in SPL is
something which is in the cards for this board?
--
Stefan
> ---
> arch/arm/dts/Makefile | 1 +
> arch/arm/dts/rk3568-odroid-m1-u-boot.dtsi | 46 ++
> arch/arm/dts/rk3568-odroid-m1.dts | 744 ++
> board/rockchip/evb_rk3568/MAINTAINERS | 7 +
> configs/odroid-m1-rk3568_defconfig| 103 +++
> doc/board/rockchip/rockchip.rst | 1 +
> 6 files changed, 902 insertions(+)
> create mode 100644 arch/arm/dts/rk3568-odroid-m1-u-boot.dtsi
> create mode 100644 arch/arm/dts/rk3568-odroid-m1.dts
> create mode 100644 configs/odroid-m1-rk3568_defconfig
>
> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> index 480269fa6065..334c1bafda17 100644
> --- a/arch/arm/dts/Makefile
> +++ b/arch/arm/dts/Makefile
> @@ -169,6 +169,7 @@ dtb-$(CONFIG_ROCKCHIP_RK3568) += \
> rk3566-anbernic-rgxx3.dtb \
> rk3566-radxa-cm3-io.dtb \
> rk3568-evb.dtb \
> + rk3568-odroid-m1.dtb \
> rk3568-rock-3a.dtb
>
> dtb-$(CONFIG_ROCKCHIP_RK3588) += \
> diff --git a/arch/arm/dts/rk3568-odroid-m1-u-boot.dtsi
> b/arch/arm/dts/rk3568-odroid-m1-u-boot.dtsi
> new file mode 100644
> index ..dc8ad98715ce
> --- /dev/null
> +++ b/arch/arm/dts/rk3568-odroid-m1-u-boot.dtsi
> @@ -0,0 +1,46 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +
> +#include "rk356x-u-boot.dtsi"
> +
> +/ {
> + aliases {
> + spi0 = &sfc;
> + };
> +
> + chosen {
> + stdout-path = &uart2;
> + };
> +};
> +
> +&fspi_dual_io_pins {
> + bootph-all;
> +};
> +
> +&sdhci {
> + cap-mmc-highspeed;
> + mmc-ddr-1_8v;
> + mmc-hs200-1_8v;
> + mmc-hs400-1_8v;
> + mmc-hs400-enhanced-strobe;
> + pinctrl-0 = <&emmc_bus8 &emmc_clk &emmc_cmd &emmc_datastrobe>;
> +};
> +
> +&sfc {
> + bootph-pre-ram;
> + u-boot,spl-sfc-no-dma;
> +
> + flash@0 {
> + bootph-pre-ram;
> + };
> +};
> +
> +&uart2 {
> + bootph-all;
> + clock-frequency = <2400>;
> + status = "okay";
> +};
> +
> +&vcc5v0_usb_host {
> + /* Workaround until regulator implement basic reference counter */
> + regulator-always-on;
> +};
> diff --git a/arch/arm/dts/rk3568-odroid-m1.dts
> b/arch/arm/dts/rk3568-odroid-m1.dts
> new file mode 100644
> index ..59ecf868dbd0
> --- /dev/null
> +++ b/arch/arm/dts/rk3568-odroid-m1.dts
> @@ -0,0 +1,744 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +/*
> + * Copyright (c) 2022 Hardkernel Co., Ltd.
> + *
> + */
> +
> +/dts-v1/;
> +#include
> +#include
> +#include
> +#include
> +#include "rk3568.dtsi"
> +
> +/ {
> + model = "Hardkernel ODROID-M1";
> + compatible = "rockchip,rk3568-odroid-m1", "rockchip,rk3568";
> +
> + aliases {
> + ethernet0 = &gmac0;
> + i2c0 = &i2c3;
> + i2c3 = &i2c0;
> + mmc0 = &sdhci;
> + mmc1 = &sdmmc0;
> + serial0 = &uart1;
> + serial1 = &uart0;
> + };
> +
> + chosen {
> + stdout-path = "serial2:150n8";
>
Re: [PATCH 2/2] board: rockchip: Add Hardkernel ODROID-M1
On 2023-07-06 07:08, Jonas Karlman wrote: > On 2023-07-06 01:27, Stefan Agner wrote: >> On 2023-07-02 22:47, Jonas Karlman wrote: >>> Hardkernel ODROID-M1 is a single board computer with a RK3568B2 SoC, >>> a slightly modified version of the RK3568 SoC. >>> >>> Features tested on a ODROID-M1 8GB v1.0 2022-06-13: >>> - SD-card boot >>> - eMMC boot >>> - SPI Flash boot >>> - PCIe/NVMe/AHCI >>> - SATA port >>> - USB host >>> >>> Device tree is imported from linux v6.4. >>> >>> Signed-off-by: Jonas Karlman >> >> Thanks for you patch! I've compared it to my version, and did not notice >> any downside/anything missing. If anything, your version is more feature >> complete. I've also tested it on an ODORID-M1 with 8GB of memory, it >> boots fine from SD card. >> >> Reviewed-by: Stefan Agner >> Tested-by: Stefan Agner > > Thanks for review and testing! > >> >> One thing I've noticed is that USB isn't working when I use the stock >> SPL (2017.09) running from the SPI RAM and upstream U-Boot (by writing >> u-boot.itb to a raw GPT partition named "uboot" to the SD-card). That is >> the same in my patchset. If the upstream SPL is used, things work. It >> seems that something is not (re)initialized in U-Boot. Not sure if we >> typically rely on the state the SPL leaves the HW at, but it would be >> nice if we are able to make that combination work. This allows to boot >> an upstream U-Boot from an SD-card without having to reflash the onboard >> SPI. > > Trying to use a combo of vendor u-boot SPL and mainline U-Boot proper is > not something I have tested or something I would recommend anyone to use. > To make use of all features one should press the "SPI recovery switch" > during boot or erase/replace U-Boot in SPI flash. Yeah I understand that this is the correct way of doing things. For Home Assistant OS we try to build an easy to use image which can be flashed to the SD card/eMMC and then booted directly. Unfortunately, the board doesn't allow to boot straight from eMMC/SD card. I'd prefer if we don't have to touch the SPI flash to avoid complexity and allow users to easily switch back to whatever the vendor offers. In a way, this is similar to how things work on x86-64, to leave the BIOS (in this case SPL on SPI flash) up to the hardware vendor. I understand that this gets into out-of-scope/unsupported territory. I posing the question opportunistically: Since you worked with the platform quite a bit maybe you have a good guess/idea what could be the culprit. > > Does this USB issue only affect U-Boot proper or also leave USB unusable > in linux? Booting OS from USB3 have been a little bit random when I have > tested, some of my USB3 devices work if plugged in from cold start > others needs to be removed and plugged in again for U-Boot to recognize > them. USB2 ports have been much more stable during my testing. USB is usable on Linux, so this is just U-Boot. I've tested with a USB 2.0 flash drive. > >> >> On a different note: Do you know if PCIe/NVMe support in SPL is >> something which is in the cards for this board? > > As mentioned in the cover-letter this series has some dependencies for > all features enabled in defconfig to work, most notably PCIe/NVMe. > > You can use my rk3568-2023.07-rc6 branch at [1] that have all > dependencies included or test with an artifact from my github actions > test build workflow at [2]. > > Or do you mean SPL to load FIT (U-Boot proper and TF-A) from NVMe? Yes, I meant using the SPL to load the U-Boot FIT image from NVMe. -- Stefan > > [1] https://github.com/Kwiboo/u-boot-rockchip/commits/rk3568-2023.07-rc6 > [2] https://github.com/Kwiboo/u-boot-build/actions/runs/5448465108 > > Regards, > Jonas > >> >> -- >> Stefan >> >>> --- >>> arch/arm/dts/Makefile | 1 + >>> arch/arm/dts/rk3568-odroid-m1-u-boot.dtsi | 46 ++ >>> arch/arm/dts/rk3568-odroid-m1.dts | 744 ++ >>> board/rockchip/evb_rk3568/MAINTAINERS | 7 + >>> configs/odroid-m1-rk3568_defconfig| 103 +++ >>> doc/board/rockchip/rockchip.rst | 1 + >>> 6 files changed, 902 insertions(+) >>> create mode 100644 arch/arm/dts/rk3568-odroid-m1-u-boot.dtsi >>> create mode 100644 arch/arm/dts/rk3568-odroid-m1.dts >>> create mode 100644 configs/odroid-m1-rk3568_defconfig >>>[...]
Re: [PATCH] lzma: Fix decompression speed regression
Hi Simon,
Hi Christophe,
On 7/6/23 17:57, Simon Glass wrote:
On Wed, 5 Jul 2023 at 09:54, Christophe Leroy
wrote:
Uncompressing a 1.7Mbytes FIT image on U-boot 2023.04 takes
approx 7s on a powerpc 8xx.
The same on U-boot 2023.07-rc6 takes approx 28s unless watchdog
is disabled.
During that decompression, LzmaDec_DecodeReal() calls schedule
1.6 million times, that is every 4µs in average.
In the past it used to be a call to WATCHDOG_RESET() which was
just calling hw_watchdog_reset().
But the combination of commit 29caf9305b6 ("cyclic: Use schedule()
instead of WATCHDOG_RESET()") and commit 26e8ebcd7cb ("watchdog:
mpc8xxx: Make it generic") results in an heavier processing.
However, there is absolutely no point in calling schedule() that
often.
By moving and keeping only one call to schedule() in the main
loop the number of calls is reduced to 1.2 million which is still
too much. So add logic to only call schedule every 1024 times.
That leads to a call to schedule approx every 6ms which is still
far enough to entertain the watchdog which has a 1s timeout on
powerpc 8xx.
powerpc 8xx being one of the slowest targets we have today in
U-boot, and most other watchdogs having a timeout of one minutes
instead of one second like the 8xx, this fix should not have
negative impact on other targets.
Fixes: 29caf9305b6 ("cyclic: Use schedule() instead of WATCHDOG_RESET()")
Signed-off-by: Christophe Leroy
---
lib/lzma/LzmaDec.c | 18 --
1 file changed, 4 insertions(+), 14 deletions(-)
Reviewed-by: Simon Glass
+Stefan Roese I wonder if we need a more general fix?
IIRC, we already have some code in the watchdog IF making sure, that the
WDT reset is not called too often. I need to re-check here. And yes, we
should probably either move this code to the common schedule() function
or add it here. Best by adding a new Kconfig option, configuring the max
schedule frequency, e.g. 1000 Hz.
Thanks,
Stefan
Re: [PATCH] lzma: Fix decompression speed regression
Hi Christophe,
On 7/7/23 11:27, Christophe Leroy wrote:
Le 07/07/2023 à 11:09, Stefan Roese a écrit :
[Vous ne recevez pas souvent de courriers de s...@denx.de. Découvrez
pourquoi ceci est important à
https://aka.ms/LearnAboutSenderIdentification ]
Hi Simon,
Hi Christophe,
On 7/6/23 17:57, Simon Glass wrote:
On Wed, 5 Jul 2023 at 09:54, Christophe Leroy
wrote:
Uncompressing a 1.7Mbytes FIT image on U-boot 2023.04 takes
approx 7s on a powerpc 8xx.
The same on U-boot 2023.07-rc6 takes approx 28s unless watchdog
is disabled.
During that decompression, LzmaDec_DecodeReal() calls schedule
1.6 million times, that is every 4µs in average.
In the past it used to be a call to WATCHDOG_RESET() which was
just calling hw_watchdog_reset().
But the combination of commit 29caf9305b6 ("cyclic: Use schedule()
instead of WATCHDOG_RESET()") and commit 26e8ebcd7cb ("watchdog:
mpc8xxx: Make it generic") results in an heavier processing.
However, there is absolutely no point in calling schedule() that
often.
By moving and keeping only one call to schedule() in the main
loop the number of calls is reduced to 1.2 million which is still
too much. So add logic to only call schedule every 1024 times.
That leads to a call to schedule approx every 6ms which is still
far enough to entertain the watchdog which has a 1s timeout on
powerpc 8xx.
powerpc 8xx being one of the slowest targets we have today in
U-boot, and most other watchdogs having a timeout of one minutes
instead of one second like the 8xx, this fix should not have
negative impact on other targets.
Fixes: 29caf9305b6 ("cyclic: Use schedule() instead of
WATCHDOG_RESET()")
Signed-off-by: Christophe Leroy
---
lib/lzma/LzmaDec.c | 18 --
1 file changed, 4 insertions(+), 14 deletions(-)
Reviewed-by: Simon Glass
+Stefan Roese I wonder if we need a more general fix?
IIRC, we already have some code in the watchdog IF making sure, that the
WDT reset is not called too often. I need to re-check here. And yes, we
should probably either move this code to the common schedule() function
or add it here. Best by adding a new Kconfig option, configuring the max
schedule frequency, e.g. 1000 Hz.
Yes we may add a ratelimitation inside schedule() but if we only do that
it will only be a plaster. It will still use a huge amount of CPU just
for reading the time and checking the limit.
A caller shouldn't call schedule() million of times per second, I think
the root cause need to be fixed anyway. LZMA has this problem, ZLIB has
not. I didn't check other decompressors.
Agreed. We should do both, change schedule() and also fix the high
frequent callers.
The best would be that schedule() throw a WARN_ONCE() when that happens
so that we can identify frantic callers.
Good idea. Let me see if I can come up with such a patch. Will take a
few days though as I'm traveling the next few days.
Thanks,
Stefan
Re: [PATCH u-boot 0/3] Revert broken Bootmenu commits
On 7/10/23 17:17, Tom Rini wrote: On Mon, Jul 10, 2023 at 04:10:39PM +0200, Pali Rohár wrote: On Sunday 25 June 2023 21:08:19 Tom Rini wrote: On Sun, Jun 25, 2023 at 05:15:34PM +0200, Pali Rohár wrote: On Sunday 25 June 2023 10:52:13 Tom Rini wrote: On Sun, Jun 25, 2023 at 09:50:39AM +0200, Pali Rohár wrote: On Saturday 24 June 2023 12:58:07 Tom Rini wrote: On Sat, Jun 24, 2023 at 10:50:41AM +0200, Pali Rohár wrote: On Tuesday 20 June 2023 11:20:35 Simon Glass wrote: Hi Tom, Pali, On Wed, 14 Jun 2023 at 20:51, Tom Rini wrote: On Sun, Jun 11, 2023 at 02:53:21PM +0200, Pali Rohár wrote: These 3 commits broke support for U-Boot Bootmenu on Nokia N900. Issues were reported more than month ago, but nobody reacted to them. So revert these broken commits for now, to fix U-Boot Bootmenu support. With these revered commits, U-Boot Bootmenu from master branch is working fine again on Nokia N900. Pali Rohár (3): Revert "video: Enable VIDEO_ANSI by default only with EFI" Revert "menu: Factor out menu-keypress decoding" Revert "menu: Make use of CLI character processing" cmd/bootmenu.c| 9 ++-- cmd/eficonfig.c | 12 ++--- common/cli_getch.c| 12 ++--- common/menu.c | 122 ++ drivers/video/Kconfig | 7 +-- include/cli.h | 4 +- include/menu.h| 17 +- 7 files changed, 91 insertions(+), 92 deletions(-) Following up over here, while https://patchwork.ozlabs.org/project/uboot/patch/20230612201434.861700-1-...@chromium.org/ addresses some of the issues, but not all (as it clearly isn't working in all of the cases Pali has explained), looking in to the VIDEO_ANSI part of this too, all three of these reverts are related seemingly to something escape-character related. I'm not taking any of the revert commits in just yet, but will by the next -rc if we don't have something that fixes all of the issues. I did send a series [1] with a fix for the nokia_rx51 keyboard driver, including the previous ansi-code patch. Given that: - this problem doesn't seem to manifest on other boards - it does not cause any CI test to fail - there seem to be bugs in the nokia_rx51 implementation which are a possible/likely cause - the nokia_rx51 CI uses a 10-year-old out-of-tree QEMU - the problem goes away if debugging is added, suggesting it is related to timing ...I don't think a revert is appropriate. Unfortunately it does not fix this issue :-( New patch series from [1] applied on top of the master branch has still issue with DOWN key on emulated UART terminal. Pali, can you please take a look and see if you can debug what is actually going on? Here is my guess: 1. When an arrow key is pressed, cli_ch_process() handles it by being passed the codes in sequence: \e [ B 2. Calling cli_ch_process() with ichar = 0 causes it to think the sequence is finished: \e [ \0 B (this doesn't work since the \0 ends the sequence) 3. nokia_rx51 keyboard driver is returning '\0' even when key codes are pending, causing cli_ch_process() to be told that the sequence is done I can look at it later, but I'm loosing motivation to do whole debugging for another issue again, because for the last year my fixes and other patches were stalled and u-boot devs show me that they are not interested even in commenting them. I do not want to work again on something which would be ignored. Well, unless your changes here break something else, I don't think a fix for your problem will be ignored. This is something which I read here more times in the past... and reality was different. Should I remind you that there are waiting eMMC fixes for mvebu and again discussion about them stalled? Or rather should I say that it is again ignored? No, you should just say they're still waiting for review. Since they're waiting for review. The MMC custodian has been asked to review them, and hasn't yet. And they don't appear to be super critical changes, and they conflict with other series, so yes, they'll get picked up when the custodian has time to review everything. And what is "critical change" if it is not fixing booting (from eMMC)? The when and where, and since when. Since re-reading everything in https://patchwork.ozlabs.org/project/uboot/list/?submitter=78810 that's not this revert series doesn't say "fix booting on $platform that was broken by ...". It says clean up. Clean up can wait. "Fix eMMC boot" - This is not clear that it is a "fix"??? Or are you again going to play a game "I do not see your patches"? Ok, then here is direct link: https://lore.kernel.org/u-boot/20230413205750.10641-1-p...@kernel.org/ Oh, oh, I think I get it now. You're wondering why I guess: https://patchwork.ozlabs.org/project/uboot/patch/20230505193710.n35h2ofq6fogk4bq@pal
Re: [PATCH v2 1/6] arm: mvebu: ac5: Add nand-controller node
On 7/10/23 00:47, Chris Packham wrote:
The AC5/AC5X SoC has a NAND flash controller. Add this to the
SoC device tree.
Signed-off-by: Chris Packham
Reviewed-by: Stefan Roese
Thanks,
Stefan
---
arch/arm/dts/ac5-98dx25xx.dtsi | 9 +
1 file changed, 9 insertions(+)
diff --git a/arch/arm/dts/ac5-98dx25xx.dtsi b/arch/arm/dts/ac5-98dx25xx.dtsi
index 3c68355f323a..f53b4781d7fd 100644
--- a/arch/arm/dts/ac5-98dx25xx.dtsi
+++ b/arch/arm/dts/ac5-98dx25xx.dtsi
@@ -251,6 +251,15 @@
status = "disabled";
};
+ nand: nand-controller@805b {
+ compatible = "marvell,mvebu-ac5-pxa3xx-nand";
+ reg = <0x0 0x805b 0x0 0x54>;
+ #address-cells = <0x0001>;
+ marvell,nand-enable-arbiter;
+ num-cs = <0x0001>;
+ status = "disabled";
+ };
+
gic: interrupt-controller@8060 {
compatible = "arm,gic-v3";
#interrupt-cells = <3>;
Viele Grüße,
Stefan Roese
--
DENX Software Engineering GmbH, Managing Director: Erika Unter
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de
Re: [PATCH v2 2/6] arm: mvebu: ac5: Define mvebu_get_nand_clock()
On 7/10/23 00:47, Chris Packham wrote:
The NF_CLK for the AC5 SoC runs at 400MHz. There's no strapping
or gating require so just add a mvebu_get_nand_clock() that
returns this value.
Signed-off-by: Chris Packham
Reviewed-by: Stefan Roese
Thanks,
Stefan
---
arch/arm/mach-mvebu/alleycat5/soc.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/mach-mvebu/alleycat5/soc.c
b/arch/arm/mach-mvebu/alleycat5/soc.c
index dc69f46eedb2..734b0a87dd49 100644
--- a/arch/arm/mach-mvebu/alleycat5/soc.c
+++ b/arch/arm/mach-mvebu/alleycat5/soc.c
@@ -255,6 +255,12 @@ void soc_print_clock_info(void)
printf("\tMSS %4d MHz\n", 200);
}
+/* Return NAND clock in Hz */
+u32 mvebu_get_nand_clock(void)
+{
+ return 400 * 100;
+}
+
/*
* Override of __weak int mach_cpu_init(void) :
* SoC/machine dependent CPU setup
Viele Grüße,
Stefan Roese
--
DENX Software Engineering GmbH, Managing Director: Erika Unter
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de
Re: [PATCH v2 3/6] mtd: nand: pxa3xx: Add support for the Marvell AC5 SoC
On 7/10/23 00:47, Chris Packham wrote:
The NAND flash controller (NFC) on the AC5/AC5X SoC is the same as
the NFC used on other Marvell SoCs. It does have the additional
restriction of only supporting SDR timing modes up to 3.
Signed-off-by: Chris Packham
Reviewed-by: Stefan Roese
Thanks,
Stefan
---
drivers/mtd/nand/raw/pxa3xx_nand.c | 17 ++---
1 file changed, 14 insertions(+), 3 deletions(-)
diff --git a/drivers/mtd/nand/raw/pxa3xx_nand.c
b/drivers/mtd/nand/raw/pxa3xx_nand.c
index fcd1b9c63614..9dee580ab9c2 100644
--- a/drivers/mtd/nand/raw/pxa3xx_nand.c
+++ b/drivers/mtd/nand/raw/pxa3xx_nand.c
@@ -167,6 +167,7 @@ enum pxa3xx_nand_variant {
PXA3XX_NAND_VARIANT_PXA,
PXA3XX_NAND_VARIANT_ARMADA370,
PXA3XX_NAND_VARIANT_ARMADA_8K,
+ PXA3XX_NAND_VARIANT_AC5,
};
struct pxa3xx_nand_host {
@@ -391,6 +392,10 @@ static const struct udevice_id pxa3xx_nand_dt_ids[] = {
.compatible = "marvell,armada-8k-nand-controller",
.data = PXA3XX_NAND_VARIANT_ARMADA_8K,
},
+ {
+ .compatible = "marvell,mvebu-ac5-pxa3xx-nand",
+ .data = PXA3XX_NAND_VARIANT_AC5,
+ },
{}
};
@@ -505,6 +510,9 @@ static int pxa3xx_nand_init_timings(struct pxa3xx_nand_host *host)
if (mode < 0)
mode = 0;
+ if (info->variant == PXA3XX_NAND_VARIANT_AC5)
+ mode = min(mode, 3);
+
timings = onfi_async_timing_mode_to_sdr_timings(mode);
if (IS_ERR(timings))
return PTR_ERR(timings);
@@ -730,7 +738,8 @@ static irqreturn_t pxa3xx_nand_irq(struct pxa3xx_nand_info
*info)
/* NDCB3 register is available in NFCv2 (Armada 370/XP SoC) */
if (info->variant == PXA3XX_NAND_VARIANT_ARMADA370 ||
- info->variant == PXA3XX_NAND_VARIANT_ARMADA_8K)
+ info->variant == PXA3XX_NAND_VARIANT_ARMADA_8K ||
+ info->variant == PXA3XX_NAND_VARIANT_AC5)
nand_writel(info, NDCB0, info->ndcb3);
}
@@ -1579,7 +1588,8 @@ static int pxa3xx_nand_scan(struct mtd_info *mtd)
/* Device detection must be done with ECC disabled */
if (info->variant == PXA3XX_NAND_VARIANT_ARMADA370 ||
- info->variant == PXA3XX_NAND_VARIANT_ARMADA_8K)
+ info->variant == PXA3XX_NAND_VARIANT_ARMADA_8K ||
+ info->variant == PXA3XX_NAND_VARIANT_AC5)
nand_writel(info, NDECCCTRL, 0x0);
if (nand_scan_ident(mtd, 1, NULL))
@@ -1630,7 +1640,8 @@ static int pxa3xx_nand_scan(struct mtd_info *mtd)
*/
if (mtd->writesize > info->chunk_size) {
if (info->variant == PXA3XX_NAND_VARIANT_ARMADA370 ||
- info->variant == PXA3XX_NAND_VARIANT_ARMADA_8K) {
+ info->variant == PXA3XX_NAND_VARIANT_ARMADA_8K ||
+ info->variant == PXA3XX_NAND_VARIANT_AC5) {
chip->cmdfunc = nand_cmdfunc_extended;
} else {
dev_err(mtd->dev,
Viele Grüße,
Stefan Roese
--
DENX Software Engineering GmbH, Managing Director: Erika Unter
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de
Re: [PATCH v2 4/6] mtd: nand: pxa3xx: Enable devbus/nand arbiter on Armada 8K
On 7/10/23 00:47, Chris Packham wrote:
The CN9130 SoC (an ARMADA 8K type) has both a NAND Flash Controller and
a generic local bus controller (Device Bus Controller) that share common
pins.
With a board design that incorporates both a NAND flash and uses
the Device Bus (in our case for an SRAM) accessing the Device Bus device
fails unless the NfArbiterEn bit is set. Setting the bit enables
arbitration between the Device Bus and the NAND flash.
Since there is no obvious downside in enabling this for designs that
don't require arbitration, we always enable it.
Signed-off-by: Chris Packham
Reviewed-by: Stefan Roese
Thanks,
Stefan
---
drivers/mtd/nand/raw/pxa3xx_nand.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/mtd/nand/raw/pxa3xx_nand.c
b/drivers/mtd/nand/raw/pxa3xx_nand.c
index 9dee580ab9c2..d502e967f92c 100644
--- a/drivers/mtd/nand/raw/pxa3xx_nand.c
+++ b/drivers/mtd/nand/raw/pxa3xx_nand.c
@@ -125,6 +125,7 @@ DECLARE_GLOBAL_DATA_PTR;
/* System control register and bit to enable NAND on some SoCs */
#define GENCONF_SOC_DEVICE_MUX0x208
#define GENCONF_SOC_DEVICE_MUX_NFC_EN BIT(0)
+#define GENCONF_SOC_DEVICE_MUX_NFC_DEVBUS_ARB_EN BIT(27)
/*
* This should be large enough to read 'ONFI' and 'JEDEC'.
@@ -1739,7 +1740,7 @@ static int alloc_nand_resource(struct udevice *dev,
struct pxa3xx_nand_info *inf
return PTR_ERR(sysctrl_base);
regmap_read(sysctrl_base, GENCONF_SOC_DEVICE_MUX, ®);
- reg |= GENCONF_SOC_DEVICE_MUX_NFC_EN;
+ reg |= GENCONF_SOC_DEVICE_MUX_NFC_EN |
GENCONF_SOC_DEVICE_MUX_NFC_DEVBUS_ARB_EN;
regmap_write(sysctrl_base, GENCONF_SOC_DEVICE_MUX, reg);
}
Viele Grüße,
Stefan Roese
--
DENX Software Engineering GmbH, Managing Director: Erika Unter
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de
Re: [PATCH v2 5/6] arm: mvebu: Add Allied Telesis x240 board
On 7/10/23 00:47, Chris Packham wrote:
The x240 and SE240 are a series of L2+ switches from Allied Telesis.
There are a number of them in the range but as far as U-Boot is
concerned all the CPU block components are the same so there's only one
board defined.
Signed-off-by: Chris Packham
Reviewed-by: Stefan Roese
Thanks,
Stefan
---
Notes:
Changes in v2:
- drop CONFIG_DEBUG_UART
arch/arm/dts/Makefile | 3 +-
arch/arm/dts/ac5-98dx35xx-atl-x240.dts | 212 +
arch/arm/mach-mvebu/Kconfig| 7 +
board/alliedtelesis/x240/MAINTAINERS | 7 +
board/alliedtelesis/x240/Makefile | 6 +
board/alliedtelesis/x240/x240.c| 13 ++
configs/x240_defconfig | 86 ++
include/configs/x240.h | 37 +
8 files changed, 370 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/dts/ac5-98dx35xx-atl-x240.dts
create mode 100644 board/alliedtelesis/x240/MAINTAINERS
create mode 100644 board/alliedtelesis/x240/Makefile
create mode 100644 board/alliedtelesis/x240/x240.c
create mode 100644 configs/x240_defconfig
create mode 100644 include/configs/x240.h
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 480269fa6065..38d878a0f853 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -303,7 +303,8 @@ dtb-$(CONFIG_ARCH_MVEBU) += \
cn9132-db-B.dtb \
cn9130-crb-A.dtb\
cn9130-crb-B.dtb\
- ac5-98dx35xx-rd.dtb
+ ac5-98dx35xx-rd.dtb \
+ ac5-98dx35xx-atl-x240.dtb
endif
dtb-$(CONFIG_ARCH_SYNQUACER) += synquacer-sc2a11-developerbox.dtb
diff --git a/arch/arm/dts/ac5-98dx35xx-atl-x240.dts
b/arch/arm/dts/ac5-98dx35xx-atl-x240.dts
new file mode 100644
index ..820ec18b4355
--- /dev/null
+++ b/arch/arm/dts/ac5-98dx35xx-atl-x240.dts
@@ -0,0 +1,212 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+
+/dts-v1/;
+
+#include
+#include
+#include "ac5-98dx35xx.dtsi"
+
+/ {
+ model = "Allied Telesis x240";
+ compatible = "alliedtelesis,x240", "marvell,ac5x", "marvell,ac5";
+
+ aliases {
+ serial0 = &uart0;
+ spiflash0 = &spiflash0;
+ gpio0 = &gpio0;
+ gpio1 = &gpio1;
+ spi0 = &spi0;
+ i2c0 = &i2c0;
+ usb0 = &usb0;
+ pinctrl0 = &pinctrl0;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+
+ boot-board {
+ compatible = "atl,boot-board";
+ present-gpio = <&gpio1 6 GPIO_ACTIVE_HIGH>;
+ override-gpio = <&gpio1 2 GPIO_ACTIVE_HIGH>;
+ };
+
+ gpio-leds {
+ compatible = "gpio-leds";
+
+ fault {
+ label = "fault:red";
+ gpios = <&system_gpio 11 GPIO_ACTIVE_LOW>;
+ default-state = "on";
+ };
+ };
+};
+
+&nand {
+ pinctrl-names = "default";
+ pinctrl-0 = <&nand_pins>;
+
+ nand-ecc-strength = <4>;
+ nand-ecc-step-size = <512>;
+ status = "okay";
+
+ partitions {
+ compatible = "fixed-partitions";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ partition@user {
+ reg = <0x 0x1000>;
+ label = "user";
+ };
+ };
+};
+
+&uart0 {
+ status = "okay";
+};
+
+&usb0 {
+ status = "okay";
+};
+
+&i2c0 {
+ status = "okay";
+
+ mux@71 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "nxp,pca9546";
+ reg = <0x71>;
+ i2c-mux-idle-disconnect;
+ reset-gpios = <&gpio1 4 GPIO_ACTIVE_LOW>; /*
MPP36 */
+ status = "okay";
+
+ i2c@1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+
+ hwmon@2e {
+ compatible = "adi,adt7476";
+ reg = <0x2e>;
+ };
+
+ rtc@68 {
+ compatible = "adi,max31331";
+ reg = <0x68>;
+ };
+
+ system_gpio: gpio@27 {
+ compatible = "nxp
Re: [PATCH v2 6/6] arm: mvebu: Remove unused alias from RC AC5X dts
On 7/10/23 00:47, Chris Packham wrote:
The sar-reg0 alias was left over from an earlier iteration of the
patches adding support for this board. Remove the unused alias.
Fixes: 6cc8b5db40 ("arm: mvebu: Add RD-AC5X board")
Signed-off-by: Chris Packham
Reviewed-by: Stefan Roese
Thanks,
Stefan
---
arch/arm/dts/ac5-98dx35xx-rd.dts | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm/dts/ac5-98dx35xx-rd.dts b/arch/arm/dts/ac5-98dx35xx-rd.dts
index d9f217cd4a5f..1dc85bb7ef24 100644
--- a/arch/arm/dts/ac5-98dx35xx-rd.dts
+++ b/arch/arm/dts/ac5-98dx35xx-rd.dts
@@ -31,7 +31,6 @@
usb0 = &usb0;
usb1 = &usb1;
pinctrl0 = &pinctrl0;
- sar-reg0 = "/config-space/sar-reg";
};
usb1phy: usb-phy {
Viele Grüße,
Stefan Roese
--
DENX Software Engineering GmbH, Managing Director: Erika Unter
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de
Re: [PATCH] arm: mvebu: Clean up Thecus N2350 board DTS
On 6/6/23 23:45, Tony Dinh wrote:
- Update the Thecus N2350 DTS to conform with latest device-tree binding
and styles.
- Correct typo in mdio node.
Signed-off-by: Tony Dinh
Applied to u-boot-marvell/master
Thanks,
Stefan
---
arch/arm/dts/armada-385-thecus-n2350.dts | 210 +++
1 file changed, 98 insertions(+), 112 deletions(-)
diff --git a/arch/arm/dts/armada-385-thecus-n2350.dts
b/arch/arm/dts/armada-385-thecus-n2350.dts
index fc29c4d25a..2ad5158c0c 100644
--- a/arch/arm/dts/armada-385-thecus-n2350.dts
+++ b/arch/arm/dts/armada-385-thecus-n2350.dts
@@ -23,7 +23,7 @@
stdout-path = "serial0:115200n8";
};
- memory {
+ memory@0 {
device_type = "memory";
reg = <0x 0x4000>; /* 1GB */
};
@@ -37,43 +37,43 @@
};
- usb3_0_phy: usb3_0_phy {
+ usb3_0_phy: usb-phy {
compatible = "usb-nop-xceiv";
vcc-supply = <&usb3_0_power>;
+#phy-cells = <0>;
};
- usb3_1_phy: usb3_1_phy {
+ usb3_1_phy: usb-phy {
compatible = "usb-nop-xceiv";
vcc-supply = <&usb3_1_power>;
+#phy-cells = <0>;
};
- gpio-keys {
+ keys {
compatible = "gpio-keys";
- #address-cells = <1>;
- #size-cells = <0>;
pinctrl-0 = <&pmx_power_button &pmx_copy_button
&pmx_reset_button>;
pinctrl-names = "default";
- button@1 {
+ button-1 {
label = "Power Button";
linux,code = ;
gpios = <&gpio1 17 GPIO_ACTIVE_HIGH>;
};
- button@2 {
+ button-2 {
label = "Copy Button";
linux,code = ;
gpios = <&gpio1 20 GPIO_ACTIVE_HIGH>;
};
- button@3 {
+ button-3 {
label = "Reset Button";
linux,code = ;
gpios = <&gpio1 18 GPIO_ACTIVE_HIGH>;
};
};
- gpio-leds {
+ leds {
compatible = "gpio-leds";
pinctrl-0 = <&pmx_sata1_white_led
&pmx_sata1_red_led
@@ -88,142 +88,132 @@
pinctrl-names = "default";
- white_sata1 {
+ led-1 {
label = "n2350:white:sata1";
gpios = <&gpio0 20 GPIO_ACTIVE_HIGH>;
- linux,default-trigger = "ide-disk1";
};
- red_sata1 {
+ led-2 {
label = "n2350:red:sata1";
gpios = <&gpio1 14 GPIO_ACTIVE_HIGH>;
};
- white-sata2 {
+ led-3 {
label = "n2350:white:sata2";
gpios = <&gpio0 19 GPIO_ACTIVE_HIGH>;
};
- red-sata2 {
+ led-4 {
label = "n2350:red:sata2";
gpios = <&gpio1 15 GPIO_ACTIVE_HIGH>;
};
- white-sys {
+ led-5 {
label = "n2350:white:sys";
gpios = <&gpio0 14 GPIO_ACTIVE_HIGH>;
linux,default-trigger = "default-on";
};
- red-sys {
+ led-6 {
label = "n2350:red:sys";
gpios = <&gpio0 15 GPIO_ACTIVE_HIGH>;
};
- blue-pwr {
+ led-7 {
label = "n2350:blue:pwr";
gpios = <&gpio1 11 GPIO_ACTIVE_HIGH>;
};
- red-pwr {
+ led-8 {
label = "n2350:red:pwr";
gpios = <&gpio0 18 GPIO_ACTIVE_HIGH>;
};
- white-usb {
+ led-9 {
label = "n2350:white:usb";
gpios = <&gpio0 16 GPIO_ACTIVE_HIGH>;
};
- red-usb {
+ led-10 {
label = "n2350:red:usb";
gpios = <&gpio0 17 GPIO_ACTIVE_HIGH>;
};
};
- regulators {
- compatible = "simple-bus";
- #address-cells = <1>;
- #size-cells = <0>;
-
- usb3_0_power: regulator@1 {
- compatible = "regulator-fixed"
Re: [PATCH] arm: mvebu: Enable gpio-fan for Thecus N2350 board
On 6/21/23 01:20, Tony Dinh wrote:
Add gpio-fan in the DTS and enable the GPIO in board file to start the fan
during boot.
Note that this patch depends on
https://patchwork.ozlabs.org/project/uboot/patch/20230606214539.4229-1-mibo...@gmail.com/
Signed-off-by: Tony Dinh
Applied to u-boot-marvell/master
Thanks,
Stefan
---
arch/arm/dts/armada-385-thecus-n2350.dts | 15 +++
board/thecus/n2350/n2350.c | 2 +-
2 files changed, 16 insertions(+), 1 deletion(-)
diff --git a/arch/arm/dts/armada-385-thecus-n2350.dts
b/arch/arm/dts/armada-385-thecus-n2350.dts
index 2ad5158c0c..253cf01130 100644
--- a/arch/arm/dts/armada-385-thecus-n2350.dts
+++ b/arch/arm/dts/armada-385-thecus-n2350.dts
@@ -140,6 +140,16 @@
};
};
+ fan {
+ compatible = "gpio-fan";
+ gpios = <&gpio1 16 GPIO_ACTIVE_HIGH>;
+ gpio-fan,speed-map = < 0 0
+ 600 1
+ 3000 2 >;
+ pinctrl-0 = <&pmx_fan>;
+ pinctrl-names = "default";
+ };
+
usb3_0_power: v5-vbus0 {
compatible = "regulator-fixed";
regulator-name = "USB3_0_Power";
@@ -378,6 +388,11 @@
marvell,pins = "mpp17";
marvell,function = "gpio";
};
+
+ pmx_fan: pmx-fan {
+ marvell,pins = "mpp48";
+ marvell,function = "gpio";
+ };
};
&sdhci {
diff --git a/board/thecus/n2350/n2350.c b/board/thecus/n2350/n2350.c
index fd8f95f944..05b125fd7f 100644
--- a/board/thecus/n2350/n2350.c
+++ b/board/thecus/n2350/n2350.c
@@ -25,7 +25,7 @@ DECLARE_GLOBAL_DATA_PTR;
#define N2350_GPP_OUT_ENA_LOW (~(BIT(20) | BIT(21) | BIT(24)))
#define N2350_GPP_OUT_ENA_MID (~(BIT(12) | BIT(13) | BIT(16) | BIT(19) |
BIT(22)))
#define N2350_GPP_OUT_VAL_LOW (BIT(21) | BIT(24))
-#define N2350_GPP_OUT_VAL_MID (BIT(0) | BIT(12) | BIT(13))
+#define N2350_GPP_OUT_VAL_MID (BIT(0) | BIT(12) | BIT(13) | BIT(16))
#define N2350_GPP_POL_LOW 0x0
#define N2350_GPP_POL_MID 0x0
Viele Grüße,
Stefan Roese
--
DENX Software Engineering GmbH, Managing Director: Erika Unter
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de
Re: [PATCH v2 0/6] Support for AC5X NAND and AT-x240 board
On 7/10/23 00:47, Chris Packham wrote: This series adds support for the NAND flash controller on the AC5X SoC and adds support for the Allied Telesis x240 board. I've also included 2 unrelated changes. "arm: mvebu: Remove unused alias from RC AC5X dts" removes an unused alias from the dts. This was in the neighborhood of the x240 so I included it. "mtd: nand: pxa3xx: Enable devbus/nand arbiter on Armada 8K" allows using the NFC and device bus at the same time. This is needed for another board (CN9130 based) that I'll hopefully get upstream in the near future. I figured I'd include it now since I was touching the NAND driver. Chris Packham (6): arm: mvebu: ac5: Add nand-controller node arm: mvebu: ac5: Define mvebu_get_nand_clock() mtd: nand: pxa3xx: Add support for the Marvell AC5 SoC mtd: nand: pxa3xx: Enable devbus/nand arbiter on Armada 8K arm: mvebu: Add Allied Telesis x240 board arm: mvebu: Remove unused alias from RC AC5X dts Applied to u-boot-marvell/master Thanks, Stefan arch/arm/dts/Makefile | 3 +- arch/arm/dts/ac5-98dx25xx.dtsi | 9 ++ arch/arm/dts/ac5-98dx35xx-atl-x240.dts | 212 + arch/arm/dts/ac5-98dx35xx-rd.dts | 1 - arch/arm/mach-mvebu/Kconfig| 7 + arch/arm/mach-mvebu/alleycat5/soc.c| 6 + board/alliedtelesis/x240/MAINTAINERS | 7 + board/alliedtelesis/x240/Makefile | 6 + board/alliedtelesis/x240/x240.c| 13 ++ configs/x240_defconfig | 86 ++ drivers/mtd/nand/raw/pxa3xx_nand.c | 20 ++- include/configs/x240.h | 37 + 12 files changed, 401 insertions(+), 6 deletions(-) create mode 100644 arch/arm/dts/ac5-98dx35xx-atl-x240.dts create mode 100644 board/alliedtelesis/x240/MAINTAINERS create mode 100644 board/alliedtelesis/x240/Makefile create mode 100644 board/alliedtelesis/x240/x240.c create mode 100644 configs/x240_defconfig create mode 100644 include/configs/x240.h Viele Grüße, Stefan Roese -- DENX Software Engineering GmbH, Managing Director: Erika Unter HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de
Please pull u-boot-marvell/master
Hi Tom, please pull the following Marvell MVEBU related patches into master: - mvebu: Thecus: Misc enhancement and cleanup (Tony) - mvebu: Add AC5X Allied Telesis x240 board support incl NAND controller enhancements for this SoC (Chris) Here the Azure build, without any issues: https://dev.azure.com/sr0718/u-boot/_build/results?buildId=305&view=results Thanks, Stefan The following changes since commit bf5152d0108683bbaabf9d7a7988f61649fc33f4: Merge branch 'master' of https://source.denx.de/u-boot/custodians/u-boot-riscv (2023-07-12 13:10:04 -0400) are available in the Git repository at: g...@source.denx.de:u-boot/custodians/u-boot-marvell.git for you to fetch changes up to 366a863e651edfe976d28995888721e9bd403366: arm: mvebu: Remove unused alias from RC AC5X dts (2023-07-13 15:54:11 +0200) Chris Packham (6): arm: mvebu: ac5: Add nand-controller node arm: mvebu: ac5: Define mvebu_get_nand_clock() mtd: nand: pxa3xx: Add support for the Marvell AC5 SoC mtd: nand: pxa3xx: Enable devbus/nand arbiter on Armada 8K arm: mvebu: Add Allied Telesis x240 board arm: mvebu: Remove unused alias from RC AC5X dts Tony Dinh (2): arm: mvebu: Clean up Thecus N2350 board DTS arm: mvebu: Enable gpio-fan for Thecus N2350 board arch/arm/dts/Makefile| 3 +- arch/arm/dts/ac5-98dx25xx.dtsi | 9 ++ arch/arm/dts/ac5-98dx35xx-atl-x240.dts | 212 + arch/arm/dts/ac5-98dx35xx-rd.dts | 1 - arch/arm/dts/armada-385-thecus-n2350.dts | 223 --- arch/arm/mach-mvebu/Kconfig | 7 + arch/arm/mach-mvebu/alleycat5/soc.c | 6 + board/alliedtelesis/x240/MAINTAINERS | 7 + board/alliedtelesis/x240/Makefile| 6 + board/alliedtelesis/x240/x240.c | 13 ++ board/thecus/n2350/n2350.c | 2 +- configs/x240_defconfig | 86 drivers/mtd/nand/raw/pxa3xx_nand.c | 20 ++- include/configs/x240.h | 37 + 14 files changed, 514 insertions(+), 118 deletions(-) create mode 100644 arch/arm/dts/ac5-98dx35xx-atl-x240.dts create mode 100644 board/alliedtelesis/x240/MAINTAINERS create mode 100644 board/alliedtelesis/x240/Makefile create mode 100644 board/alliedtelesis/x240/x240.c create mode 100644 configs/x240_defconfig create mode 100644 include/configs/x240.h
[PATCH] cyclic: Add ratelimiting schedule() via CYCLIC_RATELIMIT_US
This patch adds the new Kconfig option CONFIG_CYCLIC_RATELIMIT_US which
defines the min allowed time after with a new call into the cyclic
infrastructure is allowed. This results in a ratelimiting of the all
functions hooked into the cyclic interface. As it's been noticed that on
some platforms, that high frequent calls to schedule() (replaced from
WATCHDOG_RESET) may lead to a performance degration.
When a high frequent calling into schedule() is detected, a warning is
logged only once to help indentify this frantic caller.
Signed-off-by: Stefan Roese
Cc: Simon Glass
Cc: Christophe Leroy
---
common/Kconfig| 11 +++
common/cyclic.c | 27 +--
include/asm-generic/global_data.h | 1 +
3 files changed, 37 insertions(+), 2 deletions(-)
diff --git a/common/Kconfig b/common/Kconfig
index 42baca20a618..0611cce301a5 100644
--- a/common/Kconfig
+++ b/common/Kconfig
@@ -601,6 +601,17 @@ config CYCLIC_MAX_CPU_TIME_US
takes longer than this duration this function will get unregistered
automatically.
+config CYCLIC_RATELIMIT_US
+ int "Sets the min time/delay in us after a new call into schedule is
done"
+ default 100
+ help
+ The min allowed time after with a new call into the cyclic
+ infrastructure is allowed. This results in a ratelimiting of the
+ all functions hooked into the cyclic interface.
+ As it's been noticed that on some platforms, that high frequent
+ calls to schedule() (replaced from WATCHDOG_RESET) may lead to a
+ performance degration.
+
endif # CYCLIC
config EVENT
diff --git a/common/cyclic.c b/common/cyclic.c
index a49bfc88f5c0..c945ae55c965 100644
--- a/common/cyclic.c
+++ b/common/cyclic.c
@@ -12,6 +12,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -109,8 +110,30 @@ void schedule(void)
* schedule() might get called very early before the cyclic IF is
* ready. Make sure to only call cyclic_run() when it's initalized.
*/
- if (gd)
- cyclic_run();
+ if (gd) {
+ uint64_t now;
+
+ /*
+* Add some ratelimiting to not call into the cyclic IF too
+* ofter. As it's been noticed that on some platforms, that
+* high frequent calls to schedule() (replaced from
+* WATCHDOG_RESET) may lead to a performance degration.
+*/
+ /* Do not reset the watchdog too often */
+ now = timer_get_us();
+ if (time_after_eq64(now, gd->cyclic_next_call)) {
+ cyclic_run();
+ gd->cyclic_next_call = now + CONFIG_CYCLIC_RATELIMIT_US;
+ } else {
+ /*
+* Throw a warning (only once) to help identifying
+* frantic callers
+*/
+ WARN_ONCE(1, "schedule() called very often, now = %lld
us next call at %lld us, dt = %lld us\n",
+ now, gd->cyclic_next_call,
+ gd->cyclic_next_call - now);
+ }
+ }
}
int cyclic_unregister_all(void)
diff --git a/include/asm-generic/global_data.h
b/include/asm-generic/global_data.h
index a1e1b9d64005..af26ae4dfc65 100644
--- a/include/asm-generic/global_data.h
+++ b/include/asm-generic/global_data.h
@@ -484,6 +484,7 @@ struct global_data {
* @cyclic_list: list of registered cyclic functions
*/
struct hlist_head cyclic_list;
+ uint64_t cyclic_next_call;
#endif
/**
* @dmtag_list: List of DM tags
--
2.41.0
Re: [PATCH u-boot 0/3] Revert broken Bootmenu commits
Hi, (added Jaehoon Chung to Cc) On 7/10/23 18:03, Stefan Roese wrote: On 7/10/23 17:17, Tom Rini wrote: On Mon, Jul 10, 2023 at 04:10:39PM +0200, Pali Rohár wrote: On Sunday 25 June 2023 21:08:19 Tom Rini wrote: On Sun, Jun 25, 2023 at 05:15:34PM +0200, Pali Rohár wrote: On Sunday 25 June 2023 10:52:13 Tom Rini wrote: On Sun, Jun 25, 2023 at 09:50:39AM +0200, Pali Rohár wrote: On Saturday 24 June 2023 12:58:07 Tom Rini wrote: On Sat, Jun 24, 2023 at 10:50:41AM +0200, Pali Rohár wrote: On Tuesday 20 June 2023 11:20:35 Simon Glass wrote: Hi Tom, Pali, On Wed, 14 Jun 2023 at 20:51, Tom Rini wrote: On Sun, Jun 11, 2023 at 02:53:21PM +0200, Pali Rohár wrote: These 3 commits broke support for U-Boot Bootmenu on Nokia N900. Issues were reported more than month ago, but nobody reacted to them. So revert these broken commits for now, to fix U-Boot Bootmenu support. With these revered commits, U-Boot Bootmenu from master branch is working fine again on Nokia N900. Pali Rohár (3): Revert "video: Enable VIDEO_ANSI by default only with EFI" Revert "menu: Factor out menu-keypress decoding" Revert "menu: Make use of CLI character processing" cmd/bootmenu.c | 9 ++-- cmd/eficonfig.c | 12 ++--- common/cli_getch.c | 12 ++--- common/menu.c | 122 ++ drivers/video/Kconfig | 7 +-- include/cli.h | 4 +- include/menu.h | 17 +- 7 files changed, 91 insertions(+), 92 deletions(-) Following up over here, while https://patchwork.ozlabs.org/project/uboot/patch/20230612201434.861700-1-...@chromium.org/ addresses some of the issues, but not all (as it clearly isn't working in all of the cases Pali has explained), looking in to the VIDEO_ANSI part of this too, all three of these reverts are related seemingly to something escape-character related. I'm not taking any of the revert commits in just yet, but will by the next -rc if we don't have something that fixes all of the issues. I did send a series [1] with a fix for the nokia_rx51 keyboard driver, including the previous ansi-code patch. Given that: - this problem doesn't seem to manifest on other boards - it does not cause any CI test to fail - there seem to be bugs in the nokia_rx51 implementation which are a possible/likely cause - the nokia_rx51 CI uses a 10-year-old out-of-tree QEMU - the problem goes away if debugging is added, suggesting it is related to timing ...I don't think a revert is appropriate. Unfortunately it does not fix this issue :-( New patch series from [1] applied on top of the master branch has still issue with DOWN key on emulated UART terminal. Pali, can you please take a look and see if you can debug what is actually going on? Here is my guess: 1. When an arrow key is pressed, cli_ch_process() handles it by being passed the codes in sequence: \e [ B 2. Calling cli_ch_process() with ichar = 0 causes it to think the sequence is finished: \e [ \0 B (this doesn't work since the \0 ends the sequence) 3. nokia_rx51 keyboard driver is returning '\0' even when key codes are pending, causing cli_ch_process() to be told that the sequence is done I can look at it later, but I'm loosing motivation to do whole debugging for another issue again, because for the last year my fixes and other patches were stalled and u-boot devs show me that they are not interested even in commenting them. I do not want to work again on something which would be ignored. Well, unless your changes here break something else, I don't think a fix for your problem will be ignored. This is something which I read here more times in the past... and reality was different. Should I remind you that there are waiting eMMC fixes for mvebu and again discussion about them stalled? Or rather should I say that it is again ignored? No, you should just say they're still waiting for review. Since they're waiting for review. The MMC custodian has been asked to review them, and hasn't yet. And they don't appear to be super critical changes, and they conflict with other series, so yes, they'll get picked up when the custodian has time to review everything. And what is "critical change" if it is not fixing booting (from eMMC)? The when and where, and since when. Since re-reading everything in https://patchwork.ozlabs.org/project/uboot/list/?submitter=78810 that's not this revert series doesn't say "fix booting on $platform that was broken by ...". It says clean up. Clean up can wait. "Fix eMMC boot" - This is not clear that it is a "fix"??? Or are you again going to play a game "I do not see your patches"? Ok, then here is direct link: https://lore.kernel.org/u-boot/20230413205750.10641-1-p...@kernel.org/ Oh, oh, I think I get it now.
Re: [PATCH] cyclic: Add ratelimiting schedule() via CYCLIC_RATELIMIT_US
Hi Simon,
On 7/13/23 22:51, Simon Glass wrote:
Hi Stefan,
On Thu, 13 Jul 2023 at 08:17, Stefan Roese wrote:
This patch adds the new Kconfig option CONFIG_CYCLIC_RATELIMIT_US which
defines the min allowed time after with a new call into the cyclic
infrastructure is allowed. This results in a ratelimiting of the all
functions hooked into the cyclic interface. As it's been noticed that on
some platforms, that high frequent calls to schedule() (replaced from
WATCHDOG_RESET) may lead to a performance degration.
When a high frequent calling into schedule() is detected, a warning is
logged only once to help indentify this frantic caller.
Signed-off-by: Stefan Roese
Cc: Simon Glass
Cc: Christophe Leroy
---
common/Kconfig| 11 +++
common/cyclic.c | 27 +--
include/asm-generic/global_data.h | 1 +
3 files changed, 37 insertions(+), 2 deletions(-)
diff --git a/common/Kconfig b/common/Kconfig
index 42baca20a618..0611cce301a5 100644
--- a/common/Kconfig
+++ b/common/Kconfig
@@ -601,6 +601,17 @@ config CYCLIC_MAX_CPU_TIME_US
takes longer than this duration this function will get unregistered
automatically.
+config CYCLIC_RATELIMIT_US
+ int "Sets the min time/delay in us after a new call into schedule is
done"
+ default 100
1000 ?
1000 was my first pick as well. Leading to this WARN_ONE warning:
schedule() called very often, now = 1085562us next call at 1086380us
This is why I switched to a less strict rate limitation as default.
Other platforms may choose to override this value if this matches their
use cases.
+ help
+ The min allowed time after with a new call into the cyclic
+ infrastructure is allowed. This results in a ratelimiting of the
rate limiting
Thanks.
+ all functions hooked into the cyclic interface.
+ As it's been noticed that on some platforms, that high frequent
+ calls to schedule() (replaced from WATCHDOG_RESET) may lead to a
+ performance degration.
degradation
also below
Thanks, will update in v2.
+
endif # CYCLIC
config EVENT
diff --git a/common/cyclic.c b/common/cyclic.c
index a49bfc88f5c0..c945ae55c965 100644
--- a/common/cyclic.c
+++ b/common/cyclic.c
@@ -12,6 +12,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -109,8 +110,30 @@ void schedule(void)
* schedule() might get called very early before the cyclic IF is
* ready. Make sure to only call cyclic_run() when it's initalized.
*/
- if (gd)
- cyclic_run();
+ if (gd) {
+ uint64_t now;
Should be u64 in here I think.
This file is already using uint64_t instead of u64. This is why I used
this type here as well.
+
+ /*
+* Add some ratelimiting to not call into the cyclic IF too
+* ofter. As it's been noticed that on some platforms, that
+* high frequent calls to schedule() (replaced from
+* WATCHDOG_RESET) may lead to a performance degration.
+*/
+ /* Do not reset the watchdog too often */
join with above comment
Ok, will do.
Thanks,
Stefan
+ now = timer_get_us();
+ if (time_after_eq64(now, gd->cyclic_next_call)) {
+ cyclic_run();
+ gd->cyclic_next_call = now + CONFIG_CYCLIC_RATELIMIT_US;
+ } else {
+ /*
+* Throw a warning (only once) to help identifying
+* frantic callers
+*/
+ WARN_ONCE(1, "schedule() called very often, now = %lld us
next call at %lld us, dt = %lld us\n",
+ now, gd->cyclic_next_call,
+ gd->cyclic_next_call - now);
+ }
+ }
}
int cyclic_unregister_all(void)
diff --git a/include/asm-generic/global_data.h
b/include/asm-generic/global_data.h
index a1e1b9d64005..af26ae4dfc65 100644
--- a/include/asm-generic/global_data.h
+++ b/include/asm-generic/global_data.h
@@ -484,6 +484,7 @@ struct global_data {
* @cyclic_list: list of registered cyclic functions
*/
struct hlist_head cyclic_list;
+ uint64_t cyclic_next_call;
#endif
/**
* @dmtag_list: List of DM tags
--
2.41.0
Regards,
Simon
Viele Grüße,
Stefan Roese
--
DENX Software Engineering GmbH, Managing Director: Erika Unter
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de
Re: [PATCH 1/5] drivers: watchdog: add mcf watchdog support
in second, driver works in msecs */
I'm a bit confused here. AFAIK, the time passed into the start()
function is in ms:
/*
* Start the timer
*
* @dev: WDT Device
* @timeout_ms: Number of ticks (milliseconds) before timer expires
* @flags: Driver specific flags. This might be used to specify
* which action needs to be executed when the timer expires
* @return: 0 if OK, -ve on error
*/
int wdt_start(struct udevice *dev, u64 timeout_ms, ulong flags);
So there should be no need to convert to ms here in this
function. Please double-check here again.
Thanks,
Stefan
+ mcf_watchdog_init(priv->base, priv->fixed_divider,
+ timeout * 1000);
+
+ return 0;
+}
+
+static int mcf_wdt_stop(struct udevice *dev)
+{
+ struct mcf_wdt_priv *priv = dev_get_priv(dev);
+ struct watchdog_regs *wdog = (struct watchdog_regs *)priv->base;
+
+ setbits_be16(&wdog->wcr, WCR_HALTED);
+
+ return 0;
+}
+
+static int mcf_wdt_probe(struct udevice *dev)
+{
+ struct mcf_wdt_priv *priv = dev_get_priv(dev);
+
+ priv->base = dev_read_addr_ptr(dev);
+ if (!priv->base)
+ return -ENOENT;
+
+ priv->fixed_divider = (u32)dev_get_driver_data(dev);
+
+ return 0;
+}
+
+static const struct wdt_ops mcf_wdt_ops = {
+ .start = mcf_wdt_start,
+ .stop = mcf_wdt_stop,
+ .reset = mcf_wdt_reset,
+ .expire_now = mcf_wdt_expire_now,
+};
+
+static const struct udevice_id mcf_wdt_ids[] = {
+ { .compatible = "fsl,mcf5208-wdt", .data = DIVIDER_5XXX },
+ { .compatible = "fsl,mcf5282-wdt", .data = DIVIDER_5282 },
+ {}
+};
+
+U_BOOT_DRIVER(mcf_wdt) = {
+ .name = "mcf_wdt",
+ .id = UCLASS_WDT,
+ .of_match = mcf_wdt_ids,
+ .probe = mcf_wdt_probe,
+ .ops= &mcf_wdt_ops,
+ .priv_auto = sizeof(struct mcf_wdt_priv),
+ .flags = DM_FLAG_PRE_RELOC,
+};
+#endif
+#endif
Re: [PATCH 2/5] m68k: move watchdog functions in mcf_wdt driver
On 6/25/23 21:35, Angelo Dureghello wrote:
Move watchdog functions inside a separate watchdog driver.
Signed-off-by: Angelo Dureghello
---
arch/m68k/cpu/mcf523x/cpu.c | 42 -
arch/m68k/cpu/mcf52x2/cpu.c | 47 +
arch/m68k/cpu/mcf532x/cpu.c | 44 --
3 files changed, 1 insertion(+), 132 deletions(-)
Now this is a nice diff-stat. Thanks for cleaning this up and moving
all this stuff into the watchdog driver. And again, please double-check,
if the hw_foo stuff (now in the wdt driver) can be completely removed.
Reviewed-by: Stefan Roese
Thanks,
Stefan
diff --git a/arch/m68k/cpu/mcf523x/cpu.c b/arch/m68k/cpu/mcf523x/cpu.c
index ba2c228911..bef67767b4 100644
--- a/arch/m68k/cpu/mcf523x/cpu.c
+++ b/arch/m68k/cpu/mcf523x/cpu.c
@@ -12,7 +12,6 @@
#include
#include
#include
-#include
#include
#include
#include
@@ -62,47 +61,6 @@ int print_cpuinfo(void)
};
#endif /* CONFIG_DISPLAY_CPUINFO */
-#if defined(CONFIG_WATCHDOG)
-/* Called by macro WATCHDOG_RESET */
-void watchdog_reset(void)
-{
- wdog_t *wdp = (wdog_t *) (MMAP_WDOG);
-
- /* Count register */
- out_be16(&wdp->sr, 0x);
- asm("nop");
- out_be16(&wdp->sr, 0x);
-}
-
-int watchdog_disable(void)
-{
- wdog_t *wdp = (wdog_t *) (MMAP_WDOG);
-
- /* UserManual, once the wdog is disabled, wdog cannot be re-enabled */
- /* halted watchdog timer */
- setbits_be16(&wdp->cr, WTM_WCR_HALTED);
-
- puts("WATCHDOG:disabled\n");
- return (0);
-}
-
-int watchdog_init(void)
-{
- wdog_t *wdp = (wdog_t *) (MMAP_WDOG);
- u32 wdog_module = 0;
-
- /* set timeout and enable watchdog */
- wdog_module = ((CFG_SYS_CLK / CONFIG_SYS_HZ) *
CONFIG_WATCHDOG_TIMEOUT_MSECS);
- wdog_module |= (wdog_module / 8192);
- out_be16(&wdp->mr, wdog_module);
-
- out_be16(&wdp->cr, WTM_WCR_EN);
- puts("WATCHDOG:enabled\n");
-
- return (0);
-}
-#endif /* CONFIG_WATCHDOG */
-
#if defined(CONFIG_MCFFEC)
/* Default initializations for MCFFEC controllers. To override,
* create a board-specific function called:
diff --git a/arch/m68k/cpu/mcf52x2/cpu.c b/arch/m68k/cpu/mcf52x2/cpu.c
index d7cbf11e25..5042a38b3e 100644
--- a/arch/m68k/cpu/mcf52x2/cpu.c
+++ b/arch/m68k/cpu/mcf52x2/cpu.c
@@ -17,7 +17,6 @@
#include
#include
#include
-#include
#include
#include
#include
@@ -53,51 +52,7 @@ int print_cpuinfo(void)
return 0;
};
#endif /* CONFIG_DISPLAY_CPUINFO */
-
-#if defined(CONFIG_WATCHDOG)
-/* Called by macro WATCHDOG_RESET */
-void watchdog_reset(void)
-{
- wdog_t *wdt = (wdog_t *)(MMAP_WDOG);
-
- out_be16(&wdt->sr, 0x);
- out_be16(&wdt->sr, 0x);
-}
-
-int watchdog_disable(void)
-{
- wdog_t *wdt = (wdog_t *)(MMAP_WDOG);
-
- /* reset watchdog counter */
- out_be16(&wdt->sr, 0x);
- out_be16(&wdt->sr, 0x);
- /* disable watchdog timer */
- out_be16(&wdt->cr, 0);
-
- puts("WATCHDOG:disabled\n");
- return (0);
-}
-
-int watchdog_init(void)
-{
- wdog_t *wdt = (wdog_t *)(MMAP_WDOG);
-
- /* disable watchdog */
- out_be16(&wdt->cr, 0);
-
- /* set timeout and enable watchdog */
- out_be16(&wdt->mr,
- (CONFIG_WATCHDOG_TIMEOUT_MSECS * CONFIG_SYS_HZ) / (32768 *
1000) - 1);
-
- /* reset watchdog counter */
- out_be16(&wdt->sr, 0x);
- out_be16(&wdt->sr, 0x);
-
- puts("WATCHDOG:enabled\n");
- return (0);
-}
-#endif /* #ifdef CONFIG_WATCHDOG */
-#endif /* #ifdef CONFIG_M5208 */
+#endif /* #ifdef CONFIG_M5208 */
#ifdef CONFIG_M5271
#if defined(CONFIG_DISPLAY_CPUINFO)
diff --git a/arch/m68k/cpu/mcf532x/cpu.c b/arch/m68k/cpu/mcf532x/cpu.c
index 548cbca36a..18d20a8926 100644
--- a/arch/m68k/cpu/mcf532x/cpu.c
+++ b/arch/m68k/cpu/mcf532x/cpu.c
@@ -12,7 +12,6 @@
#include
#include
#include
-#include
#include
#include
#include
@@ -102,49 +101,6 @@ int print_cpuinfo(void)
};
#endif /* CONFIG_DISPLAY_CPUINFO */
-#if defined(CONFIG_WATCHDOG)
-/* Called by macro WATCHDOG_RESET */
-void watchdog_reset(void)
-{
- wdog_t *wdp = (wdog_t *) (MMAP_WDOG);
-
- /* Count register */
- out_be16(&wdp->sr, 0x);
- out_be16(&wdp->sr, 0x);
-}
-
-int watchdog_disable(void)
-{
- wdog_t *wdp = (wdog_t *) (MMAP_WDOG);
-
- /* UserManual, once the wdog is disabled, wdog cannot be re-enabled */
- /* halted watchdog timer */
- setbits_be16(&wdp->cr, WTM_WCR_HALTED);
-
- puts("WATCHDOG:disabled\n");
- return (0);
-}
-
-int watchdog_
Re: [PATCH 3/5] m68k: dts: add watchdog node
On 6/25/23 21:35, Angelo Dureghello wrote:
Add watchdog node for the implemented mcf_wdt driver.
Signed-off-by: Angelo Dureghello
---
arch/m68k/dts/M5208EVBE.dts | 5 +
arch/m68k/dts/mcf5208.dtsi | 7 +++
arch/m68k/dts/mcf523x.dtsi | 7 +++
arch/m68k/dts/mcf5271.dtsi | 7 +++
arch/m68k/dts/mcf5275.dtsi | 7 +++
arch/m68k/dts/mcf5282.dtsi | 7 +++
arch/m68k/dts/mcf5329.dtsi | 7 +++
arch/m68k/dts/mcf537x.dtsi | 7 +++
8 files changed, 54 insertions(+)
diff --git a/arch/m68k/dts/M5208EVBE.dts b/arch/m68k/dts/M5208EVBE.dts
index 1c32718af4..ec203e8b69 100644
--- a/arch/m68k/dts/M5208EVBE.dts
+++ b/arch/m68k/dts/M5208EVBE.dts
@@ -15,6 +15,11 @@
};
};
+&wdog0 {
+ timeout-sec = <32>;
+ status = "okay";
+};
+
&uart0 {
bootph-all;
status = "okay";
diff --git a/arch/m68k/dts/mcf5208.dtsi b/arch/m68k/dts/mcf5208.dtsi
index 9392facfa8..b06dc4bb26 100644
--- a/arch/m68k/dts/mcf5208.dtsi
+++ b/arch/m68k/dts/mcf5208.dtsi
@@ -16,6 +16,13 @@
#address-cells = <1>;
#size-cells = <1>;
+ wdog0: watchdog@fc08c000 {
+ compatible = "fsl,mcf5208-wdt";
+ reg = <0xfc08c000 0x10>;
+ big-endian;
+ status = "disabled";
+ };
I was not able to find this compatible property in the Linux Kernel
source tree. Is this the official version of the Coldfire WDT DT node?
Just checking..
Thanks,
Stefan
+
uart0: uart@fc06 {
compatible = "fsl,mcf-uart";
reg = <0xfc06 0x40>;
diff --git a/arch/m68k/dts/mcf523x.dtsi b/arch/m68k/dts/mcf523x.dtsi
index 41c7b9b2d1..fb5a4cdc21 100644
--- a/arch/m68k/dts/mcf523x.dtsi
+++ b/arch/m68k/dts/mcf523x.dtsi
@@ -23,6 +23,13 @@
ranges = <0x 0x4000 0x4000>;
reg = <0x4000 0x4000>;
+ wdog0: watchdog@14 {
+ compatible = "fsl,mcf5208-wdt";
+ reg = <0x14 0x10>;
+ big-endian;
+ status = "disabled";
+ };
+
uart0: uart@200 {
compatible = "fsl,mcf-uart";
reg = <0x200 0x40>;
diff --git a/arch/m68k/dts/mcf5271.dtsi b/arch/m68k/dts/mcf5271.dtsi
index fc82bd3c24..0884c13ab1 100644
--- a/arch/m68k/dts/mcf5271.dtsi
+++ b/arch/m68k/dts/mcf5271.dtsi
@@ -23,6 +23,13 @@
ranges = <0x 0x4000 0x4000>;
reg = <0x4000 0x4000>;
+ wdog0: watchdog@14 {
+ compatible = "fsl,mcf5208-wdt";
+ reg = <0x14 0x10>;
+ big-endian;
+ status = "disabled";
+ };
+
uart0: uart@200 {
compatible = "fsl,mcf-uart";
reg = <0x200 0x40>;
diff --git a/arch/m68k/dts/mcf5275.dtsi b/arch/m68k/dts/mcf5275.dtsi
index 402517cdec..78210569da 100644
--- a/arch/m68k/dts/mcf5275.dtsi
+++ b/arch/m68k/dts/mcf5275.dtsi
@@ -24,6 +24,13 @@
ranges = <0x 0x4000 0x4000>;
reg = <0x4000 0x4000>;
+ wdog0: watchdog@14 {
+ compatible = "fsl,mcf5208-wdt";
+ reg = <0x14 0x10>;
+ big-endian;
+ status = "disabled";
+ };
+
uart0: uart@200 {
compatible = "fsl,mcf-uart";
reg = <0x200 0x40>;
diff --git a/arch/m68k/dts/mcf5282.dtsi b/arch/m68k/dts/mcf5282.dtsi
index 883c0d0324..40704c5202 100644
--- a/arch/m68k/dts/mcf5282.dtsi
+++ b/arch/m68k/dts/mcf5282.dtsi
@@ -23,6 +23,13 @@
ranges = <0x 0x4000 0x4000>;
reg = <0x4000 0x4000>;
+ wdog0: watchdog@14 {
+ compatible = "fsl,mcf5282-wdt";
+ reg = <0x14 0x10>;
+ big-endian;
+ status = "disabled";
+ };
+
uart0: uart@200 {
compatible = "fsl,mcf-uart";
reg = <0x200 0x40>;
diff --git a/arch/m68k/dts/mcf5329
