<zmatt>
Guest8645: ughh, looks like there are some sections in there that were written ages ago and never updated
<tbr>
k, because there was one of those too somewhere. Vague memories, or maybe that started with the BBXM
<zmatt>
anyway, typically the easiest way to get a minimal image is to either start with a console image like tgr suggested and install the stuff you need, or conversely start with the TIDL image and use the package manager to try to remove superfluous packages
<zmatt>
I think the former is generally less work than the latter, but it depends on whether TIDL needs any weird setup or if it's just a matter of installing the relevant packages
<zmatt>
building an image from scratch using the image builder sounds to me like the worst option (since "stripping" without interactivity sounds extremely inconvenient), but I've never used the image-builder so dunno
<zmatt>
like, instead of building a new image, you can just start with the console image and install the packages you need... that way you can incrementally keep adding packages until you've determined you have everything you need
<Guest8645>
zmatt yes that's one way to do it, i'm exploring options
<zmatt>
also, I'm pretty sure the current stable kernel for TIDL is 4.14
<zmatt>
even the latest testing images use kernel 4.14 (for TIDL images specifically, non-TIDL images use kernel 4.19)
<Guest8645>
zmatt the issue is with distribution of the image, i wanna put a transparent method of getting a minimal image for an AI application that I will star making soon
<Guest8645>
zmatt thanks for the 4.14 info
<zmatt>
my strategy has been to configure a reference beaglebone and then make a master image from it, but I can see merits to using an image builder
<zmatt>
though even if I'd want to use an image builder, I'd still start with first building a system interactively to figure out what packages are actually needed/desired
<Guest8645>
yes I'm considering that option too
<Guest8645>
oooff, beagle need more love than RPi
<zmatt>
rpi has a lot of money and resources
<zmatt>
too bad they chose to go with broadcom instead of a SoC manufacturer that doesn't suck
<Guest8645>
Is TI's SoC available to buy for extremely small startups tho?
<zmatt>
they're available to buy by anyone who wants them, with a minimum order quantity of 1
<zmatt>
and extensive technical documentation (thousands and thousands of pages) freely downloadable from their website, not even registration required
<Guest8645>
yep, good news
<zmatt>
unlike broadcom which doesn't even acknowledge the existence of the RPi's processor on their website: https://www.google.com/search?tbs=li:1&q=BCM2837+site:broadcom.com
<Guest8645>
yes i saw TI linking to beagle!
<mru>
wasn't rpi created specifically so they could sell off some surplus brcm test chips?
<zmatt>
sounds implausible
<Guest8645>
beagle is a dev board and an SBC product, while RPi is not a dev board
<mru>
the soc on the first rpi was a brcm test chip
<mru>
and the founder worked for brcm
<Guest8645>
there is a embedded systems podcast that do like 2m/3m interviews
<Guest8645>
they bring CEOs of companies like RISC-V and RPi ...
<Guest8645>
I would like to hear about beagle on it :D
<zmatt>
mru: I know the rpi founder worked for broadcom, I'm going to say [citation needed] on the "test chip" thing
<mru>
it was a chip made to validate the gpu
<mru>
which is why it sucked to terribly for anything else
<mru>
like running usb in software on an arm11 core
<zmatt>
again, [citation needed]
<zmatt>
the SoC is a videocore SoC, the arm11 is an auxiliary core stuck onto the side
<mru>
I don't have a link handy
<tbr>
the ARMv6 was IIRC a USB-housekeeping core
<mru>
right
<mru>
but the rpi used it as main processor
<mru>
which is why it sucked so badly
<tbr>
yup
<mru>
it really had no time for anything but usb
<mru>
8k interrupts per second...
<mru>
on an arm11
<mru>
everybody who was around at the time knows this stuff
<mru>
they built a horrible thing, then launched a smear campaign against beagleboard
<Guest8645>
i will contact that podcast and ask him to interview "christi"
<Guest8645>
request done.
<zmatt>
mru: I'm still saying [citation needed], what was the source of this story?
<mru>
what "story"?
<mru>
that the rpi soc has an arm11?
<zmatt>
what it was a "test chip" and that the arm11 was for usb housekeeping
<mru>
the usb thing is obvious if you look at the driver code
<mru>
it's just a dumb phy with everything else done in software
<mru>
on the arm11
<mru>
everybody knows this
<Guest8645>
correct me if I'm wrong, but not even an FPU
<mru>
arm11 usually has an fpu
<mru>
but I'm not sure how that particular chip was configured
<zmatt>
yeah it has an fpu
<zmatt>
ARM1176JZ-F
akaWolf has quit [Ping timeout: 268 seconds]
<Guest8645>
"Flags: half thumb fastmult vfp edsp java tls" of so i guess not with "double"
<mru>
vfp always has single and double support
<mru>
half is optional
<mru>
there's nothing wrong with the arm11 as such
mattb0ne has joined #beagle
<mru>
other than it already being a bit old when they made the rpi
<mru>
TI omap2 was arm11 based
<zmatt>
mru: the dwc2 usb controller used on the original rpi (and many other SoCs by other manufacturers) seems like a pretty normal otg usb controller, with integrated dma controller
<zmatt>
I mean, these little otg controller stlil tend to be shit, don't get me wrong :P
<mru>
no, that one was more shit than most
<mru>
it lacked most of the usual hcd
<mru>
so software had to do that
<mru>
which is why it had 8k interrupts per second when doing nothing
<mru>
this was widely discussed back then
<mru>
I'm surprised you've never come across this before
<zmatt>
ew, an interrupt on every SOF, gross
<mru>
yes, very
<mru>
and this on a fairly slow arm11
<mru>
not much time to run any user code
<zmatt>
I mean, the overhead of linux interrupt handling obviously won't help either
<mru>
it wasn't intended to run linux
<zmatt>
if you're running baremetal then 8000 interrupts per second isn't even remotely a problem
<zmatt>
like, that's one interrupt every 87500 cycles... how many cpu cycles do you really need to kick a queued transactions or whatever it does in the SOF? 100 cycles? 200? even a ridiculous 1000 cycles would still only be about 1% cpu load
<mru>
right
<mru>
but with linux it ended up wasting something like 25% cpu time on those interrupts
<zmatt>
which of course is just sadness
<zmatt>
more than 20K cycles to grab eligible transfers from a queue and start them
<zmatt>
from what I'm reading broadcom worked around it by using a FIQ handler for this and avoid the linux interrupt handling overhead
<mru>
yes, they did some improvements later on
akaWolf has joined #beagle
<zmatt>
but yeah okay, I'll concede this usb controller is worse than most
<zmatt>
at least for use on linux
<mru>
the excuse given was that the chip was only ever meant for validation of the videocore gpu
<mru>
they had piles of them and were willing to sell them for more or less nothing
<mru>
which is how the rpi was so cheap
<zmatt>
I mean, if the chip was only means for validation of the videocore then there'd be no need to stick an usb otg controller into it
<mru>
you have to talk to it somehow
<mru>
but it's impossible to know for sure why they actually made it that way
<zmatt>
it's a full SoC with a wide range of peripherals
<mru>
not really, though
<mru>
most external connections on the rpi went through that horrid usb
<zmatt>
like what? (apart from ethernet, the lack of which isn't strange for a "cost-optimized, full HD, multimedia applications processor for advanced mobile and embedded applications" targeting "applications in media playback, imaging, camcorder, streaming media, graphics and 3D gaming")
<mru>
the chip doesn't officially exist, or didn't when they first launched the rpi
samael has joined #beagle
<zmatt>
I mean, with broadcom I have no idea how you'd tell what "officially exists" .. though archive.org shows the bcm2835 page existed on broadcom's website in september 2011, which is prior to the rpi launch
<zmatt>
0 ? i2cdetect doesn't show zeros, it shows the hex address of the device, or --, or UU
<zmatt>
i2cdetect also doesn't seem to work properly, it's claiming it can't do an smbus quick write (which is silly since the i2c controller supports arbitrary i2c transfers) so it's not even scanning 0x38-0x4f
<zmatt>
oh that's weird, the i2c-omap driver is actually claiming it doesn't support I2C_FUNC_SMBUS_QUICK
<Guest18>
sorry, thanks for the help. I need to get back on the internet. I installed new os
samael has quit [Ping timeout: 246 seconds]
<zmatt>
(ah, the omap i2c peripheral genuinely doesn't support smbus quick read/write, good to know)
starblue1 has quit [Ping timeout: 252 seconds]
<Guest18>
is that diferent from the black?
<zmatt>
no
<zmatt>
blue and black use the exact same SoC
<Guest18>
the black worked like I wanted it to. Just wanted to upgrade with on board wifi etc.
<zmatt>
why not use a beaglebone black wireless?
<zmatt>
anyway, it doesn't matter, it should work fine on any of them as long as 1. the pins are configured right 2. you're using the right bus
<Guest18>
I have run the utillity you recomended, honestly not sure how to interpret. Looks like i2c 1 scl and i2c 1 sda are listed. So I guess it is configured right
<Guest18>
i2cdetect -r 1 returns "--" at 0x39 and 0x40
<Guest18>
led to my devices are on. so power and grnd wires work
<zmatt>
you've checked the wiring? didn't accidently swap sda/scl ?
<Guest18>
oh, I bet that is it. I am using the jtc connector, it fit and I assumed ... anyway going to have to check