<swiftgeek>
there is also API thingie, but menuconfig confuses me as I don't see any conditionals on exports.o, yet CONFIG_STANDALONE_LOAD_ADDR hides inside enabling API ?
sugoi has joined #u-boot
<swiftgeek>
similar with building examples
sugoi has quit [Ping timeout: 252 seconds]
<swiftgeek>
make clean somehow doesn't cover examples/standalone/hello_world.bin
mmu_man has joined #u-boot
peac has joined #u-boot
Guest4 has joined #u-boot
<marex>
swiftgeek: what are you trying to achieve in the end ? the standalone application support isn't used much as far as I know
<Guest4>
can anyone tell me when is "board_early_init_f" being called. I have set CONFIG_DEBUG_UART and the first function I see is checkboard and then the order is board_init -> power_init_board -> board_late_init. Soc vender 'NXP' suggests to disable watchdog with in board_early_init_f, otherwise uboot resets itself. I am building uboot 2024.4 without spl
<swiftgeek>
very specific scenario of escaping from uboot script I don't control, but it pulls something from sd card with bootm so I feel like going with standalone
<swiftgeek>
for one I will get puts() at the very least
<marex>
swiftgeek: bootm is meant to start the kernel from container images , there is likely a load command somewhere before that ?
RobertBerger has quit [Ping timeout: 252 seconds]
mmu_man has quit [Ping timeout: 248 seconds]
<swiftgeek>
marex: just `mmc read` immediately followed by bootm
<Guest4>
marex thank you very much for your reply. Are you suggesting that I should add my code to "common/board_f.c: board_early_init_f" or can I force u-boot to call my boards board_early_init_f function defined in my_board.c
<marex>
Guest4: the later
<swiftgeek>
on uboot binary diverging from at most v2009.08 (XF_VERSION 5)
<marex>
swiftgeek: update the boot command and sandwich your stuff between mmc read and bootm ?
<swiftgeek>
well that's the thing, I don't control it ;D
<swiftgeek>
so first I want to boot jump into maskrom for usb download, and then load new uboot
<swiftgeek>
and then start from dumping eMMC
rvalue has quit [Read error: Connection reset by peer]
<marex>
swiftgeek: why dont you put new U-Boot into that bootm'd image ?
<swiftgeek>
because I don't control it
rvalue has joined #u-boot
<swiftgeek>
wait what
<Guest4>
marex I have board_early_init_f defined in my_board.c. It is however not being called by u-boot. It starts with checkboard in my logs. How can I force u-boot to call board_early_init_f from my_board.c
<marex>
swiftgeek: start U-Boot from U-Boot , instead of starting Linux from U-Boot
<swiftgeek>
I can chain uboot on arm?
<marex>
technically it is unsupported, but yes, you can ... you might have to remove some of the lowlevel init bits if it hangs on them
<swiftgeek>
then it's cleaner to pursue switch to bootrom
<swiftgeek>
at least managed to glitch it with a finger (not reproducible anymore) and confirmed that it loads fine over usb
<marex>
swiftgeek: and that switch to bootrom is some jump to an address ?
<swiftgeek>
yep
<marex>
swiftgeek: so ... why don't you wrap like 2-line compiled assembler file into that bootm'd image which does ldr r0, =... mov pc, r0 ?
<marex>
swiftgeek: generate uImage out of it, and let U-Boot bootm it
<swiftgeek>
because then I can't see it in uart output unless I hardcode that portion as well
<marex>
swiftgeek: do some ldr / str into the UART TX FIFO register ?
<swiftgeek>
that's hardcoding
matthias_bgg has quit [Quit: Leaving]
<marex>
yes, should be good enough if all you need is to jump somewhere and get some info about it
<marex>
you certainly won't need entire U-Boot application for that
<marex>
saves you dealing with that part
<swiftgeek>
still plenty in that interface to make it worth it
<swiftgeek>
it's only missing saveenv for easy env restore
<swiftgeek>
but that can be circumvented
Guest4 has quit [Quit: Client closed]
Guest4 has joined #u-boot
<marex>
if you need full U-Boot functionality like that, then chainload U-Boot, that's probably less painful
<swiftgeek>
well I will still load uboot, just more cleanly through uboot
<swiftgeek>
which makes it a better setup for porting
<marex>
swiftgeek: can you erase the eMMC ? Does that fall back to bootrom too by any chance ?
<marex>
that way you might be able to load via USB upload right from the start
<swiftgeek>
nah, that's because of glitching fuse/strap sense, not sure which one yet :D
<swiftgeek>
I can't wait till I reproduce it again so I can capture relevant waveforms https://pic.infini.fr/ZdeiwhdB/LrYTEiAi.jpg , at that time I thought it was merely a reset button pressing
<marex>
swiftgeek: try and ground eMMC CMD/CLK/D0 lines and see if that has any impact ?
<swiftgeek>
I don't have schematics/boardview sadly
<swiftgeek>
if I did, I would be hunting down straps for boot mode already
<marex>
eMMC is BGA , right ... see if there is any pull UP resistor around the eMMC, measure it, that could be D0 pull up
<marex>
usually CLK/CMD/D0 may have them, on the rest of Dx they are optional iirc
<swiftgeek>
I pulled every testpoint nearby, but resistors are way too dense on that board
<swiftgeek>
though hmm maybe magic value exists
<marex>
swiftgeek: do you have PCBites ?
<swiftgeek>
also I could start poking that GPIO from standalone
<swiftgeek>
nah just using pogos in hand
<swiftgeek>
but that looks interesting
<swiftgeek>
definitely better than what I saw sold by acelab
<marex>
swiftgeek: yeah, I was looking for something like a scope probe holder for a LONG time, then I found those, and that was amazing
<marex>
thing just works, holds and frees my hands, and the probe end is real fine, which is great for those tiny resistors
<swiftgeek>
well for one in particular I have hand, and maybe the other one for next point (and foot pedal for power switch)
<marex>
swiftgeek: I assume you dont have JTAG access either ?
<marex>
it might be on some testpoints
<swiftgeek>
it also needs jtag enable pin, and none of those pins are muxed with GPIO
<swiftgeek>
and eMMC doesn't appear to have any special values in reference schematics, also runs at high voltage there
<marex>
swiftgeek: which SoC is that ?
<swiftgeek>
ah cmd is 22kΩ so maybe that could be found
<swiftgeek>
i.mx508
<marex>
swiftgeek: pull it down with 10k or 4k7 and that might inhibit the communication without depleting the transceiver in the SoC
<marex>
oh
<marex>
some ebook reader, huh
<swiftgeek>
> depleting the transceiver in the SoC
<marex>
pulling down a driver in the SoC straight to GND would likely have adverse effects
<swiftgeek>
that's some fancy words for a mere pair of transistors (well actually cascodes coz HV)
<swiftgeek>
that 3.15V is already too high for a single transistor there
<marex>
why ?
<swiftgeek>
far exceeds rating? :D
<marex>
SD/MMC cards end at 3V6
<marex>
the SoC probably at 3V3
<swiftgeek>
yeah that's high voltage
<swiftgeek>
as the process shrink the HV area starts getting ridiculously low ;D
<swiftgeek>
and somehow general public is always behind on what those current MCU transistors can take
<swiftgeek>
if they started writing 3.3V-tolerant on pins, just like in I/O cell library, I would be a lot more careful probing around
<swiftgeek>
yeah, but that's definitely high voltage for them
<marex>
not really, even the more recent iMX are 3V3 capable
<marex>
they have to be because of the target market, industrial and co.
<swiftgeek>
that's what cascode is for
<marex>
what's cascode ?
<swiftgeek>
you take several lower rated transistors to make something that can take higher voltage
<marex>
isnt that drive strength ?
<marex>
(not for higher voltage, but they use multiple FETs to implement that)
<swiftgeek>
nope just same idea as for resistors in eg. multimeter
<swiftgeek>
why have insane one insanely priced when you can put a ton of lower rated ones in series
<swiftgeek>
so if I wanted to have even higher voltage tolerance, I could easily build that up sorta
<swiftgeek>
without designing transistors themselves on silicon ;D
<marex>
ha, ok
<swiftgeek>
3.3V was already HV in tsmc 180nm
<swiftgeek>
so yeah now I'm paying extra attention to what voltages multimeters are putting out, to make sure that's not enough to fry something outright
<swiftgeek>
would be nice to have something custom within abs max rating for reverse polarity
<quinq>
Hi
<quinq>
Is there a place where the hush shell language is documented?
mmu_man has joined #u-boot
<swiftgeek>
huh, eMMC part is similar enough that it might use the same circuit as in reference
<swiftgeek>
so 3.15V 22kΩ might be something possible to find
<swiftgeek>
especially next to 3.15V 10kΩ
<Guest4>
marex board_early_init_f from my my_board.c is not being called. At least I don't see anything on JTAG serial port. Am I missing something?
tgamblin_ is now known as tgamblin
tgamblin has quit [Ping timeout: 246 seconds]
tgamblin has joined #u-boot
tgamblin has quit [Remote host closed the connection]
mripard has quit [Quit: mripard]
Guest4 has quit [Quit: Client closed]
jaganteki has quit [Quit: Client closed]
mmu_man has quit [Ping timeout: 244 seconds]
Guest4 has joined #u-boot
jaganteki has joined #u-boot
mmu_man has joined #u-boot
dsimic has quit [Ping timeout: 252 seconds]
dsimic has joined #u-boot
mmu_man has quit [Ping timeout: 252 seconds]
mmu_man has joined #u-boot
ellyq_ has quit []
ellyq has joined #u-boot
mmu_man has quit [Ping timeout: 246 seconds]
Stat_headcrabed has joined #u-boot
monstr has quit [Remote host closed the connection]