Ok, then we better leave a huge kernel partition so that future version as they grow bigger wont have issues as without auto resizing dynamic "ubi" it cant be resized easily in the future.
So I am thinking 8MB+
We are now reaching a phase where pernament flashing is almost possible
@adron Better use my branch for testing images as most of the stuff is now personalized for RB450Gx4 including networking config(Even damn MACs match) but I cant get first port to be WAN, stubbornly port5 is always WAN
root@OpenWrt:/tmp# ubiformat /dev/mtd0 -y -f kernel
ubiformat: mtd0 (nand), size 16777216 bytes (16.0 MiB), 64 eraseblocks of 262144 bytes (256.0 KiB), min. I/O size 4096 bytes
libscan: scanning eraseblock 63 -- 100 % complete
ubiformat: 46 eraseblocks have valid erase counter, mean value is 2
ubiformat: warning!: 18 of 64 eraseblocks contain non-UBI data
ubiformat: warning!: only 46 of 64 eraseblocks have valid erase counter
ubiformat: mean erase counter 2 will be used for the rest of eraseblock
ubiformat: use erase counter 2 for all eraseblocks
ubiformat: error!: file "kernel" (size 4515692 bytes) is not multiple of eraseblock size (262144 bytes)
error 0 (No error information)
And one more oddity. How much I have not tried with different kernel images, I always get the final ubi file multiple of 262144. Perhaps your file is not completely transferred to the target system?
I ubiformated /dev/mtd0 but still it looks the generated kernel image is not correct
root@OpenWrt:/tmp# ubiformat /dev/mtd0 -y -f /tmp/kernel
ubiformat: mtd0 (nand), size 16777216 bytes (16.0 MiB), 64 eraseblocks of 262144 bytes (256.0 KiB), min. I/O size 4096 bytes
libscan: scanning eraseblock 63 -- 100 % complete
ubiformat: 64 eraseblocks have valid erase counter, mean value is 2
ubiformat: error!: file "/tmp/kernel" (size 4515692 bytes) is not multiple of eraseblock size (262144 bytes)
error 0 (No error information)
Used the wrong image, should have used the .ubi image in /ubi folder
Also, we need to adjust the size of generated kernel image as its per stock partition of 8MB and we are using 16MB
Yes of course.
img-3521347800_0.ubifs is a ubifs filesystem for Kernel partition.
img-3521347800.ubi is a ubi partitions image and it should have been used for ubiformat.
With .ubi image it boots fine.
Now all that is left is figuring out how to permanently manage and install OpenWrt without kernel using ramfs all the time
For this you need a aux-bootloader integrated into openwrt. I will soon finish my bootloader and then return again to the issue of installation and booting from a flash drive.
Finally got the damn SD card slot working, had to use modified versions of SDHCI driver and never upstreamed LDO driver for the SD IO.
Still spews some warning stacks but detects the card
@chunkeey Have you had any luck with sdhci-msm driver?
I have been at it whole day and still havent got it to work.
There are couple of stack warning traces with the modified QCA driver and upstream one, but upstream one does not respect max-frequency at all and will at all cost try to force 400MHz which of course will fail.
But I forced 192MHz as clock as that works with QCA driver and there are no errors anymore but no SD card is detected.
This is now looking as voltage regulator issue as QCA driver has SD LDO GPIO which it pulls high on initialisation.
From 924f8445e1a7487c3908f1f58899592eec564a3b Mon Sep 17 00:00:00 2001
From: Robert Marko <robimarko@gmail.com>
Date: Fri, 15 Feb 2019 16:59:56 +0100
Subject: [PATCH] Fix clock to 192MHz
Signed-off-by: Robert Marko <robimarko@gmail.com>
---
sdhci-msm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mmc/host/sdhci-msm.c b/drivers/mmc/host/sdhci-msm.c
index 8594659..188c711 100644
--- a/drivers/mmc/host/sdhci-msm.c
+++ b/drivers/mmc/host/sdhci-msm.c
@@ -331,7 +331,7 @@ static void msm_set_clock_rate_for_bus_mode(struct sdhci_host *host,
struct clk *core_clk = msm_host->bulk_clks[0].clk;
int rc;
- clock = msm_get_clock_rate_for_bus_mode(host, clock);
+ clock = 192000000;
rc = clk_set_rate(core_clk, clock);
if (rc) {
pr_err("%s: Failed to set clock at rate %u at timing %d\n",
--
2.20.1
On RouterOS via jailbreak we can see this:
cat /sys/kernel/debug/gpio
GPIOs 0-151, msmgpio.3:
gpio-0 (power-led ) out hi
gpio-2 (beeper.9 ) out lo
gpio-3 (user-led ) out lo
gpio-5 (button ) in hi gpio-33 (sd-ldo-gpios ) out hi
gpio-34 (spi_cs1 ) out hi
gpio-41 (poe-status ) in lo
gpio-42 (poe-on
Yeah, I know that GPIO33 Is supposed to start the LDO but it makes no difference if I export it HIGH or LOW.
QCA driver internaly switches the GPIO HIGH.
QCA driver has a lot of differences but main issue is that upstream driver does not respect max frequency binding and does not have property to list available frequencies as IPQ4019 uses 192 and 384 MHz instead of 200 or 400 MHz that driver is trying to force.
No, I dont think that FIT is critical at all for these devices.
Its simply used as U-boot supports it so its the easiest way of getting them to boot.
But since Mikrotik does not use U-boot its not important and legacy image is fine.
I solved a problem. The performance drop was caused by the CPU D-Cache turned off. Now unpacking takes 2 seconds (1.5 seconds faster than with the uImage).