<NonaSuomy>
Trying to compile Linux version 2.6.35.3 for CPU is i.MX50 Revision 1.1 I tried to add earlyprintk to see why the kernel was having issues after U-Boot but get plat-mxc "config_debug_ll is incompatible with multiple archs" in debug-macro.S has anyone seen this issue before?
mmu_man has quit [Ping timeout: 248 seconds]
<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"
frieder has quit [Remote host closed the connection]
mmu_man has joined #u-boot
apritzel_ has joined #u-boot
<dormito>
re: the ls1046ardb: it seems the CAAM is used for hw accl sha1... however that (in the current code... not sure how much is hw requirements) requires the buffers be "DMA aligned" (cacheline sized). As far as I can tell this effectly renders fit images (that use sha1 hashes, thought I suspect it will effect other algos too) unbootable. Is there a good way to address this? Maybe just disable hw accel
<dormito>
for hash calaculation in uboot on that chip?
<stefanro>
dormito: i just also stumbled over this problem this week on another LX2160 based board, while updating to latest mainline. for test purposes, i disabled the alignment check and have not seens any issues so far.
<dormito>
stefanro: good to know. I dodged the issue (for the moment) by forcing it to software. If the alingment restirction can be relaxed that'd be better.
<stefanro>
dormito: we should probably check with the NXP maintainers, if this alignment is really necessary. and if yes, one solution would be to allocate an aligned buffer in the crypto code, and memcpy the area(s) into this buffer. but this would increase boot time, which is crucial for my current project.
<stefanro>
dormito: could you perhaps ask on the list with the maintainer on cc (any myself, sr@denx.de) about this?
<dormito>
While boot times are not as cirtical to me, that would be good.
<dormito>
I could probably do that (but unfortunately, probably not for a couple outs at least).
littlebobeep has joined #u-boot
littlebobeep has quit [Ping timeout: 240 seconds]
prabhakarlad has quit [Quit: Client closed]
<stefanro>
dormito: i can do this as well (back now). what is your email, so that can put you on cc here?
redbrain has quit [Read error: Connection reset by peer]
<dormito>
stefanro: you can use 'dullfire@yahoo.com"
prabhakarlad has joined #u-boot
redbrain has joined #u-boot
apritzel_ has quit [Ping timeout: 272 seconds]
<stefanro>
dormito: mail is out ;)
<stefanro>
dormito: ugh, i fat-fingered your mail address though
<Tartarus>
are you doing "make qcheck" or something else?
<Tartarus>
fwiw, with a virtualenv setup and then pip install -r test/py/requirements.txt everything should run? But that may require sudo for a few of the fs tests
<cambrian_invader>
make sure it's running in the first place
<NonaSuomy>
How do I do that?
<NonaSuomy>
when I'm sitting in the u-boot prompt if I don't type anything or just ever so many seconds the system resets and then I have to mash the keyboard on the serial terminal to get back into the uboot prompt
<NonaSuomy>
Otherwise it boots the kernel
<NonaSuomy>
Is this u-boots watchdog or something elses watchdog.
<cambrian_invader>
do you see "WDT: something or other" in the boot output?
<cambrian_invader>
if I run it throuygh pytest, everything works
<NonaSuomy>
This is a similar unit seems there is an MSP430 on this unit that does something like that.
<NonaSuomy>
"Watchdog
<NonaSuomy>
There is a watchdog that will kill your session before you have a chance to do much. From the Linux kernel code (pmic_core_i2c.c) it seems you have to send command 22 with argument 0xff to the msp430 over the i2c bus (from pmic_core_i2c.c) to disable it."
<NonaSuomy>
I have something on the i2c bus but it's not at the same address 0x48 and when i triggered stuff on it, as said there it didn't stop the watchdog.
<NonaSuomy>
on the board there is an ic labelled M430 so maybe it was a common practice.
<NonaSuomy>
But who knows how they coded their MSP430
<cambrian_invader>
if you have schematics, have a look at what's connected to the reset line
<NonaSuomy>
Seem the source code there shows MX50_PIN_WDOG = _MXC_BUILD_GPIO_PIN(5, 28, 1, 0x68, 0x314),