From rob at landley.net Sun Mar 2 17:36:24 2014 From: rob at landley.net (Rob Landley) Date: Sun, 02 Mar 2014 11:36:24 -0600 Subject: [Aboriginal] dev-environment.sh depends on gnu coreutils In-Reply-To: <5310A521.4000106@barfooze.de> References: <5310A521.4000106@barfooze.de> Message-ID: <53136C18.9070004@landley.net> On 02/28/14 09:02, John Spencer wrote: > on my busybox install (sabotage linux): > > ~/qemu/system-image-sh4 $ HDBMEGS=2048 ./dev-environment.sh > ./dev-environment.sh: line 44: truncate: command not found It's been in toybox since 2011: http://landley.net/hg/toybox/rev/396 I've been losing track of what busybox does or doesn't have, I pretty much only use the busybox-baseconfig non-toybox subset these days. > i suspect there's a portable command that could be used instead, for > example > dd if=/dev/zero of="$imagefile" bs=1 count=0 seek="$imagesize" > creates a spare file of the required size in 0.0 seconds. It used to be using that: http://landley.net/hg/aboriginal/rev/1630 Feel free to locally revert that patch, but the proper fix is either for busybox to implement truncate or for me to finish toybox. :) Rob 1393781784.0 From rob at landley.net Sun Mar 2 17:49:01 2014 From: rob at landley.net (Rob Landley) Date: Sun, 02 Mar 2014 11:49:01 -0600 Subject: [Aboriginal] qemu-system-sh4 sdb mounting broken In-Reply-To: <5310B64D.6040804@barfooze.de> References: <5310B64D.6040804@barfooze.de> Message-ID: <53136F0D.5080705@landley.net> On 02/28/14 10:16, John Spencer wrote: > /dev/sdb is not there, and there are a lot of kernel errors... > see below Yeah, I've been poking at sh4 a bit this week. If you boot to a shell prompt and then hit ctrl-c at that prompt, QEMU receives the interrupt and exits. Sigh. (Qemu bug, I should report it upstream and come up with a local patch...) The sh4 emulation only emulates one hard drive. For local hacking I did a 2 gigabyte ext2 image. AND the sh4 emulation only emulates 64 megs ram, so I created a swap file in that ext2 hda. And THEN I hit a bug where clock thought it was 1990 (make is unhappy when files are in the future), and the toybox "date" command was refusing to set the time. So, toybox bug added to the heap. But right now, the musl guys announced feature freeze for 1.0 so I've been dinking at the ccwrap rewrite to let aboriginal use musl. Doesn't look like I'll get it done this weekend, but it's bubbled to the top of my todo list due to external packages I need to stay up to date with. (Speaking of which: yes, I missed a kernel version. http://landley.net/notes-2014.html#06-02-2014 made me just not want to _think_ about the kernel for a bit. At this point my plan isnext aboriginal release will probably be two releases, catching us up on the kernel version. I should do one using 3.13 just in case anybody wants to use that specific version, and the 3.14 one at approximately the same time to catch up.) Sorry 'bout the radio silence. > + qemu-system-sh4 -M r2d -nographic -no-reboot -kernel zImage -hda > hda.sqf -append 'root=/dev/sda rw init=/sbin/ > init.sh panic=1 PATH=/bin:/sbin console=ttySC1 noiotrap HOST=sh4 CPUS=1 > ' -hdb hdb.img -m 256 -monitor null -ser > ial null -serial stdio > long read to SH7750_WCR1_A7 (0x000000001f800008) ignored > long read to SH7750_WCR2_A7 (0x000000001f80000c) ignored > long read to SH7750_WCR3_A7 (0x000000001f800010) ignored > long read to SH7750_MCR_A7 (0x000000001f800014) ignored > long read to SH7750_MCR_A7 (0x000000001f800014) ignored Those are actually qemu errors (you can tell because they're to stderr, not stdout). > Linux version 3.12.0 (landley at driftwood) (gcc version 4.2.1) #1 Mon Nov > 18 10:05:39 CST 2013 > Boot params: > ... MOUNT_ROOT_RDONLY - 00000000 > ... RAMDISK_FLAGS - 00000000 > ... ORIG_ROOT_DEV - 00000000 > ... LOADER_TYPE - 00000000 > ... INITRD_START - 00000000 > ... INITRD_SIZE - 00000000 > Booting machvec: RTS7751R2D > Node 0: start_pfn = 0xc000, low = 0x10000 > Zone ranges: > Normal [mem 0x0c000000-0x0fffffff] > Movable zone start for each node > Early memory node ranges > node 0: [mem 0x0c000000-0x0fffffff] > Renesas Technology Sales RTS7751R2D support. > FPGA version:1 (revision:0) > Built 1 zonelists in Zone order, mobility grouping on. Total pages: 16256 > Kernel command line: root=/dev/sda rw init=/sbin/init.sh panic=1 > PATH=/bin:/sbin console=ttySC1 noiotrap HOST=sh4 CPUS=1 > PID hash table entries: 256 (order: -2, 1024 bytes) > Dentry cache hash table entries: 8192 (order: 3, 32768 bytes) > Inode-cache hash table entries: 4096 (order: 2, 16384 bytes) > Sorting __ex_table... > PVR=04050005 CVR=00110000 PRR=00000113 > I-cache : n_ways=2 n_sets=64 way_incr=2048 > I-cache : entry_mask=0x000007e0 alias_mask=0x00000000 n_aliases=0 > D-cache : n_ways=2 n_sets=64 way_incr=2048 > D-cache : entry_mask=0x000007e0 alias_mask=0x00000000 n_aliases=0 > Memory: 62188K/65536K available (1977K kernel code, 136K rwdata, 264K > rodata, 96K init, 183K bss, 3344K reserved) > virtual kernel memory layout: > fixmap : 0xdfff7000 - 0xdffff000 ( 32 kB) > vmalloc : 0xc0000000 - 0xdfff5000 ( 511 MB) > lowmem : 0x8c000000 - 0x90000000 ( 64 MB) (cached) > : 0xa0000000 - 0xc0000000 ( 512 MB) (uncached) > .init : 0x8c265000 - 0x8c27d000 ( 96 kB) > .data : 0x8c1ff700 - 0x8c2649e0 ( 404 kB) > .text : 0x8c010000 - 0x8c1ff700 (1981 kB) > SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1 > NR_IRQS:8 nr_irqs:8 0 > intc: Registered controller 'sh7750' with 20 IRQs > intc: Registered controller 'sh7750_dma8' with 9 IRQs > intc: Registered controller 'sh7750_tmu34' with 2 IRQs > intc: Registered controller 'sh7750_pci' with 8 IRQs > Using R2D-PLUS interrupt controller. > intc: Registered controller 'r2d-plus' with 13 IRQs > sh_tmu.0: used for clock events > sh_tmu.0: used for periodic clock events > sh_tmu.1: used as clock source > Calibrating delay loop (skipped)... 120.00 BogoMIPS PRESET (lpj=240000) > pid_max: default: 32768 minimum: 301 > Mount-cache hash table entries: 512 > CPU: SH7751R > devtmpfs: initialized > NET: Registered protocol family 16 > PCI: Starting initialization. > bio: create slab at 0 > SCSI subsystem initialized > sh_tmu sh_tmu.0: kept as earlytimer > sh_tmu sh_tmu.1: kept as earlytimer > PCI host bridge to bus 0000:00 > pci_bus 0000:00: root bus resource [io 0x1000-0x3fffff] > pci_bus 0000:00: root bus resource [mem 0xfd000000-0xfdffffff] > pci_bus 0000:00: No busn resource found for root bus, will use [bus 00-ff] > pci 0000:00:02.0: BAR 6: assigned [mem 0xfd000000-0xfd03ffff pref] > pci 0000:00:02.0: BAR 0: assigned [io 0x1000-0x10ff] > pci 0000:00:02.0: BAR 1: assigned [mem 0xfd040000-0xfd0400ff] > Switched to clocksource sh_tmu.1 > sh_tmu sh_tmu.0: used for oneshot clock events > NET: Registered protocol family 2 > TCP established hash table entries: 512 (order: 0, 4096 bytes) > TCP bind hash table entries: 512 (order: -1, 2048 bytes) > TCP: Hash tables configured (established 512 bind 512) > TCP: reno registered > UDP hash table entries: 256 (order: 0, 4096 bytes) > UDP-Lite hash table entries: 256 (order: 0, 4096 bytes) > NET: Registered protocol family 1 > squashfs: version 4.0 (2009/01/31) Phillip Lougher > 9p: Installing v9fs 9p2000 file system support > msgmni has been set to 121 > io scheduler noop registered (default) > Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled > SuperH (H)SCI(F) driver initialized > sh-sci.1: ttySC1 at MMIO 0xffe80000 (irq = 40, base_baud = 0) is a scif > console [ttySC1] enabled > loop: module loaded > sm501 sm501: SM501 At b3e00000: Version 050100a0, 8 Mb, IRQ 100 > Attribute dbg_regs: write permission without 'store' > ------------[ cut here ]------------ > WARNING: at 8c1487c0 [verbose debug info unavailable] > > CPU: 0 PID: 1 Comm: swapper Not tainted 3.12.0 #1 > task: 8fc2c000 ti: 8fc2e000 task.ti: 8fc2e000 > PC : 8c1487c0 SP : 8fc2fe78 SR : 40008000 TEA : 00000000 > R0 : 00000034 R1 : 00000000 R2 : 40008000 R3 : 00000000 > R4 : 00000000 R5 : 8c280e1c R6 : 00000002 R7 : 00001ac4 > R8 : 8c25df38 R9 : 8c253280 R10 : 8fd5b480 R11 : 8c147d5c > R12 : 8fd5b4fc R13 : 00000000 R14 : 00000000 > MACH: 00000000 MACL: 0000005b GBR : 00000000 PR : 8c1487c0 Is that this old bug? http://lists.nongnu.org/archive/html/qemu-devel/2012-07/msg03870.html Pretty sure it wasn't doing that last time I tried it, but I'm not sure which version I was testing. I can take a look in a bit, I have to run right now... > reboot: Restarting system > Unauthorized access > qemu: fatal: Trying to execute code outside RAM or ROM at 0xa0000000 > > pc=0xa0000000 sr=0x700000f0 pr=0x8c013324 fpscr=0x00080000 > spc=0x8c01332a ssr=0x10000000 gbr=0x00463448 vbr=0x8c018000 > sgr=0x8fe6fe88 dbr=0x00000000 delayed_pc=0x8c013324 fpul=0x00000000 > r0=0x400080f1 r1=0x80000001 r2=0x10000000 r3=0x00000000 > r4=0x000000f0 r5=0x8c280e1c r6=0x00000006 r7=0x00002c4c > r8=0x01234567 r9=0x00000000 r10=0xfee1dead r11=0x01234567 > r12=0x00000000 r13=0x00000000 r14=0x7bab3d04 r15=0x8fe6fe88 > r16=0x00000000 r17=0xffffff0f r18=0x40008000 r19=0x40008000 > r20=0x8fe6fe30 r21=0x00000000 r22=0x00000000 r23=0x8fe6e000 > Killed It never rebooted cleanly. That's a qemu problem, not a kernel problem. (Hey, the emulator exits. I'll take it.) > btw, after receiving the kill signal, the terminal (xterm) is messed up > (you dont see what you type, and hitting enter displays the new prompt > in the same line instead of on a new line). Yup. Type "reset" and hit enter to fix it. Again, a qemu bug. > if otoh you run the qemu command by hand, the terminal stays intact. > putting the qemu command into a script file and calling that, the > breakage is there as well. > so it seems there's some interaction between the qemu kill and the shell > running as script processor (both bash and ash are affected). Qemu needs a signal handler to reset the terminal state. Most targets have one, sh4 doesn't. The fact they implemented qemu so you need to reimplement that per target is left as a rant for the reader... Rob 1393782541.0 From rob at landley.net Sun Mar 2 17:51:49 2014 From: rob at landley.net (Rob Landley) Date: Sun, 02 Mar 2014 11:51:49 -0600 Subject: [Aboriginal] Issue with ./dev-environment for armv7l In-Reply-To: <531101B4.3050504@barfooze.de> References: <5310DDAC.90409@gmail.com> <531101B4.3050504@barfooze.de> Message-ID: <53136FB5.3030808@landley.net> On 02/28/14 15:37, John Spencer wrote: > Tayaout Labelle Kuberek wrote: >> I have an issue with the qemu ./dev-environment not loading. The CPU > > i assume you're running dev-environment.sh with the system-image-armv6l > ? oh wait, i just see that there an armv7l system image now ... which is > kinda strange because... see below paragraph. My bad, I shouldn't have uploaded that. I have a local sources/targets/armv7l which binutils is updated to work with but gcc isn't. One of my todo items is to grab the last GPLv2 gcc release out of source control the way I did for binutils, which should have armv7 support, and then fix it up as necessary, but ellcc.org is so close to working it's on a far back burner. In the meantime, armv5 should work fine. (armv6 didn't add many interesting new instructions, it was mostly just SMP support which we're not using; no real performance benefit to it that I know of). Rob 1393782709.0 From maillist-aboriginal at barfooze.de Sun Mar 2 19:57:27 2014 From: maillist-aboriginal at barfooze.de (John Spencer) Date: Sun, 02 Mar 2014 20:57:27 +0100 Subject: [Aboriginal] dev-environment.sh depends on gnu coreutils In-Reply-To: <53136C18.9070004@landley.net> References: <5310A521.4000106@barfooze.de> <53136C18.9070004@landley.net> Message-ID: <53138D27.8040309@barfooze.de> Rob Landley wrote: > On 02/28/14 09:02, John Spencer wrote: >> on my busybox install (sabotage linux): >> >> ~/qemu/system-image-sh4 $ HDBMEGS=2048 ./dev-environment.sh >> ./dev-environment.sh: line 44: truncate: command not found > > It's been in toybox since 2011: so what ? it's by no measure a *standard* command at all. just that you implemented it for toybox doesnt make it any more portable. this is the first script i've encountered in my whole life that uses this exotic command. > > http://landley.net/hg/toybox/rev/396 > > I've been losing track of what busybox does or doesn't have, I pretty > much only use the busybox-baseconfig non-toybox subset these days. > >> i suspect there's a portable command that could be used instead, for >> example >> dd if=/dev/zero of="$imagefile" bs=1 count=0 seek="$imagesize" >> creates a spare file of the required size in 0.0 seconds. > > It used to be using that: > > http://landley.net/hg/aboriginal/rev/1630 reasoning for replacing a standard command with a non-standard one: "It's been long enough since "truncate" was introduced" huh ? you're meaning introduced to toybox ? so do you want to force anyone that wants to use aboriginal to install toybox just to be able to use some shell scripts ? come on, this is silly. my interest to compile alpha toybox is *zero*, and i dont plan to replace busybox with it until it's seen at least a decade of thorough testing in embedded products all over the world. so at the current development speed this is 20 years in the future. it's bad enough that you still stick with GNU bash scripts despite your GNU hate. > > Feel free to locally revert that patch, but the proper fix is either for > busybox to implement truncate or for me to finish toybox. :) no, the proper fix is to use a portable command, i.e. revert the patch "globally" in aboriginal. 1393790247.0 From maillist-aboriginal at barfooze.de Sun Mar 2 20:08:53 2014 From: maillist-aboriginal at barfooze.de (John Spencer) Date: Sun, 02 Mar 2014 21:08:53 +0100 Subject: [Aboriginal] Issue with ./dev-environment for armv7l In-Reply-To: <53136FB5.3030808@landley.net> References: <5310DDAC.90409@gmail.com> <531101B4.3050504@barfooze.de> <53136FB5.3030808@landley.net> Message-ID: <53138FD5.8050909@barfooze.de> Rob Landley wrote: > On 02/28/14 15:37, John Spencer wrote: >> Tayaout Labelle Kuberek wrote: >>> I have an issue with the qemu ./dev-environment not loading. The CPU >> i assume you're running dev-environment.sh with the system-image-armv6l >> ? oh wait, i just see that there an armv7l system image now ... which is >> kinda strange because... see below paragraph. > > My bad, I shouldn't have uploaded that. I have a local > sources/targets/armv7l which binutils is updated to work with but gcc > isn't. hmm in that case it looks like it would make sense to remove the broken armv7l* downloads, right ? > One of my todo items is to grab the last GPLv2 gcc release out of > source control the way I did for binutils, which should have armv7 > support, and then fix it up as necessary, would make sense either way > but ellcc.org is so close to > working it's on a far back burner. > > In the meantime, armv5 should work fine. (armv6 didn't add many > interesting new instructions, it was mostly just SMP support which we're > not using; no real performance benefit to it that I know of). does that mean armv6 is broken as well ? 1393790933.0 From tayaoutlk at gmail.com Sun Mar 2 21:43:39 2014 From: tayaoutlk at gmail.com (Tayaout Labelle Kuberek) Date: Sun, 02 Mar 2014 16:43:39 -0500 Subject: [Aboriginal] Issue with ./dev-environment for armv7 In-Reply-To: References: Message-ID: <5313A60B.1030504@gmail.com> Thanks for all the great answers. I can confirm that the armv6l package is working fine. ------------------------------ Message: 5 Date: Sun, 02 Mar 2014 21:08:53 +0100 From: John Spencer To: Rob Landley Cc: aboriginal at lists.landley.net Subject: Re: [Aboriginal] Issue with ./dev-environment for armv7l Message-ID: <53138FD5.8050909 at barfooze.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Rob Landley wrote: >> On 02/28/14 15:37, John Spencer wrote: >>> Tayaout Labelle Kuberek wrote: >>>> I have an issue with the qemu ./dev-environment not loading. The CPU >>> i assume you're running dev-environment.sh with the system-image-armv6l >>> ? oh wait, i just see that there an armv7l system image now ... which is >>> kinda strange because... see below paragraph. >> My bad, I shouldn't have uploaded that. I have a local >> sources/targets/armv7l which binutils is updated to work with but gcc >> isn't. > hmm in that case it looks like it would make sense to remove the broken > armv7l* downloads, right ? > >> One of my todo items is to grab the last GPLv2 gcc release out of >> source control the way I did for binutils, which should have armv7 >> support, and then fix it up as necessary, > would make sense either way > >> but ellcc.org is so close to >> working it's on a far back burner. >> >> In the meantime, armv5 should work fine. (armv6 didn't add many >> interesting new instructions, it was mostly just SMP support which we're >> not using; no real performance benefit to it that I know of). > does that mean armv6 is broken as well ? > > 1393796619.0 From koorogi at koorogi.info Mon Mar 3 05:45:12 2014 From: koorogi at koorogi.info (Bobby Bingham) Date: Sun, 2 Mar 2014 23:45:12 -0600 Subject: [Aboriginal] [PATCH 0/2] A couple init fixes Message-ID: I'm testing musl in Aboriginal, and these init changes are necessary for passing libc-test. The network lookback device is necessary for the socket tests, and /dev/shm is necessary for the shared memory tests. Bobby Bingham (2): Bring up loopback network device Mount /dev/shm sources/root-filesystem/sbin/init.sh | 4 ++++ 1 file changed, 4 insertions(+) -- 1.9.0 1393825512.0 From koorogi at koorogi.info Mon Mar 3 05:45:13 2014 From: koorogi at koorogi.info (Bobby Bingham) Date: Sun, 2 Mar 2014 23:45:13 -0600 Subject: [Aboriginal] [PATCH 1/2] Bring up loopback network device In-Reply-To: References: Message-ID: <757eb567cdb71ac4d699f5b9deb9f1bb384781d1.1393825221.git.koorogi@koorogi.info> --- sources/root-filesystem/sbin/init.sh | 2 ++ 1 file changed, 2 insertions(+) diff --git a/sources/root-filesystem/sbin/init.sh b/sources/root-filesystem/sbin/init.sh index 0154b2e..845dbd4 100755 --- a/sources/root-filesystem/sbin/init.sh +++ b/sources/root-filesystem/sbin/init.sh @@ -21,6 +21,8 @@ export PS1='($HOST:$CPUS) \w \$ ' # (The shell gives us a default, but it's local, not exported.) export PATH +ifconfig lo up + # If we're running under qemu, do some more setup if [ $$ -eq 1 ] then -- 1.9.0 1393825513.0 From koorogi at koorogi.info Mon Mar 3 05:45:14 2014 From: koorogi at koorogi.info (Bobby Bingham) Date: Sun, 2 Mar 2014 23:45:14 -0600 Subject: [Aboriginal] [PATCH 2/2] Mount /dev/shm In-Reply-To: References: Message-ID: --- sources/root-filesystem/sbin/init.sh | 2 ++ 1 file changed, 2 insertions(+) diff --git a/sources/root-filesystem/sbin/init.sh b/sources/root-filesystem/sbin/init.sh index 845dbd4..565bfc7 100755 --- a/sources/root-filesystem/sbin/init.sh +++ b/sources/root-filesystem/sbin/init.sh @@ -8,6 +8,8 @@ mountpoint -q sys || mount -t sysfs sys sys mountpoint -q dev || mount -t devtmpfs dev dev || mdev -s mkdir -p dev/pts mountpoint -q dev/pts || mount -t devpts dev/pts dev/pts +mkdir -p dev/shm +mountpoint -q dev/pts || mount -t tmpfs dev/shm dev/shm # If nobody said how many CPUS to use in builds, try to figure it out. if [ -z "$CPUS" ] -- 1.9.0 1393825514.0 From koorogi at koorogi.info Mon Mar 3 05:58:02 2014 From: koorogi at koorogi.info (Bobby Bingham) Date: Sun, 2 Mar 2014 23:58:02 -0600 Subject: [Aboriginal] [PATCH 2/2] Mount /dev/shm In-Reply-To: References: Message-ID: <20140303055801.GA20418@duality.lan> This is what I get for hitting send too soon. On Sun, Mar 02, 2014 at 11:45:14PM -0600, Bobby Bingham wrote: > --- > sources/root-filesystem/sbin/init.sh | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/sources/root-filesystem/sbin/init.sh b/sources/root-filesystem/sbin/init.sh > index 845dbd4..565bfc7 100755 > --- a/sources/root-filesystem/sbin/init.sh > +++ b/sources/root-filesystem/sbin/init.sh > @@ -8,6 +8,8 @@ mountpoint -q sys || mount -t sysfs sys sys > mountpoint -q dev || mount -t devtmpfs dev dev || mdev -s > mkdir -p dev/pts > mountpoint -q dev/pts || mount -t devpts dev/pts dev/pts > +mkdir -p dev/shm > +mountpoint -q dev/pts || mount -t tmpfs dev/shm dev/shm ^^^ This should be shm, of course. I'll send an updated patch -- Bobby Bingham -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: From koorogi at koorogi.info Mon Mar 3 05:59:03 2014 From: koorogi at koorogi.info (Bobby Bingham) Date: Sun, 2 Mar 2014 23:59:03 -0600 Subject: [Aboriginal] [PATCH] Mount /dev/shm In-Reply-To: References: Message-ID: <1393826343-14514-1-git-send-email-koorogi@koorogi.info> --- sources/root-filesystem/sbin/init.sh | 2 ++ 1 file changed, 2 insertions(+) diff --git a/sources/root-filesystem/sbin/init.sh b/sources/root-filesystem/sbin/init.sh index 845dbd4..54d867b 100755 --- a/sources/root-filesystem/sbin/init.sh +++ b/sources/root-filesystem/sbin/init.sh @@ -8,6 +8,8 @@ mountpoint -q sys || mount -t sysfs sys sys mountpoint -q dev || mount -t devtmpfs dev dev || mdev -s mkdir -p dev/pts mountpoint -q dev/pts || mount -t devpts dev/pts dev/pts +mkdir -p dev/shm +mountpoint -q dev/shm || mount -t tmpfs dev/shm dev/shm # If nobody said how many CPUS to use in builds, try to figure it out. if [ -z "$CPUS" ] -- 1.9.0 1393826343.0 From maillist-aboriginal at barfooze.de Mon Mar 3 16:24:13 2014 From: maillist-aboriginal at barfooze.de (John Spencer) Date: Mon, 03 Mar 2014 17:24:13 +0100 Subject: [Aboriginal] qemu-system-sh4 sdb mounting broken In-Reply-To: <53136F0D.5080705@landley.net> References: <5310B64D.6040804@barfooze.de> <53136F0D.5080705@landley.net> Message-ID: <5314ACAD.7090000@barfooze.de> Rob Landley wrote: > On 02/28/14 10:16, John Spencer wrote: >> /dev/sdb is not there, and there are a lot of kernel errors... >> see below > > Yeah, I've been poking at sh4 a bit this week. If you boot to a shell > prompt and then hit ctrl-c at that prompt, QEMU receives the interrupt > and exits. > > Sigh. (Qemu bug, I should report it upstream and come up with a local > patch...) is there a known good version of qemu-system-sh4 ? > > The sh4 emulation only emulates one hard drive. For local hacking I did > a 2 gigabyte ext2 image. hmm... in that case it may make sense if the dev-environment script has special case code for sh4 that creates an image with userdefined size and then copies the rootfs on it. otherwise anyone trying it will be puzzled that his hdb.img doesn't get mounted. > > AND the sh4 emulation only emulates 64 megs ram, so I created a swap > file in that ext2 hda. yes... > > And THEN I hit a bug where clock thought it was 1990 (make is unhappy > when files are in the future), and the toybox "date" command was > refusing to set the time. So, toybox bug added to the heap. experiencing date problems with current image as well. the clock is set to 2000-01-01, and that seems to confuse make. if the busybox date command can deal with that better, maybe it makes sense to revert that applet to busybox again. > > But right now, the musl guys announced feature freeze for 1.0 so I've > been dinking at the ccwrap rewrite to let aboriginal use musl. Doesn't > look like I'll get it done this weekend, but it's bubbled to the top of > my todo list due to external packages I need to stay up to date with. > > (Speaking of which: yes, I missed a kernel version. > http://landley.net/notes-2014.html#06-02-2014 made me just not want to > _think_ about the kernel for a bit. At this point my plan isnext > aboriginal release will probably be two releases, catching us up on the > kernel version. I should do one using 3.13 just in case anybody wants to > use that specific version, and the 3.14 one at approximately the same > time to catch up.) > > Sorry 'bout the radio silence. > >> + qemu-system-sh4 -M r2d -nographic -no-reboot -kernel zImage -hda >> hda.sqf -append 'root=/dev/sda rw init=/sbin/ >> init.sh panic=1 PATH=/bin:/sbin console=ttySC1 noiotrap HOST=sh4 CPUS=1 >> ' -hdb hdb.img -m 256 -monitor null -ser >> ial null -serial stdio >> long read to SH7750_WCR1_A7 (0x000000001f800008) ignored >> long read to SH7750_WCR2_A7 (0x000000001f80000c) ignored >> long read to SH7750_WCR3_A7 (0x000000001f800010) ignored >> long read to SH7750_MCR_A7 (0x000000001f800014) ignored >> long read to SH7750_MCR_A7 (0x000000001f800014) ignored > > Those are actually qemu errors (you can tell because they're to stderr, > not stdout). > >> Linux version 3.12.0 (landley at driftwood) (gcc version 4.2.1) #1 Mon Nov >> 18 10:05:39 CST 2013 >> Boot params: [...] >> Attribute dbg_regs: write permission without 'store' >> ------------[ cut here ]------------ >> WARNING: at 8c1487c0 [verbose debug info unavailable] >> >> CPU: 0 PID: 1 Comm: swapper Not tainted 3.12.0 #1 >> task: 8fc2c000 ti: 8fc2e000 task.ti: 8fc2e000 >> PC : 8c1487c0 SP : 8fc2fe78 SR : 40008000 TEA : 00000000 >> R0 : 00000034 R1 : 00000000 R2 : 40008000 R3 : 00000000 >> R4 : 00000000 R5 : 8c280e1c R6 : 00000002 R7 : 00001ac4 >> R8 : 8c25df38 R9 : 8c253280 R10 : 8fd5b480 R11 : 8c147d5c >> R12 : 8fd5b4fc R13 : 00000000 R14 : 00000000 >> MACH: 00000000 MACL: 0000005b GBR : 00000000 PR : 8c1487c0 > > Is that this old bug? > > http://lists.nongnu.org/archive/html/qemu-devel/2012-07/msg03870.html doesn't seem so, the emulation doesn't abort > > Pretty sure it wasn't doing that last time I tried it, but I'm not sure > which version I was testing. I can take a look in a bit, I have to run > right now... > >> reboot: Restarting system >> Unauthorized access >> qemu: fatal: Trying to execute code outside RAM or ROM at 0xa0000000 >> >> pc=0xa0000000 sr=0x700000f0 pr=0x8c013324 fpscr=0x00080000 >> spc=0x8c01332a ssr=0x10000000 gbr=0x00463448 vbr=0x8c018000 >> sgr=0x8fe6fe88 dbr=0x00000000 delayed_pc=0x8c013324 fpul=0x00000000 >> r0=0x400080f1 r1=0x80000001 r2=0x10000000 r3=0x00000000 >> r4=0x000000f0 r5=0x8c280e1c r6=0x00000006 r7=0x00002c4c >> r8=0x01234567 r9=0x00000000 r10=0xfee1dead r11=0x01234567 >> r12=0x00000000 r13=0x00000000 r14=0x7bab3d04 r15=0x8fe6fe88 >> r16=0x00000000 r17=0xffffff0f r18=0x40008000 r19=0x40008000 >> r20=0x8fe6fe30 r21=0x00000000 r22=0x00000000 r23=0x8fe6e000 >> Killed > > It never rebooted cleanly. That's a qemu problem, not a kernel problem. > (Hey, the emulator exits. I'll take it.) > >> btw, after receiving the kill signal, the terminal (xterm) is messed up >> (you dont see what you type, and hitting enter displays the new prompt >> in the same line instead of on a new line). > > Yup. Type "reset" and hit enter to fix it. good to know. can we maybe add that to the run-emulator script (at least for all known-broken archs) ? type reset > /dev/null && reset (we need to check it's there since its a ncurses command) 1393863853.0 From rob at landley.net Sat Mar 8 15:50:38 2014 From: rob at landley.net (Rob Landley) Date: Sat, 08 Mar 2014 09:50:38 -0600 Subject: [Aboriginal] [PATCH 2/2] Mount /dev/shm In-Reply-To: <20140303055801.GA20418@duality.lan> References: <20140303055801.GA20418@duality.lan> Message-ID: <531B3C4E.4090804@landley.net> On 03/02/14 23:58, Bobby Bingham wrote: > This is what I get for hitting send too soon. I'm a bit behind on my email, catching up... I thought that devtmpfs worked as tmpfs, and this just making a /dev/shm was good enough? Where do I get/how do I run libc-test? Thanks, Rob 1394293838.0 From maillist-aboriginal at barfooze.de Sat Mar 8 16:05:18 2014 From: maillist-aboriginal at barfooze.de (John Spencer) Date: Sat, 08 Mar 2014 17:05:18 +0100 Subject: [Aboriginal] [PATCH 2/2] Mount /dev/shm In-Reply-To: <531B3C4E.4090804@landley.net> References: <20140303055801.GA20418@duality.lan> <531B3C4E.4090804@landley.net> Message-ID: <531B3FBE.7090604@barfooze.de> Rob Landley wrote: > > Where do I get/how do I run libc-test? http://wiki.musl-libc.org/wiki/Libc-Test 1394294718.0 From rob at landley.net Sat Mar 8 19:44:37 2014 From: rob at landley.net (Rob Landley) Date: Sat, 08 Mar 2014 13:44:37 -0600 Subject: [Aboriginal] Build In-Reply-To: References: Message-ID: <531B7325.7040402@landley.net> On 03/08/14 10:04, David Henderson wrote: > Good morning Rob. I continued to work on getting a working kernel since > I last reached out to you. Instead of trying to build a bootable > version of AL (since I could never get that to work correctly), I just > installed qemu and used the AL system image to get into a working > development environment. I also figured out how to use the hdb.img file > to 'make menuconfig' in my host environment, and then to run 'make' > while in the qemu session. I've tried several tweaks to the kernel > config in an attempt to get a fresh one working, but it seems like an > effort in futility... > > At this point I'm simply just trying to get a working kernel so I can > continue to build the distro. This is the *most* frustrating thing to > get working!!!! Currently the build is failing with the below message: > > ...snip... > AR lib/lib.a > CC [M] lib/test-kstrtox.o > CC [M] lib/crc-ccitt.o > CC [M] lib/crc-itu-t.o > CC [M] lib/crc7.o > CC [M] lib/libcrc32c.o > CC [M] lib/crc8.o > CC [M] lib/bch.o > CC [M] lib/ts_kmp.o > CC [M] lib/ts_bm.o > CC [M] lib/ts_fsm.o > CC [M] lib/cordic.o > CC [M] lib/asn1_decoder.o > GEN lib/oid_registry_data.c > /bin/sh: line 1: perl: command not found > make[1]: *** [lib/oid_registry_data.c] Error 127 > make: *** [lib] Error 2 No idea. Let's see... vi lib/Makefile does indeed show that file having a perl generator, and git annotate says it's commit a77ad6ea from David Howells in 2012 adding fast X.509 OID lookups. My config does not enable the guard symbol for this (which is in the diff as CONFIG_OID_REGISTRY). So your config is trying to build stuff that my config isn't. $ cd ~/aboriginal/aboriginal $ more/test.sh sh4 "getconfig linux" > ~/file.txt #attached $ cd ~/linux/linux $ make allnoconfig ARCH=sh KCONFIG_ALLCONFIG=~/file.txt Compare that .config with yours? Also, you can cross compile a sh4 kernel from the host. It's something like: PATH=/home/landley/cross-compiler-sh4/bin:$PATH make \ CROSS_COMPILE=sh4- ARCH=sh And then sources/targets/sh4 says the $KERNEL_PATH where the generated image lives is arch/sh/boot/zImage under the kernel source. (It'd be nice if every qemu target could run the elf file up top, which is always "vmlinux", but alas the elf loader infrastructure isn't always hooked up...) > Obviously the AL qemu session doesn't have perl. I've tried looking up > this problem, but there doesn't seem to be any relevant information from > Google. Since you have experience pulling out perl dependencies, how > can I make this one go away? If you grab the Linux From Scratch images, they have perl. Alas, I haven't built linux from scratch under sh4 because of the emulator's crappiness (64 megs ram and only one disk), but I could use the same workarounds (make /dev/hda be ext2 with extra space, create 256 megs swap file in /home and swapon that, wget the build control image and loopback mount it on /mnt...) to do builds under that. Alas, I need to fix the toybox "date" command, and possibly tweak qemu so control-c doesn't kill the emulator... > Thanks, > Dave Rob -------------- next part -------------- CONFIG_EXPERIMENTAL=y CONFIG_NO_HZ=y CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_PCI=y CONFIG_BINFMT_ELF=y CONFIG_BINFMT_SCRIPT=y CONFIG_MAGIC_SYSRQ=y CONFIG_BLK_DEV=y CONFIG_BLK_DEV_LOOP=y CONFIG_IDE=y CONFIG_IDE_GD=y CONFIG_IDE_GD_ATA=y CONFIG_BLK_DEV_IDECD=y CONFIG_SCSI=y CONFIG_BLK_DEV_SD=y CONFIG_BLK_DEV_SR=y CONFIG_SCSI_LOWLEVEL=y CONFIG_NET=y CONFIG_PACKET=y CONFIG_UNIX=y CONFIG_INET=y CONFIG_NETDEVICES=y CONFIG_NET_ETHERNET=y CONFIG_NET_PCI=y CONFIG_8139CP=y CONFIG_HW_RANDOM=y CONFIG_RTC_CLASS=y CONFIG_RTC_HCTOSYS=y CONFIG_RTC_INTF_SYSFS=y CONFIG_RTC_INTF_DEV=y CONFIG_EXT4_FS=y CONFIG_EXT4_USE_FOR_EXT23=y CONFIG_TMPFS=y CONFIG_MISC_FILESYSTEMS=y CONFIG_SQUASHFS=y CONFIG_SQUASHFS_ZLIB=y CONFIG_DEVTMPFS=y CONFIG_VIRTUALIZATION=y CONFIG_VIRTIO_PCI=y CONFIG_VIRTIO_NET=y CONFIG_NET_9P=y CONFIG_NET_9P_VIRTIO=y CONFIG_NETWORK_FILESYSTEMS=y CONFIG_9P_FS=y CONFIG_9P_FS_POSIX_ACL=y # More random (inexplicable) guard symbols added in 3.2. TODO: write # miniconfig expander that automatically sets guard symbols when setting a # dependent symbol. CONFIG_ETHERNET=y CONFIG_NET_VENDOR_INTEL=y CONFIG_NET_VENDOR_REALTEK=y CONFIG_NET_VENDOR_AMD=y CONFIG_NET_VENDOR_NATSEMI=y CONFIG_NET_VENDOR_8390=y CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y CONFIG_SHMEM=y CONFIG_AIO=y CONFIG_PCI_QUIRKS=y CONFIG_BLOCK=y CONFIG_TTY=y CONFIG_CPU_SUBTYPE_SH7751R=y CONFIG_MMU=y CONFIG_MEMORY_START=0x0c000000 CONFIG_VSYSCALL=y CONFIG_FLATMEM_MANUAL=y CONFIG_SH_FPU=y CONFIG_SH_RTS7751R2D=y CONFIG_RTS7751R2D_PLUS=y CONFIG_SH_TIMER_TMU=y CONFIG_HW_PERF_EVENTS=y CONFIG_STANDALONE=y CONFIG_MISC_DEVICES=y CONFIG_SCSI_PROC_FS=y CONFIG_ATA=y CONFIG_SATA_PMP=y CONFIG_ATA_SFF=y CONFIG_ATA_BMDMA=y CONFIG_PATA_PLATFORM=y CONFIG_UNIX98_PTYS=y CONFIG_LEGACY_PTYS=y CONFIG_DEVKMEM=y CONFIG_SERIAL_8250=y CONFIG_SERIAL_8250_PCI=y CONFIG_SERIAL_SH_SCI=y CONFIG_SERIAL_SH_SCI_CONSOLE=y CONFIG_SPI=y CONFIG_SPI_SH_SCI=y CONFIG_MFD_SUPPORT=y CONFIG_MFD_SM501=y CONFIG_RTC_DRV_R9701=y CONFIG_FILE_LOCKING=y CONFIG_PROC_FS=y CONFIG_PROC_SYSCTL=y CONFIG_PROC_PAGE_MONITOR=y CONFIG_SYSFS=y CONFIG_CRC_T10DIF=y From rob at landley.net Sat Mar 8 23:38:41 2014 From: rob at landley.net (Rob Landley) Date: Sat, 08 Mar 2014 17:38:41 -0600 Subject: [Aboriginal] dev-environment.sh depends on gnu coreutils In-Reply-To: <53138D27.8040309@barfooze.de> References: <5310A521.4000106@barfooze.de> <53136C18.9070004@landley.net> <53138D27.8040309@barfooze.de> Message-ID: <531BAA01.60203@landley.net> On 03/02/14 13:57, John Spencer wrote: > Rob Landley wrote: >> On 02/28/14 09:02, John Spencer wrote: >>> on my busybox install (sabotage linux): >>> >>> ~/qemu/system-image-sh4 $ HDBMEGS=2048 ./dev-environment.sh >>> ./dev-environment.sh: line 44: truncate: command not found >> >> It's been in toybox since 2011: > > so what ? it's by no measure a *standard* command at all. Please point me to the posix entries for chroot, eject, ifconfig, insmod, losetup, netcat, swapon, which, whoami, yes, install, killall, reboot... heck even _tar_ isn't posix (they went with "pax" and an ever so slightly different archive format). The initramfs developers still get flames about having gone with cpio instead of tar for the archive format. (Given that the guy who made the call was Al Viro, he ignores them.) > just that you implemented it for toybox doesnt make it any more portable. Here's a freebsd man page for truncate from 2006: http://www.freebsd.org/cgi/man.cgi?query=truncate Here's the command added to coreutils in 2008: http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=commit;h=75e0047c4b916393b6be3cb985c4c4d4a2d1a836 Here's a man page from Ubuntu 10.04: http://manpages.ubuntu.com/manpages/lucid/en/man1/truncate.1.html (I think you could upgrade 8.04 and get it with the new version of coreutils, but since that hit its 5 year "long term support" end of life a year ago the upgrade servers have gone down.) Widespread deployment of this command predates qemu's 1.0 release. > this is the first script i've encountered in my whole life that uses > this exotic command. I didn't make aboriginal use it until it had been in coreutils for 5 years. I have no control over your awareness of a given command's existence, but it wasn't exactly a secret: http://landley.net/notes-2011.html#08-06-2011 >> http://landley.net/hg/toybox/rev/396 >> >> I've been losing track of what busybox does or doesn't have, I pretty >> much only use the busybox-baseconfig non-toybox subset these days. >> >>> i suspect there's a portable command that could be used instead, for >>> example >>> dd if=/dev/zero of="$imagefile" bs=1 count=0 seek="$imagesize" >>> creates a spare file of the required size in 0.0 seconds. >> >> It used to be using that: >> >> http://landley.net/hg/aboriginal/rev/1630 > > reasoning for replacing a standard command with a non-standard one: > "It's been long enough since "truncate" was introduced" No, the reasoning is that dd can never create a fully sparse file, and the truncate syntax for doing so is simple and straightfoward where the dd syntax is anything but. Also that it had been in coreutils for 5 years and in BSD before that. > huh ? you're meaning introduced to toybox ? so do you want to force > anyone that wants to use aboriginal to install toybox just to be able to > use some shell scripts ? come on, this is silly. No, if that was the case I would have made Aboriginal use the "touch -l" extension added to do this back in 2007: http://landley.net/hg/toybox/rev/162 (Which was ripped out in favor of implementing the much more standard truncate command.) > my interest to compile alpha toybox is *zero*, and i dont plan to > replace busybox with it until it's seen at least a decade of thorough > testing in embedded products all over the world. > so at the current development speed this is 20 years in the future. So you won't start using toybox for a decade after its 1.0 release. The qemu 1.0 release was December 1, 2011. So presumably you'll start using qemu in 8 years? No, that doesn't make sense. we're talking about the qemu wrapper script, all it does is launch qemu. You must mean from the START of the project. (In which case you've only got 2 more years to wait until it's a decade for toybox.) Let's see, the first commit in the qemu repository was February 18, 2003, so congratulations on your one year anniversary of using qemu! I'm sorry that my qemu wrapper script was only of use to you for part of that time. (We _are_ still discussing the contents of the qemu launcher script, right?) Leaving aside your complete dismissal of my current main project as a negotiating tactic... ("That new thing you're spending all your time on? I will _never_ care about it. Now do what I told you to do on this other thing you're only really still putting any time into as a test harness for that new thing.") You _are_ aware that projects like busybox can build individual commands, right? So you can just add the _one_ command without affecting the rest? (Even if you don't want to use scripts/single.sh you can just make allnoconfig, switch on truncate, make toybox, mv toybox truncate, just like you would with busybox?) > it's bad enough that you still stick with GNU bash scripts despite your > GNU hate. I intend to implement a reasonable bash replacement shell in toybox. That said, a todo item near the top of my aboriginal todo list is seeing how much of my scripts will run with busybox ash. (Last time I tried: not much.) Alas, given that I'm mostly using aboriginal as a toybox test bed these days and it gets about the fourth slice of my hobby programming time... (There's a ton of stuff i want to do. And with my current dayjob, 3-4 hours of commuting time to and from work each day.) >> Feel free to locally revert that patch, but the proper fix is either for >> busybox to implement truncate or for me to finish toybox. :) > > no, the proper fix is to use a portable command, i.e. revert the patch > "globally" in aboriginal. Because me pointing out the patch you can revert locally is _unclean_, and you're fighting on behalf of all those other silent people who can't be bothered. You won't use coreutils either, presumably until 4 more years have passed and the truncate command has been around for your 10 year metric. You could always install that freebsd one, you only have to wait 2 more years for that one to be "ripe". I assume asking the busybox developers to add a truncate command would still saddle you with a ten year waiting period... You could write your own truncate, since it's a trivial wrapper around a single syscall. The toybox one is 26 lines, half of which is the menuconfig entry. Almost all of the actual work is command line option parsing. But then you'd have to wait 10 years. Rob 1394321921.0 From rob at landley.net Sun Mar 9 20:46:06 2014 From: rob at landley.net (Rob Landley) Date: Sun, 09 Mar 2014 15:46:06 -0500 Subject: [Aboriginal] Moving the nameservers... Message-ID: <531CD30E.1020904@landley.net> Transferring my domain registration from whatever tucows has turned into over the years to dreamhost (which has been the web host for years, but not the DNS registrar because the old one hadn't expired yet and I didn't want to fiddle with it). The old registration expires wednesday, so digging up the administrative details for this bubbled to the top of the todo list. I hope the new one goes through before the old stops working, but can't guarantee it... If the site's down for a bit later this week, that's probably why. Rob 1394397966.0 From jazzoowatchman at gmail.com Mon Mar 10 03:42:43 2014 From: jazzoowatchman at gmail.com (Jazzoo Watchman) Date: Sun, 9 Mar 2014 23:42:43 -0400 Subject: [Aboriginal] Moving the nameservers... In-Reply-To: <531CD30E.1020904@landley.net> References: <531CD30E.1020904@landley.net> Message-ID: Thanks for the info Rob. By the way I appreciate all the gifts you've made available to the community at large. I keep looking for an opportunity to give back. Your are and indispensable inspiration. Thanks again, James On Sun, Mar 9, 2014 at 4:46 PM, Rob Landley wrote: > Transferring my domain registration from whatever tucows has turned into > over the years to dreamhost (which has been the web host for years, but > not the DNS registrar because the old one hadn't expired yet and I > didn't want to fiddle with it). > > The old registration expires wednesday, so digging up the administrative > details for this bubbled to the top of the todo list. I hope the new one > goes through before the old stops working, but can't guarantee it... > > If the site's down for a bit later this week, that's probably why. > > Rob > _______________________________________________ > Aboriginal mailing list > Aboriginal at lists.landley.net > http://lists.landley.net/listinfo.cgi/aboriginal-landley.net > -------------- next part -------------- An HTML attachment was scrubbed... URL: From maillist-aboriginal at barfooze.de Tue Mar 11 08:29:01 2014 From: maillist-aboriginal at barfooze.de (John Spencer) Date: Tue, 11 Mar 2014 09:29:01 +0100 Subject: [Aboriginal] dev-environment.sh depends on gnu coreutils In-Reply-To: <531BAA01.60203@landley.net> References: <5310A521.4000106@barfooze.de> <53136C18.9070004@landley.net> <53138D27.8040309@barfooze.de> <531BAA01.60203@landley.net> Message-ID: <531EC94D.8090100@barfooze.de> Rob Landley wrote: > On 03/02/14 13:57, John Spencer wrote: >> Rob Landley wrote: >>> On 02/28/14 09:02, John Spencer wrote: >>>> on my busybox install (sabotage linux): >>>> >>>> ~/qemu/system-image-sh4 $ HDBMEGS=2048 ./dev-environment.sh >>>> ./dev-environment.sh: line 44: truncate: command not found >>> It's been in toybox since 2011: >> so what ? it's by no measure a *standard* command at all. > > Please point me to the posix entries for chroot, eject, ifconfig, > insmod, losetup, netcat, swapon, which, whoami, yes, install, killall, > reboot... heck even _tar_ isn't posix (they went with "pax" and an ever > so slightly different archive format). doesnt change the fact that tar is available everywhere, same as dd. > > The initramfs developers still get flames about having gone with cpio > instead of tar for the archive format. (Given that the guy who made the > call was Al Viro, he ignores them.) > >> just that you implemented it for toybox doesnt make it any more portable. > > Here's a freebsd man page for truncate from 2006: > > http://www.freebsd.org/cgi/man.cgi?query=truncate > > Here's the command added to coreutils in 2008: > > http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=commit;h=75e0047c4b916393b6be3cb985c4c4d4a2d1a836 > > Here's a man page from Ubuntu 10.04: > > http://manpages.ubuntu.com/manpages/lucid/en/man1/truncate.1.html > > (I think you could upgrade 8.04 and get it with the new version of > coreutils, but since that hit its 5 year "long term support" end of life > a year ago the upgrade servers have gone down.) > > Widespread deployment of this command predates qemu's 1.0 release. it's not about that some platforms have it, it's about that some platforms have it *not*. > >> this is the first script i've encountered in my whole life that uses >> this exotic command. > > I didn't make aboriginal use it until it had been in coreutils for 5 > years. I have no control over your awareness of a given command's > existence, but it wasn't exactly a secret: > > http://landley.net/notes-2011.html#08-06-2011 > >>> http://landley.net/hg/toybox/rev/396 >>> >>> I've been losing track of what busybox does or doesn't have, I pretty >>> much only use the busybox-baseconfig non-toybox subset these days. >>> >>>> i suspect there's a portable command that could be used instead, for >>>> example >>>> dd if=/dev/zero of="$imagefile" bs=1 count=0 seek="$imagesize" >>>> creates a spare file of the required size in 0.0 seconds. >>> It used to be using that: >>> >>> http://landley.net/hg/aboriginal/rev/1630 >> reasoning for replacing a standard command with a non-standard one: >> "It's been long enough since "truncate" was introduced" > > No, the reasoning is that dd can never create a fully sparse file, and > the truncate syntax for doing so is simple and straightfoward where the > dd syntax is anything but. oh ? do you have more detail on that ? i guess it would have been helpful to have this reasoning/information in the commit message then. > > Also that it had been in coreutils for 5 years and in BSD before that. > >> huh ? you're meaning introduced to toybox ? so do you want to force >> anyone that wants to use aboriginal to install toybox just to be able to >> use some shell scripts ? come on, this is silly. > > No, if that was the case I would have made Aboriginal use the "touch -l" > extension added to do this back in 2007: > > http://landley.net/hg/toybox/rev/162 > > (Which was ripped out in favor of implementing the much more standard > truncate command.) following your logic, it's reasonable for the kernel developers to use a bit of perl here, a bit of bc there, and some python over here. because they all have been on ubuntu since 5 years. > >> my interest to compile alpha toybox is *zero*, and i dont plan to >> replace busybox with it until it's seen at least a decade of thorough >> testing in embedded products all over the world. >> so at the current development speed this is 20 years in the future. > > So you won't start using toybox for a decade after its 1.0 release. The > qemu 1.0 release was December 1, 2011. So presumably you'll start using > qemu in 8 years? > > No, that doesn't make sense. we're talking about the qemu wrapper > script, all it does is launch qemu. You must mean from the START of the > project. (In which case you've only got 2 more years to wait until it's > a decade for toybox.) no, it doesnt just launch qemu, it also prepares your work environment - and that part is broken for busybox users. > > Let's see, the first commit in the qemu repository was February 18, > 2003, so congratulations on your one year anniversary of using qemu! I'm > sorry that my qemu wrapper script was only of use to you for part of > that time. (We _are_ still discussing the contents of the qemu launcher > script, right?) you're mixing apples and oranges. qemu is not comparable to toybox/busybox: the former is a single application, the latter are collections of almost any standard utility. and i rather have these well tested. > > Leaving aside your complete dismissal of my current main project as a > negotiating tactic... ("That new thing you're spending all your time on? > I will _never_ care about it. Now do what I told you to do on this other > thing you're only really still putting any time into as a test harness > for that new thing.") i have no influence on what projects you hack on. i like and use your aboriginal project, but toybox is currently a building lot, incomplete, and lacking sufficient testing. so i see no reason apart from GPL hate (which i dont feel) to leave busybox (which is almost feature-complete, well-tested, and has almost all commands i need) behind and switch to a software in pre alpha shape. this includes playing pre-alpha-tester for toybox via aboriginal. imo you shouldnt mix these two projects together. > > You _are_ aware that projects like busybox can build individual > commands, right? So you can just add the _one_ command without affecting > the rest? (Even if you don't want to use scripts/single.sh you can just > make allnoconfig, switch on truncate, make toybox, mv toybox truncate, > just like you would with busybox?) the point here is that adding yet another command will just make my busybox binary bigger, and result in one more symlink in my already fullstuffed /bin. and having to add a new command just to make a single app that uses it happy kinda sucks. > >> it's bad enough that you still stick with GNU bash scripts despite your >> GNU hate. > > I intend to implement a reasonable bash replacement shell in toybox. > > That said, a todo item near the top of my aboriginal todo list is seeing > how much of my scripts will run with busybox ash. (Last time I tried: > not much.) > > Alas, given that I'm mostly using aboriginal as a toybox test bed these > days and it gets about the fourth slice of my hobby programming time... > (There's a ton of stuff i want to do. And with my current dayjob, 3-4 > hours of commuting time to and from work each day.) i think others use aboriginal for other purposes, which do not involve testing toybox. and in my case, i would prefer if busybox was installed instead of toybox, so stuff (including date) would just work. anyway, it was not my intention to turn this into a toybox rant. > >>> Feel free to locally revert that patch, but the proper fix is either for >>> busybox to implement truncate or for me to finish toybox. :) >> no, the proper fix is to use a portable command, i.e. revert the patch >> "globally" in aboriginal. > > Because me pointing out the patch you can revert locally is _unclean_, > and you're fighting on behalf of all those other silent people who can't > be bothered. yeah, i joined your fight to get the perl dependencies out of the kernel build process, and now i fight to get the coreutils/toybox dependencies out of the aboriginal usage process. > > You won't use coreutils either, presumably until 4 more years have > passed and the truncate command has been around for your 10 year metric. > > You could always install that freebsd one, you only have to wait 2 more > years for that one to be "ripe". > > I assume asking the busybox developers to add a truncate command would > still saddle you with a ten year waiting period... > > You could write your own truncate, since it's a trivial wrapper around a > single syscall. The toybox one is 26 lines, half of which is the > menuconfig entry. Almost all of the actual work is command line option > parsing. again, i just don't want to add yet another command just to make a single program happy. it doesnt matter how much code that program is, it matters that it sits in my /bin unused for 99.99999999999% of the time, so it just shouldnt be there to begin with. > > But then you'd have to wait 10 years. hm ? > > Rob > 1394526541.0 From rob at landley.net Sun Mar 16 21:20:21 2014 From: rob at landley.net (Rob Landley) Date: Sun, 16 Mar 2014 16:20:21 -0500 Subject: [Aboriginal] dev-environment.sh depends on gnu coreutils In-Reply-To: <531EC94D.8090100@barfooze.de> References: <5310A521.4000106@barfooze.de> <53136C18.9070004@landley.net> <53138D27.8040309@barfooze.de> <531BAA01.60203@landley.net> <531EC94D.8090100@barfooze.de> Message-ID: <53261595.1090707@landley.net> On 03/11/14 03:29, John Spencer wrote: > Rob Landley wrote: >> On 03/02/14 13:57, John Spencer wrote: >>> Rob Landley wrote: >>>> On 02/28/14 09:02, John Spencer wrote: >>>>> on my busybox install (sabotage linux): >>>>> >>>>> ~/qemu/system-image-sh4 $ HDBMEGS=2048 ./dev-environment.sh >>>>> ./dev-environment.sh: line 44: truncate: command not found >>>> It's been in toybox since 2011: >>> so what ? it's by no measure a *standard* command at all. >> >> Please point me to the posix entries for chroot, eject, ifconfig, >> insmod, losetup, netcat, swapon, which, whoami, yes, install, killall, >> reboot... heck even _tar_ isn't posix (they went with "pax" and an ever >> so slightly different archive format). > > doesnt change the fact that tar is available everywhere, same as dd. And so, these days, is truncate. That's sort of my point. >> Widespread deployment of this command predates qemu's 1.0 release. > > it's not about that some platforms have it, it's about that some > platforms have it *not*. Remember in 2010 how Ubuntu LTS didn't install "patch" by default? Or the way Fedora didn't have a _toolchain_ unless you did a magic yum incantation with a space in the name to install a dev envrionment or some such (I kept having to look that up...) Obviously, those aren't "real" commands then... >>>> It used to be using that: >>>> >>>> http://landley.net/hg/aboriginal/rev/1630 >>> reasoning for replacing a standard command with a non-standard one: >>> "It's been long enough since "truncate" was introduced" >> >> No, the reasoning is that dd can never create a fully sparse file, and >> the truncate syntax for doing so is simple and straightfoward where the >> dd syntax is anything but. > > oh ? do you have more detail on that ? Do I need to provide it? It's how the system calls work; dd does a seek and a write. You can't create a file with zero allocations by writing data to it, but writing 0 bytes is a NOP that won't extend the file (unless the kernel's changed recently). If your file _does_ have a dangling allocation at the end, and then the disk is used for something else, the result tends to be a fragmented file. It's not the end of the world, but it's untidy. > i guess it would have been helpful to have this reasoning/information in > the commit message then. Sorry, I thought you knew. I've been stomping around in this area for many years now. Here's from a decade ago: http://lkml.iu.edu//hypermail/linux/kernel/0312.1/1195.html >> Also that it had been in coreutils for 5 years and in BSD before that. >> >>> huh ? you're meaning introduced to toybox ? so do you want to force >>> anyone that wants to use aboriginal to install toybox just to be able to >>> use some shell scripts ? come on, this is silly. >> >> No, if that was the case I would have made Aboriginal use the "touch -l" >> extension added to do this back in 2007: >> >> http://landley.net/hg/toybox/rev/162 >> >> (Which was ripped out in favor of implementing the much more standard >> truncate command.) > > > following your logic, it's reasonable for the kernel developers to use a > bit of perl here, a bit of bc there, and some python over here. > because they all have been on ubuntu since 5 years. You honestly don't see a difference between perl and truncate. Truncate is a command I could (and _did) write a new implementation of from scratch in under an hour. The Perl developers rather famously failed to create a new implementation of their own project from scratch (the parrot project, to unify some of its infrastructure with python) over the course of something like 7 years. Everything there is to know about truncate fits on one screen. Everything there is to know about perl (especially given HPA's code was pulling from cpan) does not exist in any single human's head. These cases are the same to you? Really? You can't distinguish between "must use microsoft word back when nobody's ever cloned it and we just have the one magic implementation" and "I didn't like the one the system came with so I wrote my own this morning"? >>> my interest to compile alpha toybox is *zero*, and i dont plan to >>> replace busybox with it until it's seen at least a decade of thorough >>> testing in embedded products all over the world. >>> so at the current development speed this is 20 years in the future. >> >> So you won't start using toybox for a decade after its 1.0 release. The >> qemu 1.0 release was December 1, 2011. So presumably you'll start using >> qemu in 8 years? >> >> No, that doesn't make sense. we're talking about the qemu wrapper >> script, all it does is launch qemu. You must mean from the START of the >> project. (In which case you've only got 2 more years to wait until it's >> a decade for toybox.) > > no, it doesnt just launch qemu, it also prepares your work environment - > and that part is broken for busybox users. It prepares a work environment _in_qemu_. How does that invalidate the observation that the purpose of the script is to launch qemu, and everything else it does is in service to launching qemu? It can't NOT launch qemu and do anything useful, if qemu isn't on the system this script is a brick. And if you same objections were applied _to_qemu_, then qemu itself wouldn't come close to passing by your criteria. Which makes your entire line of argument kind of silly. >> Let's see, the first commit in the qemu repository was February 18, >> 2003, so congratulations on your one year anniversary of using qemu! I'm >> sorry that my qemu wrapper script was only of use to you for part of >> that time. (We _are_ still discussing the contents of the qemu launcher >> script, right?) > > you're mixing apples and oranges. qemu is not comparable to > toybox/busybox: the former is a single application, the latter are > collections of almost any standard utility. and i rather have these well > tested. So, you honestly don't know how to build+install a single command in busybox without replacing the whole of busybox, even though busybox.net explains how to do that in its FAQ? http://busybox.net/FAQ.html#backporting That technique works fine for toybox too (make allnoconfig, make, mv toybox truncate), but you can also do: tar xvjf toybox.tar.bz2 cd toybox scripts/single.sh truncate ./truncate --help I'm guessing that it's not that you don't know this, but that you don't care. >> Leaving aside your complete dismissal of my current main project as a >> negotiating tactic... ("That new thing you're spending all your time on? >> I will _never_ care about it. Now do what I told you to do on this other >> thing you're only really still putting any time into as a test harness >> for that new thing.") > > i have no influence on what projects you hack on. Given your discussion style here, I agree with that statement. > i like and use your aboriginal project, but toybox is currently a > building lot, incomplete, and lacking sufficient testing. I'm honestly not trying to force anybody to use toybox. I'm also not saying toybox originated this command. I'm saying it implemented this command _years_ after coreutils did which was _years_ after freebsd did. Busybox's failure to keep up is not my problem. Poke them. Or write a standalone one in 15 lines of C. Or, here's a fun one, google for "truncate.c" (with quotes so it actually looks for that) and on the first page of hits find: http://src.gnu-darwin.org/src/usr.bin/truncate/truncate.c > so i see no reason apart from GPL hate (which i dont feel) to leave > busybox (which is almost feature-complete, well-tested, and has almost > all commands i need) behind and switch to a software in pre alpha shape. Obviously since I'm using bash you had to switch from busybox to coreutils, because you can't use a different shell implementation when busybox already has a shell implementation. It's utterly impossible to disable a busybox command, or install things that aren't busybox on to your system, or ask the busybox developers to add a trivial system call wrapper command... I'm really not following your argument here. > this includes playing pre-alpha-tester for toybox via aboriginal. > imo you shouldnt mix these two projects together. Your opinion has been noted. Thank you for telling me what I should do with my hobby programming time. At great length. >> You _are_ aware that projects like busybox can build individual >> commands, right? So you can just add the _one_ command without affecting >> the rest? (Even if you don't want to use scripts/single.sh you can just >> make allnoconfig, switch on truncate, make toybox, mv toybox truncate, >> just like you would with busybox?) > > the point here is that adding yet another command will just make my > busybox binary bigger, and result in one more symlink in my already > fullstuffed /bin. and having to add a new command just to make a single > app that uses it happy kinda sucks. $ ls -l /usr/local/bin/qemu-system-arm -rwxr-xr-x 1 root root 5832320 Jul 8 2013 /usr/local/bin/qemu-system-arm (Checking... yes, that's stripped, and not dynamically linked.) So, a little under 6 megabytes, as opposed to: $ wget http://src.gnu-darwin.org/src/usr.bin/truncate/truncate.c 100%[======================================>] 4,903 --.-K/s in 0.1s $ gcc truncate.c -s -Os $ ls -l a.out -rwxrwxr-x 1 landley landley 10392 Mar 16 15:44 a.out 10k for the standalone BSD version, which built out of the box first try for me. Riiight... I'm assuming the problem is a shortage of inodes maybe? Have you tried installing busybox with hardlinks instead of symlinks? (Each symlink takes an inode, each hardlink does not.) Again, this script _launches_qemu_. That's what it's for. It does so with some rather elaborate setup, but running qemu is the purpose of the script, and you can't run the script in a way that _doesn't_ launch qemu. If you want to use something other than qemu, you have to modify or provide your own script. And you're complaining about the addition of 10 kilobytes to an overhead of 5.8 megabytes, so an expansion of 0.000086%. >>> it's bad enough that you still stick with GNU bash scripts despite your >>> GNU hate. >> >> I intend to implement a reasonable bash replacement shell in toybox. >> >> That said, a todo item near the top of my aboriginal todo list is seeing >> how much of my scripts will run with busybox ash. (Last time I tried: >> not much.) >> >> Alas, given that I'm mostly using aboriginal as a toybox test bed these >> days and it gets about the fourth slice of my hobby programming time... >> (There's a ton of stuff i want to do. And with my current dayjob, 3-4 >> hours of commuting time to and from work each day.) > > i think others use aboriginal for other purposes, which do not involve > testing toybox. and in my case, i would prefer if busybox was installed > instead of toybox, so stuff (including date) would just work. You noticed the "BUSYBOX=1" config option in Aboriginal's config, right? QEMU is not in busybox. This is a wrapper script to launch QEMU. Building QEMU these days requires all sorts of libraries, a fairly elaborate build environment. That was the context within which I wrote the script. the build system itself is recapitulating phylogeny and carefully tracking the dependencies necessary to recreate itself from first principles. But the emulator is a giant deus ex machina hairball of extraneous crap I can't finitely define, and you get it from "elsewhere". The emulator is optional. You can also run on real hardware. The qemu launch scripts don't do that. They provide a template you can use to write your own script to do stuff on real hardware, but in their current form they do not. The one line patch to replace truncate with dd is noise compared to the changes necessary to format an sd card or flash through openocd or drive and expect to get u-boot to tftp fetch and boot an image. That said, I _do_ provide an implementation of the truncate command as used by those scripts. Busybox doesn't, but aboriginal's default configuration does. (I don't feel obligated to do so at the design level, because it _is_ a qemu wrapper script and qemu is out of scope, thus the script to drive qemu is out of scope.) But your refusal to use the code I provided, or install any of the multiple alternatives I've suggested, or patch it out locally, really isn't my problem. > anyway, it was not my intention to turn this into a toybox rant. *shrug* >>>> Feel free to locally revert that patch, but the proper fix is either >>>> for >>>> busybox to implement truncate or for me to finish toybox. :) >>> no, the proper fix is to use a portable command, i.e. revert the patch >>> "globally" in aboriginal. >> >> Because me pointing out the patch you can revert locally is _unclean_, >> and you're fighting on behalf of all those other silent people who can't >> be bothered. > > yeah, i joined your fight to get the perl dependencies out of the kernel > build process, and now i fight to get the coreutils/toybox dependencies > out of the aboriginal usage process. And you don't see any difference between them. Did you notice that I'm not pushing my bc removal patch upstream? Introducing that was a nasty thing for Peter Anvin to do, it broke Linux >From Scratch and buildroot and openembedded and so on. But: it's a posix command, so the correct thing for me to do is implement bc in toybox. (Which is horrible because it's an arbitrary precision calculator, which is why I've been reading the libtommath code.) The fact it was not humanly possible for me to do that with perl is why I lobbied to remove the dependency on perl. There _is_ no specification for perl. There is just a single implementation that grew by accretion over multiple decades. (And on top of that the code peter stuck in the kernel sucked in additional code from the CPAN repository for any nondefault configuration, so it required extensions _beyond_ the base perl to function.) >> You won't use coreutils either, presumably until 4 more years have >> passed and the truncate command has been around for your 10 year metric. >> >> You could always install that freebsd one, you only have to wait 2 more >> years for that one to be "ripe". >> >> I assume asking the busybox developers to add a truncate command would >> still saddle you with a ten year waiting period... >> >> You could write your own truncate, since it's a trivial wrapper around a >> single syscall. The toybox one is 26 lines, half of which is the >> menuconfig entry. Almost all of the actual work is command line option >> parsing. > > again, i just don't want to add yet another command just to make a > single program happy. Then patch it out. > it doesnt matter how much code that program is, it > matters that it sits in my /bin unused for 99.99999999999% of the time, > so it just shouldnt be there to begin with. By that logic you shouldn't have a "reboot" command either. >> But then you'd have to wait 10 years. > > hm ? Well if I write code and you won't use it for ten years, even if you inspect it, then presumably if _you_ write code it has to age for ten years before it's worth using. Strange that this prohibition does not apply to qemu for some reason, and in fact half the point of aboriginal is to let you use new versions of the kernel and busybox and such... Ah, there's your solution! Use the previous release of aboriginal, and never upgrade again, because no _new_ code can be worth using until it's been around for 10 years, and thus a project whose releases are driven by quarterly kernel releases of new kernel code can't possibly be of interest to you. I'm constantly introducing new package versions that destabilize stuff, that's the main reason for new releases, and obviously that's a bad thing for you. Besides, I'm currently working on a rewrite of ccwrap to let me switch the whole thing from uClibc to musl libc, and you'd have utterly hated that. Rob 1395004821.0 From rob at landley.net Thu Mar 20 01:32:30 2014 From: rob at landley.net (Rob Landley) Date: Wed, 19 Mar 2014 20:32:30 -0500 Subject: [Aboriginal] I was on a podcast. Message-ID: <532A452E.2060901@landley.net> I got interviewed about toybox (and talked a bit about aboriginal) on the most recent Linux Luddites podcast: http://linuxluddites.com/shows/episode-11/ Just FYI, Rob 1395279150.0