qschulz has quit [Remote host closed the connection]
qschulz has joined #u-boot
mmu_man has quit [Ping timeout: 240 seconds]
thopiekar has quit [Ping timeout: 276 seconds]
thopiekar has joined #u-boot
_whitelogger has joined #u-boot
Gravis_ has joined #u-boot
Gravis has quit [Read error: Connection reset by peer]
GNUtoo has quit [Remote host closed the connection]
GNUtoo has joined #u-boot
mckoan|away is now known as mckoan
frieder has joined #u-boot
guillaume_g has joined #u-boot
pbergin has joined #u-boot
gsz has joined #u-boot
zibolo has joined #u-boot
mrnuke has quit [Ping timeout: 246 seconds]
mrnuke has joined #u-boot
hthiery has joined #u-boot
<hthiery>
does anyone know if the HAB API on imx8 will work when using the upstream TF-A firmware. We see e.g. hab_auth_img command fails . The same works without issues when using downstream TF-A from NXP.
gsz has quit [Quit: leaving]
sszy has joined #u-boot
monstr has joined #u-boot
tnovotny has joined #u-boot
prabhakarlad has joined #u-boot
sszy has quit [Ping timeout: 240 seconds]
mmu_man has joined #u-boot
zibolo_ has joined #u-boot
sszy has joined #u-boot
tnovotny has quit [Quit: Leaving]
torez has joined #u-boot
sszy has quit [Ping timeout: 240 seconds]
sszy has joined #u-boot
sszy has quit [Ping timeout: 240 seconds]
sszy has joined #u-boot
sszy has quit [Quit: No Ping reply in 180 seconds.]
sszy has joined #u-boot
<hanetzer>
blerg... workign out pll clock drivers is *fun*
<hanetzer>
y'think it would be useful to have a definition for MHz/KHz in some common location instead of defining it in every clock.h header?
gsz has joined #u-boot
pbergin has quit [Quit: Leaving]
<derRichard>
hey, i have a question on drivers/bootcount/rtc.c. it seems to assume that rtc_write16() will give you access to the internal eeprom. but actually rtc_write* will just talk to the rtc itself. so it will only work for very simple/stupid rtcs. i have a rtc on my desk where you need to use more sophisticated i2c commands to read/write the internal eeprom
<derRichard>
how to deal with such an rtc?
<Forty-Bot>
what model rtc?
<derRichard>
rv3028
<derRichard>
in the linux driver you can see what commands you need to read/write the eeprom
<derRichard>
adding a custom driver into drivers/bootcount/ should be easy, just want to make sure i don't oversee something :D
<Forty-Bot>
well, there is only one existing board with that rtc
<Forty-Bot>
and it doesn't use rtc_read* in its board code
<Forty-Bot>
so you should be fine changing it
<derRichard>
so, the goal of rtc_read*() is reading from the internal eeprom and not reading from a rtc i2c register?
<derRichard>
...which means u-boots rv3028
<Forty-Bot>
I believe so
<derRichard>
's rtc_read/write are plain wrong?
<derRichard>
:(
<Forty-Bot>
well, if that isn't the case
ilunev has joined #u-boot
<Forty-Bot>
you can always add a UCLASS_MISC child device
<derRichard>
sadly the doc string in rtc_ops on read/write is close to useless :-(
<Forty-Bot>
well, it does mention "registers" a lot
<Forty-Bot>
which seems like it's meant for raw access
<derRichard>
so drivers/bootcount/rtc.c is wrong because it assumes rtc_ops->read/writes gives access to the internal eeprom
<Forty-Bot>
test/dm/rtc.c seems to imply raw register access
<derRichard>
yeah, i'd also guess so
<Forty-Bot>
but tbh I think this API is weird
<Forty-Bot>
since usually you shouldn't care about doing raw access
<derRichard>
we could add a new set of function to rtc_ops which allow access to the internal eeprom. e.g. ->eeprom_read/write, if these are NULL the caller is allowed to use the raw access functions
<Forty-Bot>
I'd rather not proliferate read/write functions if possible...
<Forty-Bot>
I think it should be OK to change the semantics of this API
<Forty-Bot>
as there appear to be around 4-5 users total
<Forty-Bot>
and most should be unaffected
NonaSuomy has joined #u-boot
<NonaSuomy>
If u-boot is compiled for android could you still replace the kernel on the eMMC and then boot a random linux build instead of android?
<hanetzer>
I mean. if you have a working bootloader of some sort you can prolly even run bsd with the right massaging
<derRichard>
Forty-Bot: so you suggest that ->read/write should no longer give access to raw registers but to the internal eeprom (if there is any)
<Forty-Bot>
I think that's more useful generally
<Forty-Bot>
for most RTCs nothing needs to change
sobkas has joined #u-boot
<NonaSuomy>
I want to get a console after the kernel boots. I compiled busybox into the uImage I get as far as Starting kernel ... and then I believe an external watchdog from maybe the WM8321 restarts the processor MX508 before I get the busybox prompt. Any idea how to pet that dog some how so that doesn't happen?
<derRichard>
Forty-Bot: hm. and what about the rtc command? it exposes ->read/write as commands
<derRichard>
so existings scripts might break
<Forty-Bot>
well, for your specific RTC there is only one board
<Forty-Bot>
so I think you can get away with making the change and seeing what happens
<NonaSuomy>
Seems like 30 sec from U-Boot till that Linux Starting... line.
<NonaSuomy>
*Starting kernel
<Forty-Bot>
but e.g. my nvmem series also expects that the rtc read/write functions access the eeprom
<NonaSuomy>
Kernel 2.6.35.3
<Forty-Bot>
ah, the venerable 2.6
<derRichard>
Forty-Bot: i have a generic solution in mind. not a hack that will break as soon i upgrade the bootloader :D
<hanetzer>
Forty-Bot: makes me glad the kernel I'm working against is at least a 3.x series (3.10.something)
<Forty-Bot>
you guys are nuts
<hanetzer>
Forty-Bot: nah. I'm trying to be un-nuts (mainlining the device)
<NonaSuomy>
@hanetzer I tried to enable earlyprintk but it won't compile on the mx508
<Forty-Bot>
good luck!
<NonaSuomy>
bunch of mangled stuff was moved around.
<hanetzer>
but yeah. pretty nuts.
<NonaSuomy>
CC arch/arm/kernel/early_printk.o
<NonaSuomy>
In file included from arch/arm/kernel/debug.S:132:0:
<NonaSuomy>
arch/arm/plat-mxc/include/mach/debug-macro.S:51:2: error: #error "CONFIG_DEBUG_LL is incompatible with multiple archs"
<NonaSuomy>
#error "CONFIG_DEBUG_LL is incompatible with multiple archs"
<NonaSuomy>
^
<hanetzer>
oh, you just gotta mess around with the kconfig settings, you need to turn off multiple arch selection under system type somewhere.
<NonaSuomy>
hmm
<NonaSuomy>
This? │ Symbol: MX5_MULTI_ARCH [=n]
<NonaSuomy>
or this │ Symbol: ARCH_MXC [=y] │
<NonaSuomy>
│ Prompt: Freescale MXC/iMX-based
zibolo has quit [Ping timeout: 252 seconds]
<hanetzer>
not sure, havent fiddled with old kernels
zibolo_ has quit [Ping timeout: 252 seconds]
<NonaSuomy>
From when I looked up that error I just found people bickering about how to handle it properly with not much a conclusion that I understood.
<NonaSuomy>
no folder exists under arch/arm/boot/ called dts
<hanetzer>
NonaSuomy: modern kernel.
frieder has quit [Remote host closed the connection]
<hanetzer>
looks like an interesting device.
<NonaSuomy>
There is a project called inkbox I would like to get running on it.
<NonaSuomy>
They have it running on a Kobo n905a/b which runs the same processor
<NonaSuomy>
I think because I don't know how to pet that externel watchdog is the culprit or maybe I'm barking up the wrong tree
mckoan is now known as mckoan|away
<NonaSuomy>
I tried to disable all the kernel watchdog features but it still reboots like clock work after 30sec
<NonaSuomy>
I tested by using sleep 25; boot in the uboot console and then worked my way up to 30sec it gave me less and less lines from the kernel booting process.
mmu_man has quit [Ping timeout: 260 seconds]
<hthiery>
does anyone know if the HAB API on imx8 will work when using the upstream TF-A firmware. We see e.g. hab_auth_img command fails . The same works without issues when using downstream TF-A from NXP.
ilunev has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
___nick___ has joined #u-boot
<NonaSuomy>
Do embedded processors usually have an active watchdog pin, what enables them to begin with if not?
monstr has quit [Remote host closed the connection]
jenneron[m] has joined #u-boot
<jenneron[m]>
hello, does anyone know is it possible to boot a kernel from subpartition with u-boot? how?
redbrain has quit [Read error: Connection reset by peer]
redbrain has joined #u-boot
<NonaSuomy>
The watchdog timer duration is set using WDOG_TO. The watchdog timer can be halted for debug
<NonaSuomy>
purposes using the WDOG_DEBUG bit.
<NonaSuomy>
WM8321G Address R16388(4004h) Watchdog, Bit 14 WDOG_DEBUG, Default 0, Watchdog Pause 0=Disable 1=Enabled (halts the watchdog timer for system debugging) Protected by user key
ilunev has joined #u-boot
<NonaSuomy>
so now how do a form that into a uboot i2c command.
<NonaSuomy>
No no schematic I just bruteforced to make me believe that with sleep ##; boot increments to understand that it wasn't the processors watchdog as it would display less and less kernel lines the more time I gave it.
<NonaSuomy>
30 secs was the max value I could get anything from.
<rfs613>
ok, well it is possible there is another watchdog elsewhere. But this one is worth a try. Looks like it is enabled by default (per the datasheet you linked)
<rfs613>
WDOG_DEBUG looks promising, although it looks like this bit is locked, and requires writing a code to security register first.
<NonaSuomy>
There are two other uC's on board an 8bit micro and another which I can't read the label of something m430. I just hope they used the PMIC as the rest are undocumented.
Forty-Bot has quit [Read error: Connection reset by peer]
<NonaSuomy>
maybe we get lucky and they never locked the bit?
<rfs613>
see 12.4 (page 43) of the data sheet. Looks like it's built in, but they tell you the "code"
<rfs613>
seems it is mostly to avoid accidental writes, not a real security protectoin
<rfs613>
i2c md.w 0x34 0x4008 -> default value is 0x0000 according to data sheet
<NonaSuomy>
Would that mean it's disabled by default?
<rfs613>
that means you can't modify the WDOG_DEBUG bit (and other stuff too)
<rfs613>
you have to write a magic value 0x9716 to this register, to allow writes to WDOG_DEBUG etc.
<NonaSuomy>
Makes sense was just wondering if the default is security bit always enabled so you have to always do that process first. Booting now maybe we just won't get anything read back so lets see.
<rfs613>
try reading from 0x4004 also... default value seems to be 0xaa17 for that register
<NonaSuomy>
In linux it was showing that device i2cdetect as UU which means it's in use so hopefully it's not in use during uboot.
littlebobeep has quit [Ping timeout: 240 seconds]
<rfs613>
UU means there is a linux driver that has claimed the device. Says nothing about u-boot really. But, if linux knows about it and has a driver, maybe all you need to do is start watchdogd to feed the watchdog?
mmu_man has joined #u-boot
<NonaSuomy>
i2c_addr failed Error reading the chip.
<NonaSuomy>
Let me confim
<NonaSuomy>
input: wm831x_on as /devices/platform/imx-i2c.0/i2c-0/0-0034/wm831x-on/input/input2
<marex>
what are you trying to achieve here anyway ?
<marex>
what is the end goal ?
littlebobeep has quit [Ping timeout: 240 seconds]
<NonaSuomy>
disable an external watchdog on the i2c bus that is set for 30 seconds which my customized kernel I believe is taking longer than that to boot as it has busybox compiled into it.
<marex>
the WDT is not gonna be in the audio codec though ?
<marex>
so it reads raw eMMC at offset 0x800 (in 512B block units) and it reads 0x1400 such blocks
<marex>
thats the kernel
<marex>
dtto for ramdisk
<marex>
and then it jumps to it with bootm
apritzel has quit [Ping timeout: 252 seconds]
littlebobeep has quit [Quit: leaving]
<NonaSuomy>
what is the purpose of reading the mmc and then reading the ramdisk?
littlebobeep has joined #u-boot
<NonaSuomy>
I have flashed SDCard with the eMMC 1:1 copied with a few modifications to point to run from the SDCard (It used to run) when the eMMC had everything in place
<marex>
NonaSuomy: they read uImage which wraps the kernel zImage and then read uImage which wraps the ramdisk
<marex>
two blocks
<marex>
*two blobs
<marex>
and then they point the bootm command to both blobs to start kernel and provide pointer to ramdisk to the kernel
<NonaSuomy>
Does it need both or is that like a backup if it can't find the ramdisk then it falls back to the eMMC or vice versa?
littlebo1eep has joined #u-boot
<NonaSuomy>
Like I'm unsure why this uboot is still running after I removed all the partitions unless I missed it.
mmu_man has quit [Ping timeout: 252 seconds]
littlebobeep has quit [Ping timeout: 240 seconds]
<marex>
maybe it is stored in emmc boot partition or some such ?
<marex>
or in some other storage
<marex>
the kernel is what you need, the ramdisk is optional, it gets mounted as root filesystem from ~tmpfs (ram)