Mainline development for mt6735

[alifilhan0]

Hello, it seems like a great effort. Sorry, it's a huge message but I had and have a lot to say about the topic, so it's a request to read it.

My goal was also something similar, using only modem and wifi code from downstream kernel and rest from the mainline kernel. Establish a new free bootchain by updated ATF(Arm-Trusted-Firmware), OP-TEE as the new TEE OS, U-Boot replacing LK totally. Then running standard linux and mainstream android on my device....it's MT6735 btw. For all the work I have done and thought about doing later, I just compared how MT6797's basic parts were available mainline was relatedto the downstream kernel sources, and collected some datasheets from various chinese websites to facilate my work(I have NO intentions of sending them upstream since I am no programmer or familiar with linux's mainline coding style). It would be great we could share whatever we both know and I might learn something even more new. I already have solutions for updated ATF, OP-TEE so I consider it done(For ATF I have MT6735 source code v1.0 and I think it would be very easy to integrate it with the mainline ATF code(not upstreaming it though. And for the TEE OS, it has support for MT8173. MT8173 and MT6735 should work exactly similar in the OP-TEE, as I have compared their base registers and found them to be exactly same). My current progress is on U-Boot, added pwrap for MT6735(inspired from SPMI in Qualcomm, but what I wrote is VERY MT6735 specific an just basically a scrapped version from linux kernel PWRAP), UART, SD, PWM, CLK, PINCTRL, all of them are done. Now adding regulator support for MT6328 following how da9063 is supported.

On linux kernel, I also wrote PINCTRL, CLK, SD, PWRAP, SCPSYS, UART, I2C, AUXADC, PWM, MT6328 regulator and many more. Got huge help from your mainlining notes, thank you very much for that. I will start uploading on github properly once I am done working on U-Boot at least :). But the problem is I have to do all these alone, with no one of great high skills to help, so that when I get stuck badly, it takes days to solve a complex problem.

Looking on to your work, it looks serious. Do you have a clock driver for MT6577? I compared MT6797, MT8173 and many more's downstream clkmgr and found some theories, the PLL registers are just the base addresses like ARMPLL_CON0 is the enreg etc. name of clocks and how many clocks should be on the clk-mt6577.c file are in the mt_clock_manager.c right? As for the PWRAP on most other MTK SoCs, you may not need it because it works over i2c, the fuelgauge driver(if ever needed) is very similar to 88pm860x-battery.c. For me, I had to add pwrap support for the MT6735, then scrap MT6323 and MT6359's regulator drivers to form the MT6328's regulator drivers. Then added MFD support for MT6328 following MT6323.......I think if we just add support lscrapping drivers for similarly available hardware, it should work right? I am here just for learning myself....but would be more than happy to know if I could help.

Finally, messaging in the github's issues is very annoying isn't it? Do you have any more convenient place to talk? Like some social media or something?

[arzam16]

^ I don't know why GH says these commits referenced your message :D

Hi, I'm happy to learn about more people working on Mediatek devices! I see that you are working on a Denali Family SoC (mt6735) and mt6577 differs so much that I won't be able to help you using knowledge I gained while working on it, and I will explain why:

1. mt6577-like SoC family (which includes mt6515, mt6575, mt6517, mt6577, mt8317, mt8377) are 32-bit Cortex-A9 processors from 2010~2013 and their BSPs were based on the ancient custom mediatek structure. Some code from the mediatek part of the kernel contains code from 2009 and even earlier. Right back to when mtk was nothing more than a DVD Player chip manufacturer XD (just kidding)

updated ATF(Arm-Trusted-Firmware), OP-TEE as the new TEE OS

2. mt6577 is so old it doesn't seem to use all of this...

U-Boot replacing LK totally

Weird, where did you see LK on Mediatek? I thought all mtks rely on UBoot. The only occurrences of LK I saw were in SP Flash Tool and in the appropriate scatter files.

My current progress is on U-Boot
Yikes, I decided to not touch it for as long as possible... mt6577 seems to be using heavily customized UBoot. In some rare occasions where I had to do something about UBoot I resorted to reversing it in Ghidra and making small binary patches. For example, to disable NCP1851 output which was waaaaay too verbose. And to prolong the watchdog timeout when it wasn't yet supported in Linux kernel. Compiling UBoot for old mtks is a great PITA, according to 4PDA.

On linux kernel, I also wrote PINCTRL, CLK, SD, PWRAP, SCPSYS, UART, I2C, AUXADC, PWM, MT6328

It sounds super great, I'm eager to see your code for mt6328. My device has an mt6329 PMIC and judging by the downstream code it uses multiple ways to communicate with a CPU. At the very least I notices mentions of I2C (PMIC is sitting at some address on the first I2C bus) and DVFS (CPU and PMIC are communicating over 2 pins by reading/writing various registers). I haven't touched the power management subsystem yet to form an educated opinion on it.

Got huge help from your mainlining notes, thank you very much for that

Thanks for your kind words, I'm very happy to learn about I've helped someone by sharing such a specific knowledge :D

I have NO intentions of sending them upstream since I am no programmer or familiar with linux's mainline coding style

I have no desire to send my mt6577 stuff to mainstream, too, but for other reasons (maybe one day I will have some balls to actually say it on LKML haha) as I am repelled by some nuances. I enjoy programming but my primary language is not C and its derivatives so I struggle a lot sometimes. Linux coding style is very well documented btw, and speaking of code formatting you can easily point clang-format at the code you wrote to get it properly formatted.

But the problem is I have to do all these alone, with no one of great high skills to help, so that when I get stuck badly, it takes days to solve a complex problem

Don't worry mate, it takes experienced Mediatek developers more than a year to half-ass address the I2C driver issue. Fyi I've been trying to ask them just a DMA register address required for I2C driver as neither mt6577 datasheet nor genuine BSPs had it. I did several attempts but none of them were successive. Sometimes I feel like @mbgg is the only sane and helpful and generally awesome person on linux-mediatek mailing list.

While the code in this repository looks sort of fresh (mainly because of rebases and force pushes) I must say I've been writing it since ~April 2020. I've had some free time when the first Covid restrictions took place in my country and I decided to dive into Linux kernel to see how deep could I go. Back then I knew absolutely nothing and now I have some basic knowledge which is definitely cool. Currently I don't have a lot of free time and to be honest I've been slowly losing my interest in this small project. I'm returning to it every month or so for maybe an hour and that's all :D

Do you have a clock driver for MT6577?

No :( As I said above, Mediatek was still relying on the ancient code even in their v3.4.x kernels when the modern Linux clock subsystem we know today was introduced. On downstream, all PLLs and clocks are fired up all together at boot in the according driver. And the normal linux clock driver is just....... well, see it yourself. Porting mt_clock_manager to mainline is impossible because it's proprietary so the only way is to write it from scratch which is painfully impossible, to say the least.

how many clocks should be on the clk-mt6577.c file are in the mt_clock_manager.c right?

Well, almost ;) Here's the complete list of clocks.

and collected some datasheets from various chinese websites to facilate my work [...] Finally, messaging in the github's issues is very annoying isn't it? Do you have any more convenient place to talk? Like some social media or something?

I don't have any social media accounts per se, and you can reach me on Matrix. My Matrix username is written on my Github profile below my avatar.

[Tooniis]

@alifilhan0 I worked on MT6737T on a Galaxy Grand Prime+ which is pretty much the same. I looked into replacing the stock ATF since on this device it appears to be somewhat broken and isn't able to boot 64-bit Linux. The stock bootloader is also broken and can't properly load an initramfs. However, secure boot has made it impossible to do anything so far. I tried using an exploit with bypass_utility, and it supposedly was able to disable secure boot, but I would get stuck in BROM after using it, and a reboot restores secure boot. SP flash tool also doesn't work on this device, and my guess is that Samsung disabled it since they provide their own Odin, but I couldn't risk flashing anything with it since it is part of the bootloader, and if I were to get the device stuck in an earlier stage, say in BROM or preloader because of a signature mismatch or something else after flashing a modified ATF, then I'd basically have a brick in my hands.

Weird, where did you see LK on Mediatek? I thought all mtks rely on UBoot. The only occurrences of LK I saw were in SP Flash Tool and in the appropriate scatter files.

@arzam16 they do use LK on MT6735, and possibly newer SoCs as well.

[alifilhan0]

@Tooniis , The device not booting Linux 64, you mean booting a downstream kernel compiled for 64 bit or any attempt like these? I expected these errors already, maybe a better ATF would solve it? I For what I have seen, the LK will show header errors when loading a BOOTIMAGE that doesn't satisfy the peculiar requirements in these LK bootloaders to be loaded. that is why I started working in U-Boot. It did show header image problems when I tried the same. I think we need a new bootloader in this device. For preloader you could try using source codes from BSPs with the same chip and same memory configuration and flash it with SP Flash? So far ATF and LK replacement is a must if we want to advance further.

@arzam16 , MT6329 actually uses an I2C interface, and in terms of working, it is similar to MT6311. For older ancient codebase, I also have a MT8382, basically a MT6582 without a modem, and did work on it too. There seems to be available BSPs on GitHub no matter how old and crappy they are, info is always useful. And I may be wrong, but I have seen LK on all possible MTK chips that have PWRAP, no matter how old they are, and most I2C PMIC based chips had U-Boot. For example, the MT6582, MT6572 I saw LK for them too, at least MT6582 never had any U-Boot where MT6572 may have. And yes, there are LK versions of MT6577, have a look at here https://github.com/gallants/acer-e350s-aa66/tree/master/bootable/bootloader/lk/build-aa66/platform/mediatek/mt6577

These older chips running 32 bits wouldn't have a ATF, so yes, your chip doesn't need it. But it is compulsory if you see into 64 bits, and I think PLL is easy, the ****PLL_CON0 is enreg and so on.

A bit of off-topic
To be honest, I don't have much knowledge either. But I compared downstream and upstream versions of codes for available MTK chips and it took me this far. The idea of PLL having CON0, CON1 as enreg, pwr_reg etc also came from MT6797. And I guess if you need some datasheets, yiniu dot net(you know these right ;-) ) is a good place but I don't know if these could be useable mainline. Their system of knowledge sharing is buying and selling info and datasheets for some small price......in that site I mentioned, RD coins (But it is just totally free, logging and replying gives RD coins).....an if you need such datasheets I could get some.

[Tooniis]

@alifilhan0 I meant booting a 64-bit mainline kernel. The vendor kernel is 32-bit, but this SoC has armv8 CPUs so it would've been able to boot a 64-bit OS if it weren't for the broken ATF that can't switch the normal world to 64-bit mode. I don't think a 32-bit port for a SoC with armv8 CPUs would be accepted in Linux upstream, so I'm inclined to make 64-bit boot work. PSCI is also missing from the stock ATF, so that's another thing that can be improved with a modified ATF.

For preloader you could try using source codes from BSPs with the same chip and same memory configuration and flash it with SP Flash? So far ATF and LK replacement is a must if we want to advance further.

As I said, SP flash tool doesn't work on this device, so the only way to flash a preloader probably would be to dd it from linux or use odin/heimdall if it allows flashing that, and I'd have one shot with either one, so if I screw it up I'd brick the device.

[alifilhan0]

@Tooniis , You have ATF source code? I have them from Orange Pi 4G IoT BSP....It is for MT6737 and MT6735 at the same time since they are exactly similar (Except for the fact that MT6737 is just a slower clocked and has an updated Modem).

So, what I was thinking that MT8173 has really good support from the linux kernel, ATF and whatnot......so I thought of updating the ATF using my source code but following how mt8173 is added in ATF. But, the source tree for the ATF and MT6735/MT6737 is exactly the same, structured properly

And since the vendor OS is 32 bit, it is totally expected by me that it wouldn't be able to run 64 bits, the ATF and LK/U-boot stuff may never shift the CPU properly to 64 bits. My device luckily, runs on full arm64 though.

[Tooniis]

@alifilhan0 I don't, but I extracted a binary from another MT6735 device that runs arm64 android from factory and I was planning to use that.

[arzam16]

@alifilhan0 ,

I think PLL is easy, the ****PLL_CON0 is enreg and so on

Every time I sit down and try to write anything for the clock driver, I usually quit after 10 minutes 😆

Clocks on fresh platforms look better than whatever mt6577 has. Taking a closer look at the mt6577 clock_manager thing reveals using various techniques for enabling PLLs: some need to enable a bit in a register, some need to disable a bit in a register, some need a special value written into a register.

Also, it was super hard to me to understand (I still haven't) how is each clock related to each other on my platform since modern Linux clock infrastructure requires specifying parents. Even with a PDF* with useful info I can't really adapt the old mt6577 code for the new infra because it seems to differ A LOT.

Well... or maybe I'm just lazy, or dumb, or just don't have enough time to understand it once and for all. I still haven't chosen an excuse for that 😅

The next subsystem on my imaginary "roadmap" after clocks is GPIO and I think it looks a bit easier.

an if you need such datasheets I could get some

Hey, thanks! 👍 *I can't say some things on this thread because I might want to upstream this code in future (and I would like it to be legally clear) but there are places where you can get a PDF and tons of genuine BSPs without any kind of coins required.

For this and any other matter you can HMU on matrix at any time. Worth mentioning, there are postmarketOS chats with a lot of members (most of them work on qcom tho), maybe you will be interested in joining? Me and @Tooniis are both there in the offtopic chat. And AFAIK some dudes in the lowlevel chat also worked on mtk in the past (I think mt626x stuff and running arbitrary code on the modem?), just saying

[alifilhan0]

@arzam16 Deducting how a clock was related may be the only option for now. Or other than that, it can be guessed by the clock names from the clock manager header right? I know it is not even close to enough, but at least it gives some of the clocks used by hardware........but the big issue remains, how the PLLs were divided. For example, how many Xpll_d**, Xpll**_d** (where ** are numbers, X is like main, univ, sys, etc) are there and what is their parent PLL. On these, I don't think even any datasheet can help.

@Tooniis But the risk of being bricked for flashing another ATF still remains, or does it not?

[alifilhan0]

It sounds super great, I'm eager to see your code for mt6328.
@arzam16

I have some initial work done on u-boot in my u-boot repo.....interested in reviewing it?
alifilhan0/u-boot@06bf2da
I know this is just a mess of codes, but since I won't send it mainline, only I care is about it going up and working. But I have some even better work done on the Linux kernel for MT6328, which I will upstream later

[alifilhan0]

Update, this is my almost ready to test condition, added wrapper, regulator and usb-otg mode from scratch and borrowed code for rest peripherals from MT7623 and MT8516(observing datasheets). Only thing needed is to add different config options now(I just added obj-y += so that it is forced to compile and the error messages are found off the bat)

alifilhan0/u-boot@91a99d6

[ave4]

I have 2 tablets on mt6735 (and mt6328). Almost a year ago I tried to port the mainline to them, but I couldn't even enable uart. This is partly the blame for the curve bootloader in these devices. I would like to try your u-boot, but I see that it has voltage regulators, do I need to change the voltages to my own?

[alifilhan0]

@ave4 When writing almost ready I completely forgot about the part that these MTK devices MUST go through the preloader. And the preloader need some mtk header appended to the bootloder image to be loaded. U boot for MT7623 already follows that method and adds headers to the image and I need to follow the same for this build too. I will start work that tomorrow and let you know when it is done.

So for now until header problem is solved, if you want to test boot(which is the only way available too) the bootloader, just replace the kernel image with this u-boot.bin and repact, and then fastboot boot boot.img. You can thus test u-boot safely and then revert back to android by just rebooting again. (I think you know more in this regard). Moreover, can I know how and why you faced the UART problem you mentioned? If you tried to get some console on the downstream firmware, it is disabled for the kernel and is mapped to other UARTs(those not mapped on the PCB) for preloader and LK I don't know why but this was actually the case with many devices

As for the regulators, you can change them. It is better to follow the downstream device tree voltages if you want to change it. But the thing is, the driver along with the PWRAP controller was written by me from scratch. So it needs some testing. For now, just assuming the code will work and working on adding the POWER button turn off feature for uboot

[Tooniis]

just replace the kernel image with this u-boot.bin and repact, and then fastboot boot boot.img.

This will probably become the common way to install it. Using U-Boot as a secondary bootloader should be possible even on devices with secure boot enabled and no known way of disabling it or working around it, and on devices with broken/non-existent fastboot, you get a working fastboot interface as a bonus :)

I'll probably give it a shot on my device. Booting 32-bit mainline Linux is still much better than nothing.

[alifilhan0]

@Tooniis, mind you though....i would recomend it to test boot using fastboot boot boot.img only, without any flashing involved, reverting back to thr safe old android then is just a reboot away. And I am still looking for a way to totally disregard the crappy LK these devices are shipped with, maybe the header problem will fix the issue.

[alifilhan0]

@ave4 @Tooniis Is there a known fix to the secure boot problem? I saw many sites providing bypass utilities and tools like this one https://forum.hovatek.com/thread-37957.html . Is this what we're looking for? The bypass_utility @Tooniis shared looks interesting. But don't you have the DA file for your model? The stock factory firmware archive don't contain it?

As for the U-Boot update, I am currently working on a config.h file for the test device. The bootloader image header problem does need some insights.

[arzam16]

@alifilhan0 I might be wrong but IIRC the MTK-bypass/bypass_utility didn't work for @Tooniis because the bootloader of his device is kinda weird.

Also it's not cool for me to speak for him but I definitely can remember us discussing something about the MTK-bypass not working in the past

[arzam16]

I changed the issue title to something more informative as it's not really related to mt6577 but definitely worth discussing in my opinion.

[alifilhan0]

I changed the issue title to something more informative as it's not really related to mt6577 but definitely worth discussing in my opinion.

@arzam16 This thread looks more like a discussion thread than informing issues. Is this one disturbing all of your work? If I had a MT6577, I could help too. And after I finish u-boot on the MT6735, I am interested in trying out writing clock drivers for MT6577. The problem with the different bit combination you mentioned earlier is more or less present on almost all MTK SoCs(At least on my MT6735 and MT8382, MT6582 device sources) and might be related to the modem present. I got my hands on some modem source code and that's where my theories are coming from. And for initial stage, it may be like that we miss the modem clocks to try out normal enabling the PLLs and their derivatives. Only then thinking about how to pipe them to each peripheral. How was your approach and progress on the clock?

[arzam16]

Is this one disturbing all of your work?

Personally I have no complaints. Though other people who Watch the repository now and in the future will keep getting notified about Issue updates via email, and they might want to understand better what is being discussed.

How was your approach and progress on the clock?

I approached clock driver development a few times already. Mostly I just complained about how hard it is on various chats but in the meanwhile I tried the following:

1. Analyze downstream mt_clock_manager. This gave some super basic understanding of clocks on mt6577 and led to creation of arzam16/mt6577_clk_manager. That repository is nothing more than a cleaned up version of the original downstream clock manager. I removed the code which was unreachable on my device and reformatted it. At the very least, now I don't want to throw up after looking at it 😆

2. Read some SoC documentation. Frankly speaking, I expected the full clock infra diagram to be there which could've shown all the relations between them but bummer! Nevertheless, some useful bits are still there. For example, page №235 [1] has a table of what PLL could be used to drive a subsystem. A simple clock diagram is on page №236 [1]. Other fancy diagrams are on pages №237-239 [1] but I have no idea how to read it. An illustrated guide on page №245 [1] could also help but I have no idea how.

aaand that's it. As I said I don't have enough free time and currently I'm working on other projects while I can. But yeah I frequently catch myself thinking about that pesky clock driver.

[1] MT6577 HSPA Smartphone Application Processor datasheet v0.94 (24.07.2012)

[arzam16]

@ave4 ,

When I try to load uboot via fastboot boot

Wait, what? I don't think you're supposed to do this. I can't speak for mt6735 but on mt6577 uboot/lk could only be flashed with SP Flash Tool.

[alifilhan0]

@arzam16 , we are just trying to boot u-boot (chainloaded by LK) safely without bricking our devices. It is entirely possible. But what we might be missing is how MTK's boot images are packed. MT6577's U-Boot is wholly on another level which I dare not to speak of in terms of interacting with it XD. On that platform, yes it isn't possible, but it is with newer ones which at least use a device tree(or even if it is an old LK, I could try appending the dtb with bootloader itself and then give it a shot. No harm when the device is fine isn't it?)

@ave4 And we need the proper dtb for u-boot, that means, we may have to change the .dtb file from unpacked boot image as well. And if possible, rename both the uboot.bin and dtb into the old filenames. I will keep trying to get this to at least spit some lines. It would be great if you could look out something too. And in menuconfig, change CONFIG_DEBUG_UART_SHIFT from 0 to 2. Not necessary but should help since you also use that in your mt6735 linux kernel defconfig

[alifilhan0]

@ave4 , For now, I the only problem I can think of is the base address being wrong. Maybe changing them will work, but we need to know from which address boot.img is accessed. I am testing with TEXT_BASE = 0x40000000, and load addr 0x40080000(this one is not needed right at this moment)

Upd : When I try TEXT_BASE = 0x40000000, and ./mkbootimg --kernel=u-boot-dtb.bin --dt u-boot.dtb --output=u-boot.img --pagesize 2048 --base 0x40000000 --ramdisk=/dev/null --cmdline=""

I get invalid ramdisk address, overlaps with LK. So maybe it is close to the right address sets?

[alifilhan0]

@ave4, What do you think about this?

https://lists.denx.de/pipermail/u-boot/2020-August/424231.html

Before we make conclusions on where the base addresses and U-Boot Text base should be, I would like to see the full normal bootlog of your device. I mean just a normal boot containing the LK and Linux kernel UART log. My LK' UART is disabled(shielded to another UART port not mapped), only Linux kernel log is available so if you could help please.....

[ave4]

Hope this is enough:
mt6735.log

[alifilhan0]

@ave4 So, the conclusion is, The text base is 0x40080000. And just a before, you have to replace the kernel binary with u-boot-dtb.bin as you did earlier and got a reboot, just also replace the dtb binary with u-boot.dtb, and if still doesn't work then rename the new files as your replaced counterparts. Build with the new text base and select load addr 0x41000000, deselect CONFIG_POWER_MT6328. Let me know what happens

[ave4]

Changing text_base getting a lot of bind errors, changing load addr doesn't affect anything

[28680] create masp atag OK
[28680] tee_reserved_mem not supported
[28700] non_secure_sram not supported
[28700] [PROFILE] ------- boot_time takes 14603 ms -------- 
[LK_ENV]get_env hibboot
[LK_ENV]get_env resume
[28700] booting linux @ 0x40080000, ramdisk @ 0x44000000 (0)
[28700] [LEDS]LK: leds_deinit: LEDS off 
[28700] [LEDS]LK: red level is 0 
[28700] [LEDS]LK: green level is 0 
[28700] [LEDS]LK: blue level is 0 
[28700] DRAM Rank :2
[28700] DRAM Rank[0] Start = 0x40000000, Size = 0x20000000
[28700] DRAM Rank[1] Start = 0x60000000, Size = 0x1fec0000
[28700] cmdline: console=tty0 console=ttyMT0,921600n1 root=/dev/ram vmalloc=496M androidboot.hardware=mt6735 slub_max_order=0 slub_debug=O  lcm=1-jd9367_ips_qc_wxga_dsi_vdo fps=6043 vram=14352384 printk.disable_uart=0 bootprof.pl_t=1819 bootprof.lk_t=14603 boot_r[28700] lk boot time = 14603 ms
[28700] lk boot mode = 0
[28700] lk boot reason = power_key
[28700] lk finished --> jump to linux kernel 64Bit

[28700] 
[LK]jump to K64 0x40080000
[28700] smc jump
[ATF][     0.000000]save kernel info
[ATF][     0.000000]Kernel_EL2
[ATF][     0.000000]Kernel is 64Bit
[ATF][     0.000000]pc=0x40080000, r0=0x4e000000, r1=0x0
INFO:    BL3-1: Preparing for EL3 exit to normal world, Kernel
INFO:    BL3-1: Next image address = 0x40080000
INFO:    BL3-1: Next image spsr = 0x3c9
[ATF][     0.000000]el3_exit
alloc space exhausted
Error binding driver 'mt6735-clock-topckgen': -12
alloc space exhausted
Error binding driver 'mt6735-infracfg': -12
alloc space exhausted
Error binding driver 'mt6735-pericfg': -12
alloc space exhausted
Error binding driver 'mt6735-clock-apmixedsys': -12
alloc space exhausted
Error binding driver 'mtk_wdt': -12
alloc space exhausted
Error binding driver 'serial_mtk': -12
alloc space exhausted
Error binding driver 'serial_mtk': -12
alloc space exhausted
Error binding driver 'serial_mtk': -12
alloc space exhausted
Error binding driver 'mtk_pwrap': -12
Some drivers failed to bind
initcall sequence 00000000400db618 failed at call 00000000400901a8 (err=-12)
### ERROR ### Please RESET the board ###
[ATF][     0.000000]=> wdt_kernel_cb_addr=0, error before WDT successfully initialized. cpu 0
[ATF][     0.000000]=> regs->pc : 0x400d6c30
[ATF][     0.000000]=> regs->lr : 0x400d6c30
[ATF][     0.000000]=> regs->sp : 0x0
[ATF][     0.000000]=> Informations: pstate=600003c9, pc=400d6c30, sp=0
[ATF][     0.000000]regs->regs[1] = 0 
[ATF][     0.000000]regs->regs[2] = 11002000 
[ATF][     0.000000]regs->regs[3] = 11002014 
[ATF][     0.000000]regs->regs[4] = 20 
[ATF][     0.000000]regs->regs[5] = 0 
[ATF][     0.000000]regs->regs[6] = 4027f711 
[ATF][     0.000000]regs->regs[7] = 32 
[ATF][     0.000000]regs->regs[8] = 4027f870 
[ATF][     0.000000]regs->regs[9] = 0 
[ATF][     0.000000]regs->regs[10] = 0 
[ATF][     0.000000]regs->regs[11] = ffffffe0 
[ATF][     0.000000]regs->regs[12] = 6 
[ATF][     0.000000]regs->regs[13] = 1869f 
[ATF][     0.000000]regs->regs[14] = 4027f7bc 
[ATF][     0.000000]regs->regs[15] = 40107760 
[ATF][     0.000000]regs->regs[16] = 2 
[ATF][     0.000000]regs->regs[17] = 0 
[ATF][     0.000000]regs->regs[18] = 0 
[ATF][     0.000000]regs->regs[19] = 4027f8a0 
[ATF][     0.000000]regs->regs[20] = 400db658 
[ATF][     0.000000]regs->regs[21] = 0 
[ATF][     0.000000]regs->regs[22] = 400db618 
[ATF][     0.000000]regs->regs[23] = 0 
[ATF][     0.000000]regs->regs[24] = 0 
[ATF][     0.000000]regs->regs[25] = 0 
[ATF][     0.000000]regs->regs[26] = 0 
[ATF][     0.000000]regs->regs[27] = 0 
[ATF][     0.000000]regs->regs[28] = 0 
[ATF][     0.000000]regs->regs[29] = 0 
[ATF][     0.000000]regs->regs[30] = 4027f860 
[ATF][     0.000000]regs->regs[31] = 400d6c30 
[ATF][     0.000000]=> sp is NULL, skip stack dump
[ATF][     0.000000]=> wait until reboot...

[alifilhan0]

@ave4 this is at least some progress....we see u-boot executing. The load addr is just a useless value at this moment since we are not targeting kernels right off the bat, but I think it is good to keep it in a build that is being used/tested

The drivers not binding is wholly a different story. Need to change the memory allocated for u-boot binding the drivers. I may have done something wrong at setting other addresses while getting the text_base right.

[alifilhan0]

@ave4 , you could try increasing the size of CONFIG_SYS_MALLOC_F_LEN until you see different error messages. The message seems that u-boot exhausted out the memory allocated for it. Start from CONFIG_SYS_MALLOC_F_LEN 0x4000 and keep increasing it until something new comes

[ave4]

[LK]jump to K64 0x40080000
[26380] smc jump
[ATF][     0.000000]save kernel info
[ATF][     0.000000]Kernel_EL2
[ATF][     0.000000]Kernel is 64Bit
[ATF][     0.000000]pc=0x40080000, r0=0x4e000000, r1=0x0
INFO:    BL3-1: Preparing for EL3 exit to normal world, Kernel
INFO:    BL3-1: Next image address = 0x40080000
INFO:    BL3-1: Next image spsr = 0x3c9
[ATF][     0.000000]el3_exit
No serial driver found
[ATF][     0.000000]=> wdt_kernel_cb_addr=0, error before WDT successfully initialized. cpu 0
[ATF][     0.000000]=> regs->pc : 0x40081038
[ATF][     0.000000]=> regs->lr : 0x400d86bc
[ATF][     0.000000]=> regs->sp : 0x0
[ATF][     0.000000]=> Informations: pstate=800003c9, pc=40081038, sp=0
[ATF][     0.000000]regs->regs[1] = 0 
[ATF][     0.000000]regs->regs[2] = 11002000 
[ATF][     0.000000]regs->regs[3] = 11002014 
[ATF][     0.000000]regs->regs[4] = 1358 
[ATF][     0.000000]regs->regs[5] = 26c4 
[ATF][     0.000000]regs->regs[6] = 2a10 
[ATF][     0.000000]regs->regs[7] = 1324 
[ATF][     0.000000]regs->regs[8] = 2 
[ATF][     0.000000]regs->regs[9] = 40107768 
[ATF][     0.000000]regs->regs[10] = 0 
[ATF][     0.000000]regs->regs[11] = 1320 
[ATF][     0.000000]regs->regs[12] = 40277a4c 
[ATF][     0.000000]regs->regs[13] = 454 
[ATF][     0.000000]regs->regs[14] = 0 
[ATF][     0.000000]regs->regs[15] = 40107768 
[ATF][     0.000000]regs->regs[16] = 40107768 
[ATF][     0.000000]regs->regs[17] = 4009b848 
[ATF][     0.000000]regs->regs[18] = 0 
[ATF][     0.000000]regs->regs[19] = 40277ca0 
[ATF][     0.000000]regs->regs[20] = 13d621 
[ATF][     0.000000]regs->regs[21] = 186a0 
[ATF][     0.000000]regs->regs[22] = 989680 
[ATF][     0.000000]regs->regs[23] = 40107768 
[ATF][     0.000000]regs->regs[24] = 0 
[ATF][     0.000000]regs->regs[25] = 0 
[ATF][     0.000000]regs->regs[26] = 0 
[ATF][     0.000000]regs->regs[27] = 0 
[ATF][     0.000000]regs->regs[28] = 0 
[ATF][     0.000000]regs->regs[29] = 0 
[ATF][     0.000000]regs->regs[30] = 40277bc0 
[ATF][     0.000000]regs->regs[31] = 400d86bc 
[ATF][     0.000000]=> sp is NULL, skip stack dump
[ATF][     0.000000]=> wait until reboot...

[alifilhan0]

@ave4, This is U-Boot panic, for not matching the CONS_INDEX with the UART0 port for your build. By default, I selected it to one for my mapped uart is UART1. But this is the cause of the error. Deselect CONFIG_SPECIFY_CONSOLE_INDEX manually(it is selected by default no matter what) and build -> boot. By the way, how much Malloc did it need to get this far?

[Tooniis]

After adding configs to build 32-bit U-Boot, adding a device tree for my device, and some tinkering with UART and TEXT_BASE, I got a message from U-Boot to show up:

[ 4.106] lk finished --> jump to linux kernel 

serial_mtk serial@11003000: pinctrl_select_state_full: uclass_get_device_by_phandle_id: err=-19

Note that I am using UART0 (0x11002000) here.

[alifilhan0]

@Tooniis Umm, what? You are using serial 0x11002000 but that message came from UART1, 0x11003000. Pinctrl problem on UART1....And can you show a bigger log please, it helps greatly. And kindly, can I see your defconfig?

[Tooniis]

config.txt

The message came over UART0, and if I understand correctly it is saying that it failed to select a pinctrl state for UART1 for some reason.

Everything above lk finished --> jump to linux kernel is static LK and BROM output so I do not think it is useful, but here are some extra lines

[ 3.317] [IMG VER] ok
[ 3.319] Enter load_modem_image v2.0
[ 3.590] ver otp update success
[ 3.593] Warranty Bit Set - Blowing KAP_VIOLATION_FUSE
[ 3.604] KAP status = 5afe0003
[ 3.609] kernel size = 0x82000, ramdisk size = 0x119800
[ 3.655] Total boot size 1702144
[ 3.658] [TIMA trusted boot]: SEAndroid MAGIC failure (boot.img)
[ 3.669] [TIMA boot measurement] : Old/non-CL device - KNOX warranty void
[ 3.699] WB : Already SET 0x202, VER : G532FXWU1ASB1
[ 3.707] get_frp_image_status : will return type of 0 status = 1
[ 3.714] get_frp_image_status : will return type of 1 status = 1
[ 3.722] get_frp_image_status : will return type of 2 status = 0
[ 3.730] get_frp_image_status : will return type of 3 status = 0
[ 3.738] get_frp_image_status : will return type of 4 status = 0
[ 3.746] get_frp_image_status : will return type of 5 status = 0
[ 3.752] afw value = 0
[ 3.754] ================ ICCC INFO ================
[ 3.759] [ICCC] rp_ver = 0x1
[ 3.762] [ICCC] kernel_rp = 0x0
[ 3.764] [ICCC] system_rp = 0x0
[ 3.767] [ICCC] test_bit = 0x0
[ 3.770] [ICCC] sec_boot = 0x1
[ 3.773] [ICCC] react_lock = 0xffffffff
[ 3.777] [ICCC] kiwi_lock = 0xffffffff
[ 3.780] [ICCC] frp_lock = 0x0
[ 3.783] [ICCC] cc_mode = 0xffffffff
[ 3.786] [ICCC] mdm_mode = 0x0
[ 3.789] [ICCC] sysscope_flag = 0x1
[ 3.793] [ICCC] afw_value = 0x0
[ 3.796] [ICCC] image_status = 0x1, 0x1, 0x0, 0x0, 0x0, 0x0
[ 3.801] [ICCC] curr_bin_status = 0xb
[ 3.804] [ICCC] warranty_bit = 0x1
[ 3.807] [ICCC] kap_status = 0x0
[ 3.811] [ICCC] dmv_status = 0x0
[ 3.814] ===========================================
[ 3.818] iccc smc success!!! [ret = 1]
[ 3.822] ATAG_CORE: 5 54410001 0 0 0
[ 3.825] ATAG_MEM: 4 54410002 0x30000000 0x40000000
[ 3.830] ATAG_MEM: 4 54410002 0x8000000 0x70000000
[ 3.834] ATAG_MEM: 4 54410002 0x1300000 0x7cd00000
[ 3.839] ATAG_MEM: 4 54410002 0x18d0000 0x7e030000
[ 3.843] ATAG_MEM: 4 54410002 0x1f5c0000 0x80000000
[ 3.848] ATAG_INITRD2: 4 54420005 0x44000000 0x119800
[ 3.853] ATAG_REVISION: 3 54410007 5
[ 3.902] ATAG_CMDLINE: b6 54410009 'console=tty0 console=/dev/null,115200n1 printk.disable_uart=1 root=/dev/ram vmalloc=496M androidboot.sec_atd.tty=/dev/ttyMT0 androidboot.hardware=mt6735 lcm=1-s6d78a0_qhd_dsi_vdo fps=5971 vram=7340032 lcd_id=ID53b810 bootprof.pl_t=957 bootprof.lk_t=2653 sec_debug=0 sec_watchdog.sec_pet=5 fg_reset=0 androidboot.debug_level=0x4f4c androidboot.hw_rev=5 pmic_info=83 androidboot.serialno=92012371f4f335a3 androidboot.odin_download=1 androidboot.bootloader=G532FXWU1ASB1 sec_debug.reset_reason=9 cordon=e8066fd3474263967c52bc8920d985da connie=SM-G532F_SER_CIS_47d26d480d754e887b27b2126fd3c14f androidboot.warranty_bit=1 androidboot.selinux=enforcing sec_tima_log=0x200000@0x43b00000 androidboot.security_mode=1526595584'
[ 3.967] ATAG_NONE: 0 0
[ 3.972] [LK_BOOT] Load '<null>' partition to 0x41EADB74 (20 bytes in 1 ms)
[ 3.979] MEID : fa3c5f83d9ccc898e4fcff0488a354f6
[ 3.983] efuse value: ok
[ 4.20 ] DMV: Successfully informed TZ of boot mode: Normal
[ 4.25 ] WP 0x1, 0xb
[ 4.31 ] EXT_CSD_ERASE_GRP_DEF is Off, wp_size = 4MB, csd.write_prot_grpsz = 7,csd.erase_sctsz = 1024
[ 4.39 ] [mmc_decode_ext_csd]: mmc_set_wp_size 4MB
[ 4.44 ] set_wp_bootpartition (preloader): Success
[ 4.51 ] EXT_CSD_ERASE_GRP_DEF is Off, wp_size = 4MB, csd.write_prot_grpsz = 7,csd.erase_sctsz = 1024
[ 4.60 ] [mmc_decode_ext_csd]: mmc_set_wp_size 4MB
[ 4.64 ] [mmc_set_user_wp]: card->ext_csd.usr_wp:1
[ 4.69 ] [mmc_set_write_protect_by_group]: count_wp 10
[ 4.86 ] EXT_CSD_ERASE_GRP_DEF is Off, wp_size = 4MB, csd.write_prot_grpsz = 7,csd.erase_sctsz = 1024
[ 4.95 ] [mmc_decode_ext_csd]: mmc_set_wp_size 4MB
[ 4.100] set_wp_bootpartition (lk & others): Success
[ 4.104] lk boot mode = 0
[ 4.107] lk finished --> jump to linux kernel

serial_mtk serial@11003000: pinctrl_select_state_full: uclass_get_device_by_phandle_id: err=-19

[Tooniis]

Can we make a Matrix room? It would be more suited for discussion than a github issue.

[Tooniis]

I rebooted and captured the full log starting from BROM:

F0: 102B 0000
F3: 0000 0000
V0: 0000 0000 [0001]
00: 0000 0000
BP: 0000 0249 [0000]
G0: 0190 0000
T0: 0000 0153 [000F]
Jump to BL

READY[ATF][     0.000000]BL33 boot argument location=0x43e9d040
[ATF][     0.000000]BL33 boot argument size=0xd28
[ATF][     0.000000]BL33 start addr=0x41e00000
[ATF][     0.000000]teearg addr=0x101000
[ATF][     0.000000]atf_magic=0x4d415446
[ATF][     0.000000]tee_support=0x1
[ATF][     0.000000]tee_entry=0x9f600000
[ATF][     0.000000]tee_boot_arg_addr=0x101100
[ATF][     0.000000]atf_log_port=0x11002000
[ATF][     0.000000]atf_log_baudrate=0x1c200
[ATF][     0.000000]atf_log_buf_start=0x9f5c0000
[ATF][     0.000000]atf_log_buf_size=0x40000
[ATF][     0.000000]atf_aee_debug_buf_start=0x9f5fc000
[ATF][     0.000000]atf_aee_debug_buf_size=0x4000
[ATF][     0.000000]atf_irq_num=281
[ATF][     0.000000]BL33_START_ADDRESS=0x41e00000
[ATF][     0.000000]atf chip_code[321]
[ATF][     0.000000]atf chip_ver[0]
[ATF][     0.000000]###@@@ MP0_MISC_CONFIG3:0x00000000 @@@###
[ATF][     0.000000]###@@@ MP0_MISC_CONFIG3:0x0000e000 @@@###
[ATF][     0.000000]mmap atf buffer : 0x9f5c0000, 0x40000
[ATF][     0.000000]mmap atf buffer (force 2MB aligned): 0x9f400000, 0x200000
NOTICE:  BL3-1: v1.0(debug):
NOTICE:  BL3-1: Built : 16:25:09, Feb 11 2019
[ATF][     0.000000]sta=0x0 int=0xffc
[ATF][     0.000000]is_power_on_boot: true
[ATF][     0.000000]mt_log_setup - atf_buf_addr : 0x9f5c0100
[ATF][     0.000000]mt_log_setup - atf_buf_size : 0x2bf00
[ATF][     0.000000]mt_log_setup - atf_write_pos : 0x9f5c0100
[ATF][     0.000000]mt_log_setup - atf_read_pos : 0x9f5c0100
[ATF][     0.000000]mt_log_setup - atf_buf_lock : 0x0
[ATF][     0.000000]mt_log_setup - mt_log_buf_end : 0x9f5ebfff
[ATF][     0.000000]mt_log_setup - ATF_CRASH_LAST_LOG_SIZE : 0x8000
[ATF][     0.000000]mt_log_setup - ATF_EXCEPT_BUF_SIZE_PER_CPU : 0x1000
[ATF][     0.000000]mt_log_setup - ATF_EXCEPT_BUF_SIZE : 0x8000
[ATF][     0.000000]mt_log_setup - PLATFORM_CORE_COUNT : 0x8
[ATF][     0.000000]mt_log_setup - atf_except_write_pos_per_cpu[0]: 0x9f5f4000
[ATF][     0.000000]mt_log_setup - atf_except_write_pos_per_cpu[1]: 0x9f5f5000
[ATF][     0.000000]mt_log_setup - atf_except_write_pos_per_cpu[2]: 0x9f5f6000
[ATF][     0.000000]mt_log_setup - atf_except_write_pos_per_cpu[3]: 0x9f5f7000
[ATF][     0.000000]mt_log_setup - atf_except_write_pos_per_cpu[4]: 0x9f5f8000
[ATF][     0.000000]mt_log_setup - atf_except_write_pos_per_cpu[5]: 0x9f5f9000
[ATF][     0.000000]mt_log_setup - atf_except_write_pos_per_cpu[6]: 0x9f5fa000
[ATF][     0.000000]mt_log_setup - atf_except_write_pos_per_cpu[7]: 0x9f5fb000
[ATF][     0.000000]mt_log_setup - atf_crash_flag : 0x0
[ATF][     0.000000]mt_log_setup - atf_crash_log_addr : 0x0
[ATF][     0.000000]mt_log_setup - atf_crash_log_size : 0x0
[ATF][     0.000000]ATF log service is registered (0x9f5c0000, aee:0x9f5fc000)
[ATF][     0.000000]BL3-1: v1.0(debug):
[ATF][     0.000000]BL3-1: Built : 16:25:09, Feb 11 2019
INFO:    BL3-1: Initializing runtime services
[ATF][     0.000000][BL31] Jump to secure OS for initialization!
INFO:    BL3-1: Preparing for EL3 exit to normal world, LK
INFO:    BL3-1: Next image address = 0x41e00000
INFO:    BL3-1: Next image spsr = 0x1d3
[ATF][     0.000000][BL31] Final dump!
[ 1.263] *------------------------------------*
[ 1.267]  Samsung S-Boot 1.0 for Mediatek
[ 1.271]  Build time:Feb 11 2019, 16:24:32 
[ 1.275]  Board: SM_G532F Rev:5 
[ 1.278]  Chip_HW[0x321], Chip_SW[0x0]
[ 1.282] *------------------------------------*
[ 1.287] s2mu005_get_battery_detect: battery is present
[ 1.493] [MUIC] muic_id:0x005[ 1.495]  -> matched(s2mu005).
[ 1.514] s2mu005_get_cable_type : Return to cable_type : [0]
[ 1.519] aboot_dev_charging_init : cable_status(0) 
[ 1.526] s2mu005_get_battery_detect: battery is present
[ 1.531] aboot_dev_charging_init, [battery] batt_id_value (0)
[ 1.537] s2mu005_set_charger_state : en_buck = 1, en_chg = 0
[ 1.547] s2mu005_set_charger_state : S2MU005_CHG_CTRL0 : 0x12
[ 1.552] s2mu005_init_ific start 
[ 1.580] s2mu005_set_charging_current : S2MU005_CHG_CTRL7 : 0x26
[ 1.588] set_cool_charging_current : S2MU005_CHG_CTRL6 : 0x53
[ 1.598] s2mu005_get_cable_type : Return to cable_type : [0]
[ 1.604] s2mu005_set_auto_current: get_cable_type(0)
[ 1.617] s2mu005_set_auto_current: unknown_state, curr(500)
[ 1.625] s2mu005_set_input_current : S2MU005_CHG_CTRL2 : 0x08
[ 1.630] s2mu005_set_charger_state : en_buck = 1, en_chg = 1
[ 1.640] s2mu005_set_charger_state : S2MU005_CHG_CTRL0 : 0x12
[ 1.646] s2mu005_init_fuelgauge
[ 1.649] s2mu005_init_fuelgauge: POR state = 0x 0
[ 1.653] check_reboot_case: INFORM3 = 0 ... 
[ 1.664] s2mu005_get_cable_type : Return to cable_type : [0]
[ 1.674] check_dead_battery : rb=0, jig=1, ct=0, vcell=3675
[ 1.679] skip check low power
[ 1.775] EXT_CSD_ERASE_GRP_DEF is Off, wp_size = 4MB, csd.write_prot_grpsz = 7,csd.erase_sctsz = 1024
[ 1.784] [mmc_decode_ext_csd]: mmc_set_wp_size 4MB
[ 1.799] EXT_CSD_ERASE_GRP_DEF is Off, wp_size = 4MB, csd.write_prot_grpsz = 7,csd.erase_sctsz = 1024
[ 1.807] [mmc_decode_ext_csd]: mmc_set_wp_size 4MB
[ 1.818] EXT_CSD_ERASE_GRP_DEF is Off, wp_size = 4MB, csd.write_prot_grpsz = 7,csd.erase_sctsz = 1024
[ 1.827] [mmc_decode_ext_csd]: mmc_set_wp_size 4MB
[ 1.835] [SEC_CFG] sec_read_seccfg fail:3001
[ 1.838] [SEC_INIT] sec_func_init -- fail to search seccfg
[ 1.844] we will check lcm: s6d78a0_qhd_dsi_vdo
[ 1.848] [LK/LCM] lcm_init_power, LK 
[ 1.851] [LK/LCM] lcd_poweron, disable LK 
[ 1.860] [LK/LCM] lcd_poweron, enable LK 
[ 1.904] [LK/LCM] lcm_compare_id, LK 
[ 1.945] s6d78a0 lcd id is [0x53b810]!
[ 1.953] [LK/LCM] lcm_panel_reset, LK 
[ 1.982] [LK/LCM] lcm_init, LK 
[ 1.984] [LK/LCM] lcm_init_register, LK 
[ 2.135] eMMC SN: 92012371f4f335a3
[ 2.138] Persistent Blkstart = 55400
[ 2.141] Persistent blknum = 400
[ 2.150] sec_compare_rr_k:SRAM IS_R(0x4B69D3BD),R_R(0xC1A50F99)
[ 2.155] sec_check_reboot_mode: INFORM3 = 0 ... [ 2.160] skip
[ 2.161] boot_mode_select :pl->boot reason(0),mode(0),key(0)
[ 2.166] sec_check_upload: MAGIC(0x0), upload_code(0x0), SRAM_MAGIC(0xF853169C)
[ 2.175] sec_check_upload: debug level is LO! (mask: 0x1000)
[ 2.180] sec_check_download: INFORM2 = 0 ... 
[ 2.185] sec_check_download: 0
[ 2.188] PARAM_REBOOT_MODE: (10)
[ 2.191] boot_mode_select g_boot_mode=0 
[ 2.194] check_reboot_case: INFORM3 = 0 ... 
[ 2.204] s2mu005_get_cable_type : Return to cable_type : [0]
[ 2.213] check_lpm_mode: boot_reason= 0, boot_reason= 0, is_reboot_case = 0, cable_status = 0
[ 2.221] check_lpm_mode: INFORM2 = 0 ... 
[ 2.225] s2mu005_fuelgauge_reset_check
[ 2.231] s2mu005_detect_remove_battery: reg_data (0x0), reg_data1 (0x80), reg_data2 (0x81)
[ 2.240] s2mu005_fuelgauge_reset_check: POR state = 0x 0
[ 2.249] s2mu005_fuelgauge_reset_check: SOC(2012), VCELL(3675)
[ 2.271] s2mu005_get_current: rCUR_CC(0x 3b2)
[ 2.275] s2mu005_get_current: current (-231)mA
[ 2.282] s2mu005_get_soc_from_ocv: ocv (37230), soc (1392)
[ 2.291] s2mu005_fuelgauge_reset_check: SOC(2012), VCELL(3675)
[ 2.296] check_reboot_case: INFORM3 = 0 ... 
[ 2.305] s2mu005_get_cable_type : Return to cable_type : [0]
[ 2.319] check_low_battery : rb=0, jig=1, vcell=3675, soc=2012, charger_type=0
[ 2.326] skip check low battery
[ 2.328] AST_POWERON..
[ 2.413] [LK/LCM] lcm_setbacklight, LK 
[ 2.420] 
csmc_init called !!
[ 2.431] 
[BlowFish] register handler, ret = 0x0
[ 2.435] 
[BlowFish] execute handler, ret = 0x0
[ 2.441] s2mu005_get_battery_detect: battery is present
[ 2.445] [MUIC] rustproof mode Enabled
[ 2.682] [SBC] Verifying md1img, md1rom
[ 3.202] [SBC] Verification ok
[ 3.208] [SBC] Verifying md1dsp, md1dsp
[ 3.288] [SBC] Verification ok
[ 3.290] Check RP value,group0: 1 group1: 1
[ 3.300] [IMG VER] otp ver: 1
[ 3.303] [IMG VER] (group, img_ver, otp_ver) = (0x1, 0x1, 0x1)
[ 3.308] [IMG VER] ok
[ 3.316] [IMG VER] (group, img_ver, otp_ver) = (0x1, 0x1, 0x1)
[ 3.321] [IMG VER] ok
[ 3.323] Enter load_modem_image v2.0
[ 3.595] ver otp update success
[ 3.598] Warranty Bit Set - Blowing KAP_VIOLATION_FUSE
[ 3.609] KAP status = 5afe0003
[ 3.614] kernel size = 0x82000, ramdisk size = 0x119800
[ 3.660] Total boot size 1702144
[ 3.662] [TIMA trusted boot]: SEAndroid MAGIC failure (boot.img)
[ 3.674] [TIMA boot measurement] : Old/non-CL device - KNOX warranty void
[ 3.703] WB : Already SET 0x202, VER : G532FXWU1ASB1 
[ 3.711] get_frp_image_status : will return type of 0 status = 1
[ 3.719] get_frp_image_status : will return type of 1 status = 1
[ 3.727] get_frp_image_status : will return type of 2 status = 0
[ 3.735] get_frp_image_status : will return type of 3 status = 0
[ 3.743] get_frp_image_status : will return type of 4 status = 0
[ 3.750] get_frp_image_status : will return type of 5 status = 0
[ 3.757] afw value = 0
[ 3.759] ================ ICCC INFO ================
[ 3.764] [ICCC] rp_ver = 0x1
[ 3.766] [ICCC] kernel_rp = 0x0
[ 3.769] [ICCC] system_rp = 0x0
[ 3.772] [ICCC] test_bit = 0x0
[ 3.775] [ICCC] sec_boot = 0x1
[ 3.778] [ICCC] react_lock = 0xffffffff
[ 3.781] [ICCC] kiwi_lock = 0xffffffff
[ 3.785] [ICCC] frp_lock = 0x0
[ 3.788] [ICCC] cc_mode = 0xffffffff
[ 3.791] [ICCC] mdm_mode = 0x0
[ 3.794] [ICCC] sysscope_flag = 0x1
[ 3.797] [ICCC] afw_value = 0x0
[ 3.800] [ICCC] image_status = 0x1, 0x1, 0x0, 0x0, 0x0, 0x0
[ 3.806] [ICCC] curr_bin_status = 0xb
[ 3.809] [ICCC] warranty_bit = 0x1
[ 3.812] [ICCC] kap_status = 0x0
[ 3.815] [ICCC] dmv_status = 0x0
[ 3.818] ===========================================
[ 3.823] iccc smc success!!! [ret = 1]
[ 3.827] ATAG_CORE: 5 54410001 0 0 0
[ 3.830] ATAG_MEM: 4 54410002 0x30000000 0x40000000
[ 3.835] ATAG_MEM: 4 54410002 0x8000000 0x70000000
[ 3.839] ATAG_MEM: 4 54410002 0x1300000 0x7cd00000
[ 3.844] ATAG_MEM: 4 54410002 0x18d0000 0x7e030000
[ 3.848] ATAG_MEM: 4 54410002 0x1f5c0000 0x80000000
[ 3.853] ATAG_INITRD2: 4 54420005 0x44000000 0x119800
[ 3.858] ATAG_REVISION: 3 54410007 5
[ 3.907] ATAG_CMDLINE: b6 54410009 'console=tty0 console=/dev/null,115200n1 printk.disable_uart=1 root=/dev/ram vmalloc=496M androidboot.sec_atd.tty=/dev/ttyMT0 androidboot.hardware=mt6735 lcm=1-s6d78a0_qhd_dsi_vdo fps=5989 vram=7340032 lcd_id=ID53b810 bootprof.pl_t=962 bootprof.lk_t=2654 sec_debug=0 sec_watchdog.sec_pet=5 fg_reset=0 androidboot.debug_level=0x4f4c androidboot.hw_rev=5 pmic_info=83 androidboot.serialno=92012371f4f335a3 androidboot.odin_download=1 androidboot.bootloader=G532FXWU1ASB1 sec_debug.reset_reason=9 cordon=e8066fd3474263967c52bc8920d985da connie=SM-G532F_SER_CIS_47d26d480d754e887b27b2126fd3c14f androidboot.warranty_bit=1 androidboot.selinux=enforcing sec_tima_log=0x200000@0x43b00000 androidboot.security_mode=1526595584'
[ 3.972] ATAG_NONE: 0 0
[ 3.977] [LK_BOOT] Load '<null>' partition to 0x41EADB74 (20 bytes in 2 ms)
[ 3.983] MEID : fa3c5f83d9ccc898e4fcff0488a354f6
[ 3.988] efuse value: ok
[ 4.25 ] DMV: Successfully informed TZ of boot mode: Normal
[ 4.30 ] WP 0x1, 0xb
[ 4.35 ] EXT_CSD_ERASE_GRP_DEF is Off, wp_size = 4MB, csd.write_prot_grpsz = 7,csd.erase_sctsz = 1024
[ 4.44 ] [mmc_decode_ext_csd]: mmc_set_wp_size 4MB
[ 4.49 ] set_wp_bootpartition (preloader): Success
[ 4.57 ] EXT_CSD_ERASE_GRP_DEF is Off, wp_size = 4MB, csd.write_prot_grpsz = 7,csd.erase_sctsz = 1024
[ 4.65 ] [mmc_decode_ext_csd]: mmc_set_wp_size 4MB
[ 4.70 ] [mmc_set_user_wp]: card->ext_csd.usr_wp:1
[ 4.74 ] [mmc_set_write_protect_by_group]: count_wp 10
[ 4.93 ] EXT_CSD_ERASE_GRP_DEF is Off, wp_size = 4MB, csd.write_prot_grpsz = 7,csd.erase_sctsz = 1024
[ 4.101] [mmc_decode_ext_csd]: mmc_set_wp_size 4MB
[ 4.106] set_wp_bootpartition (lk & others): Success
[ 4.111] lk boot mode = 0
[ 4.113] lk finished --> jump to linux kernel 

serial_mtk serial@11003000: pinctrl_select_state_full: uclass_get_device_by_phandle_id: err=-19

[Tooniis]

I removed uart1/2/3 nodes, now I get this

[ 4.105] lk finished --> jump to linux kernel 

serial_mtk serial@11002000: pinctrl_select_state_full: uclass_get_device_by_phandle_id: err=-19
��!�m�}}&�pb��鮎0͝b-�
                  #N\�r]M����	��\b��&�ra�	��4r���B��f�`��i�a�
���]���r2R҈P���lr�                                                  ���e	$���M
Ma-!��-q-BRR�#\@ -��N�
    /�\���Bb
2餃��R��@�A-"�Sl^r@�

looks like it doesnt init uart0 properly or sets it to a different baud rate than what LK does which causes that garbled output.

[ave4]

@Tooniis What's your serial port speed? Mediatek has 921600 by default, but u-boot has 115200.

[Tooniis]

@ave4 115200

[Tooniis]

I've created a Matrix room if anyone is interested: https://matrix.to/#/#u-boot-mt6735:matrix.org

[alifilhan0]

@Tooniis I've looked into earlier issues first and I know MT7628 having similar problems regarding pinctrl. And in u-boot, before jumping to point, I am observing your LK and early log to be greatly different than MT6735 devices running 64 bit firmware by default, and the main problem with me is LK log is shielded to another port and thus I cannot get U-Boot logs either if I can't get further in the boot of this bootloader.

Now, CONFIG_SYS_TEXT_BASE=0x40004000, are you sure? I mean does your kernel load from this address? This address should be exactly the same as your kernel address loaded by LK since U-Boot here essentially pretends to be the kernel. Regarding the garbage output, either there is some baud rate mismatch or the clock I set(26 MHz) is wrong.

[alifilhan0]

@ave4 , have you tried deselecting CONFIG_SPECIFY_CONSOLE_INDEX? What's the output?

[Tooniis]

CONFIG_SYS_TEXT_BASE=0x40004000, are you sure? I mean does your kernel load from this address? This address should be exactly the same as your kernel address loaded by LK since U-Boot here essentially pretends to be the kernel.

@alifilhan0 Yes that is where the bootloader loads the kernel. It does not even print that pinctrl message with a different TEXT_BASE.

[alifilhan0]

@Tooniis , So for you 0x40004000 is correct. I am very unfamiliar with Matrix. Any guidance on how to use it?

[Tooniis]

@alifilhan0 You should find instructions in the link. Otherwise install Element or use the web client on https://element.io/ and create an account then join the room with it.

[arzam16]

@alifilhan0 matrix is something between telegram and email, bringing the best from both worlds. From former you get the decent IM, from latter you get the decentralization (just like with email, you can register on any matrix server and join conversation from there). Usually you just pick a compatible client and sign up on any matrix homeserver - there are lots of them but feel free to pick any.

If you don't really feel like creating an account in yet another messenger, let us know if you maybe prefer telegram instead? I think it could be easily bridged by @Tooniis so you could stay in tg while we stay in matrix

[alifilhan0]

@arzam16 @Tooniis which one would be better for us overall? Matrix? Then I will start using it. I do have telegram though

[Tooniis]

@alifilhan0 I don't use telegram so I can't say, but as @arzam16 said they can be bridged so it doesn't really matter. Although there are other Matrix rooms you might be interested in joining so getting into Matrix might not be totally useless for you.

[arzam16]

@alifilhan0 I agree with @Tooniis and I recommend joining Matrix, too 👍

[ave4]

@ave4 , have you tried deselecting CONFIG_SPECIFY_CONSOLE_INDEX? What's the output?

Nothing changed.