08:05 <michalkotyla_> Forty-Bot: thanks

10:55 <thopiekar> Hey! I'm using version 2021.10+dfsg-1 and noticing the following issues with two different SD cards. When powering my Odroid U3 I get the following errors: https://pastebin.com/sJ6zmGx3 When researching the problem I came to different reasons like broken SD card or too low power on the interface. However, "mmc dev 2; mmc part" gives me a partition list, so why is "ext2ls mmc 2:1" not working? Any ideas?

11:19 <thopiekar> Finally tested with my emmc module. Now it works to read the ext2 fs without any error. Should be a hardware issue then. Would be nice if someone could help by giving hints at least :)

14:33 <Daulity> hey all

14:33 <Daulity> I am thinking is it possible to load a small program into ram with u-boot (thinking of an arm processor target) and then execute it?

14:34 <Daulity> nothing ambitious just something like a Hello, World

14:48 <apritzel_> Daulity: are you looking for the "go" command? In cmd/boot.c

14:49 <rfs613> Daulity: yes this is possible, there is "hello world" example include in u-boot source code

14:49 <rfs613> https://source.denx.de/u-boot/u-boot/-/blob/master/examples/standalone/hello_world.c

14:51 <rfs613> there are further details in the main README file, seach for "Hello World"

14:58 <Daulity> i was thinking of compiling some kind of making a little hello world program and loading it with u-boot instead of like the linux kernel

14:58 <Daulity> just wanted to play around on the bare metal environment :)

14:58 <Daulity> rfs613: thanks that will be very usefull!

14:59 <Daulity> oh is that like standalone as in it will still has access to u-boot functionallity i see it use like printf and things :)

15:02 <rfs613> Daulity: it's up to you if you want to use u-boot functions (or not). You can also start poking your UART registers directly, to produce output.

15:03 <Daulity> that is true

15:05 <rfs613> more importantly, u-boot has already done a whole pile of things for you, like turning on clocks, making DDR usable, etc. So if you reall want "bare metal" you'd need to consider what happens from power-on. On most chips these days, there is a *lot* of tedious stuff before you can even get a byte out of the UART.

15:06 <Daulity> rfs613: i wasn't thinking of going that much bare metal xD

15:07 <rfs613> Daulity: good call :-)

15:07 <Daulity> that is why i wanted u-boot to load my program so that i can have the ram and other things already nicely configured :) but i wasn't sure about like extra functionality like printf's and things

15:07 <Daulity> but i guess that is up to me

15:09 <apritzel> Daulity: just load you program, converted into a binary, into RAM, then use "go <entrypoint>"

15:10 <Daulity> can i just compile say a function like main and just go to that or do i need to do more like setup heap and stack or is that already correct due to u-boot

15:10 <Daulity> like on a bare micro controller for example all that has to be setup before going into main :)

15:13 <apritzel> as rfs613 said: depends on how much bare metal you want to go. You could just choose to ignore U-Boot, and just rely on it having done the platform setup already

15:13 <rfs613> the stack is setup (inherited from u-boot, you could of course set it up differently). The code & data segments are included in your binary file, so they're taken care of. The BSS needs to be cleared (or your globals won't be zero'd), see function app_startup() which is the first thing hello_world calls.

15:15 <rfs613> s/won't/may not/

15:18 <apritzel> rfs613: Murphy's law dictates that BSS is accidentally already zeroed just in your own testing, not when you actually want to run the program for real ;-)

15:19 <rfs613> precisely! :P

15:21 <rfs613> Daulity: for comparison, when u-boot loads a linux kernel, it doesn't use any u-boot functions. The (usually compressed) kernel binary is put in RAM, and u-boot jumps to it (basically the same "go" command). The only difference being a device tree and maybe initrd are also in memory, and their addresses are passed in registers. The linux kernel binary begins to execute, decompresses itself, sets up its own

15:21 <rfs613> stack, initializes uarts, etc.,.. and eventually you see it print "Linux version ..."

15:24 <Daulity> thanks that makes sense :)

18:20 <thopiekar> Did some further investigations. I've tried with my emmc module also and it works both ways. Once connected directly to the board and also using sd card adapter attached to the same socket. I don't see why real SD cards won't work here.

21:42 <tpw_rules> hi all. i've run into a couple keyboards on a couple systems which would be fixed by this patch: https://patchwork.ozlabs.org/project/uboot/patch/20200914023921.119630-3-jason.wessel@windriver.com/ but it seems it's been deferred for reasons i don't understand. how might i kindly request that the mailing list re-review it?