<DC-IRC> <JonH> The following kernel config file works for the edge 6.2 kernel in my initial testing. The CONFIG_LOCALVERSION must be undefined or the build breaks. Other than that it appears to work. I don't know what additional configuration options in the current Armbian kernel build config is causing the problem. Turning on debug messages seems inconclusive.
<DC-IRC> <JonH> I haven't tested this with current, i.e. 6.1.y kernel but suspect it will work there also. Both kernels previously exhibited the exact same failure mode. I never really had the problem with the armbi_root. Not sure why.
<DC-IRC> <c0rnelius> The release of 6.1 i believe there was slight adjustment in the way the defconfig was handled in arm64. Both appear to now be required: `CONFIG_ARCH_BCM=y` `CONFIG_ARCH_BCM2835=y` These were always required on ARM builds.
<DC-IRC> <c0rnelius> I think on ARM64 if this was ticked `CONFIG_ARCH_BCM2835=y` it would auto tick the other. As the first one `CONFIG_ARCH_BCM=y` is dependent on the second.
<DC-IRC> <c0rnelius> and vice versa.
<DC-IRC> <JonH> Well wouldn't that be precious! 🤨
<DC-IRC> <c0rnelius> I don't know. I just noticed it exactly the same in ARM as in ARM64 now.
<DC-IRC> <c0rnelius> Pi's have always been behind in the ARM64 world. So nothing is to shocking.
<DC-IRC> <c0rnelius> As for the defconfig you posted. Armbian follows the Ubuntu way of doing things for some odd reason. Which I think 'personal opinion' is probs not the best idea.
<DC-IRC> <JonH> I'm not sure that explains why the kernel was crashing though. It was crashing with the new kernel config files proposed by Igor which had both set.
<DC-IRC> <c0rnelius> When 6.1 was released a patch was suggested that forced the selection of both. If that patch wasn't applied it would mean the platform wasn't selected. Could be why boot failed.
<DC-IRC> <JonH> I don't have much of an opinion on that. One reason I wasn't putting this in via a pull request is my relative ignorance on preferences in this area most specifically for Armbian.
<DC-IRC> <JonH> That would be true if CONFIG_ARCH_BCM was not set but it is. As is CONFIG_ARCH_BCM2835. Since they are indeed both set that can't be the boot failure cause. Must be something else I think.
<DC-IRC> <JonH> Good thought but not the actual problem it appears so far.
<DC-IRC> <c0rnelius> yeah it was bug
<DC-IRC> <JonH> I may spend some more time to figure out what is actually wrong but that is really tedious and this was in the way of something else I was trying to do so I may just move on to what I was actually _trying_ to do.
<DC-IRC> <c0rnelius> force select platform and because the defconfig was already preset it worked.
<DC-IRC> <JonH> Perhaps what you are saying is true but what I did was replace the Armbian kernel config files with that file. A cheat perhaps...
<DC-IRC> <c0rnelius> Nah nothing wrong with that. The are pulling from the foundation 'i thinks' so it should work.
<DC-IRC> <c0rnelius> Nah nothing wrong with that. They are pulling from the foundation 'i thinks' so it should work.
<DC-IRC> <c0rnelius> They should really just use the foundation defconfig honestly. It comes in the source.
<DC-IRC> <JonH> I'm sure there must be a reason. I simply don't know what it is.
<DC-IRC> <c0rnelius> They went the Ubuntu to way and... No here has much love for Pi;s.
<DC-IRC> <c0rnelius> They went the Ubuntu way and... No here has much love for Pi;s.
<DC-IRC> <c0rnelius> They went the Ubuntu way and... No one here has much love for Pi;s.
<DC-IRC> <JonH> PIs are in some ways their own little animals so I sorta get that. It's a pretty robust ecosystem compared to some of the other SBCs.
<DC-IRC> <JonH> As with everything there is good and bad.
<DC-IRC> <c0rnelius> I don't get why they use flash-kernel or whatever it is called. Lazy i guess.
<DC-IRC> <JonH> They do have a lot of good work in here so I find it difficult to complain too much. I've been a developer long enough to appreciate the risk of second guessing what/why for others.
<DC-IRC> <c0rnelius> I complain for us both 😉
<DC-IRC> <c0rnelius> Doesn't matter to me, as I don't use Armbian on my Pi's. But Knowing the approach they took, I would have gone a diff way. But yes. I have no chips in this game so its whatever.
<DC-IRC> <JonH> Fair enough. 🙃
<DC-IRC> <JonH> Thanks for the tips in any case. Something new to learn/.
<DC-IRC> <JonH> Thanks for the tips in any case. Something new to learn.
<DC-IRC> <c0rnelius> Sure. np I don't think I did anything. 😄
<DC-IRC> <c0rnelius> Just don't ask for help and you'll be fine. Suggestions always welcome.
<DC-IRC> <JonH> I have a mishmash of boards (probably like many do). I have likes and dislikes with each of them. If the RK3588 had a better ecosystem it would probably be my current fave.
<DC-IRC> <JonH> I've gotten help actually. 🥹 I try to provide it once in a while when I am able. That's only fair.
<DC-IRC> <c0rnelius> Yeah I have shit ton too. No rk3588's yet. I'm waiting for the smoke to clear.
<DC-IRC> <JonH> Keep waiting then I think....
<DC-IRC> <c0rnelius> yeaaap
<DC-IRC> <c0rnelius> it's like rk3399 all over again. new kernel.
<DC-IRC> <JonH> You mean (not a ) new kernel. 🥵
<DC-IRC> <c0rnelius> well... yes. new for them. old for us.
<DC-IRC> <JonH> Indeed
<DC-IRC> <c0rnelius> some shit android frankenbuild
<DC-IRC> <JonH> I've got 6.3-RC1 running on my Rock-5b. Very poor and incomplete. Mali works but _very_ flaky.
<DC-IRC> <c0rnelius> I'll be impressed when mainline u-boot arrives.
<DC-IRC> <JonH> I've thought of playing with that also but way down on my list of projects.
<DC-IRC> <c0rnelius> Get a real ATF option
<DC-IRC> <JonH> Been years since I did a u-boot port. I'll have to figure it out all over again.
<DC-IRC> <clever> ive been meaning to re-port u-boot to the rpi, under the open firmware
<DC-IRC> <clever> the stock u-boot fails, because it tries to query the mailbox for total ram
<DC-IRC> <JonH> The fact that I would have to go decode that statement tells me that I do indeed have to re-learn u-boot porting.
<DC-IRC> <clever> the existing uboot port, depends on api's provided by the closed source firmware
<DC-IRC> <clever> when i switch the pi to open source firmware, those api's cease to exist
<DC-IRC> <JonH> The Arm secure stuff?
<DC-IRC> <clever> the videocore mailbox
<DC-IRC> <JonH> Ah. BRCM.
<DC-IRC> <JonH> I worked there years ago. Not on that really though. Different group.
<DC-IRC> <JonH> Rockchip has their secret stuff too. I only know enough to realize it exists but without any idea of what challenges it would create for u-boot porting.
<DC-IRC> <clever> ive disected some of the rpi secrets, and can now boot linux without a single blob
<DC-IRC> <clever> ah found it
<DC-IRC> <clever> ```
<DC-IRC> <clever> int dram_init(void)
<DC-IRC> <clever> BCM2835_MBOX_INIT_TAG(&msg->get_arm_mem, GET_ARM_MEMORY);
<DC-IRC> <clever> ret = bcm2835_mbox_call_prop(BCM2835_MBOX_PROP_CHAN, &msg->hdr);
<DC-IRC> <clever> gd->ram_size = msg->get_arm_mem.body.resp.mem_size;
<DC-IRC> <clever> ```
<DC-IRC> <clever> this code calls the mailbox on the firmware
<DC-IRC> <clever> ```
<DC-IRC> <clever> switch (packet->tag) {
<DC-IRC> <clever> case 0x00010005: // get arm mem
<DC-IRC> <clever> value[0] = 0;
<DC-IRC> <clever> value[1] = 64 * 1024 * 1024;
<DC-IRC> <clever> packet->req_resp = 0x80000000 | 8;
<DC-IRC> <clever> ```
<DC-IRC> <clever> and this implements the other end, it should claim the system has 64mb of ram
<DC-IRC> <JonH> I'm usually only concerned about the blobs when they get tied to specific versions of things. Like when they depend on specific library versions or similar misbehaviors. Means you can't re-use them on newer builds even if you have the blob. Ugh!
<DC-IRC> <clever> but u-boot went and put `gd` into open bus area
<DC-IRC> <clever> so all writes to `gd` are lost
<DC-IRC> <JonH> BRCM never planned originally for this to get used like it did. It was for set-top boxes, phones, etc. All intended to be somewhat proprietary to some extent. The whole RPI thing started as a boondoggle of course.
<DC-IRC> <clever> yeah
<DC-IRC> <clever> ive decompiled the day 1 rpi firmware
<DC-IRC> <clever> it looks like it came right out of a STB
<DC-IRC> <clever> mentions of tv remote buttons, channels, game loading
<DC-IRC> <clever> most of that has since been removed
<DC-IRC> <clever> @JonH under normal conditions with the official firmware, any pi in the pi0-pi3 model range goes thru ~4 boot stages
<DC-IRC> <clever> stage 0, the maskrom in the cpu loads and runs bootcode.bin from an sd card
<DC-IRC> <clever> stage 1, bootcode.bin brings dram online, then loads and runs start.elf
<DC-IRC> <clever> stage 2, start.elf brings the rest of the system online, loads an arm kernel (linux, uboot, or atf) and turns on the arm core
<DC-IRC> <clever> stage 3, the arm kernel begins booting
<DC-IRC> <JonH> I've had to create those maskroms. And simulate them prior to chip tapeout.
<DC-IRC> <clever> with <https://github.com/librerpi/lk-overlay> i can compile a custom stage1 and stage2 binary
<DC-IRC> <clever> so i can replace every blob that you can modify
<DC-IRC> <JonH> I'll have to look at some of that. Sounds like some good examples to come back to to speed on. RPI specific but I'm sure there's some general knowledge in there also.