Re: [RFC PATCH] drivers: ata: ahci_sunxi: Increased SATA/AHCI DMA TX/RX FIFOs
Hi Maxime & Others,
what follows is a somewhat lengthy technical story behind this patch;
you can just skip it and jump to the end.
As can be seen in the ahci_sunxi.c, the port used in this patch
is this one (32bit):
#define AHCI_P0DMACR0x0170
It's a so called "Vendor Specific Port" according to the SATA/AHCI specs by
Intel.
The data behind it is actually a struct, consisting of 4 fields,
each 4bits long, plus a 16bits long field that is marked as Reserved
in secondary literature (see below):
struct AHCI_P0DMACR_t
{
unsigned TXTS : 4,
RXTS : 4,
TXABL : 4,
RXABL : 4,
Res1 : 16;
};
This struct is just my creation for my own tests as it's not part of the
driver source. The patch touches only the first 2 fields: TXTS and RXTS.
See this similar product documentation by Texas Instruments for the above
struct:
https://www.ti.com/lit/ug/sprugj8c/sprugj8c.pdf
TMS320C674x/OMAP-L1x Processor, Serial ATA (SATA) Controller, User's Guide,
Literature Number: SPRUGJ8C, March 2011,
Page 68, Chapter 4.33 "Port DMA Control Register (P0DMACR)"
The above TI document describes the two fields as follows:
TXTS:
Transmit Transaction Size (TX_TRANSACTION_SIZE). This field defines the DMA
transaction size in
DWORDs for transmit (system bus read, device write) operation. [...]
RXTS:
Receive Transaction Size (RX_TRANSACTION_SIZE). This field defines the Port
DMA transaction size
in DWORDs for receive (system bus write, device read) operation. [...]
So, in my patch the fields TXTS and RXTS are set to 3 each.
Without the patch, these fields seem to have some random content
(I'vee seen 5 and 6, 4 and 4, and 0 and 0 on different devices),
as the previous code doesn't touch these 2 fields (ie. these two fields
are not within the used old mask of 0xff00; cf. ahci_sunxi.c, function
ahci_sunxi_start_engine(...)).
Some background story in my hunt for obtaining product documentation:
I couldn't find any product documentation for the SATA/AHCI
in these SoCs by Allwinner Technology (allwinnertech.com),
unlike with such products from other such companies.
I asked Allwinner, but they just said that the A20 of my SBC
would (allegedly) no more be actual and that the support for it
has ended (but this statement somehow cannot be true as the
A20 SoC is still continued being marketed at their website).
They instead sent me a bunch of really irrelevant PDFs which have
nothing to do with SATA/AHCI.
So, the company Allwinner Technology unfortunately was not cooperative
to provide me information on their SATA/AHCI-implementation in their SoCs :-(
Even the ports used in the actual ahci_sunxi.c in the linux tree are
undocumented;
it is even commented with "/* This magic is from the original code */"
and below it many ports are used for which no documentation is available,
or at least I couldn't find any on the Internet. And the initial programmer
in 2014 and prior was Daniel Wang (danielw...@allwinnertech.com),
but email to that address bounces.
So, I was forced to research secondary literature from other vendors
like Texas Instruments (thanks TI !) and Intel, and also studying
very old source codes in the old Linux repositories (as it differs
much from the current version) going back to the year 2014, and had
to do many (blind) experiments until I found this solution.
The above given User's Guide by Texas Instruments (and their such
documents for their newer such products) helped me much to find the solution.
It's of course not really the correct documentation for the Allwinner SoCs,
but still better than nothing.
If I only had the right documentation, then I for sure could try
to further improve that already achieved result by this patch,
as with SATA-II upto 300 MiB/s is possible.
Yes, I'll resend the patch with some appropriate comments.
Uenal Mutlu
Maxime Ripard wrote on 05/12/2019 02:12 PM:
Hi,
On Fri, May 10, 2019 at 09:25:50PM +0200, Uenal Mutlu wrote:
Increasing the SATA/AHCI DMA TX/RX FIFOs (P0DMACR.TXTS and .RXTS) from
default 0x0 each to 0x3 each gives a write performance boost of 120MB/s
from lame 36MB/s to 45MB/s previously. Read performance is about 200MB/s
[tested on SSD using dd bs=4K count=512K].
Tested on the Banana Pi R1 (aka Lamobo R1) and Banana Pi M1 SBCs
with Allwinner A20 32bit-SoCs (ARMv7-a / arm-linux-gnueabihf).
These devices are RaspberryPi-like small devices.
RFC: Since more than about 25 similar SBC/SoC models do use the
ahci_sunxi driver, users are encouraged to test it on all the
affected boards and give feedback.
List of the affected sunxi and other boards and SoCs with SATA using
the ahci_sunxi driver:
$ grep -i -e "^" arch/arm/boot/dts/sun*dts
and http://linux-sunxi.org/Category:Devices_with_SATA_port
Signed-off-by: Uenal Mutlu
---
drivers/ata/ahci_sunxi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/ata/ahci_sunxi.c b/drivers/ata/ahci_sunxi.c
index 911710643305..257986431c79
Re: [RFC PATCH] drivers: ata: ahci_sunxi: Increased SATA/AHCI DMA TX/RX FIFOs
Stefan Monnier wrote on 05/11/2019 03:37 PM: Increasing the SATA/AHCI DMA TX/RX FIFOs (P0DMACR.TXTS and .RXTS) from default 0x0 each to 0x3 each gives a write performance boost of 120MB/s from lame 36MB/s to 45MB/s previously. Read performance is about 200MB/s [tested on SSD using dd bs=4K count=512K]. Such a simple patch to fix such a long-standing performance problem that everyone [ well, apparently not quite everyone ] assumed was a hardware limitation... And yet, April 1st is long gone. Is it really for real? Yes, it's indeed real, Stefan; really no April 1st joke. :-) As you indicated, this problem of slow SATA write-speed with these small devices lasts now for more than 5 years. This patch finally solves the problem. On my test device (BPI-R1) the optimum blocksize seems to be 12K as it then gives even 129 MB/s write speed. Here are some test results with different blocksizes, all giving a write speed of 125 to 129 MB/s: time sh -c "dd if=/dev/zero of=test.tmp bs=$bs count=$count conv=fdatasync" bs=8K / count=256K / 1 -- 262144+0 records in 262144+0 records out 2147483648 bytes (2.1 GB) copied, 16.9237 s, 127 MB/s real0m16.935s user0m0.388s sys 0m15.777s bs=8K / count=256K / 2 -- 262144+0 records in 262144+0 records out 2147483648 bytes (2.1 GB) copied, 16.9916 s, 126 MB/s real0m17.973s user0m0.326s sys 0m16.806s bs=8K / count=256K / 3 -- 262144+0 records in 262144+0 records out 2147483648 bytes (2.1 GB) copied, 17.0085 s, 126 MB/s real0m17.993s user0m0.442s sys 0m16.588s bs=12K / count=171K / 1 -- 175104+0 records in 175104+0 records out 2151677952 bytes (2.2 GB) copied, 16.8474 s, 128 MB/s real0m16.860s user0m0.205s sys 0m15.705s bs=12K / count=171K / 2 -- 175104+0 records in 175104+0 records out 2151677952 bytes (2.2 GB) copied, 16.6934 s, 129 MB/s real0m17.669s user0m0.227s sys 0m16.355s bs=12K / count=171K / 3 -- 175104+0 records in 175104+0 records out 2151677952 bytes (2.2 GB) copied, 16.6684 s, 129 MB/s real0m17.654s user0m0.388s sys 0m16.118s bs=16K / count=128K / 1 -- 131072+0 records in 131072+0 records out 2147483648 bytes (2.1 GB) copied, 17.1845 s, 125 MB/s real0m17.200s user0m0.251s sys 0m16.060s bs=16K / count=128K / 2 -- 131072+0 records in 131072+0 records out 2147483648 bytes (2.1 GB) copied, 16.9221 s, 127 MB/s real0m17.902s user0m0.170s sys 0m16.763s bs=16K / count=128K / 3 -- 131072+0 records in 131072+0 records out 2147483648 bytes (2.1 GB) copied, 16.8845 s, 127 MB/s real0m17.868s user0m0.167s sys 0m16.736s
[U-Boot] build error: "bfd: u-boot-spl section `.rodata' will not fit in region `.sram'"
I updated my local git source tree, but now I get this error with stock Lamobo_R1_defconfig and w/o any changes to .config: arm-linux-gnueabihf-ld.bfd: u-boot-spl section `.rodata' will not fit in region `.sram' arm-linux-gnueabihf-ld.bfd: region `.sram' overflowed by 1176 bytes scripts/Makefile.spl:384: recipe for target 'spl/u-boot-spl' failed make[1]: *** [spl/u-boot-spl] Error 1 Makefile:1689: recipe for target 'spl/u-boot-spl' failed make: *** [spl/u-boot-spl] Error 2 $ git status On branch master Your branch is up-to-date with 'origin/master'. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] Build error: caused by CONFIG_SPL_LOG_CONSOLE
If I activate "Enable logging support in SPL" (ie. CONFIG_SPL_LOG_CONSOLE), ie. the following window in make menuconfig: Logging ---> [*] Enable logging support [*] Enable logging support in SPL [*] Enable logging support in TPL (5) Maximum log level to record (3) Maximum log level to record in SPL (NEW) (3) Maximum log level to record in TPL (6) Default logging level to display [*] Allow log output to the console [*] Allow log output to the console in SPL (NEW) [*] Allow log output to the console in SPL [ ] Provide a test for logging [*] Log all functions which return an error then the build fails as follows (paths sanitized): arm-linux-gnueabihf-ld.bfd: common/built-in.o: in function `log_get_cat_name': /.../u-boot/common/log.c:48: undefined reference to `uclass_get_name' arm-linux-gnueabihf-ld.bfd: common/built-in.o: in function `_log': /.../u-boot/common/log.c:212: undefined reference to `vsnprintf' scripts/Makefile.spl:384: recipe for target 'spl/u-boot-spl' failed make[1]: *** [spl/u-boot-spl] Error 1 Makefile:1664: recipe for target 'spl/u-boot-spl' failed make: *** [spl/u-boot-spl] Error 2 Deactivating "Enable logging support in SPL" builds ok. Version: U-Boot 2019.04-00077-g48ff1bc4f0 (using stock git source tree w/o any own modifications) Platform: CONFIG_ARM=y CONFIG_SYS_ARCH="arm" CONFIG_SYS_CPU="armv7" CONFIG_SYS_SOC="sunxi" CONFIG_SYS_BOARD="sunxi" CONFIG_SYS_CONFIG_NAME="sun7i" CONFIG_DEFAULT_DEVICE_TREE="sun7i-a20-lamobo-r1" ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [linux-sunxi] [PATCH] ARM: HYP/non-sec: Don't enable ARMV7_LPAE for old sunxi kernels
Mark Kettenis wrote on 04/12/2019 03:03 PM: From: Jagan Teki Date: Fri, 12 Apr 2019 12:02:06 +0530 On Fri, Mar 22, 2019 at 2:31 AM Jonathan Liu wrote: Hi Jagan, On Fri., 22 Mar. 2019 at 4:05 am, Jagan Teki wrote: On Tue, Mar 19, 2019 at 11:09 AM Jonathan Liu wrote: Old sunxi kernels fail to boot with ARMV7_LPAE enabled. Any idea why? I don't have relevant stuff with to test this. I don't know why. It failed to boot linux-sunxi 3.4.104 kernel on A20 OLinuXino-MICRO after updating from 2018.07 to 2018.09-rc1 and would hang at "Starting kernel...". I bisected the issue to: https://git.denx.de/?p=u-boot.git;a=commit;h=d32e86bde8a31a49cf4a9b233ad91ecdfc96ba2a No problems booting mainline kernel. Can you update full details of bug on the commit message. Technically I think the right thing to do would be disabling ARMV7_VIRT as my understanding is that booting into HYP mode doesn't work without LPAE support. Some days ago I tried to disable HYP mode for SVC mode. But with SVC the PSCI is not loading (u-boot bug?), and without PSCI only the 1st core of the CPU gets used. I had documented the case here: https://lists.denx.de/pipermail/u-boot/2019-April/364192.html ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] Missing: CONFIG_EXTRA_ENV_SETTINGS
The "make menuconfig" help page for "Environment --> Create default environment from file" mentions CONFIG_EXTRA_ENV_SETTINGS, but searching for this says "No matches found", and also in the saved .config it's missing. Version info (boot msgs): U-Boot SPL 2019.04-00077-g48ff1bc4f0-dirty (Apr 11 2019 - 13:43:54 +0200) DRAM: 1024 MiB CPU: 91200Hz, AXI/AHB/APB: 3/2/2 Trying to boot from MMC1 U-Boot 2019.04-00077-g48ff1bc4f0-dirty (Apr 11 2019 - 13:43:54 +0200) Allwinner Technology CPU: Allwinner A20 (SUN7I) Model: Lamobo R1 I2C: ready DRAM: 1 GiB MMC: mmc@1c0f000: 0 Loading Environment from FAT... *** Warning - bad CRC, using default environment ... ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] sunxi-fel uboot brings SPL version mismatch error
Jack Mitchell wrote on 04/11/2019 11:13 AM:
On 11/04/2019 01:16, U.Mutlu wrote:
# CC Jagan
There's a version mismatch error with the sunxi-fel tool from sunxi-tools
( https://github.com/linux-sunxi/sunxi-tools )
./sunxi-fel -v uboot u-boot-sunxi-with-spl.bin write 0x4310 my.env
Stack pointers: sp_irq=0x2000, sp=0x5E08
Reading the MMU translation table from 0x0002
Disabling I-cache, MMU and branch prediction... done.
=> Executing the SPL... done.
Setting write-combine mapping for DRAM.
Setting cached mapping for BROM.
Writing back the MMU translation table.
Enabling I-cache, MMU and branch prediction... done.
Writing image "U-Boot 2019.04-00036-g1d63ec3fa4", 448324 bytes @
0x4A00.
sunxi SPL version mismatch: found 0x03 > maximum supported 0x02
You need a more recent version of this (sunxi-tools) fel utility.
Starting U-Boot (0x4A00).
Bug tracker:
https://github.com/linux-sunxi/sunxi-tools/issues/124
I think it's still the case that you need to build sunxi-tools from the
HEAD commit of the master branch for a recent uboot.
Do you happen to know how to do that?
I think I already have the latest repo version, isn't it? :
$ git remote show origin
* remote origin
Fetch URL: https://github.com/linux-sunxi/sunxi-tools
Push URL: https://github.com/linux-sunxi/sunxi-tools
HEAD branch: master
Remote branches:
autotools tracked
master tracked
reorganize tracked
windowstracked
Local branch configured for 'git pull':
master merges with remote master
Local ref configured for 'git push':
master pushes to master (up to date)
$ git checkout master
Already on 'master'
Your branch is up-to-date with 'origin/master'.
$ git reflog
7fe6024 HEAD@{0}: checkout: moving from master to master
7fe6024 HEAD@{1}: clone: from https://github.com/linux-sunxi/sunxi-tools
$ git checkout .
$ git checkout master
Already on 'master'
Your branch is up-to-date with 'origin/master'.
$ git pull
Already up-to-date.
So, there's nothing new coming to my local copy.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] standalone app hello_world.bin crashes
# CC W.D., T.R. I tried to run hello_world.bin (in examples/standalone) on the target device, but it crashes with "undefined instruction". I followed the steps in the doc at https://www.denx.de/wiki/view/DULG/UBootStandalone. The said example is generated together with u-boot itself; u-boot works ok, but the example crashes: => fatload mmc 0 0x4200 hello_world.bin ; go 0x4200 a b c d 570 bytes read in 2 ms (278.3 KiB/s) ## Starting application at 0x4200 ... undefined instruction pc : [<42000718>] lr : [<7ef7c633>] reloc pc : [<0d086718>]lr : [<4a002633>] sp : 7af51eb8 ip : 000c fp : 0006 r10: 7af68c28 r9 : 7af59ed8 r8 : 7efd5154 r7 : 7ef8fa25 r6 : 0006 r5 : 4200 r4 : 7af68c2c r3 : 4200 r2 : 7af68c2c r1 : 7af68c2c r0 : 0005 Flags: nzCv IRQs off FIQs off Mode SVC_32 Code: 35303753 30303234 31303030 0a0d3742 () Resetting CPU ... resetting ... => version U-Boot 2019.04-00077-g48ff1bc4f0 (Apr 11 2019 - 07:40:39 +0200) Allwinner Technology arm-linux-gnueabihf-gcc (GCC) 9.0.1 20190326 (experimental) [trunk revision 269955] GNU ld (GNU Binutils) 2.32.51.20190326 => bdi arch_number = 0x100010bb boot_params = 0x4100 DRAM bank = 0x -> start= 0x4000 -> size = 0x4000 baudrate= 115200 bps TLB addr= 0x7eff relocaddr = 0x7ef7a000 reloc off = 0x34f7a000 irq_sp = 0x7af52000 sp start= 0x7af51ff0 FB base = 0x7fb0 Early malloc usage: 134 / 400 fdt_blob= 0x7af52018 root@xy:/.../u-boot/examples/standalone# ../../../TOOLCHAIN/bin/arm-linux-gnueabihf-nm -n hello_world 4200 T hello_world 4290 T dummy 4290 T get_version 4298 T getc 42a0 T tstc 42a8 T putc 42b0 T puts 42b8 T printf 42c0 T install_hdlr 42c8 T free_hdlr 42d0 T malloc 42d8 T free 42e0 T udelay 42e8 T get_timer 42f0 T vprintf 42f8 T do_reset 42000100 T env_get 42000108 T env_set 42000110 T simple_strtoul 42000118 T strict_strtoul 42000120 T simple_strtol 42000128 T strcmp 42000130 T i2c_write 42000138 T i2c_read 42000140 T spi_setup_slave 42000148 T spi_free_slave 42000150 T spi_claim_bus 42000158 T spi_release_bus 42000160 T spi_xfer 42000168 T ustrtoul 42000170 T ustrtoull 42000178 T strcpy 42000180 T mdelay 42000188 T memset 42000194 T app_startup 4201023a R __bss_end__ 4201023a R _bss_end__ 4201023a R __bss_start 4201023a R __bss_start__ 4201023a R _edata 4201023c R _end 4201023c R __end__ -- U.Mutlu ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] sunxi-fel uboot brings SPL version mismatch error
# CC Jagan There's a version mismatch error with the sunxi-fel tool from sunxi-tools ( https://github.com/linux-sunxi/sunxi-tools ) ./sunxi-fel -v uboot u-boot-sunxi-with-spl.bin write 0x4310 my.env Stack pointers: sp_irq=0x2000, sp=0x5E08 Reading the MMU translation table from 0x0002 Disabling I-cache, MMU and branch prediction... done. => Executing the SPL... done. Setting write-combine mapping for DRAM. Setting cached mapping for BROM. Writing back the MMU translation table. Enabling I-cache, MMU and branch prediction... done. Writing image "U-Boot 2019.04-00036-g1d63ec3fa4", 448324 bytes @ 0x4A00. sunxi SPL version mismatch: found 0x03 > maximum supported 0x02 You need a more recent version of this (sunxi-tools) fel utility. Starting U-Boot (0x4A00). Bug tracker: https://github.com/linux-sunxi/sunxi-tools/issues/124 -- U.Mutlu (mutluit) ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Bug in saveenv handling?
Hi Frank, as said, the error happened in the last -rc4 version, but does not happen in the current release version (2019.04). /dev/mmcblk0p1 on the SD card is my boot partition (FAT16 LBA) and uses default settings. Hope the following info answers your questions. (yes, the SD card capacity is 16GB, but intentionally only the 1st 1.4GB or so is in use yet; this is to keep the .img size small). Regarding the environment file (uboot.env): I can't say whether it should be a hidden file or not as I saw it only recently pop-up in the /, after I used saveenv. root@xy:~# lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 465.8G 0 disk └─sda1 8:1 0 457.8G 0 part / mmcblk0 179:0 0 14.5G 0 disk ├─mmcblk0p2 179:2 0 1.4G 0 part └─mmcblk0p1 179:1 0 32M 0 part /boot root@xy:~# fdisk -l /dev/mmcblk0 Disk /dev/mmcblk0: 14.5 GiB, 15523119104 bytes, 30318592 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: dos Disk identifier: 0xdccc2266 Device Boot Start End Sectors Size Id Type /dev/mmcblk0p1 * 2048 67583 65536 32M e W95 FAT16 (LBA) /dev/mmcblk0p2 67584 3071999 3004416 1.4G 83 Linux root@xy:~# fdisk -l /dev/mmcblk0p1 Disk /dev/mmcblk0p1: 32 MiB, 33554432 bytes, 65536 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: dos Disk identifier: 0x root@xy:~# minfo -i /dev/mmcblk0p1 :: device information: === filename="/dev/mmcblk0p1" sectors per track: 32 heads: 64 cylinders: 32 mformat command line: mformat -t 32 -i /dev/mmcblk0p1 -h 64 -s 32 -H 2048 :: bootsector information == banner:"mkfs.fat" sector size: 512 bytes cluster size: 4 sectors reserved (boot) sectors: 1 fats: 2 max available root directory slots: 512 small size: 0 sectors media descriptor byte: 0xf8 sectors per fat: 64 sectors per track: 32 heads: 64 hidden sectors: 2048 big size: 65536 sectors physical drive id: 0x80 reserved=0x0 dos4=0x29 serial number: F7D2F904 disk label="NO NAME" disk type="FAT16 " Frank Wunderlich wrote on 04/10/2019 10:00 AM: please stay on list...i'm no expert in fat-environment, only have some experience on out-of-partition environment-storage (env on mmc). This seems not your case... i don't know if env_offset is used on fat (makes no sense in my eyes) and env_is_on_mmc is disabled where did your fat-partition start? if it starts after 1M offset uboot should not overwrite itself with saveenv. following your dd starts at 8k-offset and have which size (typically <1M)? your erase before cleans first 1M (except first 1k where partitiontable is located). why do you think the target-file should be hidden? imho it is a normal file on mmc 0 and maybe first fat-partition (auto-flag) named "uboot.env". you found the file on /?? this should not be a fat-partition. linux imho needs a partiton with permission-options (extx,reiser,...). i guess you mean additional fat-partition, maybe mounted to /boot. maybe you can add some debug-messages in saveenv for fat (env/fat.c env_fat_save, fs/fat/fat_write.c file_fat_write) regards Frank > Gesendet: Dienstag, 09. April 2019 um 23:21 Uhr Von: "U.Mutlu" $ ls -l u-boot-sunxi-with-spl.bin -rw-r--r-- 1 xy xy 479836 Apr 9 17:55 u-boot-sunxi-with-spl.bin I used the following to write u-boot to the SD card (/dev/sdb): # dd if=/dev/zero of=/dev/sdb bs=1k count=1023 seek=1 # dd if=u-boot-sunxi-with-spl.bin of=/dev/sdb bs=1024 seek=8 $ grep -i ENV_ .config CONFIG_ENV_SIZE=0x2 CONFIG_ENV_OFFSET=0x88000 CONFIG_ENV_VARS_UBOOT_CONFIG=y # CONFIG_SYS_CONSOLE_ENV_OVERWRITE is not set # CONFIG_SPL_ENV_SUPPORT is not set CONFIG_CMD_ENV_EXISTS=y # CONFIG_CMD_ENV_CALLBACK is not set # CONFIG_CMD_ENV_FLAGS is not set # CONFIG_ENV_IS_IN_EEPROM is not set CONFIG_ENV_IS_IN_FAT=y # CONFIG_ENV_IS_IN_EXT4 is not set # CONFIG_ENV_IS_IN_FLASH is not set # CONFIG_ENV_IS_IN_MMC is not set # CONFIG_ENV_IS_IN_NAND is not set # CONFIG_ENV_IS_IN_NVRAM is not set # CONFIG_ENV_IS_IN_ONENAND is not set # CONFIG_ENV_IS_IN_REMOTE is not set # CONFIG_ENV_IS_IN_SPI_FLASH is not set # CONFIG_ENV_IS_IN_UBI is not set CONFIG_ENV_FAT_INTERFACE="mmc" CONFIG_ENV_FAT_DEVICE_AND_PART="0:auto" CONFIG_ENV_FAT_FILE="uboot.env" # CONFIG_USE_DEFAULT_ENV_FILE is not set # CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG is not set $ grep ENV_FAT .config CONFIG_ENV_FAT_INTERFACE="mmc" CONFIG_ENV_FAT_DEVICE_AND_PART="0:auto" CONFIG_ENV_FAT_FILE="uboot.env" I guess the uboot.env is a hidden file, but occassionally (esp. after saveenv & reboot) I see this file as a normal file in /, not hidden. I used "Lamobo_R1_defconfig" as basis and made
Re: [U-Boot] Bug in saveenv handling?
Tom Rini wrote on 04/09/2019 11:09 PM: On Tue, Apr 09, 2019 at 10:53:36PM +0200, U.Mutlu wrote: Frank Wunderlich wrote on 04/09/2019 09:39 PM: this looks for me like the CONFIG_ENV_OFFSET+CONFIG_ENV_SIZE is overlapping uboots code can you post these values and position of uboot and its size for your device? which env-storage do you use (EMV_IN_MMC or ENV_FAT)? I looked up in the .config file: # U-Boot 2019.04-rc4 Configuration So, -rc4 has a bug that the final release does not, on this platform. Please try the v2019.04 release first and then if you see the problem still, continue reporting and also make sure to Cc Jagan, thanks! # U-Boot 2019.04 Configuration Yes, I too can confirm now that the problem of saveenv overwriting u-boot doesn't happen in the 2019.04 release version. But the said crash when issuing the command "scsi scan" is still present, but this maybe has some other reasons. Thx. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Possible bug in release: fdisk in linux cannot read /dev/mmcblk0 anymore
Sorry, seems to be a false alert. After rebuilding u-boot it works fine again. U.Mutlu wrote on 04/10/2019 12:37 AM: Hi folks, # U-Boot 2019.04 Configuration I just updated to the latest version via git. My previous version was the recent 2019.04-rc4. Now in this latest version I think a bug shows up: Inside Linux on the device, suddenly the following command no longer works: # fdisk -l /dev/mmcblk0 fdisk: cannot open /dev/mmcblk0: Input/output error # ls -l /dev/mmcblk0 brw-rw 1 root disk 179, 0 Jan 1 1970 /dev/mmcblk0 The device is present, but fdisk cannot read the partitions, although u-boot has successfully used the boot partition of this SD card to boot Linux. IMHO a funny situation, isn't it? :-) This always had worked for me, up until now. Is this more a linux issue or a u-boot issue? Let me know if you need specific data. Thx ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] Possible bug in release: fdisk in linux cannot read /dev/mmcblk0 anymore
Hi folks, # U-Boot 2019.04 Configuration I just updated to the latest version via git. My previous version was the recent 2019.04-rc4. Now in this latest version I think a bug shows up: Inside Linux on the device, suddenly the following command no longer works: # fdisk -l /dev/mmcblk0 fdisk: cannot open /dev/mmcblk0: Input/output error # ls -l /dev/mmcblk0 brw-rw 1 root disk 179, 0 Jan 1 1970 /dev/mmcblk0 The device is present, but fdisk cannot read the partitions, although u-boot has successfully used the boot partition of this SD card to boot Linux. IMHO a funny situation, isn't it? :-) This always had worked for me, up until now. Is this more a linux issue or a u-boot issue? Let me know if you need specific data. Thx ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Bug in saveenv handling?
U.Mutlu wrote on 04/09/2019 11:01 PM: U.Mutlu wrote on 04/09/2019 10:53 PM: Frank Wunderlich wrote on 04/09/2019 09:39 PM: this looks for me like the CONFIG_ENV_OFFSET+CONFIG_ENV_SIZE is overlapping uboots code can you post these values and position of uboot and its size for your device? $ ls -l u-boot-sunxi-with-spl.bin -rw-r--r-- 1 xy xy 479836 Apr 9 17:55 u-boot-sunxi-with-spl.bin I used the following to write u-boot to the SD card (/dev/sdb): # dd if=/dev/zero of=/dev/sdb bs=1k count=1023 seek=1 # dd if=u-boot-sunxi-with-spl.bin of=/dev/sdb bs=1024 seek=8 If you need more data let me know pls. which env-storage do you use (EMV_IN_MMC or ENV_FAT)? I looked up in the .config file: # U-Boot 2019.04-rc4 Configuration $ grep CONFIG_ENV_OFFSET .config CONFIG_ENV_OFFSET=0x88000 $ grep CONFIG_ENV_SIZE .config CONFIG_ENV_SIZE=0x2 $ grep EMV_IN_MMC .config Maybe EMV_ is a typo and should rather be ENV_ ? $ grep -i EMV_ .config $ grep -i ENV_ .config CONFIG_ENV_SIZE=0x2 CONFIG_ENV_OFFSET=0x88000 CONFIG_ENV_VARS_UBOOT_CONFIG=y # CONFIG_SYS_CONSOLE_ENV_OVERWRITE is not set # CONFIG_SPL_ENV_SUPPORT is not set CONFIG_CMD_ENV_EXISTS=y # CONFIG_CMD_ENV_CALLBACK is not set # CONFIG_CMD_ENV_FLAGS is not set # CONFIG_ENV_IS_IN_EEPROM is not set CONFIG_ENV_IS_IN_FAT=y # CONFIG_ENV_IS_IN_EXT4 is not set # CONFIG_ENV_IS_IN_FLASH is not set # CONFIG_ENV_IS_IN_MMC is not set # CONFIG_ENV_IS_IN_NAND is not set # CONFIG_ENV_IS_IN_NVRAM is not set # CONFIG_ENV_IS_IN_ONENAND is not set # CONFIG_ENV_IS_IN_REMOTE is not set # CONFIG_ENV_IS_IN_SPI_FLASH is not set # CONFIG_ENV_IS_IN_UBI is not set CONFIG_ENV_FAT_INTERFACE="mmc" CONFIG_ENV_FAT_DEVICE_AND_PART="0:auto" CONFIG_ENV_FAT_FILE="uboot.env" # CONFIG_USE_DEFAULT_ENV_FILE is not set # CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG is not set $ grep ENV_FAT .config CONFIG_ENV_FAT_INTERFACE="mmc" CONFIG_ENV_FAT_DEVICE_AND_PART="0:auto" CONFIG_ENV_FAT_FILE="uboot.env" I guess the uboot.env is a hidden file, but occassionally (esp. after saveenv & reboot) I see this file as a normal file in /, not hidden. I used "Lamobo_R1_defconfig" as basis and made just a few irrelevant minor changes in make menuconfig. It's actually a Banana Pi R1 board. CONFIG_DEFAULT_DEVICE_TREE="sun7i-a20-lamobo-r1" Thx Gesendet: Dienstag, 09. April 2019 um 21:05 Uhr Von: "U.Mutlu" It seems u-boot has overwritten parts of itself on the storage medium (uSD with FAT boot partition). ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Bug in saveenv handling?
U.Mutlu wrote on 04/09/2019 10:53 PM: Frank Wunderlich wrote on 04/09/2019 09:39 PM: this looks for me like the CONFIG_ENV_OFFSET+CONFIG_ENV_SIZE is overlapping uboots code can you post these values and position of uboot and its size for your device? which env-storage do you use (EMV_IN_MMC or ENV_FAT)? I looked up in the .config file: # U-Boot 2019.04-rc4 Configuration $ grep CONFIG_ENV_OFFSET .config CONFIG_ENV_OFFSET=0x88000 $ grep CONFIG_ENV_SIZE .config CONFIG_ENV_SIZE=0x2 $ grep EMV_IN_MMC .config Maybe EMV_ is a typo and should rather be ENV_ ? $ grep -i EMV_ .config $ grep -i ENV_ .config CONFIG_ENV_SIZE=0x2 CONFIG_ENV_OFFSET=0x88000 CONFIG_ENV_VARS_UBOOT_CONFIG=y # CONFIG_SYS_CONSOLE_ENV_OVERWRITE is not set # CONFIG_SPL_ENV_SUPPORT is not set CONFIG_CMD_ENV_EXISTS=y # CONFIG_CMD_ENV_CALLBACK is not set # CONFIG_CMD_ENV_FLAGS is not set # CONFIG_ENV_IS_IN_EEPROM is not set CONFIG_ENV_IS_IN_FAT=y # CONFIG_ENV_IS_IN_EXT4 is not set # CONFIG_ENV_IS_IN_FLASH is not set # CONFIG_ENV_IS_IN_MMC is not set # CONFIG_ENV_IS_IN_NAND is not set # CONFIG_ENV_IS_IN_NVRAM is not set # CONFIG_ENV_IS_IN_ONENAND is not set # CONFIG_ENV_IS_IN_REMOTE is not set # CONFIG_ENV_IS_IN_SPI_FLASH is not set # CONFIG_ENV_IS_IN_UBI is not set CONFIG_ENV_FAT_INTERFACE="mmc" CONFIG_ENV_FAT_DEVICE_AND_PART="0:auto" CONFIG_ENV_FAT_FILE="uboot.env" # CONFIG_USE_DEFAULT_ENV_FILE is not set # CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG is not set $ grep ENV_FAT .config CONFIG_ENV_FAT_INTERFACE="mmc" CONFIG_ENV_FAT_DEVICE_AND_PART="0:auto" CONFIG_ENV_FAT_FILE="uboot.env" I guess the uboot.env is a hidden file, but occassionally (esp. after saveenv & reboot) I see this file as a normal file in /, not hidden. I used "Lamobo_R1_defconfig" as basis and made just a few irrelevant minor changes in make menuconfig. It's actually a Banana Pi R1 board. CONFIG_DEFAULT_DEVICE_TREE="sun7i-a20-lamobo-r1" Thx Gesendet: Dienstag, 09. April 2019 um 21:05 Uhr Von: "U.Mutlu" It seems u-boot has overwritten parts of itself on the storage medium (uSD with FAT boot partition). ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Bug in saveenv handling?
Frank Wunderlich wrote on 04/09/2019 09:39 PM: this looks for me like the CONFIG_ENV_OFFSET+CONFIG_ENV_SIZE is overlapping uboots code can you post these values and position of uboot and its size for your device? which env-storage do you use (EMV_IN_MMC or ENV_FAT)? I looked up in the .config file: # U-Boot 2019.04-rc4 Configuration $ grep CONFIG_ENV_OFFSET .config CONFIG_ENV_OFFSET=0x88000 $ grep CONFIG_ENV_SIZE .config CONFIG_ENV_SIZE=0x2 $ grep EMV_IN_MMC .config $ grep ENV_FAT .config CONFIG_ENV_FAT_INTERFACE="mmc" CONFIG_ENV_FAT_DEVICE_AND_PART="0:auto" CONFIG_ENV_FAT_FILE="uboot.env" I guess the uboot.env is a hidden file, but occassionally (esp. after saveenv & reboot) I see this file as a normal file in /, not hidden. I used "Lamobo_R1_defconfig" as basis and made just a few irrelevant minor changes in make menuconfig. It's actually a Banana Pi R1 board. CONFIG_DEFAULT_DEVICE_TREE="sun7i-a20-lamobo-r1" Thx Gesendet: Dienstag, 09. April 2019 um 21:05 Uhr Von: "U.Mutlu" It seems u-boot has overwritten parts of itself on the storage medium (uSD with FAT boot partition). ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] Bug in saveenv handling?
I just made this unpleasant observation while playing with u-boot: On the u-boot CLI I changed an envvar and saved the env: setenv bootdelay 5 ; saveenv Then I issued, just for fun, the command "scsi scan", but it crashed and rebooted the device. But this time on the display only the tuxx logo and the very first u-boot line is displayed, nothing else happens. It seems u-boot has overwritten parts of itself on the storage medium (uSD with FAT boot partition). I had this experience some more times in the past; after writing u-boot anew to the uSD it continued working again. Btw, I once even had the case where saveenv overwrote boot.cmd (but nothing else) with garbage (IIRC it was filled full with the char @ ). I mention this just because it seems that there's maybe a bug in u-boot's saveenv handling (maybe data was not completely flushed, file handle was not closed, or maybe the fat write routine is buggy?...). => setenv bootdelay 5 ; saveenv Saving Environment to FAT... OK => printenv bootdelay bootdelay=5 => scsi scan scanning bus for devices... data abort pc : [<7ef94f8e>] lr : [<7ef911a1>] reloc pc : [<4a01af8e>]lr : [<4a0171a1>] sp : 7af51bf8 ip : 001c fp : 00c0 r10: r9 : 7af59ed8 r8 : r7 : 7af51e78 r6 : 7efd3f54 r5 : 7efdb9b8 r4 : 7efdb9b8 r3 : r2 : r1 : ea16 r0 : 7efdb9b8 Flags: nZcv IRQs off FIQs off Mode SVC_32 Code: e92dbd10 f8d045f0 b0858080 1000f8d8 (f8d14604) Resetting CPU ... resetting ... ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Automatic starting of netconsole at boot
I think there is a bug in netconsole of u-boot: about every 8 seconds it pauses for about another 8 seconds. Ie. some of the pressed keys on the netconsole host get struck (gets lost), after a while it continues. Happens with "tools/netconsole" as well with "nc -u -l -p ". This can also be seen from another terminal when pinging the device: every a while (~ every 8 seconds) the output of ping pauses for about 8 seconds... ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] Automatic starting of netconsole at boot
Hi, I built u-boot with CONFIG_NETCONSOLE=y. It works, but how can I set up u-boot so that after rebooting, it automatically (ie. w/o manual interaction) goes into netconsole mode? Ie. controlling the device remotely via netconsole by using the tools/netconsole script on the host as shown in doc/README.NetConsole, but there only a manual setup is given. For auto-starting netconsole I put these commands into boot.cmd and compiled it to boot.scr on the device: setenv ipaddr 192.168.1.7 setenv ncip 192.168.1.2 setenv nc 'setenv stdout nc;setenv stdin nc;setenv stderr nc' run nc At boot the netconnect connection seems to work as I get some output on the host, but after only a few seconds the device reboots itself: root@xy:/.../u-boot# tools/netconsole 192.168.1.7 Board out port: Board in port: NOTE: the interrupt signal (normally ^C) has been remapped to ^T ncb: not found #MYINFO: the following output comes from the remote board via netconsole: SCRIPT FAILED: continuing... scanning bus for devices... data abort pc : [<7ef94f8e>] lr : [<7ef911a1>] reloc pc : [<4a01af8e>]lr : [<4a0171a1>] sp : 7af515b0 ip : 001c fp : 00c0 r10: r9 : 7af59ed8 r8 : r7 : 7af51830 r6 : 7efd3f54 r5 : 7efdb9b8 r4 : 7efdb9b8 r3 : r2 : r1 : ea16 r0 : 7efdb9b8 Flags: nZcv IRQs off FIQs off Mode SVC_32 Code: e92dbd10 f8d045f0 b0858080 1000f8d8 (f8d14604) Resetting CPU ... It seems one needs some more commands when doing it inside boot.scr, or a different method. Or is the use of the envvar "nc" above maybe buggy: recursive definitions maybe? [I just followed the above u-boot doc] Is such an auto-start of netconsole possible at boot, and if yes how? Thx -- U.Mutlu ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Is running another .scr file from within boot.scr possible?
U.Mutlu wrote on 04/07/2019 08:05 PM: Hi, is it possible to exec another .scr file from within boot.scr ? Or is there another alternative to auto-run a different script file? The goal is to have different script files, one say for normal boot from SD, and the other say for booting from a tftp-server. Btw, is the interpreter that runs the boot.scr a sh/bash interpreter? Another question is: once boot.scr is started, is it still possible conditionally or unconditionally to return to the u-boot CLI prompt? ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] Is running another .scr file from within boot.scr possible?
Hi, is it possible to exec another .scr file from within boot.scr ? Or is there another alternative to auto-run a different script file? The goal is to have different script files, one say for normal boot from SD, and the other say for booting from a tftp-server. Btw, is the interpreter that runs the boot.scr a sh/bash interpreter? Thx -- U.Mutlu ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Booting from network
Chris Packham wrote on 04/07/2019 01:22 AM:
On Sun, 7 Apr 2019, 9:03 AM U.Mutlu, wrote:
I'm booting over the network (GbE) from a tftp server.
It works, but is IMHO very slow.
Is there a faster method for booting over the net?
TFTP is about as good as your going to get in u-boot right now.
Because TFTP sends a block at a time waiting for an ack between blocks it's
not going to be as fast as something that runs over TCP and benefits from
buffering.
One tunable you might get some use out of is $tftpblocksize, this will
increase the number of bytes per block. Try setting this to around 1400
keeping the overall Ethernet frame under 1518.
After attaching a monitor to the device, I now can see that
the cause is that sometimes the tftboot (or tftp) command fails,
but the script continues... Ie. there is missing some evaluation/test
of the return code of the command.
One better should do it in a loop with n retries. I've yet to read
in u-boot documentation on how one can do such tests in the script.
boot.cmd:
dhcp 0x4900
tftpboot 0x4600 192.168.1.201:uImage
tftpboot 0x4900 192.168.1.201:u-boot.dtb
setenv bootargs console=ttyS0,115200 root=/dev/sda1 rootwait panic=10
rootfstype=ext4 rw ${extra}
bootm 0x4600 - 0x4900
Btw, in the above script, can I safely replace the addresses
with ${kloadaddr} and ${fdtaddr} ?
I wonder where these variables get set or obtained from.
(I saw these variables somewhere on the net, but there was no
initialisation,
so I assumed it must be something internal/intrinsic, right?)
To my knowledge the only intrinsics are $loadaddr, $fileaddr and $filesize.
The latter two are set after a successful load. However plenty of boards
have $fdtaddr etc in their default environment so you might have acces to
those depending on your board.
I now see that the u-boot commands "bdinfo" and "printenv" do print such infos.
I haven't grasped yet if that info is persistent, or initialized each time
by u-boot, but it seems there could be some persistent store beyond uSD
on the device.
My device is Banana Pi R1 (aka BPi-R1 or Lamobo R1). I'm relatively new
to this board, and also generally to these Raspi-like small devices.
It's IMO a nice PC-like dual-core ARMv7-A20 1GHz 32bit board with GbE router &
switch capabilities,
but I have one major problem with this board: the SSD (SATA2 3Gbps AHCI)
write-speed is only about 52 MB/s (read-speed is about 200 MB/s).
I try to find out which component is responsible for the slow write-speed:
is it the SATA driver (ahci-sunxi[1c18000.sata]), or other components (HW or
SW)?
How could one best encircle/pinpoint this SATA specific problem-source?
root@r1-3:/tmp# dmesg | grep -i "sata\|ahci"
[5.485336] ahci-sunxi 1c18000.sata: Linked as a consumer to regulator.11
[5.592431] ahci-sunxi 1c18000.sata: controller can't do PMP, turning off
CAP_PMP
[5.599953] ahci-sunxi 1c18000.sata: SSS flag set, parallel bus scan disabled
[5.607139] ahci-sunxi 1c18000.sata: AHCI 0001.0100 32 slots 1 ports 3 Gbps
0x1 impl platform mode
[5.616118] ahci-sunxi 1c18000.sata: flags: ncq sntf stag pm led clo only
pio slum part ccc
[5.625664] scsi host0: ahci-sunxi
[5.629551] ata1: SATA max UDMA/133 mmio [mem 0x01c18000-0x01c18fff] port
0x100 irq 37
[5.963890] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
root@r1-3:/tmp# cat /proc/interrupts
CPU0 CPU1
...
37: 3330 2813 GICv2 88 Level ahci-sunxi[1c18000.sata]
...
And: though my board can output via HDMI, I've no monitor attached,
and a serial cable (TTY to USB) I don't have at the moment.
Is there another method to get the u-boot output (or log) to be sent to a
remote host/log?
I've never used in personally but CONFIG_NET_CONSOLE exists, I believe its
only good for output.
I'd still recommend getting a serial cable if your going to be playing with
u-boot becasue at some point you'll do something that stops your board from
booting.
Yes, I've already ordered such an adapter cable, will get it tomorrow or
tuesday.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] Booting from network
I'm booting over the network (GbE) from a tftp server.
It works, but is IMHO very slow.
Is there a faster method for booting over the net?
boot.cmd:
dhcp 0x4900
tftpboot 0x4600 192.168.1.201:uImage
tftpboot 0x4900 192.168.1.201:u-boot.dtb
setenv bootargs console=ttyS0,115200 root=/dev/sda1 rootwait panic=10
rootfstype=ext4 rw ${extra}
bootm 0x4600 - 0x4900
Btw, in the above script, can I safely replace the addresses
with ${kloadaddr} and ${fdtaddr} ?
I wonder where these variables get set or obtained from.
(I saw these variables somewhere on the net, but there was no initialisation,
so I assumed it must be something internal/intrinsic, right?)
And: though my board can output via HDMI, I've no monitor attached,
and a serial cable (TTY to USB) I don't have at the moment.
Is there another method to get the u-boot output (or log) to be sent to a
remote host/log?
Thx
--
U.Mutlu
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [sunxi/sun7i] ARMv7 SVC mode: PSCI not loaded and only 1st CPU core gets activated
Hi, when building u-boot for ARMv7 with these settings for SVC mode (ie. "Secure Mode"), instead of HYPervisor mode: ARM architecture ---> ... [*] Enable support for booting in non-secure mode [*] Boot in secure mode by default [ ] Enable support for hardware virtualization [*] Enable PSCI support (2) Maximum supported CPUs for PSCI [ ] Use LPAE page table format ... then only the first CPU core gets activated. How to bring the other core(s) online? I tried this from https://www.kernel.org/doc/html/v5.0/core-api/cpu_hotplug.html : # echo 1 > /sys/devices/system/cpu/cpu1/online bash: /sys/devices/system/cpu/cpu1/online: Permission denied (actually there is no "online" entry under cpu1, but also not under cpu0. Attached is the tree under /sys/devices/system/cpu/ ) # # Automatically generated file; DO NOT EDIT. # U-Boot 2019.04-rc4 Configuration ... CONFIG_SYS_ARCH="arm" CONFIG_SYS_CPU="armv7" CONFIG_SYS_SOC="sunxi" CONFIG_SYS_BOARD="sunxi" CONFIG_SYS_CONFIG_NAME="sun7i" ... CONFIG_DEFAULT_DEVICE_TREE="sun7i-a20-lamobo-r1" ... # uname -a Linux r1-3 5.0.5 #1 SMP Sat Mar 30 05:34:40 CET 2019 armv7l GNU/Linux kernel conf has CONFIG_HOTPLUG_CPU=y # dmesg | grep -i "smp\|psci\|started in" [0.00] Linux version 5.0.5 (u-ps@c22-local) (gcc version 9.0.1 20190326 (experimental) [trunk revision 269955] (GCC)) #1 SMP Sat Mar 30 05:34:40 CET 2019 [0.004154] smp: Bringing up secondary CPUs ... [0.004753] smp: Brought up 1 node, 1 CPU [0.004766] SMP: Total of 1 processors activated (48.00 BogoMIPS). [0.004772] CPU: All CPU(s) started in SVC mode. (ie. this means that PSCI is not loaded b/c otherwise there would be some "psci" lines in the log) # lscpu Architecture: armv7l Byte Order:Little Endian CPU(s):2 On-line CPU(s) list: 0 Off-line CPU(s) list: 1 Thread(s) per core:1 Core(s) per socket:1 Socket(s): 1 Model name:ARMv7 Processor rev 4 (v7l) CPU max MHz: 960. CPU min MHz: 144. See also: - http://linux-sunxi.org/PSCI https://www.kernel.org/doc/Documentation/devicetree/bindings/arm/psci.txt According to this page https://falstaff.agner.ch/2016/07/03/u-bootlinux-and-hyp-mode-on-armv7/ it seems in older u-boot versions it did activate all CPUs in SVC mode: " Brought up 2 CPUs SMP: Total of 2 processors activated (96.00 BogoMIPS). CPU: All CPU(s) started in SVC mode. " /sys/devices/system/cpu/ ├── cpu0 │ ├── cpu_capacity │ ├── cpufreq -> ../cpufreq/policy0 │ ├── hotplug │ │ ├── fail │ │ ├── state │ │ └── target │ ├── of_node -> ../../../../firmware/devicetree/base/cpus/cpu@0 │ ├── power │ │ ├── autosuspend_delay_ms │ │ ├── control │ │ ├── pm_qos_resume_latency_us │ │ ├── runtime_active_time │ │ ├── runtime_status │ │ └── runtime_suspended_time │ ├── subsystem -> ../../../../bus/cpu │ ├── topology │ │ ├── core_id │ │ ├── core_siblings │ │ ├── core_siblings_list │ │ ├── physical_package_id │ │ ├── thread_siblings │ │ └── thread_siblings_list │ └── uevent ├── cpu1 │ ├── cpu_capacity │ ├── cpufreq -> ../cpufreq/policy0 │ ├── hotplug │ │ ├── fail │ │ ├── state │ │ └── target │ ├── of_node -> ../../../../firmware/devicetree/base/cpus/cpu@1 │ ├── power │ │ ├── autosuspend_delay_ms │ │ ├── control │ │ ├── pm_qos_resume_latency_us │ │ ├── runtime_active_time │ │ ├── runtime_status │ │ └── runtime_suspended_time │ ├── subsystem -> ../../../../bus/cpu │ └── uevent ├── cpufreq │ ├── policy0 │ │ ├── affected_cpus │ │ ├── cpuinfo_cur_freq │ │ ├── cpuinfo_max_freq │ │ ├── cpuinfo_min_freq │ │ ├── cpuinfo_transition_latency │ │ ├── related_cpus │ │ ├── scaling_available_frequencies │ │ ├── scaling_available_governors │ │ ├── scaling_cur_freq │ │ ├── scaling_driver │ │ ├── scaling_governor │ │ ├── scaling_max_freq │ │ ├── scaling_min_freq │ │ ├── scaling_setspeed │ │ └── stats │ │ ├── reset │ │ ├── time_in_state │ │ ├── total_trans │ │ └── trans_table │ └── schedutil │ └── rate_limit_us ├── cpuidle │ ├── current_driver │ └── current_governor_ro ├── hotplug │ └── states ├── isolated ├── kernel_max ├── modalias ├── offline ├── online ├── possible ├── power │ ├── autosuspend_delay_ms │ ├── control │ ├── runtime_active_time │ ├── runtime_status │ └── runtime_suspended_time ├── present └── uevent 20 directories, 63 files ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] bug "missing clock-frequency property" (sunxi/sun7i)
Hi, I used the latest u-boot version via "git clone git://git.denx.de/u-boot.git u-boot/" and built using Lamobo_R1_defconfig. After copying the u-boot-sunxi-with-spl.bin to the boot device with these commands: dd if=/dev/zero of=/dev/mmcblk0 bs=1k count=1023 seek=1 dd if=u-boot-sunxi-with-spl.bin of=/dev/mmcblk0 bs=1024 seek=8 sync and rebooting the device, the kernel writes the following errors to the logfile: [0.049630] /cpus/cpu@0 missing clock-frequency property [0.049647] /cpus/cpu@1 missing clock-frequency property How to fix this? Thx my build script: ... make -s ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- mrproper makeARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- Lamobo_R1_defconfig makeARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- # # Automatically generated file; DO NOT EDIT. # U-Boot 2019.04-rc4 Configuration ... CONFIG_SYS_ARCH="arm" CONFIG_SYS_CPU="armv7" CONFIG_SYS_SOC="sunxi" CONFIG_SYS_BOARD="sunxi" CONFIG_SYS_CONFIG_NAME="sun7i" ... CONFIG_DEFAULT_DEVICE_TREE="sun7i-a20-lamobo-r1" ... -- U.Mutlu ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] Does u-boot end itself after starting the kernel?
Hi, the bootloader, here u-boot, starts the kernel. Is u-boot still active (ie. in a running state) after it starts the kernel? platform: ARMv7-a Thx ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
