behanw has quit [Quit: Connection closed for inactivity]
GNUtoo has quit [Ping timeout: 268 seconds]
GNUtoo has joined #u-boot
thopiekar has quit [Ping timeout: 252 seconds]
thopiekar has joined #u-boot
thopiekar has quit [Ping timeout: 252 seconds]
thopiekar has joined #u-boot
camus1 has joined #u-boot
camus has quit [Remote host closed the connection]
camus1 is now known as camus
jclsn has quit [Ping timeout: 260 seconds]
jclsn has joined #u-boot
rvalue has joined #u-boot
vagrantc has quit [Quit: leaving]
Rusty_Almighty has joined #u-boot
<Rusty_Almighty>
I'm attempting to test the memory on a custom board that I am building and am getting an error while testing memory in uboot in the highest regions of memory. However, when running my OS, I get no errors. Is there a reserved upper bound in memory that cannot be overwritten in uboot?
<tpw_rules>
not u-boot specific advice, but how are you sure there's actual ram there? seems unlikely for just one bit to be bad at some random address like that
<Rusty_Almighty>
Uboot's dminfo shows that I have 1 bank of memory that is 2 GiB in size.
<Rusty_Almighty>
Size=0x80000000, I should be able to run the mem-test to Size=0x7FFFFFFF.
<tpw_rules>
i mean it says right there that irq_sp is 0x7F7182C0
<tpw_rules>
purely based on the name, i'd hypothesize that memory testing was happening, an irq fired, the stack grew by a hundred bytes or so and overwrote the test data, then it failed
<tpw_rules>
few hundred*
<tpw_rules>
so there is actual ram there, it's just reserved for something else
<tpw_rules>
u-boot's actual code is at the relocaddr, so if you hadn't bumped into the stack you would have overwritten u-boot itself and crashed
<tpw_rules>
and the fact that u-boot is working okay probably means the ram it is running from is good
<Rusty_Almighty>
So, what is the highest address testible?
<tpw_rules>
i'd personally pick irq_sp minus a megabyte or so
<tpw_rules>
0x7f600000?
persmule has quit [Ping timeout: 268 seconds]
<Rusty_Almighty>
Hmm, why can't you use 0x7F7182C0 - 0x1 (The memory just below the irq_sp)?
<Rusty_Almighty>
Why go down an extra megabyte?
persmule has joined #u-boot
pbergin has joined #u-boot
Rusty_Almighty has quit [Quit: Leaving.]
tre has joined #u-boot
persmule has quit [Ping timeout: 268 seconds]
mmu_man has joined #u-boot
frieder has joined #u-boot
persmule has joined #u-boot
prabhakarlad has joined #u-boot
mmu_man has quit [Ping timeout: 268 seconds]
matthias_bgg has joined #u-boot
persmule has quit [Remote host closed the connection]
persmule has joined #u-boot
monstr has joined #u-boot
jagan has joined #u-boot
<milkylainen>
marex: did you ever look closer at tf-a trusted board boot chain of trust?
persmule has quit [Remote host closed the connection]
persmule has joined #u-boot
persmule has quit [Remote host closed the connection]
persmule has joined #u-boot
destmaster84 has joined #u-boot
<destmaster84>
I've encoutered this error during UBI boot from NAND
rvalue has quit [Read error: Connection reset by peer]
rvalue has joined #u-boot
destmaster84 has quit [Quit: Client closed]
rvalue has quit [Read error: Connection reset by peer]
rvalue has joined #u-boot
tre has quit [Remote host closed the connection]
torez has joined #u-boot
indy has joined #u-boot
indy has quit [Client Quit]
kallisti5[m]1 has joined #u-boot
akaWolf has quit [Ping timeout: 260 seconds]
akaWolf has joined #u-boot
prabhakarlad has quit [Quit: Client closed]
mthall has quit [Ping timeout: 252 seconds]
mthall has joined #u-boot
pbergin has quit [Quit: Leaving]
mthall has quit [Ping timeout: 252 seconds]
mthall has joined #u-boot
prabhakarlad has joined #u-boot
indy has joined #u-boot
mmu_man has joined #u-boot
ldevulder has quit [Quit: Leaving]
vagrantc has joined #u-boot
frieder has quit [Remote host closed the connection]
torez has quit [Quit: torez]
ldevulder has joined #u-boot
akaWolf has quit [Ping timeout: 260 seconds]
Guest9156 has joined #u-boot
Guest9156 has left #u-boot [#u-boot]
akaWolf has joined #u-boot
monstr has quit [Remote host closed the connection]
GuestGuy has joined #u-boot
<GuestGuy>
I have u-boot source for some Chinese IoT devices. The manufacturers don't typically respond to requests for source.
<GuestGuy>
For whatever reason, they all seem to be stuck on u-boot 2010.06
<GuestGuy>
Before I get too invested in this... how much work would it be to get the latest version of u-boot working for these devices in a way that I can submit pull requests to have the boards included in u-boot?
<marex>
which SoC is that ?
<marex>
it might be already supported upstream
<GuestGuy>
Assuming the manufacturers have at least somewhat ported it without making a huge mess
<GuestGuy>
Fullhan FH8830/FH8630
<GuestGuy>
Also some older Fullhan SoCs
<marex>
is there documentation for this hardware ?
<GuestGuy>
mostly used in IP cameras
<marex>
ok, not supported btw
<GuestGuy>
I have some documentation in Chinese
<GuestGuy>
and u-boot source and toolchain
<marex>
GuestGuy: seems like an ARM SoC ?
<marex>
GuestGuy: so you can attempt the new SoC port, sure
<marex>
hanetzer: ^
<GuestGuy>
As a first step, I was planning on diffing the source I have against U-Boot 2010.06-svn-43155 but don't know how to get this exact version.
<GuestGuy>
it's ARM1176
<hanetzer>
oh hey.
<marex>
U-Boot never was tracked in SVN to my knowledge, it was CVS and then git
<marex>
so ... that svn is probably something internal to the vendor
<hanetzer>
yeh.
<marex>
but look for CHANGELOG or HISTORY or some such file
<GuestGuy>
I'll start with 2010.06
<hanetzer>
2010.06 strikes again.
<marex>
it used to be included back in the day
<GuestGuy>
Yes, there is a changelog that, oddly, doesn't appear to be in chronological order
<GuestGuy>
I guess if you make cheap devices it means that you have to use a 12 year old version of u-boot
<marex>
not really
<hanetzer>
marex: for the record: that device is burnt out to some degree; uart input is no longer functional. I've ordered a replacement and am fiddling out the svd file for now until I get it.
<GuestGuy>
that was a joke
<hanetzer>
GuestGuy: assuming you're into making a full port and there are a number of socs in that family that boot similarly, the arch/arm/mach-rockchip tree strikes me as a good example for laying out the new tree.
<GuestGuy>
I have docs for a few SoCs and I know there are more out there... if I could find them
<GuestGuy>
but this is my first time working with u-boot source and I'm not much of a programmer... mainly I'm annoyed with these cheap devices for having such shitty software and/or locking down u-boot
<hanetzer>
get used to it :D
<hanetzer>
embrace the jank
<GuestGuy>
Seems like the right place to start is adding support for them to u-boot
<hanetzer>
yeah maybe. not familiar with arm1176
<marex>
hanetzer: that's armv6 kind of RPi1 and iMX31/35 ilk I think
<marex>
in debian, use armhf toolchain iirc
<marex>
or was it armel ?
<marex>
for u-boot, either works
<GuestGuy>
I have the SDK including u-boot source and toolchain. Maybe I'm getting ahead of myself here and need to start with building a working binary for the board I actually have on-hand.
<marex>
GuestGuy: reproducing a working build from provided sources is indeed a good start
<marex>
a way to restore the bootloader on board is also a good thing, i.e. debugger
<GuestGuy>
Is there something about versions newer than 2010.06 that might make them unsuitable for devices with limited resources?
<marex>
limited resources how ?
<GuestGuy>
No idea, I keep thinking that there must be a reason that version is used on so many devices and don't want to put a lot of effort into something that's not feasible
<GuestGuy>
size constraints maybe?
<marex>
GuestGuy: could be a lazy vendor
raindancer has joined #u-boot
<GuestGuy>
so... it includes a bin without source: fh_mkimage
<cambrian_invader>
yes, lazy vendor
<cambrian_invader>
they fork when the make the first device
<hanetzer>
GuestGuy: also spi flash clips if a full debugger isn't possible.
indy has quit [Ping timeout: 248 seconds]
<GuestGuy>
hanetzer I haven't had great lucks with chip clips. Even bought Pamona thinking it would be better
<GuestGuy>
I have a hot air gun, decent soldering station, and a flash programmer
<hanetzer>
ah. well, if you can't get them to work there's not much I can say about it. yeah, if you can do that that works too.
<GuestGuy>
Also am attempting to put together some contraption to make it easy to swap SOP8 ICs
<GuestGuy>
I have no fear of soft bricking... just destroying the hardware haha
indy has joined #u-boot
<hanetzer>
GuestGuy: sop8 or soic8?
<hanetzer>
for the latter there are uh, sockets you can put it in, that solder into a soic8 footprint
<GuestGuy>
What is the difference between soic8 and sop8?
<GuestGuy>
They look nearly identical
<hanetzer>
probably something very subtle.
<GuestGuy>
I've wondered a few times. Found this: Another name of SOP is called SOIC, JEDEC standard are called SOIC in the United States, and JEITA standard one is called SOP in Japan, and the body width of the former one is larger than the latter.
<GuestGuy>
I almost bought one of the surface mount sockets but was worried I would tear the pads off the board
<hramrach>
there is some slight variation in the package and on some the clips work quite well and on others they don't
<hanetzer>
GuestGuy: btw. re, their patched mkimage thing. should be easy enough, in theory, to take some known blob, pass it thru, and compare the results to figure out what their thing is.
<GuestGuy>
hanetzer I wasn't sure if that could be supplied with u-boot since it appears to be independent from u-boot, and I don't have source or license
<GuestGuy>
anyway doesn't look like it does too much
<hanetzer>
it should be. it appears to be mkimage patched, which is a u-boot proggie
<GuestGuy>
oh, that's good news
<hanetzer>
yeah. so maybe the u-boot they provided has the patches.