**** BEGIN LOGGING AT Fri Jan 22 02:59:58 2021 Jan 22 03:28:49 guydudebro? Jan 22 03:29:12 GenTooMan: Were you playin' a joke-a-roo on me? Jan 22 03:57:12 no Jan 22 03:57:55 Oh. Jan 22 03:58:01 Well, I tried. Jan 22 03:58:02 you didn't run it through a powered hub did you? Jan 22 03:58:07 No. Jan 22 03:58:12 The BBB? Jan 22 03:58:36 Or the SD bridge to SATA? Jan 22 03:59:11 SD as in Secure Digital? Jan 22 03:59:19 No. SOrry. SSD. Jan 22 03:59:25 SSD bridge to SATA. Jan 22 03:59:42 Right if the bridge doesn't have it's own power supply you need to power it via a hub. Jan 22 03:59:53 Right. Okay. Jan 22 03:59:57 I will try again tomorrow. Jan 22 03:59:58 or you could burn things up Jan 22 04:00:02 Right. Jan 22 04:00:05 night and sleep Jan 22 04:00:11 Later. Jan 22 10:29:50 hi Jan 22 10:30:53 I am playing around with uboot on my am335x processor and was wondering if anyone knows how the gpio command maps gpio? because the command takes a single digit but for example my let is on gpio2 4 (per my device tree) Jan 22 10:31:11 led* Jan 22 10:32:42 Duality: the single number simply starts at 0 and counts up, 32 per block Jan 22 10:32:51 so gpio1.0 is 32 Jan 22 10:36:16 so mine would be (2 4) 2 * 32 + 4? Jan 22 10:37:10 right Jan 22 10:37:25 i see thanks! Jan 22 10:40:46 it works ! Jan 22 10:40:51 at first it didn't Jan 22 10:41:07 but then i noticed i toggled the wrong pin xD Jan 22 10:41:14 then it worked! Jan 22 14:12:12 can I ssh and have tcp connections opening and closing over 1 ethernet cable? Jan 22 15:49:04 ssh *is* a tcp conncection Jan 22 15:49:39 and yes of course Jan 22 15:55:30 i need some help with loading through xmodem and ymodem. I am on a linux system and followed this guide for uart: https://software-dl.ti.com/processor-sdk-linux/esd/docs/latest/AM335X/linux/Foundational_Components_U-Boot.html Jan 22 15:55:46 loading the MLO works just fine through xmodem Jan 22 15:56:05 but sending u-boot.img through ymodem doesn't work it just times out Jan 22 15:56:32 i know this mlo + uboot image are fine these are on my filesystem and if i powercycle the board they are loaded from a partition on my disk. Jan 22 15:56:36 why would you want to do this?! o.O Jan 22 15:56:48 but i don't know why the ymodem connection is timing out. Jan 22 15:57:12 zmatt: i want to load many boards with software through uart :) Jan 22 15:57:39 but *why* Jan 22 15:58:18 why not Jan 22 15:58:41 i want to load uboot that way on a bare system and then load the rest over network Jan 22 15:58:51 has your SPL been compiled with ymodem support? :P Jan 22 15:59:01 why not also load u-boot via network? Jan 22 15:59:24 or basically anything other than a fucking slowass uart :P Jan 22 15:59:50 yea it's not configured to do network out of the rom Jan 22 16:00:05 (yes bootrom can netboot via Ethernet, or via the USB device port (shows up as RNDIS device and then netboots via that)) Jan 22 16:01:03 it can but sysboot isn't configured that way Jan 22 16:01:12 RNDIS netboot is in the default boot order, and you can use two resistors to netboot via Ethernet Jan 22 16:01:34 i am kind of running my own board :) Jan 22 16:01:52 but i figured the x/y modem boot process wouldn't be that different? Jan 22 16:01:55 if it's a custom board you have no excuse for choosing a boot order that sucks Jan 22 16:02:15 zmatt: Well .. I did not choose it Jan 22 16:02:27 x/y modem boot does not resemble netboot Jan 22 16:02:37 did i say it did Jan 22 16:02:45 yes Jan 22 16:02:50 "wouldn't be that different" Jan 22 16:03:02 yea the uart boot process is what i meant Jan 22 16:03:53 bootrom is not involved in anything with ymodem, it just loads MLO via xmodem and after that it's up to this MLO (i.e. u-boot SPL) to do whatever it wants Jan 22 16:04:17 whether or not that includes trying to obtain u-boot.img via ymodem will depend on how SPL has been configured Jan 22 16:05:05 (and any problems with that step are u-boot issues rather than bootrom issues) Jan 22 16:06:00 oh good point Jan 22 16:06:45 so just because SPL is able to load u-boot.img from disk doesn't necessarily mean it is able to load it any other way Jan 22 16:07:08 makes sense :) Jan 22 16:07:28 thanks Jan 22 16:10:24 but what if you load a spl through xmodem that only knows to boot from disk would it just boot the uboot from there? in my setup it just stops after loading the spl. i don't see the board boot up Jan 22 16:10:53 no, SPL does know how it was loaded and that affects how it tries to load u-boot.img Jan 22 16:11:06 it does understand that it needs to load it from the same medium Jan 22 16:12:22 (bootrom passes a data structure that informs SPL how it was loaded) Jan 22 16:12:54 also, correction: when using peripheral boot methods such as xmodem you don't send an MLO, you send a raw binary Jan 22 16:13:42 what is the difference? Jan 22 16:13:54 genuinely curious :) Jan 22 16:15:11 MLO is a raw binary with a header that has the load address and the length. for peripheral boot the length is implicit in the transfer and the load address is fixed Jan 22 16:16:42 also, the file u-boot calls "MLO" might not even be that, it rudely also uses that filename when it in fact has a 512-byte "configuration header" prepended which is required for raw eMMC/SD boot (i.e. without a FAT boot partition) Jan 22 16:17:41 what do you meen the length is implicit. does that meen it's fixed length? Jan 22 16:18:09 (or to be more precise, the configuration header is only 288 bytes but the MLO is expected start from the next sector on disk) Jan 22 16:18:16 *expected to Jan 22 16:18:18 no I don't Jan 22 16:19:00 I mean the transfer protocol (XMODEM or TFTP) is already able to convey the length itself Jan 22 16:19:26 oh i see Jan 22 16:36:26 Hello everyone, wishes you guys have a nice day ! Jan 22 16:39:50 After some experience with ARM MCU 32-bit (multi-thread programming, RTOS application,..) I want to learning Linux. Could s.one help recommend me dev board for learning new tech as well as the board that has generous support. Thanks in advanced ^^1 Jan 22 16:40:50 I mean, that's a rather vague specification Jan 22 16:41:32 for "learning linux", any linux system will do Jan 22 16:42:18 Hi zmatt, I'm sorry to hear that, I mean Embedded Linux Jan 22 16:43:08 with more dive in IoT devices Jan 22 16:44:21 that's still super vague though. but if you want to do anything more involved with the hardware and the way linux interacts with it (or even just bypass it and access it directly like you would on a microcontroller) then you may prefer a device that actually has good hardware documentation, like beaglebones do (open hardware design, very detailed SoC documentation) Jan 22 16:45:04 (as opposed to the rpi which uses a mostly-undocumented broadcom SoC which you can't even buy on the open market, so any knowledge you build has limited transferability) Jan 22 16:45:49 on the other hand the rpi seems to have a bigger community and more "stuff" available for it Jan 22 16:46:06 which is more important is for you to decide Jan 22 16:47:25 Thanks, I really appreciate your answer. I prefer to know more about the hardware so maybe BeagleBone is answer Jan 22 16:47:47 if you choose to go for a beaglebone, I'd recommend either the BeagleBone Black or the BeagleBone Black Wireless... the only difference between them is that the BBB has Ethernet while the BBBW has wifi/bluetooth. I'd personally prefer Ethernet but I know that's not convenient for everyone Jan 22 16:48:27 One more ques plz, do u think I should buy BeagleBone Black or BeagleBone Black Wireless Jan 22 16:48:37 I just answered that Jan 22 16:48:40 haha I almost enter when see your suggestion Jan 22 16:48:43 :) Jan 22 16:48:51 the beaglebone is nice beacause all the hardware is documented and works with mainline linux Jan 22 16:49:43 thanks you guy Jan 22 16:50:22 to get an impression of how well documented its AM3358 SoC is, grab its Technical Reference Manual: https://www.ti.com/lit/pdf/spruh73 Jan 22 16:50:41 of course none of that information is _needed_ to do embedded linux stuff on it Jan 22 16:50:59 since linux will abstract away most of it Jan 22 16:51:22 it's still useful for understanding what can be done Jan 22 16:51:26 yes Jan 22 16:51:35 if nothing else, you'll need to figure out valid pinmux combinations Jan 22 16:51:45 this is the first time I enter a chat channel with kindness people like this. really appreciate your generous support Jan 22 16:51:51 if you go beyond what's on the bbb pcb Jan 22 16:52:21 ItachiThuan: it can be pretty quiet here, it'll depend on whether people happen to be online and looking at chat. hence the "please be patient" in channel topic :) Jan 22 16:53:39 zmatt: got it its 1PM now maybe I should sleep a bit now. Have a nice day ^^ Jan 22 16:53:58 and people are in different timezones of course Jan 22 16:54:00 mru: thanks have a nice day buddy Jan 22 16:54:10 but, good night to you :) Jan 22 16:54:43 zmatt see you later ^^ Jan 22 18:07:09 are the standard streams provided by a tty instance? Jan 22 18:17:46 ? Jan 22 18:19:50 just trying to understand how these systems work Jan 22 18:20:00 without reading the source because of a lot of resources are... Jan 22 18:20:08 insufficient Jan 22 18:20:52 stdin/stdout/stderr are merely whatever files/devices are open on fds 0/1/2, either because you opened them yourself or more commonly because you inherited them from your parent (fds are inherited across exec() unless marked as close-on-exec) Jan 22 18:21:43 yeah but i'm more concerned with how these as io streams related to TTYs which also seem to play a role in IO traditionally connecting hardware IO to a process, as far as i understand it Jan 22 18:22:07 the only way fds 0-2 are special pretty much only in convention... the only special treatment in the kernel is that (to avoid security holes resulting from that convention) on exec() if any of them are not open fds, they're opened to /dev/null Jan 22 18:22:30 a tty is merely one possible device you can read from and write to Jan 22 18:22:35 if you have the right Jan 22 18:23:09 (well, I'm oversimplifying, yada yada controlling terminal yada yada but let's ignore that for now) Jan 22 18:23:48 yeah its the details that i think i'm interested in Jan 22 18:24:09 i'm looking for how all these things interact when i create input or read output Jan 22 18:24:20 but i mean im satisfied with my lack of understanding until i can dive into the source Jan 22 18:26:36 so, for example for the serial console systemd will spawn a getty, which opens /dev/ttyS0, makes it its controlling terminal and opens it on fds 0, 1, and 2 Jan 22 18:27:15 (controlling terminal has to do with things like killing with ctrl-C and stopping background processes if they try to read from the tty) Jan 22 18:28:55 from that point on. the processes spawned from that (e.g. typically a "login" process which authenticates you and the login shell after that) have simply inherited those fds Jan 22 18:30:02 (you can also explicitly open your controlling terminal as /dev/tty, if you have the right (which is typical but not always), but there's rarely a reason to do this and it's generally considered rude) Jan 22 18:33:10 and e.g. if you type foo | bar into your shell, it will create a pipe, spawn a child process for foo (and optionally one for bar), dupping the input fd of the pipe onto the stdout of the foo-process and the output-fd of the pipe onto the stdin of the bar-process, and everything else (stdin and stderr of foo, stdout and stderr of bar) is left untouched Jan 22 18:34:00 yeah i have to read the source lol Jan 22 18:34:23 i think the tty system requires some attention from me Jan 22 18:34:40 you're going to dive into the tty subsystem? my condolences Jan 22 18:36:01 bring a dragon slayer Jan 22 18:36:28 and wear eye protection Jan 22 18:36:52 also abandon all hope Jan 22 18:37:21 I actually have a commit in the tty subsystem... a pretty trivial one, but still Jan 22 18:37:55 felicidades Jan 22 18:38:16 "pty: fix O_CLOEXEC for TIOCGPTPEER"? Jan 22 18:38:25 yep Jan 22 18:39:27 looks like I have 4 commits under drivers/tty/ Jan 22 18:39:36 all in serial/ Jan 22 18:39:46 so not the actual dragon's lair Jan 22 18:40:04 plenty of stench coming from that subdirectory too Jan 22 18:40:18 hence the need to patch it Jan 22 18:41:18 of course I had a device with an 8250 variant not quite like any of the 1000000000 already supported ones Jan 22 18:42:23 I hate 8250 and its horrid register interface with a passion... Jan 22 18:43:48 those registers with multiple meanings are extra fun Jan 22 18:44:13 and trying to shoehorn everything that's vaguely like it into a common driver (which makes me feel like noone in their right mind would want to touch that code since you'll never be able to test the impact of your changes on the zoo of kinda-but-not-quite-8250-like serial devices) Jan 22 19:01:10 aw... that good old days Jan 22 19:01:13 haha Jan 22 19:03:40 things got a bit better with the 16450's and 16550's but crap... you guys are starting to make me think your as old as i am Jan 22 19:05:36 no see, I wish I had nothing to do with that ancient thing since it is before my time, except people feel the incessant need to keep this relic alive by adding derivatives (or possibly even new ones with compatible register interface, which is a particularly horrifying thought) to modern SoCs Jan 22 19:06:08 see also: x86 Jan 22 19:06:39 I actually prefer to see as little of x86 as possible Jan 22 19:07:05 exactly, yet they keep extending it and making more of them Jan 22 19:07:21 any time I learn more about x86, I find myself wishing I knew less Jan 22 19:07:29 i tend to just ignore all that old crap not in the tree and wasn't even sure if it was still there Jan 22 19:08:14 someplace in the junk out in the shop im sure theres still a couple of tubes of 8250b and some 16550s but that was all there was back then Jan 22 19:08:50 i just took it forgranted that crap was pitched from the sources by now Jan 22 19:09:01 weird they would try and keep that Jan 22 19:09:06 not sure why Jan 22 19:09:15 and it's really just a glorified shift register Jan 22 19:09:21 where would anyone even use it any more Jan 22 19:09:34 _everything_ has a 16550-ish uart Jan 22 19:09:46 that's the part that sucks, it's still all over the place Jan 22 19:09:54 ya for sure and if one needed to be creative these days its just easier to use a shifter and a bit of logic Jan 22 19:10:06 like, every serial port on the beaglebone Jan 22 19:11:36 of all the "simple" peripheral it's definitely the most obnoxious to initialize correctly Jan 22 19:12:00 ya i guess the code/ip portion is now probably just in the soc but its probably simple to maintain as its so standardized Jan 22 19:12:20 even my new amd epyc machine pretends to have a 16550 Jan 22 19:12:36 ya i quess your right on that Jan 22 19:12:39 of course it's actually part of the aspeed bmc Jan 22 19:12:49 so it's probably emulated in software there Jan 22 19:12:52 just not something one thinks much of any more Jan 22 19:16:17 what used to be a 40 0r more pin discrete is now probably just a spec of logic cells on the wafer now Jan 22 19:20:49 i see your point tho about some poor sob having to try and keep it maintained... just something i kinda long since stopped thinking about till i you guys chattin bout it Jan 22 19:23:10 i used to have hundreds of them as there were no other ways of creating enough interfaces to hang hundreds of modems off when creating terminal servers for the early bbs's and internet Jan 22 19:25:32 there were very few hardware companies back then making big port boxes you could just buy and worse still was winblows was a pain to get to even handle that many ports Jan 22 19:26:08 when linus released his early kernel and slackware came out most of us moved to it Jan 22 19:26:09 what do you mean, there can be NO MORE THAN FOUR serial ports Jan 22 19:26:29 had to build port boxes Jan 22 19:26:39 how could you possibly manage more with 640 kB of RAM? Jan 22 19:26:40 hack them into early nt versions Jan 22 19:27:08 had to use the sysconf file to load drivers Jan 22 19:27:40 boca was the 1st one that i remember releasing a port box Jan 22 19:28:08 it had 16 ports and you could stack them using up whatever you had for isa slots on the mb Jan 22 19:28:42 then cyclades came out with a faster pci driven board when the pci slots started appearing Jan 22 19:29:12 they were more active with a propriatary driver that handled the driver hacking Jan 22 19:29:37 linux tho made things much easier from a code stand point Jan 22 19:30:35 there were a few small communties back then that usually hacked things together Jan 22 19:30:59 mostly found on uucp back then but someplace someone usually had something going on Jan 22 19:34:58 oh... man... talk about dating oneself... all those fond memories of winblows and himem.sys emm386.exe Jan 22 19:35:01 hahaha Jan 22 19:36:26 they were some of the drivers used on x86 / winblows to handle the memory limits Jan 22 19:36:53 its how windows hoped over the lower memory map barriers Jan 22 19:37:55 anyways... enough of the history crap... but i feel your pain in regards to it still being around just not thought much of it Jan 23 01:50:51 wooaaaah is me Jan 23 01:51:08 virtual box has fallen! **** ENDING LOGGING AT Sat Jan 23 02:59:57 2021