06:07 <logicalerzor> hey calebccff would like some help here. i got uboot to build, but i can't seem to get it to output logs over uart. my progress is here: https://codeberg.org/LogicalErzor/u-boot/commit/4b065799f3adb433d3fa0e605dcc69b5fa8e6873 and upstream uart is here: https://codeberg.org/LogicalErzor/linux/src/branch/expressatt/arch/arm/boot/dts/qcom/qcom-msm8960-samsung-expressatt.dts#L23

06:07 <logicalerzor> some questions:

06:07 <logicalerzor> - are the changes i made to crt0.S and start.S breaking this somehow

06:07 <logicalerzor> - my bootloader deals with atags and board files, not dts. would i need to follow this https://github.com/u-boot/u-boot/blob/master/doc/board/qualcomm/board.rst ? i think it would be different for me, but not sure if i can just do something like `mkbootimg --kernel u-boot-dtb.bin \

06:07 <logicalerzor> - do i need to add clocks for uart? i thought it would be inited by stock bootloader. should i pull from linux upstream?

06:07 <logicalerzor> --output boot.img --pagesize 4096 --base 0x80000000`

06:07 <logicalerzor> - d/icache isn't necessary to boot?

06:07 <logicalerzor> - uboot doesn't need a linux kernel header for arm32 devices?

06:16 <logicalerzor> the crt0.S and start.S changes I made are pulled from arm64: https://source.denx.de/u-boot/u-boot/-/blob/master/arch/arm/lib/crt0_64.S#L77-81 so I'm not sure if there are changes needed to be made elsewhere (i dont think there needs to be, but u-boot is a new codebase for me). not sure if CONFIG_POSITION_INDEPENDENT is important or if u think i could use another config instead and bypass adding these changes in

07:57 <calebccff> logicalerzor: kernel header I guess would still be needed but i have no idea. Maybe instead of doing the PIE hacks you could just define the right TEXT_BASE for your board? At least to get it started. If you don't need to pass the dtb via the bootloader then just use the u-boot-dtb.bin file since it has the dtb baked in already.

07:58 <calebccff> if you enable debug uart and have the correct addresses and don't see any output then it either means that: a) your bootloader turns off UART clocks (which would be super dumb and kinda unlikely but definitely possible), or b) execution isn't getting far enough to print stuff over UART. I'd lead towards b right now. Maybe you can write a tiny UART gadget in assembly to try and spit some characters

07:58 <calebccff> out really early on

12:01 <naoki> StarFive # led list

12:01 <naoki> led-0 <inactive>

12:01 <naoki> StarFive # led led-0

12:01 <naoki> LED 'led-0' not found (err=-19)

12:01 <naoki> any idea?

12:02 <naoki> I added this https://github.com/MilkVNaoki/u-boot/commit/218422189a8998367d6f176c778e39efe6588368

13:20 <LeSpocky> is there a limitation in call stack depth?

13:21 <LeSpocky> still investigating this 'data abort' issue I have and noticed in gdb the backtrace has 127 entries o.O

13:21 <LeSpocky> down to arch/arm/lib/crt0.S:190

13:24 <LeSpocky> wait, actually 128 entries, counts from zero

13:36 <LeSpocky> bbl

13:39 <Tartarus> https://source.denx.de/u-boot/u-boot/-/pipelines/21366/test_report

13:39 <Tartarus> That's handy, lets see if I can convince Azure to do similar

13:40 <Tartarus> And oh good, I got that one right on attempt #2

13:40 <Tartarus> https://dev.azure.com/u-boot/u-boot/_build/results?buildId=8827&view=ms.vss-test-web.build-test-results-tab

23:22 <logicalerzor> alright thanks calebccff ill see what i can do here

23:27 <logicalerzor> the problem isnt with TEXT_BASE but SYS_INIT_SP_ADDR