Tartarus changed the topic of #u-boot to: SOURCE MOVED TO https://source.denx.de/u-boot/u-boot.git / U-Boot v2024.07, v2024.10-rc2 are OUT / Merge Window is CLOSED, next branch is OPEN / Release v2024.10 is scheduled for 07 October 2024 / Channel archives at https://libera.irclog.whitequark.org/u-boot
ikarso has quit [Quit: Connection closed for inactivity]
mmu_man has quit [Ping timeout: 245 seconds]
jclsn has quit [Ping timeout: 276 seconds]
jclsn has joined #u-boot
Jones42 has quit [Ping timeout: 246 seconds]
alpernebbi has quit [Ping timeout: 255 seconds]
ellyq has quit [Ping timeout: 248 seconds]
ellyq has joined #u-boot
ellyq has quit [Changing host]
ellyq has joined #u-boot
alpernebbi has joined #u-boot
vagrantc has joined #u-boot
<swiftgeek> actually how do I pass CONFIG_STANDALONE_LOAD_ADDR without using menuconfig, it gets removed every time regardless of using defconfig or modifying .config
<swiftgeek> anyway modified makefile just for now
<swiftgeek> yeah hello doesn't seem to work even if I use .bin and jump to it with .go
vagrantc has quit [Quit: leaving]
<marex> swiftgeek: did you enable CONFIG_EXAMPLES ? that's its dependency
<marex> 22 config STANDALONE_LOAD_ADDR
<marex> 23 depends on EXAMPLES
<swiftgeek> I don't see it in any kconfig on older uboot
<swiftgeek> ah nvm I'm grepping too much
<swiftgeek> actually it is indeed like that, it's missing from any Kconfig on older ones, while in new one it's in api dir for some reason
<swiftgeek> I guess I should make some qemu setup for sanity
<swiftgeek> maybe my assumption about CONFIG_STANDALONE_LOAD_ADDR is bad and it doesn't let me configure load address for standalone app
<swiftgeek> is qemu_arm_defconfig supporting some extra storage device by default?
<marex> CFI Flash apparently
<swiftgeek> mtd list shows two devices
<swiftgeek> `mtd dump nor0 0 256` shows data, I presume that's uboot
<swiftgeek> so how do I pass image of 2nd flash
<swiftgeek> truncate -s 67108864 ./examples/standalone/hello_world.bin
<swiftgeek> qemu-system-arm -nographic -serial mon:stdio -machine virt -bios u-boot.bin -drive file=./examples/standalone/hello_world.bin,format=raw,if=pflash,index=1
<swiftgeek> not ideal but oh well
<swiftgeek> beats setting up tftp
<swiftgeek> even with `netboot`
<swiftgeek> oh missed tftp=dir in man page
<swiftgeek> ok that worked
<swiftgeek> mtd read nor1 0x40400000 0 400
<swiftgeek> but mtd read nor1 0x0c100000 0 400 is an instant restart
persmule has quit [Remote host closed the connection]
<swiftgeek> ok rebuilding entire u-boot with modified CONFIG_STANDALONE_LOAD_ADDR equal to 0x40400000 leads to working standalone app
<swiftgeek> mtd read nor1 0x40400000 0 400; go 0x40400000
<swiftgeek> might as well check bootm
sugoi has joined #u-boot
<swiftgeek> confusion intensifies https://bpa.st/ZYZY2
sugoi has quit [Ping timeout: 252 seconds]
<swiftgeek> so bootm is working but not working?
tec has joined #u-boot
<swiftgeek> oh, -hda is virtio dev 0
mmu_man has joined #u-boot
<swiftgeek> actually if entry point is absolute, I don't even need to have anything in image
<swiftgeek> if it would work, i can just set entrypoint to maskrom lol
lowfi has joined #u-boot
<swiftgeek> oh well
<swiftgeek> looks like bootm doesn't support uboot ostype
<swiftgeek> There is only boot_jump_linux() and boot_jump_vxworks()
prabhakalad has quit [Quit: Konversation terminated!]
prabhakalad has joined #u-boot
<swiftgeek> but the commit message in ba07984068dc96a2234371545df043495dcbeadd ...
lowfi has quit [Quit: Leaving]
<swiftgeek> > Image Type: MIPS U-Boot Standalone Program (uncompressed)
<swiftgeek> boot/bootm_os.c, do_bootm_standalone checks for autostart xD
<swiftgeek> now it works
<swiftgeek> not sure why it launches twice but oh well
<swiftgeek> autostart is mentioned doc/usage/environment.rst, but usage is completely backwards
<swiftgeek> ah nvm
<swiftgeek> last paragraph of that section has it explained
<swiftgeek> so...
<swiftgeek> linux image is the exception and it will be jumped into regardless of autostart?
<swiftgeek> older uboot is more explicit about it, and autostart needs to be set to "no"
<swiftgeek> I guess the only issue now is to build old u-boot, and maybe standalone without building entire u-boot
<swiftgeek> strings examples/standalone/hello_world | grep -i '\.[ch]$'
<swiftgeek> I guess that covers what got inside
Stat_headcrabed has joined #u-boot
<swiftgeek> marex: I don't think I mentioned exact name of the other probe thingie https://blog.acelab.eu.com/pc-3000-flash-spider-board-adapter-how-to-use-it.html
slobodan has quit [Read error: Connection reset by peer]
Hypfer63 has joined #u-boot
m5zs7k_ has joined #u-boot
tec3 has joined #u-boot
iprusov_ has joined #u-boot
alpernebbi has quit []
prabhakalad has quit [*.net *.split]
tec has quit [*.net *.split]
m5zs7k has quit [*.net *.split]
Hypfer6 has quit [*.net *.split]
iprusov has quit [*.net *.split]
tec3 is now known as tec
Hypfer63 is now known as Hypfer6
m5zs7k_ is now known as m5zs7k
prabhakalad has joined #u-boot
<swiftgeek> also to be clear, many strap pins aren't in BSDL either so trying to find them is "fun"
naoki has quit [Quit: naoki]
<swiftgeek> I forgot about possibility that I might have caused a latchup on eMMC, since that's a computer too
<swiftgeek> yeah, it was eMMC that was glitched up
<swiftgeek> it does not respond to mmc rescan
sugoi has joined #u-boot
alpernebbi has joined #u-boot
sugoi has quit [Ping timeout: 260 seconds]
<swiftgeek> I guess I might as well try dumping straps like 0x53FD0004 SRC Boot Mode Register (SRC_SBMR)
<swiftgeek> would be nice to have SVD/SystemRDL for this SoC
<swiftgeek> ah at least datasheet is explicit about address being absolute
<swiftgeek> I entered a TEST_MODE it seems xD
mmu_man has quit [Ping timeout: 265 seconds]
rvalue has quit [Read error: Connection reset by peer]
rvalue has joined #u-boot
mmu_man has joined #u-boot
<swiftgeek> ok started triggering it reliably again and it turns out I wasn't pressing the reset button fast/quickly enough
<swiftgeek> and once I do, eMMC is locking up
rfs613 has quit [Ping timeout: 252 seconds]
rfs613 has joined #u-boot
dsimic has quit [Ping timeout: 276 seconds]
persmule has joined #u-boot
dsimic has joined #u-boot
alan_o has quit [Remote host closed the connection]
alan_o has joined #u-boot
sugoi has joined #u-boot
sugoi has quit [Ping timeout: 255 seconds]
Algotech has quit [Ping timeout: 244 seconds]
Algotech has joined #u-boot
flyback has joined #u-boot
<marex> swiftgeek: could it be U-Boot simply doesn't power the eMMC regulator ON on boot ? That's often the case with new board ports
<swiftgeek> not sure how that works yet, but pretty sure a power cycle will be needed
<swiftgeek> I should probably confirm that 3.15V is there at the very least
Perflosopher has quit [Ping timeout: 260 seconds]
Perflosopher has joined #u-boot
pgreco has joined #u-boot
<swiftgeek> oh it might be not possible on that PMIC, how odd
<marex> eMMC should have nRST line and Vcc/Vccq power rails, toggling nRST or Vcc should reset it
<marex> Vccq is IO voltage
sugoi has joined #u-boot
<swiftgeek> no reset line on eMMC
<swiftgeek> and PMIC doesn't seem to support toggling those power rails, which makes it really odd
<swiftgeek> as SPI interface is already there
<swiftgeek> maybe there is some fancy reset in band lol
sugoi has quit [Ping timeout: 252 seconds]
<swiftgeek> ah actual board PMIC can have 3.15V rail toggled
<marex> which pmic is that ?
Perflosopher4 has joined #u-boot
Perflosopher has quit [Ping timeout: 255 seconds]
Perflosopher4 is now known as Perflosopher
<swiftgeek> MC13892
<swiftgeek> sucks that board ships with linux predating arm devicetrees, this will make things a lil bit harder
sugoi has joined #u-boot
enok has joined #u-boot
sugoi has quit [Ping timeout: 245 seconds]
enok has quit [Client Quit]
<marex> swiftgeek: linux is GPL, ask vendor for sources
<marex> seems most of the regulators do have enable bit on that pmic
xroumegue has quit [Ping timeout: 260 seconds]
<kabel> any germans here? :-)
rvalue- has joined #u-boot
xroumegue has joined #u-boot
rvalue has quit [Ping timeout: 252 seconds]
mmu_man has quit [Ping timeout: 255 seconds]
<marex> kabel: probably
rvalue- is now known as rvalue
slobodan has joined #u-boot
Stat_headcrabed1 has joined #u-boot
Stat_headcrabed has quit [Ping timeout: 265 seconds]
Stat_headcrabed1 is now known as Stat_headcrabed
sugoi has joined #u-boot
sugoi has quit [Ping timeout: 244 seconds]
slobodan has quit [Remote host closed the connection]
slobodan has joined #u-boot
Stat_headcrabed has quit [Quit: Stat_headcrabed]
slobodan has quit [Ping timeout: 248 seconds]
slobodan has joined #u-boot
slobodan_ has joined #u-boot
goliath has joined #u-boot
slobodan has quit [Ping timeout: 276 seconds]
slobodan_ is now known as slobodan
mmu_man has joined #u-boot
Stat_headcrabed has joined #u-boot
mmu_man has quit [Ping timeout: 252 seconds]
mmu_man has joined #u-boot
naoki has joined #u-boot
flokli has quit [Ping timeout: 252 seconds]
flokli has joined #u-boot
mmu_man has quit [Ping timeout: 246 seconds]
Stat_headcrabed has quit [Quit: Stat_headcrabed]
slobodan_ has joined #u-boot
slobodan has quit [Ping timeout: 276 seconds]
goliath has quit [Quit: SIGSEGV]
dsimic has quit [Quit: Going offline for now]
dsimic has joined #u-boot
crb_ has quit [Quit: Leaving]
mmu_man has joined #u-boot
sugoi has joined #u-boot
<swiftgeek> marcan: yes and they are that old anyway
<swiftgeek> errr, sorry marex *
<swiftgeek> android is already pretty bad with updating anything besides bugfixes, and this is merely an e-reader so nothing like that is ever a concern
<swiftgeek> the entire device still gets updates, but not to the kernel/uboot
mmu_man has quit [Ping timeout: 245 seconds]