**** BEGIN LOGGING AT Wed Sep 21 02:59:57 2022
Sep 21 07:57:46 <jfsimon1981> Good morning
Sep 21 07:58:05 <jfsimon1981> Yes it more than enough, the program is a few 100 k maybe
Sep 21 07:58:42 <jfsimon1981> Ok so the console 1 Gb image
Sep 21 13:38:12 <jfsimon1981_b> zmatt
Sep 21 13:38:52 <jfsimon1981_b> Matt, one question, i'm done with the process, do you think that way's gonna be all right ? I used a TI tool from debian console image:
Sep 21 13:39:03 <jfsimon1981_b> sudo apt update && sudo apt install bb-beagle-flasher
Sep 21 13:39:08 <jfsimon1981_b> sudo beagle-flasher
Sep 21 13:39:22 <jfsimon1981_b> Very simple, seems to be doing good job so far.
Sep 21 13:39:35 <jfsimon1981_b> Final install is about 600 meg
Sep 21 13:43:25 <Beagle45> Hi there,I'm new to BBB and I try to build from scratch u-boot.
Sep 21 13:43:26 <Beagle45> I follow this tutorial (https://www.twam.info/hardware/beaglebone-black/u-boot-on-beaglebone-black)
Sep 21 13:43:26 <Beagle45> but I can't have the u-boot console instead I've
Sep 21 13:43:26 <Beagle45> U-Boot SPL 2022.07-rc6 (Sep 21 2022 - 11:33:02 +020)
Sep 21 13:43:27 <Beagle45> Trying to boot from MMC1
Sep 21 13:43:43 <Beagle45> Anyone have an idea ?
Sep 21 15:06:58 <zmatt> Beagle45: I'd generally be suspicious of any sort of tutorial or other documentation dating from 2014
Sep 21 15:11:40 <Beagle45> Yeah I found an other one https://forum.digikey.com/t/debian-getting-started-with-the-beaglebone-black/12967
Sep 21 15:12:03 <Beagle45> an it's boot from the sd to the EMMC
Sep 21 15:12:21 <Beagle45> thx for the answer
Sep 21 15:12:50 <zmatt> this is the tool used to build the official u-boot for beagleboard.org images: https://github.com/RobertCNelson/Bootloader-Builder
Sep 21 15:13:22 <zmatt> (though I have no idea how it works)
Sep 21 15:13:25 <jfsimon1981_b> ok
Sep 21 15:13:52 <jfsimon1981_b> I'll get it through
Sep 21 15:13:59 <Beagle45> good to know
Sep 21 15:14:11 <Beagle45> jfsimon1981_b
Sep 21 15:14:19 <Beagle45> good luck
Sep 21 15:14:35 <jfsimon1981_b> I ran it from the 1 GB debian console, i think it instralled an image of it into the emmc
Sep 21 15:14:54 <jfsimon1981_b> which is perfect in this case.
Sep 21 15:19:55 <Beagle45> Anyone know how to wipe the emmc on the board ??
Sep 21 15:25:22 <jfsimon1981_b> You probably run from microsd to do that
Sep 21 15:25:37 <jfsimon1981_b> burn the debian console for example into it and boot into it
Sep 21 15:26:09 <jfsimon1981_b> (press the boot switch button before poweruing up until it start to boot into the usd)
Sep 21 15:27:00 <Beagle45> jfsimon1981_b Okay thx but I'm talking about the emmc memory. I want to wipe this one
Sep 21 15:27:10 <jfsimon1981_b> exactly
Sep 21 15:27:42 <jfsimon1981_b> you run the OS from microsd then you can wipe it, when you'll run from microsd you can access and write/erase the other one, emmc.
Sep 21 15:28:03 <jfsimon1981_b> check slots with lsblk
Sep 21 15:28:21 <Beagle45> ah okay I did'nt understand thanks
Sep 21 15:28:31 <jfsimon1981_b> right
Sep 21 16:01:28 <Beagle45> I have a last newbie question.
Sep 21 16:01:28 <Beagle45> I built the kernel and then i try to boot on it it's say
Sep 21 16:01:29 <Beagle45> U-Boot SPL 2022.04 (Sep 20 2022 - 14:54:58 +0200)
Sep 21 16:01:29 <Beagle45> Trying to boot from MMC1
Sep 21 16:01:30 <Beagle45> U-Boot 2022.04 (Sep 20 2022 - 14:54:58 +0200)
Sep 21 16:01:30 <Beagle45> CPU  : AM335X-GP rev 2.1
Sep 21 16:01:31 <Beagle45> Model: TI AM335x BeagleBone Black
Sep 21 16:01:31 <Beagle45> DRAM:  512 MiB
Sep 21 16:01:32 <Beagle45> Core:  150 devices, 14 uclasses, devicetree: separate
Sep 21 16:01:32 <Beagle45> WDT:   Started wdt@44e35000 with servicing (60s timeout)
Sep 21 16:01:33 <Beagle45> NAND:  0 MiB
Sep 21 16:01:33 <Beagle45> MMC:   OMAP SD/MMC: 0, OMAP SD/MMC: 1
Sep 21 16:01:34 <Beagle45> Loading Environment from FAT... Unable to use mmc 0:1...
Sep 21 16:01:34 <Beagle45> <ethaddr> not set. Validating first E-fuse MAC
Sep 21 16:01:35 <Beagle45> Net:   eth2: ethernet@4a100000, eth3: usb_ether
Sep 21 16:01:35 <Beagle45> Hit any key to stop autoboot:  0
Sep 21 16:01:36 <Beagle45> ** Invalid partition 2 **
Sep 21 16:01:36 <Beagle45> switch to partitions #0, OK
Sep 21 16:01:50 <Beagle45> Anyone have an idea why ??
Sep 21 16:03:26 <zmatt> Beagle45: please don't spam multi-line pastes into chat, use a paste service like pastebin.com to share logs
Sep 21 16:04:08 <Beagle45> Sorry :(  I don't use much irc
Sep 21 16:04:10 <zmatt> also, I don't know what the default boot script of whatever u-boot you're using looks like, but nothing you've pasted looks like a real error to me
Sep 21 16:04:43 <zmatt> like, not being able to load environment is fine and normal (in fact, persistent environment is disabled in beagleboard.org's u-boot)
Sep 21 16:05:08 <zmatt> and my guess would be it probably gave the "invalid partition 2" error while trying to scan for partitions
Sep 21 16:05:35 <Beagle45> I cut to avoid too many lines
Sep 21 16:05:36 <Beagle45> https://pastebin.com/XDLus5DL
Sep 21 16:05:41 <Beagle45> The complete one
Sep 21 16:05:58 <Beagle45> and okay I'll check to this direction
Sep 21 16:06:00 <Beagle45> thx
Sep 21 16:06:15 <zmatt> yeah dunno, it looks like it's trying all sorts of things that don't make sense
Sep 21 16:06:27 <zmatt> why are you trying to build a custom u-boot anyway?
Sep 21 16:07:16 <Beagle45> it's to learn form scratch how things work
Sep 21 16:07:57 <Beagle45> using builtin tools it's easier but I can't really understand how it's work
Sep 21 16:10:11 <zmatt> if you want to understand how the boot flow works on a standard beagleboard.org image you may want to instead focus on understanding what the boot script of its u-boot does.  merely reproducing an u-boot build doesn't seem particularly insightful to me
Sep 21 16:11:50 <zmatt> if it's of interest, here's its default environment, reformatted to looks more like a normal shell script (for improved readability): https://pastebin.com/Kt1rUe5V
Sep 21 16:11:57 <zmatt> the entrypoint is bootcmd
Sep 21 16:13:19 <Beagle45> zmatt okay thanks
Sep 21 16:22:44 <jfsimon1981_b> Matt thanks for all your help, i'll see how that goes on now, just monitoring the lab device and client will test it too, they have 2 units.
Sep 21 16:23:17 <jfsimon1981_b> I run them on reliable emmc and they have 1 gig free so should be good for long time, probably lifetime of the device.
Sep 21 16:25:57 <jfsimon1981_b> The TI tool when run from debian console image will make an ext4 partition, copy the microsd into to, so it's really installing the content of microSD currently mounted into the emmc. I end up putting all installatin files into the emmc, run safewrite, power cycle, flash, then restart from emmc and finish installation from it.
Sep 21 16:26:08 <zmatt> jfsimon1981_b: the flasher tool isn't a TI tool
Sep 21 16:26:19 <jfsimon1981_b> Makes a 1.8 gig ready for final installation and test.
Sep 21 16:26:42 <jfsimon1981_b> Yep ok. I though Robert Nelson is from TI
Sep 21 16:27:26 <zmatt> nope
Sep 21 16:29:57 <jfsimon1981_b> yes all right
Sep 21 16:30:04 <jfsimon1981_b> but it works great
Sep 21 16:30:10 <jfsimon1981_b> i'll start with it
Sep 21 16:34:37 <Beagle45> jfsimon1981_b Felicitations :party:
Sep 21 16:38:14 <jfsimon1981_b> Sometime later i'll run reliability tests with a bb power up/off randomly, i want to see at which point the filesystem gets corrupted if at all
Sep 21 16:38:39 <jfsimon1981_b> I'll have a device to randomly power off and recycle it.
Sep 21 21:24:19 <LetoThe2nd> NishanthMenon: i keep on forgetting which machine in meta-ti-bsp shall be used for the bbai64. can you kick my memory please? ;-)
Sep 21 21:28:50 <zmatt> j721e-something
Sep 21 21:33:33 <zmatt> LetoThe2nd: almost certainly j721e-evm
Sep 21 21:33:48 <zmatt> if there's nothing bbai64-specific
Sep 21 21:34:42 <zmatt> having said that, shouldn't it have a bbai64-specific config to select the right dtb?
Sep 21 21:35:01 <jfsimon1981_b> Matt i think you throw all logs away, be aware there's a tweak file at /etc/logrotate.d/rsyslog so that you can keep and rotate logs more often to reduce waste space.
Sep 21 21:35:30 <zmatt> jfsimon1981_b: rsyslog is one of the first things I remove from a system
Sep 21 21:35:36 <jfsimon1981_b> I won't throw away logs at the moment, but i replaced the rotate weekly by daily for some of them.
Sep 21 21:35:43 <jfsimon1981_b> Ok
Sep 21 21:35:54 <jfsimon1981_b> By removing it you don't get any log then ?
Sep 21 21:36:50 <zmatt> rsyslog is redundant, systemd-journald already handles logging.  by default on beagleboard.org images it doesn't log persistently (i.e. logs are in ram only) which is also what I prefer, but you can easily enable persistent journal if desired
Sep 21 21:37:18 <jfsimon1981_b> in my case i have auth logs a lot
Sep 21 21:37:43 <jfsimon1981_b> because program calls sudo. That pollutes the filesystem
Sep 21 21:38:08 <zmatt> having a program call sudo sounds like a terrible kludge anyway, sudo is meant to be used by people, not by programs
Sep 21 21:38:19 <jfsimon1981_b> when you remove rsyslog what does it change ?
Sep 21 21:38:54 <zmatt> rsyslog takes configurable subsets of the same stuff that's logged to journal, and writes it to logfiles on eMMC
Sep 21 21:39:04 <jfsimon1981_b> yes i have to change that too, i'm using i2c command, i did'nt implement properly the main program yet so that was a quick fix.
Sep 21 21:39:28 <zmatt> I don't want logs to be written to eMMC, and I don't need these redundant legacy logs either way
Sep 21 21:39:35 <jfsimon1981_b> ok like when removed it won't go into the drive then ?
Sep 21 21:39:53 <jfsimon1981_b> Got to testit that sounds better once the system will be tested all right
Sep 21 21:40:54 <zmatt> I mean, you do you, but there's really no good reason for rsyslog anymore... not just not in production, but also not in development/testing, since journal is already keeping the exact same logs
Sep 21 21:41:44 <zmatt> (though like I said, journal on beagleboard.org images is non-persistent by default but you can easily change it to persistent if desired during development/testing, with configurable limits)
Sep 21 21:42:00 <jfsimon1981_b> ok
Sep 21 21:42:23 <jfsimon1981_b> when removing this file you don't get logs ?
Sep 21 21:42:40 <jfsimon1981_b> written to /var/log is it right ?
Sep 21 21:42:40 <zmatt> the only reason rsyslog is installed is to accomodate people who are too lazy to learn how to use journalctl to get logs from journal :D
Sep 21 21:43:02 <zmatt> rsyslog is what's writing logs in plain text to various files in /var/log/ yes
Sep 21 21:43:14 <zmatt> journal is queried using journalctl
Sep 21 21:43:18 <jfsimon1981_b> ok, so once removed it logs to ram only
Sep 21 21:43:51 <zmatt> yes, unless you enable persistent journal (by creating the directory /var/log/journal/ )
Sep 21 21:43:51 <jfsimon1981_b> i progably need to go that way long term
Sep 21 21:44:00 <jfsimon1981_b> i don't like the filesystem being written too much
Sep 21 21:44:04 <jfsimon1981_b> Ok
Sep 21 21:46:10 <jfsimon1981_b> Logs are'nt useful for your purpose ?
Sep 21 23:04:17 <zmatt> jfsimon1981_b: persistent logs on emmc?  not really no, they're just pointless emmc writes
Sep 21 23:05:06 <zmatt> and like I said (more than once) if I had a need for persistent logs in some situation I can just make journal persistent on that particular device
Sep 21 23:05:12 <zmatt> I've never felt a need to do that though
Sep 21 23:16:03 <jfsimon1981_b> yes i understood it
Sep 21 23:16:13 <jfsimon1981_b> read you
Sep 21 23:17:19 <jfsimon1981_b> i'll get the logs enable for a while, they cycle, just tune it for a week instead of a month, in case something goes wrong i can debug it
Sep 21 23:18:14 <NishanthMenon> zmatt: LetoThe2nd  - Sorry,  I dont think we have had a chance to merge the patches in TI mainline kernel atm (upstream first rule).. but we could probably post a patch to use the beagleboard kernel instead for a ai64 build
**** ENDING LOGGING AT Thu Sep 22 02:59:57 2022